Best practice per la mitigazione dei 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 compromette 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 simulano l'identità legittima. Anche dopo aver rimosso l'accesso dell'utente malintenzionato all'endpoint compromesso, l'aggressore 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 è rivolto ai team di sicurezza o ai cloud architect responsabili di proteggere le loro risorse cloud da accessi illegittimi. Questo documento presenta i controlli disponibili che puoi utilizzare per ridurre in modo proattivo l'impatto dei token OAuth gcloud CLI compromessi e correggere l'ambiente dopo la compromissione di un endpoint.

Panoramica

Per capire come funziona questa minaccia, è necessario comprendere in che modo l'interfaccia a riga della gcloud CLI archivia le credenziali OAuth 2.0 e come 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 per le API Google Cloud. Il flusso OAuth varia a seconda dei 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 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 le consente di richiedere nuovi token di accesso. Con le impostazioni predefinite, il token di aggiornamento di lunga durata persiste fino a soddisfare le relative condizioni di scadenza.

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, questa chiave viene utilizzata per richiedere periodicamente un token di accesso. La chiave privata di lunga durata viene archiviata nella configurazione dellgcloud CLI e rimane valida finché non elimini la chiave dell'account di servizio.

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 account di servizio. Ad esempio, in Compute Engine, un'applicazione come gcloud CLI può eseguire una query sul server dei 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 sono esposte all'applicazione.

Quando esegui l'autenticazione con la federazione delle identità per i carichi di lavoro, le applicazioni vengono autenticate 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 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 bersagli preziosi perché consentono agli utenti malintenzionati di persistere o di aumentare il loro accesso.

Uno sviluppatore potrebbe avere la legittima necessità 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 in 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 uno sviluppatore, la minaccia principale è che possa eseguire i comandi dell'interfaccia a riga di comando 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 in modo da mantenere l'accesso. Quando si verifica questo furto di credenziali, esiste una minaccia secondaria secondo cui l'utente malintenzionato può comunque utilizzare i token OAuth di lunga durata per avere accesso permanente 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ò 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 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 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 ridurre il rischio di token gcloud CLI compromessi. Se stai seguendo le best practice per la sicurezza descritte nel progetto di base aziendale o nella progettazione delle zone di destinazione in Google Cloud, potresti aver già implementato questi controlli.

Impostare la durata della sessione per i servizi Google Cloud

Per ridurre il tempo in cui un utente malintenzionato può sfruttare un token compromesso, imposta la durata della sessione per i servizi Google Cloud. Per impostazione predefinita, il token di aggiornamento che il sistema concede dopo l'autenticazione è una credenziali 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. Dopo la durata della sessione definita, il criterio di riautenticazione invalida il token di aggiornamento e obbliga l'utente ad autenticare di nuovo regolarmente gcloud CLI con la propria password o il token di sicurezza.

La durata della sessione per i servizi Google Cloud è un'impostazione diversa dalla durata della sessione per i servizi Google, che controlla le sessioni web per l'accesso a tutti i servizi Google Workspace, ma non controlla la riautenticazione per Google Cloud. Se utilizzi i servizi di 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 garantire 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 poiché il perimetro blocca le richieste ai servizi limitati provenienti da endpoint controllati dagli aggressori al di fuori del tuo ambiente.

Configura Chrome Enterprise Premium

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

Chrome Enterprise Premium è un controllo incentrato sugli utenti che rifiuta il traffico delle API utente che non soddisfa condizioni definite. Controlli di servizio VPC sono un controllo incentrato sulle risorse che definisce i perimetri entro i quali le risorse possono comunicare. Controlli di servizio VPC si applica a tutte le identità utente e a quelle degli account di servizio, mentre Chrome Enterprise Premium si applica solo alle identità utente all'interno della tua organizzazione. Se utilizzati insieme, Chrome Enterprise Premium e Controlli di servizio VPC riducono l'efficacia delle credenziali compromesse su una macchina controllata da utenti malintenzionati 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 mediante SSH, configura OS Login con la verifica in due passaggi. In questo modo viene applicato un checkpoint aggiuntivo in cui l'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 Remote Desktop Protocol (RDP) 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. Se utilizzi i 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 la chiave di un 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 tuo file system locale o da un repository di codice interno. Pertanto, oltre a pianificare la mitigazione dei token di accesso compromessi, valuta la possibilità di 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 e applicare il vincolo del criterio dell'organizzazione iam.disableServiceAccountKeyCreation per disabilitare la creazione delle chiavi degli account di servizio.

