S3 Encryption | Notion

Ref: https://learn.cantrill.io/courses/1820301/lectures/41301481

DEMO: https://learn.cantrill.io/courses/1820301/lectures/41301483

S3 Encryption In Transit

🔧 S3 enforces encryption in transit (or “in flight”)
- S3 endpoints accessible only with HTTPS → requires clients to use SSL/TLS

Once data arrives to S3 endpoints, it is encrypted before being stored in disk → at-rest encryption (don't confuse with in-transit/in-flight encryption that happens before!)
‼️ Objects are encrypted, NOT buckets!!
- Different objects might use different encryption!
- An S3 bucket can have a default encryption configuration → its objects will be encrypted like that by default
  - Doc reference: https://docs.aws.amazon.com/AmazonS3/latest/user-guide/default-bucket-encryption.html
Two paradigms for encryption at rest in S3 (and in other AWS storage services):
1. Client-Side Encryption (CSE): client sends ciphertext
  - 👍 Client has full-control over crypto keys, process, and tooling
    - S3 only used for storage, no crypto ops performed there
      - AWS never sees plaintext
      - AWS never uses crypto keys
    - Can be compliant with strict high-sec requirements
  - 👎 Client must perform all crypto ops (can be computationally expensive)
2. **Server-Side Encryption (SSE): client sends plaintext**
  - S3 performs crypto ops
    - 👎 Client has less control over encryption
    - 👍 Offloads crypto ops from client to S3
‼️ AWS has made SSE mandatory!!
- Storing data in plaintext in AWS was possible before, but is no longer allowed!
- If you use CSE, you now use both CSE & SSE together

3 types
1. SSE-S3 (S3-managed keys) → Default
2. SSE-KMS (KMS-managed keys)
3. SSE-C (customer-provided keys)
All types of SSE are tradeoffs based on how you manage the crypto keys and what you entrust S3 with (better for different scenarios)