Having your data encrypted at rest is crucial for a secure application, especially when you are reporting to a governing body for IT security standards in the Healthcare or Financial markets. Our VPC networking ensures all private network traffic is fully encrypted per customer network, which ensures your data is encrypted over the wire between VMs. Having encrypted volumes will add an extra layer of security to ensure even a somehow compromised volume is rendered unreadable.
We’re going to review encrypting your Cloud-A SSD volume on both a Redhat based, and Debian based Linux distribution using the dm-crypt package — the gold standard for modern Linux disk encryption. dm-crypt is a kernel level transparent disk encryption system, only worrying about block level encryption without ever interpreting data itself. This gives dm-crypt the availability to encrypt any block device, from root disks and attached volumes, to even swap space.
Create your SSD Volume
Head to your Cloud-A dashboard, and create a new Volume under “Servers -> Volumes”. We’ll create a 120GB volume named “Encrypted Disk 1?.
Now that we have the drive in place, we’ll attach it to a server to configure the disk encryption.
Linux Setup: Ubuntu 14.04 & Fedora 20
Our Ubuntu and Fedora images ship with the necessary tools to do encryption out of the box, we’re going to use the cryptsetup package to create the encrypted block device, create a password, and make it available to mount via the mapper.
sudo cryptsetup -y luksFormat /dev/vdb
Cryptsetup will prompt you to overwrite the block device, and be irreparable. Type “YES” in all caps to confirm. You’ll next be asked to provide a password for decrypting your data, make sure you choose a strong password and store it somewhere safe.
Now we can use cryptsetup luksOpen to open the encrypted disk, and have the device mapper make it available. When you run this command, you’ll need to provide the password you entered in the last step.
sudo cryptsetup luksOpen /dev/vdb encrypted_vol
Next, we’re able to interact with the disk per usual at the /dev/mapper/encrypted_vol location created in the last step. Since the encryption is done transparently, you don’t need to do anything special from here on out to keep your data encrypted and safe. We’ll create a simple journaled Ext4 filesystem, and mount it to /data for the application server to use.
sudo mkfs.ext4 -j /dev/mapper/encrypted_vol sudo mkdir /data sudo mount /dev/mapper/encrypted_vol /data
Your disk is ready. You can check that it’s mounted and how much space is available using df -h.
Filesystem Size Used Avail Use% Mounted on /dev/vda1 60G 22G 38G 36% / /dev/mapper/encrypted_vol 118G 18M 112G 1% /data
You can now configure your database data directory, or application user data to point to your new encrypted /data directory to store your sensitive data.
Next Steps
When you are done with the volume, you can close it by unmounting and using luksClose to remove the mapping and deauthenticate the mount point so it cannot be accessed until re-authenticating.
sudo umount /data sudo luksClose encrypted_vol
And to re-authenticate in the future on this, or any other VM you simply need to use luksOpen with your decryption password and mount to your desired location.
sudo cryptsetup luksOpen /dev/vdb encrypted_vol sudo mount /dev/mapper/encrypted_vol /data
This should help you get on your way to a more secure installation of your application with securely storing your application data on a high performance SSD volume. At any time, you can use the Volume Live Snapshot function in the dashboard to capture a snapshot of this volume to maintain encrypted backups that you can restore to a new volume at any time.
Encrypted disks are not the only security measure you should be taking into account when deploying your infrastructure, but it is a crucial step in the right direction for every security conscious deployment scenario.
