Control de Acceso Discrecional (DAC): el dueño decide

De “quién eres” a “qué puedes hacer”

El módulo anterior respondía una sola pregunta de muchas maneras: ¿quién eres? Los factores, el MFA, la biometría, el SSO y las sesiones son toda la maquinaria de la autenticación — demostrar la identidad. Este módulo pasa a la otra mitad del acceso: una vez que sabemos quién eres, ¿qué se te permite hacer? Eso es la autorización, y la familia de modelos que la responden suele apodarse xBAC — DAC, MAC, RBAC, ABAC, PBAC, ReBAC, NGAC — porque casi todos terminan en “Based Access Control” (control de acceso basado en…).

Empezamos donde empezó el control de acceso mismo: el Control de Acceso Discrecional (DAC), el modelo más antiguo y todavía el más extendido. Su idea definitoria está en la palabra discrecional — el acceso queda a la discreción del dueño. Si creas un archivo, eres su dueño, y decides quién más puede leerlo o cambiarlo. El sistema hace cumplir fielmente lo que elijas, pero no impone una política propia. Cada vez que haces clic derecho en un documento y eliges “Compartir”, o ejecutas chmod en un script, estás ejerciendo DAC.

DAC recibió su nombre formal en los Trusted Computer System Evaluation Criteria de 1985 del Departamento de Defensa de EE. UU. (el “Libro Naranja”), que lo definieron como un medio de restringir el acceso “con base en la identidad de los sujetos y/o los grupos a los que pertenecen”, con la propiedad crucial de que un sujeto con un permiso de acceso dado es “capaz de pasar ese permiso a cualquier otro sujeto”. Esa última cláusula — la capacidad de pasar los permisos adelante — es a la vez la gran comodidad de DAC y su debilidad fundamental, y recorrerá todo este artículo.

La matriz de control de acceso: el modelo bajo los modelos

Antes de DAC, MAC o RBAC, hay una estructura abstracta que todos ellos no son más que formas de expresar: la matriz de control de acceso, descrita por Butler Lampson en 1971. Imagina una cuadrícula gigante. Cada sujeto (usuario, proceso) es una fila. Cada objeto (archivo, dispositivo, registro) es una columna. Cada celda enumera los derechos que ese sujeto tiene sobre ese objeto: leer, escribir, ejecutar, ser dueño, borrar.

La matriz es un modelo conceptual perfecto y uno práctico pésimo: para miles de usuarios y millones de objetos estaría casi toda vacía y sería imposiblemente grande de almacenar. Así que los sistemas reales nunca la almacenan directamente. En cambio la guardan rebanada de una de dos formas, y esa elección define dos tradiciones enteras del control de acceso.

Rebanar por columna: las Listas de Control de Acceso (ACL)

Toma un objeto y enumera a todos los que pueden tocarlo. Esa columna de la matriz, adjunta al objeto, es una Lista de Control de Acceso (ACL). Un archivo dice, en efecto, “Sara puede leerme y escribirme; Daniel puede leerme”. Las ACL responden la pregunta “¿quién puede acceder a este objeto?” al instante, porque la respuesta vive con el objeto. Así funcionan los sistemas de archivos, y es la forma dominante de implementar DAC.

Rebanar por fila: las capabilities

Toma un sujeto y enumera todo lo que puede tocar. Esa fila, en poder del sujeto, es un conjunto de capabilities — tokens infalsificables que dicen cada uno “el portador puede hacer X sobre el objeto Y”. Una capability responde “¿a qué puede acceder este sujeto?” al instante. Las capabilities son menos comunes en los sistemas de archivos convencionales, pero reaparecen por todas partes en los sistemas modernos: una URL firmada, un token bearer de OAuth, un token de cuenta de servicio de Kubernetes y un descriptor de archivo son todos, en esencia, capabilities — poseer es poder.

