generated from coulomb/repo-seed
44 lines
1.2 KiB
Markdown
44 lines
1.2 KiB
Markdown
# Pattern: Tenant Data Partitioning
|
|
|
|
Status: seed
|
|
Readiness target: RL3 production
|
|
Primary owners: product repos, NetKingdom
|
|
Genesis family: Tenant isolation
|
|
|
|
## Problem
|
|
|
|
Tenant data can leak when storage, query, object, or cache access does
|
|
not enforce tenant partition boundaries.
|
|
|
|
## Context
|
|
|
|
Use this pattern for shared databases, object storage, search indexes,
|
|
caches, queues, analytics stores, and backup/export paths.
|
|
|
|
## Forces
|
|
|
|
- Shared data stores improve efficiency.
|
|
- Every data access must include trusted tenant scope.
|
|
- Query bugs can bypass application-level checks.
|
|
- Backups and exports need the same tenant boundary as live systems.
|
|
|
|
## Solution
|
|
|
|
Partition data by tenant at the storage or query layer and require
|
|
tenant-scoped authorization before access. Use schema, prefix, row-level
|
|
security, bucket/prefix policy, or dedicated stores according to risk.
|
|
|
|
## Verification
|
|
|
|
- Cross-tenant query and object access tests fail.
|
|
- Background jobs and exports carry tenant context.
|
|
- Backups, search, and caches preserve tenant partitioning.
|
|
- Audit records identify tenant, object, and actor.
|
|
|
|
## Related Patterns
|
|
|
|
- Tenant Context Propagation.
|
|
- Object-Level Authorization Check.
|
|
- Key-per-Tenant.
|
|
- STS Credential Vending.
|