Applicare criteri ai gruppi di utenti utilizzando le associazioni di accesso

Puoi utilizzare le associazioni di accesso per controllare a quali applicazioni e risorse possono accedere i tuoi gruppi di utenti. Un'associazione di accesso specifica come applicare i livelli di accesso e i controlli della sessione a un gruppo di utenti. Puoi applicare lo stesso livello di accesso e lo stesso controllo della sessione a tutte le applicazioni oppure puoi definire comportamenti specifici per le singole applicazioni.

Per assicurarti di aver configurato tutto correttamente, testa le policy prima di applicarle.

Quando utilizzi le associazioni di accesso, tieni presente il seguente comportamento:

  • Un gruppo di utenti può avere una sola associazione di accesso.
  • Se un utente appartiene a più gruppi, l'accesso viene concesso se una qualsiasi policy lo consente (OR, non AND).
  • Per i controlli della sessione, viene applicata solo l'associazione di accesso creata più di recente.

Utilizza un'unica configurazione per tutte le applicazioni

Questo metodo applica lo stesso livello di accesso e lo stesso controllo della sessione a tutte le applicazioni a cui accede un gruppo di utenti.

Ti consigliamo di testare la policy con un dry run o di applicarla a un piccolo gruppo di test prima di implementarla in produzione.

gcloud

Crea l'associazione di accesso.

gcloud access-context-manager cloud-bindings create \
     --group-key GROUP_ID
     --organization ORG_ID
     --level DEFAULT_ACCESS_LEVEL
  [  --session-length=DEFAULT_SESSION_LENGTH                ]
  [  --session-reauth-method=DEFAULT_SESSION_REAUTH_METHOD  ]

Sostituisci quanto segue:

  • GROUP_ID: l'ID gruppo. Se non hai a disposizione l'ID gruppo, puoi recuperarlo chiamando il metodo get sulla risorsa del gruppo.
  • ORG_ID: ID organizzazione.
  • DEFAULT_ACCESS_LEVEL: il nome facoltativo del livello di accesso, che assume la forma accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sostituisci POLICY_ID con l'ID della policy di accesso e ACCESS_LEVEL_NAME con il nome del livello di accesso.
  • DEFAULT_SESSION_LENGTH: la durata facoltativa della sessione nel formato ora, ad esempio 15h per 15 ore o 2h per due ore.
  • DEFAULT_SESSION_REAUTH_METHOD: il metodo facoltativo per chiedere agli utenti di verificare nuovamente la propria identità, che deve essere uno dei seguenti:
    • LOGIN: applica l'accesso standard, che può includere l'MFA o altri fattori definiti da Workspace.
    • PASSWORD: richiede solo una password, anche se sono definiti altri fattori. Se le password vengono gestite utilizzando un IdP esterno, gli utenti vengono reindirizzati all'IdP. Se la sessione IdP è attiva, gli utenti vengono autenticati nuovamente in modo implicito. Se l'IdP non è attivo, gli utenti devono accedere tramite l'IdP.
    • SECURITY_KEY: richiede una chiave di sicurezza hardware.

