Control de Acceso Basado en Atributos (ABAC): el acceso sigue al contexto

Cuarenta y dos roles para una regla

El equipo de cumplimiento le manda a Sara un requisito nuevo para la plataforma de soporte: los agentes de soporte solo pueden leer la cuenta de un cliente si la cuenta es de la región del agente, solo mientras el agente tenga abierto un ticket de ese cliente y solo durante su horario de trabajo. El administrador que gestiona los roles de la plataforma echa la cuenta en voz alta. Catorce regiones, tres turnos: cuarenta y dos roles antes de pensar siquiera en la condición del ticket, que ningún rol puede expresar, porque si un ticket está abierto cambia cada pocos minutos.

El artículo anterior dejó al RBAC justo en este borde. Los roles recogen cuál es tu puesto, pero no la situación: la región a la que pertenece un recurso, si eres su dueño, la hora, el estado de tu dispositivo, una puntuación de riesgo en vivo. Cuando el acceso depende de una condición en lugar de una asignación fija, lo único que puede hacer el RBAC es crear otro rol por combinación, y las combinaciones se disparan. Hace falta un modelo que evalúe los hechos de la propia petición, en el momento en que ocurre. Ese modelo es el control de acceso basado en atributos (ABAC).

El ABAC cambia la pregunta. El RBAC pregunta qué roles tienes. El ABAC pregunta: teniendo en cuenta quién eres, qué estás tocando, qué intentas hacer y las condiciones de este momento, ¿lo permite la política? Cada una de esas cosas es un cajón de atributos, y una política ABAC es un conjunto de reglas sobre ellos. Como los atributos se leen en el momento de la petición, el ABAC puede expresar justo las condiciones dinámicas y de contexto que rompían el RBAC, y sin crear nada por adelantado, porque una sola regla que diga “tu región coincide con la del recurso” cubre todas las regiones a la vez. Los cuarenta y dos roles de Sara se convierten en una regla.

El ABAC está estandarizado en NIST SP 800-162, la guía de referencia del modelo, y es el motor conceptual de los lenguajes de políticas modernos y de la autorización en la nube. La intuición es antigua. Bell-LaPadula comparaba un atributo de habilitación con uno de clasificación en los años 70, así que en cierto sentido el MAC fue un antepasado rígido, de dos atributos, del ABAC. Como modelo general, sin embargo, el ABAC maduró con XACML, el eXtensible Access Control Markup Language que estandarizó OASIS en los 2000, que dio a las políticas de atributos una estructura formal de petición y respuesta y un lenguaje de políticas. El NIST publicó SP 800-162 en 2014 presentando el ABAC como la forma de escalar el control de acceso a entornos grandes y dinámicos que cruzan organizaciones, donde preparar cada relación de antemano es imposible. El momento no fue casual: el ABAC se generalizó justo cuando la nube, el SaaS y la federación hicieron el acceso contextual por naturaleza y los roles por sí solos dejaron de bastar.

Los cuatro tipos de atributo

Un atributo no es más que una propiedad con nombre y un valor: department = "support", classification = "confidential", time = 14:30. NIST SP 800-162 los ordena en cuatro categorías, y aprender a repartir un requisito en esos cajones es casi toda la habilidad de pensar en ABAC.

Los atributos del sujeto describen a quien pide: departamento, puesto, habilitación, responsable, equipo, certificaciones, tipo de contrato. Los atributos del recurso describen el objeto al que se accede: dueño, clasificación, región, proyecto, sensibilidad, fecha de creación. Los atributos de la acción describen la operación, leer, escribir, aprobar, borrar, y a veces matices como el importe de una operación, lo que permite que una regla distinga “aprobar un reembolso pequeño” de “aprobar uno grande” sin inventar acciones aparte. Los atributos del entorno describen el contexto con independencia de quién y qué: la hora actual, el día de la semana, la ubicación o red de origen, el estado del dispositivo, la fuerza con que se autenticó el usuario, el nivel de amenaza del momento. Son los que hacen que el acceso cambie con el tiempo, de modo que el mismo sujeto y el mismo recurso pueden recibir una respuesta distinta a las tres de la mañana que a mediodía.

