Principal Access Boundary-Richtlinien

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

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.

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

Funktionsweise von Principal Access Boundary-Richtlinien

Standardmäßig dürfen Hauptkonten auf jede Google Cloud Ressource zugreifen. Wenn ein Hauptkonto eine Berechtigung für die Ressource hat und diese Berechtigung nicht verweigert wird, kann es mit dieser Berechtigung auf die Ressource zugreifen.

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

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

Principal Access Boundary-Richtlinien bestehen aus Principal Access Boundary-Regeln. Jede Principal Access Boundary-Regel definiert eine Reihe von Ressourcen, 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 Gruppe von Hauptkonten anzuwenden.

Für ein Hauptkonto 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 zuweisen.

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

• Der Schulleiter Tal (tal@example.com) gehört zur Google Workspace-Organisation example.com.
• Tal erhält die Rolle „Storage-Administrator“ (roles/storage.admin) für einen Cloud Storage-Bucket in einer anderen Organisation, cymbalgroup.com. Diese Rolle enthält die Berechtigung storage.objects.get, die zum Anzeigen von Objekten im Bucket erforderlich ist.
• Es gibt keine Ablehnungsrichtlinien in cymbalgroup.com, die Tal daran hindern, die Berechtigung storage.objects.get zu verwenden.

Mit reinen Zulassungs- und Ablehnungsrichtlinien kann example.com nicht verhindern, dass Tal Objekte in diesem externen Bucket aufruft. Kein example.com-Hauptkonto ist berechtigt, die Zulassungsrichtlinie des Buckets zu bearbeiten. Daher kann die Rolle von Tal nicht widerrufen werden. Sie sind auch nicht berechtigt, Ablehnungsrichtlinien in cymbalgroup.com zu erstellen. Sie können also keine Ablehnungsrichtlinie verwenden, um Tal den Zugriff auf den Bucket zu verwehren.

Mit Principal Access Boundary-Richtlinien können example.com-Administratoren jedoch dafür sorgen, dass Tal keine Objekte im Bucket cymbalgroup.com oder in einem Bucket außerhalb von example.com ansehen kann. Dazu können Administratoren eine Principal Access Boundary-Richtlinie erstellen, in der festgelegt wird, dass example.com-Hauptkonten nur auf Ressourcen in example.com zugreifen dürfen. Anschließend können sie eine Richtlinienbindung erstellen, um diese Richtlinie an alle Hauptkonten in der Organisation example.com anzuhängen. Mit einer solchen Richtlinie kann Tal keine Objekte im Bucket cymbalgroup.com ansehen, obwohl er die Rolle „Storage-Administrator“ für den Bucket hat.

Fail-closed-Bewertung

Principal Access Boundary-Richtlinien werden standardmäßig nicht erfüllt. Wenn IAM eine Principal Access Boundary-Richtlinie bei der Bewertung des Zugriffs eines Hauptkontos nicht auswerten kann, verhindert IAM, dass das Hauptkonto auf die Ressource zugreift.

Der häufigste Grund dafür, dass IAM Principal Access Boundary-Richtlinien nicht auswerten kann, ist, dass die Details eines Hauptkontos noch im System weitergegeben werden. Das passiert am ehesten bei neu erstellten Nutzern. Um dieses Problem zu beheben, muss das neue Hauptkonto warten und später noch einmal versuchen, auf die Ressource zuzugreifen.

Berechtigungen, die von Principal Access Boundary-Richtlinien blockiert werden

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: Sie 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, dem Hauptkonto Lee (lee@example.com) wird die Rolle „Dataflow-Entwickler“ (roles/dataflow.developer) zugewiesen. Diese Rolle umfasst die Berechtigung dataflow.jobs.snapshot, mit der Lee Snapshots von Dataflow-Jobs erstellen kann. Lee unterliegt außerdem einer Principal Access Boundary-Richtlinie, die den Zugriff auf Ressourcen außerhalb von example.com untersagt. Wenn die Richtlinien für die Zugriffsgrenze für Principals die Berechtigung dataflow.jobs.snapshot jedoch nicht blockieren, kann Lee weiterhin Snapshots von Dataflow-Jobs in Organisationen außerhalb von example.com erstellen.

Welche Berechtigungen durch eine Principal Access Boundary-Richtlinie blockiert werden, hängt von der Version der Principal Access Boundary-Durchsetzung ab.

Versionen der Erzwingung der Principal Access Boundary-Richtlinie

