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

Last reviewed 2024-02-15 UTC

Questo documento descrive come ridurre l'impatto di un attacco che compromette i token OAuth utilizzati dalla CLI gcloud.

Un utente malintenzionato può compromettere questi token OAuth se ottiene l'accesso a un endpoint se un account utente o di servizio legittimo è già stato autenticato con gcloud CLI. L'attaccante può quindi copiare questi token in un altro endpoint che controlla per effettuare richieste che rubano l'identità legittima. Anche dopo aver rimosso l'accesso dell'aggressore all'endpoint compromesso, l'autore dell'attacco può continuerà a effettuare richieste API autenticate utilizzando i token copiati. Per aiutare ridurre questo rischio, puoi controllare l'accesso ai tuoi sistemi utilizzando credenziali di breve durata e sensibili al contesto.

Questo documento è rivolto ai team di sicurezza o ai cloud architect che sono responsabile per proteggere le risorse cloud da accessi illegittimi. Questo documento illustra 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 la compromissione di un endpoint.

Panoramica

Per capire come funziona questa minaccia, occorre conoscere il modo in cui gcloud CLI archivia le credenziali OAuth 2.0 e il modo in cui queste credenziali possono essere utilizzati in modo illecito se compromessi da un aggressore.

Tipi di credenziali memorizzate dall'interfaccia a riga di comando gcloud

L'interfaccia a riga di comando gcloud 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 e altri tipi di credenziali potrebbero essere permanenti.

Quando autorizzi la CLI gcloud con un account utente, la CLI gcloud avvia un flusso di consenso OAuth a tre vie per accedere alle API Google Cloud per conto dell'utente. Dopo che l'utente ha completato flusso di consenso, gcloud CLI riceve un token di accesso e un aggiornamento che gli consenta di richiedere nuovi token di accesso. Con le impostazioni predefinite, il codice di aggiornamento a lungo termine persiste finché non vengono soddisfatte le sue condizioni di scadenza.

Quando autorizzi gcloud CLI con un account di servizio, gcloud CLI avvia un flusso OAuth a due passaggi per accedere alle API Google Cloud come identità dell'account di servizio. Dopo aver attivato un account di servizio da un file della chiave privata, questa chiave viene utilizzata per richiedere periodicamente un token di accesso. La chiave privata a lungo termine viene archiviata nella configurazione della CLI gcloud e rimane valida finché non elimini la chiave dell'account di servizio.

Quando esegui gcloud CLI in un ambiente Google Cloud come Compute Engine o Cloud Shell, l'applicazione può automaticamente trovare le credenziali autenticarsi come account di servizio. Ad esempio, in Compute Engine, un'applicazione come la CLI gcloud può eseguire query sul server di metadati per ottenere un token di accesso. Google gestisce e gira la chiave di firma privata utilizzata per creare il token di accesso e le credenziali a vita lunga non sono esposte all'applicazione.

Quando esegui l'autenticazione con la federazione delle identità per i carichi di lavoro, 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 di lunga durata utilizzate dal provider di identità esterno, consulta best practice per l'utilizzo della federazione delle identità per i carichi di lavoro.

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

Se un malintenzionato riesce a compromettere un endpoint, le credenziali come i token OAuth sono target importanti perché consentono agli aggressori di eseguire la persistenza o la riassegnazione del loro accesso.

Uno sviluppatore potrebbe avere la legittima necessità di visualizzare le proprie credenziali quando la scrittura e il debug del codice. Ad esempio, uno sviluppatore potrebbe dover autenticarsi per utilizzare le richieste REST ai servizi Google Cloud quando utilizza una libreria client non supportata. Lo sviluppatore può visualizzare le credenziali tramite vari metodi, tra cui:

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

Se un utente malintenzionato compromette un endpoint, ad esempio una workstation di uno sviluppatore, minaccia principale è che l'aggressore può eseguire i comandi gcloud CLI altro codice con le credenziali legittime dell'identità autenticata. Nella Inoltre, l'autore dell'attacco potrebbe copiare i token OAuth su un altro endpoint per mantenere l'accesso. Quando si verifica il furto di credenziali, c'è un minaccia secondaria per cui l'autore dell'attacco può ancora usare i token OAuth di lunga durata per permanentemente anche dopo aver rimosso l'accesso all'account endpoint.

Se l'aggressore riesce a compromettere i token OAuth, può completa le seguenti azioni:

  • Un malintenzionato può rubare l'identità dell'account utente o di servizio compromesso. Il traffico API che utilizza i token compromessi viene registrato come se provenisse da l'account utente o di servizio compromesso, rendendo difficile distinguerlo le attività normali e dannose nei log.
  • Un malintenzionato può aggiornare il token di accesso a tempo indeterminato utilizzando un token di aggiornamento permanente associato a un utente o una chiave privata associata a un account di servizio.
  • Un malintenzionato può bypassare 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 la mitigazione dei rischi

