IAM-Übersicht

Auf dieser Seite wird beschrieben, wie das IAM-System (Identity and Access Management) von Google Cloudfunktioniert und wie Sie es zum Verwalten des Zugriffs in Google Cloudverwenden können.

IAM ist ein Tool zur Verwaltung der detaillierten Autorisierung fürGoogle Cloud. Mit anderen Worten: Sie können steuern, wer was mit welchen Ressourcen tun darf.

Zugriff in Google Cloud

Für jede Aktion in Google Cloud sind bestimmte Berechtigungen erforderlich. Wenn jemand versucht, eine Aktion in Google Cloudauszuführen, z. B. eine VM-Instanz zu erstellen oder ein Dataset aufzurufen, wird in IAM zuerst geprüft, ob die erforderlichen Berechtigungen vorhanden sind. Wenn nicht, verhindert IAM, dass sie die Aktion ausführen.

Wenn Sie jemandem Berechtigungen in IAM erteilen, sind die folgenden drei Komponenten erforderlich:

  • Hauptkonto: Die Identität der Person oder des Systems, dem Sie Berechtigungen erteilen möchten.
  • Rolle: Die Sammlung von Berechtigungen, die Sie dem Hauptkonto zuweisen möchten
  • Ressource: Die Google Cloud Ressource, auf die das Hauptkonto zugreifen soll

Wenn Sie dem Hauptkonto die Berechtigung zum Zugriff auf die Ressource erteilen möchten, weisen Sie ihm die Rolle für die Ressource zu. Sie weisen diese Rollen mit einer Zulassungsrichtlinie zu.

In den folgenden Abschnitten werden diese Konzepte näher beschrieben.

Hauptkonten

In Google Cloud steuern Sie den Zugriff für Hauptkonten. Hauptkonten stellen eine oder mehrere Identitäten dar, die sich bei Google Cloudauthentifiziert haben.

In der Vergangenheit wurden Hauptkonten als Mitglieder bezeichnet. In einigen APIs wird dieser Begriff weiterhin verwendet.

Es gibt verschiedene Arten von Hauptkonten in IAM, die sich in zwei große Kategorien unterteilen lassen:

  • Menschliche Nutzer: Einige IAM-Hauptkontotypen repräsentieren menschliche Nutzer. Mit diesen Hauptkontotypen verwalten Sie den Zugriff Ihrer Mitarbeiter aufGoogle Cloud -Ressourcen.

    Zu den Hauptkontotypen, die menschliche Nutzer repräsentieren, gehören Google-Konten, Google-Gruppen und föderierte Identitäten in Workforce Identity-Pools.

  • Arbeitslasten: Einige IAM-Hauptkontotypen stellen Arbeitslasten dar. Sie verwenden diese Hauptkontotypen, wenn Sie den Zugriff Ihrer Arbeitslasten aufGoogle Cloud -Ressourcen verwalten.

    Zu den Hauptkontotypen, die Arbeitslasten darstellen, gehören Dienstkonten und föderierte Identitäten in einem Workload Identity-Pool.

Weitere Informationen zu Hauptkonten finden Sie unter IAM-Hauptkonten.

Berechtigungen und Rollen

Berechtigungen bestimmen, welche Vorgänge bei einer Ressource zugelassen sind. In IAM werden Berechtigungen normalerweise so dargestellt: service.resource.verb. Oft entsprechen Berechtigungen eins zu eins den REST API-Methoden. Mit der Berechtigung resourcemanager.projects.list können Sie beispielsweise Resource Manager-Projekte auflisten.

Sie können einem Hauptkonto nicht direkt Berechtigungen erteilen. Stattdessen erteilen Sie Hauptkonten Berechtigungen, indem Sie ihnen Rollen zuweisen.

Rollen sind Sammlungen von Berechtigungen. Wenn Sie einem Hauptkonto eine Rolle zuweisen, erhält es alle Berechtigungen, die in dieser Rolle enthalten sind.

Es gibt drei Arten von Rollen:

  • Vordefinierte Rollen: Rollen, die von Google Cloud -Diensten verwaltet werden. Diese Rollen enthalten die Berechtigungen, die zum Ausführen allgemeiner Aufgaben für die einzelnen Dienste erforderlich sind. Beispielsweise ermöglicht die Rolle „Pub/Sub Publisher“ (roles/pubsub.publisher) den Zugriff zum Veröffentlichen von Nachrichten in einem Pub/Sub-Thema.

  • Benutzerdefinierte Rollen: Rollen, die Sie erstellen und die nur die von Ihnen angegebenen Berechtigungen enthalten. Sie haben die volle Kontrolle über die Berechtigungen in diesen Rollen. Sie sind jedoch mit einem höheren Wartungsaufwand verbunden als vordefinierte Rollen und es gibt eine Begrenzung für die Anzahl der benutzerdefinierten Rollen, die Sie in Ihrem Projekt und in Ihrer Organisation haben können.

  • Einfache Rollen: Sehr permissive Rollen, die umfassenden Zugriff aufGoogle Cloud -Dienste ermöglichen. Diese Rollen können für Testzwecke nützlich sein, sollten aber nicht in Produktionsumgebungen verwendet werden.

