According to industry surveys, like the IBM 2021 Data Breach Investigations Report, a very high percentage of data breaches occur because attackers are abusing system privileges. It won’t be wrong to note that “criminals are not breaking in, they are logging in,” as Uri Rivner, Founder & CEO at Regutize highlighted in the Thales Security Sessions podcast. When it comes to cloud security, the overarching security principle is that of shared responsibility. Cloud customers are responsible for the security and protection of data stored in the cloud.
Segregation of duties separate you from dangers
An important concept of this security model is the segregation of duties – the administrators managing the systems where data are stored should be separate from the security teams imposing controls for the protection of this data. Without proper separation of duty, it would be very difficult to prevent and block damaging data breaches.
Segregation of duties applies also to how you handle encryption and cryptographic key management for protecting your sensitive data stored in cloud storage such as the Amazon Elastic Block Store (EBS) volumes. Amazon EBS provides block level storage volumes for use with EC2 instances. EBS volumes behave like raw, unformatted block devices. You can mount these volumes as devices on your instances. EBS volumes that are attached to an instance are exposed as storage volumes that persist independently from the life of the instance.
Relying on cloud native encryption alone is not considered as a best practice for securing sensitive data in the cloud. In fact, additional levels of protection are necessary to protect your data and your organization from all sorts of threats, including ransomware. I will use the Amazon EBS example to demonstrate that, but the same capabilities and risks apply for Google Cloud and Microsoft Azure.
Understanding encryption in Amazon EBS
When it comes to encrypting Amazon EBS, Amazon provides two types of keys – customer managed key (CMK) and AWS managed key.
The Key Management Service (KMS) keys that you create are customer managed keys. AWS services that use KMS keys to encrypt your service resources often create keys for you. KMS keys that AWS services create in your AWS account are AWS managed keys.
Risks and benefits of available cloud data encryption methods
When encrypting data on Amazon EBS, there are a couple of available options available.
1. Use AWS managed key
AWS managed CMK is the default on Amazon EBS (unless you explicitly override it) and does not require you to create a key or manage any policies related to the key. Any user with EC2 permission in your account can encrypt/decrypt EBS resources encrypted with that key. This option, although is seems straight forward, comes with certain security shortfalls:
- Configuration mistakes or human errors can leave your data with no encryption at all.
- Even if your data is encrypted, there’s no separation of duties and no key material ownership. The only controls are AWS native.
If the volume is mounted on a machine and the system is up and running, sensitive data will be exposed. In addition, if someone takes a snapshot (a backup) of your volume, then the sensitive data will be propagated, and the user may or may not have protected the snapshot with an AWS managed key. Either way you lose visibility to your data.
2. Use customer managed keys
Cloud Service Providers allow organizations to create their own key material (Bring Your Own Key, BYOK) and push this key to the KMS in the cloud. This option gives you more control on tasks like backup and restore, key rotation, reporting and separation of duty. However, sensitive data is still exposed if the EBS volume is mounted, and the system is up and running.
3. Data encryption leveraging BYOK and BYOE
The best strategy to reduce the risk of a data breach is to leverage both BYOK and Bring Your Own Encryption (BYOE). This new key is created on an external FIPS Certified Appliance with full key management reporting, audit trail and key material ownership. The most sensitive data is also protected with separate controls outside of the operating system so if privilege user account was compromised, no access is provided. Any snapshot created and volume created will have encrypted data and no matter where it is mounted to or copied, it will be encrypted.
Choosing the appropriate level of encryption really depends on who you are trying to protect yourself from and what kinds of attacks. Using cloud native encryption only, might not be the best option for customers who have sensitive data in the cloud.
Discover Thales’ offering of neutral cloud security solutions that enable you to control the security of your data and keys in the cloud.