Policy di Principal Access Boundary

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

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

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

Come funzionano i criteri di Principal Access Boundary

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

Con i criteri di Principal Access Boundary, puoi limitare le risorse a cui un'entità può accedere. Se un criterio di confine dell'accesso dell'entità rende un'entità non idonea ad accedere a una risorsa, l'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 (Identity and Access Management). Per scoprire di più sulle autorizzazioni bloccate, consulta Autorizzazioni che possono essere bloccate da Principal Access Boundary.

I criteri di confine dell'accesso dell'entità sono costituiti da regole di confine dell'accesso dell'entità. Ogni regola di limite di accesso all'entità definisce un insieme di risorse a cui le entità interessate sono idonee ad accedere. Puoi creare fino a 1000 criteri di confine di accesso principale nella tua organizzazione.

Dopo aver creato un criterio di confine dell'accesso dell'entità, devi creare un'associazione di criteri per applicarlo a un insieme di entità.

Un entità principale può essere soggetta a una o più policy di Principal Access Boundary. Ogni entità è idonea ad accedere solo alle risorse elencate in questi criteri. Per tutte le altre risorse, l'accesso dell'entità a quella risorsa è limitato, anche se concedi ruoli all'entità in quella risorsa.

Poiché i criteri di confine di accesso delle entità sono associati alle entità e non alle risorse, puoi utilizzarli per impedire alle entità di accedere alle risorse che non possiedi. Ad esempio, considera il seguente scenario:

• Il preside Tal (tal@altostrat.com) fa parte dell'organizzazione Google Workspace altostrat.com.
• A Tal viene concesso il ruolo Amministratore Storage (roles/storage.admin) per 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.
• In cymbalgroup.com non sono presenti criteri di rifiuto 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. Nessun amministratore altostrat.com ha l'autorizzazione per modificare il criterio di autorizzazione del bucket, pertanto non può revocare il ruolo di Tal. 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 di accesso delle 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 gli entità dell'organizzazionealtostrat.com. Con questo criterio, Tal non potrà visualizzare gli oggetti nel bucket cymbalgroup.com, anche se gli è stato assegnato il ruolo Amministratore archiviazione per il bucket.

Valutazione fail-open

Durante la release di anteprima dei criteri di Principal Access Boundary, i criteri di Principal Access Boundary non generano errori. Ciò significa che, se IAM non riesce a valutare un criterio di confine di accesso principale, 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 confine di accesso delle entità non blocca un'autorizzazione, i criteri di confine di accesso delle entità non influiscono sulla possibilità per le entità di utilizzare l'autorizzazione.

Ad esempio, immagina che a un'entità, Lee (lee@example.com), venga assegnato il ruolo sviluppatore di Dataflow (roles/dataflow.developer). Questo ruolo include l'autorizzazione dataflow.jobs.snapshot, che consente a Lee di acquisire istantanee dei job di 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 al di fuori di 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 una versione di applicazione, IAM utilizza la versione più recente e continuerà a utilizzarla 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 i criteri di confine di accesso principali per utilizzare la nuova versione. Se vuoi che la versione di applicazione delle norme venga aggiornata automaticamente con il rilascio di nuove versioni, puoi utilizzare il valore latest quando crei il 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.

Associare i criteri di confine dell'accesso dell'entità ai set 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à. A ogni set di entità può essere associato un massimo di 10 criteri di limite di accesso all'entità.

Per scoprire come gestire i criteri di confine dell'accesso dell'entità, consulta Creare e applicare i criteri di confine dell'accesso dell'entità.

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 di criteri per quel tipo di set di entità

Associazioni di criteri condizionali per i criteri di confine dell'accesso dell'entità

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

Le espressioni di condizione per le associazioni di norme 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 norme e, in ultima analisi, determina se la norma si applica.

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

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

  Ad esempio, se aggiungi la seguente espressione di condizione a un'associazione per un criterio di confine di accesso principale, 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 cruz@example.com. Puoi utilizzare le condizioni con questo attributo per controllare esattamente quali entità sono soggette a un criterio di confine di accesso delle entità.

  Ad esempio, se aggiungi la seguente espressione di condizione a un'associazione per un criterio di confine di accesso principale, il criterio non verrà applicato all'utente special-admin@example.com:

  principal.subject != 'special-admin@example.com'
  

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

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

