Überblick

Auf dieser Seite werden die grundlegenden Konzepte von Cloud Identity and Access Management (Cloud IAM) beschrieben.

Mit Cloud IAM können Sie detaillierte Zugriffsberechtigungen auf bestimmte Ressourcen der Google Cloud gewähren und unerwünschten Zugriff auf andere Ressourcen verhindern. So können Sie z. B. das Sicherheitsprinzip der geringsten Berechtigung anwenden, also nur die minimal notwendigen Berechtigungen für den Zugriff auf bestimmte Ressourcen gewähren.

Funktionsweise von Cloud IAM

Mit Cloud IAM verwalten Sie die Zugriffssteuerung. Sie legen fest, wer (Identität) welchen Zugriff (Rolle) auf welche Ressource hat. VM-Instanzen von Google Compute Engine, GKE-Cluster (Google Kubernetes Engine) und Cloud Storage-Buckets sind z. B. Google Cloud-Ressourcen. Die Organisationen, Ordner und Projekte, mit denen Sie Ihre Ressourcen organisieren, sind ebenfalls Ressourcen.

In Cloud IAM wird dem Endnutzer die Berechtigung für den Zugriff auf eine Ressource nicht direkt gewährt. Stattdessen werden Berechtigungen in Rollen gruppiert und die Rollen authentifizierten Mitgliedern zugewiesen. In einer Cloud IAM-Richtlinie wird festgelegt und erzwungen, welche Rollen welchen Mitgliedern gewährt werden. Diese Richtlinie ist mit einer Ressource verknüpft. Wenn ein authentifiziertes Mitglied versucht, auf eine Ressource zuzugreifen, prüft Cloud IAM die Richtlinie der Ressource, um festzustellen, ob die Aktion zulässig ist.

Das folgende Diagramm veranschaulicht die Berechtigungsverwaltung in Cloud IAM.

Cloud IAM-Architektur.

Dieses Modell für die Zugriffsverwaltung besteht aus drei Hauptabschnitten:

  • Mitglied: Ein Mitglied kann ein Google-Konto (für Endnutzer), ein Dienstkonto (für Anwendungen und virtuelle Maschinen), eine Google-Gruppe oder eine G Suite- oder Cloud Identity-Domain sein, die auf eine Ressource zugreifen kann. Die Identität eines Mitglieds ist eine E-Mail-Adresse, die mit einem Nutzer, einem Dienstkonto oder einer Google-Gruppe verknüpft ist, oder ein Domainname, der mit G Suite- oder Cloud Identity-Domains verknüpft ist.
  • Rolle: Eine Rolle ist eine Sammlung von Berechtigungen. Berechtigungen bestimmen, welche Vorgänge bei einer Ressource zugelassen sind. Wenn Sie einem Mitglied eine Rolle zuweisen, gewähren Sie alle mit ihr verknüpften Berechtigungen.
  • Richtlinie: Die Cloud IAM-Richtlinie bindet ein Mitglied oder mehrere Mitglieder an eine Rolle. Wenn Sie festlegen möchten, wer (Mitglied) welche Art von Zugriff (Rolle) auf eine Ressource hat, erstellen Sie eine Richtlinie und verknüpfen sie mit der Ressource.

Im vorhergehenden Diagramm bindet beispielsweise die Cloud IAM-Richtlinie den Endnutzer, der mit userid@gmail.com angegeben ist, an die Rolle "App Engine-Administrator" (roles/appengine.appAdmin). Wird die Richtlinie mit einem Projekt verknüpft, hat der Nutzer die Rolle "App Engine-Administrator" innerhalb dieses Projekts. In diesem Fall kann der Nutzer alle Anwendungskonfigurationen und -einstellungen für App Engine auf Projektebene aufrufen, erstellen und aktualisieren.

Nachstehend werden diese Konzepte detaillierter beschrieben.

In Cloud IAM gewähren Sie Mitgliedern Zugriff. Folgende Arten von Mitgliedern sind zulässig:

  • Google-Konto
  • Dienstkonto.
  • Google-Gruppe
  • G Suite-Domain
  • Cloud Identity-Domain

Google-Konto

