Best practice per la gestione delle chiavi degli account di servizio

A differenza degli utenti normali, gli account di servizio non hanno password. Gli account di servizio utilizzano invece coppie di chiave RSA per l'autenticazione. Se conosci la chiave privata della coppia di chiavi di un account di servizio, puoi utilizzare la chiave privata per creare un token di connessione JWT e utilizzare il token di connessione per richiedere un token di accesso. Il token di accesso risultante riflette l'identità dell'account di servizio e puoi utilizzarlo per interagire con le API Google Cloud per conto dell'account di servizio.

Poiché la chiave privata ti consente di autenticarti come account di servizio, avere accesso alla chiave privata è simile conoscere la password di un utente. La chiave privata è nota come chiave dell'account di servizio. Le coppie di chiavi utilizzate dagli account di servizio rientrano in due categorie: gestite da Google e gestite dall'utente.

Le chiavi degli account di servizio possono rappresentare un rischio per la sicurezza se non vengono gestite con attenzione. Dovresti scegliere un'alternativa più sicura per l'autenticazione quando è possibile. Le principali minacce sono correlate alle chiavi degli account di servizio:

  • fuga di credenziali: le chiavi degli account di servizio potrebbero finire inavvertitamente in posizioni in cui non dovrebbero essere archiviate. Un malintenzionato può utilizzare una chiave dell'account di servizio divulgata per autenticarsi e introdursi nel tuo ambiente.
  • Escalation dei privilegi: se un utente malintenzionato ottiene l'accesso a una chiave dell'account di servizio mal protetta, potrebbe essere in grado di utilizzarla per aumentare i propri privilegi.
  • Divulgazione di informazioni: le chiavi degli account di servizio potrebbero divulgare inavvertitamente metadati riservati.
  • Non rifiuto: eseguendo l'autenticazione mediante una chiave dell'account di servizio e consentendo all'account di servizio di eseguire operazioni per suo conto, un utente malintenzionato potrebbe nascondere la propria identità e le proprie azioni.

Il modo migliore per mitigare queste minacce è evitare le chiavi degli account di servizio gestite dall'utente e utilizzare altri metodi per autenticare gli account di servizio quando possibile. Puoi anche utilizzare le condizioni IAM e i Controlli di servizio VPC per limitare le risorse potenzialmente accessibili da un account di servizio compromesso.

Per situazioni in cui non puoi utilizzare alternative più sicure alle chiavi degli account di servizio, questa guida illustra le best practice per la gestione, l'utilizzo e la protezione delle chiavi degli account di servizio.

Protezione dalla fuga di credenziali

Analogamente a un nome utente e a una password, le chiavi degli account di servizio sono una forma di credenziale. Se un utente può accedere a una chiave dell'account di servizio valida, può utilizzarla per eseguire l'autenticazione e accedere alle risorse a cui è stato concesso l'accesso al rispettivo account di servizio.

Per i malintenzionati, le chiavi degli account di servizio possono essere ancora più preziose di una password divulgata: è improbabile che il tentativo di accedere utilizzando una password divulgata non vada a buon fine se l'account utente è stato configurato per utilizzare la verifica in due passaggi e le verifiche dell'accesso. Al contrario, è probabile che l'autenticazione mediante l'utilizzo di una chiave dell'account di servizio divulgata vada a buon fine perché gli account di servizio non sono soggetti a ulteriori verifiche dell'accesso.

I malintenzionati potrebbero cercare le chiavi degli account di servizio in diverse posizioni, tra cui:

  • Repository di codice sorgente di progetti open source
  • Bucket Cloud Storage pubblici
  • Dump di dati pubblici dei servizi violati

Oltre alle posizioni pubbliche, i malintenzionati potrebbero cercare le chiavi degli account di servizio in località private compromesse. Ecco alcuni esempi:

  • Caselle di posta
  • Condivisioni di file
  • Spazio di archiviazione dei backup
  • Directory del file system temporaneo

Un modo efficace per ridurre il rischio di perdita delle chiavi degli account di servizio è ridurre il numero di chiavi in circolazione e disincentivare la creazione di nuove chiavi. Le seguenti sezioni descrivono come limitare il numero di chiavi degli account di servizio in circolazione e quali altre misure possono aiutarti a limitare il rischio di perdite degli account di servizio.

