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

En lugar de depender de personas para comprobar el cumplimiento o recordar las normas de seguridad, dichas normas existen como lógica ejecutable que se ejecuta cada vez que un desarrollador o un sistema propone un cambio o una solicitud. Si alguien envía un cambio, un motor de políticas evalúa automáticamente dicho cambio en función de las normas de codificación y, en consecuencia, lo permite, lo rechaza o lo marca.

Este proceso aleja las prácticas de gestión de políticas de los documentos estáticos y las orienta hacia una superficie de control dinámica, aplicada de forma continua e integrada en la canalización de entrega de software.

Las reglas basadas en código ayudan a garantizar que se apliquen las mismas políticas en todas partes, de forma repetible y escalable. Los motores de políticas pueden realizar comprobaciones automatizadas en cuestión de segundos durante las compilaciones o implementaciones, lo que acorta los ciclos de feedback y ayuda a los equipos de DevOps a evitar sorpresas relacionadas con la seguridad o el cumplimiento en fases avanzadas del proceso.

La PaC permite a las empresas mejorar su postura general de ciberseguridad y mantener el cumplimiento de las normas sectoriales reglamentarias. Además, tratar las políticas como código se alinea con una transición más amplia hacia el modelo “todo como código”, que convierte elementos 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 deben configurarse, consultarse o ejecutarse la infraestructura de TI y las aplicaciones. Más concretamente, las políticas dictan qué acciones están permitidas, son obligatorias o están prohibidas para que los sistemas sigan funcionando en su estado óptimo. 

Por ejemplo, “todos los depósitos de almacenamiento 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 la PaC, las políticas se escriben en un lenguaje de programación estructurado, de modo que los motores de políticas y las herramientas de automatización puedan analizarlas y evaluarlas de forma determinista. De este modo, las políticas se convierten en controles de seguridad ejecutables que los sistemas y los ingenieros deben cumplir, en lugar de directrices que las personas podrían 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 en las canalizaciones de integración continua/entrega continua (CI/CD), de modo que se comprueba automáticamente el cumplimiento de cada cambio.

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 utilizar una amplia gama de lenguajes imperativos y declarativos de alto nivel, incluyendo Python, YAML, JavaScript Object Notation (JSON) o Rego, que normalmente se emplea junto con el Open Policy Agent (OPA), un motor de políticas de código abierto . Cada archivo de política declara las entradas que le interesan (por ejemplo, “resource.kind” o “metadata.labels”) y codifica las condiciones (también llamadas “predicados”) y los resultados (permitir/denegar, gravedad, mensajes).

• El código se envía a un sistema de control de versiones, como Git o GitHub, y sigue los mismos flujos de trabajo que el código de las aplicaciones, incluyendo pull requests, la revisión del código y rigurosas pruebas sintácticas.

• 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 a un formato de instrucciones compacto y de bajo nivel (bytecode) para una evaluación rápida.

• El invocador (el fragmento de código que solicita una decisión al motor de políticas) normaliza las entradas de datos. El invocador procesa diferentes formatos de entrada, incluidos archivos en HashiCorp Configuration Language (HCL) y plantillas JSON procedentes de herramientas de IaC, manifiestos YAML de Kubernetes y plataformas en la nube, solicitudes HTTP procedentes de llamadas a la API y datos de aplicaciones, así como datos de telemetría procedentes de entornos de tiempo de ejecución y de producción. Limpia y reestructura la entrada sin procesar en una estructura estándar, de modo que las políticas pueden leer las entradas de forma coherente.

• El invocador devuelve los datos normalizados al motor de políticas, que empieza a ejecutar el código de las políticas sobre las entradas de datos.  

• El motor de políticas revisa las reglas y comprueba los predicados de cada una de ellas con respecto a la entrada para determinar qué predicados son aplicables. Se puede considerar 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 única decisión política (un proceso llamado agregación de decisiones) y crea una lista de mensajes. Los mensajes proporcionan más detalles (qué regla se ha infringido y qué objeto la ha infringido) sobre el código defectuoso y, a veces, ofrecen sugerencias sobre cómo corregirlo.

• El motor de políticas devuelve la decisión, incluidos los mensajes pertinentes, las etiquetas y la información sobre la gravedad. Si la decisión es “denegar”, el motor de políticas bloquea todas las pull requests y las fusiones de código, y detiene la implementación hasta que los desarrolladores corrijan la infracció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) e implementa el código. Si hay advertencias, se permite que el código pase, pero el motor incluye las advertencias en los archivos de registro o en los comentarios. 

Las comprobaciones de políticas pueden realizarse en cualquier momento del ciclo de vida del desarrollo de software (SDLC), desde la integración del código hasta la producción en vivo y la monitorización.

Dado 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 estas devuelven, con el fin de 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 y convertirla en módulos o funciones reutilizables. De este modo, varias políticas de nivel superior pueden recurrir a políticas compartidas en lugar de duplicar las condiciones en todas partes.

