Richtlinien mithilfe von Zugriffsbindungen auf Nutzergruppen anwenden

Mit Zugriffsberechtigungen können Sie steuern, auf welche Anwendungen und Ressourcen Ihre Nutzergruppen zugreifen können. Eine Zugriffsbindung gibt an, wie Zugriffsebenen und Sitzungseinstellungen auf eine Nutzergruppe angewendet werden. Sie können dieselbe Zugriffsebene und Sitzungssteuerung auf alle Anwendungen anwenden oder spezifische Verhaltensweisen für einzelne Anwendungen definieren.

Testen Sie Ihre Richtlinien, bevor Sie sie erzwingen, um sicherzustellen, dass alles richtig konfiguriert ist.

Beachten Sie bei der Arbeit mit Zugriffsberechtigungen das folgende Verhalten:

  • Eine Nutzergruppe kann nur eine Zugriffsbildung haben.
  • Wenn ein Nutzer mehreren Gruppen angehört, wird ihm Zugriff gewährt, wenn eine Richtlinie dies zulässt (OR, nicht AND).
  • Für Sitzungseinstellungen gilt nur die zuletzt erstellte Zugriffsberechtigungsbindung.

Eine einzige Konfiguration für alle Anwendungen verwenden

Bei dieser Methode werden dieselbe Zugriffsebene und Sitzungssteuerung auf alle Anwendungen angewendet, auf die eine Nutzergruppe zugreift.

Wir empfehlen, die Richtlinie mit einem Probelauf zu testen oder auf eine kleine Testgruppe anzuwenden, bevor Sie sie in der Produktion implementieren.

gcloud

Erstellen Sie die Zugriffsberechtigungen.

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  ]

Ersetzen Sie Folgendes:

  • GROUP_ID: Die Gruppen-ID. Wenn Sie die Gruppen-ID nicht haben, können Sie sie abrufen, indem Sie die Methode get für die Gruppenressource aufrufen.
  • ORG_ID: Ihre Organisations-ID.
  • DEFAULT_ACCESS_LEVEL: Der optionale Name der Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Ersetzen Sie POLICY_ID durch die ID der Zugriffsrichtlinie und ACCESS_LEVEL_NAME durch den Namen der Zugriffsebene.
  • DEFAULT_SESSION_LENGTH: Die optionale Sitzungsdauer im Stundenformat, z. B. 15h für 15 Stunden oder 2h für zwei Stunden.
  • DEFAULT_SESSION_REAUTH_METHOD: Die optionale Methode, um Nutzer aufzufordern, ihre Identität noch einmal zu bestätigen. Dies muss eine der folgenden Optionen sein:
    • LOGIN: Die Standardanmeldung wird angewendet. Diese kann die Multi-Faktor-Authentifizierung oder andere in Workspace definierte Faktoren umfassen.
    • PASSWORD: Nur ein Passwort erforderlich, auch wenn andere Faktoren definiert sind. Wenn Passwörter über einen externen IdP verwaltet werden, werden Nutzer zum IdP weitergeleitet. Wenn die IdP-Sitzung aktiv ist, werden Nutzer implizit noch einmal authentifiziert. Wenn der IdP nicht live ist, müssen sich Nutzer über den IdP anmelden.
    • SECURITY_KEY: Hardware-Sicherheitsschlüssel erforderlich.

API

  1. Erstellen Sie einen JSON-Text:

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

    Ersetzen Sie Folgendes:

    • GROUP_ID: Die Gruppen-ID. Wenn Sie die Gruppen-ID nicht haben, können Sie sie abrufen, indem Sie die Methode get für die Gruppenressource aufrufen.
    • DEFAULT_ACCESS_LEVEL: Der optionale Name der Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Ersetzen Sie POLICY_ID durch die ID der Zugriffsrichtlinie und ACCESS_LEVEL_NAME durch den Namen der Zugriffsebene.
    • DEFAULT_SESSION_LENGTH: Die optionale Sitzungsdauer im Stundenformat, z. B. 15h für 15 Stunden oder 2h für zwei Stunden.
    • DEFAULT_SESSION_REAUTH_METHOD: Die optionale Methode, um Nutzer aufzufordern, ihre Identität noch einmal zu bestätigen. Dies muss eine der folgenden Optionen sein:
      • LOGIN: Die Standardanmeldung wird angewendet. Diese kann die Multi-Faktor-Authentifizierung oder andere in Workspace definierte Faktoren umfassen.
      • PASSWORD: Nur ein Passwort erforderlich, auch wenn andere Faktoren definiert sind. Wenn Passwörter über einen externen IdP verwaltet werden, werden Nutzer zum IdP weitergeleitet. Wenn die IdP-Sitzung aktiv ist, werden Nutzer implizit noch einmal authentifiziert. Wenn der IdP nicht live ist, müssen sich Nutzer über den IdP anmelden.
      • SECURITY_KEY: Hardware-Sicherheitsschlüssel erforderlich.

  2. Senden Sie die POST-Anfrage:

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

    ORG_ID ist die ID der Organisation, die Sie zum Erstellen der Rolle Cloud Access Binding Admin verwendet haben. Wenn das Attribut access-context-manager/organization nicht festgelegt wurde, ersetzen Sie ORG_ID im optionalen Flag --organization durch die ID der Organisation, die Sie beim Erstellen der Rolle „Cloud Access Binding Admin“ verwendet haben.

