Securing S3 with Policies, ACLs, and IAM

1. The Layers of S3 Access Control

Controlling access to S3 resources involves multiple overlapping mechanisms. At first, this can seem complex, but each tool has a specific purpose. Grasping the distinction between them is the first step toward mastering S3 security.

Let's begin with a high-level overview. The following cheat sheet provides an excellent comparison of the three main policy and list-based mechanisms.

As the cheat sheet shows, we have:

• IAM Policies: Attached to identities (users, groups, roles). They answer the question, "What can this user/role do across AWS?"
• S3 Bucket Policies: Attached to a resource (the S3 bucket itself). They answer the question, "Who can access this specific bucket?"
• Access Control Lists (ACLs): A legacy mechanism for managing access at the bucket or object level. As we'll see, their use is now discouraged in favor of policies.

Before we dive into the details of these policies, we must discuss the most critical security feature of all: S3 Block Public Access.

2. The First Line of Defense: S3 Block Public Access

Think of Block Public Access as a master safety switch for your buckets and your entire account. By default, AWS now enables this feature for all new buckets and accounts, preventing accidental public exposure of data. It acts as an umbrella protection that can override any policies that might otherwise allow public access. When troubleshooting S3 permissions, especially when public access isn't working as expected, this is the very first place you should check.

The official AWS Security Blog provides an excellent explanation of this feature.

3. Identity vs. Resource: IAM and Bucket Policies

With the primary safeguard of Block Public Access in place, let's turn to the fine-grained tools: policies. Both IAM and Bucket Policies are written in JSON and use a similar structure, but their focus is different. This distinction is crucial.

• IAM Policies are identity-based. You attach them to a user, group, or role. They are ideal for managing permissions for your internal users and services, especially when a single identity needs access to multiple AWS resources (e.g., an EC2 instance and an S3 bucket).
• Bucket Policies are resource-based. You attach them directly to an S3 bucket. They are perfect for managing cross-account access, making a bucket selectively public (for a static website, for instance), or enforcing bucket-wide rules like IP address restrictions.

The blog "S3 Policies Explained" offers a clear and practical breakdown of these concepts.

To hear these concepts explained, the following video offers a good verbal summary.

4. Writing a Bucket Policy in Practice

Let's move from theory to practice. A common DevOps task is to enforce a security rule on a bucket, such as requiring all uploaded files to be encrypted. This is a perfect use case for a bucket policy.

The official AWS channel has a great tutorial showing how to create a bucket policy from scratch in the AWS console, following the principle of least privilege.

After watching the video, consider this practical example of a bucket policy that denies any upload that doesn't specify server-side encryption. This kind of preventative security control is a hallmark of a well-managed cloud environment.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "AES256"
        }
      }
    }
  ]
}

This policy is powerful. It uses a Deny effect with a Condition. It says: deny any PutObject action on any object in this bucket if the s3:x-amz-server-side-encryption header is not present and equal to AES256. This effectively forces encryption on all incoming data.

5. The Legacy Player: Access Control Lists (ACLs)

You will encounter ACLs in your work, so it's important to know what they are. However, for most modern use cases, you should avoid them. ACLs predate IAM and are a less flexible, less auditable way to control access.

With the introduction of the "Bucket owner enforced" setting for S3 Object Ownership (which is now the default), ACLs are disabled, and all access control is managed through IAM and bucket policies. This simplifies security management significantly.

The AWS blog post we looked at earlier has a succinct explanation.

6. How AWS Evaluates Policies: The Final Decision

Now for the most important part: how do all these rules work together? When an S3 request is made, AWS evaluates all applicable settings and policies—Block Public Access, IAM policies, bucket policies, and ACLs (if enabled)—to make an authorization decision.

The logic follows a clear, conservative sequence designed for security:

1. Starts with a Deny: By default, access is denied.
2. Check Block Public Access: If the request is blocked by a Block Public Access setting, it's denied immediately.
3. Check for an Explicit Deny: AWS then evaluates all applicable policies. If any policy statement has an Effect of Deny that matches the request, the request is denied. An explicit Deny always wins.
4. Check for an Explicit Allow: If there are no explicit denies, AWS looks for an Allow. At least one policy statement (from an IAM policy, bucket policy, etc.) must explicitly Allow the request.
5. Final Deny: If no Allow is found, the initial default Deny remains, and the request is denied.

This flowchart visualizes the process perfectly.

For a final review of this crucial logic, this short video segment provides a great animated summary.

Conclusion

In this lesson, we've navigated the landscape of S3 security, moving from the high-level safety of Block Public Access to the granular control of IAM and bucket policies. You now have the conceptual framework to secure data in one of AWS's most fundamental services.

Key Takeaways:

• Block Public Access is your first and strongest defense. Always start here and ensure it's enabled unless you have a specific, verified need for public access.
• Policies are the primary tool for fine-grained control. Use IAM policies to define what your users and roles can do, and use S3 bucket policies to define who can access a specific bucket and under what conditions.
• ACLs are legacy. For new buckets, stick to the "Bucket owner enforced" setting and manage all permissions with policies.
• The evaluation logic is simple but critical: an explicit Deny always overrides any Allows.

In our next lesson, we will explore another core pillar of cloud operations: monitoring. Now that we've provisioned, managed, and secured our resources, we'll learn how to use Amazon CloudWatch to create dashboards, set alarms, and analyze logs to gain visibility into the health and performance of our AWS environment.