Criteri di Principal Access Boundary

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

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

Ad esempio, puoi usare i criteri di Principal Access Boundary per impedire alle entità di accedere alle risorse di altre organizzazioni, il che può aiutare a prevenire il phishing attacchi 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. Questo significa che se un'entità ha un'autorizzazione per la risorsa e non viene negata con quell'autorizzazione, può utilizzarla per accedere alla risorsa.

Con i criteri di Principal Access Boundary, puoi limitare le risorse di cui L'entità è idonea all'accesso. 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 Autorizzazioni che possono essere bloccate da Principal Access Boundary.

I criteri di Principal Access Boundary sono costituiti da Principal Access Boundary . Ogni regola di limite di accesso all'entità definisce un insieme di risorse a cui le entità interessate sono idonee ad 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:

• Il Tal dell'entità ([e-mail]) 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 contiene l'autorizzazione storage.objects.get, necessaria per per visualizzare gli oggetti nel bucket.
• In cymbalgroup.com non esistono criteri di negazione che impediscano a Tal di usare 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 ha l'autorizzazione per creare criteri di rifiuto in cymbalgroup.com, pertanto non può utilizzare un criterio di rifiuto per impedire a Tal di accedere al bucket.

Tuttavia, con i criteri di Principal Access Boundary, gli amministratori di altostrat.com possono assicurarsi che Tal non possa visualizzare gli oggetti nel bucket cymbalgroup.com o in qualsiasi altro bucket esterno a altostrat.com. A tale scopo, gli amministratori possono creare un criterio di confine dell'accesso dell'entità che indica che le entità altostrat.com sono idonee ad accedere solo alle risorse in altostrat.com. Poi, può creare un'associazione di criteri per collegare questo criterio a tutti i principali dell'organizzazionealtostrat.com. Con questo criterio, Tal non potrà visualizzare gli oggetti nel bucket cymbalgroup.com, anche se gli è stato concesso 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 riesce a valutare un criterio di Principal Access Boundary, lo ignora e procede a valutare i criteri di autorizzazione e diniego 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 confine di accesso delle entità impediscono loro di utilizzare alcune, ma non tutte, le 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 qualsiasi entità non idonea ad accedere a una risorsa di utilizzare 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 ([e-mail]), sia stato concesso il ruolo sviluppatore Dataflow (roles/dataflow.developer). Questo ruolo include l'autorizzazione dataflow.jobs.snapshot, che consente a Lee di acquisire istantanee dei job Dataflow. Lee è inoltre soggetto a un criterio di limite di accesso all'entità che lo rende non idoneo ad accedere alle 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 limite di accesso all'entità dipendono dalla versione di applicazione del limite di accesso all'entità.

Versioni di applicazione di Principal Access Boundary

Ogni criterio di limite di accesso all'entità specifica una versione di applicazione, che identifica un elenco predefinito di autorizzazioni IAM che il criterio può bloccare. Specifichi la versione di applicazione quando crei o aggiorni un criterio di Principal Access Boundary. Se non specifichi applicazione forzata, IAM utilizza la versione più recente e continuerà a utilizzare quella versione finché non la aggiorni.

Periodicamente, IAM aggiunge nuove versioni di applicazione dei limiti di accesso all'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 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, sconsigliamo di utilizzare questo valore, perché potrebbe causare la perdita imprevista dell'accesso alle risorse da parte dei principali.

Per un elenco completo delle autorizzazioni bloccate da ogni versione di applicazione, consulta Autorizzazioni bloccate dai criteri di confine di accesso principale.

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 aver associato il criterio a un insieme di entità, le entità in questo insieme possono accedere solo alle risorse incluse nelle regole del criterio di confine di accesso delle entità.

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 quel tipo di set di entità
• La risorsa Resource Manager (progetto, cartella o organizzazione) che ha come parente le associazioni dei criteri per quel tipo di set di entità

Set di entità	Dettagli	Associazione di criteri risorsa padre
Pool di identità della forza lavoro	Contiene tutte le identità nella forza lavoro specificata pool di identità. 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à nel pool di identità di carico di lavoro specificato. 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à di carico di lavoro di 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 di criteri condizionali per i criteri di confine dell'accesso dell'entità

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 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 criteri e, in ultima analisi, determina se il criterio si applica.

