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

De reglas en tu cabeza a política a la vista

El artículo de ABAC terminó con una pseudo-política: un pequeño bloque de cláusulas permitir si… sobre atributos. Ese bloque planteó silenciosamente una pregunta que el artículo anterior aplazó: ¿dónde vive de verdad esa política, y quién la evalúa? En la mayoría de los sistemas, históricamente, la respuesta es sombría — la lógica de autorización está dispersa por el código de la aplicación como miles de sentencias if, enterrada en controladores y middleware, duplicada de forma inconsistente entre servicios, invisible para los auditores, y cambiable solo enviando código nuevo. El Control de Acceso Basado en Políticas (PBAC) es la respuesta a ese problema: hacer de la política un artefacto explícito y de primera clase, escrito en un lenguaje formal, almacenado en un lugar, y evaluado por un motor dedicado.

PBAC y ABAC son primos cercanos, y la industria a menudo usa los términos indistintamente. La distinción que vale la pena sostener es de énfasis. ABAC trata de las entradas de una decisión — atributos. PBAC trata de cómo se expresa y opera la lógica de decisión misma — como política declarativa y externalizada, desacoplada del código que la hace cumplir. Casi todo sistema PBAC es basado en atributos por dentro, así que la forma más limpia de pensar en PBAC es ABAC operacionalizado: toma la lógica de atributos que describió ABAC y elévala a un documento de política gobernado y a un motor de decisión real que puedes versionar, probar y auditar.

Esta es la rampa de entrada a todo el siguiente módulo. Todo lo que hay allí — la arquitectura de referencia XACML, las herramientas de políticas como código, los motores de grano fino — es maquinaria para hacer bien PBAC a escala. Este artículo es el puente conceptual: por qué la autorización quiere ser política externalizada explícita, antes de que el siguiente módulo se sumerja en cómo se construye.

Una breve historia

La idea de que la política debería separarse del mecanismo es vieja, pero PBAC se cristalizó en torno a XACML, el eXtensible Access Control Markup Language que OASIS estandarizó a mediados de los 2000. XACML hizo dos cosas duraderas: definió una arquitectura de referencia — el PEP, PDP, PIP y PAP que estudiarás el siguiente módulo — que separó limpiamente decidir de hacer cumplir de administrar, y dio a la política una estructura formal de conjuntos de políticas, políticas y reglas con un protocolo de solicitud/respuesta. El XML de XACML era verboso y su adopción despareja, pero su arquitectura ganó por completo; todo motor de autorización moderno, sea cual sea su lenguaje, es reconociblemente una implementación del patrón que XACML nombró. Los años 2010 luego trajeron sucesores más ligeros y amigables para desarrolladores — el Rego de Open Policy Agent, más tarde el Cedar de AWS — que conservaron la separación de responsabilidades de XACML mientras se deshacían de su XML. PBAC hoy es ese linaje: las ideas de XACML, entregadas en herramientas modernas y ergonómicas.

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

La idea definitoria de PBAC es una separación que suena simple y lo cambia todo: el código que hace cumplir una decisión no debería ser el código que la toma. Una aplicación debería preguntar “¿puede este sujeto realizar esta acción sobre este recurso, bajo estas condiciones?” y hacer cumplir la respuesta — pero la lógica que produce la respuesta vive afuera, en la política. Esto es la autorización externalizada, y sus dos mitades ya tienen nombres que conociste en el artículo de Zero Trust: el Policy Enforcement Point (PEP), el código en la app que pregunta y hace cumplir, y el Policy Decision Point (PDP), el motor que evalúa la política y responde.

Una vez que haces esa división, la autorización deja de ser una propiedad de cada aplicación y se convierte en 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. Cambia la regla una vez, y el comportamiento de cada servicio cambia junto, sin redespliegue. Esa única propiedad — una política, muchos ejecutores — es toda la razón por la que las organizaciones grandes invierten en PBAC, porque la alternativa es lógica de autorización desincronizándose entre decenas de bases de código hasta que nadie puede decir cuáles son las reglas de acceso reales del sistema.

