¿Qué es la política como código (PaC)?

En lugar de depender de humanos para verificar el cumplimiento o recordar las reglas de seguridad, esas reglas existen como lógica ejecutable cada vez que un desarrollador o sistema propone un cambio o solicitud. Si alguien envía un cambio, un motor de políticas evalúa automáticamente el cambio según las reglas codificadas y lo permite, lo deniega o lo señala.

Este proceso aleja las prácticas de gestión de políticas de los documentos estáticos y los lleva hacia una superficie de control viva y aplicada continuamente e integrada en el pipeline de entrega.

Las reglas basadas en código ayudan a garantizar que se apliquen las mismas políticas en todas partes, de manera repetible y escalable. Los motores de políticas pueden ejecutar comprobaciones automatizadas en segundos durante las compilaciones o despliegues, reduciendo los ciclos de feedback y ayudando a los equipos de DevOps a evitar sorpresas de seguridad o cumplimiento en etapas tardías.

PaC permite a las empresas mejorar su postura general de ciberseguridad y mantener el cumplimiento de los estándares regulatorios y de la industria. Además, el tratamiento de políticas como código se alinea con una transición más amplia de “todo como código”, que convierte cosas como las solicitudes de infraestructura en archivos de código revisables en torno a los cuales los equipos de desarrollo pueden colaborar.

En términos de DevOps, una política es una norma clara y aplicable sobre cómo se deben configurar o ejecutar la infraestructura y las aplicaciones de TI o cómo se debe acceder a estas. Más precisamente, las políticas dictan qué acciones están permitidas o prohibidas o cuáles se requieren para que los sistemas sigan funcionando en su estado ideal. 

Por ejemplo, “todos los buckets de almacenamiento de información deben estar cifrados” o “ningún servicio público puede exponer el puerto 22” son políticas, ya que especifican restricciones concretas sobre el comportamiento del sistema.

Con PaC, las políticas se escriben en un lenguaje de programación estructurado, por lo que los motores de políticas y las herramientas de automatización pueden analizarlas y evaluarlas de forma determinista. De este modo, las políticas se convierten en barreras ejecutables que los sistemas e ingenieros deben cumplir, en lugar de directrices que se puedan interpretar de forma diferente.

Las herramientas de política como código permiten a los desarrolladores escribir código ejecutable en entornos de tiempo de ejecución y pipelines de integración continua/entrega continua (CI/CD), de modo que cada cambio se compruebe automáticamente para verificar su cumplimiento.

Técnicamente, la mayoría de las configuraciones de PaC siguen los mismos pasos básicos:

• Los desarrolladores escriben políticas en forma de archivos de código. Pueden usar una variedad de lenguajes imperativos y declarativos de alto nivel, incluyendo Python, YAML, JavaScript Object Notation (JSON) o Rego, que generalmente se usa junto con Open Policy Agent (OPA), un motor de políticas de código abierto. Cada archivo de política declara las entradas que le importan (por ejemplo, “resource.kind”, “metadata.labels”) y codifica las condiciones (también llamadas “predicados”) y los resultados (permitir/negar, gravedad, mensajes).

• El código se envía a un sistema de control de versiones, como Git o GitHub, y pasa por los mismos flujos de trabajo que el código de aplicación, incluyendo solicitudes de extracción, revisión de código y pruebas sintácticas rigurosas.

• Un motor de políticas lee el archivo de código lo analiza y lo convierte en estructuras de datos e instrucciones comprensibles internamente. Estas estructuras e instrucciones se convierten luego en un formato de instrucción compacto de bajo nivel (bytecode) para una evaluación rápida.

• Quien llama, el código que solicita una decisión al motor de políticas, normaliza las entradas de datos. Quien llama procesa diferentes formatos de entrada, incluidos archivos HashiCorp Configuration Language (HCL) y plantillas JSON de herramientas de IaC, manifiestos YAML de Kubernetes y plataformas en la nube, solicitudes HTTP de llamadas a la API y datos de aplicaciones y datos de telemetría de entornos de tiempo de ejecución y producción. Limpia y reconfigura la entrada sin procesar en una estructura estándar, para que las políticas puedan leer las entradas de manera congruente.

• Quien llama devuelve los datos normalizados al motor de políticas, que comienza a ejecutar código de política contra las entradas de datos.  

• El motor de políticas recorre las reglas y verifica los predicados de cada regla con la entrada para comprender qué predicados se aplican. Se puede pensar que el motor de políticas se pregunta: “¿Qué dice esta regla sobre esta entrada?”.

