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 des sessions à toutes les applications, ou définir des comportements spécifiques pour des applications individuelles.

Pour vous assurer que vous avez tout configuré correctement, vous pouvez tester 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, l'accès lui est accordé si une stratégie l'autorise (OR, pas AND).
  • Pour les commandes de session, seule la liaison d'accès créée la plus récemment 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 un essai 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 l'ID de groupe n'est pas disponible, vous pouvez le récupérer en appelant la méthode get sur la ressource de groupe.
  • ORG_ID: ID de votre organisation.
  • DEFAULT_ACCESS_LEVEL: nom facultatif du niveau d'accès, qui prend la forme 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 ISO 8601, par exemple 30m pour 30 minutes ou 2h pour deux heures.
  • DEFAULT_SESSION_REAUTH_METHOD: méthode facultative pour demander aux utilisateurs de valider à nouveau leur identité. Elle doit être l'une des 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 fournisseur d'identité externe, les utilisateurs sont redirigés vers celui-ci. Si la session de l'IdP est active, les utilisateurs sont réauthentifiés implicitement. Si le fournisseur d'identité n'est pas actif, les utilisateurs doivent se connecter via celui-ci.
    • SECURITY_KEY: exigez 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 l'ID de groupe n'est pas disponible, vous pouvez le récupérer en appelant la méthode get sur la ressource de groupe.
    • DEFAULT_ACCESS_LEVEL: nom facultatif du niveau d'accès, qui prend la forme 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 ISO 8601, par exemple 30m pour 30 minutes ou 2h pour deux heures.
    • DEFAULT_SESSION_REAUTH_METHOD: méthode facultative pour demander aux utilisateurs de valider à nouveau leur identité. Elle doit être l'une des 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 fournisseur d'identité externe, les utilisateurs sont redirigés vers celui-ci. Si la session de l'IdP est active, les utilisateurs sont réauthentifiés implicitement. Si le fournisseur d'identité n'est pas actif, les utilisateurs doivent se connecter via celui-ci.
      • SECURITY_KEY: exigez 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 : ID de l'organisation que vous avez utilisée pour créer le rôle Administrateur de liaison d'accès 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 Administrateur de la liaison d'accès Cloud.

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

Définir des configurations pour des applications spécifiques

Cette méthode vous permet d'appliquer différents niveaux d'accès et de contrôle des sessions à différentes applications. Vous pouvez également définir des règles par défaut pour les applications qui ne disposent pas de configurations spécifiques. Cette méthode est utile lorsque vous souhaitez effectuer les opérations suivantes:

  • Appliquer des règles à certaines applications uniquement

  • Créez une règle générale, mais excluez-en certaines applications.

gcloud

  1. Créez un fichier de liaison au format YAML avec une liste d'entrées de portée 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:
        #
        # because this app is specified by `name`,
        # it won't work with sessionSettings.
        #
        # if you add sessionSettings, make sure to
        # replace the `name` key with `clientId`,
        # and use the OAuth client ID as the value.
        #
        name: CLIENT_NAME
  activeSettings:
    accessLevels:
    - ACCESS_LEVEL_B

    Remplacez les éléments suivants :

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

    • SESSION_REAUTH_METHOD: méthode facultative pour demander aux utilisateurs de valider à nouveau leur identité. Elle doit être l'une des 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 de l'IdP est active, les utilisateurs sont réauthentifiés de manière implicite. Si l'IdP n'est pas actif, les utilisateurs doivent se connecter via l'IdP.
      • SECURITY_KEY: exigez une clé de sécurité matérielle.

    • CLIENT_NAME: nom du client. Si l'application contient sessionSettings, vous ne pouvez pas utiliser le nom du client. Utilisez plutôt l'ID client OAuth.

    • ACCESS_LEVEL_B: nom de 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'est compatible qu'avec 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 de votre organisation.
    • GROUP_ID: ID du groupe. Si l'ID de groupe n'est pas disponible, vous pouvez le récupérer en appelant la méthode get sur la ressource de 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'est compatible qu'avec scopedAccessSettings.
    • DEFAULT_ACCESS_LEVEL: nom facultatif du niveau d'accès, qui prend la forme 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 ISO 8601, par exemple 30m pour 30 minutes ou 2h pour deux heures.
    • DEFAULT_SESSION_REAUTH_METHOD: méthode facultative pour demander aux utilisateurs de valider à nouveau leur identité. Elle doit être l'une des 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 fournisseur d'identité externe, les utilisateurs sont redirigés vers celui-ci. Si la session de l'IdP est active, les utilisateurs sont réauthentifiés implicitement. Si le fournisseur d'identité n'est pas actif, les utilisateurs doivent se connecter via celui-ci.
      • SECURITY_KEY: exigez une clé de sécurité matérielle.

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

  • Si vous n'utilisez que --binding-file, seules les applications du fichier voient les règles appliquées.
  • Si vous n'utilisez que --level, le niveau d'accès s'applique à toutes les applications.
  • Si vous utilisez les deux, les règles du fichier YAML ont la priorité. La valeur --level s'applique à toutes les applications qui ne sont pas listées dans le fichier.

