Práticas recomendadas para proteger credenciais de desenvolvedor

Conheça as práticas recomendadas para proteger as estações de trabalho dos desenvolvedores e evitar o roubo e o uso indevido de Google Cloud credenciais, incluindo tokens de portador OAuth da Google Cloud CLI, Application Default Credentials e chaves locais.

Este documento é destinado a equipes de segurança ou arquitetos de nuvem responsáveis por proteger os recursos na nuvem contra o acesso ilegítimo. Conheça os controles disponíveis que podem ser usados para reduzir proativamente o impacto de credenciais de desenvolvedor comprometidas e corrigir o ambiente depois que um endpoint for comprometido.

O risco de credenciais comprometidas

Um invasor pode comprometer credenciais se tiver acesso a um endpoint em que uma conta de usuário ou de serviço legítima já foi autenticada com Google Cloud a CLI gcloud. O invasor pode copiar esses tokens para outro endpoint que ele controla para fazer solicitações que falsificam a identidade legítima. Mesmo depois que você remover o acesso do invasor ao endpoint comprometido, ele poderá continuar fazendo solicitações de API autenticadas usando os tokens copiados. Para reduzir esse risco, controle o acesso aos seus sistemas usando credenciais de curta duração e baseadas no contexto.

Visão geral das credenciais do desenvolvedor

As credenciais a seguir Google Cloud são normalmente encontradas em estações de trabalho de desenvolvedores:

As seções a seguir descrevem como cada tipo de credencial é armazenado e usado.

Tokens OAuth da CLI gcloud

A CLI gcloud usa tokens de acesso OAuth 2.0 para autenticar solicitações de Google Cloud APIs. O fluxo de OAuth muda de acordo com os tipos de credenciais usados, mas geralmente o token de acesso e outras credenciais podem ser acessíveis localmente. Em cada caso, o token de acesso expira após 60 minutos por padrão, mas pode durar até 12 horas em restrições de vida útil estendida. No entanto, outros tipos de credenciais podem ser persistentes.

Quando você autoriza a CLI gcloud com uma conta de usuário, ela inicia um fluxo de consentimento do OAuth de três etapas para acessar Google Cloud APIs em nome do usuário. Depois que o usuário conclui o fluxo de consentimento, a CLI gcloud recebe um token de acesso e um token de atualização que permite solicitar novos tokens de acesso. O token de atualização de longa duração persiste até que as condições de expiração sejam atendidas.

Quando você autoriza a CLI gcloud com uma conta de serviço, ela inicia um fluxo OAuth de duas etapas para acessar Google Cloud APIs como a identidade da conta de serviço. Depois que você ativa uma conta de serviço de um arquivo de chave privada, a CLI gcloud usa essa chave para solicitar periodicamente um token de acesso. A chave privada de longa duração é armazenada na configuração da CLI gcloud e permanece válida até que você desative ou exclua a chave da conta de serviço.

Quando você executa a CLI gcloud em um Google Cloud ambiente, como o Compute Engine ou o Cloud Shell, o aplicativo pode encontrar credenciais automaticamente e autenticar como uma conta de serviço. Por exemplo, no Compute Engine, um aplicativo como a CLI gcloud pode consultar o servidor de metadados para um token de acesso. O Google gerencia e alterna a chave de assinatura privada usada para criar o token de acesso, e as credenciais de longa duração não são expostas ao aplicativo.

Application Default Credentials

As Application Default Credentials são usadas por aplicativos para autenticar com Google Cloud APIs. Os desenvolvedores podem gerar Application Default Credentials executando gcloud auth application-default login. Esse comando grava um arquivo JSON de texto simples ($HOME/.config/gcloud/application_default_credentials.json ou %APPDATA%\gcloud\application_default_credentials.json), que contém um token de atualização do OAuth 2.0 e credenciais de cliente para bibliotecas de cliente.

Qualquer biblioteca de cliente ou script personalizado pode usar essas credenciais para chamar Google Cloud APIs.

