Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Policy di Principal Access Boundary

Le policy di Principal Access Boundary (PAB) ti consentono di definire le risorse a cui le entità possono accedere.

Ad esempio, puoi utilizzare le policy sul confine di accesso dell'entità per impedire alle tue entità di accedere alle risorse di altre organizzazioni, il che può contribuire a prevenire attacchi di phishing o l'esfiltrazione di dati.

Per scoprire gli altri tipi di criteri di controllo dell'accesso dell'accesso offerti da Identity and Access Management (IAM), consulta Tipi di criteri.

Come funzionano le policy sul confine di accesso dell'entità

Per impostazione predefinita, le entità possono accedere a qualsiasi Google Cloud risorsa. Ciò significa che se un'entità dispone di un'autorizzazione per la risorsa e non le è stata negata l'autorizzazione, può utilizzarla per accedere alla risorsa.

Con le policy sul confine di accesso dell'entità, puoi definire le risorse a cui un'entità può accedere. Se una policy sul confine di accesso dell'entità rende un'entità non idonea ad accedere a una risorsa, il suo accesso a questa risorsa è limitato, indipendentemente dai ruoli che le sono stati concessi.

Quando le entità tentano di accedere a risorse a cui non possono accedere, le policy sul confine di accesso dell'entità possono bloccare alcune autorizzazioni IAM (Identity and Access Management), ma non tutte. Per scoprire di più sulle autorizzazioni bloccate, consulta Autorizzazioni che il confine di accesso dell'entità può bloccare.

Le policy sul confine di accesso dell'entità sono costituite da regole del confine di accesso dell'entità. Ogni regola del confine di accesso dell'entità definisce un insieme di risorse a cui le entità interessate possono accedere. Puoi creare fino a 1000 policy sul confine di accesso dell'entità nella tua organizzazione.

Dopo aver creato una policy sul confine di accesso dell'entità, crea un'associazione policy per applicare la policy a un insieme di entità.

Un'entità può essere soggetta a una o più policy sul confine di accesso dell'entità. Ogni entità può accedere solo alle risorse elencate in queste policy. Per tutte le altre risorse, l'accesso dell'entità a quella risorsa è limitato, anche se concedi ruoli all'entità su quella risorsa.

Poiché le policy di Principal Access Boundary sono associate alle entità e non alle risorse, puoi utilizzarle per impedire alle entità di accedere alle risorse che non ti appartengono. Ad esempio, considera il seguente scenario:

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

Il preside Tal (tal@example.com) fa parte dell'organizzazione Google Workspace example.com.
A Tal viene concesso il ruolo Storage Admin (roles/storage.admin) su un bucket Cloud Storage in un'altra organizzazione, cymbalgroup.com. Questo ruolo contiene l'autorizzazione storage.objects.get, necessaria per visualizzare gli oggetti nel bucket.
Non esistono policy di negazione in cymbalgroup.com che impediscono a Tal di utilizzare l'autorizzazione storage.objects.get.

Con le sole policy di autorizzazione e negazione, example.com non può impedire a Tal di visualizzare gli oggetti in questo bucket esterno. Nessuna entità example.com ha l'autorizzazione per modificare i criteri di autorizzazione del bucket, pertanto non può revocare il ruolo di Tal. Inoltre, non ha l'autorizzazione per creare criteri di negazione in cymbalgroup.com, quindi non può utilizzare un criterio di negazione per impedire a Tal di accedere al bucket.

Tuttavia, con i criteri di Principal Access Boundary, gli amministratori di example.com possono assicurarsi che Tal non possa visualizzare gli oggetti nel bucket cymbalgroup.com o in qualsiasi bucket al di fuori di example.com. A questo scopo, gli amministratori possono creare una policy di Principal Access Boundary che stabilisce che le entità example.com sono idonee ad accedere solo alle risorse in example.com. Dopodiché, possono creare un'associazione di policy per collegare questa policy a tutte le entità dell'organizzazione example.com. Con una policy di questo tipo, Tal non potrà visualizzare gli oggetti nel bucket cymbalgroup.com, anche se gli è stato concesso il ruolo di amministratore Storage nel bucket.