• El motor de políticas toma los resultados de todas las reglas y los combina en una sola decisión de políticas, un proceso llamado agregación de decisiones, y crea una lista de mensajes. Los mensajes proporcionan más detalles (qué regla se violó y qué objeto la violó) sobre el código fallido y, a veces, ofrecen sugerencias sobre cómo hacer arreglos.

• El motor de políticas devuelve la decisión, incluyendo mensajes relevantes, etiquetas e información de gravedad. Si la decisión es “denegar”, el motor de políticas bloquea todas las solicitudes de extracción y las fusiones de código y detiene el despliegue hasta que los desarrolladores corrigen la violación de la política. Si la decisión es “permitir”, el motor crea un artefacto de compilación (un archivo de código compilado, empaquetado y probado) y despliega el código. Si hay advertencias, el código puede pasar, pero el motor incluye las advertencias en archivos de registro o comentarios. 

Las verificaciones de políticas pueden ocurrir en cualquier punto del ciclo de vida del desarrollo de software (SDLC), desde la integración de código hasta la producción y el monitoreo en vivo.

Debido a que las políticas son código, también pueden tratarse como cualquier otro artefacto de software.

Los equipos de desarrollo pueden escribir pruebas automatizadas que introduzcan entradas de muestra en las políticas y verifiquen las decisiones que devuelven para acelerar los ciclos de feedback cuando cambian las políticas.

Cuando las políticas están codificadas, los desarrolladores pueden extraer la lógica común en módulos o funciones reutilizables. Varias políticas de nivel superior pueden invocar políticas compartidas en lugar de duplicar condiciones en todas partes.

Los desarrolladores también pueden cambiar el nombre, reestructurar o dividir políticas grandes en otras más pequeñas sin cambiar su comportamiento, al igual que refactorizar una función de aplicación grande en otras más pequeñas.

Estas capacidades permiten a los equipos aplicar las prácticas de ingeniería de software existentes a la lógica de gobernanza, lo que les ayuda a mantener los requisitos de seguridad y cumplimiento a medida que las arquitecturas de TI escalan y evolucionan.

Supongamos que la empresa X quiere implementar una política de “solo HTTPS” en la que cada servicio web debe usar HTTPS, no HTTP simple. Para codificar la política, un ingeniero de plataformas escribe una regla simple que dice:

• Si el protocolo de un servicio es HTTP, el cambio debe rechazarse.
• Si el protocolo de un servicio es HTTPS, se permite el cambio.

El ingeniero coloca este archivo de políticas en una carpeta “políticas” dentro del mismo repositorio de código que la aplicación y abre una solicitud de extracción para agregar la política. Esa solicitud de extracción desencadena una verificación automática de sintaxis del archivo de políticas y una revisión de código por parte de otro ingeniero. Solo después de que la política supera las pruebas necesarias se fusiona con la rama principal.

En el pipeline de integración continua (CI), todos los archivos de políticas se cargan en el motor de políticas desde la carpeta “políticas”. El motor de políticas lee la política, la convierte en una representación interna y la compila en una forma compacta y de bajo nivel. Esta forma compacta permite que el motor responda rápidamente “¿permitir o denegar?” para cada servicio que el pipeline verifica.

Independientemente del formato del archivo, un trabajo de CI toma el archivo de configuración existente, extrae los campos importantes (nombre, protocolo, puerto) y crea una descripción JSON simple de cada servicio.

La persona que llama solicita una decisión del motor de políticas enviando la descripción del servicio estandarizada como entrada e indicando que se debe aplicar el paquete de políticas para “solo HTTPS”.

Luego, el motor de políticas evalúa la entrada con respecto a las reglas. Revisa el campo de protocolo del servicio. Si el protocolo es HTTP, significa que la entrada coincide con la condición de “denegar” en la política. El motor indica que se debe denegar el cambio y crea un mensaje que le indica al desarrollador que el servicio debe usar HTTPS en lugar de HTTP. Si el servicio utiliza HTTPS, no se cumple ninguna de las condiciones de denegación y el motor indica que el cambio está permitido.

Luego, el motor de políticas resume las evaluaciones de reglas en un único objeto de decisión para el servicio. Los objetos de decisión suelen especificar si la decisión general es “permitir” o “denegar” y la gravedad del problema (alta, media, baja). También incluyen una lista de mensajes que explican por qué se denegó la entrada y cualquier advertencia que el motor encontró en el proceso de evaluación. Si todo cumple, el objeto de decisión indica que el cambio está permitido y viene solo con notas informativas (o sin ningún mensaje).

