Appliquer des règles à des groupes d'utilisateurs à l'aide de liaisons d'accès

Vous pouvez utiliser des liaisons d'accès pour contrôler les applications et les ressources auxquelles vos groupes d'utilisateurs peuvent accéder. Une liaison d'accès spécifie comment appliquer des niveaux d'accès et des contrôles de session à un groupe d'utilisateurs. Vous pouvez appliquer le même niveau d'accès et le même contrôle de session à toutes les applications, ou définir des comportements spécifiques pour chaque application.

Pour vous assurer que vous avez tout configuré correctement, testez vos règles avant de les appliquer.

Lorsque vous utilisez des liaisons d'accès, tenez compte du comportement suivant :

  • Un groupe d'utilisateurs ne peut avoir qu'une seule liaison d'accès.
  • Si un utilisateur appartient à plusieurs groupes, il est autorisé à accéder à la ressource si l'une des règles l'autorise (OR et non AND).
  • Pour les contrôles de session, seule la liaison d'accès la plus récente s'applique.

Utiliser une seule configuration pour toutes les applications

Cette méthode applique le même niveau d'accès et le même contrôle de session à toutes les applications auxquelles un groupe d'utilisateurs accède.

Nous vous recommandons de tester votre stratégie avec une simulation ou de l'appliquer à un petit groupe de test avant de l'implémenter en production.

gcloud

Créez la liaison d'accès.

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  ]

Remplacez les éléments suivants :

  • GROUP_ID : ID du groupe. Si vous ne disposez pas de l'ID du groupe, vous pouvez le récupérer en appelant la méthode get sur la ressource du groupe.
  • ORG_ID : ID d'organisation.
  • DEFAULT_ACCESS_LEVEL : nom facultatif du niveau d'accès, au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Remplacez POLICY_ID par l'ID de la règle d'accès et ACCESS_LEVEL_NAME par le nom du niveau d'accès.
  • DEFAULT_SESSION_LENGTH : durée de session facultative au format heure, par exemple 15h pour 15 heures ou 2h pour deux heures.
  • DEFAULT_SESSION_REAUTH_METHOD : méthode facultative permettant de demander aux utilisateurs de confirmer à nouveau leur identité, qui doit être l'une des suivantes :
    • LOGIN : appliquez la connexion standard, qui peut inclure MFA ou d'autres facteurs définis par Workspace.
    • PASSWORD : ne demander qu'un mot de passe, même si d'autres facteurs sont définis. Si les mots de passe sont gérés à l'aide d'un IdP externe, les utilisateurs sont redirigés vers l'IdP. Si la session IdP est active, les utilisateurs sont implicitement réauthentifiés. Si le fournisseur d'identité n'est pas actif, les utilisateurs doivent se connecter via le fournisseur d'identité.
    • SECURITY_KEY : exiger une clé de sécurité matérielle.

API

  1. Créez un corps JSON :

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

    Remplacez les éléments suivants :

    • GROUP_ID : ID du groupe. Si vous ne disposez pas de l'ID du groupe, vous pouvez le récupérer en appelant la méthode get sur la ressource du groupe.
    • DEFAULT_ACCESS_LEVEL : nom facultatif du niveau d'accès, au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Remplacez POLICY_ID par l'ID de la règle d'accès et ACCESS_LEVEL_NAME par le nom du niveau d'accès.
    • DEFAULT_SESSION_LENGTH : durée de session facultative au format heure, par exemple 15h pour 15 heures ou 2h pour deux heures.
    • DEFAULT_SESSION_REAUTH_METHOD : méthode facultative permettant de demander aux utilisateurs de confirmer à nouveau leur identité, qui doit être l'une des suivantes :
      • LOGIN : appliquez la connexion standard, qui peut inclure MFA ou d'autres facteurs définis par Workspace.
      • PASSWORD : ne demander qu'un mot de passe, même si d'autres facteurs sont définis. Si les mots de passe sont gérés à l'aide d'un IdP externe, les utilisateurs sont redirigés vers l'IdP. Si la session IdP est active, les utilisateurs sont implicitement réauthentifiés. Si le fournisseur d'identité n'est pas actif, les utilisateurs doivent se connecter via le fournisseur d'identité.
      • SECURITY_KEY : exiger une clé de sécurité matérielle.

  2. Envoyez la requête POST :

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

    ORG_ID est l'ID de l'organisation que vous avez utilisé pour créer le rôle Administrateur de liaison d'accès au cloud. Si la propriété access-context-manager/organization n'a pas été définie, remplacez ORG_ID dans l'option facultative --organization par l'ID de l'organisation que vous avez utilisé lors de la création du rôle d'administrateur de liaison Cloud Access.

