Graduate Program KB

Section 9 - S3 Security

Object Encryption

  • Server-Side Encryption (SSE)
    • Use S3-Managed Keys (SSE-S3) which are enabled by default
    • Can also use KMS (SSE-KMS) or Customer-Provided Keys (SSE-C) when you want to manage your own encryption keys
  • Client-Side Encryption

SSE-S3

  • Encryption using keys handled, managed and owned by AWS
  • Server-side encryption
  • AES-256
  • Must set header "x-amz-server-side-encryption": "AES256"
  • Enabled by default for new buckets and new objects

SSE-KMS

  • Encryption using keys handled and managed by AWS KMS
  • Enables more user control and auditing key usage via CloudTrail
  • Server-side encryption
  • Must set header "x-amz-server-side-encryption": "aws:kms"
  • Limitations:
    • KMS limits
    • Calls GenerateDataKey KMS API on uploads
    • Calls Decrypt KMS API on downloads
    • Counts towards the KMS quota per second (5500, 10000, 30000 req/s based on region)
    • Can request a quota increase using Service Quotas console

SSE-C

  • Server-side encryption using fully managed customer keys
  • S3 Does not store encryption key you provide
  • HTTPS must be used
  • Encryption key must be provided in HTTP headers for every request

Client-Side Encryption

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

Encryption in Transit (SSL/TLS)

  • Encryption in-flight is also called SSL/TLS
  • S3 exposes two endpoints: HTTP and HTTPS (recommended and mandatory for SSE-C)
  • Most clients use HTTPS endpoint by default

CORS

  • Cross-Origin Resource Sharing
    • Origin: Scheme (protocol) + Host (domain) + Port
  • A browser-based mechanism to allow requests to other origins while visiting the main origin
  • Requests won't be fulfilled unless other origin allows for the requests using CORS Headers
  • CORS headers must be enabled if a client makes a cross-origin request on our S3 bucket
  • Can allow for specific origins or for all using the wildcard (*)

MFA Delete

  • Multi-Factor Authentication forces users to generate a code on a device before doing important S3 operations
  • Required to permanently delete an object version or suspend versioning on a bucket
    • Not required to enable versioning or list deleted versions
  • For MFA Delete, versioning must be enabled on the bucket
  • Only the bucket owner (root account) can enable/disable MFA Delete

Access Logs

  • Audit logs are stored in another S3 bucket, these record any requests made to S3
  • The target logging bucket must be in the same AWS region
  • Don't set the logging bucket to be the monitored bucket
    • Creates a logging loop which causes your bucket to grow exponentially

Pre-Signed URLs

  • Pre-signed URLS can be generated using Console, CLI or SDK
  • URL expiration
    • Console: 1 min up to 720 mins
    • CLI: Configure expiration with --expires-in parameters in seconds (default - 3600 secs, max. - 604800 secs)
  • Users given a pre-signed URL inherit permissions of the user that generated the URL for GET/PUT

Glacier Vault Lock

  • Use Write Once Read Many (WORM) model
  • Create Vault Lock Policy
  • Lock policy for future edits
  • Useful for compliance and data retention

Object Lock

  • Block an object version deletion for a specified amount of time
  • Must have versioning enabled
  • Adopt WORM model
  • Retention modes:
    • Compliance
      • Versions can't' be overwritten or deleted by an user, including the root user
      • Object retention modes can't be changed and retention periods can't be shortened
    • Governance
      • Most users can't overwrite / delete an object version or alter its lock settings
      • Some users have special permissions to change the retention or delete the object
  • Objects have a retention period to protect it, this period can be extended
  • Legal hold protects the object indefinitely, independent from retention period
    • Can be freely placed and removed using the s3:PutObjectLegalHold IAM permission

Access Points

  • Simplify security management for S3 buckets
  • Each access point has its own DNS name and an access point policy
  • For VPC origin:
    • Create a VPC endpoint to access the access point (gateway / interface endpoint)
    • VPC endpoint policy must allow access to the target bucket and access point

Object Lambda

  • Use Lambda functions to change the object before it's retrieved by the caller application
  • Only one S3 bucket is needed with an S3 Access Point and S3 Object Lambda Access Point
  • Use cases:
    • Redacting personal information for analytics or non-production environments
    • Converting across data formats, such as XML to JSON
    • Resizing and watermarking images on the fly