Over the years, Amazon has repeatedly recommended that customers who care about the security of their data should consider encrypting information stored on disks, whether ephemeral storage (/mnt) or EBS volumes. This, even though they take pains to ensure that disk blocks are wiped between uses by different customers, and they implement policies which restrict access to disks even by their own employees.
There are a few levels where encryption can take place:
File level. This includes tools like GnuPG, freely available on Ubuntu in the
gnupgpackage. If you use this approach, make sure that you don’t store the unencrypted information on the disk before encrypting it.File system level. This includes useful packages like
encfswhich transparently encrypt files before saving to disk, presenting the unencrypted contents in a virtual file system. This can even be used on top of ans3fsfile system letting you store encrypted data on S3 with ease.Block device level. You can place any file system you’d like on top of the encrypted block interface and neither your application nor your file system realize that the hardware disk never sees unencrypted data.
The rest of this article presents a simple way to set up a level of encryption at the block device level using cryptsetup/LUKS. It has been tested on the 32-bit Ubuntu 9.10 Jaunty server AMI listed on http://alestic.com and should work on other Ubuntu AMIs and even other distros with minor changes.
This walkthrough uses the /mnt ephemeral storage, but you can replace /mnt and /dev/sda2 with appropriate mount point and device for 64-bit instance types or EBS volumes.
Setup
Install tools and kernel modules:
sudo apt-get update
sudo apt-get install -y cryptsetup xfsprogs
for i in sha256 dm_crypt xfs; do
sudo modprobe $i
echo $i | sudo tee -a /etc/modules
done
Before you continue, make sure there is nothing valuable on /mnt because we’re going to replace it!
sudo umount /mnt
sudo chmod 000 /mnt
Encrypt the disk and create your favorite file system on it:
sudo luksformat -t xfs /dev/sda2
sudo cryptsetup luksOpen /dev/sda2 crypt-sda2
Remember your passphrase! It is not recoverable!
Update /etc/fstab and replace the /mnt line (or create a new line for an EBS volume):
fstabentry='/dev/mapper/crypt-sda2 /mnt xfs noauto 0 0'
sudo perl -pi -e "s%^.* /mnt .*%$fstabentry%" /etc/fstab
Mount the file system on the encrypted block device:
sudo mount /mnt
You’re now to free to place files on /mnt knowing that the content will be encrypted before it is written to the hardware disk.
After reboot, /mnt will appear empty until you re-mount the encrypted partition, entering your passphrase:
sudo cryptsetup luksOpen /dev/sda2 crypt-sda2
sudo mount /mnt
Notes
See “man cryptsetup” for info on adding keys and getting information from the LUKS disk header.
It is possible to auto-mount the encrypted disk on reboot if you are willing to put your passphrase in the root partition (almost ruins the point of encryption). See the documentation on crypttab and consider adding a line like:
crypt-sda2 /dev/sda2 /PASSPHRASEFILE luks
Study the cryptsetup documentation carefully so that you understand what is going on. Keeping your data private is important, but it’s also important that you know how to get it back in the case of problems.
This article does not attempt to cover all of the possible security considerations you might need to take into account for data leakage on disks. For example, sensitive information might be stored in /tmp, /etc, or log files on the root disk. If you have swap enabled, anything in memory could be saved in the clear to disk whenever the operating system feels like it.
How do you solve your data security challenges on EC2?
This article was based on a post made on the EC2 Ubuntu group.
What performance cost does this kind of block level encryption has?
orensol: I doubt the performance implications can be given as a single value for all applications. Fortunately, it's easy to try things cheaply on EC2.
Security through encryption is not going to come free in terms of performance or management. For example, the above approach requires you to manually enter passphrases when disks are mounted.
Each customer is going to have to make the call as to whether the added safety is worth the costs. For a lot of applications, Amazon's existing storage security measures will continue to be acceptable.
Forgive me, if I'm asking a stupid question, but I just would like to double check my understanding.
When you are using block device encryption; as I understand it the encrypt/decrypt operations happens within the server and not at the EBS level. Or phrased in another way; the data traffic between the EC2 instance and the EBS instance is always encrypted.
Is this a correct interpretation?
jens: Your understanding is correct. The encryption is performed before the data is sent to EBS and decryption is performed on the host after receiving the encrypted block from EBS.