Data Security in the AWS Cloud
S3
S3 [3], one of the oldest services in AWS, is divided into buckets at the top level. A bucket contains folders and objects/files. S3 buckets are also the easiest way to launch a static website in AWS. You drop the files that make up the website into a bucket and then make them available via HTTP(S) with a few clicks. In the past, this occasionally went wrong, because confidential data was accidentally left in the clear on the Internet.
Figure 1 shows the settings for creating a bucket. If encryption is enabled, the user can choose whether the AWS system will use automatically generated data or the data stored in the Key Management Service (KMS) [4]. Encryption applies to the objects in the bucket. By default, public access is also blocked (Figure 2).
The admin can also control what kind of encryption applies at the folder level (Figure 3). The last stage is the individual object (a file, for example). The user can set encryption here (if using) along with the encryption method.
Alternatively, you can encrypt the objects locally in S3 before uploading them, so that there is no AWS key capable of decrypting them.
KMS
AWS by default uses keys that are automatically generated on the fly to quickly encrypt data. However, the confidentiality and integrity objectives pertaining to the Amazon admins are still not in place.
If you want more control over the keys, you need to use KMS [4]. In the KMS console, AWS offers a list of implicitly generated keys for encrypting databases. For customer-managed keys that are generated by the admin in the console and then have a policy applied to them, a policy is attached to a key – anyone who uses the key is allowed to do what the policy states.
When you create your own key in KMS using KMS to generate the key, the dialog prompts you to define who can manage the key and who can use it for encryption and decryption. Based on this, the user guide calculates a policy, which it attaches to the key.
Instead of having AWS generate a key, an admin can store an externally generated key. In this case, the console requires the admin to select an algorithm to pack the key before uploading it and a token to unpack the key again (see [5] for an example).
Finally, Amazon offers a CloudHSM cluster [6]. If you choose this option, you are binding several hardware security modules (HSMs) that contain a tamper-proof key; this achieves the highest level of control possible in the cloud.
All requests for encryption are answered by the HSMs; their hardware makes sure that nobody reads the keys. Designed as a cluster, CloudHSM is highly available (the A in CIA) – which is important for people who secure large sections of their infrastructure with HSM.
Due to interchangeable components and API compatibility, taking the big step towards CloudHSM in an architecture does not have to happen at the very beginning of development. In this configuration, the remaining trust topic is that the KMS clients are under the control of AWS (i.e., they store decrypted data in RAM).
VMs with Encrypted Hard Disks
Amazon's EC2 VM service uses S3 for its virtual hard disks, making encryption of the hard disks possible. Linux administrators have been aware of this kind of protection for a long time at the level of encrypted partitions or volumes. This either means that the admin has to enter a password when booting the machine or that the password has to be stored in the bootloader. In the latter case, the data remains unprotected in the event of theft.
The AWS Cloud uses KMS behind the scenes. When an admin creates a new VM, the memory management menu offers the option of encrypting the hard disk (Figure 4). The user keys generated in the selected AWS region appear in the selection list.
When the VM starts, the hypervisor retrieves the data for decryption. Admins who failed to secure access permissions to the key when it was created are allowed to attach the hard disk to a VM, but are unable to read the data, similar to any other encrypted volume.
Since AWS unfortunately does not provide a console for a Linux VM, the ability to work with Linux on-board tools does not exist for the root volume. If the confidential data resides on a separate partition from the VM, the admin boots the VM in the normal way, manually mounts the volume, and enters the password; this means that the key does not reside in AWS.
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Canonical Releases Ubuntu 24.04
After a brief pause because of the XZ vulnerability, Ubuntu 24.04 is now available for install.
-
Linux Servers Targeted by Akira Ransomware
A group of bad actors who have already extorted $42 million have their sights set on the Linux platform.
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.