In jeder Principal Access Boundary-Richtlinie wird eine Erzwingungsversion angegeben, die eine vordefinierte Liste von IAM-Berechtigungen enthält, die durch die 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 Erzwingungsversion angeben, verwendet IAM die neueste Erzwingungsversion und verwendet diese Version weiterhin, 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, damit die neue Version verwendet wird. Wenn die Erzwingungsversion 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.

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

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, die Sie erzwingen möchten, als auch der Hauptkontosatz angegeben werden, für den Sie sie erzwingen möchten. 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.

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

• Typ der Hauptkontogruppe
• 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

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 in Bedingungen für Richtlinienbindungen nicht unterstützt.

• Das Attribut principal.type gibt an, welcher Hauptkontotyp im Antrag enthalten ist, z. B. Dienstkonten oder Identitäten in einem Workload Identity-Pool. Sie können Bedingungen mit diesem Attribut verwenden, um zu steuern, für welche Arten von Hauptkonten eine Principal Access Boundary-Richtlinie 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 gibt die Identität des Prinzipal in der Anfrage an, z. B. cruz@example.com. Sie können Bedingungen mit diesem Attribut verwenden, um genau zu steuern, 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.

Beispiel: Bedingungen verwenden, um die Ressourcen einzuschränken, auf die ein Hauptkonto zugreifen darf

Eine Möglichkeit, Bedingungen in Richtlinienbindungen für Principal Access Boundary-Richtlinien zu verwenden, besteht darin, die Ressourcen einzuschränken, auf die ein einzelnes Hauptkonto zugreifen darf.

Angenommen, Sie haben ein Dienstkonto dev-project-service-account mit der E-Mail-Adresse dev-project-service-account@dev-project.iam.gserviceaccount.com. Für dieses Dienstkonto gilt eine Principal Access Boundary-Richtlinie, die Hauptkonten berechtigt, auf alle Ressourcen in der Organisation example.com zuzugreifen. Diese Richtlinie ist an den Hauptkontosatz der Organisation example.com angehängt.

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

Um diese Änderung vorzunehmen, folgen Sie der Anleitung zum Einschränken der Ressourcen, auf die Hauptkonten zugreifen dürfen. Sie fügen der Richtlinienbindung jedoch eine Bedingung hinzu, anstatt sie zu löschen:

1. Sie bestätigen, dass für dev-project-service-account nur die Principal Access Boundary-Richtlinie gilt, die Hauptkonten berechtigt, auf alle Ressourcen in example.com zuzugreifen.

2. Sie erstellen eine neue Principal Access Boundary-Richtlinie, mit der Hauptkonten berechtigt werden, auf Ressourcen in dev-project zuzugreifen, und hängen sie an den 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 schließen dev-project-service-account von der Principal Access Boundary-Richtlinie aus, die Hauptkonten berechtigt, auf alle Ressourcen in example.com zuzugreifen. Dazu fügen Sie der Richtlinienbindung, mit der die Principal Access Boundary-Richtlinie an den Hauptkontosatz der Organisation angehängt wird, die folgende Bedingung hinzu:

   "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 diese Bedingung der Richtlinienbindung 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.

Organisationsübergreifende Richtlinienbindungen

Sie können keine organisationsübergreifende Richtlinienbindung für eine Principal Access Boundary-Richtlinie erstellen. Eine organisationsübergreifende Richtlinienbindung ist eine Richtlinienbindung, mit der eine Richtlinie in einer Organisation an einen Hauptkontosatz in einer anderen Organisation gebunden wird.

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, mit der Hauptkonten auf Ressourcen in example.com zugreifen können, und binden diese Richtlinie an den Hauptkontosatz für example-project.
• Sie verschieben example-project von example.com nach cymbalgroup.com.

In diesem Fall würde beim Verschieben des Projekts eine organisationsübergreifende Richtlinienbindung erstellt. Das liegt daran, dass die Principal Access Boundary-Richtlinie in example.com an eine Gruppe von Principals in cymbalgroup.com gebunden wäre. 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.

Richtlinienüberschneidungen

IAM wertet jede Principal Access Boundary-Richtlinie in Kombination mit Ihren Zulassungs- und Ablehnungsrichtlinien sowie mit Ihren anderen Principal Access Boundary-Richtlinien aus. Alle diese Richtlinien werden verwendet, um zu bestimmen, 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 eine Principal Access Boundary-Richtlinie ein Hauptkonto daran hindert, auf eine Ressource zuzugreifen, verhindert IAM den Zugriff auf diese Ressource, unabhängig von den an die Ressource angehängten Zulassungs- und Ablehnungsrichtlinien.

