Best practice per l'utilizzo degli account di servizio

Gli account di servizio rappresentano utenti non umani. Sono studiate per 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 differiscono dai normali account utente per diversi aspetti:

  • Non dispongono di una password e non possono essere utilizzati per l'accesso tramite browser.
  • Vengono create e gestite come risorsa che appartiene a un progetto Google Cloud. Al contrario, gli utenti sono gestiti in un account Cloud Identity o Google Workspace.
  • Sono specifici di Google Cloud. Al contrario, gli utenti gestiti in Cloud Identity o Google Workspace lavorano su una moltitudine di prodotti e servizi Google.
  • Sono sia una risorsa che un'entità:
    • Come entità, a un account di servizio può essere concesso l'accesso alle risorse, ad esempio a un bucket Cloud Storage.
    • Come risorsa, un account di servizio è accessibile e possibilmente impersonato da altre entità, come un utente o un gruppo.

Sebbene gli account di servizio siano uno strumento utile, esistono diversi modi in cui è possibile utilizzarli in modo illecito:

  • Escalation dei privilegi: un utente malintenzionato potrebbe ottenere l'accesso a risorse a cui altrimenti non avrebbe accesso impersonando l'account di servizio.
  • Spoofing: un malintenzionato potrebbe utilizzare il furto dell'identità dell'account di servizio per oscurare la sua identità.
  • Non rifiuto: un 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 da parte del 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 proteggere meglio gli account di servizio, considera la loro duplice 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 illustra le best practice per la gestione, l'utilizzo e la protezione degli account di servizio.

Scegli 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 eseguire l'autenticazione con un metodo più sicuro rispetto a una chiave dell'account di servizio. Ti consigliamo di evitare di utilizzare chiavi degli account di servizio, quando 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, usa il diagramma seguente per scegliere un metodo di autenticazione:

Albero decisionale per la scelta del metodo di autenticazione in base al caso d'uso

Questo diagramma ti guida attraverso le seguenti domande:

  1. Stai eseguendo il codice in un ambiente di sviluppo a utente singolo, come 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. Stai eseguendo 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. Se sì, 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. Se sì, impersona un account di servizio con credenziali utente.
  5. Il tuo carico di lavoro autentica con un provider di identità esterno che supporta la federazione delle identità per i carichi di lavoro?
    1. Se sì, configura la federazione delle identità per i carichi di lavoro per consentire alle applicazioni in esecuzione on-premise o su altri cloud provider di utilizzare un account di servizio.
    2. In caso contrario, crea una chiave dell'account di servizio.

Gestione degli account di servizio

Gli account di servizio differiscono dai normali account utente, non solo per il modo in cui vengono utilizzati, ma anche per la modalità di gestione. Le sezioni seguenti forniscono le best practice per la gestione degli account di servizio.

Best practice:

Gestire gli account di servizio come risorse.
Crea account di servizio monouso.
Segui una convenzione di denominazione e documentazione.
Identificare e disabilitare gli account di servizio inutilizzati.
Disattiva gli account di servizio inutilizzati prima di eliminarli.

Gestire gli account di servizio come risorse

In genere, gli account utente normali vengono gestiti in base ai processi di joiner-mover- sugli abbandoni dell'organizzazione: quando un dipendente diventa membro, viene creato un nuovo account utente per lui. Quando si spostano i reparti, il loro account utente viene aggiornato. Quando lascia l'azienda, il suo account utente viene sospeso o eliminato.

Al contrario, gli account di servizio non sono associati a nessun dipendente specifico. È preferibile 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 in modo efficace gli account di servizio, non considerarli isolati. Considerali invece nel contesto della risorsa a cui sono associati e gestisci l'account di servizio e la risorsa associata come un'unica unità: applica gli stessi processi, lo stesso ciclo di vita e la stessa diligenza all'account di servizio e alla risorsa associata e utilizza gli stessi strumenti per gestirli.

