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

Os pipelines de implantação permitem automatizar o processo de fazer com que os códigos ou artefatos pré-criados e implantá-los em um ambiente do Google Cloud sejam uma alternativa ao uso de ferramentas interativas, como o Console do Google Cloud ou a CLI do Google Cloud..

Os pipelines de implantação diferem de ferramentas interativas como o Console do Google Cloud ou a CLI gcloud na maneira como interagem com o Identity and Access Management. Você precisa considerar essas diferenças ao proteger seus recursos do Google Cloud.

Antes de acessar um recurso, o Google Cloud executa uma verificação de acesso. Para realizar essa verificação, o IAM geralmente considera o seguinte:

  • Sua identidade
  • O recurso que você está tentando acessar e as políticas de permissão e negação do IAM
  • O contexto da solicitação (incluindo horário e local)

Em um pipeline de implantação, você raramente chama APIs do Google Cloud diretamente. Em vez disso, você usa ferramentas para acessar os recursos do Google Cloud. Ferramentas como o Console do Google Cloud ou a CLI gcloud exigem que você primeiro autorize a ferramenta a acessar recursos em seu nome. Ao conceder essa autorização, você concede à ferramenta permissão para usar sua identidade ao fazer chamadas de API.

Assim como o Console do Google Cloud ou a CLI gcloud, um pipeline de implantação funciona em seu nome: ele pega as alterações, expressas como código-fonte, e as implanta no Google Cloud. Mas, diferentemente do Console do Google Cloud ou da CLI do gcloud, um pipeline de implantação normalmente não usa sua identidade para realizar a implantação:

  1. Como usuário, você normalmente não interage diretamente com um pipeline de implantação. Em vez disso, você interage com um sistema de controle de origem (SCM) enviando as alterações de código para um repositório de origem ou aprovando as revisões de código.

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

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

    1. O código-fonte e os metadados dele podem não indicar que você é o autor ou as informações do autor não são à prova de adulteração (como no caso de confirmações do Git não assinadas).
    2. A identidade usada para enviar o código-fonte pode ser diferente da sua identidade do Google, e as duas identidades não podem ser mapeadas

    Portanto, a maioria dos pipelines de implantação realiza implantações com a própria identidade usando uma conta de serviço.

  3. Quando o pipeline de implantação acessa o Google Cloud, o IAM permite ou nega o acesso apenas com base na identidade da conta de serviço usada pelo pipeline, não na identidade da conta de usuário.

Pipeline de implantação

Permitir que um pipeline de implantação use uma conta de serviço para acessar o Google Cloud tem algumas vantagens:

  • O ciclo de vida de uma conta de serviço é desconectado do ciclo de vida das contas de usuário. Ao configurar um pipeline para usar uma conta de serviço, você garante que o código possa ser implantado mesmo que o autor do código não esteja mais na organização.
  • Ao gerenciar recursos usando um pipeline de implantação, você não precisa conceder aos usuários acesso aos recursos ou pode limitar as permissões ao acesso somente leitura. Essa abordagem pode facilitar o gerenciamento de políticas do IAM e permite que você force os usuários a usar o pipeline de implantação para realizar todas as modificações.

No entanto, usar uma conta de serviço também gera novas ameaças. São eles:

  • Spoofing:um usuário de má-fé pode tentar falsificar a identidade do pipeline de implantação ou roubar as credenciais dela para ter acesso aos recursos.
  • Escalonamento de privilégios: o pipeline pode ser induzido a realizar ações que ele não deveria executar, tornando-se um representante confuso.
  • Não repúdio: depois que um pipeline executa uma operação, pode ser difícil reconstruir por que isso foi feito e por qual desenvolvedor ou alteração de código ela foi acionada.
  • Tampering: um pipeline pode ser comprometido por minar a integridade ou os controles de segurança dos seus ambientes de nuvem.
  • Divulgação de informações:usuários de má-fé podem tentar usar o pipeline de implantação para exfiltrar dados confidenciais.

Proteger contra ameaças de spoofing

Para conceder acesso ao Google Cloud a um pipeline de implantação, você costuma fazer o seguinte:

  1. Crie uma conta de serviço
  2. Conceder à conta de serviço acesso aos recursos necessários
  3. Configurar o pipeline de implantação para usar a conta de serviço

