Richtlinien mithilfe von Zugriffsbindungen auf Nutzergruppen anwenden

Mit Zugriffsbindungen können Sie steuern, auf welche Anwendungen und Ressourcen Ihre Nutzergruppen zugreifen können. Mit einer Zugriffsbindung wird festgelegt, wie Zugriffsebenen und Sitzungssteuerungen auf eine Nutzergruppe angewendet werden. Sie können dieselbe Zugriffsebene und Sitzungssteuerung auf alle Anwendungen anwenden oder bestimmte Verhaltensweisen für einzelne Anwendungen definieren.

Sie können Ihre Richtlinien testen, bevor Sie sie erzwingen, um sicherzustellen, dass alles richtig konfiguriert ist.

Beachten Sie bei der Arbeit mit Zugriffsbindungen Folgendes:

  • Eine Nutzergruppe kann nur eine Zugriffsbindung haben.
  • Wenn ein Nutzer mehreren Gruppen angehört, erhält er Zugriff, wenn eine Richtlinie dies zulässt (OR, nicht AND).
  • Für Sitzungssteuerungen gilt nur die zuletzt erstellte Zugriffsbindung.

Eine einzige Konfiguration für alle Anwendungen verwenden

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

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

gcloud

Erstellen Sie die Zugriffsbindung.

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 die Gruppen-ID nicht verfügbar ist, können Sie sie abrufen, indem Sie die Methode get aufrufen für die Gruppenressource.
  • 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 ISO 8601-Dauerformat, z. B. 30m für 30 Minuten oder 2h für zwei Stunden.
  • DEFAULT_SESSION_REAUTH_METHOD: Die optionale Methode, mit der Nutzer aufgefordert werden, ihre Identität noch einmal zu bestätigen. Sie muss eine der folgenden sein:
    • LOGIN: Die Standardanmeldung anwenden, die MFA oder andere von Workspace definierte Faktoren umfassen kann.
    • PASSWORD: Nur ein Passwort erforderlich, auch wenn andere Faktoren definiert sind. Wenn Passwörter über einen externen IdP verwaltet werden, werden Nutzer an den IdP weitergeleitet. Wenn die IdP-Sitzung aktiv ist, werden Nutzer implizit noch einmal authentifiziert. Wenn der IdP nicht aktiv ist, müssen sich Nutzer über den IdP anmelden.
    • SECURITY_KEY: Hardware-Sicherheitsschlüssel erforderlich machen.

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 die Gruppen-ID nicht verfügbar ist, können Sie sie abrufen, indem Sie die Methode get aufrufen für die Gruppenressource.
    • 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 ISO 8601-Dauerformat, z. B. 30m für 30 Minuten oder 2h für zwei Stunden.
    • DEFAULT_SESSION_REAUTH_METHOD: Die optionale Methode, mit der Nutzer aufgefordert werden, ihre Identität noch einmal zu bestätigen. Sie muss eine der folgenden sein:
      • LOGIN: Die Standardanmeldung anwenden, die MFA oder andere von Workspace definierte Faktoren umfassen kann.
      • PASSWORD: Nur ein Passwort erforderlich, auch wenn andere Faktoren definiert sind. Wenn Passwörter über einen externen IdP verwaltet werden, werden Nutzer an den IdP weitergeleitet. Wenn die IdP-Sitzung aktiv ist, werden Nutzer implizit noch einmal authentifiziert. Wenn der IdP nicht aktiv ist, müssen sich Nutzer über den IdP anmelden.
      • SECURITY_KEY: Hardware-Sicherheitsschlüssel erforderlich machen.

  2. Senden Sie die POST-Anfrage:

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

    ORG_ID ist die ID der Organisation, mit der Sie die Rolle Administrator für Cloud-Zugriffsbindung erstellt haben. Wenn die Property 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 „Administrator für Cloud Access Bindings“ verwendet haben.

Bei Erfolg sollten Sie eine Darstellung des JSON-Objekts erhalten. Falls ein Problem vorliegt, erhalten Sie eine Fehlermeldung.

Konfigurationen für bestimmte Anwendungen definieren

