Principal Access Boundary-Richtlinien

Mit PAB-Richtlinien (Principal Access Boundary) können Sie die Ressourcen definieren, auf die Hauptkonten zugreifen können.

Andere zugriffsbezogene Richtlinien, z. B. Zulassungs- und Ablehnungsrichtlinien, sind Ressourcen zugeordnet. Diese Richtlinien definieren, wer auf die Ressource zugreifen darf, an die sie angehängt sind. Im Gegensatz dazu werden Principal Access Boundary-Richtlinien an Hauptkontogruppen angehängt und steuern, was die Hauptkonten in der Hauptkontogruppe tun dürfen.

Mit Principal Access Boundary-Richtlinien können Sie beispielsweise verhindern, dass Ihre Hauptkonten auf Ressourcen in anderen Organisationen zugreifen. So lassen sich Phishing-Angriffe oder Daten-Exfiltration verhindern.

Funktionsweise von Principal Access Boundary-Richtlinien

Standardmäßig dürfen Hauptkonten auf jede Cloud de Confiance by S3NS Ressource zugreifen. Wenn eine Zulassungsrichtlinie einem Hauptkonto Zugriff auf eine Ressource gewährt und keine Ablehnungsrichtlinien diesen Zugriff blockieren, kann das Hauptkonto auf die Ressource zugreifen.

Mit Principal Access Boundary-Richtlinien können Sie die Ressourcen definieren, auf die ein Hauptkonto zugreifen darf. Wenn ein Hauptkonto nicht berechtigt ist, auf eine Ressource zuzugreifen, ist der Zugriff auf diese Ressource unabhängig von den ihm zugewiesenen Rollen eingeschränkt. Weitere Informationen zur Verwendung von Principal Access Boundary-Richtlinien zum Definieren der Ressourcen, auf die ein Hauptkonto zugreifen darf, finden Sie unter Zulässige Ressourcen definieren.

Principal Access Boundary-Richtlinien blockieren nur Zugriffsversuche, bei denen unterstützte Berechtigungen verwendet werden. Wenn eine Principal Access Boundary-Richtlinie eine Berechtigung nicht blockieren kann, können Hauptkonten diese Berechtigung für den Zugriff auf eine beliebige Ressource verwenden, unabhängig von den Richtlinien, denen sie unterliegen. Weitere Informationen finden Sie unter Berechtigungen, die durch Principal Access Boundary-Richtlinien blockiert werden können.

Anwendungsfälle

Principal Access Boundary-Richtlinien sind in folgenden Fällen nützlich:

• Verhindern, dass Hauptkonten auf Ressourcen zugreifen, die Ihnen nicht gehören
• Bestimmte Hauptkontotypen wie Dienstkonten auf bestimmte Projekte beschränken

Ausführliche Beispiele für die Verwendung von Principal Access Boundary-Richtlinien in solchen Situationen finden Sie unter Anwendungsbeispiele für Principal Access Boundary-Richtlinien.

Komponenten der Principal Access Boundary-Richtlinie

Principal Access Boundary-Richtlinien bestehen aus einzelnen Regeln. Jede Regel definiert eine Reihe von Ressourcen, auf die Hauptkonten zugreifen dürfen. Jede Richtlinie kann bis zu 500 Regeln enthalten.

Richtlinien enthalten auch andere Informationen, darunter Metadaten und Konfigurationsdetails. Weitere Informationen finden Sie unter Struktur einer Principal Access Boundary-Richtlinie.

Nachdem Sie eine Principal Access Boundary-Richtlinie erstellt haben, wenden Sie sie auf Hauptkontosätze an, indem Sie Richtlinienbindungen erstellen. Alle Hauptkonten in diesen Hauptkontensätzen unterliegen dann dieser Principal Access Boundary-Richtlinie. Das bedeutet, dass sie auf die in der Richtlinie aufgeführten Ressourcen zugreifen dürfen. Sie können eine Principal Access Boundary-Richtlinie an eine beliebige Anzahl von Hauptkontogruppen binden.