Best practice:

Fornisci alternative per creare chiavi degli account di servizio.
Utilizza i vincoli dei criteri dell'organizzazione per limitare i progetti che possono creare chiavi degli account di servizio.
Non lasciare le chiavi degli account di servizio in località temporanee.
Non passare chiavi degli account di servizio tra utenti.
Non inviare chiavi degli account di servizio ai repository di codice sorgente.
Non incorporare le chiavi degli account di servizio nei file binari dei programmi.
Utilizza insight e metriche per identificare le chiavi degli account di servizio inutilizzate.
Ruota le chiavi degli account di servizio per ridurre i rischi per la sicurezza causati dalla perdita di chiavi.
Utilizza le date di scadenza per far scadere automaticamente le chiavi.
Utilizza i vincoli dei criteri dell'organizzazione per disabilitare automaticamente le chiavi divulgate.

Fornisci alternative alla creazione di chiavi degli account di servizio

Assicurati che gli utenti della tua organizzazione siano a conoscenza delle alternative e possano giustificare il rischio aggiuntivo e l'overhead di gestione derivante dall'utilizzo di una chiave dell'account di servizio:

  • Educare gli sviluppatori sulle alternative più sicure alle chiavi degli account di servizio
  • Stabilisci un processo per aiutare gli sviluppatori a decidere il metodo di autenticazione appropriato per il loro caso d'uso prima di creare una nuova chiave dell'account di servizio.
  • Utilizza i vincoli dei criteri dell'organizzazione per impedire la creazione di nuove chiavi degli account di servizio e consenti eccezioni solo per i progetti che hanno dimostrato di non poter utilizzare un'alternativa più sicura.

Utilizza i vincoli dei criteri dell'organizzazione per limitare i progetti che possono creare chiavi degli account di servizio

Date le alternative più sicure alle chiavi degli account di servizio, è meglio considerare l'utilizzo delle chiavi degli account di servizio come eccezione anziché come norma.

Per impedire l'utilizzo non necessario di chiavi degli account di servizio, utilizza i vincoli dei criteri dell'organizzazione:

La modifica dei vincoli dei criteri dell'organizzazione richiede l'autorizzazione orgpolicy.policy.set. Poiché né il ruolo Proprietario (roles/owner) né Editor (roles/editor) include questa autorizzazione, i vincoli possono essere applicati anche in ambienti non di produzione in cui alcune entità potrebbero avere accesso come Proprietario o Editor ai progetti.

Non lasciare le chiavi degli account di servizio in località temporanee

Quando crei una chiave dell'account di servizio utilizzando la console Google Cloud, la maggior parte dei browser scarica immediatamente la nuova chiave e la salva in una cartella di download sul computer. Dovresti spostare immediatamente la chiave nella posizione in cui vuoi memorizzarla. Assicurati di non lasciare accidentalmente una copia nella cartella di download o nel cestino del computer.

Puoi ridurre il rischio di lasciare accidentalmente copie delle chiavi degli account di servizio in posizioni temporanee utilizzando Google Cloud CLI: il comando gcloud iam service-accounts keys create ti consente di scrivere il file della chiave dell'account di servizio direttamente nella posizione in cui ne hai bisogno. Inoltre, nella maggior parte dei sistemi operativi, gcloud CLI regola automaticamente le autorizzazioni dei file in modo che il file sia accessibile solo a te.

Non passare le chiavi degli account di servizio tra gli utenti

Quando esegui il deployment di un'applicazione che richiede una chiave dell'account di servizio, potresti non avere l'autorizzazione per creare autonomamente una chiave dell'account di servizio. Potresti dover richiedere a un'altra persona di creare una chiave dell'account di servizio per te.

In scenari in cui più utenti sono coinvolti nella creazione e nel deployment di una chiave dell'account di servizio, c'è un rischio maggiore che le copie della chiave rimangano in caselle di posta, cronologie chat o altre posizioni. Ogni volta che è necessario un passaggio tra utenti, può essere più sicuro caricare una chiave dell'account di servizio:

  1. In qualità di utente che esegue il deployment dell'applicazione, crea un certificato autofirmato che utilizzi una coppia di chiavi RSA a 2048 bit sulla macchina di destinazione. Per creare il certificato, puoi usare openssl, certutil, New-SelfSignedCertificate o altri strumenti del sistema operativo.
  2. Passa il file del certificato all'utente che ha l'autorizzazione a caricarlo mantenendo la chiave privata sulla macchina di destinazione. Quando trasmetti il certificato, assicurati che non possa essere sostituito o manomesso, ma non è necessario mantenerlo riservato.
  3. In qualità di utente che dispone delle autorizzazioni necessarie per gestire le chiavi degli account di servizio, carica il certificato per associarlo a un account di servizio.

