claude-plugins/negocio/skills/saas/references/multi-tenancy.md

SaaS - Arquitectura Multi-tenant

Estrategias de Isolamento

1. Database per Tenant (Isolamento Maximo)

• Pros: Seguranca total, restore independente
• Contras: Custo, complexidade gestao
• Usar quando: Enterprise, regulamentacoes
• Exemplo: AWS RDS + Aurora Serverless

2. Schema per Tenant (Equilibrio)

• Pros: Bom isolamento, gestao simplificada
• Contras: Limites BD (PostgreSQL ~10k schemas)
• Usar quando: B2B medio porte
• Exemplo: PostgreSQL schemas dinamicos

3. Shared DB + Row-Level Security (Economico)

• Pros: Mais barato, facil escalar
• Contras: tenant_id em tudo, RLS obrigatorio
• Usar quando: B2C, SMB self-service
• Exemplo: PostgreSQL RLS policies

Implementacao Row-Level Security (PostgreSQL)

-- 1. Adicionar tenant_id a todas as tabelas
ALTER TABLE users ADD COLUMN tenant_id UUID NOT NULL;
ALTER TABLE projects ADD COLUMN tenant_id UUID NOT NULL;
ALTER TABLE documents ADD COLUMN tenant_id UUID NOT NULL;

-- 2. Activar RLS
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

-- 3. Criar policy de isolamento
CREATE POLICY tenant_isolation ON users
    USING (tenant_id = current_setting('app.tenant_id')::uuid);

CREATE POLICY tenant_isolation ON projects
    USING (tenant_id = current_setting('app.tenant_id')::uuid);

-- 4. No inicio de cada request (backend)
-- SET app.tenant_id = 'uuid-do-tenant-autenticado';

Checklist Seguranca Multi-tenant

[ ] tenant_id em TODAS as tabelas
[ ] RLS policies activas
[ ] Indexes em tenant_id (performance)
[ ] Validacao tenant_id no auth middleware
[ ] Logs de acesso cross-tenant
[ ] Testes de isolamento (tenant A nao ve tenant B)