You Can Put Your Data in the Cloud

Throughout recent engagements with our clients we see a recurring theme…

 All our clients:

• want to move faster
• want the benefits realised by moving to the cloud
• want to be sure all their data is secure

There is a deep-seated belief that the above three bullet points are associating incompatible ideas or contradictions in terms, that you cannot have your cake and eat it too.  There are (too) many articles online which suggest that it is ok to use the cloud but that sensitive data should be treated differently and stored ‘more securely’.   

This article seeks to challenge that viewpoint with first-hand evidence gained from working with AWS and our own deep-dives into how AWS works for our clients.

Starting first with the guidance provided in the NCSC’s cloud security principles, two of the principles to consider when protecting data on the cloud are :

1. User data transiting networks should be adequately protected against tampering /eavesdropping.
2. User data, and the assets storing or processing it, should be protected against physical tampering, loss, damage or seizure.

AWS have cross referenced the NCSC’s principles with their controls and mitigations here.  This document along with the support from the AWS security team was invaluable to understand some of the security processes and ways of working that enhance their security posture, and indeed flag any areas for further discussion. 

Through some of our client engagements and our Select partnership with AWS. We have been fortunate enough to spend time with quite a number of AWS’ security team, including the General Manager of the AWS Key Management Store (KMS) and the Vice President of AWS Cryptography.

The security of data is paramount to any public cloud provider.  Any data leakage would be catastrophic for their reputation. Amazon have invested very heavily in security, and with the full weight of AWS behind them, their target operating model is ubiquitous encryption.  The result is a comprehensive set of services designed to move and store data securely.

The diagram above outlines the envelope encryption used by AWS, and the key point to remember is that ultimately a master key will need to be stored somewhere in plain text (in this case the KMS).

And above visualises the two tiered hierarchy of encryption for the AWS services.

These services are designed to work in concert to provide all the relevant capability to achieve ubiquitous encryption, for example the KMS is a managed service designed to protect and control encryption keys.  The permission to use keys is managed solely by customers; permission is granted via the fully integrated AWS IAM. The Customer Master Key (CMK) is only available via the secure KMS, there are no tools or APIs to access the CMK directly as plaintext.  The key is only available in volatile memory on the customer’s instance (usually for milliseconds although dependant upon the size of the task), and access to the volatile memory is now protected by AWS Nitro to prevent compromise of the hypervisor, so it is not possible to dump the memory of instances running on the Nitro architecture.  Critically, data keys are not managed by the KMS. No single AWS operator can access a Hardware Security Module hosting the KMS. Further to this, as the design stands, multiple operators cannot access data within a customer’s HSM*. Furthermore all access to the KMS is fully audited anyway.

*There is a risk that multiple people could be compromised to edit the APIs into the KMS and in doing so enable access to customer’s keys.  This would require at least two developers and two separate operators to work together to develop and upload new software compromise updates.

The AWS approach to security, enabling the use of server side encryption for AWS services (including S3 and EBS) provides the most proportional and holistic solution to help manage the protection of data in the cloud.  A golden rule to follow is not to encrypt the data using your own ‘smarts’. It may be that you can access the brightest minds to produce a more secure encryption algorithm than AES-256, but incorporating the generation of the keys, maintaining those keys and protecting their usage will result in a less secure solution than that provided at no extra charge by AWS.

At Naimuri, we believe that starting with the data protection services offered by AWS and building upon these with appropriate solutions that offer more defense, provides a solution that is highly secure for most use cases.  For example, one of the biggest risks when storing data in the cloud isn’t hacking by competitors, it is more likely as a result of misconfiguration of the system by your own people. Using AWS’ security groups alongside bespoke firewalls mitigates this issue, although it does make the management of the environment more complicated.  That is when you need a tried and tested approach to build, test and deploy where everything, including all the infrastructure is captured as code. But that’s another story…