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.
Scriptorium 