Best practice per la mitigazione dei token OAuth compromessi per Google Cloud CLI

Last reviewed 2025-03-10 UTC

Questo documento descrive come ridurre l'impatto della compromissione da parte di un malintenzionato dei token di autenticazione OAuth utilizzati da gcloud CLI.

Un malintenzionato puรฒ compromettere questi token OAuth se ottiene l'accesso a un endpoint in cui un account utente o unaccount di serviziot legittimo รจ giร  stato autenticato con la gcloud CLIud. L'autore dell'attacco puรฒ quindi copiare questi token in un altro endpoint che controlla per effettuare richieste che impersonano l'identitร  legittima. Anche dopo aver rimosso l'accesso dell'autore dell'attacco all'endpoint compromesso, l'autore dell'attacco puรฒ continuare a effettuare richieste API autenticate utilizzando i token copiati. Per contribuire a mitigare questo rischio, puoi controllare l'accesso ai tuoi sistemi utilizzando credenziali di breve durata e sensibili al contesto.

Questo documento รจ destinato ai team di sicurezza o ai cloud architect responsabili della protezione delle risorse cloud da accessi illegittimi. Questo documento introduce i controlli disponibili che puoi utilizzare per ridurre in modo proattivo l'impatto dei token OAuth di gcloud CLI compromessi e correggere il tuo ambiente dopo che un endpoint รจ stato compromesso.

Panoramica

Per capire come funziona questa minaccia, devi comprendere in che modo la gcloud CLId archivia le credenziali OAuth 2.0 e come queste credenziali possono essere usate in modo improprio se compromesse da un malintenzionato.

Tipi di credenziali archiviate da gcloud CLI

gcloud CLI utilizza token di accesso OAuth 2.0 per autenticare le richieste per le API Google Cloud . Il flusso OAuth varia in base ai tipi di credenziali utilizzati, ma in genere il token di accesso e altre credenziali sono accessibili localmente. In ogni caso, il token di accesso scade dopo 60 minuti, ma altri tipi di credenziali potrebbero essere persistenti.

Quando autorizzi gcloud CLI con un account utente, gcloud CLI avvia un flusso di consenso OAuth a tre vie per accedere alle APIGoogle Cloud per conto dell'utente. Dopo che l'utente completa il flusso di consenso, gcloud CLI riceve un token di accesso e un token di aggiornamento che gli consente di richiedere nuovi token di accesso. Il token di aggiornamento di lunga durata rimane valido fino al soddisfacimento delle condizioni di scadenza.

Quando autorizzi gcloud CLI con un service account, gcloud CLI avvia un flusso OAuth a due passaggi per accedere alle APIGoogle Cloud come identitร  del account di servizio. Dopo aver attivato un account di servizio da un file di chiave privata, questa chiave viene utilizzata per richiedere periodicamente un token di accesso. La chiave privata di lunga durata viene archiviata nella configurazione di gcloud CLI e rimane valida finchรฉ non elimini la account di servizio account.

Quando esegui gcloud CLI all'interno di un ambiente Google Cloud, come Compute Engine o Cloud Shell, l'applicazione puรฒ trovare automaticamente le credenziali e autenticarsi come service account. Ad esempio, in Compute Engine, un'applicazione come gcloud CLI puรฒ eseguire query sul server di metadati per ottenere un token di accesso. Google gestisce e ruota la chiave di firma privata utilizzata per creare il token di accesso e le credenziali di lunga durata non vengono esposte all'applicazione.

Quando esegui l'autenticazione con la federazione delle identitร  dei workload, le applicazioni si autenticano in base a una credenziale di un provider di identitร  esterno e ricevono un token di accesso federato di breve durata. Per ulteriori informazioni su come archiviare e gestire le credenziali a lunga durata utilizzate dal provider di identitร  esterno, consulta le best practice per l'utilizzo della federazione delle identitร  dei carichi di lavoro.