Bei erfolgreicher Ausführung erhalten Sie eine Darstellung des JSON-Objekts. Wenn ein Problem auftritt, erhalten Sie eine Fehlermeldung.

Konfigurationen für bestimmte Anwendungen definieren

Mit dieser Methode können Sie verschiedene Zugriffsebenen und Sitzungssteuerungen auf verschiedene Anwendungen anwenden. Sie können auch Standardregeln für Anwendungen festlegen, die keine spezifischen Konfigurationen haben.

Sie können Anwendungen in Zugriffsberechtigungen mithilfe ihrer OAuth-Client-ID angeben. Sie können die folgenden Anwendungen mit ihrem Namen angeben:

Diese Methode ist in folgenden Fällen nützlich:

  • Richtlinien nur auf bestimmte Anwendungen anwenden.

  • Erstellen Sie eine allgemeine Richtlinie, schließen Sie jedoch einige Anwendungen davon aus.

gcloud

  1. Erstellen Sie eine Bindungsdatei im YAML-Format mit einer Liste von Bereichseinträgen in der Liste scopedAccessSettings. Fügen Sie für jede Anwendung, die Sie einer bestimmten Zugriffsebene zuordnen möchten, einen clientScope-Eintrag hinzu.

    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

    Ersetzen Sie Folgendes:

    • CLIENT_ID: Die OAuth-Client-ID. Sie können entweder clientId oder name verwenden, wenn eine Anwendung sessionSettings enthält.
    • ACCESS_LEVEL_A: Ein Name für die Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • SESSION_LENGTH: Die Sitzungsdauer im Stundenformat, z. B. 15h für 15 Stunden oder 2h für zwei Stunden.

    • SESSION_REAUTH_METHOD: Die optionale Methode, mit der Nutzer aufgefordert werden, ihre Identität noch einmal zu bestätigen. Dies muss eine der folgenden Methoden sein:

      • LOGIN: Die Standardanmeldung wird angewendet. Diese kann die Multi-Faktor-Authentifizierung (MFA) oder andere in Workspace definierte Faktoren umfassen.
      • PASSWORD: Es ist nur ein Passwort erforderlich, auch wenn andere Faktoren definiert sind. Wenn Passwörter über einen externen IdP verwaltet werden, werden Nutzer zum IdP weitergeleitet. Wenn die IdP-Sitzung aktiv ist, werden Nutzer implizit noch einmal authentifiziert. Wenn der IdP nicht live ist, müssen sich Nutzer über den IdP anmelden.
      • SECURITY_KEY: Hardware-Sicherheitsschlüssel erforderlich.

    • CLIENT_NAME: Der Clientname. Sie können entweder name oder clientId verwenden, wenn eine Anwendung sessionSettings enthält.

    • ACCESS_LEVEL_B: Ein Name für die Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

    Wenn Sie eine Standardzugriffsebene für Anwendungen festlegen möchten, die nicht in der YAML-Datei definiert sind, verwenden Sie das Argument --level. Die YAML-Datei unterstützt nur anwendungsspezifische Einstellungen (scopedAccessSettings).

  2. Erstellen Sie die Zugriffsberechtigungen.

    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  ]

    Ersetzen Sie Folgendes:

    • ORG_ID: Ihre Organisations-ID.
    • GROUP_ID: Die Gruppen-ID. Wenn Sie die Gruppen-ID nicht haben, können Sie sie abrufen, indem Sie die Methode get für die Gruppenressource aufrufen.
    • BINDING_FILE_PATH: Der Pfad zur YAML-Datei, die das Zugriffsbinder-Schema enthält. Die Bindungsdatei unterstützt nur scopedAccessSettings.
    • DEFAULT_ACCESS_LEVEL: Der optionale Name der Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Ersetzen Sie POLICY_ID durch die ID der Zugriffsrichtlinie und ACCESS_LEVEL_NAME durch den Namen der Zugriffsebene.
    • DEFAULT_SESSION_LENGTH: Die optionale Sitzungsdauer im Stundenformat, z. B. 15h für 15 Stunden oder 2h für zwei Stunden.
    • DEFAULT_SESSION_REAUTH_METHOD: Die optionale Methode, um Nutzer aufzufordern, ihre Identität noch einmal zu bestätigen. Dies muss eine der folgenden Optionen sein:
      • LOGIN: Die Standardanmeldung wird angewendet. Diese kann die Multi-Faktor-Authentifizierung oder andere in Workspace definierte Faktoren umfassen.
      • PASSWORD: Nur ein Passwort erforderlich, auch wenn andere Faktoren definiert sind. Wenn Passwörter über einen externen IdP verwaltet werden, werden Nutzer zum IdP weitergeleitet. Wenn die IdP-Sitzung aktiv ist, werden Nutzer implizit noch einmal authentifiziert. Wenn der IdP nicht live ist, müssen sich Nutzer über den IdP anmelden.
      • SECURITY_KEY: Hardware-Sicherheitsschlüssel erforderlich.

