Best practice per l'utilizzo degli account di servizio

Gli account di servizio rappresentano utenti non umani. Sono destinati a scenari in cui un carico di lavoro, ad esempio un'applicazione personalizzata, deve accedere alle risorse o eseguire azioni senza il coinvolgimento dell'utente finale.

Gli account di servizio sono diversi dai normali account utente in diversi modi:

• Non hanno una password e non possono essere utilizzati per l'accesso tramite browser.
• Vengono create e gestite come risorsa appartenente a un progetto Google Cloud. Gli utenti, invece, vengono gestiti in un account Cloud Identity o Google Workspace.
• Sono specifici di Google Cloud. Gli utenti gestiti in Cloud Identity o Google Workspace, invece, lavorano su una moltitudine di prodotti e servizi Google.
• Sono sia una risorsa sia un principale:
  • Come entità, a un account di servizio può essere concesso l'accesso alle risorse, come un bucket Cloud Storage.
  • Come risorsa, a un account di servizio è possibile accedere e, eventualmente, simularne l'identità da parte di altre entità, ad esempio un utente o un gruppo.

Sebbene gli account di servizio siano uno strumento utile, esistono diversi modi in cui un account di servizio può essere utilizzato in modo improprio:

• Escalation dei privilegi: un malintenzionato potrebbe ottenere l'accesso a risorse a cui altrimenti non avrebbe accesso simulando l'identità dell'account di servizio.
• Spoofing:un malintenzionato potrebbe utilizzare l'usurpazione di identità dell'account di servizio per nascondere la propria identità.
• Non ripudio: un utente malintenzionato potrebbe nascondere la propria identità e le proprie azioni utilizzando un account di servizio per eseguire operazioni per suo conto. In alcuni casi, potrebbe non essere possibile risalire a queste azioni tramite il malintenzionato.
• Divulgazione di informazioni:un malintenzionato potrebbe ricavare informazioni sulla tua infrastruttura, sulle tue applicazioni o sui tuoi processi dall'esistenza di determinati account di servizio.

Per contribuire a proteggere gli account di servizio, tieni presente la loro doppia natura:

• Poiché un account di servizio è un'entità, devi limitarne i privilegi per ridurre il potenziale danno che può essere causato da un account di servizio compromesso.
• Poiché un account di servizio è una risorsa, devi proteggerlo da eventuali compromissioni.

Questa guida presenta le best practice per la gestione, l'utilizzo e la protezione degli account di servizio.

Scegliere quando utilizzare gli account di servizio

Non tutti gli scenari richiedono un account di servizio per accedere ai servizi Google Cloud e molti scenari possono essere autenticati con un metodo più sicuro rispetto all'utilizzo di una chiave dell'account di servizio. Ti consigliamo di evitare di utilizzare le chiavi degli account di servizio, se possibile.

Quando accedi ai servizi Google Cloud utilizzando Google Cloud CLI, le librerie client di Cloud, gli strumenti che supportano le Credenziali predefinite dell'applicazione (ADC) come Terraform o le richieste REST, utilizza il seguente diagramma per scegliere un metodo di autenticazione:

Questo diagramma ti guida attraverso le seguenti domande:

1. Esegui il codice in un ambiente di sviluppo per un solo utente, ad esempio la tua workstation, Cloud Shell o un'interfaccia desktop virtuale?
   1. In caso affermativo, vai alla domanda 4.
   2. In caso contrario, vai alla domanda 2.
2. Esegui codice in Google Cloud?
   1. In caso affermativo, vai alla domanda 3.
   2. In caso contrario, vai alla domanda 5.
3. Esegui container in Google Kubernetes Engine o GKE Enterprise?
   1. In caso affermativo, utilizza la federazione delle identità per i carichi di lavoro per GKE per collegare gli account di servizio ai pod Kubernetes.
   2. In caso contrario, collega un account di servizio alla risorsa.

4. Il tuo caso d'uso richiede un account di servizio?

   Ad esempio, vuoi configurare l'autenticazione e l'autorizzazione in modo coerente per la tua applicazione in tutti gli ambienti.

   1. In caso contrario, esegui l'autenticazione con le credenziali utente.
   2. In caso affermativo, assumi l'identità di un account di servizio con le credenziali utente.
5. Il tuo carico di lavoro si autentica con un provider di identità esterno che supporta la federazione delle identità per i workload?
   1. In caso affermativo, configura la federazione delle identità per i carichi di lavoro per consentire alle applicazioni in esecuzione on-premise o su altri provider cloud di utilizzare un account di servizio.
   2. In caso contrario, crea una chiave dell'account di servizio.

Gestisci service account

Gli account di servizio sono diversi dai normali account utente, non solo per il modo in cui vengono utilizzati, ma anche per il modo in cui devono essere gestiti. Le sezioni seguenti forniscono le best practice per la gestione degli account di servizio.

Gestire gli account di servizio come risorse

In genere, gli account utente normali vengono gestiti in base alle procedure di joiner-mover-leaver di un'organizzazione: quando un dipendente entra a far parte dell'organizzazione, viene creato un nuovo account utente. Quando cambia reparto, il suo account utente viene aggiornato. Quando l'utente lascia l'azienda, il suo account viene sospeso o eliminato.

Al contrario, gli account di servizio non sono associati a un determinato dipendente. È meglio considerare gli account di servizio come risorse che appartengono o fanno parte di un'altra risorsa, ad esempio una determinata istanza VM o un'applicazione.

Per gestire efficacemente gli account di servizio, non considerarli singolarmente. Prendili invece in considerazione nel contesto della risorsa a cui sono associati e gestisci l'account di servizio e la relativa risorsa associata come un'unica unità: applica le stesse procedure, lo stesso ciclo di vita e la stessa diligenza all'account di servizio e alla relativa risorsa associata e utilizza gli stessi strumenti per gestirli.

Creare account di servizio a scopo singolo

