Questa pagina è stata tradotta dall'API Cloud Translation.

Criteri di Principal Access Boundary

I criteri di Principal Access Boundary (PAB) ti consentono di limitare le risorse a cui possono accedere le entità.

Ad esempio, puoi utilizzare i criteri di confine di accesso dei principali per impedire ai principali di accedere alle risorse di altre organizzazioni, il che può contribuire a prevenire attacchi di phishing o esfiltrazione di dati.

Per scoprire di più sugli altri tipi di criteri di controllo dell'accesso che Offerte IAM (Identity and Access Management), consulta Tipi di criteri.

Come funzionano i criteri di Principal Access Boundary

Per impostazione predefinita, le entità sono idonee ad accedere a qualsiasi risorsa Google Cloud. Ciò significa che se un'entità ha un'autorizzazione per la risorsa e non gli viene negata, può utilizzare l'autorizzazione per accedere alla risorsa.

Con i criteri di Principal Access Boundary, puoi limitare le risorse a cui un'entità può accedere. Se un criterio di confine dell'accesso dell'entità rende un'entità non idonea ad accedere a una risorsa, il suo accesso a quella risorsa è limitato, indipendentemente dai ruoli che le sono stati assegnati.

Quando le entità tentano di accedere a risorse a cui non sono autorizzate, i criteri di confine di accesso delle entità possono bloccare alcune, ma non tutte, le autorizzazioni IAM (Gestione di identità e accessi). Per scoprire di più sulle autorizzazioni bloccate, consulta la sezione Autorizzazioni che possono essere bloccate da Principal Access Boundary.

I criteri di Principal Access Boundary sono costituiti da Principal Access Boundary . Ogni regola di Principal Access Boundary definisce un insieme risorse a cui le entità interessate possono accedere. Puoi creare a 1000 criteri di Principal Access Boundary nella tua organizzazione.

Dopo aver creato un criterio di Principal Access Boundary, puoi creare un criterio binding per applicare il criterio a un insieme di entità.

Un'entità può essere soggetta a uno o più criteri di Principal Access Boundary. Ogni entità può accedere solo alle risorse elencate in quei criteri. Per tutti gli altri risorse, l'accesso dell'entità a quella risorsa è limitato, anche se concedi ruoli all'entità su quella risorsa.

Poiché i criteri di Principal Access Boundary sono associati alle entità e non a puoi utilizzarle per impedire alle entità di accedere alle risorse non ti appartengono. Ad esempio, considera il seguente scenario:

Criterio di confine dell'accesso dell'entità che impedisce l'accesso a una risorsa

Il Tal dell'entità (tal@altostrat.com) fa parte del Organizzazione di Google Workspace altostrat.com.
A Tal viene concesso il ruolo Amministratore Storage (roles/storage.admin) su una Bucket Cloud Storage in un'altra organizzazione, cymbalgroup.com. Questo ruolo contiene l'autorizzazione storage.objects.get, necessaria per visualizzare gli oggetti nel bucket.
In cymbalgroup.com non esistono criteri di negazione che impediscono a Tal di usando l'autorizzazione storage.objects.get.

Con solo i criteri di autorizzazione e diniego, altostrat.com non può impedire a Tal di visualizzare gli oggetti in questo bucket esterno. Nessuna entità altostrat.com ha autorizzazione per modificare il criterio di autorizzazione del bucket, in modo che non possano revocare ruolo. Inoltre, non hanno l'autorizzazione per creare criteri di negazione in cymbalgroup.com, quindi non potrà utilizzare un criterio di negazione per impedire a Tal di accedere nel bucket.

Tuttavia, con i criteri di Principal Access Boundary, gli amministratori di altostrat.com possono assicurati che Tal non possa visualizzare gli oggetti nel bucket cymbalgroup.com o qualsiasi esterno a altostrat.com. A questo scopo, gli amministratori possono creare criterio di Principal Access Boundary che indica che le entità altostrat.com vengono idoneo per accedere alle risorse in altostrat.com. Quindi può creare un criterio associazione per collegare questo criterio a tutte le entità nell'organizzazione altostrat.com. Con questo criterio, Tal non potrà visualizzare gli oggetti nel bucket cymbalgroup.com, anche se gli è stato assegnato il ruolo Amministratore archiviazione per il bucket.