Weitere Informationen zu Rollen und Berechtigungen finden Sie unter Rollen und Berechtigungen.

Ressourcen

Die meisten Google Cloud Dienste haben eigene Ressourcen. Compute Engine hat beispielsweise Ressourcen wie Instanzen, Laufwerke und Subnetzwerke.

In IAM weisen Sie Rollen für eine Ressource zu. Wenn einem Hauptkonto eine Rolle für eine Ressource zugewiesen wird, kann das Hauptkonto die Berechtigungen in dieser Rolle verwenden, um auf die Ressource zuzugreifen.

Sie können Rollen für eine Teilmenge von Google Cloud Ressourcen zuweisen. Eine vollständige Liste der Ressourcen, für die Sie Rollen zuweisen können, finden Sie unter Ressourcentypen, die Zulassungsrichtlinien akzeptieren.

Google Cloud hat auch mehrere Containerressourcen, darunter Projekte, Ordner und Organisationen. Wenn Sie einem Hauptkonto eine Rolle für eine Containerressource zuweisen, erhält das Hauptkonto Zugriff auf die Containerressource und die Ressourcen in diesem Container. Mit dieser Funktion können Sie einem Hauptkonto mit einer einzigen Rollenzuweisung Zugriff auf mehrere Ressourcen gewähren, einschließlich Ressourcen, für die Sie Rollen nicht direkt zuweisen können. Weitere Informationen finden Sie auf dieser Seite unter Richtlinienübernahme.

Zulassungsrichtlinien

Sie weisen Hauptkonten Rollen mithilfe von Richtlinien zulassen zu. In der Vergangenheit wurden diese Richtlinien als IAM-Richtlinien bezeichnet.

Eine „allow“-Richtlinie ist ein YAML- oder JSON-Objekt, das einer Google Cloud-Ressource zugeordnet ist.

Das folgende Diagramm zeigt die Struktur einer Zulassungsrichtlinie:

Eine Zulassungsrichtlinie mit zwei Rollenbindungen. Grafik: Die Rollenbindungen verknüpfen bestimmte Hauptkonten mit bestimmten Rollen.

Jede Zulassungsrichtlinie enthält eine Liste von Rollenbindungen, die IAM-Rollen mit den Hauptkonten verknüpfen, denen diese Rollen zugewiesen werden.

Wenn ein authentifiziertes Hauptkonto versucht, auf eine Ressource zuzugreifen, prüft IAM anhand der Zulassungsrichtlinie der Ressource, ob das Hauptkonto die erforderlichen Berechtigungen hat. Wenn das Hauptkonto in einer Rollenbindung enthalten ist, die eine Rolle mit den erforderlichen Berechtigungen enthält, darf es auf die Ressource zugreifen.

Beispiele für „allow”-Richtlinien und Informationen zu ihrer Struktur finden Sie unter „allow”-Richtlinien.

Übernahme von Richtlinien

Google Cloud bietet Containerressourcen wie Projekte, Ordner und Organisationen, mit denen Sie Ihre Ressourcen in einer Über- und Untergeordneten-Hierarchie organisieren können. Diese Hierarchie wird als Ressourcenhierarchie bezeichnet.

Die Google Cloud Ressourcenhierarchie hat die folgende Struktur:

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

Das folgende Diagramm zeigt ein Beispiel für eine Google Cloud Ressourcenhierarchie:

Hierarchie für IAM-Ressourcen.

Wenn Sie eine Zulassungsrichtlinie für eine Containerressource festlegen, gilt sie auch für alle Ressourcen in diesem Container. Dieses Konzept wird als Richtlinienübernahme bezeichnet, da untergeordnete Ressourcen die Zulassungsrichtlinien ihrer übergeordneten Ressourcen übernehmen.