Mit dieser Methode können Sie unterschiedliche Zugriffsebenen und Sitzungssteuerungen auf verschiedene Anwendungen anwenden. Sie können auch Standardregeln für Anwendungen festlegen, die keine bestimmten Konfigurationen haben. Diese Methode ist nützlich, wenn Sie Folgendes tun möchten:

  • Richtlinien nur auf bestimmte Anwendungen anwenden

  • Sie können eine allgemeine Richtlinie erstellen, aber einige Anwendungen davon ausschließen.

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:
        #
        # 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

    Ersetzen Sie Folgendes:

    • CLIENT_ID: Die OAuth-Client-ID. Sie müssen 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.
    • SESSION_LENGTH: Die Sitzungsdauer im ISO 8601-Dauerformat, z. B. 30m für 30 Minuten 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. Sie muss eine der folgenden sein:

      • LOGIN: Die Standardanmeldung anwenden, die MFA oder andere von Workspace definierte Faktoren umfassen kann.
      • PASSWORD: Es wird nur ein Passwort benötigt, auch wenn andere Faktoren definiert sind. Wenn Passwörter über einen externen IdP verwaltet werden, werden Nutzer an den IdP weitergeleitet. Wenn die IdP-Sitzung aktiv ist, werden Nutzer implizit noch einmal authentifiziert. Wenn der IdP nicht aktiv ist, müssen sich Nutzer über den IdP anmelden.
      • SECURITY_KEY: Hardware-Sicherheitsschlüssel erforderlich machen.

    • CLIENT_NAME: Der Name des Kunden. Wenn die Anwendung sessionSettings enthält, können Sie den Clientnamen nicht verwenden. Verwenden Sie stattdessen die OAuth-Client-ID.

    • 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 Zugriffsbindung.

    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 die Gruppen-ID nicht verfügbar ist, können Sie sie abrufen, indem Sie die Methode get aufrufen für die Gruppenressource.
    • BINDING_FILE_PATH: Der Pfad zur YAML-Datei, die das Zugriffsbindungsschema 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 ISO 8601-Dauerformat, z. B. 30m für 30 Minuten oder 2h für zwei Stunden.
    • DEFAULT_SESSION_REAUTH_METHOD: Die optionale Methode, mit der Nutzer aufgefordert werden, ihre Identität noch einmal zu bestätigen. Sie muss eine der folgenden sein:
      • LOGIN: Die Standardanmeldung anwenden, die MFA oder andere von Workspace definierte Faktoren umfassen kann.
      • PASSWORD: Nur ein Passwort erforderlich, auch wenn andere Faktoren definiert sind. Wenn Passwörter über einen externen IdP verwaltet werden, werden Nutzer an den IdP weitergeleitet. Wenn die IdP-Sitzung aktiv ist, werden Nutzer implizit noch einmal authentifiziert. Wenn der IdP nicht aktiv ist, müssen sich Nutzer über den IdP anmelden.
      • SECURITY_KEY: Hardware-Sicherheitsschlüssel erforderlich machen.

Zusammenspiel 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, haben die Regeln in der YAML-Datei Vorrang. Der Wert --level gilt für alle Anwendungen, die nicht in der Datei aufgeführt sind.

Sitzungssteuerung verwenden

  • Verwenden Sie --session-length und --session-reauth-method, um Standardeinstellungen für die Sitzungssteuerung für alle Anwendungen festzulegen.
  • Wenn Sie auch Sitzungssteuerungen in der YAML-Datei definieren, werden die Standardeinstellungen für diese bestimmten Anwendungen durch diese Sitzungssteuerungen überschrieben.
  • 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 die Gruppen-ID nicht verfügbar ist, können Sie sie abrufen, indem Sie die Methode get aufrufen für die Gruppenressource.
  • 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 müssen 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.
  • SESSION_LENGTH: Die Sitzungsdauer im ISO 8601-Dauerformat, z. B. 30m für 30 Minuten 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. Sie muss eine der folgenden sein:

    • LOGIN: Die Standardanmeldung anwenden, die MFA oder andere von Workspace definierte Faktoren umfassen kann.
    • PASSWORD: Es wird nur ein Passwort benötigt, auch wenn andere Faktoren definiert sind. Wenn Passwörter über einen externen IdP verwaltet werden, werden Nutzer an den IdP weitergeleitet. Wenn die IdP-Sitzung aktiv ist, werden Nutzer implizit noch einmal authentifiziert. Wenn der IdP nicht aktiv ist, müssen sich Nutzer über den IdP anmelden.
    • SECURITY_KEY: Hardware-Sicherheitsschlüssel erforderlich machen.

  • CLIENT_NAME: Der Name des Kunden. Wenn die Anwendung sessionSettings enthält, können Sie den Clientnamen nicht verwenden. Verwenden Sie stattdessen die OAuth-Client-ID.

  • 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, mit der Sie die Rolle Administrator für Cloud-Zugriffsbindung erstellt haben. Wenn die Property 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 „Administrator für Cloud Access Bindings“ verwendet haben.

