Questo documento descrive le best practice consigliate per l'utilizzo dell'accesso sensibile al contesto per proteggere in modo efficace le risorse Google Cloud . L'accesso sensibile al contesto è un approccio alla sicurezza in cui controlli l'accesso degli utenti in base alla forza dell'autenticazione, alla postura del dispositivo, alla posizione di rete, alla posizione geografica o ad altri attributi. Questo approccio va oltre l'utilizzo delle identità utente di base per l'accesso di sicurezza e può aiutarti a implementare un modello di sicurezza Zero Trust per migliorare la tua security posture complessiva. Per informazioni dettagliate su come implementare l'accesso sensibile al contesto per diversi tipi di app e risorse, consulta Proteggi app e risorse utilizzando l'accesso sensibile al contesto.
Per proteggere le tue app e le tue risorse Google Cloud , puoi definire un controllo dell'accesso granulare, basato su una varietà e una combinazione di fattori contestuali. Puoi utilizzare Gestore contesto accesso per definire le policy di accesso, che contengono livelli di accesso e parametri di servizio.
Questo documento è rivolto a tutti i professionisti della sicurezza responsabili di Identity and Access Management (IAM) e della sicurezza delle risorse e delle app Google Cloud . Questo documento presuppone che tu abbia già familiarità con Gestore contesto accesso,Google Cloude la gestione di IAM.
Approcci di accesso sensibile al contesto
Quando configuri l'accesso sensibile al contesto nella tua organizzazione, devi decidere se applicare i controlli di accesso sensibile al contesto alle app, alle risorse o a entrambe. Per prendere questa decisione, è utile distinguere tra i seguenti diversi tipi di app e servizi:
- App amministrative: queste app consentono agli utenti di gestire o interagire con le risorseGoogle Cloud come istanze VM, set di dati BigQuery o bucket Cloud Storage. Esempi di app amministrative includono la console Google Cloud , Google Cloud CLI, Terraform e IAP Desktop.
- App line of business: queste app includono app web eseguite su Google Cloud e utilizzano SAML o Identity-Aware Proxy (IAP) per l'autenticazione e l'autorizzazione. Queste app vengono talvolta chiamate app interne. Esempi di app line of business includono sistemi CRM, dashboard e altre app personalizzate.
- Google Workspace e altri servizi Google: questi servizi sono forniti da Google, ma non sono correlati a Google Cloud.
Puoi distinguere ulteriormente le app line of business in base al modo in cui gestiscono l'autenticazione e l'autorizzazione:
- SAML: app che utilizzano SAML di Google Workspace per l'autenticazione. Le app SaaS rientrano spesso in questa categoria.
- IAP: app web personalizzate di cui hai eseguito il deployment dietro IAP.
- OAuth: app web o desktop personalizzate che utilizzano OAuth 2.0 e uno o più ambiti OAuthGoogle Cloud .
Il seguente diagramma di flusso mostra l'approccio di accesso sensibile al contesto più adatto per ogni tipo di app:
Il diagramma mostra i seguenti tipi di app:
App amministrative: in genere, è più importante proteggere le risorse a cui l'app amministrativa facilita l'accesso, piuttosto che l'app stessa.Google Cloud Considera i seguenti scenari:
- Un utente non può accedere a nessuna delle risorse. In questo scenario, è probabile che l'accesso a un'app amministrativa non sia così importante per l'utente.
- Un utente ha accesso a una risorsa, ma non può accedere a un'app amministrativa. In questo scenario, potrebbe essere in grado di trovare un'altra app amministrativa che non è bloccata e che gli consente di accedere alla risorsa.
Pertanto, per le app amministrative, adotta un approccio incentrato sulle risorse. Per applicare nel modo più efficace i controlli di accesso sensibile al contesto corretti alle risorse, utilizza i perimetri di servizio Virtual Private Cloud (VPC) con le regole di ingresso appropriate. Puoi integrare i perimetri di servizio VPC con le associazioni di accesso.
App per linee di business che utilizzano OAuth: per queste app, è importante proteggere l'accesso alle app stesse, nonché alle risorse che le app potrebbero utilizzare. Per proteggere le app utilizzando l'accesso sensibile al contesto, utilizza le associazioni di accesso.
App per linee di business che utilizzano IAP: sebbene IAP utilizzi OAuth, non puoi utilizzare le associazioni di accesso per proteggere le app che utilizzano IAP per autenticare gli utenti. Proteggi invece queste app utilizzando le condizioni IAM.
App line of business che utilizzano SAML: analogamente alle app line of business che utilizzano OAuth, è importante proteggere l'accesso alle app stesse, nonché alle risorse che le app potrebbero utilizzare. Per proteggere queste app, utilizza l'accesso sensibile al contesto di Google Workspace.
Google Workspace e altri servizi Google: per queste app, è importante proteggere l'accesso alle app stesse, nonché alle risorse che potrebbero utilizzare. Per proteggere queste app, utilizza l'accesso sensibile al contesto di Google Workspace.
Gestione del livello di accesso
Le sezioni seguenti descrivono le pratiche consigliate da utilizzare per la gestione dei livelli di accesso.
Crea livelli di accesso riutilizzabili
I livelli di accesso sono una risorsa globale e sono destinati a essere utilizzati tra le risorse della tua organizzazione Google Cloud . Pertanto, è meglio limitare il numero complessivo di livelli di accesso e renderli significativi e applicabili a più risorse. Considera quanto segue:
- Evita di incorporare i nomi di risorse o app specifiche nel nome di un livello di accesso.
- Evita di codificare requisiti specifici per le risorse o per le app in un livello di accesso.
- Utilizza nomi che indicano una determinata postura dell'utente o del dispositivo, ad esempio
Fully Trusted Device.
Utilizza livelli di accesso compositi
Per ridurre l'overhead di manutenzione e garantire la coerenza quando le subnet o le regioni cambiano, non ripetere gli stessi requisiti in più livelli di accesso. Invece, fai in modo che i livelli di accesso dipendano l'uno dall'altro.
Ad esempio, non elencare le stesse regioni o subnet IP attendibili in più livelli di accesso, ma crea un livello di accesso aggiuntivo denominato Trusted location. Questo livello Trusted location può fungere da dipendenza per gli altri livelli di accesso.
Esenta gli utenti con accesso di emergenza nei livelli di accesso
Per evitare un blocco accidentale, è consigliabile escludere almeno un utente con accesso di emergenza da tutti i livelli di accesso. Per assicurarti che l'esenzione venga applicata a tutte le app e le risorse a cui applichi il livello di accesso, configura l'esenzione nel livello di accesso stesso:
- Aggiungi una condizione che definisca i requisiti standard.
- Aggiungi un'altra condizione con un requisito
membersche elenchi uno o più utenti con accesso di emergenza. - Imposta la funzione di combinazione su una condizione
ORin modo che gli utenti debbano soddisfare solo una delle due condizioni.
Ad esempio, il seguente livello di accesso limita l'accesso a tre regioni, ma l'utente emergencyaccess@example.net è esente da questo requisito:
{
"name": "accessPolicies/…",
"title": "Example access level",
"basic": {
"conditions": [
{
"members": [
"user:emergencyaccess@example.net"
]
},
{
"regions": [
"DE",
"AU",
"SG"
]
}
],
"combiningFunction": "OR"
}
}
Configura un messaggio di correzione
Gli utenti della tua organizzazione potrebbero non essere consapevoli del fatto che la loro posizione, il dispositivo e altri fattori possono influire sulla loro autorizzazione ad accedere o meno a determinate app. Per tenere informati gli utenti e contribuire a ridurre le richieste di assistenza, configura un messaggio di correzione personalizzato che indichi agli utenti i passaggi da seguire per riottenere l'accesso.
Gestione delle associazioni di accesso
Le associazioni di accesso ti consentono di configurare l'accesso sensibile al contesto per le app OAuth che utilizzano uno o più ambiti Google Cloud . Le associazioni di accesso sono anche un modo efficace per applicare l'accesso sensibile al contesto per le app della linea di business.
Le sezioni seguenti descrivono le pratiche consigliate da adottare quando utilizzi le associazioni di accesso.
Utilizza un'unica associazione di accesso con impostazioni con ambito
Quando utilizzi le associazioni di accesso, devi considerare i seguenti vincoli:
- Ogni gruppo Cloud Identity può avere al massimo un'associazione di accesso.
- Se a un utente si applicano più associazioni di accesso, l'associazione di accesso meno restrittiva ha la precedenza.
Per soddisfare questi due vincoli, utilizza un'unica associazione di accesso che si applica a tutti i tuoi utenti:
- Crea un gruppo che contenga automaticamente tutti gli utenti del tuo account Cloud Identity o Google Workspace.
- Crea o utilizza un'associazione di accesso che associa un livello di accesso predefinito al gruppo. Il livello di accesso predefinito dovrebbe essere appropriato per la maggior parte degli utenti, dei dispositivi e delle app.
- Se necessario, utilizza le impostazioni di accesso limitato (
scopedAccessSettings) per assegnare livelli di accesso più deboli alle app selezionate.
Utilizza un livello di accesso predefinito rigoroso
Se un'associazione di accesso specifica sia un'impostazione di accesso con ambito sia un livello di accesso predefinito, i due livelli di accesso vengono combinati utilizzando la semantica OR.
Questo comportamento ha le seguenti implicazioni:
- Un utente deve soddisfare solo uno dei livelli di accesso per accedere all'app OAuth.
- Quando aggiungi un'impostazione di accesso con ambito per un'app OAuth, puoi ridurre i requisiti di accesso effettivi.
- Un'impostazione di accesso limitato non ha effetto se utilizza un livello di accesso più restrittivo rispetto al livello di accesso predefinito dell'associazione di accesso.
Quando selezioni un livello di accesso predefinito per un'associazione di accesso, ti consigliamo di:
- Utilizza un livello di accesso rigoroso come livello di accesso predefinito.
- Applica livelli di accesso inferiori alle singole app OAuth utilizzando le impostazioni di accesso con ambito.
Valuta la possibilità di aggiungere alcune o tutte le seguenti limitazioni al livello di accesso predefinito:
- Limitazioni relative a browser e dispositivi: richiedi agli utenti di accedere alle app utilizzando un browser Chrome gestito e un dispositivo approvato dall'amministratore.
- Limitazioni geografiche: se la tua organizzazione opera esclusivamente in determinate regioni, utilizza le limitazioni per regione per includere solo queste regioni nella lista consentita. In caso contrario, puoi utilizzare le limitazioni per regione per limitare l'accesso alle aree geografiche soggette a sanzioni o che non sono pertinenti per altri motivi.
- Limitazioni della rete IP: se gli utenti della tua organizzazione accedono aGoogle Cloud esclusivamente da determinate reti o se la tua organizzazione utilizza un proxy in uscita comune, puoi includere limitazioni della rete IP.
Non utilizzare livelli di accesso che richiedono l'autenticazione basata su certificati come livello di accesso predefinito. L'autenticazione basata su certificati è più adatta per le regole in entrata del perimetro di servizio VPC.
Gestisci le eccezioni per app
Per gestire le eccezioni al livello di accesso predefinito, aggiungi eccezioni per singole app, anziché per utenti o gruppi.
Un livello di accesso predefinito rigoroso potrebbe essere appropriato per la maggior parte delle app, ma non per tutte:
- Alcune app potrebbero essere meno sensibili e devi renderle accessibili agli utenti che non soddisfano il livello di accesso predefinito. Alcuni esempi potrebbero essere le app che devono essere accessibili a partner, ospiti o ex studenti.
- Alcune app potrebbero essere tecnicamente incompatibili con una delle limitazioni applicate dal livello di accesso predefinito.
Per esentare singole app dal livello di accesso predefinito, utilizza le impostazioni di accesso con ambito. Per ogni app interessata, aggiungi un'impostazione con ambito e assegna un livello di accesso più appropriato per la singola app.
Non creare associazioni di accesso aggiuntive per gestire le eccezioni per utente o gruppo. Le associazioni di accesso aggiuntive possono causare i seguenti problemi:
- Potresti inavvertitamente creare associazioni di accesso sovrapposte.
- Potrebbe diventare difficile determinare quali requisiti di accesso sensibile al contesto vengono applicati in modo efficace per le singole app.
Evita associazioni di accesso sovrapposte
Le associazioni di accesso sono associate ai gruppi. Se un utente è membro di più gruppi, potrebbero essere applicate più associazioni di accesso. In questo caso, i requisiti di accesso sensibile al contesto di queste associazioni di accesso vengono combinati utilizzando la semantica OR.
Questo comportamento può causare effetti indesiderati. Ad esempio, quando agli utenti è consentito unirsi ad altri gruppi, la protezione di alcune app potrebbe essere compromessa.
Per evitare queste situazioni, ti consigliamo di evitare associazioni di accesso sovrapposte:
- Riduci al minimo il numero di associazioni di accesso, idealmente a una.
- Se hai bisogno di più associazioni di accesso, assegnale a gruppi che si escludono a vicenda.
Proteggi i gruppi da modifiche non autorizzate
Per impostazione predefinita, Cloud Identity consente ai membri di un gruppo di abbandonarlo. Questo comportamento è appropriato per i gruppi di accesso, ma è problematico per i gruppi con associazioni di accesso associate. Se un utente esce da un gruppo con un'associazione di accesso, non è più soggetto ai requisiti di accesso sensibile al contesto imposti dalle associazioni di accesso. Pertanto, gli utenti possono aggirare i requisiti di accesso sensibile al contesto uscendo da un gruppo.
Utilizza sempre i gruppi di applicazione e non consentire agli utenti di uscire da un gruppo di applicazione quando configuri le associazioni di accesso. In alternativa, crea un gruppo che contenga automaticamente tutti gli utenti del tuo account Cloud Identity o Google Workspace.
Non consentire l'accesso di utenti esterni quando utilizzi le associazioni di accesso
Le associazioni di accesso interessano solo gli utenti dell'account Cloud Identity o Google Workspace a cui appartiene la tua organizzazione Google Cloud . Questi utenti sono comunque soggetti alle associazioni di accesso nella tuaorganizzazioneGoogle Cloud se tentano di accedere alle risorse in altreorganizzazioniGoogle Cloud . Questa applicazione delle associazioni di accesso agli utenti è diversa dal comportamento in altri contesti con Cloud Identity.
Se consenti agli utenti di account Cloud Identity o Google Workspace esterni di accedere alle risorse nelle tue organizzazioni Google Cloud, le associazioni di accesso non hanno alcun effetto su questi utenti.
Per assicurarti che le associazioni di accesso siano efficaci, non concedere agli utenti esterni l'accesso ad app o risorse nella tua organizzazione Google Cloud . Inoltre, non aggiungere utenti esterni ai gruppi nel tuo account Cloud Identity o Google Workspace.
Utilizza associazioni di accesso separate per il controllo della durata della sessione
Oltre al controllo dell'accesso sensibile al contesto, puoi utilizzare anche le associazioni di accesso per gestire la durata delle sessioni del browser e dei token OAuth.
Quando utilizzi le associazioni di accesso per controllare l'accesso sensibile al contesto, è meglio evitare associazioni di accesso sovrapposte.
Quando utilizzi le associazioni di accesso per controllare la durata della sessione, non creare associazioni di accesso sovrapposte. Se a un utente si applicano più associazioni di accesso di questo tipo, viene applicata solo l'associazione di accesso aggiornata più di recente, il che può portare a risultati imprevisti.
Per evitare questi risultati indesiderati, utilizza un'associazione di accesso separata per controllare la durata della sessione.
Non consentire agli utenti di agire come account di servizio
Le associazioni di accesso si applicano agli utenti di Cloud Identity e Google Workspace, ma non influiscono sui service account. Se consenti agli utenti di autenticarsi e agire come account di servizio, potrebbero essere in grado di compromettere i controlli di accesso sensibile al contesto.
Quando gli utenti possono agire come account di servizio, sono coinvolti altri rischi. Se vuoi consentire agli utenti di elevare temporaneamente i propri privilegi, ti consigliamo di utilizzare Privileged Access Manager. Non utilizzare la simulazione dell'identità dei account di servizio, se non per scopi di sviluppo.
Per ulteriori informazioni su come proteggere i service account e le relative chiavi, consulta Best practice per l'utilizzo dei service account e Best practice per la gestione delle account di servizio account.
Regole in entrata per i perimetri di servizio VPC
Le regole in entrata ti consentono di concedere l'accesso sensibile al contesto dall'esterno del perimetro di servizio alle risorse all'interno del perimetro. I perimetri di servizio VPC e le regole in entrata proteggono le risorse Google Cloud , non le singole app. Pertanto, un perimetro di servizio con regole in entrata è ideale per applicare l'accesso sensibile al contesto per strumenti amministrativi come la console Google Cloud e gcloud CLI.
Per ulteriori informazioni e best practice sui perimetri di servizio VPC, consulta Best practice per l'abilitazione dei Controlli di servizio VPC.
Le sezioni seguenti descrivono le pratiche consigliate per l'utilizzo delle regole in entrata per applicare l'accesso sensibile al contesto.
Includi l'inoltro TCP IAP come servizio limitato
Consentire agli utenti di connettersi alle istanze VM nel perimetro di servizio utilizzando SSH o RDP può essere rischioso per i seguenti motivi:
- Le regole in entrata non si applicano alle connessioni perché l'utilizzo di SSH e RDP non prevede l'accesso alle API di Google.
- Dopo che gli utenti hanno stabilito una sessione SSH o RDP, qualsiasi accesso all'API avviato dall'interno della sessione viene considerato proveniente dal perimetro di servizio. Pertanto, le regole in entrata non si applicano all'accesso all'API avviato dall'interno della sessione.
Per mitigare questi rischi, consenti l'accesso SSH e RDP alle VM solo tramite l'inoltro TCP IAP:
- Includi il servizio
iaptunnel.googleapis.comcome servizio limitato. - Configura le regole firewall che limitano l'accesso alle porte SSH e RDP tramite l'inoltro TCP di IAP.
Utilizza l'inoltro TCP IAP per assicurarti che la configurazione delle regole in entrata del perimetro di servizio VPC venga applicata a ogni tentativo di accesso SSH e RDP.
Utilizza l'accesso basato su certificati per i perimetri di servizio sensibili
Per impostazione predefinita, i token di accesso e di aggiornamento di Google non sono associati a un dispositivo e possono essere vulnerabili a furti o attacchi di replay. Per contribuire a mitigare questi rischi, puoi utilizzare l'accesso basato su certificato (CBA), che limita l'accesso ai dispositivi che possiedono un certificato X.509 attendibile.
Il CBA ti aiuta a rafforzare la sicurezza, ma questo approccio aggiunge anche ulteriori requisiti di infrastruttura:
- Il dispositivo di un utente deve avere un certificato X.509 emesso da un'autorità di certificazione interna.
- La chiave associata al certificato deve essere archiviata in modo da impedire l'esportazione non autorizzata.
- Le app client devono utilizzare l'autenticazione mutual TLS (mTLS) per connettersi alle APIGoogle Cloud .
Utilizza l'accesso basato sul contesto per proteggere l'accesso ai perimetri di servizio VPC più sensibili. Questo approccio ti consente di bilanciare la sicurezza con requisiti minimi di infrastruttura e impatto complessivo.
Collaboratori
Autore: Johannes Passing | Cloud Solutions Architect
Altro collaboratore: Ido Flatow | Cloud Solutions Architect