Best practice per l'utilizzo degli account di servizio

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

Sebbene i service account siano uno strumento utile, esistono diversi modi in cui un account di serviziot può essere utilizzato in modo illecito:

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

Per proteggere gli account di servizio, considera la loro duplice natura:

  • Poiché un account di servizio è un principal, devi limitarne i privilegi per ridurre i potenziali danni che può causare unaccount di serviziot compromesso.
  • Poiché un account di servizio è una risorsa, devi proteggerlo da compromissioni.

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

Scegliere quando utilizzare i service account

Non tutti gli scenari richiedono un account di servizio per accedere ai servizi Google Cloude molti scenari possono autenticarsi con un metodo più sicuro rispetto all'utilizzo di una chiave del account di servizio. Ti consigliamo di evitare di utilizzare le chiavi dei account di servizio, se possibile.

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

Struttura 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 per un singolo 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. Stai eseguendo il 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?
    1. In caso affermativo, utilizza Workload Identity Federation per GKE per collegare i service account ai pod Kubernetes.
    2. In caso contrario, collega un service account 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 workload esegue l'autenticazione 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 workload 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 account di servizio account.

Gestisci service account

I service account differiscono dagli altri tipi di principal 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 i service account come risorse

Gli account per i singoli utenti vengono in genere gestiti in base alle procedure di inserimento, trasferimento e uscita di un'organizzazione: quando un dipendente viene assunto, viene creato un nuovo account utente. Quando cambiano reparto, il loro account utente viene aggiornato. Quando lascia l'azienda, il suo account utente viene sospeso o eliminato.

Al contrario, i service account non sono associati a nessun dipendente in particolare. È invece meglio considerare i service account come risorse che appartengono a un'altra risorsa o ne fanno parte, ad esempio una particolare istanza VM o un'applicazione.

Per gestire in modo efficace i service account, non considerarli isolati. Considerali invece nel contesto della risorsa a cui sono associati e gestisci ilaccount di serviziot e la risorsa associata come un'unica unità: applica gli stessi processi, lo stesso ciclo di vita e la stessa attenzione aaccount di serviziont e alla risorsa associata e utilizza gli stessi strumenti per gestirli.

Crea service account monouso

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

  • 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 stessoaccount di serviziot, potrebbe essere necessario concedere a quest'ultimo 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 avuto 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 service account predefinito che ha il ruolo Editor (roles/editor) sul progetto per impostazione predefinita. Quando crei una risorsa, ad esempio un'istanza di macchina virtuale (VM) Compute Engine, e non specifichi un account di servizio, la risorsa può utilizzare automaticamente il account di servizio predefinito. Sebbene l'account di servizio predefinito semplifichi l'avvio, è molto rischioso condividere un account di servizio così potente tra più applicazioni.

Puoi adottare diverse misure per evitare queste complicazioni:

Seguire 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 service account:

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

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

Identificare e disattivare i service account inutilizzati

Quando un account di servizio non viene più utilizzato, disabilitalo. Se disattivi i service account inutilizzati, riduci il rischio che vengano utilizzati in modo illecito per il movimento laterale o per l'escalation dei privilegi da parte di un malintenzionato.

Per i service account monouso associati a una risorsa specifica, ad esempio un'istanza VM, disattiva il 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 Analizzatore attività per visualizzare le attività di autenticazione più recenti per i tuoi service account.

Disattivare i service account 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 disabiliti e riattivi un account di servizio, tutti i binding IAM rimangono intatti.

Per evitare di perdere inavvertitamente i binding 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 i service account predefiniti, come il service account predefinito di App Engine o il service account predefinito di Compute Engine. Questi account di servizio non possono essere ricreati senza disattivare e riattivare l'API corrispondente, il che potrebbe interrompere l'implementazione esistente. Se non utilizzi i service account predefiniti, disabilitali.

Limita i privilegi dell'account di servizio

