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

“Los mismos accesos que David”

Cuando Daniel pasa de soporte al equipo de facturación, su nuevo responsable abre un ticket de una sola línea: “Por favor, dadle a Daniel los mismos accesos que David”. Es la petición de acceso más común del mundo, y es terrible sin hacer ruido. El administrador copia todos los permisos que David ha ido acumulando en seis años, incluidos dos sistemas que David solo usó para un proyecto de 2021 y una carpeta compartida de un equipo que ya no existe. Nadie le quita a Daniel sus accesos de soporte, porque el ticket no lo pedía. Seis meses después, una auditoría descubre que Daniel puede emitir un reembolso en la herramienta de soporte y aprobarlo en facturación.

Los dos artículos anteriores dejaron un hueco. El DAC deja que los dueños compartan libremente, lo que no escala ni se puede gobernar. El MAC impone etiquetas rígidas, demasiado inflexibles para llevar una empresa en el día a día. Ninguno responde a la pregunta que hace de verdad una organización: “esta persona trabaja en facturación, así que dale lo que tiene la gente de facturación”. El acceso debería seguir a lo que hace la gente, no a quién es dueño de un fichero ni a cómo está clasificado un documento. El modelo que hace eso, y que gobierna el acceso en la inmensa mayoría de las empresas, es el control de acceso basado en roles (RBAC).

La idea central es una sola capa de indirección muy potente. En lugar de conceder permisos a usuarios, los concedes a roles y asignas usuarios a los roles. Un rol es un paquete de permisos con nombre que corresponde a un puesto: “Agente de soporte”, “Auditor”, “Mozo de almacén”, “Administrador de facturación”. Cuando Daniel entra en facturación, recibe el rol de Administrador de facturación y tiene exactamente lo que necesita facturación, nada copiado de nadie. Cuando vuelva a cambiar, se le cambia el rol. Nadie edita miles de concesiones individuales; gestionas el conjunto, mucho más pequeño, de pertenencias a roles. Esa indirección es la razón de que el RBAC escale donde el DAC no lo hace.

El RBAC no es folclore; es un estándar formal. Agrupar el acceso por puesto es una idea antigua, pero el RBAC como modelo lo formularon en 1992 David Ferraiolo y Richard Kuhn, del NIST, en un artículo que defendía que la mayoría de las organizaciones no militares no hacían ni DAC puro ni MAC, sino algo intermedio, asignar el acceso por función en la organización, y que eso merecía ser un modelo por derecho propio. La idea maduró en los 90 hasta el modelo de referencia del NIST de 2000 y el estándar nacional estadounidense INCITS 359. Como está estandarizado, “RBAC” significa algo concreto, y puedes contrastar la promesa “basado en roles” de un fabricante con una definición real.

Tres elementos, dos asignaciones

Si dejas el RBAC en los huesos, hay tres tipos de cosas y dos relaciones entre ellas. Los usuarios son las personas y, cada vez más, las cargas de trabajo. Los permisos son lo que se puede hacer sobre los objetos, como “leer factura”, “borrar usuario” o “aprobar reembolso”, y un permiso es a su vez una pareja: una operación (leer, borrar, aprobar) aplicada a un objeto (factura, usuario, reembolso). Acertar con esa granularidad es sutil. Demasiado gruesa, como “acceder a facturación”, y los roles no pueden aplicar el mínimo privilegio; demasiado fina, como “leer el campo 7 de la factura 402”, y el conjunto de permisos se vuelve inmanejable. Los roles están entre los usuarios y los permisos. Dos asignaciones los conectan: usuario a rol, como “Daniel es Administrador de facturación”, y permiso a rol, como “el Administrador de facturación puede editar facturas”. El acceso efectivo de un usuario es la unión de los permisos de todos sus roles.

La columna de la derecha es la razón de que cualquier organización de más de un puñado de personas acabe con RBAC. Convierte la gestión del acceso, de un problema del tamaño de usuarios por recursos, en uno del tamaño del catálogo de roles, y los roles cambian mucho más despacio que los usuarios o los recursos.

