La Política como Código

Capítulo 1. La Política como Código: Una amable introducción

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Según algunas estimaciones, en los últimos 60 años se han escrito más de 2,7 billones de líneas de código. ¿Cuántas líneas has escrito tú? No sé cuántas líneas he escrito, pero llevo casi 30 años escribiendo código. Sólo en los últimos ocho años he utilizado Policy as Code (PaC) para controlar mejor los cambios, guiarme a través de sistemas y soluciones complejas, y asegurarme de que lo que escribo es lo que quiero escribir, ejecutar y distribuir.

Independientemente del sistema o artefacto, PaC ha surgido como la norma sobre cómo reducimos los cambios y comportamientos no deseados y no deterministas en los sistemas y soluciones que utilizamos, construimos y apoyamos. PaC nos permite codificar las directrices que especificamos, seguimos e imponemos. PaC hereda su utilidad de las normas y buenas prácticas de codificación, así como de los controles para aplicarlas.

La PaC aparece y mejora muchos sistemas y soluciones hoy en día, desde la computación en nube y Kubernetes hasta la Autorización (AuthZ), la integración continua/entrega continua(CI/CD), DevOps, DevSecOps, GitOps y la seguridad de la cadena de suministro de software. En este libro, examino la PaC más de cerca y presento ideas, patrones y ejemplos de cómo utilizar la PaC para habilitar mediante políticas tus soluciones. Por ahora, en este capítulo introduzco los conceptos de PaC, cómo debe trazarse PaC a partir de tus normas, y las características de PaC que pueden utilizarse para ayudarte a elegir la solución adecuada a tus necesidades. Al final del capítulo, dispondrás de un proceso y una lista de comprobación que podrás aplicar a lo largo de este libro para calibrar cómo se ajustan a tus necesidades las soluciones adicionales de PaC.

¿Qué es la política?

Sigues políticas todos los días. Las políticas te ayudan a tomar decisiones en el contexto de las situaciones en las que operas. Normalmente, estas políticas se basan en normas y directrices documentadas. Aceptas estas normas y directrices como parte del empleo o de la pertenencia a las organizaciones en las que funcionas. La política no es nueva para ti. En pocas palabras, la política es un sistema planificado de normas y directrices que dirige a los usuarios y la automatización para que se ejecuten dentro de unos límites intencionados. La política establece barandillas que iluminan y limitan.

Yo añadiría que con la política intentamos conseguir los resultados deseados. En el trabajo, hacer que sigas la política de la empresa es la forma que tiene la dirección de conseguir los resultados deseados, como asegurarse de que documentas e informas adecuadamente de tu tiempo fuera del trabajo.

La política reguladora se ha convertido en una fuerza impulsora de los sistemas informáticos al servicio de las empresas. Según la Organización de Cooperación y Desarrollo Económicos (OCDE), "la política reguladora consiste en alcanzar los objetivos del gobierno mediante el uso de reglamentos, leyes y otros instrumentos para obtener mejores resultados económicos y sociales y mejorar así la vida de los ciudadanos y las empresas."

El Reglamento General de Protección de Datos (RGPD) es una de las políticas reguladoras de la privacidad de datos emergentes más conocidas de la Unión Europea (UE). Como tal, el GDPR debe considerarse una fuerza motriz, junto con las políticas reguladoras en general.

Dado que en este libro las políticas se centrarán en los sistemas de tecnologías de la información (TI), necesitamos una definición de política más centrada en las TI. Según Torin Sandall en su artículo de Medium de 2017 "¿Qué es una política? Primera parte: Aplicación","En el contexto de los sistemas de software, las políticas son las reglas que rigen cómo se comporta el sistema".

Yo añadiría que las políticas también rigen cómo se comportan los actores dentro de esos sistemas. Las políticas definen reglas, y estas reglas especifican cómo se comportan los sistemas, así como la forma en que se configuran, se utilizan para su propósito definido y se aseguran.

Un tema importante de este libro es el uso de políticas y herramientas de políticas para evitar cambios no deseados y aplicar buenas prácticas en nuestros sistemas y artefactos. Es lógico que adoptemos una definición de política que cubra mejor el alcance de nuestras necesidades.

Ahora que entendemos la idea básica y la finalidad de la política, definamos la Política como Código.

¿Qué es la Política como Código?

Como se menciona en el Prefacio, PaC es el uso de artefactos de código -políticas- para gestionar y aplicar reglas y condiciones. Los motores de políticas son los programas que interpretan los artefactos de políticas para aplicar decisiones políticas, utilizando las reglas y condiciones mencionadas. Las reglas y condiciones definidas en los artefactos de políticas nos ayudan a aplicar las normas y políticas organizativas que hemos creado o adoptado. Estas implementaciones -conocidas como controles- aplicandecisiones de seguridad, cumplimiento, gobernanza y buenas prácticas que están diseñadas para prevenir y reaccionar ante cambios no deseados en los sistemas que soportamos y utilizamos.

En el nivel fundamental, durante la ejecución para llegar a decisiones, el PaC responde a preguntas: preguntas sobre sistemas, artefactos, escenarios y situaciones que hay que controlar. Más preguntas respondidas significa más controles implementados. Más controles implementados significa más comportamientos deterministas, menos comportamientos no deseados y menos sorpresas.

En la siguiente sección, examinaremos la estructura y las características de las políticas.

¿Qué es una Política?

Podemos modelar fácilmente una política descomponiéndola en partes que tengan sentido para nuestro uso. A alto nivel, nuestro modelo de política se compone de las siguientes partes:

Nombre de la política

Se utiliza para etiquetar la política para futuras referencias

Objetivo político

La razón por la que existe esta política y lo que intenta hacer cumplir o abordar

Situación política

El contexto (incluidos el sistema y el entorno) en el que se utilizará la política

Normas políticas

Controles individuales o comportamientos prescritos; las políticas pueden tener múltiples normas

Acciones políticas

Acciones que se toman si se infringe una norma de la política (no siempre forman parte del motor de la política)

A continuación, examinaremos más detenidamente las características de las políticas que las hacen tan útiles y los lenguajes políticos que utilizan.

Características de la Política PaC

