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 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.
O diagrama mostra o seguinte fluxo de trabalho:
Um usuário cria uma pull request em um GitHub repositório.
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.
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
O fluxo de trabalho reutilizável do Checkov faz o download das políticas personalizadas de um repositório externo.
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
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
A ferramenta Checkov
é destinada à análise estática que verifica IaC para identificação de falhas 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. 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
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
| 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 | 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 |
| 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 | 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 Para obter mais detalhes sobre como gravar um fluxo de trabalho de exemplo do Checkov, consulte Informações adicionais. | DevOps engenheiro |
| Tarefa | Description | Habilidades necessárias |
|---|---|---|
Determine as políticas que podem ser aplicadas com o Checkov. |
Para obter mais detalhes sobre como criar políticas personalizadas do Checkov, consulte Custom Policies Overview | 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 |
| 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 | 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 | 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 Por exemplo, para exigir aprovações do
O arquivo Para obter mais informações sobre como proteger os arquivos do fluxo de trabalho do Checkov, consulte Informações adicionais. Para obter mais informações sobre | DevOps engenheiro |
Recursos relacionados
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:
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.
Crie um repositório
checkovpara armazenar a configuração do Checkov e um repositóriogithub-workflowspara armazenar a configuração do fluxo de trabalho reutilizável. Preencha os repositórios com o conteúdo fornecido no repositório de exemplo.Crie um repositório de aplicação e copie e cole o fluxo de trabalho
checkov-scan.yamlna pasta.github/workflowsdesse 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.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.
