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 Per creare e aggiornare i criteri di negazione, vedi Negare l'accesso alle risorse.

Come funzionano i criteri di negazione

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 per la autorizzazione da negare

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 negazione pertinenti prima di controllare i criteri di autorizzazione pertinenti. Per informazioni dettagliate, consulta la valutazione delle norme.

Per specificare dove vuoi applicare un criterio di negazione, collegalo a un progetto, cartella o organizzazione. Quando un criterio di negazione viene collegato a uno di questi 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 punto di accesso su questa pagina.

Puoi collegare più criteri di negazione a una singola risorsa. Questo consente di e creare criteri di negazione separati per i diversi tipi di regole di negazione. Ad esempio: puoi inserire regole di negazione relative alla conformità in un criterio, per altre regole di negazione. Ogni criterio di rifiuto viene valutato indipendentemente da tutti gli altri criteri di rifiuto.

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 attacco

Ogni criterio di negazione è collegato a un'organizzazione, una cartella o 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:

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 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 negazione 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 negazione specificano le condizioni che devono essere soddisfatte per un rifiuto la regola da applicare. 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 restituisce false, la regola di negazione non viene applicata e le entità possono usare le autorizzazioni specificate, se le dispongono.

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

Per informazioni su come scrivere le condizioni, consulta Panoramica di IAM Condizioni.

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 usare un gruppo di autorizzazioni per negare insiemi di autorizzazioni correlate, ad esempio puoi negare tutte autorizzazioni per un singolo servizio o risorsa.

I gruppi di autorizzazioni supportati sono elencati in Autorizzazioni supportate in negazione . 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 tutto autorizzazioni per la risorsa specificata specificata.
• SERVICE_FQDN/*.*: nega tutte le autorizzazioni per del servizio specificato.
• SERVICE_FQDN/*.VERB: nega tutte le autorizzazioni per un servizio che termina 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.

È possibile utilizzare caratteri jolly soltanto 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 negazione è una raccolta di metadati e di regole di negazione. Una regola di negazione associa un insieme di entità a un insieme di autorizzazioni negata o non possono essere utilizzate. 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"
        ],
        "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 a cui è associato il criterio di negazione, POLICY_ID è l'ID alfanumerico del criterio di negazione.
• uid: un ID univoco assegnato al criterio di negazione da Google.
• kind: il tipo di criterio. Il kind per un criterio di negazione è sempre DenyPolicy.
• displayName: facoltativo. Un nome leggibile per il criterio di negazione.
• 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: data e ora in cui è stato creato il criterio 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. Tipi di entità individuali che includono account utente, account di servizio e singole identità in una forza lavoro o un pool di identità 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 dell'entità API IAM v2.

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

  Puoi elencare singole entità e insiemi di entità. 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. Insiemi di entità includono gruppi Google, domini Cloud Identity, gruppi di forza lavoro le identità dei carichi di lavoro e tutti gli utenti di internet.

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

• deniedPermissions: le autorizzazioni che le entità specificate non sono in grado che vuoi usare o negare. Queste autorizzazioni usano il formato IAM v2, che utilizza nomi di dominio completi 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.

  È possibile negare solo alcune autorizzazioni. Per un elenco completo delle autorizzazioni che puoi negare l'accesso, vedi Autorizzazioni supportate nella .

  In alcuni casi, puoi anche utilizzare i gruppi di autorizzazioni per negare gli insiemi autorizzazioni aggiuntive. Per ulteriori informazioni, consulta la sezione Autorizzazioni gruppi di lavoro.

• 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, l'autorizzazione non viene negata. Per ulteriori informazioni, consulta la sezione Rifiuto condizioni 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 necessarie.

Ad esempio, immagina che sia yuri@example.com sia tal@example.com abbiano il Ruolo Amministratore ruoli organizzazione (roles/iam.organizationRoleAdmin). Tuttavia, yuri@example.com è membro di custom-role-admins@example.com, e tal@example.com non lo è. Con questo criterio di rifiuto, solo yuri@example.com è in grado di 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à fornisce è possibile concedere un ruolo ad alto livello nella gerarchia delle risorse neghi le autorizzazioni per le singole risorse di livello inferiore necessaria.

Ad esempio, immagina di avere una cartella, Engineering, che contiene diversi progetti. Vuoi assegnare a un gruppo, eng@example.com, 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 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"
  ]
}

Quindi, aggiungi questa regola di negazione a un criterio di negazione e colleghi quest'ultimo al progetto example-prod.

Dopo aver collegato il criterio di negazione al progetto, puoi concedere al servizio Ruolo Amministratore chiavi account per eng@example.com nella cartella Engineering senza consentendo al gruppo di creare o eliminare le chiavi degli 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 appartiene a eng@example.com, 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 di eng@example.com sia in grado per 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"
  ]
}

Grazie a questo criterio di negazione rivisto, i membri di eng-prod@example.com possono creare e 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 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: Elimina i progetti con il tag prod.

Per risolvere il problema, devi creare una regola di negazione che nega Autorizzazione cloudresourcemanager.googleapis.com/projects.delete per tutti tranne 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, considera due utenti, bola@example.com e kiran@example.com. Entrambi gli utenti hanno il ruolo Autore eliminazione progetto (roles/resourcemanager.projectDeleter). Inoltre, kiran@example.com è un membro di project-admins@example.com. Con questo criterio di negazione, 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

• 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 è possibile negare.
• Vedi i tipi di entità che puoi includere nei criteri di negazione.