Determine Appropriate Data Security Controls (Task 1.3)

Determine Appropriate Data Security Controls

Source: https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/protect-data-at-rest.html

Data controls start with classification (public / internal / confidential / regulated), retention requirements, and access governance. The exam then tests the encryption ladder, key custody, and recovery controls — each with a scenario that hinges on the nuance, not the name.

Encryption at Rest — S3 Options (Memorize the Ladder)

How KMS actually works (envelope encryption)

Brief: KMS stores keys inside FIPS-validated HSMs that never leave AWS custody; your data is encrypted by DATA KEYS that the CMK protects.

How it works: When S3 writes an object with SSE-KMS, it asks KMS to generate a data key; the data key encrypts the object, and the ENCRYPTED data key is stored alongside it. Every read requires KMS to decrypt the data key — which means every read is a KMS API call, logged in CloudTrail, and subject to the KEY POLICY. Key policy is the primary grant: IAM permissions alone cannot override a key policy that does not allow the account; grants provide temporary, scoped key use (cross-account/service use without policy sprawl). AWS-managed keys auto-rotate yearly; customer-managed CMKs rotate on demand with the same alias.

The killer exam nuance: with SSE-KMS, a user needs BOTH s3:GetObject AND kms:Decrypt on the CMK. Granting S3 read without key access = AccessDenied — the single most-tested data-security trap.

Real use-case: An auditor must prove who read a confidential archive: CloudTrail shows every kms:Decrypt against the dedicated CMK, with caller, time, and the exact S3 operation it served. SSE-S3 could never answer that question — no per-key audit trail exists.

Gotchas & interview notes: cross-account S3 access with SSE-KMS needs the KEY POLICY to allow the other account (bucket policy alone is not enough — the second classic trap). KMS requests have quotas (originally ~5,500–50,000/s depending on Region) — high-throughput S3 workloads use S3 Bucket Keys to cut KMS calls per object. CloudHSM = single-tenant FIPS 140-2 Level 3 hardware for the strictest custody (sovereign keys, financial regulation) — "you must control the hardware" → CloudHSM.

Encryption in Transit

• Enforce TLS end-to-end: ACM issues/renews certificates for CloudFront, ALB, API Gateway
• S3/S3 Glacier: bucket policy condition aws:SecureTransport: false = deny — the "force HTTPS" answer
• Internal East-West: TLS between tiers using ACM + AWS Private CA
• AWS Backup plans: frequency, retention, cold-storage tiering, cross-Region and cross-account copies — the isolation answer for ransomware scenarios (accounts compromised by ransomware cannot delete backups in an account they do not control)
• S3 Versioning recovers overwrites/deletes; MFA Delete protects the versions themselves
• S3 Object Lock = WORM retention — compliance mode cannot be bypassed even by root; governance mode allows privileged override
• S3 Replication (CRR) copies objects to another Region — resilience and data sovereignty
• RDS/Aurora encrypted snapshots + point-in-time recovery
• Enforce classification with Amazon Macie (discover PII in S3) and bucket policies denying unencrypted writes (s3:x-amz-server-side-encryption condition)
• Lifecycle: transition + expire per retention schedule; S3 Glacier Vault Lock = immutable archive policy
• Audit: CloudTrail data events on S3, KMS key-use logs, IAM Access Analyzer for public/shared buckets
• Classification: confidential/HIPAA → US Regions only, BAA signed in Artifact
• At rest: S3 SSE-KMS with a dedicated CMK; key policy grants only the app role and the audit role; CloudTrail logs every kms:Decrypt
• In transit: ACM on CloudFront/ALB; bucket policy denies non-TLS uploads
• Retention: 7-year WORM via S3 Object Lock (compliance mode) after landing
• Recovery: AWS Backup daily cross-Region copy to us-west-2, restore tested quarterly
• Detection: Macie alert if a partner drops unencrypted PII; Config rule flags buckets without the encryption policy

Real use-case: A security review finds API clients calling S3 over HTTP from a legacy script. One bucket policy statement (Deny when aws:SecureTransport is false) makes every non-TLS call fail instantly — enforcement without chasing clients.

Gotchas & interview notes: ACM auto-renews DNS-validated certificates — "certificates expiring caused outages" → ACM (the answer to manual cert lifecycle). ACM certs for CloudFront must be in us-east-1 — a deployment gotcha, not an exam staple, but a real one.

Backup, Replication, and Recovery Controls