Vale la pena detenerse en por qué la alternativa incrustada falla de forma tan confiable, porque el fallo no es pereza sino estructura. Cuando cada servicio posee sus propias comprobaciones, la misma regla se implementa un poco distinta en cada uno — un equipo olvida la condición de región, otro la aplica a las lecturas pero no a las exportaciones, un tercero copia una versión de hace dos años. No hay un solo lugar donde leer “cuáles son nuestras reglas de acceso”, así que las auditorías se vuelven arqueología y cada cambio arriesga olvidar una copia. La externalización no solo ordena esto; hace la deriva imposible, porque solo hay una copia que cambiar. El valor es menos sobre elegancia que sobre eliminar toda una categoría de error de inconsistencia que la autorización incrustada produce por su propia naturaleza.

flowchart LR
  accTitle: Autorización externalizada con un policy decision point compartido
  accDescr: Dos aplicaciones, App A y App B, contienen cada una un Policy Enforcement Point. Ambos puntos de aplicación envían consultas de autorización a un único Policy Decision Point 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 desde fuentes de datos. Evalúa la política contra esos datos y devuelve una decisión de permitir o denegar al punto de aplicación que preguntó. El diagrama enfatiza que una política sirve a muchas aplicaciones.
  A[App A<br/>PEP] -->|¿puede el sujeto hacer la acción?| PDP{Policy Decision Point}
  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 de PBAC es que la política se escribe en un lenguaje formal y declarativo en lugar de en código de propósito general. Esto no es pedantería; desbloquea capacidades concretas. Una política en Rego (el lenguaje de Open Policy Agent), Cedar (el lenguaje de AWS) o XACML puede versionarse en control de código como cualquier artefacto, probarse unitariamente con solicitudes de ejemplo y decisiones esperadas, revisarse en un pull request por seguridad y los dueños de aplicación juntos, y en algunos lenguajes analizarse en busca de propiedades como “¿es algún recurso alcanzable por un usuario no autenticado?”. Nada de eso es posible de forma confiable cuando la regla es un if enterrado tres marcos de llamada abajo en un servicio.

Declarativo también significa que la política enuncia qué se permite, no cómo comprobarlo, así que se lee más cerca del requisito mismo. Compara una comprobación imperativa dispersa con una regla 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"
}

Esa es la misma regla que el artículo de ABAC expresó en pseudocódigo, ahora como un artefacto ejecutable y probable. Es legible para un revisor, vive en un archivo, y cambiar la regla de región no requiere tocar una sola aplicación. El salto de “la autorización es código que escribes por app” a “la autorización es política que creas una vez” es todo el valor del pilar del lenguaje formal.

Más allá de permitir y denegar: obligaciones y advertencias

Una sutileza que distingue al PBAC maduro de una simple comprobación booleana es que una decisión de política puede llevar más que “sí” o “no”. XACML formalizó dos extras que los buenos sistemas de autorización todavía usan. Una obligación (obligation) es una acción que el punto de aplicación debe realizar cuando actúa sobre una decisión — “permitir, pero registra este acceso en la traza de auditoría”, o “denegar, y notifica al equipo de seguridad”. Una advertencia (advice) es una recomendación más suave y opcional que el PEP puede atender — “permitir, y por cierto muestra un aviso de manejo de datos”. La decisión, en otras palabras, no es solo un veredicto sino un pequeño conjunto de instrucciones.

Esto importa porque la autorización real rara vez es una puerta desnuda. “Puedes exportar este informe, pero la exportación debe llevar marca de agua y registrarse” es una sola decisión de política con una obligación adjunta, y expresarla como una política mantiene el requisito de seguridad ligado al acceso en lugar de disperso como código separado y olvidable. Las obligaciones son cómo PBAC codifica “permitido con condiciones” — autenticación step-up, registro obligatorio, avisos de motivo de acceso, concesiones acotadas en el tiempo — limpiamente, en el mismo lugar donde vive el permitir/denegar. Cuando ves un sistema que no solo bloquea el acceso sino que da forma a cómo ocurre el acceso permitido, usualmente estás viendo obligaciones en acción.

Cómo obtiene sus datos el motor: push contra pull

