Criteri di negazione

I criteri di negazione di Identity and Access Management (IAM) consentono di impostare sistemi di protezione per l'accesso a dell'accesso a specifiche 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 negazione e delle regole di negazione. Per scoprire come creare e aggiornare i criteri di rifiuto, consulta Negare l'accesso alle risorse.

Come funzionano i criteri 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 che richieda di quell'autorizzazione, indipendentemente dai ruoli IAM assegnati concesso. Questo perché IAM verifica sempre i criteri di rifiuto pertinenti prima di controllare quelli di autorizzazione pertinenti. Per maggiori dettagli, consulta le norme di valutazione.

Per specificare dove vuoi applicare un criterio di rifiuto, devi collegarlo a un progetto, una cartella o un'organizzazione. Quando un criterio di negazione viene collegato a uno di questi di risorse, le entità del criterio non possono usare le autorizzazioni specificate accedere alla risorsa o ai relativi discendenti. A scopri di più su dove puoi collegare un criterio di negazione, consulta Allegato su questa pagina.

Puoi collegare più criteri di negazione 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 negazione relative alla conformità in un criterio, per altre regole di negazione. Ogni criterio di negazione viene valutato indipendentemente e altri criteri di negazione.

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

Punto di collegamento

Ogni criterio di rifiuto è associato a un'organizzazione, a una cartella o a un progetto. Quando collegati a una di queste risorse, i criteri di negazione vengono ereditati risorse di livello inferiore nel progetto, nella cartella o nell'organizzazione. Per lavorare con per i criteri di negazione, è necessario un identificatore per la risorsa corrispondente denominato punto di collegamento. Questo identificatore utilizza uno dei seguenti attributi i formati disponibili nella tabella seguente:

Formato del punto di attacco
Organizzazione

cloudresourcemanager.googleapis.com/organizations/ORG_ID
Sostituisci ORG_ID con l'organizzazione numerica ID. Per l'API REST, esegui la codifica URL dell'intero valore.

Esempio per gcloud CLI:
cloudresourcemanager.googleapis.com/organizations/123456789012

Esempio per l'API REST:
cloudresourcemanager.googleapis.com%2Forganizations%2F123456789012

Cartella

cloudresourcemanager.googleapis.com/folders/FOLDER_ID
Sostituisci FOLDER_ID con l'ID numerico della cartella. Per l'API REST, esegui la codifica URL dell'intero valore.

Esempio per gcloud CLI:
cloudresourcemanager.googleapis.com/folders/987654321098

Esempio per l'API REST:
cloudresourcemanager.googleapis.com%2Ffolders%2F987654321098

Progetto

cloudresourcemanager.googleapis.com/projects/PROJECT_ID
Sostituisci PROJECT_ID con il carattere alfanumerico o con un ID progetto numerico. Per l'API REST, esegui la codifica URL dell'intero valore.

Esempio per l'interfaccia a riga di comando gcloud:
cloudresourcemanager.googleapis.com/projects/my-project

Esempio per l'API REST:
cloudresourcemanager.googleapis.com%2Fprojects%2Fmy-project

Nega l'ereditarietà dei criteri

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

Ad esempio, se un criterio di negazione per un'organizzazione indica che un'entità non può usano un'autorizzazione specifica, l'entità non può utilizzarla qualsiasi 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 principale e le cartelle hanno criteri di negazione 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 restituisce true o non può essere valutata, la regola di negazione si applica e le entità non sono in grado di utilizzare autorizzazioni aggiuntive. 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 il 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. Identificatori dell'autorizzazione supportata i gruppi 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 del 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 ai 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, come example.googleapis.com/exampleResource.newPermission, l'utente eseguirà automaticamente la nuova autorizzazione.

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

Struttura di un criterio di rifiuto

Un criterio di negazione è una raccolta di metadati e di regole di negazione. Una regola di negazione associa un insieme di entità a un insieme di autorizzazioni negato o non è in grado di utilizzarlo. 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 di project-admins@example.com 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 seguenti sezioni descrivono i campi nei metadati di un criterio di negazione e Nega le regole del caso.

Metadati

