Implemente o escaneamento Checkov personalizado e centralizado para aplicar a política antes de implantar a infraestrutura AWS

PDF

Criado por Benjamin Morris (AWS)

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 Seguindo esse padrão, uma equipe de segurança da informação pode escrever, adicionar e manter políticas personalizadas com base nos 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 impor os padrões de recursos da empresa antes que os recursos 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 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. No entanto, você pode 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 para fluxos de trabalho (.github/workflows) e arquivos para políticas personalizadas (custom_policiespasta e arquivo de .checkov.yml configuração) no mesmo repositório.

O diagrama mostra o seguinte fluxo de trabalho:

1. Um usuário cria uma pull request em um GitHub repositório.

2. 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.

3. 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

4. O fluxo de trabalho reutilizável do Checkov baixa as políticas personalizadas de um repositório externo.

5. 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 passa ou falha com base na descoberta de problemas de segurança.

Automação e escala

Esse padrão permite o gerenciamento central da configuração do Checkov, para que as atualizações de políticas possam ser aplicadas em um único local. No entanto, esse padrão exige que cada repositório use um fluxo de trabalho que contenha uma referência ao fluxo de trabalho central reutilizável. Você pode adicionar essa referência manualmente ou usar scripts para enviar o arquivo para a .github/workflows pasta de cada repositório.

Ferramentas

Serviços da AWS

• AWS CloudFormationajuda 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

• O Checkov é uma ferramenta estática de análise de código que verifica o IaC em busca de configurações incorretas de segurança e conformidade.

• GitHub O 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 é uma ferramenta de IaC HashiCorp que ajuda você a criar e gerenciar recursos na nuvem e no local. Checkov pode escanear o Terraform.

Repositório de código

O código desse padrão está disponível no GitHub centralized-custom-checkov-sastrepositório.

Práticas recomendadas

• Para manter uma postura de segurança consistente, alinhe as políticas de segurança da sua empresa com as políticas da Checkov.

• Nas fases iniciais da implementação das políticas personalizadas do Checkov, você pode usar a opção soft-fail em sua verificação do Checkov para permitir que o IaC com problemas de segurança seja mesclado. À medida que o processo amadurece, mude da opção de falha suave para a opção de falha definitiva.

Épicos

Crie um repositório central do Checkov para políticas personalizadas

Tarefa	Descrição	Habilidades necessárias
Crie um repositório central do Checkov.	Crie um repositório para armazenar políticas personalizadas do Checkov que serão usadas 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 repositório central do Checkov.	DevOps engenheiro
Crie um repositório para fluxos de trabalho reutilizáveis.	Se já existir um repositório para fluxos de trabalho reutilizáveis ou se você planeja incluir arquivos de fluxo de trabalho reutilizáveis no mesmo repositório das políticas personalizadas do Checkov, você 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 esse repositório.	DevOps engenheiro

Crie um repositório central do Checkov para políticas personalizadas

Tarefa	Descrição	Habilidades necessárias
Crie um repositório central do Checkov.	Crie um repositório para armazenar políticas personalizadas do Checkov que serão usadas 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 repositório central do Checkov.	DevOps engenheiro
Crie um repositório para fluxos de trabalho reutilizáveis.	Se já existir um repositório para fluxos de trabalho reutilizáveis ou se você planeja incluir arquivos de fluxo de trabalho reutilizáveis no mesmo repositório das políticas personalizadas do Checkov, você 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 esse repositório.	DevOps engenheiro

Crie fluxos de trabalho Checkov reutilizáveis e de exemplo

Tarefa	Descrição	Habilidades necessárias
Adicione um fluxo de trabalho Checkov reutilizável.	Crie um fluxo de trabalho Checkov GitHub Actions reutilizável (arquivo YAML) no repositório de fluxos de trabalho reutilizáveis. Você pode adaptar esse fluxo de trabalho reutilizável a partir do arquivo de fluxo de trabalho fornecido nesse padrão. Um exemplo de alteração que talvez você queira fazer é alterar o fluxo de trabalho reutilizável para usar a opção soft-fail. A configuração soft-fail para true permite que o trabalho seja concluído com êxito, mesmo se houver uma falha na verificação do Checkov. Para obter instruções, consulte Falha rígida e flexível na documentação do Checkov.	DevOps engenheiro
Adicione um exemplo de fluxo de trabalho.	Adicione um exemplo de fluxo de trabalho Checkov que faça referência ao reusable fluxo de trabalho. Isso fornecerá um modelo de como reutilizar o reusable fluxo de trabalho. No repositório de exemplo, checkov-source.yaml é o fluxo de trabalho reutilizável e checkov-scan.yaml é o exemplo que consome. checkov-source Para obter mais detalhes sobre como escrever um exemplo de fluxo de trabalho do Checkov, consulte Informações adicionais.	DevOps engenheiro