Do ponto de vista do IAM, a conta de serviço representa o pipeline de implantação, mas o pipeline de implantação e a conta de serviço são duas entidades separadas. Se não houver uma proteção adequada, um usuário de má-fé poderá usar a mesma conta de serviço. Isso permite que ele "falsifique" a identidade do pipeline de implantação.

A seção a seguir descreve as práticas recomendadas que podem ajudar a reduzir o risco dessas ameaças.

Práticas recomendadas:

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

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

Para aplicativos implantados no Compute Engine que precisam de acesso aos recursos do Google Cloud, 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 implantação, essa prática pode ser problemática se a mesma instância de VM puder ser usada para executar diferentes pipelines de implantação que exigem acesso a diferentes recursos.

Em vez de usar contas de serviço anexadas para permitir que os pipelines de implantação acessem recursos, permita cada pipeline de implantação usar uma conta de serviço separada. Evite anexar uma conta de serviço a instâncias de VM usadas por sistemas de CI/CD ou anexar uma conta de serviço limitada ao acesso a serviços essenciais, como apenas a geração de serviços em nuvem.

Usar contas de serviço dedicadas por pipeline de implantação

Ao permitir que vários pipelines de implantação usem a mesma conta de serviço, o IAM não consegue diferenciar os pipelines: os pipelines têm acesso aos mesmos recursos e os registros de auditoria podem não conter informações suficientes para determinar qual pipeline de implantação acionou um recurso a ser acessado ou alterado.

Para evitar essa ambiguidade, mantenha uma relação de 1:1 entre pipelines de implantação e contas de serviço. Crie uma conta de serviço dedicada para cada pipeline de implantação e verifique se:

  • Incorpore o nome ou o ID do pipeline de implantação ao endereço de e-mail da conta de serviço. Seguir um esquema de nomenclatura consistente ajuda a determinar o pipeline de implantação a partir do nome da conta de serviço e vice-versa.
  • Conceda à conta de serviço acesso apenas aos recursos necessários para o pipeline de implantação específico.

Use a federação de identidade da carga de trabalho sempre que possível

Alguns sistemas de CI/CD, como as ações do GitHub ou o GitLab, permitem que os pipelines de implantação recebam tokens compatíveis com o OpenID Connect, garantindo a identidade do pipeline de implantação. É possível permitir que os pipelines de implantação usem esses tokens para personificar uma conta de serviço. Basta usar a federação de identidade da carga de trabalho.

O uso da federação de identidade de carga de trabalho ajuda a evitar os riscos associados ao uso de chaves de conta de serviço.

Use o VPC Service Controls para reduzir o impacto de credenciais vazadas

Se um usuário de má-fé conseguir roubar um token de acesso ou uma chave de conta de serviço de um dos pipelines de implantação, ele poderá tentar usar essa credencial e acessar os recursos de uma máquina que controla.

Por padrão, o IAM não considera a geolocalização, o endereço IP de origem ou o projeto de origem do Google Cloud ao tomar decisões de acesso. Portanto, é possível usar uma credencial roubada de qualquer lugar.

É possível aplicar restrições às origens de onde os recursos do Google Cloud podem ser acessados colocando os projetos em um perímetro de serviço da VPC e usando regras de entrada:

  • Se o pipeline de implantação for executado no Google Cloud, será possível configurar uma regra de entrada para permitir apenas o acesso do projeto que contém o sistema de CI/CD.
  • Se o pipeline de implantação for executado fora do Google Cloud, será possível criar um nível de acesso que permita acesso apenas em determinadas localizações geográficas ou intervalos de IP. Em seguida, crie uma regra de entrada que permita o acesso para os clientes que satisfazem esse nível de acesso.

Proteger contra ameaças de adulteração

Para alguns dados armazenados no Google Cloud, talvez seja importante evitar modificações ou exclusões não autorizadas. Se as modificações ou exclusões não autorizadas forem especialmente preocupantes, você poderá caracterizar os dados como de alta integridade.

Para manter a integridade dos dados, é preciso garantir que os recursos do Google Cloud usados para armazenar e gerenciar esses dados estejam configurados com segurança e precisam manter a integridade.

Os pipelines de implantação podem ajudar a manter a integridade dos dados e recursos, mas podem representar um risco: se o pipeline de um dos componentes não atender aos requisitos de integridade dos recursos gerenciados, O pipeline de implantação se transforma em um ponto fraco que pode permitir que usuários de má-fé entrem no controle dos seus dados ou recursos.