flowchart TD
  accTitle: Cómo decide una solicitud el Control de Acceso Discrecional
  accDescr: Un dueño fija la lista de control de acceso de un objeto a su discreción, incluida la concesión de derechos a otros sujetos. Cuando un sujeto hace una solicitud al objeto, un monitor de referencia la intercepta y consulta la lista de control de acceso del objeto. Si la lista concede el derecho solicitado, se permite el acceso; en caso contrario se deniega. Una flecha aparte muestra que un sujeto al que se le ha concedido un derecho, incluida la opción de concesión, puede pasar ese derecho a otro sujeto, ilustrando la propagación de derechos.
  OWN[Dueño] -->|fija a discreción| ACL[Lista de Control de Acceso del objeto]
  OWN -->|concede derechos a| SUBJ[Otros sujetos]
  REQ[Sujeto solicita acceso] --> RM{Monitor de referencia}
  RM -->|consulta| ACL
  ACL -->|derecho presente| ALLOW[Permitir]
  ACL -->|derecho ausente| DENY[Denegar]
  SUBJ -.->|puede pasar el derecho| SUBJ2[Aún otro sujeto]

Una breve historia: por qué “discrecional” es un término de defensa

Es fácil suponer que los permisos de archivo son solo una comodidad de ingeniería, pero el vocabulario viene de la investigación de defensa, y la historia explica la forma del modelo. En los años sesenta, Multics fue pionero en las ACL por segmento y en las ideas de anillos de protección que Unix después simplificó en los bits de dueño/grupo/otros. En 1985, el Departamento de Defensa de EE. UU. publicó los Trusted Computer System Evaluation Criteria (el Libro Naranja), que separaron formalmente dos tipos de control: discrecional (guiado por el dueño, el tema de este artículo) y obligatorio (guiado por etiquetas, el siguiente). La palabra “discrecional” existe precisamente para contrastar con “obligatorio” — nombra el hecho de que la política queda a la discreción de un usuario en lugar de imponerse por el sistema.

Ese encuadre no era académico. El Libro Naranja era un estándar de adquisición: para vender sistemas al gobierno tenías que cumplir una clase evaluada, y las clases más altas exigían controles obligatorios porque se entendía que los discrecionales eran insuficientes para datos clasificados — por exactamente las razones del caballo de Troya de más abajo. Así que cuando haces chmod a un archivo hoy, usas un mecanismo que un estándar de seguridad de hace 40 años clasificó como el más débil de dos niveles, conservado porque es indispensable para el trabajo cotidiano. Conocer ese linaje es lo que mantiene a DAC en su justa proporción: no un defecto por eliminar, sino una herramienta deliberadamente limitada que el resto del campo se construyó para complementar.

El monitor de referencia: lo que de verdad dice “no”

DAC describe quién decide la política, pero algo tiene que hacerla cumplir en cada acceso, sin excepción y sin poder ser evitado. Ese algo es el monitor de referencia — un concepto tan antiguo como la teoría misma del control de acceso. Un monitor de referencia debe ser tres cosas: siempre invocado (ningún camino de acceso lo salta), a prueba de manipulación (nada puede desactivarlo ni editarlo) y suficientemente pequeño para verificarse (para que de verdad puedas confiar en él). En un sistema operativo, la comprobación de acceso del kernel es el monitor de referencia; en una aplicación web, es el middleware de autorización por el que pasa cada solicitud.

Esto importa para DAC porque la discreción del dueño solo vale tanto como la puerta que la hace cumplir. Si un atacante puede llegar a un archivo por un camino que salta la comprobación de permisos — una exportación NFS mal configurada, un respaldo expuesto sin ACL, un endpoint de depuración que lee archivos directamente — entonces el cuidadoso chmod del dueño no significa nada. Todos los modelos de este módulo dan por supuesto, en última instancia, un monitor de referencia que funciona debajo. Cuando más adelante conozcas el Policy Enforcement Point en el módulo de arquitectura de autorización, reconócelo como la idea del monitor de referencia, ascendida a un componente de primera clase y a escala de red.

DAC en la práctica n.º 1: los permisos de archivo de Linux

La implementación canónica de DAC está en la máquina desde la que probablemente lees esto. Cada archivo en un sistema tipo Unix tiene un dueño, un grupo y tres conjuntos de bits de permiso — lectura (r), escritura (w), ejecución (x) — para el dueño, el grupo y los otros. Ejecuta ls -l y lo ves:

-rwxr-x---  1 sara  finance  8451 Jul 15 09:03 deploy.sh

Leyendo de izquierda a derecha tras el guion de tipo de archivo: la dueña sara tiene rwx (leer, escribir, ejecutar); el grupo finance tiene r-x (leer y ejecutar, sin escribir); todos los demás tienen --- (nada). La dueña lo fijó, y la dueña puede cambiarlo en cualquier momento con chmod, o entregar el archivo a otro dueño con chown. Esa discreción es todo el punto — ningún administrador tuvo que aprobarlo, y ninguna política central lo dictó. sara decidió.