En el contexto de PaC, las políticas tienen otras características que las hacen útiles en los sistemas informáticos. En primer lugar, las políticas PaC se escriben, almacenan, gestionan e interpretan como artefactos de código. Esto facilita su gestión e implementación en los sistemas con las mismas herramientas y procesos automatizados que ya utilizas para la entrega de aplicaciones.

Otro aspecto importante de las políticas PaC, independientemente de la implementación subyacente, es su familiaridad sintáctica. Como verás más adelante, cuando explores las soluciones PaC individuales con más detalle, los distintos lenguajes de políticas mejoran la adopción de PaC. Por ejemplo, si tu organización tiene profundas capacidades en JavaScript, entonces podrías elegir una solución PaC sustentada en el lenguaje JavaScript.

La naturaleza familiar de las políticas PaC, o de sus envoltorios de configuración, ayuda a su adopción. Para mí, cuanto más familiar es el lenguaje de las políticas PaC o su envoltorio de configuración, más intuitiva tiende a ser la solución. Sin embargo, lo familiar o intuitivo que me resulte un lenguaje -o su léxico- es algo subjetivo, basado en mis conocimientos y experiencia. Tú puedes tener ideas diferentes sobre la naturaleza familiar e intuitiva de los lenguajes que utilizas o prefieres. Puedes elegir soluciones PaC con lenguajes de políticas que sean declarativos, o puedes elegir lenguajes que sean más imperativos o incluso basados en aserciones.

Independientemente del lenguaje de políticas que elijas, las entradas que PaC maneja, evalúa y salidas tienden a ser más declarativas y estructuradas. De hecho, cuanto más declarativos y estructurados sean los artefactos, más fiablemente podrá evaluarlos PaC. Para ello, exploraremos por qué JSON y YAML son tan populares en las soluciones PaC.

El papel de JSON y YAML

Creo que todos estamos de acuerdo en que JSON y YAML son ejemplos de dos de los formatos de datos más declarativos e intuitivos que se utilizan ampliamente en los sistemas informáticos modernos. De hecho, muchos ingenieros de computación en nube y Kubernetes utilizan estos formatos de datos a diario para definir y declarar sus configuraciones en formatos estructurados.

No es casualidad que las herramientas PaC hayan adoptado estos dos formatos de datos para entregar políticas a los sistemas, procesar entradas y proporcionar salidas. Para algunos en el sector, las políticas PaC escritas o envueltas en JSON o YAML tienden a ser más declarativas, expresivas e incluso autodocumentadas. Aunque el lenguaje de las políticas PaC, utilizado dentro de un motor de políticas, no esté basado en formatos de datos JSON o YAML, o envuelto en ellos, los artefactos que evalúan las políticas suelen ser JSON o YAML. Los datos estructurados son sencillamente más fáciles de manejar.

PaC analiza y evalúa de forma natural artefactos JSON y YAML como parte de la correspondencia y evaluación de políticas. Los datos, independientemente de lo que representen, son más adecuados para las evaluaciones de PaC cuando pueden estructurarse en JSON o YAML. JSON y YAML pueden convertirse entre sí muy fácilmente. Por último, otros artefactos no estructurados o menos estructurados pueden analizarse en JSON y YAML para su posterior procesamiento por PaC.

A continuación, veamos cómo podemos evitar acciones o cambios no deseados utilizando el PaC para erigir barandillas.

Barandillas: Prevenir lo no deseado

Como mencioné en el Prefacio de este libro, en el pasado trabajé con organizaciones que utilizaban el PaC para crear límites para las operaciones de computación en nube. Cuando se trata de evitar cambios o comportamientos no deseados por parte de los usuarios o la automatización, estos límites actúan como guardarraíles. Si las operaciones se mantienen dentro de las barandillas, como se conduce normalmente por una autopista, entonces esas operaciones no están restringidas. Cuando esas operaciones se desvían del camino prescrito, violan las normas y condiciones establecidas por las políticas e intentan operar fuera de las barandillas, entonces esas operaciones se restringen mediante controles, que se hacen cumplir y se aplican mediante políticas.

Los guardarraíles permiten el flujo sin restricciones entre sus perímetros. En el caso de la computación en nube, la infraestructura cambia rápidamente para satisfacer las necesidades empresariales. Los profesionales que gestionan la seguridad, el cumplimiento y la gobernanza erigen barandillas, en forma de controles, para impedir comportamientos no deseados que podrían poner en peligro el negocio. Independientemente del control implantado, existe un fuerte deseo de no obstaculizar el progreso permitido.

Muchas organizaciones establecen controles para determinar cómo se aprovisionan las instancias informáticas. Esto ayuda a evitar cambios no deseados, independientemente de las intenciones de los usuarios o de sus niveles de experiencia y conocimientos. Por ejemplo, es habitual ver controles que impiden que existan instancias de cálculo si están asociadas a direcciones IP públicas. Los controles actúan como barandillas. Teniendo en cuenta nuestro modelo de política anterior, puedes visualizar la política para no permitir el cómputo con una dirección IP pública, que se muestra en la Figura 1-1.

Figura 1-1. Modelo de política: ComputePublicIP

En este ejemplo, cuando aprovisionas un equipo, tus acciones avanzan sin restricciones siempre que te mantengas dentro de los límites de seguridad. Sin embargo, si creas cómputo con una IP pública, tu progreso se detiene, y el cómputo que aprovisionaste se desactiva o incluso finaliza. La Figura 1-2 muestra un sencillo diagrama de actividad del flujo.

Con el tiempo, los guardarraíles te enseñan el flujo correcto y cómo proceder sin restricciones. Las organizaciones, en su conjunto, se mueven con mayor rapidez y seguridad cuando operan entre límites prescritos con poca fricción.

Veamos ahora cómo podemos utilizar el PaC para evitar lo no deseado reaccionando ante lo no previsto.

Figura 1-2. Diagrama de actividades de la política ComputeNoPublicIP

Planes: Reaccionar ante lo imprevisto

Los usuarios están constantemente haciendo cambios en los sistemas y artefactos. Es casi imposible juzgar lo que intentarán a continuación. Restringir las acciones de los malos actores es aún más difícil. Sin embargo, no es imposible determinar lo que unos y otros pueden hacer a continuación. Las políticas, aplicadas por los motores PaC, construyen una estrategia de defensa en profundidad (DiD), añadiendo una capa de contramedidas independientemente del origen del cambio.

