Las mejoras del análisis de Snyk IaC incluyen infraestructura como código para Azure y AWS

Hace poco escribí sobre la infraestructura como código (IaC) y sobre cómo el análisis de Snyk IaC puede ayudar a detectar problemas en tus plantillas antes de que lleguen al aprovisionamiento. Nuestro equipo de ingeniería sigue ampliando la cobertura de las políticas de análisis de IaC para proteger mejor tus plataformas contra vulnerabilidades y otros problemas.

En esta publicación, revisaremos la herramienta de análisis de IaC, conoceremos las últimas incorporaciones —como infraestructura como código para Azure, GCP y AWS— y veremos cómo tus equipos pueden integrarla activamente en las iniciativas de DevSecOps de tu empresa.

¿Por qué debería analizar la IaC?

Las plantillas de IaC contienen el estado declarativo que quieres que tengan tus aplicaciones en los distintos entornos de implementación. Me gusta pensar en ellas —junto con otros artefactos como los Dockerfiles— como manuales de operaciones automatizados que recopilan todo el conocimiento tácito y los procedimientos asociados con las implementaciones manuales, y los convierten en pasos estandarizados y repetibles que se pueden revisar y probar antes de ejecutarlos. También te permiten aplicar principios del desarrollo de software, como las revisiones y aprobaciones de código, a tu código de infraestructura. Las herramientas de análisis de Snyk realizan una revisión automatizada que compara tus plantillas de IaC con nuestro conjunto seleccionado de políticas y prácticas recomendadas. El resultado es un informe con los problemas detectados, descripciones detalladas y recomendaciones para corregirlos.

La mayoría de los problemas relacionados con IaC no son «vulnerabilidades», al menos no en el sentido clásico de la palabra. En general, quienes usan IaC no se preocupan por que una vulnerabilidad de día cero afecte de repente sus definiciones de IaC; más bien, se centran en cumplir las políticas y los estándares definidos por los equipos de seguridad y arquitectura. En la práctica, esto significa que normalmente queremos probar el código a medida que se modifica, algo que encaja bien con el patrón de ejecutar pruebas en los pipelines cuando se envía un cambio o se crea un pull request.

Sin embargo, Kubernetes puede echar por tierra hasta los mejores planes. Por ejemplo, la vulnerabilidad de ataque de intermediario del servicio de Kubernetes podía explotarse en todas las versiones de Kubernetes. Se identificó como CVE-2020-8554 y se divulgó públicamente el 8 de diciembre de 2020. Mientras escribo esta publicación, todavía no existe un parche para esta vulnerabilidad. Para quienes tenían habilitado el monitoreo de Snyk IaC, se agregó rápidamente una política actualizada y empezaron a recibir alertas automáticamente como parte de la función de análisis continuo de Snyk para GitHub, aunque no hubieran iniciado un análisis por su cuenta.

El informe de problemas del análisis de Snyk IaC muestra un riesgo potencial de CVE-2020-8554.

Si recién estás conociendo IaC y quieres saber cómo funciona el análisis de Snyk, consulta esta publicación sobre herramientas de infraestructura como código para profundizar en el tema.

Novedades en el análisis de seguridad de infraestructura como código

Al principio, Snyk IaC analizaba problemas en Kubernetes, Helm Charts y recursos de AWS para Terraform. Desde su lanzamiento inicial, los ingenieros de Snyk han agregado políticas continuamente para ampliar la cobertura del análisis. Entre las mejoras incorporadas recientemente se incluyen:

Infraestructura como código de AWS para Terraform

Más de 100 políticas que cubren áreas como:

• Control de acceso y registro de S3

• Diversas comprobaciones relacionadas con datos confidenciales (por ejemplo, secretos codificados de forma fija y configuraciones débiles) en Lambda, EC2 y EKS

• Detección de la falta de cifrado en reposo en distintos servicios

• Malas prácticas de privilegios de IAM

Infraestructura como código de Azure para Terraform

Ahora también es compatible con Azure, con cobertura que incluye:

• Prácticas recomendadas de registro

• Prácticas recomendadas para servicios de aplicaciones

• MYSQL: problemas relacionados con SSL y las alertas

• Diversos problemas de PostgresSQL, entre ellos:

  • SSL

  • Limitación de conexiones

  • Registro

• Problemas de acceso y cifrado de cuentas de almacenamiento

Google Cloud Platform (GCP)

También se agregaron recursos de GCP, entre ellos:

• Asignación de usuarios de IAM

• Problemas relacionados con Kubernetes en GCP

Kubernetes

La cobertura para los recursos de Kubernetes y Helm sigue ampliándose con nuevas políticas. Más específicamente:

• Comprobaciones de contenedores, entre ellas:

  • Puerto SSH expuesto

  • Montajes de dispositivos del host

  • Falta de comprobaciones de disponibilidad

  • etc.

• Servicios con IP externa (el análisis de CVE-2020-8554 mencionado anteriormente)

• Comprobaciones de PSP, como:

  • Montaje de volúmenes con permisos excesivos

  • Seccomp

  • Problemas de AppArmor

  • Permitir el GID raíz en los procesos de contenedor

Analizar tu propio código de IaC es fácil

En Snyk, nos enorgullece hacer que la seguridad sea fácil de usar. Creemos que, al brindarles a los desarrolladores herramientas que se adapten a sus flujos de trabajo, podemos ayudarlos a marcar una diferencia activa y eliminar vulnerabilidades y problemas de seguridad desde el origen.

Puedes empezar a analizar tus plantillas de IaC de inmediato creando una cuenta gratuita en Snyk.io.

Para conocer más sobre las novedades de Snyk de este año, no te pierdas el artículo que mis colegas Jim Armstrong y Daniel Berman publicaron hace poco. En él repasan todas las funciones y los anuncios de Snyk para Cloud Native durante 2020.

¡Hagamos que 2021 sea el año más seguro hasta ahora!