Best practice per proteggere le credenziali sviluppatore

Scopri le best practice per proteggere le workstation degli sviluppatori e prevenire il furto e l'uso improprio delle Google Cloud credenziali, inclusi i token di supporto OAuth di Google Cloud CLI, le Credenziali predefinite dell'applicazione e le chiavi locali.

Questo documento è destinato ai team di sicurezza o agli architetti cloud responsabili della protezione delle risorse cloud da accessi illegittimi. Scopri i controlli disponibili che puoi utilizzare per ridurre in modo proattivo l'impatto delle credenziali degli sviluppatori compromesse e correggere l'ambiente dopo che un endpoint è stato compromesso.

Il rischio di credenziali compromesse

Un malintenzionato può compromettere le credenziali se ottiene l'accesso a un endpoint in cui un account utente o account di servizio legittimo è già stato autenticato con Google Cloud o gcloud CLI. Il 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 del malintenzionato all'endpoint compromesso, il malintenzionato 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.

Panoramica delle credenziali degli sviluppatori

Le seguenti Google Cloud credenziali si trovano in genere nelle workstation degli sviluppatori:

Nelle sezioni seguenti viene descritto come viene archiviato e utilizzato ogni tipo di credenziale.

Token OAuth di gcloud CLI

gcloud CLI utilizza i token di accesso OAuth 2.0 per autenticare le richieste alle Google Cloud API. Il flusso OAuth varia in base ai tipi di credenziali utilizzati, ma in genere il token di accesso e le altre credenziali sono accessibili localmente. In ogni caso, il token di accesso scade dopo 60 minuti per impostazione predefinita, ma può durare fino a 12 ore in base ai vincoli di durata estesa. Tuttavia, 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 Google Cloud API per conto dell'utente. Una volta 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. Il token di aggiornamento di lunga durata rimane valido fino a quando non vengono soddisfatte le condizioni di scadenza met.

Quando autorizzi gcloud CLI con un service account, gcloud CLI avvia un flusso OAuth a due vie per accedere alle Google Cloud API come identità del account di servizio. Dopo aver attivato un account di servizio da un file di chiavi private, gcloud CLI utilizza questa chiave per richiedere periodicamente un token di accesso. La chiave privata di lunga durata viene archiviata nella configurazione di gcloud CLI e rimane valida finché non disattivi o elimini la chiave del account di servizio.

Quando esegui gcloud CLI all'interno di un Google Cloud ambiente, come Compute Engine o Cloud Shell, l'applicazione può trovare automaticamente le credenziali ed eseguire l'autenticazione come service account. Ad esempio, in Compute Engine, un'applicazione come gcloud CLI può eseguire una query sul server di metadati per un token di accesso. Google gestisce ed esegue la rotazione della chiave di firma privata utilizzata per creare il token di accesso e le credenziali di lunga durata non vengono esposte all'applicazione.

Credenziali predefinite dell'applicazione

Le Credenziali predefinite dell'applicazione vengono utilizzate dalle applicazioni per l'autenticazione alle Google Cloud API. Gli sviluppatori possono generare Credenziali predefinite dell'applicazione eseguendo gcloud auth application-default login. Questo comando scrive un file JSON in testo non crittografato ($HOME/.config/gcloud/application_default_credentials.json o %APPDATA%\gcloud\application_default_credentials.json), che contiene un token di aggiornamento OAuth 2.0 e le credenziali client per le librerie client.

Qualsiasi libreria client o script personalizzato può utilizzare queste credenziali per chiamare Google Cloud le API.

Poiché le Credenziali predefinite dell'applicazione vengono salvate in testo non crittografato, qualsiasi processo o script non attendibile in esecuzione nel contesto dell'utente può accedere direttamente al file o utilizzare comandi come gcloud auth application-default print-access-token per recuperare i token di accesso attivi.

Il malware tipico spesso prende di mira la directory ~/.config/gcloud/ per raccogliere application_default_credentials.json.

Per ulteriori informazioni, consulta Credenziali predefinite dell'applicazione.

Chiavi dei service account

Le chiavi dei service account sono file di chiavi JSON private scaricati dalla Google Cloud console. Queste chiavi vengono utilizzate dalle applicazioni per l'autenticazione alle Google Cloud API. Le chiavi dei service account possono essere archiviate nelle seguenti posizioni:

  • Directory di configurazione di gcloud CLI dopo l'esecuzione di gcloud auth activate-service-account
  • File system locale
  • Repository di codice interno

Le chiavi dei service account sugli endpoint degli sviluppatori non sono vincolate alla verifica in due passaggi, non hanno limiti di sessione e non scadono automaticamente.