Por ejemplo, consideremos un escenario en el que operas y mantienes un clúster Kubernetes o una colección de ellos. Aunque los usuarios que desplieguen en tu(s) clúster(es) pertenezcan a tu organización, no siempre tendrás el control sobre su código o imágenes de contenedor que necesitas para evitar que sus contenedores comprometan la integridad de tu(s) clúster(es). Puedes especificar ciertas prácticas para evitar que sus contenedores se comporten mal, como la configuración de seguridad, la configuración de red o incluso desde dónde se permite el origen de las imágenes de contenedor. Sin embargo, no puedes confiar en que los usuarios sigan tus instrucciones; además, puede que no tengan los conocimientos necesarios sobre Kubernetes. En lugar de eso, necesitas guardarraíles.

Para contrarrestar la posibilidad de que código o contenedores deshonestos saturen tu clúster o clústeres, necesitas establecer políticas, respaldadas por motores de políticas que se integren con Kubernetes. Exploraremos este tema con más detalle en capítulos posteriores, pero por ahora, se podrían implementar los siguientes ejemplos de políticas de base:

• Limitar la obtención de imágenes de contenedores sólo de registros aprobados

• Aplicar los elementos apropiados del contexto de seguridad de Kubernetes en los niveles Pod y contenedor

• Evita las entradas y salidas de red no deseadas desde y hacia los Pods aplicando las políticas de red Kubernetes adecuadas

• Impedir el uso de redes y puertos de host

• Evitar el uso Pod de procesos host y espacios de nombres

• Hacer cumplir las solicitudes y límites de recursos de los contenedores

Todas las políticas precedentes se ajustan al modelo de política definido anteriormente. La combinación de las políticas precedentes con acciones de política como denegar o modificar puede evitar los cambios no deseados relacionados con los clústeres y la posibilidad de que el código deshonesto cause problemas. Aunque exista código deshonesto, o binarios no deseados o a la deriva, dentro de un contenedor, las posibilidades de que cause daños se reducen, si no se eliminan. Esto forma parte de una estrategia DiD centrada en el menor privilegio. Con estas políticas, los contenedores sólo obtienen los permisos y recursos que necesitan para funcionar correctamente. Con este enfoque, reaccionas realmente ante lo imprevisto.

Nota

El PaC es sólo una parte del éxito de una estrategia DiD. Para más información sobre DiD, empieza por NIST SP 800-53.

Ahora que hemos definido la política y las políticas, y discutido cómo pueden ayudar a prevenir lo no deseado y a reaccionar ante lo imprevisto, tenemos que cambiar de marcha y explorar cómo el software de código abierto desempeña un papel clave en la PaC.

Adoptar software de código abierto

Cuando oigo el término software de código abierto (OSS), pienso en software accesible públicamente, de forma que cualquiera puede revisar el código o incluso modificarlo. Por supuesto, esto está sujeto a las licencias OSS y a las guías y acuerdos de los colaboradores. También pienso en comunidad, y con una comunidad de desarrollo de proyectos más grande viene la posibilidad de una mayor estabilidad y seguridad.

La mayoría de las soluciones de PaC son proyectos de código abierto. ¿Has trabajado o contribuido alguna vez a un proyecto de OSS? ¿Alguna vez has querido o has tenido que adoptar un proyecto de OSS para tus necesidades? El OSS tiene ciertas ventajas e inconvenientes en el contexto de la PaC, y no todos los proyectos de OSS son iguales.

En mi opinión, las dos mayores ventajas del OSS son el ahorro potencial de costes que puede proporcionar y su escala de contribuciones. Muchos proyectos y bibliotecas de OSS son utilizados por las organizaciones para reducir el esfuerzo general de desarrollo. Alguien ya lo ha escrito, y si funciona para tus necesidades, ¿por qué duplicar el esfuerzo? En igualdad de condiciones, puedes avanzar más rápido con el OSS. Avanzar más rápido reduciendo el esfuerzo de desarrollo suele significar reducciones de costes.

Por su naturaleza, los proyectos maduros de OSS pueden tener un mayor número de mantenedores y colaboradores. Esto significa que hay más ojos en el proyecto y que las contribuciones proceden de diferentes perspectivas. Los mantenedores de proyectos OSS dirigen y guían el proyecto, ateniéndose a los estatutos y a la dirección del proyecto definidos. Los colaboradores aportan sugerencias y posibles cambios y son multiplicadores de fuerza para los proyectos OSS; aumentan la eficacia de las actividades del proyecto.

Más implicación significa más control y menos posibilidades de que se pase algo por alto. Aunque esto no significa que no tengas que revisar y gestionar los artefactos del proyecto, como harías con cualquier otro proyecto de software, sí aumenta la probabilidad de que los problemas importantes se detecten y solucionen antes.

Nota

Para más información sobre los mantenedores y colaboradores de OSS, consulta el artículo "How Open Source Maintainers Keep Contributors-and Themselves-Happy" de Klint Finley en The ReadME Project.

Junto con la madurez del proyecto de OSS, el impulso continuo y constante del proyecto es clave para el éxito de los proyectos de PaC de OSS. Las soluciones PaC tienen más éxito cuando pueden resolver múltiples casos de uso. Resolver casos de uso requiere políticas e integraciones nuevas y actualizadas. En otras palabras, los proyectos deben seguir creciendo, resolviendo más problemas para más usuarios. Sin impulso, los proyectos PaC -y los proyectos OSS en general- se estancan, y los usuarios buscan soluciones en otra parte.

Ahora que sabemos por qué debemos utilizar OSS, equilibremos la ecuación considerando algunas de las desventajas del OSS.

Desventajas del OSS

Ciertamente, los proyectos de OSS no están exentos de desventajas y riesgos. De hecho, si me dejara llevar, el tema del riesgo del OSS podría consumir la mayor parte de este libro, si no todo. De lejos, la mayor desventaja del OSS es la posible falta de apoyo. No estoy diciendo que los mantenedores y colaboradores de OSS no apoyen a su comunidad de usuarios; mi experiencia ha sido todo lo contrario. Sin embargo, el mantenimiento y las contribuciones al OSS suelen realizarse como esfuerzos secundarios; los mantenedores y colaboradores tienen trabajos diarios fuera de los proyectos que apoyan.

