Principal Access Boundary-Richtlinien

Mit PAB-Richtlinien (Principal Access Boundary) können Sie die Ressourcen einschränken, auf die Hauptkonten zugreifen dürfen.

Mit Richtlinien für Begrenzungen des Nutzerzugriffs können Sie beispielsweise verhindern, dass Ihre Nutzer auf Ressourcen in anderen Organisationen zugreifen. So lassen sich Phishing-Angriffe oder Datenexfiltrationen verhindern.

Weitere Informationen zu den anderen Arten von Zugriffssteuerungsrichtlinien, die Identity and Access Management (IAM) bietet, finden Sie unter Richtlinientypen.

Funktionsweise von Principal Access Boundary-Richtlinien

Standardmäßig können Hauptkonten auf alle Google Cloud-Ressourcen zugreifen. Wenn ein Hauptkonto also eine Berechtigung für die Ressource hat und diese Berechtigung nicht abgelehnt wird, kann es diese Berechtigung verwenden, um auf die Ressource zuzugreifen.

Mit Principal Access Boundary-Richtlinien können Sie die Ressourcen einschränken, auf die ein Hauptkonto zugreifen darf. Wenn ein Hauptkonto aufgrund einer Principal Access Boundary-Richtlinie nicht auf eine Ressource zugreifen darf, ist sein Zugriff auf diese Ressource unabhängig von den zugewiesenen Rollen eingeschränkt.

Wenn Hauptkonten versuchen, auf Ressourcen zuzugreifen, auf die sie keinen Zugriff haben, können Richtlinien für die Zugriffsgrenze von Hauptkonten einige, aber nicht alle IAM-Berechtigungen (Identity and Access Management) blockieren. Weitere Informationen dazu, welche Berechtigungen blockiert werden, finden Sie unter Berechtigungen, die durch die Begrenzung des Hauptkontozugriffs blockiert werden können.

Principal Access Boundary-Richtlinien bestehen aus Principal Access Boundary-Regeln. Mit jeder Principal Access Boundary-Regel wird eine Reihe von Ressourcen definiert, auf die die betroffenen Hauptkonten zugreifen dürfen. Sie können in Ihrer Organisation bis zu 1.000 Principal Access Boundary-Richtlinien erstellen.

Nachdem Sie eine Principal Access Boundary-Richtlinie erstellt haben, erstellen Sie eine Richtlinienbindung, um die Richtlinie auf eine Reihe von Hauptkonten anzuwenden.

Für ein Prinzipal können eine oder mehrere Principal Access Boundary-Richtlinien gelten. Jedes Hauptkonto darf nur auf die in diesen Richtlinien aufgeführten Ressourcen zugreifen. Bei allen anderen Ressourcen ist der Zugriff des Hauptkontos auf diese Ressource eingeschränkt, auch wenn Sie dem Hauptkonto Rollen für diese Ressource gewähren.

Da Richtlinien zur Begrenzung des Hauptkontozugriffs mit Hauptkonten und nicht mit Ressourcen verknüpft sind, können Sie damit verhindern, dass Hauptkonten auf Ressourcen zugreifen, die nicht Ihnen gehören. Betrachten Sie beispielsweise das folgende Szenario:

• Die Hauptperson Tal (tal@altostrat.com) ist Teil der Google Workspace-Organisation altostrat.com.
• Tal wird die Rolle „Storage-Administrator“ (roles/storage.admin) für einen Cloud Storage-Bucket in einer anderen Organisation, cymbalgroup.com, zugewiesen. Diese Rolle enthält die Berechtigung storage.objects.get, die zum Ansehen von Objekten im Bucket erforderlich ist.
• In cymbalgroup.com gibt es keine Ablehnungsrichtlinien, die Tal daran hindern, die Berechtigung storage.objects.get zu verwenden.

Mit reinen Zulassungs- und Ausschlussrichtlinien kann altostrat.com nicht verhindern, dass Tal Objekte in diesem externen Bucket aufruft. Keine altostrat.com-Hauptkonten sind berechtigt, die Zulassungsrichtlinie des Buckets zu bearbeiten. Daher kann die Rolle von Tal nicht widerrufen werden. Außerdem ist er nicht berechtigt, Ablehnungsrichtlinien in cymbalgroup.com zu erstellen. Er kann also nicht mit einer Ablehnungsrichtlinie verhindern, dass Tal auf den Bucket zugreift.

