Projetar pipelines de implantação seguros

Last reviewed 2023-09-28 UTC

Um pipeline de implantação é um processo automatizado que usa código ou artefatos pré-criados e os implanta em um ambiente de teste ou de produção. Os pipelines de implantação são comumente usados para implantar aplicativos, configurações ou infraestrutura em nuvem (infraestrutura como código) e podem desempenhar um papel importante na postura geral de segurança de uma implantação na nuvem.

Este guia é destinado a engenheiros de DevOps e segurança e descreve as práticas recomendadas para projetar pipelines de implantação seguros com base nos requisitos de confidencialidade, integridade e disponibilidade.

Arquitetura

O diagrama a seguir mostra o fluxo de dados em um pipeline de implantação. Ele ilustra como transformar artefatos em recursos.

O artefato flui para um pipeline de implantação e sai um recurso.

Os pipelines de implantação costumam fazer parte de um fluxo de trabalho maior de integração/implantação contínua (CI/CD) e costumam ser implementados usando um dos seguintes modelos:

Modelo de push:nesse modelo, o pipeline de implantação é implementado usando um sistema de CI/CD central, como o Jenkins ou GitLab. Esse sistema de CI/CD pode ser executado no Google Cloud, no local ou em um ambiente de nuvem diferente. Muitas vezes, o mesmo sistema de CI/CD é usado para gerenciar vários pipelines de implantação.

O modelo de push leva a uma arquitetura centralizada com alguns sistemas de CI/CD usados para gerenciar um número potencialmente grande de recursos ou aplicativos. Por exemplo, é possível usar uma única instância do Jenkins ou GitLab para gerenciar todo o ambiente de produção, incluindo todos os seus projetos e aplicativos.
Modelo pull: nesse modelo, o processo de implantação é implementado por um agente que é implantado com o recurso, por exemplo, no mesmo Kubernetes. O agente extrai artefatos ou código-fonte de um local centralizado e os implanta localmente. Cada agente gerencia um ou dois recursos.

O modelo de pull leva a uma arquitetura mais descentralizada com um número potencialmente grande de agentes de finalidade única.

Em comparação com implantações manuais, o uso consistente de pipelines de implantação pode ter os seguintes benefícios:

Maior eficiência, porque não é necessário trabalho manual.
Maior confiabilidade, porque o processo é totalmente automatizado e pode ser repetido.
Maior rastreabilidade, porque é possível rastrear todas as implantações até alterações no código ou artefatos de entrada.

Para executar, um pipeline de implantação requer acesso aos recursos que gerencia:

Um pipeline que implanta infraestrutura usando ferramentas como o Terraform pode precisar criar, modificar ou até mesmo excluir recursos como instâncias de VM, sub-redes ou buckets do Cloud Storage.
Um pipeline que implanta aplicativos pode precisar fazer upload de novas imagens de contêiner no Artifact Registry e implantar novas versões de aplicativos no App Engine, no Cloud Run ou o Google Kubernetes Engine (GKE).
Um pipeline que gerencia configurações ou implanta arquivos de configuração pode precisar modificar metadados de instâncias de VM e configurações do Kubernetes ou modificar dados no Cloud Storage.

Se os pipelines de implantação não estiverem devidamente protegidos, o acesso deles aos recursos do Google Cloud poderá se tornar um ponto fraco na postura de segurança. A segurança enfraquecida pode levar a vários tipos de ataque, incluindo:

Ataques de envenenamento de pipeline: em vez de atacar um recurso diretamente, um usuário de má-fé pode tentar comprometer o pipeline de implantação, a configuração ou a infraestrutura subjacente. Aproveitando o acesso do pipeline ao Google Cloud, o usuário de má-fé pode fazer com que o pipeline execute ações maliciosas nos recursos do Cloud, conforme mostrado no diagrama a seguir:
Ataques à cadeia de suprimentos: em vez de atacar o pipeline de implantação, um usuário de má-fé pode tentar comprometer ou substituir a entrada do pipeline, incluindo código-fonte, bibliotecas ou imagens de contêiner, conforme mostrado em diagrama a seguir.

Para determinar se os pipelines de implantação estão protegidos adequadamente, basta analisar apenas as políticas de permissão e negação dos recursos do Google Cloud de forma isolada. Em vez disso, você precisa considerar o gráfico inteiro de sistemas que concedem acesso direta ou indiretamente a um recurso. Esse gráfico inclui as seguintes informações:

O pipeline de implantação, o sistema de CI/CD e a infraestrutura subjacentes
O repositório do código-fonte, os servidores e a infraestrutura subjacentes.
Artefatos de entrada, locais de armazenamento e infraestrutura subjacente
Sistemas que produzem os artefatos de entrada e a infraestrutura deles

Gráficos de entrada complexos dificultam a identificação do acesso do usuário a recursos e fraquezas sistêmicas.

As seções a seguir descrevem as práticas recomendadas para projetar pipelines de implantação que ajudam a gerenciar o tamanho do gráfico e reduzir o risco de movimentos laterais e ataques à cadeia de suprimentos.

Avaliar os objetivos de segurança

A sensibilidade dos seus recursos no Google Cloud provavelmente varia. Alguns recursos podem ser altamente confidenciais porque são essenciais para os negócios ou confidenciais. Outros recursos podem ser menos confidenciais por serem temporários ou destinados apenas para fins de teste.

Para projetar um pipeline de implantação seguro, é necessário primeiro entender os recursos que o pipeline precisa acessar e a importância desses recursos. Quanto mais confidenciais forem os recursos, mais você precisará se concentrar na proteção do pipeline.

Os recursos acessados por pipelines de implantação podem incluir:

Aplicativos, como o Cloud Run ou o App Engine
Recursos do Cloud, como instâncias de VM ou buckets do Cloud Storage
Dados, como objetos do Cloud Storage, registros do BigQuery ou arquivos

Alguns desses recursos podem ter dependências de outros recursos, como por exemplo:

Os aplicativos podem acessar dados, recursos da nuvem e outros aplicativos.
Os recursos do Cloud, como instâncias de VM ou buckets do Cloud Storage, podem conter aplicativos ou dados.

Conforme mostrado no diagrama anterior, as dependências afetam a sensibilidade de um recurso. Por exemplo, se você usa um aplicativo que acessa dados altamente confidenciais, normalmente trate esse aplicativo como altamente confidencial. Da mesma forma, se um recurso de nuvem, como um bucket do Cloud Storage, contiver dados confidenciais, trate o bucket como confidencial.

Devido a essas dependências, é melhor avaliar primeiro a sensibilidade dos seus dados. Depois de avaliar seus dados, é possível examinar a cadeia de dependências e avaliar a sensibilidade dos seus recursos e aplicativos do Cloud.

Categorizar a confidencialidade dos dados

Para entender a confidencialidade dos dados no pipeline de implantação, considere estes três objetivos:

Confidencialidade: você precisa proteger os dados contra acesso não autorizado.
Integridade: você precisa proteger os dados contra modificações ou exclusões não autorizadas.
Disponibilidade: é preciso garantir que pessoas e sistemas autorizados possam acessar os dados no pipeline de implantação.

Para cada um desses objetivos, pergunte a si mesmo o que aconteceria se o pipeline fosse violado:

Confidencialidade:qual seria o nível de danos se os dados fossem divulgados a um usuário de má-fé ou vazados para o público?
Integridade:qual seria o nível de danos se os dados fossem modificados ou excluídos por um usuário de má-fé?
Disponibilidade: qual seria o nível de danos se um usuário de má-fé interrompia o acesso aos dados?

Para tornar os resultados comparáveis entre recursos, é útil introduzir categorias de segurança. Os Padrões para categorização de segurança (FIPS-199) sugerem o uso das quatro categorias a seguir:

Alto: o dano seria grave ou catastrófico.
Moderado: o dano seria grave.
Baixo: o dano seria limitado
Não relevante: o padrão não se aplica.

Dependendo do ambiente e do contexto, um conjunto diferente de categorias pode ser mais apropriado.

A confidencialidade e a integridade dos dados de pipeline existem em um espectro baseado nas categorias de segurança discutidas. As subseções a seguir contêm exemplos de recursos com diferentes medidas de confidencialidade e integridade:

Recursos com baixa confidencialidade, mas integridade baixa, moderada e alta

Todos os exemplos de recursos a seguir têm baixa confidencialidade:

Baixa integridade:dados de teste
Integridade moderada: conteúdo do servidor da Web público, restrições de política para sua organização
Alta integridade: imagens de contêiner, imagens de disco, configurações de aplicativos, políticas de acesso (listas de permissão e negação), garantias e dados no nível de acesso.

