Pregunta y escenarios adecuados
Un equipo de plataforma desea que reglas como «las bases de datos no pueden ser públicas», «solo se pueden ejecutar imágenes firmadas» y «un rol solo puede leer su propio tenant» se vuelvan testeables, revisables y se apliquen automáticamente. El entrevistador te pide que expliques Policy as Code y traces el límite entre las decisiones de política y la ejecución de negocio.
Asume que las solicitudes provienen de una API, CI/CD o un cambio de infraestructura; la entrada de la política es un JSON estructurado; y las políticas requieren versiones, reversión y auditabilidad. La pregunta se centra en el límite y el razonamiento, no en un compromiso con OPA, Rego o un proveedor específico.
Qué evalúa el entrevistador
- Si separas las responsabilidades de definición de políticas, cómputo de decisiones y aplicación (enforcement).
- Si sabes que un motor de políticas puede devolver resultados estructurados en lugar de solo un booleano.
- Si manejas la coherencia de versiones de políticas y entradas, tiempos de espera, almacenamiento en caché y denegación por defecto.
- Si tratas el código de políticas como software que requiere revisión, pruebas, despliegue y auditoría, y no como configuración copiada.
Una respuesta débil dice «usa OPA para autorización». Una respuesta sólida coloca un Policy Enforcement Point en el límite de la solicitud, mantiene el Policy Decision Point enfocado en el cómputo y hace que cada decisión sea explicable, reproducible y rastreable.
Preguntas para aclarar antes de responder
- ¿La decisión es para acceso en tiempo de ejecución o cumplimiento previo al despliegue? Las decisiones en tiempo de ejecución enfatizan la latencia y la disponibilidad; las comprobaciones de despliegue enfatizan la retroalimentación y el bloqueo.
- ¿Quién suministra la identidad, el tenant, las etiquetas de recursos y el estado del entorno, y se puede confiar en esos campos? La falta de entradas no debe convertirse silenciosamente en un permiso.
- En caso de falla, ¿el sistema debe denegar por defecto, degradar a permitir o solicitar aprobación humana? La respuesta depende del impacto de la acción y de los objetivos de disponibilidad.
- ¿Puede la publicación de políticas ser independiente del lanzamiento de la aplicación? Los lanzamientos independientes requieren vinculación de versiones, comprobaciones de compatibilidad y reversión rápida.
- ¿Qué debe contener un registro de auditoría? Si la entrada incluye datos personales o secretos, los registros necesitan redacción antes del almacenamiento o carga.
Estructura de respuesta de 30 segundos
«Policy as Code coloca reglas ejecutables bajo control de versiones, revisión y pruebas. Una solicitud llega a un PEP, que recopila y normaliza el sujeto, la acción, el recurso y el contexto, y luego llama a un PDP con la entrada normalizada y la versión de la política. El PDP devuelve una decisión estructurada, como permitir, denegar, motivos y obligaciones; el PEP realmente bloquea o continúa la acción. Yo utilizaría denegación por defecto, caché acotada y versionada, y registros de decisiones redactados. Antes del lanzamiento, ejecutaría comprobaciones de reproducción y canario, e implementaría excepciones de emergencia limitadas en el tiempo, aprobadas y auditables».
Respuesta detallada paso a paso
1. Definir el objeto y el límite de la política
Traduce una regla en lenguaje natural a sujeto, acción, recurso, condiciones y resultado. «Un servicio no debe exponer un puerto público sin cifrar» puede significar: el sujeto es una canalización de despliegue, la acción es crear servicio, el recurso es la configuración del servicio, las condiciones son los atributos de puerto y red, y el resultado es denegar con un mensaje de corrección.
El PDP lee la entrada normalizada y la política y devuelve allow, deny, warn o datos estructurados más ricos. El PEP se ubica en una API, controlador de admisión, tarea de CI o límite de llamada a servicio y convierte el resultado en bloquear, continuar, mutar o escalamiento humano.
caller -> PEP: subject, action, resource, context
PEP -> PDP: normalized input + policy version
PDP -> PEP: decision, reasons, obligations, decision_id
PEP -> target: enforce decision or stop request
PEP -> audit: redacted decision recordLa documentación de OPA separa explícitamente la toma de decisiones de la aplicación, y la guía de AWS describe PDP con PEP en las API. Ese límite permite que un conjunto de reglas sirva a múltiples puntos de entrada sin pretender que el motor de políticas realice la transacción de negocio.
2. Normalizar la entrada y manejar campos faltantes
Los formatos sin procesar difieren según el punto de entrada: CI puede proporcionar un plan YAML, una API una solicitud HTTP y una llamada a un servicio un objeto. El PEP o una capa de autorización debe convertirlos a una estructura interna estable y adjuntar metadatos de origen, marca de tiempo y versión de datos.
Cuando faltan el tenant, el propietario o el estado del entorno, la denegación por defecto es más segura que adivinar. La política debe distinguir la denegación explícita de «no se puede decidir», permitiendo que el PEP solicite aprobación o reintente; un valor no definido no debe tratarse como un permiso.
{
"subject": {"id": "u-17", "tenant": "t-3", "roles": ["reader"]},
"action": "read",
"resource": {"type": "invoice", "id": "inv-9", "tenant": "t-3"},
"context": {"environment": "prod", "authn_level": "mfa"},
"policy_version": "2026-06-18.4"
}3. Tratar la política como software comprobable
Los archivos de políticas pertenecen a Git y deben pasar comprobaciones de sintaxis, pruebas unitarias, casos adversos y revisión de código. Las pruebas deben cubrir los caminos de permitir y de tenants vecinos, campos faltantes, identidad expirada, reglas en conflicto y rutas por defecto.
package invoices
default allow := false
allow if {
input.action == "read"
input.subject.tenant == input.resource.tenant
"reader" in input.subject.roles
}Fija la versión de la política y la captura instantánea de datos en las pruebas. Si una regla depende de un directorio en vivo o una llamada de red, define límites de tiempo de espera y obsolescencia antes de decidir si el almacenamiento en caché local es aceptable.
4. Diseñar publicación, almacenamiento en caché y reversión
El lanzamiento de políticas necesita una versión, comprobaciones de compatibilidad y reversión, al igual que el lanzamiento de un servicio. Un PDP puede ejecutarse como un sidecar local, una biblioteca o un servicio centralizado: la ejecución local reduce la latencia de red, mientras que la centralización simplifica la gestión. La elección depende de la velocidad de actualización, el radio de impacto de fallas y los requisitos de coherencia.
Almacena en caché solo decisiones con un tiempo de vida explícito, vinculando el sujeto, el recurso, la versión de la política y la versión de los datos de autorización. La revocación de permisos, la migración de tenants y las acciones de alto riesgo no deben usar una caché prolongada que no se pueda invalidar rápidamente. Cuando el PDP agota el tiempo de espera, el PEP elige denegar, solicitar aprobación o una ruta estrecha preaprobada según el riesgo de la acción.
5. Registrar decisiones explicables y redactadas
Cada decisión necesita al menos la versión de la política, el resumen de entrada, el resultado, los motivos, el ID de decisión y la identidad del PEP para la reproducción de incidentes. Las entradas pueden contener nombres de usuario, tokens o secretos, por lo que la capa de registro debe eliminar o enmascarar los campos confidenciales antes de cargarlos o almacenarlos.
Un permiso también puede conllevar obligaciones, como escribir un evento de auditoría, limitar campos o requerir una confirmación escalonada. El PDP devuelve la obligación; el PEP la ejecuta y deniega o escala si no puede hacerlo.
Respuesta de muestra de alta calidad
Definiría Policy as Code como la expresión de restricciones de seguridad, cumplimiento y operaciones como reglas versionadas, testeables y legibles por máquina. Una solicitud llega a un PEP, que autentica el sujeto y normaliza sujeto, acción, recurso y contexto antes de enviarlos con una versión de política a un PDP. El PDP calcula una decisión y devuelve permitir, denegar, motivos, obligaciones y un ID de decisión. El PEP, no el PDP, bloquea la solicitud, continúa la acción de negocio o inicia la aprobación humana.
Versionaría los datos de entrada y las políticas, revisaría las políticas en Git y las probaría con capturas instantáneas reproducibles. El comportamiento en tiempo de ejecución adopta la denegación por defecto y las memorias caché están vinculadas a las versiones de políticas y datos de autorización; las revocaciones invalidan rápidamente las decisiones de alto riesgo. Una interrupción del PDP no debería convertirse automáticamente en permitir, por lo que elegiría el modo de falla según el riesgo de la acción. Finalmente, escribiría registros de decisiones redactados para auditoría y reversión. De este modo, las mismas reglas pueden servir a puntos de entrada de API, CI e infraestructura, mientras que cada punto de entrada conserva la responsabilidad de aplicación.
Errores comunes
- Error → Permitir que el PDP actualice una base de datos o despliegue infraestructura → Por qué falla → La decisión y los efectos secundarios se vuelven inseparables y difíciles de reintentar o auditar → Solución → Devolver una decisión y obligaciones desde el PDP; dejar que el PEP o el servicio de negocio ejecute los efectos.
- Error → Permitir por defecto cuando el PDP agota el tiempo de espera → Por qué falla → Una falla de red se convierte en una elusión de permisos → Solución → Elegir denegar, aprobación o una ruta corta preaprobada según el riesgo de la acción.
- Error → Registrar únicamente permitir o denegar → Por qué falla → Nadie puede explicar qué regla y qué entrada produjeron el resultado → Solución → Registrar la versión de la política, los motivos, el ID de decisión y un resumen de entrada redactado.
- Error → Tratar la caché de políticas como una verdad permanente → Por qué falla → Las revocaciones y los cambios de tenant no pueden surtir efecto oportunamente → Solución → Vincular versiones y caducidad, e invalidar ante eventos críticos.
Preguntas de seguimiento y respuestas
Si el PDP centralizado no está disponible, ¿deben fallar todas las lecturas?
Clasifica la acción primero. Los cambios de permisos, las transferencias y las lecturas entre tenants deben denegarse por defecto; una lectura de bajo riesgo puede utilizar una decisión local de corta duración y vinculada a una versión, registrando y auditando el uso de la caché tras la recuperación. La disponibilidad no es una razón universal para permitir.
¿Qué sucede si la política y el directorio de identidades se actualizan al mismo tiempo?
Incluye las versiones de la política y de los datos de identidad en la decisión, y haz que el PEP verifique una versión o concesión antes de la aplicación. Los eventos de revocación invalidan las memorias caché; si no se puede confirmar la versión, deniega o reevalúa. Prueba actualizaciones concurrentes y mensajes demorados para que una decisión antigua no pueda volver a escribirse.
Si una regla permite y otra deniega, ¿cuál prevalece?
Define la precedencia de manera explícita; nunca dependas del orden de los archivos. Usa denegación por defecto con precedencia de denegación explícita, o agrega reglas en una decisión con motivos y riesgo. Los conflictos necesitan pruebas y una compuerta de lanzamiento para que diferentes puntos de entrada no puedan interpretarlos de manera distinta.
¿Cómo admites un permiso de emergencia sin destruir la auditabilidad?
Modélalo como una política temporal u obligación con aprobador, alcance, motivo, hora de inicio y vencimiento. El PEP registra cada uso, el vencimiento automático lo revoca y la reproducción distingue la excepción de las reglas normales. Nunca eludas las versiones de políticas editando una base de datos manualmente.