Finalmente, las herramientas de CI hacen cumplir la decisión. Si la decisión es “denegar”, el cambio no se fusionará en la rama de código principal. El ingeniero ve un mensaje de error que indica que el servicio debe usar HTTPS y someterse a modificaciones específicas. Si la decisión es “permitir”, el artefacto se empaqueta y despliega, y el pipeline de CI continúa normalmente.

La política como código surgió de un movimiento más amplio de “todo como código” en DevOps moderno y la ingeniería en la nube.

Originalmente, la infraestructura como código (IaC) fue el gran cambio. En lugar de que los administradores del sistema hagan clic en las interfaces de usuario o sigan los runbooks, los equipos describieron servidores, redes y otros recursos en archivos de código declarativo. Estos archivos se almacenan en sistemas de control de versiones y se aplican a través de pipelines automatizados.

A medida que las empresas vieron los beneficios, el enfoque se extendió a otros componentes de las arquitecturas de TI. La configuración de aplicaciones se movió hacia enfoques basados en código. Los pipelines de CI/CD se convirtieron en scripts que residen en repositorios de código. Las reglas de monitoreo y alerta también comenzaron a residir en código. En conjunto estas prácticas se hicieron conocidas como “todo como código”.

La idea central de “todo como código” es que, si alguna parte del sistema puede describirse, debe describirse como código y gestionarse de la misma manera que las aplicaciones de software.

PaC es esencialmente la aplicación de esa filosofía a las reglas, la gobernanza y el cumplimiento. Tradicionalmente, las políticas se plasmaban en archivos PDF y wikis, o bien eran decididas por un comité, y su aplicación corría a cargo de personas. Este proceso funcionó cuando los ciclos de lanzamiento eran lentos y la infraestructura era relativamente estática.

A medida que las arquitecturas nativas de la nube y los microservicios tomaron el control, y los equipos empezaron a desplegar código varias veces al día, los procesos manuales no pudieron seguir el ritmo. PaC abordó este desafío expresando políticas en formatos legibles por máquina, de modo que puedan versionarse en Git, revisarse como archivos de código, probarse en CI y aplicarse automáticamente en pipelines o en tiempo de ejecución.

La política como código es una práctica para gestionar políticas de TI como el código de software. La infraestructura como código (IaC) es similar, pero con un enfoque diferente. Permite a los equipos de ingeniería definir y gestionar la infraestructura de TI usando código de aplicación.

En lugar de crear y configurar manualmente activos de red como máquinas virtuales (VM) y balanceadores de carga, IaC permite a los desarrolladores escribir código para describir el estado deseado de estos recursos. Luego, una herramienta de IaC toma ese código y crea o modifica los recursos especificados.

IaC facilita mucho el escalado y la automatización de la infraestructura. Si un equipo necesita más servidores, puede cambiar un número en el código (de seis instancias a nueve, por ejemplo). Las herramientas de automatización se encargan de los detalles del aprovisionamiento de esos recursos adicionales.

A un alto nivel, IaC dicta qué infraestructura debe existir y cómo debe configurarse, mientras que PaC se centra en las reglas y restricciones que debe obedecer la infraestructura. El código IaC crea y configura recursos, y el código PaC ayuda a garantizar que esos recursos (y las formas en que se utilizan) sigan los requisitos de seguridad definidos, los estándares de cumplimiento y las medidas de seguridad operativas.

En muchas arquitecturas de TI modernas y configuraciones de CI/CD, IaC y PaC proporcionan beneficios complementarios. IaC automatiza el aprovisionamiento y PaC agrega gobernanza automatizada en la parte superior.

Cuando un desarrollador cambia un archivo IaC, un motor PaC puede inspeccionar el nuevo plan o configuración. Si todo cumple con las políticas establecidas, se permite que el cambio continúe y la infraestructura se actualiza. Si algo infringe una regla, el pipeline falla y no se despliega nada hasta que se soluciona el problema.

DevSecOps trata de la incorporación de la seguridad y el cumplimiento en el ciclo de vida de DevOps, en lugar de agregarlos al final. Es un enfoque de desarrollo en el que los procesos de seguridad se priorizan y ejecutan durante cada etapa del ciclo de vida del desarrollo de software.

PaC admite prácticas de DevSecOps mediante:

PaC ayuda a los equipos a cambiar la seguridad al trasladar los controles de seguridad a las primeras etapas del proceso de desarrollo, en lugar de esperar a ejecutar los controles después del despliegue, cuando los problemas pueden afectar a los usuarios. Si un desarrollador introduce una configuración arriesgada o un patrón inseguro, las políticas automatizadas pueden detectar el problema y hacer fallar la compilación.

