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

Cuando la respuesta depende de la situación

El artículo anterior dejó a RBAC en un borde duro. Los roles capturan cuál es tu puesto, pero no pueden capturar la situación — la región a la que pertenece un recurso, si eres su dueño, la hora del día, la salud de tu dispositivo, una puntuación de riesgo en vivo. En el momento en que el acceso depende de una condición en lugar de una asignación estática, la única jugada de RBAC es acuñar otro rol por combinación, y las combinaciones explotan. Lo que necesitamos es un modelo que evalúe los hechos de la solicitud misma, en el momento en que ocurre. Ese modelo es el Control de Acceso Basado en Atributos (ABAC).

ABAC cambia la pregunta. RBAC pregunta “¿qué roles tienes?” ABAC pregunta “dado quién eres, qué estás tocando, qué intentas hacer y las condiciones actuales — ¿la política lo permite?” Cada una de esas palabras en negrita es un cubo de atributos, y una política ABAC es un conjunto de reglas sobre ellos. Como los atributos se leen en el momento de la solicitud, ABAC puede expresar exactamente las condiciones dinámicas y contextuales que rompieron a RBAC — y puede hacerlo sin precrear nada, porque una regla sobre “tu región coincide con la región del recurso” cubre todas las regiones a la vez.

Esto no es una idea marginal. Está estandarizada en NIST SP 800-162, la guía autoritativa de ABAC, y es el motor conceptual dentro de los lenguajes de política modernos y la autorización en la nube. Entender bien ABAC es también lo que hace legible el siguiente módulo — arquitectura de autorización, políticas como código, motores de grano fino — porque todo ello es maquinaria para evaluar políticas de atributos a escala.

Una breve historia

La intuición es vieja — Bell-LaPadula comparaba un atributo de habilitación con un atributo de clasificación allá por los años setenta, así que en cierto sentido MAC fue un ancestro rígido, de dos atributos, de ABAC. Pero ABAC como modelo general maduró con XACML (eXtensible Access Control Markup Language, estandarizado por OASIS en los 2000), que dio a las políticas de atributos una estructura formal de solicitud/respuesta y un lenguaje de política. NIST luego publicó SP 800-162 en 2014 como la guía definitiva, enmarcando ABAC como el modelo que escala el control de acceso a entornos grandes, dinámicos y entre organizaciones donde preaprovisionar cada relación es imposible. Ese momento no es coincidencia: ABAC se volvió mainstream exactamente cuando la nube, el SaaS y la federación hicieron el acceso inherentemente contextual y los roles por sí solos dejaron de ser suficientes. El modelo respondió a un problema que la industria acababa de adquirir.

Los cuatro tipos de atributo

Un atributo es solo una propiedad con nombre y un valor: departamento = "soporte", clasificacion = "confidencial", hora = 14:30. NIST SP 800-162 los organiza en cuatro categorías, y aprender a clasificar un requisito en estos cubos es la mayor parte de la habilidad de pensar en ABAC.

Los atributos del sujeto describen a quien solicita: departamento, puesto, habilitación, gerente, equipo, certificaciones, tipo de empleo. 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 calificadores como el monto de una transacción, lo que permite a una sola regla distinguir “aprobar un reembolso pequeño” de “aprobar uno grande” sin inventar acciones separadas. Los atributos del entorno describen el contexto independiente de quién y qué: hora actual, día de la semana, ubicación o red de origen, postura del dispositivo, fuerza de autenticación, nivel de amenaza actual. Estos son los atributos que hacen el acceso temporal — el mismo sujeto y recurso pueden dar decisiones distintas a las 3 a. m. que al mediodía. Una sola regla de política alcanza a través de estas categorías, y ese alcance es exactamente lo que da a ABAC su poder.

Considera la regla que RBAC no pudo expresar: “un agente de soporte puede leer una cuenta de cliente solo si la región de la cuenta coincide con la región del agente, solo mientras el agente tenga un ticket abierto asignado para ese cliente, y solo durante el horario laboral.” En ABAC esto es una sola regla: comparar un atributo del sujeto (región del agente) con un atributo del recurso (región de la cuenta), comprobar una relación capturada como atributo (ticket abierto asignado), y comprobar un atributo del entorno (horario laboral). Sin roles nuevos; una política cubre a todo agente, región y cliente.

