I criteri basati su ambito sono criteri di accesso che si applicano a cartelle o progetti specifici, insieme a un criterio di accesso che puoi applicare all'intera organizzazione. Puoi utilizzare i criteri basati su ambito per delegare l'amministrazione dei perimetri di VPC Service Controls e dei livelli di accesso agli amministratori a livello di cartella e progetto.
Le organizzazioni possono avere un solo criterio di accesso a livello di organizzazione e puoi applicare il criterio di accesso a livello di organizzazione a qualsiasi cartella o progetto dell'organizzazione.
Potrebbero verificarsi casi in cui vuoi delegare la gestione di un criterio per un sottoinsieme di risorse di un'organizzazione, ad esempio una cartella, a un amministratore delegato. Puoi creare criteri di accesso che si applicano a cartelle o progetti specifici insieme a un criterio di accesso che può essere applicato all'intera organizzazione. Per delegare l'amministrazione dei perimetri e dei livelli di accesso di VPC Service Controls agli amministratori a livello di cartella e a livello di progetto, puoi utilizzare i criteri basati su ambito.
Quando deleghe l'amministrazione di un criterio basato sugli ambiti, gli amministratori delegati possono modificare o leggere quel criterio specifico e non il criterio di Gestore contesto accesso dell'organizzazione. I criteri basati sugli ambiti limitano le risorse che possono essere soggette a restrizioni in un perimetro dei Controlli di servizio VPC e la visibilità di eventuali livelli di accesso.
Gestione dei criteri basati sugli ambiti
In qualità di amministratore di Gestore contesto accesso a livello di organizzazione, puoi creare, modificare ed eliminare i criteri basati sugli ambiti. Puoi specificare le associazioni di Identity and Access Management (IAM) direttamente nel criterio di Access Context Manager e consentire un'ulteriore delega dell'amministrazione dei criteri di Access Context Manager ad altri utenti dell'organizzazione. Un amministratore dei criteri con ambito può configurare i perimetri di servizio e i livelli di accesso nei criteri. Tuttavia, un amministratore delle norme basate sugli ambiti non può creare una nuova norma o modificarne l'ambito per applicarla a un'altra cartella o a un altro progetto.
Ecco una sequenza di come gli amministratori gestiscono i criteri basati sugli ambiti:
L'amministratore a livello di organizzazione crea un nuovo criterio di accesso con un campo di ambito che fa riferimento a una cartella o un progetto specifico.
L'amministratore a livello di organizzazione assegna le autorizzazioni IAM all'amministratore delegato direttamente nella risorsa del criterio di accesso. L'amministratore con delega ora dispone delle autorizzazioni per il criterio basato sugli ambiti, ma non per nessun altro criterio, a meno che l'amministratore a livello di organizzazione non li assegni esplicitamente all'amministratore con delega.
L'amministratore delegato ora può modificare il criterio per configurare i livelli di accesso e i perimetri di servizio. L'amministratore delegato può anche concedere le autorizzazioni IAM per il criterio a qualsiasi altro utente.
Quando elimini una cartella o un progetto, viene eliminato anche il criterio che ha come ambito la cartella o il progetto eliminato. Inoltre, se sposti un progetto in un altro nodo della gerarchia dell'organizzazione, il criterio limitato al progetto non viene modificato automaticamente. Devi eliminare il criterio associato al progetto, ricrearlo e specificare l'ambito.
Gerarchia dei criteri basati sugli ambiti
La risorsa organizzazione è il nodo radice della Google Cloud gerarchia delle risorse e tutte le risorse che appartengono a un'organizzazione esistono come elementi figlio del nodo organizzazione. Le cartelle sono un meccanismo di raggruppamento dei progetti. Le cartelle e i progetti esistono come nodi secondari della risorsa organizzazione.
Il seguente diagramma mostra un'organizzazione di esempio che contiene cartelle per ogni reparto e le cartelle contengono progetti di sviluppo, test e produzione.
Nell'organizzazione di esempio, i seguenti vincoli si applicano a un perimetro di servizio o a un livello di accesso in un criterio basato su ambito:
I perimetri di servizio in un criterio basato su ambito possono limitare solo le risorse esistenti nel relativo ambito. Ad esempio, un perimetro di servizio in un criterio con ambito corrispondente alla cartella di ingegneria può proteggere i progetti example-dev, example-prod ed example-test perché si trovano nella cartella di ingegneria.
Se il criterio basato sugli ambiti si applica alla cartella vendite, i perimetri di servizio in quel criterio non possono proteggere nessuno dei progetti example-dev, example-prod ed example-test. Tuttavia, il perimetro del servizio nel criterio basato sugli ambiti può consentire l'accesso ai progetti in altre cartelle utilizzando le regole di ingresso e di uscita.
I livelli di accesso in un criterio basato su ambito sono visibili solo nell'ambito del criterio. Se crei un livello di accesso nel criterio con ambito nella cartella di ingegneria, solo i perimetri di servizio e i livelli di accesso nella cartella di ingegneria possono utilizzarlo. I perimetri di servizio e i livelli di accesso in altre cartelle non possono utilizzare il livello di accesso definito nella cartella di ingegneria.
Una posizione, ad esempio una cartella, nella gerarchia delle risorse dell'organizzazione example.com può avere più criteri che contengono un livello di accesso o un perimetro di servizio. Quando esistono più criteri, una richiesta di risorse nell'organizzazione example.com viene valutata in base alle seguenti regole:
Un criterio può contenere un solo ambito, ad esempio una cartella, ma puoi creare un criterio per ogni livello di un'organizzazione. Ad esempio, se l'ambito del criterio 1 è la cartella di ingegneria, non puoi impostare la cartella di ingegneria come ambito di nessun altro criterio. Puoi impostare un altro criterio con l'ambito impostato sulla cartella figlia dell'ingegneria, ad esempio example-prod.
Se l'ambito di una regola si applica a un progetto o a un progetto principale, puoi aggiungerlo alla regola. Tuttavia, un progetto può essere membro di un solo perimetro di servizio in tutti i criteri. Ad esempio, un criterio con ambito impostato sull'organizzazione example.com può definire un perimetro di servizio con example-dev. Un criterio con ambito impostato sulla cartella di ingegneria o sul progetto example-dev può anche aggiungere il progetto example-dev a un perimetro definito in uno dei due. Tuttavia, solo uno di questi tre criteri può contenere questo progetto.