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

Tres motores y una pregunta que nadie sabe responder

A final de año, la empresa de Sara tiene tres sistemas de autorización. El acceso según el puesto vive en grupos RBAC del directorio. El equipo de clasificación de datos mantiene reglas de atributos que alejan los documentos Confidenciales de quien no tiene habilitación. Y la plataforma de colaboración tiene su propio grafo de relaciones para compartir. Cada uno funciona. Entonces un auditor hace una pregunta sencilla: “¿Quién puede leer hoy roadmap.md, y según cuál de vuestras políticas?”. Responderla supone consultar tres sistemas con tres modelos de datos, cruzar los resultados a mano y esperar que el código pegamento entre ellos haga lo que todo el mundo cree que hace.

Los artículos anteriores defendieron cada uno una base distinta para el acceso: dueños, etiquetas, roles, atributos y relaciones. Cada uno era el más fuerte para un tipo de problema y torpe para los demás, y los sistemas reales acaban combinando dos o tres, cosidos en el código de la aplicación, exactamente como en la empresa de Sara. Eso deja una pregunta en el aire sobre toda esta parte del dominio: ¿existe una estructura formal lo bastante general como para expresar roles, atributos y relaciones a la vez, para no tener que atornillar motores distintos? 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 otro.

La apuesta del NGAC es radical en su sencillez: modelarlo todo como un único grafo dirigido. Los usuarios, los atributos que los agrupan, los objetos, los atributos que agrupan a los objetos y las propias políticas se convierten en nodos, y las formas en que se relacionan se convierten en aristas. Una decisión de acceso deja de ser una comparación con reglas o una consulta de roles y pasa a ser una pregunta sobre el grafo: ¿hay un camino de privilegio desde este usuario hasta este objeto, concedido por una asociación y no cortado por una prohibición? Donde el ReBAC ponía en un grafo las relaciones entre recursos, el NGAC pone toda la política, sujetos, objetos, atributos, concesiones y denegaciones, en un único grafo, y deduce cada decisión de su estructura. Esa generalidad es toda la idea, y es la razón de que el NGAC no se presente como rival del RBAC o el ABAC, sino como un marco en el que ellos son casos particulares.

Si el NGAC llegará a ser la forma dominante de construir la autorización sigue sin estar claro; sus herramientas y su adopción van por detrás de sus ideas. Pero como forma de entender cómo se relacionan entre sí los roles, los atributos y las relaciones, es difícil de superar, y su influencia en el pensamiento moderno sobre autorización ya es profunda.

De la Policy Machine a un estándar

El NGAC es la forma estandarizada de años de investigación del NIST llamada Policy Machine, dirigida por David Ferraiolo, el mismo investigador cuyo nombre aparece en el modelo RBAC original de los 90. Tras ayudar a formalizar el RBAC, Ferraiolo y sus colegas dedicaron los 2000 a una pregunta más profunda: en lugar de construir un mecanismo nuevo para cada tipo de política, ¿podría haber un único mecanismo de control de acceso de propósito general cuyo comportamiento lo determinaran por completo unos datos configurables? La Policy Machine fue su respuesta, una máquina cuyo “programa” es un grafo, de modo que el RBAC, el ABAC, la seguridad multinivel y sus combinaciones son configuraciones distintas del mismo motor y no motores distintos.

Esa investigación se estandarizó como NGAC, primero como INCITS 499 en 2013 y después como la versión revisada INCITS 565, con publicaciones del NIST que desarrollaron el modelo, incluido el trabajo sobre la combinación de políticas de control de acceso. El NIST publica además una implementación de referencia de la Policy Machine, y unos pocos productos comerciales han adoptado el enfoque. El linaje importa: el NGAC viene de la misma tradición intelectual que el RBAC, ampliada con dos décadas de reflexión sobre cómo generalizarlo, y por eso puede presentar los roles como una configuración entre muchas.

Todo es un nodo

El vocabulario del NGAC es pequeño, y aprenderlo es casi todo lo que hay que aprender del NGAC.