Valutazione fail-open

Durante la release di anteprima del criterio di Principal Access Boundary, L'apertura dei criteri di Principal Access Boundary viene eseguito. Ciò significa che, se IAM non può valutare un criterio di Principal Access Boundary, il criterio di Principal Access Bound viene ignorato il criterio di Principal Access Boundary e procede alla valutazione di autorizzazione e negazione pertinenti .

Autorizzazioni bloccate dai criteri di Principal Access Boundary

Quando le entità tentano di accedere a una risorsa a cui non sono idonee, i criteri di Principal Access Boundary impediscono loro di utilizzare alcuni, ma non tutti, Autorizzazioni IAM (Identity and Access Management) per accedere alla risorsa.

Se un criterio di Principal Access Boundary blocca un'autorizzazione, IAM applica i criteri di Principal Access Boundary per quell'autorizzazione. In altre parole, impedisce a tutte le entità non idonee ad accedere a una risorsa di utilizzare con quell'autorizzazione per accedere alla risorsa.

Se un criterio di Principal Access Boundary non blocca un'autorizzazione, I criteri di Principal Access Boundary non hanno alcun effetto sulla possibilità o meno di utilizzare autorizzazione.

Ad esempio, immagina che a un'entità, Lee (lee@example.com), venga concesso il Ruolo Sviluppatore Dataflow (roles/dataflow.developer). Questo ruolo include dataflow.jobs.snapshot, che consente a Lee di acquisire istantanee di di job Dataflow. Lee è inoltre soggetto a un criterio di Principal Access Boundary che non sono idonei ad accedere a risorse esterne a example.com. Tuttavia, se i criteri di confine di accesso principali non bloccano l'autorizzazione dataflow.jobs.snapshot, Lee può comunque acquisire istantanee dei job di Dataflow nelle organizzazioni esterne a example.com.

Le autorizzazioni bloccate da un criterio di Principal Access Boundary dipendono Principal Access Bound Enforcement.

Versioni di applicazione di Principal Access Boundary

Ogni criterio di Principal Access Boundary specifica una versione di applicazione, che identifica un elenco predefinito di autorizzazioni IAM che il criterio di Principal Access Boundary può bloccare. Specifichi la versione di applicazione quando crei o aggiorni un criterio di Principal Access Boundary. Se non specifichi una versione di applicazione, IAM utilizza la versione più recente e continuerà a utilizzarla fino a quando non la aggiornerai.

Periodicamente, IAM aggiunge una nuova applicazione dei limiti di accesso all'entità che possono bloccare autorizzazioni aggiuntive. Ogni nuova versione può anche bloccare tutte le autorizzazioni nella versione precedente.

Per bloccare le autorizzazioni in una nuova versione di applicazione, devi aggiornare il i criteri di Principal Access Boundary per usare la nuova versione. Se vuoi che l'applicazione per aggiornarla automaticamente man mano che vengono rilasciate nuove versioni, puoi usare il valore latest durante la creazione del criterio. Tuttavia, ti sconsigliamo di utilizzare questo perché potrebbe causare la perdita dell'accesso alle risorse in modo imprevisto.

Per un elenco completo delle autorizzazioni bloccate da ogni versione di applicazione forzata, vedi Autorizzazioni bloccate dai criteri di Principal Access Boundary.

Associa i criteri di Principal Access Boundary agli insiemi di entità

Per associare un criterio di confine dell'accesso dell'entità a un set di entità, crea un'associazione di criteri che specifichi sia il criterio di confine dell'accesso dell'entità che vuoi applicare sia il set di entità per cui vuoi applicarlo. Dopo l'associazione dal criterio a un set di entità, le entità di quel set possono accedere Solo le risorse incluse nelle regole del criterio di Principal Access Boundary.

Puoi associare un criterio di confine dell'accesso dell'entità a un numero qualsiasi di insiemi di entità. Ciascuna Il set di entità può avere fino a 10 limiti di accesso all'entità e i criteri associati.

Per scoprire come gestire i criteri di Principal Access Boundary, consulta Creare e applicare criteri di Principal Access Boundary.

