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

La hoja de ruta que se fue por la puerta

Sara, ingeniera del equipo de producto, es dueña de una carpeta llamada /research/roadmap. La configura para tener acceso total, que su grupo de producto pueda explorarla y leerla y que nadie más vea nada. Daniel, que trabaja en soporte, necesita un documento de esa carpeta para responder a un cliente, así que Sara le da acceso de lectura a q3.pdf con un solo comando. Sin ticket, sin administrador, hecho en diez segundos. Una semana después, Daniel, con toda la buena intención, le manda el PDF por correo a un socio. Un mes más tarde, seguridad pregunta quién tiene acceso a la hoja de ruta y nadie sabe dar una respuesta completa. Cuando Daniel deja la empresa, su permiso personal sobre q3.pdf se queda ahí, porque nada central sabe que existe.

Cada uno de esos hechos es el control de acceso discrecional (DAC) haciendo exactamente aquello para lo que se diseñó. Los artículos anteriores respondían a una sola pregunta de muchas maneras: ¿quién eres? Los factores, el MFA, la biometría, el SSO y las sesiones son maquinaria de autenticación. A partir de aquí el dominio pasa a la otra mitad del acceso: una vez que sabemos quién eres, ¿qué puedes hacer? Eso es la autorización, y a la familia de modelos que la responden se la suele llamar xBAC, DAC, MAC, RBAC, ABAC, PBAC, ReBAC, NGAC, porque casi todos terminan en “Based Access Control”.

Empezamos donde empezó el propio control de acceso. El DAC es el modelo más antiguo y todavía el más extendido, y su idea central está en la palabra: el acceso queda a criterio del dueño. Si creas un fichero, es tuyo, y decides quién más puede leerlo o cambiarlo. El sistema aplica con fidelidad lo que elijas, pero no impone ninguna política propia. Cada vez que haces clic derecho en un documento y eliges “Compartir”, o ejecutas chmod sobre un script, estás usando DAC.

La matriz de control de acceso

Antes del DAC, el MAC o el RBAC hay una estructura abstracta que todos expresan de una forma u otra: la matriz de control de acceso que describió Butler Lampson en 1971. Imagina una cuadrícula enorme. Cada sujeto, un usuario o un proceso, es una fila. Cada objeto, un fichero, un dispositivo, un registro, es una columna. Cada celda enumera los derechos que ese sujeto tiene sobre ese objeto: leer, escribir, ejecutar, poseer, borrar.

Como concepto, la matriz es perfecta; como implementación, es imposible. Con miles de usuarios y millones de objetos sería enorme y estaría casi vacía. Así que los sistemas reales nunca la guardan tal cual. La guardan cortada de una de dos maneras, y esa elección define dos tradiciones completas.

Si la cortas por columnas, coges un objeto y enumeras a todos los que pueden tocarlo. Esa columna, pegada al objeto, es una lista de control de acceso (ACL). Un fichero dice, en la práctica, “Sara puede leerme y escribirme; Daniel puede leerme”. Las ACL responden al instante a “¿quién puede acceder a este objeto?”, porque la respuesta vive con el objeto. Así funcionan los sistemas de ficheros, y es la forma dominante de implementar el DAC.

Si la cortas por filas, coges un sujeto y enumeras todo lo que puede tocar. Esa fila, en manos del sujeto, es un conjunto de capacidades (capabilities), tokens infalsificables que dicen cada uno “quien tenga esto puede hacer X sobre el objeto Y”. Las capacidades responden al instante a “¿a qué puede llegar este sujeto?”. Son menos habituales en los sistemas de ficheros corrientes, pero aparecen por todas partes en los sistemas modernos: una URL firmada, un bearer token de OAuth, el token de una cuenta de servicio de Kubernetes y un descriptor de fichero son en la práctica capacidades, en las que tenerlo es el permiso.

