Questo documento descrive best practice, scenari e procedure per revocare l'accesso di un utente a un progetto Google Cloud . Poiché ogni attività ha politiche e carichi di lavoro diversi, ti consigliamo di utilizzare questo documento per elaborare politiche e procedure personalizzate che ti consentano di revocare l'accesso in modo coerente e tempestivo.
Quando un dipendente lascia la tua azienda, il tuo rapporto con un collaboratore termina o un collaboratore passa ad altri progetti, ci sono alcune cose che devi fare per revocare l'accesso non necessario alle tue risorse cloud.
Alcuni di questi processi sono facoltativi. Devi determinare quale di questi passaggi eseguire in base alle tue esigenze di sicurezza, ai prodotti in uso e alla fiducia nella persona a cui viene revocato l'accesso.
Best practice per la configurazione del progetto
Puoi migliorare la capacità del tuo progetto di revocare in modo efficiente l'accesso degli utenti facendo scelte ponderate al momento della configurazione.
Federare gli account utente con il tuo provider di identità esistente
Quando federi gli account utente con il tuo provider di identità esistente, assicurati di propagare gli eventi di sospensione ed eliminazione degli utenti. Con la propagazione, quando sospendi o rimuovi un account utente dal tuo provider di identità, l'utente perde anche l'accesso alle risorse Google Cloud .
Per saperne di più, consulta le best practice per la federazione Google Cloud con un provider di identità esterno.
Per altre best practice relative all'identità, consulta Best practice per la pianificazione di account e organizzazioni.
Per informazioni sulla federazione delle identità per la forza lavoro, consulta Federazione delle identità per la forza lavoro.
Valuta la possibilità di utilizzare Google Gruppi per gestire l'accesso alle risorse di progetto
Google Gruppi ti consente di organizzare gli utenti in base all'appartenenza al team, ai requisiti di accesso o ad altri criteri. Dopo aver creato Google Gruppi, puoi assegnare l'accesso a Google Cloud progetti e risorse in base all'iscrizione al gruppo. Quando un utente passa a un altro team o a un'altra funzione lavorativa, puoi spostare il suo account utente in un altro gruppo, il che rimuove automaticamente l'accesso concesso dalle norme di autorizzazione al gruppo precedente.
L'utilizzo di Google Gruppi non è appropriato in tutte le circostanze. Ad esempio, non devi utilizzare gruppi basati solo sulla struttura organizzativa della tua attività per gestire l'accesso. Per le best practice sull'utilizzo dei gruppi, consulta Best practices for using Google Groups.
Per saperne di più, vedi Gestire i gruppi nella Google Cloud console e Creare un gruppo nell'organizzazione
Utilizzare OS Login
Utilizza OS Login anziché chiavi SSH basate su metadati in modo che le chiavi autorizzate dell'utente siano collegate alla sua identità Google. Quando rimuovi un account utente, le chiavi autorizzate e l'accesso alle VM vengono revocati automaticamente. Per saperne di più, consulta Utilizza OS Login per garantire una valutazione continua dell'accesso in base alle policy IAM.
Per istruzioni, vedi Configura OS Login.
Limitare l'accesso dagli account utente esterni
Non concedere agli utenti esterni l'accesso al progetto perché non puoi controllare il
ciclo di vita di questi account utente. Per limitare gli utenti esterni, utilizza il vincolo
iam.allowedPolicyMemberDomains
dell'elenco.
Per istruzioni, vedi Limitazione delle identità per dominio.
Utilizzare i proxy di autenticazione con i database
I proxy di autenticazione consentono di collegare il ciclo di vita delle credenziali del database al ciclo di vita di un'identità Google. Quando sospendi o elimini un account utente in Cloud Identity o Google Workspace, l'accesso ai database viene automaticamente revocato.
Per saperne di più, consulta proxy di autenticazione Cloud SQL e proxy di autenticazione AlloyDB per PostgreSQL.
Prepararsi per la rotazione delle credenziali
Progetta i tuoi progetti e le tue risorse in modo da consentire la rotazione non distruttiva delle credenziali a livello di progetto. Si tratta di secret collegati al progetto stesso, come chiavi delaccount di serviziot, client secret OAuth e secret specifici dell'applicazione come le password root del database. Per saperne di più, consulta Rispondere a credenziali Google Cloud compromesse.
Limitare le chiavi API
Quando crei e gestisci le chiavi API, limita l'insieme di siti web, indirizzi IP e app che possono utilizzarle. Un account utente con ruoli come Visualizzatore o Amministratore chiavi API può visualizzare le chiavi API del tuo progetto, quindi qualsiasi chiave senza restrizioni deve essere ruotata o eliminata per revocare l'accesso alla fatturazione. Per ulteriori informazioni, vedi Proteggere una chiave API.
Monitorare le autorizzazioni di accesso
Il monitoraggio attento dell'accesso contribuisce a mitigare il potenziale abuso di accesso. Puoi utilizzare IAM Role Recommender per monitorare l'utilizzo dei ruoli e contribuire a far rispettare il principio del privilegio minimo. Inoltre, le funzionalità di Cloud Infrastructure Entitlement Management (CIEM) di Security Command Center ti consentono di gestire quali identità hanno accesso a quali risorse nelle tue implementazioni e di mitigare le potenziali vulnerabilità derivanti da errori di configurazione.
Utilizza l'accesso uniforme a livello di bucket per Cloud Storage
L'accesso uniforme a livello di bucket ti consente di utilizzare solo IAM per gestire le autorizzazioni per i tuoi bucket Cloud Storage. Utilizza l'accesso uniforme a livello di bucket insieme ad altre controllo dell'accesso dell'accesso per definire con maggiore precisione chi può accedere ai contenuti nei tuoi bucket.
Best practice aggiuntive
Oltre alle best practice descritte in questo documento, esamina le seguenti best practice:
- Best practice per lavorare con gli account di servizio
- Decidere la sicurezza per la tua zona di Google Cloud destinazione
- Verifica esplicitamente ogni tentativo di accesso
Scenari per la revoca dell'accesso ai Google Cloud progetti
Se hai implementato le best practice elencate in Best practice per la configurazione del progetto, la seguente tabella riassume come revocare l'accesso.
| Scenario | Revoca delle opzioni di accesso |
|---|---|
| Un dipendente lascia la tua azienda. | Se configuri la federazione
tra Cloud Identity o Google Workspace con il provisioning automatico degli utenti,
la revoca dell'accesso può avvenire automaticamente. Se non hai seguito le best practice e hai concesso l'accesso alle tue risorse alle identità utente esterne, devi rimuovere manualmente le identità dai tuoi progetti e dalle tue risorse. |
| Un dipendente cambia la sua funzione lavorativa. | Rimuovi il dipendente dal gruppo del team. |
| Termina un contratto. | Se configuri la federazione
tra Cloud Identity o Google Workspace con il provisioning automatico degli utenti,
la revoca dell'accesso può avvenire automaticamente. Se non hai seguito le best practice e hai concesso alle identità utente esterne l'accesso alle tue risorse, devi rimuovere manualmente le identità dai tuoi progetti e dalle tue risorse. |
| Un account è stato compromesso. | Per istruzioni, vedi Rispondere a credenzialiGoogle Cloud compromesse. |
Revoca l'accesso
Se hai fatto scelte giuste nella configurazione del progetto, le seguenti procedure saranno un modo efficiente per revocare l'accesso di una persona.
Per determinare a quali risorse ha accesso una persona, utilizza Policy Analyzer. Per istruzioni, vedi Analizzare le policy IAM.
Eliminare l'account utente dal provider di identità
Se l'utente lascia la tua organizzazione e hai federato Cloud Identity o Google Workspace con il tuo provider di identità, con il provisioning automatico degli utenti, la revoca dell'accesso può avvenire automaticamente.
Per informazioni sull'eliminazione degli utenti della federazione delle identità per la forza lavoro, consulta Eliminare gli utenti della federazione delle identità per la forza lavoro e i relativi dati.
Revocare le sessioni utente del pool di forza lavoro
Se sospetti che le credenziali di un utente della forza lavoro siano compromesse o se vuoi terminare immediatamente le sessioni attive prima del completamento dell'eliminazione, revoca le sessioni dell'utente.
Per ulteriori informazioni, consulta Revocare le sessioni utente della federazione delle identità per la forza lavoro.
Spostare l'account in un altro gruppo
Se l'utente cambia ruolo, rimuovi il suo account dai gruppi Google attuali. Se hai federato Cloud Identity o Google Workspace con il tuo provider di identità per gestire l'iscrizione al gruppo, la revoca dell'accesso può avvenire automaticamente.
Per saperne di più, consulta Visualizzare e modificare i dettagli del gruppo.
Rimuovi l'account utente dalle policy di autorizzazione IAM
Per rimuovere un account utente dai criteri di autorizzazione a livello di progetto:
Nella console Google Cloud , vai alla pagina Autorizzazioni IAM.
Seleziona il progetto da cui vuoi rimuovere un account utente.
Seleziona la casella di controllo accanto alla riga contenente l'account utente che vuoi rimuovere dall'elenco dei membri, quindi fai clic su Rimuovi.
Per verificare altre posizioni in cui è possibile impostare la policy di autorizzazione, incluse cartelle, organizzazione o singole risorse, consulta Verificare che le autorizzazioni siano state rimosse.
Ruota le credenziali del progetto
Se la persona a cui stai revocando l'accesso aveva accesso a credenziali a livello di progetto, come chiavi account di servizio, secret del client OAuth o chiavi API, devi ruotarle.
Ruota le chiavi del account di servizio
Se utilizzi le chiavi del account di servizio per l'autenticazione a un service account, devi ruotarle. Inoltre, valuta se la persona potrebbe aver avuto accesso alle chiavi del account di servizio al di fuori degli strumenti Google Cloud, ad esempio il repository del codice sorgente o le configurazioni dell'applicazione.
Nella console Google Cloud , vai alla pagina Credenziali API.
Fai clic sul nome dell'account di servizio da modificare.
Nella scheda Chiave, fai clic su Aggiungi chiave.
Fai clic su Crea nuova chiave.
Scegli il tipo di chiave che vuoi creare. Nella maggior parte dei casi, è consigliabile utilizzare JSON, ma P12 è disponibile per la compatibilità con le versioni precedenti del codice che dipende da questo formato.
Fai clic su Crea. Un file contenente la nuova chiave verrà scaricato automaticamente tramite il browser. Esegui il deployment di questa chiave in qualsiasi applicazione che ne ha bisogno.
Dopo aver verificato che la nuova chiave funzioni come previsto, torna alla pagina delle credenziali ed elimina la vecchia chiave associata a questoaccount di serviziot.
Ruotare i secret dell'ID client OAuth
I ID client secret OAuth non forniscono alcun accesso diretto al tuo progetto. Tuttavia, se un malintenzionato conosce il ID client secret OAuth, può falsificare la tua applicazione e richiedere l'accesso agli Account Google dei tuoi utenti da un'applicazione dannosa.
Potresti dover ruotare i segreti dell'ID client OAuth se la persona a cui viene revocato l'accesso ha mai avuto accesso al segreto, anche nel repository del codice sorgente, nelle configurazioni dell'applicazione o tramite i ruoli IAM.
Nella console Google Cloud , vai alla pagina Credenziali API.
Fai clic sul nome dell'ID client OAuth 2.0 da modificare.
Nella pagina ID client, fai clic su Reimposta secret.
Fai clic su Reimposta nella finestra di dialogo di conferma per revocare immediatamente il vecchio segreto e impostarne uno nuovo. Tieni presente che tutti gli utenti attivi dovranno autenticarsi nuovamente alla prossima richiesta.
Esegui il deployment del nuovo secret in tutte le applicazioni che ne hanno bisogno.
Ruotare le chiavi API
Le chiavi API non forniscono l'accesso al tuo progetto o ai dati dei tuoi utenti, ma controllano a chi Google fattura le richieste API. Un account utente con ruoli come Visualizzatore o Amministratore chiavi API può visualizzare le chiavi API del tuo progetto. Se hai chiavi senza restrizioni, devi eliminarle o rigenerarle quando revochi l'accesso di qualcuno al tuo progetto.
Nella console Google Cloud , vai alla pagina Credenziali API.
Fai clic sul nome della chiave API da modificare.
Fai clic su Rigenera chiave.
In una finestra di dialogo verrà visualizzata la chiave appena creata. Esegui il deployment di questa chiave in qualsiasi applicazione utilizzando la chiave che vuoi sostituire.
Dopo aver verificato che le tue applicazioni funzionano come previsto con la nuova chiave, torna alla pagina delle credenziali ed elimina la vecchia chiave senza restrizioni.
Revocare l'accesso alle VM
Se la persona a cui stai revocando l'accesso non ha accesso di accesso a nessuna delle VM del progetto, puoi saltare questo passaggio.
Rimuovi tutte le chiavi SSH a livello di progetto a cui la persona aveva accesso.
Su ogni VM a cui la persona aveva accesso SSH, rimuovi tutte le chiavi a livello di istanza.
Rimuovi l'account della persona da tutte le VM a cui aveva accesso.
Controlla la presenza di applicazioni sospette che la persona potrebbe aver installato per fornire l'accesso backdoor alla VM. Se non hai la certezza della sicurezza di qualsiasi codice in esecuzione sulla VM, ricrealo e rifai il deployment delle applicazioni di cui hai bisogno dall'origine.
Verifica che le impostazioni del firewall della VM non siano state modificate rispetto alla configurazione pianificata o prevista.
Se crei nuove VM da immagini di base personalizzate, verifica che le immagini di base non siano state modificate in modo da compromettere la sicurezza delle nuove VM.
Revocare l'accesso ai database
Se il tuo progetto non utilizza risorse Cloud SQL o AlloyDB per PostgreSQL, puoi saltare questo passaggio.
Per revocare l'accesso a un database Cloud SQL, completa i seguenti passaggi:
Nella console Google Cloud , vai alla pagina Istanze SQL.
Fai clic sull'ID istanza del database per cui vuoi revocare l'accesso.
Nel menu a sinistra, fai clic su Collegamenti.
Verifica che l'elenco degli indirizzi IP in Reti autorizzate e l'elenco delle app in Autorizzazione App Engine corrispondano a quanto previsto. Se la persona a cui stai cercando di revocare l'accesso ha accesso alle reti o alle applicazioni elencate qui, può accedere a questo database.
Nel menu a sinistra, fai clic su Utenti.
Elimina o modifica la password di tutti gli account utente a cui la persona aveva accesso. Assicurati di aggiornare tutte le applicazioni che dipendono da questi account utente.
Per revocare l'accesso a un database AlloyDB per PostgreSQL, consulta Rimuovere un utente IAM o un account di servizio da un cluster.
Esegui di nuovo il deployment di App Engine
Per impostazione predefinita, le app App Engine hanno accesso a un account di servizio che è un editor del progetto associato. I gestori delle richieste di App Engine possono eseguire operazioni come creare nuove VM e leggere o modificare i dati in Cloud Storage. Qualcuno con la possibilità di eseguire il deployment del codice in App Engine potrebbe utilizzare questo account di servizio per aprire una backdoor nel tuo progetto. Se ti preoccupa l'integrità del codice delle app di cui è stato eseguito il deployment, potresti voler rifare il deployment (inclusi i moduli) con un'immagine nota e valida dal sistema di controllo della versione.
Verificare che le autorizzazioni siano state rimosse
Puoi verificare le autorizzazioni a livello di organizzazione, progetto o utilizzando Policy Analyzer.
Per trovare le risorse a cui un determinato utente potrebbe avere accesso a livello di organizzazione, utilizza il metodo search-all-iam-policies in Google Cloud CLI. Ad esempio, per determinare se un utente ha accesso alle tue risorse, esegui:
gcloud asset search-all-iam-policies --scope='organizations/ORGANIZATION_ID --query='policy:IDENTITY'
Dove:
ORGANIZATION_IDè il numero della tua organizzazione.IDENTITYè l'identità dell'utente, ad esempio un indirizzo email.
Per verificare le autorizzazioni di un progetto, consulta Autorizzazioni di un'entità su un progetto.
Per verificare le autorizzazioni utilizzando Policy Analyzer, consulta Determina a quali risorse può accedere un'entità.
Passaggi successivi
Consulta Rispondere alle credenziali compromesse Google Cloud.
Scopri di più Best practice per proteggere le credenziali dello sviluppatore.
Crea una policy di negazione per specificare a quali autorizzazioni l'utente non può più accedere.