Übersicht

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

Mit IAM können Sie detaillierte Zugriffsberechtigungen auf bestimmte Ressourcen von Google Cloud gewähren und unerwünschten Zugriff auf andere Ressourcen verhindern. Sie haben mit IAM die Möglichkeit, das Sicherheitsprinzip der geringsten Berechtigung anzuwenden, das besagt, dass niemand mehr Berechtigungen haben sollte, als er tatsächlich benötigt.

Funktionsweise von IAM

Mit 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 IAM wird dem Endnutzer die Berechtigung für den Zugriff auf eine Ressource nicht direkt gewährt. Stattdessen werden Berechtigungen in Rollen gruppiert, die dann authentifizierten Hauptkonten zugewiesen werden. In der Vergangenheit bezeichnete IAM die Hauptkonten häufig als Mitglieder. In einigen APIs wird dieser Begriff weiterhin verwendet.

In einer IAM-Richtlinie wird festgelegt und erzwungen, welche Rollen welchen Hauptkonten gewährt werden. Diese Richtlinie wird einer Ressource zugeordnet. Wenn ein authentifiziertes Hauptkonto versucht, auf eine Ressource zuzugreifen, prüft IAM die Richtlinie der Ressource, um festzustellen, ob die Aktion zulässig ist.

Im folgenden Diagramm wird die Berechtigungsverwaltung in IAM veranschaulicht.

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

  • Hauptkonto. Ein Hauptkonto kann ein Google-Konto (für Endnutzer), ein Dienstkonto (für Anwendungen und Arbeitslasten), eine Google-Gruppe oder ein Google Workspace-Konto oder eine Cloud Identity-Domain sein, die auf eine Ressource zugreifen können. Die Identität eines Hauptkontos ist eine E-Mail-Adresse, die mit einem Nutzer, einem Dienstkonto oder einer Google-Gruppe verknüpft ist, oder ein Domain-Name, der mit einem Google Workspace-Konto oder einer Cloud Identity-Domain verknüpft ist.
  • Rolle: Eine Rolle ist eine Sammlung von Berechtigungen. Berechtigungen bestimmen, welche Vorgänge bei einer Ressource zugelassen sind. Wenn Sie einem Hauptkonto eine Rolle zuweisen, gewähren Sie alle mit ihr verknüpften Berechtigungen.
  • Richtlinie: Die IAM-Richtlinie umfasst eine Reihe von Rollenbindungen, die ein oder mehrere Hauptkonten an einzelne Rollen binden. Wenn Sie festlegen möchten, wer (Hauptkonto) welche Art von Zugriff (Rolle) auf eine Ressource hat, erstellen Sie eine Richtlinie und verknüpfen sie mit der Ressource.

Im vorhergehenden Diagramm bindet z. B. die IAM-Richtlinie Hauptkonten wie user@example.com an Rollen wie die App Engine-Administratorrolle (roles/appengine.appAdmin). Wenn die Richtlinie an ein Projekt angehängt ist, erhalten die Hauptkonten die angegebenen Rollen innerhalb des Projekts.

Nachstehend werden diese Konzepte detaillierter beschrieben.

In IAM gewähren Sie Hauptkonten Zugriff. Folgende Typen von Hauptkonten sind möglich:

  • Google-Konto
  • Dienstkonto
  • Google-Gruppe
  • Google Workspace-Konto
  • Cloud Identity-Domain
  • Alle authentifizierten Nutzer
  • Alle Nutzer

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 oder Compute-Arbeitslast anstelle eines einzelnen Endnutzers. 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 mühelos Hauptkonten zu einer Google-Gruppe hinzufügen oder aus ihr entfernen. Das ist einfacher, als 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.

Google Workspace-Konto

Ein Google Workspace-Konto stellt eine virtuelle Gruppe aller Google-Konten dar, die es enthält. Google Workspace-Konten sind mit dem Internetdomainnamen Ihrer Organisation verknüpft, z. B. example.com. Wenn Sie ein Google-Konto für einen neuen Nutzer erstellen, z. B. username@example.com, wird dieses Google-Konto der virtuellen Gruppe für Ihr Google Workspace-Konto hinzugefügt.

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

Cloud Identity-Domain

Eine Cloud Identity-Domain ähnelt einem Google Workspace-Konto, 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 Features von Google Workspace. Unter Was ist Cloud Identity? erfahren Sie mehr zu diesem Thema.

Alle authentifizierten Nutzer

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 einem Google Workspace-Konto oder einer Cloud Identity-Domain verbunden sind, z. B. persönliche Gmail-Konten. Nicht authentifizierte Nutzer, wie anonyme Besucher, sind nicht eingeschlossen.

Einige Ressourcentypen unterstützen diesen Hauptkontotyp nicht.

Alle Nutzer

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

Einige Ressourcentypen unterstützen diesen Hauptkontotyp nicht.

Wenn ein authentifiziertes Hauptkonto versucht, auf eine Ressource zuzugreifen, prüft IAM anhand der IAM-Richtlinie der Ressource, 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 können Sie IAM-Berechtigungen auf Projektebene 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 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. Eine Liste aller verfügbaren Berechtigungen zusammen mit ihren Rollen finden Sie in der Referenz zu Berechtigungen.

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

