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 di un attacco che compromette i token di connessione OAuth utilizzati da gcloud CLI.

Un utente malintenzionato può compromettere questi token OAuth se ottiene l'accesso a un endpoint in cui un account utente o un account di servizio legittimo è già stato autenticato con gcloud CLI. L'utente malintenzionato 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'utente malintenzionato all'endpoint compromesso, l'utente malintenzionato può continuare a effettuare richieste API autenticate utilizzando i token copiati. Per ridurre 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 agli architetti cloud 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 l'ambiente dopo che un endpoint è stato compromesso.

Panoramica

Per comprendere il funzionamento di questa minaccia, devi capire in che modo gcloud CLI archivia le credenziali OAuth 2.0 e in che modo queste credenziali possono essere utilizzate in modo illecito se compromesse da un utente malintenzionato.

Tipi di credenziali archiviate da gcloud CLI

gcloud CLI utilizza i token di accesso OAuth 2.0 per autenticare le richieste alle Google Cloud API. 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 Google Cloud API per conto dell'utente. Dopo che l'utente ha completato 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 a quando non vengono soddisfatte le condizioni di scadenza.

Quando autorizzi gcloud CLI con un account di servizio, gcloud CLI avvia un flusso OAuth a due passaggi per accedere alle Google Cloud API come identità dell'account di servizio. Dopo aver attivato un account di servizio da un file di chiavi private, 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 chiave dell'account di servizio.

Quando esegui gcloud CLI all'interno di un Google Cloud ambiente, come Compute Engine o Cloud Shell, l'applicazione può trovare automaticamente le credenziali ed eseguire l'autenticazione come account di servizio. Ad esempio, in Compute Engine, un'applicazione come gcloud CLI può eseguire una query sul server di metadati per 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à per i workload, le applicazioni eseguono l'autenticazione in base a una credenziale di un provider di identità esterno e ricevono un token di accesso federato di breve durata. Per saperne di più su come archiviare e gestire le credenziali di lunga durata utilizzate dal provider di identità esterno, consulta le best practice per l'utilizzo della federazione delle identità per i workload.

In che modo un utente malintenzionato può utilizzare i token OAuth compromessi

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

Uno sviluppatore potrebbe avere un'esigenza legittima di visualizzare le proprie credenziali durante la scrittura e il debug del codice. Ad esempio, uno sviluppatore potrebbe dover eseguire l'autenticazione per utilizzare le richieste REST ai Google Cloud servizi quando lavora con una libreria client non supportata. Lo sviluppatore può visualizzare le credenziali tramite vari metodi, tra cui:

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

Se un utente malintenzionato compromette un endpoint, ad esempio una workstation di sviluppo, la minaccia principale è che l'utente malintenzionato possa eseguire comandi gcloud CLI o altro codice con le credenziali legittime dell'identità autenticata. Inoltre, l'utente malintenzionato 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'utente malintenzionato può comunque utilizzare i token OAuth di lunga durata per avere un accesso persistente anche dopo aver rimosso l'accesso all'endpoint compromesso.

Se l'utente malintenzionato riesce a compromettere i token OAuth, può completare le seguenti azioni:

  • Un utente malintenzionato può impersonare l'utente o l'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, il che rende difficile distinguere l'attività normale e quella dannosa nei log.
  • Un utente malintenzionato può aggiornare il token di accesso a tempo indeterminato utilizzando un token di aggiornamento persistente associato a un utente o una chiave privata associata a un account di servizio.
  • Un utente malintenzionato può ignorare l'autenticazione con la password o la verifica in due passaggi dell'utente perché i token vengono concessi dopo il flusso di accesso.

Best practice per ridurre i rischi

Implementa i controlli descritti nelle sezioni seguenti per ridurre il rischio di token gcloud CLI compromessi. Se segui le best practice di sicurezza descritte nel progetto di base aziendale o nella progettazione della landing zone Google Cloud, potresti già aver implementato questi controlli.

Impostare la durata della sessione per i Google Cloud servizi

Per ridurre il tempo in cui un utente malintenzionato può sfruttare un token compromesso, imposta la durata della sessione per i Google Cloud servizi. 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. Esamina questa impostazione per assicurarti di avere una policy di riautenticazione con una durata della sessione compresa tra 1 e 24 ore. La policy 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 Google Cloud servizi è 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 i 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 che Google Cloud 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 limitati provenienti da endpoint controllati da utenti malintenzionati che si trovano al di fuori del tuo ambiente.

Configurazione di Chrome Enterprise Premium

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

Chrome Enterprise Premium è un controllo incentrato sull'utente che rifiuta il traffico API dell'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. I Controlli di servizio VPC si applicano a tutte le identità utente e alle identità degli 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 utente malintenzionato che si trova al di fuori del tuo ambiente.

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

Se consenti agli sviluppatori di accedere alle risorse di 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 password o il token di sicurezza. Un utente malintenzionato con token OAuth compromessi ma senza password o token di sicurezza viene bloccato da questa funzionalità.

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

