Práticas recomendadas para mitigar tokens OAuth comprometidos para a CLI Google Cloud

Last reviewed 2025-03-10 UTC

Este documento descreve como mitigar o impacto de um atacante que comprometa os tokens de portador OAuth usados pela CLI gcloud.

Um atacante pode comprometer estes tokens OAuth se obtiver acesso a um ponto final onde uma conta de utilizador legítima ou uma conta de serviço já foi autenticada com a CLI gcloud. O atacante pode, em seguida, copiar estes tokens para outro ponto final que controla para fazer pedidos que se fazem passar pela identidade legítima. Mesmo depois de remover o acesso do atacante ao ponto final comprometido, o atacante pode continuar a fazer pedidos de API autenticados através dos tokens copiados. Para ajudar a mitigar este risco, pode controlar o acesso aos seus sistemas através de credenciais de curta duração e sensíveis ao contexto.

Este documento destina-se a equipas de segurança ou arquitetos da nuvem que são responsáveis por proteger os respetivos recursos da nuvem contra acesso ilegítimo. Este documento apresenta os controlos disponíveis que pode usar para reduzir proativamente o impacto dos tokens OAuth da CLI gcloud comprometidos e corrigir o seu ambiente depois de um ponto final ter sido comprometido.

Vista geral

Para compreender como esta ameaça funciona, tem de compreender como a CLI gcloud armazena credenciais OAuth 2.0 e como essas credenciais podem ser usadas indevidamente se forem comprometidas por um atacante.

Tipos de credenciais armazenadas pela CLI gcloud

A CLI gcloud usa chaves de acesso OAuth 2.0 para autenticar pedidos de Google Cloud APIs. O fluxo OAuth varia consoante os tipos de credenciais usados, mas, geralmente, o token de acesso e outras credenciais estão acessíveis localmente. Em cada caso, o token de acesso expira após 60 minutos, mas outros tipos de credenciais podem ser persistentes.

Quando autoriza a CLI gcloud com uma conta de utilizador, a CLI gcloud inicia um fluxo de consentimento do OAuth de três partes para aceder àsGoogle Cloud APIs em nome do utilizador. Depois de o utilizador concluir o fluxo de consentimento, a CLI gcloud recebe uma chave de acesso e uma chave de atualização que lhe permite pedir novas chaves de acesso. O token de atualização de longa duração persiste até que as respetivas condições de validade sejam cumpridas.

Quando autoriza a CLI gcloud com uma conta de serviço, a CLI gcloud inicia um fluxo OAuth de duas pernas para aceder àsGoogle Cloud APIs como a identidade da conta de serviço. Depois de ativar uma conta de serviço a partir de um ficheiro de chave privada, esta chave é usada para pedir periodicamente um token de acesso. A chave privada de longa duração é armazenada na configuração da CLI gcloud e permanece válida até eliminar a chave da conta de serviço.

Quando executa a CLI gcloud num ambiente, como o Compute Engine ou o Cloud Shell, a aplicação pode encontrar automaticamente as credenciais e autenticar-se como uma conta de serviço. Google Cloud Por exemplo, no Compute Engine, uma aplicação como a CLI gcloud pode consultar o servidor de metadados para obter um token de acesso. A Google gere e roda a chave de assinatura privada usada para criar o token de acesso, e as credenciais de longa duração não são expostas à aplicação.

Quando se autentica com a federação de identidades da carga de trabalho, as aplicações autenticam-se com base numa credencial de um fornecedor de identidade externo e recebem um token de acesso federado de curta duração. Para mais informações sobre como armazenar e gerir as credenciais de longa duração usadas pelo fornecedor de identidade externo, consulte as práticas recomendadas para usar a federação de identidades de cargas de trabalho.

Como um atacante pode usar tokens OAuth comprometidos

Se um atacante conseguir comprometer um ponto final, as credenciais, como os tokens OAuth, são alvos valiosos porque permitem que os atacantes persistam ou aumentem o respetivo acesso.

Um programador pode ter uma necessidade legítima de ver as suas próprias credenciais quando escreve e depura código. Por exemplo, um programador pode ter de se autenticar para usar pedidos REST para Google Cloud serviços quando trabalha com uma biblioteca cliente não suportada. O programador pode ver as credenciais através de vários métodos, incluindo os seguintes:

No entanto, um atacante pode usar estas mesmas técnicas depois de comprometer um ponto final.

Se um atacante comprometer um ponto final, como uma estação de trabalho de programador, a principal ameaça é que o atacante pode executar comandos da CLI gcloud ou outro código com as credenciais legítimas da identidade autenticada. Além disso, o atacante pode copiar os tokens OAuth para outro ponto final que controla para persistir no acesso. Quando este roubo de credenciais acontece, existe uma ameaça secundária de que o atacante ainda pode usar os tokens OAuth de longa duração para ter acesso persistente, mesmo depois de remover o acesso ao ponto final comprometido.

