Control de Acceso Basado en Políticas (PBAC): la autorización como política explícita

Diecisiete copias de una regla

Cuando cumplimiento cambia la regla de acceso de soporte, para que los agentes solo puedan ver la cuenta de un cliente mientras tengan abierto un ticket suyo, le preguntan a David cuánto tardará el cambio. Busca la comprobación actual en el código y la encuentra diecisiete veces, repartida por seis servicios. Tres de las copias no coinciden con las demás: una nunca comprobaba la región, otra aplicaba la comprobación al leer cuentas pero no al exportarlas, y otra era una versión de hace dos años que alguien pegó y nunca actualizó. Nadie sabe decir con seguridad cuál es hoy la regla de acceso real del sistema, y cambiarla supone editar diecisiete sitios y esperar que todos queden iguales.

El artículo del ABAC terminaba con una pseudopolítica, un pequeño bloque de cláusulas permit if sobre atributos. Ese bloque dejaba abierta una pregunta: ¿dónde vive realmente la política y quién la evalúa? Históricamente la respuesta ha sido desoladora. La lógica de autorización acaba repartida por el código de las aplicaciones en forma de miles de sentencias if, enterrada en controladores y middleware, duplicada sin coherencia entre servicios, invisible para los auditores y modificable solo publicando código nuevo. El control de acceso basado en políticas (PBAC) responde a ese problema convirtiendo la política en un artefacto explícito por derecho propio, escrito en un lenguaje formal, guardado en un único sitio y evaluado por un motor dedicado.

El PBAC y el ABAC son primos cercanos, y a menudo se usan como sinónimos. La diferencia que merece la pena conservar es de énfasis. El ABAC trata de las entradas de una decisión, los atributos. El PBAC trata de cómo se expresa y se ejecuta la propia lógica de decisión, como política declarativa y externalizada, separada del código que la aplica. Casi todos los sistemas PBAC se basan en atributos por dentro, así que la forma más limpia de pensar en él es como el ABAC llevado a la operación: coger la lógica de atributos que describía el ABAC y elevarla a un documento de política gobernado y a un motor de decisión real que se puede versionar, probar y auditar.

La idea de que la política debe ir separada del mecanismo es antigua, pero el PBAC tomó forma en torno a XACML, el eXtensible Access Control Markup Language que OASIS estandarizó a mediados de los 2000. XACML hizo dos cosas que perduran. Definió una arquitectura de referencia, el PEP, el PDP, el PIP y el PAP que trata el artículo de la arquitectura XACML, que separaba limpiamente decidir, aplicar y administrar, y le dio a la política una estructura formal de conjuntos de políticas, políticas y reglas con un protocolo de petición y respuesta. Su XML era farragoso y su adopción desigual, pero su arquitectura ganó del todo: cualquier motor de autorización moderno, sea cual sea su lenguaje, es una implementación reconocible del patrón que XACML bautizó. En la década de 2010 llegaron sucesores más ligeros y amables para los desarrolladores, el Rego de Open Policy Agent y después el Cedar de AWS, que mantuvieron la separación de responsabilidades de XACML y se libraron del XML.

La jugada central: separar la decisión del código

La idea que define al PBAC es una separación que suena sencilla y lo cambia todo: el código que aplica una decisión no debería ser el que la toma. Una aplicación debería preguntar si este sujeto puede hacer esta acción sobre este recurso en estas condiciones, y aplicar la respuesta, mientras que la lógica que produce la respuesta vive fuera, en la política. Es la autorización externalizada, y sus dos mitades ya tienen nombre desde el artículo de Zero Trust: el punto de aplicación de políticas (PEP), el código de la app que pregunta y aplica, y el punto de decisión de políticas (PDP), el motor que evalúa la política y responde.

En cuanto haces esa separación, la autorización deja de ser una propiedad de cada aplicación y pasa a ser un servicio compartido. Diez microservicios ya no reinventan cada uno “quién puede ver este pedido”; todos preguntan al mismo PDP, que evalúa la misma política. Cambias la regla una vez y todos los servicios cambian a la vez, sin redesplegar nada. Esa sola propiedad, una política y muchos aplicadores, es la razón de que las grandes organizaciones inviertan en PBAC.