Dos de esas categorías merecen una nota. Los atributos no necesitan estar almacenados — algunos son derivados o computados bajo demanda. esGerenteDe(sujeto, recurso.dueno) o ticketAbierto(agente, cliente) no son campos en una base de datos; son preguntas respondidas llamando a otro sistema en el momento de la decisión. Esto es poderoso (las políticas pueden razonar sobre relaciones y cálculos en vivo) y peligroso (cada atributo derivado es otra dependencia que puede ser lenta, errónea o no estar disponible). Y los atributos del entorno son los que RBAC estructuralmente no puede tocar en absoluto: un rol se asigna una vez y no puede conocer la hora, ubicación o riesgo actuales. En el instante en que un requisito contiene la palabra “cuándo” o “dónde”, casi con seguridad estás mirando un atributo del entorno, y casi con seguridad fuera del alcance de RBAC.

Una política es reglas sobre atributos

Una política ABAC es una colección de reglas, cada una de las cuales evalúa atributos a una decisión — permitir o denegar. Escrita en pseudo-política sencilla, la regla de soporte de arriba se ve así:

permitir si
  accion == "leer"
  y sujeto.rol == "agente_soporte"
  y recurso.tipo == "cuenta_cliente"
  y sujeto.region == recurso.region
  y ticketAbierto(sujeto.id, recurso.cliente_id)
  y entorno.hora en horario_laboral

Cada cláusula es una comparación de atributos. Cambia “leer” por “cerrar_cuenta” y exige sujeto.rol == "supervisor" y tienes una segunda regla. La política completa es el conjunto de tales reglas más una forma de combinarlas (abajo). Nota lo que está ausente: no hay una lista de qué agentes pueden tocar qué cuentas. Esa lista se computa a partir de atributos en cada solicitud, que es por lo que ABAC escala a situaciones que RBAC necesitaría millones de concesiones para cubrir — y también por lo que, como veremos, responder “¿quién puede tocar esta cuenta?” se vuelve una pregunta genuinamente difícil.