Valutazione con esito negativo

Le policy sul confine di accesso dell'entità non sono riuscite. Ciò significa che, se IAM non riesce a valutare un criterio del confine di accesso dell'entità quando valuta l'accesso di un'entità, IAM impedisce all'entità di accedere alla risorsa.

Il motivo più comune per cui IAM non è in grado di valutare le policy sul confine di accesso dell'entità è che i dettagli di un'entità si stanno ancora propagando nel sistema. Ciò si verifica più probabilmente per gli utenti appena creati. Per risolvere il problema, chiedi alla nuova entità di attendere e di provare ad accedere nuovamente alla risorsa in un secondo momento.

Autorizzazioni bloccate dalle policy sul confine di accesso dell'entità

Quando le entità tentano di accedere a una risorsa a cui non possono accedere, i criteri sul confine di accesso dell'entità impediscono loro di utilizzare alcune, ma non tutte, le autorizzazioni IAM (Identity and Access Management) per accedere alla risorsa.

Se una policy sul confine di accesso dell'entità blocca un'autorizzazione, IAM applica le policy sul confine di accesso dell'entità per questa autorizzazione. In altre parole, impedisce a qualsiasi entità non idonea ad accedere a una risorsa di utilizzare questa autorizzazione per accedere alla risorsa.

Se una policy sul confine di accesso dell'entità non blocca un'autorizzazione, allora le policy sul confine di accesso dell'entità non influiscono sulla possibilità di utilizzare l'autorizzazione.

Ad esempio, supponiamo che a un'entità, Lee (lee@example.com), venga concesso il ruolo Sviluppatore Dataflow (roles/dataflow.developer). Questo ruolo include l'autorizzazione dataflow.jobs.snapshot, che consente a Lee di creare snapshot dei job Dataflow. Lee è anche soggetto a una policy di Principal Access Boundary che lo rende non idoneo ad accedere alle risorse al di fuori di example.com. Tuttavia, se le policy di boundary di accesso dei principal non bloccano l'autorizzazione dataflow.jobs.snapshot, Lee può comunque acquisire snapshot dei job Dataflow nelle organizzazioni al di fuori di example.com.

Le autorizzazioni bloccate da un criterio di Principal Access Boundary dipendono dalla versione dell'applicazione del confine di accesso dell'entità.

Versioni di applicazione del confine di accesso dell'entità

Ogni policy sul confine di accesso dell'entità specifica una versione di applicazione, che identifica un elenco predefinito di autorizzazioni IAM che la policy sul confine di accesso dell'entità può bloccare. Specifichi la versione di applicazione quando crei o aggiorni una policy sul confine di accesso dell'entità. Se non specifichi una versione di applicazione, IAM utilizza l'ultima versione di applicazione e continuerà a utilizzarla finché non la aggiorni.

Periodicamente, IAM aggiunge nuove versioni dell'applicazione del confine di accesso dell'entità che possono bloccare autorizzazioni aggiuntive. Ogni nuova versione può anche bloccare tutte le autorizzazioni della versione precedente.

Per bloccare le autorizzazioni in una nuova versione di applicazione, devi aggiornare le policy del confine di accesso del principal in modo che utilizzino la nuova versione. Se vuoi che la versione di applicazione venga aggiornata automaticamente man mano che vengono rilasciate nuove versioni, puoi utilizzare il valore latest durante la creazione del criterio. Tuttavia, non consigliamo di utilizzare questo valore perché potrebbe causare la perdita imprevista dell'accesso alle risorse da parte dei principal.

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

Versione di applicazione predefinita

La versione di applicazione predefinita viene utilizzata per le seguenti policy sul confine di accesso dell'entità:

Nuove policy che non specificano un numero di versione
Policy che utilizzano il valore latest per la versione

