Panoramica degli account di servizio

Questa pagina spiega cosa sono gli account di servizio e descrive importanti considerazioni relative alla gestione degli account di servizio in ogni fase del loro ciclo di vita.

Che cosa sono gli account di servizio?

Un account di servizio è un particolare tipo di account solitamente utilizzato da un'applicazione o da un carico di lavoro di calcolo, ad esempio un'istanza Compute Engine, anziché una persona. Un account di servizio è identificato dal suo indirizzo email, che è univoco per l'account.

Le applicazioni utilizzano gli account di servizio per effettuare chiamate API autorizzate mediante l'autenticazione come account di servizio stesso o come utenti di Google Workspace o Cloud Identity tramite la delega a livello di dominio. Quando un'applicazione si autentica come account di servizio, ha accesso a tutte le risorse a cui l'account di servizio è autorizzato ad accedere.

Il modo più comune per consentire a un'applicazione di eseguire l'autenticazione come account di servizio è collegare un account di servizio alla risorsa che esegue l'applicazione. Ad esempio, puoi collegare un account di servizio a un'istanza di Compute Engine in modo che le applicazioni in esecuzione su quell'istanza possano autenticarsi come account di servizio. Quindi, puoi concedere i ruoli IAM dell'account di servizio per consentire all'account di servizio, e, per estensione, alle applicazioni sull'istanza, di accedere alle risorse di Google Cloud.

Esistono altri modi per consentire alle applicazioni di eseguire l'autenticazione come account di servizio oltre al collegamento di un account di servizio. Ad esempio, puoi configurare la federazione delle identità dei carichi di lavoro per consentire ai carichi di lavoro esterni di eseguire l'autenticazione come account di servizio oppure creare una chiave dell'account di servizio e utilizzarla in qualsiasi ambiente per ottenere token di accesso OAuth 2.0.

Per saperne di più sull'autenticazione dell'account di servizio per le applicazioni, consulta la panoramica sulle identità per i carichi di lavoro.

Anche le entità, come gli utenti e altri account di servizio, possono autenticarsi come account di servizio. Per ulteriori informazioni, consulta Utilizzo dell'identità di un account di servizio in questa pagina.

Tipi di account di servizio

In Google Cloud, sono disponibili diversi tipi di account di servizio:

  • Account di servizio gestiti dall'utente: gli account di servizio che crei e gestisci. Questi account di servizio vengono spesso utilizzati come identità per i carichi di lavoro.

  • Account di servizio predefiniti: account di servizio gestiti dall'utente che vengono creati automaticamente quando si abilitano determinati servizi Google Cloud. Sei responsabile di gestire questi account di servizio.

  • Account di servizio gestiti da Google: account di servizio gestiti e creati da Google che consentono ai servizi di accedere alle risorse per tuo conto.

Per saperne di più sui diversi tipi di account di servizio, vedi Tipi di account di servizio.

Credenziali dell'account di servizio

Le applicazioni e le entità si autenticano come account di servizio eseguendo una delle seguenti operazioni:

  • Ottenere credenziali di breve durata. In molti casi, ad esempio account di servizio e comandi collegati che utilizzano il flag dell'interfaccia a riga di comando gcloud di --impersonate-service-account, queste credenziali vengono ottenute automaticamente, quindi non è necessario crearle o gestirle autonomamente.
  • Utilizzare una chiave dell'account di servizio per firmare un token web JSON (JWT) e scambiarlo con un token di accesso. Le chiavi dell'account di servizio rappresentano un rischio per la sicurezza se non sono gestite correttamente. Se possibile, utilizza un metodo diverso per autenticarti.

Per scoprire di più sull'autenticazione dell'account di servizio, consulta Credenziali dell'account di servizio.

Furto d'identità dell'account di servizio

Quando un'entità, ad esempio un utente o un altro account di servizio, utilizza credenziali di breve durata per eseguire l'autenticazione come account di servizio, si parla di furto d'identità nell'account di servizio. In genere, il furto d'identità viene utilizzato per concedere temporaneamente a un utente un accesso elevato, in quanto consente agli utenti di assumere temporaneamente i ruoli di cui dispone l'account di servizio.

