Ensuring the security of data stored on Amazon Elastic Block Store (EBS) volumes is a critical concern for any organization using AWS. EBS volumes provide block-level storage that can be attached to Amazon EC2 instances to enable applications to persist data. As these volumes often contain sensitive information, it is important to understand the risks and utilize the tools available to mitigate threats.
Data protection risks for EBS volumes
When considering how to best protect EBS volume data, it is helpful to first understand the potential risks. Some key threats to address include:
- Unauthorized access – An attacker gaining access to read or modify data on an EBS volume attached to a compromised EC2 instance.
- Intercepted data – Network sniffing or man-in-the-middle attacks intercepting data in transit between an EC2 instance and EBS.
- Data deletion – Accidental or malicious deletion of EBS volume snapshots resulting in permanent data loss.
- Physical risks – Loss of data due to hardware failure, data center disasters, etc.
While AWS provides resilience against many infrastructure risks, the customer is responsible for addressing risks related to logical access, network security, and proper backups.
Protecting data at rest
Data at rest refers to data that is persisted and stored on a disk or other media. For EBS volumes, this includes data written to the volume while attached to an EC2 instance. There are several best practices to follow to keep this data secure:
Use encrypted EBS volumes
Amazon EBS encryption allows volumes to be fully encrypted at the block level to prevent unauthorized access to data. Encryption uses AES-256 and is handled seamlessly on the backend. To enable it, you simply need to tick a box when creating a new EBS volume. Some key points:
- Encryption applies to the entire EBS volume
- All data written to the volume is encrypted before being written to disk
- All reads are transparently decrypted before being sent to the requesting instance
- Minimal effect on latency – overhead is only a few percentage points
With encryption enabled, access to the raw encrypted data or even theft of the volume’s underlying physical storage provides no usable data without the encryption keys.
Leverage role-based access controls
Using AWS Identity and Access Management (IAM), you can control which users and resources are permitted to work with EBS volumes and snapshots. For example:
- Restrict CreateVolume permissions to only approved admins/roles
- Limit DeleteVolume to help prevent accidental data loss
- Control who can create and delete volume snapshots
Combined with encryption, tight access controls prevent unauthorized users from accessing volume data or snapshots.
Take regular snapshots
EBS volume snapshots allow you to take point-in-time backups of volumes for backup and recovery purposes. Snapshots capture a volume’s data incrementally, minimizing storage costs. Key points:
- Snapshots are stored redundantly in S3 and across AZs for resilience
- Snapshots are compressed to minimize storage footprint
- Create and retain snapshots based on data criticality and RPO/RTO
- Snapshots can be easily restored to new volumes when needed
By routinely backing up volumes using snapshots, data can be recovered in the event of corruption, deletion, or infrastructure failure.
Use multi-AZ volumes for high availability
Mission critical EBS volumes can be provisioned as multi-AZ volumes. These synchronize data across multiple underlying physical devices in different AZs. Benefits include:
- Increased volume durability and availability
- Continuous replication to prevent data loss in the event of failure
- Low latency synchronous replication across AZs
- Automatic failover in case of AZ outage
For production databases or other I/O intensive workloads needing availability, multi-AZ volumes are recommended.
Securing data in transit
In addition to data at rest, data security practices must also address data in transit between EC2 instances and EBS volumes. As this data can traverse the public internet, private connections and encryption should be used.
Use encrypted connections
To protect against network sniffing, man-in-the-middle attacks, and similar threats, always use encrypted connections for data in transit:
- For EC2 <-> EBS, use encrypted EBS volumes
- For EC2 <-> EC2, use IPsec VPN or TLS connections
- For Client <-> EC2, use SSL/TLS if possible
- For on-prem <-> AWS connections, use AWS Direct Connect or VPN
Doing so encrypts data throughout its journey from instance to external client and across any network hops in between.
Utilize private network connections
Whenever possible, avoid sending sensitive data over the public internet. Options for private connectivity include:
- Direct Connect – Provides direct private connectivity to AWS resources bypassing the internet.
- VPC endpoints – Allow private connections between VPCs and supported AWS services like S3 without internet routing.
- EC2 in VPC – Placing EC2 instances in a VPC keeps all traffic private and isolated.
Using private IP connections decreases exposure and removes risks associated with public internet transfers.
Isolate public-facing workloads
For workloads that must run on instances with public IP addresses, security groups should be used to limit access. Examples include:
- Allowing only port 443 inbound to web servers
- Restricting MySQL database to accept connections only from application servers
- Limiting admin ports like SSH only to management hosts
Properly configuring security groups minimizes the attack surface and entry points into the application stack.
Additional considerations
Beyond the best practices outlined above, here are some additional considerations when planning how best to secure EBS volumes:
Use third-party encryption
For enhanced security, you can layer on third party encryption tools that encrypt data prior to sending to EBS. This provides an added layer of protection in case the EBS encryption is compromised.
Monitor and audit
Having visibility into access patterns and changes can help detect potential security incidents proactively. Solutions like AWS CloudTrail and CloudWatch Logs can provide this. You can for example:
- Send CloudTrail logs to CloudWatch Logs or SIEM tools for analysis
- Create CloudWatch alarms to notify on unusual API activity
- Log all SSH sessions to EC2 application instances
Static data vs dynamic data
For real-time, frequently changing data written to EBS in production, the encryption and snapshotting capabilities of EBS work well. However, for large amounts of static data, other alternatives like S3 may be more cost effective. Always choose the storage approach that aligns best with your workload and access patterns.
EBS vs instance store
EBS volumes offer durability and resiliency that instance stores do not. However, instance stores can provide very high IOPS performance for I/O intensive workloads. Understand the tradeoffs between using directly attached NVMe instance storage vs EBS volumes.
Conclusion
Protecting the confidentiality and integrity of EBS volume data is critical for security in the public cloud. By leveraging encrypted volumes, managing access controls, taking consistent backups, and enabling secure connectivity, organizations can reduce risks and protect their most sensitive data on AWS.
The key takeaways around securing EBS data at rest and in transit include:
- Enable encryption using AES-256 for all EBS volumes storing sensitive data
- Leverage IAM policies and roles to limit access and control to volumes/snapshots
- Routinely back up volumes using EBS snapshots based on RTO/RPO needs
- For availability, use Multi-AZ volumes for mission critical data
- Encrypt all data in transit using SSL/TLS connections
- Utilize private network connectivity where possible to avoid the public internet
- Isolate and restrict access to public-facing application tiers
- Implement robust monitoring and auditing to detect potential incidents
Following these best practices, organizations can deploy secure, robust storage as part of their cloud architecture on AWS.