Set di entità supportati

La tabella seguente elenca i tipi di insiemi di principali a cui puoi associare i criteri di confine di accesso principale. Ogni riga contiene quanto segue:

Il tipo di set di entità
Le entità in quel tipo di set di entità
Il formato degli ID per il tipo di set di entità
La risorsa Resource Manager (progetto, cartella o organizzazione) che rappresenta le associazioni dei criteri per quel tipo di set di entità

Set di entità	Dettagli	Risorsa principale delle associazioni di criteri
Pool di identità della forza lavoro	Contiene tutte le identità nel pool di identità della forza lavoro specificato. Formato: `//iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID`	L'organizzazione che contiene il pool di identità della forza lavoro
Pool di identità per i carichi di lavoro	Contiene tutte le identità nell'identità del carico di lavoro specificata pool. Formato: `//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID`	Il progetto che contiene il pool di identità di Workload Identity
Dominio Google Workspace	Contiene tutte le identità nel dominio Google Workspace specificato. Formato: `//iam.googleapis.com/locations/global/workspace/WORKSPACE_ID` Per scoprire come trovare l'ID area di lavoro, consulta Trovare l'ID area di lavoro il tuo ID cliente.	L'organizzazione associata al dominio Google Workspace.
Set di entità del progetto	Contiene tutti gli account di servizio e i pool di identità per i carichi di lavoro nella progetto specificato. Formato: `//cloudresourcemanager.googleapis.com/projects/PROJECT_ID`	Il progetto
Set di entità della cartella	Contiene tutti gli account di servizio e tutti i pool di identità per i carichi di lavoro in in qualsiasi progetto nella cartella specificata. Formato: `//cloudresourcemanager.googleapis.com/folders/FOLDER_ID`	La cartella
Set di entità dell'organizzazione	Contiene le seguenti identità: Tutte le identità in tutti i domini associati al tuo account Google Workspace ID cliente Tutti i pool di identità per la forza lavoro della tua organizzazione Tutti gli account di servizio e i pool di identità per i carichi di lavoro in qualsiasi progetto dell'organizzazione Formato: `//cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_ID`	L'organizzazione

Associazioni dei criteri condizionali per i criteri di Principal Access Boundary

Puoi usare le espressioni di condizione nelle associazioni di criteri per il limite di accesso all'entità per perfezionare ulteriormente le entità a cui si applica il criterio.

Le espressioni di condizione per le associazioni di criteri sono costituite da una o più istruzioni uniti da un massimo di 10 operatori (&&, || o !). Ogni istruzione esprime un'espressione regola di controllo che si applica all'associazione dei criteri e infine determina sull'eventuale applicazione delle norme.

Puoi utilizzare gli attributi principal.type e principal.subject in per le associazioni di criteri. Non sono supportati altri attributi nelle condizioni per le associazioni di norme.

L'attributo principal.type indica il tipo di entità nella richiesta, ad esempio account di servizio o identità in un pool di identità per i carichi di lavoro. Puoi utilizzare le condizioni con questo attributo per controllare quali tipi di entità a cui si applica il criterio di Principal Access Boundary.

Ad esempio, se aggiungi la seguente espressione di condizione a un'associazione per un criterio di Principal Access Boundary, il criterio si applica solo agli account di servizio:
```
principal.type == 'iam.googleapis.com/ServiceAccount'
```
L'attributo principal.subject indica l'identità dell'entità in la richiesta, ad esempio cruz@example.com. Puoi utilizzare le condizioni con questo attributo per controllare esattamente quali entità sono soggette a un criterio di confine di accesso delle entità.

Ad esempio, se aggiungi la seguente espressione di condizione a un'associazione per un criterio di Principal Access Boundary, il criterio non verrà applicato all'utente special-admin@example.com:
```
principal.subject != 'special-admin@example.com'
```

Per scoprire di più sui valori che puoi utilizzare per queste condizioni, consulta il riferimento all'attributo condizioni.

Esempio: utilizza le condizioni per ridurre le risorse a cui un'entità può accedere

Uno dei modi in cui puoi usare le condizioni nel criterio di Principal Access Boundary consiste nel ridurre le risorse alle quali è idonea una singola entità l'accesso.

