Panoramica di Gestore contesto accesso

Questo documento fornisce una panoramica generale del servizio Gestore contesto accesso e delle sue funzioni.Gli amministratori dell'organizzazione Google Cloud possono utilizzare Gestore contesto accesso per definire un controllo dell'controllo dell'accesso granulare e basato sugli attributi per progetti e risorse in Google Cloud. In qualità di amministratore, devi prima definire una policy di accesso, ovvero un container a livello di organizzazione per i livelli di accesso e i perimetri di servizio.

I livelli di accesso descrivono i requisiti per l'accettazione delle richieste. Alcuni esempi sono:

  • Tipo di dispositivo e sistema operativo
  • Indirizzo IP
  • Identità utente

I perimetri di servizio definiscono sandbox di risorse. Le risorse all'interno del perimetro possono scambiare dati liberamente, ma non possono esportarli all'esterno del perimetro. Gestore contesto accesso non è responsabile dell'applicazione delle policy. Invece, Gestore contesto accesso è progettato per definire regole o contesti specifici. La policy viene configurata e applicata in vari punti, ad esempio Controlli di servizio VPC. Per scoprire di più su questi servizi, consulta le rispettive guide dell'utente.

Puoi configurare e applicare le policy di Gestore contesto accesso nei seguenti componenti della soluzione Chrome Enterprise Premium:

Vantaggi

Molte aziende si affidano a un modello di sicurezza perimetrale, come un firewall, per proteggere le risorse interne. Un modello di sicurezza perimetrale è fortemente sorvegliato con un unico punto di ingresso e di uscita. Tutto ciò che si trova all'esterno del perimetro è considerato pericoloso. Tutto ciò che si trova all'interno è considerato attendibile.

I firewall e il modello di sicurezza perimetrale funzionano bene se esiste un confine ben definito attorno a utenti e servizi specifici. Tuttavia, se la forza lavoro è mobile, la varietà di dispositivi aumenta man mano che gli utenti portano i propri dispositivi (BYOD) e utilizzano servizi basati su cloud. Questo scenario genera ulteriori vettori d'attacco che non vengono considerati dal modello perimetrale. Di conseguenza, il perimetro non è più solo la sede fisica dell'azienda e ciò che si trova all'interno non può essere considerato sicuro.

Puoi utilizzare Gestore contesto accesso per ridurre le dimensioni della rete con privilegi e passare a un modello in cui gli endpoint non dispongono di autorizzazioni ambientali basate sulla rete. Puoi invece concedere l'accesso in base al contesto della richiesta, ad esempio il tipo di dispositivo, l'identità dell'utente e altro ancora, continuando a controllare l'accesso alla rete aziendale quando necessario.

Gestore contesto accesso è parte integrante dell'impegno di Google per BeyondCorp. Per saperne di più, consulta BeyondCorp.

Criteri di accesso

Una policy di accesso è un container per tutte le risorse di Gestore contesto accesso, ad esempio livelli di accesso e perimetri di servizio.

Puoi creare una policy di accesso nel contesto di un'organizzazione e utilizzarla ovunque all'interno dell'organizzazione. Per delegare l'amministrazione di una policy di accesso, puoi creare una policy di accesso con ambito e impostare l'ambito della policy a livello di cartella o progetto. L'amministratore delegato a cui è assegnata la policy con ambito può gestire solo la policy di accesso con ambito e non la policy di accesso a livello di organizzazione.

Una policy di accesso viene sottoposta a controllo delle versioni utilizzando un etag. Puoi utilizzare etag per applicare le modifiche alla policy di accesso, ad esempio modifiche ai livelli di accesso o a una versione specifica della policy. Se più origini modificano la policy di accesso, l'utilizzo del campo etag per lo strumento a riga di comando gcloud e le chiamate API aiuta a evitare sovrascritture e conflitti involontari.

Per scoprire come creare policy di accesso, consulta Crea una policy di accesso.

Livelli di accesso

I livelli di accesso vengono utilizzati per consentire l'accesso alle risorse in base alle informazioni contestuali sulla richiesta. Utilizzando i livelli di accesso, puoi iniziare a organizzare i livelli di attendibilità. Ad esempio, potresti creare un livello di accesso denominato High_Level che consentirà le richieste di un piccolo gruppo di persone con privilegi elevati. Potresti anche identificare un gruppo più generale di cui fidarti, ad esempio un intervallo IP da cui vuoi consentire le richieste. In questo caso, puoi creare un livello di accesso denominato Medium_Level per consentire queste richieste.

Dopo aver definito i livelli di accesso, i servizi di applicazione possono utilizzarli per determinare se accettare una richiesta. Ad esempio, puoi specificare che, sebbene molte risorse siano disponibili per Medium_Trust, alcune risorse più sensibili richiedono il livello High_Trust. Questi controlli vengono applicati in aggiunta alla policy IAM standard.

I livelli di accesso sono personalizzabili; i livelli di accesso High_Trust e Medium_Trust sono esempi. Puoi specificare più livelli di accesso nell'ambito di una policy di accesso.

Gestore contesto accesso offre due modi per definire i livelli di accesso:

  • Un livello di accesso di base è costituito da una raccolta di condizioni utilizzate per testare le richieste. Le condizioni possono essere definite come un gruppo di attributi che vuoi testare, ad esempio il tipo di dispositivo, l'indirizzo IP o l'identità dell'utente. Gli attributi vengono combinati come un'operazione AND (tutti devono essere true) o un'operazione NOR (nessuno deve essere true) per determinare se la condizione è soddisfatta.

  • I livelli di accesso personalizzati vengono creati utilizzando un sottoinsieme di Common Expression Language. Oltre al contesto della richiesta utilizzato per i livelli di accesso di base, puoi utilizzare anche i livelli di accesso personalizzati per consentire le richieste in base ai dati dei servizi di terze parti. Per saperne di più, consulta Livelli di accesso personalizzati. 

