Securing S3 objects at rest and in transit
In the previous section, you learned about bucket default encryption, which is completely different from object-level encryption. Buckets are not encrypted, whereas objects are. A question may arise here: what is the default bucket encryption? You will learn these concepts in this section. Data during transmission can be protected by using Secure Socket Layer (SSL) or Transport Layer Security (TLS) for the transfer of HTTPS requests. The next step is to protect the data, where the authorized person can encode and decode the data.
It is possible to have different encryption settings on different objects in the same bucket. S3 supports Client-Side Encryption (CSE) and Server-Side Encryption (SSE) for objects at rest:
- CSE: A client uploads the object to S3 via the S3 endpoint. In CSE, the data is encrypted by the client before uploading to S3. Although the transit between the user and the S3 endpoint happens in an encrypted channel, the data in the channel is already encrypted by the client and can’t be seen. In transit, encryption takes place by default through HTTPS. So, AWS S3 stores the encrypted object and cannot read the data in any format at any point in time. In CSE, the client takes care of encrypting the object’s content. So, control stays with the client in terms of key management and the encryption-decryption process. This leads to a huge amount of CPU usage. S3 is only used for storage.
- SSE: A client uploads the object to S3 via the S3 endpoint. Even though the data in transit is through an encrypted channel that uses HTTPS, the objects themselves are not encrypted inside the channel. Once the data hits S3, then it is encrypted by the S3 service. In SSE, you trust S3 to perform encryption-decryption, object storage, and key management. There are three types of SSE techniques available for S3 objects:
- SSE with Customer-Provided Keys (SSE-C): With SSE-C, the user is responsible for the key that is used for encryption and decryption. S3 manages the encryption and decryption process. In CSE, the client handles the encryption-decryption process, but in SSE-C, S3 handles the cryptographic operations. This potentially decreases the CPU requirements for these processes. The only overhead here is to manage the keys. Ideally, when a user is doing a PUT operation, the user has to provide a key and an object to S3. S3 encrypts the object using the key provided and attaches the hash (a cipher text) to the object. As soon as the object is stored, S3 discards the encryption key. This generated hash is one-way and cannot be used to generate a new key. When the user provides a GET operation request along with the decryption key, the hash identifies whether the specific key was used for encryption. Then, S3 decrypts and discards the key.
- SSE with Amazon S3-Managed Keys (SSE-S3): With SSE-S3, AWS handles both the management of the key and the process of encryption and decryption. When the user uploads an object using a PUT operation, the user just provides the unencrypted object. S3 creates a master key to be used for the encryption process. No one can change anything on this master key as this is created, rotated internally, and managed by S3 from end to end. This is a unique key for the object. It uses the AES-256 algorithm by default.
- SSE with Customer Master Keys stored in AWS Key Management Service (SSE-KMS): AWS Key Management Service (KMS) manages the Customer Master Key (CMK). AWS S3 collaborates with AWS KMS and generates an AWS-managed CMK. This is the default master key used for SSE-KMS. Every time an object is uploaded, S3 uses a dedicated key to encrypt that object, and that key is a Data Encryption Key (DEK). The DEK is generated by KMS using the CMK. S3 is provided with both a plain-text version and an encrypted version of the DEK. The plain-text version of DEK is used to encrypt the object and then discarded. The encrypted version of DEK is stored along with the encrypted object. When you are using SSE-KMS, it is not necessary to use the default CMK that is created by S3. You can create and use a customer-managed CMK, which means you can control the permission on it as well as the rotation of the key material. So, if you have a regulatory board in your organization that is concerned with the rotation of the key or the separation of roles between encryption users and decryption users, then SSE-KMS is the solution. Logging and auditing are also possible on SSE-KMS to track the API calls made against keys.
- Default bucket encryption: If you set AES-256 while creating a bucket, or you enable it after creating a bucket, then SSE-S3 will be used (when you don’t set something at the object level while performing a PUT operation).
In the next section, you will learn about some of the data stores used with EC2 instances.