Immagina di avere un account di servizio, dev-project-service-account, con l'indirizzo email dev-project-service-account@dev-project.iam.gserviceaccount.com. Questo account di servizio è soggetto a un criterio di Principal Access Boundary che rende le entità idonee ad accedere a tutte le risorse nell'organizzazione example.com. Questo criterio è associato a Set di entità dell'organizzazione example.com.

Decidi di non rendere dev-project-service-account idoneo a accedere a tutte le risorse in example.com. Vuoi che sia idoneo per accedere alle risorse in dev-project. Tuttavia, non vorrai modificare Risorse idonee per altre entità nel set di entità example.com per accedere.

Per apportare questa modifica, segui la procedura per ridurre le risorse che le entità sono idonee all'accesso, ma aggiungi una condizione all'associazione dei criteri anziché eliminarla:

Confermi che l'unico criterio di confine di accesso delle entità a cui è soggetto dev-project-service-account è il criterio che rende le entità idonee ad accedere a tutte le risorse in example.com.
Crea un nuovo criterio di confine dell'accesso dell'entità che renda le entità idonee ad accedere alle risorse in dev-project e associalo all'entità impostata per dev-project. Utilizza la seguente condizione nell'associazione dei criteri per assicurarti che il criterio sia applicato solo per dev-project-service-account:
```
"condition": {
  "title": "Only dev-project-service-account",
  "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && principal.subject == 'dev-project-service-account@dev-project.iam.gserviceaccount.com'"
}
```
Esenti da dev-project-service-account dal criterio di confine di accesso delle entità che rende le entità idonee ad accedere a tutte le risorse in example.com. Per farlo, aggiungi la seguente condizione all'associazione del criterio che collega il criterio di confine dell'accesso dell'entità all'insieme di entità dell'organizzazione:
```
"condition": {
  "title": "Exempt dev-project-service-account",
  "expression": "principal.subject != 'dev-project-service-account@dev-project.iam.gserviceaccount.com' || principal.type != 'iam.googleapis.com/ServiceAccount'"
}
```
Per scoprire come aggiornare i criteri di Principal Access Boundary esistenti, consulta Modificare i criteri di Principal Access Boundary.

Dopo aver aggiunto questa condizione all'associazione di criteri, dev-project-service-account non può più accedere a tutte le risorse in example.com, invece, è idoneo ad accedere alle risorse solo in dev-project.

Interazioni con i criteri

IAM valuta ogni criterio di Principal Access Boundary in combinazione con i criteri di autorizzazione e di negazione, nonché con gli altri criteri di Principal Access Boundary. Tutti questi criteri vengono utilizzati per determinare se un'entità può accedere a un risorsa.

Interazione con altri tipi di norme

Quando un'entità tenta di accedere a una risorsa, IAM valuta tutti limite di accesso all'entità pertinente, nonché i criteri di autorizzazione e di negazione per verificare se l'entità autorizzati ad accedere alla risorsa. Se uno di questi criteri indica che l'entità non deve essere in grado di accedere alla risorsa, IAM impedisce l'accesso.

Di conseguenza, se un criterio di limite di accesso all'entità impedirà a un'entità di accede a una risorsa, IAM gli impedisce di accedervi indipendentemente dai criteri di autorizzazione e negazione associati alla risorsa.

Inoltre, i criteri di Principal Access Boundary non consentono alle entità di accedere Google Cloud. Sebbene i criteri di Principal Access Boundary possano rendere un'entità idonea ad accedere a una risorsa, solo i criteri di autorizzazione possono effettivamente concedere all'entità accesso alla risorsa.

Per scoprire di più sulla valutazione dei criteri IAM, consulta Valutazione dei criteri.

Interazione tra i criteri di Principal Access Boundary

Se un criterio di Principal Access Boundary rende un'entità idonea ad accedere a un risorsa, l'entità è idonea ad accedere alla risorsa, indipendentemente Gli altri criteri di Principal Access Boundary a cui è soggetta l'entità. Di conseguenza, se un'entità è già soggetta a un criterio di Principal Access Boundary, non puoi aggiungere criteri di questo tipo per ridurre l'accesso dell'entità.

