Google Cloud für AWS-Experten: Verwaltung

Aktualisiert am 17. März 2017

Verwaltungsdienste vergleichen, die Amazon und Google in ihren jeweiligen Cloudumgebung anbieten. Wenn Sie bereits mit der Implementierung der Identitäts- und Zugriffsverwaltung für Amazon Web Services (AWS) vertraut sind, erhalten Sie in diesem Artikel eine umfassende Einführung in die Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) von Google. Google Cloud und AWS bieten ähnliche IAM-Lösungen. Sie können diese Tools zum Erstellen und Verwalten von Berechtigungen für Ihre Cloud-Ressourcen verwenden, einschließlich Daten und Anwendungen.

Sowohl bei AWS als auch bei Google Cloud können Sie Nutzern, Gruppen und Anwendungen Berechtigungen erteilen. Diese Berechtigungen ermöglichen der entsprechenden Entität einen klar definierten Zugriff auf Ihre Cloud-Ressourcen.

In der folgenden Tabelle wird eine allgemeine Zuordnung von AWS-Begriffen und -Konzepten zu ihren Google Cloud-Entsprechungen beschrieben.

Konzept AWS Google Cloud
Programmatische Identität IAM-Rolle und Instanzenprofil IAM-Dienstkonto
Nutzeridentität In IAM verwaltet. Identität zum externen Identitätsverwaltungssystem föderiert. Außerhalb von IAM verwaltet. Identität durch Anschluss an externes Identitätsverwaltungssystem föderiert.
Richtlinien Ein Dokument, das explizit Berechtigungen auflistet. Eine Liste von Bindungen. Eine Bindung bindet mehrere in einer Liste aufgeführte Mitglieder an eine Rolle.
Richtlinienbindung Mit einem IAM-Nutzer oder eine Gruppe oder Ressource verknüpfte Richtlinie. An eine Ressource gebundene Richtlinie.

Richtlinienbewertung Standardmäßig ablehnen. Standardmäßig ablehnen.
Berechtigungssammlung Richtlinie Rolle
Vordefinierter Satz von Berechtigungen Verwaltete Richtlinien Vordefinierte Rollen
IAM-Aufrufe prüfen AWS CloudTrail Audit-Protokollierung
Versionsverwaltung Ja Nein

Ressourcenverwaltung und Datenkapselung

Dieser Abschnitt hilft Ihnen, ein Verständnis dafür zu entwickeln, wie die einzelnen Cloud-Provider Ressourcen verwalten.

Mehrere Konten in AWS

Bei AWS richten Sie am besten mehrere Konten für jedes Team ein. Sie können dann unter jedem Konto Berechtigungen und Richtlinien zuweisen. Sie können die Verwaltung mehrerer AWS-Konten weniger komplex gestalten, indem Sie eine konsolidierte Abrechnung einrichten und AWS-Organisationen implementieren.

Projekte und Richtlinien in Google Cloud organisieren

Google Cloud stellt Containerressourcen wie Organisationen, Ordner und Projekte bereit, mit denen Sie andere Google Cloud-Ressourcen gruppieren und hierarchisch organisieren können, wie beispielsweise Pub/Sub-Themen und VM-Instanzen von Compute Engine. In dieser hierarchischen Organisation können Sie gemeinsame Aspekte Ihrer Ressourcen wie Zugriffssteuerung und Konfigurationseinstellungen verwalten.

Alle Google Cloud-Ressourcen gehören zur Projektressource und ein individuelles Google-Konto kann mehrere Projekte verwalten. Sie können die Projekte individuell verwalten. Sie können ähnliche Projekte in Ordnern gruppieren und von dort aus verwalten. Außerdem können Sie Ordner und Projekte in einer Organisationsressource verwalten.

Das folgende Diagramm zeigt ein Beispiel für verschiedene Ressourcen und ihre hierarchische Organisation in Google Cloud. Wenn Sie mit Google Cloud-Ressourcen interagieren möchten, müssen Sie in der Regel in jeder Anfrage die entsprechenden Projektinformationen angeben.

