¿Cómo protegemos las herramientas de infraestructura como código?

Como su nombre lo indica, la infraestructura como código (IaC) es la práctica de definir como código y archivos de configuración la infraestructura en la que se ejecutan tus aplicaciones. Esto nos permite no solo automatizar el aprovisionamiento de recursos, sino también someterlo a los mismos procesos del ciclo de vida que históricamente se aplicaban solo al código de las aplicaciones. Si no conoces IaC, consulta este artículo, donde explicamos qué es la infraestructura como código (IaC) y cuáles son las implicaciones de seguridad de usarla en el mundo real.

Existe una gran variedad de herramientas de automatización de infraestructura para implementar IaC. Muchas provienen de proveedores de nube pública, como CloudFormation de Amazon Web Services y Resource Manager (ARM) de Azure, además de proyectos compatibles con distintas plataformas de infraestructura, como HashiCorp Terraform y Pulumi.

Estas herramientas de IaC basadas en lenguajes declarativos son ideales para las técnicas de análisis estático, que permiten detectar y resolver problemas de seguridad antes de implementar siquiera la infraestructura definida. Los patrones de buenas prácticas de seguridad en el ámbito de IaC se descubren continuamente. A medida que desarrollamos el producto Snyk IaC, nos esforzamos por facilitar al máximo la adopción de IaC para las organizaciones: ayudamos a los desarrolladores no solo a conocer los problemas, sino también les damos contexto y recomendaciones para corregirlos.

Veamos algunas de las herramientas populares de infraestructura como código y las medidas de seguridad que puedes aplicar a nivel de código para proteger tus aplicaciones y plataformas.

Herramientas de infraestructura como código

Soluciones de proveedores de nube

AWS CloudFormation, Azure Resource Manager (ARM), y Google Deployment Manager (GDM)Todos los principales proveedores de nube crean sus propias herramientas de IaC para aprovisionar infraestructura de forma automatizada. Estas herramientas definen declarativamente el estado deseado de las implementaciones mediante plantillas JSON o YAML y, en el caso de Google Deployment Manager, también permiten usar Jinja y Python.

Amazon Cloud Development Kit (CDK)Lanzado en 2019, Amazon Cloud Development Kit (CDK) permite a los desarrolladores definir implementaciones en lenguajes de programación de alto nivel, como JavaScript, Python o C# (consulta la lista completa de lenguajes aquí). Además de ofrecer una sintaxis más familiar, permite integrarse con IDE y empaquetar patrones en bibliotecas reutilizables y estructuras de código probadas, en lugar de depender de copiar y pegar archivos JSON/YAML entre proyectos. El resultado de CDK es JSON de CloudFormation, así que Amazon ofrece un entorno orientado a los desarrolladores que sigue aprovechando sus herramientas de orquestación de infraestructura CloudFormation, probadas en el tiempo.

Soluciones para varias nubes

HashiCorp TerraformTerraform ofrece una herramienta de aprovisionamiento automatizado que permite aprovisionar y configurar una amplia variedad de plataformas y productos mediante complementos de proveedores.

PulumiPulumi es un proyecto de IaC de código abierto que ofrece SDK en varios lenguajes de programación para aprovisionar y administrar recursos en numerosas plataformas.

Problemas a los que debes prestar atención y ejemplos de análisis

Independientemente del proveedor de nube o la herramienta de IaC que elijas, hay algunas áreas comunes en las que debes enfocarte desde el punto de vista de la seguridad. Veamos algunas, junto con ejemplos de Terraform y AWS. Todos estos ejemplos están en este repositorio de GitHub. También incluyo algunas capturas de pantalla que muestran cómo la herramienta de análisis Snyk IaC presenta los posibles problemas detectados.

Credenciales

En el directorio de nivel superior de nuestro repositorio de Git, hay un archivo main.tf donde vemos varios problemas comunes. El análisis de Snyk reporta un problema de gravedad alta y cinco de gravedad media, como se muestra a continuación.