Si l'opération réussit, vous recevez une représentation de l'objet JSON. En cas de problème, vous recevez un message d'erreur.

Définir des configurations pour des applications spécifiques

Cette méthode vous permet d'appliquer différents niveaux d'accès et contrôles de session à différentes applications. Vous pouvez également définir des règles par défaut pour les applications qui n'ont pas de configuration spécifique.

Vous pouvez spécifier des applications dans les liaisons d'accès à l'aide de leur ID client OAuth. Vous pouvez spécifier les applications suivantes en utilisant leur nom :

Cette méthode est utile lorsque vous souhaitez effectuer les opérations suivantes :

  • Appliquez des règles à certaines applications uniquement.

  • Créer une règle générale, mais en exclure certaines applications.

gcloud

  1. Créez un fichier de liaison au format YAML avec une liste d'entrées de champ d'application dans la liste scopedAccessSettings. Pour chaque application que vous souhaitez mapper à un niveau d'accès spécifique, incluez une entrée 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

    Remplacez les éléments suivants :

    • CLIENT_ID : ID client OAuth. Vous pouvez utiliser clientId ou name lorsqu'une application contient sessionSettings.
    • ACCESS_LEVEL_A : nom d'un niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • SESSION_LENGTH : durée de la session au format heure, par exemple 15h pour 15 heures ou 2h pour deux heures.

    • SESSION_REAUTH_METHOD : méthode facultative pour demander aux utilisateurs de valider à nouveau leur identité. Il doit s'agir de l'une des valeurs suivantes :

      • LOGIN : appliquez la connexion standard, qui peut inclure l'authentification multifacteur (MFA) ou d'autres facteurs définis par Workspace.
      • PASSWORD : n'exigez qu'un mot de passe, même si d'autres facteurs sont définis. Si les mots de passe sont gérés à l'aide d'un IdP externe, les utilisateurs sont redirigés vers l'IdP. Si la session IdP est active, les utilisateurs sont implicitement réauthentifiés. Si le fournisseur d'identité n'est pas actif, les utilisateurs doivent se connecter via le fournisseur d'identité.
      • SECURITY_KEY : exiger une clé de sécurité matérielle.

    • CLIENT_NAME : nom du client. Vous pouvez utiliser name ou clientId lorsqu'une application contient sessionSettings.

    • ACCESS_LEVEL_B : nom d'un niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

    Pour définir un niveau d'accès par défaut pour les applications non définies dans le fichier YAML, utilisez l'argument --level. Le fichier YAML n'accepte que les paramètres spécifiques à l'application (scopedAccessSettings).

  2. Créez la liaison d'accès.

    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  ]

    Remplacez les éléments suivants :

    • ORG_ID : ID d'organisation.
    • GROUP_ID : ID du groupe. Si vous ne disposez pas de l'ID du groupe, vous pouvez le récupérer en appelant la méthode get sur la ressource du groupe.
    • BINDING_FILE_PATH : chemin d'accès au fichier YAML contenant le schéma de liaison d'accès. Le fichier de liaison n'accepte que scopedAccessSettings.
    • DEFAULT_ACCESS_LEVEL : nom facultatif du niveau d'accès, au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Remplacez POLICY_ID par l'ID de la règle d'accès et ACCESS_LEVEL_NAME par le nom du niveau d'accès.
    • DEFAULT_SESSION_LENGTH : durée de session facultative au format heure, par exemple 15h pour 15 heures ou 2h pour deux heures.
    • DEFAULT_SESSION_REAUTH_METHOD : méthode facultative permettant de demander aux utilisateurs de confirmer à nouveau leur identité, qui doit être l'une des suivantes :
      • LOGIN : appliquez la connexion standard, qui peut inclure MFA ou d'autres facteurs définis par Workspace.
      • PASSWORD : ne demander qu'un mot de passe, même si d'autres facteurs sont définis. Si les mots de passe sont gérés à l'aide d'un IdP externe, les utilisateurs sont redirigés vers l'IdP. Si la session IdP est active, les utilisateurs sont implicitement réauthentifiés. Si le fournisseur d'identité n'est pas actif, les utilisateurs doivent se connecter via le fournisseur d'identité.
      • SECURITY_KEY : exiger une clé de sécurité matérielle.

Fonctionnement combiné des arguments --level et --binding-file

  • Si vous n'utilisez que --binding-file, les règles ne sont appliquées qu'aux applications du fichier.
  • Si vous n'utilisez que --level, le niveau d'accès s'applique à toutes les applications.
  • Si vous utilisez les deux, les règles sont combinées. La valeur --level s'applique à toutes les applications, tandis que les règles du fichier YAML spécifié par --binding-file ne s'appliquent qu'aux applications définies dans le fichier.

