3.4.2.3. Data Management (Classification, Encryption, Key Management, Access Controls)
3.4.2.3. Data Management (Classification, Encryption, Key Management, Tokenization)
Data security follows the lifecycle: classify → encrypt → manage keys → control access → audit.
Data classification with Amazon Macie:
- ML-powered service that discovers PII, financial data, credentials in S3 buckets
- Automated discovery scans all buckets; targeted scans focus on specific prefixes
- Findings: "S3 bucket contains 1,247 objects with credit card numbers"
Encryption strategies:
| Approach | Where Encrypted | Key Management | Use Case |
|---|---|---|---|
| SSE-S3 | Server-side (S3 managed) | AWS manages everything | Default S3 encryption |
| SSE-KMS | Server-side (KMS managed) | You control key policy | Audit trail, key rotation |
| SSE-C | Server-side (customer key) | You provide key per request | Regulatory requirement |
| Client-side | Before upload | You manage entirely | Maximum control |
AWS KMS key types:
- AWS managed keys (
aws/s3,aws/ebs): Free, automatic rotation, limited control - Customer managed keys (CMKs): You control policy, rotation, and access. $1/month/key.
- Customer managed keys with imported material: You generate and import the key material
- AWS owned keys: used internally by some services for default encryption (e.g., DynamoDB); invisible to you, with no key policy and no CloudTrail record of use
- External key store (XKS): a customer managed key whose key material stays in your own HSM outside AWS, reached through an XKS proxy, for requirements that AWS must never hold the key
Rotation: automatic rotation keeps the same key ID and retains all prior key material, so old ciphertext still decrypts. "Rotating" by creating a new key and moving the alias does not re-encrypt existing data; deleting the old key then makes that data permanently unreadable.
Key policy first: a KMS key's key policy is its primary access control. An IAM policy allowing kms:Decrypt has no effect unless the key policy contains the default statement giving the account principal (arn:aws:iam::<account-id>:root) kms:*, which is what enables IAM policies for that key. If a custom key policy omits it, IAM policies grant nothing on that key; only the key policy (or a KMS grant) can allow access.
Tokenization replaces sensitive data with a non-sensitive token. AWS doesn't have a native tokenization service — implement with DynamoDB (token → data mapping) or use third-party solutions.
Exam Trap: SSE-KMS has a request rate limit (5,500-30,000 requests/second depending on region). High-throughput S3 workloads can be throttled by KMS. If the exam describes S3 performance degradation with KMS encryption, the answer is either using S3 bucket keys (reduces KMS calls by 99%) or switching to SSE-S3.