Ein Google-Konto stellt einen Entwickler, einen Administrator oder eine andere Person dar, die mit Google Cloud interagiert. Jede E-Mail-Adresse, die mit einem Google-Konto verknüpft ist, kann eine Identität sein, einschließlich gmail.com oder anderer Domains. Neue Nutzer können sich für ein Google-Konto anmelden, wenn sie die Registrierungsseite für das Google-Konto aufrufen.

Dienstkonto

Ein Dienstkonto ist ein Konto für eine Anwendung und nicht für einen einzelnen Endnutzer. Wenn Sie Code ausführen, der in Google Cloud gehostet wird, wird der Code unter dem von Ihnen angegebenen Konto ausgeführt. Sie können so viele Dienstkonten erstellen, wie erforderlich sind, um die verschiedenen logischen Komponenten Ihrer Anwendung zu repräsentieren. Weitere Informationen zur Verwendung eines Dienstkontos in Ihrer Anwendung finden Sie unter Erste Schritte bei der Authentifizierung.

Google-Gruppe

Eine Google-Gruppe ist eine benannte Sammlung von Google-Konten und Dienstkonten. Jede Google-Gruppe hat eine eindeutige E-Mail-Adresse, die mit der Gruppe verknüpft ist. Die E-Mail-Adresse, die mit einer Google-Gruppe verknüpft ist, finden Sie auf der Startseite der jeweiligen Google-Gruppe unter Info. Weitere Informationen zu Google-Gruppen finden Sie auf der Startseite von Google-Gruppen.

Google-Gruppen sind eine praktische Möglichkeit, um einer Reihe von Nutzern Zugriffsrichtlinien zuzuweisen. Sie können die Zugriffssteuerungen für eine ganze Gruppe auf einmal gewähren oder ändern, anstatt sie nacheinander für jeden einzelnen Nutzer oder jedes Dienstkonto individuell zu gewähren oder zu ändern. Sie können auch einfach Mitglieder zu einer Google-Gruppe hinzufügen oder aus ihr entfernen, anstatt Cloud IAM-Richtlinien zu aktualisieren, um Nutzer hinzuzufügen oder zu entfernen.

Google-Gruppen haben keine Anmeldedaten. Außerdem können Sie Google-Gruppen nicht zum Feststellen der Identität für eine Anfrage zum Zugriff auf eine Ressource verwenden.

G Suite-Domain

Eine G Suite-Domain repräsentiert eine virtuelle Gruppe aller Google-Konten, die im G Suite-Konto einer Organisation erstellt wurden. G Suite-Domains repräsentieren den Internetdomainnamen Ihrer Organisation, (z. B. example.com). Wenn Sie Ihrer G Suite-Domain einen Nutzer hinzufügen, wird für den Nutzer innerhalb dieser virtuellen Gruppe ein neues Google-Konto erstellt (z. B. username@example.com).

Wie Google-Gruppen können G Suite-Domains nicht zum Feststellen der Identität verwendet werden. Sie ermöglichen aber eine effektive Berechtigungsverwaltung.

Cloud Identity-Domain

Eine Cloud Identity-Domain ähnelt einer G Suite-Domain, weil sie eine virtuelle Gruppe aller Google-Konten in einer Organisation repräsentiert. Nutzer einer Cloud Identity-Domain haben jedoch keinen Zugriff auf Anwendungen und Funktionen der G Suite. Unter Was ist Cloud Identity? erfahren Sie mehr zu diesem Thema.

allAuthenticatedUsers

Der Wert allAuthenticatedUsers ist eine spezielle Kennzeichnung für alle Dienstkonten und alle Nutzer im Internet, die sich mit einem Google-Konto authentifiziert haben. Diese Kennzeichnung schließt auch Konten ein, die nicht mit einer G Suite- oder Cloud Identity-Domain verbunden sind, z. B. persönliche Gmail-Konten. Nicht authentifizierte Nutzer, wie anonyme Besucher, sind nicht eingeschlossen.

allUsers

Der Wert allUsers ist eine spezielle Kennzeichnung für alle Internetnutzer, einschließlich authentifizierter und nicht authentifizierter Nutzer.

Wenn ein authentifiziertes Mitglied versucht, auf eine Ressource zuzugreifen, prüft Cloud IAM die Cloud IAM-Richtlinie der Ressource, um festzustellen, ob die Aktion zulässig ist.