La condivisione di un singolo account di servizio tra più applicazioni può complicare la gestione dell'account di servizio:

• Le applicazioni potrebbero avere cicli di vita diversi. Se un'applicazione viene ritirata, potrebbe non essere chiaro se anche l'account di servizio può essere ritirato o se è ancora necessario.
• Nel tempo, i requisiti di accesso delle applicazioni potrebbero divergere. Se le applicazioni utilizzano lo stesso account di servizio, potrebbe essere necessario concedere all'account di servizio l'accesso a un numero crescente di risorse, il che a sua volta aumenta il rischio complessivo.
• Cloud Audit Logs includono il nome dell'account di servizio che ha eseguito una modifica o ha eseguito l'accesso ai dati, ma non mostrano il nome dell'applicazione che ha utilizzato l'account di servizio. Se più applicazioni condividono un account di servizio, potresti non essere in grado di risalire all'applicazione corretta.

In particolare, alcuni servizi Google Cloud, tra cui App Engine e Compute Engine, creano un account di servizio predefinito che ha il ruolo di editor (roles/editor) nel progetto per impostazione predefinita. Quando crei una risorsa come un'istanza di una macchina virtuale (VM) di Compute Engine e non specifichi un account di servizio, la risorsa può utilizzare automaticamente l'account di servizio predefinito. Sebbene l'account di servizio predefinito ti consenta di iniziare più facilmente, è molto rischioso condividerlo con più applicazioni.

Puoi adottare diversi passaggi per evitare queste complicazioni:

• Crea account di servizio dedicati per ogni applicazione ed evita di utilizzare account di servizio predefiniti.
• Non utilizzare le concessioni di ruoli automatiche per gli account di servizio predefiniti.
• Utilizza gli strumenti di Google per comprendere l'utilizzo degli account di servizio, che possono aiutarti a monitorare l'utilizzo e a impedire la condivisione degli account di servizio su più applicazioni.

Segui una convenzione di denominazione e documentazione

Per facilitare il monitoraggio dell'associazione tra un servizio e un'applicazione o una risorsa, segui una convenzione di denominazione quando crei nuovi account di servizio:

• Aggiungi un prefisso all'indirizzo email dell'account di servizio che identifichi il modo in cui viene utilizzato l'account. Ad esempio:
  • vm- per gli account di servizio collegati a un'istanza VM.
  • wlifgke- per gli account di servizio utilizzati da Workload Identity Federation for GKE.
  • wlif- per gli account di servizio utilizzati dalla federazione delle identità per i carichi di lavoro.
  • onprem- per gli account di servizio utilizzati dalle applicazioni on-premise.
• Incorpora il nome dell'applicazione nell'indirizzo email dell'account di servizio, ad esempio: vm-travelexpenses@ se la VM esegue un'applicazione per le spese di viaggio.
• Utilizza il campo della descrizione per aggiungere una persona di contatto, link alla documentazione pertinente o altre note.

Non incorporare termini o informazioni sensibili nell'indirizzo email di un account di servizio.

Identificare e disattivare gli account di servizio inutilizzati

Quando un account di servizio non viene più utilizzato, disattivalo. Se disattivi gli account di servizio inutilizzati, riduci il rischio che vengano utilizzati in modo improprio da parte di malintenzionati per movimenti laterali o per l'escalation dei privilegi.

Per gli account di servizio a scopo singolo associati a una determinata risorsa, ad esempio un'istanza VM, disattiva l'account di servizio non appena la risorsa associata viene disattivata o eliminata.

Per gli account di servizio utilizzati per più scopi o condivisi tra più risorse, può essere più difficile identificare se l'account di servizio è ancora in uso. In questi casi, puoi utilizzare Activity Analyzer per visualizzare le attività di autenticazione più recenti per i tuoi service account.

Disattivare gli account di servizio inutilizzati prima di eliminarli

Se elimini un account di servizio e poi ne crei uno nuovo con lo stesso nome, al nuovo account di servizio viene assegnata un'identità diversa. Di conseguenza, nessuna delle associazioni IAM originali si applica al nuovo account di servizio. Al contrario, se disattivi e riattivi un account di servizio, tutte le associazioni IAM rimangono invariate.

Per evitare di perdere inavvertitamente le associazioni IAM, è meglio non eliminare immediatamente gli account di servizio. Disattiva invece un account di servizio se non è più necessario ed eliminalo solo dopo un determinato periodo di tempo.

Non eliminare mai gli account di servizio predefiniti, come quelli di App Engine o Compute Engine. Questi account di servizio non possono essere ricreati senza disattivare e riattivare la rispettiva API, il che potrebbe interrompere il deployment esistente. Se non utilizzi gli account di servizio predefiniti, disabilitali.

Limitare i privilegi dell'account di servizio

Gli account di servizio sono entità e a questi può essere concesso l'accesso a una risorsa come un account utente normale. Tuttavia, gli account di servizio hanno spesso accesso a più risorse rispetto a un utente normale. Inoltre, man mano che aggiungi funzionalità alle tue applicazioni, i relativi account di servizio tendono ad acquisire sempre più accessi nel tempo. Potresti anche dimenticare di revocare l'accesso non più necessario.

Non utilizzare le concessioni di ruoli automatiche per gli account di servizio predefiniti

Alcuni servizi Google Cloud creano account servizio predefinite la prima volta che attivi la relativa API in un progetto Google Cloud. A seconda della configurazione dei criteri dell'organizzazione, a questi account di servizio potrebbe essere concesso automaticamente il ruolo Editor (roles/editor) nel progetto Google Cloud, che consente loro di leggere e modificare tutte le risorse del progetto. Il ruolo viene concesso per comodità, ma non è essenziale per il funzionamento dei servizi: per accedere alle risorse nel progetto Google Cloud, i servizi Google Cloud utilizzano gli agenti di servizio, non gli account di servizio predefiniti.