Esta seção descreve as práticas recomendadas que podem ajudar a reduzir o risco de adulteração de ameaças.

Práticas recomendadas:

Evite permitir que os pipelines de implantação gerenciem os controles de segurança.

Limitar o acesso aos controles de segurança

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

  • Permitir e negar políticas
  • Restrições da política organizacional
  • Perímetros, níveis de acesso e políticas de entrada do VPC Service Controls

Esses controles de segurança são recursos isolados. Adulteração de controles de segurança coloca em risco a integridade dos recursos a que os controles de segurança se aplicam. Como resultado, a integridade dos controles de segurança precisa ser pelo menos tão importante quanto a integridade dos recursos a que eles se aplicam.

Se você permitir que um pipeline de implantação gerencie controles de segurança, cabe ao pipeline de implantação manter a integridade dos controles de segurança. Por isso, considere que a integridade do pipeline de implantação é pelo menos tão importante quanto a integridade dos controles de segurança que gerencia e dos recursos a que esses controles se aplicam.

É possível limitar o impacto de um pipeline de implantação na integridade dos recursos fazendo o seguinte:

  • Não conceder acesso aos pipelines de implantação para permitir políticas, negar políticas e outros controles de segurança e restringir o acesso deles a outros recursos
  • Conceder acesso apenas aos controles de segurança selecionados, como as políticas de permissão e negação de um recurso ou projeto específico, sem conceder acesso a controles mais amplos que afetam vários recursos ou projetos

Se o pipeline de implantação, os componentes dele e a infraestrutura subjacente não atendem às demandas de integridade de determinados controles de segurança, é melhor evitar que os pipelines de implantação gerenciem esses controles de segurança.

Proteger contra ameaças de não repúdio

Em algum momento, talvez você veja atividades suspeitas que afetam um dos seus recursos no Google Cloud. Nesse caso, você precisa saber mais sobre a atividade e, de preferência, reconstruir a cadeia de eventos que levou a ela.

Os registros de auditoria do Cloud permitem que você descubra quando os recursos foram acessados ou modificados e quais usuários estavam envolvidos. Embora os registros de auditoria do Cloud sejam um ponto de partida para analisar atividades suspeitas, as informações fornecidas por eles podem não ser suficientes. Se você usar pipelines de implantação, também será possível correlacionar os registros de auditoria do Cloud com registros produzidos pelo pipeline de implantação.

Nesta seção, você verá as práticas recomendadas que podem ajudar a manter uma trilha de auditoria no Google Cloud e nos pipelines de implantação.

Práticas recomendadas:

Verifique se é possível correlacionar os registros do pipeline de implantação com os registros de auditoria do Cloud.
Alinhe os períodos de armazenamento dos registros de pipeline de implantação e dos registros de auditoria do Cloud.

Verifique se é possível correlacionar os registros do pipeline de implantação com os registros de auditoria do Cloud

Os registros de auditoria do Cloud contêm carimbos de data/hora e informações sobre o usuário que iniciou uma atividade. Se você usa uma conta de serviço dedicada para cada pipeline de implantação, essas informações permitem identificar o pipeline de implantação que iniciou a atividade e também podem ajudar a restringir quais mudanças de código e pipeline poderiam ter sido responsáveis. Mas a identificação da execução exata do pipeline e da alteração de código que levou à atividade pode ser difícil sem mais informações que permitam correlacionar os registros de auditoria do Cloud com os registros do pipeline de implantação.

É possível enriquecer os registros de auditoria do Cloud para conter mais informações de várias maneiras, incluindo:

  • Ao usar o Terraform, especifique um motivo da solicitação que indica a execução do pipeline de CI/CD.
  • Adicione um cabeçalho HTTP X-Goog-Request-Reason às solicitações de API e passe o ID da execução do pipeline de implantação.
  • Use um User-Agent personalizado que incorpore o ID da execução do pipeline de implantação.

Também é possível enriquecer os registros emitidos pelo pipeline de implantação:

  • Solicitações de API de registro realizadas por cada execução de pipeline de CI/CD.
  • Sempre que a API retornar um ID de operação, registre o ID nos registros do sistema de CI/CD.

Alinhe os períodos de armazenamento dos registros de pipeline de implantação e dos registros de auditoria do Cloud