Los permisos suelen escribirse en octal: cada terna rwx se convierte en un dígito (r=4, w=2, x=1), así que -rwxr-x--- es 750. chmod 640 informe.txt significa dueño lectura+escritura, grupo lectura, otros nada. Vale la pena interiorizar esto porque es la notación de control de acceso más común del mundo, y toda revisión de incidentes de DevOps termina incluyendo a alguien que descubre un archivo secreto dejado en 644 (legible por todo el mundo) cuando debía estar en 600.

Las ACL POSIX: DAC más allá de dueño/grupo/otros

El modelo de tres niveles dueño/grupo/otros es tosco: ¿qué pasa si sara quiere dar acceso de escritura exactamente a otro usuario, david, sin meterlo en el grupo finance? Los bits clásicos no pueden expresar eso. Las ACL POSIX extienden el mismo modelo discrecional con entradas con nombre. Con setfacl -m u:david:rw informe.txt, sara concede a david lectura-escritura directamente; getfacl enumera el conjunto completo. Esto sigue siendo DAC puro — la dueña extiende sus propias concesiones discrecionales a una audiencia más amplia y precisa — pero elimina el techo de expresividad de los tres niveles clásicos. Es el puente de “dueño/grupo/otros” hacia el quién-puede-hacer-qué arbitrario de una ACL completa.

Las capabilities no son pieza de museo

Es tentador archivar las capabilities bajo “historia”, pero silenciosamente hacen funcionar la infraestructura moderna. Un descriptor de archivo que pasas a un proceso hijo es una capability. Una URL prefirmada de S3 es una capability: quien tenga el enlace puede descargar el objeto, sin comprobación de identidad. Un token bearer de OAuth, un token de cuenta de servicio de Kubernetes, un JWT en una cabecera Authorization, una cadena de conexión a base de datos — todos son capabilities en el sentido estricto: poseer es poder. El modelo de object-capability lleva esto a su conclusión y construye sistemas enteros donde la única forma de actuar sobre un recurso es tener una referencia a él, lo que sostiene una forma muy limpia de mínima autoridad — un componente solo puede afectar aquello que se le entregó explícitamente. La razón por la que esto importa aquí es que las capabilities heredan el rasgo de propagación de DAC en su forma más aguda: una capability es trivialmente copiable y, como veremos, dolorosamente difícil de revocar.

DAC en la práctica n.º 2: las DACL de Windows

Windows hace el modelo de ACL explícito y central. Cada objeto asegurable (archivo, clave del registro, servicio, impresora) lleva un descriptor de seguridad, y dentro de él una Lista de Control de Acceso Discrecional (DACL) — el nombre mismo te dice el modelo. La DACL es una lista ordenada de Entradas de Control de Acceso (ACE), cada una de las cuales concede o deniega un derecho específico (leer, escribir, borrar, tomar posesión) a un principal de seguridad específico (un usuario o grupo identificado por un SID).

Cuando un proceso intenta abrir un objeto, el kernel de Windows recorre la DACL entrada por entrada, acumulando los derechos concedidos y honrando primero las ACE de denegación explícita, hasta que tiene lo suficiente para satisfacer la solicitud — o se queda sin entradas y deniega. El dueño del objeto siempre puede modificar la DACL, que es precisamente lo que la hace discrecional. Windows superpone mucho encima de esto — herencia desde contenedores padre, una SACL aparte para auditoría — pero el núcleo es una ACL por objeto que el dueño controla. Es DAC con una superficie de grado empresarial.

Por qué el orden de las ACE es una decisión de seguridad

Esa frase “honrando primero las ACE de denegación explícita” esconde una trampa real. Una ACL no es un conjunto; es una lista ordenada, y la evaluación se detiene en cuanto los derechos acumulados satisfacen la solicitud. Pon una entrada de permitir antes de una de denegar que debía anularla, y puede que la denegación nunca se alcance. Por eso Windows impone un orden canónico (denegaciones explícitas, luego permisos explícitos, luego entradas heredadas) y por eso mezclar ACE de “denegar” y “permitir” a mano es una fuente clásica de sobre-permiso accidental. La lección se generaliza: cualquier sistema de ACL que admita entradas negativas hace del orden parte de la política, y una ACL correcta como conjunto puede seguir siendo incorrecta como lista. Prefiere expresar la intención mediante concesiones positivas a audiencias estrechas antes que apilar denegaciones sobre audiencias amplias.