Per impedire che agli account di servizio predefiniti venga concesso automaticamente il ruolo Editor, attiva il vincolo Disabilita l'assegnazione automatica di diritti IAM ai service account predefiniti (constraints/iam.automaticIamGrantsForDefaultServiceAccounts) per la tua organizzazione. Per applicare il vincolo a più progetti Google Cloud, configuralo nella cartella o nel nodo dell'organizzazione. L'applicazione della limitazione non rimuove il ruolo Editor dagli account di servizio predefiniti esistenti.

Se applichi questo vincolo, gli account di servizio predefiniti nei nuovi progetti non avranno accesso alle tue risorse Google Cloud. Devi concedere i ruoli appropriati agli account di servizio predefiniti in modo che possano accedere alle tue risorse.

Non fare affidamento sugli ambiti di accesso quando colleghi un account di servizio a un'istanza VM

Quando colleghi un account di servizio a un'istanza VM, puoi specificare uno o più ambiti di accesso. Gli ambiti di accesso ti consentono di limitare i servizi a cui può accedere la VM. Le limitazioni vengono applicate oltre ai criteri consentiti.

Gli ambiti di accesso sono granulari. Ad esempio, utilizzando l'ambitohttps://www.googleapis.com/auth/devstorage.read_only, puoi limitare l'accesso alle operazioni di sola lettura di Cloud Storage, ma non puoi limitare l'accesso a bucket specifici. Pertanto, gli ambiti di accesso non sono un'alternativa valida ai criteri di autorizzazione granulari.

Anziché fare affidamento sugli ambiti di accesso, crea un account di servizio dedicato e utilizza criteri di autorizzazione granulari per limitare le risorse a cui l'account di servizio ha accesso.

Evita di utilizzare i gruppi per concedere agli account di servizio l'accesso alle risorse

In un'organizzazione è normale che più dipendenti esercitino funzioni lavorative simili o sovrapposte e, di conseguenza, richiedano un accesso simile alle risorse. Utilizzando i gruppi, puoi sfruttare queste somiglianze per ridurre il sovraccarico amministrativo.

Gli account di servizio sono destinati all'utilizzo da parte delle applicazioni. È raro che più applicazioni svolgano la stessa funzione e abbiano quindi requisiti di accesso simili o identici. Le applicazioni, invece, tendono ad essere univoche e le risorse a cui richiedono l'accesso sono in genere diverse per ogni applicazione.

L'utilizzo dei gruppi per concedere agli account di servizio l'accesso alle risorse può portare a risultati indesiderati:

• Una proliferazione di gruppi, con ogni gruppo contenente solo uno o pochi account di servizio.
• Aumento progressivo delle autorizzazioni: nel tempo, a un gruppo viene concesso l'accesso a un numero crescente di risorse, anche se ogni membro del gruppo richiede l'accesso solo a un sottoinsieme di risorse.

A meno che lo scopo di un gruppo non sia definito in modo limitato, è meglio evitare di utilizzare i gruppi. Concedi invece direttamente ai service account l'accesso alle risorse di cui hanno bisogno.

Evita di utilizzare la delega a livello di dominio

La delega a livello di dominio consente a un account di servizio di rubare l'identità di qualsiasi utente in un account Cloud Identity o Google Workspace. La delega a livello di dominio consente a un account di servizio di eseguire determinate attività amministrative in Google Workspace e Cloud Identity oppure di accedere alle API di Google che non supportano gli account di servizio dall'esterno di Google Cloud.

La delega a livello di dominio non limita un account di servizio a rubare l'identità di un determinato utente, ma gli consente di rubare l'identità di qualsiasi utente in un account Cloud Identity o Google Workspace, inclusi i super amministratori. Consentire a un account di servizio di utilizzare la delega sull'intero dominio può quindi rendere l'account di servizio un obiettivo interessante per gli attacchi di escalation dei privilegi.

Evita di utilizzare la delega a livello di dominio se puoi svolgere la tua attività direttamente con un account di servizio o utilizzando il flusso di consenso OAuth.

Se non puoi evitare di utilizzare la delega a livello di dominio, limita l'insieme di ambiti OAuth che l'account di servizio può utilizzare. Anche se gli ambiti OAuth non limitano gli utenti che l'account di servizio può rappresentare tramite simulazione dell'identità, limitano i tipi di dati utente a cui l'account di servizio può accedere.

Non utilizzare gli account di servizio per accedere ai dati utente senza il consenso dell'utente

Un'applicazione potrebbe richiedere l'accesso a dati utente sensibili o personali. Esempi di questi dati includono la posta in arrivo o il calendario di un utente, i documenti archiviati su Google Drive o un set di dati BigQuery contenente dati sensibili.

L'utilizzo di un account di servizio per accedere ai dati utente può essere appropriato se l'applicazione svolge attività in background non supervisionate, come l'indicizzazione o le scansioni di prevenzione della perdita di dati (DLP), o se l'utente finale non ha eseguito l'autenticazione con un'identità Google. In tutti gli altri scenari in cui un'applicazione agisce per conto di un utente finale, è meglio evitare di utilizzare gli account di servizio.

Anziché utilizzare un account di servizio per accedere ai dati utente (eventualmente eseguendo una transizione del principale), utilizza il flusso di consenso OAuth per richiedere il consenso dell'utente finale. Poi lascia che l'applicazione agisca con l'identità dell'utente finale. Se utilizzi OAuth anziché un account di servizio, contribuisci a garantire che:

• Gli utenti possono esaminare le risorse a cui stanno per concedere l'accesso all'applicazione e possono esprimere o negare esplicitamente il proprio consenso.
• Gli utenti possono revocare il consenso in qualsiasi momento nella pagina Account personale.
• Non è necessario un account di servizio con accesso illimitato a tutti i dati dell'utente.