Bei Erfolg sollten Sie eine Darstellung des JSON-Objekts erhalten. Bei einem Problem wird eine Fehlermeldung angezeigt.

Zugriffsebenen für den Testlauf verwenden, um die Erzwingung zu simulieren

Mit einem Probelauf für Zugriffsebenen können Sie Ihre Zugriffsrichtlinien testen, ohne sie tatsächlich durchzusetzen. So können Sie die Auswirkungen einer Richtlinie nachvollziehen, bevor sie live geschaltet wird. In den Protokollen des Probelaufs sehen Sie, was passiert wäre, wenn die Richtlinie aktiv wäre.

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

Bindung für Probelauf erstellen

Sie können Zugriffsebenen für den Trockenlauf zusammen mit regulären Zugriffsebenen in derselben Bindung definieren oder separate Bindungen für den Trockenlauf verwenden.

gcloud

  1. Konfigurieren Sie die Zugriffseinstellungen.

    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 Name des Kunden. Wenn die Anwendung sessionSettings enthält, können Sie den Clientnamen nicht verwenden. Verwenden Sie stattdessen die OAuth-Client-ID.
    • 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 müssen clientId 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 Zugriffsbindung.

    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 die Gruppen-ID nicht verfügbar ist, können Sie sie abrufen, indem Sie die Methode get aufrufen für die Gruppenressource.
    • BINDING_FILE_PATH: Der Pfad zur YAML-Datei, die das Zugriffsbindungsschema enthält. Die Bindungsdatei unterstützt nur scopedAccessSettings.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL_2: Optionaler Name der Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

    Fügen Sie dieses Flag hinzu, um die angegebene Zugriffsebene für den Trockenlauf 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 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"
        ]
      }
    }
  ]
}

    Ersetzen Sie Folgendes:

    • GROUP_ID: Die Gruppen-ID. Wenn die Gruppen-ID nicht verfügbar ist, können Sie sie abrufen, indem Sie die Methode get aufrufen für die Gruppenressource.
    • 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_DRY_RUN_ACCESS_LEVEL: Optionaler Name der Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_NAME: Der Name des Kunden. Wenn die Anwendung sessionSettings enthält, können Sie den Clientnamen nicht verwenden. Verwenden Sie stattdessen die OAuth-Client-ID.
    • 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 müssen client_id 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:

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

    ORG_ID ist die ID der Organisation, mit der Sie die Rolle Administrator für Cloud-Zugriffsbindungen erstellt haben. Wenn die Property 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 „Administrator für Cloud Access Bindings“ verwendet haben.

    Bei Erfolg sollten Sie eine Darstellung des JSON-Objekts erhalten. Falls ein Problem vorliegt, erhalten Sie eine Fehlermeldung.

Probelauf-Logs ansehen

Nachdem Sie einen Trockenlauf eingerichtet haben, können Sie in den Protokollen nachsehen, welche Zugriffsversuche abgelehnt worden wären.

In der folgenden Tabelle sind die Logfelder aufgeführt, mit denen Sie die Abfrage zum Abrufen der Protokolle 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 abgelehnt wird.
protoPayload.metadata.evaluationResult Das Ergebnis der Bewertung der Richtlinie für den aktiven Zugriff. Mögliche Werte: GRANTED oder DENIED.
protoPayload.metadata.appliedAccessLevels Die angewendeten Zugriffsebenen, die gemäß der Richtlinie für den aktiven Zugriff erforderlich sind.
protoPayload.metadata.appliedDryRunAccessLevels Die angewendeten Zugriffsebenen, die gemäß der Zugriffsrichtlinie für den Testlauf erforderlich sind.
protoPayload.metadata.dryRunEvaluationResult Das Ergebnis der Bewertung der Zugriffsrichtlinie für den Testlauf, das die beabsichtigte Aktion angibt, wenn die Zugriffsrichtlinie erzwungen wird. Mögliche Werte: GRANTED oder DENIED.

Weitere Informationen zum Erstellen einer Abfrage für Protokolle finden Sie unter Logging-Abfragesprache.