Policy di negazione

I criteri di rifiuto di Identity and Access Management (IAM) ti consentono di impostare sistemi di protezione per gli accessi alle risorse Google Cloud. Con i criteri di negazione, puoi definire regole di negazione che impediscono a determinate entità di utilizzare determinate autorizzazioni, indipendentemente dai ruoli loro concessi.

Questa pagina fornisce una panoramica dei criteri di rifiuto e delle regole di rifiuto. Per scoprire come creare e aggiornare i criteri di rifiuto, consulta Negare l'accesso alle risorse.

Come funzionano le norme di rifiuto

I criteri di negazione sono composti da regole di negazione. Ogni regola di negazione specifica quanto segue:

• Un insieme di entità a cui sono negate le autorizzazioni
• Le autorizzazioni negate alle entità o che le entità non possono utilizzare
• (Facoltativo) La condizione che deve essere vera affinché l'autorizzazione venga negata

Quando a un'entità viene negata un'autorizzazione, l'entità non può fare nulla per cui sia richiesta quell'autorizzazione, indipendentemente dai ruoli IAM assegnati. Questo perché IAM verifica sempre i criteri di rifiuto pertinenti prima di controllare quelli di autorizzazione pertinenti. Per informazioni dettagliate, consulta la sezione valutazione delle norme.

Per specificare dove vuoi applicare un criterio di rifiuto, devi collegarlo a un progetto, una cartella o un'organizzazione. Quando un criterio di rifiuto è associato a una di queste risorse, le entità nel criterio non possono utilizzare le autorizzazioni specificate per accedere alla risorsa o a uno dei suoi discendenti. Per approfondire dove puoi allegare un criterio di rifiuto, consulta la sezione Punto di allegato in questa pagina.

Puoi associare più criteri di rifiuto a una singola risorsa. In questo modo puoi creare criteri di rifiuto separati per diversi tipi di regole di rifiuto. Ad esempio, puoi inserire regole di rifiuto relative alla conformità in un criterio, quindi utilizzare un altro criterio per altre regole di rifiuto. Ogni criterio di rifiuto viene valutato indipendentemente da tutti gli altri criteri di rifiuto.

Ogni risorsa può avere fino a 500 criteri di rifiuto. Insieme, questi criteri di rifiuto possono contenere un totale di 500 regole di rifiuto.

Punto di attacco

Ogni criterio di rifiuto è associato a un'organizzazione, a una cartella o a un progetto. Quando sono collegati a una di queste risorse, i criteri di rifiuto vengono ereditati da tutte le risorse di livello inferiore nel progetto, nella cartella o nell'organizzazione. Per utilizzare le norme di rifiuto, devi avere un identificatore per la risorsa a cui è associata la norma di rifiuto, chiamato punto di attacco. Questo identificatore utilizza uno dei formati indicati nella tabella seguente:

Ereditarietà dei criteri di negazione

I criteri di negazione, come i criteri di autorizzazione, vengono ereditati tramite la gerarchia delle risorse. Quando colleghi un criterio di rifiuto a un progetto, una cartella o un'organizzazione, il criterio è efficace anche per tutte le risorse al suo interno.

Ad esempio, se un criterio di rifiuto per un'organizzazione indica che un'entità non può utilizzare un'autorizzazione specifica, l'entità non potrà utilizzare l'autorizzazione per nessuna risorsa all'interno dell'organizzazione. Questa regola si applica anche se le cartelle e i progetti all'interno dell'organizzazione hanno criteri di rifiuto più permissivi.

Analogamente, se un criterio di rifiuto per un progetto indica che un'entità non può utilizzare un'autorizzazione specifica, l'entità non potrà utilizzare l'autorizzazione per nessuna risorsa all'interno del progetto. Questa regola si applica anche se l'organizzazione e le cartelle principali hanno criteri di rifiuto più permissivi.

Condizioni di rifiuto

Le condizioni di rifiuto specificano le condizioni che devono essere soddisfatte affinché venga applicata una regola di rifiuto. Se la condizione ha valore true o non può essere valutata, viene applicata la regola di rifiuto e i principali non possono utilizzare le autorizzazioni specificate. Se la condizione ha valore false, la regola di negazione non viene applicata e le entità possono utilizzare le autorizzazioni specificate, se le hanno.

Le condizioni di rifiuto hanno la stessa struttura delle condizioni IAM. Tuttavia, le condizioni di rifiuto riconoscono solo le funzioni dei tag risorsa.

Per scoprire come scrivere le condizioni, consulta la panoramica delle condizioni IAM.

Gruppi di autorizzazioni