Crie fluxos de trabalho Checkov reutilizáveis e de exemplo

Tarefa	Descrição	Habilidades necessárias
Adicione um fluxo de trabalho Checkov reutilizável.	Crie um fluxo de trabalho Checkov GitHub Actions reutilizável (arquivo YAML) no repositório de fluxos de trabalho reutilizáveis. Você pode adaptar esse fluxo de trabalho reutilizável a partir do arquivo de fluxo de trabalho fornecido nesse padrão. Um exemplo de alteração que talvez você queira fazer é alterar o fluxo de trabalho reutilizável para usar a opção soft-fail. A configuração soft-fail para true permite que o trabalho seja concluído com êxito, mesmo se houver uma falha na verificação do Checkov. Para obter instruções, consulte Falha rígida e flexível na documentação do Checkov.	DevOps engenheiro
Adicione um exemplo de fluxo de trabalho.	Adicione um exemplo de fluxo de trabalho Checkov que faça referência ao reusable fluxo de trabalho. Isso fornecerá um modelo de como reutilizar o reusable fluxo de trabalho. No repositório de exemplo, checkov-source.yaml é o fluxo de trabalho reutilizável e checkov-scan.yaml é o exemplo que consome. checkov-source Para obter mais detalhes sobre como escrever um exemplo de fluxo de trabalho do Checkov, consulte Informações adicionais.	DevOps engenheiro

Associe as políticas da empresa às políticas personalizadas da Checkov

Tarefa	Descrição	Habilidades necessárias
Determine as políticas que podem ser aplicadas com o Checkov.	Analise as políticas da empresa relacionadas à segurança da infraestrutura e quais requisitos devem estar em vigor. Determine quais requisitos podem ser implementados usando as políticas personalizadas da Checkov. Crie uma convenção de nomenclatura que mapeie o controle de política para a política personalizada do Checkov. Normalmente, as políticas personalizadas da Checkov têm um identificador com o nome da Checkov, a fonte da política (personalizada) e um número da política (por exemplo,CKV2_CUSTOM_123). Para obter mais detalhes sobre a criação de políticas personalizadas do Checkov, consulte Visão geral das políticas personalizadas na documentação do Checkov.	Segurança e conformidade
Adicione políticas personalizadas do Checkov.	Converta as políticas identificadas da empresa em políticas personalizadas do Checkov no repositório central. Você pode escrever políticas simples de Checkov em Python ou YAML.	Segurança

Associe as políticas da empresa às políticas personalizadas da Checkov

Tarefa	Descrição	Habilidades necessárias
Determine as políticas que podem ser aplicadas com o Checkov.	Analise as políticas da empresa relacionadas à segurança da infraestrutura e quais requisitos devem estar em vigor. Determine quais requisitos podem ser implementados usando as políticas personalizadas da Checkov. Crie uma convenção de nomenclatura que mapeie o controle de política para a política personalizada do Checkov. Normalmente, as políticas personalizadas da Checkov têm um identificador com o nome da Checkov, a fonte da política (personalizada) e um número da política (por exemplo,CKV2_CUSTOM_123). Para obter mais detalhes sobre a criação de políticas personalizadas do Checkov, consulte Visão geral das políticas personalizadas na documentação do Checkov.	Segurança e conformidade
Adicione políticas personalizadas do Checkov.	Converta as políticas identificadas da empresa em políticas personalizadas do Checkov no repositório central. Você pode escrever políticas simples de Checkov em Python ou YAML.	Segurança

Implemente políticas personalizadas centralizadas da Checkov

Tarefa	Descrição	Habilidades necessárias
Adicione o fluxo de trabalho reutilizável Checkov a todos os repositórios.	Nesse ponto, você deve ter um exemplo de fluxo de trabalho Checkov que faça referência ao fluxo de trabalho reutilizável. Copie o exemplo do fluxo de trabalho Checkov que faz referência ao fluxo de trabalho reutilizável para cada repositório que o requer.	DevOps engenheiro
Crie um mecanismo para garantir que o Checkov seja executado antes das fusões.	Para garantir que o fluxo de trabalho do Checkov seja executado para cada pull request, crie uma verificação de status 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 em 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. Você deve 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 (PAT) com permissões para ler os repositórios da organização. Compartilhe esse PAT com repositórios, seja como um segredo para toda a organização (se estiver em um plano pago) ou como um segredo em cada repositório (versão gratuita). No código de exemplo, o nome padrão do 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 CODEOWNERS arquivo. Normalmente, o CODEOWNERS arquivo é 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 Um CODEOWNERS arquivo é específico para o repositório em que ele reside. Para proteger o fluxo de trabalho do Checkov usado pelo repositório, você deve adicionar (ou atualizar) um CODEOWNERS arquivo em cada repositório. Para obter mais informações sobre a proteção dos arquivos de fluxo de trabalho do Checkov, consulte Informações adicionais. Para obter mais informações sobre CODEOWNERS arquivos, consulte a documentação oficial do seu provedor de CI/CD (como GitHub).	DevOps engenheiro

