Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Implemente un escaneo Checkov personalizado y centralizado para aplicar la política antes de implementar AWS la infraestructura
Benjamin Morris, Amazon Web Services
Resumen
Este patrón proporciona un marco de GitHub acciones para escribir políticas de Checkov personalizadas en un repositorio que se pueden reutilizar en toda la organización. GitHub Al seguir este patrón, un equipo de seguridad de la información puede escribir, agregar y mantener políticas personalizadas según los requisitos de la empresa. Las políticas personalizadas se pueden incorporar automáticamente a todos los procesos de la GitHub organización. Este enfoque se puede utilizar para hacer cumplir los estándares de la empresa en relación con los recursos antes de que estos se implementen.
Requisitos previos y limitaciones
Requisitos previos
Un activo Cuenta de AWS
Una GitHub organización que usa GitHub Actions
AWS infraestructura implementada con HashiCorp Terraform o AWS CloudFormation
Limitaciones
Este patrón está escrito para GitHub Actions. Sin embargo, se puede adaptar a marcos similares de integración continua y entrega continua (CI/CD), como. GitLab No se requiere una versión de pago específica de GitHub .
Algunas Servicios de AWS no están disponibles en todas Regiones de AWS. Para conocer la disponibilidad regional, consulta los puntos finales y las cuotas del servicio en la AWS documentación y elige el enlace correspondiente al servicio.
Arquitectura
Este patrón está diseñado para implementarse como un GitHub repositorio que contiene un flujo de trabajo GitHub reutilizable y políticas de Checkov personalizadas. El flujo de trabajo reutilizable puede escanear repositorios de Terraform y de CloudFormation infraestructura como código (IaC).
El siguiente diagrama muestra el repositorio de GitHub flujos de trabajo reutilizables y el repositorio de políticas de Custom Checkov como iconos separados. Sin embargo, puede implementar estos repositorios como repositorios separados o como un repositorio único. El código de ejemplo usa un único repositorio, con archivos para flujos de trabajo (.github/workflows) y archivos para políticas personalizadas (la carpeta custom_policies y el archivo de configuración .checkov.yml) en el mismo repositorio.
En el diagrama, se muestra el siguiente flujo de trabajo:
Un usuario crea una solicitud de extracción en un GitHub repositorio.
Los flujos de trabajo de Pipeline comienzan en GitHub Actions, e incluyen una referencia a un flujo de trabajo reutilizable de Checkov.
El flujo de trabajo de canalización descarga el flujo de trabajo reutilizable de Checkov al que se hace referencia desde un repositorio externo y ejecuta ese flujo de trabajo de Checkov mediante Actions. GitHub
El flujo de trabajo reutilizable de Checkov descarga las políticas personalizadas de un repositorio externo.
El flujo de trabajo reutilizable de Checkov evalúa el IaC del GitHub repositorio en función de las políticas de Checkov integradas y personalizadas. El flujo de trabajo reutilizable de Checkov se aprueba o no en función de si se detectan problemas de seguridad.
Automatización y escala
Este patrón permite la administración centralizada de la configuración de Checkov, de modo que las actualizaciones de políticas se puedan aplicar en un solo lugar. Sin embargo, este patrón requiere que cada repositorio utilice un flujo de trabajo que contenga una referencia al flujo de trabajo central reutilizable. Puede añadir esta referencia manualmente o utilizar scripts para insertar el archivo en la carpeta .github/workflows de cada repositorio.
Tools (Herramientas)
Servicios de AWS
CloudFormationle ayuda a configurar AWS los recursos, aprovisionarlos de forma rápida y coherente y gestionarlos a lo largo de su ciclo de vida en todas las regiones. Cuentas de AWS Checkov puede escanear CloudFormation.
Otras herramientas
Checkov
es una herramienta de análisis de código estático que comprueba si la IaC se ha configurado mal configurado en función de la seguridad y el cumplimiento. GitHub Actions
está integrado en la GitHub plataforma para ayudarte a crear, compartir y ejecutar flujos de trabajo en tus GitHub repositorios. Puedes usar GitHub Actions para automatizar tareas como crear, probar e implementar tu código. Terraform
es una herramienta de iAC HashiCorp que le ayuda a crear y administrar recursos locales y en la nube. Checkov puede analizar Terraform.
Repositorio de código
El código de este patrón está disponible en el repositorio. GitHub centralized-custom-checkov-sast
Prácticas recomendadas
Para mantener una postura de seguridad coherente, asegúrese de que las políticas de seguridad de su empresa coinciden con las políticas de Checkov.
En las primeras fases de la implementación de las políticas personalizadas de Checkov, puede utilizar la opción Error leve en el análisis de Checkov para poder combinar la IaC que tenga problemas de seguridad. A medida que el proceso vaya madurando, cambie de la opción Error leve a la opción Error grave.
Epics
| Tarea | Descripción | Habilidades requeridas |
|---|---|---|
Cree un repositorio central de Checkov. | Cree un repositorio para almacenar las políticas de Checkov personalizadas que se utilizarán en la organización. Para empezar rápidamente, puedes copiar el contenido del repositorio de este patrón en tu GitHub centralized-custom-checkov-sast | DevOps ingeniero |
Cree un repositorio para flujos de trabajo reutilizables. | Si ya existe un repositorio para flujos de trabajo reutilizables, o si planea incluir archivos de flujo de trabajo reutilizables en el mismo repositorio que las políticas personalizadas de Checkov, puede omitir este paso. Cree un GitHub repositorio para almacenar flujos de trabajo reutilizables. Las canalizaciones de otros repositorios harán referencia a este repositorio. | DevOps ingeniero |
| Tarea | Descripción | Habilidades requeridas |
|---|---|---|
Añada un flujo de trabajo reutilizable de Checkov. | Cree un flujo de trabajo reutilizable de Checkov GitHub Actions (archivo YAML) en el repositorio de flujos de trabajo reutilizables. Puede adaptar este flujo de trabajo reutilizable a partir del archivo de flujo de trabajo que se proporciona en este patrón. Como ejemplo de un cambio, es posible que quiera cambiar el flujo de trabajo reutilizable para utilizar la opción Error leve. Si establece | DevOps ingeniero |
Añada un ejemplo de flujo de trabajo. | Añada un ejemplo de flujo de trabajo de Checkov que haga referencia al flujo de trabajo de Para obtener más información sobre cómo escribir un ejemplo de flujo de trabajo de Checkov, consulte Información adicional. | DevOps ingeniero |
| Tarea | Descripción | Habilidades requeridas |
|---|---|---|
Determine las políticas que se pueden aplicar con Checkov. |
Para obtener más información sobre la creación de políticas personalizadas de Checkov, consulte la Custom Policies Overview | Seguridad y conformidad |
Agregue políticas personalizadas de Checkov. | Convierta las políticas de la empresa identificadas en políticas de Checkov personalizadas en el repositorio central. Puede escribir políticas de Checkov sencillas en Python o YAML. | Seguridad |
| Tarea | Descripción | Habilidades requeridas |
|---|---|---|
Añada el flujo de trabajo reutilizable de Checkov a todos los repositorios. | En este punto, debería tener un ejemplo de flujo de trabajo de Checkov que haga referencia al flujo de trabajo reutilizable. Copie el ejemplo del flujo de trabajo de Checkov que hace referencia al flujo de trabajo reutilizable en cada repositorio que lo requiera. | DevOps ingeniero |
Cree un mecanismo para garantizar que Checkov se ejecute antes de las combinaciones. | Para asegurarte de que el flujo de trabajo de Checkov se ejecute para cada solicitud de extracción, crea una verificación de estado | DevOps ingeniero |
Cree un PAT para toda la organización y compártalo como un secreto. | Si su GitHub organización es visible públicamente, puede omitir este paso. Este patrón requiere que el flujo de trabajo de Checkov pueda descargar políticas personalizadas del repositorio de políticas personalizadas de su GitHub organización. Debe proporcionar permisos para que el flujo de trabajo de Checkov pueda acceder a esos repositorios. Para ello, cree un token de acceso personal | DevOps ingeniero |
(Opcional) Proteja los archivos de flujo de trabajo de Checkov para que no se modifiquen. | Para proteger los archivos de flujo de trabajo de Checkov de cambios no deseados, puede utilizar un archivo Por ejemplo, para solicitar la aprobación del
Un archivo Para obtener más información acerca de la protección de los archivos de flujo de trabajo de Checkov, consulte Información adicional. Para obtener más información sobre | DevOps ingeniero |
Recursos relacionados
Información adicional
Escritura de archivos de flujo de trabajo de Checkov
Al escribir checkov-scan.yaml, tenga en cuenta cuándo quiere que se ejecute. La clave onde nivel superior determina cuándo se ejecuta el flujo de trabajo. En el repositorio de ejemplo, el flujo de trabajo se ejecutará cuando haya una solicitud de extracción dirigida a la rama main (y siempre que se modifique la rama de origen de esa solicitud de extracción). El flujo de trabajo también se puede ejecutar según sea necesario debido a la clave workflow_dispatch.
Puede cambiar las condiciones de activación del flujo de trabajo en función de la frecuencia con la que desee que este se ejecute. Por ejemplo, puede cambiar el flujo de trabajo para que se ejecute cada vez que se introduzca código en una rama; para ello, sustituya pull_request por push y quite la clave branches.
Puede modificar el archivo de flujo de trabajo de ejemplo que creó en un repositorio individual. Por ejemplo, puede ajustar el nombre de la rama de destino de main a production si el repositorio está estructurado en torno a una rama de production.
Protección de archivos de flujo de trabajo de Checkov
El análisis de Checkov proporciona información útil sobre posibles errores de configuración de seguridad. Sin embargo, es posible que algunos desarrolladores perciban esto como una barrera para su productividad e intenten eliminar o deshabilitar el flujo de trabajo de análisis.
Hay varias formas de abordar este problema, como enviar información más detallada sobre el valor a largo plazo del análisis de seguridad y documentar de manera más clara cómo implementar una infraestructura segura. Estos son importantes enfoques «flexibles» de DevSecOps la colaboración que pueden considerarse la solución a la causa raíz de este problema. Sin embargo, también puede utilizar controles técnicos, como un archivo CODEOWNERS que actúe como barrera de protección, para ayudar a los desarrolladores a seguir el camino correcto.
Prueba de un patrón en un entorno de pruebas
Para probar este patrón en un entorno de pruebas, siga estos pasos:
Cree una nueva GitHub organización. Cree un token con acceso de solo lectura a todos los repositorios de la organización. Como este token se usará en un entorno de pruebas y no en un entorno de pago, no podrá almacenarlo como secreto para toda la organización.
Cree un repositorio de
checkovpara almacenar la configuración de Checkov y un repositorio degithub-workflowspara almacenar la configuración del flujo de trabajo reutilizable. Rellene los repositorios con el contenido del repositorio de ejemplo.Cree un repositorio de aplicaciones y copie y pegue el flujo de trabajo
checkov-scan.yamlen su carpeta.github/workflows. Agregue un secreto al repositorio que contenga el PAT que creó para el acceso de solo lectura de la organización. El valor predeterminado del secreto esORG_PAT.Crea una solicitud de extracción que añada algo de Terraform o CloudFormation código al repositorio de aplicaciones. Checkov debería analizar esto y devolver un resultado.