En la última fila hay una ventaja más sutil. Como el acceso de un puesto se define en un solo sitio, el RBAC hace el acceso describible. Puedes darle a un responsable nuevo la lista de roles de su equipo y entenderla de verdad, algo que ningún montón de ACL por objeto permite. Esa legibilidad es lo que hace posible que las personas lleven a cabo revisiones de acceso, auditorías y decisiones de mínimo privilegio. Un modelo cuyo estado cabe en la cabeza de alguien es un modelo cuyos errores alguien puede detectar.

Se suele equiparar los roles con los grupos del directorio, y en la práctica los grupos de Active Directory y LDAP son la forma más común de implementarlos. Conceptualmente, sin embargo, un grupo es un conjunto de usuarios, mientras que un rol es un conjunto de permisos al que después se asignan usuarios. Un rol bien diseñado lleva el nombre de un puesto y tiene un conjunto de permisos cuidado; los grupos a menudo simplemente van acumulando. Cuando los grupos llevan nombres de puestos y corresponden limpiamente a permisos, son RBAC. Cuando se llaman “acceso-temporal-proyectoX-2019”, son la maraña del DAC disfrazada de grupo.

El modelo del NIST: cuatro niveles

El estándar define el RBAC como capacidades anidadas, cada una más potente, y los niveles te dan vocabulario para decir cuán sofisticado es de verdad el RBAC de un sistema.

El RBAC básico es la base que acabamos de describir: usuarios, roles, permisos, las dos asignaciones y las sesiones, a las que llegaremos. El RBAC jerárquico añade jerarquías de roles, en las que los roles superiores heredan los permisos de los inferiores. Defines “Empleado” con lo que necesita todo el mundo, haces que “Ingeniero” herede de Empleado y añada permisos de ingeniería, y que “Ingeniero sénior” herede de Ingeniero. El acceso compartido se especifica una vez y la jerarquía refleja el organigrama. Dos precauciones mantienen seguras las jerarquías. La herencia sube, así que un permiso añadido a un rol inferior llega a todos los roles de encima, y el rol base Empleado tiene que ser mínimo a propósito, porque es el radio de impacto de toda la empresa. Y no mezcles antigüedad y función en el mismo eje: que Ingeniero sénior herede de Ingeniero es limpio, pero hacer que Ingeniero herede de Agente de soporte porque ambos son “plantilla” mezcla permisos que no tienen nada que ver y lleva directo a la explosión de roles. Las jerarquías deben expresar “una versión con más privilegios de”, no cercanía en el organigrama.

El RBAC con restricciones añade las restricciones de segregación de funciones y a menudo restricciones de cardinalidad, límites como “como mucho dos personas pueden tener el rol de Administrador del dominio”. Limitar cuántos miembros tienen tus roles más peligrosos reduce directamente el radio de impacto y obliga a tomar una decisión consciente cada vez que alguien nuevo necesita ese poder. El RBAC simétrico añade la revisión de permisos por rol, la posibilidad de preguntar con eficacia “¿quién tiene este permiso y a través de qué roles?”, que es la capacidad de auditoría que hace gobernable al RBAC. La mayoría de los sistemas empresariales implementan el RBAC básico y el jerárquico más algunas restricciones; la revisión simétrica completa es la marca de un programa de gobierno de identidades maduro.

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 centro: Sara a Ingeniero sénior, Daniel a Agente de soporte, David a Administrador de facturación. Se muestra una jerarquía en la que Ingeniero sénior hereda de Ingeniero, que hereda de un rol base Empleado que incluyen todos los roles. A la derecha están los permisos. Cada rol se une a los permisos que tiene: Empleado a leer-directorio, Ingeniero a desplegar-servicio, Agente de soporte a leer-ticket y emitir-reembolso, Administrador de facturación a editar-factura. Las flechas van de los usuarios a través de los roles hasta los permisos, lo que muestra que el acceso se concede de forma indirecta por pertenecer a un rol y no directamente a los usuarios.
  U1[Sara] --> R3[Ingeniero sénior]
  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]