Uno dei modi in cui puoi utilizzare le condizioni nelle associazioni dei criteri di confine di accesso delle entità è ridurre le risorse a cui un singolo utente può accedere.

Immagina di avere un account di servizio, dev-project-service-account, con l'indirizzo email dev-project-service-account@dev-project.iam.gserviceaccount.com. Questo account di servizio è soggetto a un criterio di confine di accesso delle 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 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 vuoi modificare le risorse a cui possono accedere gli altri entità nel set di entità example.com.

Per apportare questa modifica, segui la procedura per ridurre le risorse a cui gli agenti possono accedere, 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'insieme di entità per dev-project. Utilizza la seguente condizione nell'associazione dei criteri per assicurarti che il criterio sia applicato solo per dev-project-service-account:

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

3. Esenti da dev-project-service-account dal criterio di 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 del criterio che collega il criterio di confine dell'accesso dell'entità all'insieme di entità dell'organizzazione:

   "condition": {
     "title": "Exempt dev-project-service-account",
     "expression": "principal.subject != 'dev-project-service-account@dev-project.iam.gserviceaccount.com' || principal.type != 'iam.googleapis.com/ServiceAccount'"
   }
   

   Per scoprire come aggiornare i criteri di Principal Access Boundary esistenti, consulta Modificare i criteri di Principal Access Boundary.

Dopo aver aggiunto questa condizione all'associazione del criterio, 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 le norme

IAM valuta ogni criterio di limite di accesso all'entità in combinazione con i criteri di autorizzazione e di negazione e con gli altri criteri di limite di accesso all'entità. Tutti questi criteri vengono utilizzati 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 tutti i criteri di confine di accesso delle entità, di autorizzazione e di negazione pertinenti per verificare se l'entità è autorizzata ad accedere alla risorsa. Se uno di questi criteri indica che l'entità non deve essere in grado di accedere alla risorsa, IAM impedisce l'accesso.

Di conseguenza, se un criterio di 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 da soli non concedono agli entità di accedere alle risorse. Sebbene i criteri di Principal Access Boundary possano rendere un'entità idonea ad accedere a una risorsa, solo i criteri di autorizzazione possono effettivamente concedere all'entità accesso alla risorsa.

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

Interazione tra i criteri di Principal Access Boundary

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

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

Crea 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, quindi associalo al set di entità dell'organizzazione.

In base a questi criteri di confine dell'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 i criteri di confine delle entità a cui è soggetta.

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

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

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

Ereditarietà delle norme

I criteri di confine dell'accesso dell'entità sono associati agli insiemi di entità, non alle 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 principali di Resource Manager, ovvero le cartelle e le organizzazioni, includono sempre tutti gli enti negli insiemi di entità dei loro discendenti. Ad esempio, se un'entità è inclusa nel set di entità di un progetto, è inclusa anche nei set di entità di eventuali organizzazioni o cartelle principali.

Ad esempio, prendiamo 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, che sono elementi secondari di folder-a

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

Di conseguenza, le seguenti entità sono interessate dalle seguenti policy 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 fa parte degli insiemi di entità per project-1 e example.com e sarà interessato dai criteri di confine dell'accesso dell'entità associati a uno di questi insiemi di entità.

• Un account di servizio in project-3 fa parte degli insiemi di entità per project-3, folder-a e example.com e sarà interessato dai criteri di confine dell'accesso dell'entità associati a uno di questi insiemi di entità.

Criteri di confine dell'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 pubblicamente leggibili.

L'eventuale impedimento da parte del limite di accesso dell'entità alla visualizzazione di una risorsa visibile pubblicamente da parte di entità non idonee dipende dal fatto che la risorsa sia memorizzata 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 all'entità impedisce alle persone giuridiche non idonee di visualizzarla

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

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

