Diese Seite wurde von der Cloud Translation API übersetzt.

Richtlinien mithilfe von Zugriffsbindungen auf Nutzergruppen anwenden

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

Damit Sie sichergehen können, dass Sie alles richtig konfiguriert haben, können Sie Ihre Richtlinien testen, bevor Sie sie erzwingen.

Beachten Sie bei der Arbeit mit Zugriffsbinding Folgendes:

Eine Nutzergruppe kann nur eine Zugriffsbindung haben.
Wenn ein Nutzer mehreren Gruppen angehört, wird ihm Zugriff gewährt, wenn dies durch eine Richtlinie erlaubt ist (OR nicht AND).
Bei Sitzungssteuerungen gilt nur die zuletzt erstellte Zugriffsbindung.

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 sie 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 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 ISO 8601-Format, z. B. 30m für 30 Minuten oder 2h für 2 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 wird angewendet, die die MFA oder andere von Workspace definierte Faktoren umfassen kann.
- PASSWORD: Es ist 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 neu authentifiziert. Wenn der IdP nicht aktiv ist, müssen sich Nutzer über den IdP anmelden.
- SECURITY_KEY: Hardware-Sicherheitsschlüssel erforderlich.

API

JSON-Text erstellen:
```
{
  "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 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 ISO 8601-Format, z. B. 30m für 30 Minuten oder 2h für 2 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 wird angewendet, die die MFA oder andere von Workspace definierte Faktoren umfassen kann.
  - PASSWORD: Es ist 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 neu authentifiziert. Wenn der IdP nicht aktiv ist, müssen sich Nutzer über den IdP anmelden.
  - SECURITY_KEY: Hardware-Sicherheitsschlüssel erforderlich.
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 Administrator für Cloud-Zugriffsbindung 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 Erfolg sollten Sie eine Darstellung des JSON-Objekts erhalten. 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, für die keine spezifischen Konfigurationen vorhanden sind.

Sie können Anwendungen in Zugriffsbindingen anhand ihrer OAuth-Client-ID angeben. Sie können die folgenden Anwendungen anhand ihres Namens angeben:

Cloud Console
Google Cloud SDK
Google Auth Library Wenn Sie die Standardanmeldedaten für Anwendungen verwenden, die von der gcloud CLI generiert wurden, und Sie den Namen verwenden möchten, müssen Sie die in die gcloud CLI integrierte Standard-Client-ID verwenden. Sie können der gcloud CLI keine Client-ID-Datei bereitstellen.
Firebase Console

Diese Methode ist nützlich, wenn Sie Folgendes tun möchten:

Richtlinien nur auf bestimmte Anwendungen anwenden
Sie erstellen eine allgemeine Richtlinie, schließen aber einige Anwendungen aus.

gcloud

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 ein.
```
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 der Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
- SESSION_LENGTH: Die Sitzungsdauer im ISO 8601-Format, z. B. 30m für 30 Minuten oder 2h für 2 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 wird angewendet, die die MFA oder andere von Workspace definierte Faktoren umfassen kann.
  - PASSWORD: Nur ein Passwort ist 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 neu authentifiziert. Wenn der IdP nicht aktiv ist, müssen sich Nutzer über den IdP anmelden.
  - SECURITY_KEY: Hardware-Sicherheitsschlüssel erforderlich.
- CLIENT_NAME: Der Clientname. 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 der 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).
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 für die Gruppenressource aufrufen.
- BINDING_FILE_PATH: Der Pfad zur YAML-Datei, die das Zugriffsbindungsschema enthält. In der Bindungsdatei wird nur scopedAccessSettings unterstützt.
- 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-Format, z. B. 30m für 30 Minuten oder 2h für 2 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 wird angewendet, die die MFA oder andere von Workspace definierte Faktoren umfassen kann.
  - PASSWORD: Es ist 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 neu authentifiziert. Wenn der IdP nicht aktiv 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 YAML-Datei, die durch --binding-file angegeben wird, nur für die in der Datei definierten Anwendungen gelten.

Mit Sitzungssteuerelementen 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 auch Sitzungssteuerungen in der YAML-Datei definieren, überschreiben diese die Standardeinstellungen für die jeweiligen Anwendungen.
Sie müssen sowohl --session-length als auch --session-reauth-method zusammen verwenden.