Un'entità può utilizzare la rappresentazione dell'account di servizio per eseguire i comandi come account di servizio. Tuttavia, un'entità non può utilizzare la rappresentazione dell'account di servizio per accedere alla console Google Cloud.

Se un'entità accede alle risorse durante il furto d'identità di un account di servizio, la maggior parte degli audit log include sia la sua identità sia l'identità dell'account di servizio utilizzato per rubare l'identità. Per saperne di più, consulta Interpretazione dei log di controllo.

Di seguito sono riportati alcuni esempi di furto d'identità dell'account di servizio:

  • Un utente esegue un comando dell'interfaccia a riga di comando gcloud con il flag --impersonate-service-account. Questo flag consente all'interfaccia a riga di comando gcloud di creare credenziali di breve durata per l'account di servizio, quindi esegue il comando con quelle credenziali.

    In questo caso, l'utente si spaccia per l'account di servizio.

  • Un utente crea manualmente le credenziali di breve durata utilizzando l'API Service Account Credentials, quindi le utilizza per l'autenticazione.

    In questo caso, l'utente si spaccia per l'account di servizio.

I seguenti non sono esempi di rappresentazione dell'account di servizio:

  • Un utente collega un account di servizio a una risorsa.

    L'utente non autentica come account di servizio quando lo collega a una risorsa, quindi non ruba l'identità dell'account di servizio.

  • Il codice in esecuzione su una risorsa effettua chiamate API autorizzate utilizzando l'account di servizio collegato di una risorsa.

    Il codice non ha un'identità, quindi non può impersonare un account di servizio. Quando il codice in esecuzione su una risorsa viene autenticato come account di servizio associato della risorsa, l'unica identità pertinente è quella dell'account di servizio.

  • Un utente o un'applicazione utilizza una chiave dell'account di servizio per eseguire l'autenticazione come account di servizio.

    L'utilizzo di una chiave dell'account di servizio per l'autenticazione come account di servizio richiede solo un'identità: quella dell'account di servizio. Poiché è coinvolta una sola identità, l'uso di una chiave non è la rappresentazione dell'account di servizio.

Per informazioni sulle autorizzazioni necessarie per impersonare un account di servizio, consulta Ruoli per la gestione e il furto d'identità degli account di servizio.

Account di servizio e domini di Google Workspace

A differenza degli account utente, gli account di servizio non appartengono al dominio Google Workspace. Se condividi asset di Google Workspace, come documenti o eventi, con tutto il dominio Google Workspace, questi non vengono condivisi con gli account di servizio. Analogamente, gli asset Google Workspace creati da un account di servizio non vengono creati nel dominio Google Workspace. Di conseguenza, i tuoi amministratori di Google Workspace e Cloud Identity non possono possedere o gestire questi asset.

Autorizzazioni account di servizio

Gli account di servizio sono principali. Ciò significa che puoi concedere agli account di servizio l'accesso alle risorse Google Cloud. Ad esempio, potresti concedere a un account di servizio il ruolo Amministratore Compute (roles/compute.admin) su un progetto. Quindi, l'account di servizio sarà in grado di gestire le risorse Compute Engine nel progetto.

Tuttavia, anche gli account di servizio sono risorse. Ciò significa che puoi consentire ad altre entità di accedere a un account di servizio, ovvero creare, gestire e impersonare. Ad esempio, potresti concedere a un utente il ruolo Utente account di servizio (roles/iam.serviceAccountUser) su un account di servizio. Quindi, l'utente sarà in grado di impersonare l'account di servizio.

Le sezioni seguenti spiegano come gestire gli account di servizio come entità e come risorse.

Account di servizio come entità

Poiché gli account di servizio sono entità, puoi consentire a un account di servizio di accedere alle risorse del progetto assegnandogli un ruolo, proprio come faresti per qualsiasi altra entità. Ad esempio, se vuoi consentire all'account di servizio dell'applicazione di accedere agli oggetti in un bucket Cloud Storage, puoi concedere all'account di servizio il ruolo Visualizzatore oggetti Storage (roles/storage.objectViewer) nel bucket.

Come per tutti i tipi di entità, devi concedere all'account di servizio solo l'insieme minimo di autorizzazioni necessarie per raggiungere il suo obiettivo.