Sie können in Ihrer Organisation bis zu 1.000 Principal Access Boundary-Richtlinien erstellen.

Berechtigungen, die von Principal Access Boundary-Richtlinien blockiert werden

Principal Access Boundary-Richtlinien können alle Berechtigungen blockieren, die in der Durchsetzungsversion der Richtlinie enthalten sind. Wenn eine Principal Access Boundary-Richtlinie eine Berechtigung blockieren kann, kann sie verhindern, dass nicht berechtigte Hauptkonten diese Berechtigung für den Zugriff auf Ressourcen verwenden.

Sie geben die Erzwingungsversion einer Richtlinie an, wenn Sie die Richtlinie erstellen. Durch das Aktualisieren der Erzwingungsversion werden die Berechtigungen aktualisiert, die durch die Richtlinie blockiert werden können. Eine vollständige Liste der Berechtigungen, die von den einzelnen Erzwingungsversionen blockiert werden, finden Sie in der Referenz zu Erzwingungsversionen.

Wenn eine Principal Access Boundary-Richtlinie eine Berechtigung nicht blockieren kann, hat die Richtlinie keine Auswirkungen darauf, ob Hauptkonten die Berechtigung verwenden können. Mit anderen Worten: IAM kann die Richtlinie für Zugriffsversuche mit dieser Berechtigung nicht erzwingen.

Angenommen, dem Hauptkonto Lee (lee@example.com) wird die Rolle „Dataflow-Entwickler“ (roles/dataflow.developer) zugewiesen. Diese Rolle enthält die Berechtigung dataflow.googleapis.com/jobs.snapshot, mit der Lee Snapshots von Dataflow-Jobs erstellen kann. Für Lee gilt außerdem eine Richtlinie für die Begrenzung des Hauptkontozugriffs, die den Zugriff auf Ressourcen außerhalb von example.com untersagt. Wenn diese Principal Access Boundary-Richtlinie die Berechtigung dataflow.jobs.snapshot jedoch nicht blockieren kann, kann Lee weiterhin Snapshots von Dataflow-Jobs in Organisationen außerhalb von example.com erstellen.

Versionen von Maßnahmen verwalten

In regelmäßigen Abständen werden in IAM neue Erzwingungsversionen hinzugefügt, die zusätzliche Berechtigungen blockieren können. Jede neue Version kann auch alle Berechtigungen der vorherigen Version blockieren.

Wenn Sie die Berechtigungen in einer neuen Erzwingungsversion blockieren möchten, müssen Sie Ihre Principal Access Boundary-Richtlinien aktualisieren, damit die neue Version verwendet wird.

Wenn die Erzwingungsversion einer Richtlinie automatisch aktualisiert werden soll, sobald neue Versionen veröffentlicht werden, können Sie beim Erstellen der Richtlinie den Wert latest verwenden. Wir empfehlen jedoch nicht, diesen Wert zu verwenden, da er dazu führen kann, dass Principals unerwartet den Zugriff auf Ressourcen verlieren.

Richtlinien, die latest für die Versionsnummer verwenden, nutzen die Standardversion für die Erzwingung. Die Standardversion für die Durchsetzung ist in der Regel die neueste Version. Es kann jedoch bis zu vier Wochen dauern, bis eine neue Version zur Standardversion für die Durchsetzung wird. Informationen dazu, welche Erzwingungsversion die Standardversion ist, finden Sie in der Referenz zur Erzwingungsversion.

Die Standardversion für die Erzwingung wird auch für neue Principal Access Boundary-Richtlinien verwendet, in denen keine Versionsnummer angegeben ist.

Zulässige Ressourcen definieren

Hauptkonten können von einer beliebigen Anzahl von Principal Access Boundary-Richtlinien betroffen sein oder diesen unterliegen. Zusammen definieren diese Richtlinien die Ressourcen, auf die das Hauptkonto zugreifen darf.

