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 Implementación de un análisis centralizado y personalizado de Checkov *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](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) 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. ![\[GitHub Actions utiliza un GitHub flujo de trabajo reutilizable y políticas de Checkov personalizadas para evaluar la IaC.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/patterns/images/pattern-img/6c0c941f-14f9-4569-92da-9f81ab3e525c/images/a1539ce5-0ee6-4af1-bd01-cafad0f71708.png) En el diagrama, se muestra el siguiente flujo de trabajo: 1. Un usuario crea una solicitud de extracción en un GitHub repositorio. 1. Los flujos de trabajo de Pipeline comienzan en GitHub Actions, e incluyen una referencia a un flujo de trabajo reutilizable de Checkov. 1. 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 1. El flujo de trabajo reutilizable de Checkov descarga las políticas personalizadas de un repositorio externo. 1. 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** + [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)le 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](https://www.checkov.io/) 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](https://github.com/features/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](https://www.terraform.io/) 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](https://github.com/aws-samples/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 ### Creación de un repositorio central de Checkov para políticas personalizadas | 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 ](https://github.com/aws-samples/centralized-custom-checkov-sast)repositorio central de Checkov. | 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 | ### Creación de flujos de trabajo de Checkov reutilizables y de ejemplo | 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 `soft-fail` en `true`, el trabajo se puede completar correctamente incluso si se produce un error en el análisis de Checkov. Para obtener instrucciones, consulte [Hard and soft fail](https://www.checkov.io/2.Basics/Hard%20and%20soft%20fail.html) en la documentación de Checkov. | 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 `reusable`. Esto proporcionará una plantilla sobre cómo reutilizar el flujo de trabajo de `reusable`. En el repositorio de ejemplo, `checkov-source.yaml` es el flujo de trabajo reutilizable y `checkov-scan.yaml` es el ejemplo que consume `checkov-source`.Para obtener más información sobre cómo escribir un ejemplo de flujo de trabajo de Checkov, consulte [Información adicional](#centralized-custom-checkov-scanning-additional). | DevOps ingeniero | ### Asociación de las políticas de la empresa a las políticas personalizadas de Checkov | Tarea | Descripción | Habilidades requeridas | | --- | --- | --- | | Determine las políticas que se pueden aplicar con Checkov. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/patterns/centralized-custom-checkov-scanning.html)Para obtener más información sobre la creación de políticas personalizadas de Checkov, consulte la [Custom Policies Overview](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html) en la documentación de Checkov. | 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 | ### Implemente políticas personalizadas de Checkov centralizadas | 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](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks) que requiera un flujo de trabajo de Checkov correcto antes de poder fusionar las solicitudes de extracción. GitHub te permite exigir que se ejecuten flujos de trabajo específicos antes de poder fusionar las solicitudes de extracción. | 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](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token) (PAT) con permisos para leer los repositorios de la organización. Comparta el PAT con los repositorios, ya sea como un secreto para toda la organización (si tiene un plan de pago) o como un secreto en cada repositorio (versión gratuita). En el código de ejemplo, el nombre predeterminado del secreto es `ORG_PAT`. | 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 `CODEOWNERS`. Normalmente, el archivo `CODEOWNERS` se implementa en la raíz del directorio.Por ejemplo, para solicitar la aprobación del `secEng` grupo de su GitHub organización cuando se modifique el `checkov-scan.yaml` archivo, añada lo siguiente al archivo de `CODEOWNERS` un repositorio:
[Checkov]
.github/workflows/checkov-scan.yaml @myOrg/secEng
Un archivo `CODEOWNERS` es específico del repositorio en el que reside. Para proteger el flujo de trabajo de Checkov que usa el repositorio, debe añadir (o actualizar) un archivo `CODEOWNERS` en cada repositorio.Para obtener más información acerca de la protección de los archivos de flujo de trabajo de Checkov, consulte [Información adicional](#centralized-custom-checkov-scanning-additional). Para obtener más información sobre `CODEOWNERS` los archivos, consulta la documentación oficial de tu CI/CD proveedor (por ejemplo,). [GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) | DevOps ingeniero | ## Recursos relacionados + [Información general de las políticas personalizadas de Checkov](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html) + [CloudFormation Escaneo de configuraciones](https://www.checkov.io/7.Scan%20Examples/Cloudformation.html) + [GitHub Acciones: flujos de trabajo reutiliz](https://docs.github.com/en/actions/using-workflows/reusing-workflows) ## 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 `on`de 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: 1. 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. 1. Cree un repositorio de `checkov` para almacenar la configuración de Checkov y un repositorio de `github-workflows` para almacenar la configuración del flujo de trabajo reutilizable. Rellene los repositorios con el contenido del repositorio de ejemplo. 1. Cree un repositorio de aplicaciones y copie y pegue el flujo de trabajo `checkov-scan.yaml` en 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 es `ORG_PAT`. 1. 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.