GCP - Basic Information
Ressourcenhierarchie
Google Cloud verwendet eine Ressourcenhierarchie, die konzeptionell ähnlich wie die eines traditionellen Dateisystems ist. Dies bietet einen logischen Eltern-Kind-Arbeitsablauf mit spezifischen Anknüpfungspunkten für Richtlinien und Berechtigungen.
Auf hoher Ebene sieht es so aus:
Projektmigration
Es ist möglich, ein Projekt ohne eine Organisation zu einer Organisation zu migrieren mit den Berechtigungen roles/resourcemanager.projectCreator und roles/resourcemanager.projectMover. Wenn sich das Projekt in einer anderen Organisation befindet, muss der GCP-Support kontaktiert werden, um sie zuerst aus der Organisation zu verschieben. Weitere Informationen finden Sie hier.
Organisationsrichtlinien
Ermöglichen die zentrale Kontrolle über die Cloud-Ressourcen Ihrer Organisation:
Zentrale Kontrolle zur Konfiguration von Beschränkungen für die Verwendung der Ressourcen Ihrer Organisation.
Definieren und festlegen von Leitplanken für Ihre Entwicklungsteams, um innerhalb der Compliance-Grenzen zu bleiben.
Unterstützen Projektinhaber und ihre Teams dabei, schnell voranzukommen, ohne sich um die Einhaltung von Vorschriften sorgen zu müssen.
Diese Richtlinien können erstellt werden, um die gesamte Organisation, Ordner oder Projekte zu beeinflussen. Nachkommen des ausgewählten Ressourcen-Hierarchieknotens erben die Organisationsrichtlinie.
Um eine Organisationsrichtlinie zu definieren, wählen Sie eine Einschränkung aus, die eine bestimmte Art von Beschränkung gegen einen Google Cloud-Dienst oder eine Gruppe von Google Cloud-Diensten darstellt. Sie konfigurieren diese Einschränkung mit den gewünschten Beschränkungen.
Häufige Anwendungsfälle
Begrenzung des Ressourcenaustauschs basierend auf der Domäne.
Begrenzung der Verwendung von Identitäts- und Zugriffsverwaltungsdienstkonten.
Einschränkung des physischen Standorts neu erstellter Ressourcen.
Deaktivierung der Erstellung von Dienstkonten
Standard-Organisationsrichtlinien
IAM-Rollen
Diese sind wie IAM-Richtlinien in AWS, da jede Rolle eine Reihe von Berechtigungen enthält.
Im Gegensatz zu AWS gibt es jedoch kein zentrales Repository für Rollen. Anstatt dessen geben Ressourcen X-Zugriffsrollen an Y-Prinzipale, und der einzige Weg herauszufinden, wer Zugriff auf eine Ressource hat, besteht darin, die get-iam-policy-Methode über diese Ressource zu verwenden.
Dies könnte ein Problem sein, da dies bedeutet, dass der einzige Weg herauszufinden, welche Berechtigungen ein Prinzipal hat, darin besteht, jede Ressource zu fragen, wem sie Berechtigungen gibt, und ein Benutzer möglicherweise nicht die Berechtigungen hat, um Berechtigungen von allen Ressourcen zu erhalten.
Es gibt drei Arten von Rollen in IAM:
Grundlegende/Primitive Rollen, die die Owner, Editor und Viewer-Rollen umfassen, die vor der Einführung von IAM existierten.
Vordefinierte Rollen, die granularen Zugriff für einen bestimmten Dienst bieten und von Google Cloud verwaltet werden. Es gibt viele vordefinierte Rollen, Sie können alle mit den ihnen zugeordneten Berechtigungen hier einsehen hier.
Benutzerdefinierte Rollen, die granularen Zugriff gemäß einer benutzerspezifischen Liste von Berechtigungen bieten.
Es gibt Tausende von Berechtigungen in GCP. Um zu überprüfen, ob eine Rolle über Berechtigungen verfügt, können Sie hier nach der Berechtigung suchen und sehen, welche Rollen diese haben.
Sie können auch hier nach vordefinierten Rollen suchen, die von jedem Produkt angeboten werden. Beachten Sie, dass einige Rollen nicht an Benutzer angehängt werden können und nur an SAs aufgrund einiger Berechtigungen, die sie enthalten. Darüber hinaus werden Berechtigungen nur wirksam, wenn sie dem relevanten Dienst zugeordnet sind.
Oder überprüfen Sie, ob eine benutzerdefinierte Rolle eine bestimmte Berechtigung hier verwenden kann.
pageGCP - IAM, Principals & Org Policies EnumBenutzer
Im GCP-Console gibt es kein Benutzer- oder Gruppenmanagement, das wird in Google Workspace durchgeführt. Sie könnten jedoch einen anderen Identitätsanbieter in Google Workspace synchronisieren.
Sie können auf die Benutzer und Gruppen von Workspaces unter https://admin.google.com zugreifen.
MFA kann für Workspace-Benutzer erzwungen werden, jedoch könnte ein Angreifer ein Token verwenden, um auf GCP zuzugreifen über die Befehlszeile, die nicht durch MFA geschützt ist (es wird nur durch MFA geschützt, wenn der Benutzer sich anmeldet, um es zu generieren: gcloud auth login).
Gruppen
Wenn eine Organisation erstellt wird, wird dringend empfohlen, mehrere Gruppen zu erstellen. Wenn Sie eine davon verwalten, könnten Sie die gesamte Organisation oder einen wichtigen Teil davon kompromittiert haben:
Gruppe | Funktion |
| Verwaltung von Ressourcen, die der Organisation gehören. Weisen Sie diese Rolle sparsam zu; Org-Administratoren haben Zugriff auf alle Ihre Google Cloud-Ressourcen. Alternativ, da diese Funktion sehr privilegiert ist, erwägen Sie die Verwendung von individuellen Konten anstelle der Erstellung einer Gruppe. |
| Erstellen von Netzwerken, Subnetzen, Firewall-Regeln und Netzwerkgeräten wie Cloud Router, Cloud VPN und Cloud-Lastenausgleicher. |
| Einrichten von Abrechnungskonten und Überwachung ihrer Nutzung. |
| Entwurf, Codierung und Testen von Anwendungen. |
| Einrichten und Verwalten von Sicherheitsrichtlinien für die gesamte Organisation, einschließlich Zugriffsverwaltung und Organisationsrichtlinienbeschränkungen. Sehen Sie sich den Google Cloud Security Foundations-Leitfaden für weitere Informationen zur Planung Ihrer Google Cloud-Sicherheitsinfrastruktur an. |
| Erstellen oder Verwalten von End-to-End-Pipelines, die die kontinuierliche Integration und Bereitstellung, Überwachung und Systembereitstellung unterstützen. |
| |
| |
| |
| Überwachung der Ausgaben für Projekte. Typische Mitglieder sind Teil des Finanzteams. |
| Überprüfung von Ressourceninformationen in der gesamten Google Cloud-Organisation. |
| Überprüfung der Cloud-Sicherheit. |
| Überprüfung von Netzwerkkonfigurationen. |
| Anzeigen von Prüfprotokollen. |
| Verwaltung des Security Command Center. |
| Verwaltung von Secrets im Secret Manager. |
Standard-Passwortrichtlinie
Durchsetzung von starken Passwörtern
Zwischen 8 und 100 Zeichen
Keine Wiederverwendung
Kein Ablaufdatum
Wenn Personen über einen Drittanbieter auf Workspace zugreifen, werden diese Anforderungen nicht angewendet.
Dienstkonten
Dies sind die Prinzipale, die Ressourcen angehängt haben können und Zugriff haben, um einfach mit GCP zu interagieren. Zum Beispiel ist es möglich, auf das Authentifizierungstoken eines Dienstkontos zuzugreifen, das an eine VM angehängt ist, in den Metadaten.
Es kann zu Konflikten kommen, wenn sowohl IAM als auch Zugriffsberechtigungen verwendet werden. Zum Beispiel könnte Ihr Dienstkonto die IAM-Rolle compute.instanceAdmin haben, aber die Instanz, auf die Sie zugegriffen haben, wurde mit der Bereichseinschränkung https://www.googleapis.com/auth/compute.readonly eingeschränkt. Dadurch wird verhindert, dass Sie Änderungen mit dem automatisch Ihrem Dienst zugewiesenen OAuth-Token vornehmen können.
Es ähnelt den IAM-Rollen von AWS. Aber anders als bei AWS kann jedes Dienstkonto an jeden Dienst angehängt werden (es muss nicht über eine Richtlinie zugelassen werden).
Einige der Dienstkonten, die Sie finden werden, werden tatsächlich automatisch von GCP generiert, wenn Sie einen Dienst verwenden, wie:
Jedoch ist es auch möglich, benutzerdefinierte Dienstkonten zu erstellen und an Ressourcen anzuhängen, die wie folgt aussehen werden:
Zugriffsberechtigungen
Zugriffsberechtigungen werden den generierten OAuth-Token zugeordnet, um auf die GCP-API-Endpunkte zuzugreifen. Sie beschränken die Berechtigungen des OAuth-Tokens. Das bedeutet, dass, wenn ein Token einem Besitzer einer Ressource gehört, aber nicht über den im Token festgelegten Bereich verfügt, um auf diese Ressource zuzugreifen, das Token nicht verwendet werden kann, um diese Berechtigungen zu (miss)brauchen.
Google empfiehlt tatsächlich, dass Zugriffsberechtigungen nicht verwendet werden und vollständig auf IAM vertraut wird. Das Web-Verwaltungsportal setzt dies tatsächlich durch, aber Zugriffsberechtigungen können immer noch programmgesteuert auf Instanzen angewendet werden, die benutzerdefinierte Dienstkonten verwenden.
Sie können sehen, welche Bereiche zugewiesen sind, indem Sie abfragen:
Die vorherigen Berechtigungen sind diejenigen, die standardmäßig mit gcloud generiert werden, um auf Daten zuzugreifen. Dies liegt daran, dass Sie bei Verwendung von gcloud zunächst ein OAuth-Token erstellen und es dann verwenden, um die Endpunkte zu kontaktieren.
Die wichtigste Berechtigung davon ist wahrscheinlich cloud-platform, was im Grunde bedeutet, dass es möglich ist, auf jeden Dienst in GCP zuzugreifen.
Sie können eine Liste aller möglichen Berechtigungen hier finden.
Wenn Sie gcloud Browser-Anmeldeinformationen haben, ist es möglich, ein Token mit anderen Berechtigungen zu erhalten, indem Sie etwas Ähnliches tun wie:
Terraform IAM-Richtlinien, Bindungen und Mitgliedschaften
Wie von Terraform in https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam definiert, gibt es bei der Verwendung von Terraform mit GCP verschiedene Möglichkeiten, einem Prinzipal Zugriff auf eine Ressource zu gewähren:
Mitgliedschaften: Sie setzen Prinzipale als Mitglieder von Rollen ohne Einschränkungen über die Rolle oder die Prinzipale. Sie können einen Benutzer als Mitglied einer Rolle festlegen und dann eine Gruppe als Mitglied derselben Rolle festlegen und auch diese Prinzipale (Benutzer und Gruppe) als Mitglied anderer Rollen festlegen.
Bindungen: Mehrere Prinzipale können an eine Rolle gebunden werden. Diese Prinzipale können immer noch gebunden sein oder Mitglieder anderer Rollen sein. Wenn jedoch ein Prinzipal, der nicht an die Rolle gebunden ist, als Mitglied einer gebundenen Rolle festgelegt wird, verschwindet die Mitgliedschaft beim nächsten Mal, wenn die Bindung angewendet wird.
Richtlinien: Eine Richtlinie ist verbindlich, sie gibt Rollen und Prinzipale an und dann können diese Prinzipale keine weiteren Rollen haben und diese Rollen keine weiteren Prinzipale haben, es sei denn, diese Richtlinie wird geändert (nicht einmal in anderen Richtlinien, Bindungen oder Mitgliedschaften). Wenn also eine Rolle oder ein Prinzipal in einer Richtlinie angegeben ist, sind alle seine Berechtigungen durch diese Richtlinie eingeschränkt. Offensichtlich kann dies umgangen werden, falls dem Prinzipal die Möglichkeit gegeben wird, die Richtlinie zu ändern oder Berechtigungen für Eskalation von Privilegien zu erhalten (wie das Erstellen eines neuen Prinzips und Zuweisen einer neuen Rolle).
Referenzen
Last updated
