Práticas recomendadas para usar contas de serviço em pipelines

Os pipelines de implementação permitem-lhe automatizar o processo de obtenção de código ou artefactos pré-criados e implementá-los num ambiente. Além disso, podem ser uma alternativa à utilização de ferramentas interativas, como a consola ou a CLI Google Cloud. Google Cloud Google Cloud

Os pipelines de implementação diferem das ferramentas interativas, como a Google Cloud consola ou a CLI gcloud, na forma como interagem com a Identity and Access Management, e tem de ter em consideração estas diferenças ao proteger os seus recursos Google Cloud.

Antes de Google Cloud lhe permitir aceder a um recurso, realiza uma verificação de acesso. Para realizar esta verificação, a IAM considera normalmente o seguinte:

  • A sua identidade e todas as políticas de limite de acesso principal associadas
  • O recurso ao qual está a tentar aceder e as respetivas políticas IAM de permissão e negação
  • O contexto do seu pedido (possivelmente, incluindo a hora e a localização)

Num pipeline de implementação, raramente chama Google Cloud APIs diretamente. Em alternativa, usa ferramentas para aceder a Google Cloud recursos. As ferramentas, como a Google Cloud consola ou a CLI gcloud, exigem que autorize primeiro a ferramenta a aceder a recursos em seu nome. Ao fornecer esta autorização, concede à ferramenta autorização para usar a sua identidade quando fizer chamadas API.

Tal como a Google Cloud consola ou a CLI gcloud, um pipeline de implementação atua em seu nome: recebe as suas alterações, expressas como código fonte, e implementa-as Google Cloud. No entanto, ao contrário da Google Cloud consola ou da CLI gcloud, um pipeline de implementação normalmente não usa a sua identidade para realizar a implementação:

  1. Normalmente, como utilizador, não interage diretamente com um pipeline de implementação. Em alternativa, interage com um sistema de controlo de origem (SCM) ao enviar alterações de código para um repositório de origem ou aprovar revisões de código.

  2. O pipeline de implementação lê as alterações de código enviadas do sistema SCM e implementa-as no Google Cloud.

    Para realizar a implementação, normalmente, o pipeline de implementação não pode usar a sua identidade porque:

    1. O código-fonte e os respetivos metadados podem não indicar que foi o autor ou as informações do autor não são invioláveis (como no caso de commits do Git não assinados)
    2. A identidade que usou para enviar o código-fonte pode ser diferente da sua identidade para Google Cloud, e não é possível mapear as duas identidades

    Por conseguinte, a maioria dos pipelines de implementação realiza implementações sob a sua própria identidade através de uma conta de serviço.

  3. Quando o pipeline de implementação acede ao Google Cloud, o IAM permite ou nega o acesso apenas com base na identidade da conta de serviço usada pelo pipeline e não na identidade da sua conta de utilizador.

Pipeline de implementação

Permitir que um pipeline de implementação use uma conta de serviço para aceder ao Google Cloud tem algumas vantagens:

  • O ciclo de vida de uma conta de serviço está desassociado do ciclo de vida das contas de utilizador. Ao configurar um pipeline para usar uma conta de serviço, garante que o código pode ser implementado mesmo que o autor do código já não esteja na sua organização.
  • Quando gere recursos através de um pipeline de implementação, não precisa de conceder aos utilizadores acesso aos recursos ou pode limitar as autorizações ao acesso só de leitura. Esta abordagem pode facilitar a gestão das políticas de permissão e negação do IAM, e permite-lhe forçar os utilizadores a usarem o pipeline de implementação para fazer todas as modificações.