Las ACL y las capacidades no son tecnologías rivales, sino la misma matriz vista desde dos lados. Las ACL viven con el objeto y se revisan fácilmente por recurso. Las capacidades viven con el sujeto, se revisan fácilmente por usuario y se delegan con facilidad. La mayoría de los sistemas reales se basan en ACL y añaden capacidades allí donde importa delegar.

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 criterio, 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; si no, se deniega. Una flecha aparte muestra que un sujeto al que se le ha concedido un derecho, incluida la opción de concederlo, puede pasarlo a otro sujeto, lo que ilustra la propagación de derechos.
  OWN[Dueño] -->|fija a su criterio| ACL[Lista de control de acceso del objeto]
  OWN -->|concede derechos a| SUBJ[Otros sujetos]
  REQ[Un sujeto pide acceso] --> RM{Monitor de referencia}
  RM -->|consulta| ACL
  ACL -->|el derecho está| ALLOW[Permitir]
  ACL -->|el derecho no está| DENY[Denegar]
  SUBJ -.->|puede pasar el derecho| SUBJ2[Otro sujeto más]

Por qué “discrecional” es un término de defensa

Los permisos de ficheros parecen una simple comodidad de ingeniería, pero el vocabulario viene de la investigación militar, y la historia explica la forma del modelo. En los años 60, Multics introdujo las ACL por segmento y los anillos de protección que Unix simplificó después en los bits de dueño, grupo y otros. En 1985, el Departamento de Defensa de Estados Unidos publicó los Trusted Computer System Evaluation Criteria, el “Libro Naranja”, que separó formalmente dos tipos de control: el discrecional, movido por los dueños, y el obligatorio, movido por etiquetas, que es el tema del siguiente artículo. Definía el DAC como la restricción del acceso “según la identidad de los sujetos o de los grupos a los que pertenecen”, con una propiedad clave: un sujeto que tiene un permiso es “capaz de pasárselo a cualquier otro sujeto”. Esa capacidad de ir pasando permisos es la gran comodidad del DAC y su debilidad de fondo, y atraviesa todo este artículo.

El Libro Naranja era una norma de compras. Para vender sistemas al gobierno estadounidense había que cumplir una clase evaluada, y las clases altas exigían controles obligatorios porque se entendía que los discrecionales no bastaban para datos clasificados. Así que cuando hoy haces chmod sobre un fichero, estás usando un mecanismo que una norma de seguridad de hace cuarenta años clasificó como el más débil de dos niveles, y que se mantiene porque es imprescindible para el trabajo diario. Ese linaje pone al DAC en su sitio: no es un defecto que haya que eliminar, sino una herramienta limitada a propósito que el resto del campo se construyó para complementar.

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

El DAC describe quién decide la política, pero algo tiene que aplicarla en cada acceso, sin excepciones y sin que se pueda sortear. Ese algo es el monitor de referencia, un concepto tan antiguo como la teoría del control de acceso. Tiene que invocarse siempre, para que ninguna vía de acceso se lo salte; ser inalterable, para que nada pueda desactivarlo ni editarlo; y ser lo bastante pequeño como para verificarlo, para que puedas fiarte de él. En un sistema operativo, la comprobación de acceso del núcleo es el monitor de referencia; en una aplicación web, es el middleware de autorización por el que pasa cada petición.

Esto importa para el DAC porque el criterio del dueño vale lo que valga la puerta que lo aplica. Si un atacante puede llegar a un fichero por un camino que se salta la comprobación de permisos, una exportación NFS mal configurada, una copia de seguridad expuesta sin sus ACL, un endpoint de depuración que lee ficheros directamente, los permisos cuidadosos de Sara no sirven de nada. Todos los modelos de esta parte del dominio dan por hecho un monitor de referencia que funciona por debajo. Cuando más adelante veas el punto de aplicación de políticas de los artículos de arquitectura de autorización, reconócelo como el monitor de referencia ascendido a componente de primera clase y a escala de red.

El DAC en la práctica: permisos de ficheros en Linux

La implementación clásica del DAC está, probablemente, en la máquina desde la que lees esto. Cada fichero de un sistema tipo Unix tiene un dueño, un grupo y tres juegos de bits de permiso, lectura (r), escritura (w) y ejecución (x), para el dueño, el grupo y todos los demás. Ejecuta ls -l y los verás:

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