DAC en la práctica n.º 3: bases de datos y la nube

El control discrecional está en todas partes una vez que aprendes a verlo. En SQL, GRANT SELECT ON cuentas TO daniel es una concesión discrecional; añade WITH GRANT OPTION y le has entregado literalmente a Daniel el derecho de propagación de DAC — ahora puede conceder SELECT a otros, y el acceso se expande hacia afuera desde el dueño original. Los almacenes de objetos de la nube empezaron igual: las ACL de objeto de Amazon S3 permiten al dueño de un objeto conceder lectura a cuentas específicas, aunque AWS ahora aleja a sus clientes de las ACL hacia políticas gestionadas de forma central, precisamente porque las concesiones discrecionales sin gestión son difíciles de gobernar a escala.

Y toda herramienta de colaboración de consumo es DAC en el fondo. Cuando pulsas Compartir en un Google Doc y tecleas el correo de un colega, eres el dueño añadiendo una ACE a la ACL de ese documento. Cuando concedes “Editor” y esa persona puede volver a compartirlo, has cedido la opción de concesión. Toda la experiencia del software colaborativo moderno es una cara amable sobre el Control de Acceso Discrecional.

El problema del caballo de Troya: el pecado original de DAC

DAC es cómodo, intuitivo y ubicuo — y tiene una debilidad estructural que ninguna configuración cuidadosa arregla. DAC controla el acceso a los objetos, pero no controla lo que le pasa a la información después del acceso. Una vez que un sujeto puede leer datos, el modelo no tiene voz sobre si los copia, los reenvía o los pega en algún lugar legible por todo el mundo.

La ilustración clásica es el caballo de Troya. Supón que sara tiene acceso de lectura a un archivo sensible. daniel, que no lo tiene, le da a sara una herramienta de aspecto útil — un formateador, un linter, lo que sea. Cuando sara la ejecuta, ese programa corre con los derechos de Sara. Nada impide que lea silenciosamente el archivo sensible (que Sara puede leer) y escriba una copia en un lugar que Daniel controla. Sara nunca pretendió filtrar nada; el programa abusó de los derechos que ella legítimamente posee. DAC no puede impedir esto, porque desde la vista del sistema el acceso estaba perfectamente autorizado — era Sara leyendo su propio archivo.

Esto también se llama el problema del diputado confundido (confused deputy), nombrado por Norm Hardy en 1988 a partir de un caso real: un compilador que podía escribir registros de facturación en un directorio protegido recibió de un usuario común la petición de escribir ahí su salida, y diligentemente sobrescribió el archivo de facturación — abusando de su propia autoridad por cuenta de un usuario. Un programa con privilegios es engañado para ejercerlos a favor de alguien que carece de ellos. Es la razón fundamental por la que los entornos de alta seguridad no pueden apoyarse solo en DAC: los permisos discrecionales viajan con el proceso, no con una política sobre los datos, así que la información fluye a donde el código en ejecución la lleve. Controlar ese flujo es exactamente para lo que se inventó el Control de Acceso Obligatorio — el tema del siguiente artículo.

Fortalezas y debilidades, con honestidad

DAC domina por razones reales, y falla por razones igual de reales. Sostener ambas a la vista es el punto de estudiarlo.

Fortalezas. Es simple e intuitivo — la propiedad se corresponde con cómo la gente ya piensa en sus cosas. Es flexible e inmediato: sin ticket, sin administrador, sin revisión de política para compartir un archivo con un colega. Es descentralizado, lo que significa que escala socialmente — millones de usuarios gestionan sus propios recursos sin un cuello de botella. Y es universal: todo sistema operativo, base de datos y herramienta de colaboración lo habla, así que es la lengua franca del acceso.