Limitare l'utilizzo delle chiavi degli account di servizio

Quando utilizzi una chiave dell'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 utente 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 ridurre i token di accesso compromessi, valuta la modalità di gestione dei file delle chiavi degli account di servizio scaricati.

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

Considerare il principio del privilegio minimo

Quando progetti le policy IAM, considera il privilegio minimo. Concedi agli utenti i ruoli di cui hanno bisogno per svolgere un'attività con l'ambito più piccolo. Non concedere loro ruoli di cui non hanno bisogno. 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 utente malintenzionato potrebbe ottenere l'accesso fisico o remoto agli endpoint, ad esempio le workstation di sviluppo o le istanze di Compute Engine. Sebbene sia importante un piano per affrontare la minaccia dei token OAuth compromessi, valuta anche come rispondere alla minaccia di come un utente malintenzionato può compromettere i tuoi endpoint attendibili. Se un utente malintenzionato ha accesso ai tuoi endpoint attendibili, può eseguire comandi gcloud CLI o altro codice direttamente sull'endpoint stesso.

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

  • In che modo viene protetta la sicurezza fisica delle workstation di sviluppo?
  • Come identifichi e rispondi alle violazioni della 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 degli account di servizio potrebbero 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 gcloud CLI memorizzate nella cache di un altro utente?
  • Un utente può eseguire l'autenticazione 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 abbiano l'accesso appropriato alla Google Cloud console e alla Console di amministrazione. Se team separati gestiscono la Google Cloud console e la Console di amministrazione, potresti avere una risposta ritardata durante un incidente.

Per rimuovere l'accesso da un account utente compromesso, il team di risposta agli incidenti ha bisogno di un ruolo della Console di amministrazione, ad esempio Amministratore della gestione utenti. Per valutare se si è verificata un'attività sospetta nelle tue Google Cloud risorse, questo team potrebbe aver bisogno anche di ruoli IAM, ad esempio Revisore della sicurezza in tutti i progetti o Visualizzatore 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 che un endpoint è stato compromesso, nell'ambito del piano di gestione degli incidenti, determina come rispondere alla minaccia principale di un endpoint compromesso e come ridurre i potenziali danni continui derivanti dalla minaccia secondaria dei token compromessi. Se un utente malintenzionato ha un accesso persistente alla workstation di sviluppo, potrebbe copiare di nuovo i token dopo che l'utente legittimo ha eseguito nuovamente l'autenticazione. Se sospetti che i token gcloud CLI possano essere compromessi, apri un ticket con l'assistenza clienti Google Cloud e completa i consigli nelle sezioni seguenti. Queste azioni possono contribuire a limitare l'impatto di un evento di questo tipo 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 copiati da un endpoint compromesso.

Far scadere i token attivi per tutti gli account utente con Google Cloud il controllo della sessione

Se non hai ancora applicato Google Cloud il controllo della sessione, attivalo immediatamente con una breve frequenza di riautenticazione. Questo controllo consente di garantire che tutti i token di aggiornamento scadano al termine della durata definita, il che limita la durata durante la quale un utente 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 gestire i 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 gcloud CLI per il proprio account.

Altri metodi, come la sospensione dell'utente, la reimpostazione della password dell'utente o la reimpostazione dei cookie di accesso, non risolvono in modo specifico la minaccia dei token OAuth compromessi. Questi metodi sono generalmente utili per la risposta agli incidenti, ma non invalidano i token di accesso già controllati dall'utente malintenzionato. 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 programmaticamente i token 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ò interrompere gli utenti legittimi e terminare i processi di lunga durata che dipendono dalle credenziali utente. Se scegli di adottare questo approccio, prepara in anticipo una soluzione con script da eseguire per il tuo Security Operations Center (SOC) e testala con alcuni utenti.

Il seguente codice campione utilizza l'SDK Admin di Workspace per identificare tutte le identità utente nel tuo account Google Workspace o Cloud Identity che hanno accesso a 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 gli account di servizio

A differenza dei token di accesso concessi alle identità utente, i token di accesso che vengono 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 Google Cloud controllo della sessione si applica agli account utente nella directory Cloud Identity o Google Workspace, ma non agli account di servizio. 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, disattiva il service account, elimina le account di servizio account se esistenti, e poi, dopo 60 minuti, attiva il service account. L'eliminazione di una chiave dell'account di servizio può invalidare la credenziale di lunga durata in modo che un utente malintenzionato non possa richiedere un nuovo token di accesso, ma non invalida i token di accesso già concessi. Per assicurarti che i token di accesso non vengano utilizzati in modo illecito entro la loro durata di 60 minuti, devi disattivare il account di servizio per 60 minuti.

In alternativa, puoi eliminare e sostituire l'account di servizio per revocare immediatamente tutte le credenziali di breve e lunga durata, ma questa operazione potrebbe richiedere un lavoro più interruttivo per sostituire l'account di servizio nelle applicazioni.

Passaggi successivi