As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Implemente o escaneamento Checkov personalizado e centralizado para aplicar a política antes de implantar a infraestrutura AWS
*Benjamin Morris, Amazon Web Services*
## Resumo
Esse padrão fornece uma estrutura de GitHub ações para escrever políticas personalizadas do Checkov em um repositório que pode ser reutilizada em toda a organização. GitHub Ao seguir este padrão, uma equipe de segurança da informação poderá gravar, adicionar e manter políticas personalizadas de acordo com os requisitos da empresa. As políticas personalizadas podem ser inseridas automaticamente em todos os pipelines da GitHub organização. Essa abordagem pode ser usada para aplicar os padrões da empresa aos recursos antes que sejam implantados.
## Pré-requisitos e limitações
**Pré-requisitos **
+ Um ativo Conta da AWS
+ Uma GitHub organização usando GitHub Ações
+ AWS infraestrutura implantada com HashiCorp Terraform ou AWS CloudFormation
**Limitações**
+ Esse padrão foi escrito para GitHub Ações. No entanto, ele pode ser adaptado a estruturas similares de integração contínua e entrega contínua (CI/CD), como. GitLab Nenhuma versão paga específica do GitHub é necessária.
+ Alguns Serviços da AWS não estão disponíveis em todos Regiões da AWS. Para a disponibilidade da região, consulte [Pontos de extremidade e cotas de serviço](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) na AWS documentação e escolha o link para o serviço.
## Arquitetura
Esse padrão foi projetado para ser implantado como um GitHub repositório que contém um fluxo de trabalho GitHub reutilizável e políticas personalizadas do Checkov. O fluxo de trabalho reutilizável pode escanear tanto o Terraform quanto os repositórios de CloudFormation infraestrutura como código (IaC).
O diagrama a seguir mostra o repositório de ** GitHub fluxos de trabalho reutilizáveis e o repositório** de **políticas do Custom Checkov** como ícones separados. Contudo, é possível implementar esses repositórios como repositórios separados ou como um único repositório. O código de exemplo usa um único repositório, com arquivos destinados a fluxos de trabalho (`.github/workflows`) e arquivos destinados a políticas personalizadas (pasta `custom_policies` e o arquivo de configuração `.checkov.yml`) no mesmo repositório.
![\[GitHub O Actions usa GitHub fluxo de trabalho reutilizável e políticas personalizadas do Checkov para avaliar o IaC.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/images/pattern-img/6c0c941f-14f9-4569-92da-9f81ab3e525c/images/a1539ce5-0ee6-4af1-bd01-cafad0f71708.png)
O diagrama mostra o seguinte fluxo de trabalho:
1. Um usuário cria uma pull request em um GitHub repositório.
1. Os fluxos de trabalho do pipeline começam em GitHub Ações, incluindo uma referência a um fluxo de trabalho reutilizável do Checkov.
1. O fluxo de trabalho do pipeline baixa o fluxo de trabalho reutilizável Checkov referenciado de um repositório externo e executa esse fluxo de trabalho Checkov usando Ações. GitHub
1. O fluxo de trabalho reutilizável do Checkov faz o download das políticas personalizadas de um repositório externo.
1. O fluxo de trabalho reutilizável do Checkov avalia o IaC no GitHub repositório em relação às políticas incorporadas e personalizadas do Checkov. O fluxo de trabalho reutilizável do Checkov é aprovado ou reprovado dependendo da presença de problemas de segurança.
**Automação e escala**
Este padrão permite o gerenciamento centralizado da configuração do Checkov, para que as atualizações de políticas possam ser aplicadas em um único local. Entretanto, este padrão exige que cada repositório empregue um fluxo de trabalho que contenha uma referência ao fluxo de trabalho reutilizável central. É possível adicionar essa referência manualmente ou usar scripts para transferir o arquivo para a pasta `.github/workflows` de cada repositório.
## Ferramentas
**Serviços da AWS**
+ [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)ajuda você a configurar AWS recursos, provisioná-los de forma rápida e consistente e gerenciá-los em todo o ciclo de vida em todas Contas da AWS as regiões. Checkov pode escanear CloudFormation.
**Outras ferramentas**
+ A ferramenta [Checkov](https://www.checkov.io/) é destinada à análise estática que verifica IaC para identificação de falhas de segurança e conformidade.
+ GitHub O [Actions](https://github.com/features/actions) é integrado à GitHub plataforma para ajudar você a criar, compartilhar e executar fluxos de trabalho em seus GitHub repositórios. Você pode usar o GitHub Actions para automatizar tarefas como criar, testar e implantar seu código.
+ [O Terraform](https://www.terraform.io/) é uma ferramenta de IaC HashiCorp que ajuda você a criar e gerenciar recursos na nuvem e no local. O Checkov consegue realizar a verificação do Terraform.
**Repositório de código**
O código desse padrão está disponível no GitHub [centralized-custom-checkov-sast](https://github.com/aws-samples/centralized-custom-checkov-sast)repositório.
## Práticas recomendadas
+ Para garantir uma postura de segurança consistente, alinhe as políticas de segurança da sua empresa às políticas do Checkov.
+ Nas fases iniciais da implementação das políticas personalizadas do Checkov, você pode usar a opção de falha branda na verificação do Checkov para permitir que uma IaC com problemas de segurança seja mesclada. Com o amadurecimento do processo, faça a transição da opção de falha branda para a opção de falha definitiva.
## Épicos
### Criação de um repositório central do Checkov para políticas personalizadas
| Tarefa | Description | Habilidades necessárias |
| --- | --- | --- |
| Crie um repositório central do Checkov. | Crie um repositório para armazenar as políticas personalizadas do Checkov que serão aplicadas na organização.Para começar rapidamente, você pode copiar o conteúdo do repositório desse padrão em seu GitHub [centralized-custom-checkov-sast ](https://github.com/aws-samples/centralized-custom-checkov-sast)repositório central do Checkov. | DevOps engenheiro |
| Crie um repositório para fluxos de trabalho reutilizáveis. | Se um repositório para fluxos de trabalho reutilizáveis já existir, ou se você planeja incluir os arquivos de fluxos de trabalho reutilizáveis no mesmo repositório das políticas personalizadas do Checkov, pode pular esta etapa.Crie um GitHub repositório para armazenar fluxos de trabalho reutilizáveis. Os pipelines de outros repositórios farão referência a este repositório. | DevOps engenheiro |
### Criação de fluxos de trabalho reutilizáveis e de exemplo do Checkov
| Tarefa | Description | Habilidades necessárias |
| --- | --- | --- |
| Adicione um fluxo de trabalho reutilizável do Checkov. | Crie um fluxo de trabalho Checkov GitHub Actions reutilizável (arquivo YAML) no repositório de fluxos de trabalho reutilizáveis. Você pode adaptar este fluxo de trabalho reutilizável usando o arquivo de fluxo de trabalho fornecido neste padrão.Um exemplo de alteração que você pode desejar fazer é alterar o fluxo de trabalho reutilizável para usar a opção de falha branda. Definir `soft-fail` como `true` permite que o trabalho seja concluído com êxito, mesmo que ocorra uma falha na verificação do Checkov. Para obter instruções, consulte [Hard and soft fail](https://www.checkov.io/2.Basics/Hard%20and%20soft%20fail.html) na documentação do Checkov. | DevOps engenheiro |
| Adicione um fluxo de trabalho de exemplo. | Adicione um fluxo de trabalho de exemplo do Checkov que faça referência ao fluxo de trabalho `reusable`. Isso fornecerá um modelo de como reutilizar o fluxo de trabalho `reusable`. No repositório de exemplo, `checkov-source.yaml` representa o fluxo de trabalho reutilizável, enquanto `checkov-scan.yaml` é o exemplo que utiliza `checkov-source`.Para obter mais detalhes sobre como gravar um fluxo de trabalho de exemplo do Checkov, consulte [Informações adicionais](#centralized-custom-checkov-scanning-additional). | DevOps engenheiro |
### Associação das políticas da empresa às políticas personalizadas do Checkov
| Tarefa | Description | Habilidades necessárias |
| --- | --- | --- |
| Determine as políticas que podem ser aplicadas com o Checkov. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/centralized-custom-checkov-scanning.html)Para obter mais detalhes sobre como criar políticas personalizadas do Checkov, consulte [Custom Policies Overview](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html) na documentação do Checkov. | Segurança e conformidade |
| Adicione políticas personalizadas do Checkov. | Converta as políticas da empresa identificadas em políticas personalizadas do Checkov no repositório central. É possível gravar políticas simples do Checkov tanto em Python quanto em YAML. | Segurança |
### Implementação das políticas personalizadas do Checkov de forma centralizada
| Tarefa | Description | Habilidades necessárias |
| --- | --- | --- |
| Adicione o fluxo de trabalho reutilizável do Checkov a todos os repositórios. | Nesse momento, você deve ter um fluxo de trabalho de exemplo do Checkov que faça referência ao fluxo de trabalho reutilizável. Copie o fluxo de trabalho de exemplo do Checkov, que referencia o fluxo de trabalho reutilizável, para cada repositório que necessitar dele. | DevOps engenheiro |
| Crie um mecanismo para garantir que o Checkov seja executado antes das mesclagens. | Para garantir que o fluxo de trabalho do Checkov seja executado para cada pull request, crie uma [verificação de status](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks) que exija um fluxo de trabalho Checkov bem-sucedido antes que os pull requests possam ser mesclados. GitHub permite que você exija que fluxos de trabalho específicos sejam executados antes que as pull requests possam ser mescladas. | DevOps engenheiro |
| Crie um PAT para toda a organização e compartilhe-o como um segredo. | Se sua GitHub organização estiver visível publicamente, você pode pular essa etapa.Esse padrão exige que o fluxo de trabalho do Checkov seja capaz de baixar políticas personalizadas do repositório de políticas personalizadas em sua GitHub organização. É necessário fornecer permissões para que o fluxo de trabalho do Checkov possa acessar esses repositórios.Para fazer isso, [crie um token de acesso pessoal](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) com permissões de leitura para os repositórios da organização. Compartilhe este PAT com os repositórios, seja como um segredo organizacional (se estiver usando um plano pago) ou como um segredo em cada repositório (se estiver usando a versão gratuita). No código de amostra, o nome padrão para o segredo é `ORG_PAT`. | DevOps engenheiro |
| (Opcional) Proteja os arquivos do fluxo de trabalho do Checkov contra modificações. | Para proteger os arquivos do fluxo de trabalho do Checkov contra alterações indesejadas, você pode usar um arquivo `CODEOWNERS`. O arquivo `CODEOWNERS` é geralmente implantado na raiz do diretório.Por exemplo, para exigir aprovações do `secEng` grupo da sua GitHub organização quando o `checkov-scan.yaml` arquivo for modificado, acrescente o seguinte ao arquivo do repositório: `CODEOWNERS`[Checkov]
.github/workflows/checkov-scan.yaml @myOrg/secEng
O arquivo `CODEOWNERS` é específico para o repositório em que está localizado. Para proteger o fluxo de trabalho do Checkov usado pelo repositório, é necessário adicionar (ou atualizar) um arquivo `CODEOWNERS` em cada repositório.Para obter mais informações sobre como proteger os arquivos do fluxo de trabalho do Checkov, consulte [Informações adicionais](#centralized-custom-checkov-scanning-additional). Para obter mais informações sobre `CODEOWNERS` arquivos, consulte a documentação oficial do seu CI/CD provedor (como [GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)). | DevOps engenheiro |
## Recursos relacionados
+ [Checkov Custom Policies Overview](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html)
+ [CloudFormation Escaneamento de configuração](https://www.checkov.io/7.Scan%20Examples/Cloudformation.html)
+ [GitHub Ações Fluxos de trabalho reutilizáveis](https://docs.github.com/en/actions/using-workflows/reusing-workflows)
## Mais informações
**Elaboração de arquivos de fluxo de trabalho do Checkov**
Ao elaborar o arquivo `checkov-scan.yaml`, considere quando deseja que ele seja executado. A chave `on` de nível superior determina quando o fluxo de trabalho será executado. No repositório de exemplo, o fluxo de trabalho será executado quando houver uma solicitação de pull direcionada para a ramificação `main` (e sempre que a ramificação de origem dessa solicitação de pull for modificada). O fluxo de trabalho também pode ser executado sob demanda, devido à chave `workflow_dispatch`.
É possível alterar as condições de acionamento do fluxo de trabalho com base na frequência com que deseja que ele seja executado. Por exemplo, você poderia alterar o fluxo de trabalho para ser executado sempre que o código for enviado a qualquer ramificação, substituindo `pull_request` por `push` e removendo a chave `branches`.
É possível modificar o arquivo de fluxo de trabalho de exemplo que foi criado em um repositório individual. Por exemplo, você poderia ajustar o nome da ramificação de destino de `main` para `production`, caso o repositório seja estruturado em torno de uma ramificação de `production`.
**Proteção de arquivos de fluxo de trabalho do Checkov**
A verificação do Checkov fornece informações úteis sobre potenciais erros de configuração relacionados à segurança. No entanto, alguns desenvolvedores podem considerar a ferramenta como um obstáculo para sua produtividade e tentar remover ou desabilitar o fluxo de trabalho de verificação.
Existem várias formas de resolver esse problema, incluindo uma comunicação mais eficaz sobre o valor a longo prazo da verificação de segurança e uma documentação mais clara sobre como implantar uma infraestrutura segura. Essas são abordagens “leves” importantes de DevSecOps colaboração que podem ser vistas como a solução para a causa raiz desse problema. No entanto, você também pode usar controles técnicos, como um arquivo `CODEOWNERS` e as barreiras de proteção para orientar os desenvolvedores corretamente.
**Padrão de testes em um ambiente de sandbox**
Para testar este padrão em um ambiente de sandbox, siga estas etapas:
1. Crie uma nova GitHub organização. Crie um token com acesso somente para leitura a todos os repositórios da organização. Como esse token é para um ambiente de sandbox, e não para um ambiente pago, não será possível armazená-lo como um segredo global da organização.
1. Crie um repositório`checkov` para armazenar a configuração do Checkov e um repositório `github-workflows` para armazenar a configuração do fluxo de trabalho reutilizável. Preencha os repositórios com o conteúdo fornecido no repositório de exemplo.
1. Crie um repositório de aplicação e copie e cole o fluxo de trabalho `checkov-scan.yaml` na pasta `.github/workflows` desse repositório. Adicione um segredo ao repositório que contenha o PAT que você criou para o acesso somente à leitura da organização. O segredo padrão é `ORG_PAT`.
1. Crie uma pull request que adicione um pouco de Terraform ou CloudFormation código ao repositório do aplicativo. O Checkov deve realizar a verificação e retornar um resultado.