Creare account di servizio a uso specifico

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 dismessa, potrebbe non essere chiaro se è possibile dismettere anche l'account di servizio 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 include il nome dell'account di servizio che ha eseguito una modifica o l'accesso ai dati, ma non riporta 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 far risalire l'attività all'applicazione corretta.

In particolare, alcuni servizi Google Cloud, tra cui App Engine e Compute Engine, creano un account di servizio predefinito con il ruolo Editor (roles/editor) sul progetto per impostazione predefinita. Quando crei una risorsa come un'istanza di una macchina virtuale (VM) 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 renda più semplice iniziare, è molto rischioso condividere un account di servizio così potente tra più applicazioni.

Per evitare queste complicazioni, puoi adottare diverse misure:

Segui una convenzione di denominazione e documentazione

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

  • Aggiungi all'indirizzo email dell'account di servizio un prefisso che identifichi il modo in cui viene utilizzato l'account. Ad esempio:
    • vm- per gli account di servizio collegati a un'istanza VM.
    • wi- per gli account di servizio utilizzati da Workload Identity.
    • wif- 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 un contatto, link alla documentazione pertinente o altre note.

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

Identifica e disattiva gli account di servizio inutilizzati

Quando un account di servizio non viene più utilizzato, disabilitalo. Disattivando gli account di servizio inutilizzati, riduci il rischio che questi account vengano utilizzati in modo illecito per movimento laterale o escalation dei privilegi da parte di un utente malintenzionato.

Per gli account di servizio a uso specifico associati a una determinata risorsa, ad esempio un'istanza VM, disabilita l'account di servizio non appena la risorsa associata viene disabilitata o eliminata.

Per gli account di servizio che vengono utilizzati per più scopi o condivisi tra più risorse, può essere più difficile capire se l'account di servizio viene ancora utilizzato. In questi casi, puoi utilizzare Activity Analyzer per visualizzare le attività di autenticazione più recenti per i tuoi account di servizio.

Disattiva gli account di servizio inutilizzati prima di eliminarli

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

Per evitare di perdere inavvertitamente le associazioni IAM, ti consigliamo di non eliminare immediatamente gli account di servizio. Piuttosto, disabilita un account di servizio se non è più necessario ed eliminalo solo dopo un determinato periodo.

Non eliminare mai gli account di servizio predefiniti come App Engine o l'account di servizio predefinito di Compute Engine. Questi account di servizio non possono essere ricreati senza disabilitare e riattivare l'API corrispondente, 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à a cui è possibile concedere l'accesso a una risorsa come un normale account utente. Tuttavia, gli account di servizio hanno spesso un maggiore accesso a più risorse rispetto a un utente tipico. Inoltre, man mano che aggiungi funzionalità alle tue applicazioni, i loro account di servizio tendono ad acquisire un accesso sempre maggiore nel tempo; potresti anche dimenticare di revocare l'accesso non più necessario.

Best practice:

Non utilizzare la concessione automatica dei ruoli per gli account di servizio predefiniti.
Non fare affidamento sugli ambiti di accesso quando colleghi un account di servizio a un'istanza VM.
Evita di utilizzare gruppi per concedere agli account di servizio l'accesso alle risorse.
Evita di utilizzare la delega a livello di dominio.
Non utilizzare account di servizio per accedere ai dati utente senza il consenso dell'utente.
Utilizza l'API IAM delle credenziali per l'elevazione temporanea dei privilegi.
Utilizza i confini di accesso alle credenziali per eseguire il downgrade dei token di accesso.
Utilizza i suggerimenti sui ruoli per identificare le autorizzazioni inutilizzate.
Utilizza le informazioni sul movimento laterale per limitare il movimento laterale.

Non utilizzare la concessione automatica dei ruoli per gli account di servizio predefiniti

