Práticas recomendadas para reduzir os tokens OAuth comprometidos no Google Cloud CLI

Last reviewed 2024-02-15 UTC

Este documento descreve como reduzir o impacto de um invasor comprometendo os tokens OAuth usados pela CLI gcloud.

Um invasor pode comprometer esses tokens do OAuth se ganhar acesso a um endpoint em que uma conta de usuário ou de serviço legítima já foi autenticada com 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.

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. Neste documento, apresentamos os controles disponíveis que podem ser usados para reduzir proativamente o impacto dos tokens OAuth da CLI gcloud comprometidos e corrigir o ambiente depois que um endpoint for comprometido.

Visão geral

Para entender como essa ameaça funciona, é preciso entender como a CLI gcloud armazena credenciais do OAuth 2.0 e como essas credenciais podem ser violadas se forem comprometidas por um invasor.

Tipos de credenciais armazenadas pela CLI gcloud

A CLI gcloud usa tokens de acesso OAuth 2.0 para autenticar solicitações para APIs Google Cloud. 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, mas outros tipos de credenciais podem ser persistentes.

Quando você autoriza a CLI gcloud com uma conta de usuário, a CLI gcloud inicia um fluxo de consentimento do OAUTH de três etapas para acessar as APIs Google Cloud 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. Nas configurações padrão, 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, a CLI gcloud inicia um fluxo de consentimento do OAUTH de três etapas para acessar as APIs Google Cloud como a identidade da conta de serviço. Depois que você ativar uma conta de serviço de um arquivo de chave privada, essa chave será usada 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ê exclua a chave da conta de serviço.

Quando você executa a CLI gcloud em um ambiente do Google Cloud, 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.

Quando você faz a autenticação com a federação de identidade da carga de trabalho, os aplicativos são autenticados com base em uma credencial de um provedor de identidade externo e recebem um token de acesso federado de curta duração. Para mais informações sobre como armazenar e gerenciar as credenciais de longa duração usadas pelo provedor de identidade externo, consulte práticas recomendadas para usar a federação de identidade da carga de trabalho.

Como um invasor pode usar tokens OAuth comprometidos

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 se autenticar para usar solicitações REST nos serviços do Google Cloud ao trabalhar com uma biblioteca de cliente sem compatibilidade. 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, como uma estação de trabalho de desenvolvedor, 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 os tokens OAuth para outro endpoint que eles controlam para manter o acesso. Quando esse roubo de credenciais ocorre, há uma ameaça secundária de que o invasor ainda pode usar os tokens OAuth de longa duração para ter acesso permanente, mesmo depois que você remove o acesso ao endpoint comprometido.

Se o invasor conseguir comprometer tokens OAuth, ele poderá realizar as seguintes ações:

  • Um invasor pode falsificar 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.
  • Um invasor pode atualizar o token de acesso indefinidamente usando um token de atualização persistente associado a um usuário ou a uma chave privada associada a uma conta de serviço.
  • Um invasor pode 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.

Práticas recomendadas para reduzir os riscos

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

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

Para reduzir o tempo que um invasor pode explorar um token comprometido, defina a duração da sessão para os serviços do Google Cloud. Por padrão, o token de atualização que o sistema concede após a autenticação é uma credencial de longa duração, e uma sessão da CLI gcloud nunca exige reautenticação. Altere essa configuração para configurar uma política de reautenticação com uma duração de sessão de 1 a 24 horas. Após a duração da sessão definida, a política de reautenticação invalida o token de atualização e 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 dos serviços do Google Cloud é diferente da duração da sessão dos 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 do 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 o VPC Service Controls em todo o ambiente para garantir que apenas o tráfego da API Google Cloud 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 console do Google Cloud e as APIs do Google Cloud. Configure um nível de acesso e vinculação do Chrome Enterprise Premium Enterprise para permitir seletivamente atributos 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.

Aplique 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 IAP para computadores ou plug-ins RDP baseados no Google Chrome, defina controles gerais, como duração da sessão para serviços do Google e configurações da verificação em duas etapas para as sessões da Web do usuário e desative a configuração Permitir que o usuário confie no dispositivo na verificação em duas etapas.

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 da gcloud, separadamente do arquivo de chave baixado. Um invasor com acesso ao seu ambiente pode copiar a chave da configuração da CLI do 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.

Revisão alternativas mais seguras para a autenticação, para reduzir ou eliminar os casos de uso que dependem de uma chave de conta de serviço e aplicar a restrição na política da organização iam.disableServiceAccountKeyCreation para desativar a criação da chave da conta de serviço.

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

Ao criar políticas do IAM, considere o privilégio mínimo. Conceda aos usuários os papéis necessários para realizar uma tarefa no menor escopo. Não conceda a eles papéis que não são necessários. 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 tokens OAuth comprometidos seja importante, considere também como responder à ameaça de como um invasor pode 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 no próprio endpoint.

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 outras 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 Control?

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 console do Google Cloud e ao Admin Console. Se equipes separadas gerenciam o console do Google Cloud e o Admin Console, é possível que você receba uma resposta atrasada durante um incidente.

