S3

• Amazon S3 Encryption – SSE-S3

  
  

  • Encryption using keys handled, managed, and owned by AWS.

  • Object is encrypted server-side.

  • Encryption type is AES-256.

  • Must set header "x-amz-server-side-encryption": "AES256".

  • Enabled by default for new buckets & new objects.

  
• Amazon S3 – Force Encryption in Transit

  
  

  aws:SecureTransport

  
• Amazon S3 – Object Encryption.

  
  

  1) SSE-S3 (Server-Side Encryption with Amazon S3-Managed Keys) – Enabled by Default.

  • Encrypts S3 objects using keys handled, managed, and owned by AWS.

  
  

  3) SSE-C (Server-Side Encryption with Customer-Provided Keys).

  • When you want to manage your own encryption keys.

  
  

  4) Client-Side Encryption.

  
  

  5) Glacier: all data is AES-256 encrypted, key under AWS control.

  
• Amazon S3 – Object Encryption.

  
  

  2) SSE-KMS (Server-Side Encryption with KMS Keys stored in AWS KMS).

  
  

  • Leverage KMS to manage encryption keys.

  • Key usage appears in CloudTrail.

  • Objects made public can never be read (Exam**).

  • On s3:PutObject, make the permission kms:GenerateDataKey is allowed.

  
  

  ** The objects, even if you make them public, can never be read by anonymous users because they do not have access to the underlying KMS keys. Whereas an objects encrypted with SSE-S3 made public can be accessed by anonymous users.
• "S3 Bucket Key" for SSE-KMS Encryption

  
  

  • New setting to decrease...

  • • Number of API calls made to KMS from S3 by 99%.

  • • Costs of overall KMS encryption with Amazon S3 by 99%.

  
  

  • This leverages data keys.

  • • A “S3 bucket key” is generated (Customer master key in KMS is periodocally rotated).

  • • That key is used to encrypt KMS objects with new data keys.

  • • The “S3 bucket key” will create a lot of Data keys using envelope encryption.

  
  

  • You will see less KMS CloudTrail events in CloudTrail.

  
  

  An optimisation of using SSE-KMS to decrease the number of KMS API calls.

  
• S3 Batch – Object Encryption (how to encrypt many objects at a time in the S3 bucket).

  
  

  Must use the:

  
  

  • "S3 Batch" service – perform bulk operations on existing S3 objects with a single request (e.g., encrypt un-encrypted objects)

  • "S3 Inventory" – to get the list of all objects and its associated metadata (select Encryption Status from optional fields)

  • "S3 Select" or Athena – to filter and list only un-encrypted objects

  
  

  • Note: In the example, the S3 Batch Operations job must have access to the S3 bucket and the KMS Key.

  
• S3 Glacier Vault Lock

  • Adopt a WORM (Write Once Read Many) model.

  • Create a Vault Lock Policy.

  • Lock the policy for future edits (can no longer be changed or deleted).

  • Helpful for compliance and data retention.

  
• S3 Object Lock (versioning must be enabled)

  
  

  Retention mode - Compliance:

  
  

  • Object versions can't be overwritten or deleted by any user, including the root user

  • Objects retention modes can't be changed, and retention periods can't be shortened

  
  

  Retention mode - Governance:

  
  

  • Most users can't overwrite or delete an object version or alter its lock settings

  • Some users have special permissions to change the retention or delete the object

  
  

  Retention Period: protect the object for a fixed period, it can be extended
• Legal Hold:

  • Protect the object indefinitely, independent from retention period

  • Can be freely placed and removed using the s3:PutObjectLegalHold IAM permission
• Amazon S3 Glacier - Vault Policies & Vault Lock

  
  

  • Each Vault has:

  • • ONE vault access policy .

  • • ONE vault lock policy.

  
  

  • Vault Policies are written in JSON.

  
  

  • Vault Access Policy is like a bucket policy (restrict user / account permissions).

  
  

  • Vault Lock Policy is a policy you lock, for regulatory and compliance requirements.

  • • The policy is immutable, it can never be changed (that’s why it’s call LOCK).

  • • Example 1: forbid deleting an archive if less than 1 year old.

  • • Example 2: implement WORM policy (write once read many).

  
• Amazon S3 Encryption – SSE-C

  
  

  • Server-Side Encryption using keys fully managed by the customer outside of AWS.

  • Amazon S3 does NOT store the encryption key you provide.

  • HTTPS must be used.

  • Encryption key must provided in HTTP headers, for every HTTP request made.

  
• Prevent uploads of unencrypted S3 objects: What does the bucket Policy condition check against?

  The header in your PUT request

  
• Amazon S3 – Default Encryption vs. Bucket Policies

  • SSE-S3 encryption is automatically applied to new objects stored in S3 bucket.
  • Optionally, you can “force encryption” using a bucket policy and refuse any API call to PUT an S3 object without encryption headers (SSE-KMS or SSE-C).

  NOTE: Bucket Policies are evaluated before “Default Encryption”

  The right hand Bucket Policy example says: hey, if you are uploading this but there is no customer side algorithm, so no SSE-C, then deny this object.

  
• Amazon S3 – Encryption in transit (SSL/TLS)

  • Encryption in flight is also called SSL/TLS

  Amazon S3 exposes two endpoints:

  1. HTTP Endpoint – non encrypted
  2. HTTPS Endpoint – encryption in flight

  • HTTPS is recommended
  • HTTPS is mandatory for SSE-C
• Amazon S3 Encryption – Client-Side Encryption

  • Use client libraries such as Amazon S3 Client-Side Encryption Library.
  • Clients must encrypt data themselves before sending to Amazon S3.
  • Clients must decrypt data themselves when retrieving from Amazon S3.
  • Customer fully manages the keys and encryption cycle.

  
• Amazon S3 Encryption – SSE-KMS

  • Encryption using keys handled and managed by AWS KMS.
  • KMS advantages: user control + audit key usage using CloudTrail.
  • Object is encrypted server side.
  • Must set header "x-amz-server-side-encryption": "aws:kms".

  "x-amz-server-side-encryption": "AES256"

  "x-amz-server-side-encryption": "aws:kms"