Un malintenzionato che ruba una chiave del account di servizio può creare token di accesso del account di servizio per mantenere l'accesso persistente.

Per ulteriori informazioni, leggi le best practice per la gestione delle account di servizio account.

Chiavi SSH

Le chiavi SSH vengono utilizzate per l'autenticazione con le istanze di Compute Engine. Gli sviluppatori possono generare chiavi SSH utilizzando gcloud compute ssh. Questo comando genera chiavi private locali in ~/.ssh/google_compute_engine. Le chiavi SSH sono di lunga durata.

Un malintenzionato può utilizzare una chiave SSH rubata per accedere a una VM e quindi eseguire una query sul server di metadati per estrarre un token del account di servizio collegato. Questo attacco aggira i firewall del perimetro esterno.

Anziché utilizzare le chiavi SSH, valuta la possibilità di utilizzare OS Login con la verifica in due passaggi. Per ulteriori informazioni, consulta Applicare la verifica in due passaggi per l'accesso al server remoto.

Cookie del browser

I cookie del browser autenticano le richieste HTTP web alla Google Cloud console e a Cloud Shell. I cookie del browser vengono creati automaticamente quando un utente accede alla Google Cloud console.

I cookie vengono archiviati nella directory del profilo del browser sulla workstation locale. Ad esempio, Google Chrome archivia i cookie in ~/.config/google-chrome/ su Linux o %LOCALAPPDATA%\Google\Chrome\User Data su Windows.

I cookie del browser sono credenziali di lunga durata che vengono invalidate solo quando un utente esegue la disconnessione, quando si verifica un timeout della sessione o quando un amministratore reimposta la sessione utente nella Console di amministrazione.

Un malintenzionato che ruba questi cookie può importarli in un altro browser per dirottare le sessioni della console attive Google Cloud , bypassando l'autenticazione.

Per ridurre il rischio di furto dei cookie di sessione, imposta la durata della sessione per Google Cloud i servizi.

Token di accesso della federazione delle identità della forza lavoro

Gli sviluppatori possono utilizzare la federazione delle identità della forza lavoro per eseguire l'autenticazione tramite un provider di identità esterno in modo da poter accedere alle Google Cloud risorse.

Per accedere con un'identità federata, gli sviluppatori utilizzano un file di configurazione dell'accesso (creato con il gcloud iam workforce-pools create-login-config comando) e accedono a gcloud CLI. Dopo l'autenticazione con il provider di identità esterno, il servizio token di sicurezza scambia il codice di autorizzazione con un token di accesso federato di breve durata e un token di aggiornamento OAuth.

gcloud CLI archivia i metadati delle credenziali e i token di aggiornamento in un database delle credenziali locale e memorizza nella cache i token di accesso attivi nella directory di configurazione di gcloud CLI. I token di accesso federati sono credenziali di breve durata che scadono dopo un periodo di tempo prestabilito (60 minuti per impostazione predefinita).

Un malintenzionato che compromette un endpoint può estrarre i token di accesso federati attivi o utilizzare gcloud auth print-access-token per simulare l'identità dell'entità della forza lavoro. Se l'identità della forza lavoro dispone dei diritti di simulazione dell'identità, il malintenzionato può anche richiedere token di accesso del account di servizio per aumentare i privilegi.

Per ridurre i rischi, configura la durata della sessione nel pool di identità della forza lavorocon la durata minima necessaria e allinea la durata alle policy di riautenticazione e timeout della sessione del provider di identità esterno. Per ulteriori informazioni su come archiviare e gestire le credenziali, consulta le best practice per l'utilizzo della federazione delle identità per i workload.

Impatto delle credenziali compromesse

Se un malintenzionato riesce a compromettere un endpoint, le credenziali come i token OAuth sono obiettivi preziosi perché consentono ai malintenzionati di mantenere o aumentare il proprio accesso.

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

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

Se un malintenzionato compromette un endpoint, la minaccia principale è che può eseguire comandi gcloud CLI o altro codice con le credenziali legittime dell'identità autenticata. Inoltre, il malintenzionato potrebbe copiare le credenziali in un altro endpoint che controlla per mantenere l'accesso. Quando si verifica questo furto di credenziali, si verifica una minaccia secondaria. Il malintenzionato può comunque utilizzare le credenziali di lunga durata per avere un accesso persistente anche dopo aver rimosso l'accesso all'endpoint compromesso.