Come un malintenzionato puรฒ utilizzare i token OAuth compromessi

Se un malintenzionato riesce a compromettere un endpoint, le credenziali come i token OAuth sono obiettivi preziosi perchรฉ consentono agli aggressori di mantenere o aumentare il proprio accesso.

Uno sviluppatore potrebbe avere la necessitร  legittima di visualizzare le proprie credenziali durante la scrittura e il debug del codice. Ad esempio, uno sviluppatore potrebbe dover autenticarsi per utilizzare le richieste REST ai servizi Google Cloud quando lavora con una libreria client non supportata. Lo sviluppatore puรฒ visualizzare le credenziali in vari modi, tra cui:

Tuttavia, un malintenzionato potrebbe utilizzare queste stesse tecniche dopo aver compromesso un endpoint.

Se un malintenzionato compromette un endpoint, ad esempio una workstation di sviluppo, la minaccia principale รจ che possa eseguire comandi dell'interfaccia a riga di comandogcloud CLId o altro codice con le credenziali legittime dell'identitร  autenticata. Inoltre, l'autore dell'attacco potrebbe copiare i token OAuth in un altro endpoint che controlla per mantenere l'accesso. Quando si verifica questo furto di credenziali, esiste una minaccia secondaria: l'aggressore puรฒ comunque utilizzare i token OAuth di lunga durata per avere accesso persistente anche dopo la rimozione dell'accesso all'endpoint compromesso.

Se l'aggressore riesce a compromettere i token OAuth, puรฒ completare le seguenti azioni:

  • Un malintenzionato puรฒ rappresentare l'utente o il account di servizio compromesso. Il traffico API che utilizza i token compromessi viene registrato come se provenisse dall'utente o dall'account di servizio compromesso, rendendo difficile distinguere l'attivitร  normale da quella dannosa nei log.
  • Un malintenzionato puรฒ aggiornare il token di accesso all'infinito utilizzando un token di aggiornamento persistente associato a un utente o una chiave privata associata a unaccount di serviziont.
  • Un malintenzionato puรฒ bypassare l'autenticazione con la password dell'utente o la verifica in due passaggi perchรฉ i token vengono concessi dopo il flusso di accesso.

Best practice per la mitigazione dei rischi

Implementa i controlli descritti nelle sezioni seguenti per contribuire a ridurre il rischio di token gcloud CLI compromessi. Se segui le best practice per la sicurezza descritte nel blueprint delle fondamenta aziendali o nella progettazione della landing zone in Google Cloud, potresti aver giร  implementato questi controlli.

Impostare la durata della sessione per i servizi Google Cloud

Per ridurre il periodo di tempo in cui un malintenzionato puรฒ sfruttare un token compromesso, imposta la durata della sessione per i servizi Google Cloud . Per i nuovi clienti, viene applicata automaticamente una durata della sessione predefinita di 16 ore. I clienti che hanno creato la propria Google Cloud organizzazione prima del 2023 potrebbero avere un'impostazione predefinita che non richiede mai la riautenticazione. Rivedi questa impostazione per assicurarti di avere una norma di riautenticazione con una durata della sessione compresa tra 1 e 24 ore. Il criterio di riautenticazione invalida il token di aggiornamento e costringe l'utente a riautenticare regolarmente gcloud CLI con la password o il token di sicurezza.

La durata della sessione per i servizi Google Cloud รจ un'impostazione distinta dalla durata della sessione per i servizi Google, che controlla le sessioni web per l'accesso ai servizi Google Workspace, ma non controlla la riautenticazione per Google Cloud. Se utilizzi i servizi Google Workspace, imposta la durata della sessione per entrambi.

Configurazione dei Controlli di servizio VPC

Configura i Controlli di servizio VPC nel tuo ambiente per assicurarti che solo il traffico API Google Cloud che ha origine all'interno del perimetro definito possa accedere alle risorse supportate. Il perimetro di servizio limita l'utilitร  delle credenziali compromesse perchรฉ blocca le richieste ai servizi con limitazioni provenienti da endpoint controllati da malintenzionati che si trovano al di fuori del tuo ambiente.