Los desarrolladores también pueden renombrar, reestructurar o dividir políticas grandes en otras más pequeñas sin alterar su comportamiento, del mismo modo que se refactoriza una función grande de una aplicación en funciones 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 gobierno, 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 desea implementar una política de “solo HTTPS”, según la cual todos los servicios web deben utilizar HTTPS, y no HTTP estándar. Para codificar la política, un ingeniero de plataforma escribe una regla sencilla que dice:

• Si el protocolo de un servicio es HTTP, el cambio debe rechazarse.
• Si el protocolo de un servicio es HTTPS, el cambio está permitido.

El ingeniero coloca este archivo de política en una carpeta denominada “políticas” dentro del mismo repositorio de código que la aplicación y abre una pull request para añadir la política. Dicha pull request activa una comprobación sintáctica automática del archivo de política y una revisión del código por parte de otro ingeniero. Solo después de que la política supere las pruebas necesarias se fusiona con la rama principal.

En la canalización 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 un formato compacto de bajo nivel. Este formato compacto permite al motor responder rápidamente a la pregunta “¿permitir o denegar?” para cada servicio que comprueba la canalización.

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

El invocador solicita una decisión al motor de políticas enviando la descripción estandarizada del servicio como entrada e indicando que debe aplicarse el paquete de políticas para “solo HTTPS”.

A continuación, el motor de políticas evalúa la entrada en función de las reglas. Comprueba el campo de protocolo del servicio. Si el protocolo es HTTP, eso significa que la entrada cumple la condición de “denegación” de la política. El motor indica que el cambio debe denegarse y genera un mensaje en el que se informa al desarrollador de que el servicio debe utilizar 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.

A continuación, el motor de políticas resume las evaluaciones de las 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 cuál es la gravedad del problema (alta, media, baja). También incluyen una lista de mensajes que explican por qué se ha denegado la entrada, así como cualquier advertencia que el motor haya detectado durante el proceso de evaluación. Si todo cumple con los requisitos, el objeto de decisión indica que el cambio está permitido y solo incluye notas informativas (o ningún mensaje en absoluto).

Por último, las herramientas de CI aplican la decisión. Si la decisión es “denegar”, el cambio no se integra en la rama principal del código. El ingeniero ve un mensaje de error que indica que el servicio debe utilizar HTTPS y someterse a modificaciones específicas. Si la decisión es “permitir”, el artefacto se empaqueta y se implementa, y la canalización de CI continúa con normalidad.

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

En un principio, la infraestructura como código (IaC) supuso un gran cambio. En lugar de que los administradores de sistemas tuvieran que navegar por interfaces de usuario o seguir manuales de procedimientos, los equipos describían los servidores, las 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 canalizaciones automatizadas.

A medida que las empresas fueron percibiendo los beneficios, este enfoque se extendió a otros componentes de las arquitecturas de TI. La configuración de las aplicaciones pasó a basarse en enfoques basados en código. Las canalizaciones de CI/CD se convirtieron en scripts alojados en repositorios de código. Las reglas de monitorización y alertas también comenzaron a estar definidas en código. En conjunto, estas prácticas pasaron a denominarse “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 forma que las aplicaciones de software.

PaC es, en esencia, la aplicación de esa filosofía a las normas, el gobierno y el cumplimiento. Tradicionalmente, las políticas se almacenaban en archivos PDF y wikis, o bien eran decididas por un comité, y su cumplimiento lo garantizaban personas. Este proceso funcionaba cuando los ciclos de lanzamiento eran lentos y la infraestructura era relativamente estática.

A medida que las arquitecturas nativas de la nube y de microservicios se impusieron, y los equipos comenzaron a implementar código varias veces al día, los procesos manuales ya no podían seguir el ritmo. La PaC abordó este reto expresando las políticas en formatos legibles por máquina, de modo que puedan versionarse en Git, revisarse como archivos de código, someterse a pruebas en la CI y aplicarse automáticamente en las canalizaciones 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 mediante el código de la aplicación.

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

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

A grandes rasgos, IaC determina qué infraestructura debe existir y cómo debe configurarse, mientras que PaC se centra en las normas y restricciones que dicha infraestructura debe cumplir. El código de IaC crea y configura recursos, y el código de PaC contribuye a garantizar que dichos recursos (y la forma en que se utilizan) cumplan los requisitos de seguridad, las normas de cumplimiento y los controles de seguridad definidos.

En muchas arquitecturas de TI modernas y configuraciones de CI/CD, IaC y PaC aportan beneficios complementarios. La IaC automatiza el aprovisionamiento, y la PaC añade a ello un gobierno automatizado.