Principal Access Boundary-Richtlinien sind additiv. Das bedeutet, dass die Ressourcen, auf die ein Hauptkonto zugreifen darf, die Vereinigung aller Ressourcen in allen Principal Access Boundary-Richtlinien sind, denen das Hauptkonto unterliegt. Wenn ein Hauptkonto durch eine einzelne Principal Access Boundary-Richtlinie zum Zugriff auf eine Ressource berechtigt ist, ist es unabhängig von den anderen Principal Access Boundary-Richtlinien, denen es unterliegt, zum Zugriff auf die Ressource berechtigt.

Wenn für ein Hauptkonto keine Principal Access Boundary-Richtlinien gelten, darf es auf jede Cloud de Confiance Ressource zugreifen.

In den folgenden Abschnitten wird beschrieben, wie Sie die Ressourcen anpassen, auf die ein Prinzipal zugreifen kann.

Zulässige Ressourcen hinzufügen

Es gibt mehrere Möglichkeiten, einem Prinzipal den Zugriff auf eine Ressource zu ermöglichen, auf die er nicht zugreifen darf:

• Fügen Sie die Ressource einer Principal Access Boundary-Richtlinie hinzu, der das Hauptkonto unterliegt.
• Erstellen Sie eine neue Principal Access Boundary-Richtlinie mit der zusätzlichen Ressource und binden Sie die Richtlinie an einen Hauptkontosatz, der das Hauptkonto enthält.
• Entfernen oder löschen Sie alle Principal Access Boundary-Richtlinien, denen das Hauptkonto unterliegt. Durch diese Aktion darf das Hauptkonto auf alle Cloud de Confiance Ressourcen zugreifen.

Geeignete Ressourcen entfernen

Es gibt mehrere Möglichkeiten, den Zugriff eines Principals auf eine Ressource zu verhindern, auf die er eigentlich Zugriff hat.

Suchen Sie zuerst nach allen Principal Access Boundary-Richtlinien, denen das Hauptkonto unterliegt und die die Ressource enthalten. Anhand der gefundenen Richtlinien können Sie dann eine der folgenden Aktionen ausführen:

• Wenn das Hauptkonto keinen Principal Access Boundary-Richtlinien unterliegt, erstellen Sie eine neue Principal Access Boundary-Richtlinie, die nur die Ressourcen enthält, auf die das Hauptkonto zugreifen darf. Binden Sie diese Richtlinie dann an eine Hauptkontogruppe, die das Hauptkonto enthält.

  Nachdem Sie die Richtlinie angewendet haben, kann das Hauptkonto nicht mehr auf alle Ressourcen zugreifen, sondern nur noch auf die in der Richtlinie aufgeführten Ressourcen.

• Wenn für das Hauptkonto bereits eine oder mehrere Principal Access Boundary-Richtlinien gelten, müssen Sie dafür sorgen, dass keine der Principal Access Boundary-Richtlinien, denen es unterliegt, die Ressource enthält. Eine detaillierte Anleitung finden Sie unter Ressourcen reduzieren, auf die Principals zugreifen können.

  Während dieses Vorgangs müssen Sie dafür sorgen, dass für das Hauptkonto immer mindestens eine Principal Access Boundary-Richtlinie gilt. Andernfalls kann das Hauptkonto möglicherweise auf alle Ressourcen zugreifen.

Principal Access Boundary-Richtlinien und im Cache gespeicherte Ressourcen

Bestimmte Cloud de Confiance by S3NS Dienste speichern öffentlich sichtbare Ressourcen im Cache. Cloud Storage speichert beispielsweise öffentlich lesbare Objekte im Cache.

Ob eine Principal Access Boundary-Richtlinie verhindern kann, dass nicht berechtigte Hauptkonten eine öffentlich sichtbare Ressource aufrufen, hängt davon ab, ob die Ressource im Cache gespeichert ist:

• Wenn die Ressource im Cache gespeichert ist, können Principal Access Boundary-Richtlinien nicht verhindern, dass Hauptkonten die Ressource ansehen.
• Wenn die Ressource nicht im Cache gespeichert ist, verhindert die Principal Access Boundary, dass nicht berechtigte Hauptkonten die Ressource aufrufen können.