Segregación de funciones: “que no sea la misma persona”

Algunas combinaciones de acceso no son peligrosas por separado, sino juntas. Quien puede crear un pago no debería poder aprobarlo; quien pide un cambio no debería poder desplegarlo. Es la segregación de funciones (SoD), el principio contable de siglos según el cual las acciones críticas necesitan más de un par de manos, y el RBAC es donde los sistemas de identidad lo recogen. Es también justo lo que rompió el acceso copiado de Daniel: emitir un reembolso y aprobarlo acabaron en las mismas manos.

La SoD estática prohíbe la asignación conflictiva. Un usuario sencillamente no puede recibir a la vez los roles de Crear pago y Aprobar pago; se comprueba al asignar los roles, y es el control más fuerte y limpio. La SoD dinámica es más permisiva: un usuario puede tener los dos roles pero no activarlos en la misma sesión, así que quien lleva dos sombreros con todo derecho tiene que cambiar de contexto a propósito. Es útil en equipos pequeños en los que una persona cubre de verdad dos funciones pero nunca debe hacer las dos sobre una misma operación.

En los procesos regulados, la información financiera con SOX, los pagos con PCI DSS, la sanidad con HIPAA, la segregación de funciones es obligatoria y los auditores la comprueban. “Enséñame que nadie puede iniciar y aprobar una transferencia a la vez” es una pregunta de auditoría habitual, y la respuesta limpia es una restricción de SoD estática en tu RBAC. Las organizaciones que guardan la SoD como saber popular en lugar de como restricción del sistema suspenden esas auditorías en cuanto alguien acumula los dos roles sin que nadie se dé cuenta, como le pasó a Daniel.

Sesiones y mínimo privilegio

La sesión del RBAC une los roles que tiene un usuario con los que está usando. Cuando Sara empieza una sesión, puede activar algunos o todos sus roles asignados, y solo están disponibles los permisos de los roles activados. Eso permite a un usuario con mucho poder trabajar casi siempre con un rol mínimo y activar uno de administración solo cuando hace falta, que es el mínimo privilegio en el tiempo y no solo en el alcance. Es el mismo instinto que hay detrás de “no navegues por internet como root” y de la elevación justo a tiempo en la gestión de accesos privilegiados: ten el poder, pero no lo lleves encendido todo el rato. Un rol que no estás usando es un rol del que un atacante que entre en tu sesión no puede abusar de inmediato.

El RBAC en la práctica

El RBAC no es un producto; es la forma que tiene el acceso en casi cualquier sistema serio. Los grupos de Active Directory y LDAP son la implementación empresarial clásica, con las pertenencias a grupos de un usuario haciendo de roles y los recursos dando 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 roles sobre ámbitos de Azure y los roles de Google Cloud IAM agrupan permisos y los asignan a identidades. Kubernetes gobierna el clúster con objetos Role y ClusterRole vinculados a sujetos mediante RoleBinding. Y casi todas las aplicaciones SaaS traen un modelo de Administrador, Miembro y Lector, que es el RBAC en su forma mínima. Cuando ves usuarios, roles y permisos, un binding de Kubernetes, una asignación de roles de Azure y un grupo de AD dejan de ser tres sistemas sin relación y pasan a ser tres dialectos de un idioma que ya hablas.

El dialecto de Kubernetes casi deletrea el modelo:

# 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 de 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 de permisos a rol, verbos sobre recursos, y el RoleBinding es la asignación de usuario a rol, un sujeto vinculado a un rol. A propósito, no hay forma de concederle un verbo directamente a Daniel; Kubernetes obliga a que toda concesión pase por un rol, que es RBAC básico impuesto por la plataforma. Lee un rol de AWS IAM o una asignación de roles de Azure y encontrarás las mismas dos uniones con otros nombres.