Aunque hay excepciones, este conflicto entre trabajos y proyectos limita de forma natural la rapidez con la que los mantenedores y colaboradores pueden responder a las solicitudes. Esto puede no funcionar para las organizaciones que están acostumbradas a los acuerdos de soporte empresarial o que requieren tiempos de respuesta más deterministas para las solicitudes de soporte. Aunque existe soporte empresarial de terceros para algunos proyectos de OSS, no es la norma.

Cuando utilizas un proyecto OSS y no eres mantenedor, careces de control definitivo sobre la dirección del proyecto. Tienes que decidir si esa falta de control, suplantada por una esfera de influencia limitada, se ajusta a tus necesidades. En muchos casos, es un compromiso manejable.

Nota

El riesgo es otra posible desventaja de los proyectos de OSS. Para más información sobre el riesgo del OSS, consulta los 10 principales riesgos del software de código abierto publicados recientemente por OWASP. Esta lista destaca el riesgo significativo de los proyectos de OSS y se basa en parte en las conclusiones del Informe de análisis de riesgos y seguridad del software de código abierto de Synopsys. El informe de Synopsys señalaba los siguientes datos generales de riesgo del OSS:

• El 89% de las bases de código contienen OSS que está más de cuatro años desfasado

• El 91% de las bases de código contienen componentes que no han tenido ningún desarrollo nuevo en más de dos años

Juntos, estos dos informes proporcionan una valiosa visión del riesgo de los proyectos de OSS.

El OSS no es perfecto, pero utilizado correctamente, sigue siendo un facilitador, si no un multiplicador de fuerzas. Ahora, veamos más de cerca algunos de los aspectos del OSS que debemos tener en cuenta a la hora de decidir si debemos utilizar proyectos de OSS.

El cuidado y la alimentación del OSS

Aunque el OSS ofrece ventajas sobre los proyectos desarrollados internamente, su uso requiere cierto cuidado y alimentación. Deben tenerse en cuenta las siguientes cuestiones relacionadas con el OSS:

Licencias

Asegúrate de que el proyecto OSS que quieres utilizar tiene una licencia que permite la forma en que quieres utilizarlo. ¿Puedes bifurcarlo, si es necesario? La mayoría de las organizaciones tienen una oficina de programas de código abierto (OSPO) que define qué licencias pueden utilizarse internamente.

Seguridad

¿Está la seguridad integrada en el proyecto? La OpenSSF Scorecard es una herramienta emergente para medir la seguridad del proyecto de OSS.

Madurez

¿Qué grado de madurez tiene este proyecto? ¿Cuántas y qué tipos de versiones se han cortado? ¿Está generalmente disponible (GA)? ¿Cuál es el índice de errores y de mejoras solicitadas? ¿Cómo gestiona el proyecto los cambios?

Dependencias

¿Qué dependencias tiene el proyecto OSS? ¿Están documentadas esas dependencias? ¿Son seguras?

Apoyo activo

¿Cómo de activos son los mantenedores del proyecto OSS que estás considerando? ¿Cuándo fue la última vez que se hicieron contribuciones a este proyecto? ¿Son regulares las contribuciones? ¿Cuándo se corregirán los errores o vulnerabilidades? ¿Podrías seguir apoyándolo si fuera necesario? ¿Requiere tu organización un acuerdo de soporte más formalizado para el software externo?

Dirección del proyecto

¿Hacia dónde se dirige el proyecto? ¿Tiene sentido tu caso de uso para la dirección del proyecto, o es sólo un caso de perímetro?

Capacidad interna

¿Tú o tu equipo estáis familiarizados con la tecnología o los lenguajes utilizados en el proyecto de OSS? ¿Podéis todos revisar el código y decidir con precisión sobre su fiabilidad y adecuación para tu uso? ¿Dispones de los sistemas necesarios para almacenar, gestionar y vender los artefactos del proyecto de OSS para un uso seguro y fiable dentro de tu organización? ¿Dispones de las herramientas para escanear y detectar de forma exhaustiva y fiable las vulnerabilidades del OSS?

Consejo

Más allá de las bifurcaciones de corta duración utilizadas para las contribuciones pull-request, los proyectos OSS sólo deben bifurcarse como último recurso. La bifurcación de un proyecto OSS suele hacerse para dirigir el proyecto en una dirección diferente y eventualmente sustituirlo.

Aunque la necesidad sea la "madre de la invención" (Platón), las decisiones desesperadas conducen a errores y malentendidos. Si decides utilizar OSS por cualquier motivo, PaC o de otro tipo, opta por asumir el esfuerzo holístico que supone gestionar los artefactos de OSS como si los hubieras desarrollado tú mismo. Si necesitas más influencia sobre el proyecto de OSS, planea contribuir al proyecto o incluso mantenerlo, si es necesario.

El patrocinio de proyectos y colaboradores son formas de apoyar los proyectos de OSS más allá de la participación activa de los colaboradores o mantenedores en el proyecto. Teniendo en cuenta cuántos proyectos de OSS se utilizan en productos de software y proyectos dentro de las empresas, hay poca retribución en forma de apoyo financiero a estos proyectos. El patrocinio de proyectos y colaboradores es una buena forma de retribuir a la comunidad de proyectos OSS y a los proyectos de los que dependen tus productos o proyectos.

Si tu organización tiene una OSPO, aprovecha sus conocimientos y experiencia para guiarte mejor por el camino de menor resistencia a la hora de consumir proyectos de OSS. La OSPO ha estado allí y ha hecho eso, y está encargada de ayudar a tu organización a utilizar OSS con éxito y seguridad.

Nota

Para más información sobre las OSPO y la comunidad de profesionales, consulta la organización Talk Openly Develop Openly (TODO).

Pasando de las preocupaciones sobre el OSS, veamos cómo el PaC está vinculado a las normas y controles de tu organización.

Normas y controles