Se o atacante conseguir comprometer os tokens OAuth, pode concluir as seguintes ações:

  • Um atacante pode roubar a identidade do utilizador ou da conta de serviço comprometida. O tráfego da API que usa os tokens comprometidos é registado como se fosse proveniente do utilizador ou da conta de serviço comprometida, o que dificulta a distinção entre a atividade normal e a atividade maliciosa nos registos.
  • Um atacante pode atualizar a chave de acesso indefinidamente através de uma chave de atualização persistente associada a um utilizador ou uma chave privada associada a uma conta de serviço.
  • Um atacante pode contornar a autenticação com a palavra-passe do utilizador ou a validação em 2 passos, uma vez que os tokens são concedidos após o fluxo de início de sessão.

Práticas recomendadas para mitigar riscos

Implemente os controlos descritos nas secções seguintes para ajudar a mitigar o risco de tokens da CLI gcloud comprometidos. Se estiver a seguir as práticas recomendadas de segurança descritas no projeto de base empresarial ou no design da zona de destino no Google Cloud, já pode ter estes controlos implementados.

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

Para reduzir o tempo durante o qual um atacante pode explorar um token comprometido, defina a duração da sessão para os Google Cloud serviços. Para novos clientes, é aplicada automaticamente uma duração da sessão predefinida de 16 horas. Os clientes que criaram a respetiva Google Cloud organização antes de 2023 podem ter uma predefinição para nunca exigir a reautenticação. Reveja esta definição para garantir que tem uma política de reautenticação com uma duração da sessão entre 1 e 24 horas. A política de reautenticação invalida o token de atualização e força o utilizador a reautenticar regularmente a CLI gcloud com a respetiva palavra-passe ou chave de segurança.

A duração da sessão para os Google Cloud serviços é uma definição distinta da duração da sessão para os serviços Google, que controla as sessões Web para início de sessão nos serviços Google Workspace, mas não controla a reautenticação para o Google Cloud. Se usar os serviços do Google Workspace, defina a duração da sessão para ambos.

Configure os VPC Service Controls

Configure o VPC Service Controls no seu ambiente para ajudar a garantir que apenas o tráfego de API que tem origem no seu perímetro definido pode aceder aos recursos suportados. Google Cloud O perímetro de serviço limita a utilidade das credenciais comprometidas porque o perímetro bloqueia pedidos a serviços restritos que têm origem em pontos finais controlados por atacantes que estão fora do seu ambiente.

Configure o Chrome Enterprise Premium

Configure políticas do Chrome Enterprise Premium para ajudar a proteger a Google Cloud consola e as Google Cloud APIs. Configure um nível de acesso do Chrome Enterprise Premium e uma associação para permitir seletivamente atributos que são avaliados em todos os pedidos de API, incluindo acesso baseado em IP ou acesso baseado em certificados para TLS mútuo. Os pedidos que usam credenciais de autorização comprometidas, mas não cumprem as condições definidas na sua política do Chrome Enterprise Premium, são rejeitados.

O Chrome Enterprise Premium é um controlo centrado no utilizador que rejeita o tráfego da API do utilizador que não cumpre as condições definidas. O VPC Service Controls é um controlo centrado nos recursos que define os perímetros dentro dos quais os recursos podem comunicar. Os VPC Service Controls aplicam-se a todas as identidades de utilizadores e identidades de contas de serviço, mas o Chrome Enterprise Premium aplica-se apenas às identidades de utilizadores na sua organização. Quando usados em conjunto, o Chrome Enterprise Premium e os VPC Service Controls reduzem a eficácia das credenciais comprometidas numa máquina controlada por um atacante que está fora do seu ambiente.

Aplique a validação em dois passos para o acesso ao servidor remoto

Se permitir que os programadores acedam aos recursos do Compute Engine através de SSH, configure o Início de sessão do SO com a validação em dois passos. Isto aplica um ponto de verificação adicional em que um utilizador tem de fazer novamente a autenticação com a respetiva palavra-passe ou chave de segurança. Um atacante com tokens OAuth comprometidos, mas sem uma palavra-passe ou uma chave de segurança, é bloqueado por esta funcionalidade.

O acesso ao Protocolo de ambiente de trabalho remoto (RDP) a instâncias do Windows no Compute Engine não suporta o serviço de início de sessão do SO, pelo que não é possível aplicar a validação em dois passos de forma detalhada às sessões do RDP. Quando usar o IAP Desktop ou plug-ins de RDP baseados no Google Chrome, defina controlos detalhados, como a duração da sessão para os serviços Google e as definições de validação em dois passos para as sessões Web do utilizador, e desative a definição Permitir que o utilizador confie no dispositivo na validação em dois passos.