In diesem Abschnitt werden die Entitäten und Konzepte beschrieben, die für die Autorisierung relevant sind.

Ressource

Wenn ein Nutzer Zugriff auf eine bestimmte Google Cloud-Ressource benötigt, können Sie ihm eine Rolle für diese Ressource zuweisen. Beispiele für Ressourcen sind Projekte, Compute Engine-Instanzen und Cloud Storage-Buckets.

Einige Dienste unterstützen IAM-Berechtigungen mit feineren Abstufungen, als dies auf Projektebene möglich ist. Beispielsweise können Sie einem Nutzer für einen bestimmten Cloud Storage-Bucket die Rolle "Storage-Administrator" (roles/storage.admin) oder für eine bestimmte Compute Engine-Instanz die Rolle "Compute-Instanzadministrator" (roles/compute.instanceAdmin) zuweisen.

In anderen Fällen kann es sinnvoll sein, Cloud IAM-Berechtigungen auf Projektebene zu erteilen. Diese Berechtigungen werden dann von allen Ressourcen im jeweiligen Projekt übernommen. Wenn Sie beispielsweise Zugriff auf alle Cloud Storage-Buckets in einem Projekt gewähren möchten, erteilen Sie keinen gesonderten Zugriff auf jeden einzelnen Bucket, sondern auf das Projekt, das die Buckets enthält. Genauso verhält es sich, wenn auf alle Compute Engine-Instanzen in einem Projekt zugegriffen werden soll: Sie erteilen den Zugriff auf das Projekt und nicht auf jede einzelne Instanz.

Informationen dazu, welche Rollen für welche Ressourcen zugewiesen werden können, finden Sie unter Informationen zu Rollen in der Spalte Niedrigste Ressource für einzelne Rollen.

Berechtigungen

Berechtigungen bestimmen, welche Vorgänge bei einer Ressource zugelassen sind. In Cloud IAM werden Berechtigungen so dargestellt: <service>.<resource>.<verb>. Beispiel: pubsub.subscriptions.consume.

Berechtigungen entsprechen oft eins zu eins den REST API-Methoden. Das bedeutet, dass jedem Google Cloud-Dienst eine Reihe von Berechtigungen für jede bereitgestellte REST API-Methode zugeordnet ist. Der Aufrufer dieser Methode braucht die entsprechenden Berechtigungen. Wenn Sie beispielsweise "Pub/Sub" verwenden und die Methode topics.publish() aufrufen müssen, benötigen Sie die Berechtigung pubsub.topics.publish für dieses Thema.

Sie weisen Nutzern Berechtigungen nicht direkt zu. Stattdessen legen Sie Rollen fest, die die entsprechenden Berechtigungen umfassen, und weisen diese dann dem Nutzer zu.

Rollen

Eine Rolle ist eine Sammlung von Berechtigungen. Sie können dem Nutzer eine Berechtigung nicht direkt zuweisen. Stattdessen weisen Sie ihm eine Rolle zu. Wenn Sie einem Nutzer eine Rolle zuweisen, erhält er alle mit ihr verknüpften Berechtigungen.

Berechtigung zur Rollenzuordnung

Es gibt drei Arten von Rollen in Cloud IAM:

  • Einfache Rollen: Dies sind Rollen, die zuvor schon in der Google Cloud Console verfügbar waren. Diese Rollen heißen "Inhaber", "Bearbeiter" und "Betrachter". Sie sollten diese Rollen nach Möglichkeit nicht verwenden, da sie eine Vielzahl von Berechtigungen für alle Google Cloud-Dienste umfassen.

  • Vordefinierte Rollen: Dies sind Rollen, die eine feiner abgestufte Zugriffssteuerung ermöglichen als die einfachen Rollen. Beispielsweise ermöglicht die vordefinierte Rolle Pub/Sub-Publisher (roles/pubsub.publisher) ausschließlich Zugriff für die Veröffentlichung von Nachrichten in einem Cloud Pub/Sub-Thema.

  • Benutzerdefinierte Rollen: Dies sind Rollen, die Sie erstellen, um Berechtigungen an die Anforderungen Ihrer Organisation anzupassen, wenn diese durch vordefinierte Rollen nicht erfüllt werden.

