Encryption at Rest Implementation

We enable encryption for every storage service: RDS with KMS customer-managed keys, S3 with SSE-KMS and bucket policies enforcing encryption, EBS volumes with default encryption enabled at the account level, EFS with encryption at rest and in transit, and DynamoDB with AWS-owned or customer-managed keys. Account-level defaults ensure that new resources are encrypted automatically. SCP policies prevent creation of unencrypted resources — no exceptions.

Some data requires encryption above the storage layer. We implement field-level encryption for PII fields (email, phone, SSN) using envelope encryption: a data encryption key (DEK) encrypts the field, and a KMS key encrypts the DEK. This enables per-tenant keys for efficient data deletion (destroy the key, the data is unreadable) and limits blast radius (compromising one tenant's key does not expose other tenants' data). Application encryption libraries handle transparent encrypt/decrypt in the data access layer.

Encryption keys are managed in AWS KMS, Google Cloud KMS, or HashiCorp Vault. Key policies enforce separation of duties: application roles can encrypt/decrypt, admin roles can manage key policies, and no single role can do both. Automatic key rotation runs on a 365-day cycle (KMS default) or 90-day cycle for high-security requirements. Rotated keys remain available for decrypting data encrypted with previous versions. Key usage is logged in CloudTrail for audit.

We verify encryption implementation across the entire infrastructure: AWS Config Rules check that every storage resource uses encryption, custom scripts verify that application-level encryption is applied to all designated fields, and penetration testing confirms that raw data is not accessible through any unencrypted path. Compliance reports map encryption controls to framework requirements: SOC 2 CC6.1, HIPAA 164.312(a)(2)(iv), PCI DSS 3.4, and GDPR Article 32.