Diseñar multi-tenant security para un SaaS vertical en LATAM se reduce a tres decisiones: RLS en PostgreSQL filtrado por tenant_id, RBAC con 7 a 17 roles según vertical, y audit trail global con hash chain SHA-256 inmutable. En Catalizadora hemos diseñado plataformas multi-tenant operando 100 franquicias internacionales con 17 roles RBAC y zero filtraciones entre tenants en 12 semanas de construcción. Cuando los datos se unifican, los problemas se anuncian solos.
Por qué single database con RLS gana sobre database-per-tenant
Tres razones operativas:
- Operational overhead. Database-per-tenant significa N migrations, N backups, N replicas. A los 50 tenants ya nadie sabe en qué versión está cada base.
- Costos cloud explosivos. Cada DB nueva son 25 USD/mes mínimo. 100 tenants son 2,500 USD/mes solo en bases. Vs single Supabase Pro 25 USD/mes.
- Compliance equivalente con RLS bien hecho. Si RLS está configurado correctamente, el aislamiento lógico es tan fuerte como aislamiento físico para 99% de los reguladores.
Database-per-tenant solo tiene sentido para banca regulada, healthcare con HIPAA o clientes que contractualmente exigen aislamiento físico.
El caso real: 100 franquicias, 17 roles RBAC, 57 RLS policies
Un holding LATAM construyó una plataforma multi-tenant para 100 franquicias internacionales operando en Estados Unidos, Guatemala y Sudamérica. El reto: rollout 12 semanas sin piloto, 9,931 empleados seed, 445 oficinas activas.
Lo que se entregó en arquitectura de seguridad:
- 57 RLS policies activas en PostgreSQL
- 17 roles RBAC configurados (super-admin, tenant-admin, regional-manager, branch-admin, sales-rep, tech, auditor, readonly y variantes)
- 7 roles principales con permisos granulares por módulo (Cross-Sell, AI Sales, Token Credits, Reportería, Enhanced Pest Control)
- Audit trail inmutable con SHA-256 hash chain
- 100 cuentas Stripe Connect (una por franquicia)
- Onboarding 100% automatizado vía Next.js + FastAPI
Inversión total: 26,000 USD fijos. Zero filtraciones detectadas en QA y testing waves.
Stack recomendado para multi-tenant security 2026
| Capa | Tecnología | Razón |
|---|---|---|
| DB | PostgreSQL 17 + RLS | Multi-tenancy nativo a nivel de fila |
| Auth | Supabase Auth o Clerk | JWT con claims de tenant |
| RBAC | Casbin o policies custom | Permisos granulares por rol |
| Audit log | Append-only table + hash chain | Forensicamente verificable |
| Secrets | Vault o Supabase Vault | Per-tenant secrets aislados |
| Observability | Sentry + tags por tenant | Debug por cliente sin filtrar |
Las cinco trampas en multi-tenant security
Errores que cuestan filtraciones en producción:
- Confiar solo en filtros de aplicación. Si tu query es
SELECT * FROM contratos WHERE tenant_id = ?, un bug puede omitir el WHERE. RLS lo rechaza en la base. - No usar
auth.uid()en policies. Hardcodear tenant_id en lugar de extraerlo del JWT es vulnerable a spoofing. - Compartir secrets entre tenants. Stripe webhook secret debe ser único por tenant. Lo mismo para API keys de Twilio, OpenAI, etc.
- Logs sin tenant_id. Cuando un cliente reporta bug, sin tag por tenant en logs estructurados, debugging es imposible sin riesgo de filtrar otro cliente.
- Backups sin separación lógica. Si restauras backup de todos los tenants y un cliente pidió "right to be forgotten", restauras data eliminada y violas LFPDPPP.
Patrón Catalizadora: cómo se ven las RLS policies
Ejemplo de policy real para tabla invoices:
CREATE POLICY invoices_tenant_isolation ON invoices
FOR ALL
USING (tenant_id = (auth.jwt() ->> 'tenant_id')::uuid);
CREATE POLICY invoices_role_admin ON invoices
FOR DELETE
USING (
tenant_id = (auth.jwt() ->> 'tenant_id')::uuid
AND (auth.jwt() ->> 'role') = 'tenant-admin'
);
Cada tabla con datos de tenant tiene mínimo dos policies: una de aislamiento global y una por rol con permisos write/delete.
Cómo arrancar un proyecto multi-tenant seguro en 12 semanas
Plan operativo:
- Semanas 1 y 2: discovery de roles, módulos, permisos. Inventario de datos sensibles.
- Semanas 3 y 4: esquema con tenant_id en cada tabla, RLS policies, RBAC blueprint, audit trail design.
- Semanas 5 a 8: construcción modular, demos semanales, testing de aislamiento entre tenants.
- Semanas 9 y 10: penetration interno, hardening, despliegue paralelo.
- Semanas 11 y 12: capacitación, documentación de threat model, transferencia formal.
Próximos pasos
Si tu SaaS vertical va a operar múltiples clientes con aislamiento estricto y compliance LATAM, agenda una sesión técnica con MAGIA Forge. Doce semanas, multi-tenant security desde el primer commit, código a tu nombre.
Para automatización empresarial multi-locales con RLS, RBAC y dashboards por rol, MAGIA Core es el camino correcto. Sin retainers, sin licencias atadas.