Ad esempio, immagina che un'entità, Dana (dana@example.com), sia soggetta a un singolo criterio di Principal Access Boundary, prod-projects-policy. Questo criterio rende le entità idonee ad accedere alle risorse in prod-project. Dana è soggetta a questo criterio perché è associata al set di entità della sua organizzazione.

Creerai un nuovo criterio di Principal Access Boundary, dev-staging-projects-policy, che rende le entità idonee ad accedere alle risorse in dev-project e staging-project e associarlo al set di entità dell'organizzazione.

In base a questi criteri di confine dell'accesso dell'entità, Dana è idonea ad accedere alle risorse in dev-project, staging-project e prod-project.

Se vuoi ridurre le risorse a cui Dana può accedere, devi modificare o rimuovere i criteri di confine delle entità a cui è soggetta.

Ad esempio, puoi modificare dev-staging-projects-policy in modo che non dichiari i principali idonei ad accedere alle risorse in dev-project. In questo modo, Dana potrà accedere solo alle risorse in staging-project e prod-project.

In alternativa, puoi rimuovere prod-projects-policy eliminando il vincolo del criterio che lo lega al set di principali dell'organizzazione. Quindi, Dana usava solo essere idoneo per accedere alle risorse in dev-project e staging-project.

Tuttavia, queste modifiche non riguardano solo Dana, ma anche gli altri principali soggetti ai criteri e alle associazioni di Principal Access Boundary modificati. Se vuoi ridurre le risorse a cui un singolo entità è idonea ad accedere, utilizza le associazioni di criteri condizionali.

Ereditarietà dei criteri

I criteri di confine dell'accesso dell'entità sono associati agli insiemi di entità, non alle risorse Resource Manager. Di conseguenza, non vengono ereditati attraverso gerarchia delle risorse, così come consente e nega le norme.

Tuttavia, i set di entità per le risorse principali di Resource Manager, ovvero le cartelle e le organizzazioni, includono sempre tutti gli enti nei set di entità dei loro discendenti. Ad esempio, se un'entità è inclusa un set di entità di un progetto, è incluso anche negli insiemi di entità di qualsiasi cartelle o organizzazioni principali.

Ad esempio, prendi in considerazione un'organizzazione, example.com. Questa organizzazione è associata al dominio example.com e dispone delle seguenti risorse Resource Manager:

Gerarchia delle risorse per example.com

Un'organizzazione, example.com
Un progetto, project-1, che è un progetto secondario dell'organizzazione
Una cartella, folder-a, che è una cartella secondaria dell'organizzazione
Due progetti, project-2 e project-3, secondari di folder-a

La posizione di queste risorse i set di entità contengono le seguenti identità:

Set di entità	Identità Google Workspace nel dominio `example.com`	Pool di federazione delle identità per la forza lavoro in `example.com`	Account di servizio e pool di identità per i carichi di lavoro in `project-1`	Account di servizio e pool di identità per i carichi di lavoro in `project-2`	Account di servizio e pool di identità per i carichi di lavoro in `project-3`
Entità impostata per `example.com`
Entità impostata per `folder-a`
Entità impostata per `project-1`
Entità impostata per `project-2`
Set di entità principale per `project-3`

Di conseguenza, i seguenti principali sono interessati dai seguenti criteri di confine di accesso principale:

Un'identità Google Workspace nel dominio example.com fa parte dell'insieme di entità per example.com e sarà interessata dai criteri di confine dell'accesso dell'entità associati a quell'insieme di entità.
Un account di servizio in project-1 fa parte degli insiemi di entità per project-1 e example.com e sarà interessato dai criteri di confine dell'accesso dell'entità associati a uno di questi insiemi di entità.
Un account di servizio in project-3 fa parte degli insiemi di entità per project-3, folder-a e example.com e sarà interessato dai criteri di confine dell'accesso dell'entità associati a uno di questi insiemi di entità.

Criteri di Principal Access Boundary e risorse memorizzate nella cache

Alcuni servizi Google Cloud memorizzano nella cache le risorse visibili pubblicamente. Ad esempio, Cloud Storage memorizza nella cache gli oggetti pubblicamente leggibili.

