Neste documento, descrevemos as práticas recomendadas para proteger suas implantações.
Criar e aplicar políticas de implantação
Para proteger os ambientes de execução, defina políticas com critérios para implantação e valide a conformidade com elas antes e depois da implantação. Definir uma política que permita apenas código assinado por atestadores predefinidos ajuda a bloquear implantações e implantar somente código de origens confiáveis.
Veja alguns exemplos de critérios de implantação:
- Nenhuma vulnerabilidade conhecida com gravidade acima de Medium
- 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.
- Origens do build
A procedência do build é uma coleção de dados verificáveis sobre um build, como os resumos de imagens criadas, os locais de origem de entrada, o conjunto de ferramentas e a duração dela. O SLSA, um framework para avaliar a postura de segurança, oferece um modelo de procedência e os requisitos de procedência. A procedência é uma categoria de requisitos no framework e cada requisito é associado aos níveis da SLSA para que seja possível implementar mitigações de maneira incremental.
- Para a garantia de nível 1 da 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 verificar a autenticidade e a integridade dela.
- Os níveis 3 e 4 de SLSA têm requisitos mais rigorosos para assinatura de procedência e profundidade dos detalhes dos dados de procedência.
Alguns serviços de build geram metadados de procedência da build.
- No Google Cloud, o Cloud Build gera e assina a procedência de build para imagens de contêiner compatíveis com builds SLSA de nível 3.
- O framework SLSA oferece uma ferramentas de procedência do GitHub. As ferramentas geram uma procedência não forgável da SLSA no GitHub, que atende aos requisitos nas categorias build e provenance para o nível 3 da SLSA.
- O projeto de código aberto sigstore inclui a ferramenta cosign para assinar contêineres.
- Vulnerabilidades
O software de verificação de vulnerabilidades confere o código-fonte e cria artefatos em busca de vulnerabilidades conhecidas. O Artifact Analysis pode verificar automaticamente imagens de contêiner enviadas ao Artifact Registry em busca de vulnerabilidades. Para verificar se há vulnerabilidades nos artefatos antes de armazená-las, use a API On-Demand Scanning em um ambiente de desenvolvimento local ou em um pipeline de CI/CD, como uma etapa de criação 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 suas políticas.
No Google Cloud, é possível configurar uma política em autorização binária para suas implantações. A autorização binária aplica a política para tentativas de implantação em plataformas compatíveis com contêineres. Ele também executa a validação contínua da política para cargas de trabalho em execução no GKE, no Cloud Run e no GKE Enterprise.
As verificações pré-implantação podem bloquear todas as imagens que não estão na lista de imagens isentas. Dessa maneira, apenas imagens confiáveis são implantadas a partir de registros confiáveis. A política também pode exigir attestations, documentos digitais que significam que a imagem foi criada com um processo específico necessário. Por exemplo, um atestado pode indicar que uma imagem:
- Criado 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, é possível adicioná-las a uma lista de permissões.
A validação contínua estende a validação da política para o ambiente pós-implantação. Quando ativada, a autorização binária fornece validação ao longo de todo o ciclo de vida do pod, registrando regularmente a conformidade com a política no Cloud Logging. Isso é útil em diversas situações. Por exemplo, se você alterar sua política depois de implantar um contêiner, a validação contínua registrará os pods que violam a política atualizada. Ele também registra violações de política para pods implantados com simulação ou implantação.
Usar serviços de implantação controlados
Com o bloqueio de implantação, você pode aprovar ou negar implantações em pontos específicos do processo de implantação usando um serviço de CI/CD autônomo ou integrado a um sistema de automação de processos. As implantações restritas impedem que usuários não autorizados façam alterações nos ambientes do aplicativo. Elas oferecem uma supervisão adicional para o 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 controlada permite que os usuários especifiquem se uma aprovação é necessária para a promoção a um destino.
Monitore suas cargas de trabalho
As cargas de trabalho são aplicativos executados em plataformas baseadas em contêineres, como GKE e Cloud Run. As cargas de trabalho implantadas precisam ter uma configuração reforçada que limite a superfície de ataque.
Verificar cargas de trabalho entre clusters em busca de problemas de configuração pode ser difícil de fazer manualmente em escala. O Software Delivery Shield é uma solução de segurança da cadeia de suprimentos de software totalmente gerenciada no Google Cloud que oferece painéis no Cloud Run e na interface do GKE no console do Google Cloud para conferir insights de segurança para cargas de trabalho.
O painel de postura de segurança do GKE fornece orientações para fortalecer a postura de segurança dos seus clusters com base nas recomendações do Google. Ela inclui a verificação automática da configuração da carga de trabalho, que confere se há problemas de configuração conhecidos em todas as cargas de trabalho. O GKE verifica cada carga de trabalho implantada em relação às 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 uma trilha auditável de preocupações 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 ver insights de segurança.
O Cloud Run contém um painel de segurança que exibe insights sobre a segurança da cadeia de suprimentos de software, como informações de conformidade no nível da versão SLSA, experiência de compilação e vulnerabilidades encontradas nos serviços em execução. Para instruções sobre como visualizar insights de segurança no painel de insights de segurança do Cloud Run, consulte Implantar no Cloud Run e ver insights de segurança.
O Software Delivery Shield também oferece outros serviços e recursos para melhorar sua postura de segurança durante o ciclo de vida de desenvolvimento de software. Para mais informações, consulte Visão geral do Software Delivery Shield.
A seguir
- Conheça 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.