La versione di applicazione predefinita attuale è 4. Per scoprire quali autorizzazioni sono bloccate in questa versione di applicazione, consulta la sezione Autorizzazioni bloccate dalle policy sul confine di accesso dell'entità.

Associa le policy sul confine di accesso dell'entità ai set di entità

Per associare una policy di Principal Access Boundary a un insieme di entità, crea un'associazione policy che specifica sia la policy di Principal Access Boundary che vuoi applicare sia l'insieme di entità a cui vuoi applicarla. Dopo aver associato il criterio a un insieme di entità, le entità in quell'insieme possono accedere solo alle risorse incluse nelle regole del criterio di Principal Access Boundary.

Puoi associare una policy sul confine di accesso dell'entità a un numero qualsiasi di set di entità. A ogni insieme di entità possono essere associate fino a 10 policy sul confine di accesso dell'entità.

Puoi creare associazioni solo per le policy sul confine di accesso dell'entità esistenti. Il tentativo di creare un'associazione per una policy sul confine di accesso dell'entità eliminata non andrà a buon fine. Se hai eliminato di recente una policy sul confine di accesso dell'entità, a volte puoi creare un'associazione, ma l'associazione non avrà alcun effetto. IAM esegue automaticamente la pulizia di questi binding.

Per scoprire come gestire le policy sul confine di accesso dell'entità, consulta Creare e applicare policy sul confine di accesso dell'entità.

Set di entità supportati

La tabella seguente elenca i tipi di set di entità a cui puoi associare le policy sul confine di accesso dell'entità. 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 quel tipo di set di entità
La risorsa Resource Manager (progetto, cartella o organizzazione) che contiene i binding delle policy per quel tipo di set di entità

Set di entità	Dettagli	Risorsa padre dei binding delle policy
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à del workload	Contiene tutte le identità nel pool di identità del workload specificato. Formato: `//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID`	Il progetto che contiene il pool di identità del workload
Dominio Google Workspace	Contiene tutte le identità nel dominio Google Workspace specificato. Formato: `//iam.googleapis.com/locations/global/workspace/CUSTOMER_ID` Puoi trovare il tuo ID cliente utilizzando i seguenti metodi: Utilizza il comando `gcloud organizations describe`. L'ID workspace si trova nel campo `directoryCustomerId` della risposta. Utilizza il metodo `organizations.get` nell'API Cloud Resource Manager. L'ID workspace si trova nel campo `directoryCustomerId` della risposta. Visualizza il tuo ID cliente nella Console di amministrazione. Questo metodo richiede il ruolo di super amministratore Google Workspace.	L'organizzazione associata al dominio Google Workspace
Set di entità del progetto	Contiene tutti i service account, i pool di identità del workload e le identità dell'agente nel progetto specificato. Formato: `//cloudresourcemanager.googleapis.com/projects/PROJECT_ID`	Il progetto
Set di entità della cartella	Contiene tutti i service account, tutti i pool di identità del workload e tutte le identità agente 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 ID cliente Google Workspace Tutti i pool di identità della forza lavoro nella tua organizzazione Tutti i service account, i pool di identità del workload e le identità dell'agente in qualsiasi progetto dell'organizzazione Formato: `//cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_ID`	L'organizzazione
Identità dell'agente	Tutte le identità dell'agente nel dominio di attendibilità del progetto specificato. Per impostazione predefinita, il dominio di attendibilità di un progetto contiene tutte le identità dell'agente nel progetto. Formati: `//agents.global.org-ORGANIZATION_ID.system.id.goog/attribute.container/projects/PROJECT_NUMBER` `//agents.global.proj-PROJECT_NUMBER.system.id.goog/attribute.container/projects/PROJECT_NUMBER`	Il progetto

Associazioni di policy condizionali per le policy sul confine di accesso dell'entità

Puoi utilizzare le espressioni di condizione nelle associazioni di policy per le policy sul confine di accesso dell'entità per perfezionare ulteriormente le entità a cui si applica la policy.