Come con altre entità, puoi aggiungere account di servizio a un gruppo Google e concedere ruoli al gruppo. Tuttavia, l'aggiunta di account di servizio ai gruppi non è una best practice. Gli account di servizio vengono utilizzati dalle applicazioni e probabilmente ogni applicazione ha i propri requisiti di accesso.

Per scoprire come concedere i ruoli alle entità, inclusi gli account di servizio, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.

Account di servizio come risorse

Anche gli account di servizio sono risorse che possono avere i propri criteri di autorizzazione. Di conseguenza, puoi consentire ad altre entità di accedere a un account di servizio assegnando loro un ruolo nell'account di servizio o su una delle risorse padre dell'account di servizio. Ad esempio, per consentire a un utente di assumere l'identità di un account di servizio, puoi concedergli il ruolo Utente account di servizio (roles/iam.serviceAccountUser) nell'account di servizio.

Quando concedi un ruolo che consente a un utente di impersonare un account di servizio, tieni presente che l'utente può accedere a tutte le risorse a cui può accedere l'account di servizio. Fai attenzione quando consenti agli utenti di impersonare account di servizio con privilegi elevati, come gli account di servizio predefiniti di Compute Engine e App Engine.

Per ulteriori informazioni sui ruoli che puoi concedere alle entità per gli account di servizio, consulta Autorizzazioni per gli account di servizio.

Per scoprire come concedere un ruolo a un'entità su un account di servizio, consulta Gestire l'accesso agli account di servizio.

Ciclo di vita di un account di servizio

Durante la gestione dei progetti, è probabile che creerai, gestirai ed elimini molti account di servizio diversi. Questa sezione descrive le considerazioni chiave da eseguire per gestire gli account di servizio nelle varie fasi del loro ciclo di vita.

Dove creare gli account di servizio

Ogni account di servizio si trova in un progetto. Dopo aver creato un account di servizio, non puoi spostarlo in un altro progetto.

Esistono alcuni modi per organizzare gli account di servizio in progetti:

  • Crea account di servizio e risorse nello stesso progetto.

    Questo approccio semplifica l'uso degli account di servizio. Tuttavia, può essere difficile tenere traccia degli account di servizio quando sono distribuiti in molti progetti.

  • Centralizza gli account di servizio in progetti separati.

    Questo approccio consente di inserire tutti gli account di servizio della tua organizzazione in un numero ridotto di progetti, semplificandone la gestione. Tuttavia, è necessaria una configurazione aggiuntiva se colleghi account di servizio alle risorse in altri progetti, il che consente a queste risorse di utilizzare l'account di servizio come identità.

    Quando un account di servizio si trova in un progetto e accede a una risorsa in un altro progetto, in genere devi abilitare l'API per quella risorsa in entrambi i progetti. Ad esempio, se hai un account di servizio nel progetto my-service-accounts e un'istanza Cloud SQL nel progetto my-application, devi abilitare l'API Cloud SQL sia in my-service-accounts che in my-application.

    Per impostazione predefinita, puoi creare fino a 100 account di servizio in un progetto. Se devi creare altri account di servizio, richiedi un aumento della quota.

Per informazioni su come creare un account di servizio, consulta l'articolo Creare gli account di servizio.

Impedisci la creazione di account di servizio

Per controllare meglio dove vengono creati gli account di servizio, può essere opportuno impedire la creazione di account di servizio in alcuni progetti della tua organizzazione.

Puoi impedire la creazione di account di servizio applicando il constraints/iam.disableServiceAccountCreation vincolo dei criteri dell'organizzazione in un'organizzazione, un progetto o una cartella.

Prima di applicare questo vincolo, considera le seguenti limitazioni:

Monitora gli account di servizio

Man mano che crei sempre più account di servizio, potresti perdere di volta in volta l'account di servizio utilizzato per quale scopo.

Il nome visualizzato di un account di servizio è utile per acquisire ulteriori informazioni sull'account di servizio, ad esempio lo scopo dell'account di servizio o una persona di contatto per l'account. Per i nuovi account di servizio, puoi compilare il nome visualizzato durante la creazione dell'account di servizio. Per gli account di servizio esistenti, utilizza il metodo serviceAccounts.update() per modificare il nome visualizzato.