Un criterio di confine dell'accesso dell'entità è una raccolta di metadati e dettagli dei criteri di confine dell'accesso dell'entità. I metadati forniscono informazioni come il nome del criterio e la data di creazione. I dettagli del criterio ne definiscono la funzionalità, ad esempio le risorse a cui possono accedere le entità interessate.

Ad esempio, il seguente criterio di confine di accesso delle entità rende le entità soggetti al criterio idonee ad accedere alle risorse dell'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 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 confine dell'accesso dell'entità.
• 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, consulta Annotazioni.
• createTime: la data e l'ora in cui è stato creato il criterio di confine dell'accesso dell'entità.
• updateTime: l'ora dell'ultimo aggiornamento del criterio di Principal Access Boundary.

Dettagli

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

• rules: un elenco di regole di 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 di Resource Manager (progetti, cartelle e organizzazioni) a cui vuoi che gli entità possano accedere. Qualsiasi entità soggetto a queste norme è idonea ad accedere a queste risorse.

    Ogni criterio di limite di accesso all'entità può fare riferimento a un massimo di 500 risorse in tutte le regole della stessa.

  • effect: la relazione che i principali hanno con le risorse elencate nel campo resources. L'unico effetto che puoi specificare nelle regole di confine di accesso principale è "ALLOW". Questa relazione rende le entità idonee ad accedere alle risorse elencate nella regola.

• enforcementVersion: la versione di applicazione utilizzata da IAM quando applica il criterio. La versione del criterio di Principal Access Boundary determina le autorizzazioni che il criterio può bloccare.

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

Struttura di un'associazione di criteri

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

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

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

Ogni associazione di norme contiene i seguenti campi:

• name: il nome dell'associazione del criterio. Questo nome ha il formato RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID, dove RESOURCE_TYPE/RESOURCE_ID è il tipo e l'ID della risorsa principale della definizione del criterio e BINDING_ID è l'ID alfanumerico della definizione del criterio.
• uid: un ID univoco assegnato all'associazione del criterio.
• etag: un identificatore 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 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 target può avere fino a 10 criteri associati.

• policyKind: il tipo di criterio a cui fa riferimento l'associazione dei criteri. Per le associazioni delle policy per le policy 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 limite di accesso all'entità a cui si fa riferimento nel campo policy.

• condition: facoltativo. Un'espressione logica che influisce sugli entità per le quali 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, consulta Principal Access Boundary e condizioni in questa pagina.

• createTime: l'ora in cui è stata creata l'associazione del criterio.

• updateTime: l'ora dell'ultimo aggiornamento dell'associazione dei criteri.

Casi d'uso

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

Limitare le entità alle risorse della tua organizzazione

Puoi utilizzare i criteri di confine di accesso delle entità per assicurarti che le entità della tua organizzazione siano idonee ad accedere solo alle risorse all'interno della tua organizzazione.

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

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

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

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

Poi, crea un'associazione di criteri per associare questo criterio 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 a example.com, anche se dispongono di queste autorizzazioni per le risorse in questione.

Limitare gli account di servizio alle risorse di 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.

Hai un criterio di confine di accesso delle entità che rende idonee tutte le entità della tua organizzazione, inclusi gli account di servizio in example-dev, ad accedere alle risorse in example.com. Per avere un'idea di questo tipo di criteri, 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 un criterio di confine di accesso delle entità che rende tutte le entità in example.com idonee ad accedere a tutte le risorse in example.com. I criteri di confine di accesso dei principali sono additivi, pertanto gli account di servizio in example-dev sono ancora idonei ad accedere a tutte le risorse in example.com.

Per assicurarti che gli account di servizio in example-dev siano solo idonei ad accedere alle risorse in example-dev, devi aggiungere una condizione all'associazione del criterio per il criterio di confine di accesso principale esistente che ne impedisca 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 confine dell'accesso dell'entità.
• Esamina l'autorizzazione bloccata da ogni versione dell'applicazione delle norme di Principal Access Boundary.