Saltar al contenido

Conceptos

Permitido frente a observado

El diff en el corazón del mapa de acceso — lo que se concede a un agente frente a lo que se le ve hacer — que saca a la luz accesos inesperados y concesiones sin uso

Cada arista del mapa de acceso lleva dos hechos independientes: si el acceso está permitido y si ha sido observado. El diff entre esas dos capas es el elemento diferenciador: es lo que convierte un grafo estático en un hallazgo.

Dos capas en una misma arista

El mapa no mantiene un “grafo de políticas” separado de un “grafo de telemetría”. Cada arista es una única relación (origen a recurso, de lectura o lectura-escritura tipada) que lleva ambos indicadores:

  • Permitido — una concesión o política permite este acceso. La fuente de señal es la propia política declarada.
  • Observado — se vio que el acceso ocurría realmente, derivado de la telemetría y la auditoría nativa (OpenTelemetry de agentes cooperativos, pgAudit de PostgreSQL, logs de auditoría de la nube, un respaldo eBPF a nivel de kernel).

Un matiz que importa por honestidad: no permitido significa «no se sabe que esté permitido», no «prohibido». El mapa registra lo que puede probar a partir de las concesiones declaradas; la ausencia de una concesión es una laguna que investigar, no un veredicto de aplicación.

El diff: donde está el valor

La deriva respecto al mínimo privilegio es, simplemente, el conjunto de aristas en las que los dos indicadores discrepan. Se divide en dos hallazgos operativamente distintos:

  • Acceso inesperadoobservado pero no permitido. Un agente tocó un recurso que ninguna concesión cubre. Esta es la mitad relevante para la seguridad, presentada como el hallazgo principal.
  • Concesiones sin usopermitido pero nunca observado. Una concesión que nadie llegó a ejercer. Esta es tu lista concreta de limpieza de mínimo privilegio, no un vago recordatorio de «revisa tu IAM».

Las aristas en las que ambos indicadores coinciden —permitido y usado, o ninguno de los dos— son el estado estable, aburrido y esperado. El diff es la pequeña porción accionable que queda en medio.

Honestidad dentro del diff

Un diff ingenuo produce hallazgos falsos, así que la reconciliación es deliberadamente conservadora.

Reconciliación pendiente

La auditoría atribuye un acceso a una credencial o un rol; una concesión se escribe contra una identidad; una señal cooperativa nombra a un agente o una sesión. Cuando el mapa de acceso aún no puede vincular con firmeza al agente que actúa con la identidad para la que se escribió su concesión, no puede probar que el acceso esté permitido, pero tampoco debe presentarlo como una infracción. Tales aristas se marcan como reconciliation_pending: incertidumbre honesta, no un hallazgo fabricado. Se resuelven de forma limpia en cuanto la identidad por agente vincula la credencial con el agente.

Concesiones sobre recursos que nadie vigila

Algunas concesiones residen en tipos de recurso que no tienen colector del lado observado: no hay nada que vigile quién usó realmente un directorio LDAP o una asignación de aplicación de un IdP. Para esos, «nunca observado» es el estado estable esperado, no una prueba de sobreaprovisionamiento. Se mantienen fuera de la lista principal de concesiones sin uso en lugar de inflarla con ruido.

La cobertura y la atribución siguen viajando con la arista

El diff hereda la fidelidad por niveles de las aristas subyacentes. En un almacén opaque (Redis, SQLite, D1) no hay señal pasiva de lectura/escritura en absoluto, así que la ausencia de una arista observada no es prueba de que el acceso no ocurriera: es silencio. Del mismo modo, una cuenta de servicio compartida reduce la atribución a approximate. El diff nunca presenta un hallazgo de baja confianza como si fuera firme.

Cuando el diff se calcula sobre una ventana parcial (un patrimonio muy grande que supera el límite de paginación), el resultado se marca explícitamente como parcial en lugar de presentarse como autoritativo.

Detective, no en el camino

Producir este diff es una actividad fuera de banda, detective. El control plane se ejecuta en tu propia infraestructura (y puede estar aislado en red); observa a través de logs, OpenTelemetry y auditoría nativa, y no se sitúa en el camino de las peticiones entre un agente y sus recursos. Un colector que falla nunca rompe el tráfico de producción.

De ahí se siguen dos consecuencias. Primera, el diff es un informe, no una barrera: saca a la luz lo que ya ocurrió. Allí donde el producto sí actúa sobre un hallazgo, lo hace en modo deny-closed y bajo demanda, nunca como un ejecutor generalizado. Segunda, leer el diff es en sí mismo una acción privilegiada, acotada al tenant y plenamente auditada: el acto de inspeccionar quién-puede-alcanzar-qué es relevante para el reconocimiento, y la lectura se registra en el ledger de auditoría de solo adición antes de devolver arista alguna.

Esta es también la razón por la que el diff es seguro de ejecutar sobre patrimonios sensibles: el mapa almacena la relación —origen, recurso, lectura/escritura, fuente, confianza, marcas de tiempo—, nunca las cargas útiles, los cuerpos SQL, los secretos o los datos personales que fluyeron por la arista. Lo que no se almacena no puede filtrarse.

Relacionado