Alcuni servizi Google Cloud creano account di servizio predefiniti quando abiliti per la prima volta la relativa API in un progetto Google Cloud. Per impostazione predefinita, a questi account di servizio viene concesso il ruolo Editor (roles/editor) nel progetto Google Cloud, che consente loro di leggere e modificare tutte le risorse nel progetto Google Cloud. Il ruolo viene concesso per praticità, 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 e non gli account di servizio predefiniti.

Per impedire che agli account di servizio predefiniti venga concesso automaticamente il ruolo Editor, abilita il vincolo Disabilita concessioni IAM automatiche per gli account di servizio predefiniti (constraints/iam.automaticIamGrantsForDefaultServiceAccounts) nella tua organizzazione. Per applicare il vincolo a più progetti Google Cloud, configuralo sulla cartella o sul nodo organizzazione. L'applicazione del vincolo 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 risorse Google Cloud. Devi concedere i ruoli appropriati agli account di servizio predefiniti in modo che possano accedere alle 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 consentono di limitare i servizi a cui la VM può accedere. Le limitazioni vengono applicate oltre ai criteri di autorizzazione.

Gli ambiti di accesso sono granulari. Ad esempio, utilizzando l'ambito https://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. Di conseguenza, gli ambiti di accesso non sostituiscono i 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 ha accesso l'account di servizio.

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

In un'organizzazione, è frequente che più dipendenti svolgano funzioni lavorative simili o sovrapposte e pertanto richiedono un accesso simile alle risorse. Usando i gruppi, puoi sfruttare queste analogie per ridurre il sovraccarico amministrativo.

Gli account di servizio sono pensati per essere utilizzati dalle applicazioni. Raramente più applicazioni svolgono la stessa funzione e quindi abbiano requisiti di accesso simili o identici. Le applicazioni tendono a essere univoche e le risorse a cui richiedono l'accesso sono generalmente diverse per ogni applicazione.

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

  • Una proliferazione di gruppi, ognuno dei quali contiene solo uno o pochi account di servizio.
  • Crescente di 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 agli account di servizio 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 impersonare 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 o di accedere alle API di Google che non supportano gli account di servizio esterni a Google Cloud.

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

Evita di utilizzare la delega a livello di dominio se puoi svolgere l'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ò impersonare, limitano i tipi di dati utente a cui può accedere l'account di servizio.

Un'applicazione potrebbe richiedere l'accesso a dati utente sensibili o personali. Esempi di questi dati includono la casella di posta o il calendario di un utente, 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 degli utenti può essere appropriato se l'applicazione esegue attività in background automatiche, ad esempio analisi di indicizzazione o prevenzione della perdita di dati (DLP) oppure se l'utente finale non si è autenticato con un'identità Google. In tutti gli altri casi in cui un'applicazione agisce per conto di un utente finale, è preferibile evitare di utilizzare account di servizio.