Puoi utilizzare gli attributi principal.type e principal.subject in per le associazioni di criteri. Nessun altro attributo è supportato nelle condizioni per le associazioni di criteri.

• 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à del principale nella richiesta, ad esempio [e-mail]. Puoi utilizzare condizioni con questo attributo per controllare esattamente quali entità sono soggette a Principal Access Boundary.

  Ad esempio, se aggiungi la seguente espressione di condizione a un'associazione per un criterio di confine di accesso principale, il criterio non verrà applicato 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.

Esempio: utilizzare 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 [e-mail]. 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 volere che dev-project-service-account sia idoneo ad accedere a tutte le risorse in example.com, ma solo 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:

1. 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.

2. 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. Utilizzi quanto segue: condition nell'associazione dei criteri per garantire che il criterio venga applicata solo per dev-project-service-account:

   "condition": {
     "title": "Only dev-project-service-account",
     "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && principal.subject == '[e-mail]'"
   }
   

3. Puoi esonerare dev-project-service-account dal criterio di Principal Access Boundary che rende le entità idonee ad accedere a tutte le risorse in example.com. A A tale scopo, aggiungi la seguente condizione all'associazione di criteri che collega il criterio di Principal Access Boundary di Principal Access Boundary al set di entità dell'organizzazione:

   "condition": {
     "title": "Exempt dev-project-service-account",
     "expression": "principal.subject != '[e-mail]' || 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 dei criteri, dev-project-service-account non è più idoneo ad accedere a tutte le risorse in example.com, ma solo alle risorse 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à principale non deve essere in grado di accedere alla risorsa, IAM impedisce l'accesso.

Di conseguenza, se un criterio di confine di accesso dell'entità impedisce a un'entità di accedere a una risorsa, IAM impedisce a questa entità di accedere alla risorsa, indipendentemente dai criteri di autorizzazione e di negazione associati alla risorsa.

Inoltre, i criteri di Principal Access Boundary non consentono alle entità di accedere Google Cloud. I criteri di Principal Access Boundary possono rendere un'entità idonea per accedere a una risorsa, solo i criteri di autorizzazione possono effettivamente concedere l'entità l'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 aggiungi criteri di Principal Access Boundary per ridurre l'accesso di un'entità.

Ad esempio, immagina che un'entità, Dana ([e-mail]), 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é è associato al set di entità della relativa 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 seguito a questi criteri di Principal Access Boundary, Dana è idonea ad accedere 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, potresti modificare dev-staging-projects-policy in modo che non rendono le entità idonee ad accedere alle risorse in dev-project. Quindi, Dana potrai accedere solo alle risorse in staging-project e prod-project.

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

Importante: se rimuovi un criterio di confine di accesso dell'entità per ridurne l'accesso, assicurati che l'entità sia sempre soggetta ad almeno un criterio di confine di accesso dell'entità. Se un'entità non è soggetta ad alcun criterio di Principal Access Boundary, allora è idonea a: per accedere a tutte le risorse Google Cloud. Per scoprire come ridurre in sicurezza l'accesso di un'entità, consulta la sezione Ridurre le risorse a cui le entità possono accedere.

Tuttavia, queste modifiche non interessano solo Dana, ma riguardano anche le altre le entità soggette ai criteri modificati di Principal Access Boundary e associazioni di contenuti. 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 Principal Access Boundary sono collegati ai set di entità, non Risorse Resource Manager. Di conseguenza, non vengono ereditati tramite la gerarchia delle risorse nello stesso modo in cui lo sono i criteri di autorizzazione e di negazione.

Tuttavia, gli insiemi di entità per le risorse padre di Resource Manager, ovvero cartelle e organizzazioni, includi sempre tutte le entità discendenti set di entità. 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:

• 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

I set di principali di queste risorse contengono le seguenti identità:

Set di entità	Identità Google Workspace nel dominio example.com	Pool di federazione delle identità della 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
Set di entità principale per example.com
Set di entità principale per folder-a
Set di entità principale per project-1
Set di entità principale per project-2
Entità impostata per project-3

Di conseguenza, le seguenti entità sono interessate dai seguenti criteri di Principal Access Boundary:

• 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 si trova negli insiemi di entità per project-1 e example.com e saranno interessati dal limite di accesso all'entità associati a uno di questi set 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 Principal Access Boundary impediscono alle entità non idonee di Modifica o eliminazione di risorse visibili pubblicamente.

Struttura di un criterio di confine dell'accesso dell'entità

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 la data di creazione. I dettagli dei criteri definiscono di un criterio, ad esempio le risorse interessate idonei per l'accesso.

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 per lo stato corrente 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, vedi Annotazioni.
• createTime: la data e l'ora in cui è stato creato il criterio di confine dell'accesso dell'entità.
• updateTime: data e 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 limiti di accesso all'entità che definiscono le risorse a cui possono accedere le entità interessate. Ogni regola contiene i seguenti campi:

  • description: una descrizione leggibile della regola.

  • resources: un elenco di risorse Resource Manager (progetti, cartelle e organizzazioni) a cui vuoi che le entità siano idonee ad accedere. Qualsiasi l'entità soggetta a queste norme può accedere a questi Google Cloud.

    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 le regole di Principal Access Boundary sono "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 può bloccare.

  Per ulteriori informazioni sulle versioni dei criteri di Principal Access Boundary, consulta Versioni dell'applicazione forzata di Principal Access Boundary in questa pagina.

Struttura di un'associazione criterio

Un'associazione di criteri per un criterio di Principal Access Boundary contiene il nome di un criterio, il nome del set di entità a cui associare il criterio e i metadati che descrivono dell'associazione di criteri. Può anche contenere condizioni che modificano le entità esatte a cui si applicano le norme.

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à [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 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 di criteri.
• etag: un identificatore per lo stato corrente del criterio. Questo valore cambia quando aggiorni il criterio. Per evitare aggiornamenti in conflitto, il valore etag deve che corrisponda al valore archiviato 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 queste annotazioni per aggiungere metadati aggiuntivi alla definizione delle norme, ad esempio chi ha creato la definizione delle norme o se è stata implementata da una pipeline automatica. 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 principali a cui vuoi 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 le associazioni dei criteri per i criteri di Principal Access Boundary, questo valore è sempre PRINCIPAL_ACCESS_BOUNDARY.

• policy: il criterio di confine dell'accesso dell'entità da associare all'insieme 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à IAM applica il criterio. Se la condizione è vera o non può essere valutata, Identity and Access Management applica il criterio per l'entità che effettua la richiesta. Se la condizione è falsa, 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 dei criteri.

• updateTime: data e ora dell'ultimo aggiornamento dell'associazione di 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.

Limitare le entità alle risorse della 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 assicurare che tutte le entità del l'organizzazione example.com può accedere alle risorse solo all'interno di example.com. Le entità che si trovano in example.com includono tutte le identità nel dominio example.com, in tutti i pool di identità della forza lavoro example.com e tutti gli account di servizio e i pool di identità per i carichi di lavoro in in qualsiasi progetto in example.com.

Non esistono criteri di Principal Access Boundary che si applicano a nessuno dei della tua organizzazione. Di conseguenza, tutte le entità sono idonee a per accedere a tutte le risorse.

Per rendere le entità non idonee ad accedere alle risorse al di fuori di example.com, devi crea un criterio di Principal Access Boundary che renda le entità idonee ad accedere 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, tutti i principali in example.com sono solo idonei ad accedere alle risorse in example.com. Non possono utilizzare le autorizzazioni bloccate dal criterio di confine di accesso principale per accedere alle risorse esterne aexample.com, anche se dispongono di queste autorizzazioni per le risorse in questione.

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. Vuoi assicurarti che gli account di servizio in example-dev siano idonei ad accedere solo alle risorse in example-dev.

Se disponi di un criterio di Principal Access Boundary che rende tutte le entità nel tuo dell'organizzazione, inclusi gli account di servizio del dominio example-dev, idonea accedere alle risorse in example.com. Per avere un'idea di questo tipo di criterio, consulta Limitare le entità alle risorse della tua organizzazione.

Per rendere gli account di servizio in example-dev non idonei ad accedere alle risorse al di fuori di example-dev, devi prima creare un criterio 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, 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, queste norme da sole non limitano l'idoneità degli account di servizio. Questo perché esiste già un criterio di Principal Access Boundary rende tutte le entità in example.com idonee per 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 sono idonei ad accedere solo alle risorse in 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.

Passaggi successivi

• Scopri come creare e applicare i criteri di Principal Access Boundary.
• Esamina l'autorizzazione bloccata da ogni versione dell'applicazione dei criteri di limite di accesso all'entità.