Informationen zum Zuweisen von Rollen an Nutzer finden Sie unter Zugriff erteilen, ändern und entziehen. Informationen zu verfügbaren vordefinierten Cloud IAM-Rollen finden Sie unter Informationen zu Rollen. Weitere Informationen zu benutzerdefinierten Rollen finden Sie unter Informationen zu benutzerdefinierten IAM-Rollen und Benutzerdefinierte Rollen erstellen und verwalten.

Cloud IAM-Richtlinie

Sie können Nutzern Rollen zuweisen, indem Sie Cloud IAM-Richtlinien erstellen. Dabei handelt es sich um Festlegungen, mit denen der Zugriff für verschiedene Personen zugewiesen wird. Richtlinien werden mit einer Ressource verbunden und erfordern eine Zugriffssteuerung, wenn auf diese Ressource zugegriffen wird.

Cloud IAM-Richtlinie

Eine Cloud IAM-Richtlinie wird durch das Cloud IAM-Objekt Policy dargestellt. Ein Cloud IAM-Objekt Policy besteht aus einer Liste von Bindungen. Ein Binding bindet eine Liste von members an eine role.

  • role: Das ist die Rolle, die Sie dem Mitglied zuweisen möchten. role wird in der Form roles/service.roleName angegeben. Cloud Storage bietet beispielsweise die Rollen roles/storage.objectAdmin, roles/storage.objectCreator und roles/storage.objectViewer.

  • members: Eine Liste mit einer oder mehreren Identitäten, wie im Abschnitt Identitätskonzepte in diesem Dokument beschrieben. Jeder Mitgliedstyp ist mit einem Präfix gekennzeichnet, z. B. ein Google-Konto (user:), ein Dienstkonto (serviceAccount:), eine Google-Gruppe (group:) oder eine G Suite- oder Cloud Identity-Domain (domain:). Im folgenden Beispiel-Code-Snippet wird die Rolle storage.objectAdmin den folgenden Mitgliedern mit dem entsprechenden Präfix zugewiesen: user:alice@example.com, serviceAccount:my- other-app@appspot.gserviceaccount.com, group:admins@example.com und domain:google.com. Die Rolle objectViewer wird user:bob@example.com zugewiesen.

Das folgende Code-Snippet zeigt die Struktur einer Cloud IAM-Richtlinie.

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
       "members": [
         "user:alice@example.com",
         "serviceAccount:my-other-app@appspot.gserviceaccount.com",
         "group:admins@example.com",
         "domain:google.com"
       ]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:bob@example.com"
      ]
    }
  ]
}

Cloud IAM- und Richtlinien-APIs

Cloud IAM bietet verschiedene Methoden, mit denen Sie Zugriffssteuerungsrichtlinien für Google Cloud-Ressourcen erstellen und verwalten können. Diese Methoden werden von den Diensten bereitgestellt, die Cloud IAM unterstützen. Beispielsweise werden die Cloud IAM-Methoden durch die Resource Manager API, die Pub/Sub API und die Cloud Life Sciences APIs bereitgestellt.

Die Cloud IAM-Methoden sind:

  • setIamPolicy(): Legt Richtlinien für Ihre Ressourcen fest.
  • getIamPolicy(): Ruft eine zuvor festgelegte Richtlinie ab.
  • testIamPermissions(): Testet, ob der Aufrufer die angegebenen Berechtigungen für eine Ressource hat.

Sie finden die API-Referenzthemen für diese Methoden in der Dokumentation für jeden Dienst, der Cloud IAM unterstützt.

Richtlinienhierarchie

Google Cloud-Ressourcen sind hierarchisch organisiert:

  • Die Organisation ist der Stammknoten in der Hierarchie.
  • Ordner sind untergeordnete Elemente der Organisation.
  • Projekte sind untergeordnete Elemente der Organisation oder eines Ordners.
  • Die Ressourcen für jeden Dienst sind Projekten untergeordnet.

Jeder Ressource ist genau ein Element übergeordnet. Weitere Informationen finden Sie unter Ressourcenhierarchie in Resource Manager.

Im folgenden Diagramm ist ein Beispiel für eine Google Cloud-Ressourcenhierarchie dargestellt.

Hierarchie für Cloud IAM-Ressourcen.