Zusammenwirken der Argumente --level und --binding-file

  • Wenn Sie nur --binding-file verwenden, werden die Richtlinien nur auf die Anwendungen in der Datei angewendet.
  • Wenn Sie nur --level verwenden, gilt die Zugriffsebene für alle Anwendungen.
  • Wenn Sie beide verwenden, werden die Regeln kombiniert. Der Wert --level gilt für alle Anwendungen, während die Richtlinien in der durch --binding-file angegebenen YAML-Datei nur für die in der Datei definierten Anwendungen gelten.

Mit Sitzungseinstellungen arbeiten

  • Wenn Sie Standardeinstellungen für die Sitzungssteuerung für alle Anwendungen festlegen möchten, verwenden Sie --session-length und --session-reauth-method.
  • Wenn Sie in der YAML-Datei auch Sitzungseinstellungen definieren, überschreiben diese die Standardeinstellungen für die entsprechenden Anwendungen.
  • Sie müssen sowohl --session-length als auch --session-reauth-method verwenden.

API

Erstellen Sie einen JSON-Text:

{
  "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"
          ]
        }
      }
    }
  ]
}

Ersetzen Sie Folgendes:

  • GROUP_ID: Die Gruppen-ID. Wenn Sie die Gruppen-ID nicht haben, können Sie sie abrufen, indem Sie die Methode get für die Gruppenressource aufrufen.
  • DEFAULT_ACCESS_LEVEL: Der optionale Name der Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Ersetzen Sie POLICY_ID durch die ID der Zugriffsrichtlinie und ACCESS_LEVEL_NAME durch den Namen der Zugriffsebene.
  • CLIENT_ID: Die OAuth-Client-ID. Sie können entweder clientId oder name verwenden, wenn eine Anwendung sessionSettings enthält.
  • ACCESS_LEVEL_A: Ein Name für die Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
  • SESSION_LENGTH: Die Sitzungsdauer im Stundenformat, z. B. 2h für zwei Stunden.

  • SESSION_REAUTH_METHOD: Die optionale Methode, mit der Nutzer aufgefordert werden, ihre Identität noch einmal zu bestätigen. Dies muss eine der folgenden Methoden sein:

    • LOGIN: Die Standardanmeldung wird angewendet. Diese kann die Multi-Faktor-Authentifizierung oder andere in Workspace definierte Faktoren umfassen.
    • PASSWORD: Es ist nur ein Passwort erforderlich, auch wenn andere Faktoren definiert sind. Wenn Passwörter über einen externen IdP verwaltet werden, werden Nutzer zum IdP weitergeleitet. Wenn die IdP-Sitzung aktiv ist, werden Nutzer implizit noch einmal authentifiziert. Wenn der IdP nicht live ist, müssen sich Nutzer über den IdP anmelden.
    • SECURITY_KEY: Hardware-Sicherheitsschlüssel erforderlich.

  • CLIENT_NAME: Der Clientname. Sie können entweder name oder clientId verwenden, wenn eine Anwendung sessionSettings enthält.

  • ACCESS_LEVEL_B: Ein Name für die Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