Recursos com confidencialidade média, mas integridade baixa, moderada e alta

Todos os exemplos de recursos a seguir têm confidencialidade média:

Baixa integridade: conteúdo interno do servidor da Web
Integridade moderada: registros de auditoria
Alta integridade: arquivos de configuração do aplicativo

Recursos com alta confidencialidade, mas integridade baixa, moderada e alta

Todos os exemplos de recursos a seguir têm alta confidencialidade:

Baixa integridade: dados de uso e informações de identificação pessoal
Integridade moderada: secrets
Alta integridade: dados financeiros e chaves do KMS

Categorizar aplicativos com base nos dados que eles acessam

Quando um aplicativo acessa dados confidenciais, tanto o aplicativo quanto o pipeline de implantação que o gerencia também podem se tornar confidenciais. Para qualificar essa sensibilidade, observe os dados que o aplicativo e o pipeline precisam acessar.

Depois de identificar e categorizar todos os dados acessados por um aplicativo, use as categorias a seguir para categorizar inicialmente o aplicativo antes de projetar um pipeline de implantação seguro:

Confidencialidade: categoria mais alta de todos os dados acessados.
Integridade: categoria mais alta de todos os dados acessados
Disponibilidade: a categoria mais alta de todos os dados acessados

Esta avaliação inicial fornece orientação, mas pode haver outros fatores a serem considerados, por exemplo:

Dois conjuntos de dados podem ter baixa confidencialidade de forma isolada. Mas, quando combinadas, elas podem revelar novos insights. Se um aplicativo tiver acesso aos dois conjuntos de dados, talvez seja necessário categorizá-lo como confidencialidade média ou alta.
Se um aplicativo tiver acesso a dados de alta integridade, ele normalmente será categorizado como de alta integridade. No entanto, se esse acesso for somente leitura, uma categorização de alta integridade poderá ser muito rigorosa.

Para mais detalhes sobre uma abordagem formalizada para categorizar aplicativos, consulte o Guia para mapeamento de tipos de sistemas de informação e da informação para categorias de segurança (NIST SP 800-60 Vol. 2 Rev1).

Categorizar recursos da nuvem com base nos dados e aplicativos que eles hospedam

Todos os dados ou aplicativos que você implanta no Google Cloud são hospedados por um recurso do Google Cloud:

Um aplicativo pode ser hospedado por um serviço do App Engine, uma instância de VM ou um cluster do GKE.
Os dados podem ser hospedados por um disco permanente, um bucket do Cloud Storage ou um conjunto de dados do BigQuery.

Quando um recurso de nuvem hospeda dados ou aplicativos confidenciais, o recurso e o pipeline de implantação que o gerencia também podem se tornar confidenciais. Por exemplo, considere um serviço do Cloud Run e o pipeline de implantação dele como tão confidenciais quanto o aplicativo que ele está hospedando.

Depois de categorizar os dados e os aplicativos, crie uma categoria de segurança inicial para o aplicativo. Para fazer isso, determine um nível entre as seguintes categorias:

Confidencialidade: categoria mais alta de quaisquer dados ou aplicativos hospedados
Integridade: categoria mais alta de todos os dados ou aplicativos hospedados
Disponibilidade: a categoria mais alta de qualquer dado ou aplicativo hospedado

Ao fazer sua avaliação inicial, não seja muito rigoroso, por exemplo:

Se você criptografar dados altamente confidenciais, trate a chave de criptografia como altamente confidencial. Mas você pode usar uma categoria de segurança mais baixa para o recurso que contém os dados.
Se você armazena cópias redundantes de dados ou executa instâncias redundantes dos mesmos aplicativos em vários recursos, é possível tornar a categoria do recurso menor que a categoria dos dados ou do aplicativo que ele hospeda.

Restringir o uso de pipelines de implantação

Se o pipeline de implantação precisar acessar recursos confidenciais do Google Cloud, considere a postura de segurança dele. Quanto mais sensíveis forem os recursos, melhor será a tentativa de proteger o pipeline. No entanto, você pode encontrar as seguintes limitações práticas:

Ao usar a infraestrutura atual ou um sistema de CI/CD atual, essa infraestrutura pode restringir o nível de segurança que você pode alcançar de forma realista. Por exemplo, seu sistema de CI/CD pode oferecer suporte apenas a um conjunto limitado de controles de segurança ou pode estar sendo executado em uma infraestrutura que você considera menos segura do que alguns dos ambientes de produção.
Ao configurar uma nova infraestrutura e sistemas para executar o pipeline de implantação, proteger todos os componentes de uma maneira que atenda aos requisitos de segurança mais rigorosos pode não ser econômico.

Para lidar com essas limitações, pode ser útil definir restrições sobre quais cenários podem ou não usar pipelines de implantação e um sistema de CI/CD específico. Por exemplo, as implantações mais confidenciais costumam ser mais bem tratadas fora de um pipeline de implantação. Essas implantações podem ser manuais, usando um sistema de gerenciamento de sessão privilegiado, um sistema de gerenciamento de acesso privilegiado ou algo diferente, como proxies de ferramentas.

Para definir restrições, defina quais controles de acesso você quer aplicar com base nas categorias de recursos. Considere as orientações oferecidas na tabela a seguir:

Categoria do recurso	Controles de acesso
Baixa	Não é necessária aprovação
Moderada	O líder da equipe precisa aprovar
Alta	Vários leads devem ser aprovados e as ações precisam ser registradas

Para comparar esses requisitos com os recursos dos sistemas de gerenciamento de código-fonte (SCM, na sigla em inglês) e de CI/CD, faça as seguintes perguntas:

Os sistemas SCM ou CI/CD são compatíveis com os controles de acesso e os mecanismos de aprovação necessários?
Os controles estão protegidos contra subvertidos caso alguém ataque a infraestrutura subjacente?
A configuração que define os controles está devidamente protegida?

Dependendo dos recursos e das limitações impostas pelos sistemas SCM ou CI/CD, é possível definir as restrições de dados e aplicativos para os pipelines de implantação. Considere as orientações oferecidas na tabela a seguir:

Categoria do recurso	Restrições
Baixa	Os pipelines de implantação podem ser usados, e os desenvolvedores podem aprovar as implantações.
Moderada	Os pipelines de implantação podem ser usados, mas um líder de equipe precisa aprovar cada confirmação e implantação.
Alta	Não use pipelines de implantação. Em vez disso, os administradores precisam usar um sistema de gerenciamento de acesso privilegiado e a gravação de sessões.

Manter a disponibilidade de recursos

O uso de um pipeline de implantação para gerenciar recursos pode afetar a disponibilidade desses recursos e introduzir novos riscos:

Causar interrupções: um pipeline de implantação pode enviar arquivos de configuração ou código defeituosos, causando a falha de um sistema anteriormente em funcionamento ou fazendo com que os dados se tornem inutilizáveis.
Prolongar interrupções: para corrigir uma interrupção temporária, talvez seja necessário executar novamente um pipeline de implantação. Se o pipeline de implantação estiver corrompido ou indisponível por outros motivos, isso pode prolongar a interrupção.

Um pipeline que pode causar ou prolongar interrupções representa um risco de negação de serviço: um usuário de má-fé pode usar o pipeline de implantação para causar uma interrupção intencionalmente.

Criar procedimentos de acesso de emergência

Quando um pipeline de implantação é a única maneira de implantar ou configurar um aplicativo ou recurso, a disponibilidade do pipeline pode se tornar crítica. Em casos extremos, em que um pipeline de implantação é a única maneira de gerenciar um aplicativo essencial para os negócios, talvez seja necessário considerar o pipeline de implantação como essencial para os negócios.

Como os pipelines de implantação geralmente são feitos de vários sistemas e ferramentas, manter um alto nível de disponibilidade pode ser difícil ou antieconômico.

É possível reduzir a influência dos pipelines de implantação na disponibilidade criando procedimentos de acesso de emergência. Por exemplo, crie um caminho de acesso alternativo que possa ser usado se o pipeline de implantação não estiver operacional.

A criação de um procedimento de acesso de emergência normalmente requer a maioria dos processos abaixo:

Mantenha uma ou mais contas de usuário com acesso privilegiado a recursos relevantes do Google Cloud.
Armazene as credenciais das contas de usuário com acesso de emergência em um local seguro ou use um sistema de gerenciamento de acesso privilegiado para intermediar o acesso.
Estabeleça um procedimento que funcionários autorizados possam seguir para acessar as credenciais.
Audite e analise o uso de contas de usuário para acesso de emergência.

