Control de Acceso Basado en Roles (RBAC): el acceso sigue al puesto

El modelo que de verdad opera la empresa

Dos artículos plantearon una brecha. DAC deja a los dueños compartir libremente, lo que no escala y no se puede gobernar. MAC impone etiquetas rígidas, lo que es demasiado inflexible para operar una empresa día a día. Ninguno responde la pregunta que una organización real de hecho hace: “esta persona trabaja en soporte — dale lo que la gente de soporte recibe.” El acceso debería seguir lo que la gente hace, no quién es dueño de un archivo ni cómo se clasifica un documento. El modelo que hace esto — y que gobierna el acceso en la abrumadora mayoría de las empresas — es el Control de Acceso Basado en Roles (RBAC).

La idea central es una sola y poderosa capa de indirección. En lugar de conceder permisos a usuarios, concedes permisos a roles, y asignas usuarios a roles. Un rol es un paquete con nombre de permisos que corresponde a una función laboral: “Agente de Soporte”, “Auditor”, “Almacenista”, “Admin de Facturación”. Cuando Daniel entra a soporte, le asignas el rol “Agente de Soporte” y al instante tiene exactamente lo que soporte necesita. Cuando se mueve a finanzas, cambias el rol. Nadie edita miles de concesiones individuales; gestionas el conjunto mucho más pequeño de pertenencias a roles. Esa indirección es toda la razón por la que RBAC escala donde DAC no.

RBAC no es folclore — es un estándar formal. NIST propuso el modelo de referencia en 2000, y se convirtió en el Estándar Nacional Americano INCITS 359. Entender ese modelo con precisión es lo que separa “tenemos algunos grupos” del verdadero acceso basado en roles, así que lo construiremos pieza por pieza.

Una breve historia

Agrupar el acceso por puesto es antiguo, pero RBAC como modelo se cristalizó en un artículo de 1992 de David Ferraiolo y Richard Kuhn en NIST, que argumentó que la mayoría de las organizaciones no militares no hacían ni DAC puro ni MAC sino algo intermedio — asignar acceso por rol organizacional — y que eso merecía ser un modelo de primera clase. A lo largo de los años noventa la idea maduró, culminando en el modelo de referencia de NIST de 2000 y el estándar INCITS 359 de 2004, luego revisado. Ese linaje importa por una razón práctica: como RBAC está estandarizado, “RBAC” significa algo específico, y puedes contrastar la afirmación “basado en roles” de un proveedor con una definición real en vez de con una capa de marketing. Cuando alguien dice que su producto hace RBAC, los niveles de abajo son la lista de verificación.

Los tres elementos y las dos asignaciones

Reduce RBAC a sus huesos y hay tres tipos de cosa y dos relaciones entre ellas.

Los usuarios son las personas (o, cada vez más, las cargas de trabajo). Los permisos son las cosas que puedes hacer a los objetos — “leer factura”, “borrar usuario”, “aprobar reembolso”. Nota que un permiso es en sí un par: una operación (leer, borrar, aprobar) aplicada a un objeto (factura, usuario, reembolso). Acertar con esta granularidad es sutil — demasiado gruesa (“acceder a facturación”) y los roles no pueden hacer cumplir el mínimo privilegio; demasiado fina (“leer el campo 7 de la factura 402”) y el conjunto de permisos se vuelve inmanejable. Los roles se sitúan entre usuarios y permisos. Luego dos asignaciones lo conectan todo: la asignación usuario-a-rol (Daniel es Agente de Soporte) y la asignación permiso-a-rol (el Agente de Soporte puede leer tickets y emitir reembolsos hasta un límite). El acceso efectivo de un usuario es la unión de los permisos de todos los roles que se le asignan.

La columna derecha es por qué las organizaciones con más de un puñado de personas convergen en RBAC. Convierte la gestión de acceso de un problema O(usuarios × recursos) en un problema O(roles), y los roles cambian mucho más lentamente que los usuarios o los recursos.

Hay un beneficio más sutil escondido en esa última fila. Como el acceso de un puesto se define en un solo lugar, RBAC hace el acceso describible: puedes entregar a un nuevo gerente la lista de roles que tiene su equipo y de verdad la puede entender, algo que ninguna pila de ACL por objeto permite. Esa legibilidad no es un adorno cosmético — es lo que hace posibles las revisiones de acceso, las auditorías y las decisiones de mínimo privilegio para que los humanos las realicen. Un modelo cuyo estado una persona puede tener en la cabeza es un modelo cuyos errores una persona puede detectar, y mucho de la permanencia de RBAC viene de ser comprensible, no solo compacto.

