Best practice per la gestione delle chiavi degli account di servizio

A differenza dei normali utenti, gli account di servizio non hanno password. Gli account di servizio, invece, utilizzano coppie di chiave RSA per l'autenticazione: se conosci la chiave privata della coppia di chiavi di un account di servizio, puoi utilizzarla per creare un token JWT con mittente e utilizzare il token con mittente 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 a 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: gestita da Google e gestita 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 ogni volta che è possibile. Le principali minacce relative alle chiavi degli account di servizio sono:

• Perdita di credenziali: le chiavi degli account di servizio potrebbero finire inavvertitamente in luoghi in cui non dovrebbero essere archiviate. Un malintenzionato può utilizzare una chiave dell'account di servizio divulgata per autenticarsi e ottenere un punto d'appoggio nel tuo ambiente.
• Escalation dei privilegi: se un malintenzionato ottiene l'accesso a una chiave dell'account di servizio con scarsa sicurezza, potrebbe essere in grado di utilizzarla per eseguire l'escalation dei propri privilegi.
• Divulgazione di informazioni:le chiavi degli account di servizio potrebbero divulgare inavvertitamente metadati riservati.
• Non ripudio:autenticandosi utilizzando una chiave dell'account di servizio e consentendo all'account di servizio di eseguire operazioni per suo conto, un malintenzionato potrebbe nascondere la propria identità e le proprie azioni.

Il modo migliore per mitigare queste minacce è evitare le chiavi dei service account gestite dall'utente e utilizzare altri metodi per autenticare gli account di servizio, se possibile. Puoi anche utilizzare le condizioni IAM e i Controlli di servizio VPC per limitare le risorse a cui può accedere potenzialmente un account di servizio compromesso.

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

Protezione contro la fuga di credenziali

Come un nome utente e 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 autenticarsi e accedere alle risorse a cui è stato concesso l'accesso al rispettivo account di servizio.

Per gli utenti malintenzionati, le chiavi dell'account di servizio possono essere ancora più preziose di una password compromessa: è improbabile che il tentativo di accedere utilizzando una password compromessa riesca se l'account dell'utente è stato configurato per l'utilizzo della verifica in due passaggi e delle verifiche di accesso. Al contrario, l'autenticazione tramite una chiave dell'account di servizio compromessa ha maggiori probabilità di riuscire poiché gli account di servizio non sono soggetti a verifiche di accesso aggiuntive.

Gli utenti malintenzionati potrebbero cercare le chiavi dell'account di servizio in vari luoghi, tra cui:

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

Oltre alle posizioni pubbliche, gli utenti malintenzionati potrebbero cercare le chiavi dell'account di servizio in posizioni private che hanno compromesso. Ecco alcuni esempi:

• Posta in arrivo delle email
• Condivisioni file
• Spazio di archiviazione dei backup
• Directory del file system temporanee

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

Fornire alternative alla creazione delle chiavi degli account di servizio

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

• Fornisci agli sviluppatori informazioni sulle alternative più sicure alle chiavi degli account di servizio
• Stabilisci una procedura 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 del account di servizio e consenti eccezioni solo per i progetti che hanno dimostrato di non poter utilizzare un'alternativa più sicura.

Utilizzare i vincoli delle norme dell'organizzazione per limitare i progetti che possono creare chiavi del 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 un'eccezione piuttosto che la norma.

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

• Nella posizione principale della gerarchia delle risorse dell'organizzazione, applica i vincoli Disattiva creazione chiavi account di servizio e Disattiva caricamento chiavi account di servizio per impostare un valore predefinito in cui le chiavi dell'account di servizio non sono consentite.

• Se necessario, sostitui uno dei vincoli per i progetti selezionati per riattivare la creazione o il caricamento delle chiavi dell'account di servizio.

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

Non lasciare le chiavi dell'account di servizio in posizioni 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. Devi spostare immediatamente la chiave nella posizione in cui vuoi conservarla. Assicurati di non lasciare accidentalmente una copia nella cartella dei download o nel secchio del riciclo 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 ti serve. Inoltre, sulla maggior parte dei sistemi operativi, l'interfaccia alla gcloud CLI regola automaticamente le autorizzazioni dei file in modo che il file sia accessibile solo a te.

