Al empezar un proyecto parece que habrá dos roles: «admin» y «usuario». Seis meses después llegan comerciales, contables, socios externos y clientes con acceso a sus datos, y los permisos empiezan a escribirse en el código caso por caso. Así nacen las vulnerabilidades y los errores. Merece la pena diseñar el modelo de acceso desde el principio; es una de las tareas básicas del desarrollo de aplicaciones web.
En resumen: separa dos ejes: a qué datos accede el usuario (tenant, organización, proyecto) y qué acciones puede hacer (rol y permisos). Comprueba los permisos en el servidor en cada petición y registra las acciones importantes.
Multi-tenant: de quién son los datos
Si distintas empresas usan el producto, los datos de cada una deben estar aislados. Enfoques principales:
| Enfoque | Cómo funciona | Cuándo encaja |
|---|---|---|
| Base compartida con ID de tenant | Cada registro lleva el ID de la organización | La mayoría de SaaS, arranque rápido |
| Esquema por tenant | Tablas propias para cada cliente | Mayor exigencia de aislamiento |
| Base de datos por tenant | Aislamiento total | Grandes clientes, requisitos regulatorios |
Modelos de permisos
- RBAC (por roles): roles con conjuntos de permisos: propietario, admin, gestor, lector. Sencillo y claro.
- Permisos por recurso: ver, crear, editar, borrar por sección; más flexible, ideal para CRM y back office.
- Reglas por atributos (ABAC): el acceso depende de propiedades, como «el comercial ve solo sus tratos». Potente, pero más difícil de mantener.
Qué incluir desde el primer día
- ID de organización en cada tabla de negocio.
- Comprobación de permisos en el servidor, no solo botones ocultos.
- Invitaciones con rol y enlace que caduca.
- Registro de auditoría: quién cambió qué y cuándo.
- Permisos específicos para exportar y borrar datos.
Errores habituales
- Permisos comprobados solo en el frontend: la API queda abierta a cualquier usuario autenticado.
- ID de registros secuenciales sin comprobar a qué organización pertenecen.
- Roles fijados en el código sin poder configurarse.
- Sin registro de acciones: imposible investigar incidentes.
Preguntas frecuentes
¿Se puede añadir multi-tenant más adelante?
Sí, pero cuesta: migrar datos y reescribir consultas. Si el producto va a servir a varias empresas, inclúyelo desde el inicio.
¿Necesito inicio de sesión único (SSO)?
A menudo para clientes corporativos, pero puede esperar en el MVP. Consulta nuestro artículo sobre prioridades del MVP SaaS.
¿Qué relación tiene con el CRM?
Los permisos por recurso son la columna vertebral de cualquier CRM: los comerciales ven sus tratos y los responsables, el departamento. Usamos el mismo modelo en sistemas CRM/ERP y conectamos datos de otros servicios mediante API.
¿Diseñas un producto con roles y áreas de cliente? Envía tu solicitud en la página de aplicaciones web: diseñaremos el modelo de datos, acceso y auditoría antes de empezar a desarrollar.