In IAM gibt es verschiedene Arten von Rollen:

  • Einfache Rollen: Dies sind Rollen, die zuvor schon in der Google Cloud Console verfügbar waren. Diese Rollen heißen "Inhaber", "Bearbeiter" und "Betrachter".

  • 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.

Weitere Informationen zu Rollen finden Sie in den folgenden Ressourcen:

IAM-Richtlinie

Sie können Nutzern durch Erstellen von IAM-Richtlinien Rollen zuweisen. Diese Richtlinien sind 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.

IAM-Richtlinie.

Eine IAM-Richtlinie wird durch das IAM-Objekt Policy dargestellt. Ein Policy-Objekt in IAM besteht aus einer Liste von Rollenbindungen. Eine Rollenbindung bindet mehrere in einer Liste aufgeführte Hauptkonten an eine Rolle.

  • role: Das ist die Rolle, die Sie dem Hauptkonto 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 Hauptkonten, wie im Abschnitt Identitätskonzepte in diesem Dokument beschrieben. Jeder Hauptkontotyp ist mit einem Präfix gekennzeichnet: ein Google-Konto mit user:, ein Dienstkonto mit serviceAccount:, eine Google-Gruppe mit group:, ein Google Workspace-Konto oder eine Cloud Identity-Domain mit domain:. Im folgenden Beispiel-Code-Snippet wird die Rolle storage.objectAdmin den folgenden Hauptkonten mit dem entsprechenden Präfix zugewiesen: user:ali@example.com, serviceAccount:my-other-app@appspot.gserviceaccount.com, group:admins@example.com und domain:google.com. Die Rolle objectViewer wird user:maria@example.com zugewiesen.

Das folgende Code-Snippet veranschaulicht die Struktur einer IAM-Richtlinie.

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

IAM und Richtlinien-APIs

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

Die Methoden von IAM sind die folgenden:

  • 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 IAM unterstützt.

Ressourcenhierarchie

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 IAM-Ressourcen.

Sie können eine IAM-Richtlinie auf jeder Ebene der Ressourcenhierarchie festlegen: der Organisationsebene, der Ordnerebene, der Projektebene oder der Ressourcenebene. Ressourcen übernehmen die Richtlinien aller ihrer übergeordneten Ressourcen. Die geltende Richtlinie für eine Ressource ist die Kombination aus der für diese Ressource festgelegten Richtlinie und der Richtlinien, die von weiter oben in der Hierarchie übernommen werden.

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.

Die Richtlinien für untergeordnete Ressourcen übernehmen die Richtlinien für ihre übergeordneten Ressourcen. 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. Wenn Sie die Ressourcenhierarchie ändern, ändert sich auch die Richtlinienübernahme. Wenn Sie beispielsweise ein Projekt in eine Organisation verschieben, übernimmt das Projekt Richtlinien von der IAM-Richtlinie der Organisation.

IAM-Unterstützung für Google Cloud-Dienste

In IAM wird jede API-Methode in allen Google Cloud-Diensten geprüft, um dafür zu sorgen, dass das Konto, das die API-Anfrage stellt, die entsprechende Berechtigung zur Verwendung der Ressource hat.

Google Cloud-Dienste bieten vordefinierte Rollen, die eine detaillierte Zugriffssteuerung ermöglichen. Compute Engine bietet beispielsweise Rollen wie Compute-Instanzadministrator und Compute-Netzwerkadministrator. App Engine bietet beispielsweise Rollen wie App Engine-Administrator und App Engine-Dienstadministrator.

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, können Sie 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 IAM-Zugriffssteuerungsrichtlinie erstellen, die einem Nutzer die Rolle "Abonnent" 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.

Konsistenzmodell für die IAM API

Wenn Sie Daten aus der IAM API lesen, unterliegt jeder Lesevorgang Eventual Consistency. Wenn Sie also Daten mit der IAM API schreiben und diese dann sofort lesen, gibt der Lesevorgang möglicherweise eine ältere Version der Daten zurück. Nach einer kurzen Verzögerung können Sie die neue Version der Daten lesen. Diese Verzögerung wird normalerweise in Sekunden und nicht in Minuten gemessen.

Im Gegensatz dazu ist das Schreiben von Daten in die IAM API sequenziell konsistent. Mit anderen Worten, Schreibvorgänge werden immer in der Reihenfolge verarbeitet, in der sie empfangen wurden.

Diese Konsistenzmodelle wirken sich darauf aus, wie die IAM API funktioniert. Wenn Sie beispielsweise ein Dienstkonto erstellen und dann in einer anderen Anfrage sofort auf dieses Dienstkonto verweisen, wird in der IAM API möglicherweise angezeigt, dass das Dienstkonto nicht gefunden wurde. Dieses Verhalten tritt auf, weil Lesevorgänge Eventual Consistency haben. Es kann einige Zeit dauern, bis das neue Dienstkonto sichtbar ist.

Zur Behebung dieses Verhaltens kann Ihre Anwendung die Anfrage mit abgeschnittenem exponentiellem Backoff wiederholen.

Nächste Schritte

Jetzt testen

Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

Jetzt kostenlos starten