Opening Framing
Networks can be rebuilt, applications redeployed, and infrastructure recreated from code. But data—customer records, intellectual property, financial transactions—is irreplaceable and often the ultimate target of attacks. In cloud environments, data protection encompasses encryption at rest and in transit, key management, access controls, data classification, and preventing unauthorized exposure.
Cloud providers offer powerful data protection capabilities: managed encryption, hardware security modules, automated key rotation, and data loss prevention services. But these capabilities only work when properly configured. A single misconfigured S3 bucket can expose millions of records. Understanding how to classify data, apply appropriate controls, and verify protection is essential.
This week covers data classification, encryption at rest and in transit, key management services, storage security (S3, databases), secrets management, and data loss prevention. You'll learn to implement defense-in-depth for your most valuable assets.
Key insight: Encryption without proper key management is security theater. Both must work together.
1) Data Classification and Lifecycle
Effective data protection starts with understanding what data you have and how sensitive it is:
Data Classification Framework:
CLASSIFICATION LEVELS:
┌─────────────────────────────────────────────────────────────┐
│ PUBLIC │
│ ├── Definition: No impact if disclosed │
│ ├── Examples: Marketing materials, public docs │
│ ├── Controls: Basic access controls │
│ └── Encryption: Optional │
├─────────────────────────────────────────────────────────────┤
│ INTERNAL │
│ ├── Definition: Internal use only, minor impact if leaked │
│ ├── Examples: Internal policies, org charts │
│ ├── Controls: Authentication required │
│ └── Encryption: Recommended │
├─────────────────────────────────────────────────────────────┤
│ CONFIDENTIAL │
│ ├── Definition: Significant impact if disclosed │
│ ├── Examples: Customer data, financial records, PII │
│ ├── Controls: Encryption, access logging, least privilege │
│ └── Encryption: Required at rest and in transit │
├─────────────────────────────────────────────────────────────┤
│ RESTRICTED │
│ ├── Definition: Severe impact, regulatory requirements │
│ ├── Examples: PHI, payment card data, trade secrets │
│ ├── Controls: Strong encryption, MFA, audit trails, DLP │
│ └── Encryption: Required, customer-managed keys │
└─────────────────────────────────────────────────────────────┘
CLASSIFICATION BY REGULATION:
┌─────────────────────────────────────────────────────────────┐
│ Data Type │ Regulations │ Minimum Level │
├────────────────────┼───────────────────┼────────────────────┤
│ Payment Card (PCI) │ PCI DSS │ Restricted │
│ Health Info (PHI) │ HIPAA │ Restricted │
│ Personal Data (EU) │ GDPR │ Confidential+ │
│ Financial Records │ SOX, GLBA │ Confidential │
│ Student Records │ FERPA │ Confidential │
│ Government Data │ FedRAMP, ITAR │ Varies │
└─────────────────────────────────────────────────────────────┘Data Lifecycle Security:
Data Lifecycle Stages:
┌─────────────────────────────────────────────────────────────┐
│ CREATE ──► STORE ──► USE ──► SHARE ──► ARCHIVE ──► DESTROY │
└─────────────────────────────────────────────────────────────┘
CREATE:
┌─────────────────────────────────────────────────────────────┐
│ Security Considerations: │
│ - Classify at creation │
│ - Minimize data collection (data minimization) │
│ - Encrypt immediately │
│ - Tag with metadata (owner, classification, retention) │
│ │
│ Cloud Controls: │
│ - Default encryption on storage │
│ - Automatic tagging policies │
│ - Input validation │
└─────────────────────────────────────────────────────────────┘
STORE:
┌─────────────────────────────────────────────────────────────┐
│ Security Considerations: │
│ - Encryption at rest │
│ - Access controls (IAM, bucket policies) │
│ - Versioning for integrity │
│ - Backup and replication │
│ │
│ Cloud Controls: │
│ - S3 encryption, bucket policies │
│ - RDS encryption, IAM authentication │
│ - Cross-region replication │
└─────────────────────────────────────────────────────────────┘
USE:
┌─────────────────────────────────────────────────────────────┐
│ Security Considerations: │
│ - Encryption in transit │
│ - Least privilege access │
│ - Audit logging │
│ - Secure processing environments │
│ │
│ Cloud Controls: │
│ - TLS enforcement │
│ - IAM roles for applications │
│ - CloudTrail, data access logs │
└─────────────────────────────────────────────────────────────┘
SHARE:
┌─────────────────────────────────────────────────────────────┐
│ Security Considerations: │
│ - Secure transfer methods │
│ - Access controls on shared data │
│ - Time-limited sharing │
│ - Track who has access │
│ │
│ Cloud Controls: │
│ - Pre-signed URLs with expiration │
│ - Cross-account roles │
│ - VPC endpoints for private sharing │
└─────────────────────────────────────────────────────────────┘
ARCHIVE:
┌─────────────────────────────────────────────────────────────┐
│ Security Considerations: │
│ - Maintain encryption │
│ - Preserve access logs │
│ - Retention policy compliance │
│ - Restore testing │
│ │
│ Cloud Controls: │
│ - S3 Glacier, lifecycle policies │
│ - Object Lock for immutability │
│ - Vault Lock policies │
└─────────────────────────────────────────────────────────────┘
DESTROY:
┌─────────────────────────────────────────────────────────────┐
│ Security Considerations: │
│ - Secure deletion verification │
│ - Key destruction for crypto-shredding │
│ - Compliance with retention requirements │
│ - Audit trail of destruction │
│ │
│ Cloud Controls: │
│ - Lifecycle policies for automatic deletion │
│ - KMS key deletion (7-30 day waiting period) │
│ - S3 object expiration │
└─────────────────────────────────────────────────────────────┘Key insight: Security controls must follow data through its entire lifecycle, not just when it's actively being used.
2) Encryption at Rest
Encryption at rest protects data stored on disk from physical theft, unauthorized access, and some insider threats:
Encryption at Rest Concepts:
WHY ENCRYPT AT REST:
┌─────────────────────────────────────────────────────────────┐
│ Protection Against: │
│ - Physical theft of storage media │
│ - Unauthorized access to storage systems │
│ - Insider threats with storage access │
│ - Improper decommissioning │
│ - Compliance requirements (PCI, HIPAA, GDPR) │
│ │
│ Does NOT Protect Against: │
│ - Application-level attacks │
│ - Authorized users with decryption access │
│ - Compromised credentials │
│ - Memory-based attacks │
└─────────────────────────────────────────────────────────────┘
ENCRYPTION TYPES:
┌─────────────────────────────────────────────────────────────┐
│ SERVER-SIDE ENCRYPTION (SSE): │
│ - Cloud provider encrypts after receiving data │
│ - Decrypts when authorized user requests │
│ - Transparent to applications │
│ - Provider manages encryption/decryption │
│ │
│ CLIENT-SIDE ENCRYPTION (CSE): │
│ - You encrypt before sending to cloud │
│ - Provider never sees unencrypted data │
│ - You manage keys completely │
│ - More complex but maximum control │
└─────────────────────────────────────────────────────────────┘AWS Encryption Options:
AWS Server-Side Encryption Options:
SSE-S3 (S3 Managed Keys):
┌─────────────────────────────────────────────────────────────┐
│ How It Works: │
│ - AWS manages keys completely │
│ - Unique key per object │
│ - Master key regularly rotated by AWS │
│ - AES-256 encryption │
│ │
│ Pros: │
│ + Simplest option, no key management │
│ + No additional cost │
│ + Default encryption option │
│ │
│ Cons: │
│ - No control over keys │
│ - Cannot audit key usage │
│ - Cannot revoke access via key deletion │
│ │
│ Best For: General data without compliance requirements │
└─────────────────────────────────────────────────────────────┘
SSE-KMS (KMS Managed Keys):
┌─────────────────────────────────────────────────────────────┐
│ How It Works: │
│ - Keys stored in AWS KMS │
│ - You create and manage KMS keys │
│ - Envelope encryption (data key encrypted by KMS key) │
│ - Full audit trail in CloudTrail │
│ │
│ Pros: │
│ + Control over key policies │
│ + Audit trail of all key usage │
│ + Can disable/delete keys to revoke access │
│ + Automatic key rotation available │
│ + Separation of duties (key admin vs data admin) │
│ │
│ Cons: │
│ - Additional cost per API call │
│ - Slightly more complex │
│ - Rate limits on KMS API │
│ │
│ Best For: Sensitive data, compliance requirements │
└─────────────────────────────────────────────────────────────┘
SSE-C (Customer Provided Keys):
┌─────────────────────────────────────────────────────────────┐
│ How It Works: │
│ - You provide encryption key with each request │
│ - AWS uses key to encrypt/decrypt │
│ - AWS does not store the key │
│ - You must manage key storage │
│ │
│ Pros: │
│ + Complete key control │
│ + Keys never stored by AWS │
│ │
│ Cons: │
│ - You must manage key storage securely │
│ - Key must be provided with every request │
│ - Complex operational model │
│ - Lose key = lose data │
│ │
│ Best For: Specific compliance requiring key custody │
└─────────────────────────────────────────────────────────────┘
COMPARISON:
┌────────────────┬──────────┬──────────┬──────────┐
│ Feature │ SSE-S3 │ SSE-KMS │ SSE-C │
├────────────────┼──────────┼──────────┼──────────┤
│ Key Management │ AWS │ You+AWS │ You │
│ Audit Trail │ No │ Yes │ No │
│ Key Rotation │ Auto │ Optional │ Manual │
│ Access Control │ IAM only │ IAM+Key │ Key only │
│ Cost │ Free │ Per call │ Free │
│ Complexity │ Low │ Medium │ High │
└────────────────┴──────────┴──────────┴──────────┘Encryption Across Services:
AWS Service Encryption:
S3:
┌─────────────────────────────────────────────────────────────┐
│ Default Encryption: Can be enabled at bucket level │
│ Options: SSE-S3, SSE-KMS, SSE-C │
│ Bucket Policy: Can require encryption │
│ │
│ Require Encryption Policy: │
│ { │
│ "Condition": { │
│ "StringNotEquals": { │
│ "s3:x-amz-server-side-encryption": "aws:kms" │
│ } │
│ } │
│ } │
└─────────────────────────────────────────────────────────────┘
EBS (Elastic Block Store):
┌─────────────────────────────────────────────────────────────┐
│ Encryption: Per-volume setting │
│ Default: Can enable account-level default encryption │
│ Options: AWS managed key or customer managed KMS key │
│ Snapshots: Encrypted if volume is encrypted │
│ │
│ Enable Default Encryption: │
│ aws ec2 enable-ebs-encryption-by-default │
└─────────────────────────────────────────────────────────────┘
RDS:
┌─────────────────────────────────────────────────────────────┐
│ Encryption: Enabled at instance creation │
│ Cannot be changed after creation │
│ Encrypts: Storage, snapshots, read replicas, backups │
│ Options: AWS managed or customer managed KMS key │
│ │
│ Note: To encrypt existing unencrypted database: │
│ 1. Create encrypted snapshot copy │
│ 2. Restore from encrypted snapshot │
└─────────────────────────────────────────────────────────────┘
DynamoDB:
┌─────────────────────────────────────────────────────────────┐
│ Encryption: Always encrypted (default since 2018) │
│ Options: AWS owned, AWS managed, customer managed │
│ Encrypts: Tables, indexes, streams, backups │
└─────────────────────────────────────────────────────────────┘Key insight: Default to SSE-KMS for sensitive data. The audit trail and access control are worth the small additional cost.
3) Key Management Services
Key management is the critical enabler of encryption—poor key management undermines even strong encryption:
AWS Key Management Service (KMS):
KMS CONCEPTS:
┌─────────────────────────────────────────────────────────────┐
│ KMS Key (formerly CMK): │
│ - Logical key resource in KMS │
│ - Never leaves KMS unencrypted │
│ - Used to encrypt/decrypt data keys │
│ - Has key policy controlling access │
│ │
│ Data Key: │
│ - Generated by KMS for encrypting actual data │
│ - Plaintext used for encryption, then discarded │
│ - Encrypted copy stored with data │
│ - Envelope encryption pattern │
│ │
│ Key Policy: │
│ - Resource policy attached to KMS key │
│ - Determines who can use and manage the key │
│ - Required for any key access │
└─────────────────────────────────────────────────────────────┘
ENVELOPE ENCRYPTION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ENCRYPTION: │
│ ┌─────────┐ ┌─────────────┐ ┌─────────────────┐ │
│ │ KMS Key │────►│ Generate │────►│ Plaintext Data │ │
│ │ │ │ Data Key │ │ Key │ │
│ └─────────┘ └─────────────┘ └────────┬────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────┐ ┌──────────────┐ │
│ │ Encrypted Data │ │ Encrypt Data │ │
│ │ Key │ │ │ │
│ └────────┬────────┘ └──────┬───────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────────────────────────┐ │
│ │ Encrypted Data + Encrypted Key │ │
│ │ (Stored Together) │ │
│ └─────────────────────────────────────┘ │
│ │
│ DECRYPTION: │
│ 1. Retrieve encrypted data key │
│ 2. Send to KMS for decryption │
│ 3. Use plaintext data key to decrypt data │
│ 4. Discard plaintext data key │
│ │
└─────────────────────────────────────────────────────────────┘KMS Key Types and Policies:
KMS Key Types:
AWS OWNED KEYS:
┌─────────────────────────────────────────────────────────────┐
│ - AWS creates and manages completely │
│ - Shared across multiple accounts │
│ - No visibility or control │
│ - No additional cost │
│ - Used by some services by default │
└─────────────────────────────────────────────────────────────┘
AWS MANAGED KEYS:
┌─────────────────────────────────────────────────────────────┐
│ - Created by AWS in your account │
│ - Named aws/service (e.g., aws/s3, aws/ebs) │
│ - Automatic rotation yearly │
│ - Visible in console, limited control │
│ - No additional cost beyond API calls │
└─────────────────────────────────────────────────────────────┘
CUSTOMER MANAGED KEYS:
┌─────────────────────────────────────────────────────────────┐
│ - You create and manage │
│ - Full control over key policy │
│ - Optional automatic rotation │
│ - Can be enabled/disabled/deleted │
│ - Monthly cost + API call costs │
│ - Best for sensitive data │
└─────────────────────────────────────────────────────────────┘
KEY POLICY EXAMPLE:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Enable IAM policies",
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::111122223333:root"},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow key administrators",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/KeyAdmin"
},
"Action": [
"kms:Create*",
"kms:Describe*",
"kms:Enable*",
"kms:List*",
"kms:Put*",
"kms:Update*",
"kms:Revoke*",
"kms:Disable*",
"kms:Delete*",
"kms:ScheduleKeyDeletion",
"kms:CancelKeyDeletion"
],
"Resource": "*"
},
{
"Sid": "Allow key usage",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/AppRole"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:GenerateDataKey*"
],
"Resource": "*"
}
]
}Key Rotation and Management:
Key Rotation:
AUTOMATIC ROTATION (KMS):
┌─────────────────────────────────────────────────────────────┐
│ - Enabled per key │
│ - Rotates yearly automatically │
│ - Old key material retained for decryption │
│ - New material used for new encryptions │
│ - Transparent to applications │
│ - Key ID stays the same │
│ │
│ aws kms enable-key-rotation --key-id │
└─────────────────────────────────────────────────────────────┘
MANUAL ROTATION:
┌─────────────────────────────────────────────────────────────┐
│ When Needed: │
│ - More frequent than yearly rotation │
│ - Different key material │
│ - Key compromise response │
│ │
│ Process: │
│ 1. Create new KMS key │
│ 2. Update alias to point to new key │
│ 3. Re-encrypt data with new key (if required) │
│ 4. Schedule deletion of old key │
│ │
│ Consideration: Existing data stays encrypted with old key │
└─────────────────────────────────────────────────────────────┘
KEY DELETION:
┌─────────────────────────────────────────────────────────────┐
│ WARNING: Deleting key = losing access to encrypted data │
│ │
│ Safeguards: │
│ - 7-30 day waiting period (default 30) │
│ - Can cancel during waiting period │
│ - Cannot be undone after waiting period │
│ │
│ Best Practice: │
│ - Disable key first, monitor for usage │
│ - Only delete after confirming no dependencies │
│ - Use for crypto-shredding (intentional data destruction) │
└─────────────────────────────────────────────────────────────┘
CROSS-ACCOUNT KEY SHARING:
┌─────────────────────────────────────────────────────────────┐
│ Key Policy Grant: │
│ { │
│ "Sid": "Allow external account", │
│ "Effect": "Allow", │
│ "Principal": { │
│ "AWS": "arn:aws:iam::444455556666:root" │
│ }, │
│ "Action": [ │
│ "kms:Encrypt", │
│ "kms:Decrypt", │
│ "kms:GenerateDataKey*" │
│ ], │
│ "Resource": "*" │
│ } │
│ │
│ + IAM policy in external account allowing kms:* on key ARN │
└─────────────────────────────────────────────────────────────┘ Key insight: Separate key administration from key usage. The person managing keys should not be the one using them.
4) Storage Security
Cloud storage services require specific security configurations to prevent data exposure:
S3 Security:
S3 SECURITY LAYERS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Account Level: S3 Block Public Access │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ Bucket Level: Bucket Policy + ACL │ │ │
│ │ │ ┌─────────────────────────────────────────────┐ │ │ │
│ │ │ │ Object Level: Object ACL + Encryption │ │ │ │
│ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ │
│ │ │ │ │ Your Data │ │ │ │ │
│ │ │ │ └─────────────────────────────────────────┘ │ │ │ │
│ │ │ └─────────────────────────────────────────────┘ │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
S3 BLOCK PUBLIC ACCESS:
┌─────────────────────────────────────────────────────────────┐
│ Account-level or bucket-level settings: │
│ │
│ □ BlockPublicAcls │
│ Prevents adding public ACLs │
│ │
│ □ IgnorePublicAcls │
│ Ignores existing public ACLs │
│ │
│ □ BlockPublicPolicy │
│ Prevents adding public bucket policies │
│ │
│ □ RestrictPublicBuckets │
│ Restricts access to public buckets │
│ │
│ BEST PRACTICE: Enable all four at account level │
│ Only disable for specific buckets that must be public │
└─────────────────────────────────────────────────────────────┘
SECURE BUCKET POLICY EXAMPLE:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyUnencryptedUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::my-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
},
{
"Sid": "DenyHTTP",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "RestrictToVPCEndpoint",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
],
"Condition": {
"StringNotEquals": {
"aws:sourceVpce": "vpce-1234567890abcdef"
}
}
}
]
}S3 Additional Security Features:
S3 Security Features:
VERSIONING:
┌─────────────────────────────────────────────────────────────┐
│ - Preserves all versions of objects │
│ - Protection against accidental deletion │
│ - Protection against overwrites │
│ - Required for cross-region replication │
│ - Cost: Storage for all versions │
│ │
│ Security Use: Ransomware recovery, audit trail │
└─────────────────────────────────────────────────────────────┘
OBJECT LOCK:
┌─────────────────────────────────────────────────────────────┐
│ WORM (Write Once Read Many) protection │
│ │
│ Retention Modes: │
│ - Governance: Can be overridden with permission │
│ - Compliance: Cannot be overridden by anyone (even root) │
│ │
│ Legal Hold: │
│ - Prevents deletion regardless of retention │
│ - For litigation or investigation holds │
│ │
│ Security Use: Compliance, ransomware protection │
└─────────────────────────────────────────────────────────────┘
ACCESS LOGGING:
┌─────────────────────────────────────────────────────────────┐
│ Server Access Logging: │
│ - Logs all requests to bucket │
│ - Delivered to target bucket │
│ - Best effort delivery │
│ │
│ S3 Data Events (CloudTrail): │
│ - Object-level API logging │
│ - GetObject, PutObject, DeleteObject │
│ - Guaranteed delivery │
│ - Additional cost │
└─────────────────────────────────────────────────────────────┘
ACCESS POINTS:
┌─────────────────────────────────────────────────────────────┐
│ - Named network endpoints for bucket access │
│ - Simplify managing access for shared datasets │
│ - Each access point has own policy │
│ - Can be VPC-only (no internet access) │
│ │
│ Use Case: Different teams accessing same bucket with │
│ different permissions via different access points │
└─────────────────────────────────────────────────────────────┘
MACIE (Data Discovery):
┌─────────────────────────────────────────────────────────────┐
│ - ML-powered sensitive data discovery │
│ - Scans S3 buckets for PII, PHI, credentials │
│ - Identifies security issues (public buckets, etc.) │
│ - Generates findings for remediation │
│ │
│ Use Case: Find sensitive data you didn't know about │
└─────────────────────────────────────────────────────────────┘Database Security:
RDS Security:
NETWORK SECURITY:
┌─────────────────────────────────────────────────────────────┐
│ - Deploy in private subnets │
│ - Security groups limiting access │
│ - No public accessibility │
│ - VPC endpoints for management │
│ │
│ RDS Security Group Example: │
│ Inbound: MySQL (3306) from app-tier-sg only │
│ Outbound: None (or minimal) │
└─────────────────────────────────────────────────────────────┘
AUTHENTICATION:
┌─────────────────────────────────────────────────────────────┐
│ Traditional: Username/password │
│ │
│ IAM Database Authentication: │
│ - Use IAM credentials to authenticate │
│ - No password management │
│ - Token-based with 15-minute validity │
│ - Audit via CloudTrail │
│ │
│ Connection Flow: │
│ 1. Application assumes IAM role │
│ 2. Generates RDS authentication token │
│ 3. Connects using token as password │
│ 4. Token expires, application regenerates │
└─────────────────────────────────────────────────────────────┘
ENCRYPTION:
┌─────────────────────────────────────────────────────────────┐
│ At Rest: Enable at instance creation │
│ In Transit: Enable SSL/TLS enforcement │
│ │
│ Force SSL (PostgreSQL parameter group): │
│ rds.force_ssl = 1 │
│ │
│ Verify SSL Connection: │
│ SELECT ssl_is_used(); -- Returns true if SSL │
└─────────────────────────────────────────────────────────────┘
ADDITIONAL CONTROLS:
┌─────────────────────────────────────────────────────────────┐
│ - Automated backups with encryption │
│ - Snapshot encryption │
│ - Enhanced monitoring │
│ - Performance Insights │
│ - Audit logging (varies by engine) │
│ - Parameter groups for security settings │
└─────────────────────────────────────────────────────────────┘Key insight: Multiple security layers protect data. No single control is sufficient—use defense in depth.
5) Secrets Management and Data Loss Prevention
Proper secrets management and DLP prevent credential exposure and data leakage:
Secrets Management:
WHY SECRETS MANAGEMENT MATTERS:
┌─────────────────────────────────────────────────────────────┐
│ Problems with Hardcoded Secrets: │
│ - Committed to source control │
│ - Visible in configuration files │
│ - Difficult to rotate │
│ - Shared across environments │
│ - No audit trail │
│ │
│ Real Impact: │
│ - GitHub scans find 1000s of exposed AWS keys daily │
│ - Compromised within minutes of commit │
│ - Used for cryptomining, data theft, lateral movement │
└─────────────────────────────────────────────────────────────┘
AWS SECRETS MANAGER:
┌─────────────────────────────────────────────────────────────┐
│ Features: │
│ - Centralized secret storage │
│ - Automatic rotation │
│ - Fine-grained access control │
│ - Audit via CloudTrail │
│ - Encryption with KMS │
│ - Cross-region replication │
│ │
│ Supported Secret Types: │
│ - Database credentials (auto-rotation for RDS) │
│ - API keys │
│ - OAuth tokens │
│ - Any key-value pairs │
│ │
│ Pricing: $0.40/secret/month + $0.05/10,000 API calls │
└─────────────────────────────────────────────────────────────┘
SECRETS MANAGER USAGE:
# Store a secret
aws secretsmanager create-secret \
--name prod/database/mysql \
--secret-string '{"username":"admin","password":"secret123"}'
# Retrieve a secret (in application)
import boto3
import json
client = boto3.client('secretsmanager')
response = client.get_secret_value(SecretId='prod/database/mysql')
secret = json.loads(response['SecretString'])
username = secret['username']
password = secret['password']
# Enable rotation
aws secretsmanager rotate-secret \
--secret-id prod/database/mysql \
--rotation-lambda-arn arn:aws:lambda:...:function:rotate-fn \
--rotation-rules AutomaticallyAfterDays=30
AWS SYSTEMS MANAGER PARAMETER STORE:
┌─────────────────────────────────────────────────────────────┐
│ Alternative for simpler use cases: │
│ │
│ Standard Parameters: Free (up to 10,000) │
│ Advanced Parameters: $0.05/parameter/month │
│ │
│ SecureString: Encrypted with KMS │
│ No built-in rotation (use Lambda) │
│ │
│ Best For: Configuration values, less frequent rotation │
└─────────────────────────────────────────────────────────────┘Data Loss Prevention:
Data Loss Prevention (DLP):
DLP STRATEGIES:
┌─────────────────────────────────────────────────────────────┐
│ 1. DISCOVERY │
│ Find where sensitive data exists │
│ - Amazon Macie (S3 scanning) │
│ - Third-party DLP tools │
│ - Manual classification │
│ │
│ 2. CLASSIFICATION │
│ Tag and categorize data │
│ - Resource tags │
│ - Automated classification │
│ - Data catalogs │
│ │
│ 3. PROTECTION │
│ Apply controls based on classification │
│ - Encryption requirements │
│ - Access restrictions │
│ - Network isolation │
│ │
│ 4. MONITORING │
│ Detect policy violations │
│ - Access logging │
│ - Anomaly detection │
│ - Alert on sensitive data access │
│ │
│ 5. PREVENTION │
│ Block unauthorized data movement │
│ - VPC endpoint policies │
│ - S3 bucket policies │
│ - Network egress filtering │
└─────────────────────────────────────────────────────────────┘
AMAZON MACIE:
┌─────────────────────────────────────────────────────────────┐
│ ML-powered sensitive data discovery: │
│ │
│ Detection Types: │
│ - PII (names, addresses, SSN, etc.) │
│ - Financial data (credit cards, bank accounts) │
│ - Credentials (API keys, passwords) │
│ - Health information (PHI) │
│ - Custom data identifiers │
│ │
│ Findings: │
│ - Sensitive data found │
│ - Public buckets │
│ - Unencrypted buckets │
│ - Buckets shared with other accounts │
│ │
│ Integration: │
│ - Security Hub │
│ - EventBridge for automation │
│ - S3 for detailed findings │
└─────────────────────────────────────────────────────────────┘
PREVENTING DATA EXFILTRATION:
┌─────────────────────────────────────────────────────────────┐
│ VPC Endpoint Policy (restrict S3 access): │
│ { │
│ "Statement": [{ │
│ "Effect": "Deny", │
│ "Principal": "*", │
│ "Action": "s3:*", │
│ "Resource": "*", │
│ "Condition": { │
│ "StringNotEquals": { │
│ "s3:ResourceAccount": "111122223333" │
│ } │
│ } │
│ }] │
│ } │
│ │
│ This prevents exfiltration to attacker-controlled buckets │
└─────────────────────────────────────────────────────────────┘
S3 BUCKET POLICY (prevent copying to other accounts):
{
"Statement": [{
"Effect": "Deny",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::sensitive-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}]
}Key insight: DLP is about knowing where your sensitive data is, controlling access to it, and preventing unauthorized movement.
Real-World Context
Case Study: Twitch Source Code Leak (2021)
In 2021, an anonymous user posted 125GB of Twitch data including complete source code, internal tools, and creator payment data. The breach resulted from a server configuration change that exposed an internal Git server to the internet. The exposed data wasn't encrypted at rest in a way that would prevent access by someone who gained system access. This demonstrates that encryption at rest protects against physical theft but not against authorized (or improperly authorized) access. Defense in depth—network isolation, access controls, monitoring, AND encryption—is required.
Case Study: S3 Bucket Exposures
Public S3 bucket exposures have affected hundreds of organizations, exposing billions of records. Notable examples include: Verizon (14M customer records from third-party vendor), US Army (classified data from misconfigured bucket), and multiple companies exposing customer PII. These breaches share common causes: default public access, misunderstanding of bucket policies, no monitoring for public exposure. AWS responded with S3 Block Public Access (account-level setting) and console warnings. Prevention requires account-level blocks, automated compliance checking, and monitoring tools like Macie and Access Analyzer.
Data Protection Checklist:
Data Protection Best Practices:
ENCRYPTION:
□ Default encryption on all storage (S3, EBS, RDS)
□ Use SSE-KMS for sensitive data
□ Enable automatic key rotation
□ Enforce TLS for data in transit
□ Separate key administration from usage
ACCESS CONTROL:
□ S3 Block Public Access at account level
□ Bucket policies denying unencrypted uploads
□ VPC endpoints for private access
□ IAM database authentication
□ Least privilege access policies
SECRETS:
□ No hardcoded credentials in code
□ Secrets Manager for database credentials
□ Automatic secret rotation enabled
□ IAM roles for applications (no access keys)
□ Git hooks to prevent secret commits
MONITORING:
□ S3 access logging enabled
□ CloudTrail data events for sensitive buckets
□ Macie scanning for sensitive data
□ Alerts on bucket policy changes
□ Access Analyzer findings reviewed
COMPLIANCE:
□ Data classification applied
□ Retention policies configured
□ Object Lock for compliance data
□ Cross-region backup for DR
□ Regular access reviewsData protection failures are often simple misconfigurations, not sophisticated attacks. Automation and continuous monitoring are essential.
Guided Lab: S3 Security Configuration
In this lab, you'll implement comprehensive S3 security controls including encryption, access policies, and monitoring.
Lab Environment:
- AWS account with S3, KMS, and Macie access
- AWS CLI or Console
- Sample data files for testing
Exercise Steps:
- Enable S3 Block Public Access at account level
- Create KMS key for S3 encryption
- Create bucket with default SSE-KMS encryption
- Configure bucket policy requiring encryption and HTTPS
- Enable versioning and access logging
- Create VPC endpoint and restrict bucket access
- Enable Macie and run sensitive data scan
- Test security controls
Reflection Questions:
- How do multiple security controls work together?
- What happens if someone tries to upload unencrypted data?
- How would you detect a data exfiltration attempt?
Week Outcome Check
By the end of this week, you should be able to:
- Apply data classification frameworks to cloud resources
- Implement encryption at rest using SSE-S3, SSE-KMS, and SSE-C
- Configure KMS keys with appropriate policies and rotation
- Secure S3 buckets with policies, Block Public Access, and logging
- Implement database security including encryption and IAM auth
- Use Secrets Manager for credential management and rotation
- Deploy DLP controls using Macie and bucket policies
- Prevent data exfiltration using VPC endpoint policies
🎯 Hands-On Labs (Free & Essential)
Protect cloud data with encryption, key management, and secure storage configurations.
🔒 TryHackMe: S3 Bucket Security
What you'll do: Exploit and secure misconfigured S3 buckets—learn to find
exposed data and prevent leaks.
Why it matters: S3 misconfigurations are the #1 cause of cloud data
breaches.
Time estimate: 2-3 hours
🔑 AWS Skill Builder: KMS and Encryption
What you'll do: Master AWS Key Management Service—create keys, configure
encryption, and implement key rotation.
Why it matters: Proper key management is what makes encryption actually
secure.
Time estimate: 2-3 hours
🧪 HackTheBox: Cloud Data Exfiltration
What you'll do: Practice attacking and defending cloud storage—learn data
exfiltration techniques and prevention (free modules).
Why it matters: Understanding attacker data theft methods informs defensive
architecture.
Time estimate: 3-4 hours
💡 Lab Strategy: Use AWS CloudTrail to monitor all S3 access patterns—visibility is the first step to protection.
Resources
Lab
Complete the following lab exercises to practice cloud data protection.