Senden Sie die POST-Anfrage:

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

ORG_ID ist die ID der Organisation, die Sie zum Erstellen der Rolle Cloud Access Binding Admin verwendet haben. Wenn das Attribut access-context-manager/organization nicht festgelegt wurde, ersetzen Sie ORG_ID im optionalen Flag --organization durch die ID der Organisation, die Sie beim Erstellen der Rolle „Cloud Access Binding Admin“ verwendet haben.

Wenn der Vorgang erfolgreich ist, sollten Sie eine Darstellung des JSON-Objekts erhalten. Wenn ein Problem aufgetreten ist, erhalten Sie eine Fehlermeldung.

Zugriffsebenen für Probelauf verwenden, um die Erzwingung zu simulieren

Mit Zugriffsebenen für Probeläufe können Sie Ihre Zugriffsrichtlinien testen, ohne sie tatsächlich zu erzwingen. So können Sie die Auswirkungen einer Richtlinie nachvollziehen, bevor sie live geht. Sie können sich die Probelauf-Logs ansehen, um zu sehen, was passiert wäre, wenn die Richtlinie aktiv gewesen wäre.

Im Probelaufmodus können nur Zugriffsebenen verwendet werden. Sitzungssteuerungen sind im Probelaufmodus nicht verfügbar.

Allgemeine Probelaufrichtlinie erstellen

Bei dieser Methode wird dieselbe Zugriffsebene für den Probelauf auf alle Anwendungen angewendet, auf die eine Nutzergruppe zugreift.

gcloud

Erstellen Sie die Zugriffsbindung mit dem 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>

Ersetzen Sie Folgendes:

  • GROUP_ID: Die Gruppen-ID. Wenn Sie die Gruppen-ID nicht haben, können Sie sie abrufen, indem Sie die Methode get für die Gruppenressource aufrufen.
  • ORG_ID: Ihre Organisations-ID.
  • DEFAULT_DRY_RUN_ACCESS_LEVEL: Der Name der Zugriffsebene für den Probelauf im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

API

  1. Erstellen Sie einen JSON-Text, der dry_run_access_levels enthält.

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

    Ersetzen Sie Folgendes:

    • GROUP_ID: Die Gruppen-ID. Wenn Sie die Gruppen-ID nicht haben, können Sie sie abrufen, indem Sie die Methode get für die Gruppenressource aufrufen.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL: Der Name der Zugriffsebene für den Probelauf im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Senden Sie die POST-Anfrage:

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

    ORG_ID ist die ID der Organisation, die Sie zum Erstellen der Rolle Cloud Access Binding Admin verwendet haben. Wenn das Attribut access-context-manager/organization nicht festgelegt wurde, ersetzen Sie ORG_ID im optionalen Flag --organization durch die ID der Organisation, die Sie beim Erstellen der Rolle „Cloud Access Binding Admin“ verwendet haben.

Probelaufrichtlinie für bestimmte Anwendungen erstellen

Mit dieser Methode können Sie verschiedene Probelauf-Zugriffsebenen auf verschiedene Anwendungen anwenden. Sie können auch Standardregeln für Anwendungen ohne spezifische Konfiguration festlegen.

gcloud

  1. Konfigurieren Sie die Zugriffseinstellungen in einer YAML-Bindungsdatei mit dem Feld 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

    Ersetzen Sie Folgendes:

    • CLIENT_NAME: Der Clientname. Sie können entweder name oder clientId verwenden, wenn eine Anwendung sessionSettings enthält.
    • ACCESS_LEVEL_A: Ein Name für die Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • DRY_RUN_ACCESS_LEVEL_1: Ein Name für die Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_ID: Die OAuth-Client-ID. Sie können entweder clientId oder name verwenden, wenn eine Anwendung sessionSettings enthält.
    • DRY_RUN_ACCESS_LEVEL_2: Ein Name für die Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Erstellen Sie die Zugriffsberechtigungen.

    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

    Ersetzen Sie Folgendes:

    • ORG_ID: Ihre Organisations-ID.
    • GROUP_ID: Die Gruppen-ID. Wenn Sie die Gruppen-ID nicht haben, können Sie sie abrufen, indem Sie die Methode get für die Gruppenressource aufrufen.
    • BINDING_FILE_PATH: Der Pfad zur YAML-Datei, die das Zugriffsbinder-Schema enthält. Die Bindungsdatei unterstützt nur scopedAccessSettings.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL: Ein optionaler Name für die Zugriffsebene im Probelauf im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

    Fügen Sie dieses Flag hinzu, um die angegebene Probelauf-Zugriffsebene standardmäßig auf alle Anwendungen anzuwenden, wenn sie nicht in der YAML-Datei angegeben sind.