El modelo NIST: cuatro niveles de RBAC

El estándar define RBAC como un conjunto de capacidades anidadas, cada una añadiendo poder. Conocer los niveles te da vocabulario para decir exactamente cuán sofisticado es en realidad el RBAC de un sistema dado.

El RBAC núcleo (core) es la base recién descrita: usuarios, roles, permisos y las dos asignaciones, más las sesiones (abajo). Todo lo demás se construye sobre él.

El RBAC jerárquico añade jerarquías de roles: los roles superiores heredan los permisos de los inferiores. Define “Empleado” con el acceso que todos necesitan; deja que “Ingeniero” herede Empleado y añada permisos de ingeniería; deja que “Ingeniero Senior” herede Ingeniero. Especificas el acceso compartido una sola vez, y la jerarquía refleja el organigrama. Aquí es donde RBAC empieza a sentirse elegante — y también donde un permiso añadido descuidadamente a “Empleado” alcanza silenciosamente a todos los humanos de la empresa.

Dos precauciones hacen seguras las jerarquías. Primera, la herencia corre hacia arriba: un permiso añadido a un rol inferior fluye a todos los roles superiores por encima de él, así que el rol base “Empleado” debe permanecer deliberadamente mínimo — es el radio de explosión de toda la empresa. Segunda, resiste modelar la antigüedad y la función en el mismo eje; un “Ingeniero Senior” que hereda “Ingeniero” es limpio, pero forzar a “Ingeniero” a heredar “Agente de Soporte” porque ambos son “personal” mezcla conjuntos de permisos no relacionados y es un camino rápido a la explosión de roles de abajo. Las jerarquías deberían expresar genuinas relaciones de “es-una-versión-más-privilegiada-de”, no proximidad organizacional.

El RBAC restringido (constrained) añade restricciones de separación de deberes (la siguiente sección) y a menudo restricciones de cardinalidad — límites como “a lo sumo dos personas pueden tener el rol Admin de Dominio” o “este rol puede asignarse a no más de N usuarios”. La cardinalidad es un control silencioso pero poderoso: limitar la pertenencia de tus roles más peligrosos acota el radio de explosión directamente y fuerza una compensación deliberada cada vez que alguien nuevo necesita ese poder. El RBAC simétrico añade la revisión permiso-rol — la capacidad de preguntar eficientemente “¿quién tiene este permiso, y a través de qué roles?” — que es la auditabilidad que hace gobernable a RBAC. La mayoría de los sistemas empresariales implementan núcleo más jerárquico más algo de RBAC restringido; la revisión simétrica completa es la marca de un programa maduro de gobernanza de identidades.

flowchart LR
  accTitle: Estructura del Control de Acceso Basado en Roles con una jerarquía de roles
  accDescr: A la izquierda están los usuarios Sara, Daniel y David. Cada usuario se asigna a uno o más roles en el medio: Sara a Ingeniero Senior, Daniel a Agente de Soporte, David a Admin de Facturación. Se muestra una jerarquía de roles donde Ingeniero Senior hereda de Ingeniero, que hereda de un rol base Empleado que todos los roles incluyen. A la derecha están los permisos. Cada rol se conecta a los permisos que tiene: Empleado a leer-directorio, Ingeniero a desplegar-servicio, Agente de Soporte a leer-ticket y emitir-reembolso, Admin de Facturación a editar-factura. Las flechas fluyen de los usuarios a través de los roles hacia los permisos, ilustrando que el acceso se concede indirectamente por la pertenencia a roles en vez de directamente a los usuarios.
  U1[Sara] --> R3[Ingeniero Senior]
  U2[Daniel] --> R4[Agente de Soporte]
  U3[David] --> R5[Admin de Facturación]
  R3 -->|hereda| R2[Ingeniero]
  R2 -->|hereda| R1[Empleado]
  R1 --> P1[leer-directorio]
  R2 --> P2[desplegar-servicio]
  R4 --> P3[leer-ticket]
  R4 --> P4[emitir-reembolso]
  R5 --> P5[editar-factura]

Separación de deberes: codificar “no la misma persona”

Algunas combinaciones de acceso son peligrosas no individualmente sino juntas. La persona que puede crear un pago no debería también aprobarlo; la que puede solicitar un cambio no debería también desplegarlo. Esto es la separación de deberes (SoD), el principio contable centenario de que las acciones críticas requieren más de una mano, y RBAC es donde los sistemas de identidad la codifican.