Una política es inerte sin datos — los atributos y relaciones que prueba. Hay dos formas de llevar esos datos al motor de decisión, y la elección es una decisión arquitectónica real. En el modelo pull, el PDP obtiene lo que necesita en el momento de la decisión, llamando al proveedor de identidad, a un servicio de recursos o a un feed de riesgo mientras la política evalúa. Esto mantiene los datos máximamente frescos pero añade latencia y dependencias externas a cada decisión, y una fuente de datos lenta se convierte en una autorización lenta. En el modelo push (o replicado), los datos relevantes se entregan al motor por adelantado — empaquetados con la política o transmitidos a medida que cambian — así que la evaluación es local y rápida, al costo de que los datos estén tan frescos como tu última replicación.

La mayor parte del PBAC de alto rendimiento se apoya en push: Open Policy Agent, por ejemplo, evalúa contra datos cargados en el motor en lugar de llamar afuera a mitad de la decisión, que es exactamente lo que le permite decidir en microsegundos. El compromiso es la misma tensión de frescura contra latencia que conociste con las sesiones, la revocación de tokens y el caché de atributos de ABAC — un tema recurrente en la identidad precisamente porque todo sistema de autorización debe responder “¿cuán actuales son los datos sobre los que decido, y qué me cuesta mantenerlos actuales?”. No hay respuesta gratis, solo una deliberada.

La anatomía de una política