Seguendo questa procedura, eviti di trasmettere la chiave privata e scambi solo informazioni pubbliche tra gli utenti.

Non inviare chiavi degli account di servizio ai repository di codice sorgente

Le chiavi dell'account di servizio sono credenziali e devono essere protette da accessi non autorizzati. Se invii una chiave dell'account di servizio a un repository di codice sorgente, aumenta il rischio che la chiave diventi accessibile a utenti non autorizzati e utenti malintenzionati:

  • I malintenzionati potrebbero eseguire la scansione del codice sorgente dei repository di codice pubblico per individuare chiavi divulgate.
  • In futuro, potresti decidere di trasformare un repository di codice sorgente privato in un repository pubblico, senza prima verificare la presenza di chiavi.
  • Altri membri del team potrebbero archiviare copie del codice sorgente sulla propria workstation.

Quando lavori su un codice che utilizza una chiave dell'account di servizio, memorizza sempre la chiave dell'account di servizio separata dal codice sorgente per ridurre il rischio di inviare accidentalmente la chiave al repository di codice sorgente. In molti casi, puoi ridurre ulteriormente questo rischio non utilizzando affatto le chiavi degli account di servizio durante lo sviluppo e utilizzando le tue credenziali personali anziché le chiavi degli account di servizio.

Inoltre, configura il sistema di controllo del codice sorgente in modo che rilevi l'invio accidentale di chiavi dell'account di servizio:

Non incorporare le chiavi degli account di servizio nei file binari del programma

Le chiavi dell'account di servizio sono stringhe corrispondenti a un determinato pattern e possono essere identificate anche se incorporate in altri file o programmi binari. Se un malintenzionato ha accesso al programma binario, può estrarre tutte le chiavi dell'account di servizio incorporate nel programma binario.

I programmi binari dei programmi per le applicazioni lato server potrebbero essere ospitati in repository di artefatti oppure copiati sulle workstation di sviluppatori a scopo di debug. Mantenere le chiavi degli account di servizio separate dai file binari del programma aiuta ad assicurare che un utente che può accedere al programma binario non ottenga implicitamente l'accesso alle credenziali dell'account di servizio.

  • Per le applicazioni lato client come strumenti, programmi desktop o app mobile, non utilizzare gli account di servizio. Consenti invece agli utenti di eseguire l'autenticazione con le loro credenziali utilizzando il flusso di consenso OAuth.
  • Per le applicazioni lato server, non incorporare le chiavi degli account di servizio nel programma binario. ma mantieni invece le chiavi separate dal programma binario dell'applicazione.

Utilizza insight e metriche per identificare le chiavi degli account di servizio inutilizzate

Per ridurre al minimo il numero di chiavi di account di servizio valide in circolazione, ti consigliamo di disabilitare le chiavi appena non sono più necessarie, quindi di eliminarle quando hai la certezza che non siano più necessarie. Se non hai la certezza che una chiave sia ancora in uso o meno, puoi utilizzare gli insight sull'account di servizio e le metriche di autenticazione:

Poiché gli account di servizio appartengono a un progetto Google Cloud, insight e metriche devono essere monitorati singolarmente per ogni progetto.

Ruota le chiavi degli account di servizio per ridurre i rischi per la sicurezza causati dalla perdita di chiavi

Sebbene sia possibile ridurre la probabilità di perdita accidentale di una chiave dell'account di servizio, può essere difficile eliminare completamente il rischio.

La rotazione della chiave è il processo di sostituzione delle chiavi esistenti con nuove chiavi e di invalidazione delle chiavi sostituite. Ti consigliamo di ruotare regolarmente tutte le chiavi che gestisci, incluse le chiavi degli account di servizio.