Le espressioni di condizione per le associazioni di policy sono costituite da una o più istruzioni unite da un massimo di 10 operatori logici (&&, || o !). Ogni istruzione esprime una regola di controllo basata sugli attributi che si applica all'associazione di policy e determina in definitiva se la policy si applica.

Puoi utilizzare gli attributi principal.type e principal.subject nelle condizioni per i binding delle policy. Nessun altro attributo è supportato nelle condizioni per i binding delle norme.

L'attributo principal.type indica il tipo di entità presente nella richiesta, ad esempio service account o identità in un pool di identità per i workload. Puoi utilizzare le condizioni con questo attributo per controllare a quali tipi di entità si applica una policy sul confine di accesso dell'entità.

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à del principal nella richiesta, ad esempio cruz@example.com. Puoi utilizzare le condizioni con questo attributo per controllare esattamente quali entità sono soggette a un criterio sul confine di accesso dell'entità.

Ad esempio, se aggiungi la seguente espressione di condizione a un'associazione per una policy sul confine di accesso dell'entità, la policy non verrà applicata 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 utilizzare le condizioni nei binding delle policy sul confine di accesso dell'entità è ridurre le risorse a cui una singola entità può accedere.

Supponiamo 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 una policy sul confine di accesso dell'entità che rende le entità idonee ad accedere a tutte le risorse dell'organizzazione example.com. Questo criterio è associato al set di entità dell'organizzazione example.com.

Decidi che dev-project-service-account non deve avere l'idoneità per accedere a tutte le risorse in example.com, ma solo a quelle in dev-project. Tuttavia, non vuoi modificare le risorse a cui possono accedere le altre entità nel set di entità example.com.

Per apportare questa modifica, segui la procedura per ridurre le risorse a cui le entità possono accedere, ma aggiungi una condizione all'associazione di policy anziché eliminarla:

Confermi che l'unica policy sul confine di accesso dell'entità a cui è soggetto dev-project-service-account è la policy che rende le entità idonee ad accedere a tutte le risorse in example.com.
Crea una nuova policy di Principal Access Boundary che renda le entità idonee ad accedere alle risorse in dev-project e collegala al set di entità per dev-project. Utilizzi la seguente condizione nel binding della policy per assicurarti che la policy venga applicata 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'"
}
```
Esoneri dev-project-service-account dalla policy sul confine di accesso dell'entità che rende le entità idonee ad accedere a tutte le risorse in example.com. Per farlo, aggiungi la seguente condizione all'associazione di policy che collega la policy sul confine di accesso dell'entità al set 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 le policy sul confine di accesso dell'entità esistenti, consulta Modificare le policy sul confine di accesso dell'entità.

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

Associazioni di policy tra organizzazioni

Non puoi creare un'associazione di policy tra organizzazioni per una policy di confine dell'accesso dell'entità. Un'associazione di policy tra organizzazioni è un'associazione di policy che associa una policy di un'organizzazione a un set di entità di un'altra organizzazione.

IAM elimina periodicamente tutti i binding dei criteri cross-organization esistenti. I binding dei criteri tra organizzazioni possono verificarsi quando sposti un progetto da un'organizzazione a un'altra. Ad esempio, considera la seguente situazione:

Hai un progetto, example-project, nell'organizzazione example.com.
Vuoi che le entità in example-project siano idonee ad accedere alle risorse in example.com. Per farlo, crea una policy di Principal Access Boundary in example.com che renda le entità idonee ad accedere alle risorse in example.com e associa questa policy al set di entità per example-project.
Sposti example-project da example.com a cymbalgroup.com.

In questa situazione, lo spostamento del progetto creerebbe un'associazione di policy tra organizzazioni. Questo perché la policy sul confine di accesso dell'entità in example.com sarebbe associata a un insieme di entità in cymbalgroup.com. Se non elimini manualmente l'associazione, IAM la eliminerà automaticamente. L'eliminazione di questa associazione contribuisce a garantire che gli amministratori di cymbalgroup.com abbiano accesso a tutte le policy sul confine di accesso dell'entità associate alle loro entità.

Interazioni tra policy

IAM valuta ogni policy sul confine di accesso dell'entità in combinazione con le policy di autorizzazione e negazione e con le altre policy sul confine di accesso dell'entità. Tutte queste policy vengono utilizzate per determinare se un'entità può accedere a una risorsa.

Interazione con altri tipi di norme

Quando un'entità tenta di accedere a una risorsa, IAM valuta tutte le policy sul confine di accesso dell'entità, di autorizzazione e di negazione pertinenti per verificare se l'entità è autorizzata ad accedere alla risorsa. Se uno qualsiasi di questi criteri indica che l'entità non deve essere in grado di accedere alla risorsa, IAM impedisce l'accesso.

Di conseguenza, se una policy sul confine di accesso dell'entità impedisce a un'entità di accedere a una risorsa, IAM le impedisce di accedere a quella risorsa, indipendentemente dalle policy di autorizzazione e negazione associate alla risorsa.

Inoltre, le policy sul confine di accesso dell'entità da sole non concedono alle entità l'accesso alle risorse. Sebbene le policy di Principal Access Boundary possano rendere un'entità idonea ad accedere a una risorsa, solo le policy di autorizzazione possono effettivamente concedere all'entità l'accesso alla risorsa.

Per scoprire di più sulla valutazione delle policy IAM, consulta Valutazione delle policy.

Interazione tra le policy sul confine di accesso dell'entità

Se una policy sul confine di accesso dell'entità rende un'entità idonea ad accedere a una risorsa, l'entità è idonea ad accedere a quella risorsa, indipendentemente dalle altre policy sul confine di accesso dell'entità a cui è soggetta. Di conseguenza, se un'entità è già soggetta a una policy sul confine di accesso dell'entità, non puoi aggiungere policy sul confine di accesso dell'entità per ridurre l'accesso di un'entità.

Ad esempio, supponiamo che un'entità, Dana (dana@example.com), sia soggetta a un'unica policy sul confine di accesso dell'entità, prod-projects-policy. Questa policy rende le entità idonee ad accedere alle risorse in prod-project. Dana è soggetta a questo criterio perché è associato al set di entità della sua organizzazione.

Crea una nuova policy sul confine di accesso dell'entità, dev-staging-projects-policy, che rende le entità idonee ad accedere alle risorse in dev-project e staging-project, quindi la associa al set di entità dell'organizzazione.

In seguito a queste policy sul confine di accesso dell'entità, Dana può 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 le policy sul confine di accesso dell'entità a cui è soggetta.

Ad esempio, puoi modificare dev-staging-projects-policy in modo che non renda le entità idonee ad accedere alle risorse in dev-project. In questo caso, Dana potrebbe accedere solo alle risorse in staging-project e prod-project.

In alternativa, puoi rimuovere prod-projects-policy eliminando l'associazione di criteri che lo associa al set di entità dell'organizzazione. In questo caso, Dana potrà accedere solo alle risorse in dev-project e staging-project.

Tuttavia, queste modifiche non riguardano solo Dana, ma anche le altre entità soggette alle policy e ai binding del confine di accesso dell'entità modificati. Se vuoi ridurre le risorse a cui una singola entità può accedere, utilizza le associazioni di policy condizionali.

Ereditarietà delle policy

Le policy sul confine di accesso dell'entità sono associate a insiemi di entità, non a risorse Resource Manager. Di conseguenza, non vengono ereditati tramite la gerarchia delle risorse nello stesso modo in cui vengono ereditati i criteri di autorizzazione e negazione.

Tuttavia, i set di entità per le risorse padre di Resource Manager, ovvero cartelle e organizzazioni, includono sempre tutte le entità nei set di entità dei relativi discendenti. Ad esempio, se un'entità è inclusa nel set di entità di un progetto, è inclusa anche nei set di entità di eventuali cartelle o organizzazioni padre.

Ad esempio, considera un'organizzazione, example.com. Questa organizzazione è associata al dominio example.com e ha le seguenti risorse Resource Manager:

Gerarchia delle risorse per example.com

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

I set di entità di queste risorse 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`	Service account e pool di identità del workload in `project-1`	Service account e pool di identità del workload in `project-2`	Service account e pool di identità del workload in `project-3`
Entità impostata per `example.com`
Entità impostata per `folder-a`
Entità impostata per `project-1`
Entità impostata per `project-2`
Entità impostata per `project-3`

