Este documento descreve padrões para automatizar verificações de política e conformidade para seus recursos do Google Cloud usando o Chef InSpec, um framework de teste de infraestrutura de código aberto. Este documento é destinado a arquitetos e profissionais de DevOps que querem integrar o teste de conformidade contínua no fluxo de trabalho de desenvolvimento de software.
Política e conformidade no Google Cloud
O Google Cloud oferece uma variedade de ferramentas para ajudar você a aplicar e auditar os requisitos de política e conformidade:
| Serviço | Descrição |
|---|---|
| Hierarquia de recursos | É possível usar a hierarquia de recursos para mapear a estrutura operacional da sua empresa no Google Cloud e gerenciar o controle de acesso e as permissões dos grupos de recursos relacionados. É possível definir grupos de recursos relacionados e aplicar controles consistentes a todos os recursos do grupo. Por exemplo, é possível agrupar todos os projetos do Google Cloud sujeitos à conformidade com o Padrão de segurança de dados do setor de cartões de pagamento (PCI DSS, na sigla em inglês) em uma pasta específica. Em seguida, você pode aplicar controles relevantes a todos os projetos nessa pasta. |
| Organization Policy Service | Use o serviço Política da organização para definir restrições que limitam a disponibilidade ou a funcionalidade dos serviços do Google Cloud. Por exemplo, é possível usar a restrição de local do recurso para limitar o conjunto de regiões em que recursos baseados em local, como máquinas virtuais, podem ser criados. O serviço de política da organização funciona em conjunto com a hierarquia de recursos. Você pode aplicar políticas da organização em diferentes níveis da hierarquia. Por exemplo, você pode definir uma política da organização para seus projetos que estão sujeitos à conformidade com o PCI e aplicar a política à pasta PCI. |
| Security Command Center | É possível usar o Security Command Center para ter visibilidade centralizada de todos os seus recursos do Google Cloud. O Security Command Center analisa automaticamente os recursos da nuvem em busca de vulnerabilidades conhecidas e fornece uma única interface do usuário e uma plataforma de dados para agregar e gerenciar descobertas de segurança. O Security Health Analytics pode fornecer monitoramento e geração de relatórios para padrões de conformidade, como o PCI DSS, e padrões do setor, como o comparativo de mercado do Center for Internet Security (CIS). É possível visualizar os relatórios em um painel de conformidade e exportá-los. O Security Command Center integra-se a várias fontes de segurança de terceiros e fornece uma API para que você possa adicionar e gerenciar as descobertas personalizadas. O Security Command Center oferece uma interface unificada para todas as descobertas de segurança e conformidade. |
| Config Sync | Caso use o GKE Enterprise, será possível utilizar o Config Sync para manter seus clusters do Kubernetes sincronizados com as configurações definidas em um repositório Git. O repositório Git funciona como a única fonte confiável para as políticas e a configuração do cluster. O Config Sync audita continuamente seu ambiente do GKE Enterprise para identificar e corrigir clusters que diferem da configuração definida no seu repositório. |
| Controlador de Políticas | Se você usar o GKE Enterprise, poderá usar o Controlador de Políticas, um controlador de admissão dinâmica do Kubernetes, para aplicar políticas totalmente programáveis dos clusters. Com o Controlador de Políticas, é possível impedir a criação de objetos nos clusters que não atendem aos requisitos da política. Por exemplo, é possível criar políticas para aplicar a segurança do pod. |
Conheça o Chef InSpec
O Chef InSpec é um framework de teste de infraestrutura de código aberto com uma linguagem específica de domínio legível (DSL, na sigla em inglês) para especificar requisitos de conformidade, segurança e política.
Com o Chef InSpec:
- Definia os requisitos de conformidade como código e teste sua infraestrutura de nuvem em relação a esses requisitos.
- Permita que as equipes de desenvolvimento adicionem testes específicos do aplicativo e avaliem a conformidade dos aplicativos nas políticas de segurança antes de enviar alterações ao ambiente de produção.
- Automatize a verificação de conformidade em pipelines de CI/CD e como parte do processo de lançamento.
- Teste sua infraestrutura do Google Cloud da mesma maneira que você testa sua infraestrutura em outros ambientes de nuvem.
O Google Cloud fornece vários recursos para ajudar você a começar a usar o Chef InSpec:
- O pacote de recursos do Google Cloud InSpec contém os recursos básicos para gravar testes do Chef InSpec em objetos do Google Cloud.
- O perfil CIS do Google Cloud InSpec contém um conjunto de testes do Chef InSpecs que avaliam a posição de segurança dos seus projetos do Google Cloud em relação ao comparativo de mercado do Center for Internet Security (CIS).
Práticas recomendadas para usar o Chef InSpec com o Google Cloud
Veja a seguir as práticas recomendadas gerais para usar o Chef InSpec:
- Defina e adote um processo para corrigir as violações descobertas pelos testes do Chef InSpec. O Chef InSpec destaca violações dos seus requisitos de política e conformidade, mas não realiza nenhuma correção.
- Conceda as permissões apropriadas do IAM à conta de serviço usada para executar os testes do Chef InSpec. Por exemplo, se você estiver testando buckets do Cloud Storage, a conta de serviço precisará ter os papéis do IAM apropriados para o Cloud Storage.
- Configure os relatórios do Chef InSpec para produzir relatórios formatados que descrevem os testes e resultados. É possível armazenar esses relatórios para fornecer um registro histórico. Também é possível usar esses relatórios como entradas nas suas outras ferramentas de segurança e conformidade. Por exemplo, é possível Integrar o Chef InSpec e o Security Command Center.
- Agrupe testes de Chef InSpec em perfis. É possível criar perfis diferentes para casos de uso distintos. Por exemplo, você pode executar um perfil completo e completo como parte dos testes noturnos programados. Ou você pode executar um perfil mais curto e mais focado em resposta a eventos em tempo real.
Escrever testes do Chef InSpec
Os testes InSpec do Chef são usados com a DSL InSpec do Chef, que é uma DSL do Ruby para gravar controles de auditoria.
O código a seguir mostra um controle para validar atributos de buckets do Cloud Storage:
control 'policy_gcs_bucket' do
title 'Cloud Storage bucket policy'
desc 'Compliance policy checks for Cloud Storage bucket'
impact 'medium'
google_storage_buckets(project: project_id).bucket_names.each do |bucket|
describe "[#{project_id}] Cloud Storage Bucket #{bucket}" do
subject { google_storage_bucket(name: bucket) }
its('storage_class') { should eq 'STANDARD' }
its('location') { should be_in ['EUROPE-WEST2', 'EU'] }
end
end
end
O controle especifica as seguintes informações:
- Metadados que descrevem o controle
- Impacto ou gravidade das falhas
- Verificações de política que verificam os atributos de cada bucket do Cloud Storage no projeto
Executar testes do Chef InSpec com o Cloud Build
Os padrões descritos neste documento usam o Cloud Build e a imagem do contêiner do Chef InSpec para executar os testes do InSpec. Ao usar o Cloud Build, é possível executar imagens do contêiner e encadear etapas de criação para formar um pipeline. Por exemplo, é possível executar os testes do Chef InSpec em uma etapa de build e, em seguida, exportar ou analisar os relatórios gerados em uma etapa subsequente. No entanto, não é obrigatório usar o Cloud Build. Integre o Chef InSpec às ferramentas que você usar.
O arquivo de configuração do Cloud Build a seguir mostra um pipeline com duas etapas de compilação:
steps:
- id: 'run-inspec-cis'
name: chef/inspec:latest
entrypoint: '/bin/sh'
args:
- '-c'
- |
inspec exec https://github.com/GoogleCloudPlatform/inspec-gcp-cis-benchmark.git \
--target gcp:// \
--input gcp_project_id=${PROJECT_ID} \
--reporter cli json:/workspace/report.json \
--chef-license accept || touch fail.marker
- id: 'store-report'
name: gcr.io/cloud-builders/gsutil:latest
args:
- cp
- /workspace/report.json
- gs://${_REPORTS_BUCKET}/cis-report-${BUILD_ID}.json
A primeira etapa executa os testes do
comparativo de mercado CIS do Google Cloud
e gera um relatório no formato JSON. A etapa de criação usa a imagem do contêiner chef/inspec e busca os testes do repositório público do Google Cloud CIS no GitHub. A segunda etapa de versão copia o relatório gerado para um intervalo do Cloud Storage.
Para simplificar, o exemplo anterior faz referência à tag latest para todas as imagens de contêiner. Para ajudar a tornar seus builds reproduzíveis, recomendamos que você referencie uma versão fixa e específica da imagem do contêiner, em vez de uma versão contínua, como latest.
Se algum dos testes falhar, o Chef InSpec retornará um erro. Em vez de falhar na compilação, a primeira etapa de build grava um arquivo fail.marker e a segunda etapa de build é executada mesmo que qualquer um dos testes do Chef InSpec falhe. Se você quiser fazer uma falha explícita
na compilação para destacar os erros, verifique o arquivo fail.marker
em uma etapa final de build e falhe se a build existir.
Analisar relatórios do Chef InSpec
É possível configurar os geradores de relatórios do Chef InSpec para produzir relatórios formatados que descrevem os testes e resultados do InSpec. É possível armazenar esses relatórios para fornecer um registro histórico. Você também pode usar esses relatórios como entradas para suas outras ferramentas de segurança e conformidade ou para gerar visualizações ou alertas. Os padrões descritos mais adiante neste documento recomendam que você armazene os relatórios do Chef InSpec em um bucket do Cloud Storage.
O diagrama a seguir mostra como armazenar os relatórios e acionar ações automaticamente.
Adicionar o relatório a um bucket do Cloud Storage gera um evento. Você pode acionar mais ações ou análises do relatório em resposta a esse evento. No diagrama anterior, você aciona uma Função do Cloud que grava detalhes dos testes do Chef InSpec no BigQuery e outra função do Cloud que adiciona descobertas ao Security Command Center.
Integrar o Chef InSpec e o Security Command Center
O Security Command Center é o banco de dados de segurança e risco canônico do Google Cloud. O Security Command Center fornece visibilidade centralizada de todos os seus recursos do Google Cloud e analisa automaticamente seus recursos da nuvem em busca de vulnerabilidades conhecidas. Recomendamos ativar o Security Command Center para sua organização.
Você pode adicionar os resultados dos testes do Chef InSpec ao Security Command Center. O Security Command Center funciona como a plataforma de dados centralizada para agregar e gerenciar descobertas de segurança de várias fontes.
O Security Command Center inclui o Security Health Analytics. O Security Health Analytics verifica automaticamente seus projetos e recursos do Google Cloud em busca de vulnerabilidades comuns. Por exemplo, o Security Health Analytics executa verificações que avaliam seus projetos em relação ao comparativo de mercado CIS do Google Cloud Foundation 1.0. Também é possível executar um conjunto semelhante de testes usando o perfil CIS do Google Cloud InSpec. Você deve comparar o escopo dos testes do Chef InSpec para que os testes não dupliquem as verificações realizadas pelo Security Health Analytics.
Há várias maneiras de adicionar as descobertas do Chef InSpec ao Security Command Center:
- Use o Chef Automatizar para o Security Command Center para fornecer integração automática dos resultados do teste do Chef InSpec ao Security Command Center.
- Use a API Security Command Center para criar uma fonte personalizada para o Chef InSpec e, em seguida, crie descobertas para capturar quaisquer violações descobertas pelos testes do Chef InSpec.
Padrões
Nesta seção, descrevemos os padrões para integrar o Chef InSpec às operações diárias. É possível combinar esses padrões para conseguir testes de conformidade contínuos.
Programar testes do Chef InSpec
Nesse padrão, você executa o conjunto de testes Chef InSpec em uma programação fixa. Recomendamos essa abordagem de programação fixa como uma boa maneira de começar a usar o Chef InSpec, porque é possível introduzir testes do Chef InSpec sem modificar os processos existentes.
O diagrama a seguir mostra como executar os testes em uma programação.
No diagrama anterior, você cria um job do Cloud Scheduler executado com a frequência preferencial. Sempre que o job é executado, ele aciona um pipeline do Cloud Build que executa os testes do Chef InSpec e gera o relatório de teste para o Cloud Storage. Para mais informações, consulte Como programar versões.
Esse padrão tem os seguintes benefícios:
- Você pode introduzir testes do Chef InSpec com alterações mínimas nos processos atuais.
- É possível usar os testes InSpec do Chef independentemente de qualquer processo usado para provisionar e gerenciar a infraestrutura e os aplicativos.
Esse padrão tem as seguintes limitações:
- Os testes do Chef InSpec são independentes do provisionamento de infraestrutura, o que dificulta a atribuição de alterações específicas a testes com falha do Chef InSpec.
- Os testes do Chef InSpec são executados apenas periodicamente. Portanto, pode haver algum atraso antes que você identifique violações de conformidade ou de política
Integrar diretamente com os pipelines de CI/CD
Muitas organizações automatizam o provisionamento e o gerenciamento da infraestrutura usando ferramentas como o Terraform ou o Config Connector. Normalmente, a infraestrutura é criada ou alterada apenas como parte de um pipeline de CI/CD. Para mais informações sobre os conceitos de CI/CD no Google Cloud, consulte CI/CD moderno com o GKE Enterprise.
Nesse padrão, você adiciona testes Chef InSpec como etapas adicionais nos pipelines de implantação de infraestrutura para que possa validar a infraestrutura sempre que executar o pipeline de implantação. É possível falhar a versão se houver alguma violação de conformidade.
O diagrama a seguir mostra um fluxo de trabalho comum em que o pipeline de implantação é acionado com base em uma confirmação que inclui alterações de infraestrutura.
No diagrama anterior, as alterações de infraestrutura são aplicadas a um ambiente de teste ou de preparo e, em seguida, os testes de Chef InSpec são executados nesse ambiente. Se todas as verificações do Chef InSpec forem compatíveis, será possível mesclar e aplicar as alterações de infraestrutura ao ambiente de produção, e os testes do Chef InSpec serão executados novamente no ambiente de produção.
Esse padrão tem os seguintes benefícios:
- Os testes Chef InSpec são integrados diretamente ao processo de implantação para que as violações sejam identificadas rapidamente.
- Se os testes do Chef InSpec não forem aprovados, você poderá falhar explicitamente a implantação.
Esse padrão tem as seguintes limitações:
- Os testes Chef InSpec são diretamente integrados aos pipelines de compilação. Portanto, a equipe que gerencia seu pipeline de compilação precisa entender os testes do Chef InSpec
- Se você tiver várias compilações que exigem testes do Chef InSpec, é preciso adicionar as etapas do Chef InSpec a cada build individual, o que pode dificultar a manutenção e o dimensionamento dos esforços do Chef InSpec.
Integrar indiretamente com os pipelines de CI/CD
Esse padrão é semelhante ao padrão anterior, mas, em vez de executar diretamente os testes do Chef InSpec como uma etapa no pipeline de implantação, você executa os testes do Chef InSpec em um pipeline separado. Esse pipeline separado é acionado pelos pipelines de implantação. É possível manter a lógica do Chef InSpec separada dos pipelines de infraestrutura, mas ainda executar testes de conformidade e política como parte do fluxo de trabalho de implantação.
O Cloud Build gera automaticamente notificações de compilação quando o estado da versão for alterado. Por exemplo, quando a versão for criada, quando a versão é transferida para um estado de trabalho e quando a versão é concluída. As mensagens de notificação são publicadas em um tópico do Pub/Sub e contém informações sobre a compilação, incluindo as etapas de compilação individuais e os respectivos argumentos.
O diagrama a seguir mostra como criar um Cloud Function que é acionado automaticamente sempre que uma mensagem é publicada no tópico do Pub/Sub de notificação de versão.
No diagrama anterior, a função pode inspecionar a mensagem de notificação da compilação e, em seguida, acionar o pipeline do Chef InSpec quando necessário. Por exemplo, você quer acionar apenas o pipeline do Chef InSpec em resposta a versões bem-sucedidas que contêm etapas específicas de versão.
Esse padrão tem os seguintes benefícios:
- Os testes do Chef InSpec são independentes dos pipelines de implantação. As equipes que gerenciam os pipelines de implantação não precisam interagir com o Chef InSpec.
- É possível centralizar seus testes do Chef InSpec, facilitando a manutenção e o escalonamento dos seus esforços do Chef InSpec.
- É possível executar seletivamente os testes InSpec do Chef dependendo dos resultados e da saída das compilações upstream.
Esse padrão tem as seguintes limitações:
- Você deve escrever e manter o código para analisar e analisar as mensagens de notificação de compilação para determinar se os testes do Chef InSpec serão executados e passar parâmetros para os testes do Chef InSpec.
- As notificações do Cloud Build são publicadas em um tópico do Pub/Sub no mesmo projeto. Se você tiver versões em vários projetos, precisará implantar a Função do Cloud em cada projeto.
Acionar testes no Chef InSpec em resposta a notificações do Inventário de recursos do Cloud
O Inventário de recursos do Cloud fornece um inventário de todos os recursos do Google Cloud. O Cloud Asset Inventory pode ser usado para pesquisar, analisar e exportar os recursos e os metadados deles nos projetos, nas pastas e na organização do Google Cloud. Também é possível usar o Cloud Asset Inventory para enviar notificações em tempo real sobre alterações nos recursos e políticas da nuvem.
O diagrama a seguir mostra como executar os testes do Chef InSpec com base nas notificações do Cloud Asset Inventory.
O diagrama anterior mostra como é possível receber feedback quase em tempo real sobre quaisquer recursos de nuvem novos ou atualizados que não estejam em conformidade. É possível filtrar as notificações para que você receba notificações somente quando houver mudanças em determinados tipos de recursos. É possível usar essas notificações para acionar testes segmentados, específicos de recursos do Chef InSpec. Por exemplo, você executa um conjunto específico de testes sempre que um bucket do Cloud Storage é criado e executa um conjunto diferente de testes Chef InSpec quando uma política do IAM é atualizada.
Esse padrão tem os seguintes benefícios:
- É possível acionar testes Chef InSpec direcionados e específicos de recursos, dependendo das alterações específicas nos recursos na nuvem.
- As notificações do Cloud Asset Inventory são entregues quase em tempo real. Portanto, qualquer violação de conformidade ou política é identificada rapidamente.
- É possível usar esse padrão independentemente de qualquer processo usado para provisionar e gerenciar sua infraestrutura. Os testes Chef InSpec são executados independentemente da infraestrutura ser criada ou alterada por um desenvolvedor individual ou um pipeline de CI/CD.
- O Cloud Asset Inventory pode gerar notificações sobre alterações nos recursos de toda a organização ou de pastas ou projetos selecionados. É possível executar conjuntos específicos de testes do Chef InSpec, dependendo da pasta ou do projeto de origem da alteração.
- Você pode usar esse padrão junto com os outros padrões. Por exemplo, muitas organizações não têm implantações automatizadas para seus ambientes de desenvolvimento ou sandbox. Use esse padrão para executar verificações de políticas selecionadas nesses ambientes, ao mesmo tempo em que se integra aos pipelines de CI/CD para os ambientes de produção e de preparo.
Esse padrão tem as seguintes limitações:
- Esse padrão pode não ser prático se houver um grande volume de alterações nos recursos da nuvem porque os testes do Chef InSpec podem ser acionados por cada alteração.
- Você precisa escrever e manter o código para analisar e analisar as mensagens de notificação do Cloud Asset Inventory para determinar se executará seus testes Chef InSpec.
A seguir
- Siga as instruções do Cloud Shell para instalar rapidamente o Chef InSpec na instância do Cloud Shell e verificar a infraestrutura nos seus projetos do Google Cloud em relação ao comparativo de mercado do CIS.
- Visite a Central de recursos de conformidade do Google Cloud.
- Leia o Blueprint de bases empresariais.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.