Amazon Elastic Compute Cloud (EC2), a service which provides on demand computing capacity has become ubiquitous in the world of cloud computing. Over 300,000 businesses are currently using EC2 as part of their solution, according to a study from 2021 (source). As these solutions become more complex, performance and scalability become challenging, particularly for storage. EBS is a scalable, simple and high-performance block storage for EC2 that can ease some of this burden. EBS volumes act as primary storage for EC2 instances and can even be retained after instance termination. Managing additional storage however, often highlights concerns for data security. Protecting sensitive production data from unauthorized users is crucial. Encryption is therefore vital when designing any solution that uses EBS.
EBS uses AES-256 encryption keys that are managed and protected by AWS. AES is an encryption algorithm formally approved by the US National Security Agency (NSA).
The AWS UI is constantly evolving and has continued to simplify the process of enabling EBS encryption. AWS have gone to great lengths to empower developers to build secure architectures. Specifically, the Well-Architected Framework provides security guidance and CloudFormation gives us the ability to define secure architecture as code. EBS encryption can protect sensitive data both at rest and in transit, providing users with peace of mind and an easy path to compliance.
This article will seek to cover the basics of EBS. Please find an executive summary below covering some quick pros and cons of the technology, before we continue.
|Protect sensitive data using the strongest available encryption algorithm. AES-256 has 256 bits of encryption. Thats over one hundred quattuorvigintillion (a 78 digit number) possible combinations.||Key management operational overhead|
|Protect data at rest, in transit and snapshots||Cost and latency|
|Meet compliancy standards||Losing the key would result in the data becoming inaccessible|
What EBS encryption does
EBS volumes store data in blocks. Each block has certain specifications, such as read-write capacity, speed, bandwidth, and latency. These blocks are stored and managed as a logical volume, with all operations orchestrated by AWS. To ensure data stored on these volumes is secure, AWS offers EBS encryption. The default version is free and encrypts all data at rest, all data moving between a volume and its EC2 instance and all volume snapshots. It will also encrypt any volumes created from those snapshots.
Configuring EBS encryption
When using the default option, configuration is automated and simply needs to be enabled. KMS also provides the ability to use self-service encryption keys. This premium tier of EBS encryption empowers users to customize and control keys to meet business requirements and compliance standards.
An AWS KMS key is a logical representation of an encryption key. It can carry out the functions one might expect of an encryption key – the encryption and decryption of data. The KMS key also includes data about the key itself, such as ID, description, and creation date.
There are a number of factors to consider when choosing the type of key to use. AWS managed keys can be viewed and audited with no monthly fee. This makes AWS managed keys the perfect choice when simplicity and cost are a factor. However, with AWS managed keys, the key rotation period is fixed at once every three years and their policies cannot be changed. The alternative is customer-managed keys, which are user created and managed. These keys incur a monthly fee, but provide the owner with full control. This includes, but is not limited to, modifying key policies, adding tags, manual rotation and scheduled deletion.
For most use cases, AWS managed keys will suffice. However, your organization’s policies and compliance standards may prevent this. For example, you may be required to prove that you own the original underlying keying material and that this was generated to meet certain randomness requirements. In this case, a CMK (Customer Managed Key) would be the better choice.
Creating a secure EBS volume from scratch is easy. Simply:
- navigate to the EC2 service
- click the Volumes option in the Elastic Block Store section
- click the Create Volume button. The Encryption checkbox is at the end of the Create Volume form
- tick the checkbox and select the KMS encryption key to use
- EBS encryption and decryption actions are handled transparently and do not require any additional actions at runtime
Image shows the option to encrypt a volume
To enable encryption by default:
- Navigate to the EC2 Service
- Select the EC2 Dashboard. Click the EBS Encryption link in the Account Attributes section
- Update the default encryption option in the Modify EBS encryption form
Default encryption is set at the region level and not the account level, so make sure to carry out these steps in each region.
Image shows setting default EBS encryption
Infrastructure as code
There are also other controls that can be used to enforce your encryption policies. AWS CloudFormation enables an entire AWS infrastructure to be defined through code. This means that EBS configurations can be version controlled and subject to the same rigorous code review processes as traditional application code.
Image shows an example of enabling encryption via infrastructure as code
When defining an EC2 volume in code, most properties are optional, but there are two keys that need to be considered when using encryption. The first, the Encrypted property key, accepts a boolean value. Setting this to True encrypts the volume. The second key, KmsKeyId, is the ID of the AWS Key to be used for encryption. If no value is provided, the volume is encrypted using the accounts default key.
You can also encrypt EBS volumes that weren’t originally encrypted by default. Of course, making changes to production systems must be meticulously planned to minimise downtime and prevent data loss. To encrypt pre-existing volumes, conduct the following steps:
- Identify your unencrypted EBS volumes. There are several ways to do this. The first is to use AWS Config. AWS Config provides AWS managed rules to evaluate if AWS infrastructure is in line with the security best practices outlined by the Well-Architected Framework. One of these rules identifies any unencrypted EBS volumes in your account. Alternatively, if you do not have AWS Config enabled, use the AWS command line to quickly list unencrypted volumes:
aws ec2 describe-volumes --filters Name=encrypted,Values=false
- Determine the purpose and role of your EBS volumes. Then, if encryption is required, schedule a maintenance window for it to be replaced with an encrypted copy. You should inform any stakeholders that there will be downtime during this window.
- Create a snapshot of the EBS volume.
- Although you can’t encrypt an unencrypted snapshot, you can create an encrypted copy using the Copy snapshot action. This can be found in the snapshots section of the main EC2 console.
- Create a new EBS volume from the encrypted snapshot.
- Stop the EC2 instance attached to the unencrypted EBS volume.
- Detach the unencrypted volume and attach the new encrypted volume.
- Restart the EC2 instance and inform all relevant parties that maintenance has been completed.
To eliminate any risk of having to repeat this process, ensure that your account has encryption set as default for all regions that you use.
Image shows using AWS Config rules to identify noncompliant resources
EBS Best Practices
The AWS Well-Architected Framework is a useful guide to consult when designing any EBS solution. To ensure that you can fulfill any compliance requirements for data-at-rest encryption, consider the following:
- Never make volume snapshots public. Whitelists can be used to protect sensitive customer data from unauthorized parties
- Frequently audit EBS volumes and remove unused or idle volumes to increase security and lower costs
- Ensure that any volume snapshots containing sensitive data are encrypted
- Ensure all new volumes are encrypted by default
- If more granular control over the encryption process is required, ensure that volumes are encrypted using customer-managed keys (CMK) rather than AWS managed keys
- If you wish to share snapshots across accounts, your target account will need access to the source KMS key used to encrypt the snapshot. Once the snapshot has been copied, it should be re-encrypted using a CMK owned by the target account. This protects the target account in the event that the original CMK is compromised, or permissions to use the original CMK are revoked.
Clear business requirements help determine which storage features are required, so correctly ascertaining these in advance helps set the basic groundwork. When choosing EBS as your storage solution, it's important to consider the type of data being stored, who needs access to it, and at what level. All AWS customers should enable default encryption, but need to decide if AWS managed keys or customer managed keys are a better fit. Regardless of your choice, always enable automated monitoring for unencrypted and unused EBS volumes. Finally, always consult the Well-Architected Framework to esure that your EBS strategy is in line with any pertinent regulatory requirements. If you enjoyed this article and found it useful, why not check out some of our other AWS best practices?