Policy di Principal Access Boundary

Le policy sul confine di accesso dell'entità (PAB) ti consentono di definire le risorse a cui le entità possono accedere.

Altre norme relative all'accesso, come le norme di autorizzazione e negazione, sono associate alle risorse. Questi criteri definiscono chi è autorizzato ad accedere alla risorsa a cui sono collegati. Al contrario, le policy di Principal Access Boundary sono associate agli insiemi di entità e controllano cosa possono fare le entità nell'insieme di entità.

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&#3esfiltrazione di datiti.

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 criterio di autorizzazione concede a un'entità l'accesso a una risorsa e nessun criterio di negazione blocca l'accesso, l'entità può accedere alla risorsa.

Con le policy sul confine di accesso dell'entità, puoi definire le risorse a cui un'entità è idonea ad accedere. Se un'entità non è idonea ad accedere a una risorsa, il suo accesso a quella risorsa è limitato, indipendentemente dai ruoli che le sono stati concessi. Per saperne di più sull'utilizzo delle policy sul confine di accesso dell'entità per definire le risorse a cui un'entità può accedere, consulta Definisci le risorse idonee.

Le policy sul confine di accesso dell'entità bloccano solo i tentativi di accesso che coinvolgono autorizzazioni supportate. Se un criterio sul confine di accesso dell'entità non può bloccare un'autorizzazione, le entità possono utilizzare questa autorizzazione per accedere a qualsiasi risorsa, indipendentemente dai criteri a cui sono soggette. Per saperne di più, consulta Autorizzazioni che possono essere bloccate dalle policy sul confine di accesso dell'entità.

Casi d'uso

I criteri di Principal Access Boundary sono utili in circostanze come le seguenti:

• Impedire alle entità di accedere alle risorse che non possiedi
• Limitare determinati tipi di entità, come gli account di servizio, a determinati progetti

Per esempi dettagliati di come utilizzare le policy sul confine di accesso dell'entità in situazioni come queste, consulta Esempi di casi d'uso per le policy sul confine di accesso dell'entità.

Componenti del criterio di Principal Access Boundary

Le policy sul confine di accesso dell'entità sono costituite da singole regole. Ogni regola definisce un insieme di risorse a cui le entità possono accedere. Ogni policy può avere fino a 500 regole.

I criteri contengono anche altre informazioni, inclusi metadati e dettagli di configurazione. Per saperne di più, consulta Struttura di una policy sul confine di accesso dell'entità.

Dopo aver creato un criterio di confine dell'accesso dell'entità, lo applichi a insiemi di entità creando associazioni di policy. Tutte le entità in questi set di entità sono quindi soggette a questa policy sul confine di accesso dell'entità, il che significa che sono idonee ad accedere alle risorse elencate nella policy. Puoi associare un criterio di confine di accesso dell'entità a un numero qualsiasi di insiemi di entità.

Puoi creare fino a 1000 criteri di Principal Access Boundary nella tua organizzazione.

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

Le policy sul confine di accesso dell'entità possono bloccare tutte le autorizzazioni incluse nella versione di applicazione della policy. Se una policy sul confine di accesso dell'entità può bloccare un'autorizzazione, può impedire alle entità non idonee di utilizzare questa autorizzazione per accedere alle risorse.

Specifichi la versione di applicazione di una policy quando la crei. L'aggiornamento della versione di applicazione aggiorna le autorizzazioni che il criterio può bloccare. Per un elenco completo delle autorizzazioni bloccate da ogni versione dell'applicazione, consulta il riferimento alla versione dell'applicazione.

Se una policy sul confine di accesso dell'entità non può bloccare un'autorizzazione, non ha alcun effetto sulla possibilità delle entità di utilizzare l'autorizzazione. In altre parole, IAM non può applicare il criterio per i tentativi di accesso che coinvolgono questa autorizzazione.