Reparte la regla de cumplimiento en estos cajones y se desmonta sola. La región del agente es un atributo del sujeto y la de la cuenta es un atributo del recurso, así que la regla los compara. El ticket abierto es una relación entre este agente y este cliente, recogida como atributo. Y el horario de trabajo es un atributo del entorno. Ningún rol nuevo; una política cubre a todos los agentes, regiones y clientes.

Dos apuntes sobre esas categorías. Los atributos no tienen por qué estar guardados; algunos son derivados o se calculan al momento. isManagerOf(subject, resource.owner) o ticketOpen(agent, customer) no son campos de una base de datos; son preguntas que se responden llamando a otro sistema en el momento de decidir. Eso es potente, porque las políticas pueden razonar sobre relaciones y cálculos en vivo, y arriesgado, porque cada atributo derivado es otra dependencia que puede ser lenta, errónea o no estar disponible. Y los atributos del entorno son los que el RBAC no puede tocar de ninguna manera, porque un rol se asigna una vez y no puede saber la hora, el sitio ni el riesgo del momento. En cuanto un requisito contiene la palabra “cuándo” o “dónde”, casi seguro que estás ante un atributo del entorno, y casi seguro fuera del alcance del RBAC.

Una política son reglas sobre atributos

Una política ABAC es un conjunto de reglas, cada una de las cuales evalúa atributos hasta llegar a una decisión, permitir o denegar. Escrita como pseudopolítica sencilla, la regla de cumplimiento queda así:

permit if
  action == "read"
  and subject.role == "support_agent"
  and resource.type == "customer_account"
  and subject.region == resource.region
  and ticketOpen(subject.id, resource.customer_id)
  and environment.time in business_hours

Cada cláusula compara atributos. Cambia “read” por “close_account”, exige subject.role == "supervisor" y tienes una segunda regla. La política completa es el conjunto de esas reglas más una forma de combinarlas, a la que llegaremos. Fíjate en lo que falta: no hay ninguna lista de qué agentes pueden tocar qué cuentas. Esa lista se calcula a partir de los atributos en cada petición, y por eso el ABAC escala a situaciones para las que el RBAC necesitaría millones de concesiones, y por eso también, como veremos, responder “¿quién puede tocar esta cuenta?” se vuelve realmente difícil.

flowchart LR
  accTitle: Flujo de decisión del control de acceso basado en atributos
  accDescr: Un sujeto hace una petición para realizar una acción sobre un recurso. Esa petición llega a un motor de políticas en el centro. Cuatro fuentes de atributos alimentan el motor: atributos del sujeto, como el departamento y la región; atributos del recurso, como el dueño y la clasificación; atributos de la acción, como leer o aprobar; y atributos del entorno, como la hora y la ubicación. El motor evalúa sus reglas sobre todos los atributos reunidos y devuelve una decisión de permitir o denegar al punto de aplicación que hay delante del recurso.
  REQ[El sujeto pide una acción sobre un recurso] --> ENG{Motor de políticas}
  SUB[Atributos del sujeto<br/>departamento, región] --> ENG
  RES[Atributos del recurso<br/>dueño, clasificación] --> ENG
  ACT[Atributos de la acción<br/>leer, aprobar] --> ENG
  ENV[Atributos del entorno<br/>hora, ubicación, riesgo] --> ENG
  ENG -->|permitir / denegar| PEP[Punto de aplicación]
  PEP --> RESOURCE[(Recurso)]

De dónde salen los atributos

Una política vale lo que valen los atributos que lee, y estos tienen que venir de algún sitio con autoridad. Los atributos del sujeto suelen salir del sistema de RR. HH. y del proveedor de identidad, como el departamento, el puesto y el responsable, a menudo dentro de los tokens de los artículos anteriores. Los del recurso vienen de los sistemas dueños de los datos: un esquema de etiquetado, un servicio de clasificación de datos, una base de datos de configuración. Los del entorno vienen del tiempo de ejecución: el reloj, la red y las señales de estado del dispositivo y de riesgo que también usa el algoritmo de confianza de Zero Trust.