Restrinja a utilização de chaves de contas de serviço

Quando usa uma chave da conta de serviço para fazer a autenticação, o valor da chave é armazenado nos ficheiros de configuração da CLI gcloud, separadamente do ficheiro de chave transferido. Um atacante com acesso ao seu ambiente pode copiar a chave da configuração da CLI gcloud ou copiar o ficheiro de chave do seu sistema de ficheiros local ou repositório de código interno. Por conseguinte, além do seu plano para mitigar tokens de acesso comprometidos, pondere como gere os ficheiros de chaves de contas de serviço transferidos.

Reveja as alternativas de autenticação mais seguras para reduzir ou eliminar os seus exemplos de utilização que dependem de uma chave de conta de serviço e aplique a restrição da política da organização iam.disableServiceAccountKeyCreation para desativar a criação de chaves de contas de serviço.

Considere o princípio do menor privilégio

Ao criar políticas IAM, considere o menor privilégio. Conceda aos utilizadores as funções de que precisam para realizar uma tarefa no âmbito mais pequeno. Não lhes atribua funções de que não precisam. Reveja e aplique as recomendações de funções para evitar políticas IAM com funções não utilizadas e excessivas no seu ambiente.

Proteja os seus pontos finais

Considere como um atacante pode obter acesso físico ou acesso remoto aos seus pontos finais, como estações de trabalho de programadores ou instâncias do Compute Engine. Embora um plano para resolver a ameaça de tokens OAuth comprometidos seja importante, considere também como responder à ameaça de como um atacante pode comprometer os seus pontos finais fidedignos. Se um atacante tiver acesso aos seus pontos finais fidedignos, pode executar comandos da CLI gcloud ou outro código diretamente no próprio ponto final.

Embora a proteção abrangente das estações de trabalho dos programadores esteja fora do âmbito deste documento, avalie como as suas ferramentas e operações de segurança podem ajudar a proteger e monitorizar os seus pontos finais contra comprometimento. Considere as seguintes questões:

  • Como é protegida a segurança física das estações de trabalho dos programadores?
  • Como identifica e responde a violações de rede?
  • Como é que os utilizadores obtêm acesso remoto a sessões SSH ou RDP?
  • Como é que outras credenciais persistentes, como chaves SSH ou chaves de contas 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?
  • Existem dispositivos partilhados nos quais alguém possa ler as credenciais da CLI gcloud em cache de outro utilizador?
  • Um utilizador pode autenticar-se com a CLI gcloud a partir de um dispositivo não fidedigno?
  • Como é que o tráfego aprovado se liga aos recursos dentro do perímetro do VPC Service Controls?

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

Alinhe as suas equipas de resposta

Certifique-se antecipadamente de que as equipas de segurança responsáveis pela resposta a incidentes têm acesso adequado na Google Cloud consola e na consola do administrador. Se equipas separadas gerirem a Google Cloud consola e a consola do administrador, pode haver um atraso na resposta durante um incidente.

Para remover o acesso de uma conta de utilizador comprometida, a sua equipa de resposta a incidentes precisa de uma função da consola do administrador, como administrador de gestão de utilizadores. Para avaliar se ocorreu atividade suspeita nos seus recursos Google Cloud, esta equipa também pode precisar de funções do IAM, como revisor de segurança em todos os projetos ou visualizador de registos num destino de registos centralizado. As funções necessárias para a sua equipa de segurança variam consoante a conceção e o funcionamento do seu ambiente.

Práticas recomendadas para a remediação após um incidente de segurança

Após um ponto final ser comprometido, como parte do seu plano de gestão de incidentes, determine como responder à ameaça principal de um ponto final comprometido e como mitigar potenciais danos contínuos da ameaça secundária de tokens comprometidos. Se um atacante tiver acesso persistente à estação de trabalho do programador, pode copiar novamente os tokens depois de o utilizador legítimo voltar a autenticar-se. Se suspeitar que os tokens da CLI gcloud podem ter sido comprometidos, abra um pedido junto ao apoio técnico ao cliente da nuvem e conclua as recomendações nas secções seguintes. Estas ações podem ajudar a limitar o impacto de um evento como este na sua organização. Google Cloud

As recomendações nesta secção sobrepõem-se às orientações gerais sobre a gestão de credenciais comprometidas Google Cloud , mas focam-se especificamente na ameaça de tokens da CLI gcloud que são copiados de um ponto final comprometido.

Faça expirar as chaves ativas de todas as contas de utilizador com Google Cloud controlo de sessão

Se ainda não o fez, aplique o Google Cloud controlo de sessão> imediatamente com uma frequência de reautenticação curta. Este controlo ajuda a garantir que todos os tokens de atualização expiram no final da duração que definir, o que limita a duração durante a qual um atacante pode usar os tokens comprometidos.