In allen Fällen verhindern Principal Access Boundary-Richtlinien weiterhin, dass nicht berechtigte Hauptkonten öffentlich sichtbare Ressourcen ändern oder löschen.

Bewertung von Principal Access Boundary-Richtlinien

Wenn ein Hauptkonto versucht, auf eine Ressource zuzugreifen, wertet IAM die relevanten Principal Access Boundary-Richtlinien aus, um festzustellen, ob der Zugriffsversuch blockiert werden soll. Eine Richtlinie ist relevant, wenn das Hauptkonto, das den Zugriffsversuch unternimmt, der Richtlinie unterliegt.

Principal Access Boundary-Richtlinien können den Zugriff nur blockieren oder nicht blockieren, aber nicht gewähren. Nur Zulassungsrichtlinien können Hauptkonten Zugriff auf Ressourcen gewähren. Informationen dazu, wie sich verschiedene Richtlinientypen auf den Zugriff von Identitäten auf Ressourcen auswirken, finden Sie unter Richtlinientypen.

IAM blockiert den Zugriff nicht, wenn eine der folgenden Bedingungen zutrifft:

• Für das Hauptkonto gelten keine Principal Access Boundary-Richtlinien
• Die relevanten Principal Access Boundary-Richtlinien können die Berechtigung in der Anfrage nicht blockieren.
• Durch eine Principal Access Boundary-Richtlinie erhält das Hauptkonto die Berechtigung, auf die Ressource zuzugreifen.

IAM blockiert den Zugriff, wenn für das Hauptkonto mindestens eine Principal Access Boundary-Richtlinie gilt, aber keine der relevanten Richtlinien dem Hauptkonto den Zugriff auf die Ressource ermöglichen.

Fail-Closed-Bewertung

Principal Access Boundary-Richtlinien sind standardmäßig geschlossen. Wenn bei der Auswertung einer Principal Access Boundary-Richtlinie ein Fehler auftritt, verhindert IAM, dass das Hauptkonto auf die Ressource zugreift.

Der häufigste Grund für einen IAM-Fehler bei der Auswertung von Principal Access Boundary-Richtlinien ist, dass die Details eines Hauptkontos noch im System weitergegeben werden. Das tritt am wahrscheinlichsten bei neu erstellten Nutzern auf. Um dieses Problem zu beheben, muss der neue Prinzipal warten und später noch einmal versuchen, auf die Ressource zuzugreifen.

Principal Access Boundary-Richtlinien auf Hauptkontogruppen anwenden

Wenn Sie eine Principal Access Boundary-Richtlinie auf einen Hauptkontosatz anwenden möchten, erstellen Sie eine Richtlinienbindung, in der sowohl die anzuwendende Principal Access Boundary-Richtlinie als auch der Hauptkontosatz angegeben werden, auf den sie angewendet werden soll. Mit dieser Richtlinienbindung wird die Richtlinie an die Hauptkontogruppe gebunden.

Nachdem Sie eine Richtlinie an einen Hauptkontensatz gebunden haben, können die Hauptkonten in diesem Hauptkontensatz nur auf die Ressourcen zugreifen, die in den Principal Access Boundary-Richtlinien aufgeführt sind, denen sie unterliegen.

Sie können eine Principal Access Boundary-Richtlinie an eine beliebige Anzahl von Hauptkontogruppen binden. An jede Hauptkontogruppe können bis zu zehn Principal Access Boundary-Richtlinien gebunden werden.

Sie können nur Bindungen für vorhandene Principal Access Boundary-Richtlinien erstellen. Der Versuch, eine Bindung für eine gelöschte Principal Access Boundary-Richtlinie zu erstellen, schlägt fehl. Wenn Sie vor Kurzem eine Principal Access Boundary-Richtlinie gelöscht haben, können Sie manchmal eine Bindung erstellen, aber die Bindung hat keine Auswirkungen. IAM bereinigt diese Bindungen automatisch.

Informationen zum Verwalten von Principal Access Boundary-Richtlinien finden Sie unter Principal Access Boundary-Richtlinien erstellen und anwenden.

Unterstützte Hauptkontogruppen