La rotazione delle chiavi dell'account di servizio può aiutare a ridurre il rischio causato dalla perdita o dal furto delle chiavi. Se una chiave viene trapelata, i malintenzionati potrebbero impiegare giorni o settimane per scoprirla. Se ruoti regolarmente le chiavi dell'account di servizio, c'è una maggiore possibilità che le chiavi divulgate non siano più valide nel momento in cui un utente malintenzionato le riceve.

Avere un processo consolidato per la rotazione delle chiavi degli account di servizio consente inoltre di agire rapidamente se sospetti che una chiave dell'account di servizio sia stata compromessa.

Se hai generato personalmente la coppia di chiave pubblica/privata, l'hai archiviata in un modulo di sicurezza hardware (HSM) e hai caricato la chiave pubblica su Google, potrebbe non essere necessario ruotare la chiave in base a una pianificazione regolare. Puoi invece ruotare la chiave se ritieni che sia stata compromessa.

Utilizza date di scadenza per far scadere automaticamente le chiavi

Per impostazione predefinita, le chiavi degli account di servizio che crei e scarichi da IAM non hanno una data di scadenza e rimangono valide finché non le elimini. L'impostazione di una scadenza per le chiavi degli account di servizio può limitare i rischi per la sicurezza riducendo la durata delle credenziali permanenti. Tuttavia, l'impostazione delle tempistiche di scadenza presenta altri rischi. Ad esempio, l'impostazione di una scadenza può causare l'errore dei carichi di lavoro alla scadenza delle chiavi.

Utilizza le date di scadenza quando hai bisogno di accedere temporaneamente a un sistema che richiede una chiave dell'account di servizio. Ad esempio, utilizza la data di scadenza quando svolgi le seguenti operazioni:

  • Sviluppare codice in un ambiente non di produzione per un'applicazione che può autenticarsi solo con le chiavi degli account di servizio.
  • Utilizzo di uno strumento di terze parti che può eseguire l'autenticazione solo con le chiavi degli account di servizio

Evita di utilizzare date di scadenza per questi scenari:

  • Carichi di lavoro di produzione. In produzione, una chiave dell'account di servizio scaduta potrebbe causare un'interruzione accidentale. Puoi invece usare chiavi senza scadenza e gestire il relativo ciclo di vita conrotazione della chiavei.
  • Carichi di lavoro non di produzione che richiedono l'accesso permanente, ad esempio una pipeline di integrazione continua (CI).
  • Sistemi di rotazione della chiave che impediscono l'utilizzo di una chiave dopo un determinato periodo di tempo. Per scoprire di più sulle strategie di rotazione della chiave consigliate, consulta Rotazione delle chiavi dell'account di servizio.

Per limitare la validità delle chiavi degli account di servizio, puoi configurare una data di scadenza per le chiavi appena create nel progetto, nella cartella o nell'organizzazione. La data di scadenza non si applica alle chiavi esistenti.

In alternativa, puoi caricare una chiave dell'account di servizio e specificare una data Valido fino a nel file del certificato X.509. Una volta trascorsa la data di scadenza, la chiave non può essere utilizzata per l'autenticazione. Tuttavia, rimane associato all'account di servizio finché non lo elimini.

Utilizza i vincoli dei criteri dell'organizzazione per disabilitare automaticamente le chiavi divulgate

Anche se segui tutte le best practice per le chiavi degli account di servizio, è possibile che le chiavi degli account di servizio vengano divulgate.

Per facilitare la gestione delle credenziali divulgate, assicurati che il vincolo di risposta all'esposizione delle chiavi dell'account di servizio sia impostato su DISABLE_KEY. Se imposti il vincolo su questo valore, Google Cloud disattiverà automaticamente tutte le chiavi divulgate che rileva.

Per scoprire altre best practice per la gestione delle credenziali compromesse, vedi Gestione delle credenziali Google Cloud compromesse.

Protezione dall'escalation dei privilegi

L'utilizzo delle chiavi degli account di servizio può esporti ad attacchi di escalation dei privilegi se le chiavi sono meno protette rispetto alle risorse a cui concede l'accesso.