El RBAC dice que el acceso pasa por los roles, pero no dice cómo consigue un usuario un rol. En sistemas pequeños, un administrador asigna los roles a mano. A escala, la asignación se automatiza con reglas de acceso por nacimiento (birthright), como “todo el que esté en el departamento de Ventas recibe automáticamente el rol Ventas Base”, evaluadas a partir de atributos de RR. HH. como el departamento, la ubicación y el código de puesto. Entra ID las llama grupos dinámicos; otras plataformas, reglas de asignación o políticas de acceso. Aquí los atributos deciden quién pertenece a un rol mientras los roles siguen llevando los permisos, lo que mantiene intacta la capa auditable de roles, porque sigues pudiendo preguntar quién está en Ventas Base y por qué, y elimina el trabajo manual. Es el primer sitio en que atributos y roles colaboran, y un adelanto del modelo híbrido que veremos más abajo.

Ingeniería de roles: donde está la dificultad

El mecanismo del RBAC es sencillo; decidir cuáles deben ser los roles es difícil, y esa disciplina tiene nombre, ingeniería de roles. Hay dos enfoques amplios, que suelen combinarse. El descendente (top-down) parte del negocio: entrevistar a los departamentos, modelar las funciones de los puestos y definir roles que reflejen cómo funciona de verdad la organización. Produce roles con sentido y bien nombrados, pero es lento y puede pasar por alto la realidad desordenada de quién necesita qué. El ascendente (bottom-up), también llamado minería de roles, parte de los datos de acceso existentes, analizando los permisos que tiene hoy la gente y agrupándolos estadísticamente en roles candidatos. Es rápido y está pegado a la realidad, pero puede consagrar errores existentes, del tipo “todo el mundo ya tiene esto, así que será un rol”, y sus roles necesitan que se les ponga un nombre de negocio. Los programas maduros hacen las dos cosas: extraen candidatos del acceso actual y luego los refinan de forma descendente para que cada rol corresponda a un puesto real con un responsable de su contenido. El dominio de IGA tiene un artículo completo sobre ingeniería de roles que entra a fondo en esto.

La explosión de roles: el fallo característico del RBAC

La gran debilidad del RBAC sale directamente 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 más lectura de un informe financiero; ¿creas “Ingeniero más informe financiero”? Hazlo bastantes veces y llega la 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 maraña por usuario del DAC, un nivel más arriba.

La causa de fondo es que los roles no ven el contexto. Un rol no puede decir “leer informes financieros, pero solo los de tu región y en horario laboral”. En cuanto el acceso depende de una condición, la hora, la ubicación, la relación entre este usuario y este recurso, una puntuación de riesgo, la única herramienta del RBAC es otro rol por cada combinación, y las combinaciones se multiplican. No es un fallo que se arregle configurando; es el límite del modelo. El acceso que depende de atributos y contexto pide otro modelo, el tema del siguiente artículo.

La explosión de roles no solo crea desorden; debilita la seguridad de forma activa. Cuando hay demasiados roles para entenderlos, los administradores asignan el que “seguro que incluye lo necesario”, que suele ser más amplio de lo debido, y los revisores aprueban renovaciones que no pueden evaluar. El resultado es un exceso de privilegios silencioso y extendido, lo contrario del mínimo privilegio que el RBAC debía traer.

Antipatrones que conviene reconocer

La explosión de roles es el fallo famoso, pero hay otros que aparecen tanto que merecen nombre. El rol dios es un único rol de Administrador que ha ido acumulando todos los permisos potentes porque añadirle cosas era más fácil que diseñar bien, lo contrario del mínimo privilegio y lo primero que hereda un atacante de cualquiera que lo tenga. El rol personal tiene exactamente un miembro, lo que significa que no se ha abstraído nada; es una concesión directa con otra etiqueta, y un catálogo lleno de ellos es DAC disfrazado. El anidamiento profundo apila jerarquías con tantas capas que nadie puede seguir por qué un usuario tiene un permiso, y acaba en silencio con la capacidad de auditoría, que era el objetivo. Los roles huérfanos siguen ahí después de que desaparezca el puesto que modelaban. Y la petición de copiar a otro usuario, “los mismos accesos que David”, es como se propagan todos ellos: copia la historia acumulada de una persona en otra en lugar de asignar los roles que de verdad necesita el puesto.

