Criteri di negazione

I criteri di negazione di Identity and Access Management (IAM) consentono di impostare misure di protezione per l'accesso 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 assegnati.

Questa pagina fornisce una panoramica dei criteri di negazione e delle regole di negazione. Per informazioni su come creare e aggiornare i criteri di negazione, consulta 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 affinché l'autorizzazione venga negata

Quando a un'entità viene negata un'autorizzazione, l'entità non può fare nulla per cui sia richiesta l'autorizzazione in questione, indipendentemente dai ruoli IAM assegnati. perché IAM verifica sempre i criteri di negazione pertinenti prima di controllare quelli di autorizzazione pertinenti. Per maggiori dettagli, consulta la valutazione dei criteri.

Per specificare dove vuoi che venga applicato un criterio di negazione, lo colleghi a un progetto, una cartella o un'organizzazione. Quando un criterio di negazione è associato a una di queste risorse, le entità nel criterio non possono utilizzare le autorizzazioni specificate per accedere alla risorsa o a qualsiasi discendente della risorsa.

Puoi collegare più criteri di negazione a una singola risorsa. In questo modo puoi creare criteri di negazione separati per diversi tipi di regole di negazione. Ad esempio, potresti inserire le regole di negazione relative alla conformità in un criterio e poi utilizzarne un altro per altre regole di negazione. Ogni criterio di negazione viene valutato indipendentemente da tutti gli altri criteri di negazione.

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

Valutazione dei criteri

Quando un'entità tenta di accedere a una risorsa, IAM valuta tutti i criteri di autorizzazione e negazione pertinenti per verificare se l'entità è autorizzata ad accedere alla risorsa. Valuta i criteri nel seguente ordine:

  1. IAM controlla tutti i criteri di negazione pertinenti per verificare se all'entità è stata negata l'autorizzazione. I criteri di negazione pertinenti sono quelli associati alla risorsa, nonché tutti i criteri di negazione ereditati.

    Se uno qualsiasi di questi criteri di negazione impedisce all'entità di utilizzare un'autorizzazione richiesta, IAM impedisce all'entità di accedere alla risorsa.

    Se nessun criterio di negazione impedisce all'entità di utilizzare un'autorizzazione richiesta, IAM continua con il passaggio successivo.

  2. IAM controlla tutti i criteri di autorizzazione pertinenti per vedere se l'entità dispone delle autorizzazioni richieste. I criteri di autorizzazione pertinenti sono i criteri di autorizzazione associati alla risorsa, nonché eventuali criteri di autorizzazione ereditati.

    Se l'entità dispone delle autorizzazioni richieste, IAM consente di accedere alla risorsa.

    Se l'entità non dispone delle autorizzazioni richieste, IAM le impedisce di accedere alla risorsa.

Il seguente diagramma mostra questo flusso di valutazione dei criteri:

Nega ereditarietà dei criteri

I criteri di negazione, come quelli di autorizzazione, vengono ereditati attraverso la gerarchia delle risorse. Quando colleghi un criterio di negazione a un progetto, una cartella o un'organizzazione, il criterio viene applicato anche per tutte le risorse all'interno del progetto, della cartella o dell'organizzazione.

Ad esempio, se un criterio di negazione per un'organizzazione indica che un'entità non può utilizzare un'autorizzazione specifica, non può utilizzarla per qualsiasi 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 negazione per un progetto indica che un'entità non può utilizzare un'autorizzazione specifica, non può utilizzare l'autorizzazione per qualsiasi risorsa all'interno del progetto. Questa regola si applica anche se l'organizzazione e le cartelle padre hanno criteri di negazione più permissivi.

Condizioni di negazione

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

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

Per informazioni su come scrivere le condizioni, consulta la panoramica sulle condizioni IAM.

Gruppi di autorizzazioni

Alcuni servizi 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 risorsa.

I gruppi di autorizzazioni supportati sono elencati in Autorizzazioni supportate nei criteri di negazione. Non puoi utilizzare i caratteri jolly in altri nomi di autorizzazioni.

L'identificatore di un gruppo di autorizzazioni sostituisce una o più sezioni del nome di un'autorizzazione con un carattere jolly (*). Il gruppo di autorizzazioni include tutte le autorizzazioni che corrispondono a questo pattern.

I caratteri jolly possono comparire nelle seguenti posizioni:

  • 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 corrispondenti 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à negata automaticamente la nuova autorizzazione.

Struttura di un criterio di negazione

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

Ad esempio, il seguente criterio di negazione impedisce a tutte le entità di eliminare progetti, a meno che l'entità non sia membro di project-admins@example.com o che il progetto in fase di eliminazione non abbia un tag con 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 seguenti sezioni descrivono i campi dei metadati e delle regole di negazione di un criterio di negazione.

Metadati

