Determine Appropriate Data Security Controls

Source: Dev.to

🛡️ Domain 1 – Design Secure Architectures

Task 1.3 – Determining Appropriate Data‑Security Controls

Goal: Protect data throughout its entire lifecycle.

Quick Checklist

• IAM – Enforce least‑privilege, use role‑based access, enable MFA.
• Classification – Tag resources with sensitivity level; apply lifecycle policies accordingly.
• Encryption – Enable default encryption for storage services; enforce TLS 1.2+ for all network traffic.
• Key Management – Rotate KMS keys regularly (e.g., annually) or per compliance requirement; audit key usage with CloudTrail.
• Backup/DR – Automate backups, test restores quarterly, and replicate critical data to at least one additional AWS Region.

Secure Data Design Questions You Should Be Able to Answer

1 | Data Access and Governance

• Data governance on AWS usually means:
  • Strong IAM controls (least privilege)
  • Resource policies (e.g., S3 bucket policies)
  • Central guardrails (Organizations + SCPs in multi‑account)
  • Visibility & auditing (CloudTrail, S3 access logs, AWS Config)

“Prevent unintended public exposure” → tighten resource policies, block public access, enforce least‑privilege.

2 | Data Recovery

• Goal: Meet RPO/RTO requirements and survive failures.
• Key techniques:
  • Backups – point‑in‑time restore, snapshots.
  • Replication – same‑region or cross‑region copy.
  • DR patterns – pilot light, warm standby, multi‑site.

“Need cross‑region recovery?”
Enable replication plus cross‑region backups.

3 | Data Retention and Classification

• Keep data only as long as needed (compliance + cost).
• Classify data and apply controls based on sensitivity.

Common AWS Tools & Patterns

1. S3 lifecycle policies – transition objects to IA/Glacier and expire them.
2. S3 Object Lock – WORM retention for compliance.
3. Amazon Macie – discover PII in S3 and aid classification.

4 | Encryption and Appropriate Key Management

Note: Encryption is not just “turn it on”; it’s who controls the keys and who can use them.

Typical Compliance‑Driven Controls

• Encryption at rest and in transit.
• Strong retention & immutability (WORM).
• Auditability & access logging.
• Key separation of duties – security team manages keys, application team uses them.

Regulated data → use customer‑managed KMS keys, enforce tight key policies, enable comprehensive logging, and apply retention controls.

B | Encrypt Data at Rest

AWS Key Management Service (KMS)

Common “Encryption‑at‑Rest” Mappings

Need control over key usage / audit / rotation?
Use SSE‑KMS with a customer‑managed key.

ACM (AWS Certificate Manager) & TLS

• Use TLS for all client‑to‑service and service‑to‑service traffic.
• ACM provisions and manages certificates for:
  • ALB / NLB (TLS listeners)
  • CloudFront
  • API Gateway (custom domains)

Manage and renew certs automatically → use ACM.

KMS Access Control

1. Key policies – primary control plane.
2. IAM policies – supplemental control.
3. KMS grants – often used by AWS services to act on your behalf.

Design Recommendations

• Least‑privilege: grant only the actions kms:Encrypt, kms:Decrypt, kms:GenerateDataKey that are required.
• Separation of duties: admins manage the key; applications can use it but cannot modify it.

Only a specific role can decrypt?
Create a KMS key policy that allows Decrypt for that role and denies everyone else.

Common AWS Backup & Replication Patterns

Tip: Use AWS Backup + AWS Organizations to enforce a centralized backup policy across multiple accounts.

Example Configurations

1. S3 bucket policy – Restrict access to specific IAM roles or VPC endpoints and require TLS.
2. S3 Block Public Access – Prevent accidental public exposure of bucket contents.
3. Lifecycle policies – Transition older objects to cheaper storage tiers and expire them when retention periods end.
4. Object Lock – Enforce WORM (Write‑Once‑Read‑Many) retention for compliance archives.

Use case: “Must prevent deletion for X years” → S3 Object Lock.

5. KMS key rotation – Enable automatic rotation for customer‑managed CMKs (where applicable).
6. Secrets rotation – Configure Secrets Manager to rotate database passwords, API keys, etc. automatically.
7. Certificate renewal – Let ACM automatically renew eligible TLS/SSL certificates.

Use case: “Rotate keys automatically without app changes” → KMS automatic rotation (customer‑managed CMK) combined with envelope‑encryption patterns (handled by AWS services).

Scenario‑Based Decision Matrix

Quick Checklist for Task 1.3

• Classify data – public, internal, confidential, or regulatory; ensure controls match the sensitivity.
• Encrypt data at rest – typically via AWS KMS; use Customer‑Managed Keys (CMKs) when you need tighter control.
• Protect data in transit – TLS with ACM‑managed certificates (or equivalent).
• Apply least‑privilege key management – separate duties and restrict key usage.
• Backup & disaster recovery – meet RPO/RTO using AWS Backup, snapshots, or cross‑region replication.
• Enforce retention policies – use S3 lifecycle rules, Object Lock, or legal hold to satisfy required lifecycles.

AWS Data‑Security Controls Checklist (Task Statement 1.3)

These are the primary AWS documents behind Task Statement 1.3. You do not need to memorize them; use them to understand why AWS data‑security controls work the way they do.

Core Reference Materials

1. AWS Key Management Service (KMS) – Developer Guide

• Covers KMS keys, envelope encryption, key policies, grants, and rotation.
• Primary source for “who can encrypt/decrypt?” questions.

2. KMS Key Policies

• Central mechanism for controlling key usage.
• Enables “only this role can decrypt” and separation‑of‑duties scenarios.

3. AWS Certificate Manager (ACM)

• Provisioning and renewal of TLS certificates.
• Used with ALB, CloudFront, and API Gateway custom‑domain encryption.

4. Data Protection by Service

• Overview of encryption options and best‑practice configurations for each AWS service.

5. Amazon S3 Encryption Options

• SSE‑S3 – Server‑side encryption with S3‑managed keys.
• SSE‑KMS – Server‑side encryption with KMS‑managed keys.
• Client‑side encryption – Encryption performed before data reaches S3.
• Helps decide “which encryption option should we pick?”.

6. S3 Block Public Access

• Blocks accidental public exposure via ACLs or bucket policies.
• Ideal control when the scenario focuses on preventing data leakage.

7. S3 Object Lock (WORM Retention)

• Provides compliance‑grade immutability and legal hold.
• Tested for requirements involving retention or immutability.

8. Amazon RDS Encryption

• Encryption at rest for RDS/Aurora, including impact on snapshots and replicas.

9. Backup, Recovery, & Retention

• Guidance for designing backup strategies that meet RPO/RTO objectives.

10. AWS Backup

• Centralized backup policies, vaults, lifecycle rules, and cross‑account patterns.
• Frequently referenced for “backup at scale” exam questions.

11. Disaster Recovery on AWS (Concepts & Patterns)

• Explains RPO/RTO and DR strategies: backup/restore, pilot light, warm standby, multi‑site.
• Assists in matching a DR approach to a given requirement.

12. Compliance & Security Mindset

• AWS Well‑Architected Framework – Security Pillar – Rationale behind least‑privilege, data protection, and governance decisions.
• AWS Shared Responsibility Model – Clarifies AWS‑provided controls vs. customer‑managed configurations (especially for encryption and access).

🚀 Tip: Use this checklist as a quick‑look guide when designing or reviewing AWS data‑security solutions.