Verifique se os artefatos de entrada atendem às demandas de disponibilidade

Os pipelines de implantação geralmente precisam fazer o download do código-fonte de um repositório central antes de executar uma implantação. Se o repositório de código-fonte não estiver disponível, a execução do pipeline de implantação provavelmente falhará.

Muitos pipelines de implantação também dependem de artefatos de terceiros. Esses artefatos podem incluir bibliotecas de origens como npm, Maven Central ou a Galeria NuGet, assim como imagens de base de contêiner e pacotes .deb e .rpm. Se uma das origens de terceiros estiver indisponível, a execução do pipeline de implantação poderá falhar.

Para manter um determinado nível de disponibilidade, é preciso garantir que todos os artefatos de entrada do pipeline de implantação atendam aos mesmos requisitos ou a requisitos de disponibilidade maiores. A lista a seguir pode ajudar a garantir a disponibilidade dos artefatos de entrada:

Limite o número de origens de artefatos de entrada, especialmente fontes de terceiros.
manter um cache de artefatos de entrada que os pipelines de implantação possam usar se os sistemas de origem estiverem indisponíveis;

Trate os pipelines de implantação e a infraestrutura deles como sistemas de produção

Os pipelines de implantação geralmente servem como o tecido conjuntivo entre os ambientes de desenvolvimento, preparação e produção. Dependendo do ambiente, eles podem implementar vários estágios:

Na primeira etapa, o pipeline de implantação atualiza um ambiente de desenvolvimento.
No próximo estágio, o pipeline de implantação atualiza um ambiente de preparação.
No estágio final, o pipeline de implantação atualiza o ambiente de produção.

Ao usar um pipeline de implantação em vários ambientes, verifique se ele atende às demandas de disponibilidade de cada ambiente. Como os ambientes de produção geralmente têm as demandas de disponibilidade mais altas, trate o pipeline de implantação e a infraestrutura subjacente dele como um sistema de produção. Em outras palavras, aplique os mesmos padrões de controle de acesso, segurança e qualidade dos sistemas de produção à infraestrutura que executa seus pipelines de implantação.

Limitar o escopo dos pipelines de implantação

Quanto mais recursos um pipeline de implantação puder acessar, mais danos ele poderá causar se for comprometido. Um pipeline de implantação comprometido com acesso a vários projetos ou até mesmo a toda a organização pode, na pior das hipóteses, causar danos duradouros a todos os dados e aplicativos no Google Cloud.

Para evitar esse pior cenário, limite o escopo dos pipelines de implantação. Defina o escopo de cada pipeline de implantação para que ele precise acessar apenas um número relativamente pequeno de recursos no Google Cloud:

Em vez de conceder acesso no nível do projeto, conceda apenas aos pipelines de implantação acesso a recursos individuais.
Evite conceder acesso a recursos em vários projetos do Google Cloud.
Divida os pipelines de implantação em vários estágios se eles precisarem de acesso a vários projetos ou ambientes. Em seguida, proteja as etapas individualmente.

Manter a confidencialidade

Um pipeline de implantação precisa manter a confidencialidade dos dados que gerencia. Um dos principais riscos relacionados à confidencialidade é a exfiltração de dados.

Há várias maneiras que um usuário de má-fé pode tentar usar um pipeline de implantação para exfiltrar dados dos recursos do Google Cloud. Elas incluem:

Direto: um usuário de má-fé pode modificar o pipeline de implantação ou a configuração dele para extrair dados dos recursos do Google Cloud e copiá-los para outro lugar.
Indireto: um usuário de má-fé pode usar o pipeline de implantação para implantar um código comprometido, que depois rouba dados do ambiente do Google Cloud.

É possível diminuir os riscos de confidencialidade ao minimizar o acesso a recursos confidenciais. No entanto, remover todo o acesso a recursos confidenciais pode não ser prático. Portanto, projete seu pipeline de implantação para atender às demandas de confidencialidade dos recursos que ele gerencia. Para determinar essas demandas, use a seguinte abordagem:

Determinar os dados, aplicativos e recursos que o pipeline de implantação precisa acessar e categorizá-los.
Encontre o recurso com a categoria de confidencialidade mais alta e use-o como uma categoria inicial para o pipeline de implantação.

