Questo documento descrive le best practice consigliate per l'utilizzo dell' accesso sensibile al contesto per proteggere le tue Google Cloud risorse in modo efficace. 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 delle identità utente di base per l'accesso alla sicurezza e può aiutarti a implementare un modello di sicurezza Zero Trust per migliorare la 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 Google Cloud risorse, 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 è destinato a tutti i professionisti della sicurezza responsabili di Identity and Access Management (IAM) e della sicurezza di Google Cloud risorse e app. Questo documento presuppone che tu abbia già familiarità con Gestore contesto accesso, Google Cloud, e la gestione di IAM.
Approcci all'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 a entrambi. Per prendere questa decisione, è utile distinguere tra i seguenti 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 Google Cloud console, Google Cloud CLI, Terraform e IAP Desktop.
- App di linea di business: queste app includono app web che vengono eseguite 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 di linea di 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 di linea di business in base alla modalità di gestione dell'autenticazione e dell'autorizzazione:
- SAML: app che utilizzano Google Workspace SAML per l' autenticazione. Le app SaaS spesso rientrano in questa categoria.
- IAP: app web personalizzate che hai eseguito il deployment dietro IAP.
- OAuth: app web o desktop personalizzate che utilizzano OAuth 2.0 e uno o più Google Cloud ambiti OAuth.
Il seguente diagramma di flusso mostra l'approccio all'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 Google Cloud risorse a cui l'app amministrativa facilita l'accesso piuttosto che l'app stessa. 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ì prezioso 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 i controlli dell'accesso sensibile al contesto corretti alle risorse nel modo più efficace, utilizza i perimetri di servizio Virtual Private Cloud (VPC) con le regole in entrata appropriate. Puoi integrare i perimetri di servizio VPC con le associazioni di accesso.
App di linea 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 di linea di business che utilizzano IAP: anche se IAP utilizza 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 di linea di business che utilizzano SAML: analogamente alle app di linea di 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 best practice consigliate da utilizzare quando gestisci i livelli di accesso.
Creare livelli di accesso riutilizzabili
I livelli di accesso sono una risorsa globale e sono destinati a essere utilizzati in tutte le risorse della tua Google Cloud organizzazione. Pertanto, è consigliabile 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 i requisiti specifici per le risorse o le 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 il sovraccarico di manutenzione e garantire la coerenza quando le sottoreti o le regioni cambiano, non ripetere gli stessi requisiti in più livelli di accesso. Consenti invece ai livelli di accesso di dipendere l'uno dall'altro.
Ad esempio, non elencare le stesse regioni
o sottoreti IP attendibili in più livelli di accesso, ma crea invece un livello di accesso aggiuntivo
denominato Trusted location. Questo livello Trusted location può fungere da dipendenza per gli altri livelli di accesso.
Escludere 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 definisca i requisiti normali.
- Aggiungi un'altra condizione con un
membersrequisito che 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 a conoscenza del fatto che la loro posizione, il dispositivo e altri fattori possono influire sulla possibilità di accedere a determinate app. Per tenere informati gli utenti e 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
Le associazioni di accesso consentono di configurare l'accesso sensibile al contesto per le app OAuth che utilizzano uno o più Google Cloud ambiti. Le associazioni di accesso sono anche un modo efficace per applicare l'accesso sensibile al contesto per le app di linea di business.
Le sezioni seguenti descrivono le best practice consigliate da utilizzare quando utilizzi le associazioni di accesso.
Utilizzare una singola associazione di accesso con impostazioni con ambito
Quando utilizzi le associazioni di accesso, devi tenere presente i seguenti vincoli:
- Ogni gruppo Cloud Identity può avere al massimo un'associazione di accesso.
- Se a un utente si applica più di un'associazione di accesso, ha la precedenza l'associazione di accesso meno restrittiva.
Per soddisfare questi due vincoli, utilizza una singola associazione di accesso che si applichi a tutti gli 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 degli utenti, dei dispositivi e delle 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 abbassare i requisiti di accesso effettivi.
- Un'impostazione di accesso con ambito non ha effetto se utilizza un livello di accesso più rigoroso del livello di accesso predefinito dell'associazione di accesso.
Quando selezioni un livello di accesso predefinito per un'associazione di accesso, ti consigliamo di procedere nel seguente modo:
- 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 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 della rete IP: se gli utenti della tua organizzazione accedono Google Cloud esclusivamente da determinate reti o se la tua organizzazione utilizza un proxy di uscita comune, puoi includere le limitazioni della rete IP.
Non utilizzare come livello di accesso predefinito i livelli di accesso che richiedono l'autenticazione basata su certificati. L'autenticazione basata su certificati è più adatta alle regole in entrata del perimetro di servizio VPC.
Gestire le eccezioni per app
Per gestire le eccezioni al livello di accesso predefinito, aggiungi eccezioni per le 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. Esempi potrebbero includere 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 escludere le 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 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.
Evitare le 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 gli utenti possono unirsi a gruppi aggiuntivi, la protezione di determinate app potrebbe essere compromessa.
Per evitare queste situazioni, ti consigliamo di evitare le 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.
Proteggere i gruppi da modifiche non autorizzate
Per impostazione predefinita, Cloud Identity consente ai membri del gruppo di lasciare un gruppo. Questo comportamento è appropriato per i gruppi di accesso, ma è problematico per i gruppi con associazioni di accesso associate. Se un utente lascia un gruppo con un'associazione di accesso associata, 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 lasciando un gruppo.
Utilizza sempre i gruppi di applicazione forzata e non consentire agli utenti di lasciare un gruppo di applicazione forzata 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 agli 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 Google Cloud organizzazione. Questi utenti sono comunque soggetti alle associazioni di accesso nella tua Google Cloud organizzazione se tentano di accedere alle risorse in altre Google Cloud organizzazioni. 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 Google Cloud organizzazioni, le tue associazioni di accesso non hanno alcun effetto su questi utenti.
Per assicurarti che le tue associazioni di accesso siano efficaci, non concedere agli utenti esterni l'accesso ad app o risorse nella tua Google Cloud organizzazione. Inoltre, non aggiungere utenti esterni ai gruppi nel tuo account Cloud Identity o Google Workspace.
Utilizzare associazioni di accesso separate per il controllo della durata della sessione
Oltre al controllo dell'accesso sensibile al contesto, puoi utilizzare le associazioni di accesso anche 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 le 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 applica più di un'associazione di accesso di questo tipo, viene applicata solo l'associazione di accesso aggiornata più di recente, il che può portare a risultati indesiderati.
Per evitare questi risultati indesiderati, utilizza un'associazione di accesso separata per controllare la durata della sessione.
Non consentire agli utenti di agire come un account di servizio
Le associazioni 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 controlli dell'accesso sensibile al contesto.
Esistono altri rischi quando gli utenti possono agire come un account di servizio. 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, tranne che per scopi di sviluppo.
Per saperne di più su come proteggere i service account e le chiavi dei account di servizio, 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 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 Google Cloud le risorse, non le singole app. Pertanto, un perimetro di servizio con regole in entrata è ideale per applicare l'accesso sensibile al contesto per gli strumenti amministrativi come la Google Cloud console 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 best practice consigliate da utilizzare quando utilizzi le regole in entrata per applicare l'accesso sensibile al contesto.
Includere 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 comporta l'accesso alle API Google.
- Dopo che gli utenti hanno stabilito una sessione SSH o RDP, qualsiasi accesso API avviato dall'interno della sessione viene considerato proveniente dall'interno del perimetro di servizio. Pertanto, le regole in entrata non si applicano a nessun accesso 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
iaptunnel.googleapis.comservizio come servizio limitato. - Configura le regole firewall che limitano l'accesso alle porte SSH e RDP tramite l'inoltro TCP IAP.
Utilizza l'inoltro TCP IAP per assicurarti che la configurazione delle regole in entrata del perimetro di servizio VPC si applichi a ogni tentativo di accesso SSH e RDP.
Utilizzare l'accesso basato su certificati per i perimetri di servizio sensibili
Per impostazione predefinita, i token di accesso e i token di aggiornamento di Google non sono associati a un dispositivo e possono essere vulnerabili al furto o agli attacchi di riproduzione. Per contribuire a mitigare questi rischi, puoi utilizzare l'accesso basato su certificati (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 rilasciato 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 a Google Cloud API.
Utilizza CBA per proteggere l'accesso ai perimetri di servizio VPC più sensibili. Questo approccio ti consente di bilanciare la solidità della sicurezza con requisiti infrastrutturali minimi e un impatto complessivo.
Collaboratori
Autore: Johannes Passing | Cloud Solutions Architect
Altro collaboratore: Ido Flatow | Cloud Solutions Architect