Se consenti all'applicazione di utilizzare le credenziali dell'utente finale, rimandi i controlli delle autorizzazioni alle API Google Cloud. Questo approccio limita il rischio di esporre accidentalmente dati a cui l'utente non dovrebbe avere accesso a causa di un errore di programmazione (problema del sostituto confuso).

Utilizzare l'API Credenziali IAM per l'elevazione temporanea dei privilegi

Alcune applicazioni richiedono l'accesso a determinate risorse solo in momenti specifici o in determinate circostanze. Ad esempio:

• Un'applicazione potrebbe richiedere l'accesso ai dati di configurazione durante l'avvio, ma potrebbe non richiederlo una volta inizializzata.
• Un'applicazione di supervisione potrebbe avviare periodicamente job in background in cui ogni job ha requisiti di accesso diversi.

In questi scenari, l'utilizzo di un singolo account di servizio e la concessione dell'accesso a tutte le risorse viola il principio del privilegio minimo: in qualsiasi momento, l'applicazione potrebbe avere accesso a più risorse di quelle di cui ha effettivamente bisogno.

Per assicurarti che le diverse parti della tua applicazione abbiano accesso solo alle risorse di cui hanno bisogno, utilizza l'API Credentials IAM per l'elevazione temporanea dei privilegi:

• Crea account di servizio dedicati per ogni parte dell'applicazione o del caso d'uso e concedi all'account di servizio l'accesso solo alle risorse necessarie.
• Crea un altro account di servizio che agisce come supervisore. Concedi all'account di servizio supervisore il ruolo Creatore token account di servizio sugli altri account di servizio in modo che possa richiedere token di accesso di breve durata per questi account di servizio.
• Suddividi l'applicazione in modo che una parte dell'applicazione agisca da broker di token e consenti solo a questa parte dell'applicazione di utilizzare gli account di servizio di supervisione.
• Utilizza il broker di token per emettere account di servizio di breve durata per le altre parti dell'applicazione.

Per assistenza sulla creazione di credenziali di breve durata, consulta Creare credenziali di breve durata per un account di servizio.

Utilizzare i confini per l'accesso con credenziali per ridurre l'ambito dei token di accesso

I token di accesso di Google sono token bearer, il che significa che il loro utilizzo non è legato a nessuna applicazione specifica. Se la tua applicazione passa un token di accesso a un'altra applicazione, quest'ultima può utilizzare il token nello stesso modo in cui lo fa la tua applicazione. Analogamente, se un token di accesso viene divulgato a un malintenzionato, quest'ultimo può utilizzarlo per ottenere l'accesso.

Poiché i token di accesso sono token bearer, devi proteggerli da fughe di dati o da visibilità a parti non autorizzate. Puoi limitare i potenziali danni causati da un token di accesso compromesso limitando le risorse a cui concede l'accesso. Questo processo è chiamato riduzione del livello.

Utilizza i confini di accesso alle credenziali per limitare l'ambito dei token di accesso ogni volta che ne passi uno a un'altra applicazione o a un altro componente della tua applicazione. Imposta il confine di accesso in modo che il token conceda l'accesso sufficiente alle risorse richieste, ma non di più.

Utilizzare i suggerimenti sui ruoli per identificare le autorizzazioni inutilizzate

Quando esegui il deployment di un'applicazione per la prima volta, potresti non sapere con certezza quali ruoli e autorizzazioni siano effettivamente necessari. Di conseguenza, potresti concedere all'account di servizio dell'applicazione più autorizzazioni di quelle richieste.

Analogamente, i requisiti di accesso di un'applicazione potrebbero evolversi nel tempo e alcuni dei ruoli e delle autorizzazioni concessi inizialmente potrebbero non essere necessari.

Utilizza i suggerimenti sui ruoli per identificare le autorizzazioni effettivamente utilizzate da un'applicazione e quelle che potrebbero essere inutilizzate. Modifica i criteri di autorizzazione delle risorse interessate per contribuire a garantire che a un'applicazione non venga concesso più accesso di quanto effettivamente necessario.

Utilizzare le informazioni sul movimento laterale per limitare il movimento laterale

Il movimento laterale si verifica quando un account di servizio in un progetto è autorizzato a simulare l'identità di un account di servizio in un altro progetto. Ad esempio, un account di servizio potrebbe essere stato creato nel progetto A, ma avere autorizzazioni per simulare l'identità di un account di servizio nel progetto B.

Queste autorizzazioni possono comportare una catena di furti d'identità nei progetti che consente alle entità di accedere in modo indesiderato alle risorse. Ad esempio, un'entità potrebbe assumere il ruolo di un account di servizio nel progetto A e poi utilizzare quell'account di servizio per assumere il ruolo di un account di servizio nel progetto B. Se l'account di servizio nel progetto B ha l'autorizzazione per simulare l'identità di altri account di servizio in altri progetti della tua organizzazione, il principale potrebbe continuare a utilizzare la rappresentazione dell'account di servizio per spostarsi da un progetto all'altro, acquisendo le autorizzazioni man mano che procede.

Il Recommender fornisce approfondimenti sul movimento laterale per aiutarti ad attenuare il problema. Le informazioni sui movimenti laterali identificano i ruoli che consentono a un account di servizio in un progetto di simulare l'identità di un account di servizio in un altro progetto. Per scoprire come visualizzare e gestire direttamente le informazioni sul movimento laterale, consulta Gestire le informazioni sul movimento laterale.

Alcuni approfondimenti sui movimenti laterali sono associati ai consigli sui ruoli. Puoi applicare questi consigli per ridurre il movimento laterale nei tuoi progetti. Per scoprire come, consulta l'articolo Esaminare e applicare i consigli.

Proteggiti dalle minacce di escalation dei privilegi

Un account di servizio a cui non sono stati concessi ruoli, che non ha accesso a nessuna risorsa e non è associato a regole firewall è in genere di scarso valore. Dopo aver concesso a un account di servizio l'accesso alle risorse, il valore dell'account di servizio aumenta: diventa più utile per te, ma diventa anche un target più interessante per gli attacchi di escalation dei privilegi.