Las herramientas PaC automatizan la aplicación mediante la incorporación de reglas de seguridad directamente en los pipelines de CI/CD y los sistemas de tiempo de ejecución, por lo que las comprobaciones se realizan automáticamente cada vez que cambia el código o la infraestructura. En lugar de depender de humanos para recordar cada estándar de seguridad y revisar manualmente cada cambio, el sistema evalúa constantemente los cambios para garantizar que no se omita accidentalmente ningún paso.

PaC ayuda a los desarrolladores a mantener la velocidad de despliegue sin sacrificar la coherencia ni la seguridad. Ejecuta las mismas definiciones de políticas en todos los entornos y en todas las etapas: desarrollo, pruebas, puesta en escena y producción. Esta característica permite a los equipos lanzar con frecuencia porque pueden confiar en que se aplica el mismo conjunto de reglas en todas partes. También les ayuda a evitar situaciones en las que diferentes entornos se separan o utilizan interpretaciones ligeramente diferentes de las reglas.

PaC trata las políticas de seguridad de aplicaciones como cualquier otro artefacto de código que reside en un sistema de control de versiones. Los equipos de desarrollo, operaciones y seguridad pueden revisar, debatir y actualizar políticas mediante flujos de trabajo familiares (revisiones de código, estrategias de ramificación), lo que hace que las conversaciones sobre políticas sean más transparentes e integradas en el trabajo diario de desarrollo.

La política como código tiene una amplia gama de aplicaciones para arquitecturas de TI empresariales.

Los desarrolladores y los profesionales de la seguridad están explorando las políticas como código como una forma de crear modelos de barreras de seguridad en capas que abarquen todo el ciclo de vida de un flujo de trabajo de IA o flujo de trabajo con agentes. Aunque la práctica aún está en desarrollo, las investigaciones iniciales revelaron muchas posibles aplicaciones de PaC en flujos de trabajo de IA.

PaC puede ayudar a establecer una separación clara entre el razonamiento de la IA y el sistema que decide qué acciones realmente puede ejecutar. La herramienta de IA puede proponer acciones o planes, pero un motor de políticas evalúa esas propuestas con respecto a reglas codificadas antes de que se toque cualquier sistema subyacente.

En la etapa de entrada, PaC puede ayudar a filtrar o transformar las instrucciones del usuario, ocultar datos confidenciales, aplicar el aislamiento de inquilinos y bloquear patrones de ataque conocidos. Durante la planificación, PaC puede requerir que los agentes de IA produzcan planes estructurados y validen cada paso con las herramientas permitidas, las acciones y las condiciones de riesgo antes de que se permita la ejecución.

En el momento de la ejecución, la capa de aplicación de políticas puede verificar cada invocación de herramienta o llamada a API. La capa decide si permitir, denegar o modificar una acción o escalarla a un ser humano. Después de la ejecución, las políticas pueden impulsar el registro, las pistas de auditoría, las reglas de retención y los filtros posteriores en los resultados del modelo para garantizar que las respuestas cumplan con los requisitos necesarios.

• Coherencia. Con PaC, las políticas se aplican de la misma manera en todos los entornos porque el mismo código se ejecuta en todas partes. Esta coherencia reduce las configuraciones únicas y “aisladas” y evita que los equipos tengan que recordar procesos manuales ligeramente diferentes para cada entorno.

• Eficiencia. Cuando las políticas están codificadas, se pueden aplicar automáticamente en los pipelines de CI/CD o en el momento del despliegue, eliminando la necesidad de verificaciones y aprobaciones manuales.

• Automatización. PaC permite la validación automatizada y las pruebas de políticas, lo que ayuda a los equipos a minimizar el impacto de los errores humanos, detectar configuraciones erróneas y abordar las vulnerabilidades de seguridad antes de que afecten la producción.

• Visibilidad. Con políticas escritas en código y almacenadas de forma centralizada, los stakeholders pueden ver exactamente qué reglas existen en lugar de depender de documentos dispersos y lo que recuerden las personas.

• Escalabilidad. La evaluación de políticas está automatizada, por lo que las organizaciones pueden aplicar políticas a escala en muchos servicios, clústeres o cuentas sin aumentos proporcionales en el número de empleados.

• Colaboración. PaC agiliza la colaboración en torno al código de políticas. Estos flujos de trabajo compartidos eliminan los silos, alinean la seguridad y la gobernanza con las prácticas de DevOps y hacen que los debates sobre políticas sean más concretos y comprobables.