La infraestructura como código (IaC) se ha convertido rápidamente en un elemento revolucionario del panorama tecnológico moderno. Al traducir los procesos de aprovisionamiento y gestión de la infraestructura en código, los desarrolladores obtienen control de versiones y repetibilidad, y se reducen las posibles vulnerabilidades, pero su proliferación conlleva posibles problemas de vulnerabilidad.
GitLab IaC Scanning destaca como un medio eficaz y eficiente para descubrir configuraciones erróneas y brechas de seguridad en las configuraciones de IaC, al tiempo que protege contra ellas. Esta guía profundizará en su valor, el proceso de configuración y las mejores prácticas para fortalecer las configuraciones de IaC.
¿Qué es la infraestructura como código (IaC)?
La infraestructura como código (IaC) es un enfoque en el que las tareas de aprovisionamiento, gestión y configuración de la infraestructura se especifican como código en lugar de mediante procesos manuales o scripts personalizados. En lugar de depender de procesos manuales para aprovisionar servidores, bases de datos o componentes de infraestructura de red, IaC utiliza plantillas de código estándar.
La popularidad de IaC se explica por la necesidad cada vez mayor de agilidad a la hora de implementar y escalar aplicaciones. La gestión tradicional de la infraestructura requería una configuración que consumía mucho tiempo y que a menudo dependía del error humano; IaC ofrece consistencia, repetibilidad y procesos de actualización rápidos mediante el control de versiones de la infraestructura, al igual que el código de software, lo que permite que las construcciones de infraestructura repetibles y versionadas se ejecuten continuamente sin supervisión humana ni errores.
Las prácticas de DevOps también se complementan bien con las prácticas de IaC, lo que ayuda a las organizaciones a salvar la brecha entre el desarrollo y las operaciones. Con IaC, los cambios en la infraestructura se pueden implementar simultáneamente con el desarrollo de aplicaciones para acelerar los tiempos de implementación y facilitar la gestión del proceso. Sus esfuerzos combinados impulsan a las organizaciones hacia una mayor eficiencia y fiabilidad durante los procesos de implementación.
¿Por qué es esencial el escaneo de IaC?
La infraestructura como código ha abierto nuevas vías de vulnerabilidad potencial. Los desarrolladores que escriben scripts para automatizar la implementación de la infraestructura pueden introducir inadvertidamente importantes brechas de seguridad en el proceso de implementación de la infraestructura; El escaneo de IaC se vuelve esencial para detectar estos agujeros de seguridad antes de que lleguen a los entornos de producción.
Las infraestructuras nativas de la nube modernas pueden ser entornos bastante dinámicos y complejos; las configuraciones erróneas pueden pasar desapercibidas incluso para los desarrolladores más vigilantes, incluso sin herramientas de escaneo de IaC que examinen las definiciones del código para detectar configuraciones erróneas que violen las mejores prácticas de seguridad y reduzcan las violaciones de datos y el compromiso del sistema debido a vulnerabilidades de la infraestructura. Las herramientas de análisis de IaC utilizan tecnología de inteligencia artificial como consumo (AIC). De este modo, reducen drásticamente los riesgos relacionados con las vulnerabilidades de la infraestructura que provocan violaciones de datos o comprometen el sistema.
A medida que se han endurecido las normas de cumplimiento y protección de datos, las empresas necesitan implementar una infraestructura segura desde el primer día para evitar repercusiones legales o reputacionales. El escaneo de IaC ayuda a las empresas a cumplir con esta norma al garantizar que su infraestructura se ajuste a las regulaciones de la industria, protegiéndolas así contra repercusiones legales.
Comprender el escaneo de IaC de GitLab
La función de escaneo de Infraestructura como Código (IaC) de GitLabLa función de escaneo de infraestructura como código (IaC) de GitLab ofrece un enfoque sistemático para examinar los archivos de configuración de IaC en busca de posibles vulnerabilidades. Esto garantiza que las configuraciones para aprovisionar y gestionar la infraestructura sean robustas, seguras y conformes. La compatibilidad se extiende a varios archivos de configuración de IaC, incluidos los más populares como Terraform, Ansible, AWS CloudFormation y Kubernetes.
- Requisitos y compatibilidad
- Archivos compatibles y personalización
- Personalización de la configuración y las reglas
- Resolución automática de vulnerabilidades
1. Requisitos y compatibilidad
El escaneo eficaz de El escaneo IaC requiere trabajar dentro de la etapa de prueba, ya que debe incluirse en el archivo .gitlab-ci.yml de esta etapa.
- Los requisitos mínimos de RAM deben ser de 4 GB para maximizar el rendimiento.
- De forma predeterminada, GitLab Runner con el ejecutor Docker o Kubernetes es obligatorio (y se habilita automáticamente para los usuarios de GitLab.com). Sin embargo, los analizadores de escaneo de IaC pueden ser incompatibles con arquitecturas de CPU que no sean amd64, por lo que se recomienda evitar la versión 19.03.0 de Docker para estos trabajos.
2. Archivos compatibles y personalización
El escaneo IaC de GitLab proporciona una compatibilidad completa, gracias a la herramienta KICS. Entre los archivos de configuración compatibles se encuentran los de Ansible, AWS CloudFormation, Azure Resource Manager Dockerfile, Google Deployment Manager Kubernetes OpenAPI Terraform; al revisar los resultados, también deben tenerse en cuenta los requisitos específicos, como la necesidad de plantillas de Azure Resource Manager con formato JSON y la falta de compatibilidad con los módulos Terraform de registro personalizados.
GitLab continúa su compromiso con la apertura con esta función, al poner a disposición todos los analizadores de código abierto (OSS) a través del nivel GitLab Free. Al manipular la variable SAST_IMAGE_SUFFIX, puede alternar entre las versiones estándar y FIPS de las imágenes.
3. Configuración y personalización de reglas
Establecer IaC Scanning en su proyecto es relativamente sencillo. Puede configurarlo manualmente incluyendo la plantilla SAST-IaC.gitlab-ci.yml, que, una vez incluida, genera trabajos de IaC Scanning dentro de su canalización CI/CD, o automáticamente a través de solicitudes de fusión, cuyos resultados se almacenan como artefactos de informes SAST una vez completado el escaneo.
Los equipos que deseen mejorar el proceso de escaneo tienen la opción de personalizar las reglas predeterminadas; esta función incluye la posibilidad de:
- Desactivar reglas predefinidas.
- Anular las existentes con definiciones personalizadas que afectan a aspectos como la gravedad o la vinculación directa a la documentación personal.
También es posible asociar los procesos de escaneo con versiones específicas del analizador, lo que protege en caso de que las actualizaciones traigan consigo regresiones o modificaciones no deseadas.
4. Resolución automática de vulnerabilidades
El escaneo IaC de GitLab hace hincapié en eliminar el ruido innecesario en los informes. Para mantener la relevancia y centrarse en las vulnerabilidades actuales, el sistema realiza ciertas acciones automáticas:
1. Desactivación de reglas: una vez que decida que una o varias reglas ya no son relevantes para su proyecto y las haya desactivado explícitamente, sus informes anteriores de vulnerabilidades se resolverán automáticamente.
2. Eliminación de reglas: si GitLab decide que una o varias reglas predeterminadas son obsoletas o producen demasiados falsos positivos, es probable que se eliminen, y cualquier vulnerabilidad señalada por dichas reglas se resolverá automáticamente.
3. Registros históricos: Es fundamental mantener un registro de auditoría; el sistema de gestión de vulnerabilidades de GitLab añade comentarios, lo que garantiza que usted siga al tanto de las vulnerabilidades pasadas que se han automatizado y resuelto.
4. Reactivación de reglas: Al reactivar las reglas que se habían desactivado anteriormente, se volverán a abrir los hallazgos resueltos automáticamente para su clasificación, con el fin de garantizar que las vulnerabilidades pasadas no pasen desapercibidas.
Informes: comprender el formato JSON
La herramienta de análisis IaC de GitLab genera sus hallazgos en forma de informes JSON estructurados que se ajustan a los formatos de informe SAST, lo que proporciona a los usuarios resultados completos:
1. Estandarización: este formato facilita la integración y la comparación entre varios proyectos o análisis.
2. Accesibilidad: Los usuarios pueden descargar rápida y fácilmente los informes directamente desde las páginas de los canales de CI o fusionar los canales de solicitud utilizando la directiva artifacts: paths con “gl-sast-report.json”. Para facilitar esta acción, establezca su directiva artifacts: paths como "gl-sast-report.json".
3. Referencia del esquema: GitLab ofrece documentación detallada sobre el esquema para que aquellos interesados en profundizar o integrar este informe con otros sistemas puedan acceder a todas sus partes de forma fácil y completa.
Configuración del escaneo IaC de GitLab
Veamos cómo configurar el escaneo IaC de GitLab para tus proyectos.
Los pasos para configurar GitLab IaC Scanning son los siguientes:
- Requisitos previos
- Integración de GitLab CI/CD
- Configuración personalizada (opcional)
- Ejecutar el escaneo
- Revisar los resultados
1. Requisitos previos
- Versión de GitLab: Debes asegurarte de que estás utilizando la versión 12.10 o posterior de GitLab.
- Configuración del repositorio: tus archivos de infraestructura como código (como Terraform, CloudFormation y los archivos de configuración de Kubernetes) deben formar parte de tu repositorio.
2. Integración de GitLab CI/CD
Para configurar el escaneo de IaC, deberá integrarlo con el pipeline de GitLab CI/CD.
Cree o actualice .gitlab-ci.yml en la raíz de su repositorio.
Añade la siguiente configuración:
Incluir:
plantilla: Security/Infrastructure-Scanning.gitlab-ci.yml
Esta inclusión habilitará el trabajo de escaneo de IaC dentro de tu canalización CI/CD.
3. Configuración personalizada (opcional)
Para proyectos con requisitos específicos, el proceso de escaneo se puede personalizar:
- Reglas personalizadas: GitLab IaC Scanning permite a los usuarios definir reglas personalizadas o modificar las existentes. Estas se pueden añadir al directorio .iac-custom-rules en la raíz de su repositorio.
- Ignorar directorios: Si desea que el escáner omita determinados directorios, puede definirlos en la configuración de CI/CD en variables:
Variables:
IAC_PATHS: –infrastructure/*,!infrastructure/legacy/–
En el ejemplo anterior, el escáner solo analizará los archivos del directorio infrastructure y excluirá el subdirectorio legacy.
4. Ejecución del análisis
Una vez configurada, inicie una ejecución del proceso CI/CD. La tarea de análisis de IaC analizará sus archivos de infraestructura como código y proporcionará información sobre posibles vulnerabilidades.
5. Revisión de los resultados
Tras el análisis, se mostrarán las vulnerabilidades (si las hay):
- Dentro de la solicitud de fusión (si el análisis se ha activado por una).
- En la sección Seguridad y cumplimiento de su proyecto.
Aquí puede:
- Ver los detalles de la vulnerabilidad.
- Marcarla como resuelta o crear un problema para realizar su seguimiento.
- Opcionalmente, configurar acciones automatizadas basadas en la gravedad o el tipo de vulnerabilidad.
Prácticas recomendadas para una configuración segura de IaC (Infraestructura como código)
Las mejores prácticas para una configuración segura de IaC (Infraestructura como código) son –
- Principio PoLP (principio del privilegio mínimo)
- Mantener el control de versiones y el seguimiento de cambios
- Escanear y actualizar periódicamente las dependencias
- Proteger los secretos
- Validar y evaluar configuraciones de manera eficiente
1. Principio PoLP (principio del mínimo privilegio)
El principio del mínimo privilegio es un concepto de seguridad esencial diseñado para garantizar que las entidades (ya sean usuarios, sistemas o procesos) reciban solo los privilegios necesarios para realizar sus tareas y nada más. Este principio se vuelve aún más esencial en entornos IaC con permisos que se pueden asignar mediante programación; cuando se otorgan de forma incorrecta o demasiado amplia, podrían exponer los recursos a riesgos innecesarios.
El cumplimiento de los requisitos del PoLP dentro de IaC requiere una cuidadosa programación de los permisos, de modo que cada servicio o función solo acceda a los recursos que necesita. En el caso de infraestructuras en la nube como AWS, esto podría implicar otorgar permisos de solo lectura para el bucket S3 en lugar de permisos generales para todos los recursos de almacenamiento. revisar continuamente los scripts de IaC para garantizar que los permisos sigan siendo estrictos a medida que evoluciona la infraestructura.
2. Mantener el control de versiones y el seguimiento de cambios
El control de versiones no solo es necesario en el desarrollo de software tradicional, sino que también desempeña un papel esencial en la gestión de la infraestructura en un entorno IaC. El seguimiento de los cambios, la reversión de configuraciones y la comprensión de los ajustes de la infraestructura son fundamentales para mantener un entorno seguro y estable para la gestión de la infraestructura IaC.
Las plataformas GitLab y GitHub para la configuración de IaC no solo proporcionan herramientas de seguimiento de cambios, sino también funciones colaborativas para revisar las modificaciones propuestas con los miembros del equipo antes de implementarlas en entornos de producción. Este proceso de revisión por pares garantiza que se tengan en cuenta las cuestiones de seguridad y se cumplan las mejores prácticas antes de introducir modificaciones significativas en los entornos IaC.
3. Escaneo y actualización periódicos de las dependencias
Al igual que en el desarrollo de software, las configuraciones de infraestructura como código (IaC) suelen depender de plantillas y módulos de terceros para optimizar la implementación de la infraestructura; aunque estas dependencias pueden simplificar la implementación, también presentan posibles vulnerabilidades si están obsoletas o comprometidas.
El análisis constante de las dependencias ayuda a garantizar que no se introduzcan vulnerabilidades de seguridad conocidas en la infraestructura, con herramientas especiales diseñadas para esta tarea que marcan automáticamente los módulos obsoletos o vulnerables y solicitan a los equipos que los actualicen según sea necesario, de forma muy similar a la gestión de parches de softwarepatch management, pero aplicada específicamente a los módulos de infraestructura con el fin de lograr la máxima protección y resiliencia.
4. Proteger los secretos
El panorama digital está plagado de historias de advertencia sobre secretos que se han visto expuestos y que han dado lugar a graves violaciones de la seguridad. La naturaleza programática de IaC hace que los programadores se sientan tentados a codificar información confidencial directamente en los scripts, una práctica irresponsable que siempre debe evitarse.
Las organizaciones deben evitar incrustar secretos directamente en los scripts de IaC y, en su lugar, emplear soluciones de gestión de secretos específicas, como HashiCorp Vault o AWS Secrets Manager, para proteger los secretos mientras permanecen cifrados, garantizando así su protección incluso si los archivos de configuración se exponen públicamente.
5. Validar y evaluar eficazmente las configuraciones
Garantizar que los scripts de IaC sean funcionales y seguros es un esfuerzo constante que exige una evaluación periódica. A medida que cambian las configuraciones o el panorama de TI, surgen nuevas vulnerabilidades que podrían hacer que los scripts que antes funcionaban dejen de hacerlo o que se rompan por completo.
Las organizaciones deben asegurarse de que sus configuraciones de IaC se ajustan regularmente a los estándares y las mejores prácticas del sector para evitar esta situación, utilizando herramientas de prueba automatizadas para realizar comprobaciones periódicas sin intervención manual. Antes de implementar cualquier cambio en los entornos de producción, los entornos de prueba o de ensayo son muy valiosos para alertar de forma temprana sobre cualquier problema inesperado, lo que ayuda a garantizar infraestructuras seguras y operativas en los entornos de producción.
Errores comunes en IaC y cómo evitarlos
¿Errores comunes en el escaneo de IaC de GitLab y cómo evitarlos?
- Tratar el código de infraestructura como un script único
- Descuido de las pruebas
- Codificación fija de secretos y credenciales
- Complejidad excesiva de los scripts de IaC
- Omisión de herramientas o bibliotecas obsoletas
1. Tratar el código de infraestructura como un script único
Una idea errónea muy extendida sobre el código de infraestructura (IaC) es tratarlo como cualquier script único que se escribe una vez y rara vez se revisa. Sin embargo, a diferencia de los scripts únicos, el IaC requiere actualizaciones de mantenimiento periódicas, revisiones y modificaciones, como cualquier código de software.
Cómo prevenirlo: Realice revisiones y actualizaciones periódicas del código utilizando herramientas como GitLab IaC Scanning para escanear continuamente las configuraciones de IaC, lo que garantiza que su código se mantenga actualizado, relevante y libre de posibles vulnerabilidades.
2. Descuido de las pruebas
Algunos equipos que se apresuran a implementar pueden omitir las pruebas exhaustivas de scripts de IaC en favor de avanzar rápidamente, creyendo que si algo funciona, todo está bien, lo que puede dar lugar a comportamientos inesperados o vulnerabilidades de seguridad en su infraestructura aprovisionada. Este descuido puede dejar comportamientos inesperados sin explicar o crear agujeros de seguridad que requieran parches inmediatos tras la implementación.
Cómo prevenirlo: al igual que con el código de las aplicaciones, es esencial probar las configuraciones de IaC en entornos que no sean de producción, como los de ensayo, para evitar configuraciones erróneas y posibles problemas en el entorno de producción. GitLab IaC Scanning proporciona un servicio esencial que permite a los equipos identificar cualquier configuración errónea antes de que afecte directamente a los entornos de producción.
3. Codificación dura de secretos y credenciales
El hardcoding puede ser un problema evidente en los scripts de IaC y siempre debe evitarse para proteger la seguridad de los datos. Al incrustar secretos o credenciales directamente en su código, los secretos o credenciales hardcoded pueden suponer amenazas de seguridad importantes que no deben descuidarse.
Cómo prevenirlo: en lugar de incluir secretos directamente en los scripts, utilice herramientas específicas para la gestión de secretos. Las herramientas de análisis de IaC de GitLab pueden detectar estas prácticas mediante su análisis como parte de su proceso de escaneo, por ejemplo, alertando a los desarrolladores sobre cualquier credencial codificada en sus archivos de configuración.
4. Scripts de IaC excesivamente complicados
Al intentar crear una solución que cubra todos los escenarios posibles, algunos ingenieros complican demasiado la redacción de los scripts de IaC. Si bien esto puede cubrir diversas situaciones de manera más eficiente, también crea complicaciones innecesarias y posibles puntos de fallo en sus soluciones de IaC.
Cómo evitarlo: priorice la simplicidad y la claridad dividiendo las configuraciones complejas en módulos manejables utilizando GitLab IaC Scanning; inspeccione regularmente estos módulos utilizando GitLab IaC Scanning para que sigan siendo eficaces, seguros y funcionales.
5. Evitar herramientas o bibliotecas obsoletas
suele depender de herramientas o bibliotecas terceros; sin embargo, a medida que estos recursos externos se desarrollan, pueden dejar utilizar ciertas características funciones. el uso métodos obsoletos podría presentar vulnerabilidades tanto funcionales como seguridad.
cómo prevenirlo: vigile activamente las terceros dependen sus configuraciones iac, actualice periódicamente los scripts para reflejar versiones y recomendaciones actualizadas, utilice análisis gitlab iac scanning, resaltan funciones dependencias obsoletas.< p>
Vea SentinelOne en acción
Descubra cómo la seguridad en la nube basada en IA puede proteger su organización en una demostración individual con un experto en productos SentinelOne.
DemostraciónConclusión
Preguntas frecuentes sobre el escaneo de IaC de GitLab
El escaneo IaC de GitLab es una función CI/CD integrada que examina tus archivos de infraestructura como código, como Terraform, CloudFormation, Ansible, Dockerfiles y manifiestos de Kubernetes, en busca de configuraciones incorrectas y vulnerabilidades conocidas. Se ejecuta durante la fase de prueba de tu canalización, genera informes SAST en formato JSON y destaca los problemas en las solicitudes de fusión para que puedas corregir las configuraciones riskantes antes de la implementación.
El escaneo de IaC debutó en GitLab 14.5, lanzado en junio de 2021. A partir de esa versión, cualquier archivo de configuración de IaC compatible en un proyecto activa automáticamente los analizadores basados en KICS adecuados durante los procesos de CI, siempre que se incluya la plantilla de IaC en .gitlab-ci.yml
El escaneo IaC de GitLab admite una amplia gama de archivos de configuración, todos ellos impulsados por KICS:
- Playbooks de Ansible
- AWS CloudFormation (YAML/JSON)
- Azure Resource Manager (JSON)
- Archivos Docker
- Google Deployment Manager
- Manifiestos de Kubernetes
- Definiciones de OpenAPI
Terraform HCLSi utiliza Bicep, compile en JSON antes de escanear y tenga en cuenta que los módulos Terraform del registro personalizado aún no se escanean .
Todos los analizadores de escaneo IaC en GitLab se basan en KICS (Keep It Configuration Scanner), un motor de código abierto que comprueba tus archivos IaC con un amplio conjunto de reglas. KICS detecta automáticamente los formatos compatibles y aplica las comprobaciones adecuadas, y usted puede personalizar, desactivar o fijar versiones de reglas mediante variables de CI o directorios de reglas personalizados.
Para habilitar el escaneo IaC, añade la plantilla oficial al archivo .gitlab-ci.yml de tu proyecto en la parte superior:
añade la línea:
- template: Jobs/SAST-IaC.gitlab-ci.yml
Esto inyecta un trabajo iacs en la fase de prueba. En GitLab.com o autogestionado con corredores compartidos, no se necesita ninguna configuración adicional del corredor. Después de que se ejecute un pipeline, los resultados del escaneo aparecen como artefactos de trabajo, en las solicitudes de fusión y en Seguridad y cumplimiento .