flowchart LR
  accTitle: Flujo de decisión del Control de Acceso Basado en Atributos
  accDescr: Un sujeto emite una solicitud para realizar una acción sobre un recurso. Esa solicitud va a un motor de políticas en el centro. Cuatro fuentes de atributos alimentan el motor: atributos del sujeto como departamento y región, atributos del recurso como dueño y clasificación, atributos de la acción como leer o aprobar, y atributos del entorno como hora y ubicación. El motor evalúa sus reglas de política contra todos los atributos reunidos y devuelve una decisión de permitir o denegar al punto de aplicación frente al recurso.
  REQ[Sujeto solicita acción sobre 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 vienen los atributos

Una política es solo tan buena como los atributos que lee, y esos atributos tienen que venir de algún lugar autoritativo. Los atributos del sujeto típicamente fluyen del sistema de RRHH y del proveedor de identidad (departamento, puesto, gerente) — a menudo llevados en los tokens del módulo anterior. Los atributos del recurso vienen de los sistemas que poseen los datos: un esquema de etiquetado, un servicio de clasificación de datos, una CMDB. Los atributos del entorno vienen del runtime: el reloj, la red, las señales de postura del dispositivo y riesgo que el Algoritmo de Confianza de Zero Trust también consume.

Este es el corazón silencioso de la dificultad de ABAC. Cada atributo necesita una fuente autoritativa, un significado acordado y un proceso que lo mantenga fresco. Si la region de una cuenta es errónea, o el departamento de un usuario tiene un año de antigüedad, la política toma decisiones confiadas y equivocadas — y a diferencia de una mala asignación de rol, que un humano podría notar en una revisión, un mal atributo es invisible hasta que produce un mal acceso. ABAC no elimina la carga de gobernanza que tiene RBAC; la reubica de gestionar roles a gestionar atributos y sus fuentes. Las organizaciones que adoptan ABAC sin un programa de gobernanza de atributos simplemente cambian la dispersión de roles por errores silenciosos guiados por datos.

La trampa de la consistencia semántica

Hay un problema de atributos más sutil que la obsolescencia: el significado. Cuando una política compara sujeto.region con recurso.region, ambos lados deben significar lo mismo — mismo vocabulario, misma granularidad, misma codificación. Si RRHH registra la región como "EMEA" pero el etiquetador de recursos escribe "Europa", la regla silenciosamente nunca coincide, y una política que parece correcta deniega (o permite) por la razón equivocada. Multiplica esto por decenas de atributos que fluyen de RRHH, el IdP, una CMDB y una docena de equipos de aplicación, y la deriva semántica se vuelve una causa principal de errores de autorización. Los programas ABAC maduros por tanto invierten en un esquema de atributos — un catálogo gobernado que define el nombre, tipo, valores permitidos y fuente autoritativa de cada atributo — para que “región” signifique una cosa en todas partes. Este es trabajo poco glamoroso de gobernanza de datos, y es la diferencia entre un despliegue ABAC que se sostiene y uno que se pudre en silencio.

Combinar reglas: qué pasa cuando no coinciden

Las políticas reales tienen muchas reglas, y dos reglas pueden llegar a conclusiones opuestas sobre la misma solicitud — una permite, otra deniega. Un algoritmo de combinación resuelve el conflicto de forma determinista. Los comunes son deny-overrides (si alguna regla deniega, el resultado es denegar — el default seguro), permit-overrides (cualquier permitir gana), first-applicable (la primera regla que coincide decide) y only-one-applicable. La elección es una decisión de seguridad: deny-overrides es conservador y usualmente correcto, pero debes entender qué algoritmo usa tu motor, porque el mismo conjunto de reglas produce respuestas distintas bajo combinadores distintos. Un equipo que asume deny-overrides mientras corre un motor con default permit-overrides ha, en efecto, invertido la seguridad de cada conflicto en su política sin darse cuenta.

También está la cuestión de qué hacer cuando un atributo necesario simplemente falta — el feed está caído, al token le falta un claim. Una política bien diseñada es explícita sobre esto: tratar los atributos ausentes como denegación (fail-closed) para acciones sensibles, y nunca dejar que “atributo no presente” satisfaga accidentalmente una condición. Estas semánticas de combinación y de default son exactamente los detalles que los lenguajes formales de política (XACML, Rego, Cedar) hacen rigurosos, que es el puente al módulo de arquitectura de autorización que viene.

Como estas interacciones son sutiles, probar deja de ser opcional en el momento en que las políticas se enriquecen. Un conjunto de reglas con una docena de condiciones superpuestas y un algoritmo de combinación es en efecto un pequeño programa, y como cualquier programa necesita un conjunto de pruebas: solicitudes representativas con decisiones esperadas conocidas, ejecutadas cada vez que la política cambia, para que añadir una regla no voltee silenciosamente una decisión no relacionada. Precisamente por esto la industria se movió hacia las políticas como código — expresar la política en un lenguaje que puedes versionar, revisar y probar unitariamente — que es el tema de un artículo dos adelante. Tratar una política ABAC como configuración sin probar es cómo un modelo “más preciso” produce un comportamiento menos predecible que los roles que reemplazó.

El problema de la consulta inversa

La expresividad de ABAC tiene un costo preciso, y vale la pena enunciarlo con nitidez porque sorprende a la gente. RBAC hace trivial “¿quién puede acceder a este recurso?” — lee la lista de roles que lo conceden. ABAC hace esa pregunta genuinamente difícil, porque el acceso no se almacena, se computa. Para responder “¿quién puede leer esta cuenta?” debes, en principio, evaluar la política para cada sujeto posible bajo cada condición relevante, ya que no hay lista que leer — solo una regla que da una respuesta una vez que provees un sujeto y un momento concretos.

Este es el problema de la consulta inversa (o “revisión centrada en el recurso”), y es la otra cara del poder de ABAC. Complica las revisiones de acceso, las auditorías y preguntas como “¿alguien fuera de Finanzas tiene un camino a la nómina?” — el tipo de cosa que un auditor pregunta rutinariamente y que un sistema solo-ABAC no puede responder por inspección. Los despliegues maduros lo mitigan con herramientas que enumeran o simulan decisiones, y es una razón mayor por la que las organizaciones mantienen roles en la mezcla: un rol es un hecho almacenado y legible, y mantener la decisión gruesa basada en roles preserva la auditabilidad que las políticas de atributos puras sacrifican.

El ángulo de cumplimiento afina por qué esto importa. Las regulaciones y auditorías son abrumadoramente centradas en el recurso: “demuestra quién puede acceder a los datos de tarjetas”, “atestigua la lista de todos con acceso a este sistema”. Estas son precisamente consultas inversas, y un sistema que solo puede responder la pregunta directa (“¿puede esta persona específica hacer esta cosa específica ahora mismo?”) es estructuralmente incómodo de auditar. Esto no es razón para evitar ABAC — su expresividad suele ser indispensable — pero es razón para diseñar para la auditabilidad desde el principio: mantén una capa de roles legible para las concesiones gruesas, registra cada decisión con los atributos que la impulsaron, e invierte en herramientas de consulta antes de la primera auditoría en lugar de durante ella. La expresividad y la auditabilidad tiran una contra la otra, y fingir lo contrario es cómo los equipos descubren la tensión en el peor momento posible.

Beneficios, con honestidad

ABAC gana su complejidad donde el acceso es genuinamente condicional. Es dinámico: las decisiones reflejan el estado del mundo en el momento de la solicitud, así que el acceso se aprieta automáticamente cuando el riesgo sube o un ticket se cierra, sin acción administrativa. Es de grano fino: una regla puede controlar un solo campo de un solo registro sobre una combinación precisa de condiciones. Es escalable en expresividad: una política cubre cada región, tenant o cliente, reemplazando lo que sería una pila combinatoria de roles. Y externaliza la autorización: las políticas viven en un lugar en vez de estar dispersas como sentencias if por el código de la aplicación — el tema que desarrolla todo el siguiente módulo. Para el SaaS multitenant, las plataformas con muchos datos y las arquitecturas Zero Trust, estos no son lujos; son la única forma en que las reglas de acceso pueden expresarse en absoluto.

El caso multitenant vale la pena detenerse porque es donde ABAC se vuelve innegociable. Una plataforma SaaS con diez mil tenants de clientes no puede acuñar roles por tenant — eso es explosión de roles por definición. Pero una sola regla ABAC, “un usuario puede acceder a un registro solo si registro.tenant == sujeto.tenant”, hace cumplir un aislamiento de tenants perfecto para los diez mil a la vez, y sigue funcionando para el diez-mil-uno sin cambios. Este único patrón — coincidencia de tenant como comparación de atributos — sostiene silenciosamente una gran fracción del SaaS que usas, y simplemente no es expresable en RBAC puro. Cuando la gente dice que ABAC “escala”, esto es la cosa concreta que quieren decir: el tamaño de la política permanece constante mientras el número de sujetos y recursos crece sin límite.

Retos, con honestidad

Los costos son igual de reales. La gobernanza de atributos, como arriba, es el dominante — la corrección del modelo descansa enteramente en la calidad de los datos. La auditabilidad sufre por el problema de la consulta inversa: el acceso dinámico es más difícil de inspeccionar que una lista almacenada. Razonar es más difícil: una política rica de atributos puede tener interacciones sutiles, y es fácil escribir reglas que se superponen o contradicen de formas que nadie pretendió, así que probar se vuelve esencial en lugar de opcional. El rendimiento debe diseñarse: leer atributos frescos y evaluar la política en cada solicitud añade latencia, así que los sistemas reales cachean atributos y decisiones con cuidado. Y hay un riesgo genuino de explosión de políticas — el análogo ABAC de la explosión de roles — donde una pila desestructurada de reglas se vuelve tan inmantenible como una pila desestructurada de roles. ABAC mueve la complejidad; no la abole.

Vale la pena ser explícito en que ABAC no escapa mágicamente de la trampa que fue inventado para resolver. La explosión de roles venía de codificar cada condición como un rol nuevo; la explosión de políticas viene de codificar cada caso especial como una regla nueva, y un sistema ABAC con mil reglas ad hoc y superpuestas no es más gobernable que mil roles — posiblemente menos, porque las reglas interactúan de formas que los roles no. El escape es la estructura, no la elección del modelo: agrupa las reglas por tipo de recurso, factoriza las condiciones compartidas en predicados reutilizables, nombra y asigna dueño a cada política, y prueba el conjunto completo. Las organizaciones que triunfan con ABAC tratan la política como una base de código diseñada y mantenida; las que fracasan la tratan como un lugar para atornillar excepciones hasta que nadie puede predecir lo que hace.

ABAC es el motor de Zero Trust

Si ABAC se siente abstracto, nota que ya lo conociste con otro nombre. El Algoritmo de Confianza de Zero Trust — la cosa dentro del Policy Decision Point que pondera identidad, postura del dispositivo, ubicación y riesgo en cada solicitud — es una política de atributos. “Conceder acceso solo si el usuario está autenticado, el dispositivo cumple, la ubicación no es anómala y la puntuación de riesgo es baja” es una regla sobre atributos del sujeto, el entorno y el recurso, evaluada continuamente. La Confianza Adaptativa Continua es el “los atributos se releen en el momento de la solicitud” de ABAC aplicado a toda una sesión: cuando un dispositivo deja de cumplir o el riesgo se dispara, la mismísima política que permitió el acceso ahora deniega, sin administrador de por medio.

Por esto los modelos de este módulo no son académicos. Zero Trust, el colofón del módulo anterior, se implementa como política basada en atributos; ABAC es el nombre formal de cómo se toman sus decisiones. Cada comprobación de postura del dispositivo, disparador de step-up y bloqueo basado en riesgo es una comparación de atributos. Ver ABAC y Zero Trust como la misma maquinaria vista a distintas altitudes — una una estrategia, el otro su modelo de decisión — es una de las conexiones más clarificadoras de la seguridad de identidad.

Hacerlo rápido: caché y latencia de decisión

Leer atributos frescos y evaluar una política en cada solicitud suena costoso, e ingenuamente lo es. Una decisión podría necesitar atributos del token, de un almacén de etiquetas de recursos y de un feed de riesgo en vivo — saltos de red que, sin gestionar, añaden latencia a cada acción que un usuario realiza. Los sistemas ABAC reales diseñan alrededor de esto. Los atributos que cambian lentamente (departamento, clasificación) se cachean con un tiempo de vida sensato; los atributos que deben estar al día (riesgo, postura del dispositivo) se leen en vivo o se empujan como eventos. Las decisiones mismas a veces se cachean para solicitudes repetidas idénticas, con cuidado, para que una revocación no se ignore. Y la evaluación de la política se mantiene cerca del punto de aplicación para evitar un viaje de ida y vuelta.

Estos son los mismos compromisos de latencia contra frescura que viste con las sesiones y la revocación de tokens en el módulo anterior, y son exactamente lo que los artículos de autorización de grano fino y autorización descentralizada del siguiente módulo abordan en profundidad. La conclusión aquí es que el “evaluar todo en el momento de la solicitud” de ABAC es un compromiso de diseño con una factura de rendimiento, y tratar esa factura como una ocurrencia tardía es cómo un elegante modelo de política se convierte en una aplicación lenta. La expresividad se compra con ingeniería.

El híbrido: roles y atributos juntos

En la práctica el encuadre RBAC-contra-ABAC es una falsa elección; la respuesta madura es ambos, y la forma más limpia de verlo es que un rol es solo un atributo del sujeto. Mantén los roles para la decisión gruesa, estable y auditable — “¿es esta persona un agente de soporte siquiera?” — y superpón reglas de atributos para la parte condicional y dinámica — “…y ¿es esta la región, el ticket y la hora correctos?”. Obtienes la legibilidad de RBAC para la base y la flexibilidad de ABAC para las condiciones, evitando tanto la explosión de roles como el caos de las políticas de atributos.

Esto es exactamente lo que envían las plataformas mayores. AWS empareja los roles IAM con claves de condición y etiquetas de recursos, así que un rol concede una clase de acción y las condiciones la estrechan por coincidencia de etiquetas (un patrón ABAC canónico que AWS mismo llama “control de acceso basado en atributos”). Hecho concreto, el idioma de coincidencia de etiquetas se lee como una comparación de atributos incrustada en una política IAM:

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

Esa única sentencia dice “permitir leer cualquier objeto cuya etiqueta region sea igual a la etiqueta region del propio principal” — una sola regla que cubre cada región a la vez, exactamente la jugada ABAC que necesitaría un rol por región bajo RBAC puro. Azure adjunta condiciones ABAC a las asignaciones de rol con el mismo espíritu. Y los motores de políticas del siguiente módulo — OPA, Cedar — tratan roles y atributos uniformemente como entradas más. La lección de tres artículos es consistente: cada modelo responde algo que el anterior no pudo, y los sistemas reales los componen en lugar de coronar a un ganador.

Un ejemplo trabajado: el roadmap, por fin resuelto

Vuelve al roadmap de Sara una última vez en este hilo. La regla que derrotó a RBAC — “un agente de soporte puede leer el roadmap solo para su región y solo mientras tenga un ticket abierto que lo referencie, durante el horario laboral” — es una sola política ABAC: coincidir sujeto.region con recurso.region, comprobar la relación ticketAbierto, y probar entorno.hora. Cubre a todo agente y región a la vez, no necesita roles por región, y se aprieta automáticamente en el momento en que un ticket se cierra o el horario laboral termina, porque los atributos se releen en la siguiente solicitud. El problema que forzó la explosión de roles es ahora una regla legible.

Y nota el nuevo borde apareciendo, justo a tiempo. Nuestra regla se apoyó en ticketAbierto(sujeto.id, recurso.cliente_id) — una relación entre el sujeto y el recurso específico. ABAC puede consumir eso como un atributo si algo lo computa y lo provee, pero expresar el acceso principalmente en términos de relaciones entre entidades — “puede editar el documento porque eres miembro del equipo que es dueño de la carpeta en la que vive” — es incómodo de modelar como atributos planos y costoso de evaluar. Esa es la costura donde el siguiente modelo, el control de acceso basado en relaciones, toma el relevo. Cada modelo pasa el testigo al que resuelve su caso difícil residual — ABAC resolvió la ceguera al contexto de RBAC, y su propia torpeza con las relaciones profundas es precisamente lo que motiva al modelo siguiente.

Recap

El Control de Acceso Basado en Atributos hace del acceso una función del contexto, evaluada en el momento de la solicitud:

1. 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 (NIST SP 800-162), leídos cuando ocurre la solicitud — así que el acceso puede depender de la región, la propiedad, la hora, el dispositivo y el riesgo.
2. Una política es reglas sobre atributos. Cada regla compara atributos para llegar a permitir o denegar; una regla cubre cada sujeto y recurso, que es cómo ABAC expresa lo que RBAC necesitaría un número combinatorio de roles para cubrir.
3. La gobernanza de atributos es el trabajo real. El modelo es solo tan correcto como las fuentes, significados y frescura de sus atributos — atributos basura producen decisiones confiadas y equivocadas.
4. La expresividad tiene costos. 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 defaults de atributos faltantes, y la explosión de políticas es un modo de fallo real.
5. La respuesta es híbrida. Un rol es un atributo; los sistemas maduros usan roles para la base gruesa y auditable y reglas de atributos para las condiciones dinámicas — como envían tanto AWS como Azure.

Tres preguntas para ponerte a prueba

1. Toma la regla “un gerente puede aprobar un gasto solo para sus propios reportes, solo hasta su límite de aprobación, y solo si el gasto está en un periodo de reporte abierto”. Clasifica cada condición en atributos de sujeto, recurso, acción o entorno, y explica por qué RBAC solo no puede expresarla.
2. Tu auditor pregunta “¿quién puede leer registros de clientes en la región de la UE?”. Explica por qué esto es fácil bajo RBAC y difícil bajo ABAC puro, nombra el problema, y describe dos formas en que un despliegue ABAC real hace la pregunta respondible.
3. Un equipo propone reemplazar todos los roles con políticas de atributos. Da dos ventajas concretas y dos riesgos concretos, y arma el caso para un híbrido en su lugar — incluyendo 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 pseudo-reglas. Elige una regla de acceso real de un sistema que conozcas y escríbela como una regla ABAC, etiquetando la categoría de atributo de cada cláusula. Luego identifica, para cada atributo, cuál es la fuente autoritativa y cuán obsoleto podría estar.
2. Encuentra ABAC en tu nube. En AWS o Azure, localiza una política que use una condición — una política IAM con un bloque Condition y una comparación de etiquetas, o una asignación de rol 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 es errónea.
3. Ejercita la consulta inversa. Para una política de atributos, intenta responder “¿quién puede acceder al recurso X?” a mano. Nota que debes enumerar sujetos y condiciones en lugar de leer una lista. Esboza qué necesitaría hacer una herramienta para responderla automáticamente — este es el problema de diseño que el artículo de autorización de grano fino retomará.