I service account sono entità e possono ricevere l'accesso a una risorsa come qualsiasi altro tipo di entità. Tuttavia, i service account spesso hanno un accesso maggiore a più risorse rispetto ad altri tipi di entità. Inoltre, man mano che aggiungi funzionalità alle tue applicazioni, i relativi service account tendono ad acquisire sempre più accesso nel tempo; potresti anche dimenticare di revocare l'accesso non più necessario.

Non utilizzare le concessioni automatiche dei ruoli per i service account predefiniti

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

Per impedire che ai service account 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 sul nodo organizzazione o cartella. 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 tue risorse Google Cloud . Devi concedere ruoli appropriati ai service account predefiniti in modo che possano accedere alle tue risorse.

Non fare affidamento agli 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 la VM può accedere. Le limitazioni vengono applicate in aggiunta alle policy 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. Pertanto, gli ambiti di accesso non sono un sostituto adatto per le policy di autorizzazione granulari.

Anziché fare affidamento agli ambiti di accesso, crea un service account dedicato e utilizza criteri di autorizzazione granulari per limitare le risorse a cui il service account ha accesso.

Se tutti i service account attuali e futuri in un progetto, una cartella o un'organizzazione specifici condividono i requisiti, utilizza i set di entità service account per concedere loro i ruoli anziché utilizzare gruppi personalizzati.

Per saperne di più, consulta le best practice per l'utilizzo di Google Gruppi.

Evita di utilizzare la delega a livello di dominio

La delega a livello di dominio consente a un account di servizio di rappresentare 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 dall'esterno di Google Cloud.

La delega sull'intero dominio non limita un account di servizio a rappresentare un utente specifico, ma gli consente di rappresentare qualsiasi utente in un account Cloud Identity o Google Workspace, inclusi i super amministratori. Consentire a un service account di utilizzare la delega sull'intero dominio può quindi renderlo un obiettivo interessante per gli attacchi di escalation dei privilegi.

Evita di utilizzare la delega a livello di dominio se puoi svolgere l'attività direttamente con unaccount di serviziot o utilizzando il flusso di consenso OAuth. Ad esempio, se devi utilizzare Google Drive per archiviare i file, puoi utilizzare direttamente unaccount di serviziot per caricare i file in un drive condiviso oppure utilizzare il flusso di consenso OAuth 2.0 per caricare i file per conto di un utente.

Se non puoi evitare di utilizzare la delega a livello di dominio, limita l'insieme di ambiti OAuth che ilaccount di serviziot 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.

Tieni presente che i service account non possono essere proprietari diretti di asset in Google Workspace. Se devi utilizzare Google Drive per archiviare i file anziché utilizzare i bucket, carica i file direttamente su un Drive condiviso, agisci per conto di un utente utilizzando il flusso di consenso OAuth 2.0 o utilizza la delega a livello di dominio.

Utilizzare l'API Service Account 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 l'accesso una volta inizializzata.
  • Un'applicazione supervisore 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 è contrario al principio del privilegio minimo. Questo perché, in qualsiasi momento, l'applicazione probabilmente ha 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 Service Account Credentials per l'elevazione temporanea dei privilegi:

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

Per assistenza nella creazione di credenziali di breve durata, vedi Creare credenziali di breve durata per un service account.

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 sono effettivamente necessari. Di conseguenza, potresti concedere al account di servizio dell'applicazione più autorizzazioni di quelle richieste.

Allo stesso modo, i requisiti di accesso di un'applicazione potrebbero evolversi nel tempo e alcuni dei ruoli e delle autorizzazioni che hai concesso inizialmente potrebbero non essere più necessari.

Utilizza i suggerimenti sui ruoli per identificare quali autorizzazioni vengono effettivamente utilizzate da un'applicazione e quali potrebbero non essere utilizzate. Modifica le policy di autorizzazione delle risorse interessate per assicurarti che a un'applicazione non venga concesso un accesso superiore a quello di cui ha effettivamente bisogno.

