Best practice per l'utilizzo di account di servizio

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

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

  • Non hanno una password e non possono essere utilizzati per l'accesso tramite browser.
  • Vengono create e gestite come risorsa appartenente a un progetto Google Cloud. Al contrario, gli utenti sono gestiti in Cloud Identity Account Google Workspace.
  • Sono specifici di Google Cloud. Gli utenti gestiti in Cloud Identity o Google Workspace, invece, lavorano su una moltitudine di prodotti e servizi Google.
  • Sono sia una risorsa sia un'entità:
    • Come entità, a un account di servizio può essere concesso l'accesso alle risorse, come un bucket Cloud Storage.
    • Come risorsa, a un account di servizio è possibile accedere furto d'identità di altri come un utente o un gruppo.

Sebbene gli account di servizio siano uno strumento utile, esistono diversi modi per l'account di servizio può essere utilizzato in modo illecito:

  • Escalation dei privilegi:un utente malintenzionato potrebbe ottenere l'accesso alle risorse che altrimenti non avrebbero accesso a rubando l'identità dell'account di servizio.
  • Spoofing: un malintenzionato potrebbe utilizzare l'usurpazione di identità dell'account di servizio per nascondere la propria identità.
  • Non ripudio: un utente malintenzionato potrebbe nascondere la propria identità e le proprie azioni utilizzando un account di servizio per eseguire operazioni per suo conto. In alcuni casi, potrebbe non essere possibile risalire a chi ha compiuto queste azioni.
  • 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 gli account di servizio, considera la loro duplice natura:

  • Poiché un account di servizio è un'entità, devi limitarne i privilegi a ridurre i potenziali danni che possono essere causati da un account di servizio compromesso.
  • Poiché un account di servizio è una risorsa, è necessario proteggerlo è stato compromesso.

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

Scegliere quando utilizzare gli account di servizio

Non tutti gli scenari richiedono un account di servizio per accedere a Google Cloud e in molti scenari è possibile eseguire l'autenticazione con un metodo più sicuro rispetto utilizzando una chiave dell'account di servizio. Ti consigliamo di evitare di utilizzare un account di servizio se possibile.

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

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

Questo diagramma ti guida attraverso le seguenti domande:

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

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

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

    1. In caso contrario, utilizzare le credenziali utente.
    2. In caso affermativo, assumi l'identità di un account di servizio con le credenziali utente.
  5. Il carico di lavoro esegue l'autenticazione con un provider di identità esterno che supporti federazione delle identità per i carichi di lavoro?
    1. Se sì, configurare 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.

Gestisci account di servizio

Gli account di servizio sono diversi dai normali account utente, non solo per il modo in cui vengono utilizzati, ma anche nel modo in cui devono essere gestiti. 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 a scopo singolo.
Segui una convenzione di denominazione e documentazione.
Identifica e disattiva gli account di servizio inutilizzati.
Disattiva gli account di servizio inutilizzati prima di eliminarli.

Gestisci gli account di servizio come risorse

I normali account utente sono generalmente gestiti in base alla Processi joiner-mover-leaver: quando un dipendente entra in azienda, viene creato un nuovo account utente che hai creato per loro. Quando spostano i reparti, il loro account utente viene aggiornato. Quando l'utente lascia l'azienda, il suo account viene sospeso o eliminato.

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

Per gestire efficacemente gli account di servizio, non esaminarli singolarmente. Considerali invece nel contesto della risorsa a cui sono associati gestisci l'account di servizio e la risorsa associata come un'unica unità: applica lo stesso di elaborazione, stesso ciclo di vita e la stessa attenzione per l'account di servizio e i suoi e una risorsa associata e usa gli stessi strumenti per gestirle.

Crea account di servizio monouso

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

  • Le applicazioni potrebbero avere cicli di vita diversi. Se un'applicazione viene dismessa, potrebbe non essere chiaro se sia possibile dismettere anche l'account di servizio o se è ancora necessario.
  • Nel tempo, i requisiti di accesso delle applicazioni potrebbero variare. 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.
  • I log di controllo di Cloud includono il nome dell'account di servizio che ha eseguito una modifica o ha eseguito l'accesso ai dati, ma non mostrano il nome dell'applicazione che ha utilizzato l'account di servizio. Se più applicazioni condividono un account di servizio, potresti non essere in grado di risalire all'applicazione corretta.

In particolare, alcuni servizi Google Cloud, tra cui App Engine e Compute Engine, creano un account di servizio predefinito che ha il ruolo di editor (roles/editor) nel progetto per impostazione predefinita. Quando crei una risorsa come un'istanza di macchina virtuale (VM) Compute Engine e non specifichi un account di servizio, la risorsa può utilizzare automaticamente l'account di servizio predefinito. Anche se l'account di servizio predefinito semplifica per iniziare, è molto rischioso condividere un account di servizio così potente per applicazioni containerizzate.

