Securing Amazon S3: public access, bucket policies, encryption and logging
In short: Amazon S3 data leaks almost always come from configuration, not from S3 itself. Keep Block Public Access on, disable ACLs, grant access through tight policies, encrypt with KMS where needed, enforce TLS, turn on versioning and logging, and use tools that scan for sensitive data.
Why buckets leak
Amazon Simple Storage Service (S3) is object storage (see cloud storage types). It is private by default: new buckets have Block Public Access turned on and access control lists (ACLs) disabled. Leaks happen when someone deliberately loosens those settings, writes a policy with a wildcard principal, or shares a pre-signed link too widely. The fix is a layered, consistent baseline.
Access control
- Block Public Access (BPA): turn it on at the account level so no bucket can be made public by accident. If you need a public website, serve it through Amazon CloudFront with origin access control instead.
- Object Ownership: keep "bucket owner enforced", which disables ACLs so only policies decide access.
- Bucket policies: resource-based JSON rules. Use them for cross-account access and to enforce conditions.
- IAM policies: give roles access to named buckets and prefixes only.
- Access points: separate named entry points with their own policies, useful for shared data sets.
This bucket policy statement denies any request that does not use TLS:
{
"Sid": "DenyInsecureTransport",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": ["arn:aws:s3:::<your-bucket>", "arn:aws:s3:::<your-bucket>/*"],
"Condition": {"Bool": {"aws:SecureTransport": "false"}}
}Encryption and recovery
| Option | Who manages the key | When to use |
|---|---|---|
| SSE-S3 | AWS, fully managed (default for new objects) | General data |
| SSE-KMS | A KMS key you control, with key policy and audit trail | Sensitive or regulated data |
| DSSE-KMS | Two layers of KMS-based encryption | Rules that demand dual-layer encryption |
| Client-side | You, before upload | When AWS must never see plaintext |
With SSE-KMS, enable S3 Bucket Keys to cut KMS request costs. For recovery, turn on versioning so deletes and overwrites can be undone, and add lifecycle rules to expire old versions. For backups and records, Object Lock in compliance mode makes objects immutable for a set period, which protects against ransomware and insider deletion. MFA Delete adds a further barrier for versioned buckets.
Logging and checking
- Turn on CloudTrail data events for sensitive buckets, or S3 server access logging, and send logs to a separate, locked-down log bucket.
- Use IAM Access Analyzer for S3 to list buckets shared publicly or with other accounts.
- Run Amazon Macie to discover personal data stored in buckets.
- Use AWS Config rules or Security Hub controls to alert on public or unencrypted buckets.
- Review pre-signed URL use and keep expiry times short.
Tip: practise these steps in the private S3 bucket lab on your own account.
Practice
Where should Block Public Access be enabled for the strongest protection?
A role can read a bucket but gets AccessDenied on SSE-KMS objects. What is likely missing?
Which feature protects backup objects from being deleted, even by an administrator, for 90 days?
Key takeaways
- S3 is private by default; leaks come from loosened settings.
- Keep Block Public Access on at account level and ACLs disabled.
- Use tight IAM and bucket policies and deny non-TLS requests.
- Encrypt with SSE-KMS for sensitive data; use versioning and Object Lock.
- Log data access and scan with Access Analyzer and Macie.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.