Tres de estas aristas hacen el trabajo de verdad. Una asignación es contención pura: user:sara → UA:engineer dice que Sara está en el atributo engineer, y object:roadmap → OA:research-docs dice que la hoja de ruta está en el atributo research-docs. Las asignaciones se encadenan, así que los atributos contienen atributos, UA:engineer → UA:staff y OA:research-docs → OA:company-files, y se construyen las dos jerarquías, una de usuarios y otra de objetos, que dan forma al grafo. Una asociación es la concesión que tiende un puente entre los dos lados: UA:engineer ⇒ {read, write} ⇒ OA:research-docs significa que cualquiera contenido en engineer puede leer y escribir cualquier cosa contenida en research-docs. Una prohibición es la excepción explícita: UA:engineer ⊘ {delete} OA:company-files retira el borrado aunque cualquier asociación lo conceda. Esa es toda la gramática, contenedores, concesiones y denegaciones sobre contenedores, y lo notable es que basta para expresar los modelos de los artículos anteriores.

Cómo se calcula una decisión

Con el grafo delante, decidir una petición, usuario, operación, objeto, “¿puede Sara leer roadmap.md?”, es una búsqueda bien definida, y su determinismo es gran parte del atractivo del NGAC. El motor hace tres cosas. Reúne los contenedores de atributos a los que llega el usuario siguiendo las asignaciones hacia arriba: Sara, engineer, staff. Reúne los contenedores a los que llega el objeto: roadmap, research-docs, company-files. Y busca una asociación cuyo origen sea uno de los contenedores del usuario, cuyo destino sea uno de los contenedores del objeto y cuyas operaciones incluyan la pedida; aquí coincide engineer ⇒ {read, write} ⇒ research-docs. Si ese camino de privilegio existe y ninguna prohibición retira la operación, la petición se permite; si no, se deniega.

flowchart LR
  accTitle: Cómo deduce el NGAC una decisión de acceso a partir del grafo de política
  accDescr: El procedimiento de decisión empieza con una petición que nombra un usuario, una operación y un objeto. El primer paso sigue las aristas de asignación hacia arriba desde el usuario para reunir todos los atributos de usuario que lo contienen, como engineer y staff. El segundo sigue las aristas de asignación hacia arriba desde el objeto para reunir todos los atributos de objeto que lo contienen, como research docs y company files. El tercero busca una asociación cuyo origen sea uno de los atributos de usuario reunidos, cuyo destino sea uno de los atributos de objeto reunidos y cuyas operaciones incluyan la pedida, por ejemplo engineer a research-docs. Si no existe, el resultado es denegar. Si existe, un cuarto paso comprueba si alguna prohibición retira la operación pedida para este usuario sobre este objeto. Si se aplica una prohibición, el resultado es denegar; si no, el resultado es permitir.
  R["Petición: usuario sara, op read, objeto roadmap"] --> UA["Reúne los atributos de usuario sobre sara:<br/>engineer, staff"]
  R --> OA["Reúne los atributos de objeto sobre roadmap:<br/>research-docs, company-files"]
  UA --> A{"¿Asociación de un atributo de usuario a uno de objeto<br/>que incluya read?<br/>p. ej. engineer a research-docs"}
  OA --> A
  A -->|no| D1["DENEGAR, sin camino de privilegio"]
  A -->|sí| P{"¿Alguna prohibición retira read aquí?"}
  P -->|sí| D2["DENEGAR, gana la prohibición"]
  P -->|no| PERMIT["PERMITIR, el camino sobrevive"]

Dos propiedades de este procedimiento son las grandes ventajas del NGAC. Es determinista y acotado: no hay ambigüedad sobre el orden de las reglas ni sutilezas de algoritmos de combinación, porque la respuesta es función del grafo y su coste crece con el tamaño del grafo, no con un montón cada vez mayor de reglas escritas por separado. Y el mismo grafo responde a las consultas de revisión con la misma naturalidad que a las peticiones de acceso. “¿A qué puede acceder Sara?” consiste en reunir sus atributos de usuario, seguir cada asociación que sale de ellos y enumerar los atributos de objeto, y su contenido, a los que llega. “¿Quién puede borrar este registro?” es la imagen en el espejo. Esas preguntas por usuario y por objeto son de lo que viven los auditores y los programas de certificación de accesos, y el RBAC y sobre todo el ABAC solo las responden con enumeraciones costosas, el problema de la consulta inversa. En el NGAC son recorridos nativos, porque el acceso es estructural y no lo calculan reglas opacas. La pregunta del auditor a la empresa de Sara sería un solo recorrido.

Un grafo, varias políticas