Mithilfe von Principal Access Boundary-Richtlinien können altostrat.com-Administratoren jedoch dafür sorgen, dass Tal keine Objekte im cymbalgroup.com-Bucket oder in einem Bucket außerhalb von altostrat.com sehen kann. Dazu können die Administratoren eine Principal Access Boundary-Richtlinie erstellen, die festlegt, dass Hauptkonten von altostrat.com nur auf Ressourcen in altostrat.com zugreifen dürfen. Anschließend kann er eine Richtlinienbindung erstellen, um diese Richtlinie an alle Hauptkonten in der Organisation altostrat.com anzuhängen. Mit dieser Richtlinie kann Tal keine Objekte im Bucket cymbalgroup.com aufrufen, obwohl ihm die Rolle „Storage-Administrator“ für den Bucket zugewiesen ist.

Fail-Open-Bewertung

Während der Vorabversion der Principal Access Boundary-Richtlinien werden diese Richtlinien bei Fehlern nicht geschlossen. Wenn IAM also eine Principal Access Boundary-Richtlinie nicht auswerten kann, wird sie ignoriert und die relevanten Zulassungs- und Ablehnungsrichtlinien werden ausgewertet.

Von Principal Access Boundary-Richtlinien blockierte Berechtigungen

Wenn Hauptkonten versuchen, auf eine Ressource zuzugreifen, auf die sie keinen Zugriff haben, verhindern Principal Access Boundary-Richtlinien, dass sie einige, aber nicht alle IAM-Berechtigungen (Identity and Access Management) für den Zugriff auf die Ressource verwenden.

Wenn eine Principal Access Boundary-Richtlinie eine Berechtigung blockiert, erzwingt IAM Principal Access Boundary-Richtlinien für diese Berechtigung. Mit anderen Worten: Es wird verhindert, dass Hauptkonten, die keinen Zugriff auf eine Ressource haben, diese Berechtigung für den Zugriff auf die Ressource verwenden.

Wenn eine Principal Access Boundary-Richtlinie eine Berechtigung nicht blockiert, haben Principal Access Boundary-Richtlinien keine Auswirkungen darauf, ob Hauptkonten die Berechtigung verwenden können.

Angenommen, einem Hauptkonto, Leo (lee@example.com), wird die Rolle „Dataflow-Entwickler“ (roles/dataflow.developer) zugewiesen. Diese Rolle umfasst die Berechtigung dataflow.jobs.snapshot, mit der Leo Snapshots von Dataflow-Jobs erstellen kann. Lee unterliegt außerdem einer Richtlinie zur Begrenzung des Hauptkontozugriffs, die es ihm nicht erlaubt, auf Ressourcen außerhalb von example.com zuzugreifen. Wenn die Richtlinien für die Begrenzung des Hauptzugriffs die dataflow.jobs.snapshot-Berechtigung jedoch nicht blockieren, kann Lee weiterhin Snapshots von Dataflow-Jobs in Organisationen außerhalb von example.com erstellen.

Welche Berechtigungen von einer Principal Access Boundary-Richtlinie blockiert werden, hängt von der Version der Erzwingung der Principal Access Boundary ab.

Versionen der Erzwingung von Principal Access Boundary

Für jede Principal Access Boundary-Richtlinie wird eine Durchsetzungsversion angegeben, die eine vordefinierte Liste von IAM-Berechtigungen identifiziert, die von der Principal Access Boundary-Richtlinie blockiert werden können. Sie geben die Erzwingungsversion an, wenn Sie eine Principal Access Boundary-Richtlinie erstellen oder aktualisieren. Wenn Sie keine Version für die Erzwingung angeben, verwendet IAM die neueste Version für die Erzwingung und diese Version wird so lange verwendet, bis Sie sie aktualisieren.

In regelmäßigen Abständen werden in IAM neue Versionen der Principal Access Boundary-Erzwingung 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, um die neue Version zu verwenden. Wenn die Version für die Erzwingung automatisch aktualisiert werden soll, wenn 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 es sonst passieren kann, dass Hauptberechtigte den Zugriff auf Ressourcen unerwartet verlieren.

