How to Configure Encryption for EBS Volumes on Existing EC2 Instances
Using Snapshots and EBS Volumes to Secure EC2 Instances
To enhance the security of your EC2 instances, you must ensure that encryption is enabled for EBS volumes. In this demo, we will show you how to configure encryption for EBS volumes on existing EC2 instances.
First, you’ll analyze your snapshots. An encrypted snapshot indicates an encrypted EBS volume. If a snapshot is unencrypted (found in the snapshot’s Description tab), you need to create a new volume off of that snapshot. When you create a new volume, you have the option to apply encryption to the volume with a key of your choice. Once this new, encrypted EBS volume is created, you will attach it to your EC2 instance. Now, the encryption from the EBS volume will be applied to the EC2 instances.
For a visual guide to enabling encryption for EBS volumes, watch the full demo.
Transcription
Amazon documentation points out that you can only configure the encryption setting at the time that you create the volume. If you need to retroactively apply encryption to an already existing EBS volume, the process to do that is to first create a snapshot and then create a volume off of the snapshot and encrypt that volume going forward. So, we’ll demonstrate that here.
Let’s go over to our “Snapshots.” We already created our snapshot offline. We can confirm that this is an unencrypted volume because the snapshot, itself, is also unencrypted. When you do create an encrypted EBS volume and then create a snapshot of that, the snapshot itself, will also be encrypted. There’s just no other way around that.
So, with our unencrypted volume that we created, we will come up here, select “Actions,” “Create Volume,” and now you can see that we do have the option, at the time of creating this volume, to apply encryption. We will select our key that we’ll use to protect the volume key that’s actually used to perform the encryption. We’ll add a tag to this, Encryption Enabled, just to call it something different. Sure enough, we created our volume. If we click on the settings, we will see that it is, indeed, encrypted at this point. Then, we would just reattach this volume to our EC2 instance and bring the instance back online, again. From that point forward, EBS volume encryption will be applied to the EC2 instance.
Related Videos
Basic Tools for AWS Security
Cloud Attacks on the Rise
Do All Keys Have Resources Attached?
Enable Role Based Access Control (RBAC) for Azure Key Vault
Encrypt Kubernetes Secrets Using Keys
Encrypting Traffic In and Out of AWS
Encryption Decisions for Your Technology Stack
Encryption Opportunities
Encryption for EBS Volumes
Encryption for S3 Buckets
Enforce Separation of Duties When Assigning KMS Related Roles
Enforcing Strong TLS Ciphers
Ensure KMS Cryptokeys Are Not Publicly Accessible
Ensure Use of CMKs for Unattached Disks
Ensure that Virtual Hard Disks Are Encrypted
Ensure that an Expiration Date Is Set for All Keys in Non-RBAC Key Vaults
Ensure that an Expiration Date Is Set for All Secrets in Non-RBAC Key Vaults
Ensure the Key Vault Is Recoverable
Events that Drive Key Rotation
FAQs for Amazon S3 Security
How to Configure Encryption for EBS Volumes on New EC2 Instances
How to Configure Encryption for RDS
How to Configure Encryption for S3 Buckets
Install Endpoint Protection for All Virtual Machines
Introduction to Amazon Inspector
Key Rotation and Management
Load Balancers Must Require TLS 1.2
Only Install Company-Approved Extensions on Your Virtual Machines
PCI Requirement 3.1 - Keep Cardholder Data Storage to a Minimum
PCI Requirement 3.2 - Do Not Store Sensitive Authentication Data After Authorization
PCI Requirement 3.3 Mask PAN when Displayed
PCI Requirement 3.4 Render PAN Unreadable Anywhere it Is Stored
PCI Requirement 3.4.1 Logical Access Management
PCI Requirement 3.5 Document & Implement Procedures to Protect Keys
PCI Requirement 3.5.1 Maintain a Documented Description of The Cryptographic Architecture
PCI Requirement 3.5.2 Restrict Access to Cryptographic Keys
PCI Requirement 3.5.3 Store Secret and Private Keys Used to Encrypt/Decrypt Cardholder Data
PCI Requirement 3.5.4 Store Cryptographic Keys in The Fewest Possible Locations
PCI Requirement 3.6 Document & Implement all Key-Management Processes & Procedures
PCI Requirement 3.6.1 Generation of Strong Cryptographic Keys
PCI Requirement 3.6.2 Secure Cryptographic Key Distribution
PCI Requirement 3.6.3 Secure Cryptographic Key Storage
PCI Requirement 3.6.4 Cryptographic Key Changes at Cryptoperiod Completion
PCI Requirement 3.6.5 Replacing Weakened Keys
PCI Requirement 3.6.6 Using Split Knowledge & Dual Control
PCI Requirement 3.6.7 Prevention of Unauthorized Substitution of Cryptographic Keys
PCI Requirement 3.6.8 Key-Custodian Responsibilities
PCI Requirement 3.7 Security Policies & Operational Procedures
PCI Requirement 4.1 – Use Strong Cryptography & Security Protocols to Safeguard Sensitive CHD
PCI Requirement 4.1.1 – Ensure Wireless Network Transmitting CHD Use Strong Encryption
PCI Requirement 4.3 – Ensure Security Policies and Procedures are Known to all Affected Parties
PCI Requirements 3.2.1, 3.2.2, & 3.2.3 Do Not Store Tracks, Codes, or PINs After Authorization
Preventing Public Accessibility on DB Instances
Re-Keying for Decryption
Requirement 4 - Encrypt Transmission of Cardholder Data Across Open, Public Networks
Requirement 4.2 – Never Send Unprotected PAN by End-User Technologies
Rotate KMS Encryption Keys Regularly
Route 53 Support for DNSSEC
Set Expiration Date for All Keys in RBAC Key Vaults
Set Expiration Date for All Secrets In RBAC Key Vaults
Take Advantage of Automatic Key Rotation within Azure Key Vault
The AWS Shared Responsibility Model
Use CMEK To Secure GKE Storage
Using AWS KMS
Using Prowler to Evaluate AWS Security
Using S3 Versioning
Using TLS 1.2 to Encrypt Data in Transit