Non passare le chiavi dell'account di servizio tra 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 invece dover chiedere a un'altra persona di creare una chiave dell'account di servizio per te.

Negli scenari in cui sono coinvolti più utenti nella creazione e nell'implementazione di una chiave dell'account di servizio, è aumentato il rischio che copie della chiave rimangano nelle caselle di posta, nelle cronologie chat o in 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 utilizzare openssl, certutil, New-SelfSignedCertificate o altri strumenti del sistema operativo.
2. Passa il file del certificato all'utente che ha l'autorizzazione a caricare il certificato mantenendo la chiave privata sulla macchina di destinazione. Quando passi 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 dell'account di servizio, carica il certificato per associarlo a un account di servizio.

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

Non inviare le chiavi dell'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, esiste un rischio maggiore che la chiave diventi accessibile a utenti non autorizzati e malintenzionati:

• Gli utenti malintenzionati potrebbero cercare chiavi trapelate nel codice sorgente dei repository di origine pubblici.
• In futuro, potresti decidere di trasformare un repository di origine privato in un repository pubblico, senza prima controllare la presenza di chiavi.
• Altri membri del team potrebbero memorizzare copie del codice sorgente sulla propria workstation.

Quando lavori su codice che utilizza una chiave dell'account di servizio, archivia sempre la chiave dell'account di servizio separatamente dal codice sorgente per ridurre il rischio di inviare accidentalmente la chiave al repository di origine. 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:

• Se utilizzi Cloud Source Repositories, abilita il rilevamento delle chiavi per bloccare le operazioni push git che contengono chiavi private e per inviare una notifica agli utenti.
• Se utilizzi GitHub, abilita la scansione dei segreti per i tuoi repository.
• Utilizza il rilevamento delle anomalie di Security Command Center per visualizzare informazioni sulle credenziali trapelate.
• Se il tuo sistema di gestione del controllo del codice sorgente non supporta la scansione automatica, utilizza uno strumento open source come truffleHog per cercare i secret nel codice sorgente utilizzando un hook pre-commit, aggiungendo un passaggio alla pipeline di integrazione continua o entrambi.

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

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

I file binari del programma per le applicazioni lato server potrebbero essere ospitati in repository di elementi o essere copiati nelle stazioni di lavoro degli sviluppatori ai fini del debug. Mantenere le chiavi dell'account di servizio separate dai binari del programma contribuisce a garantire che un utente che può accedere al 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 autenticarsi con le proprie credenziali utilizzando il flusso di consenso OAuth.
• Per le applicazioni lato server, non incorporare le chiavi dell'account di servizio nel file binario. Mantieni invece le chiavi separate dal file binario dell'applicazione.

Utilizzare approfondimenti e metriche per identificare le chiavi degli account di servizio inutilizzate

Per ridurre al minimo il numero di chiavi dell'account di servizio valide in circolazione, è meglio disattivarle non appena non sono più necessarie ed eliminarle quando hai la certezza che non sono più necessarie. Se non sai con certezza se una chiave è ancora in uso, puoi utilizzare gli approfondimenti e le metriche di autenticazione dell'account di servizio:

• Gli approfondimenti sugli account di servizio ti consentono di identificare gli account di servizio che non sono stati utilizzati negli ultimi 90 giorni.
• Monitorando la metrica Eventi di autenticazione della chiave, puoi scoprire quando è stata utilizzata l'ultima volta una chiave dell'account di servizio e la frequenza con cui è stata utilizzata per autenticare un account di servizio.

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

Ruota le chiavi dell'account di servizio per ridurre il rischio per la sicurezza causato dalle chiavi trapelate

Sebbene sia possibile ridurre la probabilità di divulgare accidentalmente una chiave di account di servizio, può essere difficile eliminare completamente il rischio.

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

La rotazione delle chiavi dell'account di servizio può contribuire a ridurre il rischio rappresentato dalle chiavi divulgate o rubate. Se una chiave viene divulgata, i malintenzionati potrebbero impiegare giorni o settimane per scoprirla. Se ruoti regolarmente le chiavi dell'account di servizio, è più probabile che le chiavi trapelate non siano più valide quando vengono acquisite da un malintenzionato.