Assim como o processo de categorização de aplicativos e recursos da nuvem, essa avaliação inicial nem sempre é apropriada. Por exemplo, é possível usar um pipeline de implantação para criar recursos que eventualmente conterão informações altamente confidenciais. Se você restringir o pipeline de implantação para que ele possa criar, mas não ler, esses recursos, uma categoria de confidencialidade mais baixa poderá ser suficiente.

Para manter a confidencialidade, o modelo Bell-LaPadula sugere que um pipeline de implantação não pode:

Consumir artefatos de entrada de maior confidencialidade
Gravar dados em um recurso de menor confidencialidade

O modelo Bell-LaPadula.

De acordo com o modelo Bell-LaPadula, o diagrama anterior mostra como os dados precisam fluir no pipeline para ajudar a garantir a confidencialidade dos dados.

Não permita que os pipelines de implantação leiam os dados de que não precisam

Os pipelines de implantação geralmente não precisam de acesso aos dados, mas ainda podem ter esse acesso. Essa concessão de acesso excessiva pode ocorrer devido a:

Concedendo permissões de acesso incorretas. Por exemplo, um pipeline de implantação pode receber acesso ao Cloud Storage no nível do projeto. Como resultado, o pipeline de implantação pode acessar todos os buckets do Cloud Storage no projeto, embora o acesso a um único bucket possa ser suficiente.
Usar um papel excessivamente permissivo. Um pipeline de implantação pode receber um papel que fornece acesso total ao Cloud Storage, por exemplo. No entanto, a permissão para criar novos buckets seria suficiente.

Quanto mais dados um pipeline puder acessar, maior será o risco de que alguém ou algo possa roubar seus dados. Para minimizar esse risco, evite conceder aos pipelines de implantação acesso a dados desnecessários. Muitos pipelines de implantação não precisam de acesso a dados, porque o único propósito deles é gerenciar configurações ou implantações de software.

Não permita que os pipelines de implantação gravem em locais de que não precisam

Para remover dados, um usuário de má-fé precisa de acesso e de uma maneira de transferir os dados para fora do ambiente. Quanto mais locais de armazenamento e rede um pipeline de implantação puder enviar dados, maior será a probabilidade de um usuário de má-fé usar um desses locais para exfiltração.

É possível reduzir o risco limitando o número de locais de rede e armazenamento a que um pipeline pode enviar dados:

Revogue o acesso de gravação a recursos que não são necessários para o pipeline, mesmo que os recursos não contenham dados confidenciais.
Bloquear o acesso à Internet ou restringir conexões a um conjunto de locais de rede autorizados.

Restringir o acesso de saída é particularmente importante para pipelines que você classificou como moderadamente confidenciais ou altamente confidenciais porque eles têm acesso a dados confidenciais ou material de chave criptográfica.

Usar o VPC Service Controls para impedir que implantações comprometidas roubem dados

Em vez de permitir que o pipeline de implantação execute a exfiltração de dados, alguém de má-fé pode tentar usá-lo para implantar o código comprometido. Esse código comprometido pode roubar dados do seu ambiente do Google Cloud.

É possível reduzir o risco dessas ameaças de roubo de dados usando o VPC Service Controls. O VPC Service Controls permite restringir o conjunto de recursos e APIs que podem ser acessados em determinados projetos do Google Cloud.

Manter a integridade

Para manter seu ambiente do Google Cloud seguro, você precisa proteger a integridade dele. Isso inclui:

Impedir a modificação ou exclusão não autorizada de dados ou configuração
Como impedir que códigos ou configurações não confiáveis sejam implantados
Garantir que todas as alterações deixem uma trilha de auditoria clara

Os pipelines de implantação ajudam a manter a integridade do ambiente, permitindo que você:

Implementar processos de aprovação, por exemplo, na forma de revisões de código
Aplique um processo consistente para todas as alterações de configuração ou código
Execute testes automatizados ou verificações rápidas antes de cada implantação

Para ser eficaz, você precisa tentar garantir que usuários de má-fé não possam prejudicar ou desviar essas medidas. Para evitar essas atividades, é necessário proteger a integridade dos itens a seguir:

O pipeline de implantação e sua configuração
A infraestrutura subjacente
Todas as entradas consumidas pelo pipeline de implantação