Utilizzare gli approfondimenti 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 le autorizzazioni per simulare l'identità di un account di servizio nel progetto B.

Queste autorizzazioni possono comportare una catena di rappresentazioni nei progetti che concede alle entità un accesso non intenzionale alle risorse. Ad esempio, un principal potrebbe assumere l'identità di unaccount di serviziot nel progetto A e poi utilizzare questoaccount di serviziot per assumere l'identità di uaccount di serviziont nel progetto B. Se il account di servizio nel progetto B è autorizzato a simulare l'identità di altri service account in altri progetti della tua organizzazione, il principal potrebbe continuare a utilizzare la simulazione dell'identità deaccount di serviziont per spostarsi da un progetto all'altro, ottenendo le autorizzazioni man mano che procede.

Recommender fornisce informazioni sul movimento laterale per aiutarti a mitigare questo problema. Gli approfondimenti sul movimento laterale identificano i ruoli che consentono a unaccount di serviziot in un progetto di rappresentare unaccount di serviziot in un altro progetto. Per scoprire come visualizzare e gestire direttamente gli insight sul movimento laterale, consulta Gestire gli insight sul movimento laterale.

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

Protezione dalle minacce di escalation dei privilegi

Un account di servizio a cui non sono stati concessi ruoli, che non ha accesso a risorse e che non è associato ad alcuna regola firewall in genere ha un valore limitato. Dopo aver concesso a un account di servizio l'accesso alle risorse, il valore del account di servizio aumenta: diventa più utile per te, ma anche un obiettivo 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 che contiene informazioni sensibili. In questa situazione, il account di servizio è prezioso quanto il bucket Cloud Storage stesso. Anziché tentare di accedere direttamente al bucket, un malintenzionato potrebbe tentare di assumere il controllo dell'account di servizio. Se il tentativo va a buon fine, l'autore dell'attacco può aumentare i propri privilegi imitando 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 i service account rientrano in genere in queste categorie:

  • Autenticazione come account di servizio:potresti concedere inavvertitamente a un utente l'autorizzazione a impersonare un account di servizio o a creare una account di servizio account per un service account. Se l'account di servizio ha più privilegi dell'utente, l'utente può autenticarsi come account di servizio per aumentare i propri privilegi e ottenere l'accesso a risorse a cui altrimenti non potrebbe accedere.

  • Utilizzo di risorse con un account di servizio collegato:se un utente dispone dell'autorizzazione per accedere e modificare pipeline CI/CD, istanze VM o altri sistemi di automazione con service account collegati, potrebbe essere in grado di eseguire azioni utilizzando i service account collegati a queste risorse. Di conseguenza, anche se non hanno l'autorizzazione per rappresentare tramite simulazione dell'identità l'account di servizio, potrebbero comunque essere in grado di utilizzare le autorizzazioni dell'account di servizio per eseguire azioni che non sarebbero autorizzati a eseguire personalmente.

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

  • Modifiche a criteri di autorizzazione, 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 del account di servizio, del progetto o della cartellaGoogle Cloud . 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 sezioni seguenti forniscono best practice per proteggere gli account di servizio dalle minacce di escalation 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 il account di servizio. Se l'account di servizio ha un accesso più ampio rispetto all'utente, è effettivamente più privilegiato dell'utente.

Concedere a un utente l'autorizzazione a rappresentare un account di servizio con più privilegi 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 dell'elevazione dei privilegi di processo su Windows. A meno che tu non stia gestendo uno scenario in cui è necessario un aumento temporaneo dei privilegi, è meglio evitare di consentire agli utenti di rappresentare un account di servizio con più privilegi.

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