Supponiamo, ad esempio, che un malintenzionato abbia già preso piede nel tuo ambiente e ora provi ad accedere a determinate risorse di Google Cloud. Potrebbero non disporre ancora delle autorizzazioni per accedere a queste risorse, ma i loro privilegi potrebbero essere sufficienti per accedere a una chiave dell'account di servizio archiviata su una VM, una condivisione file o un'altra posizione meno sicura. Eseguendo l'autenticazione utilizzando la chiave dell'account di servizio, il malintenzionato può assumere l'identità dell'account di servizio. L'account di servizio potrebbe consentire all'utente malintenzionato di accedere alle risorse a cui in precedenza non aveva accesso, aumentando così i suoi privilegi.

Poiché una chiave dell'account di servizio concede indirettamente l'accesso alle risorse su Google Cloud, devi considerare la chiave stessa preziosa e che valga la pena di proteggere quanto le risorse stesse.

Le seguenti sezioni descrivono le best practice per la protezione delle chiavi degli account di servizio e la riduzione del rischio di accessi non autorizzati e della conseguente escalation dei privilegi.

Best practice:

Evita di memorizzare le chiavi su un file system.
Utilizza un HSM o un TPM per archiviare le chiavi.
Utilizza un archivio chiavi basato su software.
Non archiviare le chiavi in Secret Manager o in altri archivi di secret basati su cloud.
Non utilizzare il ruolo Editor nei progetti che consentono la creazione o il caricamento di chiavi degli account di servizio.
Evita di utilizzare chiavi degli account di servizio per la delega a livello di dominio.

Evitare di memorizzare le chiavi in un file system

Le chiavi degli account di servizio create utilizzando la console Google Cloud o gcloud CLI sono file JSON e puoi copiarli nel file system della macchina dove sono necessari. Tuttavia, l'archiviazione delle chiavi degli account di servizio come file su un file system può comportare diversi rischi, tra cui:

  • Alcuni file system, ad esempio NTFS, utilizzano autorizzazioni ereditate per impostazione predefinita. Se non è disabilitata, un'autorizzazione aggiunta a una cartella padre potrebbe inavvertitamente far sì che un file della chiave diventi più accessibile e visibile a utenti non autorizzati.
  • In un ambiente virtualizzato, i malintenzionati potrebbero essere in grado di minare la sicurezza del file system accedendo al disco virtuale sottostante.
  • Spesso l'accesso al file system e le modifiche alle autorizzazioni non vengono sottoposti a controllo. Se le autorizzazioni dei file vengono modificate inavvertitamente e la chiave diventa visibile a utenti non autorizzati, potrebbe essere difficile analizzare quando e da chi sono state apportate queste modifiche.
  • I file possono essere facilmente copiati e quindi esfiltrati se un malintenzionato riesce ad accedere.

Se possibile, evita di archiviare le chiavi degli account di servizio in un file system. Se non riesci a evitare di archiviare le chiavi su disco, assicurati di limitare l'accesso al file della chiave, di configurare il controllo dell'accesso ai file e di criptare il disco sottostante.

Utilizza un HSM o un TPM per archiviare le chiavi

Quando crei una chiave dell'account di servizio utilizzando la console Google Cloud o gcloud CLI, la chiave privata viene generata da Google Cloud e poi rivelata. Molti rischi per la sicurezza associati alle chiavi degli account di servizio sono dovuti al fatto che la chiave privata è, temporaneamente o permanente, disponibile in chiaro e può quindi essere difficile da proteggere.

Anziché consentire a Google Cloud di generare una coppia di chiavi, puoi utilizzare un modulo di sicurezza hardware (HSM) o un modulo TPM (Trusted Platform Module) per creare e gestire le chiavi:

  1. Utilizza un HSM o un TPM per generare una coppia di chiave RSA.
  2. Utilizza la coppia di chiavi per creare un certificato autofirmato.
  3. Carica il certificato come chiave dell'account di servizio.
  4. Consenti all'applicazione di utilizzare l'HMS o l'API di firma di TPM per firmare il JWT per l'autenticazione dell'account di servizio.

Un HSM o un TPM consente di utilizzare una chiave privata senza mai rivelarla in chiaro. L'utilizzo di un HSM o di un TPM per gestire le chiavi degli account di servizio consente quindi di applicare controllo dell'accesso'accesso riducendo al contempo il rischio che le chiavi vengano copiate in altri sistemi.

Alcune piattaforme forniscono astrazioni che ti consentono di sfruttare un TPM senza doverlo interagire direttamente. Ad esempio, Windows ti consente di gestire le chiavi protette da TPM utilizzando l'API CryptoNG insieme a Microsoft Platform Crypto Provider.