Eine vollständige Liste der Berechtigungen, die von den einzelnen Erzwingungsversionen blockiert werden, finden Sie unter Von Principal Access Boundary-Richtlinien blockierte Berechtigungen.

Principal Access Boundary-Richtlinien an Hauptkontogruppen binden

Wenn Sie eine Principal Access Boundary-Richtlinie an einen Hauptkontosatz binden möchten, erstellen Sie eine Richtlinienbindung, in der sowohl die Principal Access Boundary-Richtlinie als auch der Hauptkontosatz angegeben werden, für den sie erzwungen werden soll. Nachdem Sie die Richtlinie an einen Hauptkontensatz gebunden haben, können die Hauptkonten in diesem Hauptkontensatz nur auf die Ressourcen zugreifen, die in den Regeln der Principal Access Boundary-Richtlinie enthalten sind.

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.

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 Principal-Sets aufgeführt, an die Sie Richtlinien für Principal Access Boundary binden können. Jede Zeile enthält Folgendes:

• Der Typ der Hauptkontogruppe
• Die Hauptkonten in dieser Art von Hauptkontogruppe
• Das Format der IDs für diesen Typ von Hauptkontosatz
• Die Resource Manager-Ressource (Projekt, Ordner oder Organisation), die Richtlinienbindungen für diesen Hauptkontotyp übergeordnet ist

Bedingte Richtlinienbindungen für Principal Access Boundary-Richtlinien

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

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

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

• Das Attribut principal.type gibt an, welche Art von Hauptkonto in der Anfrage enthalten ist, z. B. Dienstkonten oder Identitäten in einem Workload Identity-Pool. Mithilfe von Bedingungen mit diesem Attribut können Sie steuern, auf welche Arten von Hauptkonten eine Principal Access Boundary-Richtlinie angewendet wird.

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

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

• Das principal.subject-Attribut gibt die Identität des Hauptkontos in der Anfrage an, z. B. cruz@example.com. Mithilfe von Bedingungen mit diesem Attribut können Sie genau steuern, für welche Hauptkonten eine Richtlinie für Zugriffsgrenzen gilt.

  Wenn Sie beispielsweise einer Bindung für eine Principal Access Boundary-Richtlinie den folgenden Bedingungsausdruck 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.

Beispiel: Mit Bedingungen die Ressourcen einschränken, auf die ein Hauptkonto zugreifen darf

Mit Bedingungen in Richtlinienbindungen für Principal Access Boundary-Richtlinien können Sie beispielsweise die Ressourcen einschränken, auf die ein einzelnes Hauptkonto zugreifen darf.

Angenommen, Sie haben ein Dienstkonto namens dev-project-service-account mit der E-Mail-Adresse dev-project-service-account@dev-project.iam.gserviceaccount.com. Dieses Dienstkonto unterliegt einer Principal Access Boundary-Richtlinie, die es Hauptkonten ermöglicht, auf alle Ressourcen in der Organisation example.com zuzugreifen. Diese Richtlinie ist an den Hauptkontosatz der Organisation example.com angehängt.

Sie möchten nicht, dass dev-project-service-account auf alle Ressourcen in example.com zugreifen kann, sondern nur auf die Ressourcen in dev-project. Sie möchten jedoch nicht die Ressourcen ändern, auf die andere Hauptkonten im Hauptkontensatz example.com zugreifen dürfen.

Führen Sie dazu das Verfahren aus, um die Ressourcen einzuschränken, auf die Hauptkonten zugreifen dürfen, fügen Sie der Richtlinienbindung aber eine Bedingung hinzu, anstatt sie zu löschen:

1. Sie bestätigen, dass für dev-project-service-account nur die Richtlinie gilt, die Hauptkonten den Zugriff auf alle Ressourcen in example.com ermöglicht.

2. Sie erstellen eine neue Richtlinie zur Begrenzung des Hauptkontozugriffs, die es Hauptkonten ermöglicht, auf Ressourcen in dev-project zuzugreifen, und hängen sie dem Hauptkontosatz für dev-project an. Sie verwenden die folgende Bedingung in der Richtlinienbindung, um sicherzustellen, dass die Richtlinie nur für dev-project-service-account erzwungen wird:

   "condition": {
     "title": "Only dev-project-service-account",
     "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && principal.subject == 'dev-project-service-account@dev-project.iam.gserviceaccount.com'"
   }
   