In der folgenden Tabelle sind die Arten von Hauptkontosets aufgeführt, an die Sie Principal Access Boundary-Richtlinien binden können. Jede Zeile enthält Folgendes:

• Typ der Prinzipalgruppe
• Die Hauptkonten in dieser Art von Hauptkontogruppe
• Das Format der IDs für diesen Typ von Hauptkontogruppe
• Die Resource Manager-Ressource (Projekt, Ordner oder Organisation), die übergeordnete Richtlinienbindungen für diesen Typ von Hauptkonto enthält

Richtlinienübernahme und Hauptkontogruppen

Principal Access Boundary-Richtlinien werden an Hauptkontogruppen und nicht an Ressourcen angehängt. Daher werden sie nicht auf dieselbe Weise über die Ressourcenhierarchie übernommen wie Zulassungs- und Ablehnungsrichtlinien.

Die Principal-Sets für Ordner und Organisationen enthalten jedoch immer alle Principals in den Principal-Sets ihrer untergeordneten Elemente. Wenn ein Hauptkonto beispielsweise im Hauptkonto-Set eines Projekts enthalten ist, ist es auch in den Hauptkonto-Sets aller übergeordneten Ordner oder Organisationen enthalten.

Betrachten Sie beispielsweise eine Organisation, example.com. Diese Organisation ist mit der Domain example.com verknüpft und enthält die folgenden Ressourcen:

• Eine Organisation, example.com
• Ein Projekt, project-1, das ein untergeordnetes Element der Organisation ist
• Ein Ordner, folder-a, der ein untergeordnetes Element der Organisation ist
• Zwei Projekte, project-2 und project-3, die untergeordnete Elemente von folder-a sind

Die Prinzipalmengen dieser Ressourcen enthalten die folgenden Identitäten:

Daher sind die folgenden Hauptkonten von den folgenden Principal Access Boundary-Richtlinien betroffen:

• Eine Google Workspace-Identität in der Domain example.com ist in der Hauptkontogruppe für example.com enthalten und wird von Principal Access Boundary-Richtlinien beeinflusst, die an diese Hauptkontogruppe gebunden sind.

• Ein Dienstkonto in project-1 ist in den Hauptkontogruppen für project-1 und example.com enthalten und unterliegt Richtlinien zur Begrenzung des Hauptkontozugriffs, die an eine dieser Hauptkontogruppen gebunden sind.

• Eine Agentenidentität in project-3 ist in den Hauptkontosätzen für project-3, folder-a und example.com enthalten und wird von Principal Access Boundary-Richtlinien beeinflusst, die an einen dieser Hauptkontosätze gebunden sind.

Bedingte Richtlinienbindungen für Principal Access Boundary-Richtlinien

Sie können Bedingungsausdrücke in Richtlinienbindungen für Principal Access Boundary-Richtlinien verwenden, um genauer festzulegen, für welche Hauptkonten die Richtlinie gilt.

Bedingungsausdrücke für Richtlinienbindungen bestehen aus einer oder mehreren Anweisungen, die durch bis zu 10 logische Operatoren (&&, || oder !) verbunden sind. Jede Anweisung drückt eine attributbasierte Steuerungsregel aus, die für die Richtlinienbindung gilt und letztlich bestimmt, ob die Richtlinie angewendet wird.

Sie können die Attribute principal.type und principal.subject in Bedingungen für Richtlinienbindungen verwenden. Andere Attribute werden nicht unterstützt.

• Das Attribut principal.type bezieht sich auf den Typ des Hauptkontos, das die Anfrage gestellt hat, z. B. ein Dienstkonto oder eine Agent-Identität. Sie können Bedingungen mit diesem Attribut verwenden, um zu steuern, für welche Arten von Hauptkonten eine Richtlinie zur Begrenzung des Hauptkontozugriffs gilt.

  Wenn Sie beispielsweise den folgenden Bedingungsausdruck einer Bindung für eine Principal Access Boundary-Richtlinie hinzufügen, gilt die Richtlinie nur für Dienstkonten:

  principal.type == 'iam.googleapis.com/ServiceAccount'
  