Merece la pena ver por qué la alternativa en línea falla con tanta fiabilidad, porque el fallo no es pereza sino estructura. Cuando cada servicio tiene sus propias comprobaciones, la misma regla se implementa de forma un poco distinta en cada uno, justo como encontró David: un equipo olvida la condición de la región, otro la aplica a las lecturas pero no a las exportaciones, un tercero copia una versión antigua. No hay un único sitio donde leer las reglas de acceso, así que las auditorías se convierten en arqueología y cada cambio corre el riesgo de dejarse una copia. La externalización no solo ordena esto; hace imposible la deriva, porque solo hay una copia que cambiar.

flowchart LR
  accTitle: Autorización externalizada con un punto de decisión compartido
  accDescr: Dos aplicaciones, App A y App B, contienen cada una un punto de aplicación de políticas. Los dos puntos de aplicación envían consultas de autorización a un único punto de decisión compartido en el centro. El punto de decisión carga una política formal desde un almacén de políticas y obtiene datos, como atributos del sujeto y del recurso, de varias fuentes. Evalúa la política con esos datos y devuelve una decisión de permitir o denegar al punto de aplicación que preguntó. El diagrama destaca que una sola política sirve a muchas aplicaciones.
  A[App A<br/>PEP] -->|¿puede el sujeto hacer la acción?| PDP{Punto de decisión<br/>PDP}
  B[App B<br/>PEP] -->|¿puede el sujeto hacer la acción?| PDP
  POL[(Política formal)] --> PDP
  DATA[(Datos de sujeto / recurso)] --> PDP
  PDP -->|permitir / denegar| A
  PDP -->|permitir / denegar| B

Por qué importa un lenguaje formal

El segundo pilar del PBAC es que la política se escribe en un lenguaje formal y declarativo y no en código de propósito general. No es pedantería; abre posibilidades concretas. Una política en Rego, el lenguaje de Open Policy Agent, en Cedar, el lenguaje de AWS, o en XACML se puede versionar en control de código como cualquier artefacto, probar con tests unitarios a partir de peticiones de ejemplo y decisiones esperadas, revisar en una pull request entre seguridad y los dueños de la aplicación y, en algunos lenguajes, analizar para comprobar propiedades como “¿puede un usuario sin autenticar llegar a algún recurso?”. Nada de eso es fiable cuando la regla es un if enterrado tres llamadas más abajo dentro de un servicio.

Declarativo significa también que la política dice qué está permitido y no cómo comprobarlo, así que se lee más cerca del requisito. Esta es la regla de soporte en Rego:

package authz
 
default allow = false
 
allow if {
  input.action == "read"
  input.subject.role == "support_agent"
  input.subject.region == input.resource.region
  input.resource.type == "customer_account"
  ticket_open
}
 
ticket_open if {
  some t in data.tickets
  t.agent == input.subject.id
  t.customer == input.resource.customer_id
  t.status == "open"
}

Es la regla que el artículo del ABAC escribía en pseudocódigo, ahora como un artefacto ejecutable y que se puede probar. Un revisor puede leerla, vive en un solo fichero y cambiar la condición del ticket no toca ni una aplicación. Es la regla que David cambia ahora una vez en lugar de diecisiete. El código de autorización imperativo responde a “¿qué comprobaciones hace este endpoint?”, una pregunta con una respuesta distinta en cada endpoint, y así nace la deriva. La política declarativa responde a “¿cuál es la regla?”, con una sola respuesta en todas partes. Cuando la autorización es declarativa, puedes hacerle las preguntas de un auditor directamente a la política en lugar de deducirlas del código, y eso suele ser la mayor ganancia práctica de adoptar el PBAC.

Más que permitir o denegar

