Tenant status lifecycle states
Define TenantStatus enum with values: PROVISIONING (initial state during setup), ACTIVE (ready for use), SUSPENDED (temporarily disabled), OFFBOARDING (undergoing removal), DELETED (permanently removed).
OWASP Cheat Sheets · all subjects
tenant_lifecycle
6 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Secure tenant provisioning process
Provisioning workflow: 1) Create tenant record with PROVISIONING status, 2) Create isolated database schema (tenant_{sanitized_id}), 3) Apply schema migrations, 4) Generate API key (return once only, never store plain text, store only SHA256 hash), 5) Create storage prefix, 6) For BUSINESS/ENTERPRISE: provision tenant-specific KMS key, 7) Update status to ACTIVE. Log all steps in audit trail.
Generate cryptographically secure tenant IDs and API keys
Use secrets.token_urlsafe(16) for tenant IDs and secrets.token_urlsafe(32) for API keys. Store only SHA256 hash of API keys, never plain text.
Tenant offboarding with data retention period
Offboarding workflow: 1) Mark tenant as OFFBOARDING status (prevents new operations), 2) Revoke all active sessions and API keys, 3) Export tenant data for compliance/portability, 4) Schedule data deletion after retention period (default 30 days). Return export location and scheduled deletion date.
Tenant permanent deletion steps
Execute deletion: 1) Drop database schema with CASCADE (or for shared tables, DELETE FROM WHERE tenant_id), 2) Invalidate all cached data using cache.invalidate_tenant(), 3) Delete all stored files using storage.delete_tenant_data(), 4) Delete tenant-specific encryption keys, 5) Mark as DELETED in database (retain minimal audit record).
Do not retain tenant data indefinitely after offboarding
Implement scheduled deletion of tenant data after offboarding. Default retention period should be 30 days. Delete within defined retention window to comply with privacy regulations.