Avere un processo stabilito per la rotazione delle chiavi dell'account di servizio ti aiuta anche a intervenire rapidamente se sospetti che una chiave dell'account di servizio sia stata compromessa.

Se hai generato autonomamente la coppia di chiave pubblica/privata, hai archiviato la chiave privata in un modulo di sicurezza hardware (HSM) e hai caricato la chiave pubblica su Google, potresti non dover ruotare la chiave con una frequenza regolare. Puoi invece ruotare la chiave se ritieni che possa essere stata compromessa.

Utilizza le date di scadenza per consentire la scadenza automatica delle chiavi

Per impostazione predefinita, le chiavi dell'account di servizio che crei e scarichi da IAM non hanno una data di scadenza e rimangono valide fino a quando non le elimini. L'impostazione di una data di scadenza per le chiavi degli account di servizio può limitare il rischio per la sicurezza riducendo la durata della credenziale permanente. Tuttavia, esistono altri rischi associati all'impostazione di date di scadenza. Ad esempio, l'impostazione di una data di scadenza può causare l'interruzione dei workload quando le relative chiavi scadono.

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 le date di scadenza quando:

• Sviluppo di codice in un ambiente di produzione per un'applicazione che può autenticarsi solo con le chiavi dell'account di servizio
• Utilizzo di uno strumento di terze parti che può autenticarsi solo con le chiavi dell'account di servizio

Evita di utilizzare le date di scadenza per i seguenti scenari:

• Workload di produzione. In produzione, una chiave dell'account di servizio scaduta potrebbe causare un'interruzione accidentale. Utilizza invece chiavi che non scadono e gestisci il loro ciclo di vita con rotazione della chiave.
• Carichi di lavoro non di produzione che richiedono l'accesso permanente, ad esempio una pipeline di integrazione continua (CI).
• Sistemi di rotazione delle chiavi che impediscono l'utilizzo di una chiave dopo un determinato periodo di tempo. Per scoprire le strategie di rotazione della chiave consigliate, consulta Rotazione delle chiavi dell'account di servizio.

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

In alternativa, puoi caricare una chiave dell'account di servizio e specificare una data Valida 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.

Utilizzare i vincoli dei criteri dell'organizzazione per disattivare automaticamente le chiavi compromesse

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

Per gestire le credenziali trapelate, assicurati che il vincolo Risposta esposizione chiave service account sia impostato su DISABLE_KEY. Se imposti il vincolo su questo valore, Google Cloud disabiliterà automaticamente le eventuali chiavi con accesso non autorizzato rilevate.

Se una chiave viene disattivata perché è stata divulgata, ai metadati della chiave vengono aggiunti i seguenti campi:

• "disable_reason": "SERVICE_ACCOUNT_KEY_DISABLE_REASON_EXPOSED": indica che la chiave è stata disattivata perché è stata esposta.
• "extended_status": "SERVICE_ACCOUNT_KEY_EXTENDED_STATUS_KEY_EXPOSED"": indica che la chiave è stata precedentemente esposta pubblicamente. Questo valore persiste anche se riattivi la chiave.
• "extended_status_message": "LINK_TO_EXPOSURE": se disponibili, i metadati contengono un link alla posizione in cui è stata rilevata la chiave, che puoi utilizzare per la correzione.

Queste chiavi possono essere riattivate se necessario per mitigare un'interruzione del servizio. Tuttavia, ti consigliamo di disattivarle nuovamente il prima possibile, perché le chiavi esposte pubblicamente rappresentano un rischio per la sicurezza, anche se l'esposizione iniziale viene rimossa.

Per scoprire altre best practice per la gestione delle credenziali compromesse, consulta Gestire le credenziali Google Cloud compromesse.

Protezione contro l'escalation dei privilegi

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