API

  1. Crea un corpo JSON:

    {
  "groupKey": "GROUP_ID",
  "accessLevels": [
    "DEFAULT_ACCESS_LEVEL"
  ],
  // optional:
  "sessionSettings": {
    "sessionLength": "DEFAULT_SESSION_LENGTH",
    "sessionReauthMethod": "DEFAULT_SESSION_REAUTH_METHOD"
  }
}

    Sostituisci quanto segue:

    • GROUP_ID: l'ID gruppo. Se non hai a disposizione l'ID gruppo, puoi recuperarlo chiamando il metodo get sulla risorsa del gruppo.
    • DEFAULT_ACCESS_LEVEL: il nome facoltativo del livello di accesso, che assume la forma accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sostituisci POLICY_ID con l'ID della policy di accesso e ACCESS_LEVEL_NAME con il nome del livello di accesso.
    • DEFAULT_SESSION_LENGTH: la durata facoltativa della sessione nel formato ora, ad esempio 15h per 15 ore o 2h per due ore.
    • DEFAULT_SESSION_REAUTH_METHOD: il metodo facoltativo per chiedere agli utenti di verificare nuovamente la propria identità, che deve essere uno dei seguenti:
      • LOGIN: applica l'accesso standard, che può includere l'MFA o altri fattori definiti da Workspace.
      • PASSWORD: richiede solo una password, anche se sono definiti altri fattori. Se le password vengono gestite utilizzando un IdP esterno, gli utenti vengono reindirizzati all'IdP. Se la sessione IdP è attiva, gli utenti vengono autenticati nuovamente in modo implicito. Se l'IdP non è attivo, gli utenti devono accedere tramite l'IdP.
      • SECURITY_KEY: richiede una chiave di sicurezza hardware.

  2. Invia la richiesta POST:

    POST https://accesscontextmanager.googleapis.com/v1/organizations/ORG_ID/gcpUserAccessBindings

    ORG_ID è l'ID dell'organizzazione che hai utilizzato per creare il ruolo Cloud Access Binding Admin. Se la proprietà access-context-manager/organization non è stata impostata, sostituisci ORG_ID nel flag facoltativo --organization con l'ID dell'organizzazione che hai utilizzato quando hai creato il ruolo Cloud Access Binding Admin.

In caso di esito positivo, ricevi una rappresentazione dell'oggetto JSON. Se si verifica un problema, riceverai un messaggio di errore.

Definisci le configurazioni per applicazioni specifiche

Questo metodo ti consente di applicare livelli di accesso e controlli delle sessioni diversi ad applicazioni diverse. Puoi anche impostare regole predefinite per le applicazioni che non hanno configurazioni specifiche.

Puoi specificare le applicazioni nelle associazioni di accesso utilizzando il relativo ID client OAuth. Puoi specificare le seguenti applicazioni utilizzando il loro nome:

Questo metodo è utile se vuoi:

  • Applica le policy solo ad alcune applicazioni.

  • Creare una policy generale, ma escludere alcune applicazioni.

gcloud

  1. Crea un file di associazione in formato YAML con un elenco di voci di ambito all'interno dell'elenco scopedAccessSettings. Per ogni applicazione che vuoi mappare a un livello di accesso specifico, includi una voce clientScope.

    scopedAccessSettings:
- scope:
    clientScope:
      restrictedClientApplication:
        clientId: CLIENT_ID
  activeSettings:
    accessLevels:
    - ACCESS_LEVEL_A
    sessionSettings:
      sessionLength: SESSION_LENGTH
      sessionReauthMethod: SESSION_REAUTH_METHOD
      sessionLengthEnabled: true