Außerdem gewähren Principal Access Boundary-Richtlinien allein keinen Zugriff auf Ressourcen. Mit Principal Access Boundary-Richtlinien kann ein Hauptkonto berechtigt werden, auf eine Ressource zuzugreifen. Der tatsächliche Zugriff auf die Ressource kann jedoch nur mit Zulassungsrichtlinien gewährt werden.

Weitere Informationen zur IAM-Richtlinienauswertung finden Sie unter Richtlinienauswertung.

Interaktion zwischen Principal Access Boundary-Richtlinien

Wenn ein Hauptkonto durch eine Principal Access Boundary-Richtlinie zum Zugriff auf eine Ressource berechtigt ist, kann es unabhängig von den anderen Principal Access Boundary-Richtlinien, denen es unterliegt, auf diese Ressource zugreifen. Wenn ein Hauptkonto bereits einer Principal Access Boundary-Richtlinie unterliegt, können Sie keine weiteren Principal Access Boundary-Richtlinien hinzufügen, um den Zugriff des Hauptkontos einzuschränken.

Angenommen, für das Hauptkonto Dana (dana@example.com) gilt nur eine Principal Access Boundary-Richtlinie, nämlich prod-projects-policy. Mit dieser Richtlinie können Hauptkonten auf Ressourcen in prod-project zugreifen. Dana unterliegt dieser Richtlinie, weil sie an die Hauptkontogruppe ihrer Organisation gebunden ist.

Sie erstellen eine neue Principal Access Boundary-Richtlinie, dev-staging-projects-policy, mit der Hauptkonten auf Ressourcen in dev-project und staging-project zugreifen können, 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, die für Dana gelten.

Sie können beispielsweise dev-staging-projects-policy so bearbeiten, dass Hauptkonten nicht für den Zugriff auf Ressourcen in dev-project infrage kommen. Dana hätte dann nur Zugriff auf Ressourcen in staging-project und prod-project.

Alternativ können Sie prod-projects-policy entfernen, indem Sie die Richtlinienbindung löschen, mit der sie an den Hauptkontosatz der Organisation gebunden ist. Dana könnte dann nur auf Ressourcen in dev-project und staging-project zugreifen.

Diese Änderungen betreffen jedoch nicht nur Dana, sondern auch die anderen Hauptkonten, die den geänderten Richtlinien und Bindungen für Principal Access Boundary unterliegen. Wenn Sie die Ressourcen reduzieren möchten, auf die ein einzelnes Hauptkonto zugreifen darf, verwenden Sie bedingte Richtlinienbindungen.

Übernahme von Richtlinien

PAB-Richtlinien (Principal Access Boundary) werden an Hauptkontogruppen und nicht an Resource Manager-Ressourcen angehängt. Daher werden sie nicht auf dieselbe Weise über die Ressourcenhierarchie vererbt wie Zulassungs- und Ablehnungsrichtlinien.

Hauptkontogruppen für übergeordnete Resource Manager-Ressourcen, also Ordner und Organisationen, enthalten jedoch immer alle Hauptkonten in den Hauptkontogruppen ihrer untergeordneten Ressourcen. Wenn ein Hauptkonto beispielsweise in der Hauptkontogruppe eines Projekts enthalten ist, ist es auch in den Hauptkontogruppen aller übergeordneten Ordner oder Organisationen enthalten.

Betrachten Sie beispielsweise eine 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 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 Hauptkontosätze 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 den Principal Access Boundary-Richtlinien, die an eine dieser Hauptkontogruppen gebunden sind.

• Ein Dienstkonto in project-3 ist in den Hauptkontogruppen für project-3, folder-a und example.com enthalten und wird von Principal Access Boundary-Richtlinien beeinflusst, 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. Cloud Storage speichert beispielsweise Objekte, die öffentlich lesbar sind, im Cache.

Ob eine 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 Principal Access Boundary nicht verhindern, dass Hauptkonten die Ressource aufrufen.
• Wenn die Ressource nicht im Cache gespeichert ist, wird durch die Principal Access Boundary verhindert, 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 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": "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 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 Erzwingungsversion:

• 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 für Menschen lesbare Beschreibung der Regel.

  • resources: Eine Liste der Resource Manager-Ressourcen (Projekte, Ordner und Organisationen), auf die Hauptkonten zugreifen dürfen sollen. Jedes Hauptkonto, das dieser Richtlinie unterliegt, kann 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 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 Richtlinie blockiert werden können.

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

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.

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 auch 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 10 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 Zielhauptkontogruppe 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 „false“ ergibt, erzwingt Identity and Access Management die Richtlinie für den Principal nicht. 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 dieser Richtlinien an Hauptkontogruppen finden Sie unter Principal Access Boundary-Richtlinien erstellen und anwenden.