Utilizzare gli account di servizio con Compute Engine

Le istanze di Compute Engine devono essere eseguite come account di servizio per poter accedere ad altre risorse Google Cloud. Per proteggere le tue istanze di Compute Engine, considera quanto segue:

  • Puoi creare istanze nello stesso progetto con account di servizio diversi. Per modificare l'account di servizio di un'istanza dopo la creazione, utilizza il metodo instances.setServiceAccount.

  • Per impostare l'autorizzazione per gli account di servizio collegati, devi configurare gli ambiti di accesso oltre ai ruoli IAM.

  • Poiché le istanze dipendono dai loro account di servizio per avere accesso alle risorse Google Cloud, evita di eliminare gli account di servizio quando sono ancora utilizzati dalle istanze in esecuzione.

Per saperne di più sull'utilizzo degli account di servizio con Compute Engine, consulta Account di servizio nella documentazione di Compute Engine.

Identificare gli account di servizio inutilizzati

Dopo qualche tempo, nei tuoi progetti potresti avere account di servizio che non usi più.

Poiché gli account di servizio inutilizzati creano un rischio per la sicurezza non necessario, ti consigliamo di disattivare gli account di servizio inutilizzati e poi di eliminare gli account di servizio quando hai la certezza che non siano più necessari. Puoi utilizzare i seguenti metodi per identificare gli account di servizio inutilizzati:

Puoi anche utilizzare le metriche di utilizzo dell'account di servizio per monitorare l'utilizzo dell'account di servizio e della chiave in generale.

Se sei un cliente Security Command Center Premium, puoi utilizzare il servizio Event Threat Detection per ricevere una notifica quando un account di servizio inattivo attiva un'azione. Gli account di servizio inattivi sono account di servizio inattivi da più di 180 giorni. Una volta utilizzato, l'account di servizio non è più inattivo.

Elimina account di servizio

Prima di eliminare un account di servizio, disattivalo per assicurarti che non sia necessario. Gli account di servizio disattivati possono essere riattivati se sono ancora in uso.

Dopo aver confermato che un account di servizio non è necessario, puoi eliminarlo.

Ricreare account di servizio eliminati

Puoi eliminare un account di servizio e quindi crearne uno nuovo con lo stesso nome.

Quando elimini un account di servizio, le relative associazioni di ruolo non vengono eliminate immediatamente. Le associazioni di ruoli elencano invece l'account di servizio con il prefisso deleted:. Per un esempio, consulta Criteri con entità eliminate.

Se crei un nuovo account di servizio con lo stesso nome di un account di servizio eliminato di recente, le vecchie associazioni potrebbero continuare a esistere; tuttavia, non verranno applicate al nuovo account di servizio anche se entrambi gli account hanno lo stesso indirizzo email. Questo comportamento si verifica perché agli account di servizio viene assegnato un ID univoco all'interno di Identity and Access Management (IAM) al momento della creazione. Internamente, tutte le associazioni di ruoli vengono concesse utilizzando questi ID, non l'indirizzo email dell'account di servizio. Di conseguenza, le eventuali associazioni di ruoli esistenti per un account di servizio eliminato non si applicano a un nuovo account di servizio che utilizza lo stesso indirizzo email.

Analogamente, se colleghi un account di servizio a una risorsa, elimini l'account di servizio e crei un nuovo account di servizio con lo stesso nome, il nuovo account di servizio non verrà associato alla risorsa.

Per evitare questo comportamento imprevisto, valuta la possibilità di utilizzare un nuovo nome univoco per ogni account di servizio. Inoltre, se elimini accidentalmente un account di servizio, puoi provare a ripristinarlo anziché crearne uno nuovo.

Se non puoi annullare l'eliminazione dell'account di servizio originale e devi creare un nuovo account di servizio con lo stesso nome e gli stessi ruoli, devi concedere i ruoli al nuovo account di servizio. Per maggiori dettagli, consulta Criteri con entità eliminate.

Se è necessario che il nuovo account di servizio sia collegato alle stesse risorse dell'account di servizio originale, procedi in uno dei seguenti modi:

Passaggi successivi

Provalo

Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $ di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

Inizia gratuitamente