S3 Security: Bucket Policies, ACLs, Encryption

Amazon S3 (Simple Storage Service) is a highly durable and scalable object storage service. Security in S3 is multi-layered, encompassing identity-based policies (IAM), resource-based policies (bucket policies and ACLs), encryption (at rest and in transit), and access logging. The SAA-C03 exam heavily tests your ability to design secure storage solutions that meet specific compliance and access control requirements.

A bucket policy is a JSON-formatted resource-based policy attached directly to an S3 bucket. It defines who (principal) can perform what actions (effect, action) on which resources (resource) under what conditions (condition). Bucket policies are evaluated when an IAM principal makes a request to the bucket. The policy can grant or deny access to the entire bucket or specific objects (using a wildcard arn:aws:s3:::bucket-name/*).

Key elements of a bucket policy: - Version: Always "2012-10-17" (the current policy language version). - Statement: An array of individual permission statements. - Effect: "Allow" or "Deny". - Principal: The AWS account/user/role to which the policy applies. For cross-account access, you specify the AWS account ID. - Action: S3 API actions like s3:GetObject, s3:PutObject, s3:ListBucket. - Resource: The ARN of the bucket or objects, e.g., arn:aws:s3:::my-bucket for the bucket itself, arn:aws:s3:::my-bucket/* for all objects. - Condition: Optional conditions using AWS global condition keys or S3-specific keys like s3:x-amz-acl, s3:VersionId, aws:SourceIp, aws:MultiFactorAuthPresent.

Example policy that grants public read access to objects in a bucket:

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

Access Control Lists (ACLs) are a legacy access control mechanism that predates IAM and bucket policies. They can be applied at the bucket or object level. Each ACL consists of a set of grants specifying the grantee (e.g., an AWS account or a predefined group like AllUsers or AuthenticatedUsers) and the permission (e.g., READ, WRITE, FULL_CONTROL). ACLs are less flexible than bucket policies and are generally not recommended for new deployments. However, the exam tests your understanding of when ACLs are still relevant (e.g., when you need to grant access to specific objects to different AWS accounts without using IAM roles).

By default, ACLs are disabled on new S3 buckets unless you specifically enable them. The recommended approach is to use bucket policies and IAM for access control, and to disable ACLs (the default).

S3 offers several encryption options for data at rest: - SSE-S3 (Server-Side Encryption with S3-Managed Keys): Amazon S3 manages the encryption keys. Each object is encrypted with a unique key, and the key itself is encrypted with a master key that rotates regularly. This is the simplest option, requiring no additional configuration from the user. To use SSE-S3, you set the x-amz-server-side-encryption header to AES256. - SSE-KMS (Server-Side Encryption with AWS KMS-Managed Keys): You use AWS Key Management Service (KMS) to manage the encryption keys. This provides additional control, such as separate permissions for key usage (via KMS key policies) and the ability to audit key usage via CloudTrail. You can use a customer managed key or the default AWS managed key (aws/s3). To use SSE-KMS, set the header to aws:kms and optionally specify a key ID via x-amz-server-side-encryption-aws-kms-key-id. - SSE-C (Server-Side Encryption with Customer-Provided Keys): You provide your own encryption key, and S3 manages the encryption/decryption process. The key is never stored by AWS; you must provide it with every request. This option is useful for organizations that need to control their own keys but want S3 to handle the encryption. The key is sent in the x-amz-server-side-encryption-customer-key header. - Client-Side Encryption: You encrypt data before uploading it to S3 using your own encryption library or tools (e.g., Amazon S3 Encryption Client). AWS never sees the plaintext data or encryption keys.

S3 supports both HTTP and HTTPS. To enforce encryption in transit, you can use a bucket policy that denies requests where aws:SecureTransport is false. Example:

{
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::my-bucket/*",
    "Condition": {
        "Bool": {
            "aws:SecureTransport": "false"
        }
    }
}

When a request is made to S3, the following evaluation logic applies: 1. The request must be authenticated (unless it's an anonymous request). 2. The user's identity-based policy (IAM) is evaluated. 3. The resource-based policy (bucket policy) is evaluated. 4. If ACLs are enabled, they are also evaluated. 5. The default is to deny all access. An explicit allow in any of the policies (IAM, bucket policy, ACL) will grant access, unless there is an explicit deny in any policy (deny overrides allow). 6. For cross-account access, both the requesting account's IAM policy and the resource account's bucket policy must allow the action.

To prevent accidental public exposure, S3 provides four block public access settings at the bucket and account level: - BlockPublicAcls: Blocks public ACLs. - IgnorePublicAcls: Ignores public ACLs (treats them as if they don't exist). - BlockPublicPolicy: Blocks public bucket policies (policies that grant access to Principal: "*" or Principal: { "AWS": "*" }). - RestrictPublicBuckets: Restricts access to only AWS services and authorized users within the account, even if a bucket policy allows public access.

These settings can be applied at the account level via the S3 console or the PutPublicAccessBlock API, and they override any more permissive policies. The exam often tests that enabling these settings can prevent data leaks even if a bucket policy is misconfigured.

Pre-signed URLs allow temporary access to a specific S3 object. They are generated by signing a URL with the credentials of a user who has permission to access the object. The URL includes an expiration time (default 3600 seconds, max 604800 seconds for AWS Signature V4). Pre-signed URLs are commonly used to allow users to upload or download objects without giving them permanent credentials. The exam tests that pre-signed URLs are generated using the AWS SDK or CLI, and that the expiration time can be set.

The exam may ask you to choose the appropriate logging mechanism for compliance or security analysis.

A financial services company must store sensitive customer data in S3 with strict compliance requirements (e.g., PCI-DSS). They use SSE-KMS with a customer managed key to encrypt all objects at rest. To enforce encryption in transit, they attach a bucket policy that denies requests without aws:SecureTransport=true. They also enable S3 Block Public Access at the account level to prevent any accidental public exposure. Access is granted only to specific IAM roles used by applications, and cross-account access is not allowed. CloudTrail is enabled to log all API calls, and S3 server access logs are sent to a separate bucket for analysis. The company uses AWS Config to monitor bucket policies for any changes that might weaken security. A common misconfiguration is forgetting to set the x-amz-server-side-encryption header when uploading objects, which results in objects stored without encryption. To enforce encryption, they add a bucket policy that denies s3:PutObject if the header is missing or set to an incorrect value.

A media company uses S3 to store raw video footage. They need to allow external editors to download files temporarily. They generate pre-signed URLs using an IAM role that has read access to the bucket. The URLs are set to expire after 24 hours. The company also uses bucket policies to restrict access to only the specific IAM role that generates the pre-signed URLs, preventing any other access. They do not enable ACLs. A common issue is that the pre-signed URL expiration time is set too long, increasing the risk of unauthorized access if the URL is leaked. The exam tests that pre-signed URLs inherit the permissions of the IAM user who generated them, so that user must have the necessary S3 permissions.

A startup hosts a static website on S3. They need to allow public read access to all objects in the bucket. They attach a bucket policy that grants s3:GetObject to Principal: "*". They also enable static website hosting and configure the bucket for public access. However, they must ensure that the block public access settings are not enabled (or are configured to allow public bucket policies). A frequent mistake is enabling block public access at the account level, which overrides the bucket policy and causes the website to return 403 errors. The exam tests that for public access, you must explicitly allow it in the bucket policy and ensure block public access settings are not blocking it.