La SoD estática prohíbe la asignación conflictiva: un usuario simplemente no puede recibir a la vez los roles “Crear Pago” y “Aprobar Pago”, punto. Se hace cumplir en el momento de la asignación y es el control más fuerte y limpio. La SoD dinámica es más permisiva: un usuario puede tener ambos roles pero no activar ambos en la misma sesión, así que una persona que legítimamente lleva dos sombreros debe cambiar de contexto conscientemente — útil para equipos pequeños donde una persona genuinamente cubre dos funciones pero no debe hacer ambas a una sola transacción. La SoD es la razón concreta por la que RBAC incluye siquiera la noción de sesiones y roles activados: el mínimo privilegio no es solo qué roles tienes, sino cuáles estás usando ahora mismo.

Sesiones y mínimo privilegio

La sesión de RBAC es el puente entre los roles que un usuario tiene y los roles que está usando. Cuando Sara inicia una sesión puede activar algunos o todos sus roles asignados; los permisos disponibles en esa sesión son solo los de los roles activados. Esto permite que un usuario poderoso trabaje la mayor parte del tiempo con un rol mínimo y active un rol administrativo solo cuando lo necesita — la expresión RBAC del mínimo privilegio en el tiempo, no solo en el alcance. Es el mismo instinto detrás de “no navegues la web como root” y detrás de la elevación de privilegios justo a tiempo en el PAM moderno: ten el poder, pero no lo lleves activado en todo momento. Un rol que no estás usando actualmente es un rol que un atacante que caiga en tu sesión no puede abusar de inmediato.

RBAC en la práctica

RBAC no es un producto; es la forma del acceso en casi todo sistema serio. Los grupos de Active Directory / LDAP son la implementación empresarial clásica — las pertenencias a grupos de un usuario son sus roles, y los recursos conceden acceso a grupos. El IAM en la nube es RBAC hasta la médula: los roles y políticas gestionadas de AWS IAM, las asignaciones de rol de Azure RBAC sobre alcances, y los roles de Google Cloud IAM agrupan permisos y los asignan a identidades. El RBAC de Kubernetes gobierna el clúster con objetos Role/ClusterRole vinculados a sujetos vía RoleBindings — el mismo triángulo usuarios-roles-permisos, expresado en YAML. Y prácticamente toda aplicación SaaS trae un modelo de roles “Admin / Miembro / Visor”, que es RBAC en su forma más mínima.

Reconocer el patrón a través de todos estos es el rédito práctico del modelo abstracto: una vez que ves usuarios-roles-permisos, un ClusterRoleBinding de Kubernetes y una asignación de rol de Azure y un grupo de AD dejan de ser tres sistemas no relacionados y se vuelven tres dialectos de un lenguaje que ya hablas.

Hecho concreto, el dialecto de Kubernetes se lee casi como el modelo deletreado:

# Un Role = un paquete de permisos (verbos sobre recursos)
kind: Role
metadata: { namespace: support, name: ticket-reader }
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list"]      # las operaciones
---
# Un RoleBinding = una asignación usuario-a-rol
kind: RoleBinding
metadata: { namespace: support, name: daniel-ticket-reader }
subjects:
  - kind: User
    name: daniel               # el usuario
roleRef:
  kind: Role
  name: ticket-reader          # el rol

El Role es la asignación permiso-a-rol (verbos sobre recursos); el RoleBinding es la asignación usuario-a-rol (un sujeto vinculado a un rol). Deliberadamente no hay forma de conceder un verbo directamente a Daniel — Kubernetes fuerza cada concesión a través de un rol, que es RBAC núcleo impuesto por la propia plataforma. Lee un rol de AWS IAM o una asignación de rol de Azure y encontrarás las mismas dos uniones con nombres distintos.

Cómo se asignan los roles: birthright y reglas

Un detalle que confunde a los novatos: RBAC dice que el acceso fluye a través de roles, pero no dice por sí mismo cómo un usuario obtiene un rol. En sistemas pequeños un administrador los asigna a mano. A escala, la asignación se automatiza con reglas de birthright (derecho de nacimiento) — “todos en el departamento de Ventas reciben automáticamente el rol Ventas-Base” — evaluadas a partir de atributos de RRHH como departamento, ubicación y código de puesto. Entra ID los llama grupos dinámicos; otras plataformas los llaman reglas de asignación o políticas de acceso. Nota la sutileza: aquí se usan atributos para decidir la pertenencia a roles, mientras que los roles siguen portando los permisos. Esto mantiene intacta la capa auditable de roles — todavía puedes preguntar “¿quién es miembro de Ventas-Base y por qué?” — a la vez que elimina el trabajo manual de asignación. Es el primer lugar donde atributos y roles cooperan, y un anticipo del modelo híbrido de abajo.

