Tema 9
La autorización necesita una estructura. Los modelos de control de acceso ofrecen distintas maneras de organizar permisos y políticas según el tipo de sistema, el nivel de riesgo y la complejidad del dominio. Ninguno es universalmente mejor: cada uno resuelve ciertos problemas y se vuelve incómodo o insuficiente en otros.
Una vez entendido qué es autorización, aparece una pregunta práctica: ¿cómo organizamos las reglas para que el sistema las pueda aplicar de forma consistente? Ahí entran los modelos de control de acceso.
Estos modelos no son protocolos ni productos. Son formas de estructurar decisiones de autorización. Algunos ponen el foco en el dueño del recurso, otros en clasificaciones rígidas, otros en roles organizacionales, atributos dinámicos o relaciones entre sujetos y objetos.
En la práctica, muchos sistemas combinan más de un modelo. El objetivo no es memorizar siglas, sino entender qué problema resuelve cada enfoque y qué costos introduce.
Sin un modelo, la autorización suele convertirse en una colección informal de ifs, flags, excepciones y casos especiales distribuidos en toda la aplicación. Eso escala mal, es difícil de auditar y casi siempre termina generando inconsistencias.
Un modelo de acceso sirve para:
Elegir el modelo equivocado no impide necesariamente que el sistema funcione, pero suele volverlo innecesariamente rígido o caótico.
Los modelos más mencionados en este ámbito suelen ser:
Algunos son más tradicionales y nacieron en sistemas operativos o entornos gubernamentales. Otros tienen especial relevancia en aplicaciones modernas, SaaS, plataformas colaborativas y APIs distribuidas.
En DAC, el acceso depende principalmente del propietario o titular del recurso, que puede decidir quién accede y con qué nivel. Es un modelo intuitivo y muy común en sistemas donde los recursos tienen dueño claro.
Ejemplos típicos son archivos compartidos, documentos colaborativos o carpetas donde el creador decide con quién comparte lectura o edición.
Su principal ventaja es la flexibilidad. Su principal problema es que, si se usa sin límites, puede derivar en una proliferación de permisos individuales difíciles de gobernar.
DAC funciona bien cuando:
Se vuelve más problemático cuando:
En otras palabras, DAC ofrece mucha autonomía, pero esa misma autonomía puede chocar con políticas corporativas o regulatorias.
En MAC, las reglas no dependen de la voluntad del usuario propietario, sino de una política central obligatoria. El acceso suele estar determinado por niveles de clasificación, etiquetas de seguridad y reglas estrictas definidas por la organización o el sistema.
Este modelo es clásico en entornos militares, gubernamentales o de alta sensibilidad, donde los recursos y sujetos tienen clasificaciones formales y no se permite delegación libre.
La lógica típica no es “el dueño decide”, sino “la política central determina qué niveles pueden acceder a qué datos”.
MAC ofrece control central muy fuerte y reduce arbitrariedad. Es útil cuando la protección de la información exige reglas inflexibles y consistentes.
Sus límites son evidentes en entornos más dinámicos:
Por eso, aunque es un modelo importante conceptualmente, no suele ser la elección natural para la mayoría de los productos SaaS o aplicaciones empresariales modernas.
RBAC probablemente sea el modelo más conocido en aplicaciones corporativas. La idea es asignar permisos a roles y luego asignar roles a usuarios. En lugar de administrar permisos uno por uno para cada persona, se define qué puede hacer un “administrador”, un “supervisor”, un “operador” o un “analista”.
Este enfoque simplifica mucho la administración cuando la organización tiene funciones relativamente estables y repetibles.
Ejemplos típicos:
RBAC es popular por buenas razones:
También ayuda en auditorías porque resulta más simple revisar roles que miles de permisos individuales dispersos.
RBAC empieza a mostrar tensión cuando las reglas dependen demasiado de contexto, atributos o relaciones. Entonces aparecen explosiones de roles: decenas o cientos de variantes para cubrir combinaciones específicas.
Por ejemplo, si hace falta distinguir por sede, tenant, horario, jerarquía y tipo de recurso, el modelo puede volverse difícil de sostener solo con roles. Allí empiezan a surgir nombres como “SupervisorRegionalLecturaParcial”, una señal bastante clara de que el enfoque está siendo forzado.
ABAC decide acceso a partir de atributos del sujeto, del recurso, de la acción y del contexto. En lugar de depender exclusivamente de un rol fijo, evalúa propiedades dinámicas y reglas más expresivas.
Por ejemplo:
ABAC permite modelar decisiones más finas y adaptadas al contexto real del sistema.
Las fortalezas de ABAC son claras:
Sus desafíos también son importantes:
ABAC puede ser muy potente, pero mal diseñado termina siendo opaco y difícil de operar.
ReBAC decide acceso a partir de relaciones entre sujetos y recursos. En lugar de preguntar solo por rol o atributo, pregunta qué vínculo existe entre las partes.
Ejemplos típicos:
Este modelo resulta especialmente útil en plataformas colaborativas, sistemas sociales, entornos multi-tenant complejos y dominios donde las relaciones importan más que los roles generales.
ReBAC es muy valioso cuando el acceso depende del grafo de relaciones entre entidades. Permite expresar políticas naturales para entornos modernos donde pertenencia, ownership y vínculos directos o indirectos son centrales.
Su principal dificultad está en la complejidad operativa y de evaluación. Mantener y consultar relaciones de forma eficiente puede ser costoso, especialmente cuando el grafo crece o las decisiones requieren navegación profunda.
| Modelo | Idea central | Ventaja principal | Límite típico |
|---|---|---|---|
| DAC | El dueño del recurso decide | Flexibilidad y colaboración | Gobernanza débil si crece sin control |
| MAC | La política central obliga | Control rígido y consistente | Poca flexibilidad |
| RBAC | Los permisos se agrupan por roles | Simplicidad administrativa | Explosión de roles ante mucha variación |
| ABAC | La decisión depende de atributos | Gran expresividad contextual | Mayor complejidad de diseño y explicación |
| ReBAC | La decisión depende de relaciones | Muy natural para colaboración y ownership | Gestión y evaluación del grafo más complejas |
En la práctica, muchos sistemas no implementan un único modelo de forma pura. Es habitual ver combinaciones:
Este enfoque híbrido suele ser más realista, pero exige disciplina. Si se combinan modelos sin claridad, el resultado puede ser más confuso que útil.
No hay una receta universal, pero pueden trazarse algunas orientaciones:
Lo importante es no elegir por moda. Debe elegirse por adecuación al dominio, al riesgo y a la capacidad operativa del equipo.
Elegir un modelo de control de acceso es una decisión arquitectónica importante. Define cómo se representarán los permisos, cómo se mantendrán en el tiempo y qué tan fácil será explicar, auditar y evolucionar las decisiones de autorización. Un modelo bien elegido simplifica; uno mal elegido obliga a pelear contra la propia estructura del sistema.
En el próximo tema veremos cómo estos modelos se conectan con principios de mínimo privilegio, segregación de funciones y acceso just-in-time.