Multi-tenant data access patterns and IAM policies
Using Data Stores in AWS
Dunieski Otano
AWS Solutions Architect
The Multi-tenant security breach
- SaaS application serves 1,000 companies
- Bug in application code allows cross-tenant access
- Company A employee views Company B's data
- Result: Lost customers, lawsuits, reputation damage
Understanding multi-tenancy
- What is multi-tenancy?
- Multiple customers share infrastructure
- Benefits
- Cost efficiency, easier maintenance
- Challenge
- Ensuring complete data isolation
Partition key per tenant pattern
- Design
- tenantId as partition key
- Include tenantId in every item
- Advantages
- Cost-effective, scales to thousands
- Requirements
- Strict access controls, IAM policies
Separate tables per tenant pattern
- Design
- Dedicated table for each tenant
- Advantages
- Better isolation, easier compliance
- Disadvantages
- Complexity management, table limits
Separate databases per tenant pattern
- Design
- Dedicated database for each tenant
- Advantages
- Complete isolation, custom configurations
- Disadvantages
- Highest cost, operational overhead
IAM condition keys for tenant isolation
- dynamodb:LeadingKeys
- Restricts partition key access
- Example policy
- "Allow if tenantId = tenant-123"
- Enforcement
- AWS enforces at API level
Implementing defense in depth
- Layer 1: Application
- Layer 2: IAM Policy
- Condition keys enforce isolation
- Layer 3: Database Design
- Partition key physical separation
Testing and validation
- Test cross-tenant access
- Attempt to read other tenant's data
- Should fail with AccessDeniedException
- Audit logging
- CloudTrail logs all access attempts
- Regular reviews
- Review IAM policies and access patterns
Congratulations!
- AWS Data Stores: DynamoDB, S3, ElastiCache, OpenSearch
- Design & Optimize: Table design, storage optimization
- Secure Data: Encryption, secrets management, multi-tenant isolation
Let's practice!
Using Data Stores in AWS
Preparing Video For Download...