I criteri di negazione contengono i seguenti metadati:

  • name: il nome del criterio di negazione. 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 negazione e 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: l'identificatore di una versione del criterio. Per evitare aggiornamenti in conflitto, il valore etag deve corrispondere al valore archiviato in IAM. Se i valori etag non corrispondono, la richiesta non va a buon fine.
  • createTime: data e ora della creazione del criterio di negazione.
  • updateTime: l'ultima volta che il criterio di negazione è stato aggiornato.

Regole di negazione

Ogni regola di negazione può avere i seguenti campi:

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

    Per un elenco dei tipi di entità e degli 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 singole entità e insiemi di entità. I tipi di entità individuali includono account utente, account di servizio e identità singole in una forza lavoro o in un pool di identità dei carichi di lavoro. Gli insiemi di entità comprendono gruppi Google, domini Cloud Identity, insiemi di identità di forza lavoro o carichi di lavoro e tutti gli utenti su internet.

    Per un elenco dei tipi di entità e degli identificatori validi, consulta Identificatori delle entità API IAM v2.

  • deniedPermissions: le autorizzazioni che le entità specificate non sono in grado di utilizzare o che le entità specificate non sono in grado di utilizzare. Queste autorizzazioni utilizzano il formato dell'autorizzazione 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.

    È possibile negare solo alcune autorizzazioni. Per un elenco completo delle autorizzazioni che possono essere negate, vedi Autorizzazioni supportate nei criteri di negazione.

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

  • denialConditions: facoltativo. Un'espressione logica che influisce sul momento in cui si applica la regola di negazione. 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 maggiori informazioni, consulta la sezione Condizioni di negazione in questa pagina.

Casi d'uso comuni

Di seguito sono riportate alcune situazioni comuni in cui potresti voler utilizzare i criteri di negazione e alcuni esempi di regole di negazione che potresti creare in ciascuna situazione. Per informazioni su come creare e aggiornare i criteri di negazione, consulta 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 personalizzati per la tua organizzazione a un unico team centrale. Per farlo, crea una regola di negazione che nega le autorizzazioni necessarie per la gestione dei ruoli personalizzati a tutti gli utenti, ad eccezione degli 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",
  ]
}

Successivamente, collegherai il criterio di negazione alla tua organizzazione.

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

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

Creazione di eccezioni per accedere alle concessioni

Puoi utilizzare i criteri di negazione per negare le autorizzazioni ereditate. Questa funzionalità ti offre la possibilità di concedere un ruolo a un livello superiore nella gerarchia delle risorse e di negare le autorizzazioni del ruolo per le singole risorse di livello inferiore, se necessario.

Ad esempio, immagina di avere una cartella, Engineering, che contiene più progetti. Vuoi assegnare a un gruppo, eng@example.com, le autorizzazioni nel ruolo Amministratore chiavi dell'account di servizio (roles/iam.serviceAccountKeyAdmin) per quasi tutti i progetti presenti nella cartella. Tuttavia, non vuoi che il gruppo ottenga la possibilità di creare ed eliminare le chiavi degli account di servizio in un progetto specifico nella cartella, example-prod.

Anziché concedere il ruolo Amministratore chiavi account di servizio su ogni singolo progetto, puoi creare la seguente regola di negazione, che nega alle entità in eng@example.com le autorizzazioni di creazione ed eliminazione del ruolo Amministratore chiavi dell'account di servizio:

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

Dopo aver collegato il criterio di negazione 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 le chiavi degli account di servizio in example-prod.

I membri di eng@example.com possono quindi creare ed eliminare le chiavi degli account di servizio in tutti i progetti tranne in example-prod. Ad esempio, se izumi@example.com è un membro di 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 voler davvero che un sottoinsieme di eng@example.com sia in grado di creare ed eliminare le chiavi degli account di servizio in example-prod. Questo sottoinsieme è rappresentato dal gruppo eng-prod@example.com. Per consentire ai membri di eng-prod@example.com di creare ed eliminare le chiavi degli 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 negazione rivisto, i membri di eng-prod@example.com possono creare ed eliminare chiavi degli account di servizio in tutti i progetti, incluso example-prod. 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 è anche membro di eng@example.com.

Blocco dell'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 aggiungere una condizione IAM a ogni concessione di ruolo.

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

Per risolvere questo problema, crei una regola di negazione che neghi l'autorizzazione cloudresourcemanager.googleapis.com/projects.delete a 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')"
        }
      }
    }
  ]
}

Poi, aggiungi questa regola di negazione a un criterio di negazione e collegalo alla tua organizzazione.

Grazie a questa regola di negazione, puoi limitare l'accesso delle entità senza aggiungere una condizione alle concessioni dei ruoli. Puoi invece concedere alle entità ruoli che contengono l'autorizzazione cloudresourcemanager.googleapis.com/projects.delete e utilizzare la regola di negazione per impedire alle entità esterne a project-admins@example.com di eliminare tutti i progetti taggati 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 è membro di project-admins@example.com. Con questo criterio di negazione, bola@example.com può eliminare solo i progetti che hanno il tag dev o test. kiran@example.com può eliminare tutti i progetti, indipendentemente dai tag.

Passaggi successivi