Se il malintenzionato riesce a compromettere le credenziali degli sviluppatori, può completare le seguenti azioni:

  • Simulare l'identità dell'utente o del account di servizio compromesso. Il traffico API che utilizza i token compromessi viene registrato come se provenisse dall'utente o dal account di servizio compromesso, il che rende difficile distinguere tra attività normali e dannose nei log.
  • Richiedere token di accesso a tempo indeterminato utilizzando un token di aggiornamento OAuth persistente (da gcloud CLI o Credenziali predefinite dell'applicazione) o una chiave privata associata a un account di servizio.
  • Bypassare l'autenticazione con la password dell'utente o la verifica in due passaggi perché i token vengono concessi dopo il flusso di accesso.
  • Utilizzare le chiavi SSH rubate per accedere alle istanze di Compute Engine ed eseguire query sul server di metadati per rubare i token dei account di servizio collegati.
  • Utilizzare i cookie del browser rubati per dirottare le sessioni della Google Cloud console attive senza richiedere la password dell'utente o la verifica in due passaggi.
  • Utilizzare i token di accesso federati rubati per accedere alle risorse concesse ai pool di identità della forza lavoro o aumentare i privilegi simulando l'identità dei service account.

Best practice per la mitigazione dei rischi

Implementa i controlli descritti nelle sezioni seguenti per contribuire a mitigare il rischio di credenziali degli sviluppatori compromesse. Se segui le best practice di sicurezza descritte nel progetto di base aziendale o nella progettazione della landing zone in Google Cloud, potresti aver già implementato questi controlli.

Impostare la durata della sessione per i Google Cloud servizi

Per ridurre il tempo in cui un malintenzionato può sfruttare un token compromesso, imposta la durata della sessione per Google Cloud i servizi. Per i nuovi clienti, viene applicata automaticamente una durata della sessione predefinita di 16 ore. I clienti che hanno creato la propria Google Cloud organizzazione prima del 2023 potrebbero avere un'impostazione predefinita che non richiede mai la riautenticazione. Esamina questa impostazione per assicurarti di avere una policy di riautenticazione con una durata della sessione compresa tra 1 e 24 ore. La policy di riautenticazione impone all'utente di riautenticare regolarmente gcloud CLI con la propria password o il proprio token 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 riautenticazione per Google Cloud. Se utilizzi i servizi Google Workspace, imposta la durata della sessione per entrambi.

Configurare i Controlli di servizio VPC

Configura Controlli di servizio VPC nel tuo ambiente per assicurarti che solo il Google Cloud traffico API proveniente dal perimetro definito possa accedere alle risorse supportate. Il perimetro di servizio limita l'utilità delle credenziali compromesse perché blocca le richieste ai servizi limitati provenienti da endpoint controllati da malintenzionati che si trovano al di fuori del tuo ambiente.

Configurare Chrome Enterprise Premium

Configura i criteri di Chrome Enterprise Premium per proteggere la Google Cloud console e Google Cloud le API. Configura un livello di accesso e un binding di Chrome Enterprise Premium per consentire in modo selettivo gli attributi che vengono valutati su ogni richiesta API, incluso l'accesso basato su IP o l'accesso basato su certificati per mTLS. Le richieste che utilizzano credenziali di autorizzazione compromesse ma non soddisfano le condizioni definite nella policy di Chrome Enterprise Premium vengono rifiutate.

Chrome Enterprise Premium è un controllo incentrato sull'utente che rifiuta il traffico API dell'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. I Controlli di servizio VPC si applicano a tutte le identità utente e le identità dei account di servizio, ma 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 l'efficacia delle credenziali compromesse su una macchina controllata da 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 di Compute Engine utilizzando SSH, configura OS Login con la verifica in due passaggi. In questo modo viene applicato un checkpoint aggiuntivo in cui un utente deve eseguire nuovamente l'autenticazione con la propria password o il proprio token di sicurezza. Un malintenzionato con token OAuth compromessi ma senza password o token di sicurezza viene bloccato da questa funzionalità.

L'accesso RDP (Remote Desktop Protocol) 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. Quando utilizzi IAP Desktop (Identity-Aware Proxy) o i plug-in RDP basati su Google Chrome, completa i seguenti passaggi:

Limitare l'utilizzo delle chiavi dei account di servizio

Quando utilizzi una chiave account di servizio per l'autenticazione, il valore della chiave viene archiviato nei file di configurazione di gcloud CLI, separatamente dal file della chiave scaricata. Un malintenzionato con accesso al tuo ambiente può copiare la chiave dalla configurazione di gcloud CLI o copiare il file della chiave dal file system locale o dal repository di codice interno. Pertanto, oltre al piano per mitigare i token di accesso compromessi, valuta la modalità di gestione dei file delle chiavi dei service account scaricati.

Esamina alternative più sicure per l'autenticazione per ridurre o eliminare i casi d'uso che dipendono da una chiave del account di servizio. Inoltre, applica i vincoli della policy dell'organizzazione constraints/iam.disableServiceAccountKeyCreation e constraints/iam.disableServiceAccountKeyUpload per disattivare la creazione di chiavi dei account di servizio.

Applicare il principio del privilegio minimo

Quando progetti le policy IAM (Identity and Access Management), tieni presente il privilegio minimo. Concedi agli utenti solo i ruoli di cui hanno bisogno per svolgere un'attività con l'ambito più piccolo. Esamina e applica i consigli sui ruoli per evitare policy IAM con ruoli inutilizzati ed eccessivi nel tuo ambiente.

Proteggere gli endpoint

Valuta in che modo un malintenzionato potrebbe ottenere l'accesso fisico o remoto agli endpoint, ad esempio le workstation degli sviluppatori o le istanze di Compute Engine. Sebbene sia importante un piano per affrontare la minaccia di credenziali compromesse, considera anche il rischio che un malintenzionato comprometta i tuoi endpoint attendibili. Se un malintenzionato ha accesso ai tuoi endpoint attendibili, può eseguire comandi gcloud CLI o altro codice direttamente sugli endpoint stessi.

Sebbene la protezione completa delle workstation degli sviluppatori non rientri nell'ambito di questo documento, valuta in che modo i tuoi strumenti e le tue operazioni di sicurezza possono contribuire a proteggere e monitorare i tuoi endpoint per rilevare eventuali compromissioni. Prendi in considerazione queste domande:

  • In che modo viene protetta la sicurezza fisica delle workstation degli sviluppatori?
  • Come identifichi e rispondi alle violazioni della rete?
  • In che modo gli utenti ottengono l'accesso remoto alle sessioni SSH o RDP?
  • In che modo le credenziali persistenti come le chiavi SSH o le chiavi dei account di servizio potrebbero essere compromesse?
  • Esistono flussi di lavoro che utilizzano credenziali persistenti che potrebbero essere sostituite con credenziali di breve durata?
  • Esistono dispositivi condivisi in cui qualcuno potrebbe leggere le credenziali di 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 Controlli di servizio VPC?

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

Allineare i team di risposta

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

Per valutare e rispondere a una compromissione, consulta Rispondere alle Google Cloud credenziali compromesse.

Monitorare la compromissione delle credenziali

Per monitorare potenziali compromissioni, valuta quanto segue:

  • Esegui la scansione dei secret nei repository di codice utilizzando strumenti come Rilevamento anomalie o scansione dei secret.

  • In Cloud Audit Logs, configura gli avvisi per quanto segue:

    • Metodi iamcredentials.googleapis.com (ad esempio GenerateAccessToken, GenerateIdToken, SignJwt) per controllare la generazione di token dei account di servizio

      Questi log richiedono l'attivazione dei log degli accessi ai dati .

    • protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail per controllare le simulazioni dell'identità di utenti e account di servizio

    • Richieste di scambio sts.googleapis.com per asserzioni di identità anomale

  • In Security Command Center, monitora i seguenti risultati delle minacce di Event Threat Detection:

    • Persistenza: nuova regione
    • Persistenza: nuovo user agent
    • Persistenza: nuovo metodo API
    • Evasione: accesso da proxy con anonimizzazione
    • Aumento dei privilegi: simulazione anomala dell'identità del service account per l'attività di amministrazione
    • Aumento dei privilegi: simulatore anomalo dell'identità del service account per l'attività di amministrazione
    • Accesso iniziale: chiave del service account divulgata utilizzata
    • Persistenza: chiave del service account creata
    • Accesso iniziale: accesso sospetto bloccato
    • Accesso iniziale: account disattivato dirottato

    Per ogni minaccia vengono forniti i passaggi di indagine consigliati per facilitare la risposta.

  • Monitora gli accessi degli utenti in Google Workspace e Cloud Identity. Per monitorare meglio i problemi, valuta la possibilità di esportare i log in Cloud Logging.

  • Monitora i log di Chrome Enterprise Premium e dei Controlli di servizio VPC per i tentativi di accesso al di fuori del perimetro con token rubati.

  • Monitora le anomalie nell'utilizzo delle chiavi dei account di servizio utilizzando Cloud Monitoring.

Assicurati che il tuo Security Operations Center (SOC) venga informato tempestivamente e disponga dei playbook, degli strumenti e dell'accesso necessari per rispondere rapidamente a una sospetta compromissione delle credenziali. Puoi anche integrare Security Command Center con il tuo SIEM esistente o importare i log in Google Security Operations per ulteriori analisi.

Passaggi successivi