Puoi adottare diversi passaggi per evitare queste complicazioni:

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

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

Identifica e disattiva gli account di servizio inutilizzati

Quando un account di servizio non viene più utilizzato, disattivalo. Se disabiliti gli account di servizio inutilizzati, riduci il rischio degli account di servizio abusato per movimento laterale o per escalation dei privilegi da parte di un malintenzionato.

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

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

Disattivare gli account di servizio inutilizzati prima di eliminarli

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

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

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

Limita i privilegi dell'account di servizio

Gli account di servizio sono entità e a questi può essere concesso l'accesso a una risorsa come un account utente normale. Tuttavia, gli account di servizio spesso hanno un accesso più ampio più risorse rispetto a un utente tipico. Inoltre, man mano che aggiungi funzionalità le tue applicazioni, i loro account di servizio tendono ad avere sempre più accesso volta; potresti anche dimenticare di revocare l'accesso non più necessario.

Best practice:

Non utilizzare le concessioni di ruoli automatiche 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 i 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 delle credenziali IAM per l'elevazione temporanea dei privilegi.
Utilizza i confini per l'accesso con credenziali per ridurre l'ambito 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 le concessioni di ruoli automatiche per gli account di servizio predefiniti

Alcuni servizi Google Cloud creano un servizio predefinito account, alla prima attivazione in un progetto Google Cloud. A seconda della configurazione dei criteri dell'organizzazione, a questi account di servizio potrebbe essere concesso automaticamente il ruolo Editor (roles/editor) sul tuo progetto Google Cloud, che consente di leggere e e modificare tutte le risorse nel progetto Google Cloud. Il ruolo viene concesso ma non è essenziale per il corretto funzionamento dei servizi: per accedere alle risorse nel tuo progetto Google Cloud, i servizi Google Cloud utilizzano e non quelli predefiniti.

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

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

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

Quando colleghi un account di servizio a un'istanza VM, puoi Specifica 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 consentiti.

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

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

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

In un'organizzazione, accade spesso che più dipendenti funzionino in modo simile o che si sovrappongano di mansioni lavorative e richiedono quindi un accesso simile alle risorse. Utilizzando i gruppi, puoi sfruttare queste somiglianze per ridurre il sovraccarico amministrativo.

Gli account di servizio sono destinati a essere utilizzati dalle applicazioni. È raro che più applicazioni svolgono la stessa funzione e, pertanto, hanno e requisiti di accesso identici. Invece, le applicazioni tendono a essere univoche e Le risorse a cui devono accedere sono tipicamente diverse per ogni applicazione.

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

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

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

Evita di utilizzare la delega a livello di dominio

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

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

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

Se non puoi evitare di utilizzare la delega a livello di dominio, limita il set di ambiti OAuth. utilizzabili dall'account di servizio. Anche se gli ambiti OAuth non limitare 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 tali dati includono la casella di posta o il calendario dell'utente, i documenti archiviati Google Drive o un set di dati BigQuery contenente dati sensibili.

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

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

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

Se consenti all'applicazione di utilizzare le credenziali dell'utente finale, rimandi i controlli delle autorizzazioni alle API Google Cloud. Questo approccio limita il rischio di esporre accidentalmente Dati a cui l'utente non deve essere autorizzato ad accedere a causa di un errore di programmazione (problema confuso con il vicepresidente).

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

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

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

In scenari del genere, usare un singolo account di servizio e concedergli l'accesso a tutti delle risorse vanno in contrasto con il principio del privilegio minimo: in qualsiasi momento, è probabile che l'applicazione abbia accesso a più risorse di quelle di cui ha effettivamente bisogno.

Per assicurarti che le diverse parti dell'applicazione abbiano accesso soltanto risorse necessarie, utilizza l'API IAM Credentials per l'elevazione temporanea dei privilegi:

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

Per informazioni sulla creazione di credenziali di breve durata, vedi Creare credenziali di breve durata per un account di servizio.

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

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

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

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

Utilizzare i suggerimenti sui ruoli per identificare le autorizzazioni inutilizzate

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

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

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

Utilizzare le informazioni sul movimento laterale per limitare il movimento laterale

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

Queste autorizzazioni possono comportare una catena di rappresentazioni tra progetti concede alle entità un accesso involontario alle risorse. Ad esempio, un'entità potrebbe assumere il ruolo di un account di servizio nel progetto A e poi utilizzare quell'account di servizio per assumere il ruolo di un account di servizio nel progetto B. Se l'account di servizio nel progetto B dispone dell'autorizzazione per impersonare altri account di servizio in altri progetti in dell'organizzazione, l'entità potrebbe continuare a utilizzare la simulazione dell'identità degli account di servizio di passare da un progetto all'altro, acquisendo sempre le autorizzazioni necessarie.

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