!(origin.region_code in ['RU', 'BY', 'UA']) -> FAILED  // levels.regions_check

inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED  // levels.ip_check

!(origin.region_code in ['RU', 'BY', 'UA']) || inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED

levels.regions_check || levels.ip_check -> GRANTED

Indirizzo IP

Puoi concedere un livello di accesso in base all'indirizzo IP della richiesta di origine. L'intervallo di indirizzi IP da consentire viene specificato sotto forma di blocco Classless Inter-Domain Routing (CIDR), che consente un controllo granulare sugli indirizzi IP consentiti.

Un singolo livello di accesso può contenere più intervalli IP.

Per scoprire come creare un livello di accesso che consenta l'accesso solo a un intervallo di indirizzi IP specificato, ad esempio quelli all'interno di una singola rete aziendale, consulta Creazione di un livello di accesso per l'accesso alla rete aziendale.

I seguenti intervalli IP sono trattati come intervalli privati da Gestore contesto accesso:

  • 10.0.0.0/8 (RFC 1918)
  • 172.16.0.0/12 (RFC 1918)
  • 192.168.0.0/16 (RFC 1918)
  • 100.64.0.0/10 (RFC 6598 Shared Address Space)
  • fc00::/7 (indirizzi locali univoci IPv6 RFC 4193)

Tipo di dispositivo

Gestore contesto accesso utilizza Verifica endpoint per raccogliere informazioni sui dispositivi degli utenti, come il sistema operativo, il tipo di dispositivo o la versione. Puoi concedere un livello di accesso in base a questi dati. Ad esempio, puoi concedere un livello di accesso più permissivo ai dispositivi che eseguono l'ultima versione del sistema operativo principale utilizzato nella tua azienda.

Per scoprire come concedere un livello di accesso in base a questi attributi del dispositivo, consulta Limita l'accesso in base al tipo di dispositivo.

Identità utente

In alcuni scenari, potresti voler concedere un livello di accesso a entità specifiche. In questi scenari, l'identità del chiamante determina se la condizione è soddisfatta. Questo scenario viene spesso utilizzato insieme ai service account e ai Controlli di servizio VPC. Ad esempio, puoi utilizzare questo scenario per consentire a una Cloud Function di accedere ai dati protetti dai Controlli di servizio VPC.

Puoi creare e gestire i livelli di accesso basati solo sull'identità con lo strumento a riga di comando gcloud, ma non con la console Google Cloud .

Per iniziare a creare un livello di accesso di base, consulta Crea un livello di accesso per Gestore contesto accesso.

Per informazioni sulla creazione di un livello di accesso che consente l'accesso in base al contesto di una richiesta, consulta Crea un livello di accesso personalizzato.

Combinare le condizioni

Un singolo livello di accesso può contenere più condizioni. Le condizioni possono essere valutate utilizzando l'operatore AND o OR. Puoi specificare la modalità quando crei o aggiorni un livello di accesso.

Il caso AND è l'opzione più restrittiva e predefinita. Questa opzione concede il livello di accesso solo se tutte le condizioni sono soddisfatte. Ad esempio, potresti richiedere che una richiesta provenga dalla rete aziendale e da un dispositivo che esegue l'ultima versione di un sistema operativo.

OR è un'opzione meno restrittiva. Questa opzione richiede che solo una delle tante condizioni sia vera. A volte questo è utile quando si gestiscono le identità utente, ad esempio per escludere entità specifiche (come i service account) dai requisiti normali.

Condizioni di nidificazione

Le condizioni possono essere nidificate in modo che una condizione dipenda da un'altra. Ad esempio, se hai i due livelli di accesso di attendibilità "Media" e "Alta", puoi impostare i requisiti per "Alta" in modo che richiedano "Media", oltre ad altre condizioni.

La nidificazione delle condizioni può rendere più comoda la gestione dei livelli di accesso. Ad esempio, immagina che il livello di accesso più permissivo contenga una versione minima del sistema operativo e che i livelli più restrittivi dipendano da questo. Se in futuro aggiorni la versione minima, dovrai aggiornare una sola condizione, anziché ogni livello di accesso nella policy.

Quando nidifichi i livelli di accesso, tieni presente i seguenti limiti e restrizioni:

  • Nessuna dipendenza circolare: le dipendenze circolari non sono consentite. I livelli di accesso non possono fare riferimento l'uno all'altro in un loop, né direttamente (ad esempio, Level_A richiede Level_B e Level_B richiede Level_A o un livello di accesso fa riferimento a se stesso) né in modo transitivo (ad esempio, Level_A richiede Level_B, Level_B richiede Level_C e Level_C richiede Level_A). Se tenti di creare o aggiornare un livello di accesso che introduce una dipendenza circolare, la chiamata non va a buon fine e viene visualizzato un errore INVALID_ARGUMENT.

  • Numero massimo di dipendenze per condizione: in un livello di accesso di base, l'elenco requiredAccessLevels di una singola condizione può fare riferimento a un massimo di 15 altri livelli di accesso.

  • Profondità di nidificazione: poiché Gestore contesto accesso valuta i livelli di accesso nidificati in ordine di dipendenza anziché espanderli in modo ricorsivo, non esiste un limite di profondità massima separato per una catena di livelli di accesso nidificati oltre al limite complessivo dei livelli di accesso per policy di accesso. Tutti i livelli di accesso a cui viene fatto riferimento devono appartenere alla stessa policy di accesso.

Scopri di più