Utiliser les commandes de session

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

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 l'ID de groupe n'est pas disponible, vous pouvez le récupérer en appelant la méthode get sur la ressource de groupe.
  • DEFAULT_ACCESS_LEVEL: nom facultatif du niveau d'accès, qui prend la forme 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 devez utiliser clientId lorsqu'une application contient sessionSettings.
  • ACCESS_LEVEL_A: nom de niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
  • SESSION_LENGTH: durée de la session au format ISO 8601, par exemple 30m pour 30 minutes ou 2h pour deux heures.

  • SESSION_REAUTH_METHOD: méthode facultative pour demander aux utilisateurs de valider de nouveau leur identité. Elle doit être l'une des 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 de l'IdP est active, les utilisateurs sont réauthentifiés de manière implicite. Si l'IdP n'est pas actif, les utilisateurs doivent se connecter via l'IdP.
    • SECURITY_KEY: exigez une clé de sécurité matérielle.

  • CLIENT_NAME: nom du client. Si l'application contient sessionSettings, vous ne pouvez pas utiliser le nom du client. Utilisez plutôt l'ID client OAuth.

  • ACCESS_LEVEL_B: nom de 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 correspond à l'ID de l'organisation que vous avez utilisée pour créer le rôle Administrateur de liaison d'accès 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 Administrateur de la liaison d'accès 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 en simulation pour simuler l'application

Les niveaux d'accès en simulation 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 simulation pour voir ce qui se serait passé si la règle était active.

Seuls les niveaux d'accès peuvent être utilisés en mode de simulation. Les commandes de session ne sont pas disponibles en mode de simulation.

Créer une liaison de simulation

Vous pouvez définir des niveaux d'accès de simulation en plus des niveaux d'accès normaux dans la même liaison, ou vous pouvez utiliser des liaisons distinctes pour les simulations.

gcloud

  1. Configurez les paramètres d'accès.

    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. Si l'application contient sessionSettings, vous ne pouvez pas utiliser le nom du client. Utilisez plutôt l'ID client OAuth.
    • ACCESS_LEVEL_A: nom de niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • DRY_RUN_ACCESS_LEVEL_1: nom de niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_ID: ID client OAuth. Vous devez utiliser clientId lorsqu'une application contient sessionSettings.
    • DRY_RUN_ACCESS_LEVEL_2: nom de 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 de votre organisation.
    • GROUP_ID: ID du groupe. Si l'ID de groupe n'est pas disponible, vous pouvez le récupérer en appelant la méthode get sur la ressource de 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'est compatible qu'avec scopedAccessSettings.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL_2: nom facultatif du niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

    Incluez cet indicateur pour appliquer le niveau d'accès de simulation spécifié à toutes les applications par défaut s'ils ne sont pas spécifiés 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 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
   // be applied by default.
   //
  "access_levels": [
    "DEFAULT_ACCESS_LEVEL"
  ],
   //
   // 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"
          }
        }
      },
      "active_settings": {
        "access_levels": [
          "DRY_RUN_ACCESS_LEVEL_2"
        ]
      }
    }
  ]
}

    Remplacez les éléments suivants :

    • GROUP_ID: ID du groupe. Si l'ID de groupe n'est pas disponible, vous pouvez le récupérer en appelant la méthode get sur la ressource de groupe.
    • DEFAULT_ACCESS_LEVEL: nom facultatif du niveau d'accès, qui prend la forme 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_DRY_RUN_ACCESS_LEVEL: nom facultatif du niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_NAME: nom du client. Si l'application contient sessionSettings, vous ne pouvez pas utiliser le nom du client. Utilisez plutôt l'ID client OAuth.
    • ACCESS_LEVEL_A: nom de niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • DRY_RUN_ACCESS_LEVEL_1: nom de niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_ID: ID client OAuth. Vous devez utiliser client_id lorsqu'une application contient sessionSettings.
    • DRY_RUN_ACCESS_LEVEL_2: nom de niveau d'accès au format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Envoyez la requête POST:

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

    ORG_ID : ID de l'organisation que vous avez utilisée pour créer le rôle Administrateur de liaison d'accès 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 Administrateur de la liaison d'accès Cloud.

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

Afficher les journaux de simulation

Une fois que vous avez configuré un exercice fictif, vous pouvez consulter les journaux pour voir quelles tentatives d'accès auraient été refusées.

Le tableau suivant répertorie les champs de journal que vous pouvez utiliser pour créer et exécuter la requête permettant 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.
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 règle d'accès en simulation.
protoPayload.metadata.dryRunEvaluationResult Résultat de l'évaluation de la stratégie d'accès en simulation, qui indique l'action prévue lorsque la stratégie d'accès est appliquée. Valeurs possibles : GRANTED ou DENIED.

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