Aquí está el corazón discreto de la dificultad del ABAC. Cada atributo necesita una fuente con autoridad, un significado acordado y un proceso que lo mantenga al día. Si la region de una cuenta está mal, o el department de un usuario lleva un año desactualizado, la política toma decisiones seguras y equivocadas. Y a diferencia de una asignación de rol errónea, que alguien podría ver en una revisión, un atributo erróneo es invisible hasta que produce una decisión errónea. El ABAC no elimina la carga de gobierno que tiene el RBAC; la traslada de gestionar roles a gestionar atributos y sus fuentes. Las organizaciones que adoptan el ABAC sin un programa para gobernar los atributos cambian la maraña de roles por errores silenciosos que salen de los datos.

Hay un problema más sutil que el de los datos viejos: el significado. Cuando una política compara subject.region con resource.region, los dos lados tienen que significar lo mismo, con el mismo vocabulario, la misma granularidad y la misma codificación. Si RR. HH. registra la región como "EMEA" y quien etiqueta los recursos escribe "Europa", la regla no coincide nunca sin que nadie se entere, y una política que parece correcta deniega o permite por la razón equivocada. Multiplica eso por decenas de atributos que llegan desde RR. HH., el proveedor de identidad, una base de datos de configuración y una docena de equipos de aplicaciones, y la deriva semántica se convierte en una de las grandes causas de errores de autorización. Por eso los programas de ABAC maduros invierten en un esquema de atributos, un catálogo gobernado que define el nombre, el tipo, los valores permitidos y la fuente con autoridad de cada atributo, para que “región” signifique lo mismo en todas partes. Es trabajo de gobierno de datos poco vistoso, y es la diferencia entre un ABAC que se sostiene y uno que se pudre en silencio.

El fallo habitual del ABAC no es una política equivocada; es una política correcta alimentada con atributos equivocados. Una regla correcta que lee una habilitación caducada, una región mal escrita o una señal de confianza del dispositivo que vale “de confianza” por defecto cuando se cae su fuente autorizará con total seguridad lo que no debe. Antes de fiarte de un atributo en una política, conoce su fuente de verdad, lo rápido que se actualiza y cómo se comporta cuando falla.

Cuando las reglas no se ponen de acuerdo

Las políticas reales tienen muchas reglas, y dos pueden llegar a conclusiones opuestas sobre la misma petición. Un algoritmo de combinación resuelve el conflicto de forma determinista. Los habituales son denegar prevalece (deny-overrides), en el que gana cualquier denegación, la opción segura por defecto; permitir prevalece (permit-overrides), en el que gana cualquier permiso; la primera aplicable (first-applicable), en la que decide la primera regla que encaja; y solo una aplicable (only-one-applicable). La elección es una decisión de seguridad. Denegar prevalece es conservador y suele ser lo correcto, pero tienes que saber qué algoritmo usa tu motor, porque las mismas reglas dan respuestas distintas con combinadores distintos. Un equipo que da por hecho denegar prevalece mientras usa un motor que por defecto aplica permitir prevalece ha invertido en la práctica la seguridad de cada conflicto de su política sin saberlo.

También está la cuestión de qué hacer cuando falta un atributo necesario, porque se ha caído una fuente o a un token le falta un claim. Una política bien diseñada lo dice claramente: tratar los atributos ausentes como una denegación en las acciones sensibles, fallando cerrado, y no dejar nunca que “el atributo no está” cumpla por accidente una condición. Estas reglas de combinación y de valores por defecto son justo lo que los lenguajes de políticas formales como XACML, Rego y Cedar hacen rigurosas.

Como estas interacciones son sutiles, las pruebas dejan de ser opcionales en cuanto las políticas se enriquecen. Un conjunto de una docena de reglas que se solapan más un algoritmo de combinación es en la práctica un programa pequeño, y como cualquier programa necesita su batería de pruebas: peticiones representativas con decisiones esperadas conocidas, ejecutadas cada vez que cambia la política, para que añadir una regla no cambie en silencio una decisión que no tenía nada que ver. Por eso el sector avanzó hacia las políticas como código, escribir las políticas en un lenguaje que se puede versionar, revisar y probar con tests unitarios. Tratar una política ABAC como configuración sin probar es la forma de que un modelo “más preciso” acabe comportándose de manera menos predecible que los roles a los que sustituyó.

El problema de la consulta inversa