Debilidades. No hay política central — la organización no puede fácilmente enunciar ni hacer cumplir una regla como “nadie fuera de Finanzas puede jamás leer la nómina”, porque cada dueño decide de forma independiente. Las concesiones se acumulan en abuso de privilegios, y como están dispersas por los objetos, son difíciles de auditar (“¿quién puede leer esto?” se responde por archivo; “todo lo que Daniel puede alcanzar” no). Es vulnerable al malware y al diputado confundido, ya que el código en ejecución hereda los derechos del usuario. Y no ofrece ningún control de flujo de información — la fuga del caballo de Troya de arriba le es invisible. En resumen: DAC optimiza para la comodidad del dueño, no para la garantía de la organización.

Revocación: el fallo silencioso

Conceder es fácil bajo DAC; quitar el acceso es donde se desmorona en silencio. Con las ACL, la revocación es al menos localizable en principio — editas la lista del objeto — pero en la práctica las concesiones están dispersas por miles de objetos, así que revocar por completo a una persona significa encontrar cada ACE en la que aparece, en todas partes, lo cual ningún sistema guiado por dueños rastrea de forma central. Con las capabilities es peor: una vez que has repartido un token infalsificable que dice “el portador puede leer X”, en general no puedes des-emitirlo. Los arreglos clásicos son todos incómodos — añadir una capa de indirección para poder invalidar el destino, dar a las capabilities vidas cortas para que caduquen, o mantener una lista de revocación que luego debes comprobar en cada uso (lo que silenciosamente vuelve tu capability en una consulta de ACL).

Ya viste esta tensión en el módulo anterior: revocar una sesión o un token de OAuth es difícil por exactamente la misma razón — un token bearer es una capability. Reconocer la revocación como una debilidad general del acceso discrecional basado en posesión — no una peculiaridad de un sistema — es una de las cosas más útiles que llevarte de este artículo. Cuando un auditor pide “demuestra que este exproveedor ya no puede alcanzar nada”, un patrimonio solo-DAC no puede responder limpiamente, y esa brecha es un motor directo de los modelos más centralizados que vienen.

Un ejemplo trabajado: la carpeta de investigación compartida

Hazlo concreto. Sara es dueña de una carpeta /research/roadmap y la fija en 750 — ella tiene acceso completo, su grupo product puede leer y ejecutar (navegar), los otros nada. Daniel, en soporte, necesita un documento. Sara añade una ACL POSIX: setfacl -m u:daniel:r /research/roadmap/q3.pdf. Limpio, inmediato, sin administrador de por medio — DAC en su mejor versión.

Ahora aparecen las grietas. Daniel, servicial como siempre, reenvía q3.pdf a un socio por correo — DAC nunca controló la copia. Un mes después, seguridad pregunta “¿quién tiene acceso al roadmap?” y no hay un solo lugar donde responderlo; las concesiones están repartidas por la carpeta, las ACL de archivos individuales y la pertenencia a grupos. Luego Daniel deja la empresa: su entrada ACL personal en q3.pdf persiste porque ningún proceso central sabe quitar las concesiones discrecionales por archivo. Cada uno de estos problemas es DAC siendo exactamente lo que es — guiado por el dueño y descentralizado — y cada uno de ellos es una razón por la que los modelos posteriores añaden estructura encima.

Contrasta cómo se comporta la misma carpeta una vez que se superpone un modelo central. Bajo RBAC, el acceso a /research fluiría de un rol (“Producto — Roadmap”) que un proceso de altas-cambios-bajas adjunta y desadjunta automáticamente, así que la salida de Daniel le quita el acceso en un solo lugar y la pregunta “¿quién puede leer esto?” tiene una única respuesta autoritativa. Bajo MAC, q3.pdf podría llevar una etiqueta Confidencial que prohíbe de plano la exportación a un canal no clasificado, así que Daniel no habría podido enviarlo por correo en primer lugar. DAC no hizo nada mal aquí — hizo exactamente lo que su dueño le dijo — pero “exactamente lo que el dueño le dijo” no es lo mismo que “lo que la organización necesita”, y esa brecha es la razón por la que existe cada artículo restante de este módulo. Ten presente esta carpeta; la volveremos a resolver, mejor, con cada nuevo modelo.

Dónde encaja DAC entre los modelos

DAC no está “mal” — es una capa. En la práctica los sistemas modernos apilan modelos: el sistema de archivos hace cumplir los bits DAC, SELinux hace cumplir las etiquetas MAC encima de ellos, la aplicación hace cumplir los roles RBAC, y un motor de políticas puede hacer cumplir reglas ABAC encima de eso. Una solicitud debe satisfacer todas las capas que apliquen. DAC es casi siempre la capa inferior — la base guiada por el dueño — con modelos más centralizados añadidos allí donde la organización necesita garantías que la discreción del dueño no puede dar.