Le chiavi dell'account di servizio gestite da un TPM sono univoche per una macchina fisica o virtuale. Puoi comunque consentire a più macchine di condividere un account di servizio associando la chiave di ogni macchina a un account di servizio comune.

Usa un archivio chiavi basato su software

Nei casi in cui non è possibile utilizzare un archivio chiavi basato su hardware, utilizza un archivio chiavi basato su software per gestire le chiavi degli account di servizio. Analogamente alle opzioni basate su hardware, un archivio chiavi basato su software consente a utenti o applicazioni di utilizzare le chiavi degli account di servizio senza rivelare la chiave privata. Le soluzioni di archiviazione delle chiavi basate su software possono aiutarti a controllare l'accesso alle chiavi in modo granulare e possono inoltre garantire che ogni accesso alle chiavi venga registrato.

La sicurezza di un archivio di chiavi basato su software dipende in genere dal modo in cui è protetta la relativa chiave master. Prima di utilizzare un archivio chiavi basato su software, assicurati di controllare quanto segue:

  • il modo in cui la chiave master è protetta at-rest,
  • come funziona il processo di chiusura e chi è in grado di avviarlo,
  • in che modo le chiavi vengono protette dall'estrazione dalla memoria,
  • il modo in cui l'archivio chiavi è protetto da compromissioni se un utente malintenzionato ottiene l'accesso alla shell o all'hypervisor al sistema sottostante.

Non archiviare le chiavi in Secret Manager o in altri archivi di secret basati su cloud

Non è consigliabile utilizzare Secret Manager di Google Cloud per archiviare e ruotare le chiavi degli account di servizio. Il motivo è che, per accedere ai secret di Secret Manager, la tua applicazione deve avere un'identità che Google Cloud sia in grado di riconoscere. Se la tua applicazione ha già un'identità che Google Cloud è in grado di riconoscere, può utilizzare quell'identità per l'autenticazione in Google Cloud anziché utilizzare una chiave dell'account di servizio.

Lo stesso concetto si applica ad altri servizi di gestione dei secret basati su cloud, come Azure KeyVault e AWS Secret Manager. Se un'applicazione dispone già di un'identità che questi cloud provider sono in grado di riconoscere, potrebbero utilizzarla per l'autenticazione in Google Cloud anziché utilizzare una chiave dell'account di servizio.

Non utilizzare il ruolo Editor nei progetti che consentono la creazione o il caricamento di chiavi dell'account di servizio

Una differenza fondamentale tra i ruoli di base Editor (roles/editor) e Proprietario (roles/owner) è che il ruolo Editor non consente di modificare i criteri o i ruoli IAM. Con il ruolo Editor, non puoi quindi estendere facilmente il tuo accesso o concedere ad altri utenti l'accesso alle risorse del progetto.

Le limitazioni del ruolo Editor possono essere compromesse se un progetto contiene account di servizio. Poiché i ruoli Editor concedono l'autorizzazione per creare o caricare le chiavi degli account di servizio, un utente malintenzionato può creare nuove chiavi per gli account di servizio esistenti e utilizzarle per riassegnare il proprio accesso o per passare le chiavi ad altri utenti per ottenere l'accesso alle risorse del progetto.

Invece di utilizzare il ruolo Editor o qualsiasi altro ruolo di base, ti consigliamo di utilizzare i ruoli predefiniti con una definizione più restrittiva o di creare ruoli personalizzati che concedono solo le autorizzazioni necessarie.

Se devi utilizzare il ruolo Editor, disabilita il caricamento delle chiavi dell'account di servizio e la creazione delle chiavi utilizzando i vincoli dei criteri dell'organizzazione per garantire che non sia possibile usare in modo illecito il ruolo Editor per l'escalation dei privilegi.

Evita di utilizzare chiavi degli account di servizio per la delega a livello di dominio

La delega a livello di dominio ti consente di rubare l'identità di un utente, in modo da poter accedere ai dati di un utente senza che sia necessaria un'autorizzazione manuale da parte sua. Sebbene gli esempi che illustrano l'utilizzo della delega a livello di dominio suggeriscano comunemente l'utilizzo di chiavi degli account di servizio, l'utilizzo delle chiavi degli account di servizio non è necessario per eseguire la delega a livello di dominio.