Ad esempio, supponiamo che a un'entità, Lee ([e-mail]), venga concesso il ruolo Sviluppatore Dataflow (roles/dataflow.developer). Questo ruolo include l'autorizzazione dataflow.googleapis.com/jobs.snapshot, che consente a Lee di creare snapshot dei job Dataflow. Lee è anche soggetto a una policy sul confine di accesso dell'entità che lo rende non idoneo ad accedere alle risorse al di fuori di example.com. Tuttavia, se questa policy Principal Access Boundary non può bloccare l'autorizzazione dataflow.jobs.snapshot, Lee può comunque acquisire snapshot dei job Dataflow nelle organizzazioni al di fuori di example.com.

Gestire le versioni dell'applicazione

Periodicamente, IAM aggiunge nuove versioni di applicazione 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 tue policy sul confine di accesso dell'entità in modo che utilizzino la nuova versione.

Se vuoi che la versione di applicazione di una norma venga aggiornata automaticamente man mano che vengono rilasciate nuove versioni, puoi utilizzare il valore latest quando crei la norma. Tuttavia, non consigliamo di utilizzare questo valore perché potrebbe causare la perdita imprevista dell'accesso alle risorse da parte dei principal.

Le policy che utilizzano latest per il numero di versione utilizzano la versione di applicazione predefinita. La versione di applicazione predefinita è in genere la più recente. Tuttavia, possono essere necessarie fino a 4 settimane prima che una nuova versione diventi la versione di applicazione predefinita. Per scoprire quale versione di applicazione è quella predefinita, consulta il riferimento alla versione di applicazione.

La versione di applicazione predefinita viene utilizzata anche per le nuove policy sul confine di accesso dell'entità che non specificano un numero di versione.

Definisci le risorse idonee

Le entità possono essere interessate da, o soggette a, un numero qualsiasi di policy sul confine di accesso dell'entità. Insieme, queste policy definiscono le risorse a cui l'entità è idonea ad accedere.

Le policy sul confine di accesso dell'entità sono additive. Ciò significa che le risorse a cui un'entità può accedere sono l'unione di tutte le risorse in tutte le policy sul confine di accesso dell'entità a cui è soggetta. In altre parole, se una singola policy sul confine di accesso dell'entità rende un'entità idonea ad accedere a una risorsa, allora è idonea ad accedere alla risorsa, indipendentemente dalle altre policy sul confine di accesso dell'entità a cui è soggetta.

Se un'entità non è soggetta ad alcuna policy sul confine di accesso dell'entità, è idonea ad accedere a qualsiasi risorsa Google Cloud .

Le sezioni seguenti descrivono come personalizzare l'insieme di risorse a cui un principal può accedere.

Aggiungere risorse idonee

Esistono diversi modi per rendere un'entità idonea ad accedere a una risorsa a cui non può accedere:

• Aggiungi la risorsa a una policy sul confine di accesso dell'entità a cui è soggetta l'entità.
• Crea una nuova policy sul confine di accesso dell'entità con la risorsa aggiuntiva e associa la policy a un insieme di entità che include l'entità.
• Rimuovi o elimina tutte le policy sul confine di accesso dell'entità a cui è soggetta l'entità. Questa azione rende l'entità idonea ad accedere a tutte le risorse Google Cloud .

Rimuovere le risorse idonee

Esistono diversi modi per rendere un'entità non idonea ad accedere a una risorsa a cui è idonea ad accedere.

Innanzitutto, trova tutte le policy sul confine di accesso dell'entità a cui è soggetta l'entità che includono la risorsa. In base alle norme che trovi, puoi eseguire una delle seguenti operazioni:

• Se l'entità non è soggetta ad alcuna policy sul confine di accesso dell'entità, allora crea una nuova policy sul confine di accesso dell'entità che includa solo le risorse a cui vuoi che l'entità possa accedere. Poi, associa questa policy a un set di entità che contiene l'entità.

  Dopo aver applicato il criterio, l'entità passa dall'idoneità ad accedere a tutte le risorse all'idoneità ad accedere solo alle risorse elencate nel criterio.

