AMAZON EC2’S INSTANCE STORE ENCRYPTION TO PROTECT DATA AT REST
Encrypting data at rest is essential in ensuring the protection of sensitive data stored on disks. Similarly, it is essential for regulatory compliance. It should have a valid key for use before readability of data. HIPAA and PCI DSS are compliance regulations that require encryption for data at rest, throughout its data lifecycle.
Amazon web services supply options for data-at-rest and key management to sustain the encryption process. Similarly, Amazon enables encryption of EBS volumes and configures its S3 buckets for SSE or server side encryption using AES-256 Encryption. Amazon also supports the TDE or Transparent Data Encryption.
Further, instance storage temporarily stores Amazon EC2 instances in its block level storage. The storage exists on physical disks attached to the host computer. Most noteworthy, instance storage allows for temporary storage of frequently changing data. These include caches, buffers, and scratch data. By default, however, these data contains non-encrypted files.
This section shows the encryption method applied on the Linux EC2 instances. Additionally, it does transparent encryption that effectively protects confidential information. Applications that use the data cannot detect the disk-level encryption.
File system and Disk Encryption
In summary, there are two encryption methods for instance stores. One of them is the File-system-level encryption where only files and the directories are encrypted. It is portable across OS and operates above the file system.
Next, we have the Disk encryption. Disk encryption encrypts a block of the disk or the entire disk itself using one or several encryption keys. This approach, on the other hand, operates below the file system and hides file and directory information such as name and size. It is also OS-agnostic.
Linux dm-crypt Infrastructure
The Linux kernel-level encryption method features the dm-crypt that gives users permission to mount the encrypted file system. Mounting file systems is done by attaching to a mount point or directory that makes it available to the OS. Next, the file systems are made available to applications and do not require added interactions. Such files are encrypted when stored on the disk.
Moving on, Device Mapper found in the Linux 2.6 and Linux 3.x kernel is an infrastructure that creates a way to develop block devices into layers. The crypt target of this infrastructure makes a transparent encryption using kernel crypto API. Arguably, Dm-crypt combined with the disk backup file system is the solution of choice, mapped to the Logical Volume Manager (LVM).
The diagram, for this purpose, shows the Amazon dm-crypt relationship with application and file system. It sits between the file system and the physical disk. Furthermore, data written from the OS to the disk is encrypted.
Most of all, the application cannot detect the disk-level encryption because it is not made aware. When applications are using a directory or mount point to retrieve files, storing files into disk makes them encrypted. This, for that reason, renders the files useless if the drive is stolen or lost.
Meanwhile, try to create a new file system that is dm-crypt encrypted and name it “secretfs.” The file uses LVM and LUKS or Linux Unified Key Setup to encrypt it. The EC2 instance disk storage contains the file system.
A diagram traces the newly encrypted file as located in the EC2 internal disk storage. Applications that need to save confidential data will use “secretfs” as the mount point temporarily (‘/mnt/secretfs’)to save the sratch file.
Especially relevant, this solution requires three sets of actions for it to work. Firstly, perform the EC2 Launch Config on boot because the file is created at boot time. Full control over every step should be granted and revoked by an administrator. This, specifically, is to aid in file system creation or to access keys.
Next, log every decryption and encryption request using the AWS CloudTrail. This is rather critical when creating keys. It is also critical when seeking to unlock an encrypted file system.
Lastly, integrate other AWS services to the solution. There are four services included. This section describes each of them.
First, the AWS Key Management Service or KMS enables the creation of encryption keys and controlling keys in encrypting data. This service uses envelope encryption which has a master key on top of a data key. Most noteworthy, the master key can decrypt and encrypt up to 4 KB of data.
Second, the AWS CloudTrail records and logs request back and forth the KMS. This data is used for auditing in the future. Similarly, it helps to monitor API calls for the account.
Amazon S3 is a storage feature of the AWS. It saves the password for the encrypted file system.
Next, AWS IAM or Identity and Access Management enables control on the secure accessibility to AWS services. It allows access to S3 bucket (reading encrypted password) and KMS (decrypt password).
To implement the solution:
1. Initially, create an S3 bucket. Doing this stores the file that contains the encrypted password. This password is used to encrypt the chosen file system.
Next, sign into the s3 Console, and click Create Bucket. Afterward, type your chosen Bucket name in the box and press Create. As a result, the right pane will show the new bucket you created.
2. Next, configure the IAM policy to grant permission to the S3 bucket. Configuration is done in the bucket name you created that stores the encrypted password. To start, you need to create an IAM policy.
Subsequently, choose IAM console and select Roles, and select Create New Role. Type the Role Name and hit Next Step. Then, click next Step for Established Trust. In the Attach Policy, choose the IAM policy you set up.
Certainly, launching EC2 instances requires the use of the newly created IAM role. This grants the permission for accessing the encrypted password in the S3 bucket. The newly setup role should display on the Roles page.
3. At this point, Use the KMS to encrypt a password. Encrypting a text with KMS must have AWS CLI. Use AWSCLI that is installed by default in the EC2 Linux Instances. This is compatible with Windows, Mac and Linux OS.
aws –region us-east-one kms encrypt –key-id ‘alias/EncFSForEC2InternalStorageKey’ –plaintext “ThisIs-a-SecretPassword” –query CiphertextBlob –output text | base64 –decode > LuksInternalStorageKey.
aws s3 cp LuksInternalStorageKey s3:///LuksInternalStorageKey.
Next, type this command in the AWS CLI and replace –region with your region name. Ensure you have the right permissions to make keys and save in the S3 bucket. The file generated by the command is then copied to the S3 bucket. The alias key that makes it unique is EncFSForEC2InternalStorageKey.
4. Now, choose Encryption keys from the navigating pane of IAM Console. Select the key alias generated earlier add a new role that can access key. Later, scroll down to the Key Policy and choose Add.
Select the new role you created earlier. Next, click on Attach. This role is granted permission to use the key.
5. Finally, Launch a new instance in the EC2 console. On the Configure Instance Details, choose the IAM Role earlier.
You will see an Advanced Details section on the bottom pane. Paste this code in the User Data and choose As Text. This will execute at boot time of the EC2. #!/bin/bash
## Initial setup to execute on boot.
# Create an empty file. This file is used to host the file system.
# In this example we create a 2 GB file called secretfs (Secret File System).
dd of=secretfs bs=1G count=0 seek=2.
# Lock down normal access to the file.
chmod 600 secretfs.
# Associate a loopback device with the file.
losetup /dev/loop0 secretfs.
#Copy encrypted password file from S3. The password is used to configure LUKE later on.
aws s3 cp s3://an-internalstoragekeybucket/LuksInternalStorageKey.
# Decrypt the password from the file with KMS, save the secret password in.
LuksClearTextKeyLuksClearTextKey=$(aws –region us-east-1 kms decrypt –ciphertext-blob. fileb://LuksInternalStorageKey –output text –query Plaintext | base64 –decode).
# Encrypt storage in the device. cryptsetup will use the Linux.
# device mapper to create, in this case, /dev/mapper/secretfs.
# Initialize the volume and set an initial key.
echo “$LuksClearTextKey” | cryptsetup -y luksFormat /dev/loop0.
# Open the partition, and create a mapping to /dev/mapper/secretfs.
echo “$LuksClearTextKey” | cryptsetup luksOpen /dev/loop0 secretfs.
# Clear the LuksClearTextKey variable because we don’t need it anymore.
# Check its status (optional).
cryptsetup status secretfs.
# Zero out the new encrypted device.
dd if=/dev/zero of=/dev/mapper/secretfs.
# Create a file system and verify its status.
mke2fs -j -O dir_index /dev/mapper/secretfs
# List file system configuration (optional).
tune2fs -l /dev/mapper/secretfs.
# Mount the new file system to /mnt/secretfs.
mount /dev/mapper/secretfs /mnt/secretfs.
Remember to enable CloudTrail. This will help you monitor and audit accessibility to the KMS key. Launch the EC2 Instance. This copies the password file to S3 and then decrypted by the KMS. It then configures the encrypted file system mounted in mnt/secretfs.
Every file saved on the mount point will be encrypted when stored on the disk. Applications handling sensitive data will need to access the mount point to be able to use the encrypted file system. The rest of the file system other than of the mount is not encrypted.
Elsewhere, here is another article about Using APT tactics and techniques in your pentests.