Ingeniería de roles: donde de verdad vive la dificultad

El mecanismo de RBAC es simple; decidir cuáles deberían ser los roles es la parte difícil, y tiene nombre: ingeniería de roles. Hay dos enfoques amplios, usualmente combinados. De arriba hacia abajo (top-down) parte del negocio: entrevistar departamentos, modelar funciones laborales y definir roles que reflejen cómo la organización de verdad funciona. Produce roles significativos y bien nombrados pero es lento y puede pasar por alto la realidad desordenada de quién de verdad necesita qué. De abajo hacia arriba (bottom-up) (también llamado minería de roles) parte de los datos de acceso existentes: analizar los permisos que la gente tiene actualmente y agruparlos estadísticamente en roles candidatos. Es rápido y anclado en la realidad pero puede codificar errores existentes (“todos ya tienen esto, así que debe ser un rol”) y produce roles que necesitan nombres de negocio adjuntos.

Los programas maduros hacen ambos: minar el acceso actual para descubrir roles candidatos, luego refinar de arriba hacia abajo para que cada rol mapee a una función laboral real con un dueño responsable de su contenido. Acertar con esto es la mayor parte del trabajo de un programa de gobernanza de identidades, y equivocarse produce el modo de fallo que todos en el campo han visto.

Explosión de roles: el fallo característico de RBAC

La gran debilidad de RBAC es una consecuencia directa de su gran fortaleza. Como un rol es un paquete fijo de permisos, cualquier variación en la necesidad te tienta a crear otro rol. Sara necesita todo lo que tiene un Ingeniero pero también acceso de lectura a un informe de finanzas; ¿creas un rol “Ingeniero-más-informe-de-finanzas”? Hazlo suficientes veces y obtienes explosión de roles: más roles que usuarios, un catálogo que nadie entiende, y revisiones de acceso que no significan nada porque los roles ya no corresponden a puestos comprensibles. Has recreado la dispersión por usuario de DAC, solo que un nivel más arriba.

La causa raíz es que los roles son ciegos al contexto. Un rol no puede decir “leer informes de finanzas pero solo los de tu propia región durante el horario laboral”. En el momento en que el acceso depende de una condición — hora, ubicación, la relación entre el usuario y el recurso específico, una puntuación de riesgo — la única herramienta de RBAC es hornear otro rol por cada combinación, y las combinaciones se multiplican. Esto no es un fallo que puedas configurar para que desaparezca; es la frontera del modelo. El acceso que depende de atributos y contexto quiere un modelo distinto, y ese modelo es el tema del siguiente artículo.

Antipatrones para reconocer a simple vista

La explosión de roles es el fallo famoso, pero un puñado de otros aparecen tan a menudo que vale la pena nombrarlos para que los detectes en una revisión. El rol dios es un único rol “Admin” que acumula cada permiso poderoso porque es más fácil añadirle que diseñar bien — la antítesis del mínimo privilegio, y lo primero que hereda un atacante que comprometa a cualquiera de sus titulares. El rol personal (o rol-por-persona) es un rol con exactamente un miembro, lo que significa que no has abstraído nada; has reetiquetado una concesión directa, y un catálogo lleno de estos es DAC disfrazado. El anidamiento profundo apila jerarquías de roles tantas capas que nadie puede rastrear por qué un usuario tiene un permiso, derrotando silenciosamente la auditabilidad que era el punto. Y los roles huérfanos persisten después de que el puesto que modelaban desaparece, concediendo acceso a una función que ya no existe.

El remedio común es propiedad y revisión: cada rol tiene un dueño con nombre responsable de lo que contiene, un claro nombre de función laboral (no un código de proyecto ni el nombre de una persona), y una revisión periódica que lo poda. Un catálogo de roles es un artefacto vivo; sin atender, cada uno de estos antipatrones vuelve a crecer. Reconocerlos por su nombre es media batalla en cualquier revisión de acceso — y nombrar el olor a menudo es lo que desbloquea el arreglo, porque “eso es un rol dios” inicia una conversación que “los permisos se sienten raros” nunca inicia.