Algo que distingue a un PBAC maduro de un simple sí o no es que una decisión puede llevar algo más que un veredicto. XACML formalizó dos extras que los buenos sistemas de autorización siguen usando. Una obligación es algo que el punto de aplicación tiene que hacer cuando actúa sobre una decisión: “permitir, pero registrar este acceso en la auditoría” o “denegar y avisar al equipo de seguridad”. Un consejo (advice) es una recomendación más suave y opcional que el PEP puede seguir: “permitir y mostrar un aviso sobre el tratamiento de los datos”. La decisión pasa a ser un pequeño juego de instrucciones en lugar de un veredicto desnudo.

La autorización real rara vez es una simple barrera. “Puedes exportar este informe, pero la exportación tiene que llevar marca de agua y quedar registrada” es una sola decisión con una obligación asociada, y expresarla en una política mantiene el requisito de seguridad atado al acceso en lugar de repartido en código aparte que alguien olvidará. Las obligaciones son la forma en que el PBAC expresa “permitido, con condiciones”, autenticación escalonada, registro obligatorio, una pregunta por el motivo del acceso, una concesión que caduca, en el mismo sitio donde viven el permitir y el denegar.

Cómo le llegan los datos al motor

Una política no hace nada sin datos, los atributos y relaciones que comprueba, y hay dos formas de hacérselos llegar al motor. En el modelo de consulta (pull), el PDP busca lo que necesita en el momento de decidir, llamando al proveedor de identidad, a un servicio de recursos o a una fuente de riesgo mientras evalúa. Los datos están todo lo frescos que pueden estar, pero cada decisión gana latencia y dependencias externas, y una fuente de datos lenta hace lenta la autorización. En el modelo de envío (push), los datos llegan al motor por adelantado, empaquetados con la política o enviados a medida que cambian, así que la evaluación es local y rápida, a cambio de que los datos sean tan frescos como la última actualización.

El PBAC de alto rendimiento se apoya sobre todo en el envío. Open Policy Agent, por ejemplo, evalúa sobre datos cargados en el motor en lugar de llamar fuera a mitad de la decisión, y eso es lo que le permite decidir en microsegundos. Es el mismo equilibrio entre frescura y latencia que viste con las sesiones, la revocación de tokens y la caché de atributos, un tema que se repite en identidad porque todo sistema de autorización tiene que decidir lo actuales que deben ser sus datos y lo que cuesta mantenerlos así.

El ciclo de vida de la política

Tratar la política como un artefacto significa darle un ciclo de vida, como al código, y ponerle nombre a sus etapas es la forma de evitar que degenere en la maraña que venía a curar. La redacción escribe la política, cerca del requisito y con alguien que responda de ella. Las pruebas la ejecutan contra una batería de peticiones representativas con decisiones esperadas conocidas, para que cambiar una regla no rompa otra sin que nadie se entere; es la disciplina más importante del PBAC y la razón de que existan las políticas como código. El despliegue reparte la política entre los motores de decisión, versionada para poder volver atrás. La evaluación es el tiempo de ejecución, el motor respondiendo consultas con la política y los datos actuales. Y la revisión vuelve a examinar cada cierto tiempo la política en busca de reglas obsoletas, solapadas o demasiado amplias, igual que la certificación de accesos poda los roles.

XACML llama punto de administración de políticas (PAP) a las herramientas donde se escriben y gestionan las políticas. Lo importante aquí es que el PBAC no es solo un mecanismo de ejecución; es una práctica, y la práctica decide si la política externalizada se mantiene limpia. Un motor de políticas sin batería de pruebas ni ritmo de revisión se convierte en una maraña opaca igual que el código de aplicación sin cuidar; solo ha cambiado el desorden de sitio.