Ayuda conocer el vocabulario de cómo se estructuran las políticas, porque recurre en cada motor aunque la sintaxis difiera. En el nivel más pequeño está una regla (rule): una unidad única con un objetivo (target) (a qué solicitudes aplica — “acciones sobre cuentas de cliente”), una condición opcional (la prueba 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 resolver desacuerdos internos. Las políticas se agrupan en un conjunto de políticas (policy set), y los conjuntos de políticas pueden anidarse, cada capa con su propio algoritmo de combinación. Una solicitud se evalúa de arriba hacia abajo por este árbol, y los algoritmos de combinación en cada nivel pliegan las subdecisiones en un permitir o denegar final.

Esta jerarquía no es burocracia; es cómo la política grande permanece comprensible. Estructurar las reglas en políticas por tipo de recurso, y las políticas en conjuntos por dominio, es el análogo PBAC de factorizar un programa grande en módulos — y, como modularizar código, es la diferencia entre una política que puedes razonar y la “explosión de políticas” que refleja la explosión de roles. Cuando lees un despliegue XACML o un árbol de paquetes Rego bien organizado, esta estructura anidada de objetivo-condición-efecto es el esqueleto de abajo.

PBAC como el modelo paraguas

Hay una forma útil de ver a PBAC en relación con todo lo anterior: como el paraguas bajo el cual los otros modelos pueden expresarse. Una política puede codificar una comprobación de rol (subject.role == "admin") — eso es RBAC dentro de una política. Puede comparar atributos (subject.region == resource.region) — eso es ABAC dentro de una política. Puede incluso codificar reglas de etiqueta como MAC o, como muestra el siguiente artículo, comprobaciones de relación. PBAC no compite con RBAC y ABAC tanto como provee el vehículo para expresarlos y operarlos uniformemente, en un lugar gobernado, con un motor.

Por esto tantos sistemas reales se describen como “PBAC” o “basados en políticas” aunque sus reglas sean en su mayoría guiadas por roles y atributos: la característica definitoria no es qué prueban las reglas sino que las reglas son política explícita, externalizada y formal. También disuelve mucho debate infructuoso de “RBAC contra ABAC contra PBAC” — estos no son tres competidores en un eje. Dos de ellos describen en qué se basa una decisión; el tercero describe cómo se expresa y opera la lógica de decisión. Puedes, y usualmente deberías, hacer RBAC y ABAC dentro de un marco PBAC, que es precisamente lo que resultan ser los sistemas híbridos de los últimos dos artículos.

El ciclo de vida de la política

Tratar la política como un artefacto de primera clase significa que obtiene un ciclo de vida, muy parecido al del código, y nombrar las etapas es cómo la mantienes sin decaer en la misma dispersión que debía curar. La creación (authoring) escribe la política, idealmente cerca del requisito y con un dueño responsable. La prueba (testing) ejecuta la política contra un conjunto de solicitudes representativas con decisiones esperadas conocidas, para que un cambio a una regla no pueda romper silenciosamente otra — la disciplina más importante en PBAC, y la razón por la que existen las políticas como código. El despliegue (deployment) distribuye la política a los motores de decisión, versionada para que puedas revertir. La evaluación es el runtime: el motor responde consultas contra la política y los datos actuales. Y la revisión (review) reexamina periódicamente la política en busca de reglas obsoletas, superpuestas o demasiado amplias, del mismo modo que la recertificación de acceso poda los roles.

Este ciclo de vida se administra a través de lo que XACML llama el Policy Administration Point (PAP) — las herramientas donde se crean y gestionan las políticas — que conocerás formalmente en el siguiente módulo junto al PEP y el PDP. El punto aquí es que PBAC no es solo un mecanismo de runtime; es una práctica, y la práctica es lo que determina si la política externalizada permanece limpia. Un motor de políticas sin conjunto de pruebas y sin cadencia de revisión se convierte en un enredo opaco igual que el código de aplicación sin gestionar — solo ha movido el desorden a una nueva ubicación.

Analizar la política: conflictos, lagunas y cobertura

Un rédito poco apreciado de hacer de la política un artefacto formal explícito es que puedes analizarla, no solo ejecutarla. Como la política es un documento en vez de código difuso, las herramientas pueden hacerle preguntas al conjunto completo a la vez. El análisis de conflictos encuentra reglas que se superponen y no coinciden, sacando a la luz dónde el algoritmo de combinación está decidiendo silenciosamente algo que no pretendías. El análisis de lagunas encuentra solicitudes que ninguna regla cubre, que luego caen al default — y una laguna de default-denegar es una funcionalidad rota mientras que una de default-permitir es un agujero de seguridad. La cobertura comprueba que cada tipo de recurso y acción que un sistema expone esté de hecho gobernado por alguna regla, atrapando el endpoint que alguien olvidó proteger.

Algunos lenguajes de política van más lejos y admiten razonamiento formal — probar propiedades como “ningún principal no autenticado puede alcanzar ningún recurso etiquetado como confidencial” a través de toda la política, en lugar de probar un puñado de ejemplos y esperar. Esto es simplemente imposible cuando la autorización es código imperativo disperso: no puedes analizar lo que no puedes ver en un lugar. La capacidad de tratar la autorización como un artefacto analizable — de preguntar “¿hay alguna forma de alcanzar esto?” y obtener una respuesta real — es uno de los argumentos más profundos a favor de PBAC, y es por lo que los sistemas críticos en seguridad cada vez más lo exigen.

El ciclo de vida continuado: ¿quién es su dueño?

La pregunta más difícil de PBAC no es técnica sino organizacional: ¿quién crea y es dueño de la política? Centralizar la autorización crea un solo artefacto que gobierna todo, lo que eleva las apuestas de cada cambio y fuerza una decisión que la era del código disperso te dejaba esquivar. Empuja toda la política a un equipo central de seguridad y obtienes consistencia pero un cuello de botella — ese equipo se vuelve el bloqueador de cada funcionalidad que toca el acceso. Deja que cada equipo de aplicación escriba su propia política libremente y arriesgas la deriva y las autoconcesiones demasiado amplias que PBAC debía prevenir. El punto medio viable es federado con barandillas: los equipos de aplicación crean política para sus propios recursos, un equipo central posee la política base compartida y revisa los cambios, y las pruebas y análisis automatizados hacen cumplir invariantes que ningún equipo puede violar. Acertar con este modelo operativo importa al menos tanto como elegir un motor de políticas, y es donde los programas PBAC más a menudo triunfan o fallan en silencio.

PBAC en la práctica

El modelo es concreto y ampliamente desplegado. Open Policy Agent (OPA) con su lenguaje Rego es el estándar abierto de facto para la política externalizada, usado para autorizar la admisión de Kubernetes, las llamadas de API entre microservicios y las acciones de CI/CD desde un solo motor de políticas. AWS Cedar y Amazon Verified Permissions ofrecen un lenguaje de autorización dedicado y un PDP gestionado. XACML es el estándar OASIS más antiguo, basado en XML, que fue pionero de la arquitectura PEP/PDP/PAP y todavía corre en muchos sistemas empresariales y de gobierno. Y una ola de servicios enfocados en desarrolladores — los motores de grano fino del siguiente módulo — empaquetan las ideas de PBAC tras APIs más amigables. Lo que comparten es la esencia de PBAC: política como artefacto explícito, evaluada por un motor, externa a las aplicaciones que gobierna.

Reconocer el patrón a través de ellos es el rédito. Sea el lenguaje Rego, Cedar o XACML, y sea el motor un sidecar, una biblioteca o un servicio gestionado, la forma es idéntica — un PEP pregunta, un PDP decide contra política externalizada, y los datos fluyen desde fuentes autoritativas. Aprende la forma una vez y cada uno de estos productos se vuelve una variación de un tema que entiendes, que es exactamente la perspectiva sobre la que construirá el módulo de arquitectura de autorización.

Hay una trayectoria clara de la industria que vale la pena nombrar: la autorización está siguiendo el camino que la configuración y la infraestructura ya tomaron, de código a medida hacia servicios gestionados y declarativos. Igual que los equipos dejaron de hacer a mano scripts de despliegue una vez que existieron Terraform y Kubernetes, cada vez más se rehúsan a hacer a mano la autorización una vez que existen OPA, Cedar y servicios de permisos alojados. La frase que oirás para esto es “autorización como capacidad de plataforma” — algo que un servicio consume en vez de reimplementar. PBAC es la precondición conceptual de ese giro: no puedes ofrecer autorización como servicio compartido hasta que la política sea, en primer lugar, un artefacto explícito y externalizado. Las ideas de este artículo son, en ese sentido, el cimiento sobre el que se construye todo el ecosistema moderno de herramientas de autorización.

Retos, con honestidad

Los beneficios de PBAC son reales, y también lo son sus costos. Hay una curva de aprendizaje: los lenguajes de política como Rego son poderosos pero poco familiares, y una política mal escrita es un error de seguridad. Hay una dependencia de runtime: cada solicitud ahora implica una llamada de decisión, que debe ser rápida y altamente disponible, porque un PDP lento grava cada acción y un PDP caído puede detener todo el sistema a menos que diseñes su modo de fallo deliberadamente. Ese modo de fallo es en sí una decisión de seguridad: ¿debería el PEP fallar cerrado (denegar cuando el PDP es inalcanzable, favoreciendo la seguridad al costo de una caída) o fallar abierto (permitir, favoreciendo la disponibilidad al costo de la seguridad)? Para acciones sensibles la respuesta es casi siempre fallar-cerrado, que es exactamente por lo que los despliegues reales empujan la política y los datos hacia el punto de aplicación — una decisión local e incrustada no puede ser cortada por una partición de red, esquivando el dilema para el caso común. El artículo de autorización descentralizada del siguiente módulo trata en gran parte sobre este problema. Hay el problema de datos, idéntico al de ABAC: las decisiones del motor son solo tan buenas como los atributos y relaciones que le alimentas, así que la gobernanza de atributos no desaparece. Y hay una pregunta de gobernanza con peso organizacional real: ¿a quién se le permite crear política, quién la revisa, y cómo evitas que un equipo de aplicación se escriba silenciosamente una regla demasiado amplia?

Un ejemplo trabajado: una política, dos servicios

Imagina la fintech de cashback que los artículos posteriores desarrollan. Su app de cara al cliente y su consola interna de soporte necesitan ambas responder “¿puede este actor ver esta cuenta?” Sin PBAC, cada una incrusta su propia lógica, y el día que la regla cambia — digamos, los agentes de soporte ahora solo pueden ver cuentas con un ticket abierto — alguien debe encontrar y editar esa lógica en dos bases de código y esperar que coincidan. Con PBAC, ambas apps tienen solo un PEP; ambas preguntan al mismo PDP; la regla vive en una política Rego. Cambiarla es un pull request revisado y probado a un solo archivo, desplegado una vez, y ambos servicios obedecen idénticamente al segundo siguiente.

Hay un segundo beneficio, más silencioso, en este ejemplo: como la política está versionada, el cambio es reversible. Si la nueva regla de “ticket abierto requerido” resulta romper un flujo de trabajo legítimo, reviertes la política a la versión anterior — un revert, desplegado en segundos, ambos servicios restaurados — en lugar de correr a redesplegar dos aplicaciones. Los cambios de autorización son exactamente el tipo de cambio que ocasionalmente sale mal en producción, y hacer que se comporten como cualquier otro artefacto versionado, con un revert limpio, convierte un posible incidente en un no-evento. Esa seguridad es consecuencia directa de que la política sea un artefacto explícito en vez de código incrustado.

Ahora extiéndelo. Se construye una nueva herramienta de revisión de fraude; ella también solo llama al PDP y hereda las mismas reglas de acceso a cuentas gratis, sin reimplementación. Ese apalancamiento compuesto — cada servicio nuevo obtiene autorización consistente preguntando, no reconstruyendo — es la recompensa práctica de PBAC, y es exactamente lo que el módulo de arquitectura convierte en un sistema de grado de producción. Pero nota un límite incluso aquí: nuestra regla todavía se apoyó en relaciones como “el ticket asignado a este agente para este cliente”. Expresar el acceso principalmente como una red de relaciones entre entidades es incómodo incluso en un buen lenguaje de política, y esa es la costura que el siguiente modelo fue construido para poseer.

Recap

El Control de Acceso Basado en Políticas convierte la decisión de autorización en un artefacto explícito, externalizado y gobernado:

1. La política deja el código. La lógica de autorización sale de sentencias if dispersas hacia una política explícita evaluada por un motor dedicado — autorización externalizada, dividida en un Policy Enforcement Point (pregunta y hace cumplir) y un Policy Decision Point (decide).
2. Una política, muchos ejecutores. Un PDP compartido permite que muchas aplicaciones obedezcan las mismas reglas, cambiadas una vez sin redesplegar cada servicio — la victoria operativa central.
3. El lenguaje formal desbloquea el rigor. Escribir la política en Rego, Cedar o XACML la hace versionable, probable, revisable y analizable, cosa que el código disperso nunca es de forma confiable.
4. PBAC es el paraguas. Roles, atributos, etiquetas y relaciones pueden expresarse todos como política; PBAC se define no por qué prueban las reglas sino por que la política sea explícita, externa y gobernada — se entiende mejor como ABAC operacionalizado.
5. La disciplina es el precio. Un lenguaje de política, una dependencia de decisión en runtime, la calidad de los datos de atributos y la gobernanza de la política son costos reales; sin pruebas, propiedad y revisión, una política central solo reubica el desorden.

Tres preguntas para ponerte a prueba

1. Explica la diferencia entre un Policy Enforcement Point y un Policy Decision Point, y describe qué se vuelve posible específicamente una vez que los separas que no es posible cuando la autorización son sentencias if en línea en cada servicio.
2. Un colega dice “PBAC y ABAC son lo mismo”. Da la distinción más útil entre ellos, y explica por qué casi todo sistema PBAC es basado en atributos por debajo — usando la idea de PBAC como “ABAC operacionalizado”.
3. Tu equipo externaliza la autorización en una sola 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 la habrían mantenido mantenible.

Ejercicios prácticos

1. Escribe y prueba una política. Usando el playground de Open Policy Agent o la CLI opa, escribe una pequeña política Rego que permita una acción solo cuando un atributo del sujeto coincida con un atributo del recurso. Luego escribe dos entradas de prueba — una que debería permitir y una que debería denegar — y ejecútalas. Acabas de hacer el bucle central de PBAC: política más pruebas.
2. Encuentra el PEP y el PDP en un sistema que uses. Para cualquier plataforma con autorización externalizada (Kubernetes con OPA/Gatekeeper, una malla de servicios, un servicio de autorización en la nube), identifica qué hace de PEP (pregunta y hace cumplir) y qué hace de PDP (decide). Anota dónde se almacena la política y cómo se actualiza.
3. Refactoriza una comprobación en línea en papel. Toma una sentencia if de autorización real de código que conozcas y reescríbela como una regla de política externalizada, luego lista qué ganaste (versionado, pruebas, una fuente de verdad) y qué nueva dependencia introdujiste (una llamada de decisión en la ruta de la solicitud). Decide si el intercambio vale la pena para ese caso.