Hauptkonten für den Zugriff auf Ressourcen in Ihrer Organisation berechtigen

Mit einer Principal Access Boundary-Richtlinie können Sie Hauptkonten in Ihrer Organisation berechtigen, auf Ressourcen in Ihrer Organisation zuzugreifen. Wenn dies die einzige Principal Access Boundary-Richtlinie ist, der die Hauptkonten in Ihrer Organisation unterliegen, dürfen sie aufgrund dieser Richtlinie auch nicht auf Ressourcen außerhalb Ihrer Organisation zugreifen.

Angenommen, Sie möchten, dass alle Identitäten in der Organisation example.com auf Ressourcen in example.com zugreifen können, aber nicht auf Ressourcen in anderen Organisationen. 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 einem beliebigen Projekt in example.com.

Es gibt keine Principal Access Boundary-Richtlinien, die auf die Hauptkonten in Ihrer Organisation angewendet werden. Daher können alle Hauptkonten auf alle Ressourcen zugreifen.

Damit Hauptkonten auf Ressourcen in example.com zugreifen können, aber nicht auf Ressourcen außerhalb von example.com, erstellen Sie eine Principal Access Boundary-Richtlinie, die Hauptkonten berechtigt, 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 der Organisation 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"
}

Wenn diese Richtlinie an den Organisationshauptkontensatz gebunden ist, können alle Hauptkonten in example.com auf Ressourcen in example.com zugreifen. Da dies die einzige Principal Access Boundary-Richtlinie ist, der diese Hauptkonten unterliegen, verhindert die Richtlinie auch, dass die Hauptkonten in example.com auf Ressourcen außerhalb Ihrer Organisation zugreifen können. Das bedeutet, dass sie keine Berechtigungen verwenden können, die durch die Principal Access Boundary-Richtlinie blockiert werden, um auf Ressourcen außerhalb von example.com zuzugreifen, auch wenn sie diese Berechtigungen für diese Ressourcen haben.

Dienstkonten für Ressourcen in einem einzelnen Projekt verfügbar machen

Sie können eine Principal Access Boundary-Richtlinie erstellen, um die Dienstkonten in einem bestimmten Projekt für den Zugriff auf Ressourcen in diesem Projekt zu autorisieren.

Wenn dies die einzige Principal Access Boundary-Richtlinie ist, der die Dienstkonten unterliegen, dürfen die Dienstkonten nur auf Ressourcen in diesem Projekt zugreifen.

Angenommen, Sie haben ein Projekt example-dev mit der Projektnummer 901234567890. Sie möchten sicherstellen, dass die Dienstkonten in example-dev nur auf Ressourcen in example-dev zugreifen können.

Sie haben eine Principal Access Boundary-Richtlinie, die alle Hauptkonten in Ihrer Organisation, einschließlich der Dienstkonten in example-dev, für den Zugriff auf Ressourcen in example.com berechtigt. Beispiel für eine Organisationsrichtlinie

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, mit der Hauptkonten auf Ressourcen in example-dev zugreifen können.

{
  "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 an alle Hauptkonten in example-dev zu binden, 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 ändert jedoch nicht die Ressourcen, auf die die Dienstkonten zugreifen können. Das liegt daran, dass es eine vorhandene Principal Access Boundary-Richtlinie gibt, die alle Hauptkonten in example.com berechtigt, auf alle Ressourcen in example.com zuzugreifen. Principal Access Boundary-Richtlinien sind additiv. Die Dienstkonten in example-dev können also 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, einschließlich der Standarddienstkonten, 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') || !principal.subject == 'example-dev@appspot.gserviceaccount.com || !principal.subject == '901234567890-compute@developer.gserviceaccount.com'"
  }
}

Die Dienstkonten in example-dev können jetzt nur noch auf Ressourcen in example-dev zugreifen. Sie können keine Berechtigungen verwenden, die durch die Principal Access Boundary-Richtlinie blockiert werden, um auf Ressourcen außerhalb von example-dev zuzugreifen, auch wenn sie diese Berechtigungen für diese Ressourcen haben.

Wenn Sie später die Ressourcen erweitern möchten, auf die diese Dienstkonten zugreifen können, können Sie der example-dev-only-Richtlinie zusätzliche Ressourcen hinzufügen oder eine zusätzliche Richtlinie für die Zugriffsgrenze für Hauptkonten erstellen und sie an die Dienstkonten binden.

Nächste Schritte

• Informationen zum Erstellen und Anwenden von Principal Access Boundary-Richtlinien
• Sehen Sie sich die Berechtigungen an, die durch die einzelnen Versionen der Erzwingung von Principal Access Boundary-Richtlinien blockiert werden.