El remedio es la responsabilidad y la revisión: cada rol tiene un responsable con nombre que responde de su contenido, un nombre claro basado en una función y no en un código de proyecto o en una persona, y una revisión periódica que lo poda. Un catálogo de roles es algo vivo, y si se deja solo, todos estos patrones vuelven a crecer. Ponerle nombre al mal olor a menudo es lo que desbloquea el arreglo, porque “eso es un rol dios” abre una conversación que “los permisos me dan mala espina” nunca abre.

Gobierno: los roles a lo largo del ciclo de vida

El RBAC es donde la gestión de accesos se encuentra con el gobierno, porque los roles son la unidad natural del ciclo de altas, cambios y bajas. Una persona que entra recibe automáticamente un paquete de roles por nacimiento según su departamento. A quien cambia de puesto se le quitan los roles viejos y se le añaden los nuevos, el paso que las organizaciones fallan más a menudo y que produce el exceso de acceso acumulado llamado acumulación de privilegios, que es exactamente lo que le pasó a Daniel. A quien se va se le revocan todos los roles en una sola acción, la baja limpia que el DAC no podía ofrecer. La certificación de accesos periódica pide a los responsables de roles y recursos que confirmen que cada asignación sigue justificada, y la gestión del ciclo de vida de los roles mantiene podado el propio catálogo a medida que cambia el negocio.

Por eso el RBAC y el gobierno de identidades son inseparables en la práctica: los roles valen lo que valgan los procesos que los asignan, revisan y retiran. Un modelo de roles perfecto sin certificación degenera en acumulación de privilegios en un año, y uno mediocre con un gobierno disciplinado se mantiene más seguro. La certificación tiene su propia trampa, la fatiga de revisión. Dale a un responsable una lista trimestral de cientos de permisos y aprobará la página entera de un clic, convirtiendo el control en teatro. Los programas maduros revisan roles y no permisos en bruto, unos pocos elementos con sentido en lugar de cientos de crípticos, señalan solo lo que ha cambiado desde la última revisión y mandan cada rol al responsable que lo entiende. La gracia de la indirección del RBAC es tener menos cosas, y más significativas, que revisar, y esa ventaja se pierde del todo si certificas permisos en bruto.

La realidad híbrida: roles más reglas

Muy pocos sistemas grandes son RBAC puro, ni puro nada. El patrón dominante en el mundo real es el RBAC como base con reglas basadas en atributos encima para las condiciones que los roles no pueden expresar. Los roles fijan qué tipo de cosa puedes hacer, “el Agente de soporte puede leer tickets”, y una capa fina de reglas lo estrecha a qué casos y cuándo, “pero solo los tickets de tu cola y durante tu turno”. Obtienes la capacidad de auditoría y la legibilidad de organigrama de los roles para la decisión gruesa y la flexibilidad de los atributos para la fina, sin la explosión de roles del RBAC puro ni la opacidad de las reglas de atributos puras.

El híbrido es tan común que el control de acceso moderno se describe a menudo como “RBAC más contexto”. AWS combina los roles de IAM con claves de condición y etiquetas; Azure añade condiciones ABAC a las asignaciones de roles; Kubernetes complementa el RBAC con controladores de admisión. Entender bien el RBAC no queda superado por el siguiente modelo; es la base que el siguiente modelo afina. Los roles responden a quién eres, más o menos, y los atributos responden a si esta petición concreta es adecuada.

De vuelta a la carpeta de investigación

Vuelve una vez más a la carpeta /research/roadmap de Sara. Con DAC, ella le dio a Daniel una ACL por fichero que se quedó ahí cuando él se fue. Con MAC, una clasificación bloqueó un flujo no autorizado, pero no dijo nada sobre los puestos. Con RBAC, el acceso a la hoja de ruta sale de un rol “Producto, lector de la hoja de ruta”. Daniel no recibe una concesión personal; si su puesto de verdad necesita la hoja de ruta, se le asigna el rol, y cuando sale de soporte el proceso de altas, cambios y bajas se lo quita automáticamente. “¿Quién puede leer la hoja de ruta?” tiene ahora una única respuesta con autoridad: todos los que están en ese rol. El alta, la baja y la auditoría se reducen a la pertenencia al rol.

