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 von Identity and Access Management (IAM) für Amazon Web Services (AWS) vertraut sind, erhalten Sie in diesem Artikel eine umfassende Einführung in Google Cloud Identity and Access Management. Google Cloud und AWS bieten ähnliche IAM-Lösungen. Sie können diese Tools zum Erstellen von und Verwalten von Berechtigungen für Ihre Cloud-Ressourcen verwenden, einschließlich für 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 Cloud IAM-Dienstkonto
Nutzeridentität In IAM verwaltet. Identität zum externen Identitätsverwaltungssystem föderiert. Außerhalb von IAM verwaltet. Identität zum externen 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.

Organisieren von Projekten und Richtlinien in Google Cloud

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 organisationsweite IAM-Richtlinien haben 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 des Projektbesitzes:

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

In Cloud IAM können Sie keine Endnutzeridentitäten verwalten; Sie können Nutzern, die Sie auf andere Weise erstellen und verwalten, Zugriff gewähren. Bei der Nutzung von Cloud IAM können Sie standardmäßig den folgenden Identitätstypen Zugriff gewähren:

  • Google-Konto
  • Dienstkonto
  • Google-Gruppe
  • G Suite-Domain

Google Groups sind gut zu bedienen und wir empfehlen diese für die Anwendung einer Zugriffsrichtlinie auf eine Nutzergruppe. Sie können die Zugriffskontrollen für eine ganze Gruppe auf einmal gewähren oder ändern, anstatt die Zugriffskontrollen 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.

Wenn Sie noch keine G Suite-Domain zur Nutzerverwaltung verwenden, können Sie Ihre bestehende Teilmenge der operativen Nutzer 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.

Die folgende Tabelle listet die Möglichkeiten auf, wie Sie Nutzer in Google Cloud föderieren können, und beschreibt diese.

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 Nicht-Mitarbeiter-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.
Externe Identitätsverbindungen 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 mithilfe der Google Cloud Console, der Cloud Identity and Access Management API oder des gcloud Befehlszeilentools 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.

Bei den Cloud IAM-Dienstkonten können Sie sie unter anderem als eine Ressource oder eine Identität behandeln. 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 sein, die Sie selbst verwalten, oder von Google Cloud verwaltete Schlüssel.

Sie können nutzerverwaltete Schlüssel mit der Cloud Console, der Cloud IAM API oder dem Befehlszeilentool gcloud 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 wechselt 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 Cloud 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, sodass beispielsweise zum Auflisten aller Buckets in einem Projekt, ein häufiger Anwendungsfall, nur die Verwendung der Betrachterrolle notwendig ist. 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 set-iam-policy-Befehl im Tool gcloud 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 Befehl gcloud 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 Versionskontrollsystem auf, um Ihre Cloud-Umgebung zu definieren. Wenn Sie Ihre Richtlinien aktualisieren, erstellen Sie eine neue Version.

Während AWS über die beiden zuvor beschriebenen Richtlinientypen verfügt, hat Google Cloud nur einen Richtlinientyp. Sie können Ihre Richtlinien ganz flexibel mit dem von Ihnen als angemessen erachteten Versionskontrollsystem verwalten. Google Cloud bietet Cloud Source Repositories, private Git-Repositories mit vollem Funktionsumfang, die auf 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, anzuzeigen, zu bearbeiten oder vorzunehmen.

Wenn Sie Ihre aktuellen Versionskontrolllösungen 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 überprü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 anzeigen, 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 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 effektive Richtlinie für eine Ressource die Verbindung aus der mit dieser Ressource festgelegten 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 Google Cloud Operations Suite gespeichert. So erhalten Sie auf einen Blick Dashboard-Ansichten der letzten Aktivitäten. Diese Einträge werden nach einer bestimmten Zeit aus der Google Cloud Operations Suite gelöscht. Die Cloud Logging-Kontingentrichtlinie erläutert 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.

Nächste Schritte

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