Implemente políticas personalizadas centralizadas da Checkov

Tarefa	Descrição	Habilidades necessárias
Adicione o fluxo de trabalho reutilizável Checkov a todos os repositórios.	Nesse ponto, você deve ter um exemplo de fluxo de trabalho Checkov que faça referência ao fluxo de trabalho reutilizável. Copie o exemplo do fluxo de trabalho Checkov que faz referência ao fluxo de trabalho reutilizável para cada repositório que o requer.	DevOps engenheiro
Crie um mecanismo para garantir que o Checkov seja executado antes das fusões.	Para garantir que o fluxo de trabalho do Checkov seja executado para cada pull request, crie uma verificação de status 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 em 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. Você deve 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 (PAT) com permissões para ler os repositórios da organização. Compartilhe esse PAT com repositórios, seja como um segredo para toda a organização (se estiver em um plano pago) ou como um segredo em cada repositório (versão gratuita). No código de exemplo, o nome padrão do 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 CODEOWNERS arquivo. Normalmente, o CODEOWNERS arquivo é 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 Um CODEOWNERS arquivo é específico para o repositório em que ele reside. Para proteger o fluxo de trabalho do Checkov usado pelo repositório, você deve adicionar (ou atualizar) um CODEOWNERS arquivo em cada repositório. Para obter mais informações sobre a proteção dos arquivos de fluxo de trabalho do Checkov, consulte Informações adicionais. Para obter mais informações sobre CODEOWNERS arquivos, consulte a documentação oficial do seu provedor de CI/CD (como GitHub).	DevOps engenheiro

Recursos relacionados

• Visão geral das políticas personalizadas da Checkov

• CloudFormation Escaneamento de configuração

• GitHub Ações Fluxos de trabalho reutilizáveis

Mais informações

Escrevendo arquivos de fluxo de trabalho do Checkov

Ao escrevercheckov-scan.yaml, considere quando você quer que ele seja executado. A on chave de nível superior determina quando o fluxo de trabalho é executado. No repositório de exemplo, o fluxo de trabalho será executado quando houver uma pull request direcionada à main ramificação (e sempre que a ramificação de origem da pull request for modificada). O fluxo de trabalho também pode ser executado conforme necessário devido à workflow_dispatch chave.

Você pode alterar as condições de acionamento do fluxo de trabalho com base na frequência com que deseja que o fluxo de trabalho seja executado. Por exemplo, você pode alterar o fluxo de trabalho para ser executado sempre que o código for enviado para qualquer ramificação pull_request substituindo push e removendo a branches chave.

Você pode modificar o arquivo de exemplo de fluxo de trabalho que você criou em um repositório individual. Por exemplo, você pode ajustar o nome da ramificação de destino de main para production se um repositório estiver estruturado em torno de uma production ramificação.

Protegendo arquivos de fluxo de trabalho do Chec

O escaneamento Checkov fornece informações úteis sobre possíveis erros de configuração de segurança. No entanto, alguns desenvolvedores podem perceber que isso é uma barreira para sua produtividade e tentar remover ou desativar o fluxo de trabalho de digitalização.

Há várias maneiras de resolver esse problema, incluindo melhores mensagens sobre o valor a longo prazo da verificação de segurança e 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 CODEOWNERS arquivo, como grades de proteção para ajudar a manter os desenvolvedores no caminho certo.

Padrão de teste em uma caixa de areia

Para testar esse padrão em um ambiente sandbox, siga estas etapas:

1. Crie uma nova GitHub organização. Crie um token com acesso somente de leitura a todos os repositórios da organização. Como esse token é para um ambiente sandbox, não para um ambiente pago, você não poderá armazená-lo em um segredo para toda a organização.

2. Crie um checkov repositório para manter a configuração do Checkov e um github-workflows repositório para manter a configuração do fluxo de trabalho reutilizável. Preencha os repositórios com o conteúdo do repositório de exemplo.

3. Crie um repositório de aplicativos e copie e cole o checkov-scan.yaml fluxo de trabalho em sua .github/workflows pasta. Adicione um segredo ao repositório que contém o PAT que você criou para acesso somente para leitura da organização. O segredo padrão éORG_PAT.

4. Crie uma pull request que adicione um pouco de Terraform ou CloudFormation código ao repositório do aplicativo. Checkov deve digitalizar e retornar um resultado.