Data Segregation and Isolation

Overview

Data segregation ensures tenant data remains isolated in multi-tenant cloud environments, preventing unauthorized cross-tenant access.

Learning Objectives

• Understand multi-tenant data isolation
• Implement database segregation
• Apply encryption for tenant separation
• Configure access controls
• Apply ISO 27017 data isolation controls

Multi-Tenant Data Models

Isolation Strategies

ISO 27017 Controls

A.9.4.1 - Information Access Restriction

Implementation for Multi-Tenancy:

• Row-level security (RLS)
• Tenant ID filtering
• Application-level isolation
• Encrypted tenant data

CLD.6.3.1 - Virtual Machine Hardening

Data Isolation:

• Separate storage volumes per tenant
• Encrypted volumes with tenant-specific keys
• Network isolation
• Access logging

Database Segregation Techniques

Approach 1: Database Per Tenant

┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│  Tenant A   │  │  Tenant B   │  │  Tenant C   │
│             │  │             │  │             │
│   DB-A      │  │   DB-B      │  │   DB-C      │
└─────────────┘  └─────────────┘  └─────────────┘

Pros: Maximum isolation, easier compliance Cons: Higher cost, complex management

Approach 2: Schema Per Tenant

┌──────────────────────────────────┐
│         Database Server          │
├──────────────────────────────────┤
│  Schema-A  │ Schema-B │ Schema-C│
└──────────────────────────────────┘

Pros: Good isolation, moderate cost Cons: Schema proliferation

Approach 3: Shared Schema with Row-Level Security

-- Example: PostgreSQL Row-Level Security
CREATE POLICY tenant_isolation ON customer_data
  USING (tenant_id = current_setting('app.current_tenant')::int);

ALTER TABLE customer_data ENABLE ROW LEVEL SECURITY;

Encryption for Tenant Isolation

Tenant-Specific Encryption Keys

┌──────────────────────────────────┐
│     Key Management Service       │
├──────────────────────────────────┤
│  Key-A  │  Key-B  │  Key-C      │
└───┬─────┴────┬────┴────┬─────────┘
    │          │         │
┌───▼──┐   ┌───▼──┐  ┌───▼──┐
│Data-A│   │Data-B│  │Data-C│
└──────┘   └──────┘  └──────┘

Application-Level Isolation

Tenant Context Management

// Example: Express.js middleware
function tenantContext(req, res, next) {
  const tenantId = extractTenantId(req);
  req.tenantId = tenantId;
  
  // Verify tenant access
  if (!hasAccess(req.user, tenantId)) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  
  // Set tenant context for queries
  db.setTenantContext(tenantId);
  next();
}

Testing Isolation

Validation Checklist

• Cross-tenant data access attempts fail
• Tenant-specific encryption keys verified
• Database isolation tested
• API authorization tested
• Penetration testing completed
• Audit logs reviewed

Key Takeaways

1. Multiple isolation strategies exist with different trade-offs
2. Database isolation is critical for security
3. Encryption provides additional protection
4. Application-level controls must enforce isolation
5. Regular testing validates isolation effectiveness

Self-Assessment

1. What are the three main multi-tenant data models?
2. How does row-level security work?
3. Why use tenant-specific encryption keys?
4. What is the highest isolation strategy?
5. How should isolation be tested?