No entanto, a utilização de uma conta de serviço também introduz novas ameaças. Por exemplo:

  • Roubo de identidade: um interveniente malicioso pode tentar roubar a identidade do pipeline de implementação ou roubar as respetivas credenciais para obter acesso a recursos.
  • Escalamento de privilégios: o pipeline pode ser enganado para realizar ações que não deve realizar, tornando-se efetivamente um confused deputy.
  • Não repúdio: depois de um pipeline executar uma operação, pode tornar-se difícil reconstruir por que motivo foi feita e que programador ou alteração de código a acionou.
  • Adulteração: um pipeline pode ser usado indevidamente para comprometer a integridade ou os controlos de segurança dos seus ambientes de nuvem.
  • Divulgação de informações: os intervenientes prejudiciais podem tentar usar o pipeline de implementação para roubar dados confidenciais.

Proteja-se contra ameaças de spoofing

Para conceder a uma pipeline de implementação acesso a Google Cloud, normalmente, faz o seguinte:

  1. Criar uma conta de serviço
  2. Conceda à conta de serviço acesso aos recursos necessários
  3. Configure o pipeline de implementação para usar a conta de serviço

Do ponto de vista da IAM, a conta de serviço representa o pipeline de implementação, mas o pipeline de implementação e a conta de serviço são duas entidades separadas. Se não estiver devidamente protegida, um ator malicioso pode usar a mesma conta de serviço, o que lhe permite "roubar" a identidade do pipeline de implementação.

A secção seguinte descreve as práticas recomendadas que podem ajudar a reduzir o risco de tais ameaças.

Práticas recomendadas:

Evite anexar contas de serviço a instâncias de VMs usadas por sistemas de CI/CD.
Use contas de serviço dedicadas por pipeline de implementação.
Use a federação de identidade da carga de trabalho sempre que possível.
Use os VPC Service Controls para reduzir o impacto das credenciais roubadas.

Evite anexar contas de serviço a instâncias de VM usadas por sistemas de CI/CD

Para aplicações implementadas no Compute Engine que precisam de acesso a Google Cloud recursos, é normalmente melhor anexar uma conta de serviço à instância de VM subjacente. Para sistemas de CI/CD que usam VMs do Compute Engine para executar diferentes pipelines de implementação, esta prática pode ser problemática se a mesma instância de VM puder ser usada para executar diferentes pipelines de implementação que requerem acesso a recursos diferentes.

Em vez de usar contas de serviço anexadas para permitir que os pipelines de implementação acedam aos recursos, permita que cada pipeline de implementação use uma conta de serviço separada. Evite anexar uma conta de serviço a instâncias de VMs usadas por sistemas de CI/CD ou anexe uma conta de serviço que esteja limitada ao acesso a serviços essenciais, como o Cloud Logging.

Use contas de serviço dedicadas por pipeline de implementação

Quando permite que várias pipelines de implementação usem a mesma conta de serviço, o IAM não consegue distinguir as pipelines. Os pipelines têm acesso aos mesmos recursos e os registos de auditoria podem não conter informações suficientes para determinar que pipeline de implementação acionou o acesso ou a alteração de um recurso.

Para evitar essa ambiguidade, mantenha uma relação de 1:1 entre os pipelines de implementação e as contas de serviço. Crie uma conta de serviço dedicada para cada pipeline de implementação e certifique-se de que faz o seguinte:

  • Incorpore o nome ou o ID do pipeline de implementação no endereço de email da conta de serviço. Seguir um esquema de nomenclatura consistente ajuda a determinar que contas de serviço estão associadas a que pipelines de implementação.
  • Conceda à conta de serviço acesso apenas aos recursos de que o pipeline de implementação específico precisa.

Use a Workload Identity Federation sempre que possível

Alguns sistemas de CI/CD, como o GitHub Actions ou o GitLab, permitem que os pipelines de implementação obtenham tokens compatíveis com o OpenID Connect que afirmam a identidade do pipeline de implementação. Pode permitir que os pipelines de implementação usem estes tokens para se fazerem passar por uma conta de serviço usando a Workload Identity Federation.

A utilização da Workload Identity Federation ajuda a evitar os riscos associados à utilização de chaves de contas de serviço.