Como as Application Default Credentials são salvas em texto simples, qualquer processo ou script não confiável em execução no contexto do usuário pode acessar o arquivo diretamente ou usar comandos como gcloud auth application-default print-access-token para recuperar tokens de acesso ativos.

O malware típico geralmente tem como alvo o diretório ~/.config/gcloud/ para coletar application_default_credentials.json.

Para mais informações, consulte Application Default Credentials.

Chaves da conta de serviço

As chaves da conta de serviço são arquivos de chave JSON privados que são baixados do Google Cloud console. Essas chaves são usadas por aplicativos para autenticar com Google Cloud APIs. As chaves da conta de serviço podem ser armazenadas nos seguintes locais:

  • Diretório de configuração da CLI gcloud após a execução de gcloud auth activate-service-account
  • O sistema de arquivos local
  • Um repositório de código interno

As chaves da conta de serviço em endpoints de desenvolvedores não são vinculadas à verificação em duas etapas, não têm limites de sessão e não expiram automaticamente.

Um invasor que rouba uma chave de conta de serviço pode criar tokens de acesso à conta de serviço para manter o acesso persistente.

Para mais informações, consulte Práticas recomendadas para gerenciar chaves de conta de serviço.

Chaves SSH

As chaves SSH são usadas para autenticar com instâncias do Compute Engine. Os desenvolvedores podem gerar chaves SSH usando gcloud compute ssh. Esse comando gera chaves privadas locais em ~/.ssh/google_compute_engine. As chaves SSH são de longa duração.

Um invasor pode usar uma chave SSH roubada para acessar uma VM e consultar o servidor de metadados para extrair um token de conta de serviço anexado. Esse ataque ignora firewalls de perímetro externos.

Em vez de usar chaves SSH, considere o login do SO com a verificação em duas etapas. Para mais informações, consulte Aplicar a verificação em duas etapas para acesso remoto ao servidor.

Cookies do navegador

Os cookies do navegador autenticam solicitações HTTP da Web para o Google Cloud console e o Cloud Shell. Os cookies do navegador são criados automaticamente quando um usuário faz login no Google Cloud console.

Os cookies são armazenados no diretório de perfil do navegador na estação de trabalho local. Por exemplo, o Google Chrome armazena cookies em ~/.config/google-chrome/ no Linux ou %LOCALAPPDATA%\Google\Chrome\User Data no Windows.

Os cookies do navegador são credenciais de longa duração que só são invalidadas quando um usuário faz logout, quando ocorre um tempo limite da sessão ou quando um administrador redefine a sessão do usuário no Admin Console.

Um invasor que rouba esses cookies pode importá-los para outro navegador para sequestrar sessões ativas do Google Cloud console, ignorando a autenticação.

Para reduzir o risco de cookies de sessão roubados, defina a duração da sessão para Google Cloud serviços.

Tokens de acesso da federação de identidade de colaboradores

Os desenvolvedores podem usar a federação de identidade de colaboradores para autenticar por um provedor de identidade externo para que possam acessar Google Cloud recursos.

Para fazer login com uma identidade federada, os desenvolvedores usam um arquivo de configuração de login (criado com o gcloud iam workforce-pools create-login-config comando) e fazem login na CLI gcloud. Após a autenticação com o provedor de identidade externo, o Security Token Service troca o código de autorização por um token de acesso federado de curta duração e um token de atualização do OAuth.

A CLI gcloud armazena metadados de credenciais e tokens de atualização em um banco de dados de credenciais local e armazena em cache tokens de acesso ativos no diretório de configuração da CLI gcloud. Os tokens de acesso federados são credenciais de curta duração que expiram após um período definido (60 minutos por padrão).

Um invasor que compromete um endpoint pode extrair tokens de acesso federados ativos ou usar gcloud auth print-access-token para representar o principal da força de trabalho. Se a identidade da força de trabalho tiver direitos de representação, o invasor também poderá solicitar tokens de acesso à conta de serviço para aumentar os privilégios.