Alcuni servizi ti consentono di negare i gruppi di autorizzazioni. I gruppi di autorizzazioni sono insiemi di autorizzazioni che corrispondono a un pattern specificato. Puoi utilizzare un gruppo di autorizzazioni per negare insiemi di autorizzazioni correlate, ad esempio puoi negare tutte le autorizzazioni per un singolo servizio o una singola risorsa.

I gruppi di autorizzazioni supportati sono elencati in Autorizzazioni supportate nei criteri di rifiuto. Gli identificatori dei gruppi di autorizzazioni supportati sostituiscono una o più sezioni del nome di un'autorizzazione con un carattere jolly (*). Le autorizzazioni incluse in ogni gruppo dipendono dalla posizione del carattere jolly:

• SERVICE_FQDN/RESOURCE.*: nega tutte le autorizzazioni per la risorsa specificata.
• SERVICE_FQDN/*.*: nega tutte le autorizzazioni per il servizio specificato.
• SERVICE_FQDN/*.VERB: nega tutte le autorizzazioni per un servizio che terminano con il verbo specificato.

I gruppi di autorizzazioni includono tutte le autorizzazioni attuali e future che corrispondono al pattern specificato. Ad esempio, immagina di utilizzare il gruppo di autorizzazioni example.googleapis.com/exampleResource.* per negare a un utente tutte le autorizzazioni per il tipo di risorsa exampleResource. Se example.googleapis.com aggiunge una nuova autorizzazione per il tipo di risorsa exampleResource, ad esempio example.googleapis.com/exampleResource.newPermission, all'utente verrà automaticamente negata la nuova autorizzazione.

Puoi utilizzare i caratteri jolly solo nei gruppi di autorizzazioni supportati. L'utilizzo di caratteri jolly in altri nomi di autorizzazione non è supportato.

Struttura di un criterio di negazione

Un criterio di rifiuto è una raccolta di metadati e regole di rifiuto. Una regola di negazione associa un insieme di entità a un insieme di autorizzazioni che non possono essere utilizzate o che sono negate alle entità. Ogni regola può anche specificare una condizione che determina quando l'autorizzazione viene negata.

Ad esempio, il seguente criterio di rifiuto impedisce a tutti i principali di eliminare i progetti, a meno che il principale non sia un membro del gruppo project-admins o il progetto da eliminare non abbia un tag con il valore test.

{
  "name": "policies/cloudresourcemanager.googleapis.com%2Fprojects%2F253519172624/denypolicies/limit-project-deletion",
  "uid": "06ccd2eb-d2a5-5dd1-a746-eaf4c6g3f816",
  "kind": "DenyPolicy",
  "displayName": "Only project admins can delete projects.",
  "etag": "MTc1MTkzMjY0MjUyMTExODMxMDQ=",
  "createTime": "2021-09-07T23:15:35.258319Z",
  "updateTime": "2021-09-07T23:15:35.258319Z",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": [
          "principalSet://goog/public:all"
        ],
        "exceptionPrincipals": [
          "principalSet://goog/group/project-admins@example.com"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete",
          "cloudresourcemanager.googleapis.com/folders.*"
        ],
        "exceptionPermissions": [
          "cloudresourcemanager.googleapis.com/folders.list",
          "cloudresourcemanager.googelapis.com/folders.get"
        ],
        "denialCondition": {
          "title":  "Only for non-test projects",
          "expression": "!resource.matchTag('12345678/env', 'test')"
        }
      }
    }
  ]
}

Le sezioni seguenti descrivono i campi dei metadati e delle regole di rifiuto di un criterio di rifiuto.

Metadati

I criteri di rifiuto contengono i seguenti metadati:

• name: il nome del criterio di rifiuto. Questo nome ha il formato policies/ATTACHMENT_POINT/denypolicies/POLICY_ID, dove ATTACHMENT_POINT è il progetto, la cartella o l'organizzazione a cui è associato il criterio di rifiuto e POLICY_ID è l'ID alfanumerico del criterio di rifiuto.
• uid: un ID univoco assegnato al criterio di rifiuto da Google.
• kind: il tipo di norma. Il valore kind per un criterio di rifiuto è sempre DenyPolicy.
• displayName: facoltativo. Un nome leggibile per il criterio di rifiuto.
• etag: un identificatore per una versione del criterio. Per evitare aggiornamenti in conflitto, il valore etag deve corrispondere a quello memorizzato in IAM. Se i valori etag non corrispondono, la richiesta non va a buon fine.
• createTime: l'ora in cui è stata creata la policy di negazione.
• updateTime: l'ultima volta che è stata aggiornata la norma di rifiuto.

Regole di negazione

Ogni regola di rifiuto può avere i seguenti campi:

• deniedPrincipals: le entità a cui sono negate le autorizzazioni. Puoi elencare singoli principali e insiemi di principali. I tipi di entità individuali includono account utente, account di servizio e singole identità in un pool di identità per la forza lavoro o per i carichi di lavoro. Gli insiemi di principali includono gruppi Google, domini Cloud Identity, insiemi di identità per la forza lavoro o per i carichi di lavoro e tutti gli utenti su internet.

  Per un elenco di tipi ed identificatori di entità validi, consulta Identificatori delle entità dell'API IAM v2.

• exceptionPrincipals: facoltativo. Le entità esenti dalla regola di negazione. A queste entità non vengono negate le autorizzazioni specificate anche se sono elencate in deniedPrincipals o fanno parte di un gruppo elencato in deniedPrincipals.

  Puoi elencare singoli principali e insiemi di principali. I tipi di entità individuali includono account utente, account di servizio e singole identità in un pool di identità per la forza lavoro o per i carichi di lavoro. Gli insiemi di principali includono gruppi Google, domini Cloud Identity, insiemi di identità di forza lavoro o workload e tutti gli utenti su internet.

  Per un elenco di tipi ed identificatori di entità validi, consulta Identificatori delle entità dell'API IAM v2.

• deniedPermissions: le autorizzazioni che le entità specificate non possono utilizzare o che sono state negate. Queste autorizzazioni utilizzano il formato delle autorizzazioni v2 di IAM, che utilizza nomi di dominio completi (FQDN) per identificare il servizio. Il formato è SERVICE_FQDN/RESOURCE.ACTION. Le API Google utilizzano il dominio *.googleapis.com. Ad esempio, iam.googleapis.com/roles.delete.

  Solo alcune autorizzazioni possono essere negate. Per un elenco completo delle autorizzazioni che possono essere negate, vedi Autorizzazioni supportate nei criteri di rifiuto.

  In alcuni casi, puoi anche utilizzare i gruppi di autorizzazioni per negare insiemi di autorizzazioni. Per ulteriori informazioni, vedi Gruppi di autorizzazioni.

• exceptionPermissions: facoltativo. Un elenco di autorizzazioni che gli agenti specificati possono utilizzare, anche se sono incluse in deniedPermissions. Ad esempio, puoi utilizzare questo campo per fare eccezioni per autorizzazioni specifiche in un gruppo di autorizzazioni.

• denialConditions: facoltativo. Un'espressione logica che influisce sul momento in cui viene applicata la regola di rifiuto. Se la condizione restituisce true o non può essere valutata, la richiesta di autorizzazione viene rifiutata. Se la condizione restituisce false, la permissione non viene negata. Per ulteriori informazioni, vedi Condizioni di rifiuto in questa pagina.

Casi d'uso comuni

Di seguito sono riportate situazioni comuni in cui potresti voler utilizzare i criteri di rifiuto e esempi di regole di rifiuto che potresti creare in ogni situazione. Per scoprire come creare e aggiornare i criteri di rifiuto, consulta Negare l'accesso alle risorse.

Centralizzazione dei privilegi amministrativi

Puoi utilizzare i criteri di rifiuto per limitare determinati tipi di attività amministrative a un insieme specifico di entità.

Ad esempio, immagina di voler limitare la gestione dei ruoli personalizzati per la tua organizzazione a un unico team centrale. Per farlo, crea una regola di rifiuto che nega le autorizzazioni richieste per la gestione dei ruoli personalizzati a tutti gli utenti, tranne agli utenti del gruppo amministrativo (custom-role-admins):

{
  "deniedPrincipals": [
    "principalSet://goog/public:all"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/custom-role-admins@example.com"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/roles.create",
    "iam.googleapis.com/roles.delete",
    "iam.googleapis.com/roles.update",
  ]
}

Poi, allega la policy di negazione alla tua organizzazione.

Ora solo i membri del gruppo custom-role-admins possono gestire i ruoli personalizzati, anche se altri utenti dispongono delle autorizzazioni richieste.

Ad esempio, immagina che sia Yuri che Tal abbiano il ruolo Amministratore dei ruoli dell'organizzazione (roles/iam.organizationRoleAdmin). Tuttavia, Yuri è un membro di custom-role-admins, mentre Tal no. Con questo criterio di rifiuto, solo Yuri è in grado di creare, eliminare e aggiornare i ruoli.

Creazione di eccezioni alle concessioni di accesso

Puoi utilizzare i criteri di rifiuto per negare le autorizzazioni ereditate. Questa funzionalità ti consente di concedere un ruolo a un livello elevato nella gerarchia delle risorse e di negare le autorizzazioni del ruolo alle singole risorse di livello inferiore, se necessario.

Ad esempio, immagina di avere una cartella, Engineering, che contiene diversi progetti. Vuoi assegnare a un gruppo, eng, le autorizzazioni nel ruolo Amministratore chiavi account di servizio (roles/iam.serviceAccountKeyAdmin) su quasi tutti i progetti nella cartella. Tuttavia, non vuoi che il gruppo possa creare ed eliminare chiavi dell'account di servizio in un progetto specifico della cartella example-prod.

Anziché concedere il ruolo Amministratore chiavi account di servizio a ogni singolo progetto, crea la seguente regola di rifiuto, che nega le autorizzazioni di creazione ed eliminazione nel ruolo Amministratore chiavi account di servizio ai principali nel gruppo eng:

{
  "deniedPrincipals": [
    "principalSet://goog/group/eng@example.com"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

Aggiungi questa regola di rifiuto a un criterio di rifiuto e allega il criterio al progetto example-prod.

Dopo aver allegato il criterio di rifiuto al progetto, puoi concedere il ruolo Amministratore chiavi account di servizio al gruppo eng nella cartella Engineering senza consentire al gruppo di creare o eliminare chiavi dell'account di servizio in example-prod.

I membri del gruppo eng possono quindi creare ed eliminare le chiavi degli account di servizio in tutti i progetti, ad eccezione di example-prod. Ad esempio, se Izumi fa parte del gruppo eng, può creare ed eliminare chiavi per gli account di servizio in example-dev e example-test, ma non in example-prod.

Tuttavia, immagina di volere che un sottoinsieme del gruppo eng possa creare ed eliminare le chiavi account di servizio in example-prod. Questo sottoinsieme è rappresentato dal gruppo eng-prod. Per consentire ai membri del gruppo eng-prod di creare ed eliminare chiavi account di servizio in example-prod, puoi esentare il gruppo dalla regola di rifiuto:

{
  "deniedPrincipals": [
    "principalSet://goog/group/eng@example.com"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/eng-prod@example.com"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

Con questo criterio di rifiuto rivisto, i membri del gruppo eng-prod possono creare ed eliminare le chiavi degli account di servizio in tutti i progetti, incluso example-prod. Ad esempio, se Charlie è un membro del gruppo eng-prod, può creare ed eliminare chiavi in example-dev, example-test e example-prod, anche se è anche un membro del gruppo eng.

Bloccare l'accesso in base ai tag

Un tag è una coppia chiave-valore che può essere collegata a un'organizzazione, una cartella o un progetto. Puoi utilizzare i criteri di negazione per negare le autorizzazioni in base ai tag senza dover aggiungere una condizione IAM a ogni concessione del ruolo.

Ad esempio, immagina di taggare tutti i tuoi progetti come dev, test o prod. Vuoi che solo i membri del gruppo project-admins possano eliminare i progetti con tag prod.

Per risolvere il problema, crea una regola di rifiuto che nega l'autorizzazione cloudresourcemanager.googleapis.com/projects.delete a tutti, tranne al gruppo project-admins, per le risorse con il tag prod:

{
  "displayName": "Only project admins can delete production projects.",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": [
          "principalSet://goog/public:all"
        ],
        "exceptionPrincipals": [
          "principalSet://goog/group/project-admins@example.com"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete"
        ],
        "denialCondition": {
          "title":  "Only for prod projects",
          "expression": "resource.matchTag('12345678/env', 'prod')"
        }
      }
    }
  ]
}

Poi, aggiungi questa regola di rifiuto a una policy di rifiuto e allegala alla tua organizzazione.

Grazie a questa regola di rifiuto, puoi limitare l'accesso dei principali senza aggiungere una condizione alle concessioni dei ruoli. In alternativa, puoi assegnare ai principali i ruoli che contengono l'autorizzazione cloudresourcemanager.googleapis.com/projects.delete e fare affidamento sulla regola di negazione per impedire ai principali esterni al gruppo project-admins di eliminare i progetti taggati prod.

Ad esempio, prendi in considerazione due utenti, Bola e Kiran. Entrambi gli utenti hanno il ruolo Eliminatore progetto (roles/resourcemanager.projectDeleter). Inoltre, Kiran è un membro del gruppo project-admins. Con questo criterio di rifiuto, Bola può solo eliminare i progetti con il tag dev o test. Kiran può eliminare tutti i progetti, indipendentemente dai relativi tag.

Passaggi successivi

• Scopri come creare, aggiornare ed eliminare i criteri di rifiuto.
• Scopri come risolvere i problemi di accesso con i criteri di negazione.
• Controlla le autorizzazioni che possono essere negate.
• Consulta i tipi di entità che puoi includere nei criteri di rifiuto.