Configura Chrome Enterprise Premium

Configura i criteri di Chrome Enterprise Premium per proteggere la console e le API. Google Cloud Google Cloud Configura un livello di accesso e un binding di Chrome Enterprise Premium per consentire selettivamente gli attributi valutati in ogni richiesta API, incluso l'accesso basato su IP o l'accesso basato su certificati per TLS reciproca. Le richieste che utilizzano credenziali di autorizzazione compromesse ma non soddisfano le condizioni definite nelle norme Chrome Enterprise Premium vengono rifiutate.

Chrome Enterprise Premium รจ un controllo incentrato sull'utente che rifiuta il traffico API utente che non soddisfa le condizioni definite. I Controlli di servizio VPC sono un controllo incentrato sulle risorse che definisce i perimetri all'interno dei quali le risorse possono comunicare. Controlli di servizio VPC si applica a tutte le identitร  utente e di account di servizio, ma Chrome Enterprise Premium si applica solo alle identitร  utente all'interno della tua organizzazione. Se utilizzati insieme, Chrome Enterprise Premium e i Controlli di servizio VPC riducono l'efficacia delle credenziali compromesse su una macchina controllata da un malintenzionato che si trova al di fuori del tuo ambiente.

Forzare la verifica in due passaggi per l'accesso al server remoto

Se consenti agli sviluppatori di accedere alle risorse Compute Engine utilizzando SSH, configura OS Login con la verifica in due passaggi. In questo modo viene applicato un checkpoint aggiuntivo in cui un utente deve eseguire nuovamente l'autenticazione con la propria password o il proprio token di sicurezza. Questa funzionalitร  blocca un malintenzionato con token OAuth compromessi, ma senza password o token di sicurezza.

L'accesso RDP (Remote Desktop Protocol) alle istanze Windows su Compute Engine non supporta il servizio di OS Login, pertanto la verifica in due passaggi non puรฒ essere applicata in modo granulare alle sessioni RDP. Quando utilizzi IAP Desktop o plug-in RDP basati su Google Chrome, imposta controlli granulari come la durata della sessione per i servizi Google e la verifica in due passaggi per le sessioni web dell'utente e disattiva l'impostazione Consenti all'utente di considerare attendibile il dispositivo nella verifica in due passaggi.

Limitare l'utilizzo delle chiavi del account di servizio

Quando utilizzi una chiave del account di servizio per l'autenticazione, il valore della chiave viene archiviato nei file di configurazione di gcloud CLI, separatamente dal file della chiave scaricato. Un malintenzionato con accesso al tuo ambiente potrebbe copiare la chiave dalla configurazione di gcloud CLI o copiare il file della chiave dal file system locale o dal repository di codice interno. Pertanto, oltre al piano per mitigare i token di accesso compromessi, valuta come gestire i file delle chiavi del service account scaricati.

Esamina alternative piรน sicure per l'autenticazione per ridurre o eliminare i casi d'uso che dipendono da una chiave del account di servizio e applica il vincolo del criterio dell'organizzazione iam.disableServiceAccountKeyCreation per disattivare la creazione di chiavi del account di servizio.

Considera il principio del privilegio minimo

Quando progetti le policy IAM, considera il privilegio minimo. Concedi agli utenti i ruoli necessari per svolgere un'attivitร  con il minimo ambito possibile. Non concedere ruoli non necessari. Esamina e applica i suggerimenti sui ruoli per evitare policy IAM con ruoli inutilizzati ed eccessivi nel tuo ambiente.

Proteggere gli endpoint