Cuando un desarrollador modifica un archivo de IaC, un motor de PaC puede inspeccionar el nuevo plan o la nueva configuración. Si todo cumple con las políticas establecidas, se permite que el cambio se lleve a cabo y se actualiza la infraestructura. Si algo incumple una norma, la canalización falla y no se implementa nada hasta que se solucione el problema.

DevSecOps consiste en integrar la seguridad y el cumplimiento en el ciclo de vida de DevOps, en lugar de añadirlos a posteriori. Se trata de un enfoque de desarrollo en el que los procesos de seguridad se priorizan y se ejecutan durante cada etapa del ciclo de vida del desarrollo de software.

La PaC respalda las prácticas de DevSecOps de las siguientes maneras:

La PaC ayuda a los equipos a desplazar la seguridad hacia la izquierda, trasladando los controles de seguridad a las primeras fases del proceso de desarrollo, en lugar de esperar a ejecutarlos tras la implementación, cuando los problemas ya pueden afectar a los usuarios. Si un desarrollador introduce una configuración arriesgada o un patrón inseguro, las políticas automatizadas pueden ayudar a detectar el problema y hacer que la compilación falle.

Las herramientas de PaC automatizan la aplicación de las normas al integrar reglas de seguridad directamente en las canalizaciones de CI/CD y en los sistemas de tiempo de ejecución, de modo que las comprobaciones se realizan automáticamente cada vez que cambia el código o la infraestructura. En lugar de depender de que las personas recuerden todas las normas de seguridad y revisen manualmente cada cambio, el sistema evalúa de forma sistemática los cambios para garantizar que no se omita ningún paso accidentalmente.

La PaC ayuda a los desarrolladores a mantener la velocidad de implementación sin sacrificar la coherencia ni la seguridad. Aplica las mismas definiciones de políticas en todos los entornos y en todas las fases: desarrollo, pruebas, entorno de prueba y producción. Esta característica permite a los equipos realizar lanzamientos con frecuencia, ya que pueden confiar en que se aplica el mismo conjunto de reglas en todas partes. Además, les ayuda a evitar situaciones en las que los distintos entornos se desajusten entre sí o utilicen interpretaciones ligeramente diferentes de las reglas.

La PaC trata las políticas de seguridad de las aplicaciones como cualquier otro artefacto de código que se encuentra en un sistema de control de versiones. Los equipos de desarrollo, operaciones y seguridad pueden revisar, debatir y actualizar las políticas mediante flujos de trabajo con los que están familiarizados (revisiones de código, estrategias de ramificación), lo que hace que los debates sobre las políticas sean más transparentes y estén más integrados en el trabajo diario de desarrollo.

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

Los desarrolladores y los profesionales de la seguridad están explorando el concepto de política como código como una forma de crear modelos de controles de seguridad por capas que abarquen todo el ciclo de vida de un flujo de trabajo de IA o agéntico. Aunque se trata de una práctica aún en fase incipiente, las primeras investigaciones han revelado numerosas aplicaciones posibles de la PaC en los flujos de trabajo de IA.

La PaC puede ayudar a establecer una separación clara entre el razonamiento de la IA y el sistema que decide qué acciones está realmente autorizada a ejecutar. La herramienta de IA puede proponer acciones o planes, pero un motor de políticas evalúa dichas propuestas en función de reglas codificadas antes de que se intervenga en ningún sistema subyacente.

En la fase de entrada, la PaC puede ayudar a filtrar o transformar las instrucciones de los usuarios, ocultar datos sensibles, garantizar el aislamiento de los clientes y bloquear patrones de ataque conocidos. Durante la planificación, la PaC puede exigir a los agentes de IA que elaboren planes estructurados y validen cada paso en función de las herramientas, acciones y condiciones de riesgo permitidas antes de que se autorice la ejecución.

En el momento de la ejecución, cada invocación de una herramienta o llamada a la API puede ser comprobada por la capa de aplicación de políticas. Dicha capa decide si permite, deniega o modifica una acción, o si la remite a un ser humano. Tras la ejecución, las políticas pueden gestionar la información de registro, las pistas de auditoría, las normas de retención y los filtros posteriores sobre los resultados de los modelos, con el fin de garantizar que las respuestas cumplan con los requisitos necesarios.

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

• Eficiencia. Cuando las políticas se codifican, pueden aplicarse automáticamente en las canalizaciones de CI/CD o en el momento de la implementación, lo que elimina la necesidad de comprobaciones y aprobaciones manuales.

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

• Visibilidad. Al estar las políticas escritas en código y almacenadas de forma centralizada, las partes interesadas pueden ver exactamente qué reglas están vigentes, en lugar de depender de documentos dispersos y de la memoria de las personas.

• Escalabilidad. La evaluación de las políticas es automatizada, por lo que las organizaciones pueden aplicar las políticas a escala en numerosos servicios, clústeres o cuentas sin que ello suponga un aumento proporcional de la plantilla.

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