Invalide manualmente tokens de contas de utilizadores comprometidas

Reveja as orientações para lidar com credenciais comprometidas de todas as identidades de utilizadores que possam ter sido comprometidas. Em particular, a remoção das credenciais da CLI gcloud é o método mais eficaz para uma equipa de segurança resolver tokens OAuth comprometidos para identidades de utilizadores. Para invalidar imediatamente os tokens de atualização e os tokens de acesso para a CLI gcloud e forçar o utilizador a autenticar-se novamente com a respetiva palavra-passe ou chave de segurança, remova a CLI gcloud da lista de aplicações ligadas de um utilizador.

Um utilizador individual também pode remover as credenciais da CLI gcloud para a respetiva conta individual.

Outros métodos, como suspender o utilizador, repor a palavra-passe do utilizador ou repor os cookies de início de sessão, não abordam especificamente a ameaça de tokens OAuth comprometidos. Estes métodos são geralmente úteis para a resposta a incidentes, mas não invalidam os tokens de acesso que o atacante já controla. Por exemplo, se optar por suspender um utilizador durante uma investigação, mas não revogar os tokens da CLI gcloud, os tokens de acesso podem continuar a ser válidos se o utilizador suspenso for restaurado antes da expiração dos tokens de acesso.

Invalide programaticamente tokens para muitas contas de utilizadores

Se suspeitar de uma violação, mas não conseguir identificar os utilizadores afetados, considere revogar as sessões ativas de todos os utilizadores na sua organização mais rapidamente do que a política de reautenticação permite.

Esta abordagem pode ser prejudicial para os utilizadores legítimos e terminar processos de longa duração que dependem das credenciais do utilizador. Se optar por adotar esta abordagem, prepare uma solução com script para o seu centro de operações de segurança (SOC) executar antecipadamente e teste-a com alguns utilizadores.

O seguinte código de exemplo usa o Admin SDK do Workspace para identificar todas as identidades de utilizadores na sua conta do Google Workspace ou Cloud ID que têm acesso à CLI gcloud. Se um utilizador tiver autorizado a CLI gcloud, o script revoga o token de atualização e o token de acesso e força o utilizador a autenticar-se novamente com a respetiva palavra-passe ou chave de segurança. Para ver instruções sobre como ativar a API Admin SDK e executar este código, consulte o início rápido do Google Apps Script.

/**
 * Remove access to the Google Cloud CLI for all users in an organization
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/tokens
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/users
 * @see https://developers.google.com/apps-script/guides/services/advanced#enabling_advanced_services
 */

function listUsersAndInvalidate() {
  const users = AdminDirectory.Users.list({
    customer: 'my_customer' // alias to represent your account's customerId
    }).users;
  if (!users || users.length === 0) {
    Logger.log('No users found.');
    return;
  }
  for (const user of users){
    let tokens = AdminDirectory.Tokens.list(user.primaryEmail).items
    if (!tokens || tokens.length === 0) {
      continue;
    }
    for (const token of tokens) {
      if (token.clientId === "32555940559.apps.googleusercontent.com") {
        AdminDirectory.Tokens.remove(user.primaryEmail, token.clientId)
        Logger.log('Invalidated the tokens granted to gcloud for user %s', user.primaryEmail)
      }
    }
  }
}

Invalide e altere as credenciais das contas de serviço

Ao contrário das chaves de acesso concedidas a identidades de utilizadores, as chaves de acesso concedidas a contas de serviço não podem ser invalidadas através da consola do administrador nem de comandos como gcloud auth revoke. Além disso, a duração da sessão que especificar no Google Cloud controlo de sessão aplica-se às contas de utilizador no seu diretório do Cloud Identity ou Google Workspace, mas não às contas de serviço. Por conseguinte, a sua resposta a incidentes para contas de serviço comprometidas tem de abordar os ficheiros de chaves persistentes e os tokens de acesso de curta duração.

Se suspeitar que as credenciais de uma conta de serviço foram comprometidas, desative a conta de serviço, elimine as chaves da conta de serviço se existirem e, em seguida, após 60 minutos, ative a conta de serviço. A eliminação de uma chave de conta de serviço pode invalidar a credencial de longa duração para que um atacante não possa pedir uma nova chave de acesso, mas não invalida as chaves de acesso já concedidas. Para garantir que as chaves de acesso não são usadas indevidamente durante a respetiva duração total de 60 minutos, tem de desativar a conta de serviço durante 60 minutos.

Em alternativa, pode eliminar e substituir a conta de serviço para revogar imediatamente todas as credenciais de curta e longa duração, mas isto pode exigir um trabalho mais disruptivo para substituir a conta de serviço nas aplicações.

O que se segue?