[AWS] S3 Security and Encryption

You can control S3 access can be done in 3 ways:

  • Bucket Policies apply across the bucket.
  • Object Permissions apply to individual files.
  • IAM (Identity) policies apply to users and groups

S3 Security

Bucket authorization is controlled on many levels as well.

  • By default, the public access is disabled (private), and only a creator can access it.
  • Policies will be combined: (Explicit Deny -> Explicit Allow -> Implicit Deny)
  • Identity policies are attached to IAM users, roles, and groups in your account.
  • Bucket policies are resource policies that apply to a bucket or objects in a bucket.
    • Bucket policies are used to grant permissions to anonymous users or IAM identities in another account (cross-account access).
    • Bucket policies are specific to S3 and cannot be used to access other services (e.g., EC2).
    • Bucket Policies are used to make entire buckets (e.g., S3 static website) public.
  • ACLs are applied to a bucket and an object – Not recommended anymore.
  • Bucket ACL (Access Control List) is a legacy method, used to allow public access (Everyone group)
    • Bucket ACL is used to grant permission to an S3 Log Delivery group or everyone.
  • Note that Object ACL can be applied to an object directly.
    • Object ACL is used when an object is not owned by a bucket owner or grant public access.
  • Block public access is a setting applied on top of any settings. It overrules any other public grant.
  • S3 buckets can be configured to create “S3 access logs”.
  • S3 access logs contain all requests made to the bucket.

S3 Cross-Account Access

There are 3 ways to share S3 bucket access across accounts:

  • Using Bucket policies and IAM for the entire bucket – Programmatic access only.
  • Using Bucket ACLs and IAM for individual objects – Programmatic access only.
  • Using Cross-account IAM Roles – Programmatic access and Console access.

Data Encryption

  • Data is encrypted in transit (SSL/TLS).
  • Encryption at rest can be configured on a per-object basis.
  • Client-side Encryption:
    • The client is responsible for both the encryption/decryption and its keys.
    • You can use a customer master key (CMK) stored in AWS Key Management Service (AWS KMS) or use a master key that you store within your application.
  • Server-side Encryption with Customer-Managed Keys (SSE-C)
    • S3 handles the process, but the customer needs to provide the key with each PUT and GET request.
  • Server-side Encryption with S3-Managed Keys (SSE-S3)
    • Objects are encrypted with AES-256 by S3. Keys are stored with objects in an encrypted form. You just need permission on the object to decrypt and access it.
  • Server-side Encryption with AWS KMS-Managed Keys (SSE-KMS)
    • Objects are encrypted using individual keys generated by KMS. You need both S3 and KMS permissions to access objects – role separation.
  • Objects (not Buckets) are encrypted in S3. Each put operation needs to specify an encryption type. The “Default encryption” setting in the bucket is used when a new object is uploaded. The change of the setting does not affect existing objects.
  • Enforcing Encryption on S3 Buckets
    • PUT upload: the “x-amz-server-side-encryption” header is included in the request: “AES256” or “ams:kms
    • Or Use the bucket policy to enforce the use of server-side encryption.

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s