Anziché utilizzare un account di servizio per accedere ai dati utente (possibilmente eseguendo una transizione dell'entità), utilizza il flusso di consenso OAuth per richiedere il consenso dell'utente finale. e consentire all'applicazione di agire con l'identità dell'utente finale. Utilizzando OAuth anziché un account di servizio, puoi assicurarti che:

  • Gli utenti possono controllare le risorse a cui devono concedere l'accesso all'applicazione e possono esprimere o negare esplicitamente il consenso.
  • Gli utenti possono revocare il consenso in qualsiasi momento nella loro 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, puoi rinviare i controlli delle autorizzazioni alle API Google Cloud. Questo approccio limita il rischio di esporre accidentalmente dati a cui l'utente non dovrebbe essere autorizzato ad accedere a causa di un errore di programmazione (problema del deputy confuso).

Utilizza l'API IAM Credentials per l'elevazione temporanea dei privilegi

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

  • Un'applicazione potrebbe richiedere l'accesso ai dati di configurazione durante l'avvio, ma potrebbe non richiedere questo accesso dopo l'inizializzazione.
  • Un'applicazione supervisore potrebbe periodicamente avviare 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 vanno contro il principio del privilegio minimo: è probabile che in qualsiasi momento l'applicazione abbia accesso a più risorse di quelle necessarie.

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

  • Creare account di servizio dedicati per ogni parte dell'applicazione o del caso d'uso e concedere all'account di servizio l'accesso solo alle risorse necessarie.
  • Crea un altro account di servizio che funga da supervisore. Concedi all'account di servizio supervisor il ruolo Creatore token account di servizio per gli 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 funzioni come token broker e che solo questa parte utilizzi gli account di servizio del supervisore.
  • Utilizza il token broker per inviare account di servizio di breve durata alle altre parti dell'applicazione.

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

Utilizza i confini di accesso alle credenziali per eseguire il downgrade dei token di accesso

I token di accesso di Google sono token di connessione, il che significa che il loro utilizzo non è legato a nessuna applicazione particolare. Se l'applicazione passa un token di accesso a un'applicazione diversa, l'altra applicazione può utilizzarlo nello stesso modo in cui può utilizzare l'applicazione. Analogamente, se un utente malintenzionato divulga un token di accesso, può utilizzarlo per ottenere l'accesso.

Poiché i token di accesso sono di tipo portante, devi proteggerli dalla fuga di dati o dalla loro visibilità a soggetti non autorizzati. Puoi limitare i potenziali danni causati da un token di accesso divulgato limitando le risorse a cui concede l'accesso. Questo processo è chiamato downgrade.

Utilizza Confini di accesso alle credenziali per eseguire il downgrade dei token di accesso ogni volta che passi un token di accesso a un'applicazione diversa o a un componente diverso dell'applicazione. Imposta il limite di accesso in modo che il token conceda un accesso sufficiente alle risorse richieste, ma non di più.

Utilizza i suggerimenti sui ruoli per identificare le autorizzazioni inutilizzate

Quando esegui il deployment di un'applicazione per la prima volta, potresti non essere sicuro dei ruoli e delle autorizzazioni di cui l'applicazione ha realmente bisogno. Di conseguenza, potresti concedere all'account di servizio dell'applicazione le autorizzazioni necessarie.

Analogamente, i requisiti di accesso di un'applicazione potrebbero evolversi nel tempo e alcuni ruoli e autorizzazioni che hai concesso 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 garantire che a un'applicazione non venga concesso più accesso di quanto ne abbia effettivamente bisogno.

Usa le informazioni sul movimento laterale per limitare il movimento laterale

Lo spostamento laterale si verifica quando un account di servizio in un progetto dispone dell'autorizzazione per impersonare un account di servizio in un altro progetto. Ad esempio, un account di servizio potrebbe essere stato creato nel progetto A, ma avere le autorizzazioni per rubare l'identità di un account di servizio nel progetto B.

Queste autorizzazioni possono comportare una catena di rappresentazioni tra progetti che concede alle entità un accesso involontario alle risorse. Ad esempio, un'entità potrebbe impersonare un account di servizio nel progetto A e quindi utilizzare quell'account di servizio per impersonare un account di servizio nel progetto B. Se l'account di servizio nel progetto B dispone dell'autorizzazione per impersonare altri account di servizio in altri progetti dell'organizzazione, l'entità potrebbe continuare a utilizzare la simulazione dell'identità degli account di servizio per passare da un progetto al progetto, ottenendo le autorizzazioni man mano che procedi.

Il motore per suggerimenti fornisce insight sullo spostamento laterale per aiutarti a ridurre questo problema. Gli insight sugli spostamenti laterali identificano i ruoli che consentono a un account di servizio in un progetto di impersonare un account di servizio in un altro progetto. Per scoprire come visualizzare e gestire direttamente le informazioni sul movimento laterale, vedi Gestire le informazioni sul movimento laterale.

Alcune informazioni sul movimento laterale sono associate ai consigli sui ruoli. Puoi applicare questi suggerimenti per ridurre lo spostamento laterale tra i progetti. Per scoprire come fare, 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, non ha accesso a nessuna risorsa e non è associato ad alcuna regola firewall ha in genere un valore limitato. Dopo aver concesso a un account di servizio l'accesso alle risorse, il suo valore aumenta: l'account di servizio diventa più utile per te, ma diventa anche un bersaglio più interessante per gli attacchi di escalation dei privilegi.

Prendiamo ad esempio un account di servizio che ha accesso completo a un bucket Cloud Storage contenente informazioni sensibili. In questa situazione, l'account di servizio ha un valore tanto pari al bucket Cloud Storage stesso: invece di provare ad accedere direttamente al bucket, un utente malintenzionato potrebbe tentare di assumere il controllo dell'account di servizio. Se il tentativo va a buon fine, il malintenzionato può riassegnare i suoi privilegi impersonando l'account di servizio, il che a sua volta gli consente di accedere alle informazioni sensibili nel bucket.

Le tecniche di escalation dei privilegi che coinvolgono gli account di servizio generalmente rientrano nelle seguenti categorie:

  • Autenticazione come account di servizio: potresti inavvertitamente concedere a un utente l'autorizzazione a impersonare un account di servizio o a creare una chiave dell'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 riassegnare i privilegi e ottenere l'accesso a risorse a cui altrimenti non potrebbe accedere.

  • Utilizzo di risorse a cui è associato un account di servizio: se un utente ha l'autorizzazione per accedere e modificare pipeline CI/CD, istanze VM o altri sistemi di automazione che hanno account di servizio collegati, potrebbe essere in grado di eseguire azioni utilizzando gli account di servizio collegati alle risorse. Di conseguenza, anche se non dispongono dell'autorizzazione per impersonare l'account di servizio, potrebbero comunque essere in grado di utilizzare le autorizzazioni dell'account di servizio per eseguire azioni che non sarebbero autorizzate a eseguire autonomamente.

    Ad esempio, se un utente ha accesso tramite SSH a un'istanza VM di Compute Engine, può eseguire il codice nell'istanza per accedere a qualsiasi risorsa a cui può accedere l'account di servizio collegato all'istanza.

  • Consenti modifiche a criteri, gruppi o ruoli personalizzati: un utente che non ha accesso a un account di servizio con privilegi potrebbe comunque avere l'autorizzazione per modificare i criteri di autorizzazione dell'account di servizio, che includono il progetto o la cartella Google Cloud. L'utente può quindi estendere uno di questi criteri di autorizzazione per concedersi l'autorizzazione (direttamente o indirettamente) ad autenticarsi come account di servizio.

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

Best practice:

Evita di consentire agli utenti di impersonare account di servizio con più privilegi rispetto agli utenti stessi.
Evita di consentire agli utenti di modificare i criteri di autorizzazione degli account di servizio che hanno più privilegi rispetto agli utenti stessi.
Non consentire agli utenti di creare o caricare chiavi degli account di servizio.
Non concedere l'accesso agli account di servizio a livello di progetto o cartella Google Cloud.
Non eseguire codice da origini meno protette su risorse di calcolo a cui è collegato un account di servizio con privilegi.
Limita l'accesso dello shell alle VM a cui è collegato un account di servizio con privilegi.
Limita l'accesso al server dei metadati agli utenti e ai processi selezionati.

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

Rappresentando 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ù ampio dell'utente, allora avrà effettivamente più privilegi dell'utente.

La concessione a un utente dell'autorizzazione a impersonare un account di servizio con più privilegi può essere un modo per consentire deliberatamente agli utenti di aumentare temporaneamente i propri privilegi, in modo simile all'utilizzo dello strumento sudo su Linux o all'utilizzo dell'elevazione dei processi su Windows. A meno che tu non abbia a che fare con uno scenario in cui è necessaria l'elevazione temporanea dei privilegi, è meglio evitare di consentire agli utenti di impersonare un account di servizio con privilegi più privilegi.

Gli utenti possono anche ottenere indirettamente le autorizzazioni di un account di servizio collegandolo a una risorsa ed eseguendo il codice su quella risorsa. L'esecuzione del codice in questo modo non comporta l'impersonificazione degli account di servizio perché prevede 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 impersonare un account di servizio o di collegare un account di servizio a una risorsa includono quanto segue:

  • 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 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 Deployment Manager (roles/deploymentmanager.editor)
  • Editor Cloud Build (roles/cloudbuild.builds.editor)

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

  • A quali risorse all'interno e all'esterno dell'attuale progetto Google Cloud potrebbe ottenere l'accesso l'utente impersonando l'account di servizio?
  • Questo livello di accesso è giustificato?
  • Esistono protezioni sufficienti che controllano in quali circostanze l'utente può rubare l'identità dell'account di servizio?

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

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

Gli utenti autorizzati a utilizzare o impersonare un account di servizio vengono acquisiti dal criterio di autorizzazione dell'account di servizio. Il criterio di autorizzazione può essere modificato o esteso da utenti che dispongono dell'autorizzazione iam.serviceAccounts.setIamPolicy per l'account di servizio specifico. 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 offrono a un utente il controllo completo su un account di servizio:

  • L'utente può concedersi l'autorizzazione a impersonare l'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 di accesso all'account di servizio.

Prima di assegnare uno di questi ruoli a un utente, chiediti a quali risorse all'interno e all'esterno dell'attuale progetto Google Cloud l'utente potrebbe accedere assumendo l'identità dell'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 degli account di servizio

Le chiavi degli account di servizio consentono ad applicazioni o utenti di autenticarsi come account di servizio. A differenza di altre forme di furto d'identità degli 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 a quello della simulazione dell'identità degli account di servizio. Se un utente ha accesso a una chiave dell'account di servizio o ha l'autorizzazione per creare una nuova chiave dell'account di servizio, può autenticarsi come account di servizio e accedere a tutte le risorse a cui può accedere.

Per creare o caricare una chiave dell'account di servizio è necessaria l'autorizzazione iam.serviceAccountKeys.create, inclusa nei ruoli Amministratore chiavi dell'account di servizio (roles/iam.serviceAccountKeyAdmin) ed Editor (roles/editor).

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

Se il progetto Google Cloud non richiede alcuna chiave dell'account di servizio, applica i vincoli dei criteri dell'organizzazione Disabilita creazione chiavi account di servizio e Disabilita caricamento chiavi account di servizio al progetto Google Cloud o alla cartella di inclusione. Questi vincoli impediscono a tutti gli utenti di creare e caricare chiavi degli 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. Pertanto, puoi gestire l'accesso agli account di servizio a uno dei seguenti livelli:

  • L'account di servizio individuale
  • Il progetto Google Cloud che lo include
  • Una cartella nella discendenza 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ò aiutare a ridurre i costi amministrativi, ma può anche portare a una concessione eccessiva di privilegi. Ad esempio, se concedi a un utente il ruolo Creatore token account di servizio in un progetto Google Cloud, l'utente può impersonare qualsiasi account di servizio nel progetto Google Cloud. La possibilità di impersonare qualsiasi account di servizio implica che l'utente può potenzialmente accedere a tutte le risorse a cui possono accedere questi account di servizio, incluse le risorse esterne al progetto Google Cloud.

Per evitare questo tipo di autorizzazioni eccessive, non gestire l'accesso agli account di servizio a livello di progetto o cartella Google Cloud. Puoi gestire invece l'accesso singolarmente per ogni account di servizio.

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

Quando colleghi un account di servizio a una risorsa di computing, ad esempio un'istanza VM o un'applicazione Cloud Run, i processi in esecuzione su quella risorsa possono utilizzare il server metadati per richiedere token di accesso e token ID. Questi token permettono 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. Qualsiasi codice eseguito sulla risorsa di computing può invece accedere al server dei metadati e ottenere un token di accesso. Questo codice può includere:

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

Se il codice viene inviato dagli utenti o letto da una posizione di archiviazione remota, devi assicurarti che sia affidabile e che le posizioni di archiviazione remota siano protette almeno quanto l'account di servizio associato. Se una posizione di archiviazione remota è meno protetta dell'account di servizio, un utente malintenzionato potrebbe essere in grado di aumentare i propri privilegi. Potrebbe farlo iniettando un codice dannoso che utilizza i privilegi dell'account di servizio in quella località.

Limita l'accesso della shell alle VM a cui è collegato un account di servizio con privilegi

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

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

Se a un'istanza VM è collegato un account di servizio con privilegi, qualsiasi utente con accesso shell al sistema può autenticare e accedere alle risorse come account di servizio. Per impedire agli utenti di utilizzare in modo illecito questa funzionalità per riassegnare i privilegi, devi assicurarti che l'accesso alla shell sia protetto almeno quanto l'account di servizio associato.

Per le istanze Linux, puoi stabilire che l'accesso SSH sia più restrittivo dell'accesso all'account di servizio associato utilizzando OS Login. Per connettersi a un'istanza VM in cui è abilitato OS Login, all'utente deve essere consentito l'utilizzo di OS Login, ma anche l'autorizzazione iam.serviceAccounts.actAs nell'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 per i metadati o la richiesta di credenziali Windows richiede l'accesso ai metadati dell'istanza VM e all'autorizzazione iam.serviceAccounts.actAs sull'account di servizio collegato. Tuttavia, dopo la pubblicazione della chiave SSH o l'ottenimento delle credenziali di Windows, gli accessi successivi non sono soggetti ad altri controlli delle autorizzazioni IAM.

Analogamente, se un'istanza VM utilizza un modulo di autenticazione modulare Linux personalizzato per l'autenticazione o è membro di un dominio Active Directory, è possibile che gli utenti che altrimenti non sarebbero autorizzati ad autenticarsi con l'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 OS Login, valuta la possibilità di limitare l'accesso alla shell da parte di Identity-Aware Proxy. Concedi il ruolo Utente del tunnel con protezione IAP (roles/iap.tunnelResourceAccessor) solo agli utenti autorizzati ad autenticarsi come account di servizio associato all'istanza VM.

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

Quando colleghi un account di servizio a un'istanza VM, i carichi di lavoro di cui è stato eseguito il deployment nella VM possono accedere al server di metadati per richiedere i token per gli account di servizio. Per impostazione predefinita, l'accesso al server dei metadati non è limitato a nessun processo o utente specifico sulla VM: anche i processi eseguiti come utente con privilegi limitati, come nobody su Linux o LocalService su Windows, hanno accesso completo al server dei metadati e possono ottenere token per l'account di servizio.

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

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

Proteggiti dalle minacce legate alla divulgazione di informazioni

Best practice:

Evita di divulgare informazioni riservate negli indirizzi email degli account per il servizio.

Evita di divulgare informazioni riservate negli indirizzi email degli account di servizio.

Per concedere a un account di servizio l'accesso a una risorsa in un altro progetto Google Cloud, puoi aggiungere un'associazione dei 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 dall'altro progetto Google Cloud.

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

Un utente che può visualizzare un criterio di autorizzazione può anche vedere gli indirizzi email delle entità a cui è stato concesso l'accesso alla risorsa. Nel caso degli account di servizio, gli indirizzi email possono fornire suggerimenti 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.gserviceaccount.com. Al malintenzionato, questo indirizzo email non solo rivela l'esistenza di un progetto Google Cloud con ID deployment-project-123, ma anche che il progetto Google Cloud esegue un server Jenkins. Scegliendo un nome più generico, come deployer@deployment-project-123.gserviceaccount.com, eviti di divulgare informazioni sul tipo di software che è in esecuzione in deployment-project-123.

Se concedi a un account di servizio l'accesso alle risorse di un progetto Google Cloud che ha 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 a malintenzionati.

Proteggiti dalle minacce di non ripudio

Ogni volta che noti attività sospette che interessano una delle tue risorse su Google Cloud, Cloud Audit Logs sono 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, queste informazioni da sole potrebbero non essere sufficienti per ricostruire l'intera catena di eventi: devi anche poter scoprire quale utente o applicazione ha causato l'esecuzione dell'attività da parte dell'account di servizio.

Questa sezione contiene best practice che possono aiutarti a gestire un audit trail non ripudiabile.

Best practice:

Utilizza le chiavi degli account di servizio solo se non esiste un'alternativa attuabile.
Abilita i log di accesso ai dati per le API IAM.
Assicurati che la cronologia CI/CD possa essere correlata a Cloud Audit Logs.
Crea voci di log personalizzate per i singoli utenti di un'applicazione.

Utilizza le chiavi degli account di servizio solo quando non esistono alternative attuabili

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 rifiuto. Cloud Audit Logs crea un log quando un account di servizio modifica una risorsa, ma se l'account di servizio è autenticato con una chiave dell'account di servizio, non esiste un modo affidabile per capire chi ha utilizzato la chiave. In confronto, l'autenticazione come account di servizio impersonando l'account di servizio con credenziali utente registra l'entità che ha agito come account di servizio.

Consigliamo di impedire la creazione di chiavi dell'account di servizio applicando il vincolo del criterio dell'organizzazione Disabilita la creazione di chiavi dell'account di servizio al progetto Google Cloud o alla cartella che lo contiene. Se devi utilizzare le chiavi dell'account di servizio per uno scenario che non può essere gestito con nessuna delle alternative consigliate, concedi un'eccezione al vincolo del criterio, nel modo più restrittivo possibile, e consulta le best practice per la gestione delle chiavi degli account di servizio.

Abilita i log degli accessi ai dati per le API IAM

Per aiutarti a identificare e comprendere gli scenari di rappresentazione degli account di servizio, servizi come Compute Engine includono una sezione serviceAccountDelegationInfo in Cloud Audit Logs. In questa sezione viene indicato se l'account di servizio è stato impersonato e da quale utente.

Non tutti i servizi includono dettagli relativi alla rappresentazione nei rispettivi Cloud Audit Logs. Per registrare tutti gli eventi di rappresentazione, 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 Workload Identity

Se abiliti 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 vengono comunemente utilizzati dai sistemi CI/CD per eseguire i deployment dopo che una modifica al 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, i commit e le esecuzioni della pipeline corrispondenti, nonché le informazioni su chi ha approvato il deployment.

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

Per stabilire un audit trail coerente tra il sistema CI/CD e 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.

I modi per stabilire una correlazione tra i record e gli eventi di Cloud Audit Logs nella cronologia del sistema CI/CD includono:

  • Richieste API Log 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'intestazione HTTP X-Goog-Request-Reason alle richieste API e trasmetti 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 l'non ripudibilità, configura i file di log e le cronologie di commit in modo che siano immutabili e un malintenzionato non possa nascondere retroattivamente le proprie tracce.

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 esegue l'autenticazione 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 eseguire l'autenticazione ai servizi Google Cloud e accedere alle risorse. Tuttavia, Cloud Audit Logs registrerà l'accesso dell'account di servizio a una risorsa, non dell'utente che stava utilizzando l'applicazione.

Per agevolare il rilevamento 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 correlare le voci di log personalizzate con Cloud Audit Logs.

Passaggi successivi