Escaneo IaC: una oportunidad de aprendizaje fantástica y pasada por alto

Todo lo que lee sobre la infraestructura como código (IaC) se centra en cómo funciona o en por qué quiere asegurarse de que realmente se esté construyendo de la manera que usted desea.

Estas son áreas críticas. Pero, ¿estamos pensando lo suficiente en cómo utilizamos este enfoque en nuestra organización?

As Melinda Marcas de ESG afirma en un informe de la empresa que “el 83% de las organizaciones experimentaron un aumento en las configuraciones erróneas de las plantillas de IaC” a medida que continúan adoptando la tecnología.

Sabemos por el trabajo realizado por Cloud Security Alliance (“Principales amenazas a la computación en la nube: Egregious Eleven“) y otros, las configuraciones erróneas siguen siendo un riesgo importante en la nube.

IaC cuenta con apoyo para reducir
configuraciones erróneas al sistematizar la creación de infraestructura, agregando un nivel de rigor y proceso que garantice que los equipos estén construyendo lo que quieren y solo lo que quieren. Si ~83% de los equipos no ven eso, hay un problema más profundo en juego.

En equipos más pequeños, uno donde las partes de desarrollo y operaciones de la filosofía DevOps están juntas, eso tiene sentido. IaC permite a estos pequeños equipos utilizar el mismo lenguaje (código) para describir todo lo que están haciendo.

Es por eso que estamos viendo abstracciones de nivel aún más alto que herramientas como Terraform o AWS CloudFormation en el CDK de AWS y proyectos como cdk8s. Esas abstracciones de alto nivel son más cómodas para los desarrolladores.

La perspectiva de operaciones/SRE/plataforma de un servicio en la nube será muy diferente desde la perspectiva del desarrollador del mismo servicio. Un desarrollador observará un servicio de cola y se sumergirá en su interfaz: ¿un punto final simple para agregar y otro para leer? Vendido. Esa es una integración fácil.

Esta perspectiva operativa apunta a encontrar los bordes. Entonces, ¿cuándo llega esta cola a su límite? ¿El rendimiento es constante o cambia radicalmente bajo carga?

Sí, hay preocupaciones superpuestas. Y sí, esta es una vista simplificada. Pero la idea se mantiene. IaC resuelve muchos problemas, pero también puede crear y amplificar la desconexión entre equipos. Más importante aún, puede resaltar la brecha entre la intención de lo que intentas construir y la realidad de lo que has construido.

Como resultado, aquí es donde a menudo aumentan las preocupaciones sobre la seguridad.

La mayoría de las herramientas (comerciales o de código abierto) se centran en identificar los errores de las plantillas de infraestructura. Este
es una buena construcción. Haciendo así
Sería malo. Estas herramientas tienen como objetivo generar estos resultados como parte del proceso de integración continua/entrega continua (CI/CD).

Ese es un gran comienzo. Pero se hace eco del mismo problema lingüístico.

¿Quién habla y quién escucha?

Cuando una herramienta de IaC resalta un problema, ¿quién lo abordará? Si se trata del equipo de desarrollo, ¿tiene suficiente información para saber por qué se marcó esto como un problema? Si se trata del equipo de operaciones, ¿se establecen las consecuencias del problema en el informe?

Para los desarrolladores, lo que sucede a menudo es que simplemente ajustarán la configuración para que pase la prueba de IaC.

Para las operaciones, normalmente es una cuestión de si las pruebas están pasando. Si es así, pasemos a la siguiente tarea. Eso no es un golpe para ninguno de los equipos; más bien, resalta la brecha entre las expectativas y la realidad.

Lo que se necesita es contexto. Las herramientas de seguridad de IaC brindan visibilidad de lo que (con suerte) está a punto de construirse. El objetivo es detener los problemas. antes entran en producción.

Las herramientas de seguridad de IaC actuales resaltan problemas reales que deben abordarse. Tomar el resultado de estas herramientas y enriquecerlo con contexto adicional que sea específico del equipo responsable del código es una oportunidad perfecta para una automatización personalizada.

Esto también ayudará a cerrar la brecha lingüística. El resultado de sus herramientas está esencialmente en un tercer idioma (solo para complicar más las cosas) y debe comunicarse de una manera que tenga sentido para una audiencia de desarrollo o de operaciones. A menudo ambas cosas.

Por ejemplo, cuando un análisis indica que una regla de grupo de seguridad no tiene una descripción, ¿por qué importa eso? El simple hecho de recibir una alerta que diga "Agregar una descripción para el contexto" no ayuda a nadie a construir mejor.

Este tipo de bandera es una gran oportunidad para educar a los equipos que están construyendo en la nube. Agregar una explicación de que las reglas del grupo de seguridad deben ser lo más específicas posible reduce la posibilidad de ataques maliciosos. Proporcione referencias a ejemplos de reglas estrictas. Diga eso sin conocer la intención y otros equipos no podrán probar la validez de la confirmación de seguridad.

La seguridad es responsabilidad de todos, por lo que reconocer la brecha lingüística entre los desarrolladores y las operaciones resaltará oportunidades como esta para agregar automatizaciones simples que brinden información a sus equipos. Esto ayudará a mejorar lo que están construyendo y, como resultado, generará mejores resultados de seguridad.

Sobre la autora

Soy un científico forense, orador y analista de tecnología que intento ayudarle a entender el mundo digital y su impacto en nosotros. Para los usuarios cotidianos, mi trabajo ayuda a explicar cuáles son los desafíos del mundo digital. ¿Qué impacto tiene el uso de las redes sociales en su privacidad? ¿Qué significa que tecnologías como el reconocimiento facial comiencen a utilizarse en nuestras comunidades? Ayudo a responder preguntas como esta y más. Para las personas que crean tecnología, les ayudo a aplicar una lente de seguridad y privacidad a su trabajo, para que puedan permitir a los usuarios tomar decisiones más claras sobre su información y comportamiento. Existe una montaña de confusión en lo que respecta a la privacidad y la seguridad. No debería haberlo. Hago que la seguridad y la privacidad sean más fáciles de entender.