Una función sutil pero potente es la clase de política. Un mismo grafo puede contener varias políticas a la vez, cada una con su propia clase de política como raíz, y un elemento puede asignarse hacia arriba en más de una. La regla que las une es estricta: una petición solo se concede si se concede en todas las clases de política que gobiernan el objeto. Así expresa el NGAC políticas que conviven y que se escriben por separado. Una política de roles, una de clasificación de datos y una de confidencialidad de proyectos pueden vivir en un mismo grafo, y el acceso exige cumplirlas todas, igual que las preocupaciones superpuestas del gobierno real.

Las organizaciones reales nunca tienen una sola política. Legal quiere reglas de clasificación, una unidad de negocio quiere reglas de roles, un proyecto quiere reglas de necesidad de conocer, y el acceso debería exigir superar las tres. En la mayoría de los modelos esa intersección se programa a mano, que es justo el código pegamento entre los tres sistemas de Sara. En el NGAC viene de serie, porque cada preocupación es una clase de política y el procedimiento de decisión ya exige que todas las clases que gobiernan concedan.

La forma más limpia de ver el NGAC es como un camaleón. Haz que los atributos de usuario se comporten como roles y limita las asociaciones en consecuencia, y el grafo es un sistema RBAC. Deja que las asociaciones vayan entre atributos ricos de usuario y de objeto, y es ABAC. Usa las asignaciones para modelar la contención y las relaciones entre recursos, y se acerca al ReBAC. El NGAC no te pide que abandones los modelos mentales de los artículos anteriores; te pide que los veas como ajustes predefinidos de una máquina general. Ese cambio de mirada es la idea más valiosa del artículo, llegues o no a desplegar el NGAC.

Los modelos anteriores, dentro del NGAC

La afirmación es fácil de hacer y merece concretarse. Empieza por el RBAC. Un rol no es más que un atributo de usuario que agrupa usuarios, y un permiso es una asociación de ese atributo a un atributo de objeto. UA:manager ⇒ {approve} ⇒ OA:expenses es exactamente la estructura de rol que concede permiso del artículo del RBAC; UA:senior-manager → UA:manager es una jerarquía de roles expresada como contención; y la regla de segregación de funciones del RBAC con restricciones se convierte en una prohibición. En términos del NGAC, el RBAC es el caso particular en que los atributos de usuario llevan nombres de puestos y el acceso solo pasa por asociaciones.

Ahora el ABAC. Donde el RBAC usaba un puñado de atributos con forma de rol, el ABAC usa muchos descriptivos, departamento, habilitación, región, proyecto, y el NGAC representa cada uno como su propio contenedor de atributos de usuario o de objeto, con asociaciones entre los que deben conceder acceso. “Los ingenieros del proyecto de investigación pueden leer los documentos de investigación” es una asociación desde la intersección de UA:engineer y UA:research-project hasta OA:research-docs. Las decisiones basadas en atributos del artículo del ABAC se convierten en asociaciones sobre contenedores de atributos, mientras que las condiciones del entorno del ABAC, la hora y el riesgo, se añaden como restricciones, la misma costura con la que tropezó el ReBAC. Al ReBAC, por último, se llega usando las asignaciones para modelar la contención y la propiedad entre recursos: un documento asignado en el atributo de objeto de una carpeta hereda las asociaciones de la carpeta, que es la herencia del árbol de carpetas que el ReBAC expresaba con tuple-to-userset. Tres modelos, un grafo, tres configuraciones.

Obligaciones: política que se reescribe sola

Hay un elemento que separa al NGAC de casi todos los modelos: la obligación, una regla de evento y respuesta del tipo “cuando ocurra este evento, haz automáticamente estas operaciones de administración sobre el grafo”. Como las acciones de administración del NGAC, crear asignaciones, asociaciones y prohibiciones, son también operaciones que el modelo puede expresar, una obligación puede cambiar la política en respuesta a eventos. “Cuando un usuario abre un caso, dale acceso a los registros de ese caso; cuando lo cierra, quítaselo” se convierte en un par de obligaciones que añaden y quitan asignaciones solas, sin ningún flujo de trabajo fuera del modelo. Eso permite al NGAC expresar políticas dinámicas que dependen del historial, segregación de funciones que reacciona a lo que el usuario ya ha hecho, concesiones de emergencia que caducan solas, acceso limitado a un flujo de trabajo, dentro del modelo y no en el código de alrededor. Es el mismo instinto que las obligaciones del PBAC, generalizado en una política capaz de administrarse a sí misma.

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

El NGAC se entiende mejor junto a XACML, el otro gran estándar de autorización de grano fino basada en atributos, que trata el siguiente artículo. Persiguen el mismo objetivo por caminos opuestos.