En primer lugar, nunca debes incluir credenciales de ningún tipo en el control de versiones. Parece un consejo obvio, pero los foros de Internet están llenos de ejemplos de repositorios de código que las contienen, ¡muchos de ellos públicos! Por desgracia, muchos de estos ejemplos solo se descubrieron después de que alguien los aprovechara. A menudo, esto ocurre cuando un usuario descuidado hace un commit por accidente. Una forma más insidiosa de que esto suceda es incluir una credencial en un commit y eliminarla en uno posterior: el desarrollador quizá no lo note, pero la credencial permanece en el historial del repositorio. Hay técnicas para intentar detectar este problema, como usar archivos .gitignore o scripts de hooks de pre-commit; por ejemplo, “git-secrets” de AWS Labs.

También vemos varios hallazgos relacionados con las contraseñas de las cuentas de IAM. Es importante tener en cuenta que hay una política por cada cuenta de AWS y que, si configuras una, reemplazarás la política predeterminada que proporciona Amazon. Por eso, asegúrate de especificar todas estas opciones.

Cifrado de servicios de almacenamiento

El cifrado está habilitado de forma predeterminada en los volúmenes de EBS, pero no en los buckets de S3. Es importante verificar ambos para garantizar el cumplimiento de las políticas de tu empresa y de las pautas de los organismos reguladores. En nuestro repositorio de demostración, declaramos un par de recursos de almacenamiento en el archivo modules/storage/main.tf, que puedes ver en el análisis a continuación:

Aquí vemos ejemplos de ambas infracciones marcadas, además de una advertencia de prioridad baja sobre la falta de registros de acceso al servidor de S3. Si revisamos una de ellas en detalle, veremos información sobre el problema y su impacto, además de una recomendación para resolverlo.

La clasificación de gravedad alta, media o baja de cada política se puede cambiar para ajustarla a las políticas de tu organización.

Rangos de entrada y salida de los grupos de seguridad y los firewalls

Al revisar el archivo modules/vpc/main.tf, encontramos otro problema común: el acceso de entrada está configurado de forma más amplia de lo que probablemente se pretendía.

Al igual que ocurre con las credenciales codificadas, esto suele configurarse durante el desarrollo o la resolución de problemas y se incluye por accidente en el control de versiones junto con otros cambios. En este ejemplo, es muy poco probable que alguien quiera abrir el puerto 22 a todo Internet, que es lo que podría estar ocurriendo. Es fundamental restringir el tráfico que entra y sale de tus redes y permitirlo solo desde los rangos de IP que realmente lo necesitan.

Rotación de claves

Para nuestro último ejemplo, tenemos el archivo modules/pki/main.tf, donde se configura una clave sin rotación.

Este es otro caso en el que el comportamiento predeterminado no suele ser el más adecuado desde el punto de vista del fortalecimiento de la seguridad. Por supuesto, esta recomendación supone que tu organización no tiene un proceso aparte para rotar claves. Pero, si usas el servicio de administración de claves del proveedor de nube, es muy probable que la mejor opción sea dejar que se encargue de estas tareas.

¿Qué tan seguras son tus iniciativas de IaC?

Ahora que viste algunos ejemplos de problemas que pueden colarse con facilidad en el código de IaC, ¿qué tan seguro estás de que el tuyo está protegido? Recuerda: la seguridad no debe ser algo que se considere al final. Puedes ejecutar estas mismas verificaciones, además de otras para distintos proveedores de nube y Kubernetes, en tu repositorio ahora mismo y de forma gratuita, para detectar problemas antes de que se implementen o se aprovechen.

Crea una cuenta gratuita de Snyk y sigue las instrucciones para crear un proyecto a partir de tu repositorio. En cuestión de minutos, recibirás recomendaciones prácticas para resolver cualquier problema que detecte.