Entender DAC primero es lo que hace legible al resto de la familia. RBAC existe porque gestionar miles de concesiones discrecionales individuales no escala, así que agrupamos permisos en roles. ABAC existe porque los roles no pueden capturar contexto como la hora y la ubicación. MAC existe porque la discreción misma es el riesgo cuando la información no debe fluir. Cada modelo de este módulo es, en parte, una respuesta a algo que DAC no puede hacer.

La tabla de abajo adelanta ese encuadre — léela ahora como un mapa del módulo, y de nuevo tras cada artículo, cuando los compromisos signifiquen más.

Fíjate en que DAC está solo en un aspecto: es el único modelo de la familia donde un usuario final común rutinariamente redacta política. Todos los demás modelos mueven esa autoría hacia administradores, equipos de seguridad o política formal — cambiando la inmediatez de DAC por control, escala y auditabilidad. Ese intercambio es el hilo conductor de todo el módulo.

Recap

El Control de Acceso Discrecional es el cimiento contra el que se construye el resto de la autorización:

1. El dueño decide. El acceso se fija a discreción del dueño del recurso, que puede conceder derechos a otros — y los receptores a menudo pueden pasar esos derechos adelante (la propiedad de propagación de la definición del Libro Naranja).
2. Es la matriz de control de acceso, rebanada por objeto. DAC se implementa normalmente como ACL (derechos guardados con el objeto); las capabilities son la misma matriz rebanada por sujeto y reaparecen como tokens y URL firmadas.
3. Gobierna el mundo. Los permisos de Linux y las ACL POSIX, las DACL de Windows, el GRANT de SQL, las ACL de objeto de S3 y todo botón de “Compartir” son DAC.
4. Su debilidad es la propagación, no el acceso. DAC controla quién abre un objeto pero no qué pasa con los datos después — de ahí el problema del caballo de Troya / diputado confundido y la falta de control de flujo de información.
5. Es una capa, no toda la historia. DAC es la base guiada por el dueño; MAC, RBAC y ABAC añaden la política central, la escalabilidad y el contexto que no puede.

Tres preguntas para ponerte a prueba

1. Un colega dice “usamos ACL, así que no hacemos DAC”. Explica por qué esa afirmación confunde un modelo con una implementación, y describe un caso donde un sistema basado en ACL haría cumplir, aun así, una política no discrecional.
2. Recorre el ataque del caballo de Troya con tus propias palabras para un programa que un usuario descarga y ejecuta. ¿Qué propiedad exacta de DAC hace posible la fuga, y qué modelo posterior de este módulo la impediría?
3. Tu jefe quiere responder “¿quién puede leer el archivo de nómina?” y “todo lo que Daniel puede acceder” desde el mismo sistema. ¿Cuál de esas dos preguntas responde barato una ACL, cuál responde barato una capability, y por qué ninguna responde bien ambas?

Ejercicios prácticos

1. Lee una ACL real. En cualquier máquina Linux o macOS, crea un archivo, ejecuta ls -l para leer su modo, luego cámbialo con chmod y observa moverse los bits. Si tu sistema lo admite, usa setfacl/getfacl (Linux) o ls -le (macOS) para añadir e inspeccionar una entrada ACL de usuario con nombre. Anota el modo octal para “dueño lectura-escritura, grupo lectura, otros nada”.
2. Encuentra el derecho de propagación. En una base de datos a la que puedas acceder (SQLite basta conceptualmente), o en una consola de IAM en la nube, localiza el mecanismo equivalente a WITH GRANT OPTION — el ajuste que permite a un receptor volver a conceder. Anota quién, en tu entorno, lo tiene ahora, y si eso es intencional.
3. Audita una dispersión discrecional. Elige una carpeta compartida (Google Drive, SharePoint, un recurso de red). Enumera a todos los que tienen acceso y cómo lo obtuvieron (compartición directa, grupo, herencia, re-compartición). Fíjate en lo difícil que es obtener una respuesta completa — esa dificultad es la debilidad de gobernanza de DAC, y es el problema que RBAC se propone domar.