Die Richtlinienübernahme hat folgende Auswirkungen:

  • Sie können mit einer einzelnen Rollenbindung Zugriff auf mehrere Ressourcen gewähren. Wenn Sie einem Hauptkonto Zugriff auf alle Ressourcen in einem Container gewähren möchten, weisen Sie ihm eine Rolle für den Container anstelle der Ressourcen im Container zu.

    Wenn Sie beispielsweise Ihrem Sicherheitsadministrator erlauben möchten, Zulassungsrichtlinien für alle Ressourcen in Ihrer Organisation zu verwalten, können Sie ihm die Rolle „Sicherheitsadministrator“ (roles/iam.securityAdmin) für die Organisation zuweisen.

  • Sie können Zugriff auf Ressourcen gewähren, die keine eigenen Zulassungsrichtlinien haben. Nicht alle Ressourcen akzeptieren Zulassungsrichtlinien, aber alle Ressourcen übernehmen Zulassungsrichtlinien von ihren übergeordneten Ressourcen. Wenn Sie einem Hauptkonto Zugriff auf eine Ressource gewähren möchten, für die keine eigene Zulassungsrichtlinie vorhanden sein kann, weisen Sie ihm eine Rolle für einen der Vorfahren der Ressource zu.

    Angenommen, Sie möchten jemandem die Berechtigung zum Schreiben von Logs in einen Log-Bucket erteilen. Log-Buckets haben keine eigenen Zulassungsrichtlinien. Wenn Sie jemandem diese Berechtigung erteilen möchten, können Sie ihm stattdessen die Rolle „Logs Bucket Writer“ (roles/logging.bucketWriter) für das Projekt zuweisen, das den Log-Bucket enthält.

  • Wenn Sie wissen möchten, wer auf eine Ressource zugreifen kann, müssen Sie auch alle Zulassungsrichtlinien ansehen, die sich auf die Ressource auswirken. Wenn Sie eine vollständige Liste der Identitäten mit Zugriff auf die Ressource abrufen möchten, müssen Sie die Zulassungsrichtlinie der Ressource und die Zulassungsrichtlinien der übergeordneten Ressourcen der Ressource aufrufen. Die Vereinigung aller dieser Richtlinien wird als effektive Zulassungsrichtlinie bezeichnet.

Weitere Informationen zur Richtlinienübernahme für Zulassungsrichtlinien finden Sie unter Ressourcenhierarchie für die Zugriffssteuerung verwenden.

Erweiterte Zugriffssteuerung

Zusätzlich zu Zulassungsrichtlinien bietet IAM die folgenden Zugriffssteuerungsmechanismen, mit denen Sie genauer festlegen können, wer auf welche Ressourcen zugreifen darf:

  • Zusätzliche Richtlinientypen: IAM bietet zusätzlich zu Zulassungsrichtlinien die folgenden Richtlinientypen:

    • Ablehnungsrichtlinien: Ablehnungsrichtlinien verhindern, dass Hauptkonten bestimmte Berechtigungen verwenden, auch wenn ihnen eine Rolle mit der Berechtigung zugewiesen ist.

    • PAB-Richtlinien (Principal Access Boundary): PAB-Richtlinien definieren und erzwingen die Ressourcen, auf die ein Hauptkonto zugreifen darf. Hauptkonten können nicht auf Ressourcen zugreifen, für die sie nicht berechtigt sind, auch wenn ihnen eine Rolle für die Ressource zugewiesen wurde.

    Weitere Informationen zu diesen Richtlinien

  • IAM-Bedingungen: Mit IAM-Bedingungen können Sie eine bedingte, attributbasierte Zugriffssteuerung definieren und erzwingen. Sie können Bedingungen in verschiedenen Richtlinientypen verwenden. Sie können beispielsweise einer Rollenbindung in einer „allow“-Richtlinie eine Bedingung hinzufügen, um sicherzustellen, dass die Rolle nur gewährt wird, wenn die Bedingung erfüllt ist.

    Sie können Bedingungen basierend auf Attributen wie der Ressource in der Anfrage und dem Zeitpunkt der Anfrage schreiben.

    Weitere Informationen zu IAM Conditions finden Sie in der Übersicht über IAM Conditions.

  • Privileged Access Manager (PAM): Mit Privileged Access Manager können Sie Hauptkonten vorübergehenden, prüfbaren Zugriff auf Ressourcen gewähren. Sie können beispielsweise festlegen, dass Hauptkonten jedes Mal Zugriff anfordern müssen, wenn sie eine vertrauliche Ressource aufrufen möchten, anstatt ihnen dauerhaft eine IAM-Rolle zuzuweisen.

    Sie können auch konfigurieren, ob für die Anfrage von Zugriff eine Begründung erforderlich ist oder eine Genehmigung eingeholt werden muss.

    Weitere Informationen zu Privileged Access Manager finden Sie unter Privileged Access Manager – Übersicht.

Konsistenzmodell für die IAM API

Die IAM API unterliegt der 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. Außerdem können Änderungen, die sich auf die Zugriffsprüfung auswirken, einige Zeit in Anspruch nehmen.

Dieses Konsistenzmodell wirkt 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 Vorgänge letztendlich konsistent sind. Es kann einige Zeit dauern, bis das neue Dienstkonto für Leseanfragen sichtbar ist.

Nächste Schritte

Überzeugen Sie sich selbst

Wenn Sie mit Google Cloudnoch nicht vertraut sind, erstellen Sie 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