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 ein Nutzer versucht, eine Aktion in Google Cloudauszuführen, z. B. eine VM-Instanz zu erstellen oder sich einen Datensatz anzusehen, wird zuerst geprüft, ob er die erforderlichen Berechtigungen hat. Andernfalls verhindert IAM, dass die Aktion ausgeführt wird.

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

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

Um dem Hauptkonto die Berechtigung zum Zugriff auf die Ressource zu erteilen, weisen Sie ihm die Rolle für die Ressource zu. Sie gewähren diese Rollen mit einer Zulassungsrichtlinie.

In den folgenden Abschnitten werden diese Konzepte näher erläutert.

Hauptkonten

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

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

In IAM gibt es verschiedene Arten von Hauptkonten, die sich jedoch in zwei allgemeine 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 natürliche Personen repräsentieren, gehören Google-Konten, Google-Gruppen und föderierte Identitäten in Workforce Identity-Pools.

  • Arbeitslasten: Einige IAM-Hauptkontotypen repräsentieren Arbeitslasten. Sie verwenden diese Hauptkontotypen, wenn Sie dieGoogle Cloud -Ressourcen für den Zugriff auf Ihre Arbeitslasten verwalten.

    Zu den Hauptkontotypen, die Arbeitslasten repräsentieren, 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 in der Regel in Form von service.resource.verb dargestellt. Berechtigungen entsprechen oft 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 keine Berechtigungen direkt gewähren. 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 in dieser Rolle.

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 gängiger Aufgaben für jeden Dienst erforderlich sind. Beispielsweise ermöglicht die Rolle „Pub/Sub-Publisher“ (roles/pubsub.publisher) Zugriff für die Veröffentlichung von Nachrichten in einem Pub/Sub-Thema.

  • Benutzerdefinierte Rollen: Von Ihnen erstellte Rollen, die nur die von Ihnen angegebenen Berechtigungen enthalten. Sie haben die volle Kontrolle über die Berechtigungen in diesen Rollen. Sie erfordern jedoch mehr Wartungsaufwand als vordefinierte Rollen und die Anzahl der benutzerdefinierten Rollen, die Sie in Ihrem Projekt und in Ihrer Organisation haben können, ist begrenzt.

  • Einfache Rollen: Rollen mit sehr weitreichenden Berechtigungen, die umfassenden Zugriff aufGoogle Cloud Dienste gewähren. 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. Die Compute Engine bietet beispielsweise Ressourcen wie Instanzen, Laufwerke und Subnetzwerke.

In IAM gewähren Sie Rollen für eine Ressource. Wenn Sie einem Hauptkonto eine Rolle für eine Ressource gewähren, kann es mit den Berechtigungen dieser Rolle auf die Ressource zugreifen.

Sie können Rollen für eine Teilmenge von Google Cloud Ressourcen zuweisen. Eine vollständige Liste der Ressourcen, für die Sie Rollen gewähren 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 gewähren, erhält es Zugriff auf die Containerressource und die Ressourcen in diesem Container. Mit dieser Funktion können Sie einem Hauptkonto über eine einzige Rollengewährung Zugriff auf mehrere Ressourcen gewähren, einschließlich Ressourcen, für die Sie keine Rollen direkt gewähren können. Weitere Informationen finden Sie auf dieser Seite unter Richtlinienübernahme.

Zulassungsrichtlinien

Sie weisen Hauptkonten Rollen mithilfe von Zulassungsrichtlinien zu. Bisher wurden diese Richtlinien als IAM-Richtlinien bezeichnet.

Eine Zulassungsrichtlinie ist ein YAML- oder JSON-Objekt, das mit einer Google Cloud-Ressource verknüpft 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 den Hauptkonten zuordnen, denen diese Rollen gewährt 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 zu einer Rollenbindung gehört, 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 übergeordneten/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 ist ein Beispiel für eine Google Cloud Ressourcenhierarchie:

Hierarchie für IAM-Ressourcen.

Wenn Sie eine Zulassungsrichtlinie für eine Containerressource festlegen, gilt diese Richtlinie 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:

  • Mit einer einzelnen Rollenbindung können Sie 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 zu, nicht für die Ressourcen im Container.

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

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

    Angenommen, Sie möchten einer Person die Berechtigung erteilen, Protokolle in einen Protokoll-Bucket zu schreiben. Protokoll-Buckets haben keine eigenen Zulassungsrichtlinien. Wenn Sie einem Nutzer 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 Protokoll-Bucket enthält.

  • Wenn Sie wissen möchten, wer auf eine Ressource zugreifen kann, müssen Sie sich auch alle Zulassungsrichtlinien ansehen, die sich auf die Ressource auswirken. Wenn Sie eine vollständige Liste der Berechtigungsinhaber aufrufen möchten, die Zugriff auf die Ressource haben, müssen Sie sich die Zulassungsrichtlinie der Ressource und die Zulassungsrichtlinien der übergeordneten Ressourcen ansehen. Die Vereinigung aller dieser Richtlinien wird als geltende 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 festlegen können, wer Zugriff auf welche Ressourcen hat:

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

    • Ablehnungsrichtlinien: Mit Ablehnungsrichtlinien wird verhindert, dass Hauptkonten bestimmte Berechtigungen verwenden, auch wenn ihnen eine Rolle mit der Berechtigung zugewiesen wurde.

    • Principal Access Boundary-Richtlinien (PAB-Richtlinien): Mit PAB-Richtlinien werden die Ressourcen definiert und erzwungen, auf die ein Hauptkonto zugreifen darf. Hauptkonten können nicht auf Ressourcen zugreifen, auf die sie keinen Zugriff haben, auch wenn ihnen eine Rolle für die Ressource zugewiesen wurde.

    Weitere Informationen zu diesen Richtlinien finden Sie unter Richtlinientypen.

  • 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, damit 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 der Uhrzeit 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 erlauben, temporären, auditierbaren Zugriff auf Ressourcen anzufordern und zu erhalten. 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 zu gewähren.

    Sie können auch festlegen, ob Hauptbevollmächtigte Begründungen angeben oder Genehmigungen einholen müssen, wenn sie Zugriff anfordern.

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