En resumen, XACML calcula las decisiones a partir de reglas, mientras que el NGAC las lee de la estructura. El enfoque de reglas más 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 complica mucho, y responder a “¿a qué puede llegar este usuario?” obliga a evaluar todo el conjunto de reglas contra él. El grafo del NGAC hace la evaluación determinista y las consultas de revisión baratas, a cambio de un ecosistema más joven y de la disciplina de pensar en grafos. Ninguno es simplemente mejor; son formas distintas de la misma ambición.

El NGAC en la práctica

Como el NGAC es un estándar y no un producto, usarlo supone adoptar una implementación del modelo, y en todas aparece la misma arquitectura funcional, la que formaliza el siguiente artículo. Un punto de decisión de políticas responde a las peticiones recorriendo el grafo, un punto de aplicación de políticas en cada aplicación pregunta y aplica, un punto de administración de políticas es donde se escribe el grafo y, propio de las obligaciones del NGAC, un punto de procesamiento de eventos vigila los eventos y lanza las operaciones de administración que describen las obligaciones. El NIST publica una implementación de referencia abierta de la Policy Machine para poder estudiar y probar el modelo directamente, y unas pocas plataformas comerciales se basan en el estándar o se alinean con él. El ecosistema es claramente más joven y estrecho que el de OPA y Rego o el de los motores al estilo Zanzibar, el contrapeso honesto a la elegancia conceptual del NGAC.

¿Dónde encaja de forma realista el NGAC hoy? Resulta más atractivo en entornos que ya piensan en atributos y necesitan un acceso que se pueda demostrar y revisar: la administración pública, la defensa, la sanidad y las grandes empresas reguladas, los mismos sitios donde el MAC y los modelos formales encontraron su casa. Ahí, responder a “¿quién puede llegar exactamente a este registro y según qué políticas?” leyendo un grafo merece una inversión real, y el determinismo tranquiliza a los auditores como no lo hace un montón de reglas combinables. Para una aplicación web típica que busca autorización hoy, un motor al estilo Zanzibar o una política OPA suelen tener más comunidad, más ejemplos y un comienzo más fácil. El NGAC es el modelo que conviene entender en todas partes y desplegar con criterio, que es como suelen llegar al mundo los marcos unificadores: primero las ideas y después la infraestructura.

Puntos fuertes y límites, con honestidad

Los puntos fuertes del NGAC salen de su diseño. Es de verdad general, un único marco para políticas de roles, atributos y relaciones, así que puedes mezclarlas sin cambiar de motor. Su evaluación es determinista y analizable, sin la ambigüedad de los algoritmos de combinación que hace difícil fiarse de los grandes conjuntos de reglas. Sus consultas de revisión son eficientes, un regalo operativo real, porque la certificación, “¿quién puede tocar esto?” y “¿a qué pueden llegar?” son las preguntas que de verdad hace el gobierno. Y las prohibiciones y las obligaciones le permiten expresar denegaciones y políticas dinámicas que se modifican a sí mismas, algo que muchos modelos ni siquiera pueden formular.

Los límites son igual de reales. La adopción y las herramientas todavía son incipientes: frente a los ecosistemas del RBAC, OPA o los motores al estilo Zanzibar, el NGAC tiene menos implementaciones en producción, menos librerías y una comunidad más pequeña, así que elegirlo supone construir más por tu cuenta. Hay una curva de aprendizaje conceptual, porque pensar en asignaciones, asociaciones y prohibiciones sobre contenedores de atributos no resulta familiar, y un grafo mal modelado puede producir un fallo de seguridad como cualquier otro mecanismo. Y mantener el grafo a escala, que siga siendo correcto mientras cambian atributos y asignaciones y que se evalúe con poca latencia, es un problema de ingeniería propio, la misma tensión entre frescura y rendimiento que recorre toda esta parte del dominio.

La generalidad tampoco es lo mismo que la sencillez. Un marco lo bastante general como para ser RBAC, ABAC y ReBAC a la vez es por fuerza más abstracto que cualquiera de ellos, y esa abstracción se paga con cuidado al modelar y con herramientas. El valor del NGAC no está en ser más sencillo que los modelos que incluye; está en darte una única estructura coherente y un único procedimiento de decisión en lugar de tres motores cosidos. Que el intercambio merezca la pena depende de cuánto abarque tu política real de esos modelos. Cuanto más abarque, más rinde la unificación del NGAC; cuanto menos, mejor te servirá un único modelo especializado.