Implementa i controlli descritti nelle sezioni seguenti per contribuire a ridurre il rischio di token gcloud CLI compromessi. Se segui il best practice per la sicurezza descritte in progetto base aziendale o progettazione della zona di destinazione in Google Cloud, potresti aver già impostato questi controlli.

Impostare la durata della sessione per i servizi Google Cloud

Per ridurre il tempo di sfruttamento di un token compromesso, impostare la durata della sessione per i servizi Google Cloud. Per impostazione predefinita, il token di aggiornamento concesso dal sistema dopo l'autenticazione lunga durata e una sessione gcloud CLI non richiedono mai la riautenticazione. Modifica questa impostazione per configurare un criterio di riautenticazione con una durata di sessione compreso tra 1 e 24 ore. Al termine della durata della sessione definita, il criterio di autenticazione forzata invalida il token di aggiornamento e forza l'utente ad autenticarsi nuovamente regolarmente con la password o la chiave 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 ricognizione per Google Cloud. Se utilizzi i servizi Google Workspace, imposta la durata della sessione per entrambi.

Configurazione dei Controlli di servizio VPC

Configura Controlli di servizio VPC nel tuo ambiente per garantire che solo il traffico dell'API Google Cloud hanno origine all'interno del perimetro definito possono accedere risorse supportate. Il perimetro di servizio limita l'utilità delle credenziali compromesse perché blocca le richieste ai servizi con limitazioni che provengono da endpoint controllati dall'attaccante esterni al tuo ambiente.

Configurare Chrome Enterprise Premium

Configura i criteri di Chrome Enterprise Premium per contribuire a proteggere la console Google Cloud e le API Google Cloud. Configurare un livello di accesso a Chrome Enterprise Premium e associazioni per consentire selettivamente gli attributi valutati su ogni API tra cui l'accesso basato su IP o l'accesso basato su certificato per TLS reciproco. Le richieste che utilizzano credenziali di autorizzazione compromesse, ma che non soddisfano le condizioni definite nei criteri di Chrome Enterprise Premium, vengono rifiutate.

Chrome Enterprise Premium è un un controllo incentrato sugli utenti che rifiuta il traffico API utente che non soddisfa i requisiti le condizioni di traffico. 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 applicano a tutti gli identity utente e agli identity account di servizio, ma Chrome Enterprise Premium si applica solo agli identity utente all'interno della tua organizzazione. Se utilizzati insieme, Chrome Enterprise Premium e i Controlli di servizio VPC riducono le l’efficacia delle credenziali compromesse su una macchina controllata dagli aggressori che è 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 Compute Engine mediante SSH, configura OS Login con verifica in due passaggi. Viene applicato un checkpoint aggiuntivo in cui l'utente deve eseguire nuovamente l'autenticazione la password o il token di sicurezza. Un utente malintenzionato con token OAuth compromessi, ma non la password o il token di sicurezza sono bloccati da questa funzionalità.

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

Limitare l'utilizzo delle chiavi dell'account di servizio

Quando utilizzi la chiave di un account di servizio per l'autenticazione, il valore della chiave viene memorizzato i file di configurazione della gcloud CLI, separatamente dai file scaricati chiave. Un utente malintenzionato con accesso al tuo ambiente potrebbe copiare la chiave da la configurazione della gcloud CLI o copia il file della chiave di un file system o un repository di codice interno. Pertanto, in aggiunta al tuo piano di mitigazione dei token di accesso compromessi, valuta come gestire il servizio scaricato i file delle chiavi dell'account.

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 del criterio dell'organizzazione iam.disableServiceAccountKeyCreation per disattivare la creazione di chiavi dell'account di servizio.

Consideriamo il principio del privilegio minimo

Quando progetti i criteri IAM, tieni conto del privilegio minimo. Assegna agli utenti i ruoli di cui hanno bisogno per svolgere almeno un'attività l'ambito di attività. Non concedere loro ruoli che non richiedono. Esamina e applica i suggerimenti sui ruoli per evitare criteri IAM con ruoli inutilizzati ed eccessivi nel tuo ambiente.

Proteggi gli endpoint

Valuta in che modo un malintenzionato potrebbe ottenere l'accesso fisico o remoto ai tuoi endpoint, ad esempio le workstation degli sviluppatori o le istanze Compute Engine. Sebbene sia importante avere un piano per affrontare la minaccia dei token OAuth compromessi, valuta anche come rispondere alla minaccia di come un malintenzionato possa compromettere i tuoi endpoint attendibili. Se un malintenzionato ha accesso ai tuoi endpoint attendibili, può eseguire comandi della CLI gcloud o altro codice direttamente sull'endpoint stesso.

Anche se la protezione completa delle workstation degli sviluppatori non rientra nell'ambito di questo documento, valuta in che modo le operazioni e gli strumenti di sicurezza possono aiutarti 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 permanenti, come chiavi SSH o account di servizio, potrebbero le chiavi sono compromesse?
  • Esistono flussi di lavoro che utilizzano credenziali permanenti che potrebbero essere sostituite con credenziali di breve durata?
  • Esistono dispositivi condivisi da cui qualcuno potrebbe leggere la cache di un altro utente Credenziali gcloud CLI?
  • Un utente può autenticarsi con l'interfaccia a riga di comando gcloud da un dispositivo non attendibile?
  • In che modo il traffico approvato si connette alle risorse all'interno del perimetro dei Controlli di servizio VPC?

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

