Amazon S3 – Security

Now let’s talk about Amazon S3 Security. S3 offers multiple ways to manage access and secure data through user-based security, resource-based policies, ACLs, and encryption.

User-Based Security

  • IAM users can be assigned IAM policies.
  • These policies define which API calls are allowed or denied for that specific user.
  • This is the classic way to give access to users within your AWS account.

Resource-Based Security

This type of security is applied directly at the resource level (buckets or objects), rather than the user.

Includes:

  1. S3 Bucket Policies

    • Are defined as JSON-based documents.
    • can be applied directly on a bucket.
    • These are bucket-wide rules managed via the S3 console.
    • They support cross-account access (letting users from another AWS account access your bucket).

    • They are used to:

      • Grant public access
      • Force encryption during uploads
      • Allow access to specific AWS accounts

  2. Object Access Control Lists (ACLs)

    • These are used for finer-grained control at the object level.
    • These ACLs can be disabled if not needed.

  3. Bucket Access Control Lists (ACLs)

    • These are the ones which control access at the bucket level.
    • They are rarely used today.
    • These ACLs can also be disabled if not needed.
Note: When Does Access Happen?

An IAM principal (a user, role, or service) can access an S3 object only if:

  • The IAM permissions allow it OR
  • The resource policy (e.g., bucket policy) allows it AND
  • There is no explicit Deny in the action

    Then the IAM Principle can access the S3 object on the specified API call.

Encryption based Security

Finally another way to do security on Amazon S3 is to encrypt the objects using Encryption keys.

S3 Bucket Policy Structure

S3 Bucket Policies are written in JSON and include the following:

workshop scene
  • Resource: Specifies the bucket or object(s) the rule applies to (e.g., arn:aws:s3:::example-bucket/* applies to all objects in the bucket as shown in the image as above)
  • Effect: Can be either "Allow" or "Deny"
  • What do we allow or deny for?? –> We allow or deny for Actions
  • Action: Lists the permitted or denied API actions (e.g., s3:GetObject) (Remember that action is to be applied on which API calls)
  • Principal: Who the policy is for (e.g., "*" means public access) (Remember Principal as Users or Public Access (*)

Example: To allow public access to all objects:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::example-bucket/*"
}

This allows anyone to retrieve any object from example-bucket.

Examples for Better Understanding

1. Public Access Example

  • Let’s say when you want your bucket to be accessed by website visitors or the general internet:

    • Attach a bucket policy that grants public access.
    • Once applied, all objects in the bucket are publicly readable. (See the image below)
workshop scene

2. IAM User Access Example

  • If an IAM user within your AWS account needs to access the S3 bucket:

    • Attach an IAM policy to the user that grants access.
    • This policy enables the user to make the necessary API calls to S3.
workshop scene

3. EC2 Instance Access Example

If you have EC2 instance and if you want to give access from the EC2 instance into the S3 buckets then:

  • EC2 instances should not use IAM user credentials.
  • Instead, assign an IAM Role to the EC2 instance.
  • This role must have a policy allowing access to the target S3 bucket.
  • The EC2 instance will assume this role and get temporary credentials.
workshop scene

4. More Advanced: Cross-Account Access Example

  • If an IAM user is in a different AWS account and needs access to your bucket:

    • You must write a bucket policy that explicitly allows that user’s access.
    • The policy must include that user’s AWS account ID and permissions.
workshop scene

Other security setting that you need to know about is that there are:

Block Public Access Settings

Amazon introduced Block Public Access settings as a safety net to prevent accidental public exposure.

  • Even if a bucket policy allows public access, these settings can override it.
  • If these settings are enabled, the bucket cannot be made public — even if you try.

  • Best practice:

    • Keep these settings ON for buckets that should never be public.
    • You can also enforce them at the account level.

🔐 Encryption

  • You can enable encryption on objects stored in Amazon S3.
  • Encryption keys help protect sensitive data.
  • Bucket policies can also enforce that uploads must be encrypted.

Next we will look into hands-on section for what we have learnt…

S3 Hands On S3 Security Hands On