Políticas como código y su revisión

Una política escrita como código es un archivo de texto con reglas en una notación precisa: efecto (permitir o denegar), acción y condición. Vive en un repositorio, cada cambio llega como una diferencia entre versiones, alguien distinto del autor lo revisa y una suite de pruebas comprueba, antes de publicar, que peticiones conocidas reciben la decisión esperada. Frente a una consola donde alguien marca casillas, gana tres cosas: historia de quién cambió qué y por qué, revisión del cambio exacto y pruebas repetibles.

Lo que no gana sola es criterio. Una suite que solo prueba lo que debe permitirse pasa en verde aunque el cambio abra de más, porque nadie le preguntó por lo que debía seguir cerrado. Por eso las pruebas de una política valen por sus casos de denegar: son los que detectan que una regla perdió una condición.

La descripción de un cambio la escribe el autor y dice lo que el autor cree que hizo. La diferencia dice lo que hizo. Cuando una descripción habla de «simplificar» o «limpiar» una regla de permitir, la pregunta del revisor es concreta: ¿qué condición se quitó y qué peticiones quedan permitidas sin ella?

Abre el laboratorio y lee cambio-pr-2318.txt contra documentos-obra-v22.pol. Lee cada regla que el cambio toca como si fuera nueva y pregúntate a quién permite.

Cada regla de la política debería aparecer en al menos una prueba que la haga decidir. Una regla de denegar sin prueba es la más frágil: si un cambio futuro la rompe, ninguna prueba cambia de color y la suite sigue en verde. La columna «regla» de la suite dice qué regla decidió cada caso; lo que no aparece en esa columna no está cubierto.

Lee pruebas-propuesta-v23.txt y cruza la columna de reglas con las reglas que existen en la política.

Cuando una regla permite y otra deniega la misma petición, decide el algoritmo de combinación. En el estándar XACML de OASIS hay varios, y los dos más usados son opuestos: con denegar-prevalece basta una regla de denegar para cerrar, y con permitir-prevalece basta una de permitir para abrir. El primero es el que encaja con denegar por defecto: las reglas de denegar funcionan como límites que ninguna excepción atraviesa. Con el segundo, cada regla de permitir que alguien añada puede anular un límite que estaba pensado para no tener excepciones.

El equipo de plataforma pregunta si la política podría pasar a permitir-prevalece «para que las excepciones sean más fáciles». Mira la suite y busca los casos donde hoy ganan las dos clases de regla a la vez.

El cambio figura como aprobado. El comité de arquitectura tiene reglas escritas para aprobar cambios a políticas, y una aprobación que no las cumple no es una aprobación: es una firma.