La mayoría de las organizaciones tienen grupos que gestionan políticas y normas, como las de ciberseguridad. Estos grupos crean sus propias normas y adoptan normas y buenas prácticas reconocidas de organizaciones como la Cloud Security Alliance (CSA), el Center for Internet Security (CIS) y el National Institute of Standards and Technology (NIST). Se hace referencia a otros organismos de normalización, como el Payment Card Industry (PCI), según sea necesario, en función del enfoque empresarial.

Las normas suelen tener su origen en las políticas organizativas. La diferencia entre las políticas organizativas y las normas es que las políticas suelen centrarse más en comunicar la intención organizativa o directiva, mientras que las normas suelen centrarse en los requisitos específicos mensurables implícitos en las políticas y necesarios para éstas.

La organización cumple los requisitos definidos por las normas. Para gobernar, gestionar y medir el cumplimiento de las normas, las organizaciones utilizan equipos internos -y a veces externos- de gobierno, riesgo y cumplimiento (GRC). Los equipos de GRC se centran en áreas específicas de la empresa y, en algunos casos, en sistemas informáticos concretos. En el caso de TI, los equipos de GRC trabajan con PYMES de sistemas y tecnología para definir los controles necesarios para hacer cumplir los requisitos.

Por ejemplo, el equipo de ingeniería de la nube de tu empresa gestiona el uso de los servicios de la nube pública. Para proporcionar una experiencia de computación en la nube segura y bien gestionada, el equipo trabaja con GRC para definir un conjunto de controles que se ajuste a los requisitos establecidos por las normas de la organización. Las PYMES asesoran a GRC sobre lo que es posible en la nube. El grupo de trabajo, formado por la colaboración de GRC y las PYMES de ingeniería de la nube, rastrea las normas y los controles asociados mediante una matriz. En el ejemplo de matriz de trazabilidad de controles que aparece en la Tabla 1-1, la cardinalidad entre normas y controles es de uno a muchos. Las normas pueden tener varios controles.

Tabla 1-1. Matriz de trazabilidad de los controles GRC

Estándar	Área de interés	ID	Control	Estado
La informática no orientada al cliente no debe acceder directamente a puntos finales más allá de la red corporativa.	Seguridad de la Información-Cloud Computing	ISCC-1	Evitar que se asignen direcciones IP públicas a los ordenadores	Aprobado
	Seguridad de la Información-Cloud Computing	ISCC-2	Evitar que NAT se asocie a subredes privadas	En desarrollo

Las PYMES del equipo de ingeniería de la nube acuerdan implementar los controles y gestionar los esfuerzos internos para construir, probar e implementar los controles respectivos. Los equipos de GRC son partes interesadas del proyecto que orientan a la ingeniería de la nube sobre los requisitos. GRC revisa los controles y confirma que cumplen los requisitos.

El equipo de ingeniería de la nube utiliza PaC para implementar los controles acordados por el grupo de trabajo GRC. Los controles PaC emiten registros y mensajes que sirven como artefactos auditables que utilizan las PYMES para demostrar a GRC que los controles implementados hacen cumplir los comportamientos definidos en los requisitos. Del mismo modo, GRC utiliza los artefactos auditables para satisfacer a la dirección y a los auditores internos y externos.

En el modelo de este ejemplo, existe una trazabilidad desde las políticas organizativas generales hasta las políticas PaC específicas utilizadas para aplicar los controles. El modelo piramidal de la Figura 1-3 describe la jerarquía y la reducción del enfoque.

Figura 1-3. Pirámide de trazabilidad y enfoque de las políticas

Las políticas de PaC aplican controles impidiendo cambios y comportamientos no deseados y reforzando los comportamientos y prácticas deseados. En pocas palabras, PaC implementa controles. Normalmente, los controles implementados por PaC tendrán su origen en normas creadas o adoptadas por tu organización. Estos controles también deben ser trazables y auditables.

A continuación, exploraremos cómo el PaC está cambiando la forma en que aprovechamos y ampliamos los artefactos de código.

La política como código para todo como código

Durante los últimos años, hemos asistido a una especie de transformación respecto a cómo aprovisionamos y utilizamos los recursos informáticos: hemos pasado y seguimos pasando a todo como código (EaC). Muchos de los procesos que utilizamos ahora para aprovisionar, mutar o validar recursos informáticos utilizan artefactos *como código. Para muchos de nosotros, se acabaron los días de esperar semanas o meses para recibir capacidad informática. Ahora simplemente la marcamos, por así decirlo, aplicando artefactos de infraestructura como código (IaC), como JSON o YAML, o incluso planes Terraform, a través de nuestros servicios de nube pública o privada. Ahora podemos incluso aprovisionar recursos bare-metal utilizando herramientas como Tinkerbell.

Aunque suele haber una consola que podemos seguir utilizando para aprovisionar nuestros recursos, el uso de IaC nos brinda la oportunidad de gestionar nuestros recursos de infraestructura igual que lo hacemos con el código de nuestra aplicación. Ahora utilizamos herramientas de gestión del código fuente, así como herramientas de CI e incluso GitOps, para gestionar y aplicar la infraestructura. Y aunque normalmente aplicamos IaC de forma declarativa, ahora incluso hemos difuminado las líneas entre lo imperativo y lo declarativo, y hemos combinado ambos con herramientas como el Kit de Desarrollo en la Nube (CDK) de Amazon Web Services (AWS) o el Kit de Desarrollo en la Nube para Terraform (CDKTF) de HashiCorp.

Independientemente de lo que estés haciendo o utilizando, si puedes hacerlo con código, obtendrás varias ventajas tangibles que se pierden cuando realizas las tareas manualmente. Por ejemplo, puedes utilizar la misma fuente única de verdad (SSOT) que proporciona la gestión centralizada del código fuente. También puedes aprovechar las oportunidades de colaboración que ofrece la EaC. Las herramientas y los procesos han sido perfeccionados durante años de gestión del código fuente.

Utilizar y desplegar artefactos como código conlleva mejoras en la repetibilidad, ya que los procesos automatizados reducen la variabilidad entre las integraciones y las implementaciones; como los artefactos y las implementaciones son código, entendido por los sistemas subyacentes, también mejora la escalabilidad con comportamientos deterministas.