3. Sie heben die Ausnahme von dev-project-service-account von der Principal Access Boundary-Richtlinie auf, die es Hauptkonten ermöglicht, auf alle Ressourcen in example.com zuzugreifen. Dazu fügen Sie der Richtlinienbindung die folgende Bedingung hinzu, die diese Principal Access Boundary-Richtlinie an den Hauptkontosatz der Organisation anhängt:

   "condition": {
     "title": "Exempt dev-project-service-account",
     "expression": "principal.subject != 'dev-project-service-account@dev-project.iam.gserviceaccount.com' || principal.type != 'iam.googleapis.com/ServiceAccount'"
   }
   

   Informationen zum Aktualisieren vorhandener Principal Access Boundary-Richtlinien finden Sie unter Principal Access Boundary-Richtlinien bearbeiten.

Nachdem Sie der Richtlinienbindung diese Bedingung hinzugefügt haben, kann dev-project-service-account nicht mehr auf alle Ressourcen in example.com zugreifen, sondern nur noch auf Ressourcen in dev-project.

Richtlinieninteraktionen

In IAM wird jede Principal Access Boundary-Richtlinie in Kombination mit Ihren Zulassungs- und Ablehnungsrichtlinien sowie mit Ihren anderen Principal Access Boundary-Richtlinien ausgewertet. Anhand all dieser Richtlinien wird ermittelt, ob ein Hauptkonto auf eine Ressource zugreifen kann.

Interaktion mit anderen Richtlinientypen

Wenn ein Hauptkonto versucht, auf eine Ressource zuzugreifen, wertet IAM alle relevanten Principal Access Boundary-, Zulassungs- und Ablehnungsrichtlinien aus, um festzustellen, ob das Hauptkonto auf die Ressource zugreifen darf. Wenn eine dieser Richtlinien angibt, dass das Hauptkonto nicht auf die Ressource zugreifen darf, verhindert IAM den Zugriff.

Wenn also eine Principal Access Boundary-Richtlinie den Zugriff eines Hauptkontos auf eine Ressource verhindern würde, verhindert IAM den Zugriff auf diese Ressource unabhängig von den Zulassungs- und Ablehnungsrichtlinien, die an die Ressource angehängt sind.

Außerdem gewähren Principal Access Boundary-Richtlinien allein keinen Zugriff auf Ressourcen. Mit Principal Access Boundary-Richtlinien kann ein Hauptkonto zwar berechtigt werden, auf eine Ressource zuzugreifen, aber nur Zulassungsrichtlinien können dem Hauptkonto tatsächlich Zugriff auf die Ressource gewähren.

Weitere Informationen zur Bewertung von IAM-Richtlinien finden Sie unter Richtlinienbewertung.

Interaktion zwischen Principal Access Boundary-Richtlinien

Wenn ein Hauptkonto gemäß einer Principal Access Boundary-Richtlinie auf eine Ressource zugreifen darf, ist dies unabhängig von anderen Principal Access Boundary-Richtlinien, denen das Hauptkonto unterliegt, zulässig. Wenn für ein Hauptkonto bereits eine Principal Access Boundary-Richtlinie gilt, können Sie keine weiteren Principal Access Boundary-Richtlinien hinzufügen, um den Zugriff des Hauptkontos einzuschränken.

Angenommen, ein Nutzer, Dana (dana@example.com), unterliegt einer einzelnen Principal Access Boundary-Richtlinie, prod-projects-policy. Mit dieser Richtlinie können Hauptkonten auf Ressourcen in prod-project zugreifen. Dana unterliegt dieser Richtlinie, da sie an den Hauptkontosatz ihrer Organisation gebunden ist.

Sie erstellen eine neue Principal Access Boundary-Richtlinie (dev-staging-projects-policy), die es Hauptkonten ermöglicht, auf Ressourcen in dev-project und staging-project zuzugreifen, und binden sie dann an den Hauptkontosatz der Organisation.