Para evitar que o pipeline de implantação fique vulnerável, tente garantir que os padrões de integridade do pipeline de implantação correspondam ou excedam as demandas de integridade dos recursos que ele gerencia. Para determinar essas demandas, use a seguinte abordagem:

Determinar os dados, aplicativos e recursos que o pipeline de implantação precisa acessar e categorizá-los.
Encontre o recurso com a categoria de integridade mais alta e use-o como a categoria para o pipeline de implantação.

Para manter a integridade do pipeline de implantação, o modelo BIB sugere o seguinte:

O pipeline de implantação não pode consumir artefatos de entrada de menor integridade.
O pipeline de implantação não pode gravar dados em um recurso de maior integridade.

O modelo de integridade Biba.

De acordo com o modelo Biba, o diagrama anterior mostra como os dados precisam fluir no pipeline para ajudar a garantir a integridade dos dados.

Verificar a autenticidade dos artefatos de entrada

Muitos pipelines de implantação consomem artefatos de fontes de terceiros. Esses artefatos podem incluir:

Imagens de base do Docker
Pacotes .rpm ou .deb
Bibliotecas Maven, .npm ou NuGet

Um usuário de má-fé pode tentar modificar o pipeline de implantação para que ele use versões comprometidas de artefatos de terceiros por meio de:

Comprometer o repositório que armazena os artefatos
modificar a configuração do pipeline de implantação para usar um repositório de origem diferente;
Fazer upload de pacotes maliciosos com nomes semelhantes ou que contêm erros de digitação

Muitos gerenciadores de pacotes permitem verificar a autenticidade de um pacote oferecendo suporte à assinatura de código. Por exemplo, é possível usar o PGP para assinar pacotes RPM e Maven. Você pode usar o Authenticode para assinar pacotes NuGet.

É possível usar a assinatura de código para reduzir o risco de ser vítima de pacotes de terceiros comprometidos:

Como exigir que todos os artefatos de terceiros sejam assinados
Manter uma lista selecionada de chaves públicas ou certificados do editor confiável
permitir que o pipeline de implantação verifique a assinatura de artefatos de terceiros em relação à lista de editores confiáveis;

Também é possível verificar os hashes dos artefatos. Você pode usar essa abordagem para artefatos que não oferecem suporte à assinatura de código e mudam com pouca frequência.

Garanta que a infraestrutura atende às suas demandas de integridade

Em vez de comprometer o próprio pipeline de implantação, usuários de má-fé podem tentar comprometer a infraestrutura dele, incluindo:

O software de CI/CD que executa o pipeline de implantação
As ferramentas usadas pelo pipeline, por exemplo, Terraform, kubectl ou Docker
O sistema operacional e todos os seus componentes

Como a infraestrutura que sustenta os pipelines de implantação costuma ser complexa e pode conter componentes de vários fornecedores ou origens, esse tipo de violação de segurança pode ser difícil de detectar.

É possível ajudar a reduzir o risco de infraestrutura comprometida das seguintes maneiras:

Manter a infraestrutura e todos os componentes nos mesmos padrões de integridade do pipeline de implantação e dos recursos do Google Cloud que ele gerencia
Garantir que as ferramentas venham de uma fonte confiável e verificar a autenticidade delas
Reconstruir regularmente a infraestrutura do zero
Como executar o pipeline de implantação em VMs protegidas

Aplicar controles de integridade no pipeline

Os usuários de má-fé são uma ameaça, mas não são a única possível fonte de alterações de software ou configuração que podem prejudicar a integridade do ambiente do Google Cloud. Essas mudanças também podem se originar de desenvolvedores e simplesmente serem acidentais, devido ao não reconhecimento ou a erros de digitação e outros erros.

Para reduzir o risco de aplicar inadvertidamente mudanças arriscadas, configure pipelines de implantação para aplicar outros controles de integridade. Esses controles podem incluir:

Realizar análise estática do código e da configuração
Exigência de todas as mudanças para transmitir um conjunto de regras (política como código)
Limitar o número de mudanças que podem ser feitas ao mesmo tempo

A seguir

Saiba mais sobre nossas práticas recomendadas para usar contas de serviço nos pipelines de implantação.
Consulte nossas práticas recomendadas para proteger contas de serviço.
Saiba mais sobre como investigar e responder a ameaças.
Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.