RBAC como "Medida de Seguridad Apropiada" de la Ley 21.719
La Ley 21.719 obliga a aplicar "medidas de seguridad apropiadas al riesgo" para proteger datos personales, sin especificar cuáles — deja la certificación técnica a criterio de cada empresa. Un sistema que no filtra por rol no tiene un bug de relevancia: tiene un agujero de control de acceso, exactamente el tipo de brecha que la ley exige prevenir. RBAC por capas es la respuesta verificable, no una certificación que se compra.
El Problema Real
"Medidas de Seguridad Apropiadas" no Viene con Checklist
La Ley 21.719 exige proteger los datos personales con medidas de seguridad apropiadas al riesgo, pero no define un estándar técnico único — a diferencia de otros requisitos de la misma ley (plazos ARCO+, notificación de brechas en 72h), acá la exigencia es de resultado, no de procedimiento. Eso deja a cada empresa la responsabilidad de poder demostrar, si la Agencia de Protección de Datos lo pide, que su arquitectura efectivamente aísla la información por quién tiene derecho a verla.
Un sistema que no filtra por rol no tiene un bug de relevancia: tiene un agujero de control de acceso, y es exactamente el tipo de brecha que la ley busca prevenir: fuga de información entre áreas o niveles jerárquicos que pasa por la capa de acceso, no por permisos de archivo mal configurados. Control de Acceso Basado en Roles (RBAC) es el nombre técnico de la solución, pero el diseño real es más específico que "asignar roles": es una arquitectura completa de scopes de ruta, paquetes de privilegios y relación con el recurso.
Arquitectura
RBAC Parte Desde la Ruta (el Endpoint), no Desde el Rol
Antes de preguntar "¿qué rol tiene este usuario?", el sistema pregunta algo más básico: ¿qué tipo de ruta — de endpoint — es esta: pública, privada, de sistema? Esa clasificación decide si la petición siquiera llega a evaluarse por rol. Es la misma arquitectura que usamos en cualquier sistema multitenant (multi empresa) propio, no una capa agregada después, sino parte del diseño desde el modelo de datos.
| Scope de ruta (endpoint) | Requiere | Uso |
|---|---|---|
| Público | Ninguno | GET abierto: login, healthcheck, contenido sin restricción |
| Público de escritura | Ninguno, con firma HMAC propia | POST abierto sin sesión (webhooks) — el nombre no implica validación, esa es responsabilidad del handler |
| Privado | Sesión autenticada | Cualquier usuario logueado, sin filtro fino todavía |
| Lectura filtrada | Sesión + rol con permiso de lectura | Resultados acotados por rol |
| Escritura | Sesión + rol con permiso de escritura | Crear, modificar o eliminar registros |
| Sistema | Clave de sistema o red interna | Comunicación servidor-a-servidor, nunca expuesto a usuarios (peso más alto: siempre denegado desde el front) |
Estos 6 scopes deciden si la ruta responde o no, antes de que exista ningún rol que evaluar — pública y de sistema ni siquiera llegan a esa pregunta. Es un eje independiente de con qué entidad tiene relación el usuario: un mismo rol de "lectura filtrada" da acceso a datos distintos según esa relación activa (multitenant real), dos usuarios con idéntico rol ven resultados disjuntos si están atados a entidades distintas. Mezclar ambos ejes en una sola escala es el error técnico más común al describir RBAC multitenant.
Una vez que la ruta deja pasar, entran 3 capas más
El scope de ruta es el primer filtro, no el único — dentro de una ruta ya accesible, todavía queda por resolver qué ve y qué puede hacer cada usuario.
3 Capas de RBAC
Route Permissions (acceso al endpoint completo, más fino que el scope de ruta), Categories (qué ve en la navegación), Roles/Flags (qué puede hacer dentro de un endpoint ya accesible). Tres preguntas distintas, tres capas distintas.
Organigrama → Paquete → Rol
Cada posición del organigrama de la empresa resuelve un paquete de privilegios. El paquete se aplica sobre el perfil del colaborador — nunca un rol suelto, siempre atado a una posición real. Deep dive del flujo completo multi empresa →
Grafo Antes que Roles
Un rol nunca cuelga suelto: primero existe la relación (grafo) entre el perfil y la entidad, recién ahí se aplica el paquete de privilegios sobre esa relación. Sin grafo, el perfil queda huérfano.
Stateless, con Caché en Memoria
El Set de Permisos no se Recalcula en Cada Consulta
Al aplicar un paquete de privilegios, el perfil guarda un snapshot ya materializado — el mismo principio aditivo que un sistema de permisos tipo Unix. El lookup es eficiente porque el sistema lee ese snapshot, no recalcula el permiso efectivo consultando el paquete original en cada request.
Cambios futuros al paquete no se propagan solos: necesitan un resync explícito, así un cambio de política no rompe accesos ya otorgados sin control. Bajo alto consumo, esta resolución se acompaña de caché en memoria (para runtimes de vida corta como PHP-FPM, un worker Python o una función serverless) o un backend persistente compartido cuando el proceso mantiene estado (Swoole, o su equivalente en Node o Rust) — la arquitectura stateless no significa recalcular todo desde cero en cada request, significa que ningún request depende de que el anterior haya pasado por el mismo proceso. Cómo funciona esa capa de caché →
Implementación
El Control de Acceso se Diseña con el Modelo de Datos, no Después
Roles, paquetes y relaciones (grafo) viven en la misma capa que el resto del modelo de datos, no una capa aparte agregada cuando el sistema ya está funcionando. Diseñar el control de acceso después es la forma más común de terminar con un agujero: alguien construye el sistema, alguien más "le agrega permisos" al final, y las dos capas nunca terminan de calzar del todo. Es la misma arquitectura de fondo detrás de cualquier sistema que necesite demostrar aislamiento de datos por rol — desde un ERP interno hasta la gestión documental regulada de un dominio como SST — y es el argumento técnico que sostiene la casilla "medidas de seguridad apropiadas" de la Ley 21.719 sin depender de una certificación externa.
Contenido relacionado
RBAC Multitenant: Organigrama → Paquete → Rol
El mecanismo completo verificado contra código y esquema real: grafo antes que roles, snapshot tipo Unix, y cómo una cuenta tiene varias "caras" según el tenant.
Leer el mecanismo - Grafo, Snapshot y Multi-PerfilProtección de Datos Personales para Empresas (Ley 21.719)
El checklist completo de la ley — RBAC responde el punto 4 (medidas de seguridad apropiadas), este reporte cubre los otros 6.
Ver el checklist - Checklist Real de 7 EntregablesGestión Documental SST bajo DS44
El nivel de acreditación de un colaborador modelado como rol, no como metadato — la misma arquitectura aplicada a un dominio regulado.
Leer análisis - DS44 · Niveles de AcreditaciónCorreo Corporativo y Cumplimiento Normativo
Otra capa del mismo problema: quién puede acceder a qué correo, con cifrado y control propio en vez de confiar en un tercero.
Leer análisis - Caso: Investigación Clínica