Para remover o acesso de uma conta de usuário comprometida, a equipe de resposta a incidentes precisa de um papel do Admin Console, como Administrador de gerenciamento de usuários. Para avaliar se ocorreu alguma atividade suspeita nos recursos do Google Cloud, essa equipe também pode precisar de papéis do IAM, como Revisor de segurança, em todos os projetos ou Visualizador de registros em um coletor de registros centralizado. Os papéis necessários para a equipe de segurança variam de acordo com o projeto e a operação do ambiente.

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

Depois que um endpoint for comprometido, como parte do plano de gerenciamento de incidentes, determine como responder à ameaça principal de um endpoint comprometido e como mitigar possíveis danos contínuos da ameaça secundária dos tokens comprometidos. Se um invasor tiver acesso persistente à estação de trabalho do desenvolvedor, ele poderá copiar tokens novamente após a reautenticação do usuário legítimo. Se você suspeitar que os tokens da CLI gcloud podem estar comprometidos, abra um tíquete com o Cloud Customer Care e conclua as recomendações nas seções a seguir. Essas ações podem ajudar a limitar o impacto de um evento como esse na sua organização do Google Cloud.

As recomendações nesta seção se sobrepõem às orientações gerais sobre como processar credenciais comprometidas do Google Cloud, mas foque especificamente na ameaça dos tokens da CLI gcloud que são copiados de um endpoint comprometido.

Expirar tokens ativos para todas as contas de usuário com o controle da sessão do Google Cloud

Caso você ainda não tenha aplicado o controle da sessão do Google Cloud, ative-o imediatamente com uma frequência curta de reautenticação. Esse controle ajuda a garantir que todos os tokens de atualização expirem no final da duração definida, o que limita o tempo em que um invasor pode usar os tokens comprometidos.

Invalidar manualmente os tokens em contas de usuário comprometidas.

Leia as orientações para gerenciar credenciais comprometidas para qualquer identidade de usuário que possa ter sido comprometida. Especificamente, remover credenciais da CLI gcloud é o método mais eficaz para uma equipe de segurança lidar com tokens OAuth comprometidos para identidades de usuário. Para invalidar imediatamente os tokens de atualização e de acesso à CLI gcloud e forçar o usuário a se autenticar novamente com a senha ou a chave de segurança, remova a CLI gcloud da lista de aplicativos conectados de um usuário.

Um usuário individual também pode remover as credenciais da CLI gcloud da conta individual.

Outros métodos, como suspender o usuário, redefinir a senha do usuário ou redefinir cookies de login, não lidam especificamente com a ameaça de tokens OAuth comprometidos. Esses métodos geralmente são úteis para resposta a incidentes, mas não validam os tokens de acesso que o invasor já controla. Por exemplo, se você suspender um usuário durante uma investigação, mas não revogar os tokens da CLI gcloud, os tokens de acesso ainda poderão ser válidos se o usuário suspenso for restaurado antes que os tokens de acesso expirem.

Invalidar de maneira programática os tokens de muitas contas de usuário

Se você suspeitar de uma violação, mas não conseguir identificar quais usuários foram afetados, revogue as sessões ativas para todos os usuários da sua organização mais rapidamente do que a política de reautenticação permite.

Essa abordagem pode ser prejudicial para usuários legítimos e encerrar processos de longa duração que dependem das credenciais do usuário. Se você escolher adotar essa abordagem, prepare uma solução de script para a Central de Operações de Segurança (SOC, na sigla em inglês) para ser executada com antecedência e teste com alguns usuários.

O exemplo de código a seguir usa o SDK Admin do Workspace para identificar todas as identidades de usuário na sua conta do Google Workspace ou do Cloud Identity que têm acesso à CLI gcloud. Se um usuário tiver autorizado a CLI gcloud, o script revogará o token de atualização e o token de acesso e o forçará a se autenticar novamente com a senha ou a chave de segurança. Para instruções sobre como ativar a API SDK Admin e executar esse código, consulte o Guia de 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)
      }
    }
  }
}

Invalidar e alternar credenciais para contas de serviço

Ao contrário dos tokens de acesso concedidos a identidades de usuário, tokens de acesso concedidos a contas de serviço não podem ser invalidados no Admin Console ou em comandos como gcloud auth revoke. Além disso, a duração da sessão especificada no controle da sessão do Google Cloud se aplica a contas de usuário no diretório do Cloud Identity ou do Google Workspace, mas não a contas de serviço. Portanto, a resposta ao incidente para contas de serviço comprometidas precisa resolver os arquivos de chaves permanentes e os tokens de acesso de curta duração.

Se você suspeitar que as credenciais de uma conta de serviço foram comprometidas, desative a conta de serviço e exclua as chaves da conta de serviço se houver e, em seguida, após 60 minutos, ative a conta de serviço. A exclusão de uma chave de conta de serviço pode invalidar a credencial de longa duração para que um invasor não consiga solicitar um novo token de acesso, mas não invalida os tokens de acesso já concedidos. Para garantir que os tokens de acesso não sejam usados de forma indevida dentro do ciclo de vida de 60 minutos, é necessário desativar a conta de serviço por 60 minutos.

Como alternativa, é possível excluir e substituir a conta de serviço para revogar imediatamente todas as credenciais de curta e longa duração, mas isso pode exigir mais trabalho para substituir a conta de serviço nos aplicativos.

A seguir