Para analisar atividades suspeitas relacionadas a um pipeline de implantação, você geralmente precisa de vários tipos de registros, incluindo registros de auditoria de atividade do administrador, registros de auditoria de acesso a dados. os registros do seu pipeline de implantação.

O Cloud Logging só retém registros por um determinado período. Por padrão, esse período de armazenamento é mais curto para registros de auditoria de acesso a dados do que para registros de auditoria de atividade do administrador. O sistema que executa o pipeline de implantação também pode descartar os registros após um determinado período. Dependendo da natureza do seu pipeline de implantação e da importância dos recursos que o pipeline de implantação gerencia, esses períodos de retenção padrão podem ser insuficientes ou desalinhados.

Para garantir que os registros estejam disponíveis quando você precisar deles, verifique se os períodos de armazenamento de registros usados pelos diferentes sistemas estão alinhados e são longos o suficiente.

Se necessário, personalize o período de armazenamento dos registros de auditoria de acesso a dados ou configure um coletor personalizado para encaminhar os registros para um local de armazenamento personalizado.

Práticas recomendadas:

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

Proteger contra ameaças à divulgação de informações

Quando a conta de serviço de um pipeline de implantação tem acesso a dados confidenciais, uma pessoa mal-intencionada pode tentar usá-lo para exfiltrar esses dados. O acesso de um pipeline de implantação aos dados pode ser direto ou indireto:

  • Direta: a conta de serviço do pipeline de implantação pode ter permissão para ler dados confidenciais do Cloud Storage, do BigQuery ou de outros locais. Esse acesso pode ter sido concedido intencionalmente, mas também pode ser um resultado acidental de acesso excessivo.

    Se um usuário de má-fé tiver acesso a um pipeline de implantação com acesso direto a dados confidenciais, ele poderá tentar usar o token de acesso da conta de serviço para acessar e exfiltrar os dados.

  • Indireta: para implantar configurações ou novas versões de software, a conta de serviço de um pipeline de implantação pode ter permissão para criar ou reimplantar instâncias de VM, aplicativos do Cloud Run ou outros recursos de computação. Alguns desses recursos de computação podem ter uma conta de serviço anexada que concede acesso a dados confidenciais.

    Nessa situação, uma pessoa mal-intencionada pode tentar comprometer o pipeline de implantação para que ele implante código malicioso em um dos recursos de computação e permita que esse código exfiltre dados confidenciais.

Esta seção contém práticas recomendadas que ajudam você a limitar o risco de divulgação de dados confidenciais.

Evitar o acesso direto a dados confidenciais

Para implantar uma infraestrutura, configuração ou novas versões de software, um pipeline de implantação geralmente não requer acesso aos dados atuais. Muitas vezes, é suficiente limitar o acesso a recursos que não contenham dados ou pelo menos não contenham dados confidenciais.

Veja a seguir algumas formas de minimizar o acesso a dados possivelmente confidenciais atuais:

  • Em vez de conceder acesso à conta de serviço de um pipeline de implantação a todo um projeto, conceda acesso somente a recursos específicos.
  • Conceda acesso de criação sem permitir acesso de leitura. Por exemplo, ao conceder o papel Criador de objeto do Storage (roles/storage.objectCreator), é possível permitir que uma conta de serviço faça o upload de novos objetos para um bucket do Cloud Storage sem conceder permissão para ler dados existentes
  • Limite a infraestrutura como código (IaC) a recursos menos confidenciais. Por exemplo, use IaC para gerenciar instâncias ou redes de VM, mas não para gerenciar conjuntos de dados do BigQuery confidenciais.

Usar o VPC Service Controls para evitar a exfiltração de dados

É possível reduzir o risco de exfiltração de dados indiretos implantando os recursos do Google Cloud em um perímetro do VPC Service Controls.

Se o pipeline de implantação for executado fora do Google Cloud ou fizer parte de um perímetro diferente, será possível 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 permitir acesso apenas aos endereços IP usados pelo pipeline de implantação e acesso apenas aos serviços de que o pipeline de implantação realmente precisa.

Proteger contra ameaças de escalonamento de privilégios