Alcuni approfondimenti sui movimenti laterali sono associati ai consigli sui ruoli. Tu puoi applicare questi suggerimenti per ridurre gli spostamenti laterali tra i progetti. Per scoprire come, consulta l'articolo Esaminare e applicare personalizzati.

Proteggiti dalle minacce di escalation dei privilegi

Un account di servizio a cui non sono stati concessi ruoli, non ha accesso ad alcun ruolo risorse e non è associato ad alcuna regola firewall ha un valore limitato. Dopo aver concesso a un account di servizio l'accesso alle risorse, il valore dell'account di servizio aumenta: l'account di servizio diventa più utile ma diventa anche un bersaglio più interessante per gli attacchi con escalation di privilegi.

Ad esempio, considera un account di servizio che ha accesso completo a un bucket Cloud Storage contenente informazioni sensibili. In questa situazione, l'account di servizio è praticamente importante quanto il bucket Cloud Storage stesso: anziché provare ad accedere direttamente al bucket, un malintenzionato potrebbe tentare di prendere il controllo dell'account di servizio. Se il tentativo va a buon fine, il malintenzionato può riassegnare impersonando l'account di servizio, che a sua volta consente all'utente di accedere alle informazioni sensibili nel bucket.

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

  • Autenticazione come account di servizio:potresti concedere inavvertitamente una l'autorizzazione dell'utente a simulare l'identità di un o per creare un account di servizio chiave per un 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 l'accesso a risorse a cui altrimenti non potrebbero accedere.

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

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

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

Le sezioni seguenti forniscono le best practice per la protezione degli account di servizio da minacce di escalation dei privilegi.

Best practice:

Evita di consentire agli utenti di impersonare account di servizio con privilegi superiori agli utenti stessi.
Evita di consentire agli utenti di modificare i criteri di autorizzazione degli account di servizio con maggiori privilegi degli utenti stessi.
Non consentire agli utenti di creare o caricare chiavi dell'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 è associato un account di servizio con privilegi.
Limita l'accesso alla shell alle VM a cui è collegato un account di servizio con privilegi.
Limita l'accesso al server dei metadati a utenti e processi selezionati.

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

Simulando l'identità di un account di servizio, un utente ottiene l'accesso ad alcuni o a tutti i a cui può accedere l'account di servizio. Se l'account di servizio ha un accesso esteso rispetto all'utente, allora ha di fatto più privilegiati rispetto utente.

Concessione a un utente dell'autorizzazione a utilizzare l'identità di un servizio con maggiori privilegi un account può essere un modo per consentire agli utenti di aumentare temporaneamente privilegiati, analogamente all'utilizzo dello strumento sudo su Linux o all'utilizzo dell'elevazione su Windows. A meno che tu non abbia a che fare con uno scenario in cui queste l'elevazione dei privilegi è necessaria, meglio evitare di consentire agli utenti un account di servizio con maggiori privilegi.

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

Autorizzazioni che consentono a un utente di impersonare un account di servizio o di collegarlo a una account di servizio 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 dell'account di servizio (roles/iam.serviceAccountUser)
  • Creatore token account di servizio (roles/iam.serviceAccountTokenCreator)
  • Amministratore chiavi account di servizio (roles/iam.serviceAccountKeyAdmin)
  • Amministratore account di servizio (roles/iam.serviceAccountAdmin)
  • Utente Workload Identity (roles/iam.workloadIdentityUser)
  • Editor di Deployment Manager (roles/deploymentmanager.editor)
  • Editor Cloud Build (roles/cloudbuild.builds.editor)

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

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

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

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

Quali utenti sono autorizzati a utilizzare o a impersonare un account di servizio che vengono acquisiti il criterio di autorizzazione dell'account di servizio. Il criterio di autorizzazione può essere modificato o esteso dagli utenti che hanno l'autorizzazione iam.serviceAccounts.setIamPolicy nella un particolare account di servizio. I ruoli che contengono questa autorizzazione includono:

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

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

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

Prima di assegnare uno qualsiasi di questi ruoli a un utente, chiediti quali risorse e al di fuori dell'attuale progetto Google Cloud a cui l'utente potrebbe accedere 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 dell'account di servizio consentono alle applicazioni o agli utenti di autenticarsi come account di servizio. A differenza di altre forme di sostituzione dell'identità dell'account di servizio, l'utilizzo di una chiave dell'account di servizio non richiede alcuna forma di autenticazione precedente: chiunque possieda una chiave dell'account di servizio può utilizzarla.

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

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

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