Beispiel für eine Google Cloud-Ressourcenhierarchie.

Übernahme von Richtlinien

Mit AWS können Sie Ressourcen-basierte Berechtigungen festlegen, die direkt für Ressourcen gelten, oder Sie können Berechtigungen für spezifische Aktionen festlegen, die für eine gegebene Ressource ausgeführt werden können. Wie die Berechtigungen festgelegt werden können, hängt vom Dienst ab.

Die IAM-Richtlinienübernahme von Google Cloud wird durch die Ressourcenorganisation ergänzt. In Google Cloud sind Ressourcen hierarchisch organisiert, sodass Sie IAM-Richtlinien festlegen können, die vom Organisationsknoten nach unten fließen. Wenn Sie IAM-Richtlinien für die ganze Organisation verwenden möchten, können Sie diese Richtlinien der Organisationsressource zuweisen. Wenn Sie Richtlinien für mehrere Teams und Projekte festlegen möchten, können Sie dazu Google Cloud-Ordner verwenden. Sie können dann Berechtigungen auf Projektebene und schließlich auf Ressourcenebene innerhalb des Projekts zuweisen, um eine detailliertere Kontrolle zu erhalten.

Identitäten

Die Identitäten für den Zugriff auf die Cloud-Ressourcen werden in zwei Gruppen eingeteilt:

  • Endnutzer-Identitäten, repräsentiert durch die üblichen geschäftlichen Anmeldedaten. Im Fall von AWS können Endnutzer außerdem durch die Nutzung von IAM-Konten dargestellt werden.
  • Programmatische Identitäten, mit denen der Anwendungscode auf Cloudressourcen zugreifen kann.

Endnutzer-Identitäten in AWS

AWS verwaltet das Root-Konto, das für jedes erstellte Konto erforderlich ist. AWS bietet eine Liste von Best Practices zum Schutz Ihrer Root-Zugangsschlüssel für das AWS-Konto.

Wenn Sie IAM-Nutzer (innerhalb von AWS erstellte Identitäten) oder Föderationen aus Ihrem Firmenverzeichnis einrichten, gewähren Sie Zugriff auf Ihre AWS-Ressourcen. Sie können einen externen Identitätsanbieter nutzen. Wenn Sie einen externen Identitätsanbieter für die Nutzung mit AWS konfigurieren, müssen Sie eine IAM-Rolle erstellen und dann die Berechtigungen für diese Rolle definieren. Wenn sich ein föderierter Nutzer bei AWS anmeldet, ist dieser Nutzer mit der Rolle assoziiert und ihm werden die in der Rolle definierten Berechtigungen gewährt.

Endnutzerzugriff in Google Cloud

Bei Google Cloud haben Sie zwei Hauptoptionen zum Zuweisen der Projektinhaberschaft:

  • Sie können ein Projekt mit einem oder mehreren Inhabern, die vollen Zugriff auf die Projektressourcen haben, erstellen.
  • Sie können Projekte mit keinem expliziten Inhaber haben. Dieser Ansatz kann nützlich sein, wenn das Projekt Teil einer Organisation ist und alle Ihre Projekte im Besitz einer Organisation sein sollen.

Endnutzeridentitäten lassen sich in IAM nicht verwalten. Sie haben damit die Möglichkeit, Nutzern Zugriff zu gewähren, die Sie auf andere Weise erstellen und verwalten. Wenn Sie IAM verwenden, können Sie standardmäßig Zugriff auf die folgenden Arten von Identitäten gewähren:

  • Google-Konto
  • Dienstkonto
  • Google-Gruppe
  • Google Workspace-Domain

Google Groups sind gut zu bedienen und wir empfehlen diese für die Anwendung einer Zugriffsrichtlinie auf eine Nutzergruppe. 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 Mitglieder zu einer Google Groups-Gruppe hinzufügen oder aus ihr entfernen. Das ist einfacher, als IAM-Richtlinien zu aktualisieren, um Nutzer hinzuzufügen oder zu entfernen.

