Informationen zu Zulassungsrichtlinien

Sie können Zugriff auf Google Cloud-Ressourcen gewähren, indem Sie Zulassungsrichtlinien gewähren. Diese werden auch als IAM-Richtlinien (Identity and Access Management) bezeichnet und mit Ressourcen verknüpft. finden Sie weitere Informationen. Sie können jeweils nur eine Zulassungsrichtlinie an eine Ressource anhängen. Die Zulassungsrichtlinie steuert den Zugriff auf die Ressource selbst sowie auf alle Nachfolgerelemente dieser Ressource, die die Zulassungsrichtlinie übernehmen.

Auf dieser Seite werden Zulassungsrichtlinien im JSON-Format angezeigt. Sie können auch die Google Cloud CLI verwenden, um Zulassungsrichtlinien im YAML-Format abzurufen.

Richtlinienstruktur

Eine Zulassungsrichtlinie ist eine Sammlung von Rollenbindungen und Metadaten. Eine Rollenbindung gibt an, welcher Zugriff auf eine Ressource gewährt werden soll. Sie verknüpft oder bindet ein oder mehrere Hauptkonten mit einer einzigen Rolle und kontextspezifischen Bedingungen, die die Art und den Zeitpunkt der Rollenzuweisung beeinflussen. Die Metadaten enthalten zusätzliche Informationen über die Zulassungsrichtlinie, wie z. B. ein ETag und die Version, um die Richtlinienverwaltung zu erleichtern.

Jede Rollenbindung kann die folgenden Felder enthalten:

• Ein oder mehrere Hauptkonten, auch Mitglieder oder Identitäten genannt. Es gibt verschiedene Arten von Hauptkonten, darunter Nutzerkonten, Dienstkonten, Google-Gruppen und Domains. Eine vollständige Liste der unterstützten Hauptkontotypen finden Sie unter Hauptkonto-IDs.
• Eine Rolle ist eine benannte Sammlung von Berechtigungen, mit denen Sie bestimmte Aktionen für Google Cloud-Ressourcen vornehmen können.

• Eine Bedingung ist ein optionaler logischer Ausdruck, der die Rollenbindung anhand von Attributen der Anfrage wie Ursprung oder Zielressource weiter einschränkt. Mit Bedingungen wird in der Regel anhand des Kontextes einer Anfrage bestimmt, ob der Zugriff gewährt wird.

  Wenn eine Rollenbindung eine Bedingung enthält, wird sie als bedingte Rollenbindung bezeichnet.

  Einige Google Cloud-Dienste akzeptieren keine Bedingungen in Zulassungsrichtlinien. Eine Liste der Dienste und Ressourcentypen, die Bedingungen akzeptieren, finden Sie unter Ressourcentypen, die bedingte Rollenbindungen akzeptieren.

Änderungen am Zugriff eines Hauptkontos entsprechen der Eventual Consistency. Das bedeutet, dass es einige Zeit dauert, bis Zugriffsänderungen im System wirksam werden. Informationen darüber, wie lange es durchschnittlich dauert, bis Zugriffsänderungen weitergegeben werden, finden Sie unter Zugriffsänderungsverteilung.

Limits für alle Hauptkonten

Jede Zulassungsrichtlinie kann bis zu 1.500 Hauptkonten enthalten. Im Hinblick auf diese Grenze zählt IAM alle Darstellungen jedes Hauptkontos in den Rollenbindungen der zulässigen Richtlinie sowie der Hauptkonten, die die Richtlinie vom Audit-Logging des Datenzugriffs ausnimmt. Hauptkonten, die in mehreren Rollenbindungen vorkommen, werden nicht dedupliziert. Wenn eine Zulassungsrichtlinie beispielsweise nur Rollenbindungen für das Hauptkonto user:[e-mail] enthält und dieses Hauptkonto in 50 Rollenbindungen enthalten ist, können Sie den Rollenbindungen in der Zulassungsrichtlinie weitere 1.450 Hauptkonten hinzufügen.

Außerdem wird im Hinblick auf diese Grenze jedes Vorkommen einer Domain oder Google-Gruppe als einzelnes Hauptkonto gezählt, unabhängig von der Anzahl der einzelnen Mitglieder in der Domain oder Gruppe.

Wenn Sie IAM Conditions verwenden oder vielen Hauptkonten mit unüblich langen Kennzeichnungen Rollen zuweisen, erlaubt IAM möglicherweise weniger Hauptkonten in der Zulassungsrichtlinie.

Beschränkungen für Gruppen und Domains

Bis zu 250 Hauptkonten in einer Zulassungsrichtlinie können Google-Gruppen, Cloud Identity-Domains oder Google Workspace-Konten sein.

Im Hinblick auf diese Grenze werden Cloud Identity-Domains, Google Workspace-Konten und Google-Gruppen folgendermaßen gezählt:

• Bei Google-Gruppen wird jede eindeutige Gruppe nur einmal gezählt, unabhängig davon, wie oft die Gruppe in der Richtlinie zum Zulassen angezeigt wird. Das unterscheidet sich von der Zählung von Gruppen für die Beschränkung der Gesamtzahl der Hauptkonten in einer „allow“-Richtlinie. Bei dieser Beschränkung wird jede Gruppe auf das Limit angerechnet.
• Für Cloud Identity-Domains oder Google Workspace-Konten zählt IAM alle Vorkommen jeder Domain oder jedes Kontos in den Rollenbindungen der zulässigen Richtlinie. Hauptkonten, die in mehreren Rollenbindungen vorkommen, werden nicht dedupliziert.

Wenn Ihre Zulassungsrichtlinie beispielsweise nur eine Gruppe (group:[e-mail]) enthält und die Gruppe zehnmal in der Zulassungsrichtlinie enthalten ist, können Sie weitere 249 Cloud Identity-Domains, Google Workspace-Konten oder eindeutige Gruppen hinzufügen, bevor Sie das Limit erreichen.

Wenn Ihre Zulassungsliste beispielsweise nur eine Domain (domain:example.com) enthält und die Domain zehnmal in der Zulassungsliste enthalten ist, können Sie weitere 240 Cloud Identity-Domains, Google Workspace-Konten oder eindeutige Gruppen hinzufügen, bevor Sie das Limit erreichen.

Richtlinienmetadaten

Die Metadaten für eine Zulassungsrichtlinie enthalten die folgenden Felder:

• Ein etag-Feld, das für die Gleichzeitigkeitserkennung verwendet wird und sicherstellt, dass die Zulassungsrichtlinien regelmäßig aktualisiert werden. Weitere Informationen finden Sie unter ETags in einer Richtlinie verwenden auf dieser Seite.
• Ein version-Feld, das die Schemaversion für eine bestimmte Zulassungsrichtlinie angibt. Weitere Informationen finden Sie unter Richtlinienversionen auf dieser Seite.

Bei Organisationen, Ordnern, Projekten und Rechnungskonten kann die Zulassungsrichtlinie auch das Feld auditConfig enthalten. Dieses Feld gibt die Aktivitätstypen an, die Audit-Logs für jeden Dienst generieren. Informationen zum Konfigurieren dieses Teils einer Zulassungsrichtlinie finden Sie unter Audit-Logs zum Datenzugriff konfigurieren.

ETags in einer Richtlinie verwenden

Wenn mehrere Systeme versuchen, gleichzeitig in dieselbe Zulassungsrichtlinie zu schreiben, besteht das Risiko, dass diese Systeme die Änderungen des jeweils anderen überschreiben. Dieses Risiko besteht, weil Zulassungsrichtlinien mit dem Muster read-modify-write aktualisiert werden, das mehrere Vorgänge umfasst:

1. Bestehende Zulassungsrichtlinie lesen
2. Zulassungsrichtlinie ändern
3. Gesamte Zulassungsrichtlinie schreiben

Wenn System A eine Zulassungsrichtlinie liest und System B unmittelbar eine aktualisierte Version dieser Zulassungsrichtlinie schreibt, sind System A die Änderungen von System B nicht bekannt. Wenn System A seine eigenen Änderungen in die Zulassungsrichtlinie schreibt, gehen die Änderungen von System B möglicherweise verloren.

Zur Vermeidung dieses Problems unterstützt die Identitäts- und Zugriffsverwaltung (IAM) die Gleichzeitigkeitserkennung mithilfe eines etag-Felds in der Zulassungsliste. Jede Zulassungsrichtlinie enthält ein etag-Feld. Der Wert dieses Felds ändert sich bei jeder Aktualisierung einer Richtlinie. Wenn eine Zulassungsrichtlinie ein etag-Feld, aber keine Rollenbindungen enthält, gewährt die Richtlinie keine IAM-Rollen.

Das Feld etag enthält einen Wert wie BwUjMhCsNvY=. Achten Sie beim Aktualisieren der Zulassungsrichtlinie darauf, dass das Feld etag in der aktualisierten Zulassungsrichtlinie enthalten ist. Wenn die Zulassungsrichtlinie nach dem Abrufen geändert wurde, stimmt der etag-Wert nicht überein und die Aktualisierung schlägt fehl. Für die REST API erhalten Sie den HTTP-Statuscode 409 Conflict. Der Antworttext sieht in etwa so aus:

{
  "error": {
    "code": 409,
    "message": "There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff.",
    "status": "ABORTED"
  }
}

Wenn dieser Fehler auftritt, wiederholen Sie alle Vorgänge: Lesen Sie die Zulassungsrichtlinie noch einmal, ändern Sie sie bei Bedarf und schreiben Sie die aktualisierte Zulassungsrichtlinie. Wiederholungsversuche sollten Sie automatisch mit exponentiellem Backoff in allen Tools ausführen, die Sie zur Verwaltung von Zulassungsrichtlinien verwenden.

