Data Security and Governance
Core concepts
Governance has four layers: identity (IAM roles, least privilege, trust and permission policies), resource policy (S3 bucket policies, KMS key policies), network (VPC endpoints - gateway endpoints for S3 and DynamoDB, interface endpoints for Glue, Kinesis, and Redshift), and data-level controls (Lake Formation, Macie, encryption).
Encryption at rest: SSE-S3, SSE-KMS (auditable, allows key policies and grants), SSE-C (customer-provided keys), and client-side. In transit: TLS for S3/API calls and SSL enforcement on Redshift clusters. DynamoDB and S3 encrypt by default with AWS-managed keys, but compliance often requires a customer-managed KMS key.
Lake Formation centralizes fine-grained access: database/table/column/row-level (row filter expressions) permissions and tag-based access control (LF-TBAC). Glue Data Catalog and connection passwords can be encrypted with KMS.
Discovery and audit: Macie finds PII in S3, GuardDuty flags anomalous activity, CloudTrail logs data and management events, Config evaluates rules, Secrets Manager and Parameter Store hold credentials, and Glue/Redshift audit logs support forensics.
Traps
- An IAM policy that allows S3 access still fails if the KMS key policy does not grant the caller
kms:Decrypton an SSE-KMS object. - Cross-account reads need three things: caller role permission, bucket policy, and key policy - plus, if the catalog is managed, a Lake Formation grant.
- Once a table is governed by Lake Formation, IAM alone stops working; access needs both the IAM allow and an LF grant (unless it is an IAM-allowed-principals table).
- Macie is discovery/classification, not prevention.
Rule of thumb
Any "cannot read encrypted object" scenario: check IAM role → bucket policy → KMS key policy, in that order.