Wenn Sie noch keine Google Workspace-Domain zur Nutzerverwaltung verwenden, können Sie Ihre bestehende Teilmenge an operativen Nutzern aus vielen gängigen Nutzerverzeichnissen wie Active Directory föderieren. Dieser Ansatz ermöglicht Ihnen die Verwendung Ihrer vorhandenen Unternehmensidentitäten. Sie müssen zuerst Ihren Domainnamen über Google verifizieren.

In der folgenden Tabelle werden die Möglichkeiten aufgeführt und beschrieben, wie Sie Nutzer in Google Cloud föderieren können.

Föderationstechnik Beschreibung
Cloud Directory Sync Von Google bereitgestelltes Tool, das mit den meisten kommerziellen und betrieblichen LDAP-Verzeichnisdiensten funktioniert. Mit Cloud Directory Sync können Sie Nutzer, Gruppen und betriebsfremde Kontakte hinzufügen, ändern und löschen, um die Daten in Ihrer Google Cloud-Domain mithilfe von LDAP-Abfragen mit Ihrem LDAP-Verzeichnisserver zu synchronisieren. Die Daten auf Ihrem LDAP-Verzeichnisserver werden zu keiner Zeit geändert oder manipuliert.
Identitätsverbindungen von Drittanbietern Native Verbindungen mit einem Identitätsanbieter für die, die diesen bereitstellen. Verbindet einen Identitätsanbieter direkt mit einer in der Google Cloud bereitgestellten Domain. Hier einige Beispiele:

  • Ping Federate
  • Okta
  • CA Siteminder
  • Azure AD
  • OpenIAM
  • Auth0
  • Oracle IAM
Google Apps API Gibt einer Organisation programmatische Kontrolle über die Nutzer- und Gruppenverwaltung.

Sie können dann die Identitäten in Form von E-Mail-Adressen zu Google Groups hinzufügen, um ihnen Zugriff auf Google Cloud-Ressourcen zu gewähren.

Programmatische Identitäten in AWS

Wenn Sie bei AWS die AWS APIs von einer Anwendung aufrufen möchten, die nicht auf AWS Compute-Ressourcen ausgeführt wird, erstellen Sie einen IAM-Nutzer. Anschließend laden Sie die entsprechenden Schlüssel herunter und nutzen diese mit Ihrer App, um AWS APIs aufzurufen.

Wenn Sie auf einer EC2-Instanz eine programmatische Identität verwenden möchten, erstellen Sie ein Instanzen-Profil, das der Instanz beigefügt ist. Das Profil enthält eine IAM-Rolle, und es kann die Anmeldedaten der Rolle einer Anwendung zur Verfügung stellen, die auf der Instanz ausgeführt wird.

Eine IAM-Rolle ermöglicht es einem IAM-Nutzer, einer Gruppe oder einer Anwendung, die auf EC2 oder auf einem Mobilgerät ausgeführt werden könnte, die von der Rolle definierten Berechtigungen aufzunehmen. Vorläufige Anmeldedaten werden erstellt und der Entität bereitgestellt, welche die Rolle annimmt.

Die Verwendung von IAM-Rollen ermöglicht es IAM-Nutzern zudem, zu einer Rolle zu wechseln, um bei der Nutzung der Konsole die Berechtigungen dieser Rolle vorläufig zu nutzen. Wenn dies der Fall ist, geben Nutzer ihre ursprünglichen Berechtigungen auf und nehmen die der Rolle zugewiesenen Berechtigungen an. Wenn die Nutzer die Rolle verlassen, geben sie deren Berechtigungen auf.

Programmatische Identitäten in Google Cloud

Bei Google Cloud ist ein Dienstkonto ein spezielles Google-Konto, mit dem Anwendungen programmgesteuert auf Google-Dienste zugreifen können. Dieses Konto gehört zu Ihrer Anwendung oder einer Compute Engine-Instanz und nicht zu einem individuellen Endnutzer.

Ein Dienstkonto kann Paare von Dienstkontoschlüsseln enthalten, die für eine Authentifizierung bei Google verwendet werden können. Ein Dienstkontoschlüssel ist ein von Google generiertes öffentliches/privates Schlüsselpaar. Google behält den öffentlichen Schlüssel, während der Nutzer den privaten Schlüssel erhält.