Convertir la política en un artefacto explícito permite además analizarla, no solo ejecutarla. Como la política es un documento y no código repartido por todas partes, las herramientas pueden hacerle preguntas a todo el conjunto a la vez. El análisis de conflictos encuentra reglas que se solapan y no coinciden, y muestra dónde el algoritmo de combinación está decidiendo en silencio algo que no querías. El análisis de huecos encuentra peticiones que ninguna regla cubre, que caen entonces en el valor por defecto; un hueco con denegación por defecto es una funcionalidad rota y uno con permiso por defecto es un agujero de seguridad. Las comprobaciones de cobertura confirman que cada tipo de recurso y cada acción que expone el sistema están gobernados por alguna regla, y pillan el endpoint que alguien olvidó proteger. Algunos lenguajes de políticas van más allá y admiten razonamiento formal, demostrando propiedades como “ningún principal sin autenticar puede llegar a ningún recurso etiquetado como confidencial” sobre toda la política en lugar de probar un puñado de ejemplos. Eso es imposible cuando la autorización es código imperativo disperso, porque no puedes analizar lo que no ves en un solo sitio.

¿De quién es la política?

La pregunta más difícil del PBAC no es técnica sino organizativa: ¿quién escribe la política y quién es su dueño? Centralizar la autorización crea un único artefacto que lo gobierna todo, lo que sube lo que está en juego en cada cambio y obliga a tomar una decisión que la época del código disperso te dejaba esquivar. Si le das toda la política a un equipo central de seguridad, tienes coherencia pero también un cuello de botella, porque ese equipo frena cada funcionalidad que toca el acceso. Si dejas que cada equipo de aplicación escriba su política libremente, te arriesgas a la deriva y a las autoconcesiones demasiado amplias que el PBAC debía evitar. El término medio que funciona es federado con barandillas: los equipos de aplicación escriben la política de sus propios recursos, un equipo central es dueño de la política base compartida y revisa los cambios, y pruebas y análisis automáticos imponen reglas que nadie puede romper. Acertar con este modelo de funcionamiento importa al menos tanto como elegir el motor de políticas, y es donde los programas de PBAC triunfan o fracasan sin hacer ruido.

La anatomía de una política

El vocabulario de cómo se estructuran las políticas se repite en todos los motores aunque cambie la sintaxis. La unidad más pequeña es una regla, con un objetivo (target) que dice a qué peticiones se aplica (“acciones sobre cuentas de clientes”), una condición opcional para la comprobación más fina (“la región coincide”) y un efecto, permitir o denegar. Las reglas se agrupan en una política, un conjunto coherente de reglas sobre un área con su propio algoritmo de combinación para los desacuerdos internos. Las políticas se agrupan en conjuntos de políticas, que pueden anidarse, cada capa con su propio algoritmo de combinación. Una petición se evalúa de arriba abajo por este árbol, y los algoritmos de combinación de cada nivel van juntando las decisiones parciales en un único permitir o denegar final.

Esa jerarquía no es burocracia; es como una política grande sigue siendo comprensible. Organizar las reglas en políticas por tipo de recurso, y las políticas en conjuntos por dominio, es el equivalente en PBAC de dividir un programa grande en módulos, y es la diferencia entre una política sobre la que se puede razonar y la explosión de políticas que imita a la explosión de roles.

El PBAC como paraguas

Hay una forma útil de ver el PBAC junto a todo lo anterior: como el paraguas bajo el que se pueden expresar los demás modelos. Una política puede codificar una comprobación de rol, subject.role == "admin", que es RBAC dentro de una política. Puede comparar atributos, subject.region == resource.region, que es ABAC dentro de una política. Puede codificar reglas de etiquetas como el MAC, o comprobaciones de relaciones, como muestra el siguiente artículo. El PBAC no compite con el RBAC y el ABAC; les da el vehículo para expresarlos y ejecutarlos de forma uniforme, en un sitio gobernado, con un solo motor.

Por eso tantos sistemas reales se describen como basados en políticas aunque sus reglas traten sobre todo de roles y atributos: lo que define al PBAC no es qué comprueban las reglas, sino que las reglas son política explícita, externalizada y formal. También deshace mucho debate inútil sobre “RBAC frente a ABAC frente a PBAC”. No son tres competidores en un mismo eje. Dos describen en qué se basa una decisión; el tercero describe cómo se expresa y se ejecuta la lógica de decisión. Puedes, y normalmente debes, hacer RBAC y ABAC dentro de un marco PBAC, que es lo que resultan ser los sistemas híbridos de los dos últimos artículos.