Gobernanza: los roles a lo largo del ciclo de vida de la identidad

RBAC es donde la gestión de acceso se encuentra con la gobernanza, porque los roles son la unidad natural para el ciclo altas-cambios-bajas (joiner-mover-leaver). A un alta (joiner) se le concede automáticamente un paquete de roles de derecho de nacimiento para su departamento. A un cambio (mover) se le quitan los roles viejos y se le añaden los nuevos — el paso que las organizaciones más a menudo arruinan, produciendo el exceso de acceso acumulado llamado abuso de privilegios (privilege creep). A una baja (leaver) se le revocan todos los roles en una sola acción, que es exactamente la baja limpia que DAC no podía dar. La recertificación de acceso periódica pide a los dueños de roles y recursos volver a atestiguar que cada asignación sigue justificada, y la gestión del ciclo de vida de los roles mantiene el catálogo mismo podado a medida que el negocio cambia.

Por eso RBAC y la gobernanza de identidades son inseparables en la práctica: los roles son solo tan buenos como los procesos que los asignan, revisan y retiran. Un modelo de roles perfecto sin recertificación se degrada en abuso de privilegios en un año; un modelo de roles mediocre con gobernanza disciplinada permanece más seguro. El modelo es necesario pero no suficiente — la disciplina operativa a su alrededor es lo que de verdad entrega el mínimo privilegio con el tiempo.

La recertificación tiene su propio modo de fallo que vale la pena señalar: la fatiga de revisión. Cuando a un gerente se le entrega una lista trimestral de cientos de derechos que atestiguar, aprueba la página entera de un clic, y el control se vuelve teatro. Los programas maduros combaten esto revisando al nivel de roles en lugar de permisos crudos (un puñado de elementos significativos en vez de cientos de crípticos), señalando solo los cambios desde la última revisión, y enrutando cada rol al dueño que de verdad lo entiende. El punto de la indirección de RBAC no es solo menos concesiones que gestionar sino menos cosas, y más significativas, que revisar — un beneficio que pierdes por completo si recertificas permisos crudos.

La realidad híbrida: roles más reglas

En la práctica, muy pocos sistemas grandes son RBAC puro o puro nada. El patrón dominante del mundo real es RBAC como base, con reglas basadas en atributos superpuestas para las condiciones que los roles no pueden expresar. Los roles establecen qué clase de cosa puedes hacer — “el Agente de Soporte puede leer tickets” — y una capa delgada de reglas la estrecha a qué instancias, cuándo — “…pero solo tickets en tu cola asignada, durante tu turno”. Esto te da la auditabilidad y la legibilidad de organigrama de los roles para la decisión gruesa, y la flexibilidad de los atributos para la fina, sin ni la explosión de roles del RBAC puro ni la opacidad de quién-puede-hacer-qué de las reglas de atributos puras.

Este híbrido es tan común que muchas autoridades describen el control de acceso moderno como “RBAC más contexto”. AWS empareja los roles IAM con claves de condición y etiquetas; Azure añade condiciones ABAC a las asignaciones de rol; Kubernetes complementa RBAC con controladores de admisión. Entender RBAC en profundidad, por tanto, no queda superado por el siguiente modelo — es el cimiento que el siguiente modelo refina. Los roles responden “¿quién eres, aproximadamente?”, y los atributos responden “¿y es esta solicitud exacta apropiada?”. Casi todo sistema serio de autorización que construyas u operes es alguna mezcla de los dos, que es exactamente por lo que se enseñan uno tras otro.

Un ejemplo trabajado: la carpeta de investigación, bajo roles

Vuelve una última vez a la carpeta /research/roadmap de Sara. Bajo DAC ella concedió a Daniel una ACL por archivo que persistió tras su salida. Bajo MAC una clasificación bloqueó un flujo no autorizado pero no dijo nada sobre los puestos. Bajo RBAC, el acceso al roadmap fluye de un rol “Producto — Lector de Roadmap”. Daniel no obtiene una concesión personal; si su trabajo legítimamente necesita el roadmap, se le asigna el rol, y cuando deja soporte el proceso altas-cambios-bajas lo quita automáticamente. La pregunta “¿quién puede leer el roadmap?” ahora tiene una respuesta autoritativa: todos los de ese rol. El alta, la baja y la auditoría se colapsan todos a la pertenencia a roles.