Di conseguenza, le seguenti entità sono interessate dalle seguenti policy sul confine di accesso dell'entità:

Un'identità Google Workspace nel dominio example.com si trova nell'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 si trova negli 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 si trova negli 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 qualsiasi di questi insiemi di entità.

Policy sul confine di accesso dell'entità 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 leggibili pubblicamente.

La possibilità che il confine di accesso dell'entità impedisca alle entità non idonee di visualizzare una risorsa visibile pubblicamente dipende dal fatto che la risorsa sia memorizzata nella cache:

Se la risorsa è memorizzata nella cache, il confine di accesso dell'entità non può impedire alle entità di visualizzare la risorsa
Se la risorsa non è memorizzata nella cache, il confine di accesso dell'entità impedisce alle entità non idonee di visualizzarla

In tutti i casi, le policy sul confine di accesso dell'entità impediscono alle entità non idonee di modificare o eliminare le risorse visibili pubblicamente.

Struttura di una policy sul confine di accesso dell'entità

Una policy sul confine di accesso dell'entità è una raccolta di metadati e dettagli della policy sul confine di accesso dell'entità. I metadati forniscono informazioni come il nome della norma e la data di creazione. I dettagli della policy definiscono cosa fa la policy, ad esempio le risorse a cui le entità interessate possono accedere.

Ad esempio, la seguente policy sul confine di accesso dell'entità rende le entità soggette alla policy idonee ad accedere alle risorse nell'organizzazione con l'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 nei metadati e nei dettagli di una policy Principal Access Boundary.

Metadati

Le policy sul confine di accesso dell'entità contengono i seguenti metadati:

name: Il nome della policy sul confine di accesso dell'entità. Questo nome ha il formato organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID, dove ORGANIZATION_ID è l'ID numerico dell'organizzazione in cui è stata creata la policy sul confine di accesso dell'entità e PAB_POLICY_ID è l'ID alfanumerico della policy sul confine di accesso dell'entità.
uid: un ID univoco assegnato alla policy sul confine di accesso dell'entità.
etag: un identificatore per lo stato attuale della norma. Questo valore cambia quando aggiorni il criterio. Per evitare aggiornamenti in conflitto, il valore di 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 la policy del limite di accesso dell'entità.
annotations: (Facoltativo) Un elenco di coppie chiave-valore definite dall'utente. Puoi utilizzare queste annotazioni per aggiungere metadati aggiuntivi alla norma, ad esempio chi ha creato la norma o se è stata implementata da una pipeline automatica. Per saperne di più sulle annotazioni, consulta Annotazioni.
createTime: l'ora in cui è stata creata la policy sul confine di accesso dell'entità.
updateTime: l'ora dell'ultimo aggiornamento della policy sul confine di accesso dell'entità.

Dettagli

Ogni policy sul confine di accesso dell'entità contiene un campo details. Questo campo contiene le regole per il confine di accesso dell'entità e la versione di applicazione:

rules: un elenco di regole del confine di accesso dell'entità, che definiscono le risorse a cui le entità interessate possono accedere. Ogni regola contiene i seguenti campi:
- description: una descrizione della regola leggibile da una persona.
- resources: un elenco di risorse Resource Manager (progetti, cartelle e organizzazioni) a cui vuoi che le entità possano accedere. Qualsiasi entità soggetta a queste norme è idonea ad accedere a queste risorse.
  
  Ogni policy sul confine di accesso dell'entità può fare riferimento a un massimo di 500 risorse in tutte le regole della policy.
