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 malintenzionato può compromettere questi token OAuth se ottiene l'accesso a un endpoint in cui un account utente o un account di servizio legittimo si è già autenticato con la gcloud CLI. L'attaccante può quindi copiare questi token in un altro endpoint controllato per effettuare richieste che rubano l'identità legittima. Anche dopo aver rimosso l'accesso dell'autore dell'attacco all'endpoint compromesso, l'autore dell'attacco può continuare a inviare 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 è rivolto ai team di sicurezza o ai cloud architect che sono responsabili della protezione delle 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 comprendere il funzionamento di questa minaccia, devi capire come la gcloud CLI memorizza le credenziali OAuth 2.0 e come queste credenziali possono essere usate in modo improprio se compromesse da un malintenzionato.

Tipi di credenziali memorizzate dallgcloud CLI

gcloud CLI utilizza token di accesso OAuth 2.0 per autenticare le richieste per le 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 permanenti.

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. Una volta completato il flusso di consenso, gcloud CLI riceve un token di accesso e un token di aggiornamento che le consente 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 APIGoogle 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 gcloud CLI e rimane valida fino a quando non elimini la chiave dell'account di servizio.

Quando esegui gCloud CLI in un Google Cloud ambiente, come Compute Engine o Cloud Shell, l'applicazione può automaticamente trovare le credenziali e autenticarsi come account di servizio. Ad esempio, in Compute Engine, un'applicazione come la gcloud CLI 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à di 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 permanenti utilizzate dal provider di identità esterno, consulta le best practice per l'utilizzo della federazione delle identità dei carichi di lavoro.

In che modo un malintenzionato può utilizzare 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 un bisogno legittimo 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 utilizza una libreria client non supportata. Lo sviluppatore può visualizzare le credenziali tramite vari metodi, tra cui:

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

Se un malintenzionato compromette un endpoint, ad esempio una workstation per sviluppatori, la minaccia principale è che l'utente malintenzionato possa eseguire comandi gcloud CLI o altro codice con le credenziali legittime dell'identità autenticata. Inoltre, l'aggressore potrebbe copiare i token OAuth in un altro endpoint sotto il suo controllo 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 permanente anche dopo aver rimosso l'accesso all'endpoint compromesso.

Se l'aggressore riesce a compromettere i token OAuth, può eseguire 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 dall'account utente o di servizio compromesso, rendendo difficile distinguere le attività normali da quelle 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 le best practice per la sicurezza descritte nel blueprint Enterprise Foundations o nel design della zona di destinazione in Google Cloud, potresti già avere implementato questi controlli.

Impostare la durata della sessione per i Google Cloud servizi

Per ridurre il tempo durante il quale un malintenzionato può sfruttare un token compromesso, imposta la durata della sessione per i Google Cloud servizi. Per impostazione predefinita, il token di aggiornamento concesso dal sistema dopo l'autenticazione è una credenziale di lunga durata e una sessione gcloud CLI non richiede mai la riautenticazione. Modifica questa impostazione per configurare un criterio di riautenticazione con una durata della sessione compresa 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 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 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 nell'ambiente per assicurarti che solo il Google Cloud traffico API che origina 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 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 e le Google Cloud API di Google Cloud. Configura un livello di accesso e un'associazione di Chrome Enterprise Premium per consentire in modo selettivo gli attributi valutati in ogni richiesta dell'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 controllo incentrato sugli utenti che rifiuta il traffico delle 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 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 usati insieme, Chrome Enterprise Premium e i Controlli di servizio VPC riducono l'efficacia delle credenziali compromesse su un computer controllato dall'attaccante 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 Compute Engine utilizzando SSH, configura OS Login con la verifica in due passaggi. Viene applicato un punto di controllo aggiuntivo in cui un utente deve eseguire nuovamente l'autenticazione con la password o il token di sicurezza. Un malintenzionato con token OAuth compromessi, ma senza password o token di sicurezza, viene bloccato da questa funzionalità.

L'accesso tramite Remote Desktop Protocol (RDP) 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 per le 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 dell'account di servizio

Quando utilizzi una chiave dell'account di servizio per l'autenticazione, il valore della chiave viene memorizzato 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 gcloud CLI o dal file della chiave dal file system locale o dal repository di codice interno. Pertanto, oltre a pianificare la mitigazione dei token di accesso compromessi, valuta come gestisci i file delle chiavi dell'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 del criterio dell'organizzazione iam.disableServiceAccountKeyCreation per disattivare la creazione di chiavi dell'account di servizio.

Considera il principio del privilegio minimo

Quando progetti i criteri IAM, tieni conto del privilegio minimo. Concedi agli utenti i ruoli di cui hanno bisogno per svolgere un'attività con l'ambito più ridotto possibile. Non concedere ruoli non richiesti. Esamina e applica i suggerimenti sui ruoli per evitare policy IAM con ruoli inutilizzati ed eccessivi nel tuo ambiente.

Proteggi i tuoi 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 gcloud CLI 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 faccio a identificare e rispondere alle violazioni della rete?
  • In che modo gli utenti ottengono l'accesso remoto alle sessioni SSH o RDP?
  • In che modo altre credenziali permanenti, come le chiavi SSH o le chiavi degli account di servizio, potrebbero essere compromesse?
  • Esistono flussi di lavoro che utilizzano credenziali permanenti che potrebbero essere sostituite con credenziali di breve durata?
  • Esistono dispositivi condivisi su cui qualcuno potrebbe leggere le credenziali gcloud CLI memorizzate nella cache 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 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, la risposta potrebbe essere 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 sono state registrate attività sospette nelle tue Google Cloud risorse, questo team potrebbe anche aver bisogno di ruoli IAM, come Security Reviewer in tutti i progetti o Visualizzatore log in un'area di destinazione log centralizzata. I ruoli necessari per il team di sicurezza variano in base al design e al funzionamento dell'ambiente.

Best practice per la correzione 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 continui 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 gcloud CLI possano essere compromessi, apri un ticket con l'assistenza clienti Google Cloud e segui i consigli riportati 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 specificamente sulla minaccia dei token gcloud CLI copiati da un endpoint compromesso.

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

Se non l'hai ancora fatto, attiva il Google Cloud controllo della sessione con una frequenza di autenticazione ridotta. 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

Consulta le indicazioni per la gestione delle credenziali compromesse per le eventuali 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 di accesso per gcloud CLI e forzare l'utente a eseguire nuovamente l'autenticazione con la password o la chiave di sicurezza, rimuovi gcloud CLI dall'elenco di applicazioni collegate di un utente.

Un singolo utente può anche rimuovere la gcloud CLI gcloud per il proprio account individuale.

Altri metodi, come la sospensione dell'utente, la reimpostazione della password 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'attaccante. 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 loro scadenza.

Annullare 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 dal criterio di autenticazione.

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 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 la gcloud CLI, lo script revoca il token di aggiornamento e il token di accesso e lo forza 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)
      }
    }
  }
}

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 in Google Cloud Controllo 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 permanenti sia i token di accesso a vita breve.

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 a lungo termine in modo che un 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 improprio entro la loro durata di 60 minuti, devi disattivare l'account di servizio per 60 minuti.

In alternativa, puoi eliminare e sostituire il service account per revocare immediatamente tutte le credenziali di breve e lunga durata, ma questa operazione potrebbe richiedere un intervento più complesso per sostituire il service account nelle applicazioni.

Passaggi successivi