Ad esempio, supponiamo che un malintenzionato abbia già preso piede nel tuo ambiente e ora tenti di accedere a determinate risorse Google Cloud. Potrebbero non disporre 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 protetta. Se esegue l'autenticazione utilizzando la chiave dell'account di servizio, l'utente malintenzionato può assumere l'identità dell'account di servizio. L'account di servizio potrebbe consentire all'agente malintenzionato di accedere alle risorse a cui in precedenza non aveva accesso, con conseguente riassegnazione dei suoi privilegi.

Poiché una chiave dell'account di servizio concede indirettamente l'accesso alle risorse su Google Cloud, devi considerare la chiave stessa di valore e di importanza equivalente alle risorse stesse.

Le sezioni seguenti descrivono le best practice per proteggere le chiavi degli account di servizio e ridurre il rischio di accesso non autorizzato e la conseguente escalation dei privilegi.

Evita di memorizzare le chiavi su un file system

Le chiavi degli account di servizio create utilizzando la console Google Cloud o l'gcloud CLI sono file JSON e puoi copiarle nel file system della macchina in cui sono necessarie. Tuttavia, la memorizzazione delle chiavi degli account di servizio come file su un file system può esporti a diversi rischi, tra cui:

• Alcuni file system, come NTFS, utilizzano per impostazione predefinita le autorizzazioni ereditate. A meno che non sia disabilitata, un'autorizzazione aggiunta a una cartella principale potrebbe causare inavvertitamente un aumento dell'accessibilità e della visibilità di un file della chiave per gli utenti non autorizzati.
• In un ambiente virtualizzato, gli utenti malintenzionati potrebbero essere in grado di minare la sicurezza del file system accedendo al disco virtuale sottostante.
• Le modifiche all'accesso e alle autorizzazioni del file system spesso non vengono registrate durante i controlli. 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 ottiene l'accesso.

Se possibile, evita di memorizzare le chiavi degli account di servizio in un file system. Se non puoi evitare di memorizzare le chiavi sul 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 a te. Molti rischi per la sicurezza associati alle chiavi degli account di servizio derivano dal fatto che la chiave privata è temporaneamente o permanentemente disponibile in testo chiaro e può quindi essere difficile da proteggere.

Invece di lasciare che sia Google Cloud a generare una coppia di chiavi, puoi utilizzare un modulo di sicurezza hardware (HSM) o un 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 del account di servizio.
4. Consenti all'applicazione di utilizzare l'API di firma dell'HSM o del TPM per firmare il JWT per l'autenticazione dell'account di servizio.

Un HSM o un TPM ti consente di utilizzare una chiave privata senza mai rivelarla in testo non crittografato. L'utilizzo di un HSM o TPM per gestire le chiavi degli account di servizio ti aiuta quindi a applicare controllo dell'accesso'accesso e a ridurre al contempo il rischio che le chiavi vengano copiate su altri sistemi.

Alcune piattaforme forniscono astrazioni che ti consentono di sfruttare un TPM senza dover interagire direttamente con esso. Ad esempio, Windows ti consente di gestire le chiavi protette da TPM utilizzando l'API CryptoNG in combinazione con 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.

Utilizza un archivio chiavi basato su software

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

La sicurezza di un repository delle chiavi basato su software dipende in genere dal modo in cui viene protetta la chiave master. Prima di utilizzare un magazzino chiavi basato su software, assicurati di esaminare:

• come la chiave principale viene protetta a riposo.
• come funziona la procedura di annullamento del sigillo e chi è in grado di avviarla.
• come le chiavi vengono protette dall'estrazione dalla memoria.
• come il key store è protetto da eventuali compromissioni se un utente malintenzionato ottiene accesso shell o all'hypervisor del sistema sottostante.

Non memorizzare le chiavi in Secret Manager o in altri magazzini di secret basati su cloud

Sconsigliamo di utilizzare Secret Manager di Google Cloud per memorizzare e ruotare le chiavi degli account di servizio. Questo perché, per accedere ai secret di Secret Manager, la tua applicazione ha bisogno di un'identità che Google Cloud possa riconoscere. Se la tua applicazione ha già un'identità che Google Cloud può riconoscere, può utilizzarla per autenticarsi su Google Cloud anziché utilizzare una chiave dell'account 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 ha già un'identità che questi provider cloud possono riconoscere, potrà utilizzarla per autenticarsi su Google Cloud anziché utilizzare una chiave dell'account servizio.

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

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