Brief: Durability is built in (S3's 11 nines); RECOVERABILITY is designed — versioning, backups, replication, and immutable retention.

How the controls stack:

• Enforce TLS end-to-end: ACM issues/renews certificates for CloudFront, ALB, API Gateway
• S3/S3 Glacier: bucket policy condition aws:SecureTransport: false = deny — the "force HTTPS" answer
• Internal East-West: TLS between tiers using ACM + AWS Private CA
• AWS Backup plans: frequency, retention, cold-storage tiering, cross-Region and cross-account copies — the isolation answer for ransomware scenarios (accounts compromised by ransomware cannot delete backups in an account they do not control)
• S3 Versioning recovers overwrites/deletes; MFA Delete protects the versions themselves
• S3 Object Lock = WORM retention — compliance mode cannot be bypassed even by root; governance mode allows privileged override
• S3 Replication (CRR) copies objects to another Region — resilience and data sovereignty
• RDS/Aurora encrypted snapshots + point-in-time recovery
• Enforce classification with Amazon Macie (discover PII in S3) and bucket policies denying unencrypted writes (s3:x-amz-server-side-encryption condition)
• Lifecycle: transition + expire per retention schedule; S3 Glacier Vault Lock = immutable archive policy
• Audit: CloudTrail data events on S3, KMS key-use logs, IAM Access Analyzer for public/shared buckets
• Classification: confidential/HIPAA → US Regions only, BAA signed in Artifact
• At rest: S3 SSE-KMS with a dedicated CMK; key policy grants only the app role and the audit role; CloudTrail logs every kms:Decrypt
• In transit: ACM on CloudFront/ALB; bucket policy denies non-TLS uploads
• Retention: 7-year WORM via S3 Object Lock (compliance mode) after landing
• Recovery: AWS Backup daily cross-Region copy to us-west-2, restore tested quarterly
• Detection: Macie alert if a partner drops unencrypted PII; Config rule flags buckets without the encryption policy

Real use-case: A ransomware event encrypts an S3 data lake — versioning lets the team restore prior object versions; the AWS Backup copies in the SEPARATE security account were never reachable by the compromised credentials. Recovery takes hours, and the ransom negotiation takes none.

Gotchas & interview notes: "cannot delete, even by root, for 7 years" → Object Lock COMPLIANCE mode (SEC 17a-4 style). "recover overwritten objects" → versioning. "immutable backup isolation" → cross-ACCOUNT copy. Untested backups are hope, not a control — quarterly restore drills are part of the design.

Data Access and Lifecycle Policies

• Enforce TLS end-to-end: ACM issues/renews certificates for CloudFront, ALB, API Gateway
• S3/S3 Glacier: bucket policy condition aws:SecureTransport: false = deny — the "force HTTPS" answer
• Internal East-West: TLS between tiers using ACM + AWS Private CA
• AWS Backup plans: frequency, retention, cold-storage tiering, cross-Region and cross-account copies — the isolation answer for ransomware scenarios (accounts compromised by ransomware cannot delete backups in an account they do not control)
• S3 Versioning recovers overwrites/deletes; MFA Delete protects the versions themselves
• S3 Object Lock = WORM retention — compliance mode cannot be bypassed even by root; governance mode allows privileged override
• S3 Replication (CRR) copies objects to another Region — resilience and data sovereignty
• RDS/Aurora encrypted snapshots + point-in-time recovery
• Enforce classification with Amazon Macie (discover PII in S3) and bucket policies denying unencrypted writes (s3:x-amz-server-side-encryption condition)
• Lifecycle: transition + expire per retention schedule; S3 Glacier Vault Lock = immutable archive policy
• Audit: CloudTrail data events on S3, KMS key-use logs, IAM Access Analyzer for public/shared buckets
• Classification: confidential/HIPAA → US Regions only, BAA signed in Artifact
• At rest: S3 SSE-KMS with a dedicated CMK; key policy grants only the app role and the audit role; CloudTrail logs every kms:Decrypt
• In transit: ACM on CloudFront/ALB; bucket policy denies non-TLS uploads
• Retention: 7-year WORM via S3 Object Lock (compliance mode) after landing
• Recovery: AWS Backup daily cross-Region copy to us-west-2, restore tested quarterly
• Detection: Macie alert if a partner drops unencrypted PII; Config rule flags buckets without the encryption policy

Gotchas & interview notes: deny-unencrypted-PUT conditions enforce encryption AT WRITE TIME — catching every client, including future ones. Macie is detection (finds PII that policy missed); the bucket policy is prevention.

Worked Example: Regulated Health Data Pipeline

• Enforce TLS end-to-end: ACM issues/renews certificates for CloudFront, ALB, API Gateway
• S3/S3 Glacier: bucket policy condition aws:SecureTransport: false = deny — the "force HTTPS" answer
• Internal East-West: TLS between tiers using ACM + AWS Private CA
• AWS Backup plans: frequency, retention, cold-storage tiering, cross-Region and cross-account copies — the isolation answer for ransomware scenarios (accounts compromised by ransomware cannot delete backups in an account they do not control)
• S3 Versioning recovers overwrites/deletes; MFA Delete protects the versions themselves
• S3 Object Lock = WORM retention — compliance mode cannot be bypassed even by root; governance mode allows privileged override
• S3 Replication (CRR) copies objects to another Region — resilience and data sovereignty
• RDS/Aurora encrypted snapshots + point-in-time recovery
• Enforce classification with Amazon Macie (discover PII in S3) and bucket policies denying unencrypted writes (s3:x-amz-server-side-encryption condition)
• Lifecycle: transition + expire per retention schedule; S3 Glacier Vault Lock = immutable archive policy
• Audit: CloudTrail data events on S3, KMS key-use logs, IAM Access Analyzer for public/shared buckets
• Classification: confidential/HIPAA → US Regions only, BAA signed in Artifact
• At rest: S3 SSE-KMS with a dedicated CMK; key policy grants only the app role and the audit role; CloudTrail logs every kms:Decrypt
• In transit: ACM on CloudFront/ALB; bucket policy denies non-TLS uploads
• Retention: 7-year WORM via S3 Object Lock (compliance mode) after landing
• Recovery: AWS Backup daily cross-Region copy to us-west-2, restore tested quarterly
• Detection: Macie alert if a partner drops unencrypted PII; Config rule flags buckets without the encryption policy

The senior summary: classify first, then encrypt (SSE-KMS when audit matters, SSE-S3 when it does not), enforce TLS at the policy layer, make retention immutable when law demands it, and keep backups in an account the attacker cannot reach. Each control answers a specific failure — none is optional at "regulated."