• Se l'entità è già soggetta a una o più policy sul confine di accesso dell'entità, devi assicurarti che nessuna delle policy sul confine di accesso dell'entità a cui è soggetta includa la risorsa. Per istruzioni passo passo, vedi Ridurre le risorse a cui i principal possono accedere.

  Durante questo processo, devi assicurarti che l'entità sia sempre soggetta ad almeno una policy sul confine di accesso dell'entità. In caso contrario, l'entità potrebbe diventare idonea ad accedere a tutte le risorse.

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à di un criterio di Principal Access Boundary di impedire alle entità non idonee di visualizzare una risorsa visibile pubblicamente dipende dalla memorizzazione nella cache della risorsa:

• Se la risorsa è memorizzata nella cache, le policy sul confine di accesso dell'entità non possono impedire alle entità di visualizzarla
• Se la risorsa non è memorizzata nella cache, il confine di accesso dell'entità impedisce alle entità non idonee di visualizzarla

In tutti i casi, i criteri di Principal Access Boundary impediscono comunque alle entità non idonee di modificare o eliminare le risorse visibili pubblicamente.

Valutazione dei criteri di Principal Access Boundary

Quando un'entità tenta di accedere a una risorsa, IAM valuta le policy sul confine di accesso dell'entità pertinenti per determinare se bloccare il tentativo di accesso. Un criterio è pertinente se l'entità che tenta di accedere è soggetta al criterio.

Le policy sul confine di accesso dell'entità possono solo bloccare o non bloccare l'accesso, non possono concederlo. Solo le policy di autorizzazione possono effettivamente concedere alle entità l'accesso alle risorse. Per scoprire in che modo i diversi tipi di policy influiscono sull'accesso dei principal alle risorse, consulta Tipi di policy.

IAM non blocca l'accesso se si verifica una delle seguenti condizioni:

• L'entità non è soggetta ad alcuna policy sul confine di accesso dell'entità
• Le policy sul confine di accesso dell'entità pertinenti non possono bloccare l'autorizzazione nella richiesta
• Una policy sul confine di accesso dell'entità rende l'entità idonea ad accedere alla risorsa

IAM blocca l'accesso se l'entità è soggetta ad almeno una policy sul confine di accesso dell'entità, ma nessuna delle policy pertinenti rende l'entità idonea ad accedere alla risorsa.

Valutazione con esito negativo

Le policy sul confine di accesso dell'entità non vanno a buon fine. Ciò significa che, se IAM rileva un errore durante la valutazione di una policy sul confine di accesso dell'entità, impedisce all'entità di accedere alla risorsa.

Il motivo più comune per cui IAM rileva un errore durante la valutazione delle policy Principal Access Boundary è che i dettagli di un'entità sono ancora in fase di propagazione nel sistema. Ciò si verifica più probabilmente per gli utenti creati di recente. Per risolvere il problema, chiedi al nuovo principal di attendere e riprovare ad accedere alla risorsa in un secondo momento.

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

Per applicare una policy sul confine di accesso dell'entità a un insieme di entità, crea un'associazione policy che specifica sia la policy sul confine di accesso dell'entità che vuoi applicare sia l'insieme di entità a cui vuoi applicarla. Questa associazione della policy associa la policy al set di entità.

Dopo aver associato una policy a un set di entità, le entità in quel set di entità possono accedere solo alle risorse elencate nelle policy sul confine di accesso dell'entità a cui sono soggette.

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

Puoi creare associazioni solo per le policy di Principal Access Boundary 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à 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 del 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

Ereditarietà delle policy e set di entità

Le policy sul confine di accesso dell'entità sono associate a insiemi di entità, non a risorse. 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 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 principali.

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

• 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, pool di identità del workload e identità dell'agente in project-1	Service account, pool di identità del workload e identità dell'agente in project-2	Service account, pool di identità del workload e identità dell'agente 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 dalle policy sul confine di accesso dell'entità associate 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'identità agente in project-3 si trova negli insiemi di entità per project-3, folder-a e example.com e sarà interessata da policy sul confine di accesso dell'entità associate a uno qualsiasi di questi insiemi di entità.

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 dei criteri. Non sono supportati altri attributi.

