by Dob Todorov, Chief Cloud Officer at HeleCloud™
I am always surprised when in discussions with even experienced IT security specialists encryption is brought up as either the fundamental requirement for security in the Cloud, or as the ubiquitous solution for it. I think it’s important to provide some clarity here: it’s horses for courses.
Encryption is simply a tool that addresses a specific subset of scenarios for protecting data confidentiality, whether in the Cloud, or elsewhere. Not all security controls are based on encryption; as a matter of fact, only a few security controls in an organisation’s Cloud-based environment are likely to rely upon encryption in itself. Let’s look at four common encryption-based use cases:
Use case 1: A good use case for encryption in the Cloud is data confidentiality in flight: while a user is accessing their Cloud services over a public network such as the Internet, one needs a mechanism to protect private data from prying eyes while in transit and encrypt it. This comes at a minimum cost (CPU and memory utilisation, and perhaps the cost of X.509/SSL/TLS certificates), it is critical to all types of network communication, and I wouldn’t embark on elaborate Cost/Benefits Analysis here: given its negligible cost, one should just implement it, especially across the Internet.
Use case 2: A marginally good use case for encryption is the protection of data at rest while persisted in the Cloud on services such as Amazon’s Elastic Block Store (EBS) or Simple Storage Service (S3). Many organisations often tick the box and encrypt data at rest thus considering the data confidentiality case done and dusted. To the seasoned security professional, however, it is often clear that such an approach would only protect the data from unauthorised access by the Cloud Services Provider (CSP); and by definition, a customer would trust their Cloud services provider to not access their data – otherwise, they wouldn’t engage with this CSP in the first instance. The edge case of a rogue Cloud services engineer accessing customer data is in general very unlikely (much more so than the customer’s own engineers doing that), not least because of the level of controls and scrutiny normally imposed by Cloud Services Providers on their infrastructure. By and large, Cloud customers place too much reliance on encryption of data at rest – while the reality is that it actually deserves limited attention – especially in comparison to other aspects that need to be considered. This use case has more than marginal importance in case of compliance requirements – and there is a few of these that would blindly require encryption of data; if one is encrypting to satisfy compliance requirements – then so be it.
Use case 3: Encryption at rest becomes more than marginally important and is a very powerful tool for organisations that want to accomplish isolation between multiple entities or users: for example, protecting the confidentiality of data per project, or per level of access. Using separate per-project keys within a single AWS account is a common technique for protecting EC2 instances, AMIs, S3 files, etc.
Use case 4: Encryption of confidential data in relational and NoSQL databases is another good example of what one needs to consider when protecting data in the Cloud. Different databases allow for different levels of encryption, including the whole database, column, specific records and fields, etc. PCI/DSS compliance may dictate credit card PAN numbers to be encrypted but not necessarily other user data. Certain applications may employ keys that allow them to access encrypted data stored within a database, and these keys may not be available to the database administrator, who only sees encrypted blobs in particular fields. This is similar to use case 3, where encryption is used to isolate and segregate access to data in a shared environment (in this case – within a single database).
These are perhaps the most common use cases that one needs to employ encryption for. However, that’s not all when it comes to implementing encryption – key management: encryption (and for the most part – cryptography in general) uses keys to protect data, and only works as intended if one can protect these cryptographic keys and keep them secret. Encryption is a tool that should be always paired with key management as a supporting tool. The fact that one is encrypting data matters little unless they can demonstrate that they are managing the encryption keys properly.
Asymmetric keys are easier to manage: one only shares the public key, and does so in a very public way, with all other parties, while keeping the private key strictly confidential. Certificates provide an identity and trust chain wrapper around asymmetric keys, thus making them very easy to use at a low cost, and with very wide support. When it comes to the protection of data in flight – for example, HTTP over SSL/TLS (aka HTTPS), server-side certificates are likely all one needs, and these can be very easily managed by using the Amazon Certificate Manager (ACM). For protocols such as IPSec, one would typically issue certificates using their own PKI infrastructure and manage these accordingly.
Symmetric keys are much harder to manage: they protect data and are confidential, so they themselves become confidential data, and in order to protect them – one needs other keys, which in turn need to be protected, etc. Symmetric keys would typically be generated and stored in a secure location – an HSM (such as Amazon’s CloudHSM), or a software vault (such as HashiCorp’s Vault). Another very powerful solution that not only generates the keys, but can also manage access to them, rotates the keys, and protects them in a hierarchical fashion with strong cryptographic algorithms is Amazon’s Key Management Service (KMS). In fact, unless one is prepared to make a significant investment in establishing a dedicated team, a set of processes, and highly secure infrastructure to do comprehensive key management, KMS is likely the best option.
In summary, protecting data confidentiality in the Cloud is much more than ticking a few checkboxes and hoping that it’s all safe and secure; such an approach would give one a false sense of protectedness. Encryption should be employed alongside the right key management mechanisms, and only where required. In addition, organisations need to consider various other controls as well, and not simply rely upon encryption as the ubiquitous protection tool: identity and access management, network threat management, vulnerability management, patch management, secure CI/CD, SecDevOps, and security information and event management are all examples of security aspects that organisations need to consider besides encryption. And in security, one is as strong as the weakest link – so organisations should not over-index on encryption but need a comprehensive security strategy in the Cloud. The AWS Security Best Practices Whitepaper, the AWS Well-architected Whitepaper, and the AWS Cloud Adoption Framework all provide excellent guidance for establishing secure and compliant environments in the Cloud.