Sie können eine Cloud IAM-Richtlinie auf einer beliebigen Ebene der Ressourcenhierarchie festlegen: der Organisationsebene, der Ordnerebene, der Projektebene oder der Ressourcenebene. Ressourcen erben die Richtlinien der übergeordneten Ressource. Wenn Sie eine Richtlinie auf Organisationsebene festlegen, wird sie automatisch von allen untergeordneten Projekten übernommen. Wenn Sie eine Richtlinie auf Projektebene festlegen, wird sie von allen untergeordneten Ressourcen übernommen. Die resultierenden Richtlinien für eine Ressource sind die Kombination aus der für diese Ressource festgelegten Richtlinie und der von ihrem übergeordneten Element übernommenen Richtlinie.

Diese Richtlinienübernahme ist transitiv. Dies bedeutet, dass Ressourcen Richtlinien vom Projekt übernehmen, das wiederum Richtlinien von Ordnern übernimmt, die ihrerseits Richtlinien von der Organisation übernehmen. Daher gelten Richtlinien auf Organisationsebene auch auf Ressourcenebene.

Beispiel: Im obigen Diagramm ist topic_a eine Pub/Sub-Ressource, unter dem Projekt example-prod. Wenn Sie michael@example.com die Bearbeiterrolle für example-prod und andreas@example.com die Publisher-Rolle für topic_a zuweisen, erteilen Sie damit michael@example.com die Bearbeiterrolle für topic_a und andreas@example.com die Publisher-Rolle.

Für die Cloud IAM-Richtlinienhierarchie gelten dieselben Regeln wie für die Google Cloud-Ressourcenhierarchie. Wenn Sie die Ressourcenhierarchie ändern, ändert sich auch die Richtlinienhierarchie. Wenn Sie beispielsweise ein Projekt in eine Organisation verschieben, wird die Cloud IAM-Richtlinie des Projekts mit dem Inhalt der Cloud IAM-Richtlinie der Organisation aktualisiert.

Mit untergeordneten Richtlinien kann nicht der Zugriff eingeschränkt werden, der auf höherer Ebene gewährt wurde. Wenn Sie beispielsweise einem Nutzer für ein Projekt die Bearbeiterrolle und demselben Nutzer die Betrachterrolle für eine untergeordnete Ressource zuweisen, hat der Nutzer weiterhin die Bearbeiterrolle für die untergeordnete Ressource.

Cloud IAM-Support für Google Cloud-Dienste

Bei Cloud IAM wird jede API-Methode für alle Google Cloud-Dienste überprüft, damit das Konto, das die API-Anfrage durchführt, auch die entsprechende Berechtigung zur Verwendung der Ressource hat.

Vor Cloud IAM konnten Sie nur Inhaber-, Bearbeiter- oder Betrachterrollen gewähren. Diese Rollen bieten einen sehr breitgefächerten Zugriff auf ein Projekt und lassen keine fein abgestufte Aufgabentrennung zu. Google Cloud-Dienste stellen jetzt weitere vordefinierte Rollen bereit, die eine genauere Zugriffssteuerung als die Rollen "Inhaber", "Bearbeiter" und "Betrachter" ermöglichen. Zum Beispiel bietet Compute Engine Rollen wie "Instanzadministrator" und "Netzwerkadministrator", und App Engine bietet Rollen wie "App-Administrator" und "Dienstadministrator". Diese vordefinierten Rollen sind zusätzlich zu den einfachen Rollen "Inhaber", "Bearbeiter" und "Betrachter" verfügbar.

Vordefinierte Rollen sind für die meisten Google Cloud-Dienste verfügbar. Ausführliche Informationen finden Sie in der Liste aller vordefinierten Rollen. Wenn Sie noch mehr Kontrolle über Berechtigungen benötigen, sollten Sie vielleicht eine benutzerdefinierte Rolle erstellen.

Sie können Nutzern bestimmte Rollen für den Zugriff auf Ressourcen mit feineren Abstufungen als auf Projektebene zuweisen. Sie können beispielsweise eine Cloud IAM-Zugriffssteuerungsrichtlinie erstellen, die einem Nutzer die Abonnentenrolle für ein bestimmtes Pub/Sub-Thema zuweist. In der Liste aller vordefinierten Rollen wird der Ressourcentyp mit der niedrigsten Berechtigung oder detailliertesten Differenzierung angezeigt, der die einzelnen Rollen akzeptiert.

Weitere Informationen