Multi-tenancy y aislamiento de datos

Modelo conceptual

Tenant (Institución)
  ├── Users (alumnos, profesores, coordinadores, admin institucional)
  ├── Courses → Modules → Lessons
  ├── ClassGroups (grupos/clases)
  ├── MediaAssets (biblioteca de medios)
  ├── Automations
  ├── EmailTemplates
  ├── VideoProviderConfig (BBB/Zoom/Teams/Meet)
  ├── TenantApiKey (claves propias de IA)
  ├── TenantSubscription (billing)
  ├── ...todas las demás entidades

Los usuarios sin tenantId son B2C (plataforma directa). Los usuarios con tenantId pertenecen a una institución.

Aislamiento de datos — 3 capas

Capa 1: Filtro obligatorio en queries

Toda query Prisma en el código de aplicación filtra por tenantId:

const { tenantId } = requireTenant(user);
const courses = await prisma.course.findMany({
  where: { tenantId }, // OBLIGATORIO
});

requireTenant() en apps/web/lib/tenant.ts retorna NextResponse 403 si el usuario no tiene tenant. Sin esta llamada, es imposible acceder a datos B2B.

Capa 2: RLS en Supabase

Como red de seguridad contra bugs, las políticas RLS en Supabase refuerzan el aislamiento incluso en queries directas. Si un código olvida el filtro tenantId, la base de datos lo rechaza.

Capa 3: Auditoría de admin global

Cuando un admin global necesita acceder a los datos de un tenant (soporte, debug), utiliza suplantación vía cookie HMAC con:

• TTL fijo de 1h (no prorrogable)
• Firma HMAC-SHA256 con IMPERSONATION_SECRET
• Auditoría en AdminAuditLog (acción impersonate.start, IP, user-agent)
• getUserProfile() retorna isImpersonating: true + overlay en memoria
• La auth de Supabase NUNCA se modifica (solo overlay)
• Banner sticky en /institution/ alerta al admin durante la sesión

El panel admin SaaS global incluye suplantación para soporte.

API keys por tenant

Por defecto, todas las llamadas LLM utilizan las claves globales (ANTHROPIC_API_KEY, OPENAI_API_KEY, etc.) de Studeia. Los costos se imputan al tenant vía metering.

Pero las instituciones que ya tienen cuentas en Anthropic/OpenAI/Google pueden usar sus propias claves (TenantApiKey, cifrada AES-256-GCM en la base de datos):

1. Los costos van DIRECTAMENTE a la cuenta del tenant en Anthropic/OpenAI
2. Studeia no cobra margen de IA — solo la suscripción mensual
3. Resolución automática: TenantApiKey → ProviderApiKey global → process.env (cascada en apps/web/lib/api-key-resolver.ts)

NUNCA se establece process.env en runtime (entraría en conflicto entre tenants) — la clave se pasa vía opciones del SDK.

White-label completo

Cada tenant puede personalizar:

Roles y permisos

Límites por plan

Límites aplicados vía checkTenantResourceLimit(tenantId, resource) en apps/web/lib/plan-limits.ts:

7 puntos de aplicación (todos auditados el 2026-04-11):

1. POST /api/courses/[courseId]/enroll — auto-inscripción del alumno
2. POST /api/institution/courses/[id]/clone — clonar curso
3. POST /api/institution/courses/import — importar IMS CC
4. executeEnrollUser() en automatización
5. POST /api/scim/v2/Users — aprovisionamiento SCIM
6. POST /api/institution/users — vincular usuario existente
7. PATCH /api/institution/users/[id] — promover rol

Cómo solicitar override enterprise

Los tenants enterprise pueden tener Tenant.maxStudentsOverride: Int? ajustado por el admin global. Sin override (null), enterprise = ilimitado. Contacto comercial vía contact@studeia.com.

Limitaciones

• Un User pertenece a UN tenant. Para profesores que atienden múltiples escuelas, crear usuarios separados.
• El intercambio de cursos entre tenants no es nativo (cada tenant tiene su CMS aislado). Roadmap: marketplace de cursos con licenciamiento.
• La migración de un tenant a otro plan es instantánea, pero el downgrade que viola los límites actuales queda bloqueado hasta que el tenant ajuste sus recursos.

Ver también

• White-label
• SSO Enterprise
• Comparativa: Studeia vs Moodle