La expresividad del ABAC tiene un coste preciso que sorprende a la gente. El RBAC hace trivial “¿quién puede acceder a este recurso?”: lees la lista de roles que lo conceden. El ABAC hace esa pregunta realmente difícil, porque el acceso no está guardado; se calcula. Para responder “¿quién puede leer esta cuenta?” tendrías que evaluar la política para cada sujeto posible en cada condición relevante, porque no hay lista que leer, solo una regla que da una respuesta cuando le pasas un sujeto y un momento concretos.

Es el problema de la consulta inversa, también llamado revisión centrada en el recurso, y es la otra cara del poder del ABAC. Complica las revisiones de acceso, las auditorías y preguntas como “¿tiene alguien de fuera de Finanzas un camino hasta las nóminas?”, que los auditores hacen a menudo y que un sistema solo ABAC no puede responder mirando. Las normas y las auditorías están centradas, de forma abrumadora, en los recursos: demuestra quién puede acceder a los datos de tarjetas, certifica a todos los que tienen acceso a este sistema. Un sistema que solo sabe responder la pregunta directa, “¿puede esta persona hacer esto ahora?”, es incómodo de auditar por estructura. No es una razón para evitar el ABAC, cuya expresividad a menudo es imprescindible, pero sí para diseñar pensando en la auditoría desde el principio: mantener una capa de roles legible para las concesiones gruesas, registrar cada decisión junto con los atributos que la provocaron e invertir en herramientas que enumeren o simulen decisiones antes de la primera auditoría y no durante ella.

Lo que aporta el ABAC

El ABAC se gana su complejidad allí donde el acceso es de verdad condicional. Es dinámico: las decisiones reflejan el estado del mundo en el momento de la petición, así que el acceso se estrecha solo cuando sube el riesgo o se cierra un ticket, sin que intervenga ningún administrador. Es de grano fino: una regla puede condicionar un solo campo de un solo registro a una combinación precisa de condiciones. Escala en expresividad: una política cubre todas las regiones, inquilinos o clientes, sustituyendo lo que si no sería un montón combinatorio de roles. Y externaliza la autorización, manteniendo las políticas en un solo sitio en lugar de repartirlas como sentencias if por el código de la aplicación.

El caso multiinquilino muestra dónde el ABAC se vuelve imprescindible. Una plataforma SaaS con diez mil clientes no puede crear roles por inquilino; eso es explosión de roles por definición. Una sola regla ABAC, “un usuario solo puede acceder a un registro si record.tenant == subject.tenant”, aplica el aislamiento entre inquilinos a los diez mil a la vez, y sigue funcionando con el diez mil uno sin tocar nada. Ese patrón sostiene en silencio buena parte del SaaS que usas, y no se puede expresar con RBAC puro. Cuando se dice que el ABAC escala, es esto: la política mantiene su tamaño mientras el número de sujetos y recursos crece sin límite.

Lo que cuesta el ABAC

Los costes son igual de reales. Gobernar los atributos, como hemos visto, es el mayor. La capacidad de auditoría se resiente por el problema de la consulta inversa. Razonar se complica, porque una política rica puede tener interacciones sutiles y es fácil escribir reglas que se solapan o se contradicen de formas que nadie quería. El rendimiento hay que trabajarlo, porque leer atributos frescos y evaluar la política en cada petición añade latencia. Y hay un riesgo real de explosión de políticas, la versión ABAC de la explosión de roles, en la que un montón desordenado de reglas se vuelve tan inmanejable como un montón desordenado de roles. El ABAC traslada la complejidad; no la elimina.

El ABAC no escapa automáticamente de la trampa que vino a resolver. La explosión de roles salía de convertir cada condición en un rol nuevo; la explosión de políticas sale de convertir cada caso especial en una regla nueva, y un sistema ABAC con mil reglas improvisadas y solapadas no es más gobernable que mil roles, probablemente menos, porque las reglas interactúan de formas en que los roles no lo hacen. La salida es la estructura, no otro modelo: agrupa las reglas por tipo de recurso, saca las condiciones comunes a predicados reutilizables, dale nombre y responsable a cada política y prueba el conjunto entero. Las organizaciones a las que les sale bien el ABAC tratan la política como una base de código diseñada y mantenida. Aquellas a las que les sale mal la tratan como un sitio donde ir pegando excepciones hasta que nadie puede predecir qué hace.

