Esempi di casi d'uso per le policy sul confine di accesso dell'entità

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

Impedire agli utenti di accedere alle risorse esterne all'organizzazione

Poiché le policy sul confine di accesso dell'entità sono associate alle entità e non alle risorse, puoi utilizzarle per impedire alle entità di accedere alle risorse di cui non sei proprietario. Ad esempio, considera il seguente scenario:

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

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

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

Gli amministratori di example.com non possono utilizzare le policy di autorizzazione e negazione per impedire a Tal di visualizzare gli oggetti in questo bucket esterno. Nessuna entità example.com ha l'autorizzazione per modificare la policy di autorizzazione del bucket, quindi non può revocare il ruolo di Tal. Inoltre, non hanno l'autorizzazione per creare policy di negazione in cymbalgroup.com, quindi non possono utilizzare una policy di negazione per impedire a Tal di accedere al bucket.

Tuttavia, con le policy sul confine di accesso dell'entità, gli amministratori di example.com possono impedire a Tal di visualizzare gli oggetti nel bucket cymbalgroup.com o in qualsiasi bucket esterno a example.com.

A questo scopo, gli amministratori possono creare una policy sul confine di accesso dell'entità che indica che le entità example.com possono accedere solo 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": "4"
  }
}

Poi, possono creare un'associazione di policy per collegare questa policy a tutte le entità dell'organizzazione example.com:

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

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 i service account e i pool di identità del workload in qualsiasi progetto in example.com.

Con questa policy, le entità in example.com non possono utilizzare le autorizzazioni bloccate dalla policy sul confine di accesso dell'entità per accedere alle risorse esterne a example.com, anche se dispongono di queste autorizzazioni per queste risorse.

In questo caso, la policy sul confine di accesso dell'entità utilizza la versione di applicazione 4, quindi è in grado di bloccare l'storage.objects.get autorizzazione. Di conseguenza, Tal non potrà visualizzare gli oggetti nel bucket cymbalgroup.com, anche se gli è stato concesso il ruolo Storage Admin sul bucket.

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

Puoi anche utilizzare le policy sul confine di accesso dell'entità per rendere idonei i sottoinsiemi di entità ad accedere ai sottoinsiemi di risorse nella tua organizzazione.

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

Per farlo, devi prima creare una nuova policy sul confine di accesso dell'entità che renda le entità idonee ad accedere alle risorse in dev-project:

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

Questa policy sul confine di accesso dell'entità utilizza la versione di applicazione 4, il che significa che è in grado di bloccare tutte le autorizzazioni supportate nella versione di applicazione 4.

Dopo aver creato la policy sul confine di accesso dell'entità, crea un'associazione di policy per associare la nuova policy a tutte le entità in example-dev, e aggiungi una condizione in modo che l'associazione di policy si applichi solo ai service account:

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

Se questa è l'unica policy sul confine di accesso dell'entità a cui sono soggetti i service account, questi non potranno utilizzare le autorizzazioni che la policy sul confine di accesso dell'entità può bloccare per accedere a qualsiasi risorsa esterna a example-dev.

Gestire l'idoneità per diversi gruppi di entità

Puoi utilizzare più policy sul confine di accesso dell'entità nella stessa organizzazione per rendere idonee diverse entità ad accedere a risorse diverse. Quando utilizzi più policy sul confine di accesso dell'entità, utilizza condizioni nelle associazioni di policy per assicurarti che ogni policy si applichi solo alle entità a cui vuoi che si applichi.

Ad esempio, supponiamo di voler rendere la maggior parte delle entità idonea ad accedere a tutte le risorse della tua organizzazione, come mostrato in Impedire agli utenti di accedere alle risorse esterne all'organizzazione. Tuttavia, vuoi anche assicurarti che i service account in example-dev siano idonei ad accedere solo alle risorse in example-dev, come mostrato in Rendere i service account idonei ad accedere alle risorse in un singolo progetto.

Per raggiungere questo obiettivo, procedi nel seguente modo:

  1. Seguendo l'esempio in Impedire agli utenti di accedere alle risorse esterne all' organizzazione, crea una policy sul confine di accesso dell'entità che renda le entità idonee ad accedere alle risorse in example.com e la associa all'insieme di entità dell'organizzazione.

  2. Seguendo l'esempio in Rendere i service account idonei ad accedere alle risorse in un singolo progetto, crea una policy sul confine di accesso dell'entità che renda i service account in example-dev idonei ad accedere alle risorse in example-dev e la associa ai service account in example-dev.

  3. Esenta i service account in example-dev dalla policy sul confine di accesso dell'entità che rende le entità idonee ad accedere a tutte le risorse in example.com. Per farlo, aggiungi la seguente condizione all'associazione di policy che collega la policy sul confine di accesso dell'entità all'insieme di entità dell'organizzazione:

    "condition": {
  "title": "Exempt example-dev service accounts",
  "description": "Don't enforce the policy for service accounts in the example-dev project",
  "expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || (!principal.subject.endsWith('@example-dev.iam.gserviceaccount.com') && principal.subject != 'example-dev@appspot.gserviceaccount.com' && principal.subject != '901234567890-compute@developer.gserviceaccount.com')"
}

Questo ultimo passaggio è fondamentale: se non esenti i service account example-dev dalla policy sul confine di accesso dell'entità iniziale, questa policy li renderà idonei ad accedere a tutte le risorse in example.com, indipendentemente dalle altre policy sul confine di accesso dell'entità a cui sono soggetti. Per saperne di più, consulta Definire le risorse idonee.

È anche importante creare e collegare una nuova policy sul confine di accesso dell'entità ai service account example-dev prima di esentarli dalla policy sul confine di accesso dell'entità iniziale. Questa procedura garantisce che i service account siano sempre soggetti ad almeno una policy sul confine di accesso dell'entità, il che impedisce loro di diventare idonei ad accedere a tutte le Google Cloud risorse. Per saperne di più su come ridurre in sicurezza le risorse a cui un'entità è idonea ad accedere, consulta Ridurre le risorse a cui le entità sono idonee ad accedere.

Passaggi successivi