- effect: La relazione che i principal hanno con le risorse elencate nel campo resources. L'unico effetto che puoi specificare nelle regole del confine di accesso dell'entità è "ALLOW". Questa relazione rende le entità idonee ad accedere alle risorse elencate nella regola.
enforcementVersion: La versione di applicazione utilizzata da IAM quando applica la policy. La versione della policy sul confine di accesso dell'entità determina quali autorizzazioni può bloccare.

Per ulteriori informazioni sulle versioni delle policy sul confine di accesso dell'entità, consulta Versioni dell'applicazione del confine di accesso dell'entità in questa pagina.

Struttura di un'associazione di policy

Un'associazione di policy per una policy sul confine di accesso dell'entità contiene il nome di una policy, il nome dell'insieme di entità a cui associare la policy e i metadati che descrivono l'associazione di policy. Può anche contenere condizioni che modificano i principal esatti a cui si applica la policy.

Ad esempio, la seguente associazione di policy associa la policy example-policy a tutte le entità nella example.com organizzazione, che ha l'ID 0123456789012. Il binding del criterio 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 binding delle policy contiene i seguenti campi:

name: Il nome del binding della policy. 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 padre del binding dei criteri e BINDING_ID è l'ID alfanumerico del binding dei criteri.
uid: un ID univoco assegnato al binding della policy.
etag: un identificatore per lo stato attuale della norma. 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 binding della policy.
annotations: (Facoltativo) Un elenco di coppie chiave-valore definite dall'utente. Puoi utilizzare queste annotazioni per aggiungere metadati aggiuntivi all'associazione di policy, ad esempio chi ha creato l'associazione di policy o se è stata implementata da una pipeline automatizzata. Per saperne di più sulle annotazioni, consulta Annotazioni.
target: Il set di entità a cui associare la policy. Il valore ha il formato {"principalSet": PRINCIPAL_SET}, dove PRINCIPAL_SET è l'ID del set di entità di cui vuoi eseguire il binding della policy.

Ogni target può avere fino a 10 policy associate.
policyKind: Il tipo di policy a cui fa riferimento il binding della policy. Per le associazioni di policy per le policy sul confine di accesso dell'entità, questo valore è sempre PRINCIPAL_ACCESS_BOUNDARY.
policy: la policy sul confine di accesso dell'entità da associare al set di entità di destinazione.
policyUid: un ID univoco assegnato alla policy sul confine di accesso dell'entità a cui viene fatto riferimento nel campo policy.
condition: (Facoltativo) Un'espressione logica che influisce sulle entità per le quali IAM applica il criterio. Se la condizione restituisce true o non può essere valutata, Identity and Access Management applica il criterio al principal che effettua la richiesta. Se la condizione restituisce il valore false, Identity and Access Management non applica il criterio all'entità. Per ulteriori informazioni, consulta Confine di accesso dell'entità e condizioni in questa pagina.
createTime: l'ora in cui è stata creata l'associazione di policy.
updateTime: l'ora in cui l'associazione della policy è stata aggiornata l'ultima volta.

Casi d'uso

Di seguito sono riportate situazioni comuni in cui potresti voler utilizzare le policy sul confine di accesso dell'entità ed esempi di policy sul confine di accesso dell'entità e associazioni di policy che potresti creare in ogni situazione. Per scoprire come creare policy sul confine di accesso dell'entità e associarle a insiemi di entità, consulta Creare e applicare policy sul confine di accesso dell'entità.

Rendere le entità idonee ad accedere alle risorse della tua organizzazione

Puoi utilizzare una policy sul confine di accesso dell'entità per rendere le entità della tua organizzazione idonee ad accedere alle risorse all'interno della tua organizzazione. Se questo è l'unico criterio di Principal Access Boundary a cui sono soggette le entità della tua organizzazione, allora il criterio di Principal Access Boundary renderà le entità della tua organizzazione non idonee ad accedere alle risorse al di fuori della tua organizzazione.

