Questo documento descrive le best practice consigliate per l'utilizzo dell'accesso sensibile al contesto per proteggere in modo efficace le tue risorse Google Cloud . L'accesso sensibile al contesto è un approccio alla sicurezza in cui controlli l'accesso degli utenti in base alla solidità dell'autenticazione, alla postura del dispositivo, alla posizione di rete, alla posizione geografica o ad altri attributi. Questo approccio va oltre l'utilizzo di identità utente di base per l'accesso alla sicurezza e può aiutarti a implementare un modello di sicurezza zero trust per migliorare la tua postura di sicurezza complessiva. Per informazioni dettagliate su come implementare l'accesso sensibile al contesto per diversi tipi di app e risorse, vedi Proteggere 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 combinazione di fattori contestuali. Puoi utilizzare Gestore contesto accesso per definire criteri di accesso, che contengono livelli di accesso e parametri di servizio.
Questo documento è destinato a qualsiasi professionista della sicurezza responsabile di Identity and Access Management (IAM) e della sicurezza di risorse e app. Google Cloud Questo documento presuppone che tu abbia già familiarità con Gestore contesto accesso, Google Cloude la gestione IAM.
Approcci di accesso sensibile al contesto
Quando configuri l'accesso sensibile al contesto nella tua organizzazione, devi decidere se applicare i controlli dell'accesso sensibile al contesto ad app, risorse o 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 Google Cloud risorse 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 che vengono 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 alla gestione dell'autenticazione e dell'autorizzazione:
- SAML: app che utilizzano SAML di Google Workspace per l'autenticazione. Le app SaaS spesso rientrano in questa categoria.
- IAP: app web personalizzate che hai implementato dietro IAP.
- OAuth: app web o desktop personalizzate che utilizzano OAuth 2.0 e uno o più ambiti OAuth.Google 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 risorseGoogle Cloud a cui l'app amministrativa facilita l'accesso, piuttosto che l'app stessa. Considera i seguenti scenari:
- Un utente non può accedere a nessuna risorsa. 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 non bloccata che gli consenta 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 sensibili al contesto 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 i binding di accesso.
App line-of-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 i binding di accesso.
App line-of-business che utilizzano IAP: sebbene IAP utilizzi OAuth, non puoi utilizzare i binding 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: in modo simile 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 le app 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 quando gestisci i livelli di accesso.
Creare livelli di accesso riutilizzabili
I livelli di accesso sono una risorsa globale e sono pensati per essere utilizzati in tutte 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 risorse o app in un livello di accesso.
- Utilizza nomi che affermano una determinata postura dell'utente o del dispositivo, ad esempio
Fully Trusted Device.
Utilizzare 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. Lascia invece 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 chiamato Trusted location. Questo livello Trusted location può fungere
da dipendenza per gli altri livelli di accesso.
Esentare 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 si applichi 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 definisce i tuoi requisiti regolari.
- Aggiungi un'altra condizione con un
requisito
membersche elenca 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"
}
}
Configurare un messaggio di correzione
Gli utenti della tua organizzazione potrebbero non essere consapevoli che la loro posizione, il dispositivo e altri fattori possono influire sulla loro autorizzazione ad accedere a determinate app. Per tenere informati gli utenti e contribuire a ridurre le richieste di assistenza, configura un messaggio di correzione personalizzato che fornisca agli utenti i passaggi da seguire per riacquistare l'accesso.
Gestione delle associazioni di accesso
I binding di accesso ti consentono di configurare l'accesso sensibile al contesto per le app OAuth che utilizzano uno o più Google Cloud ambiti. I binding di accesso sono anche un modo efficace per applicare l'accesso sensibile al contesto alle app line-of-business.
Le sezioni seguenti descrivono le pratiche consigliate da utilizzare quando utilizzi i binding di accesso.
Utilizzare un singolo binding di accesso con impostazioni con ambito
Quando utilizzi i binding di accesso, devi tenere conto dei seguenti vincoli:
- Ogni gruppo Cloud Identity può avere al massimo un binding di accesso.
- Se a un utente si applica più di un binding di accesso, ha la precedenza il binding di accesso meno restrittivo.
Per soddisfare questi due vincoli, utilizza un unico binding di accesso che si applichi 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 associ un livello di accesso predefinito al gruppo. Il livello di accesso predefinito deve essere appropriato per la maggior parte di utenti, dispositivi e app.
- Se necessario, utilizza le
impostazioni di accesso con ambito (
scopedAccessSettings) per assegnare livelli di accesso più deboli alle app selezionate.
Utilizzare 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 con ambito non ha effetto se utilizza un livello di accesso più restrittivo del livello di accesso predefinito dell'associazione di accesso.
Quando selezioni un livello di accesso predefinito per un binding di accesso, ti consigliamo di:
- Utilizza un livello di accesso restrittivo come livello di accesso predefinito.
- Applica livelli di accesso inferiori a 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 del browser e del dispositivo: 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 regionali per includere solo queste regioni nella lista consentita. In caso contrario, puoi utilizzare le limitazioni regionali per limitare l'accesso alle aree geografiche soggette a sanzioni o che non sono pertinenti per altri motivi.
- Limitazioni di rete IP: se gli utenti della tua organizzazione accedono a Google Cloud esclusivamente da determinate reti o se la tua organizzazione utilizza un proxy di uscita comune, puoi includere limitazioni di 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 di ingresso del perimetro di servizio VPC.
Gestire 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 includere app che devono essere accessibili a partner, ospiti o ex studenti.
- Alcune app potrebbero essere tecnicamente incompatibili con una delle limitazioni imposte 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 ulteriori associazioni di accesso per gestire le eccezioni per utente o gruppo. I binding di accesso aggiuntivi possono causare i seguenti problemi:
- Potresti creare inavvertitamente 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
I binding di accesso sono associati ai gruppi. Se un utente è membro di più gruppi, potrebbero essere applicati più binding 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 di partecipare ad altri gruppi, la protezione di alcune app potrebbe essere compromessa.
Per evitare queste situazioni, ti consigliamo di evitare i binding di accesso sovrapposti:
- Riduci al minimo il numero di associazioni di accesso, idealmente a una.
- Se hai bisogno di più binding di accesso, assegnali a gruppi mutualmente esclusivi.
Proteggere i gruppi da modifiche non autorizzate
Per impostazione predefinita, Cloud Identity consente ai membri del gruppo di uscire da un gruppo. Questo comportamento è appropriato per i gruppi di accesso, ma è problematico per i gruppi con binding di accesso associati. Se un utente esce da un gruppo con un binding di accesso associato, non è più soggetto ai requisiti di Accesso sensibile al contesto imposti dai binding di accesso. Pertanto, gli utenti possono aggirare i requisiti dell'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 i binding 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 agli utenti esterni quando utilizzi i binding di accesso
I binding di accesso influiscono solo sugli utenti dell'account Cloud Identity o Google Workspace a cui appartiene la tua Google Cloud organizzazione. Questi utenti sono comunque soggetti ai binding di accesso nella tua organizzazioneGoogle Cloud se tentano di accedere alle risorse in altre organizzazioniGoogle Cloud . Questa applicazione dei binding di accesso sugli 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, i tuoi binding di accesso non hanno effetto su questi utenti.
Per garantire l'efficacia dei binding di accesso, 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.
Utilizzare binding di accesso separati per il controllo della durata della sessione
Oltre al controllo dell'accesso sensibile al contesto, puoi utilizzare anche i binding 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, è consigliabile evitare associazioni di accesso sovrapposte.
Quando utilizzi i binding di accesso per controllare la durata della sessione, non creare binding di accesso sovrapposti. Se a un utente si applica più di un'associazione di accesso di questo tipo, ha effetto solo l'associazione di accesso aggiornata per ultima, il che può portare a risultati indesiderati.
Per evitare risultati indesiderati, utilizza un binding di accesso separato per controllare la durata della sessione.
Non consentire agli utenti di fungere da account di servizio
I binding di accesso si applicano agli utenti di Cloud Identity e Google Workspace, ma non influiscono sugli account di servizio. Se consenti agli utenti di autenticarsi e agire come un account di servizio, potrebbero essere in grado di compromettere i tuoi controlli dell'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à del account di servizio, tranne che 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 chiavi degli account di servizio.
Regole di traffico in entrata per i perimetri di servizio VPC
Le regole di ingresso ti consentono di concedere l'accesso sensibile al contesto dall'esterno del perimetro di servizio alle risorse all'interno del perimetro. I perimetri e le regole di traffico in entrata dei servizi VPC proteggono le risorse, non le singole app. Google Cloud Pertanto, un perimetro di servizio con regole di ingresso è ideale per applicare l'accesso sensibile al contesto per gli 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'attivazione dei Controlli di servizio VPC.
Le sezioni seguenti descrivono le pratiche consigliate per l'utilizzo delle regole di ingresso per applicare l'accesso sensibile al contesto.
Includi l'inoltro TCP di 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 di ingresso non si applicano alle connessioni perché l'utilizzo di SSH e RDP non comporta l'accesso alle API di Google.
- Dopo che gli utenti hanno stabilito una sessione SSH o RDP, qualsiasi accesso API avviato dall'interno di quella sessione è considerato proveniente dall'interno del perimetro di servizio. Pertanto, le regole di ingresso non si applicano a nessun accesso API avviato all'interno di quella 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 di ingresso del perimetro di servizio VPC si applichi a ogni tentativo di accesso SSH e RDP.
Utilizzare l'accesso basato su certificato 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 in possesso di un certificato X.509 attendibile.
CBA ti aiuta a rafforzare la sicurezza, ma questo approccio aggiunge anche requisiti infrastrutturali aggiuntivi:
- 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 TLS reciproca (mTLS) per connettersi alle APIGoogle Cloud .
Utilizza l'autenticazione basata su certificati per proteggere l'accesso ai perimetri di servizio VPC più sensibili. Questo approccio ti consente di bilanciare la solidità della sicurezza con requisiti di infrastruttura minimi e un impatto complessivo ridotto.
Collaboratori
Autore: Johannes Passing | Cloud Solutions Architect
Altro collaboratore: Ido Flatow | Cloud Solutions Architect