Este documento descreve as práticas recomendadas para proteger suas implantações.
Criar e aplicar políticas de implantação
Para proteger seus ambientes de execução, defina políticas com critérios de implantação e valide a conformidade da política antes e depois da implantação. Definir uma política que permita apenas códigos assinados por certificadores predefinidos ajuda a bloquear implantações e implantar apenas códigos de origens confiáveis.
Exemplos de critérios de implantação incluem:
- Nenhuma vulnerabilidade conhecida com gravidade acima de média
- O código-fonte é de um repositório de origem confiável
- Um serviço de build confiável executou o build
- Os artefatos de build que você está implantando são de um repositório de artefatos confiável
Gerar metadados
Para validar esses requisitos, você precisa fornecer metadados sobre seus artefatos de build.
- Criar origens
A procedência do build é uma coleção de dados verificáveis sobre um build, como os resumos das imagens criadas, os locais da origem de entrada, a cadeia de ferramentas de build e a duração do build. A SLSA, um framework para avaliar a postura de segurança, fornece um modelo de procedência e requisitos de procedência. A procedência é uma categoria de requisito no framework, e cada requisito é associado aos níveis do SLSA para que você possa implementar mitigações de forma incremental.
- Para a garantia de nível 1 do SLSA, a procedência precisa estar disponível.
- Para a garantia de nível 2 da SLSA, a procedência precisa ser gerada, e os consumidores precisam poder verificar a autenticidade e a integridade.
- Os níveis 3 e 4 do SLSA têm requisitos mais rigorosos para assinatura de procedência e detalhes de dados de procedência.
Alguns serviços de build geram metadados de procedência do build.
- No Google Cloud, o Cloud Build gera e assina a procedência de build para imagens de contêiner que oferecem suporte a builds SLSA de nível 3.
- O framework SLSA oferece ferramentas de procedência do GitHub. As ferramentas geram procedência de SLSA não falsificável no GitHub que atenda aos requisitos nas categorias build e provenance para o nível 3 do SLSA.
- O projeto de código aberto sigstore inclui a ferramenta cosign para assinatura de contêineres.
- Vulnerabilidades
O software de verificação de vulnerabilidades verifica seu código-fonte e cria artefatos para vulnerabilidades conhecidas. O Artifact Analysis pode verificar automaticamente vulnerabilidades em imagens de contêiner enviadas para o Artifact Registry. Para verificar se há vulnerabilidades em artefatos antes de armazená-los, use a API On-Demand Scanning em um ambiente de desenvolvimento local ou em um pipeline de CI/CD, como uma etapa de build do Cloud Build.
Configurar a aplicação de políticas
Depois de ter metadados sobre os artefatos implantáveis, você precisa de ferramentas para aplicar as políticas.
No Google Cloud, é possível configurar uma política na Autorização binária para suas implantações. A autorização binária aplica a política para tentativas de implantações em plataformas com suporte baseadas em contêiner. Ele também pode realizar a validação contínua da política para cargas de trabalho executadas no GKE, Cloud Run e GKE Enterprise.
As verificações antes da implantação podem bloquear todas as imagens que não estão na lista de imagens isentas, para que apenas imagens confiáveis sejam implantadas de registros confiáveis. Sua política também pode exigir atestados, documentos digitais que indicam que a imagem foi criada com sucesso usando um processo específico necessário. Por exemplo, um atestado pode indicar que uma imagem é:
- Criadas pelo Cloud Build.
- Não contém vulnerabilidades acima de uma gravidade especificada. Se houver vulnerabilidades específicas que não se aplicam aos seus aplicativos, adicione-as a uma lista de permissões.
A validação contínua estende a validação de políticas para o ambiente pós-implantação. Quando ativada, a autorização binária oferece validação em todo o ciclo de vida do pod, registrando regularmente a conformidade com a política no Cloud Logging. Isso é útil em várias situações. Por exemplo, se você mudar a política após implantar um contêiner, a validação contínua vai registrar pods que violam a política atualizada. Ele também registra violações de políticas para pods implantados com simulação ou breakglass.
Usar serviços de implantação com restrições
A restrição de implantação permite aprovar ou negar implantações em pontos específicos do processo usando um serviço de CI/CD independente ou um serviço de CI/CD integrado a um sistema de automação de processos. As implantações restritas impedem que usuários não autorizados façam mudanças nos ambientes de aplicativos. Elas oferecem mais supervisão ao processo de implantação e maior visibilidade das aprovações.
No Google Cloud, o Cloud Deploy oferece um serviço totalmente gerenciado para implantar cargas de trabalho no Google Kubernetes Engine. O recurso de implantação restrita permite que os usuários especifiquem se uma aprovação é necessária para a promoção de um destino.
Monitorar suas cargas de trabalho
Carga de trabalho são aplicativos executados em plataformas baseadas em contêineres, como o GKE e o Cloud Run. As cargas de trabalho implantadas precisam ter uma configuração reforçada que limite a superfície de ataque.
A verificação manual de cargas de trabalho em clusters pode ser difícil. O Google Cloud oferece painéis no Cloud Run e no GKE para conferir insights de segurança de cargas de trabalho.
O painel de postura de segurança do GKE oferece orientação para fortalecer a postura de segurança dos seus clusters com base nas recomendações do Google. Ele inclui a verificação automática da configuração de carga de trabalho, que verifica problemas de configuração conhecidos em todas as cargas de trabalho. O GKE verifica cada carga de trabalho implantada de acordo com as práticas recomendadas relevantes do setor, como políticas nos padrões de segurança de pods. O GKE classifica a gravidade dos problemas descobertos e retorna recomendações e registros acionáveis. Use o Cloud Logging para ter um rastro de problemas auditável para melhorar a geração de relatórios e a observabilidade. Para instruções sobre como visualizar insights de segurança no painel de postura de segurança do GKE, consulte Implantar no GKE e visualizar insights de segurança.
O Cloud Run contém um painel de segurança que mostra insights de segurança da cadeia de suprimentos de software, como as informações de compliance do nível de build da SLSA, a proveniência do build e as vulnerabilidades encontradas nos serviços em execução. Para instruções sobre como conferir insights de segurança no painel de insights de segurança do Cloud Run, consulte Implantar no Cloud Run e conferir insights de segurança.
O Google Cloud também oferece outros serviços e recursos para melhorar sua postura de segurança em todo o ciclo de vida do desenvolvimento de software. Para mais informações, consulte a visão geral da cadeia de suprimentos de software.
A seguir
- Saiba mais sobre as práticas recomendadas para proteger o código-fonte.
- Conheça as práticas recomendadas para proteger dependências.
- Conheça as práticas recomendadas para proteger builds.