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 chiavi 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 potrai usarlo per interagire 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.

Se non gestite con attenzione, le chiavi degli account di servizio possono rappresentare un rischio per la sicurezza. Dovresti scegliere un'alternativa più sicura per l'autenticazione ogni volta che è possibile. Le principali minacce relative alle chiavi dell'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 un dell'account di servizio per eseguire l'autenticazione 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, questa guida presenta le best practice per la gestione, l'utilizzo e la protezione delle chiavi degli account di servizio.

Protezione contro la fuga di credenziali

Analogamente a un nome utente e una password, le chiavi degli account di servizio sono una forma di credenziali. 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 è probabile che riesca 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 pubblici di Cloud Storage
  • Dump di dati pubblici dei servizi violati

Oltre alle posizioni pubbliche, i malintenzionati potrebbero cercare chiavi degli account di servizio in luoghi privati compromessi. Ecco alcuni esempi:

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

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 account di servizio chiavi in circolazione e quali altre misure possono aiutarti a limitare il rischio di perdita degli account di servizio.

Best practice:

Fornisci alternative alla creazione di chiavi dell'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 posizioni temporanee.
Non passare chiavi degli account di servizio tra utenti.
Non inviare le chiavi dell'account di servizio ai repository di codice sorgente.
Non incorporare le chiavi degli account di servizio nei file binari dei programmi.
Utilizza approfondimenti e metriche per identificare le chiavi degli account di servizio inutilizzate.
Ruota le chiavi dell'account di servizio per ridurre il rischio per la sicurezza causato dalle chiavi trapelate.
Utilizza le date di scadenza per consentire la scadenza automatica delle chiavi.
Utilizza i vincoli dei criteri dell'organizzazione per disattivare automaticamente le chiavi compromesse.

Fornire 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 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
  • Definisci una procedura per aiutare gli sviluppatori a decidere il tipo di il metodo di autenticazione per il caso d'uso prima di creare un nuovo servizio chiave dell'account.
  • Utilizza i vincoli dei criteri dell'organizzazione per impedire la creazione di nuove chiavi degli account di servizio e consentire eccezioni solo per per i progetti che hanno dimostrato di non poter utilizzare una piattaforma alternativa.

Utilizzare 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 un'eccezione piuttosto che la norma.

Per evitare utilizzi non necessari delle chiavi degli account di servizio, usa vincoli dei criteri dell'organizzazione:

La modifica dei vincoli dei criteri dell'organizzazione richiede orgpolicy.policy.set autorizzazione. Perché né il Proprietario (roles/owner) né l'Editor (roles/editor) che include questa autorizzazione, i vincoli possono essere efficaci anche ambienti in cui alcune entità potrebbero avere accesso come Proprietario 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 per sbaglio una copia nella cartella dei download o nell' 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 ti serve. Inoltre, sulla maggior parte dei modelli sistemi, gcloud CLI regola automaticamente le autorizzazioni dei file è 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 invece dover chiedere 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 implementazione di una chiave dell'account di servizio, c'è un rischio maggiore che restino in caselle di posta, cronologie chat o in altre posizioni. Ogni volta che un passaggio tra per gli utenti, può essere più sicuro caricare una chiave dell'account di servizio:

  1. Quando l'utente esegue il deployment dell'applicazione, crea un certificato autofirmato utilizza una coppia di chiavi RSA a 2048 bit sul computer 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.

In questo modo, eviterai di passare la chiave privata scambiano informazioni pubbliche tra gli utenti.

Non inviare le chiavi dell'account di servizio ai repository di codice sorgente

Le chiavi degli account di servizio sono credenziali e devono essere protette l'accesso. 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:

  • I malintenzionati potrebbero scansionare il codice sorgente dei repository di codice sorgente pubblici alla ricerca di chiavi trapelate.
  • 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 il servizio dell'account di servizio diversa dal codice sorgente per ridurre il rischio di la chiave al repository di origine. In molti casi, puoi ridurre ulteriormente rischio di non utilizzare le chiavi degli account di servizio durante lo sviluppo utilizzando le tue credenziali personali anziché le chiavi dell'account di servizio.

Inoltre, configura il sistema di controllo del codice sorgente in modo che rilevi invii di chiavi degli account di servizio:

Non incorporare le chiavi degli account di servizio nei file binari dei programmi

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 utente malintenzionato ha accesso al file binario, possono estrarre qualsiasi chiave dell'account di servizio incorporata nel file binario.

I programmi binari per le applicazioni lato server potrebbero essere ospitati in un artefatto o potrebbero essere copiati nelle workstation degli sviluppatori per il debug scopi. Mantenere le chiavi degli account di servizio separate dai file binari del programma è utile assicurati che un utente che può accedere al file binario non abbia implicitamente l'accesso a le 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 le credenziali utilizzando il flusso di consenso OAuth.
  • Per le applicazioni lato server, non incorporare le chiavi degli account di servizio nel file binario. Mantieni invece le chiavi separate dal file binario dell'applicazione.

Utilizza insight 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, è consigliabile disattiva le chiavi quando non ti servono più ed eliminale 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:

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

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

