S3 Encryption Overview
S3 Encryption is a way to secure S3 buckets, this can be encryption while the data is at rest, as well as when the data is in transit.
At Rest
- By default, buckets are not encrypted and need to be secured
- Encryption is set at the object level, not the bucket level
- Can protect data theft while the data is sitting in storage
- Two types of At-Rest encryption — client-side and server-side
- Client-side — objects encrypted ***before*** data transfer begins; by default buckets have no encryption so it needs to be set
- Server-side — once objects are put in a bucket, they are secured by S3-managed encryption; three types of key management are available:
- Server-Side Encryption with Customer Provided Keys (SSE-C) — Key management and encryption is administered by customer
- Server-Side Encryption with AWS S3 Managed Keys (SSE-S3) — Key management and encryption is administered by AWS S3
- Server-Side Encryption with Customer ‘Master Keys’ Stored in AWS Key Management Service (SSE-KMS) — Key management is administered by AWS S3 and KMS; encryption is administered by AWS S3
In Transit
- Protecting data when it is moving from one location to another
- The connection between S3 and the client requesting the data has a protective tunnel to prevent unauthorized parties from access
Bucket Policies
‘Bucket Policies’ have different types available to use; these control who and what can access the S3 bucket.
It is recommended to use Bucket Policies instead of Bucket ACLs, as Bucket Policies are more flexible.
S3 buckets can only have ONE bucket policy, but this policy can have multiple statements. Bucket policies can be a resource based or identity based policies:
- Resource Policies — Attached to the resource trying to access (as opposed to an IAM role); gives the resource itself the permissions needed; used to allow both internal and external account bucket access; a principle will be specified to allow/deny access in the created policy
- Principal — the accessing identity specified in the policy principals can be any of the following: AWS account and root user, IAM users, Federated users (using web identity or SAML federation), IAM roles, Assumed-role sessions, AWS services, Anonymous users (not recommended)
- SID — optional identifier number for policy; used in SNS or SQS services
- Effect — Allow or Deny
- Action — the action being denied/allowed; in this case, fetching an S3 resource
- Resource — the object the policy is affecting; in this case, the name of S3 bucket
- Identity Policies — Attached to an existing identity inside the customer’s AWS account; the identity is given permission; used to allow internal account bucket access
Bucket ACLs
Bucket ACLs are a way to control access to the S3 Bucket, but is depreciated in favor of Bucket Policies.
Access Control List (ACL) for the bucket itself can be set; this is where public access can be granted (and acknowledgement of permission made).
Blocking public access
Bucket settings for blocking public access can also be set; by default, all public access is blocked. If setting the bucket to public access, an acknowledgement must be made, understanding the implications.
Changing on whether the bucket has public access does not affect anything laid out in resource policies; it only affects access regarding ***public*** requesters.