API

  1. Erstellen Sie einen JSON-Text:

    {
  "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"
        ]
      }
    }
  ]
}

    Ersetzen Sie Folgendes:

    • GROUP_ID: Die Gruppen-ID. Wenn Sie die Gruppen-ID nicht haben, können Sie sie abrufen, indem Sie die Methode get für die Gruppenressource aufrufen.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL: Ein optionaler Name für die Zugriffsebene im Probelauf im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_NAME: Der Clientname. Sie können entweder name oder clientId verwenden, wenn eine Anwendung sessionSettings enthält.
    • ACCESS_LEVEL_A: Ein Name für die Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • DRY_RUN_ACCESS_LEVEL_1: Ein Name für die Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_ID: Die OAuth-Client-ID. Sie können entweder client_id oder name verwenden, wenn eine Anwendung sessionSettings enthält.
    • DRY_RUN_ACCESS_LEVEL_2: Ein Name für die Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Senden Sie die POST-Anfrage:

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

    ORG_ID ist die ID der Organisation, die Sie zum Erstellen der Rolle Cloud Access Binding Admin verwendet haben. Wenn das Attribut access-context-manager/organization nicht festgelegt wurde, ersetzen Sie ORG_ID im optionalen Flag --organization durch die ID der Organisation, die Sie beim Erstellen der Rolle „Cloud Access Binding Admin“ verwendet haben.

    Bei erfolgreicher Ausführung erhalten Sie eine Darstellung des JSON-Objekts. Wenn ein Problem auftritt, erhalten Sie eine Fehlermeldung.

Probelauflogs ansehen

Nachdem Sie einen Probelauf eingerichtet haben, können Sie in den Logs nachsehen, welche Zugriffsversuche verweigert worden wären.

In der folgenden Tabelle sind die Logfelder aufgeführt, mit denen Sie die Abfrage zum Abrufen der Logs erstellen und ausführen können:

Feldname Beschreibung
protoPayload.authenticationInfo.principalEmail E‑Mail-ID des Hauptkontos, für das der Zugriff verweigert wird.
protoPayload.metadata.deniedApplications Name der Anwendung, für die der Zugriff verweigert wird.
protoPayload.metadata.evaluationResult Das Bewertungsergebnis der aktiven Zugriffsrichtlinie. Mögliche Werte: GRANTED oder DENIED. Wenn in der Bindung keine aktiven Zugriffsebenen angewendet werden, wird dieses Feld auf GRANTED gesetzt.
protoPayload.metadata.appliedAccessLevels Die angewendeten Zugriffsebenen, die für die aktive Zugriffsrichtlinie erforderlich sind.
protoPayload.metadata.appliedDryRunAccessLevels Die angewendeten Zugriffsebenen, die für die Zugriffsrichtlinie für Probeläufe erforderlich sind.
protoPayload.metadata.dryRunEvaluationResult Das Bewertungsergebnis der Zugriffsrichtlinie für den Probelauf, das die beabsichtigte Aktion angibt, wenn die Zugriffsrichtlinie erzwungen wird. Mögliche Werte: GRANTED oder DENIED. Wenn in der Bindung keine Zugriffsebenen für den Probelauf angewendet werden, wird dieses Feld auf GRANTED gesetzt, auch wenn evaluationResult den Wert DENIED hat.
protoPayload.metadata.unsatisfiedAccessLevels Die Zugriffsebenen in der Organisation, die die Anfrage nicht erfüllt hat. Diese Liste kann Zugriffsebenen enthalten, die nicht in der Zugriffsberechtigungsbindung angewendet werden. Um festzustellen, welche Zugriffsebenen eine Zugriffsverweigerung verursacht haben, vergleichen Sie dieses Feld mit appliedAccessLevels oder appliedDryRunAccessLevels.

Eine Anleitung zum Erstellen einer Abfrage für Logs finden Sie unter Logging-Abfragesprache.