Sie können benutzerdefinierte Dienstkonten in Google Cloud-Projekten mit der Google Cloud Console, der Identity and Access Management API oder dem gcloud-Befehlszeilentool erstellen.

Wenn Sie das Dienstkonto nur für Anwendungen verwenden möchten, die in Google Cloud-Computing-Diensten ausgeführt werden, müssen Sie die privaten Schlüssel nicht herunterladen, da Sie von Google Cloud verwaltete Schlüssel verwenden können.

Ein Merkmal von IAM-Dienstkonten ist, dass Sie sie als Ressource oder als Identität behandeln können. Das Dienstkonto hat eine Identität und Sie geben ihm Berechtigungen, wenn Sie ihm eine Rolle für den Zugriff auf eine Ressource, wie etwa ein Projekt, gewähren.

Wenn Sie ein Dienstkonto als Ressource betrachten, können Sie wie bei anderen Google Cloud-Ressourcen einem Nutzer die Berechtigung zum Zugriff auf dieses Dienstkonto erteilen. Sie können einem Nutzer eine Rolle als Inhaber, Bearbeiter, Betrachter oder eine undefinierte Rolle als serviceAccountUser gewähren, um auf das Dienstkonto zuzugreifen. Ein Nutzer mit serviceAccountUser als Dienstkonto kann auf alle Ressourcen mit denselben Berechtigungen zugreifen, auf die das Dienstkonto Zugriff hat. Diese Funktion ähnelt der im vorherigen Abschnitt besprochenen Nutzung der IAM-Rolle.

Dienstkontoschlüssel können entweder von Nutzern verwaltete Schlüssel die Sie selbst verwalten, oder von Google Cloud verwaltete Schlüssel sein.

Sie können vom Nutzer verwaltete Schlüssel mit der Cloud Console, der IAM API oder dem gcloud-Befehlszeilentool erstellen und verwalten. Sie sind dafür verantwortlich, die Schlüssel sicher aufzubewahren und regelmäßig zu wechseln.

Von Google Cloud verwaltete Schlüssel werden von Diensten wie App Engine und Compute Engine verwendet. Sie können einen von Google Cloud verwalteten Schlüssel nicht direkt erstellen oder herunterladen; Google verwaltet die Schlüssel und rotiert sie einmal täglich.

Berechtigungszuweisung

Sowohl Google Cloud als auch AWS verwenden die Begriffe Rolle und Richtlinie, die Verwendungszwecke unterscheiden sich jedoch geringfügig. Diese Unterschiede können bei der Zuordnung von AWS IAM zu IAM für Verwirrung sorgen. Eine Gruppe von Berechtigungen in Google Cloud wird als Rolle bezeichnet, in AWS jedoch als Richtlinie.

Beispiel für AWS-Berechtigung

Bei AWS können Sie die Berechtigungen in der Richtliniendefinition als eine Aktion, eine Ressource und einen Effekt festlegen. Eine AWS-Richtlinie, die jemandem erlaubt (Effekt), alle Buckets in einem Konto (Ressource) aufzulisten (Aktion), sieht folgendermaßen aus:

{
  "Version": "2012-10-17",
  "Statement": {
  "Effect": "Allow",
  "Action": "s3:ListAllMyBuckets",
  "Resource": "*"
  }
}

Alleinstehende AWS IAM-Richtlinien, die mehreren Nutzern, Gruppen und Rollen zugeordnet werden können, bezeichnet man als verwaltete Richtlinien. Verwaltete Richtlinien können entweder AWS verwaltete Richtlinien sein, die von AWS erstellt und verwaltet werden, oder vom Kunden verwaltete Richtlinien, die Sie in Ihrem AWS-Konto erstellen und verwalten.

Google Cloud-Berechtigungsbeispiel