Use os VPC Service Controls para reduzir o impacto das credenciais roubadas

Se um ator malicioso conseguir roubar um token de acesso ou uma chave de conta de serviço de um dos seus pipelines de implementação, pode tentar usar esta credencial e aceder aos seus recursos a partir de uma máquina diferente que controla.

Por predefinição, o IAM não tem em conta a geolocalização, o endereço IP de origem nem o projeto de origem Google Cloud quando toma decisões de acesso. Por conseguinte, uma credencial roubada pode ser utilizada a partir de qualquer lugar.

Pode impor restrições às origens a partir das quais os seus Google Cloud recursos podem ser acedidos colocando os seus projetos num perímetro de serviço da VPC e usando regras de entrada:

  • Se o pipeline de implementação for executado no Google Cloud, pode configurar uma regra de entrada para permitir apenas o acesso a partir do projeto que contém o seu sistema de CI/CD.
  • Se o pipeline de implementação for executado fora do Google Cloud, pode criar um nível de acesso que permite o acesso apenas a partir de determinadas localizações geográficas ou intervalos de IP. Em seguida, crie uma regra de entrada que permita o acesso a clientes que satisfaçam este nível de acesso.

Proteja-se contra ameaças de adulteração

Para alguns dados que armazena no Google Cloud, pode considerar particularmente importante impedir a modificação ou a eliminação não autorizada. Se a modificação ou a eliminação não autorizada for uma preocupação particular, pode caracterizar os dados como dados de alta integridade.

Para manter a integridade dos seus dados, tem de garantir que os Google Cloud recursos que usa para armazenar e gerir esses dados estão configurados em segurança e têm de manter a respetiva integridade.

Os pipelines de implementação podem ajudar a manter a integridade dos seus dados e recursos, mas também podem representar um risco: se o pipeline de um dos seus componentes não cumprir os requisitos de integridade dos recursos que gere, o pipeline de implementação transforma-se num ponto fraco que pode permitir que autores de ameaças manipulem os seus dados ou recursos.

A secção seguinte descreve as práticas recomendadas que podem ajudar a reduzir o risco de ameaças de adulteração.

Práticas recomendadas:

Evite permitir que os pipelines de implementação geram controlos de segurança.

Limite o acesso aos controlos de segurança

Para garantir a segurança e a integridade dos seus dados e recursos no Google Cloud, use controlos de segurança, como:

  • Políticas de permissão e políticas de recusa
  • Restrições de políticas da organização
  • Perímetros, níveis de acesso e políticas de entrada dos VPC Service Controls

Estes controlos de segurança são recursos por si só. A adulteração dos controlos de segurança põe em perigo a integridade dos recursos aos quais os controlos de segurança se aplicam. Como resultado, tem de considerar a integridade dos controlos de segurança, pelo menos, tão importante quanto a integridade dos recursos aos quais se aplicam.

Se permitir que um pipeline de implementação faça a gestão dos controlos de segurança, é da responsabilidade do pipeline de implementação manter a integridade dos controlos de segurança. Como resultado, tem de considerar a integridade do pipeline de implementação, pelo menos, tão importante quanto a integridade dos controlos de segurança que gere e os recursos aos quais estes controlos se aplicam.

Pode limitar o impacto de um pipeline de implementação na integridade dos seus recursos fazendo o seguinte:

  • Não conceder às condutas de implementação acesso a políticas de permissão, políticas de negação e outros controlos de segurança, e restringir o respetivo acesso a outros recursos
  • Conceder acesso apenas a controlos de segurança selecionados, como as políticas de permissão e as políticas de recusa de um recurso ou projeto específico, sem conceder acesso a controlos mais amplos que afetam vários recursos ou projetos

Se a pipeline de implementação, os respetivos componentes e a infraestrutura subjacente não conseguirem satisfazer as exigências de integridade de determinados controlos de segurança, é melhor evitar que as pipelines de implementação geram estes controlos de segurança.