Beispiel: Einfache Richtlinie

Mit der folgenden Beispielzulassungsrichtlinie wird ein Hauptkonto an eine Rolle gebunden:

{
  "bindings": [
    {
      "members": [
        "user:[e-mail]"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Im obigen Beispiel wird [e-mail] die einfache Rolle "Inhaber" ohne Bedingungen zugewiesen. Mit dieser Rolle hat [e-mail] fast unbegrenzten Zugriff.

Achtung: Einfache Rollen umfassen Tausende von Berechtigungen für alle Google Cloud-Dienste. In Produktionsumgebungen sollten Sie einfache Rollen nur zuweisen, wenn es keine andere Möglichkeit gibt. Gewähren Sie stattdessen vordefinierte Rollen mit den größten Einschränkungen oder benutzerdefinierte Rollen für Ihre Anforderungen.

Beispiel: Richtlinie mit mehreren Rollenbindungen

Betrachten Sie die folgende Beispielzulassungsrichtlinie, die mehr als eine Rollenbindung enthält. Jede Rollenbindung weist eine andere Rolle zu:

{
  "bindings": [
    {
      "members": [
        "user:[e-mail]"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:[e-mail]",
        "user:[e-mail]"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Im Beispiel oben wird Jie ([e-mail]) in der ersten Rollenbindung die vordefinierte Rolle Organisationsadministrator (roles/resourcemanager.organizationAdmin) zugewiesen. Diese Rolle enthält Berechtigungen für Organisationen, Ordner und begrenzte Projektvorgänge. In der zweiten Rollenbindung erhalten sowohl Jie als auch Raha ([e-mail]) die Möglichkeit, Projekte über die Rolle „Projektersteller“ (roles/resourcemanager.projectCreator) zu erstellen. Zusammen gewähren diese Rollenbindungen Jie und Raha differenzierten Zugriff. Jie wird dabei ein umfangreicherer Zugriff als Raha erteilt.

Beispiel: Richtlinie mit bedingter Rollenbindung

Sehen Sie sich die folgende Zulassungsrichtlinie an, die Hauptkonten an eine vordefinierte Rolle bindet und einen Bedingungsausdruck zur Beschränkung der Rollenbindung verwendet:

{
  "bindings": [
    {
      "members": [
        "group:[e-mail]",
        "serviceAccount:[e-mail]"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression":
            "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

In diesem Beispiel ist für das Feld version der Wert 3 festgelegt, da die Zulassungsrichtlinie einen Bedingungsausdruck enthält. Die Rollenbindung in der Zulassungsrichtlinie ist bedingt. Die Rolle wird der Google-Gruppe [e-mail] und dem Dienstkonto [e-mail] nur bis zum 1. Juli 2022 zugewiesen.

Weitere Informationen zu den Features der einzelnen Richtlinienversionen finden Sie auf dieser Seite unter Richtlinienversionen.

Beispiel: Richtlinie mit bedingten und bedingungslosen Rollenbindungen

Sehen Sie sich die folgende Zulassungsrichtlinie an, die sowohl bedingte als auch bedingungslose Rollenbindungen für dieselbe Rolle enthält:

{
  "bindings": [
    {
      "members": [
        "serviceAccount:[e-mail]"
       ],
       "role": "roles/appengine.deployer"
    },
    {
      "members": [
        "group:[e-mail]",
        "serviceAccount:[e-mail]"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
        "title": "Expires_July_1_2022",
        "description": "Expires on July 1, 2022",
        "expression":
          "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

In diesem Beispiel ist das Dienstkonto serviceAccount:[e-mail] in zwei Rollenbindungen für dieselbe Rolle enthalten. Die erste Rollenbindung hat keine Bedingung. Die zweite Rollenbindung hat eine Bedingung, durch die die Rolle nur bis zum 1. Juli 2022 zugewiesen wird.

Mit dieser Zulassungsrichtlinie wird die Rolle immer dem Dienstkonto zugewiesen. In IAM überschreiben bedingte Rollenbindungen keine Rollenbindungen ohne Bedingung. Wenn ein Hauptkonto an eine Rolle gebunden ist und die Rollenbindung keine Bedingung hat, hat das Hauptkonto immer diese Rolle. Das Hinzufügen des Hauptkontos zu einer bedingten Rollenbindung für dieselbe Rolle hat keine Auswirkungen.

Im Gegensatz dazu ist die Google-Gruppe group:[e-mail] nur in der bedingten Rollenbindung enthalten. Daher hat sie die Rolle nur bis zum 1. Juli 2022.

Beispiel: Richtlinie, die eine Rolle an ein gelöschtes Hauptkonto bindet

Sehen Sie sich die folgende Zulassungsrichtlinie an. Diese Zulassungsrichtlinie bindet eine Rolle an einen Nutzer [e-mail], dessen Konto gelöscht wurde: Daher hat die Kennzeichnung des Nutzers jetzt das Präfix deleted::

{
  "bindings": [
    {
      "members": [
        "deleted:user:[e-mail]?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Wenn Sie einen neuen Nutzer mit dem Namen [e-mail] erstellen, gelten die Rollenbindungen der Zulassungsrichtlinie für den gelöschten Nutzer nicht für den neuen Nutzer. Dieses Verhalten verhindert, dass neue Nutzer Rollen übernehmen, die gelöschten Nutzern gewährt wurden. Wenn Sie dem neuen Nutzer Rollen zuweisen möchten, fügen Sie den neuen Nutzer den Bindungen der Zulassungsrichtlinie hinzu, wie unter Richtlinien mit gelöschten Hauptkonten auf dieser Seite beschrieben.

Außerdem enthält der Name des Nutzers jetzt das Präfix deleted: und das Suffix ?uid=numeric-id, wobei numeric-id die eindeutige numerische ID des gelöschten Nutzers ist. In diesem Beispiel wird anstelle von user:[e-mail] die Zulassungsrichtliniedeleted:user:[e-mail]?uid=123456789012345678901 angezeigt.

Dienstkonten und Gruppen verhalten sich genauso wie Nutzer. Wenn Sie ein Dienstkonto oder eine Gruppe löschen und eine Zulassungsrichtlinie anzeigen, die dieses Hauptkonto enthält, hat der Name des gelöschten Hauptkontos das Präfix deleted: und das Suffix ?uid=numeric-id.

Standardrichtlinien

Alle Ressourcen, die Zulassungsrichtlinien akzeptieren, werden mit standardmäßigen Zulassungsrichtlinien erstellt. Die Standardzulassungsrichtlinien der meisten Ressourcen sind leer. Die Standardzulassungsrichtlinien einiger Ressourcen enthalten aber automatisch bestimmte Rollenbindungen. Wenn Sie beispielsweise ein neues Projekt erstellen, enthält die Zulassungsrichtlinie für das Projekt automatisch eine Rollenbindung, die Ihnen die Inhaberrolle (roles/owner) für das Projekt zuweist.

Diese Rollenbindungen werden vom System erstellt, sodass der Nutzer für die Ressource keine getIamPolicy- oder setIamPolicy-Berechtigungen benötigt, damit die Rollenbindungen erstellt werden können.

Informationen dazu, ob eine Ressource mit einer Zulassungsrichtlinie erstellt wird, finden Sie in der Dokumentation der Ressource.

Richtlinienübernahme und die Ressourcenhierarchie

Google Cloud-Ressourcen sind hierarchisch organisiert, wobei der Organisationsknoten der Stammknoten in der Hierarchie ist, darunter folgen optional Ordner und dann Projekte. Die meisten anderen Ressourcen werden unter der Projektebene erstellt und verwaltet. Jede Ressource hat genau ein übergeordnetes Element, mit Ausnahme der Organisation. Die Organisation als Stammknoten in der Hierarchie hat kein übergeordnetes Element. Weitere Informationen finden Sie unter Ressourcenhierarchie.

Die Ressourcenhierarchie muss beim Festlegen von Zulassungsrichtlinien berücksichtigt werden. Wenn eine Zulassungsrichtlinie auf einer höheren Ebene in der Hierarchie, z. B. auf Organisationsebene, Ordnerebene oder Projektebene, festgelegt wird, umfasst der freigegebene Zugriffsbereich die Ressourcenebene, der diese Zulassungsrichtlinie zugeordnet ist, sowie alle Ressourcen unterhalb dieser Ebene. Beispielsweise gilt eine auf Organisationsebene festgelegte Zulassungsrichtlinie für die Organisation und alle unter der Organisation angeordneten Ressourcen. Ebenso gilt eine auf Projektebene festgelegte Zulassungsrichtlinie für das Projekt und alle Ressourcen im Projekt.

Der Begriff Richtlinienübernahme beschreibt, wie Zulassungsrichtlinien auf Ressourcen unterhalb ihrer Ebene in der Ressourcenhierarchie angewendet werden. Mit dem Begriff geltende Richtlinie wird beschrieben, wie alle übergeordneten Zulassungsrichtlinien in der Ressourcenhierarchie für eine Ressource übernommen werden. Darunter fallen folgende Richtlinien:

• Die für die Ressource festgelegte Zulassungsrichtlinie
• Die Zulassungsrichtlinien, die für alle übergeordneten Ressourcenebenen der Ressource in der Hierarchie festgelegt wurden

Alle neuen Rollenbindungen, die von der übergeordneten Ressource übernommen werden und die sich auf die geltende Zulassungsrichtlinie der Ressource auswirken, werden unabhängig voneinander ausgewertet. Eine bestimmte Zugriffsanfrage für die Ressource wird positiv beantwortet, wenn der Anfrage durch eine der übergeordneten Rollenbindungen Zugriff gewährt wird.

Wenn eine neue Rollenbindung auf eine beliebige Ebene der übernommenen Zulassungsrichtlinie der Ressource angewendet wird, erhöht sich der Umfang der Zugriffsberechtigungen.

Beispiel: Richtlinienübernahme

Betrachten Sie zum Verständnis der Zulassungsrichtlinienübernahme ein Szenario, in dem Sie einem Nutzer, Raha, zwei verschiedenen IAM-Rollen auf zwei verschiedenen Ebenen in der Ressourcenhierarchie zuweisen.

Um Raha eine Rolle auf Organisationsebene zuzuweisen, legen Sie die folgende Zulassungsrichtlinie für das Projekt fest:

{
  "bindings": [
    {
      "members": [
        "user:[e-mail]"
      ],
      "role": "roles/storage.objectViewer"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Diese Zulassungsrichtlinie gewährt Raha die Rolle des Storage-Objekt-Betrachters (roles/storage.objectViewer), die die Berechtigungen get und list für Projekte und Cloud Storage-Objekte enthält. Da Sie die Zulassungsrichtlinie in Ihrer Organisation festlegen, kann Raha diese Berechtigungen für alle Projekte und alle Cloud Storage-Objekte in Ihrer Organisation verwenden.

Um Raha eine Rolle auf Projektebene zuzuweisen, legen Sie die folgende Zulassungsrichtlinie für das Projekt myproject-123 fest:

{
  "bindings": [
    {
      "members": [
        "user:[e-mail]"
      ],
      "role": "roles/storage.objectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Diese Zulassungsrichtlinie gewährt Raha die Rolle „Storage-Objekt-Ersteller” (roles/storage.objectCreator), mit der sie Cloud Storage-Objekte erstellen kann. Da Sie die Zulassungsrichtlinie für myproject-123 festlegen, kann Raha Cloud Storage-Objekte nur in myproject-123 erstellen.

Nun, da zwei Rollenbindungen Raha den Zugriff auf die Cloud Storage-Zielobjekte unter myproject-123 gewähren, gelten die folgenden Zulassungsrichtlinien:

• Eine Zulassungsrichtlinie auf Organisationsebene gewährt die Berechtigung, alle Cloud Storage-Objekte in dieser Organisation aufzulisten und abzurufen.
• Eine Zulassungsrichtlinie auf Projektebene für das Projekt myproject-123 gewährt die Möglichkeit, Objekte innerhalb dieses Projekts zu erstellen.

In der folgenden Tabelle ist die wirksame Richtlinie von Raha zusammengefasst:

Berechtigungen, die über die Rolle "storage.objectViewer" auf Organisationsebene gewährt wurden	Berechtigungen, die über die Rolle "storage.objectCreator" auf Ebene von "myproject-123" gewährt wurden	Wirksamer Gewährungsbereich für Raha unter "myproject-123"
resourcemanager.projects.get resourcemanager.projects.list storage.objects.get storage.objects.list	resourcemanager.projects.get resourcemanager.projects.list storage.objects.create	resourcemanager.projects.get resourcemanager.projects.list storage.objects.get storage.objects.list storage.objects.create

Richtlinienversionen

Im Laufe der Zeit werden von IAM ggf. neue Funktionen hinzugefügt, durch die wesentliche Felder im Zulassungsrichtlinienschema hinzugefügt oder geändert werden. Solche Änderungen werden in neuen Zulassungsrichtlinienschemaversionen eingeführt, um zu verhindern, dass bestehende Integrationen, die auf Konsistenz in der Zulassungsrichtlinienstruktur angewiesen sind, nicht mehr funktionieren.

Wenn Sie IAM zum ersten Mal einbinden, empfehlen wir die Verwendung der jeweils aktuellsten Version des Zulassungsrichtlinienschemas. Im Folgenden werden die verschiedenen verfügbaren Versionen und deren Verwendung erläutert. Außerdem wird beschrieben, wie Sie die gewünschte Version festlegen, und es werden einige Szenarien zur Fehlerbehebung aufgezeigt.

Jede bestehende Zulassungsrichtlinie gibt ein version-Feld als Teil der Metadaten der Zulassungsrichtlinie an. Betrachten Sie den markierten Bereich unten:

{
  "bindings": [
    {
      "members": [
        "user:[e-mail]"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Dieses Feld gibt die Syntaxschemaversion der Zulassungsrichtlinie an. Jede Version der Zulassungsrichtlinie enthält ein bestimmtes Syntaxschema, das von Rollenbindungen verwendet werden kann. Die neuere Version kann Rollenbindungen mit dem aktuelleren Syntaxschema enthalten, das von älteren Versionen nicht unterstützt wird. Dieses Feld ist nicht nur zur Steuerung des Syntaxschemas für die Zulassungsrichtlinie vorgesehen.

Gültige Richtlinienversionen

Richtlinien können die folgenden Zulassungsrichtlinienversionen verwenden:

Version	Beschreibung
1	Die erste Version des IAM-Syntaxschemas für Richtlinien. Unterstützt die Bindung einer Rolle an ein oder mehrere Hauptkonten. Bedingte Rollenbindungen werden nicht unterstützt.
2	Für die interne Verwendung reserviert.
3	Führt das Feld condition in der Rollenbindung ein, wodurch die Rollenbindung durch kontext- und attributbasierte Regeln eingeschränkt wird. Weitere Informationen finden Sie in der Übersicht zu IAM Conditions.

Richtlinienversion beim Abrufen einer Richtlinie angeben

Wenn Sie eine Zulassungsrichtlinie abrufen, empfehlen wir, bei Verwendung der REST API und der Clientbibliotheken in der Anfrage eine Version der Zulassungsrichtlinie zuzulassen. Wenn eine Anfrage eine Zulassungsrichtlinienversion enthält, geht IAM davon aus, dass der Aufrufer die Features dieser Zulassungsrichtlinienversion kennt und diese korrekt verarbeiten kann.

Hinweis: Wenn Sie die Cloud Console oder die gcloud CLI verwenden, müssen Sie keine Zulassungsrichtlinienversion angeben. Diese Tools legen die Version automatisch fest.

Wenn die Anfrage keine Zulassungsrichtlinienversion angibt, geht IAM davon aus, dass der Aufrufer eine Zulassungsrichtlinie der Version 1 möchte.

Wenn Sie eine Zulassungsrichtlinie erhalten, prüft IAM die Version der Zulassungsrichtlinie in der Anfrage oder die Standardversion, wenn in der Anfrage keine Version angegeben wurde. IAM prüft auch die Zulassungsrichtlinie für Felder, die in einer Zulassungsrichtlinie der Version 1 nicht unterstützt werden. Von diesen Informationen hängt ab, welche Art von Antwort gesendet wird:

• Wenn die Zulassungsrichtlinie keine Bedingungen enthält, gibt IAM immer eine Zulassungsrichtlinie der Version 1 zurück, unabhängig von der Versionsnummer in der Anfrage.
• Wenn die Zulassungsrichtlinie Bedingungen enthält und der Aufrufer eine Zulassungsrichtlinie der Version 3 angefordert hat, gibt IAM eine Richtlinie zur Zulassung der Version 3 zurück, die die Bedingungen umfasst. Ein Beispiel dafür ist das Szenario 1 auf dieser Seite.

• Wenn die Zulassungsrichtlinie Bedingungen enthält und der Aufrufer eine Zulassungsrichtlinie der Version 1 angefordert oder keine Version angegeben hat, gibt IAM eine Zulassungsrichtlinie der Version 1 zurück.

  Bei Rollenbindungen, die eine Bedingung enthalten, hängt IAM den String _withcond_ an den Rollennamen an, gefolgt von einem Hashwert, z. B. roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8. Die Bedingung selbst ist nicht aufgeführt. Ein entsprechendes Beispiel ist das Szenario 2 auf dieser Seite.

Szenario 1: Richtlinienversion, die IAM Conditions vollständig unterstützt

Angenommen, Sie rufen die folgende REST API-Methode auf, um die Zulassungsrichtlinie für ein Projekt abzurufen:

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

Der Anfragetext dafür lautet:

{
  "options": {
    "requestedPolicyVersion": 3
  }
}

Die Antwort enthält die Zulassungsrichtlinie des Projekts. Wenn die Zulassungsrichtlinie mindestens eine bedingte Rollenbindung enthält, wird für das Feld version der Wert 3 festgelegt:

{
  "bindings": [
    {
      "members": [
        "user:[e-mail]"
      ],
      "role": "roles/iam.securityReviewer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression": "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Wenn die Zulassungsrichtlinie keine bedingten Rollenbindungen enthält, wird für das Feld version der Wert 1 eingestellt, auch wenn in der Anfrage die Version 3 angegeben wurde:

{
  "bindings": [
    {
      "members": [
        "user:[e-mail]"
      ],
      "role": "roles/iam.securityReviewer",
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Szenario 2: Richtlinienversion mit eingeschränkter Unterstützung für IAM Conditions

Angenommen, Sie rufen die folgende REST API-Methode auf, um die Zulassungsrichtlinie für ein Projekt abzurufen:

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

Der Anfragetext ist leer, es wird also keine Versionsnummer angegeben. Daher verwendet IAM die Standardversion 1 der Zulassungsrichtlinie.

Die Zulassungsrichtlinie enthält eine bedingte Rollenbindung. Da die Zulassungsrichtlinienversion 1 lautet, wird die Bedingung nicht in der Antwort aufgeführt. Um anzugeben, dass die Rollenbindung eine Bedingung verwendet, hängt IAM den String _withcond_ an den Rollennamen an, gefolgt von einem Hashwert:

{
  "bindings": [
    {
      "members": [
        "user:[e-mail]"
      ],
      "role": "roles/iam.securityReviewer_withcond_58e135cabb940ad9346c"
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Richtlinienversion beim Festlegen einer Richtlinie angeben

Beim Festlegen einer Zulassungsrichtlinie empfehlen wir, eine Version der Zulassungsrichtlinie in der Anfrage anzugeben. Wenn eine Anfrage eine Zulassungsrichtlinienversion enthält, geht IAM davon aus, dass der Aufrufer die Features dieser Zulassungsrichtlinienversion kennt und diese korrekt verarbeiten kann.

Hinweis: Wenn Sie die Cloud Console oder die gcloud CLI verwenden, müssen Sie keine Zulassungsrichtlinienversion angeben. Diese Tools legen die Version automatisch fest.

Wenn in der Anfrage keine Zulassungsrichtlinienversion angegeben ist, akzeptiert IAM nur die Felder, die in einer Zulassungsrichtlinie von Version 1 enthalten sein können. Als Best Practice sollten Sie keine bedingten Rollenbindungen in einer Zulassungsrichtlinie der Version 1 ändern. Da die Richtlinie nicht die Bedingung für die einzelnen Bindungen anzeigt, wissen Sie nicht, wann oder wo die Bindung tatsächlich gewährt wird. Rufen Sie stattdessen die Darstellung der Version 3 der Zulassungsrichtlinie ab, die die Bedingung für jede Rollenbindung angibt, und verwenden Sie diese Darstellung, um die Bindungen zu aktualisieren.

Wichtig: Wenn Sie IAM Conditions verwenden, geben Sie immer die Zulassungsrichtlinienversion 3 an, und fügen Sie immer das Feld etag hinzu, wenn Sie eine Clientbibliothek oder die REST API verwenden, um eine Zulassungsrichtlinie festzulegen. Wenn Sie das Feld etag weglassen, können Sie in IAM eine Zulassungsrichtlinie der Version 3 mit einer Zulassungsrichtlinie der Version 1 überschreiben, wodurch alle Bedingungen aus der Zulassungsrichtlinie gelöscht werden.

Szenario: Richtlinienversionen in Anfragen und Antworten

Angenommen, Sie verwenden die REST API, um eine Zulassungsrichtlinie abzurufen, und geben in der Anfrage die Version 3 an. Die Antwort enthält die folgende Zulassungsrichtlinie, die die Version 3 verwendet:

{
  "bindings": [
    {
      "members": [
        "user:[e-mail]"
      ],
      "role": "roles/storage.admin",
      "condition": {
          "title": "Weekday_access",
          "description": "Monday thru Friday access only in America/Chicago",
          "expression": "request.time.getDayOfWeek('America/Chicago') >= 1 && request.time.getDayOfWeek('America/Chicago') <= 5"
      }
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

[e-mail] soll nun während der gesamten Woche die Rolle des Storage-Administrators (roles/storage.admin) haben und nicht nur an bestimmten Wochentagen. Sie entfernen dafür die Bedingung aus der Rollenbindung und senden eine REST API-Anfrage, um die Zulassungsrichtlinie festzulegen. In der Anfrage geben Sie noch einmal die Version 3 an:

{
  "bindings": [
    {
      "members": [
        "user:[e-mail]"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

Die Antwort enthält die aktualisierte Zulassungsrichtlinie:

{
  "bindings": [
    {
      "members": [
        "user:[e-mail]"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwWd8I+ZUAQ=",
  "version": 1
}

Die Zulassungsrichtlinie in der Antwort verwendet die Version 1, obwohl in der Anfrage die Version 3 angegeben wurde. Dies liegt daran, dass die Zulassungsrichtlinie nur Felder verwendet, die in einer Version 1 unterstützt werden.

Richtlinien mit gelöschten Hauptkonten

Wenn eine Rollenbindung in einer Zulassungsrichtlinie ein gelöschtes Hauptkonto enthält und Sie eine Rollenbindung für ein neues Hauptkonto mit demselben Namen hinzufügen, wird die Rollenbindung immer auf das neue Hauptkonto angewendet.

Ziehen Sie beispielsweise diese Zulassungsrichtlinie in Erwägung, die eine Rollenbindung an den gelöschten Nutzer [e-mail] und das gelöschte Dienstkonto [e-mail] enthält: Die Kennung jedes Hauptkontos hat daher das Präfix deleted::

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:[e-mail]?uid=123456789012345678901",
        "deleted:user:[e-mail]?uid=234567890123456789012"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Angenommen, Sie erstellen einen neuen Nutzer, der auch [e-mail] genannt wird, und Sie möchten die Rolle "Projektersteller" (roles/resourcemanager.projectCreator) zuweisen, mit der Hauptkonten Google Cloud-Projekte für den neuen Nutzer erstellen können. Aktualisieren Sie die Zulassungsrichtlinie wie in diesem Beispiel, um dem neuen Nutzer die Rolle zuzuweisen:

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:[e-mail]?uid=123456789012345678901",
        "deleted:user:[e-mail]?uid=234567890123456789012"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:[e-mail]"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Für eine einfachere Prüfung Ihrer IAM-Zulassungsrichtlinien können Sie den gelöschten Nutzer auch von der Bindung an die Rolle „Inhaber“ entfernen:

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:[e-mail]?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:[e-mail]"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Hinweis: Wenn Sie ein gelöschtes Hauptkonto aus einer Rollenbindung entfernen und das Hauptkonto dann wiederherstellen, wird das Hauptkonto nicht wieder der Rollenbindung hinzugefügt.

Best Practices für Richtlinien

Die folgenden Best Practices gelten für Organisationen mit vielen Google Cloud-Nutzern:

• Wenn Sie mehrere Nutzerkonten mit denselben Zugriffskonfigurationen verwalten, verwenden Sie stattdessen Google-Gruppen. Fügen Sie jedes einzelne Nutzerkonto in die Gruppe ein und gewähren Sie die gewünschten Rollen der Gruppe statt einzelnen Nutzerkonten.

• Auf Organisationsebene gewährte Rollen: Überlegen Sie sorgfältig, welchen Hauptkonten Rollen auf Organisationsebene zugewiesen werden sollen. Für die meisten Organisationen sollten nur wenige bestimmte Teams (z. B. Sicherheits- und Netzwerkteams) Zugriff auf dieser Ebene der Ressourcenhierarchie erhalten.

• Auf Ordnerebene gewährte Rollen: Sie können die Betriebsstruktur Ihrer Organisation mithilfe von Ordnerebenen darstellen. Dabei kann jeder Ordner mit verschiedenen Gruppen von Zugriffsberechtigungen konfiguriert werden, die den Geschäfts- und Betriebsanforderungen entsprechen. Beispiel: Ein übergeordneter Ordner kann eine Abteilung darstellen, einer der untergeordneten Ordner kann den Ressourcenzugriff und den Betrieb durch eine Gruppe widerspiegeln und ein anderer untergeordneter Ordner kann ein kleines Team darstellen. Beide dieser Ordner können Projekte enthalten, die für das jeweilige Team benötigt werden. Eine solche Verwendung von Ordnern kann eine geeignete Zugriffstrennung sicherstellen, wobei die von den übergeordneten Ordnern und der Organisation übernommenen Zulassungsrichtlinien berücksichtigt werden. Diese Vorgehensweise erfordert weniger Wartung von Zulassungsrichtlinien beim Erstellen und Verwalten von Google Cloud-Ressourcen.

• Auf Projektebene gewährte Rollen: Gewähren Sie Rollenbindungen auf Projektebene, wenn dies nach dem Prinzip der geringsten Berechtigung erforderlich ist. Wenn ein Hauptkonto beispielsweise Zugriff auf drei der zehn Projekte in einem Ordner benötigt, sollten Sie jedem der drei Projekte einzeln Zugriff gewähren. Wenn Sie hingegen eine Rolle für den Ordner zugewiesen haben, erhält das Hauptkonto auf sieben Projekte Zugriff, den es nicht benötigt.

  Alternativ können Sie IAM Conditions verwenden, um Rollen auf Organisations- oder Ordnerebene zu gewähren, jedoch nur für eine Teilmenge von Ordnern oder Projekten.

• Nur Hauptkonten innerhalb Ihrer Domain Zugriff gewähren: Um die Sicherheit Ihrer Organisation zu verbessern, sollten Sie Hauptkonten außerhalb Ihrer Domain keine Rollen zuweisen. Sie können diese Best Practice erzwingen, indem Sie die Einschränkung der Organisationsrichtlinie iam.allowedPolicyMemberDomains erzwingen.

  Hinweis: Wenn Ihre Organisation am oder nach dem 3. Mai 2024 erstellt wurde, wird diese Einschränkung standardmäßig erzwungen. Ihre Domain ist dann der einzige zulässige Wert.

Nächste Schritte

• Mehr über Fehlerbehebung bei Zulassungsrichtlinien, die den String withcond in Rollennamen enthalten, erfahren
• Rollenbindungen in einer Zulassungsrichtlinie verwalten
• Übersicht über IAM Conditions, die Zulassungsrichtlinien der Version 3 verwenden
• Mehr über die Policy Intelligence Tools erfahren, mit denen Sie Ihre Zulassungsrichtlinien nachvollziehen und verwalten können, um Ihre Sicherheitskonfiguration proaktiv zu verbessern.
• Verwenden Sie die Cloud Asset API, um Zulassungsrichtlinien zu suchen.
• Verwenden Sie die Cloud Asset API, um effektive Zulassungsrichtlinien aufzurufen.