Security

Tenant Separation Technical Brief

How Vigilense AI implements cryptographic tenant isolation in multi-tenant deployments

Executive Summary

Multi-tenant SaaS platforms face a fundamental challenge: how do you serve multiple customers from shared infrastructure while ensuring absolute data isolation? This technical brief details how Vigilense AI implements defense-in-depth tenant separation across all layers of our architecture.

Isolation Architecture

Our tenant separation model implements isolation at five distinct layers:

Identity Layer

Every request is authenticated and authorized with tenant context. No operation can proceed without verified tenant identity.

Application Layer

Tenant IDs are injected into every query, API call, and operation. Application logic enforces tenant boundaries.

Data Layer

Row-level security, separate schemas, or dedicated databases depending on isolation requirements.

Encryption Layer

Per-tenant encryption keys ensure that even database administrators cannot access other tenants' data.

Network Layer

Network security groups and policies prevent cross-tenant network access.

Compute Layer

Processing isolation ensures one tenant's workloads cannot impact or access another's.

Cryptographic Tenant Isolation

Key Management Architecture

Each tenant has dedicated encryption keys managed through a hierarchical key structure:

  • Master Key: HSM-protected root key (AWS KMS / Azure Key Vault / GCP Cloud KMS)
  • Tenant Key Encryption Key (KEK): Unique per tenant, derived from master key
  • Data Encryption Keys (DEK): Rotated regularly, encrypted by tenant KEK

Key Properties

  • Isolation: Tenant keys are cryptographically isolated compromise of one tenant's key does not affect others
  • Rotation: Automatic key rotation without service interruption
  • Audit: All key access and operations are logged
  • Deletion: Crypto-shredding available delete keys to make data irrecoverable

Encryption Coverage

Data Type Encryption Key Scope
Configuration data AES-256-GCM Per-tenant DEK
Database credentials AES-256-GCM Per-tenant DEK
API keys AES-256-GCM Per-tenant DEK
Alert data AES-256-GCM Per-tenant DEK
Audit logs AES-256-GCM Per-tenant DEK

Database Isolation

Isolation Levels

We offer three database isolation models based on customer requirements:

Row-Level (Standard)

Shared tables with tenant ID columns. Row-level security policies enforce access. Most cost-effective.

Schema-Level (Enhanced)

Separate database schemas per tenant. Stronger isolation with moderate overhead.

Database-Level (Maximum)

Dedicated database instances per tenant. Maximum isolation for high-security requirements.

Query Enforcement

Every database query is automatically scoped to the authenticated tenant:

-- Original query
SELECT * FROM alerts WHERE severity = 'critical';

-- Executed query (tenant context injected)
SELECT * FROM alerts 
WHERE severity = 'critical' 
AND tenant_id = 'tenant_abc123';  -- Automatically added

Network Isolation

Network Architecture

  • VPC Isolation: Each major component runs in isolated VPCs
  • Security Groups: Strict ingress/egress rules per service
  • Private Subnets: Databases and internal services not internet-accessible
  • WAF Protection: Web application firewall on all entry points

Customer Connectivity Options

  • Public Internet: TLS 1.3 encrypted connections (default)
  • VPC Peering: Direct VPC-to-VPC connection
  • PrivateLink: AWS PrivateLink / Azure Private Endpoint
  • VPN: Site-to-site VPN for on-premise connectivity

Compute Isolation

Processing Model

Tenant workloads are isolated at the compute level:

  • Container Isolation: Each tenant's processing runs in dedicated containers
  • Resource Limits: CPU and memory limits prevent noisy neighbor issues
  • Namespace Separation: Kubernetes namespaces with network policies
  • No Shared Memory: Tenants cannot access each other's memory space

Access Control

Authentication

  • Multi-factor authentication (MFA) required
  • SSO integration (SAML 2.0, OIDC)
  • Session management with automatic timeout
  • Device trust and conditional access

Authorization

  • Role-based access control (RBAC)
  • Tenant context in every authorization decision
  • Principle of least privilege
  • Regular access reviews

Audit & Compliance

Audit Logging

Audit logging captures:

  • All authentication events
  • Authorization decisions
  • Data access patterns
  • Configuration changes
  • Administrative actions

Compliance Programs

  • SOC 2 Type II (in progress)
  • ISO 27001 (aligned, certification in progress)
  • GDPR (in progress)
  • CCPA (in progress)

Testing & Validation

Security Testing

  • Penetration Testing: Annual third-party penetration tests specifically targeting tenant isolation
  • Automated Testing: Continuous integration tests validate tenant boundaries
  • Chaos Engineering: Fault injection to verify isolation under failure conditions
  • Code Review: Security-focused code review for all changes

Request Security Documentation

Enterprise customers can request detailed security documentation including:

  • SOC 2 Type II audit report (available upon completion of certification)
  • Penetration test executive summary
  • Architecture diagrams
  • Completed security questionnaires

Contact our security team to request documentation.