Pero observa aparecer la frontera. Supón que la regla es en realidad “los agentes de soporte pueden leer el roadmap solo para la región que atienden, y solo mientras tengan un ticket abierto que lo referencie”. RBAC no puede expresar eso — necesitaría un rol separado por región, y simplemente no puede representar “tiene un ticket abierto que referencia este documento”, que depende de datos en vivo sobre este usuario y este recurso ahora mismo. Hemos llegado al borde exacto donde los roles dejan de ser suficientes. Ten presente esta carpeta una vez más; el siguiente artículo la vuelve a resolver con atributos.

Vale la pena ser preciso sobre por qué este es un borde duro y no una laguna de configuración. RBAC decide el acceso a partir de un hecho estático — el conjunto de roles que tienes, que cambia solo cuando un administrador lo reasigna. La regla de roadmap-por-región depende de hechos dinámicos — tu región, la hora actual, si un ticket específico está abierto — que cambian constantemente y pertenecen a ti-y-este-recurso, no a un rol que alguien pudiera preasignar. Ninguna cantidad de diseño de roles tiende un puente de un mecanismo estático a una pregunta dinámica; necesitas un modelo que evalúe hechos en el momento de la solicitud. Eso no es una debilidad de un producto RBAC particular sino la línea definitoria del modelo mismo, y nombrarla con precisión es lo que arma el caso para ABAC en vez de para otro rol más.

Recap

El Control de Acceso Basado en Roles es la columna vertebral pragmática de la autorización empresarial:

1. El acceso sigue al puesto, mediante indirección. Los permisos se adjuntan a roles, los usuarios se asignan a roles, y el acceso efectivo es la unión de los permisos de los roles de un usuario — convirtiendo la gestión O(usuarios × recursos) en O(roles).
2. Es un estándar real. El modelo NIST / INCITS 359 define RBAC núcleo, jerárquico (herencia de roles), restringido (separación de deberes) y simétrico (revisión de permisos).
3. La separación de deberes y las sesiones codifican el mínimo privilegio. La SoD detiene combinaciones tóxicas de roles (estática o dinámicamente); las sesiones limitan el acceso a los roles realmente activados ahora.
4. Está en todas partes. Los grupos AD/LDAP, el IAM de AWS/Azure/GCP, el RBAC de Kubernetes y todo modelo SaaS “Admin/Miembro/Visor” son RBAC.
5. Sus límites son la explosión de roles y la ceguera al contexto. Los roles no pueden expresar hora, ubicación ni relaciones usuario-recurso, así que el acceso condicional fuerza o un catálogo de roles inmanejable o el salto al control basado en atributos — y vive o muere por la gobernanza.

Tres preguntas para ponerte a prueba

1. Una startup tiene 30 personas y 400 concesiones discrecionales dispersas por sus herramientas. Explica, en términos de las dos asignaciones de RBAC, exactamente cómo introducir roles cambia lo que hace un administrador cuando el empleado 31 entra y cuando el empleado 5 se va.
2. Tu auditor exige que nadie pueda a la vez enviar y aprobar un gasto por encima de un umbral. Describe cómo lo codificarías con separación de deberes estática frente a dinámica, y da un escenario donde un equipo pequeño necesitaría específicamente la forma dinámica.
3. Da una regla de acceso concreta que RBAC no pueda expresar sin crear un número combinatorio de roles. Identifica con precisión qué parte de la regla es el “contexto” que los roles no pueden capturar, y nombra el modelo que sí puede.

Ejercicios prácticos

1. Lee roles reales. En cualquier consola de nube o en un clúster local de Kubernetes (kubectl get roles,rolebindings -A), encuentra un rol, lista los permisos que agrupa, y rastrea una identidad a través de un binding hasta lo que de verdad puede hacer. Escribe el triángulo usuarios-roles-permisos para ese único ejemplo.
2. Diseña un modelo de roles pequeño. Para un equipo que conozcas, define de cuatro a seis roles de arriba hacia abajo, cada uno nombrado por una función laboral, y asígnales permisos. Luego introduce deliberadamente un requisito que tiente a un séptimo rol raramente específico — y nota el tirón hacia la explosión de roles. Decide si añadir el rol o marcarlo como un caso para reglas basadas en atributos.
3. Prueba una restricción de separación de deberes. Anota dos roles en tu entorno que nunca deberían tenerse juntos, luego comprueba si algún usuario real los tiene ambos actualmente. Si tu sistema admite restricciones de SoD, añade una; si no, anota cómo detectarías hoy una violación, y cómo se vería esa laguna para un auditor.