La hoja de ruta de Sara, por última vez

El grafo de la figura es el ejemplo, así que sigue 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. La asociación engineer ⇒ {read, write} ⇒ research-docs concede lectura y escritura entre esos contenedores. Cuando Sara pide leer roadmap.md, el motor reúne sus atributos, engineer y staff, reúne los del objeto, research-docs y company-files, encuentra la asociación que une engineer con research-docs con read en su conjunto, comprueba que ninguna prohibición la retira y permite. Cuando pide borrarlo, ninguna asociación concede delete, y el contenedor más amplio company-files lleva además la prohibición engineer ⊘ {delete}, así que la petición se deniega por partida doble. Todos los modelos anteriores llegaban a la misma respuesta; el NGAC llega leyendo la estructura del grafo.

Ahora añade una segunda clase de política, una de clasificación, sobre los mismos objetos, con su propia asociación que concede lectura sobre research-docs solo a UA:cleared. Leer roadmap.md exige ahora cumplir las dos clases de política: Sara tiene que ser engineer, según la política de roles, y estar habilitada, según la de clasificación. Es el RBAC y un modelo de clasificación componiéndose en un solo grafo sin código pegamento, justo la situación que dejó a la empresa de Sara con tres sistemas y una pregunta de auditoría sin respuesta. Y como las obligaciones pueden añadir asignaciones en respuesta a eventos, la habilitación podría concederse sola cuando Sara termine un curso de formación, dejando que la política evolucione sin administrador. Eso es lo que compra un modelo para todos: no pensar menos, sino un único sitio para todo.

Resumen

El control de acceso de nueva generación unifica los modelos anteriores en un grafo. Usuarios, atributos de usuario, objetos, atributos de objeto y políticas son nodos; asignaciones, asociaciones y prohibiciones son aristas; y una decisión es la búsqueda de un camino de privilegio del usuario al objeto. La gramática es pequeña y expresiva: las asignaciones construyen las jerarquías de usuarios y objetos, una asociación concede operaciones de un atributo de usuario a uno de objeto y una prohibición las retira y prevalece sobre las concesiones. Recoge el RBAC, el ABAC y el ReBAC como configuraciones de un mismo marco, la forma estandarizada de la Policy Machine del NIST (INCITS 565), del mismo linaje que el RBAC. La evaluación determinista y las consultas de revisión nativas son sus grandes ventajas, las clases de política permiten que convivan varias políticas exigiendo todas para el acceso y las obligaciones dejan que la política se modifique sola en respuesta a eventos. Y la adopción y las herramientas son todavía incipientes, y la generalidad cuesta abstracción, así que por ahora el NGAC vale sobre todo como forma unificadora de pensar la autorización, aunque no sea el motor que despliegues.

Tres preguntas para ponerte a prueba

1. Define asignación, asociación y prohibición en el NGAC, y usa las tres para escribir las aristas del grafo que permitirí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 prevalece sobre las demás?
2. Explica cómo responde el NGAC a “¿a qué puede acceder este usuario?” como un recorrido del grafo y por qué la misma pregunta es costosa en ABAC. ¿Por qué hace eso atractivo al NGAC para la certificación de accesos y la auditoría?
3. El NGAC afirma incluir al RBAC, el ABAC y el ReBAC. Elige dos y describe de forma concreta qué configurarías en un grafo NGAC para que se comporte como cada uno, y explica lo que te cuesta a cambio la generalidad del NGAC.

Ejercicios prácticos

1. Modela sobre el papel un grafo de dos políticas. Dibuja un grafo NGAC con una clase de política al estilo de roles (un atributo de usuario engineer con lectura y escritura sobre un atributo de objeto research-docs) y una clase de política de clasificación (un atributo de usuario cleared con lectura sobre los mismos objetos). Pon a un usuario en las dos y sigue por qué una petición solo se permite cuando las dos clases la conceden.
2. Añade una prohibición y una obligación. Amplía tu grafo con una prohibición que deniegue el borrado sobre un contenedor company-files, y describe una obligación del tipo “cuando un usuario se asigne a engineer, asígnalo automáticamente a staff”. Explica cómo cambia cada una las decisiones que produce el grafo.
3. Compara una decisión con XACML. Coge 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 objetivo, condición y efecto. Enumera lo que resulta fácil en cada una, fijándote en cómo responderías en las dos a “¿quién puede hacer esto?”.