Para reduzir o risco, configure a duração da sessão no pool de identidades da força de trabalho para a duração mínima necessária e alinhe a duração com as políticas de tempo limite da sessão e reautenticação do provedor de identidade externo. Para mais informações sobre como armazenar e gerenciar as credenciais, consulte práticas recomendadas para usar a federação de identidade da carga de trabalho.

Impacto de credenciais comprometidas

Se um invasor conseguir comprometer um endpoint, as credenciais como tokens OAuth são alvos valiosos porque permitem que invasores persistam ou encaminhem seu acesso.

Um desenvolvedor pode ter uma necessidade legítima de ver as próprias credenciais ao gravar e depurar código. Por exemplo, um desenvolvedor pode precisar autenticar solicitações REST para Google Cloud serviços ao trabalhar com uma biblioteca de cliente sem suporte. O desenvolvedor pode ver as credenciais por vários métodos, incluindo estes:

No entanto, um invasor pode usar essas mesmas técnicas depois de comprometer um endpoint.

Se um invasor comprometer um endpoint, a ameaça principal é que o invasor poderá executar comandos da CLI gcloud ou outro código com as credenciais legítimas da identidade autenticada. Além disso, o invasor pode copiar as credenciais para outro endpoint que ele controla para manter o acesso. Quando esse roubo de credenciais ocorre, uma ameaça secundária ocorre. O invasor ainda pode usar as credenciais de longa duração para ter acesso persistente, mesmo depois que você remove o acesso ao endpoint comprometido.

Se o invasor conseguir comprometer as credenciais do desenvolvedor, ele poderá realizar as seguintes ações:

  • Representar a conta de usuário ou de serviço comprometida. O tráfego de API que usa os tokens comprometidos é registrado como se viesse da conta de usuário ou de serviço comprometida, dificultando a distinção entre atividades normais e maliciosas nos registros.
  • Solicitar tokens de acesso indefinidamente usando um token de atualização OAuth persistente (da CLI gcloud ou Application Default Credentials) ou uma chave privada associada a uma conta de serviço.
  • Ignorar a autenticação com a senha do usuário ou a verificação em duas etapas porque os tokens são concedidos após o fluxo de login.
  • Usar chaves SSH roubadas para acessar instâncias do Compute Engine e consultar o servidor de metadados para roubar tokens de conta de serviço anexados.
  • Usar cookies de navegador roubados para sequestrar sessões ativas Google Cloud do console sem exigir a senha do usuário ou a verificação em duas etapas.
  • Usar tokens de acesso federados roubados para acessar recursos concedidos a pools de identidade de colaboradores ou aumentar privilégios representando contas de serviço.

Práticas recomendadas para reduzir os riscos

Implemente os controles descritos nas seções a seguir para ajudar a reduzir o risco de credenciais de desenvolvedor comprometidas. Se você estiver seguindo as práticas recomendadas de segurança descritas no blueprint de bases empresariais ou no design da zona de destino em Google Cloud, talvez você já tenha esses controles em vigor.

Definir a duração da sessão para Google Cloud serviços

Para reduzir o tempo que um invasor pode explorar um token comprometido, defina a duração da sessão para Google Cloud serviços. Para novos clientes, uma duração de sessão padrão de 16 horas é aplicada automaticamente. Os clientes que criaram a Google Cloud organização antes de 2023 podem ter uma configuração padrão para nunca exigir a reautenticação. Revise essa configuração para garantir que você tenha uma política de reautenticação com uma duração de sessão entre 1 e 24 horas. A política de reautenticação força o usuário a reautenticar regularmente a CLI gcloud com a senha ou a chave de segurança.

A duração da sessão para Google Cloud serviços é uma configuração diferente da duração da sessão para Serviços do Google, que controla as sessões da Web para login em serviços do Google Workspace, mas não controla a reautenticação para Google Cloud. Se você usa os serviços do Google Workspace, defina a duração da sessão para ambos.