Proteja-se contra ameaças de não repúdio

Em algum momento, pode reparar em atividade suspeita que afeta um dos seus recursos em Google Cloud. Nesse caso, tem de conseguir saber mais sobre a atividade e, idealmente, conseguir reconstruir a cadeia de eventos que a originou.

Os registos de auditoria do Cloud permitem-lhe saber quando os recursos foram acedidos ou modificados e que utilizadores estiveram envolvidos. Embora os registos de auditoria da nuvem forneçam um ponto de partida para analisar a atividade suspeita, as informações fornecidas por estes registos podem não ser suficientes: se usar pipelines de implementação, também tem de conseguir correlacionar os registos de auditoria da nuvem com os registos produzidos pelo seu pipeline de implementação.

Esta secção contém práticas recomendadas que podem ajudar a manter uma trilha de auditoria nas Google Cloud e nas suas pipelines de implementação.

Práticas recomendadas:

Certifique-se de que pode correlacionar os registos do pipeline de implementação com os registos de auditoria do Cloud.
Alinhe os períodos de retenção dos registos do pipeline de implementação e dos registos de auditoria do Cloud.

Certifique-se de que consegue correlacionar os registos do pipeline de implementação com os registos de auditoria do Cloud

Os registos de auditoria do Google Cloud contêm datas/horas e informações sobre o utilizador que iniciou uma atividade. Se usar uma conta de serviço dedicada para cada pipeline de implementação, estas informações permitem-lhe identificar o pipeline de implementação que iniciou a atividade e também podem ajudar a restringir as alterações de código e as execuções de pipelines que podem ter sido responsáveis. No entanto, pode ser difícil identificar a execução exata do pipeline e a alteração do código que originaram a atividade sem mais informações que lhe permitam correlacionar os registos de auditoria do Cloud com os registos do seu pipeline de implementação.

Pode enriquecer os registos de auditoria do Cloud para conterem mais informações de várias formas, incluindo:

  • Quando usa o Terraform, especifique um motivo do pedido que indique a execução do pipeline de CI/CD.
  • Adicione um X-Goog-Request-Reason cabeçalho HTTP aos pedidos da API e transmita o ID da execução do pipeline de implementação.
  • Use um User-Agent personalizado que incorpore o ID da execução do pipeline de implementação.

Também pode enriquecer os registos emitidos pelo pipeline de implementação:

  • Registe os pedidos de API realizados por cada execução da pipeline de CI/CD.
  • Sempre que a API devolve um ID de operação, registe o ID nos registos do sistema de CI/CD.

Alinhe os períodos de retenção dos registos do pipeline de implementação e dos registos de auditoria na nuvem

Normalmente, para analisar a atividade suspeita relacionada com um pipeline de implementação, precisa de vários tipos de registos, incluindo registos de auditoria da atividade do administrador, registos de auditoria de acesso aos dados e os registos do seu pipeline de implementação.

O Cloud Logging só retém registos durante um determinado período. Por predefinição, este período de retenção é mais curto para os registos de auditoria de acesso aos dados do que para os registos de auditoria da atividade do administrador. O sistema que executa o pipeline de implementação também pode rejeitar os respetivos registos após um determinado período. Consoante a natureza do seu pipeline de implementação e a importância dos recursos que o pipeline de implementação gere, estes períodos de retenção predefinidos podem ser insuficientes ou desalinhados.

Para garantir que os registos estão disponíveis quando precisar deles, certifique-se de que os períodos de retenção de registos usados pelos diferentes sistemas estão alinhados e são suficientemente longos.

Se necessário, personalize o período de retenção para os registos de auditoria de acesso a dados ou configure um destino personalizado para encaminhar os registos para uma localização de armazenamento personalizada.

Práticas recomendadas:

Evite conceder acesso direto a dados confidenciais.
Use os VPC Service Controls para ajudar a evitar a exfiltração de dados.

Proteja-se contra ameaças de divulgação de informações

Quando a conta de serviço de um pipeline de implementação tem acesso a dados confidenciais, um agente malicioso pode tentar usar o pipeline de implementação para exfiltrar esses dados. O acesso de um pipeline de implementação aos dados pode ser direto ou indireto:

  • Direta: a conta de serviço do pipeline de implementação pode ter autorização para ler dados confidenciais do Cloud Storage, do BigQuery ou de outras localizações. Este acesso pode ter sido concedido intencionalmente, mas também pode ser um resultado acidental da concessão de demasiado acesso.

    Se um agente malicioso obtiver acesso a um pipeline de implementação com acesso direto a dados confidenciais, pode tentar usar o token de acesso da conta de serviço para aceder aos dados e roubá-los.

  • Indireta: para implementar a configuração ou novas versões de software, a conta de serviço de um pipeline de implementação pode ter autorização para criar ou reimplementar recursos de computação, como instâncias de VMs do Compute Engine. Alguns destes recursos podem ter uma conta de serviço anexada que concede acesso a dados confidenciais.

    Nesta situação, um interveniente malicioso pode tentar comprometer o pipeline de implementação para que implemente código malicioso num dos recursos de computação e permitir que este código exfiltre dados confidenciais.

Esta secção contém práticas recomendadas que podem ajudar a limitar o risco de divulgação de dados confidenciais.

Evite conceder acesso direto a dados confidenciais

Para implementar infraestrutura, configuração ou novas versões de software, um pipeline de implementação geralmente não requer acesso aos dados existentes. Em alternativa, é frequentemente suficiente limitar o acesso a recursos que não contenham dados ou, pelo menos, não contenham dados confidenciais.

Seguem-se algumas formas de minimizar o acesso a dados existentes potencialmente confidenciais:

  • Em vez de conceder acesso à conta de serviço de um pipeline de implementação a um projeto inteiro, conceda acesso apenas a recursos específicos.
  • Conceder acesso de criação sem permitir acesso de leitura. Por exemplo, ao conceder a função de criador de objetos de armazenamento (roles/storage.objectCreator), pode permitir que uma conta de serviço carregue novos objetos para um contentor do Cloud Storage sem conceder autorização para ler dados existentes.
  • Limite a infraestrutura como código (IaC) a recursos menos confidenciais. Por exemplo, use a IaC para gerir instâncias de VMs ou redes, mas não para gerir conjuntos de dados confidenciais do BigQuery.

Use os VPC Service Controls para ajudar a impedir a exfiltração de dados

Pode reduzir o risco de exfiltração de dados indireta implementando os seus Google Cloud recursos num perímetro dos VPC Service Controls.

Se o pipeline de implementação for executado fora do Google Cloudou fizer parte de um perímetro diferente, pode conceder à conta de serviço do pipeline acesso ao perímetro configurando uma regra de entrada. Se possível, configure a regra de entrada para que só permita o acesso a partir dos endereços IP usados pelo pipeline de implementação e só permita o acesso aos serviços de que o pipeline de implementação realmente precisa.

Proteja-se contra ameaças de escalamento de privilégios

Quando um pipeline de implementação usa uma conta de serviço para aceder a Google Cloud recursos, fá-lo independentemente do programador ou do utilizador que criou um código ou uma alteração de configuração. A dissociação entre a conta de serviço do pipeline e a identidade do programador torna os pipelines de implementação propensos a ataques de confused deputy, nos quais um interveniente malicioso engana o pipeline para realizar uma ação que o interveniente malicioso não tem permissão para realizar e que o pipeline pode nem sequer ter de realizar.

Esta secção contém práticas recomendadas que podem ajudar a reduzir o risco de abuso do pipeline de implementação para escalamento de privilégios.