Se utilizzi la delega a livello di dominio, evita chiavi degli account di servizio e utilizza invece l'API signJwt:

  1. Autentica un account di servizio utilizzando prima un account di servizio collegato, Workload Identity o Federazione delle identità per i carichi di lavoro.
  2. Crea un JWT e utilizza la rivendicazione sub per specificare l'indirizzo email dell'utente per cui richiedi l'accesso delegato.
  3. Usa l'API signJwt per firmare il JWT.
  4. Passa il JWT firmato alla risorsa token OAuth2 per ottenere un token di accesso.

Seguendo questo approccio, eviterai di dover gestire una chiave dell'account di servizio, il che comporta una configurazione che può essere protetta più facilmente.

Protezione contro le minacce legate alla divulgazione di informazioni

Best practice:

Evita di divulgare informazioni riservate nei certificati X.509 caricati.

Evita di divulgare informazioni riservate nei certificati X.509 caricati.

Per ogni chiave dell'account di servizio, IAM consente di scaricare un certificato X.509 dall'endpoint https://www.googleapis.com/service_accounts/v1/metadata/x509/ACCOUNT_EMAIL. Questo endpoint è pubblico e non richiede l'autenticazione.

Per le chiavi gestite da Google e dagli utenti che hai creato utilizzando la console Google Cloud o gcloud CLI, i certificati X.509 vengono creati automaticamente e contengono solo metadati di base come l'indirizzo email e la data di scadenza.

Per le chiavi dell'account di servizio caricate, il certificato X.509 fornito dall'endpoint pubblico è lo stesso certificato che hai caricato. Se il certificato che hai caricato contiene attributi facoltativi (come informazioni sull'indirizzo o sulla posizione incorporati nel nome comune), anche queste informazioni diventano accessibili pubblicamente. Un malintenzionato potrebbe usare queste informazioni per saperne di più sul tuo ambiente.

Per evitare di divulgare informazioni riservate, non aggiungere attributi facoltativi ai certificati X.509 caricati e utilizza un Subject generico.

Protezione dalle minacce di non ripudio

Quando noti attività sospette che interessano le tue risorse Google Cloud e vuoi analizzarne le origini, hai bisogno di dati che ti consentano di ricostruire la catena di eventi che hanno portato all'attività sospetta. La principale fonte di dati per eseguire questo tipo di analisi sono in genere gli audit log.

L'analisi degli audit log può diventare più difficile quando sono coinvolti account di servizio: se un'attività è stata avviata da un account di servizio, la voce di log contiene l'indirizzo email dell'account di servizio, ma devi anche scoprire quale utente o applicazione stava utilizzando l'account di servizio in quel momento.

Le seguenti sezioni contengono le best practice per utilizzare le chiavi degli account di servizio al fine di monitorarne l'utilizzo.

Best practice:

Utilizzare un account di servizio dedicato per ogni applicazione.
Utilizza una chiave dedicata per ogni macchina che esegue un'applicazione.

Usa un account di servizio dedicato per ogni applicazione

Tutti i record degli audit log contengono un campo principalEmail che identifica l'entità che ha avviato l'attività. Se condividi una chiave dell'account di servizio tra più applicazioni, può essere difficile identificare quale applicazione ha eseguito un'attività poiché i record degli audit log contengono lo stesso valore principalEmail.

Anziché condividere una chiave tra più applicazioni, crea un account di servizio dedicato per ogni applicazione. In questo modo, il campo principalEmail consente di identificare l'applicazione associata a un account di servizio, il che può aiutarti a ricostruire la catena di eventi che hanno portato a un'attività sospetta.

Usa una chiave dedicata per ogni macchina che esegue un'applicazione

Se esegui più copie della stessa applicazione su più macchine, il campo principalEmail potrebbe consentirti di identificare l'applicazione, ma non la macchina da cui ha avuto origine una determinata attività.

Per restringere le potenziali sorgenti di attività sospette, crea singole chiavi per ogni copia dell'applicazione. In questo modo, puoi utilizzare il campo serviceAccountKeyName aggiunto da molti servizi ai record degli audit log per distinguere la macchina da cui ha avuto origine un'attività.

Passaggi successivi