Le limitazioni del ruolo Editor possono essere aggirate se un progetto contiene service account. Poiché i ruoli Editor concedono l'autorizzazione per creare o caricare chiavi degli account di servizio, un malintenzionato può creare nuove chiavi per gli account di servizio esistenti e utilizzarle per eseguire la riassegnazione del proprio accesso o per consegnarle ad altri utenti in modo da ottenere l'accesso alle risorse del progetto.

Anziché utilizzare il ruolo Editor o qualsiasi altro ruolo di base, è preferibile utilizzare i ruoli predefiniti definiti in modo più specifico o creare ruoli personalizzati che conferiscono solo le autorizzazioni necessarie.

Se devi utilizzare il ruolo Editor, disattiva il caricamento delle chiavi dell'account di servizio e la creazione di chiavi utilizzando i vincoli dei criteri dell'organizzazione per contribuire ad assicurarti che il ruolo Editor non possa essere utilizzato in modo improprio per l'escalation dei privilegi.

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

La delega a livello di dominio ti consente di assumere l'identità di un utente in modo da accedere ai dati di un utente senza alcuna autorizzazione manuale da parte sua. Sebbene gli esempi che illustrano l'utilizzo della delega sull'intero dominio suggeriscano comunemente l'utilizzo delle chiavi dell'account di servizio, non è necessario utilizzare le chiavi dell'account di servizio per eseguire la delega sull'intero dominio.

Quando utilizzi la delega sull'intero dominio, evita le chiavi del account di servizio e utilizza invece l'API signJwt:

1. Autentica un account di servizio utilizzando un account di servizio collegato, Federazione delle identità per i carichi di lavoro per GKE o Federazione delle identità per i carichi di lavoro.
2. Crea un JWT e utilizza l'attributo sub per specificare l'indirizzo email dell'utente per cui richiedi l'accesso delegato.
3. Utilizza 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, eviti di dover gestire una chiave dell'account di servizio, in modo da ottenere una configurazione che può essere protetta più facilmente.

Protezione dalle minacce di divulgazione di informazioni

Evitare di divulgare informazioni riservate nei certificati X.509 caricati

Per ogni chiave dell'account di servizio, IAM ti 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 le chiavi gestite dall'utente che hai creato utilizzando la console Google Cloud o la 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 che hai caricato. Se il certificato che hai caricato conteneva attributi facoltativi (ad esempio informazioni su indirizzo o posizione incorporate nel nome comune), anche queste informazioni diventano accessibili pubblicamente. Un malintenzionato potrebbe utilizzare queste informazioni per scoprire 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 contro le 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 ha portato all'attività sospetta. La fonte di dati principale per eseguire questo tipo di analisi è in genere costituita dagli audit log.

L'analisi dei log di controllo può diventare più difficile quando sono coinvolti gli 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 lo stava utilizzando in quel momento.

Le sezioni seguenti contengono le best practice per utilizzare le chiavi degli account di servizio in modo da monitorarne l'utilizzo.

Utilizza un account di servizio dedicato per ogni applicazione

Tutti i record del log di controllo contengono un campo principalEmail che identifica il principale che ha avviato l'attività. Se condividi una chiave dell'account di servizio tra più applicazioni, può essere difficile identificare l'applicazione che ha eseguito un'attività perché i record dei log di controllo 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 ha portato a un'attività sospetta.

Utilizza una chiave dedicata per ogni computer su cui viene eseguita 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 aiutarti a restringere le potenziali fonti di attività sospette, crea singole chiavi per ogni copia dell'applicazione. In questo modo, puoi utilizzare il campo serviceAccountKeyName che molti servizi aggiungono ai record dei log di controllo per distinguere la macchina da cui ha avuto origine un'attività.

Passaggi successivi

• Scopri di più sulle best practice per l'utilizzo degli account di servizio.
• Consulta le nostre best practice per l'utilizzo degli account di servizio nelle pipeline di deployment.