- scope:
    clientScope:
      restrictedClientApplication:
        name: CLIENT_NAME
  activeSettings:
    accessLevels:
    - ACCESS_LEVEL_B

    Sostituisci quanto segue:

    • CLIENT_ID: l'ID client OAuth. Puoi utilizzare clientId o name quando un'applicazione contiene sessionSettings.
    • ACCESS_LEVEL_A: il nome di un livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • SESSION_LENGTH: la durata della sessione nel formato ora, ad esempio 15h per 15 ore o 2h per due ore.

    • SESSION_REAUTH_METHOD: il metodo facoltativo per chiedere agli utenti di verificare nuovamente la propria identità, che deve essere uno dei seguenti:

      • LOGIN: applica l'accesso standard, che può includere l'autenticazione a più fattori (MFA) o altri fattori definiti da Workspace.
      • PASSWORD: richiede solo una password, anche se sono definiti altri fattori. Se le password vengono gestite utilizzando un IdP esterno, gli utenti vengono reindirizzati all'IdP. Se la sessione IdP è attiva, gli utenti vengono autenticati nuovamente in modo implicito. Se l'IdP non è attivo, gli utenti devono accedere tramite l'IdP.
      • SECURITY_KEY: richiede una chiave di sicurezza hardware.

    • CLIENT_NAME: il nome del client. Puoi utilizzare name o clientId quando un'applicazione contiene sessionSettings.

    • ACCESS_LEVEL_B: il nome di un livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

    Per impostare un livello di accesso predefinito per le applicazioni non definite nel file YAML, utilizza l'argomento --level. Il file YAML supporta solo le impostazioni specifiche dell'applicazione (scopedAccessSettings).

  2. Crea l'associazione di accesso.

    gcloud access-context-manager cloud-bindings create
    --organization ORG_ID
    --group-key GROUP_ID
    --binding-file BINDING_FILE_PATH
  [  --level DEFAULT_ACCESS_LEVEL ]
  [  --session-length=DEFAULT_SESSION_LENGTH                ]
  [  --session-reauth-method=DEFAULT_SESSION_REAUTH_METHOD  ]

    Sostituisci quanto segue:

    • ORG_ID: ID organizzazione.
    • GROUP_ID: l'ID gruppo. Se non hai a disposizione l'ID gruppo, puoi recuperarlo chiamando il metodo get sulla risorsa del gruppo.
    • BINDING_FILE_PATH: il percorso del file YAML che contiene lo schema di associazione di accesso. Il file di associazione supporta solo scopedAccessSettings.
    • DEFAULT_ACCESS_LEVEL: il nome facoltativo del livello di accesso, che assume la forma accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sostituisci POLICY_ID con l'ID della policy di accesso e ACCESS_LEVEL_NAME con il nome del livello di accesso.
    • DEFAULT_SESSION_LENGTH: la durata facoltativa della sessione nel formato ora, ad esempio 15h per 15 ore o 2h per due ore.
    • DEFAULT_SESSION_REAUTH_METHOD: il metodo facoltativo per chiedere agli utenti di verificare nuovamente la propria identità, che deve essere uno dei seguenti:
      • LOGIN: applica l'accesso standard, che può includere l'MFA o altri fattori definiti da Workspace.
      • PASSWORD: richiede solo una password, anche se sono definiti altri fattori. Se le password vengono gestite utilizzando un IdP esterno, gli utenti vengono reindirizzati all'IdP. Se la sessione IdP è attiva, gli utenti vengono autenticati nuovamente in modo implicito. Se l'IdP non è attivo, gli utenti devono accedere tramite l'IdP.
      • SECURITY_KEY: richiede una chiave di sicurezza hardware.

Come interagiscono gli argomenti --level e --binding-file

  • Se utilizzi solo --binding-file, le policy vengono applicate solo alle applicazioni nel file.
  • Se utilizzi solo --level, il livello di accesso si applica a tutte le applicazioni.
  • Se utilizzi entrambe le opzioni, le regole vengono combinate. Il valore --level si applica a tutte le applicazioni, mentre le policy nel file YAML specificato da --binding-file si applicano solo alle applicazioni definite nel file.

Utilizzare i controlli della sessione

  • Per impostare i controlli della sessione predefiniti per tutte le applicazioni, utilizza --session-length e --session-reauth-method.
  • Se definisci i controlli della sessione anche nel file YAML, questi controlli eseguono l'override delle impostazioni predefinite per queste applicazioni specifiche.
  • Devi utilizzare --session-length e --session-reauth-method insieme.

API

Crea un corpo JSON:

{
  "groupKey": "GROUP_ID",
   //
   // Optional; if specified, all applications that aren't defined in
   // scopedAccessSettings have these access levels applied.
   //
   // If more than one access level is specified, the user is
   // granted access if any one resolves to TRUE (OR logic, not AND).
   //
   // If you omit this key entirely, then no policy enforcement is
   // applied by default.
   //
  "accessLevels": [
    "DEFAULT_ACCESS_LEVEL"
  ],
  "scopedAccessSettings": [
    {
      "scope": {
        "clientScope": {
          "restrictedClientApplication": {
            "clientId": "CLIENT_ID"
          }
        }
      },
      "activeSettings": {
        "accessLevels": [
          "ACCESS_LEVEL_A"
        ],
        "sessionSettings": {
          "sessionLength": "SESSION_LENGTH",
          "sessionReauthMethod": "SESSION_REAUTH_METHOD",
          "sessionLengthEnabled": true
        }
      }
    },
    {
      "scope": {
        "clientScope": {
          "restrictedClientApplication": {
            "name": "CLIENT_NAME"
          }
        },
        "activeSettings": {
          "accessLevels": [
            "ACCESS_LEVEL_B"
          ]
        }
      }
    }
  ]
}

Sostituisci quanto segue:

  • GROUP_ID: l'ID gruppo. Se non hai a disposizione l'ID gruppo, puoi recuperarlo chiamando il metodo get sulla risorsa del gruppo.
  • DEFAULT_ACCESS_LEVEL: il nome facoltativo del livello di accesso, che assume la forma accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sostituisci POLICY_ID con l'ID della policy di accesso e ACCESS_LEVEL_NAME con il nome del livello di accesso.
  • CLIENT_ID: l'ID client OAuth. Puoi utilizzare clientId o name quando un'applicazione contiene sessionSettings.
  • ACCESS_LEVEL_A: il nome di un livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
  • SESSION_LENGTH: la durata della sessione nel formato ora, ad esempio 2h per due ore.

  • SESSION_REAUTH_METHOD: il metodo facoltativo per chiedere agli utenti di verificare nuovamente la propria identità, che deve essere uno dei seguenti:

    • LOGIN: applica l'accesso standard, che può includere l'MFA o altri fattori definiti da Workspace.
    • PASSWORD: richiede solo una password, anche se sono definiti altri fattori. Se le password vengono gestite utilizzando un IdP esterno, gli utenti vengono reindirizzati all'IdP. Se la sessione IdP è attiva, gli utenti vengono autenticati nuovamente in modo implicito. Se l'IdP non è attivo, gli utenti devono accedere tramite l'IdP.
    • SECURITY_KEY: richiede una chiave di sicurezza hardware.

  • CLIENT_NAME: il nome del client. Puoi utilizzare name o clientId quando un'applicazione contiene sessionSettings.

  • ACCESS_LEVEL_B: il nome di un livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

Invia la richiesta POST:

POST https://accesscontextmanager.googleapis.com/v1/organizations/ORG_ID/gcpUserAccessBindings

ORG_ID è l'ID dell'organizzazione che hai utilizzato per creare il ruolo Cloud Access Binding Admin. Se la proprietà access-context-manager/organization non è stata impostata, sostituisci ORG_ID nel flag facoltativo --organization con l'ID dell'organizzazione che hai utilizzato quando hai creato il ruolo Amministratore di Cloud Access Binding.

In caso di esito positivo, dovresti ricevere una rappresentazione dell'oggetto JSON o un messaggio di errore se si è verificato un problema.

Utilizza i livelli di accesso dry run per simulare l'applicazione

I livelli di accesso dry run ti consentono di testare le policy di accesso senza applicarle effettivamente. In questo modo, puoi comprendere l'impatto di una policy prima che venga pubblicata. Puoi visualizzare i log dry run per vedere cosa sarebbe successo se la policy fosse stata attiva.

In modalità dry run possono essere utilizzati solo i livelli di accesso. I controlli della sessione non sono disponibili in modalità dry run.

Crea una policy dry run generale

Questo metodo applica lo stesso livello di accesso dry run a tutte le applicazioni a cui accede un gruppo di utenti.

gcloud

Crea l'associazione di accesso con il flag --dry-run-level.

gcloud access-context-manager cloud-bindings create \
     --group-key=<var>GROUP_ID</var> \
     --organization=<var>ORG_ID</var> \
     --dry-run-level=<var>DEFAULT_DRY_RUN_ACCESS_LEVEL</var>