El PBAC en la práctica

El modelo es concreto y está muy desplegado. Open Policy Agent (OPA) con su lenguaje Rego es el estándar abierto de facto para la política externalizada, y se usa para autorizar la admisión en Kubernetes, las llamadas a APIs de microservicios y las acciones de CI/CD desde un único motor. AWS Cedar y Amazon Verified Permissions ofrecen un lenguaje de autorización hecho a propósito y un PDP gestionado. XACML es el estándar de OASIS más antiguo, basado en XML, que inauguró la arquitectura de PEP, PDP y PAP y que sigue funcionando en muchos sistemas de empresa y de la administración. Y una oleada de servicios pensados para desarrolladores, los motores de autorización de grano fino, empaquetan las ideas del PBAC tras APIs más amables. Sea el lenguaje Rego, Cedar o XACML, y sea el motor un sidecar, una librería o un servicio gestionado, la forma es la misma: un PEP pregunta, un PDP decide con una política externalizada y los datos llegan desde fuentes con autoridad.

Hay una dirección clara en el sector: la autorización está siguiendo el camino que ya recorrieron la configuración y la infraestructura, del código a medida a los servicios gestionados y declarativos. Igual que los equipos dejaron de escribir a mano scripts de despliegue cuando aparecieron Terraform y Kubernetes, cada vez se resisten más a programar a mano la autorización cuando existen OPA, Cedar y los servicios de permisos alojados. Lo oirás llamar “autorización como capacidad de plataforma”, algo que un servicio consume en lugar de reimplementar, y el PBAC es su condición previa: no puedes ofrecer la autorización como servicio compartido hasta que la política sea un artefacto explícito y externalizado.

Lo que cuesta el PBAC

Las ventajas del PBAC son reales, y también sus costes. Hay una curva de aprendizaje, porque los lenguajes de políticas como Rego son potentes pero poco familiares, y una política mal escrita es un fallo de seguridad. Hay una dependencia en tiempo de ejecución: ahora cada petición incluye una llamada de decisión, que tiene que ser rápida y estar siempre disponible, porque un PDP lento penaliza cada acción y uno caído puede parar todo el sistema si su modo de fallo no se ha diseñado a propósito. Ese modo de fallo es en sí una decisión de seguridad. ¿Debe el PEP fallar cerrado, denegando cuando no puede llegar al PDP y priorizando la seguridad a costa de una caída, o fallar abierto, permitiendo y priorizando la disponibilidad a costa de la seguridad? En las acciones sensibles la respuesta es casi siempre fallar cerrado, y por eso los despliegues reales llevan la política y los datos hasta el punto de aplicación: una decisión local e integrada no se puede cortar por una partición de red. El artículo de la autorización descentralizada trata en buena parte de esto. Está el problema de los datos, idéntico al del ABAC: las decisiones valen lo que valen los atributos y relaciones que recibe el motor. Y está el gobierno, con un peso organizativo real: ¿quién puede escribir políticas, quién las revisa y cómo impides que un equipo de aplicación se escriba sin que nadie lo vea una regla demasiado amplia?

Llevar la autorización a una política central no la hace buena automáticamente; la hace central, y eso solo mejora las cosas si la política es disciplinada. Una política externalizada sin pruebas, sin dueño y con mil reglas improvisadas es probablemente peor que el código disperso, porque ahora un único artefacto enredado lo gobierna todo y nadie se atreve a tocarlo. La herramienta centraliza la autorización; la disciplina es lo que hace que centralizarla salga bien.

Una política, dos servicios y una marcha atrás

Piensa en la fintech de cashback que desarrolla el caso práctico final del dominio. Su app para clientes y su consola interna de soporte tienen que responder a “¿puede este actor ver esta cuenta?”. Sin PBAC, cada una lleva dentro su propia lógica, y el día que cambia la regla alguien tiene que encontrarla y editarla en dos bases de código y esperar que coincidan. Con PBAC, las dos apps solo tienen un PEP, las dos preguntan al mismo PDP y la regla vive en una política Rego. Cambiarla es una pull request revisada y probada sobre un único fichero, desplegada una vez, y los dos servicios obedecen igual un segundo después.

