# Multi-Tenancy and Data Isolation Patterns One-sentence definition: Prevent cross-tenant access by design in shared systems. ## Key Facts - Isolation models: separate DBs, separate schemas, or row-level with tenant filters. - Strong tenant context propagation; verify on every access (default deny). - Unique encryption keys per tenant where feasible; rotate independently. - Test with chaos tenants/fuzz to detect breakout paths. - **Verify:** check official (ISC)² CBK and current exam outline. ## Exam Relevance - Choose stronger isolation for high-sensitivity tenants. **Mnemonic:** “**Tenant tag everywhere**.” ## Mini Scenario Q: Tenant ID from header only—risk? A: Header spoofing; bind tenant context to auth token and server-side mapping. ## Revision Checklist - Three isolation models. - Context propagation rule. - Per-tenant key benefit. ## Related [[Row-Level Security and Attribute-Based Filters]] · [[Authorization Design (RBAC ABAC Policy Engines)]] · [[API Security Fundamentals (REST GraphQL gRPC)]] · [[Privacy by Design and Data Classification in SDLC]] · [[Domain 8 - Index]]