Sostituisci quanto segue:

  • GROUP_ID: l'ID gruppo. Se non hai a disposizione l'ID gruppo, puoi recuperarlo chiamando il metodo get sulla risorsa del gruppo.
  • ORG_ID: ID organizzazione.
  • DEFAULT_DRY_RUN_ACCESS_LEVEL: il nome del livello di accesso dry run nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

API

  1. Crea un corpo JSON contenente dry_run_access_levels.

    {
  "group_key": "GROUP_ID",
  "dry_run_access_levels": [
    "DEFAULT_DRY_RUN_ACCESS_LEVEL"
  ]
}

    Sostituisci quanto segue:

    • GROUP_ID: l'ID gruppo. Se non hai a disposizione l'ID gruppo, puoi recuperarlo chiamando il metodo get sulla risorsa del gruppo.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL: il nome del livello di accesso dry run nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Invia la richiesta POST:

    POST https://accesscontextmanager.googleapis.com/v1/organizations/ORG_ID/gcpUserAccessBindings

    ORG_ID è l'ID dell'organizzazione che hai utilizzato per creare il ruolo Cloud Access Binding Admin. Se la proprietà access-context-manager/organization non è stata impostata, sostituisci ORG_ID nel flag facoltativo --organization con l'ID dell'organizzazione che hai utilizzato quando hai creato il ruolo Amministratore di Cloud Access Binding.

Crea una policy dry run per applicazioni specifiche

Questo metodo ti consente di applicare livelli di accesso dry run diversi ad applicazioni diverse. Puoi anche impostare regole predefinite per le applicazioni senza una configurazione specifica.

gcloud

  1. Configura le impostazioni di accesso in un file di associazione YAML utilizzando il campo dryRunSettings.

    scopedAccessSettings:
- scope:
    clientScope:
      restrictedClientApplication:
        name: CLIENT_NAME
  activeSettings:
    accessLevels:
    - ACCESS_LEVEL_A
  dryRunSettings:
    accessLevels:
    - DRY_RUN_ACCESS_LEVEL_1
- scope:
    clientScope:
      restrictedClientApplication:
        clientId: CLIENT_ID
  dryRunSettings:
    accessLevels:
    - DRY_RUN_ACCESS_LEVEL_2

    Sostituisci quanto segue:

    • CLIENT_NAME: il nome del client. Puoi utilizzare name o clientId quando un'applicazione contiene sessionSettings.
    • ACCESS_LEVEL_A: il nome di un livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • DRY_RUN_ACCESS_LEVEL_1: il nome di un livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_ID: l'ID client OAuth. Puoi utilizzare clientId o name quando un'applicazione contiene sessionSettings.
    • DRY_RUN_ACCESS_LEVEL_2: il nome di un livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Crea l'associazione di accesso.

    gcloud access-context-manager cloud-bindings create \
  --organization ORG_ID \
  --group-key GROUP_ID \
  --binding-file BINDING_FILE_PATH
  --dry-run-level DEFAULT_DRY_RUN_ACCESS_LEVEL

    Sostituisci quanto segue:

    • ORG_ID: ID organizzazione.
    • GROUP_ID: l'ID gruppo. Se non hai a disposizione l'ID gruppo, puoi recuperarlo chiamando il metodo get sulla risorsa del gruppo.
    • BINDING_FILE_PATH: il percorso del file YAML che contiene lo schema di associazione di accesso. Il file di associazione supporta solo scopedAccessSettings.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL: un nome facoltativo del livello di accesso dry run nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

    Includi questo flag per applicare il livello di accesso dry run specificato a tutte le applicazioni per impostazione predefinita se non sono specificate nel file YAML.