Como la política está versionada, el cambio también se puede deshacer. Si la nueva regla del ticket abierto rompe un flujo de trabajo legítimo, vuelves a la versión anterior de la política, una reversión desplegada en segundos, los dos servicios restaurados, en lugar de correr a redesplegar dos aplicaciones. Los cambios de autorización son justo del tipo que de vez en cuando sale mal en producción, y que se comporten como cualquier otro artefacto versionado convierte un posible incidente en nada. Después se construye una herramienta nueva de revisión de fraude, que simplemente llama al PDP y hereda gratis las mismas reglas de acceso a cuentas. Esa palanca que se acumula, cada servicio nuevo con una autorización coherente con solo preguntar en lugar de reconstruirla, es la recompensa práctica del PBAC.

Incluso aquí hay un límite. La regla se apoyaba todavía en una relación, el ticket asignado a este agente para este cliente. Expresar el acceso sobre todo como una red de relaciones entre entidades es incómodo incluso en un buen lenguaje de políticas, y esa es la costura de la que se hace cargo el siguiente modelo.

Resumen

El control de acceso basado en políticas convierte la decisión de autorización en un artefacto explícito, externalizado y gobernado. La política sale del código: la lógica de autorización deja las sentencias if dispersas y pasa a una política explícita que evalúa un motor dedicado, dividida entre un punto de aplicación que pregunta y aplica y un punto de decisión que decide. Una política sirve a muchos aplicadores, así que un PDP compartido permite que muchas aplicaciones obedezcan las mismas reglas, cambiadas una vez sin redesplegar cada servicio. Un lenguaje formal aporta rigor, haciendo la política versionable, comprobable, revisable y analizable, algo que el código disperso nunca es de forma fiable. El PBAC es el paraguas: roles, atributos, etiquetas y relaciones se pueden expresar como política, y lo que lo define es que la política es explícita, externa y gobernada. Y la disciplina es el precio: un lenguaje de políticas, una dependencia en tiempo de ejecución, la calidad de los datos y el gobierno son costes reales, y sin pruebas, dueños y revisión, una política central solo traslada el desorden.

Tres preguntas para ponerte a prueba

1. Explica la diferencia entre un punto de aplicación de políticas y un punto de decisión de políticas, y describe qué se vuelve posible al separarlos que no lo es cuando la autorización son sentencias if en línea dentro de cada servicio.
2. Un compañero dice: “PBAC y ABAC son lo mismo”. Da la distinción más útil entre ellos y explica por qué casi todos los sistemas PBAC se basan en atributos por debajo, usando la idea del PBAC como ABAC llevado a la operación.
3. Tu equipo lleva la autorización a una única política Rego, pero seis meses después nadie quiere tocarla. Diagnostica qué partes del ciclo de vida de la política se saltaron y nombra tres prácticas que habrían mantenido la política central fácil de mantener.

Ejercicios prácticos

1. Escribe y prueba una política. Con el playground de Open Policy Agent o la herramienta de línea de comandos opa, escribe una pequeña política Rego que permita una acción solo cuando un atributo del sujeto coincida con uno del recurso. Después escribe dos entradas de prueba, una que debería permitir y otra que debería denegar, y ejecútalas. Ese es el bucle central del PBAC: política más pruebas.
2. Encuentra el PEP y el PDP en un sistema que uses. En cualquier plataforma con autorización externalizada, como Kubernetes con OPA Gatekeeper, una service mesh o un servicio de autorización en la nube, identifica qué hace de PEP y qué hace de PDP. Anota dónde se guarda la política y cómo se actualiza.
3. Refactoriza sobre el papel una comprobación en línea. Coge una sentencia if de autorización real de un código que conozcas y reescríbela como una regla de política externalizada. Enumera lo que ganas (versionado, pruebas, una única fuente de verdad) y la nueva dependencia que introduces (una llamada de decisión en el camino de la petición), y decide si el intercambio merece la pena en ese caso.