Le autorizzazioni che consentono a un utente di rappresentare un account di servizio o collegare unaccount di serviziot 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)
  • Service Account User (roles/iam.serviceAccountUser)
  • Creatore token service account (roles/iam.serviceAccountTokenCreator)
  • Amministratore chiavi service account (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 del progetto Google Cloud attuale potrebbe accedere l'utente impersonando ilaccount di serviziot?
  • Questo livello di accesso è giustificato?
  • Esistono protezioni sufficienti che controllano in quali circostanze l'utente può simulare l'identità delaccount di serviziot?

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

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

Gli utenti autorizzati a utilizzare o rappresentare un account di servizio sono indicati nel criterio di autorizzazione delaccount di serviziot. Il criterio di autorizzazione può essere modificato o esteso dagli utenti che dispongono dell'autorizzazione iam.serviceAccounts.setIamPolicy per iaccount di serviziont 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 danno a un utente il controllo completo di unaccount di serviziot:

  • L'utente può concedersi l'autorizzazione a simulare l'identità dell'account di servizio, il che gli consente di 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, chiediti a quali risorse all'interno e all'esterno del progetto Google Cloud corrente l'utente potrebbe accedere rappresentando l'account di servizio. Non consentire a un utente di modificare il criterio di autorizzazione di un service account se l'account di servizio ha più privilegi dell'utente.

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

Le chiavi del service account consentono ad applicazioni o utenti di autenticarsi comeaccount di serviziot. A differenza di altre forme di rappresentazione diaccount di serviziot, l'utilizzo di una chiave delaccount di serviziot non richiede alcuna forma di autenticazione precedente: chiunque possieda una chiave del service account può utilizzarla.

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

La creazione o il caricamento di una chiave del service account richiede l'autorizzazione iam.serviceAccountKeys.create, che è inclusa nei ruoli Amministratore chiavi service account (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 progettoGoogle Cloud corrente l'utente potrebbe accedere rappresentando l'account di servizio. Non consentire a un utente di creare chiavi dell'account di servizio per account di servizio che hanno più privilegi di lui.

Se il tuo Google Cloud progetto non richiede affatto chiavi account di servizio, applica i vincoli delle policy dell'organizzazione Disattiva creazione account di servizio account e Disabilita caricamento chiavi service account al progetto Google Cloud o alla cartella contenitore. Questi vincoli impediscono a tutti gli utenti di creare e caricare chiavi dell'account di servizio, inclusi quelli con l'autorizzazione iam.serviceAccountKeys.create su un service account.

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

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

  • Il account di servizio individuale
  • Progetto Google Cloud contenitore
  • Una cartella nella Google Cloud discendenza del progetto
  • 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 di privilegi. Ad esempio, se concedi a un utente il ruolo Creatore token account di servizio in un progetto Google Cloud , l'utente può rappresentare qualsiasi service account nel progetto Google Cloud . La possibilità di rappresentare qualsiasi account di servizio implica che l'utente può potenzialmente ottenere l'accesso a tutte le risorse a cui possono accedere questi service account, incluse le risorse esterne al progetto Google Cloud .

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

Non eseguire codice da fonti 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 calcolo, ad esempio un'istanza VM, 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 accedere alle risorse per suo conto.

Per impostazione predefinita, l'accesso al server dei metadati non è limitato a processi o utenti specifici. Invece, qualsiasi codice eseguito sulla risorsa di calcolo può accedere al server dei 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 forniti da un bucket Cloud Storage.
  • Policy guest distribuite da VM Manager.

Se il codice viene inviato dagli utenti o letto da una posizione di archiviazione remota, devi assicurarti che sia attendibile e che le posizioni di archiviazione remota siano protette almeno quanto iaccount di serviziont collegato. Se una posizione di archiviazione remota è meno protetta del account di servizio, un malintenzionato potrebbe essere in grado di aumentare i propri privilegi. Potrebbero farlo inserendo codice dannoso che utilizza i privilegi dell'account di servizio in quella posizione.

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

Alcune risorse di calcolo supportano l'accesso interattivo e consentono agli utenti di ottenere l'accesso alla 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 container Kubernetes.

Se a un'istanza VM è collegato un account di servizio con privilegi, qualsiasi utente con accesso alla shell al sistema può autenticarsi e accedere alle risorse come service account. Per impedire agli utenti di utilizzare questa funzionalità per aumentare i 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 dell'accesso al account di servizio collegato utilizzando l'accesso del OS Login operativo: per connettersi a un'istanza VM in cui è abilitato l'accesso del sistema operativo, un utente non solo deve essere autorizzato a utilizzare l'accesso del sistema operativo, ma deve anche disporre dell'autorizzazione iam.serviceAccounts.actAs sul 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 l'autorizzazione iam.serviceAccounts.actAs sul account di servizio collegato. Tuttavia, dopo la pubblicazione della chiave SSH o l'ottenimento delle credenziali Windows, gli accessi successivi non sono soggetti a ulteriori controlli delle autorizzazioni IAM.

Allo stesso modo, 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 avrebbero l'autorizzazione per l'autenticazione come account di servizio siano autorizzati ad accedere. Per saperne di più, 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 tramite Identity-Aware Proxy. Concedi il ruolo Utente tunnel protetto da IAP (roles/iap.tunnelResourceAccessor) solo agli utenti che devono essere autorizzati ad autenticarsi come account di servizio collegato all'istanza VM.

Limitare 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 di metadati per richiedere token per i service account. Per impostazione predefinita, l'accesso al server dei metadati non è limitato a un processo o utente specifico sulla VM. Anche i processi eseguiti come utente con privilegi limitati, ad esempio 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 guest in modo da consentire solo a questi utenti di aprire 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 ti consente di personalizzare una regola del firewall in modo che si applichi a utenti o gruppi selezionati.

Proteggiti dalle minacce di divulgazione di informazioni

Evitare 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 Google Cloud progetto, puoi aggiungere un'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 quest'altro progetto Google Cloud .

La visualizzazione delle policy 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 una policy di autorizzazione può anche vedere gli indirizzi email dei principal a cui è stato concesso l'accesso alla risorsa. Nel caso degli account di servizio, gli indirizzi email possono fornire indizi ai malintenzionati.

Ad esempio, una policy di autorizzazione potrebbe includere un binding 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, ad esempio deployer@deployment-project-123.iam.gserviceaccount.com, eviti di divulgare informazioni sul tipo di software che stai eseguendo in deployment-project-123.

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

Proteggiti dalle minacce di non ripudio

Ogni volta che noti un'attività sospetta che interessa 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 un'attività è stata eseguita da un account di servizio, queste informazioni da sole potrebbero non essere sufficienti per ricostruire l'intera catena di eventi. In questi casi, devi anche essere in grado di scoprire quale utente o applicazione ha causato l'attività dell'account di servizio.

Questa sezione contiene best practice che possono aiutarti a fare in modo che l'audit trail sia non ripudiabile.

Utilizza le chiavi del 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 delaccount di serviziot 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 unaccount di serviziot modifica una risorsa, ma se ilaccount di serviziot è autenticato con una chiave deaccount di serviziont, 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 contenitore. Se devi utilizzare le chiavi account di servizio per uno scenario che non può essere gestito con nessuna delle alternative consigliate, concedi un'eccezione al vincolo di policy, nel modo più ristretto possibile, e consulta le best practice per la gestione delle account di servizio account.

Abilita i log di accesso ai dati per le API IAM

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

Non tutti i servizi includono i dettagli di rappresentazione nei propri 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 Google Cloud progetti che contengono service account
  • API Security Token Service in tutti i Google Cloud progetti che contengono pool di identità dei carichi di lavoro

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 del codice è stata verificata e approvata correttamente 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 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, ilaccount di serviziot stesso spesso non è sufficiente per ricostruire l'intera catena di eventi che hanno portato alla modifica.

Per stabilire una traccia di controllo coerente nel 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 di Cloud Audit Logs e gli eventi nella cronologia del sistema CI/CD includono:

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

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

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

Per facilitare il tracciamento 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 metti in correlazione le voci di log personalizzate con Cloud Audit Logs.

Passaggi successivi