Protecting S3 Data with Bucket Policy, SSE, Macie, and Object Lock
_Category: Data Protection_
S3 is simultaneously the most widely used storage service in AWS and the one most likely to be the source of a security incident when misconfigured. On the SCS-C03 exam, S3 data protection is tested across multiple dimensions: access control evaluation order, immutability mechanisms, sensitive data discovery, and audit log design. This post walks through five layers — access control, encryption, immutability, classification, and auditing — paired with the practical traps that trip people up.
---
The Five-Layer Model for S3 Data Protection (Access, Encryption, Immutability, Classification, Auditing)
S3 data protection is not a single feature — it is a Defense in Depth model. Think of it like protecting a vault: the building has an access control system (access control layer), the vault has a combination lock (encryption), the contents inside are sealed (immutability), items are labeled by sensitivity (data classification), and every entry and exit is logged (audit trail). Each layer compensates for the weaknesses of the others.
Layer 1 (Access Control): Bucket Policy, ACL, IAM Policy, Block Public Access, S3 Access Points, VPC Endpoint Policy. Layer 2 (Encryption): SSE-S3, SSE-KMS, SSE-C, DSSE-KMS, plus TLS enforcement via . Layer 3 (Immutability): Versioning, MFA Delete, Object Lock (Governance Mode / Compliance Mode / Legal Hold). Layer 4 (Classification): Amazon Macie automatically detects PII, financial data, and credentials. Layer 5 (Auditing): Server Access Logging, CloudTrail Data Events, S3 Inventory.
---
Bucket Policy, ACL, and IAM Policy: Who Wins and Why (Evaluation Order)
When an S3 request arrives, AWS evaluates policies in a specific sequence. Not knowing this order makes it extremely difficult to diagnose access denials.
Evaluation order: Explicit Deny → Block Public Access → Bucket Policy Allow → IAM Policy Allow → ACL Allow. A Deny anywhere in the chain immediately blocks the request. Block Public Access overrides even a public Allow in a Bucket Policy.
| Policy Type | Applies To | Key Characteristics | Exam Trap | |-------------|-----------|--------------------|-----------| | IAM Policy | IAM principals (users/roles) | Identity-based, no VPC conditions | Same role can be attached in other VPCs — VPC isolation is incomplete | | Bucket Policy | Bucket and object resources | Supports conditions like aws:sourceVpc, aws:PrincipalOrgID | Cross-account requires Allow in both Bucket Policy and IAM Policy | | ACL | Objects and buckets | Legacy, account-level granularity | Completely disabled when Bucket Owner Enforced is enabled |
Cross-account access requires both sides: the bucket-owning account's Bucket Policy must Allow the principal, and the accessing account's IAM Policy must Allow the action. Either one alone results in a denial. Using to enable Bucket Owner Enforced disables ACLs entirely, leaving only Bucket Policy and IAM Policy in control — like a building owner revoking every individual access badge and replacing them with a central keycard system.
For VPC-based restriction, use in the Bucket Policy. This only works if an S3 VPC Endpoint (Gateway or Interface) is already configured. The S3 Gateway Endpoint is free; the Interface Endpoint is billed by the hour.
---
Block Public Access and the Most Common S3 Exposure Incidents
Block Public Access is the safety net designed to prevent the single most common S3 exposure cause: accidentally permitting public access. It can be configured at both the account level and the bucket level, with account-level settings taking precedence.
BlockPublicAcls blocks new public ACLs from being added. IgnorePublicAcls ignores existing public ACLs. BlockPublicPolicy prevents public Bucket Policies from being applied. RestrictPublicBuckets neutralizes existing public policies, allowing only S3 service principals and the bucket-owning account's IAM users to access the bucket.
Three mistakes come up frequently. First: disabling account-level Block Public Access to make one bucket public, inadvertently exposing other buckets to misconfiguration risk. Second: not realizing that CloudFront with OAC (Origin Access Control) can serve S3 content without ever disabling Block Public Access — engineers disable it unnecessarily. Third: combined with an condition is sometimes flagged as a public policy by RestrictPublicBuckets — the fix is to narrow Principal to specific accounts or roles.
For organization-wide enforcement, add a SCP that Denies , or use the AWS Config rule with auto-remediation.
---
The Four Server-Side Encryption Options (SSE-S3, SSE-KMS, SSE-C, DSSE-KMS) — Comparison
Since 2023, SSE-S3 is applied by default to all S3 buckets. However, compliance requirements and key management policies often demand a different option.
| Option | Key Management | KMS Integration | Cost | Primary Use Case | |--------|---------------|-----------------|------|-----------------| | SSE-S3 | Fully managed by AWS (AES-256) | None | Free | Default encryption, minimize cost | | SSE-KMS | KMS CMK, customer-controlled | Yes (audit trail) | Per KMS API call | Key auditing, rotation, cross-account control | | SSE-C | Customer provides key per request | None | No AWS cost (customer manages key) | Never hand key material to AWS | | DSSE-KMS | KMS CMK, dual-layer encryption | Yes | ~2x SSE-KMS | FIPS 140-3 dual-encryption requirements |
The biggest trap with SSE-KMS is an unexpected cost spike. Every PUT and GET triggers a KMS API call, which means large, high-throughput buckets can generate fees that far exceed expectations. The fix is S3 Bucket Keys. By using a bucket-level data encryption key (DEK), Bucket Keys can reduce KMS API calls by up to 99%. If you are using SSE-KMS, enabling Bucket Keys is not optional — it should be the default.
SSE-C requires the customer to supply the key with every request; AWS never stores it. Three hard constraints apply: HTTPS is mandatory, there is no recovery path if the key is lost, and Cross-Region Replication (CRR) is not supported. DSSE-KMS encrypts objects with two independent KMS keys and is the right choice for FIPS 140-3 regulatory environments.
Enforcing encryption in Bucket Policy: for SSE-KMS, add a Deny for PUTs missing the condition. For TLS enforcement, Deny requests where is .
!4 S3 server-side encryption options
Object Lock and Versioning: Protection Against Modification and Deletion
S3 Object Lock prevents objects from being deleted or overwritten for a defined retention period. Object Lock can only be enabled at bucket creation time — it cannot be activated afterward or disabled once set. Versioning must be enabled for Object Lock to function.
Governance Mode allows administrators with the permission to remove the lock or shorten the retention period. It is the flexible, correctable option — useful during testing or when regulatory requirements allow for administrator override.
Compliance Mode is best described as a legally sealed vault that even the CEO cannot open. During the retention period, no user — including the AWS root account — can delete the object or shorten the retention period. This is the mode required for regulations like FINRA, SEC Rule 17a-4, and HIPAA.
| Aspect | Governance Mode | Compliance Mode | |--------|----------------|----------------| | Unlock | Possible with special permission | Not possible before expiry | | Shorten retention | Possible with special permission | Not possible | | AWS root account | Can override | Cannot override | | Best fit | Testing, flexible compliance | FINRA, SEC, HIPAA legal mandates |
Legal Hold locks an object without setting a retention period. Only users with the permission can activate or release it. It is used to preserve evidence during litigation.
When an object is deleted in a Versioning-enabled bucket, S3 creates a Delete Marker — the original version is retained. MFA Delete adds an MFA challenge to version deletion operations, protecting against mass deletion in the event of credential compromise. It can only be enabled using the root account via the AWS CLI. When Lifecycle policies and Object Lock conflict, Object Lock always wins — no Lifecycle rule can delete an object still under a retention hold.
---
Automated Sensitive Data Classification and Monitoring with Macie
Amazon Macie uses machine learning to automatically discover and classify sensitive data stored in S3 buckets. Instead of manually auditing thousands of buckets, Macie continuously scans for PII (personally identifiable information), financial data, credentials, and healthcare information.
Macie provides two core capabilities: bucket security assessment (automatically evaluating public access, encryption status, and sharing configuration) and sensitive data detection (scheduled and on-demand scans for credit card numbers, national ID numbers, AWS credentials, and more). Detection findings flow through EventBridge to Security Hub, SNS, or Lambda. For the scenario of automatically alerting and quarantining when PII is uploaded to S3, the canonical answer pattern is Macie + EventBridge + Lambda.
A common exam question distinguishes Macie from GuardDuty. Macie focuses on data content — classifying what is inside objects (sensitive information). GuardDuty focuses on S3 API behavioral anomalies — detecting suspicious activity like mass downloads or access from unexpected regions. The two complement each other. For organization-wide deployment, Macie is centrally managed through the AWS Organizations Delegated Administrator model.
---
Tricky S3 Data Protection Scenarios on the Exam
Here are the most common judgment points that appear in exam questions.
Allow S3 access only from a specific VPC: IAM Policy alone is insufficient because the same role can be attached in other VPCs, leaving isolation incomplete. The correct ans