Google Cloud verfolgt einen vordefinierten, rollenbezogenen Ansatz. So beispielsweise ist zum Auflisten aller Buckets in einem Projekt, ein häufiger Anwendungsfall, nur die Verwendung der Betrachterrolle notwendig. Diese Rolle muss dann dem Nutzer oder der Gruppe zugewiesen werden und das daraus resultierende Dokument, das Nutzer oder Gruppen an die Rolle bindet, nennt man Richtlinie. Die Definition einer Richtlinie entspricht in etwa dem folgenden Beispiel:

{
  "bindings": [
      {
     "role": "roles/viewer",
     "members": ["group:gcs-viewers@example.com"]
   }
  ]
}

AWS-Richtlinien

Bei AWS können Sie zusätzlich zum Anhängen von Richtlinien an eine Identität, eine Richtlinie an eine Ressource anhängen. Bei Richtlinien, die Sie an eine Ressource anhängen, müssen Sie eine Identität oder Rolle einbetten, die in der Lage ist, innerhalb der Richtlinie auf die Ressource zuzugreifen.

In den meisten Fällen empfiehlt AWS die Nutzung von verwalteten Richtlinien. Die Empfehlungen zur Auswahl zwischen verwalteten Richtlinien und Inline-Richtlinien sind in der AWS Dokumentation angegeben.

Google Cloud-Richtlinien

Eine Google Cloud-Richtlinie ist in einer JSON-Datei mit dem Namen iam-gcs-access.json, deklariert und weist einer Gruppe von Nutzern die Rolle viewer und einem Dienstkonto die Rolle objectCreator zu. Eine Anwendung nutzt das Dienstkonto, um den Buckets in einem Projekt Objekte hinzuzufügen. Das folgende Beispiel illustriert, wie Sie mehrere Mitglied-zu-Rolle-Bindungen in einer einzigen Richtlinie erstellen können.

{
    "bindings": [
    {
        "members": [
            "group:gcs-viewers@example.com"
        ],
        "role": "roles/viewer"
    },
    {
        "members": [
            "serviceAccount:123456789012-compute@developer.gserviceaccount.com"
        ],
        "role": "roles/storage.objectCreator"
    },
    ],
    "etag": "BwUjMhCsNvY=",
    "version": 1
}

Diese Richtlinie kann dann mithilfe der Cloud Console, dem Befehl set-iam-policy im gcloud-Tool oder der API an die Ressource gebunden werden, die in diesem Fall ein Projekt ist, um die Richtlinie dem Projekt zuzuweisen. In diesem Beispiel sieht der gcloud-Befehl so aus:

gcloud projects set-iam-policy [PROJECT_ID] iam-gcs-access.json

Dabei ist [PROJECT_ID] Ihre Google Cloud-Projekt-ID.

Dieses Vorgehen ähnelt dem Einbetten einer Identität oder Rolle, die innerhalb der Richtlinie in AWS auf die Ressource zugreifen kann.

Richtlinien in Google Cloud verwalten

Sie sollten Ihre Richtlinien wie Ihren Code behandeln: Bewahren Sie sie zusammen mit den restlichen von Ihnen verwendeten Inhalten in einem Versionsverwaltungssystem auf, um Ihre Cloud-Umgebung zu definieren. Wenn Sie Ihre Richtlinien aktualisieren, erstellen Sie eine neue Version.

Auf AWS sind die beiden zuvor beschriebenen Richtlinientypen enthalten, Google Cloud hingegen hat nur einen Richtlinientyp. Sie können Ihre Richtlinien ganz flexibel mit dem von Ihnen als angemessen erachteten System zur Versionsverwaltung verwalten. Google Cloud bietet Cloud Source Repositories, private Git-Repositories mit vollem Funktionsumfang, die in Google Cloud gehostet werden.

Wenn Sie bereits ein Repository auf GitHub oder Bitbucket haben, können Sie es mit Ihren Cloud Source Repositories verbinden. Verbundene Repositories und das Cloud Source Repository bleiben automatisch synchronisiert. Cloud Source Repositories bieten außerdem einen Quelleditor, den Sie nutzen können, um Änderungen an den Repository-Dateien von der Cloud Console aus zu suchen, anzusehen, zu bearbeiten oder vorzunehmen.