Sebbene sia possibile ridurre le probabilità di fuga accidentale da un servizio chiave dell'account, 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 degli account di servizio, c'è una maggiore probabilità che le chiavi divulgate non saranno più valide nel momento in cui un utente malintenzionato le ottiene.

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 chiavi 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. Invece, può 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 degli account di servizio create e scaricate IAM non ha una data di scadenza e rimane valido fino a quando non elimini che li rappresentano. L'impostazione di una data di scadenza per le chiavi dell'account di servizio può limitare il rischio per la sicurezza riducendo la durata della credenziale permanente. Tuttavia, ci sono Altri rischi associati all'impostazione di tempi di scadenza; Ad esempio, impostare una scadenza può causare errori dei carichi di lavoro quando scadono le chiavi.

Usa le date di scadenza quando hai bisogno di tempo l'accesso a un sistema che richiede una chiave dell'account di servizio. Ad esempio, utilizza la scadenza di volte quando esegui queste operazioni:

  • 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 in grado di eseguire l'autenticazione solo con le chiavi degli account di servizio

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

  • Carichi di lavoro di produzione. In fase di 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 la rotazione delle chiavi.
  • Carichi di lavoro non di produzione che richiedono 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 informazioni sulle strategie di rotazione della chiave consigliate, consulta Rotazione della chiave dell'account di servizio.

Per limitare la validità delle chiavi degli account di servizio, puoi: configurare una data di scadenza per 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 le chiavi degli account di servizio 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 disattiverà automaticamente le chiavi trapelate rilevate.

Se una chiave è disabilitata a causa della divulgazione, i seguenti campi sono aggiunti ai metadati della chiave:

  • "disable_reason": "SERVICE_ACCOUNT_KEY_DISABLE_REASON_EXPOSED": indica che la chiave è stata disabilitata perché è stata esposta.
  • "extended_status": "SERVICE_ACCOUNT_KEY_EXTENDED_STATUS_KEY_EXPOSED"": indica che la chiave è stata precedentemente esposta pubblicamente. Questo valore persiste 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 Gestione delle credenziali Google Cloud compromesse.

Protezione dall'escalation dei privilegi

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

Ad esempio, supponiamo che un malintenzionato abbia già acquisito un punto d’appoggio nel tuo ambiente. e ora tenta di accedere a determinate risorse Google Cloud. Potrebbero mancare ancora autorizzazioni per accedere a queste risorse, ma i relativi privilegi potrebbero essere sufficienti per accedere una chiave dell'account di servizio archiviata su una VM, una condivisione file o un'altra posizione protetta. Eseguendo l'autenticazione mediante la chiave dell'account di servizio, il malintenzionato può assumere l'identità dell'account di servizio. L'account di servizio potrebbe consentire all'agente malintenzionato di accedere a 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 seguenti sezioni descrivono le best practice per la protezione delle chiavi degli account di servizio e riducendo il rischio di accessi non autorizzati e conseguente escalation dei privilegi.

Best practice:

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

Evita di memorizzare le chiavi su un file system

Le chiavi degli account di servizio create utilizzando la console Google Cloud o l'interfaccia a riga di comando gcloud 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 disattivata, un'autorizzazione aggiunta a una cartella principale potrebbe causare inavvertitamente per renderlo più accessibile e visibile agli 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.
  • L'accesso al file system e le modifiche alle autorizzazioni spesso non sono sottoposti a audit log. Se le autorizzazioni dei file vengono inavvertitamente modificate e la chiave diventa visibile utenti non autorizzati, potrebbe essere difficile analizzare quando e da chi modifiche apportate.
  • I file possono essere facilmente copiati ed esfiltrati se un utente malintenzionato ottiene l'accesso.

Se possibile, evita di archiviare 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 dalla che la chiave privata sia disponibile, in modo temporaneo o permanente, in testo 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 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 service account.
  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 è quindi utile applicare in modo forzato il controllo dell'accesso riducendo al contempo il rischio che le chiavi vengano copiate e 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 Chiavi protette da TPM mediante 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.

Usa 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 principale. 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 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 i secret di Secret Manager, l'applicazione richiede un'identità Google Cloud è in grado di riconoscerlo. Se la tua applicazione ha già un'identità riconoscibile da Google Cloud, la tua applicazione può usare per l'autenticazione in Google Cloud anziché utilizzare un servizio chiave dell'account.

Lo stesso vale per altri servizi di gestione dei secret basati su cloud, come Azure Key Vault 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 della chiave dell'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, non puoi quindi estendere facilmente il tuo accesso o concedere l'accesso di altri utenti 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 il servizio le chiavi degli account, un utente malintenzionato può creare nuove chiavi per gli account di servizio esistenti utilizza queste chiavi per riassegnare il proprio accesso o per consegnarle ad altri per 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, disabilita il caricamento della chiave dell'account di servizio e la creazione delle chiavi mediante vincoli dei criteri dell'organizzazione per garantire che il ruolo Editor non possono essere utilizzati in modo illecito 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 a livello di dominio, evita le chiavi degli account di servizio e utilizza API signJwt anziché:

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

Protezione dalle minacce di divulgazione di informazioni

Best practice:

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

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 il client gcloud, 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 dalle minacce di non ripudio

Quando noti attività sospette che interessano il tuo account Google Cloud risorse e vuoi analizzarne le origini, ti servono dati che ti permettano ricostruiscono la catena di eventi che hanno 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 del 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.

Best practice:

Utilizza un account di servizio dedicato per ogni applicazione.
Utilizza una chiave dedicata per ogni macchina su cui viene eseguita un'applicazione.

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ù può essere difficile identificare quale applicazione ha eseguito un'attività perché 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 ti consente identificare l'applicazione associata a un account di servizio, che può aiutarti ricostruiscono la catena di eventi che hanno 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 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