Se il tuo progetto Google Cloud non richiede alcuna chiave dell'account di servizio, applica Disabilita la creazione di chiavi degli account di servizio e Disabilita il caricamento della chiave dell'account di servizio vincoli dei criteri dell'organizzazione al progetto Google Cloud o alla cartella che la contiene. 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 gerarchia delle risorse. Puoi quindi gestire l'accesso agli account di servizio a uno dei seguenti livelli:

  • Il singolo account di servizio
  • Il progetto Google Cloud contenitore
  • Una cartella nella discendenza del progetto Google Cloud
  • Il nodo organizzazione

Gestione dell'accesso a livello di progetto Google Cloud o a un livello superiore della risorsa della gerarchia può aiutare a ridurre l'overhead amministrativo, ma può anche portare a concessioni eccessive 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 rubare l'identità di qualsiasi account di servizio implica che l'utente possa potenzialmente ottenere l'accesso a tutte le risorse a cui possono accedere questi account di servizio, incluse le risorse esterne al progetto Google Cloud.

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

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

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

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

Se il codice viene inviato dagli utenti o letto da una posizione di archiviazione remota, devi assicurarsi che sia affidabile e che le posizioni di archiviazione remote siano almeno e la sicurezza dell'account di servizio collegato. Se una posizione di archiviazione remota è meno protetta dell'account di servizio, un malintenzionato potrebbe essere in grado di eseguire la riassegnazione dei propri privilegi. Potrebbero farlo iniettando codice dannoso che utilizza i privilegi dell'account di servizio in quella posizione.

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

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

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

Se a un'istanza VM è collegato un account di servizio con privilegi, qualsiasi utente con l'accesso shell al sistema può eseguire l'autenticazione e accedere alle risorse come . Per evitare che gli utenti abusino di questa capacità, devi assicurarti che l'accesso alla shell sia protetto almeno quanto con un account di servizio collegato.

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

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

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

In particolare, per le istanze VM che non utilizzano l'accesso del sistema operativo, valuta la possibilità di limitare l'accesso alla shell tramite Identity-Aware Proxy. Concedi solo ai Ruolo Utente del tunnel con protezione IAP (roles/iap.tunnelResourceAccessor) per gli utenti che deve essere autorizzato ad autenticarsi con l'account di servizio associato alla VM in esecuzione in un'istanza Compute Engine.

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

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

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

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

Proteggere dalle minacce di divulgazione di informazioni

Best practice:

Evita di divulgare informazioni riservate negli indirizzi email degli account di 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. Metti Mi piace alla risorsa stesso, il criterio di autorizzazione fa parte dell'altro progetto Google Cloud e la 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, inclusa l'autorizzazione di base Ruolo Visualizzatore.

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

Ad esempio, un criterio di autorizzazione potrebbe includere un'associazione per un account di servizio con l'indirizzo email jenkins@deployment-project-123.iam.gserviceaccount.com. Pessima 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 server Jenkins. Scegliendo un nome più generico, ad esempio deployer@deployment-project-123.iam.gserviceaccount.com, eviterai di divulgare informazioni sul tipo di software in esecuzione in deployment-project-123.

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

Proteggiti dalle minacce di non ripudio

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

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

Questa sezione contiene best practice che possono aiutarti a mantenere un e un audit trail.

Best practice:

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

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

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

Ti consigliamo di impedire la creazione di chiavi degli account di servizio applicando il metodo Disabilitare la creazione di chiavi dell'account di servizio del criterio dell'organizzazione al progetto Google Cloud o al relativo . Se devi utilizzare delle chiavi degli account di servizio per uno scenario che non può essere gestito con nessuno alternative consigliate, concedi un'eccezione alle vincolo delle norme, nel modo più limitato possibile, ed esaminare best practice per la gestione delle chiavi degli account di servizio.

Attivare i log di accesso ai dati per le API IAM

Per aiutarti a identificare e comprendere gli scenari di furto d'identità degli account di servizio, servizi come Compute Engine includono una sezione serviceAccountDelegationInfo nei log di controllo di Cloud. Questa sezione indica se l'account di servizio ha subito un furto d'identità e da quale utente.

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

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

Se attivi questi log, ti assicuri che venga aggiunta una voce ai log di controllo di Cloud 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 con Cloud Audit Logs

Gli account di servizio vengono comunemente utilizzati dai sistemi CI/CD per eseguire i deployment dopo 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, dei commit e delle esecuzioni della pipeline corrispondenti, e informazioni su chi ha approvato il deployment.

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

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

Modi per stabilire una correlazione tra record ed eventi di Cloud Audit Logs la cronologia del sistema CI/CD include:

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

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

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

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

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

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

Per aiutare a rintracciare l'accesso all'utente, progetta la logica dell'applicazione in modo che scriva una voce di log personalizzata ogni volta che un utente accede a una risorsa e correla le voci di log personalizzate con Cloud Audit Logs.

Passaggi successivi