Utiliser les commandes de session

  • Pour définir des contrôles de session par défaut pour toutes les applications, utilisez --session-length et --session-reauth-method.
  • Si vous définissez également des contrôles de session dans le fichier YAML, ils remplacent les paramètres par défaut de ces applications spécifiques.
  • Vous devez utiliser --session-length et --session-reauth-method ensemble.

API

Créez un corps 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"
          ]
        }
      }
    }
  ]
}

Remplacez les éléments suivants :

  • GROUP_ID : ID du groupe. Si vous ne disposez pas de l'ID du groupe, vous pouvez le récupérer en appelant la méthode get sur la ressource du groupe.
  • DEFAULT_ACCESS_LEVEL : nom facultatif du niveau d'accès, au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Remplacez POLICY_ID par l'ID de la règle d'accès et ACCESS_LEVEL_NAME par le nom du niveau d'accès.
  • CLIENT_ID : ID client OAuth. Vous pouvez utiliser clientId ou name lorsqu'une application contient sessionSettings.
  • ACCESS_LEVEL_A : nom d'un niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
  • SESSION_LENGTH : durée de la session au format heure, par exemple 2h pour deux heures.

  • SESSION_REAUTH_METHOD : méthode facultative pour demander aux utilisateurs de revalider leur identité. Il doit s'agir de l'une des valeurs suivantes :

    • LOGIN : appliquez la connexion standard, qui peut inclure MFA ou d'autres facteurs définis par Workspace.
    • PASSWORD : n'exigez qu'un mot de passe, même si d'autres facteurs sont définis. Si les mots de passe sont gérés à l'aide d'un IdP externe, les utilisateurs sont redirigés vers l'IdP. Si la session IdP est active, les utilisateurs sont implicitement réauthentifiés. Si l'IdP n'est pas actif, les utilisateurs doivent se connecter via l'IdP.
    • SECURITY_KEY : exiger une clé de sécurité matérielle.

  • CLIENT_NAME : nom du client. Vous pouvez utiliser name ou clientId lorsqu'une application contient sessionSettings.

  • ACCESS_LEVEL_B : nom d'un niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

Envoyez la requête POST :

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

ORG_ID est l'ID de l'organisation que vous avez utilisée pour créer le rôle Administrateur de liaison d'accès au cloud. Si la propriété access-context-manager/organization n'a pas été définie, remplacez ORG_ID dans l'option facultative --organization par l'ID de l'organisation que vous avez utilisé lors de la création du rôle d'administrateur des liaisons d'accès au cloud.

Si l'opération réussit, vous devriez recevoir une représentation de l'objet JSON ou un message d'erreur en cas de problème.

Utiliser des niveaux d'accès dry run pour simuler l'application

Les niveaux d'accès dry run vous permettent de tester vos règles d'accès sans les appliquer réellement. Cela vous aide à comprendre l'impact d'une stratégie avant sa mise en ligne. Vous pouvez consulter les journaux de dry run pour voir ce qui se serait passé si la règle avait été active.

Seuls les niveaux d'accès peuvent être utilisés en mode dry run. Les contrôles de session ne sont pas disponibles en mode dry run.

Créer une règle de dry run globale

Cette méthode applique le même niveau d'accès dry run à toutes les applications auxquelles un groupe d'utilisateurs accède.

gcloud

Créez la liaison d'accès avec l'option --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>

Remplacez les éléments suivants :

  • GROUP_ID : ID du groupe. Si vous ne disposez pas de l'ID du groupe, vous pouvez le récupérer en appelant la méthode get sur la ressource du groupe.
  • ORG_ID : ID d'organisation.
  • DEFAULT_DRY_RUN_ACCESS_LEVEL : nom du niveau d'accès dry run au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

API

  1. Créez un corps JSON contenant dry_run_access_levels.

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

    Remplacez les éléments suivants :

    • GROUP_ID : ID du groupe. Si vous ne disposez pas de l'ID du groupe, vous pouvez le récupérer en appelant la méthode get sur la ressource du groupe.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL : nom du niveau d'accès dry run au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Envoyez la requête POST :

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

    ORG_ID est l'ID de l'organisation que vous avez utilisé pour créer le rôle Administrateur de liaison d'accès au cloud. Si la propriété access-context-manager/organization n'a pas été définie, remplacez ORG_ID dans l'option facultative --organization par l'ID de l'organisation que vous avez utilisé lors de la création du rôle d'administrateur des liaisons d'accès au cloud.

Créer une règle de dry run pour des applications spécifiques

