Best practice per mitigare i token OAuth compromessi per Google Cloud CLI

Last reviewed 2024-02-15 UTC

Questo documento descrive come mitigare l'impatto di un utente malintenzionato che comprometta i token 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 rubano l'identità legittima. Anche dopo che avrai rimosso l'accesso dell'utente malintenzionato all'endpoint compromesso, quest'ultimo può continuare a effettuare richieste API autenticate utilizzando i token copiati. Per 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 che sono responsabili della protezione delle proprie 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 rimediare al tuo ambiente dopo la compromissione di un endpoint.

Panoramica

Per capire come funziona questa minaccia, devi comprendere in che modo gcloud CLI archivia le credenziali OAuth 2.0 e come queste 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 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 permanenti.

Quando autorizzi gcloud CLI con un account utente, l'interfaccia a riga di comando 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 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. Secondo le impostazioni predefinite, il token di aggiornamento di lunga durata persiste fino a quando le condizioni di scadenza sono soddisfatte.

Quando autorizzi gcloud CLI con un account di servizio, gcloud CLI avvia un flusso OAuth a due vie per accedere alle API Google Cloud come identità dell'account di servizio. Dopo aver attivato un account di servizio da un file di chiave privata, la chiave viene utilizzata per richiedere periodicamente un token di accesso. La chiave privata di lunga durata è archiviata nella configurazione dellgcloud CLI 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ò trovare automaticamente le credenziali e autenticarsi come account di servizio. Ad esempio, in Compute Engine, un'applicazione come gcloud CLI può eseguire una query sul server dei metadati per cercare 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 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 a 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 carichi di lavoro.

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 persistere o aumentare il loro accesso.

Uno sviluppatore potrebbe avere l'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 l'utilizzo delle richieste REST ai servizi Google Cloud 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 viola un endpoint, ad esempio una workstation per sviluppatori, la minaccia principale è che 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 per cui l'utente malintenzionato può comunque utilizzare i token OAuth di lunga durata per avere accesso permanente anche dopo che hai 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ò rubare l'identità dell'account utente o di servizio compromesso. Il traffico delle API che utilizza i token compromessi viene registrato come se provenisse dall'account utente o di servizio compromesso, rendendo difficile distinguere le attività normali e dannose nei log.
  • Un utente 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 utente 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 ridurre il rischio di compromessi dei token gcloud CLI. Se stai seguendo le best practice di sicurezza descritte nel progetto delle basi aziendali o nella progettazione delle zone di destinazione in Google Cloud, potresti già aver implementato questi controlli.

Impostare la durata della sessione per i servizi Google Cloud

Per ridurre il periodo di tempo in cui un utente malintenzionato può sfruttare un token compromesso, imposta la durata delle sessioni per i servizi Google Cloud. 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 una nuova autenticazione. Modifica questa impostazione per configurare un criterio di riautenticazione con una durata della sessione compresa tra 1 e 24 ore. Dopo la durata della sessione definita, il criterio di riautenticazione invalida il token di aggiornamento e obbliga l'utente a riautenticare regolarmente l'interfaccia alla gcloud CLI con la propria password o il token di sicurezza.

La durata delle sessioni per i servizi Google Cloud è un'impostazione diversa dalla durata delle sessioni 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 dell'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, in quanto blocca le richieste ai servizi limitati che provengono da endpoint controllati dall'aggressore al di fuori del tuo ambiente.

Configura BeyondCorp Enterprise

Configura i criteri di BeyondCorp Enterprise per contribuire a proteggere la console Google Cloud e le API Google Cloud. Configura un livello di accesso e l'associazione di BeyondCorp Enterprise per consentire selettivamente gli attributi valutati in 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 nel criterio BeyondCorp Enterprise, vengono rifiutate.

BeyondCorp Enterprise è un controllo incentrato sull'utente che rifiuta il traffico delle API dell'utente che non soddisfa le condizioni definite. Controlli di servizio VPC è 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 a tutte le identità degli account di servizio, mentre BeyondCorp Enterprise si applica solo alle identità utente all'interno dell'organizzazione. Se utilizzati insieme, BeyondCorp Enterprise e i Controlli di servizio VPC riducono l'efficacia delle credenziali compromesse su una macchina controllata da utenti malintenzionati esterna al tuo ambiente.

Forza l'applicazione della verifica in due passaggi per l'accesso al server remoto

Se consenti agli sviluppatori di accedere alle risorse Compute Engine tramite SSH, configura OS Login con la verifica in due passaggi. Questa operazione impone l'applicazione di un ulteriore checkpoint in cui un utente deve eseguire nuovamente l'autenticazione con la propria password o il proprio token di sicurezza. Un utente malintenzionato con token OAuth compromessi, ma senza password o token di sicurezza, è bloccato da questa funzionalità.

L'accesso Remote Desktop Protocol (RDP) alle istanze di 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 plug-in RDP basati su IAP Desktop o Google Chrome, imposta controlli granulari come la durata della sessione per i servizi Google e le impostazioni della 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.

Limita 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 dell&#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 copiare il file della chiave dal tuo file system locale o dal repository di codice interno. Pertanto, oltre al tuo piano per mitigare i token di accesso compromessi, valuta come gestire i file delle chiavi degli account di servizio scaricati.

Esamina le alternative più sicure per l'autenticazione per ridurre o eliminare i casi d'uso che dipendono da una chiave dell'account di servizio, quindi applica il vincolo del criterio dell'organizzazione iam.disableServiceAccountKeyCreation per disabilitare la creazione delle chiavi dell'account di servizio.