Las herramientas de gestión del código fuente y de CI proporcionan automatización para gestionar tus artefactos *-como-código. Puedes automatizar tanto las pruebas como el análisis del código fuente. Con las pruebas automatizadas y el PaC, aplicas políticas al código para evaluar los cambios antes de permitir su fusión. Una mayor automatización conduce a una detección más rápida de los problemas y te permite fallar y tener éxito más rápidamente, con resultados más deterministas. En otras palabras, obtienes más repetibilidad y reproducibilidad y, como ya he dicho antes, menos sorpresas suelen ser algo bueno.

Aplicar PaC a tu código fuente también te ayuda a implementar el cumplimiento como código (CaC). Con CaC, las políticas de cumplimiento se utilizan como pruebas y a menudo se emplean en las canalizaciones CI para validar los artefactos *como código antes de que puedan utilizarse para cambios posteriores.

La seguridad como código (SaC) está relacionada con la CaC y también puede beneficiarse de la PaC. Según Jim Bird, en su libro DevOpsSec (O'Reilly), "La seguridad como código es la práctica de incorporar la seguridad a las herramientas y flujos de trabajo DevOps, trazando un mapa de cómo se realizan los cambios en el código y la infraestructura y encontrando lugares donde añadir comprobaciones, pruebas y puertas de seguridad sin introducir costes o retrasos innecesarios".

Codificar la seguridad y sus políticas libera las configuraciones de seguridad de documentos legibles sólo por humanos y las convierte en artefactos legibles por humanos y máquinas, haciendo que los artefactos SaC sean ejecutables, rastreables y auditables.

En mi opinión, SaC, tal como lo define Jim Bird, implica PaC. PaC puede utilizarse para evaluar los artefactos y producir los atestados que necesitan las puertas DevOps. Siempre que las atestaciones (pruebas) sean analizables (JSON, YAML, etc.) por el motor de políticas PaC, entonces PaC se adapta a este caso de uso.

Con el tiempo, las políticas PaC, utilizadas para CaC y SaC, forman barandillas, igual que los casos de prueba lo hicieron para el desarrollo dirigido por pruebas (TDD). La automatización continua de las pruebas y las evaluaciones PaC aumenta la fiabilidad de tus bases de código y reduce las variaciones no deseadas que llegan a tus entornos de producción. Como punto de referencia, la Figura 1-4 muestra cómo CaC y SaC utilizan PaC para EaC.

Figura 1-4. CaC y SaC utilizando PaC para aplicar políticas a EaC

Ahora que hemos explorado el uso del PaC dentro del panorama en evolución del EaC, pasemos a los motores y lenguajes que ejecutan y construyen políticas para nuestras necesidades.

Motores políticos y lenguajes

Como parte de una solución PaC, los motores de políticas realizan el trabajo pesado interpretando el lenguaje de las políticas y evaluando los datos. Según Bruce A. Fette en su libro Cognitive Radio Technology, Second Edition (Academic Press), "Un motor de políticas es un programa o proceso capaz de ingerir políticas legibles por máquina y aplicarlas a un dominio problemático concreto para restringir el comportamiento de los recursos de la red".

Me gusta esta definición porque presenta tres rasgos que, en mi opinión, caracterizan correctamente a los motores políticos de PaC:

• Ingesta de políticas legibles por máquina (PaC)

• Aplicar políticas a ámbitos problemáticos específicos (datos)

• Comportamientos limitantes (resultados)

Un motor de políticas ingiere la política que se va a utilizar en la evaluación, los datos que se van a evaluar y la consulta que se va a utilizar. A continuación, el motor de políticas evalúa los datos suministrados comparándolos con la política suministrada y produce una respuesta, utilizada por el sistema al que el motor de políticas está integrado o sirve. Las políticas se escriben para que coincidan con los datos que evalúan; además, esa coincidencia se produce antes de que la política evalúe los datos y después de cualquier proceso de entrada, como el análisis sintáctico. La Figura 1-5 muestra un diagrama de flujo del proceso de evaluación típico de un motor de políticas.

Figura 1-5. Flujo de evaluación del motor de políticas

En el flujo mostrado en la Figura 1-5, si una política no coincide con los datos dados, el motor de políticas podría devolver un objeto indefinido o vacío, un error o incluso un valor falso. Algunos motores de políticas admiten la capacidad de cargar políticas y datos de apoyo de forma asíncrona, no sólo durante los ciclos de evaluación. Y hay motores de políticas que incluso buscan datos externos como parte del ciclo de evaluación.

En el contexto de un motor político, el lenguaje político es el lenguaje en el que está escrita la política, no necesariamente el lenguaje en el que está escrito el motor. Sin embargo, no todos los motores de políticas utilizan los mismos lenguajes de políticas. En este libro cubro los siguientes motores de políticas, entre otros, junto con sus lenguajes de políticas asociados:

• Custodio de la nube (c7n)-YAML

• jsPolicy-JavaScript

• Kyverno-YAML

• MagTape-Rego

• Agente de Política Abierta (OPA)-Rego

• OPA/Gatekeeper-Regoy YAML

Más adelante describiré cada uno de ellos con más detalle, pero de momento, veamos cómo podemos elegir la solución de PaC adecuada a nuestras necesidades, basándonos en el idioma y en otros factores.

Elegir la solución PaC adecuada

¿Qué motor de políticas debes utilizar? La respuesta a esa pregunta depende de varios factores. De hecho, puede que tengas que leer la mayor parte de este libro y probar varias soluciones de PaC antes de estar preparado para hacer esa elección. La buena noticia es que elegir la solución de PaC correcta, la que mejor se adapte a tus necesidades, no es necesariamente una decisión de una sola dirección. Es más, no es inaudito que los usuarios implementen varias soluciones de PaC; pueden coexistir en los sistemas a los que sirven.

Las buenas prácticas para elegir la solución PaC adecuada empiezan por la honestidad. Sé sincero contigo mismo, con tu equipo y con tu organización. No elijas simplemente la solución que te parezca más guay, o incluso la más comercializada, adoptada o conocida. Elige la solución que mejor se adapte a tus criterios de selección, a todos (o al menos a la mayoría) de tus criterios de selección. Comprende y define lo que debes tener frente a lo que deberías tener o incluso lo que te gustaría tener. Ponderar los criterios de selección es bueno para este proceso de clasificación. Basa tus criterios de selección en representaciones reales de las necesidades y capacidades de tu organización.

Conoce íntimamente tus casos de uso. Podría decirse que el siguiente paso en la elección de la solución de PaC adecuada a tus necesidades es la adecuación a tus casos de uso. Le sigue de cerca la adecuación a la experiencia de usuario (UX ) que necesitarás para fomentar la mayor aceptación y adopción dentro de tu organización. Obviamente, parte de la coincidencia de UX consiste en definir a tus usuarios y comprender sus necesidades. Los ejercicios de adecuación de los casos de uso y la UX te ayudan a evitar elecciones erróneas que den lugar a una inadecuación de la solución.

No intentes hervir el océano con la solución PaC que elijas. Desconfía de los casos de perímetro. Incluso si la solución de PaC que estás considerando satisface un caso de uso específico que preocupa a tu organización, puede que esa solución no sea la adecuada si tu caso es un caso límite que no está ampliamente adoptado o respaldado.

En las próximas secciones, trataré en detalle los factores para la selección de PaC, cómo construir tus criterios y cómo puedes tomar decisiones basadas en datos, en función de lo bien que se ajusten los factores a tus criterios. Aunque la elección es relativamente reversible, revertir la decisión no está exento de coste o impacto empresarial. Por eso es importante alinear los factores de selección de PaC, relacionados con las elecciones, con tus criterios de selección.

La siguiente sección proporciona una lista no exhaustiva de posibles factores de selección de PaC. Estos factores, junto con los casos de uso y los impulsores específicos de la organización, se utilizan para definir tus criterios de selección relativos y crear la correspondiente tarjeta de puntuación. Tu cuadro de mando te permite tomar decisiones informadas y basadas en datos. Ten en cuenta que tus decisiones pueden implicar el uso de varias soluciones; las soluciones PaC no son necesariamente excluyentes entre sí. Por ejemplo, puedes decidirte por una solución PaC para la computación en nube IaC mientras utilizas una solución PaC diferente para CI/CD o Kubernetes.

Ejemplo de factores de selección PaC

Debes considerar los siguientes factores antes de decidir qué solución de PaC adoptar:

Alineación-capacidades organizativas

¿En qué medida las tecnologías (idiomas, etc.) utilizadas por la solución PaC se ajustan a las capacidades técnicas del equipo o equipos que pondrán en marcha y gestionarán la solución?

Alineación-estrategias organizativas

¿En qué medida se ajusta la solución de PaC a las estrategias internas sobre cómo deben adoptarse y gestionarse las herramientas y aplicaciones?

Alineación-normas organizativas

¿En qué medida los controles que se crearán con la solución PaC se ajustan a las necesidades, al menos parcialmente, de las normas internas que impulsan esta decisión?

Analítica/registro/métricas

¿En qué medida proporciona la solución PaC registros, métricas y análisis adecuados para cumplir los requisitos internos, incluidas las auditorías?

Automatización (CI/CD)

¿Puede utilizarse la solución PaC en pipelines CI/CD, desplazando a la izquierda del sistema de destino? Si es así, ¿cómo? ¿Puede automatizarse la implementación del motor y las políticas?

Ejemplos y patrones disponibles

Dados tus casos de uso deseados, ¿hay suficientes ejemplos y patrones disponibles para pruebas, evaluaciones y pruebas de concepto?

Adopción comunitaria

¿Quién utiliza y apoya esta solución de PaC? ¿Qué grado de adopción ha tenido el proyecto?

Complejidad

¿Es difícil instalar y gestionar esta solución en tus entornos?

Documentación

¿Está bien documentada la solución? ¿Es comprensible la documentación?

Modos de funcionamiento

Las soluciones PaC difieren en cómo pueden utilizarse (servidor, bibliotecas, CLI, etc.). ¿Qué modos de funcionamiento admiten, y se ajustan a tus necesidades e incluso mejoran tus prácticas?

Recencia del proyecto

¿Cómo de recientes son las contribuciones y los cambios en el proyecto? ¿Sigue siendo viable el proyecto?

Informar

¿Proporciona la solución una función de elaboración de informes? ¿Utiliza o se integra en herramientas estándar de elaboración de informes? ¿Es compatible con las normas de intercambio de datos, como OSCAL?

Seguridad

¿Qué riesgos y vulnerabilidades existen en el proyecto de OSS? ¿En cuánto tiempo suelen solucionarse los riesgos y vulnerabilidades? ¿Qué herramientas y procesos automatizados se utilizan para descubrir problemas de seguridad? ¿Existe una postura de seguridad proactiva? ¿Se firman los commits? ¿Qué controles de seguridad hay en el software real, como la autenticación multifactor (MFA) y similares?

Extensibilidad de la solución

¿Puedes ampliar la solución con scripts, lenguajes o módulos? ¿Es fácil este proceso?

Madurez de la solución/proyecto

¿Ha pasado la solución/proyecto por suficientes iteraciones? ¿Está lo suficientemente madura como para ponerla en práctica? ¿Existen ejemplos o documentación para hacer operativa la solución?

Modelo de apoyo

¿Cuál es el nivel de asistencia de la solución? ¿Puedes adquirir asistencia empresarial, si es necesario?

Casos prácticos (IaC, Kubernetes, etc.)

¿Cuáles son los principales casos de uso que admite la solución? ¿Coinciden con tus casos de uso?

Experiencia del usuario

¿Es fácil utilizar la solución PaC? ¿Es intuitiva y familiar? ¿Cuánta formación se necesita para su implementación?

Ahora que tenemos los factores de selección, veamos cómo podemos utilizarlos para crear nuestros criterios de selección y puntuar las soluciones PaC.

Tarjeta de puntuación de la selección PaC

Una vez que hayas definido y comprendido los factores de selección, puedes derivar tus criterios de selección y crear tu cuadro de mando (véase la Figura 1-6). Los criterios de selección se componen de los factores de selección relativos a tu situación, anotados con un peso. El peso del factor indica lo importante que es cada factor individual para tu organización. Para los factores de importancia nula, puedes ponderar el factor en consecuencia (con un cero) o dejarlo fuera de la tabla de puntuación por completo. La puntuación de ajuste se explica por sí misma; indica lo bien que se ajusta a tus necesidades el criterio de selección de la solución PaC.

En el cuadro de mando de la Figura 1-6, la columna Peso contiene los valores 1-3, que indican cuál de las tres clasificaciones (imprescindible, necesario, agradable) se aplica a los factores de selección para formar los criterios de selección elegidos para la evaluación. El cuadro de mando incluye evaluaciones de dos soluciones, una al lado de la otra. Multiplica las columnas Ajuste de cada sección de evaluación por la columna Peso común para determinar la Puntuación individual de cada criterio de selección. La columna Ajuste utiliza los valores 1-5. Para indicar una mayor diferencia en las evaluaciones, puedes cambiar los rangos de las columnas Peso y Ajuste para que sean mayores, o incluso sustituir los números de base 10 por números de Fibonacci.

Con este enfoque de cuadro de mando, puedes evaluar y elegir la solución adecuada a tus necesidades. Utilizas el cuadro de mando para registrar tus decisiones basadas en datos, a partir de tus evaluaciones. Tus evaluaciones se derivan de pruebas activas y/o pruebas de concepto. Para los proyectos de OSS, las respectivas comunidades del proyecto pueden proporcionar una valiosa ayuda y conocimientos sobre los posibles casos de uso y la dirección del proyecto.

Figura 1-6. Tarjeta de puntuación para la selección de la solución PaC

Por último, puedes utilizar gráficos para visualizar y comunicar tus decisiones. La Figura 1-7 es un ejemplo de gráfico de piruleta que muestra claramente tu evaluación agregada sin exponer los detalles de tus criterios de selección. Es ideal cuando se presenta a partes interesadas con tiempo o atención limitados. Para obtener más detalles, sugeriría un gráfico de radar, un gráfico de áreas o incluso un gráfico radial de piruleta.

Figura 1-7. Gráfico de piruletas que muestra las puntuaciones globales

Ahora que estamos equipados con un método para evaluar diferentes soluciones PaC, quiero presentar a la Cloud Native Computing Foundation (CNCF) y tocar cómo indica la madurez de sus proyectos OSS "aceptados".

La Fundación para la Computación Nativa en la Nube

El CNCF forma parte de la Fundación Linux. El CNCF es un centro para proyectos de código abierto y neutrales respecto a los proveedores que han sido aceptados por el CNCF. Parte de su objetivo es impulsar la adopción de la nube nativa.

Según los estatutos de la CNCF, ésta se creó con una misión: "hacer omnipresente la computación nativa en la nube". ¿Qué es la computación nativa en la nube (CNC)? Puedes revisar la definición de computación nativa en la nube del CNCF cuando quieras.

Para mí, la definición de CNCF describe las tecnologías que utilizamos para el desarrollo y la entrega de aplicaciones sostenibles y modernas. Algunas de las características del CNCF que considero más importantes y relevantes para este libro son:

• Automatización

• Computación en nube (pública, privada e híbrida)

• Cambios frecuentes y deterministas

• Inmutabilidad

• Manejabilidad

• Observabilidad

• Escalabilidad

• Seguridad

Las tecnologías CNC son deseables para la mayoría de las organizaciones. Incluso con la definición de CNC, las organizaciones pueden tener dificultades para identificar proyectos y tecnologías CNC que estén listos para su consumo inmediato. Aquí es donde entra en juego el CNCF. Sólo los proyectos que cumplen las rigurosas directrices del CNCF se consideran miembros del CNCF. Con esta pertenencia viene una etiqueta que indica el nivel de preparación para ser utilizado en casos de uso de CNC que tiene cada proyecto miembro.

La madurez del proyecto es un aspecto importante de la evaluación de los proyectos de OSS y, como he mencionado antes, la madurez de la solución/proyectoes uno de mis factores de selección de PaC recomendados. En el contexto del CNCF, la indicación de facto de la madurez del proyecto se encuentra en los tres niveles de los proyectos del CNCF: sandbox, incubación y graduado. A medida que avancemos en los siguientes capítulos, iré señalando los proyectos CNCF y su correspondiente nivel de proyecto CNCF.

Nota

No me propuse escribir un tomo exhaustivo que cubriera todas las posibles reglas y herramientas políticas de TI disponibles en la actualidad. De hecho, he descrito a propósito las reglas y herramientas políticas que son específicas de CSP. Algunas de las herramientas y servicios que no cubro explícitamente en este libro son:

• Políticas de control de servicios de AWS

• Configuración AWS

• Política Azure

• Servicio de política de organización de Google Cloud Platform (GCP)

• Políticas de gestión de identidades y accesos (IAM)

Para los fines de este libro, cubro las soluciones PaC y PaC que son, en su mayor parte, neutrales en cuanto al proveedor y agnósticas en cuanto al CSP.

Resumen

Hemos cubierto mucha información en esta introducción al PaC, pero sólo hemos arañado la superficie. En este capítulo te hemos hablado de política, políticas y Política como Código (PaC). Hemos hablado de motores y lenguajes de políticas, de algunos usos de PaC (como los guardrails) y de cómo seleccionar la mejor solución PaC para tus necesidades. Con una comprensión general de PaC y con el telón de fondo del OSS y el CNCF, ahora podemos profundizar en las soluciones PaC para los sistemas que utilizas, construyes y soportas.

A lo largo del resto de este libro, presentaré, con bastante más detalle, soluciones PaC específicas y sus respectivos casos de uso, tecnología y funcionalidad general. A medida que avances en este libro, llévate contigo el Cuadro de Mando de Selección de Soluciones PaC para aplicarlo a lo largo del camino. La introduje en este primer capítulo para que pudieras utilizarla a lo largo del resto del libro como guía preliminar para evaluar las múltiples soluciones de PaC que siguen. Por último, para no regurgitar documentación ya publicada, me centraré en el conocimiento práctico de las soluciones PaC y haré referencia a la documentación sólo cuando sea necesario.

En el Capítulo 2, comenzaré mi presentación detallada de las soluciones PaC con una inmersión más profunda en Open Policy Agent.