Tras el guion inicial del tipo de fichero, la dueña sara tiene rwx; el grupo finance tiene r-x, lectura y ejecución pero no escritura; y todos los demás tienen ---, nada. Lo fijó Sara, y puede cambiarlo cuando quiera con chmod, o pasarle el fichero a otro dueño con chown. Ese criterio propio es toda la gracia. Ningún administrador lo aprobó y ninguna política central lo dictó; decidió Sara.

Los permisos se suelen escribir en octal, convirtiendo cada trío rwx en un dígito (r=4, w=2, x=1), así que -rwxr-x--- es 750, y chmod 640 report.txt significa lectura y escritura para el dueño, lectura para el grupo y nada para los demás. Conviene interiorizarlo, porque es la notación de control de acceso más común del mundo, y tarde o temprano toda revisión de incidentes de DevOps incluye a alguien descubriendo un fichero secreto en 644, legible por cualquiera, cuando debería estar en 600.

Unix tiene además un bit especial, setuid, que hace que un programa se ejecute con los privilegios del dueño del fichero en lugar de los de quien lo llama. Existe por buenas razones, porque passwd tiene que editar un fichero que es de root, pero un binario setuid-root con un fallo es un camino directo al compromiso total. Es también la semilla del problema de fondo del DAC: un programa que actúa con privilegios que la persona que lo ejecuta no controla directamente, el “delegado confundido” al que volveremos.

El modelo de dueño, grupo y otros es grueso. ¿Y si Sara quiere dar acceso de lectura exactamente a una persona, Daniel, sin meterlo en el grupo de producto? Los bits clásicos no pueden expresarlo. Las ACL POSIX amplían el mismo modelo discrecional con entradas con nombre: setfacl -m u:daniel:r q3.pdf le da a Daniel lectura directamente, y getfacl muestra el conjunto completo. Sigue siendo DAC puro, la dueña extendiendo sus propias concesiones a un público más amplio y preciso, pero quita el techo de los tres niveles clásicos. Es justo el comando que ejecutó Sara.

Las capacidades, por su parte, no son una pieza de museo. Un descriptor de fichero que se pasa a un proceso hijo es una capacidad. Una URL prefirmada de S3 también: quien tenga el enlace puede descargar el objeto, sin comprobar ninguna identidad. Un bearer token de OAuth, el token de una cuenta de servicio de Kubernetes, un JWT en una cabecera Authorization o una cadena de conexión a una base de datos son capacidades en sentido estricto. El modelo de capacidades de objeto lleva esto hasta el final y construye sistemas enteros en los que la única forma de actuar sobre un recurso es tener una referencia a él, lo que permite una forma muy limpia de mínima autoridad. Pero las capacidades heredan el rasgo de propagación del DAC en su forma más afilada: se copian sin esfuerzo y, como veremos, son dolorosamente difíciles de revocar.

El DAC en la práctica: las DACL de Windows

Windows hace explícito el modelo de ACL. Cada objeto protegible, un fichero, una clave del registro, un servicio, una impresora, lleva un descriptor de seguridad y, dentro, una Discretionary Access Control List (DACL), un nombre que ya anuncia 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 concreto, como leer, escribir, borrar o tomar posesión, a una entidad de seguridad concreta, un usuario o un grupo identificado por un SID.

Cuando un proceso intenta abrir un objeto, el núcleo de Windows recorre la DACL entrada a entrada, acumulando derechos concedidos, hasta tener suficientes para la petición o quedarse sin entradas y denegarla. El dueño del objeto siempre puede cambiar la DACL, y eso es justo lo que la hace discrecional. Windows añade mucho por encima, la herencia desde los contenedores padre y una SACL aparte para la auditoría, pero el núcleo es una ACL por objeto que controla el dueño.

El orden importa aquí más de lo que parece. Una ACL no es un conjunto; es una lista ordenada, y la evaluación se para en cuanto los derechos acumulados bastan para la petición. Pon una entrada de permitir antes de una de denegar que debía anularla y puede que nunca se llegue a la de denegar. Por eso Windows impone un orden canónico, primero las denegaciones explícitas, después los permisos explícitos y luego las entradas heredadas, y por eso mezclar a mano entradas de denegar y permitir es una fuente clásica de permisos de más por accidente. La lección vale en general: cualquier sistema de ACL que admita entradas negativas convierte el orden en parte de la política, y una ACL correcta como conjunto puede estar mal como lista. Mejor conceder en positivo a públicos estrechos que apilar denegaciones sobre públicos amplios.

El DAC en la práctica: bases de datos, la nube y cada botón de Compartir

Cuando sabes lo que buscas, el control discrecional está en todas partes. En SQL, GRANT SELECT ON accounts TO daniel es una concesión discrecional, y añadir WITH GRANT OPTION le entrega literalmente a Daniel el derecho de propagación del DAC: ahora puede conceder SELECT a otros, y el acceso se extiende hacia fuera desde el dueño original. Los almacenes de objetos en la nube empezaron igual. Las ACL de objeto de Amazon S3 permiten al dueño de un objeto dar lectura a cuentas concretas, aunque AWS ahora aleja a sus clientes de las ACL hacia políticas gestionadas de forma central, precisamente porque las concesiones discrecionales sin gestionar son difíciles de gobernar a escala.

Y todas las herramientas de colaboración de consumo son DAC en el fondo. Cuando pulsas Compartir en un documento de Google y escribes la dirección de un compañero, eres el dueño añadiendo una entrada a la ACL de ese documento. Cuando lo haces editor y puede volver a compartirlo, le has entregado la opción de conceder. Toda la experiencia del software colaborativo moderno es una cara amable del control de acceso discrecional.

El caballo de Troya: el pecado original del DAC

El DAC es cómodo, intuitivo y omnipresente, y tiene una debilidad estructural que ninguna configuración cuidadosa arregla. Controla el acceso a los objetos, pero no lo que pasa con la información después del acceso. Una vez que un sujeto puede leer unos datos, el modelo no tiene nada que decir sobre si los copia, los reenvía o los pega en un sitio público. Así fue como la hoja de ruta llegó al buzón de un socio.

El ejemplo clásico es el caballo de Troya. Supón que Sara puede leer un fichero sensible y que David, que no puede, le da una herramienta con buena pinta, un formateador o un linter. Cuando Sara la ejecuta, el programa corre con los derechos de Sara. Nada le impide leer en silencio el fichero sensible, que Sara tiene permiso para leer, y escribir una copia en un sitio que controla David. Sara nunca quiso filtrar nada; el programa abusó de derechos que ella tiene legítimamente. El DAC no puede impedirlo, porque desde el punto de vista del sistema el acceso estaba perfectamente autorizado. Era Sara leyendo su propio fichero.

También se le llama el problema del delegado confundido (confused deputy), un nombre que le puso Norm Hardy en 1988 a partir de un caso real: a un compilador que podía escribir registros de facturación en un directorio protegido le pidió un usuario normal que dejara su salida ahí, y sobrescribió obedientemente el fichero de facturación, usando mal su propia autoridad en nombre del usuario. Se engaña a un programa con privilegios para que los use en favor de alguien que no los tiene. Es la razón de fondo por la que los entornos de alta seguridad no pueden apoyarse solo en el DAC: los permisos discrecionales viajan con el proceso, no con una política sobre los datos, así que la información va adonde la lleve el código en ejecución. Controlar ese flujo es para lo que se inventó el control de acceso obligatorio.

Recuerda el principio de “asume que ya te han comprometido” de Zero Trust. Con DAC, una sola cuenta comprometida o una sola dependencia maliciosa heredan todo lo que ese usuario puede alcanzar y pueden compartirlo libremente, sin ninguna política central que impida que los datos se extiendan de lado. Por eso el control discrecional por sí solo encaja mal con la protección de información de verdad sensible, y por eso existen los demás modelos de esta parte del dominio.

Puntos fuertes y débiles, con honestidad

El DAC domina por razones reales y falla por razones igual de reales. Es sencillo e intuitivo, porque la propiedad encaja con cómo la gente ya piensa en sus cosas. Es flexible e inmediato, sin ticket, sin administrador y sin revisión de políticas para compartir un fichero con un compañero. Es descentralizado, lo que significa que escala socialmente: millones de personas gestionan sus propios recursos sin cuello de botella. Y es universal, lo hablan todos los sistemas operativos, bases de datos y herramientas de colaboración.

Por el otro lado, no hay política central, así que la organización no puede expresar ni imponer con facilidad una regla como “nadie fuera de Finanzas puede leer jamás las nóminas”, porque cada dueño decide por su cuenta. Las concesiones se acumulan en una acumulación de privilegios, y como están repartidas por los objetos, son difíciles de auditar: “¿quién puede leer esto?” se responde fichero a fichero, pero “todo lo que puede alcanzar Daniel” no. Está expuesto al malware y al delegado confundido, porque el código en ejecución hereda los derechos del usuario. Y no ofrece ningún control sobre el flujo de la información, lo que deja invisible la fuga del caballo de Troya. El DAC optimiza la comodidad del dueño, no las garantías de la organización.

Revocación: el fallo silencioso

Conceder es fácil con DAC; retirar el acceso es donde se viene abajo sin hacer ruido. Con las ACL, la revocación al menos se puede localizar en teoría, porque editas la lista del objeto, pero en la práctica las concesiones están repartidas por miles de objetos, así que revocar del todo a una persona supone encontrar cada entrada en la que aparece, en todas partes, y ningún sistema movido por los dueños lleva esa cuenta de forma central. El permiso que se le quedó a Daniel sobre q3.pdf es la versión cotidiana de esto. Con las capacidades es peor: una vez entregado un token infalsificable que dice “quien tenga esto puede leer X”, en general no se puede deshacer. Los arreglos clásicos son todos incómodos: añadir una capa de indirección para poder invalidar el destino, dar a las capacidades una vida corta para que caduquen o mantener una lista de revocación que hay que consultar en cada uso, lo que convierte sin decirlo la capacidad otra vez en una consulta de ACL.

Esta tensión ya la conoces. Revocar una sesión o un token de OAuth es difícil exactamente por lo mismo, porque un token al portador es una capacidad. Ver la revocación como una debilidad general del acceso discrecional basado en la posesión, y no como una manía de un sistema concreto, es una de las cosas más útiles que te puedes llevar de este artículo. Cuando un auditor te pide que demuestres que un antiguo contratista ya no puede llegar a nada, un entorno construido solo con DAC no puede responder con limpieza, y ese hueco es lo que impulsa los modelos más centralizados que vienen.

De vuelta a la carpeta de la hoja de ruta

Mira otra vez la carpeta de Sara con todo esto en la cabeza. Su configuración, 750 en la carpeta más una ACL POSIX para Daniel sobre un fichero, era el DAC en su mejor versión: limpio, inmediato, sin administrador. El PDF reenviado es la falta de control del DAC sobre el flujo de la información. El “¿quién tiene acceso?” sin respuesta son las concesiones dispersas del DAC, repartidas entre el modo de la carpeta, las ACL de cada fichero y la pertenencia a grupos. Y el permiso que se le quedó a Daniel es el problema de revocación del DAC.

Ahora imagina la misma carpeta con un modelo central encima. Con RBAC, el acceso a /research vendría de un rol, “Producto, hoja de ruta”, que el proceso de altas, cambios y bajas asigna y retira automáticamente, así que la salida de Daniel le quitaría el acceso en un solo sitio y “¿quién puede leer esto?” tendría una única respuesta con autoridad. Con MAC, q3.pdf podría llevar una etiqueta de Confidencial que prohíbe enviarlo por un canal no clasificado, así que Daniel ni siquiera habría podido mandarlo por correo. El DAC no hizo nada mal; hizo exactamente lo que le dijo su dueña. Pero lo que dice la dueña no es lo mismo que lo que necesita la organización, y ese hueco es la razón de ser del resto de estos artículos. Volveremos a resolver esta carpeta, y mejor, con cada modelo nuevo.

Dónde encaja el DAC entre los modelos

El DAC no está mal; es una capa. Los sistemas reales apilan modelos: el sistema de ficheros aplica los bits del DAC, SELinux aplica etiquetas MAC por encima, la aplicación aplica roles RBAC y un motor de políticas puede aplicar reglas ABAC encima de todo. Una petición tiene que cumplir todas las capas que le correspondan, y el DAC casi siempre es la de abajo, la base movida por los dueños, con modelos más centralizados añadidos allí donde la organización necesita garantías que el criterio de los dueños no puede dar.

Entender primero el DAC hace que el resto de la familia tenga sentido, porque cada modelo es en parte una respuesta a algo que el DAC no puede hacer.

El DAC está solo en un aspecto: es el único modelo de la familia en el que los usuarios finales corrientes escriben política de forma habitual. Todos los demás trasladan esa autoría a administradores, equipos de seguridad o políticas formales, y cambian la inmediatez del DAC por control, escala y capacidad de auditoría. Ese intercambio recorre todos los artículos que siguen.

Resumen

El control de acceso discrecional es la base frente a la que se construye el resto de la autorización. Decide el dueño: el acceso se fija a su criterio, y aquellos a quienes concede derechos a menudo pueden pasarlos, la propiedad de propagación del Libro Naranja. Es la matriz de control de acceso cortada por objeto, implementada casi siempre como ACL, mientras que las capacidades son la misma matriz cortada por sujeto y reaparecen como tokens y URL firmadas. Gobierna el mundo, con los permisos de Linux y las ACL POSIX, las DACL de Windows, el GRANT de SQL, las ACL de objeto de S3 y cada botón de Compartir. Su debilidad es la propagación y no el acceso: controla quién abre un objeto, pero no qué pasa con los datos después, de ahí el caballo de Troya y el delegado confundido. Y es una capa, no la historia completa, con el MAC, el RBAC y el ABAC aportando la política central, la escala y el contexto que le faltan.

Tres preguntas para ponerte a prueba

1. Un compañero dice: “Usamos ACL, así que no hacemos DAC”. Explica por qué eso confunde un modelo con una implementación, y describe un caso en que un sistema basado en ACL aplicaría aun así una política no discrecional.
2. Recorre con tus palabras el ataque del caballo de Troya para un programa que un usuario descarga y ejecuta. ¿Qué propiedad del DAC hace posible la fuga y qué modelo de más adelante en esta parte del dominio la evitaría?
3. Tu responsable quiere responder a la vez “¿quién puede leer el fichero de nóminas?” y “todo lo que puede alcanzar Daniel” desde el mismo sistema. ¿Qué pregunta responde barata una ACL, cuál responde barata una capacidad y por qué ninguna de las dos responde bien a ambas?

Ejercicios prácticos

1. Lee una ACL de verdad. En cualquier máquina Linux o macOS, crea un fichero, ejecuta ls -l para leer su modo, cámbialo con chmod y mira cómo se mueven los bits. Si tu sistema lo admite, usa setfacl y getfacl en Linux, o ls -le en macOS, para añadir y consultar una entrada de un usuario con nombre. Apunta el modo octal de “lectura y escritura para el dueño, lectura para el grupo, nada para los demás”.
2. Encuentra el derecho de propagación. En una base de datos a la que tengas acceso, o en una consola de IAM en la nube, localiza el equivalente de WITH GRANT OPTION, el ajuste que permite a quien recibe un acceso volver a concederlo. Anota quién lo tiene ahora mismo en tu entorno y si es intencionado.
3. Audita una maraña de comparticiones. Elige una carpeta compartida en Google Drive, SharePoint o una unidad de red. Haz la lista de todas las personas con acceso y de cómo lo consiguieron: compartido directo, grupo, herencia o recompartido. Fíjate en lo difícil que es obtener una respuesta completa. Esa dificultad es la debilidad de gobierno del DAC, y es el problema que el RBAC se propone domar.