Aufgrund dieser Principal Access Boundary-Richtlinien darf Dana auf Ressourcen in dev-project, staging-project und prod-project zugreifen.

Wenn Sie die Ressourcen einschränken möchten, auf die Dana zugreifen darf, müssen Sie die Principal Access Boundary-Richtlinien ändern oder entfernen, für die Dana gilt.

Sie können beispielsweise dev-staging-projects-policy so bearbeiten, dass Hauptkonten keinen Zugriff auf Ressourcen in dev-project haben. Dann kann Dana nur auf Ressourcen in staging-project und prod-project zugreifen.

Alternativ können Sie prod-projects-policy entfernen, indem Sie die Richtlinienbindung löschen, die es an den Hauptkontosatz der Organisation bindet. Dann kann Dana nur auf Ressourcen in dev-project und staging-project zugreifen.

Diese Änderungen wirken sich jedoch nicht nur auf Dana aus, sondern auch auf die anderen Hauptkonten, die den geänderten Richtlinien und Bindungen für die Begrenzung des Zugriffs von Hauptkonten unterliegen. Wenn Sie die Ressourcen einschränken möchten, auf die ein einzelnes Hauptkonto zugreifen darf, verwenden Sie bedingte Richtlinienbindungen.

Übernahme von Richtlinien

Principal Access Boundary-Richtlinien sind an Hauptkontogruppen und nicht an Resource Manager-Ressourcen gebunden. Daher werden sie nicht wie Zulassungs- und Ablehnungsrichtlinien über die Ressourcenhierarchie übernommen.

Hauptkontogruppen für übergeordnete Ressourcen des Ressourcenmanagers, also Ordner und Organisationen, enthalten jedoch immer alle Hauptkonten in den Hauptkontogruppen ihrer Nachkommen. Wenn ein Hauptkonto beispielsweise im Hauptkontosatz eines Projekts enthalten ist, ist es auch in den Hauptkontosätzen aller übergeordneten Ordner oder Organisationen enthalten.

Betrachten Sie beispielsweise die Organisation example.com. Diese Organisation ist mit der Domain example.com verknüpft und hat die folgenden Resource Manager-Ressourcen:

• Eine Organisation, example.com
• Ein Projekt „project-1“, das der Organisation untergeordnet ist
• Einen Ordner, folder-a, der der Organisation untergeordnet ist
• Zwei Projekte, project-2 und project-3, die untergeordnet sindfolder-a

Die Hauptgruppen 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 unterliegt den Principal Access Boundary-Richtlinien, die an diese Hauptkontogruppe gebunden sind.

• Ein Dienstkonto in project-1 ist in den Hauptkontengruppen für project-1 und example.com enthalten und unterliegt den Principal Access Boundary-Richtlinien, die an eine dieser Hauptkontengruppen gebunden sind.

• Ein Dienstkonto in project-3 ist in den Hauptkontogruppen für project-3, folder-a und example.com enthalten und unterliegt den Principal Access Boundary-Richtlinien, die an eine dieser Hauptkontogruppen gebunden sind.

Principal Access Boundary-Richtlinien und im Cache gespeicherte Ressourcen

Bestimmte Google Cloud-Dienste speichern öffentlich sichtbare Ressourcen im Cache. In Cloud Storage werden beispielsweise Objekte im Cache gespeichert, die öffentlich lesbar sind.

Ob die Principal Access Boundary 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, kann die Begrenzung des Hauptkontozugriffs nicht verhindern, dass Hauptkonten die Ressource aufrufen.
• Wenn die Ressource nicht im Cache gespeichert ist, verhindert die Begrenzung des Hauptkontozugriffs, dass nicht berechtigte Hauptkonten die Ressource aufrufen können.

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

Struktur einer Principal Access Boundary-Richtlinie