Configurar o VPC Service Controls

Configure VPC Service Controls em todo o ambiente para garantir que apenas o Google Cloud tráfego da API originado dentro do perímetro definido possa acessar recursos compatíveis. O perímetro de serviço limita a utilidade das credenciais comprometidas porque o perímetro bloqueia as solicitações para serviços restritos originados de endpoints controlados por invasores que estão fora do seu ambiente.

Configurar o Chrome Enterprise Premium

Configure as políticas do Chrome Enterprise Premium para ajudar a proteger o Google Cloud console e Google Cloud as APIs. Configure um nível de acesso e vinculação do Chrome Enterprise Premium para permitir seletivamente atributos que são avaliados em todas as solicitações de API, incluindo acesso baseado em IP ou acesso baseado em certificado para TLS mútuo. As solicitações que usam credenciais de autorização comprometidas, mas não atendem às condições definidas na política do Chrome Enterprise Premium Enterprise, são rejeitadas.

O Chrome Enterprise Premium é um controle centrado no usuário que rejeita o tráfego da API do usuário que não atende às condições definidas. O VPC Service Controls é um controle centrado em recursos que define os perímetros em que os recursos podem se comunicar. O VPC Service Controls se aplica a todas as identidades de usuário e identidades de conta de serviço, mas o Chrome Enterprise Premium se aplica somente a identidades de usuário na sua organização. Quando usados juntos, o Chrome Enterprise Premium e o VPC Service Controls reduzem a eficácia das credenciais comprometidas em uma máquina controlada por invasores fora do ambiente.

Aplicar a verificação em duas etapas para acesso remoto ao servidor

Se você permitir que os desenvolvedores acessem os recursos do Compute Engine usando SSH, configure o Login do SO com a verificação em duas etapas. Isso impõe um ponto de verificação adicional em que um usuário precisa se autenticar novamente com a senha ou a chave de segurança. Um invasor com tokens OAuth comprometidos, mas sem uma senha ou chave de segurança, está bloqueado por esse recurso.

O acesso do Remote Desktop Protocol (RDP) a instâncias do Windows no Compute Engine não é compatível com o serviço de Login do SO. Por isso, a verificação em duas etapas não pode ser aplicada de maneira granular para sessões RDP. Ao usar o IAP Desktop ou plug-ins RDP baseados no Google Chrome, faça o seguinte:

Restringir o uso de chaves da conta de serviço

Quando você usa uma chave de conta de serviço para autenticação, o valor da chave é armazenado nos arquivos de configuração da CLI gcloud, separadamente do arquivo de chave baixado. Um invasor com acesso ao seu ambiente pode copiar a chave da configuração da CLI gcloud ou copiar o arquivo de chave do seu sistema de arquivos local ou do repositório de código interno. Portanto, além do plano para mitigar tokens de acesso comprometidos, pense em como você gerencia arquivos de chave de conta de serviço salvos.

Analise alternativas mais seguras para autenticação para reduzir ou eliminar seus casos de uso que dependem de uma chave de conta de serviço. Além disso, aplique as constraints/iam.disableServiceAccountKeyCreation e constraints/iam.disableServiceAccountKeyUpload restrições de política da organização para desativar a criação de chaves de conta de serviço.

Aplicar o princípio de privilégio mínimo

Ao criar políticas do Identity and Access Management (IAM), considere o privilégio mínimo. Conceda aos usuários apenas os papéis necessários para realizar uma tarefa no menor escopo. Revise e aplique recomendações de papéis para evitar políticas do IAM com papéis não utilizados e excessivos no seu ambiente.

Proteger seus endpoints