Cette méthode vous permet d'appliquer différents niveaux d'accès dry run à différentes applications. Vous pouvez également définir des règles par défaut pour les applications sans configuration spécifique.

gcloud

  1. Configurez les paramètres d'accès dans un fichier de liaison YAML à l'aide du champ 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

    Remplacez les éléments suivants :

    • CLIENT_NAME : nom du client. Vous pouvez utiliser name ou clientId lorsqu'une application contient sessionSettings.
    • ACCESS_LEVEL_A : nom d'un niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • DRY_RUN_ACCESS_LEVEL_1 : nom d'un niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_ID : ID client OAuth. Vous pouvez utiliser clientId ou name lorsqu'une application contient sessionSettings.
    • DRY_RUN_ACCESS_LEVEL_2 : nom d'un niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Créez la liaison d'accès.

    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

    Remplacez les éléments suivants :

    • ORG_ID : ID d'organisation.
    • GROUP_ID : ID du groupe. Si vous ne disposez pas de l'ID du groupe, vous pouvez le récupérer en appelant la méthode get sur la ressource du groupe.
    • BINDING_FILE_PATH : chemin d'accès au fichier YAML contenant le schéma de liaison d'accès. Le fichier de liaison n'accepte que scopedAccessSettings.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL : nom facultatif du niveau d'accès dry run au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

    Incluez cette option pour appliquer par défaut le niveau d'accès dry run spécifié à toutes les applications si elles ne sont pas spécifiées dans le fichier YAML.

API

  1. Créez un corps 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"
        ]
      }
    }
  ]
}

    Remplacez les éléments suivants :

    • GROUP_ID : ID du groupe. Si vous ne disposez pas de l'ID du groupe, vous pouvez le récupérer en appelant la méthode get sur la ressource du groupe.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL : nom facultatif du niveau d'accès dry run au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_NAME : nom du client. Vous pouvez utiliser name ou clientId lorsqu'une application contient sessionSettings.
    • ACCESS_LEVEL_A : nom d'un niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • DRY_RUN_ACCESS_LEVEL_1 : nom d'un niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_ID : ID client OAuth. Vous pouvez utiliser client_id ou name lorsqu'une application contient sessionSettings.
    • DRY_RUN_ACCESS_LEVEL_2 : nom d'un niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Envoyez la requête POST :

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

    ORG_ID est l'ID de l'organisation que vous avez utilisé pour créer le rôle Administrateur de liaison d'accès au cloud. Si la propriété access-context-manager/organization n'a pas été définie, remplacez ORG_ID dans l'option facultative --organization par l'ID de l'organisation que vous avez utilisé lors de la création du rôle d'administrateur des liaisons d'accès au cloud.

    Si l'opération réussit, vous recevez une représentation de l'objet JSON. En cas de problème, vous recevez un message d'erreur.

Afficher les journaux du dry run

Après avoir configuré un dry run, vous pouvez consulter les journaux pour voir quelles tentatives d'accès auraient été refusées.

Le tableau suivant liste les champs de journal que vous pouvez utiliser pour créer et exécuter la requête afin d'obtenir les journaux :

Nom du champ Description
protoPayload.authenticationInfo.principalEmail ID de messagerie du compte principal pour lequel l'accès est refusé.
protoPayload.metadata.deniedApplications Nom de l'application pour laquelle l'accès est refusé.
protoPayload.metadata.evaluationResult Résultat de l'évaluation de la stratégie d'accès active. Valeurs possibles : GRANTED ou DENIED. Si aucun niveau d'accès actif n'est appliqué dans la liaison, ce champ est défini sur GRANTED.
protoPayload.metadata.appliedAccessLevels Niveaux d'accès appliqués requis par la règle d'accès active.
protoPayload.metadata.appliedDryRunAccessLevels Niveaux d'accès appliqués requis par la stratégie d'accès dry run.
protoPayload.metadata.dryRunEvaluationResult Résultat de l'évaluation de la stratégie d'accès dry run, qui indique l'action prévue lorsque la stratégie d'accès est appliquée. Valeurs possibles : GRANTED ou DENIED. Si aucun niveau d'accès dry run n'est appliqué dans la liaison, ce champ est défini sur GRANTED, même si evaluationResult est défini sur DENIED.
protoPayload.metadata.unsatisfiedAccessLevels Niveaux d'accès de l'organisation que la requête n'a pas pu satisfaire. Cette liste peut inclure des niveaux d'accès qui ne sont pas appliqués dans la liaison d'accès. Pour identifier les niveaux d'accès à l'origine d'un refus d'accès, comparez ce champ à appliedAccessLevels ou appliedDryRunAccessLevels.

Pour savoir comment créer une requête pour les journaux, consultez Langage de requête Logging.