Wenn Sie Ihre derzeitigen Lösungen zur Versionsverwaltung nutzen möchten, können Sie dies in Google Cloud tun.

Berechtigungen testen und prüfen

Wenn Sie AWS verwenden, können Sie den IAM-Richtliniensimulator verwenden, mit dem Sie alle neuen und bestehenden Richtlinien testen und validieren sowie feststellen können, welche Richtlinien für einen Nutzer, eine Gruppe oder eine Ressource festgelegt wurden.

Bei Google Cloud können Sie mit dem gcloud-Befehl get-iam-policy die Richtliniendefinition zurückgeben:

gcloud projects get-iam-policy [PROJECT_ID]

Mithilfe der zurückgegebenen Definition können Sie prüfen, welche Richtlinien an die Ressource angehängt sind. Sie können die Cloud Console verwenden, um eine bestimmte Ressource aufzurufen und die Berechtigungen zu prüfen.

Wenn Sie die einer Identität zugewiesenen Berechtigungen prüfen möchten, können Sie die Identität in der Cloud Console auswählen und die Rollen aufrufen, an die die Identität gebunden ist. Sie haben außerdem die Möglichkeit, sich als diese Identität oder als Testidentität anzumelden, der die gleichen Berechtigungen gewährt wurden. Anschließend können Sie prüfen, worauf die Identität über die Cloud Console zugreifen kann.

Berechtigungsverteilung

Bei AWS werden alle Richtlinien bewertet. Die Reihenfolge, in der die Richtlinien definiert werden, hat keinen merklichen Einfluss, da das Endergebnis entweder „zugelassen“ oder „abgelehnt“ lautet. Durch die Nutzung einer expliziten Ablehnung können Sie eine weite Richtlinie überschreiben, die den Zugriff auf einen weiten Ressourcensatz ermöglichen kann. Dies wird ausführlich unter Feststellen, ob eine Anfrage innerhalb eines Kontos zugelassen oder abgelehnt wird beschrieben.

Bei Google Cloud ist die geltende Richtlinie für eine Ressource die Verbindung aus der für diese Ressource festgelegte Richtlinie und der von der übergeordneten vererbten Richtlinie. Da die Rollen konzentrisch sind und dem gleichen Nutzer mehrere Rollen gewähren, werden dem Nutzer die Berechtigungen für die weitreichendste Rolle gewährt. Unter Ressourcenhierarchie für Zugriffssteuerung verwenden finden Sie einige Beispielszenarien.

IAM-Prüfung

Für die IAM-Prüfungsaktivität bietet Amazon das AWS CloudTrail an, das AWS API-Aufrufe für Ihr Konto aufzeichnet und protokolliert. CloudTrail schickt diese Protokolle an das von Ihnen angegebene Amazon S3-Konto.

Google Cloud bietet Cloud-Audit-Logs, mit denen Administratoraktivitäten und Datenzugriffe aufgezeichnet werden. Mit diesen zwei von Google Cloud-Diensten generierten Streams können Sie für Ihre Google Cloud-Projekte herausfinden, wer was wo und wann getan hat.

Die einzelnen Audit-Logeinträge werden für einen bestimmten Zeitraum in der Operations-Suite von Google Cloud gespeichert. So erhalten Sie auf einen Blick Dashboard-Ansichten der letzten Aktivitäten. Diese Einträge werden nach einer bestimmten Zeit aus der Operations-Suite von Google Cloud gelöscht. Die Cloud Logging-Kontingentrichtlinie definiert den Zeitraum, für den Logeinträge aufbewahrt werden. Ansonsten können Sie Audit-Logs nicht löschen oder ändern.

Durch das Logging von IAM-Rollen können Sie den Zugriff auf die Logging-Ressourcen in einem Projekt oder einer Organisation einschränken.

Für eine längere Aufbewahrungsdauer können Sie Audit-Log-Einträge in einen Cloud Storage-Bucket, ein BigQuery-Dataset, ein Pub/Sub-Thema oder eine beliebige Kombination der drei exportieren.

Weitere Informationen

Weitere Artikel zu Google Cloud für AWS-Experten: