Control de Acceso de Nueva Generación (NGAC): un grafo para expresarlos a todos

¿Y si un modelo pudiera expresarlos a todos?

Los cinco artículos anteriores defendieron cada uno una base distinta para el acceso: dueños, etiquetas, roles, atributos y relaciones. Cada uno era más fuerte para una forma de problema y torpe para las demás, y los sistemas reales acababan combinando dos o tres de ellos — RBAC para funciones laborales, ABAC para contexto, ReBAC para compartir — cosidos en el código de la aplicación. Eso deja una pregunta obvia sobrevolando todo el módulo: ¿existe una única estructura formal lo bastante general para expresar roles, atributos y relaciones a la vez, de modo que no tengas que atornillar motores separados? El Control de Acceso de Nueva Generación (NGAC) es la respuesta de la comunidad de estándares — un intento de unificar los modelos en lugar de añadir un sexto.

La apuesta central de NGAC es radical en su simplicidad: modela todo como un único grafo dirigido. Los usuarios, los atributos que los agrupan, los objetos, los atributos que agrupan a estos, y las políticas mismas, todos se vuelven nodos; las formas en que se relacionan se vuelven aristas. Una decisión de acceso no es entonces un emparejamiento de reglas ni una búsqueda de rol, sino una pregunta de grafo — ¿existe un camino de privilegio desde este usuario hasta este objeto, concedido por una asociación y no cortado por una prohibición? Donde ReBAC puso relaciones entre recursos en un grafo, NGAC pone la política entera — sujetos, objetos, atributos, concesiones y denegaciones — en un grafo, y deriva cada decisión de su estructura. Esa generalidad es toda la idea, y es por lo que NGAC se plantea no como un competidor de RBAC o ABAC sino como un marco en el que esos modelos son casos especiales.

Este es el broche del módulo de modelos, y lo es a propósito. Habiendo visto cada base del acceso de forma aislada, ahora estás equipado para apreciar un modelo cuyo argumento de venta es que contiene a los demás. Si NGAC llega a ser la forma dominante en que se construye la autorización sigue siendo una pregunta abierta — su ecosistema y adopción van por detrás de sus ideas — pero como forma de entender cómo se relacionan roles, atributos y relaciones entre sí, no tiene rival, y su influencia en el pensamiento moderno sobre autorización ya es profunda.

Un poco de historia: de la Policy Machine a un estándar

NGAC no apareció de la nada; es la forma estandarizada de años de investigación de NIST llamada la Policy Machine, liderada por David Ferraiolo — el mismo investigador cuyo nombre figura en el modelo RBAC original de los años noventa. Habiendo ayudado a formalizar RBAC, Ferraiolo y colegas pasaron la década de 2000 haciéndose una pregunta más profunda: en lugar de construir un mecanismo nuevo para cada tipo de política, ¿podría haber un mecanismo de control de acceso de propósito general cuyo comportamiento estuviera determinado por completo por datos configurables? La Policy Machine fue su respuesta — una máquina cuyo “programa” es un grafo, de modo que RBAC, ABAC, la seguridad multinivel y sus combinaciones se vuelven distintas configuraciones del mismo motor en lugar de motores distintos.

Esa investigación se estandarizó como NGAC: primero como INCITS 499 (2013) y luego la revisión INCITS 565, con publicaciones de NIST de apoyo (en especial el informe citado a menudo como NISTIR 7657 sobre combinación de políticas de control de acceso) desarrollando el modelo. NIST también publica una implementación de referencia de la Policy Machine, y un puñado de productos comerciales han adoptado el enfoque. El linaje importa: NGAC proviene de la misma tradición intelectual que RBAC, extendida por dos décadas de reflexión sobre cómo generalizarlo — que es exactamente por lo que puede presentar los roles como una configuración entre muchas.

Los elementos: todo es un nodo

El vocabulario de NGAC es pequeño, y aprenderlo es la mayor parte de aprender NGAC. Toda política se construye con un puñado de tipos de elemento y relación:

Tres de estas aristas hacen el trabajo de verdad, y vale la pena ser preciso con cada una. Una asignación es contención pura: user:sara → UA:engineer dice que Sara está en el atributo engineer; object:roadmap → OA:research-docs dice que el roadmap está en el atributo research-docs. Las asignaciones se encadenan, así que los atributos contienen atributos — UA:engineer → UA:staff, OA:research-docs → OA:company-files — construyendo las dos jerarquías (un lado de usuario y un lado de objeto) que dan al grafo su forma. Una asociación es la concesión que tiende un puente entre ambos lados: UA:engineer ⇒ {read, write} ⇒ OA:research-docs significa “quien esté contenido en engineer puede read y write cualquier cosa contenida en research-docs”. Una prohibición es la excepción explícita: UA:engineer ⊘ {delete} OA:company-files retira delete sin importar qué asociación pudiera concederlo de otro modo. Esa es toda la gramática — contenedores, concesiones y denegaciones sobre contenedores — y, notablemente, basta para expresar los modelos de los cinco artículos anteriores.

Cómo se calcula una decisión

Dado el grafo, decidir una solicitud ⟨usuario, operación, objeto⟩ — “¿puede Sara read roadmap.md?” — es una búsqueda bien definida, y su determinismo es gran parte del atractivo de NGAC. Informalmente, el motor hace tres cosas. Primero, calcula los contenedores de atributos que alcanza el usuario siguiendo aristas de asignación hacia arriba desde el usuario: Sara → engineer → staff. Segundo, calcula los contenedores de atributos que alcanza el objeto: roadmap → research-docs → company-files. Tercero, busca una asociación cuyo origen sea uno de los contenedores del usuario, cuyo destino sea uno de los contenedores del objeto, y cuyo conjunto de operaciones incluya la operación solicitada — aquí engineer ⇒ {read, write} ⇒ research-docs coincide. Si tal camino de privilegio existe y ninguna prohibición retira la operación por el camino, la solicitud se permite; en caso contrario se deniega.

flowchart LR
  accTitle: Cómo NGAC deriva una decisión de acceso del grafo de política
  accDescr: El procedimiento de decisión empieza con una solicitud que nombra un usuario, una operación y un objeto. El primer paso sigue aristas de asignación hacia arriba desde el usuario para recolectar todos los atributos de usuario que lo contienen, como engineer y staff. El segundo paso sigue aristas de asignación hacia arriba desde el objeto para recolectar todos los atributos de objeto que lo contienen, como research docs y company files. El tercer paso busca una asociación cuyo origen sea uno de los atributos de usuario recolectados y cuyo destino sea uno de los atributos de objeto recolectados y cuyo conjunto de operaciones incluya la operación solicitada — por ejemplo engineer a research-docs. Si no existe tal asociación, el resultado es deniega. Si existe, un cuarto paso comprueba si alguna prohibición retira la operación solicitada para este usuario sobre este objeto. Si aplica una prohibición, el resultado es deniega; en caso contrario el resultado es permite.
  R["Solicitud: usuario sara, op read, objeto roadmap"] --> UA["Recolectar atributos de usuario sobre sara:<br/>engineer, staff"]
  R --> OA["Recolectar atributos de objeto sobre roadmap:<br/>research-docs, company-files"]
  UA --> A{"¿Asociación que enlaza un atributo de usuario a uno de objeto<br/>e incluye read?<br/>ej. engineer a research-docs"}
  OA --> A
  A -->|no| D1["DENIEGA — sin camino de privilegio"]
  A -->|sí| P{"¿Alguna prohibición retira read aquí?"}
  P -->|sí| D2["DENIEGA — gana la prohibición"]
  P -->|no| PERMIT["PERMITE — el camino de privilegio sobrevive"]

Dos propiedades de este procedimiento merecen atención porque son las ventajas estelares de NGAC. Primero, es determinista y acotado: no hay ambigüedad de orden de reglas ni sutilezas de algoritmo de combinación que razonar — la respuesta es una función del grafo, y su coste escala con el tamaño del grafo, no con una pila siempre creciente de reglas escritas de forma independiente. Segundo, y más distintivo, el mismo grafo responde consultas de revisión tan naturalmente como responde consultas de acceso. “¿Qué puede acceder Sara?” es: recolecta sus atributos de usuario, sigue cada asociación que sale de ellos, y enumera los atributos de objeto (y sus contenidos) que alcanza. “¿Quién puede borrar este registro?” es la imagen especular. Estas preguntas de “revisión” por usuario y por objeto — de las que viven los auditores y los programas de recertificación de acceso, y que RBAC y sobre todo ABAC responden solo con enumeración costosa — son recorridos nativos en NGAC, porque el acceso es estructural en lugar de calculado por reglas opacas.

Por qué un grafo puede ser varias políticas: las clases de política

Una característica sutil pero poderosa es la clase de política (PC). El mismo grafo puede contener múltiples políticas simultáneamente, cada una enraizada en su propia clase de política, y un elemento puede asignarse hacia arriba a varias de ellas. La regla que las une es estricta: una solicitud se concede solo si se concede bajo cada clase de política que gobierna el objeto. Así es como NGAC expresa políticas coexistentes y de autoría independiente — una política al estilo RBAC y una política de clasificación de datos y una política de confidencialidad de proyecto pueden vivir todas en un grafo, y el acceso requiere satisfacer todas a la vez, exactamente como la intersección de intereses que encuentras en la gobernanza real.

Esto importa porque las organizaciones reales nunca tienen una sola política. Legal quiere reglas de clasificación; una unidad de negocio quiere reglas de rol; un proyecto quiere reglas de necesidad de conocer — y el acceso debería requerir pasar las tres. En la mayoría de los modelos tendrías que programar a mano esa intersección; en NGAC es intrínseca, porque cada interés es una clase de política y el procedimiento de decisión ya exige que todas las clases que gobiernan concedan. El esquema conceptual de arriba lo insinúa con una única clase “política RBAC”, pero imagina una segunda clase “Clasificación” sobre los mismos objetos, y tienes la composición multipolítica que NGAC maneja como un hecho estructural de primera clase en lugar de como código de pegamento.

Modelar los modelos anteriores, en concreto

La afirmación de subsunción es fácil de enunciar y vale la pena hacerla tangible, porque ver cómo NGAC se convierte en cada modelo anterior es lo que transforma “un marco para todos” de eslogan en intuición. Toma RBAC primero. Un rol no es más que un atributo de usuario que agrupa usuarios, y un permiso no es más que una asociación de ese atributo a un atributo de objeto. Modela UA:manager ⇒ {approve} ⇒ OA:expenses y tienes exactamente la estructura rol-concede-permiso del artículo de RBAC; asigna UA:senior-manager → UA:manager y tienes la jerarquía de roles como contención de atributos; la regla de separación de funciones del RBAC restringido se vuelve una prohibición. RBAC, en términos de NGAC, es el caso especial donde los atributos de usuario llevan nombres de puestos y el acceso fluye solo por asociaciones.

Ahora ABAC. Donde RBAC usaba un puñado de atributos con forma de rol, ABAC usa muchos descriptivos — department, clearance, region, project — y NGAC representa cada uno como su propio contenedor de atributo de usuario u objeto, con asociaciones que tienden puentes entre los que deben conceder acceso. “Los ingenieros del proyecto de investigación pueden leer documentos de investigación” es una asociación desde la intersección de UA:engineer y UA:research-project hacia OA:research-docs. Las decisiones guiadas por atributos del artículo de ABAC se vuelven asociaciones sobre contenedores de atributos, y las condiciones ambientales que ABAC amaba — tiempo, riesgo — se adjuntan como restricciones, la misma costura que vimos golpear a ReBAC. ReBAC, por último, se aproxima usando asignaciones para modelar las relaciones de contención y propiedad entre recursos: un documento asignado al atributo de objeto de una carpeta hereda las asociaciones de la carpeta, que es exactamente la herencia por árbol de carpetas que ReBAC expresaba con tuple-to-userset. Tres modelos, un grafo, tres configuraciones — ese es el beneficio de la abstracción de NGAC, y trabajar un ejemplo a través de cada uno es la forma más rápida de sentir por qué el marco se llama general.

Obligaciones: la política que se reescribe a sí misma

Un elemento que aún no hemos usado distingue a NGAC de la mayoría de los modelos: la obligación. Una obligación es una regla evento-respuesta — “cuando ocurra este evento, realiza automáticamente estas operaciones administrativas sobre el grafo”. Como las acciones administrativas en NGAC (crear asignaciones, asociaciones, prohibiciones) son ellas mismas operaciones expresables en el modelo, una obligación puede cambiar la política en reacción a eventos. “Cuando un usuario abre un caso, concédele acceso a los registros de ese caso; cuando lo cierra, revócalo” se vuelve un par de obligaciones que añaden y quitan asignaciones automáticamente, sin flujo de trabajo externo. Esto hace a NGAC capaz de expresar políticas dinámicas y dependientes de la historia — separación de funciones que reacciona a lo que un usuario ya ha hecho, concesiones de emergencia que auto-expiran, acceso acotado a un flujo de trabajo — dentro del modelo en lugar de en el código circundante. Es el mismo instinto que las obligaciones de PBAC, generalizado en “la política puede administrarse a sí misma”.

NGAC frente a XACML: dos caminos hacia la autorización de grano fino

NGAC se entiende mejor junto a XACML, el otro gran estándar orientado a la autorización de grano fino y consciente de atributos (y tema del próximo módulo). Persiguen el mismo objetivo por medios opuestos, y el contraste es esclarecedor:

La esencia es que XACML calcula decisiones a partir de reglas mientras NGAC las lee de la estructura. El enfoque de reglas y algoritmos de combinación de XACML es enormemente flexible pero puede volverse difícil de razonar — con muchas políticas y algoritmos de combinación, “¿qué decide esto en realidad, y por qué?” se vuelve genuinamente difícil, y responder “¿qué puede alcanzar este usuario?” significa evaluar todo el conjunto de reglas contra él. El grafo de NGAC hace la evaluación determinista y las consultas de revisión baratas, a costa de un ecosistema más nuevo y la disciplina de pensar en un grafo. Ninguno es simplemente mejor; son formas distintas de la misma ambición, y conocer ambos es cómo evalúas cualquier sistema de autorización de grano fino que encuentres.

NGAC en la práctica: la implementación de referencia y más allá

Como NGAC es un estándar y no un producto, usarlo significa adoptar una implementación del modelo, y la misma arquitectura funcional se repite en todas ellas — la mismísima arquitectura que el próximo módulo formaliza. Hay un Policy Decision Point que responde solicitudes recorriendo el grafo, un Policy Enforcement Point en cada aplicación que pregunta y aplica, un Policy Administration Point donde se crea el grafo, y — único de las obligaciones de NGAC — un Event Processing Point que vigila los eventos y dispara las operaciones administrativas que describen las obligaciones. NIST publica una implementación de referencia abierta de la Policy Machine para que el modelo pueda estudiarse y ejercitarse directamente, y un pequeño número de plataformas comerciales (entre ellas proveedores de autorización basada en atributos) se construyen sobre el estándar o se alinean con él. El ecosistema es inconfundiblemente más joven y estrecho que el que rodea a OPA/Rego o los motores estilo Zanzibar, lo cual es el contrapeso honesto a la elegancia conceptual de NGAC.

Ayuda imaginar dónde encaja NGAC de forma realista hoy. Es más convincente en entornos que ya piensan en atributos y necesitan acceso demostrable y revisable — gobierno, defensa, sanidad y grandes empresas reguladas, los mismos entornos donde MAC y los modelos formales encontraron históricamente su hogar. En esos lugares la capacidad de responder “exactamente quién puede alcanzar este registro, y bajo qué políticas?” leyendo un grafo vale una inversión real, y el determinismo tranquiliza a los auditores de un modo que una pila de reglas combinables no logra. Para una aplicación web típica que hoy busca autorización, un motor estilo Zanzibar o una política OPA tendrán normalmente más comunidad, más ejemplos y una rampa de entrada más suave. NGAC es el modelo que entender universalmente y desplegar selectivamente — que es precisamente cómo un marco unificador tiende a entrar en el mundo, primero las ideas y después la infraestructura.

Fortalezas y limitaciones honestas

Las fortalezas de NGAC se siguen directamente de su diseño. Ofrece generalidad genuina — un marco para política al estilo rol, atributo y relación, lo que significa que puedes mezclarlas sin cambiar de motor. Su evaluación es determinista y analizable, evitando la ambigüedad de algoritmos de combinación que hace difíciles de confiar los grandes conjuntos de reglas. Sus consultas de revisión son eficientes, lo cual es un regalo operativo real: la recertificación de acceso, “¿quién puede tocar esto?” y “¿qué puede alcanzar?” son las preguntas que la gobernanza realmente hace, y NGAC las responde por construcción. Y las prohibiciones y obligaciones le permiten expresar denegaciones y política dinámica y auto-modificable que muchos modelos no pueden enunciar en absoluto.

Las limitaciones son igual de reales y vale la pena enunciarlas con franqueza. La adopción y el ecosistema son aún tempranos — comparado con el rico ecosistema alrededor de RBAC, OPA/Rego o los motores estilo Zanzibar, NGAC tiene menos implementaciones de producción, menos bibliotecas y una comunidad más pequeña, así que elegirlo significa construir más tú mismo. Hay una curva de aprendizaje conceptual: pensar en asignaciones, asociaciones y prohibiciones sobre contenedores de atributos es poco familiar, y un grafo mal modelado es tan capaz de un fallo de seguridad como cualquier otro mecanismo. Y operar el grafo a escala — mantenerlo correcto mientras los atributos y asignaciones cambian, y evaluarlo con baja latencia — es su propio problema de ingeniería, la misma tensión de frescura y rendimiento que todo el módulo no deja de rodear. NGAC es, hoy, más influyente como forma de pensar que como opción de despliegue por defecto — pero la forma de pensar es la parte que vale la pena interiorizar.

Un ejemplo resuelto: el roadmap de Sara, una última vez

El grafo de la figura es el ejemplo resuelto, así que traza la decisión de principio a fin. Sara está asignada a UA:engineer, que está asignado a UA:staff; roadmap.md está asignado a OA:research-docs, que está asignado a OA:company-files. Una asociación engineer ⇒ {read, write} ⇒ research-docs concede lectura y escritura a través de esos contenedores. Cuando Sara solicita read sobre roadmap.md, el motor recolecta sus atributos (engineer, staff), recolecta los atributos del objeto (research-docs, company-files), encuentra la asociación que enlaza engineer con research-docs con read en su conjunto, comprueba que ninguna prohibición la retira — y permite. Cuando solicita delete sobre el mismo objeto, ninguna asociación concede delete, e incluso el contenedor más amplio company-files lleva una prohibición engineer ⊘ {delete} — así que la solicitud se deniega por partida doble. Todos los modelos anteriores llegaron al mismo veredicto; NGAC llega a él leyendo la estructura del grafo.

Ahora ve la unificación en concreto. Añade una segunda clase de política — una política de clasificación — sobre los mismos objetos, con su propia asociación que concede read sobre research-docs solo a UA:cleared. El acceso a roadmap.md ahora requiere satisfacer ambas clases de política: Sara debe ser engineer (la política de rol) y estar cleared (la política de clasificación). Eso es RBAC y un modelo de clasificación componiéndose en un grafo, sin código de pegamento — el escenario exacto que, en los artículos anteriores, forzaba un híbrido cosido a mano. Y como las obligaciones pueden añadir asignaciones ante eventos, podrías hacer que “cleared” mismo se conceda automáticamente cuando Sara complete un evento de formación, dejando que la política evolucione sin un administrador. Esto es lo que compra “un modelo para expresarlos a todos”: no menos reflexión, sino un solo lugar para toda ella.

Recapitulación

El Control de Acceso de Nueva Generación unifica los modelos anteriores en un único grafo:

1. Un grafo dirigido para todo. Usuarios, atributos de usuario, objetos, atributos de objeto y políticas son nodos; asignaciones (contención), asociaciones (concesiones) y prohibiciones (denegaciones) son aristas. Una decisión es la búsqueda de un camino de privilegio del usuario al objeto.
2. Una gramática pequeña y expresiva. Las asignaciones construyen jerarquías de atributos de usuario y objeto; una asociación concede operaciones de un atributo de usuario a uno de objeto; una prohibición las resta y anula las concesiones.
3. Subsume RBAC, ABAC y ReBAC como configuraciones de un solo marco — la forma estandarizada de la Policy Machine de NIST (INCITS 565), del mismo linaje que RBAC.
4. Evaluación determinista y consultas de revisión nativas son sus ventajas destacadas: “¿qué puede acceder este usuario?” y “¿quién puede acceder a este objeto?” son recorridos de grafo, y las clases de política permiten coexistir a múltiples políticas exigiendo el acceso todas ellas; las obligaciones dejan que la política se modifique a sí misma ante eventos.
5. La adopción y el ecosistema son aún tempranos, y la generalidad cuesta abstracción — así que NGAC es, por ahora, más valioso como forma unificadora de pensar la autorización, incluso donde no es el motor desplegado.

Tres preguntas para autoevaluarte

1. Define asignación, asociación y prohibición en NGAC, y usa las tres para escribir las aristas del grafo que dejarían a los ingenieros leer y escribir documentos de investigación pero nunca borrar archivos de la empresa. ¿Qué tipo de arista lleva el conjunto de operaciones, y cuál anula a las demás?
2. Explica cómo NGAC responde “¿qué puede acceder este usuario?” como un recorrido de grafo, y por qué la misma pregunta es costosa en ABAC. ¿Por qué hace esto a NGAC atractivo para la recertificación de acceso y la auditoría?
3. NGAC afirma subsumir RBAC, ABAC y ReBAC. Elige dos de esos modelos y describe, en concreto, qué configurarías en un grafo NGAC para hacer que se comporte como cada uno — y explica qué te cuesta a cambio la generalidad de NGAC.

Ejercicios prácticos

1. Modela un grafo de dos políticas en papel. Dibuja un grafo NGAC con una clase de política al estilo RBAC (un atributo de usuario engineer con read/write concedido sobre un atributo de objeto research-docs) y una clase de política de clasificación (un atributo de usuario cleared con read concedido sobre los mismos objetos). Coloca un usuario en ambas, y traza por qué una solicitud se permite solo cuando ambas clases de política conceden.
2. Añade una prohibición y una obligación. Extiende tu grafo con una prohibición que deniegue delete sobre un contenedor company-files, y describe una obligación de la forma “cuando un usuario se asigna a engineer, asígnalo automáticamente a staff”. Explica cómo cada una cambia las decisiones que produce el grafo.
3. Compara una decisión con XACML. Toma una regla de acceso y exprésala dos veces — una como asociación NGAC (más cualquier prohibición) y otra como regla al estilo XACML con un target, una condición y un efecto. Enumera qué se vuelve fácil en cada representación, centrándote en cómo responderías “¿quién puede hacer esto?” en ambas.