I criteri di negazione 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 a cui è associato il criterio di negazione, POLICY_ID è l'ID alfanumerico del criterio di negazione.
  • uid: un ID univoco assegnato al criterio di rifiuto da Google.
  • kind: il tipo di criterio. 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 delle norme. Per evitare conflitti vengono aggiornati, il valore etag deve corrispondere al valore memorizzato o IAM. Se i valori etag non corrispondono, la richiesta non va a buon fine.
  • createTime: l'ora in cui è stato creato il criterio di negazione.
  • updateTime: l'ultima volta che il criterio di negazione è stato aggiornato.

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 di entità e identificatori validi, consulta Identificatori delle entità 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. Individuale i tipi di entità includono account utente, account di servizio e 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 di entità e identificatori validi, consulta Identificatori delle entità API IAM v2.

  • deniedPermissions: le autorizzazioni che le entità specificate non sono in grado che vuoi usare o negare. Queste autorizzazioni utilizzano l'istruzione IAM v2 che utilizza nomi di dominio completi per identificare il servizio. Il formato è SERVICE_FQDN/RESOURCE.ACTION. Le API di 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 . Se la condizione restituisce true o non può essere valutata, l'autorizzazione viene negata. 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 alcune situazioni comuni in cui potresti voler usare criteri di negazione, ed esempi di regole di negazione che potresti creare in ciascuna situazione. Per ulteriori informazioni Per creare e aggiornare i criteri di negazione, vedi Negare l'accesso alle risorse.

Centralizzazione dei privilegi amministrativi

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

Ad esempio, immagina di voler limitare la gestione dei ruoli in un unico team centrale. Per farlo, devi creare una regola di negazione che nega le autorizzazioni necessarie per la gestione dei ruoli personalizzati a tutti gli utenti, ad eccezione di utenti del gruppo amministrativo (custom-role-admins@example.com):

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

Quindi, collegherai il criterio di negazione alla tua organizzazione.

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

Ad esempio, immagina che sia yuri@example.com sia tal@example.com abbiano il ruolo Amministratore dei ruoli dell'organizzazione (roles/iam.organizationRoleAdmin). Tuttavia, yuri@example.com è un membro di custom-role-admins@example.com, mentre tal@example.com no. Con questo criterio di negazione, solo yuri@example.com può creare, eliminare e aggiornare i ruoli.

Creazione di eccezioni per le concessioni di accesso

Puoi utilizzare i criteri di negazione 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 più progetti. Vuoi concedere a un gruppo, eng@example.com, le autorizzazioni nel ruolo Amministratore chiavi account di servizio (roles/iam.serviceAccountKeyAdmin) su per quasi tutti i progetti nella cartella. Tuttavia, non vuoi che il gruppo puoi creare ed eliminare le chiavi degli account di servizio in una specifica progetto nella cartella example-prod.

Anziché concedere il ruolo Amministratore chiavi account di servizio a ogni singolo utente progetto, crei la seguente regola di negazione, che nega la creazione e l'eliminazione nel ruolo Amministratore chiavi account di servizio alle entità in eng@example.com:

{
  "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 allegalo al progetto example-prod.

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

I membri di eng@example.com possono quindi creare ed eliminare l'account di servizio in tutti i progetti tranne example-prod. Ad esempio, se izumi@example.com è membro di eng@example.com, può creare ed eliminare le chiavi per il servizio in example-dev e example-test, ma non in example-prod.

Tuttavia, immagina di volere che un sottoinsieme di eng@example.com possa creare ed eliminare le chiavi degli account di servizio in example-prod. Questo sottoinsieme è rappresentato dal gruppo eng-prod@example.com. Consentire ai membri di eng-prod@example.com per creare ed eliminare le chiavi dell'account di servizio in example-prod, puoi rendere il gruppo esente dalla regola di negazione:

{
  "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 di eng-prod@example.com possono creare ed eliminare le chiavi degli account di servizio in tutti i progetti, incluso example-prod. Per Ad esempio, se charlie@example.com è membro di eng-prod@example.com, può creare ed eliminare chiavi in example-dev, example-test e example-prod, anche se è membro di eng@example.com.

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 usare i criteri di negazione per negare le autorizzazioni in base ai tag senza con l'aggiunta di una condizione IAM a ogni concessione di ruolo.

Ad esempio, immagina di taggare tutti i progetti come dev, test o prod. Vuoi che solo i membri di project-admins@example.com possano eliminare i progetti con il tag prod.

Per risolvere il problema, crea una regola di rifiuto che neghi l'autorizzazione cloudresourcemanager.googleapis.com/projects.delete a tutti, tranne a project-admins@example.com, per le risorse con 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')"
        }
      }
    }
  ]
}

Quindi, aggiungi questa regola di negazione a un criterio di negazione e colleghi il criterio al tuo dell'organizzazione.

Grazie a questa regola di negazione, puoi limitare le attività accedere senza aggiungere alla concessione del ruolo. Puoi invece concedere alle entità ruoli contengono l'autorizzazione cloudresourcemanager.googleapis.com/projects.delete, e si basano sulla regola di negazione per impedire alle entità al di fuori project-admins@example.com di eliminare i progetti con tag prod.

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

Passaggi successivi