• Das Attribut principal.subject bezieht sich auf die Identität des Hauptkontos, das die Anfrage gestellt hat, z. B. cruz@example.com. Mit Bedingungen können Sie genau festlegen, welche Hauptkonten einer Principal Access Boundary-Richtlinie unterliegen.

  Wenn Sie beispielsweise den folgenden Bedingungsausdruck einer Bindung für eine Principal Access Boundary-Richtlinie hinzufügen, gilt die Richtlinie nicht für den Nutzer special-admin@example.com:

  principal.subject != 'special-admin@example.com'
  

Weitere Informationen zu den Werten, die Sie für diese Bedingungen verwenden können, finden Sie in der Referenz zu Bedingungsattributen.

Ein Beispiel für die Verwendung dieser Bedingungen in Ihren Richtlinien für die Zugriffsgrenze für Hauptkonten finden Sie unter Dienstkonten für den Zugriff auf Ressourcen in einem einzelnen Projekt infrage kommen lassen.

Organisationsübergreifende Richtlinienbindungen

Sie können keine organisationsübergreifende Richtlinienbindung für eine Principal Access Boundary-Richtlinie erstellen. Eine organisationsübergreifende Richtlinienbindung bindet eine Richtlinie in einer Organisation an einen Hauptkontosatz in einer anderen Organisation.

IAM löscht regelmäßig alle vorhandenen organisationsübergreifenden Richtlinienbindungen. Organisationsübergreifende Richtlinienbindungen können auftreten, wenn Sie ein Projekt von einer Organisation in eine andere verschieben. Betrachten Sie beispielsweise die folgende Situation:

• Sie haben ein Projekt namens example-project in der Organisation example.com.
• Sie möchten, dass Hauptkonten in example-project auf Ressourcen in example.com zugreifen können. Dazu erstellen Sie in example.com eine Principal Access Boundary-Richtlinie, die Hauptkonten berechtigt, auf Ressourcen in example.com zuzugreifen, und binden diese Richtlinie an den Hauptkontosatz für example-project.
• Sie verschieben example-project von example.com nach cymbalgroup.com.

In diesem Fall wird durch das Verschieben des Projekts eine organisationsübergreifende Richtlinienbindung erstellt. Das liegt daran, dass die Principal Access Boundary-Richtlinie in example.com an eine Gruppe von Hauptkonten in cymbalgroup.com gebunden ist. Wenn Sie die Bindung nicht manuell löschen, wird sie von IAM automatisch gelöscht. Durch das Löschen dieser Bindung wird sichergestellt, dass cymbalgroup.com-Administratoren Zugriff auf alle Principal Access Boundary-Richtlinien haben, die an ihre Hauptkonten gebunden sind.

Struktur einer Principal Access Boundary-Richtlinie

Eine Principal Access Boundary-Richtlinie ist eine Sammlung von Metadaten und Details zur Principal Access Boundary-Richtlinie. Die Metadaten enthalten Informationen wie den Namen der Richtlinie und das Erstellungsdatum. In den Richtliniendetails wird definiert, was die Richtlinie bewirkt, z. B. auf welche Ressourcen betroffene Hauptkonten zugreifen dürfen.