Considere como um invasor pode ter acesso físico ou acesso remoto aos endpoints, como estações de trabalho de desenvolvedores ou instâncias do Compute Engine. Embora um plano para solucionar a ameaça de credenciais comprometidas seja importante, considere também o risco de um invasor comprometer seus endpoints confiáveis. Se um invasor tiver acesso aos endpoints confiáveis, ele poderá executar comandos da CLI gcloud ou outros códigos diretamente nos próprios endpoints.

Embora a proteção abrangente para estações de trabalho de desenvolvedores esteja além do escopo deste documento, avalie como suas ferramentas e operações de segurança podem ajudar a proteger e monitorar os endpoints em busca de comprometimento. Pense nas seguintes observações:

  • Como a segurança física das estações de trabalho do desenvolvedor é protegida?
  • Como você identifica e responde a violações de rede?
  • Como os usuários têm acesso remoto a sessões SSH ou RDP?
  • Como credenciais persistentes, como chaves SSH ou chaves de conta de serviço, podem ser comprometidas?
  • Existem fluxos de trabalho que usam credenciais persistentes que podem ser substituídas por credenciais de curta duração?
  • Há dispositivos compartilhados em que alguém pode ler as credenciais da CLI gcloud de outro usuário?
  • Um usuário pode se autenticar com a CLI gcloud em um dispositivo não confiável?
  • Como o tráfego aprovado se conecta aos recursos dentro do perímetro do VPC Service Controls?

Certifique-se de que suas operações de segurança abordam cada uma dessas questões.

Alinhar suas equipes de resposta

Confirme com antecedência se as equipes de segurança responsáveis pela resposta a incidentes têm acesso apropriado ao Google Cloud console e ao Admin Console. Se equipes separadas gerenciam o Google Cloud console e o Admin Console, você é possível que você receba uma resposta atrasada durante um incidente.

Para avaliar e responder a um comprometimento, consulte Responder a credenciais comprometidas Google Cloud .

Monitorar o comprometimento de credenciais

Para monitorar possíveis comprometimentos, considere o seguinte:

  • Verifique se há secrets nos repositórios de código usando ferramentas como Anomaly Detection ou verificação secreta.

  • Nos Registros de Auditoria do Cloud, configure alertas para o seguinte:

    • Métodos iamcredentials.googleapis.com (como GenerateAccessToken, GenerateIdToken, SignJwt) para auditar a geração de tokens de conta de serviço

      Esses registros exigem que você ative os registros de acesso aos dados.

    • protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail para auditar representações de usuários e conta de serviço

    • Solicitações de troca sts.googleapis.com para declarações de identidade anômalas

  • No Security Command Center, monitore as seguintes descobertas de ameaças do Event Threat Detection:

    • Persistência: nova região geográfica
    • Persistência: novo user agent
    • Persistência: novo método de API
    • Evasão: acesso de proxy de anonimização
    • Escalonamento de privilégios: falsificação de identidade anômala de conta de serviço para atividade de administrador
    • Escalonamento de privilégios: falsificador de identidade anômalo de conta de serviço para atividade de administrador
    • Acesso inicial: chave da conta de serviço vazada usada
    • Persistência: chave da conta de serviço criada
    • Acesso inicial: login suspeito bloqueado
    • Acesso inicial: conta desativada

    Para cada ameaça, etapas de investigação recomendadas são fornecidas para ajudar na resposta.

  • Monitore os logins dos usuários no Google Workspace e no Cloud Identity. Para acompanhar melhor os problemas, exporte os registros para o Cloud Logging.

  • Monitore os registros do Chrome Enterprise Premium e do VPC Service Controls para tentativas de acesso fora do perímetro com tokens roubados.

  • Monitore anomalias no uso de chaves da conta de serviço com o Cloud Monitoring.

Certifique-se de que sua Central de Operações de Segurança (SOC) seja notificada imediatamente e tenha os playbooks, as ferramentas e o acesso necessários para responder rapidamente a uma suspeita de comprometimento de credenciais. Também é possível integrar o Security Command Center aos seus SIEM ou importar logs para o Google Security Operations para uma análise mais aprofundada.

A seguir