Valuta in che modo un malintenzionato potrebbe ottenere l'accesso fisico o remoto ai tuoi endpoint, come workstation per sviluppatori o istanze Compute Engine. Sebbene un piano per affrontare la minaccia di token OAuth compromessi sia importante, considera anche come rispondere alla minaccia di come un malintenzionato puรฒ compromettere i tuoi endpoint attendibili. Se un malintenzionato ha accesso ai tuoi endpoint attendibili, puรฒ eseguire comandi dell'interfaccia a riga dgcloud CLIud o altro codice direttamente sull'endpoint.

Sebbene la protezione completa delle workstation degli sviluppatori non rientri nell'ambito di questo documento, valuta in che modo le tue operazioni e i tuoi strumenti di sicurezza possono contribuire a proteggere e monitorare i tuoi endpoint per rilevare eventuali compromissioni. Considera le seguenti domande:

  • Come viene protetta la sicurezza fisica delle workstation degli sviluppatori?
  • Come identifichi e rispondi alle violazioni di rete?
  • In che modo gli utenti ottengono l'accesso remoto alle sessioni SSH o RDP?
  • In che modo altre credenziali persistenti come le chiavi SSH o le chiavi dei account di servizio possono essere compromesse?
  • Esistono flussi di lavoro che utilizzano credenziali persistenti che potrebbero essere sostituite con credenziali di breve durata?
  • Esistono dispositivi condivisi in cui qualcuno potrebbe leggere le credenziali memorizzate nella cache gcloud CLId di un altro utente?
  • Un utente puรฒ autenticarsi con gcloud CLI da un dispositivo non attendibile?
  • In che modo il traffico approvato si connette alle risorse all'interno del perimetro dei Service Control VPC?

Assicurati che le tue operazioni di sicurezza rispondano a ciascuna di queste domande.

Allineare i team di risposta

Assicurati in anticipo che i team di sicurezza responsabili della risposta agli incidenti dispongano dell'accesso appropriato alla console Google Cloud e alla Console di amministrazione. Se team separati gestiscono la Google Cloud console e la Console di amministrazione, potresti ricevere una risposta in ritardo durante un incidente.

Per rimuovere l'accesso da un account utente compromesso, il tuo team di risposta agli incidenti deve disporre di un ruolo nella Console di amministrazione, ad esempio Amministratore gestione utenti. Per valutare se si sono verificate attivitร  sospette nelle tue risorse Google Cloud, questo team potrebbe anche aver bisogno di ruoli IAM, ad esempio revisore della sicurezza in tutti i progetti o visualizzatore dei log in un sink di log centralizzato. I ruoli necessari per il tuo team di sicurezza variano in base alla progettazione e al funzionamento del tuo ambiente.

Best practice per la correzione dopo un incidente di sicurezza

Dopo la compromissione di un endpoint, nell'ambito del piano di gestione degli incidenti, determina come rispondere alla minaccia principale di un endpoint compromesso e come mitigare i potenziali danni in corso causati dalla minaccia secondaria di token compromessi. Se un malintenzionato ha accesso persistente alla workstation dello sviluppatore, potrebbe copiare di nuovo i token dopo la riautenticazione dell'utente legittimo. Se sospetti che i token gcloud CLI possano essere compromessi, apri un ticket con Cloud Customer Care e completa i consigli nelle sezioni seguenti. Queste azioni possono contribuire a limitare l'impatto di un evento come questo nella tua Google Cloud organizzazione.

I consigli in questa sezione si sovrappongono alle indicazioni generali sulla gestione delle credenziali Google Cloud compromesse, ma si concentrano in particolare sulla minaccia dei token gcloud CLI che vengono copiati da un endpoint compromesso.

Scadenza dei token attivi per tutti gli account utente con controllo delle sessioni Google Cloud

Se non hai ancora applicato il controllo della sessione, attivalo immediatamente con una frequenza di riautenticazione breve.Google Cloud Questo controllo contribuisce a garantire che tutti i token di aggiornamento scadano al termine della durata che definisci, il che limita la durata durante la quale un malintenzionato puรฒ utilizzare i token compromessi.