Quando um pipeline de implantação usa uma conta de serviço para acessar os recursos do Google Cloud, ele faz isso independentemente do desenvolvedor ou usuário que criou um código ou uma mudança na configuração. A desconexão entre a conta de serviço do pipeline e a identidade do desenvolvedor torna os pipelines de implantação propensos a ataques de representante confuso, em que um usuário de má-fé engana o realizar uma ação que o usuário de má-fé não pode fazer e que o pipeline nem deve realizar.

Nesta seção, você verá as práticas recomendadas que podem ajudar a reduzir o risco de abuso do pipeline de implantação no escalonamento de privilégios.

Práticas recomendadas:

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

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

A maioria dos pipelines de implantação usa um repositório de código-fonte como origem principal de entrada e pode ser acionada automaticamente assim que detectar uma mudança no código em determinadas ramificações (por exemplo, a ramificação main). Os pipelines de implantação geralmente não podem verificar se o código e a configuração que encontram no repositório de código-fonte são autênticos e confiáveis. Portanto, a segurança dessa arquitetura depende de:

  • Controlar quem pode enviar o código e a configuração ao repositório e às ramificações usadas pelo pipeline de implantação.
  • Aplicar critérios que precisam ser atendidos para que as alterações sejam confirmadas, por exemplo, revisões de código bem-sucedidas, análises estáticas ou testes automatizados.

Para que esses controles sejam eficientes, você precisa impedir que usuários de má-fé façam o seguinte:

  • Modificar a configuração do repositório do código-fonte ou do pipeline de implantação
  • Adulteração com a infraestrutura (como VMs e armazenamento) que fundamenta o pipeline de implantação.
  • Modificar ou substituir entradas fora do repositório do código-fonte, como pacotes, imagens de contêiner ou bibliotecas.

Quando gerenciados por um pipeline de implantação, seus recursos no Google Cloud são tão seguros quanto o pipeline de implantação, a configuração, a infraestrutura e as entradas. Portanto, você precisa proteger esses componentes e os recursos do Google Cloud também.

Evitar que um pipeline de implantação modifique políticas

Para a maioria dos tipos de recursos, o IAM define uma permissão RESOURCE_TYPE.setIamPolicy. Essa permissão permite que um usuário modifique a política de permissão do IAM de um recurso, seja para conceder acesso a outros usuários ou modificar e estender o próprio acesso. A menos que isso seja limitado por uma política de negação, a concessão de uma permissão *.setIamPolicy a um usuário ou uma conta de serviço tem o efeito de conceder a eles acesso total ao recurso.

Sempre que possível, evite permitir que um pipeline de implantação modifique o acesso aos recursos. Ao conceder acesso à conta de serviço do pipeline aos recursos do Google Cloud, use papéis que não incluam nenhuma permissão *.setIamPolicy e evite usar os papéis básicos Editor e Proprietário

Para alguns pipelines de implantação, conceder permissão para modificar políticas de permissão ou negar políticas pode ser inevitável. Por exemplo, a finalidade de um pipeline de implantação é criar novos recursos ou gerenciar o acesso a recursos existentes. Nessas situações, ainda é possível limitar o quanto a implantação pode modificar o acesso das seguintes maneiras:

  • Concede apenas a permissão *.setIamPolicy para recursos específicos, e não para todo o projeto.
  • Usando políticas de negação do IAM para restringir o conjunto de permissões que podem ser concedidas ou para limitar a quais principais elas podem ser concedidas.
  • Usando condições do IAM para restringir quais papéis o pipeline pode conceder e permitindo apenas papéis que não incluam permissões *.setIamPolicy.

Não revelar as credenciais da conta de serviço nos registros

Os registros gerados por um pipeline de implantação costumam ser acessíveis a um grupo maior de usuários, incluindo usuários que não têm permissão para modificar a configuração do pipeline. É possível que esses registros revelem acidentalmente credenciais ecoando:

  • Conteúdo das variáveis de ambiente
  • Argumentos de linha de comando
  • Diagnóstico de saída

Se os registros revelarem acidentalmente credenciais como tokens de acesso, elas poderão ser usadas indevidamente por usuários de má-fé para escalonar os privilégios. Algumas maneiras de evitar que os registros revelem credenciais:

  • Evitar transmitir tokens de acesso ou outras credenciais como argumentos de linha de comando
  • Evitar armazenar credenciais em variáveis de ambiente
  • Configure seu sistema de CI/CD para detectar e mascarar automaticamente tokens e outras credenciais, se possível

A seguir