Ad esempio, supponiamo che tu voglia rendere tutti i principal dell'organizzazione example.com idonei ad accedere alle risorse all'interno di example.com e non idonei ad accedere alle risorse di altre organizzazioni. Le entità che si trovano in example.com includono tutte le identità nel dominio example.com, tutti i pool di identità della forza lavoro in example.com e tutti i service account e i pool di identità del workload in qualsiasi progetto in example.com.

Non hai criteri di Principal Access Boundary che si applicano a nessuna delle entità della tua organizzazione. Di conseguenza, tutte le entità sono idonee ad accedere a tutte le risorse.

Per rendere le entità idonee ad accedere alle risorse in example.com e non idonee ad accedere alle risorse al di fuori di example.com, crea una policy sul confine di accesso dell'entità che rende 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 di policy per associare questa policy al set di entità dell'organizzazione:

{
  "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"
}

Se associato al set di entità dell'organizzazione, questo criterio rende tutte le entità in example.com idonee ad accedere alle risorse in example.com. Poiché questa è l'unica policy sul confine di accesso dell'entità a cui sono soggette queste entità, la policy rende anche le entità in example.com non idonee ad accedere alle risorse al di fuori della tua organizzazione. Ciò significa che non possono utilizzare le autorizzazioni bloccate dalla policy sul confine di accesso dell'entità per accedere alle risorse al di fuori di example.com, anche se dispongono di queste autorizzazioni per queste risorse.

Rendere idonei i service account ad accedere alle risorse in un singolo progetto

Puoi creare una policy sul confine di accesso dell'entità per rendere i service account di un progetto specifico idonei ad accedere alle risorse all'interno di quel progetto.

Se questo è l'unico criterio del limite di accesso dell'entità a cui sono soggetti i service account, questi ultimi potranno accedere solo alle risorse all'interno di questo progetto.

Ad esempio, supponiamo di avere un progetto, example-dev, con il numero di progetto 901234567890. Vuoi assicurarti che i service account in example-dev siano idonei solo per accedere alle risorse in example-dev.

Hai una policy sul confine di accesso dell'entità che rende tutte le entità della tua organizzazione, inclusi i service account in example-dev, idonee ad accedere alle risorse in example.com. Per vedere l'aspetto di questo tipo di criterio, consulta Rendere le entità idonee ad accedere alle risorse della tua organizzazione.

Per rendere i service account in example-dev non idonei ad accedere alle risorse al di fuori di example-dev, devi prima creare una policy di confine dell'accesso dell'entità che renda 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 crei un'associazione di policy per associare questa policy a tutte le entità in example-dev e aggiungi una condizione in modo che l'associazione di policy 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, questa norma da sola non modifica le risorse a cui gli account di servizio possono accedere. Ciò è dovuto al fatto che esiste una policy di confine di accesso dell'entità che rende tutte le entità in example.com idonee ad accedere a tutte le risorse in example.com. Le policy sul confine di accesso dell'entità sono additive, quindi i service account in example-dev sono ancora idonei ad accedere a tutte le risorse in example.com.

Per assicurarti che i service account in example-dev siano idonei solo ad accedere alle risorse in example-dev, devi aggiungere una condizione al binding dei criteri per i criteri sul confine di accesso dell'entità esistenti che impedisca la loro applicazione ai service account, inclusi i service account predefiniti, 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') || !principal.subject == 'example-dev@appspot.gserviceaccount.com || !principal.subject == '901234567890-compute@developer.gserviceaccount.com'"
  }
}

Ora, i service account in example-dev sono idonei solo per accedere alle risorse in example-dev. Non possono utilizzare le autorizzazioni bloccate dal criterio di Principal Access Boundary per accedere alle risorse al di fuori di example-dev, anche se dispongono di queste autorizzazioni per queste risorse.

In un secondo momento, se vuoi aumentare le risorse a cui questi service account possono accedere, puoi aggiungere risorse aggiuntive al criterio example-dev-only o creare un criterio Principal Access Boundary aggiuntivo e associarlo ai service account.