Ad esempio, considera un account di servizio che ha accesso completo a un bucket Cloud Storage contenente informazioni sensibili. In questa situazione, l'account di servizio è praticamente importante quanto il bucket Cloud Storage stesso: anziché provare ad accedere direttamente al bucket, un malintenzionato potrebbe tentare di prendere il controllo dell'account di servizio. Se il tentativo va a buon fine, l'autore della violazione può eseguire la riassegnazione dei propri privilegi rubando l'identità dell'account di servizio, ottenendo così l'accesso alle informazioni sensibili nel bucket.

Le tecniche di riassegnazione dei privilegi che coinvolgono gli account di servizio rientrano in genere in queste categorie:

• Autenticazione come account di servizio: potresti concedere inavvertitamente a un utente l'autorizzazione per rubare l'identità di un account di servizio o per creare una chiave account di servizio per un account di servizio. Se l'account di servizio ha più privilegi dell'utente stesso, l'utente può autenticarsi come account di servizio per eseguire la riassegnazione dei suoi privilegi e ottenere l'accesso alle risorse a cui altrimenti non potrebbe accedere.

• Utilizzo di risorse con un account di servizio associato: se un utente ha l'autorizzazione per accedere e modificare pipeline CI/CD, istanze VM o altri sistemi di automazione con account di servizio associati, potrebbe essere in grado di eseguire azioni utilizzando gli account di servizio associati di queste risorse. Di conseguenza, anche se non dispone dell'autorizzazione per simulare l'identità dell'account di servizio, potrebbe comunque essere in grado di utilizzare le autorizzazioni dell'account di servizio per eseguire azioni che non potrebbe eseguire autonomamente.

  Ad esempio, se un utente dispone dell'accesso SSH a un'istanza VM di Compute Engine, può eseguire codice sull'istanza per accedere a qualsiasi risorsa a cui può accedere l'account di servizio associato all'istanza.

• Modifiche ai criteri di autorizzazione, ai gruppi o ai ruoli personalizzati: un utente che non ha accesso a un account di servizio con privilegi potrebbe comunque disporre dell'autorizzazione per modificare i criteri di autorizzazione dell'account di servizio, del progetto Google Cloud o della cartella contenente. L'utente potrebbe quindi estendere uno di questi criteri di autorizzazione per concedersi l'autorizzazione ad autenticarsi (direttamente o indirettamente) come account di servizio.

Le seguenti sezioni forniscono best practice per proteggere gli account di servizio dalle minacce di riassegnazione dei privilegi.

Evita di consentire agli utenti di autenticarsi come account di servizio con più privilegi rispetto agli utenti stessi

Impersonando un account di servizio, un utente ottiene l'accesso ad alcune o a tutte le risorse a cui può accedere l'account di servizio. Se l'account di servizio ha un accesso più approfondito rispetto all'utente, ha effettivamente più privilegi dell'utente.

Concedere a un utente l'autorizzazione a rubare l'identità di un account di servizio con privilegi più elevati può essere un modo per consentire deliberatamente agli utenti di elevare temporaneamente i propri privilegi, in modo simile all'utilizzo dello strumento sudo su Linux o all'utilizzo dell'elevazione del processo su Windows. A meno che non si tratti di uno scenario in cui è necessaria un'elevazione temporanea dei privilegi, è meglio evitare di consentire agli utenti di rubare l'identità di un account di servizio con privilegi maggiori.