API

  1. Crea un corpo JSON:

    {
  "group_key": "GROUP_ID",
  //
  // Optional; if specified, all applications that aren't defined in scopedAccessSettings will have these dry-run access levels applied.
  //
  "dry_run_access_levels": [
    "DEFAULT_DRY_RUN_ACCESS_LEVEL"
  ],
  "scoped_access_settings": [
    {
      "scope": {
        "client_scope": {
          "restricted_client_application": {
            "name": "CLIENT_NAME"
          }
        }
      },
      "active_settings": {
        "access_levels": [
          "ACCESS_LEVEL_A"
        ]
      },
      "dry_run_settings": {
        "access_levels": [
          "DRY_RUN_ACCESS_LEVEL_1"
        ]
      }
    },
    {
      "scope": {
        "client_scope": {
          "restricted_client_application": {
            "client_id": "CLIENT_ID"
          }
        }
      },
      "dry_run_settings": {
        "access_levels": [
          "DRY_RUN_ACCESS_LEVEL_2"
        ]
      }
    }
  ]
}

    Sostituisci quanto segue:

    • GROUP_ID: l'ID gruppo. Se non hai a disposizione l'ID gruppo, puoi recuperarlo chiamando il metodo get sulla risorsa del gruppo.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL: un nome facoltativo del livello di accesso dry run nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_NAME: il nome del client. Puoi utilizzare name o clientId quando un'applicazione contiene sessionSettings.
    • ACCESS_LEVEL_A: il nome di un livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • DRY_RUN_ACCESS_LEVEL_1: un nome del livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_ID: l'ID client OAuth. Puoi utilizzare client_id o name quando un'applicazione contiene sessionSettings.
    • DRY_RUN_ACCESS_LEVEL_2: il nome di un livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Invia la richiesta POST:

    POST https://accesscontextmanager.googleapis.com/v1/organizations/ORG_ID/gcpUserAccessBindings

    ORG_ID è l'ID dell'organizzazione che hai utilizzato per creare il ruolo Cloud Access Binding Admin. Se la proprietà access-context-manager/organization non è stata impostata, sostituisci ORG_ID nel flag facoltativo --organization con l'ID dell'organizzazione che hai utilizzato quando hai creato il ruolo Amministratore di Cloud Access Binding.

    In caso di esito positivo, ricevi una rappresentazione dell'oggetto JSON. Se si verifica un problema, riceverai un messaggio di errore.

Visualizza i log della policy dry run

Dopo aver configurato un dry run, puoi controllare i log per vedere quali tentativi di accesso sarebbero stati negati.

La tabella seguente elenca i campi dei log che puoi utilizzare per creare ed eseguire la query per ottenere i log:

Nome campo Descrizione
protoPayload.authenticationInfo.principalEmail ID email dell'entità a cui è stato negato l'accesso.
protoPayload.metadata.deniedApplications Nome dell'applicazione per cui è stato negato l'accesso.
protoPayload.metadata.evaluationResult Il risultato della valutazione della policy di accesso attiva. Valori possibili: GRANTED o DENIED. Se nell'associazione non vengono applicati livelli di accesso attivi, questo campo viene impostato su GRANTED.
protoPayload.metadata.appliedAccessLevels I livelli di accesso applicati richiesti dalla policy di accesso attiva.
protoPayload.metadata.appliedDryRunAccessLevels I livelli di accesso applicati richiesti dalla policy di accesso dry run.
protoPayload.metadata.dryRunEvaluationResult Il risultato della valutazione della policy di accesso dry run, che indica l'azione prevista quando viene applicata la policy di accesso. Valori possibili: GRANTED o DENIED. Se nell'associazione non vengono applicati livelli di accesso dry run, questo campo viene impostato su GRANTED, anche quando evaluationResult è DENIED.
protoPayload.metadata.unsatisfiedAccessLevels I livelli di accesso nell'organizzazione che la richiesta non è riuscita a soddisfare. Questo elenco può includere livelli di accesso non applicati nell'associazione di accesso. Per identificare i livelli di accesso che hanno causato un rifiuto dell'accesso, confronta questo campo con appliedAccessLevels o appliedDryRunAccessLevels.

Per istruzioni su come creare una query per i log, consulta Linguaggio di query di Logging.