Práticas recomendadas:

Limitar o acesso ao pipeline de implementação e a todas as entradas.
Evite permitir que um pipeline de implementação modifique políticas.
Não revele as credenciais da conta de serviço nos registos.

Limitar o acesso ao pipeline de implementação e a todas as entradas

A maioria dos pipelines de implementação usa um repositório de código-fonte como a sua principal fonte de entrada e pode ser acionada automaticamente assim que detetar uma alteração de código em determinados ramos (por exemplo, o ramo main). Normalmente, os pipelines de implementação não conseguem verificar se o código e a configuração que encontram no repositório de código-fonte são autênticos e fidedignos. Por conseguinte, a segurança desta arquitetura depende do seguinte:

  • Controlar quem pode enviar código e configuração para o repositório e as ramificações usados no pipeline de implementação.
  • Aplicar critérios que têm de ser cumpridos antes de as alterações poderem ser confirmadas, por exemplo, revisões de código bem-sucedidas, análise estática ou testes automatizados.

Para que estes controlos sejam eficazes, também tem de garantir que os intervenientes mal-intencionados não os contornam através das seguintes ações:

  • Modificar a configuração do repositório de código-fonte ou do pipeline de implementação.
  • Interferir com a infraestrutura (como VMs e armazenamento) subjacente ao pipeline de implementação.
  • Modificar ou substituir entradas fora do repositório de código-fonte, como pacotes, imagens de contentores ou bibliotecas.

Quando são geridos por um pipeline de implementação, os seus recursos no Google Cloud só podem ser tão seguros quanto o seu pipeline de implementação, a respetiva configuração, infraestrutura e entradas. Por conseguinte, tem de proteger estes componentes para proteger os seus Google Cloud recursos.

Evite permitir que um pipeline de implementação modifique políticas

Para a maioria dos tipos de recursos, a IAM define uma autorização RESOURCE_TYPE.setIamPolicy. Esta autorização permite que um utilizador modifique a política de permissão de um recurso, quer para conceder acesso a outros utilizadores, quer para modificar e ampliar o seu próprio acesso. A menos que seja restringido por uma política de negação, a concessão de uma *.setIamPolicyautorização a um utilizador ou a uma conta de serviço tem o efeito de lhe conceder acesso total ao recurso.

Sempre que possível, evite permitir que um pipeline de implementação modifique o acesso aos recursos. Quando conceder acesso da conta de serviço do pipeline a Google Cloud recursos, use funções que não incluam nenhuma autorização *.setIamPolicy e evite usar as funções básicas Editor e Proprietário.

Para alguns pipelines de implementação, a concessão de autorização para modificar políticas de permissão ou políticas de negação pode ser inevitável. Por exemplo, a finalidade de um pipeline de implementação pode ser criar novos recursos ou gerir o acesso a recursos existentes. Nestes cenários, ainda pode limitar a extensão em que a implementação pode modificar o acesso:

Não revele as credenciais da conta de serviço nos registos

Os registos gerados por um pipeline de implementação são frequentemente acessíveis a um grupo maior de utilizadores, incluindo utilizadores que não têm autorização para modificar a configuração do pipeline. É possível que estes registos revelem acidentalmente credenciais ao repetir o seguinte:

  • Conteúdos das variáveis de ambiente
  • Argumentos da linha de comandos
  • Saída de diagnósticos

Se os registos revelarem acidentalmente credenciais, como tokens de acesso, estas credenciais podem ser usadas indevidamente por autores de ameaças para aumentar os respetivos privilégios. As formas de impedir que os registos revelem credenciais incluem o seguinte:

  • Evite transmitir tokens de acesso ou outras credenciais como argumentos da linha de comandos
  • Evite armazenar credenciais em variáveis de ambiente
  • Configure o seu sistema de CI/CD para detetar e ocultar automaticamente tokens e outras credenciais, se possível

O que se segue?