Autorización fuera del modelo

Un prompt de sistema le dice al modelo qué debería hacer, pero el modelo lo trata como texto, igual que el resto de su contexto: lo que escribe el usuario, lo que trae un documento, lo que devuelve una herramienta. No hay en él una frontera que el modelo respete siempre, y por eso una regla escrita ahí es una preferencia, no un límite. Puede seguirla mil veces y saltársela la vez mil uno con la frase adecuada en el contexto.

Un control de acceso tiene otras propiedades: se evalúa fuera del modelo, con datos que el modelo no puede cambiar, da siempre la misma respuesta ante la misma entrada y deja registro de lo que decidió. Por eso la idea de este módulo es sencilla: el modelo propone la acción; un componente aparte, con reglas escritas como código, decide si se ejecuta.

Que exista un punto de decisión no significa que todo pase por él. Lo que importa es el recorrido de cada llamada: si alguna herramienta llega a su servicio por otro camino, para esa herramienta el control sigue siendo el prompt, por mucho motor de políticas que haya en el diagrama. Y suele pasar justo con las herramientas que se añadieron deprisa o que alguien consideró inofensivas.

Lee el control de cada herramienta de Caburé y busca la de escritura que no pasa por la pasarela.

Los modelos de control de acceso por atributos separan cuatro papeles, con nombres que vienen del estándar XACML de OASIS. El punto de aplicación (PEP) intercepta la acción y solo la deja seguir si le dicen que sí. El punto de decisión (PDP) evalúa las políticas y responde permitir o negar, sin ejecutar nada. El punto de información (PIP) entrega los atributos que la política necesita. El punto de administración (PAP) es donde las políticas se escriben y se gobiernan.

En un agente, el PEP tiene que estar entre la salida del modelo y el servicio real: si está antes del modelo o al lado, el modelo puede rodearlo. OPA y Cedar hacen de PDP; ninguno de los dos hace cumplir nada por sí mismo.

Un PDP es un servicio más y puede caerse o tardar. Lo que haga entonces el PEP es una decisión de diseño que hay que tomar a propósito: si niega (falla cerrado), la caída corta el servicio, pero no abre nada; si permite (falla abierto), la caída deja la herramienta sin control justo cuando nadie mira. Para un agente, la regla general es fallar cerrado, sobre todo en lo que escribe o en lo que expone datos de terceros.

Busca en el control de cada herramienta la que quedó configurada al revés.