Mit der folgenden Principal Access Boundary-Richtlinie können die Hauptkonten, die der Richtlinie unterliegen, beispielsweise auf die Ressourcen in der Organisation mit der ID 0123456789012 zugreifen.

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "uid": "puid_0123456789012345678",
  "etag": "W/\"Gh/PcTdJD/AWHUhPW45kdw==\"",
  "displayName": "Example policy",
  "annotations": {
    "example-key": "example-value"
  },
  "createTime": "2024-01-02T15:01:23Z",
  "updateTime": "2024-01-02T15:01:23Z",
  "details": {
    "rules": [
      {
        "description": "Example principal access boundary policy rule",
        "resources": [
          "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "4"
  }
}

In den folgenden Abschnitten werden die Felder in den Metadaten und Details einer Principal Access Boundary-Richtlinie beschrieben.

Metadaten

Principal Access Boundary-Richtlinien enthalten die folgenden Metadaten:

• name: Der Name der Principal Access Boundary-Richtlinie. Dieser Name hat das Format organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID, wobei ORGANIZATION_ID die numerische ID der Organisation ist, in der die Principal Access Boundary-Richtlinie erstellt wurde, und PAB_POLICY_ID die alphanumerische ID der Principal Access Boundary-Richtlinie.
• uid: Eine eindeutige ID, die der Principal Access Boundary-Richtlinie zugewiesen wurde.
• etag: Eine Kennung für den aktuellen Status der Richtlinie. Dieser Wert ändert sich, wenn Sie die Richtlinie aktualisieren. Damit widersprüchliche Aktualisierungen verhindert werden, muss der Wert etag mit dem in IAM gespeicherten Wert übereinstimmen. Wenn die etag-Werte nicht übereinstimmen, schlägt die Anfrage fehl.
• displayName: Ein für Nutzer lesbarer Name für die Principal Access Boundary-Richtlinie.
• annotations: Optional. Eine Liste benutzerdefinierter Schlüssel/Wert-Paare. Mit diesen Anmerkungen können Sie der Richtlinie zusätzliche Metadaten hinzufügen, z. B. wer die Richtlinie erstellt hat oder ob die Richtlinie über eine automatisierte Pipeline bereitgestellt wurde. Weitere Informationen zu Annotationen finden Sie unter Annotationen.
• createTime: Der Zeitpunkt, zu dem die Principal Access Boundary-Richtlinie erstellt wurde.
• updateTime: Der Zeitpunkt der letzten Aktualisierung der Principal Access Boundary-Richtlinie.

Details

Jede Principal Access Boundary-Richtlinie enthält ein details-Feld. Dieses Feld enthält die Principal Access Boundary-Regeln und die Version der Erzwingung:

• rules: Eine Liste der Principal Access Boundary-Regeln, die die Ressourcen definieren, auf die die betroffenen Hauptkonten zugreifen dürfen. Jede Regel enthält die folgenden Felder:

  • description: Eine menschenlesbare Beschreibung der Regel.

  • resources: Eine Liste der Resource Manager-Ressourcen (Projekte, Ordner und Organisationen), auf die Hauptkonten zugreifen dürfen sollen. Alle Hauptkonten, die dieser Richtlinie unterliegen, können auf diese Ressourcen zugreifen.

    In jeder Principal Access Boundary-Richtlinie können in allen Regeln der Richtlinie maximal 500 Ressourcen referenziert werden.

  • effect: Die Beziehung, die die Principals zu den im Feld resources aufgeführten Ressourcen haben. Die einzige Wirkung, die Sie in Regeln für Principal Access Boundary-Richtlinien angeben können, ist "ALLOW". Durch diese Beziehung können die Hauptkonten auf die in der Regel aufgeführten Ressourcen zugreifen.

• enforcementVersion: Die Durchsetzungsversion, die von IAM bei der Durchsetzung der Richtlinie verwendet wird. Die Version der Principal Access Boundary-Richtlinie bestimmt, welche Berechtigungen durch die Principal Access Boundary-Richtlinie blockiert werden können.

  Weitere Informationen zum Festlegen und Verwalten von Erzwingungsversionen finden Sie auf dieser Seite unter Erzwingungsversionen verwalten.

Struktur einer Richtlinienbindung

Eine Richtlinienbindung für eine Principal Access Boundary-Richtlinie enthält den Namen einer Richtlinie, den Namen des Hauptkontosatzes, an den die Richtlinie gebunden werden soll, und Metadaten, die die Richtlinienbindung beschreiben. Sie kann auch Bedingungen enthalten, die die genauen Hauptkonten ändern, für die die Richtlinie gilt.

Die folgende Richtlinienbindung bindet beispielsweise die Richtlinie example-policy an alle Principals in der Organisation example.com mit der ID 0123456789012. Die Richtlinienbindung enthält außerdem eine Bedingung, die verhindert, dass die Richtlinie für das Hauptkonto super-admin@example.com erzwungen wird.

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-policy-binding",
  "uid": "buid_01234567890123456789", 
  "etag": "W/\"cRMdDXbT82aLuZlvoL9Gqg==\"",
  "displayName": "Example policy binding",
  "annotations": {
    "example-key": "example-value"
  },
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "policyUid": "puid_0123456789012345678",
  "condition": {
    "title": "Exempt principal",
    "description": "Don't enforce the policy for super-admin@example.com",
    "expression": "principal.subject != 'super-admin@example.com'"
  },
  "createTime": "2024-01-02T17:00:16Z",
  "updateTime": "2024-01-02T17:00:16Z"
}

Jede Richtlinienbindung enthält die folgenden Felder:

• name: Der Name der Richtlinienbindung. Dieser Name hat das Format RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID, wobei RESOURCE_TYPE/RESOURCE_ID der Typ und die ID der übergeordneten Ressource der Richtlinienbindung und BINDING_ID die alphanumerische ID der Richtlinienbindung ist.
• uid: Eine eindeutige ID, die der Richtlinienbindung zugewiesen wurde.
• etag: Eine Kennung für den aktuellen Status der Richtlinie. Dieser Wert ändert sich, wenn Sie die Richtlinie aktualisieren. Damit widersprüchliche Aktualisierungen verhindert werden, muss der Wert etag mit dem in IAM gespeicherten Wert übereinstimmen. Wenn die etag-Werte nicht übereinstimmen, schlägt die Anfrage fehl.
• displayName: Ein für Nutzer lesbarer Name für die Richtlinienbindung.
• annotations: Optional. Eine Liste benutzerdefinierter Schlüssel/Wert-Paare. Mit diesen Anmerkungen können Sie der Richtlinienbindung zusätzliche Metadaten hinzufügen, z. B. wer die Richtlinienbindung erstellt hat oder ob die Richtlinienbindung über eine automatisierte Pipeline bereitgestellt wurde. Weitere Informationen zu Annotationen finden Sie unter Annotationen.

• target: Der Hauptkontosatz, an den die Richtlinie gebunden werden soll. Der Wert hat das Format {"principalSet": PRINCIPAL_SET}, wobei PRINCIPAL_SET die ID der Hauptkontogruppe ist, an die Sie die Richtlinie binden möchten.

  An jedes Ziel können bis zu zehn Richtlinien gebunden werden.

• policyKind: Der Richtlinientyp, auf den sich die Richtlinienbindung bezieht. Bei Richtlinienbindungen für Principal Access Boundary-Richtlinien ist dieser Wert immer PRINCIPAL_ACCESS_BOUNDARY.

• policy: Die Principal Access Boundary-Richtlinie, die an die Ziel-Hauptkontogruppe gebunden werden soll.

• policyUid: Eine eindeutige ID, die der Principal Access Boundary-Richtlinie zugewiesen ist, auf die im Feld policy verwiesen wird.

• condition: Optional. Ein logischer Ausdruck, der sich darauf auswirkt, für welche Hauptkonten IAM die Richtlinie erzwingt. Wenn die Bedingung „true“ ergibt oder nicht ausgewertet werden kann, erzwingt Identity and Access Management die Richtlinie für das Hauptkonto, das die Anfrage stellt. Wenn die Bedingung als „false“ ausgewertet wird, erzwingt Identity and Access Management die Richtlinie nicht für das Hauptkonto. Weitere Informationen finden Sie auf dieser Seite unter Principal Access Boundary und Bedingungen.

• createTime: Der Zeitpunkt, zu dem die Richtlinienbindung erstellt wurde.

• updateTime: Der Zeitpunkt, zu dem die Richtlinienbindung zuletzt aktualisiert wurde.

Nächste Schritte

• Weitere Informationen zu den Anwendungsfällen für Principal Access Boundary-Richtlinien
• Informationen zum Erstellen und Anwenden von Principal Access Boundary-Richtlinien
• Berechtigungen, die durch die einzelnen Versionen der Erzwingung von Principal Access Boundary-Richtlinien blockiert werden