Consideriamo il principio del privilegio minimo

Durante la progettazione di criteri IAM, considera il privilegio minimo. Concedi agli utenti i ruoli di cui hanno bisogno per svolgere un'attività con l'ambito più ristretto. 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

Pensa a come un utente malintenzionato potrebbe ottenere accesso fisico o remoto ai tuoi endpoint, come le workstation di sviluppatori o le istanze di Compute Engine. Sebbene un piano per affrontare la minaccia dei token OAuth compromessi sia importante, considera anche come rispondere alla minaccia del modo in cui un utente malintenzionato può compromettere gli endpoint attendibili in primo luogo. 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 esula dall'ambito di questo documento, valuta in che modo gli strumenti e le operazioni di sicurezza possono contribuire a proteggere e monitorare gli 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?
  • Come potrebbero essere compromesse altre credenziali persistenti come le chiavi SSH o le chiavi degli account di servizio?
  • Esistono flussi di lavoro che usano credenziali permanenti che possono essere sostituite con
  • Esistono dispositivi condivisi in cui qualcuno può leggere le credenziali di gcloud CLI 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 tuo perimetro Service Controlo VPC?

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

Allinea i team di risposta

Garantire in anticipo che i team di sicurezza responsabili della risposta agli incidenti abbiano adeguato accesso 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 subire dei ritardi 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 risorse Google Cloud, questo team potrebbe aver 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 tuo team di sicurezza variano in base alla progettazione e al funzionamento dell'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 mitigare i potenziali danni continuativi della minaccia secondaria dei token compromessi. Se un utente malintenzionato ha accesso permanente alla workstation dello sviluppatore, 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 stati compromessi, apri un ticket con l'assistenza clienti Google Cloud e completa i suggerimenti nelle sezioni seguenti. Queste azioni possono aiutare a limitare l'impatto di un evento come questo nella tua organizzazione Google Cloud.

I suggerimenti in questa sezione si sovrappongono alle linee guida 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.

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

Se non hai già applicato il controllo sessione di Google Cloud, abilitalo immediatamente con una breve frequenza di riautenticazione. Questo controllo garantisce che tutti i token di aggiornamento scadano al termine del periodo di tempo definito, il che limita la durata in cui un utente malintenzionato può utilizzare i token compromessi.

Disabilita manualmente i token per gli account utente compromessi

Consulta le indicazioni per la gestione delle credenziali compromesse per le identità degli utenti che potrebbero essere state compromesse. In particolare, la rimozione gcloud CLI gcloud è il metodo più efficace per un team di sicurezza per risolvere 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 riautenticarsi 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 individuale.

Altri metodi, come la sospensione dell'utente, la reimpostazione della password o la reimpostazione dei cookie di accesso, non affrontano 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 revocare i token di gcloud CLI, i token di accesso potrebbero essere comunque 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 gli utenti interessati, valuta la possibilità di revocare le sessioni attive per tutti gli utenti dell'organizzazione più rapidamente di quanto consentito dal criterio di riautenticazione.

Questo approccio può compromettere gli utenti legittimi e terminare i processi a lunga esecuzione che dipendono dalle credenziali utente. Se scegli di adottare questo approccio, prepara una soluzione basata su script che il tuo centro operativo di sicurezza (SOC) possa eseguire in anticipo e testala con alcuni utenti.

Il codice campione seguente 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 l'interfaccia alla gcloud CLI, lo script revoca il token di aggiornamento e il token di accesso e li obbliga a eseguire nuovamente l'autenticazione con la password o il token di sicurezza. Per istruzioni su come abilitare l'API Admin SDK 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)
      }
    }
  }
}

invalida e ruota 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 nel controllo sessione di 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 gestire sia i file di chiavi permanenti sia 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 ne esistono e, dopo 60 minuti, attiva 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 possa richiedere un nuovo token di accesso, ma non i token di accesso già concessi. Per assicurarti che non vengano utilizzati in modo illecito i token di accesso entro la loro durata di 60 minuti, 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 interventi più invasivi per sostituire l'account di servizio nelle applicazioni.

Passaggi successivi