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 una compromissione da parte di un aggressore i token OAuth utilizzati da gcloud CLI.

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’hacker può quindi copiare questi token su 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 introduce i controlli disponibili che puoi utilizzare per ridurre in modo proattivo dell'impatto dei token OAuth gcloud CLI compromessi e dopo che un endpoint è stato compromesso.

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 archiviate da gcloud CLI

gcloud CLI utilizza Token di accesso OAuth 2.0 per autenticare le richieste delle API Google Cloud. Il flusso OAuth varia in base tipi di credenziali utilizzate, ma in genere il token di accesso e altre credenziali accessibili localmente. In ogni caso, il token di accesso scade dopo 60 minuti, ma e altri tipi di credenziali potrebbero essere permanenti.

Quando autorizzare gcloud CLI con un account utente, gcloud CLI avvia un flusso di consenso OAuth a tre vie per accedere le 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. Nelle impostazioni predefinite, di lunga durata persiste finché condizioni di scadenza soddisfatte.

Quando autorizzare gcloud CLI con un account di servizio, gcloud CLI avvia un flusso OAuth a due vie per accedere 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 è archiviata in gcloud CLI configurazione e rimane valida finché elimina 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 gcloud CLI può chiedere un token di accesso al server dei metadati. Google gestisce e ruota la chiave di firma privata utilizzata per creare il token di accesso; le credenziali a lunga durata non sono esposte all'applicazione.

Quando eseguire l'autenticazione con la federazione delle identità per i carichi di lavoro, le applicazioni si autenticano in base a una credenziale di un'identità esterna e ricevere 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 utente malintenzionato riesce a compromettere un endpoint, le credenziali come OAuth i token sono bersagli preziosi perché consentono agli aggressori di persistere o di riassegnare il 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 eseguire l'autenticazione per utilizzare REST richieste ai servizi Google Cloud quando si lavora con un client non supportato libreria. Lo sviluppatore può visualizzare le credenziali in 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, la minaccia principale è che l'aggressore può eseguire i comandi della gcloud CLI altro codice con le credenziali legittime dell'identità autenticata. Nel 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 una 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'autore dell'attacco riesce a compromettere i token OAuth, può completa 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 da l'account utente o di servizio compromesso, rendendo difficile distinguerlo delle attività normali e dannose nei log.
  • Un utente malintenzionato può aggiornare il token di accesso a tempo indeterminato utilizzando un il token di aggiornamento associato a un utente o a una chiave privata associata a un l'account di servizio.
  • Un aggressore può bypassare l'autenticazione con la password dell'utente o la procedura perché i token vengono concessi dopo il flusso di accesso.

Best practice per la mitigazione dei rischi

Implementare i controlli descritti nelle sezioni seguenti per ridurre il rischio di compromissione dei token gcloud CLI. 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. Dopo la durata definita della sessione, il criterio di riautenticazione invalida il token di aggiornamento e obbliga l'utente a riautenticare regolarmente gcloud CLI con la propria password token di sicurezza.

La durata della sessione per i servizi Google Cloud è diversa impostazione da durata della sessione per i servizi Google, che controlla le sessioni web per l'accesso a tutti i servizi Google Workspace, non controlla la riautenticazione per Google Cloud. Se utilizzi per 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, il perimetro blocca le richieste a servizi con restrizioni che provengono endpoint controllati dagli aggressori che si trovano al di fuori del tuo ambiente.

Configura Chrome Enterprise Premium

Configura i criteri di Chrome Enterprise Premium per ricevere aiuto 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. Richieste che usano credenziali di autorizzazione compromesse, ma che non soddisfano le le condizioni definite nel criterio di Chrome Enterprise Premium vengono rifiutate.

Chrome Enterprise Premium è un un controllo incentrato sugli utenti che rifiuta il traffico dell'API utente che non soddisfa le le condizioni di traffico. I 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, 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 le efficacia delle credenziali compromesse su una macchina controllata da un aggressore è 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.

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 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 chiave dell'account.

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

Consideriamo il principio del privilegio minimo

Quando si progettano criteri IAM, considera 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. Esaminare e applicare i consigli sui ruoli in modo da evitare criteri IAM con ruoli inutilizzati ed eccessivi nel tuo completamente gestito di Google Cloud.

Proteggi gli endpoint

Valuta in che modo un malintenzionato potrebbe ottenere l’accesso fisico o da remoto come workstation di sviluppo o istanze di Compute Engine. Mentre un piano per affrontare la minaccia di compromissioni di token OAuth è importante, valutate anche come reagire alla minaccia di come può compromettere gli endpoint attendibili. Se un utente malintenzionato ha agli endpoint attendibili, possono eseguire gcloud CLI o altro codice direttamente sull'endpoint stesso.

Sebbene la protezione completa per le workstation degli sviluppatori esula dall'ambito di applicazione di questo documento, valuta in che modo gli strumenti e le operazioni di sicurezza possono aiutarti proteggere e monitorare gli endpoint per rilevare eventuali compromissioni. Considera quanto segue. 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 sostituite con credenziali di breve durata?
  • Esistono dispositivi condivisi in cui qualcuno potrebbe leggere la cache di un altro utente Credenziali gcloud CLI?
  • Un utente può eseguire l'autenticazione con gcloud CLI da un sistema non attendibile dispositivo?
  • In che modo il traffico approvato si connette alle risorse all'interno del VPC Perimetro Service Control?

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 disporre dell'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 necessita di un ruolo nella Console di amministrazione, Amministratore 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 alle la progettazione e il funzionamento del tuo ambiente.

Best practice per la correzione dopo un incidente di sicurezza

Dopo che un endpoint è stato compromesso, nell’ambito il tuo piano di gestione degli incidenti, determinare come rispondere alla minaccia principale di un endpoint compromesso mitigare i potenziali danni in corso causati dalla minaccia secondaria compromessi. Se un utente malintenzionato ha accesso permanente dello sviluppatore, potrebbero copiare di nuovo i token dopo che l'utente legittimo esegue nuovamente l'autenticazione. 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 aiutano a limitare l'impatto di un evento come questo in Google Cloud dell'organizzazione.

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.

Fai scadere i token attivi per tutti gli account utente con il controllo sessione 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 fa in modo che tutti i token di aggiornamento scadano alla fine del periodo definisci, che limita il tempo per cui un aggressore può utilizzare il file compromesso di token.

Disabilita 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, rimozione delle credenziali di gcloud CLI è il metodo più efficace per un team di sicurezza per affrontare la compromissione di OAuth per le identità degli utenti. 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 Rimuovi le credenziali di gcloud CLI 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ò essere fonte di disturbo per gli utenti legittimi e risolvere i problemi e processi che dipendono dalle credenziali utente. Se scegli di adottare questo approccio, preparare una soluzione basata su script che il tuo centro operativo di sicurezza (SOC) possa eseguire avanzare e testarlo con alcuni utenti.

Il codice campione seguente utilizza l'SDK Admin di Workspace per identificare tutti gli utenti di identità nel tuo account Google Workspace o Cloud Identity che e l'accesso a gcloud CLI. 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 abilitare l'API SDK Admin ed eseguire questo codice, consulta le 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 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, disabilita l'account di servizio, elimina le chiavi degli account di servizio se presenti e, dopo 60 minuti, abilitare 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 garantire che i token di accesso non vengano utilizzati in modo illecito all'interno di e una durata di 60 minuti, devi disabilitare 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