Eine Principal Access Boundary-Richtlinie besteht aus Metadaten und Details zur Principal Access Boundary-Richtlinie. Die Metadaten enthalten Informationen wie den Namen der Richtlinie und das Erstellungsdatum. In den Richtliniendetails wird festgelegt, was die Richtlinie bewirkt, z. B. auf welche Ressourcen die betroffenen 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": "1"
  }
}

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 ist.
• etag: Eine Kennzeichnung 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 von benutzerdefinierten Schlüssel/Wert-Paaren. Mit diesen Anmerkungen können Sie der Richtlinie zusätzliche Metadaten hinzufügen, z. B. wer die Richtlinie erstellt hat oder ob sie über eine automatisierte Pipeline bereitgestellt wurde. Weitere Informationen zu Anmerkungen finden Sie unter Anmerkungen.
• createTime: Der Zeitpunkt, zu dem die Principal Access Boundary-Richtlinie erstellt wurde.
• updateTime: Der Zeitpunkt, zu dem die Principal Access Boundary-Richtlinie zuletzt aktualisiert wurde.

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: 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. Jeder Nutzer, der dieser Richtlinie unterliegt, kann auf diese Ressourcen zugreifen.

    Jede Principal Access Boundary-Richtlinie kann in allen Regeln maximal 500 Ressourcen referenzieren.

  • effect: Die Beziehung der Hauptbevollmächtigten zu den im Feld resources aufgeführten Ressourcen. Der einzige Effekt, den Sie in Regeln für Principal Access Boundary angeben können, ist "ALLOW". Aufgrund dieser Beziehung dürfen 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 von der Principal Access Boundary-Richtlinie blockiert werden können.

  Weitere Informationen zu Versionen von Principal Access Boundary-Richtlinien finden Sie auf dieser Seite unter Versionen der Erzwingung der Begrenzung des Hauptkontozugriffs.

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, auf die sich die Richtlinie bezieht.

In der folgenden Richtlinienbindung wird beispielsweise die Richtlinie example-policy an alle Hauptrollen in der Organisation example.com mit der ID 0123456789012 gebunden. 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 Kennzeichnung 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 von benutzerdefinierten Schlüssel/Wert-Paaren. Mit diesen Anmerkungen können Sie der Richtlinienbindung zusätzliche Metadaten hinzufügen, z. B. wer die Richtlinienbindung erstellt hat oder ob sie über eine automatisierte Pipeline bereitgestellt wurde. Weitere Informationen zu Anmerkungen finden Sie unter Anmerkungen.

• 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 die Richtlinienbindung verweist. Bei Richtlinienbindungen für Principal Access Boundary-Richtlinien ist dieser Wert immer PRINCIPAL_ACCESS_BOUNDARY.

• policy: Die Principal Access Boundary-Richtlinie, die an den Ziel-Hauptsatz 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 die IAM-Richtlinie erzwungen wird. Wenn die Bedingung wahr ist oder nicht ausgewertet werden kann, erzwingt Identity and Access Management die Richtlinie für das Hauptkonto, das die Anfrage stellt. Wenn die Bedingung „false“ ergibt, wird die Richtlinie für den Nutzer nicht von Identity and Access Management erzwungen. 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.

Anwendungsfälle

Im Folgenden finden Sie häufig vorkommende Situationen, in denen Sie Principal Access Boundary-Richtlinien verwenden können, und Beispiele für die Principal Access Boundary-Richtlinien und Richtlinienbindungen, die Sie in den einzelnen Situationen erstellen könnten. Informationen zum Erstellen von Principal Access Boundary-Richtlinien und zum Binden an Hauptkontogruppen finden Sie unter Principal Access Boundary-Richtlinien erstellen und anwenden.

Hauptkonten auf Ressourcen in Ihrer Organisation beschränken

Mit Principal Access Boundary-Richtlinien können Sie dafür sorgen, dass Hauptkonten in Ihrer Organisation nur auf Ressourcen innerhalb Ihrer Organisation zugreifen können.

Angenommen, Sie möchten dafür sorgen, dass alle Hauptkonten in der Organisation example.com nur auf Ressourcen innerhalb von example.com zugreifen können. Die Hauptkonten in example.com umfassen alle Identitäten in der Domain example.com, alle Workforce Identity-Pools in example.com sowie alle Dienstkonten und Workload Identity-Pools in allen Projekten in example.com.

Sie haben keine Principal Access Boundary-Richtlinien, die für die Hauptkonten in Ihrer Organisation gelten. Daher haben alle Hauptkonten Zugriff auf alle Ressourcen.