Considera il principio del privilegio minimo

Quando progetti i criteri IAM, prendi in considerazione il privilegio minimo. Concedi agli utenti i ruoli necessari per svolgere un'attività nell'ambito più ristretto. Non concedere loro ruoli non richiesti. 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 utente malintenzionato potrebbe ottenere accesso fisico o remoto ai tuoi endpoint, come workstation di sviluppatori o istanze di Compute Engine. Nonostante sia importante un piano per affrontare la minaccia di compromissione dei token OAuth, valuta anche come rispondere alla minaccia di come un utente malintenzionato potrebbe compromettere i tuoi endpoint attendibili. Se un utente malintenzionato ha accesso ai tuoi endpoint attendibili, può eseguire i comandi dell'interfaccia a riga della gcloud CLI o altro codice direttamente sull'endpoint stesso.

Sebbene la protezione completa per le workstation degli sviluppatori non rientri nell'ambito di questo documento, valuta in che modo gli strumenti e le operazioni di sicurezza possono aiutare a proteggere e monitorare i tuoi endpoint per evitare possibili compromissioni. Poniti queste domande:

  • Come viene protetta la sicurezza fisica delle workstation per gli sviluppatori?
  • Come identificare e rispondere alle violazioni della rete?
  • In che modo gli utenti ottengono l'accesso remoto alle sessioni SSH o RDP?
  • Come potrebbero essere compromesse altre credenziali permanenti come le chiavi SSH o le chiavi degli account di servizio?
  • Esistono flussi di lavoro che usano credenziali permanenti sostituite con credenziali a 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.

Allinea 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 la console Google Cloud e la Console di amministrazione gestiscono la console Google Cloud e la console di amministrazione separate, potresti riscontrare ritardi nella risposta durante un incidente.

Per rimuovere l'accesso da un account utente compromesso, il team di risposta agli incidenti deve avere 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 avere bisogno anche di ruoli IAM, ad esempio Revisore sicurezza in tutti i progetti o Visualizzatore log in un sink di log centralizzato. I ruoli necessari per il team di sicurezza variano in base alla progettazione e al funzionamento dell'ambiente.

Best practice per rimediare dopo un incidente di sicurezza

Dopo che un endpoint è stato compromesso, 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 utente malintenzionato ha accesso permanente alla workstation per gli sviluppatori, potrebbe copiare di nuovo i token dopo la nuova autenticazione dell'utente legittimo. Se sospetti che i token gcloud CLI possano essere compromessi, apri un ticket con l'assistenza clienti Google Cloud e completa i suggerimenti nelle sezioni seguenti. Queste azioni possono contribuire a limitare l'impatto di un evento come questo nella tua organizzazione Google Cloud.

I suggerimenti 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.

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

Se non hai già applicato il controllo della sessione di Google Cloud, abilitalo immediatamente con una breve frequenza di riautenticazione. Questo controllo aiuta a garantire che tutti i token di aggiornamento scadano al termine della durata definita, limitando la durata dell'utilizzo dei token compromessi da parte di un utente malintenzionato.

Annullare manualmente la validità dei token per gli account utente compromessi

Leggi le indicazioni per gestire le credenziali compromesse per le identità degli utenti che potrebbero essere state compromesse. In particolare, la rimozione delle credenziali di gcloud CLI è il metodo più efficace per un team di sicurezza per gestire i token OAuth compromessi per le identità degli utenti. Per invalidare immediatamente i token di aggiornamento e i token di accesso per gcloud CLI e forzare l'utente a ripetere l'autenticazione con la password o il token di sicurezza, rimuovi gcloud CLI dall'elenco di 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, la reimpostazione della password dell'utente o la reimpostazione dei cookie di accesso, non rispondono in modo specifico alla 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 dell'interfaccia alla gcloud CLI, i token di accesso potrebbero essere comunque validi se l'utente sospeso viene ripristinato prima della scadenza dei token di accesso.

Annulla in modo programmatico 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 riautenticazione.

Questo approccio può interferire con gli utenti legittimi e causare l'interruzione dei processi di lunga durata che dipendono dalle credenziali utente. Se scegli di adottare questo approccio, prepara una soluzione basata su script per l'esecuzione anticipata del tuo centro operativo di sicurezza (SOC) e testala con pochi utenti.

Il codice campione seguente utilizza l'SDK Admin di Workspace per identificare tutte le identità degli utenti nel tuo account Google Workspace o Cloud Identity che hanno accesso a gcloud CLI. Se un utente ha autorizzato l'interfaccia alla gcloud CLI, lo script revoca il token di aggiornamento e il token di accesso e lo obbliga a eseguire nuovamente l'autenticazione con la propria 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 e ruotare le credenziali per gli account di servizio

A differenza dei token di accesso concessi alle identità degli utenti, quelli 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 Controllo sessione Google Cloud si applica agli account utente nella directory Cloud Identity o Google Workspace, ma non agli account di servizio. Di conseguenza, la risposta agli incidenti per gli account di servizio compromessi deve riguardare sia i file delle chiavi permanenti sia i token di accesso a breve durata.

Se sospetti che le credenziali di un account di servizio siano state compromesse, disabilita l'account di servizio, elimina le chiavi degli account di servizio, se presenti, e poi, dopo 60 minuti, abilita l'account di servizio. L'eliminazione di una chiave dell'account di servizio può invalidare le credenziali 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 non vengano utilizzati in modo illecito i token di accesso entro 60 minuti di durata, devi disabilitare l'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ù fastidioso per la sostituzione dell'account di servizio nelle applicazioni.

Passaggi successivi