S3 Security: Bucket Policies and ACLs

Securing your S3 data is paramount. AWS provides multiple layers of access control for S3, and understanding how they interact is critical for preventing data breaches. In this lesson, we cover IAM policies, bucket policies, Access Control Lists (ACLs), Block Public Access, and access points.

---

The Four Layers of S3 Access Control

Layer	Scope	Written In	Attached To
IAM policies	User/role-level	JSON	IAM users, groups, roles
Bucket policies	Bucket-level	JSON	The bucket itself
ACLs	Object or bucket level	XML	Bucket or individual objects
Block Public Access	Account or bucket level	Toggle settings	Account or bucket

When a request arrives, S3 evaluates all applicable policies. The request is allowed only if at least one policy grants access and no policy explicitly denies it.

---

IAM Policies for S3

IAM policies control what AWS principals (users, groups, roles) can do with S3. These are identity-based policies.

Example: Allow a user to read from a specific bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::my-app-bucket",
        "arn:aws:s3:::my-app-bucket/*"
      ]
    }
  ]
}

Note: s3:ListBucket applies to the bucket ARN, while s3:GetObject applies to the objects (the /* suffix).

---

Bucket Policies

Bucket policies are resource-based policies attached directly to the bucket. They are the most common way to grant or restrict access to S3 data.

Structure of a Bucket Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPublicRead",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-website-bucket/*"
    }
  ]
}

Field	Description
Sid	Optional statement identifier
Effect	Allow or Deny
Principal	Who the policy applies to (* = everyone)
Action	Which S3 API actions are covered
Resource	The bucket and/or objects the statement applies to
Condition	Optional conditions (IP address, MFA, TLS version, etc.)

Common Bucket Policy Patterns

Restrict access to a specific IP range:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowFromOfficeOnly",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

Require HTTPS (deny unencrypted connections):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "Bool": { "aws:SecureTransport": "false" }
      }
    }
  ]
}

Grant cross-account access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CrossAccountRead",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ]
    }
  ]
}

Applying a Bucket Policy

aws s3api put-bucket-policy --bucket my-bucket --policy file://policy.json

---

Access Control Lists (ACLs)

ACLs are the original access control mechanism for S3, predating bucket policies. They are less flexible and are now generally not recommended for most use cases.

ACL Grantees