Wenn Sie Hauptkonten den Zugriff auf Ressourcen außerhalb von example.com entziehen möchten, erstellen Sie eine Principal Access Boundary-Richtlinie, die es Hauptkonten ermöglicht, auf Ressourcen in example.com zuzugreifen:

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "displayName": "Boundary for principals in example.org",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example.org",
        "resources": [
            "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Anschließend erstellen Sie eine Richtlinienbindung, um diese Richtlinie an den Hauptkontosatz zu binden:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"
}

Jetzt dürfen alle Hauptkonten in example.com nur auf Ressourcen in example.com zugreifen. Es wird verhindert, dass sie Berechtigungen verwenden, die von der Principal Access Boundary-Richtlinie blockiert werden, um auf Ressourcen außerhalb von example.com zuzugreifen, auch wenn sie für diese Ressourcen entsprechende Berechtigungen haben.

Dienstkonten auf Ressourcen in einem einzelnen Projekt beschränken

Mit Principal Access Boundary-Richtlinien können Sie dafür sorgen, dass Dienstkonten in einem bestimmten Projekt nur auf Ressourcen innerhalb dieses Projekts zugreifen können.

Angenommen, Sie haben das Projekt example-dev. Sie möchten dafür sorgen, dass die Dienstkonten in example-dev nur auf Ressourcen in example-dev zugreifen können.

Sie haben eine Principal Access Boundary-Richtlinie, die es allen Hauptkonten in Ihrer Organisation, einschließlich der Dienstkonten in example-dev, ermöglicht, auf Ressourcen in example.com zuzugreifen. Wie eine solche Richtlinie aussieht, erfahren Sie unter Hauptkonten auf Ressourcen in Ihrer Organisation beschränken.

Damit die Dienstkonten in example-dev nicht auf Ressourcen außerhalb von example-dev zugreifen können, erstellen Sie zuerst eine Principal Access Boundary-Richtlinie, die es Hauptkonten ermöglicht, auf Ressourcen in example-dev zuzugreifen.

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "displayName": "Boundary for principals in example-dev",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example-dev",
        "resources": [
          "//cloudresourcemanager.googleapis.com/projects/example-dev"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Anschließend erstellen Sie eine Richtlinienbindung, um diese Richtlinie mit allen Hauptkonten in example-dev zu verknüpfen, und fügen eine Bedingung hinzu, damit die Richtlinienbindung nur für Dienstkonten gilt:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding",
  "displayName": "Bind policy to all service accounts in example-dev",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/projects/example-dev"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "condition": {
    "title": "Only service accounts",
    "description": "Only enforce the policy if the principal in the request is a service account",
    "expression": "principal.type == 'iam.googleapis.com/ServiceAccount'"
  }
}

Diese Richtlinie allein schränkt jedoch nicht die Eignung der Dienstkonten ein. Das liegt daran, dass es eine bestehende Principal Access Boundary-Richtlinie gibt, die allen Hauptkonten in example.com den Zugriff auf alle Ressourcen in example.com ermöglicht. Principal Access Boundary-Richtlinien sind additiv. Daher können die Dienstkonten in example-dev weiterhin auf alle Ressourcen in example.com zugreifen.

Damit Dienstkonten in example-dev nur auf Ressourcen in example-dev zugreifen können, müssen Sie der Richtlinienbindung für die vorhandene Principal Access Boundary-Richtlinie eine Bedingung hinzufügen, die verhindert, dass sie für die Dienstkonten in example-dev erzwungen wird:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "condition": {
    "title": "Exempt example-dev service accounts",
    "description": "Don't enforce the policy for service accounts in the example-dev project",
    "expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || !principal.subject.endsWith('@example-dev.iam.gserviceaccount.com')"
  }
}

Jetzt können die Dienstkonten in example-dev nur noch auf Ressourcen in example-dev zugreifen. Es wird verhindert, dass sie Berechtigungen verwenden, die von der Principal Access Boundary-Richtlinie blockiert werden, um auf Ressourcen außerhalb von example-dev zuzugreifen, auch wenn sie diese Berechtigung für diese Ressourcen haben.

Nächste Schritte

• Weitere Informationen zum Erstellen und Anwenden von Principal Access Boundary-Richtlinien
• Sehen Sie sich an, welche Berechtigung durch jede Version der Erzwingung der Principal Access Boundary-Richtlinie blockiert wird.