Invalidare manualmente i token per gli account utente compromessi

Esamina le indicazioni per la gestione delle credenziali compromesse per tutte le identitร  utente che potrebbero essere state compromesse. In particolare, la rimozione delle credenziali gcloud CLI รจ il metodo piรน efficace per un team di sicurezza per risolvere il problema dei token OAuth compromessi per le identitร  utente. Per invalidare immediatamente i token di aggiornamento e i token di accesso per gcloud CLI e forzare l'utente a eseguire nuovamente l'autenticazione con la password o il token di sicurezza, rimuovi gcloud CLI dall'elenco delle applicazioni connesse di un utente.

Un singolo utente puรฒ anche rimuovere le credenziali di gcloud CLI per il proprio account individuale.

Altri metodi, come la sospensione dell'utente, il ripristino della password dell'utente o il ripristino dei cookie di accesso, non risolvono in modo specifico la minaccia di token OAuth compromessi. Questi metodi sono generalmente utili per la risposta agli incidenti, ma non invalidano i token di accesso che l'autore dell'attacco controlla giร . Ad esempio, se hai scelto di sospendere un utente durante un'indagine, ma non revochi i token gcloud CLI, i token di accesso potrebbero essere ancora validi se l'utente sospeso viene ripristinato prima della scadenza dei token di accesso.

Invalidare i token a livello di programmazione per molti account utente

Se sospetti una violazione, ma non riesci a identificare gli utenti interessati, valuta la possibilitร  di revocare le sessioni attive per tutti gli utenti della tua organizzazione piรน rapidamente di quanto consentito dalla policy di riautenticazione.

Questo approccio puรฒ essere dannoso per gli utenti legittimi e interrompere i processi di lunga durata che dipendono dalle credenziali utente. Se scegli di adottare questo approccio, prepara una soluzione basata su script da eseguire in anticipo nel tuo Security Operations Center (SOC) e testala con alcuni utenti.

Il seguente codice campione utilizza l'SDK Workspace Admin per identificare tutte le identitร  utente nel tuo account Google Workspace o Cloud Identity che hanno accesso alla gcloud CLI. Se un utente ha autorizzato gcloud CLI, lo script revoca il token di aggiornamento e il token di accesso e lo costringe a eseguire nuovamente l'autenticazione con la password o il token di sicurezza. Per istruzioni su come attivare l'API SDK Admin ed eseguire questo codice, consulta la guida rapida di 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)
      }
    }
  }
}

Invalidare e ruotare le credenziali per i service account

A differenza dei token di accesso concessi alle identitร  utente, i token di accesso concessi agli account di servizio non possono essere invalidati tramite la Console di amministrazione o comandi come gcloud auth revoke. Inoltre, la durata della sessione specificata nel controllo sessione si applica agli account utente nella tua directory Cloud Identity o Google Workspace, ma non agli account di servizio.Google Cloud Pertanto, la risposta agli incidenti per gli account di servizio compromessi deve riguardare sia i file delle chiavi persistenti sia i token di accesso di breve durata.

Se sospetti che le credenziali di un account di servizio siano state compromesse, disabilita il service account, elimina le account di servizio account se esistenti e, dopo 60 minuti,riabilita il service account. L'eliminazione di una chiave dell'account di servizio puรฒ invalidare le credenziali di lunga durata in modo che un malintenzionato non possa richiedere un nuovo token di accesso, ma non invalida i token di accesso giร  concessi. Per garantire che i token di accesso non vengano utilizzati in modo improprio durante la loro durata di 60 minuti, devi disattivare il account di servizio per 60 minuti.

In alternativa, puoi eliminare e sostituire il account di servizio per revocare immediatamente tutte le credenziali di breve e lunga durata, ma questa operazione potrebbe richiedere un lavoro piรน dispendioso per sostituire iaccount di serviziont nelle applicazioni.

Passaggi successivi