Así que el ABAC no es automáticamente más seguro que el RBAC. Una política compleja que nadie entiende del todo no es más segura que un modelo de roles sencillo que todo el mundo entiende. La flexibilidad que te deja escribir una regla de mínimo privilegio precisa también te deja escribir una enorme y contradictoria cuyo comportamiento nadie puede prever, y sin pruebas, gobierno y herramientas de revisión puede producir decisiones equivocadas de formas mucho más difíciles de ver que un rol demasiado amplio.

El ABAC es el motor de Zero Trust

Si el ABAC te parece abstracto, ya lo conoces con otro nombre. El algoritmo de confianza de Zero Trust, la lógica dentro del punto de decisión que pondera la identidad, el estado del dispositivo, la ubicación y el riesgo en cada petición, es una política de atributos. “Concede el acceso solo si el usuario está autenticado, el dispositivo cumple, la ubicación no es rara y la puntuación de riesgo es baja” es una regla sobre atributos del sujeto, del entorno y del recurso, evaluada de forma continua. La confianza adaptativa continua es el “vuelve a leer los atributos en cada petición” del ABAC aplicado a toda una sesión: cuando un dispositivo deja de cumplir o el riesgo se dispara, la misma política que permitía el acceso ahora lo deniega, sin que intervenga ningún administrador. Zero Trust es la estrategia, y el ABAC es el nombre formal de cómo se toman sus decisiones.

Leer atributos frescos y evaluar una política en cada petición suena caro, y hecho a lo bruto lo es. Una decisión puede necesitar atributos del token, de un almacén de etiquetas de recursos y de una fuente de riesgo en vivo, saltos de red que añaden latencia a cada acción del usuario. Los sistemas ABAC reales lo resuelven con ingeniería. Los atributos que cambian poco, como el departamento y la clasificación, se guardan en caché con una vida razonable; los que tienen que estar al día, como el riesgo y el estado del dispositivo, se leen en vivo o llegan como eventos. A veces se cachean decisiones para peticiones idénticas repetidas, con cuidado, para no ignorar una revocación. Y la evaluación de la política se mantiene cerca del punto de aplicación para evitar idas y vueltas. Son los mismos compromisos entre latencia y frescura que viste con las sesiones y la revocación de tokens. “Evaluarlo todo en cada petición” es un compromiso de diseño con una factura de rendimiento.

El híbrido: roles y atributos juntos

En la práctica, “RBAC o ABAC” es una falsa elección; la respuesta madura es las dos cosas, y la forma más clara de verlo es que un rol es solo un atributo más del sujeto. Mantén los roles para la decisión gruesa, estable y auditable, “¿es esta persona agente de soporte?”, y añade reglas de atributos para la parte condicional y dinámica, “¿y es la región, el ticket y la hora correctos?”. Tienes la legibilidad del RBAC para la base y la flexibilidad del ABAC para las condiciones, sin explosión de roles ni caos de políticas. Fíjate en que la regla de Sara ya lo hacía: su segunda línea comprueba subject.role.

Es justo lo que ofrecen las grandes plataformas. AWS combina los roles de IAM con claves de condición y etiquetas de recursos, de modo que un rol concede un tipo de acción y las condiciones lo estrechan comparando etiquetas, un patrón que la propia AWS llama control de acceso basado en atributos. En una política de IAM, la comparación de etiquetas se lee como una comparación de atributos:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/region": "${aws:PrincipalTag/region}"
    }
  }
}

Esa sentencia dice “permite leer cualquier objeto cuya etiqueta region sea igual a la etiqueta region de quien lo pide”, una regla que cubre todas las regiones, justo el movimiento ABAC que con RBAC puro necesitaría un rol por región. Azure añade condiciones ABAC a las asignaciones de roles con la misma idea, y motores de políticas como OPA y Cedar tratan roles y atributos por igual como entradas. La lección de los tres últimos artículos es coherente: cada modelo responde a algo que el anterior no podía, y los sistemas reales los combinan en lugar de coronar a uno.

La hoja de ruta, resuelta, y el siguiente borde