Indica se il limite di accesso all'entità può impedire alle entità non idonee di visualizzare visibile pubblicamente dipende dal fatto che la risorsa sia stata memorizzata o meno nella cache:

Se la risorsa è memorizzata nella cache, il limite di accesso all'entità non può impedire ai principali di visualizzarla
Se la risorsa non è memorizzata nella cache, il limite di accesso dell'entità impedisce che la risorsa non sia idonea di visualizzare la risorsa

In tutti i casi, i criteri di confine di accesso dei principali impediscono ai principali non idonei di modificare o eliminare le risorse visibili pubblicamente.

Struttura di un criterio di Principal Access Boundary

Un criterio di Principal Access Boundary è una raccolta di metadati Dettagli dei criteri di Principal Access Boundary. I metadati forniscono informazioni come il nome del criterio e quando è stato creato. I dettagli del criterio ne definiscono la funzionalità, ad esempio le risorse a cui possono accedere le entità interessate.

Ad esempio, il seguente criterio di Principal Access Boundary rende le entità che sono soggetti ai criteri idonei per accedere alle risorse nell'organizzazione. con ID 0123456789012.

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "uid": "puid_0123456789012345678",
  "etag": "W/\"Gh/PcTdJD/AWHUhPW45kdw==\"",
  "displayName": "Example policy",
  "annotations": {
    "example-key": "example-value"
  },
  "createTime": "2024-01-02T15:01:23Z",
  "updateTime": "2024-01-02T15:01:23Z",
  "details": {
    "rules": [
      {
        "description": "Example principal access boundary policy rule",
        "resources": [
          "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Le sezioni seguenti descrivono i campi dei metadati e dei dettagli di un criterio di Principal Access Boundary.

Metadati

I criteri di Principal Access Boundary contengono i seguenti metadati:

name: il nome del criterio di Principal Access Boundary. Questo nome ha il formato organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID, dove ORGANIZATION_ID è l'ID numerico dell' organizzazione in cui è stato creato il criterio di confine dell'accesso dell'entità e PAB_POLICY_ID è l'ID alfanumerico del criterio di confine dell'accesso dell'entità.
uid: un ID univoco assegnato al criterio di Principal Access Boundary.
etag: un identificatore dello stato attuale del criterio. Questo valore cambia quando aggiorni il criterio. Per evitare aggiornamenti in conflitto, il valore etag deve corrispondere al valore memorizzato in IAM. Se i valori etag non corrispondono, la richiesta non va a buon fine.
displayName: un nome leggibile per il criterio di Principal Access Boundary.
annotations: facoltativo. Un elenco di coppie chiave/valore definite dall'utente. Puoi utilizzare queste annotazioni per aggiungere metadati aggiuntivi al criterio, ad esempio chi lo ha creato o se è stato implementato da una pipeline automatica. Per ulteriori informazioni sulle annotazioni, consulta Annotazioni.
createTime: la data e l'ora in cui è stato creato il criterio di confine dell'accesso dell'entità.
updateTime: l'ora dell'ultimo aggiornamento del criterio di Principal Access Boundary.

Dettagli

Ogni criterio di Principal Access Boundary contiene un campo details. Questo campo contiene le regole del limite di accesso all'entità e la versione di applicazione:

rules: un elenco di regole di Principal Access Boundary che definiscono le risorse che le entità interessate sono idonee all'accesso. Ogni regola contiene i seguenti campi:
- description: una descrizione leggibile della regola.
- resources: un elenco di risorse di Resource Manager (progetti, cartelle e organizzazioni) a cui vuoi che gli entità possano accedere. Qualsiasi entità soggetto a queste norme è idonea ad accedere a queste risorse.
  
  Ogni criterio di Principal Access Boundary può fare riferimento a un massimo di 500 risorse in tutte le regole nel .
- effect: la relazione che i principali hanno con le risorse elencate nel campo resources. L'unico effetto che puoi specificare nelle regole di confine di accesso principale è "ALLOW". Questa relazione rende le entità idonee ad accedere alle risorse elencate nella regola.
enforcementVersion: la versione di applicazione utilizzata da IAM al momento dell'applicazione dei criteri. La versione del criterio di Principal Access Boundary determina le autorizzazioni che il criterio di Principal Access Boundary può bloccare.

Per saperne di più sulle versioni dei criteri di Principal Access Boundary, consulta Versioni di applicazione di Principal Access Boundary in questa pagina.

Struttura di un'associazione di criteri

Un'associazione di criteri per un criterio di confine di accesso principale contiene il nome di un criterio, il nome dell'entità impostata per associare il criterio e i metadati che descrivono l'associazione del criterio. Può anche contenere condizioni che modificano i principali esatti a cui si applica il criterio.

Ad esempio, la seguente associazione di criteri associa il criterio example-policy a tutti gli account utente dell'organizzazione example.com, che ha l'ID 0123456789012. L'associazione dei criteri contiene anche una condizione che impedisce l'applicazione del criterio per l'entità super-admin@example.com.

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-policy-binding",
  "uid": "buid_01234567890123456789", 
  "etag": "W/\"cRMdDXbT82aLuZlvoL9Gqg==\"",
  "displayName": "Example policy binding",
  "annotations": {
    "example-key": "example-value"
  },
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "policyUid": "puid_0123456789012345678",
  "condition": {
    "title": "Exempt principal",
    "description": "Don't enforce the policy for super-admin@example.com",
    "expression": "principal.subject != 'super-admin@example.com'"
  },
  "createTime": "2024-01-02T17:00:16Z",
  "updateTime": "2024-01-02T17:00:16Z"
}

Ogni associazione di norme contiene i seguenti campi:

name: il nome dell'associazione del criterio. Questo nome ha il formato RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID, dove RESOURCE_TYPE/RESOURCE_ID è il tipo e l'ID della risorsa principale della definizione del criterio e BINDING_ID è l'ID alfanumerico della definizione del criterio.
uid: un ID univoco assegnato all'associazione del criterio.
etag: un identificatore dello stato attuale del criterio. Questo valore cambia quando aggiorni il criterio. Per evitare aggiornamenti in conflitto, il valore etag deve corrispondere al valore memorizzato in IAM. Se i valori etag non corrispondono, la richiesta non va a buon fine.
displayName: un nome leggibile per l'associazione dei criteri.
annotations: facoltativo. Un elenco di coppie chiave-valore definite dall'utente. Puoi utilizzare la modalità queste annotazioni per aggiungere metadati extra all'associazione di criteri, ad esempio ad esempio chi ha creato l'associazione di criteri o se è stata il deployment da parte di una pipeline automatizzata. Per ulteriori informazioni sulle annotazioni, consulta Annotazioni.
target: il set di entità a cui associare il criterio. Il valore ha il formato {"principalSet": PRINCIPAL_SET}, dove PRINCIPAL_SET è l'ID del set di entità che a cui si vuole associare il criterio.

Ogni destinazione può avere fino a 10 criteri associati li annotino.
policyKind: il tipo di criterio a cui fa riferimento l'associazione dei criteri. Per associazioni di criteri per i criteri di Principal Access Boundary, questo valore è sempre PRINCIPAL_ACCESS_BOUNDARY.
policy: il criterio di Principal Access Boundary da associare al set di entità di destinazione.
policyUid: un ID univoco assegnato al criterio di limite di accesso all'entità a cui si fa riferimento nel campo policy.
condition: facoltativo. Un'espressione logica che influisce sulle entità IAM applica il criterio. Se la condizione restituisce true o non può essere valutato, Identity and Access Management applica il criterio per l'entità a effettuare la richiesta. Se la condizione è false, Identity and Access Management non applica il criterio per l'entità. Per ulteriori informazioni, vedi Confini e condizioni di accesso dell'entità in questa pagina.
createTime: l'ora in cui è stata creata l'associazione del criterio.
updateTime: l'ora dell'ultimo aggiornamento dell'associazione dei criteri.

Casi d'uso

Di seguito sono riportate situazioni comuni in cui potresti voler utilizzare i criteri di confine dell'accesso dell'entità, nonché esempi di questi criteri e delle associazioni di criteri che potresti creare in ogni situazione. Per scoprire come creare dei criteri di Principal Access Boundary e associarli agli insiemi di entità. Consulta la sezione Creare applica i criteri di Principal Access Boundary.

Limita le entità alle risorse nella tua organizzazione

Puoi usare i criteri di Principal Access Boundary per assicurarti che le entità nel tuo sono idonee solo ad accedere alle risorse all'interno della tua organizzazione.

Ad esempio, immagina di voler assicurarti che tutte le entità dell'organizzazione example.com possano accedere solo alle risorse all'interno di example.com. Gli account principali in example.com includono tutte le identità nel dominio example.com, tutti i pool di identità di forza lavoro in example.com e tutti gli account di servizio e i pool di identità per i carichi di lavoro in qualsiasi progetto in example.com.

Non hai criteri di confine di accesso delle entità che si applicano a nessuna delle entità della tua organizzazione. Di conseguenza, tutti i principali sono idonei per accedere a tutte le risorse.

Per rendere le entità non idonee ad accedere alle risorse esterne a example.com, crea un criterio di confine dell'accesso dell'entità che renda le entità idonee ad accedere alle risorse in example.com:

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "displayName": "Boundary for principals in example.org",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example.org",
        "resources": [
            "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Poi, crea un'associazione del criterio per associarlo al set di entità:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"
}

Ora, tutte le entità di example.com sono idonee solo ad accedere alle risorse in example.com. Agli utenti viene impedito di utilizzare autorizzazioni bloccate Principal Access Boundary per accedere alle risorse all'esterno di example.com, anche se dispone delle autorizzazioni su quelle risorse.

Limita gli account di servizio alle risorse in un singolo progetto

Puoi utilizzare i criteri di confine di accesso dei principali per assicurarti che gli account di servizio in un progetto specifico siano idonei ad accedere solo alle risorse all'interno di quel progetto.

Ad esempio, immagina di avere un progetto, example-dev. Devi assicurarti che gli account di servizio in example-dev possano accedere solo alle risorse nel seguente paese: example-dev.

Hai un criterio di confine di accesso delle entità che rende idonee tutte le entità della tua organizzazione, inclusi gli account di servizio in example-dev, ad accedere alle risorse in example.com. Per vedere come appare questo tipo di criterio, consulta Limitare le entità alle risorse dell'organizzazione.

Per rendere gli account di servizio in example-dev non idonei ad accedere alle risorse all'esterno di example-dev, devi prima creare un criterio di Principal Access Boundary rende le entità idonee ad accedere alle risorse in example-dev

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "displayName": "Boundary for principals in example-dev",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example-dev",
        "resources": [
          "//cloudresourcemanager.googleapis.com/projects/example-dev"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Poi, crea un'associazione di criteri per associare questo criterio a tutte le entità in example-dev e aggiungi una condizione in modo che l'associazione di criteri si applichi solo agli account di servizio:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding",
  "displayName": "Bind policy to all service accounts in example-dev",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/projects/example-dev"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "condition": {
    "title": "Only service accounts",
    "description": "Only enforce the policy if the principal in the request is a service account",
    "expression": "principal.type == 'iam.googleapis.com/ServiceAccount'"
  }
}

Tuttavia, questo criterio da solo non limita gli account di servizio idoneità. Questo perché esiste un criterio di confine di accesso delle entità esistente che consente a tutte le entità in example.com di accedere a tutte le risorse in example.com. I criteri di Principal Access Boundary sono additive, pertanto gli account di servizio in example-dev vengono è ancora idoneo per accedere a tutte le risorse in example.com.

Per garantire che gli account di servizio in example-dev siano idonei all'accesso solo risorse in example-dev, devi aggiungere una condizione all'associazione di criteri per il criterio esistente di Principal Access Boundary che ne impedisce l'applicazione per gli account di servizio in example-dev:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "condition": {
    "title": "Exempt example-dev service accounts",
    "description": "Don't enforce the policy for service accounts in the example-dev project",
    "expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || !principal.subject.endsWith('@example-dev.iam.gserviceaccount.com')"
  }
}

Ora gli account di servizio in example-dev possono accedere solo alle risorse nel seguente paese: example-dev. Non possono utilizzare le autorizzazioni bloccate dal criterio di confine di accesso principale per accedere alle risorse al di fuori di example-dev, anche se dispongono di queste autorizzazioni per le risorse in questione.