Gli utenti possono anche ottenere indirettamente le autorizzazioni di un account di servizio agganciandolo a una risorsa ed eseguendo codice su quella risorsa. L'esecuzione del codice in questo modo non è una simulazione dell'identità dell'account di servizio perché coinvolge solo un'identità autenticata (l'account di servizio). Tuttavia, può concedere a un utente un accesso che altrimenti non avrebbe.

Le autorizzazioni che consentono a un utente di rubare l'identità di un account di servizio o di collegare un account di servizio a una risorsa includono:

• iam.serviceAccounts.getAccessToken
• iam.serviceAccounts.getOpenIdToken
• iam.serviceAccounts.actAs
• iam.serviceAccounts.implicitDelegation
• iam.serviceAccounts.signBlob
• iam.serviceAccounts.signJwt
• iam.serviceAccountKeys.create
• deploymentmanager.deployments.create
• cloudbuild.builds.create

I ruoli che contengono alcune di queste autorizzazioni includono (a titolo esemplificativo):

• Proprietario (roles/owner)
• Editor (roles/editor)
• Utente dell'account di servizio (roles/iam.serviceAccountUser)
• Creatore token account di servizio (roles/iam.serviceAccountTokenCreator)
• Amministratore chiavi account di servizio (roles/iam.serviceAccountKeyAdmin)
• Amministratore account di servizio (roles/iam.serviceAccountAdmin)
• Utente Workload Identity (roles/iam.workloadIdentityUser)
• Editor di Deployment Manager (roles/deploymentmanager.editor)
• Editor Cloud Build (roles/cloudbuild.builds.editor)

Prima di assegnare uno di questi ruoli a un utente, chiediti:

• A quali risorse all'interno e all'esterno dell'attuale progetto Google Cloud potrebbe accedere l'utente fingendosi l'account di servizio?
• Questo livello di accesso è giustificato?
• Sono state implementate protezioni sufficienti che controllano le circostanze in cui l'utente può simulare l'identità dell'account di servizio?

Non assegnare il ruolo se non puoi rispondere a tutte le domande. Valuta invece di assegnare all'utente un account di servizio diverso e con meno privilegi.

Evita di consentire agli utenti di modificare i criteri di autorizzazione degli account di servizio con più privilegi

Gli utenti che possono utilizzare o rubare l'identità di un account di servizio vengono acquisiti dal criterio di autorizzazione dell'account di servizio. Il criterio di autorizzazione può essere modificato o esteso dagli utenti che dispongono dell'autorizzazione iam.serviceAccounts.setIamPolicy per il particolarmente account di servizio. I ruoli che contengono questa autorizzazione includono:

• Proprietario (roles/owner)
• Amministratore sicurezza (roles/iam.securityAdmin)
• Amministratore account di servizio (roles/iam.serviceAccountAdmin)

I ruoli che includono l'autorizzazione iam.serviceAccounts.setIamPolicy danno a un utente il controllo completo su un account di servizio:

• L'utente può concedersi l'autorizzazione per simulare l'identità dell'account di servizio, in modo da poter accedere alle stesse risorse dell'account di servizio.
• L'utente può concedere ad altri utenti lo stesso livello di accesso o un livello simile all'account di servizio.

Prima di assegnare uno di questi ruoli a un utente, chiedi a te stesso a quali risorse all'interno e all'esterno dell'attuale progetto Google Cloud l'utente potrebbe ottenere l'accesso fingendo di essere l'account di servizio. Non consentire a un utente di modificare il criterio di autorizzazione di un account di servizio se l'account di servizio ha più privilegi dell'utente.

Non consentire agli utenti di creare o caricare chiavi dell'account di servizio

Le chiavi dell'account di servizio consentono alle applicazioni o agli utenti di autenticarsi come account di servizio. A differenza di altre forme di sostituzione dell'identità dell'account di servizio, l'utilizzo di una chiave dell'account di servizio non richiede alcuna forma di autenticazione precedente: chiunque possieda una chiave dell'account di servizio può utilizzarla.

L'effetto netto dell'utilizzo di una chiave dell'account di servizio per l'autenticazione è simile all'effetto dell'impersonificazione dell'account di servizio. Se un utente ha accesso a una chiave account di servizio o se gli viene concessa l'autorizzazione per creare una nuova chiave account di servizio, l'utente può autenticarsi come account di servizio e accedere a tutte le risorse a cui l'account di servizio può accedere.

La creazione o il caricamento di una chiave dell'account di servizio richiede l'autorizzazione iam.serviceAccountKeys.create, inclusa nei ruoli Amministratore chiavi account di servizio (roles/iam.serviceAccountKeyAdmin) e Editor (roles/editor).

Prima di assegnare a un utente un ruolo che include l'autorizzazione iam.serviceAccountKeys.create, chiediti a quali risorse all'interno e all'esterno del progetto Google Cloud corrente l'utente potrebbe ottenere l'accesso rubando l'identità dell'account di servizio. Non consentire a un utente di creare chiavi account di servizio per account di servizio che hanno più privilegi rispetto a lui.

Se il progetto Google Cloud non richiede chiavi dell'account di servizio, applica i vincoli delle norme dell'organizzazione Disattiva creazione chiavi account di servizio e Disattiva caricamento chiavi account di servizio al progetto Google Cloud o alla cartella contenente. Questi vincoli impediscono a tutti gli utenti di creare e caricare chiavi dell'account di servizio, incluse quelle con autorizzazione iam.serviceAccountKeys.create su un account di servizio.

Non concedere l'accesso agli account di servizio a livello di progetto o cartella Google Cloud

Gli account di servizio sono risorse e fanno parte della gerarchia delle risorse. Di conseguenza, puoi gestire l'accesso agli account di servizio a uno dei seguenti livelli:

• Il singolo account di servizio
• Il progetto Google Cloud contenitore
• Una cartella nell'albero del progetto Google Cloud
• Il nodo organizzazione

La gestione dell'accesso a livello di progetto Google Cloud o a un livello superiore della gerarchia delle risorse può contribuire a ridurre il sovraccarico amministrativo, ma può anche portare a una concessione eccessiva dei privilegi. Ad esempio, se concedi a un utente il ruolo Creatore token account di servizio in un progetto Google Cloud, l'utente può rubare l'identità di qualsiasi account di servizio nel progetto Google Cloud. La possibilità di rubare l'identità di qualsiasi account di servizio implica che l'utente possa potenzialmente ottenere l'accesso a tutte le risorse a cui possono accedere questi account di servizio, incluse le risorse esterne al progetto Google Cloud.

Per evitare questa concessione eccessiva, non gestire l'accesso agli account di servizio a livello di progetto o cartella Google Cloud. Gestisci invece l'accesso singolarmente per ogni account di servizio.

Non eseguire codice da origini meno protette su risorse di calcolo a cui è associato un account di servizio con privilegi

Quando colleghi un account di servizio a una risorsa di calcolo, ad esempio un'istanza VM o un'applicazione Cloud Run, i processi in esecuzione su quella risorsa possono utilizzare il server di metadati per richiedere token di accesso e token ID. Questi token consentono al processo di autenticarsi come account di servizio e di accedere alle risorse per suo conto.

Per impostazione predefinita, l'accesso al server dei metadati non è limitato a processi o utenti specifici. Tuttavia, qualsiasi codice eseguito nella risorsa di calcolo può accedere al server di metadati e ottenere un token di accesso. Questo codice potrebbe includere:

• Il codice della tua applicazione.
• Codice inviato dagli utenti finali, se la tua applicazione consente la valutazione di script lato server.
• Codice letto da un repository di origine remoto, se la risorsa di calcolo fa parte di un sistema CI/CD.
• Script di avvio e arresto pubblicati da un bucket Cloud Storage.
• Criteri guest distribuiti da VM Manager.

Se il codice viene inviato dagli utenti o viene letto da una posizione di archiviazione remota, devi assicurarti che sia attendibile e che le posizioni di archiviazione remota siano almeno altrettanto protette del account di servizio allegato. Se una posizione di archiviazione remota è meno protetta rispetto all'account di servizio, un malintenzionato potrebbe essere in grado di eseguire la riassegnazione dei propri privilegi. Potrebbero farlo iniettando codice dannoso che utilizza i privilegi dell'account di servizio in quella posizione.

Limita l'accesso alla shell alle VM con un account di servizio privilegiato associato

Alcune risorse di calcolo supportano l'accesso interattivo e consentono agli utenti di ottenere accesso shell al sistema. Ad esempio:

• Compute Engine ti consente di utilizzare SSH o RDP per accedere a un'istanza VM.
• Google Kubernetes Engine ti consente di utilizzare kubectl exec per eseguire un comando o avviare una shell in un contenitore Kubernetes.

Se a un'istanza VM è associato un account di servizio con privilegi, qualsiasi utente con accesso shell al sistema può autenticarsi e accedere alle risorse come account di servizio. Per impedire agli utenti di abusare di questa funzionalità per eseguire la riassegnazione dei propri privilegi, devi assicurarti che l'accesso alla shell sia protetto almeno quanto il account di servizio collegato.

Per le istanze Linux, puoi imporre che l'accesso SSH sia più restrittivo rispetto all'accesso all'account di servizio collegato utilizzando l'accesso al sistema operativo: per connettersi a un'istanza VM con l'accesso al sistema operativo abilitato, un utente deve non solo avere l'autorizzazione per utilizzare l'accesso al sistema operativo, ma deve anche disporre dell'autorizzazione iam.serviceAccounts.actAs per l'account di servizio collegato.

Lo stesso livello di controllo dell'accesso dell'accesso non si applica alle istanze VM che utilizzano chiavi basate su metadati o alle istanze Windows: la pubblicazione di una chiave SSH nei metadati o la richiesta di credenziali Windows richiede l'accesso ai metadati dell'istanza VM e all'autorizzazione iam.serviceAccounts.actAs nell'account di servizio collegato. Tuttavia, dopo che la chiave SSH è stata pubblicata o le credenziali di Windows sono state ottenute, gli accessi successivi non sono soggetti a ulteriori controlli delle autorizzazioni IAM.

Analogamente, se un'istanza VM utilizza un modulo di autenticazione plug-in Linux personalizzato per l'autenticazione o è membro di un dominio Active Directory, è possibile che gli utenti che altrimenti non disporrebbero dell'autorizzazione per autenticarsi come account di servizio possano accedere. Per ulteriori informazioni, consulta le best practice per l'esecuzione di Active Directory su Google Cloud.

In particolare, per le istanze VM che non utilizzano l'OS Login, ti consigliamo di limitare l'accesso alla shell tramite Identity-Aware Proxy. Concedi il ruolo IAP-Secured Tunnel User (roles/iap.tunnelResourceAccessor) solo agli utenti che devono poter eseguire l'autenticazione come account di servizio associato all'istanza VM.

Limita l'accesso al server dei metadati a utenti e processi selezionati

Quando colleghi un account di servizio a un'istanza VM, i workload di cui è stato eseguito il deployment sulla VM possono accedere al server metadati per richiedere token per gli account di servizio. Per impostazione predefinita, l'accesso al server di metadati non è limitato a un processo o a un utente specifico della VM: anche i processi in esecuzione come utente con privilegi ridotti, ad esempio nobody su Linux o LocalService su Windows, hanno accesso completo al server di metadati e possono ottenere token per l'account di servizio.

Per limitare l'accesso al server di metadati a utenti specifici, configura il firewall dell'host del sistema operativo guest in modo da consentire solo a questi utenti di aprire connessioni in uscita al server di metadati.

Su Linux, puoi utilizzare le opzioni --uid-owner e --gid-owner per configurare una regola iptables che si applica solo a utenti o gruppi specifici. Su Windows, il comando Set-NetFirewallSecurityFilter consente di personalizzare una regola del firewall in modo che venga applicata a utenti o gruppi selezionati.

Proteggere dalle minacce di divulgazione di informazioni

Evita di divulgare informazioni riservate negli indirizzi email dei account di servizio

Per concedere a un account di servizio l'accesso a una risorsa in un altro progetto Google Cloud, puoi aggiungere una associazione di ruoli al criterio di autorizzazione della risorsa. Come la risorsa stessa, il criterio di autorizzazione fa parte dell'altro progetto Google Cloud e la sua visibilità è controllata anche da questo altro progetto Google Cloud.

La visualizzazione dei criteri di autorizzazione in genere non è considerata un'operazione privilegiata. Molti ruoli includono l'autorizzazione *.getIamPolicy richiesta, incluso il ruolo di base Visualizzatore.

Un utente che può visualizzare un criterio di autorizzazione può anche vedere gli indirizzi email dei principali a cui è stato concesso l'accesso alla risorsa. Nel caso degli account di servizio, gli indirizzi email possono fornire indizi ai malintenzionati.

Ad esempio, un criterio di autorizzazione potrebbe includere un'associazione per un account di servizio con l'indirizzo email jenkins@deployment-project-123.iam.gserviceaccount.com. Per un malintenzionato, questo indirizzo email non solo rivela che esiste un progetto Google Cloud con ID deployment-project-123, ma anche che il progetto Google Cloud esegue un server Jenkins. Se scegli un nome più generico come deployer@deployment-project-123.iam.gserviceaccount.com, eviti di divulgare informazioni sul tipo di software in esecuzione in deployment-project-123.

Se concedi a un account di servizio l'accesso alle risorse di un progetto Google Cloud con un accesso meno controllato (ad esempio una sandbox o un progetto Google Cloud di sviluppo), assicurati che l'indirizzo email dell'account di servizio non divulghi alcuna informazione. In particolare, non divulgare informazioni riservate o che potrebbero fornire indizi agli aggressori.

Proteggiti dalle minacce di non ripudio

Ogni volta che noti attività sospette che interessano una delle tue risorse su Google Cloud, Cloud Audit Logs è un'importante fonte di informazioni per scoprire quando si è verificata l'attività e quali utenti sono stati coinvolti.

Ogni volta che Cloud Audit Logs indica che l'attività è stata eseguita da un account di servizio, quelle informazioni da sole potrebbero non essere sufficienti per ricostruire la catena completa di eventi: devi anche essere in grado di scoprire quale utente o applicazione ha causato l'attività dell'account di servizio.

Questa sezione contiene le best practice che possono aiutarti a mantenere una traccia di controllo non ripudiabile.

Utilizza le chiavi dei account di servizio solo quando non esiste un'alternativa valida

Se non puoi utilizzare metodi di autenticazione più sicuri, potrebbe essere necessario creare una chiave dell'account di servizio per l'applicazione. Tuttavia, l'autenticazione con una chiave dell'account di servizio introduce una minaccia di non ripudio. Cloud Audit Logs crea un log quando un account di servizio modifica una risorsa, ma se l'account di servizio viene autenticato con una chiave dell'account di servizio, non esiste un modo affidabile per sapere chi ha utilizzato la chiave. Al contrario, l'autenticazione come account di servizio tramite l'assunzione dell'identità dell'account di servizio con le credenziali utente registra l'entità che ha agito come account di servizio.

Ti consigliamo di impedire la creazione di chiavi del account di servizio applicando il vincolo della policy dell'organizzazione Disattiva la creazione di chiavi account di servizio account al progetto Google Cloud o alla cartella contenente. Se devi utilizzare chiavi degli account di servizio per uno scenario che non può essere affrontato con nessuna delle alternative consigliate, concedi un'eccezione al vincolo delle norme, il più limitato possibile, e consulta le best practice per la gestione delle chiavi degli account di servizio.

Attivare i log di accesso ai dati per le API IAM

Per aiutarti a identificare e comprendere gli scenari di furto d'identità degli account di servizio, servizi come Compute Engine includono una sezione serviceAccountDelegationInfo in Cloud Audit Logs. Questa sezione indica se l'account di servizio è stato impersonato e da quale utente.

Non tutti i servizi includono i dettagli di appropriazione d'identità nei propri Cloud Audit Logs. Per registrare tutti gli eventi di furto d'identità, devi anche abilitare i log di accesso ai dati per le seguenti API:

• API Identity and Access Management (IAM) in tutti i progetti Google Cloud che contengono account di servizio
• API Security Token Service in tutti i progetti Google Cloud che contengono pool di identità di carico di lavoro

Se attivi questi log, ti assicuri che venga aggiunta una voce a Cloud Audit Logs ogni volta che un utente richiede un token di accesso o un token ID per un account di servizio.

Assicurati che la cronologia CI/CD possa essere correlata a Cloud Audit Logs

Gli account di servizio sono comunemente utilizzati dai sistemi CI/CD per eseguire i deployment dopo che una modifica del codice è stata verificata e approvata per il deployment. In genere, i sistemi CI/CD mantengono una cronologia degli eventi che portano a un deployment. Questa cronologia potrebbe includere gli ID delle revisioni del codice, dei commit e delle esecuzioni della pipeline corrispondenti, nonché informazioni su chi ha approvato il deployment.

Se un deployment modifica risorse su Google Cloud, queste modifiche vengono monitorate nei log di controllo di Cloud delle rispettive risorse. Cloud Audit Logs contengono informazioni sull'account utente o di servizio che ha avviato la modifica. Tuttavia, in un deployment attivato da un sistema CI/CD, spesso l'account di servizio stesso non è sufficiente per ricostruire l'intera catena di eventi che ha portato alla modifica.

Per stabilire una traccia di controllo coerente nel sistema CI/CD e in Google Cloud, devi assicurarti che i record di Cloud Audit Logs possano essere correlati agli eventi nella cronologia del sistema CI/CD. Se riscontri un evento imprevisto in Cloud Audit Logs, puoi utilizzare questa correlazione per determinare se la modifica è stata effettivamente eseguita dal sistema CI/CD, perché è stata eseguita e chi l'ha approvata.

Esistono diversi modi per stabilire una correlazione tra i record e gli eventi di Cloud Audit Logs nella cronologia del sistema CI/CD, tra cui:

• Registra le richieste API eseguite da ogni esecuzione della pipeline CI/CD.
• Ogni volta che l'API restituisce un ID operazione, registralo nei log del sistema CI/CD.

• Aggiungi un'X-Goog-Request-Reason intestazione HTTP alle richieste API e passa l'ID dell'esecuzione della pipeline CI/CD. Terraform può aggiungere automaticamente questa intestazione se specifichi un motivo della richiesta.

  In alternativa, incorpora le informazioni nell'intestazione User-Agent in modo che vengano acquisite in Cloud Audit Logs.

Per contribuire a garantire la non ripudio, configura i file di log e le cronologie dei commit in modo che siano immutabili e un malintenzionato non possa nascondere le sue tracce in modo retroattivo.

Creare voci di log personalizzate per i singoli utenti di un'applicazione

Gli account di servizio sono utili anche per le applicazioni in cui un utente si autentica con uno schema di autenticazione personalizzato e poi accede indirettamente alle risorse Google Cloud. Queste applicazioni possono confermare che l'utente è autenticato e autorizzato, quindi utilizzare un account di servizio per autenticarsi ai servizi Google Cloud e accedere alle risorse. Tuttavia, Cloud Audit Logs registra che l'account di servizio ha eseguito l'accesso a una risorsa, non l'utente che utilizzava la tua applicazione.

Per facilitare il monitoraggio dell'accesso all'utente, progetta la logica dell'applicazione in modo da scrivere una voce di log personalizzata ogni volta che un utente accede a una risorsa e correla le voci di log personalizzate con Cloud Audit Logs.

Passaggi successivi

• Consulta le best practice per la gestione delle chiavi degli account di servizio.
• Consulta le nostre best practice per l'utilizzo degli account di servizio nelle pipeline di deployment.
• Scopri le best practice per l'utilizzo della federazione delle identità per i workload.