Vuelve a la hoja de ruta de Sara de los artículos anteriores. La regla que tumbó al RBAC, un agente de soporte puede leer la hoja de ruta solo de su región, solo mientras tenga abierto un ticket que haga referencia a ella y solo en horario laboral, es una única política ABAC: comparar subject.region con resource.region, comprobar la relación ticketOpen y mirar environment.time. Cubre a todos los agentes y regiones, no necesita roles por región y se estrecha sola en cuanto se cierra un ticket o termina la jornada, porque los atributos se vuelven a leer en la siguiente petición. El problema que obligaba a la explosión de roles es ahora una regla legible.

Y aparece un nuevo borde, como era de esperar. La regla se apoyaba en ticketOpen(subject.id, resource.customer_id), una relación entre el sujeto y este recurso concreto. El ABAC puede usarla como atributo si algo la calcula y se la proporciona, pero expresar el acceso sobre todo en términos de relaciones entre entidades, “puedes editar el documento porque eres miembro del equipo dueño de la carpeta en la que está”, es incómodo de modelar con atributos planos y caro de evaluar. Ahí es donde entra el control de acceso basado en relaciones. Cada modelo le pasa el testigo al que resuelve el caso difícil que le queda.

Resumen

El control de acceso basado en atributos convierte el acceso en una función del contexto, evaluada en el momento de la petición. El acceso sigue a la situación: las políticas deciden a partir de atributos del sujeto, el recurso, la acción y el entorno, como describe NIST SP 800-162, leídos cuando ocurre la petición, así que el acceso puede depender de la región, la propiedad, la hora, el dispositivo y el riesgo. Una política son reglas sobre atributos, y una regla cubre a todos los sujetos y recursos, que es como el ABAC expresa lo que al RBAC le costaría un número combinatorio de roles. Gobernar los atributos es el trabajo de verdad, porque el modelo es tan correcto como las fuentes, el significado y la frescura de sus atributos. La expresividad tiene costes: el problema de la consulta inversa hace difícil responder “¿quién puede acceder a esto?”, hay que entender los algoritmos de combinación y los valores por defecto para atributos ausentes, y la explosión de políticas es un fallo real. Y la respuesta es un híbrido: un rol es un atributo, y los sistemas maduros usan roles para la base gruesa y auditable y reglas de atributos para las condiciones dinámicas, como hacen AWS y Azure.

Tres preguntas para ponerte a prueba

1. Toma la regla “un responsable puede aprobar un gasto solo de las personas que dependen de él, solo hasta su límite de aprobación y solo si el gasto cae en un periodo de cierre abierto”. Reparte cada condición en atributos del sujeto, del recurso, de la acción o del entorno, y explica por qué el RBAC solo no puede expresarla.
2. Tu auditor pregunta: “¿Quién puede leer los registros de clientes de la región UE?”. Explica por qué es fácil con RBAC y difícil con ABAC puro, ponle nombre al problema y describe dos formas en que un ABAC real hace que la pregunta tenga respuesta.
3. Un equipo propone sustituir todos los roles por políticas de atributos. Da dos ventajas concretas y dos riesgos concretos, y defiende un híbrido, diciendo exactamente qué decisiones mantendrías basadas en roles y cuáles harías basadas en atributos.

Ejercicios prácticos

1. Escribe una política en pseudorreglas. Elige una regla de acceso real de un sistema que conozcas y escríbela como regla ABAC, marcando la categoría de atributo de cada cláusula. Después identifica, para cada atributo, su fuente con autoridad y lo desactualizado que podría estar.
2. Encuentra el ABAC en tu nube. En AWS o Azure, busca una política que use una condición: una política de IAM con un bloque Condition que compare etiquetas, o una asignación de roles de Azure con una condición ABAC. Lee exactamente qué atributos del sujeto y del recurso compara y predice cómo cambia la decisión si una etiqueta está mal.
3. Prueba la consulta inversa. Para una política de atributos, intenta responder a mano “¿quién puede acceder al recurso X?”. Fíjate en que tienes que enumerar sujetos y condiciones en lugar de leer una lista. Esboza qué tendría que hacer una herramienta para responderlo automáticamente; ese es el problema de diseño que retoma el artículo de autorización de grano fino.