API

JSON-Text erstellen:

{
  "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 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 müssen clientId verwenden, wenn eine Anwendung sessionSettings enthält.
ACCESS_LEVEL_A: Ein Name der Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
SESSION_LENGTH: Die Sitzungsdauer im ISO 8601-Format, z. B. 30m für 30 Minuten oder 2h für 2 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 wird angewendet, die die MFA oder andere von Workspace definierte Faktoren umfassen kann.
- PASSWORD: Nur ein Passwort ist 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 neu authentifiziert. Wenn der IdP nicht aktiv ist, müssen sich Nutzer über den IdP anmelden.
- SECURITY_KEY: Hardware-Sicherheitsschlüssel erforderlich.
CLIENT_NAME: Der Clientname. 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 der 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.

Bei Erfolg sollten Sie eine Darstellung des JSON-Objekts oder eine Fehlermeldung erhalten, wenn ein Problem aufgetreten ist.

Zugriffsebenen für Probeläufe 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 besser nachvollziehen, bevor sie in Kraft tritt. 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.

Probelaufbindung erstellen

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

gcloud

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 Clientname. 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 der Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
- DRY_RUN_ACCESS_LEVEL_1: Ein Name der 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 der Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
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 für die Gruppenressource aufrufen.
- BINDING_FILE_PATH: Der Pfad zur YAML-Datei, die das Zugriffsbindungsschema enthält. In der Bindungsdatei wird nur scopedAccessSettings unterstützt.
- DEFAULT_DRY_RUN_ACCESS_LEVEL_2: Ein optionaler Name der Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
Fügen Sie dieses Flag ein, um die angegebene Zugriffsebene für den Probelauf standardmäßig auf alle Anwendungen anzuwenden, die nicht in der YAML-Datei angegeben sind.

API

JSON-Text erstellen:

{
  "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 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_DRY_RUN_ACCESS_LEVEL: Ein optionaler Name der Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
CLIENT_NAME: Der Clientname. 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 der Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
DRY_RUN_ACCESS_LEVEL_1: Ein Name der 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 der Zugriffsebene im Format accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

Senden Sie die POST-Anfrage:
```
https://accesscontextmanager.googleapis.com/v1/organizations/ORG_ID/gcpUserAccessBindings
```
ORG_ID ist die ID der Organisation, die Sie zum Erstellen der Rolle Administrator für Cloud-Zugriffsbindung 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 Erfolg sollten Sie eine Darstellung des JSON-Objekts erhalten. Wenn ein Problem auftritt, erhalten Sie eine Fehlermeldung.

Probelauflogs ansehen

Nachdem Sie einen Probebetrieb eingerichtet haben, können Sie in den Logs nachsehen, welche Zugriffsversuche abgelehnt 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 wurde.
`protoPayload.metadata.evaluationResult`	Das Ergebnis der Auswertung der aktiven Zugriffsrichtlinie. Mögliche Werte: `GRANTED` oder `DENIED`.
`protoPayload.metadata.appliedAccessLevels`	Die angewendeten Zugriffsebenen, die von der aktiven Zugriffsrichtlinie erforderlich sind.
`protoPayload.metadata.appliedDryRunAccessLevels`	Die angewendeten Zugriffsebenen, die von der Zugriffsrichtlinie für Probeläufe erforderlich sind.
`protoPayload.metadata.dryRunEvaluationResult`	Das Ergebnis der Auswertung der Zugriffsrichtlinie für Probeläufe, das die beabsichtigte Aktion angibt, wenn die Zugriffsrichtlinie erzwungen wird. Mögliche Werte: `GRANTED` oder `DENIED`.

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

Richtlinien mithilfe von Zugriffsbindungen auf Nutzergruppen anwenden Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Eine einzige Konfiguration für alle Anwendungen verwenden

gcloud

API

Konfigurationen für bestimmte Anwendungen definieren

gcloud

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

Mit Sitzungssteuerelementen arbeiten

API

Zugriffsebenen für Probeläufe verwenden, um die Erzwingung zu simulieren

Probelaufbindung erstellen

gcloud

API

Probelauflogs ansehen

Richtlinien mithilfe von Zugriffsbindungen auf Nutzergruppen anwenden

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