Pero mira cómo aparece el límite. Supón que la regla de verdad es que los agentes de soporte pueden leer la hoja de ruta solo de la región que atienden, y solo mientras tengan abierto un ticket que haga referencia a ella. El RBAC no puede expresarlo. Necesitaría un rol por región, y no puede representar de ninguna manera “tiene abierto un ticket que hace referencia a este documento”, porque eso depende de datos en vivo sobre este usuario y este recurso en este momento. El RBAC decide a partir de un hecho estático, el conjunto de roles que tienes, que solo cambia cuando un administrador los reasigna. La regla de la región depende de hechos dinámicos, tu región, la hora, si un ticket concreto está abierto, que cambian todo el tiempo y pertenecen a ti y a este recurso, no a un rol que alguien pudiera asignar de antemano. Ningún diseño de roles une un mecanismo estático con una pregunta dinámica; hace falta un modelo que evalúe los hechos en el momento de la petición.

Resumen

El control de acceso basado en roles es la columna vertebral pragmática de la autorización en las empresas. El acceso sigue al puesto a través de una indirección: los permisos se asocian a roles, los usuarios reciben roles y el acceso efectivo es la unión de los permisos de sus roles, lo que reduce el problema de gestión al tamaño del catálogo de roles. Es un estándar real, el modelo NIST e INCITS 359, con niveles básico, jerárquico, con restricciones y simétrico. La segregación de funciones y las sesiones recogen el mínimo privilegio: la SoD bloquea las combinaciones tóxicas de forma estática o dinámica y las sesiones limitan el acceso a los roles que se están usando ahora. Está en todas partes, en los grupos de AD y LDAP, el IAM de AWS, Azure y Google Cloud, Kubernetes y cada modelo de Administrador, Miembro y Lector de las apps SaaS. Y sus límites son la explosión de roles y la ceguera al contexto, así que el acceso condicional obliga a elegir entre un catálogo inmanejable o pasar al control basado en atributos, y el RBAC vive o muere según el gobierno que tenga.

Tres preguntas para ponerte a prueba

1. Una startup tiene 30 personas y 400 concesiones discrecionales repartidas por sus herramientas. Con las dos asignaciones del RBAC, explica exactamente cómo cambia lo que hace un administrador al introducir roles cuando entra la persona número 31 y cuando se va la número 5.
2. Tu auditor exige que nadie pueda a la vez presentar y aprobar un gasto por encima de un umbral. Describe cómo lo expresarías con segregación de funciones estática y con dinámica, y da un caso en que un equipo pequeño necesitaría en concreto la forma dinámica.
3. Da una regla de acceso concreta que el RBAC no pueda expresar sin un número combinatorio de roles. Identifica con precisión qué parte de la regla es el contexto que los roles no pueden captar 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 con kubectl get roles,rolebindings -A, busca un rol, enumera los permisos que agrupa y sigue a una identidad a través de un binding hasta lo que puede hacer de verdad. Escribe el triángulo usuario-rol-permiso de ese ejemplo.
2. Diseña un modelo de roles pequeño. Para un equipo que conozcas, define de forma descendente entre cuatro y seis roles, cada uno con el nombre de un puesto, y asígnales permisos. Después introduce un requisito que te tiente a crear un séptimo rol curiosamente específico y fíjate en el tirón hacia la explosión de roles. Decide si añadir el rol o marcar el requisito como un caso para reglas basadas en atributos.
3. Prueba una restricción de segregación de funciones. Apunta dos roles de tu entorno que nunca deberían ir juntos y comprueba si algún usuario real los tiene hoy los dos. Si tu sistema admite restricciones de SoD, añade una; si no, anota cómo detectarías ahora una infracción y cómo vería ese hueco un auditor.