Allinea i team di risposta

Assicurati in anticipo che i team di sicurezza responsabili della risposta agli incidenti abbiano accesso appropriato alla console Google Cloud e alla Console di amministrazione. Se team separati gestiscono la console Google Cloud e la Console di amministrazione, potrebbe avere una risposta ritardata durante un incidente.

Per rimuovere l'accesso da un account utente compromesso, il team di risposta agli incidenti deve disporre di un ruolo della Console di amministrazione, ad esempio Amministratore della gestione utenti. Per valutare se si sono verificate attività sospette in Google Cloud di risorse, questo team potrebbe aver bisogno anche ruoli IAM, come Revisore sicurezza per tutti i progetti o Visualizzatore log in una nel sink di log. I ruoli necessari per il team di sicurezza variano in base al design e al funzionamento dell'ambiente.

Best practice per rimediare dopo un incidente di sicurezza

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

I consigli in questa sezione si sovrappongono alle linee guida generali su gestione di credenziali Google Cloud compromesse, ma concentrati in particolare sulla minaccia dei token gcloud CLI copiati da un endpoint compromesso.

Far scadere i token attivi per tutti gli account utente con il controllo delle sessioni di Google Cloud

Se non hai già applicato Controllo sessione di Google Cloud, attivare immediatamente questa funzionalità con una breve frequenza di riautenticazione. Questo controllo contribuisce a garantire che tutti i token di aggiornamento scadano al termine della durata che hai definito, il che limita la durata per cui un malintenzionato può utilizzare i token compromessi.

Annullare manualmente i token per gli account utente compromessi

Leggi le indicazioni per gestione delle credenziali compromesse per le identità degli utenti 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 l'accesso per l'interfaccia a riga di comando gcloud e costringe l'utente a ripetere l'autenticazione la propria password o token di sicurezza, rimuovi gcloud CLI dall'elenco di un utente delle applicazioni connesse.

Un singolo utente può anche rimuovere le credenziali della CLI gcloud per il proprio account individuale.

Altri metodi, come sospendere l'utente, reimpostare la sua password o la reimpostazione dei cookie di accesso non risolve in modo specifico la minaccia di compromissione Token OAuth. Questi metodi sono generalmente utili per la risposta agli incidenti, invalidare i token di accesso già controllati dall'aggressore. Ad esempio, se scelto di sospendere un utente durante un'indagine, ma non revocare gcloud CLI, i token di accesso potrebbero essere ancora validi se l'utente sospeso viene ripristinato prima della scadenza dei token di accesso.

invalidare in modo programmatico i token per molti account utente

Se sospetti una violazione ma non riesci a identificare quali utenti sono stati interessati, prendi in considerazione la revoca delle sessioni attive per tutti gli utenti nel tuo dell'organizzazione più rapidamente di quanto consentito dal criterio di riautenticazione.

Questo approccio può causare interruzioni per gli utenti legittimi e terminare processi di lunga durata che dipendono dalle credenziali utente. Se scegli di adottare questo approccio, prepara una soluzione basata su script da eseguire in advance nel tuo Security Operations Center (SOC) e testala con pochi utenti.

Il seguente codice di esempio utilizza l'SDK Workspace Admin per identificare tutte le identità utente nel tuo account Google Workspace o Cloud Identity che hanno accesso alla CLI gcloud. Se un utente ha autorizzato gcloud CLI, lo script revoca il token di aggiornamento e il token di accesso e li obbliga a ripetere 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)
      }
    }
  }
}

Annullare l'autenticazione e ruotare le credenziali per gli account di servizio

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 Controllo sessione di Google Cloud si applica agli account utente in Cloud Identity directory di Google Workspace, ma non agli account di servizio. Pertanto, la risposta agli incidenti per gli account di servizio compromessi e i token di accesso di breve durata.

Se sospetti che le credenziali di un account di servizio siano state compromesse, disattiva l'account di servizio, elimina le chiavi dell'account di servizio se esistono e, dopo 60 minuti, riattiva l'account di servizio. L'eliminazione di una chiave dell'account di servizio può invalidare la credenziale di lunga durata, in modo che un utente malintenzionato non può richiedere un nuovo token di accesso, ma questo non invalida di accesso ai token già concessi. Per assicurarti che i token di accesso non vengano utilizzati in modo improprio entro la loro durata di 60 minuti, devi disattivare l'account di servizio per 60 minuti.

In alternativa, puoi eliminare e sostituire l'account di servizio con revocare tutte le credenziali di breve e lunga durata, ma questa operazione potrebbe richiedere attività invasive per sostituire l'account di servizio nelle applicazioni.

Passaggi successivi