• L'attributo principal.type si riferisce al tipo di entità che ha effettuato la richiesta, ad esempio un account di servizio o un'identità agente. 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 si riferisce all'identità dell'entità che ha effettuato la richiesta, ad esempio [e-mail]. Puoi utilizzare le condizioni con questo attributo per controllare esattamente quali entità sono soggette a una policy sul confine di accesso dell'entità.

  Ad esempio, se aggiungi la seguente espressione di condizione a un'associazione per una policy Principal Access Boundary, la policy non verrà applicata all'utente [e-mail]:

  principal.subject != '[e-mail]'
  

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

Per un esempio di come utilizzare queste condizioni nelle policy del perimetro di accesso dell'entità, vedi Rendere idonei i service account ad accedere alle risorse in un singolo progetto.

Associazioni di policy tra organizzazioni

Non puoi creare un'associazione di policy tra organizzazioni per una policy di Principal Access Boundary. 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 crea un'associazione di policy tra organizzazioni. Ciò è dovuto al fatto che la policy sul confine di accesso dell'entità in example.com è associata a un'entità impostata in cymbalgroup.com. Se non elimini l'associazione manualmente, IAM la elimina automaticamente. L'eliminazione di questa associazione contribuisce a garantire che gli amministratori di cymbalgroup.com abbiano accesso a tutti i criteri di Principal Access Boundary associati alle loro entità.

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

Un criterio di Principal Access Boundary è una raccolta di metadati e dettagli del criterio di Principal Access Boundary. I metadati forniscono informazioni come il nome della norma e la data di creazione. I dettagli dei criteri definiscono cosa fanno i criteri, ad esempio le risorse a cui le entità interessate sono idonee ad 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": "4"
  }
}

Le sezioni seguenti descrivono i campi nei metadati e nei dettagli di una policy di Principal Access Boundary.

Metadati

I criteri di Principal Access Boundary contengono i seguenti metadati:

• name: Il nome della policy 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 è stata creata la policy di confine dell'accesso dell'entità e PAB_POLICY_ID è l'ID alfanumerico della policy di confine dell'accesso dell'entità.
• uid: un ID univoco assegnato al criterio di Principal Access Boundary.
• etag: un identificatore per lo stato attuale della policy. Questo valore cambia quando aggiorni il criterio. Per evitare aggiornamenti in conflitto, il valore di etag deve corrispondere al valore archiviato in IAM. Se i valori etag non corrispondono, la richiesta non va a buon fine.
• displayName: un nome leggibile per la policy Principal Access Boundary.
• 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 è stato creato il criterio di confine dell'accesso dell'entità.
• updateTime: L'ora in cui è stato aggiornato per l'ultima volta il criterio di Principal Access Boundary.

Dettagli

Ogni policy sul confine di accesso dell'entità contiene un campo details. Questo campo contiene le regole del 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 questa policy è 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 la policy sul confine di accesso dell'entità.

  Per saperne di più su come impostare e gestire le versioni di applicazione, consulta Gestire le versioni di applicazione 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 del set 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 il criterio.

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à [e-mail].

{
  "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 [e-mail]",
    "expression": "principal.subject != '[e-mail]'"
  },
  "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 archiviato 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 delle policy sul confine di accesso dell'entità, questo valore è sempre PRINCIPAL_ACCESS_BOUNDARY.

• policy: la policy di Principal Access Boundary da associare al set di entità di destinazione.

• policyUid: un ID univoco assegnato al criterio di Principal Access Boundary 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 di policy è stata aggiornata l'ultima volta.

Passaggi successivi

• Scopri di più sui casi d'uso per le policy sul confine di accesso dell'entità.
• Scopri come creare e applicare le policy sul confine di accesso dell'entità.
• Esamina l'autorizzazione bloccata da ogni versione di applicazione della policy sul confine di accesso dell'entità.