GCP - Basic Information
Ressourcenhierarchie
Google Cloud verwendet eine Ressourcenhierarchie, die konzeptionell der eines traditionellen Dateisystems ähnelt. Dies bietet einen logischen Eltern/Kind-Workflow mit spezifischen Anknüpfungspunkten für Richtlinien und Berechtigungen.
Auf hoher Ebene sieht es so aus:
Eine virtuelle Maschine (genannt Compute Instance) ist eine Ressource. Eine Ressource befindet sich in einem Projekt, wahrscheinlich zusammen mit anderen Compute Instances, Speicher-Buckets usw.
Projekte Migration
Es ist möglich, ein Projekt ohne Organisation zu einer Organisation mit den Berechtigungen roles/resourcemanager.projectCreator und roles/resourcemanager.projectMover zu migrieren. Wenn sich das Projekt in einer anderen Organisation befindet, muss der GCP-Support kontaktiert werden, um es zuerst aus der Organisation zu entfernen. Weitere Informationen finden Sie hier.
Organisationsrichtlinien
Ermöglichen die Zentralisierung der Kontrolle über die Cloud-Ressourcen Ihrer Organisation:
Zentralisieren Sie die Kontrolle, um Einschränkungen zu konfigurieren, wie die Ressourcen Ihrer Organisation verwendet werden können.
Definieren und etablieren Sie Leitplanken für Ihre Entwicklungsteams, um innerhalb der Compliance-Grenzen zu bleiben.
Helfen Sie Projektbesitzern und ihren Teams, schnell zu agieren, ohne sich Sorgen um die Einhaltung von Vorschriften machen zu müssen.
Diese Richtlinien können erstellt werden, um die gesamte Organisation, Ordner oder Projekte zu betreffen. Nachkommen des Zielressourcen-Hierarchieknotens erben die Organisationsrichtlinie.
Um eine Organisationsrichtlinie zu definieren, wählen Sie eine Einschränkung, die eine bestimmte Art von Einschränkung gegen einen Google Cloud-Dienst oder eine Gruppe von Google Cloud-Diensten darstellt. Sie konfigurieren diese Einschränkung mit Ihren gewünschten Beschränkungen.
Häufige Anwendungsfälle
Begrenzen Sie das Teilen von Ressourcen basierend auf der Domain.
Begrenzen Sie die Nutzung von Identity and Access Management-Dienstkonten.
Beschränken Sie den physischen Standort neu erstellter Ressourcen.
Deaktivieren Sie die Erstellung von Dienstkonten.
Es gibt viele weitere Einschränkungen, die Ihnen eine feinkörnige Kontrolle über die Ressourcen Ihrer Organisation geben. Für weitere Informationen siehe die Liste aller Organisation Policy Service-Einschränkungen.
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. Stattdessen geben Ressourcen X Zugriffsrollen an Y-Prinzipale, und der einzige Weg, um herauszufinden, wer Zugriff auf eine Ressource hat, ist die Verwendung der get-iam-policy-Methode über diese Ressource.
Dies könnte ein Problem sein, da dies bedeutet, dass der einzige Weg, um herauszufinden, welche Berechtigungen ein Prinzipal hat, darin besteht, jede Ressource zu fragen, wem sie Berechtigungen erteilt, und ein Benutzer möglicherweise keine Berechtigungen hat, um Berechtigungen von allen Ressourcen zu erhalten.
Es gibt drei Arten von Rollen in IAM:
Basis-/Primitive Rollen, die die Owner, Editor und Viewer Rollen umfassen, die vor der Einführung von IAM existierten.
Vordefinierte Rollen, die granulare Zugriffsrechte für einen bestimmten Dienst bieten und von Google Cloud verwaltet werden. Es gibt viele vordefinierte Rollen, Sie können alle mit den ihnen zugewiesenen Privilegien hier einsehen.
Benutzerdefinierte Rollen, die granulare Zugriffsrechte gemäß einer vom Benutzer festgelegten Liste von Berechtigungen bieten.
Es gibt Tausende von Berechtigungen in GCP. Um zu überprüfen, ob eine Rolle eine Berechtigung hat, können Sie die Berechtigung hier suchen und sehen, welche Rollen sie haben.
Sie können auch hier vordefinierte 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, weil einige Berechtigungen sie enthalten. Beachten Sie außerdem, dass Berechtigungen nur wirksam werden, wenn sie an den relevanten Dienst angehängt sind.
Oder überprüfen Sie, ob eine benutzerdefinierte Rolle eine spezifische Berechtigung hier verwenden kann.
GCP - IAM, Principals & Org Policies EnumBenutzer
In der GCP-Konsole gibt es keine Benutzer- oder Gruppenverwaltung, dies wird in Google Workspace durchgeführt. Obwohl Sie einen anderen Identitätsanbieter in Google Workspace synchronisieren könnten.
Sie können auf Workspaces Benutzer und Gruppen zugreifen unter https://admin.google.com.
MFA kann für Workspaces-Benutzer erzwungen werden, jedoch könnte ein Angreifer ein Token verwenden, um auf GCP über die CLI zuzugreifen, das nicht durch MFA geschützt ist (es wird nur durch MFA geschützt, wenn sich der Benutzer anmeldet, um es zu generieren: gcloud auth login).
Gruppen
Wenn eine Organisation erstellt wird, wird dringend empfohlen, mehrere Gruppen zu erstellen. Wenn Sie eine von ihnen verwalten, könnten Sie die gesamte oder einen wichtigen Teil der Organisation kompromittiert haben:
Gruppe | Funktion |
| Verwaltung aller Ressourcen, die zur Organisation gehören. Weisen Sie diese Rolle sparsam zu; Org-Admins haben Zugriff auf alle Ihre Google Cloud-Ressourcen. Alternativ, da diese Funktion hoch privilegiert ist, sollten Sie in Erwägung ziehen, individuelle Konten anstelle der Erstellung einer Gruppe zu verwenden. |
| Erstellung von Netzwerken, Subnetzen, Firewall-Regeln und Netzwerkgeräten wie Cloud Router, Cloud VPN und Cloud Load Balancers. |
| Einrichtung von Abrechnungskonten und Überwachung ihrer Nutzung. |
| Entwurf, Codierung und Testen von Anwendungen. |
| Einrichtung und Verwaltung von Sicherheitsrichtlinien für die gesamte Organisation, einschließlich Zugriffsmanagement und Organisationsbeschränkungsrichtlinien. Weitere Informationen zur Planung Ihrer Google Cloud-Sicherheitsinfrastruktur finden Sie im Google Cloud-Sicherheitsgrundlagen-Leitfaden. |
| Erstellung oder Verwaltung von End-to-End-Pipelines, 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 der Netzwerkkonfigurationen. |
| Ansicht von Audit-Logs. |
| Verwaltung des Security Command Centers. |
| Verwaltung von Geheimnissen im Secret Manager. |
Standard-Passwortrichtlinie
Erzwingen Sie starke Passwörter
Zwischen 8 und 100 Zeichen
Keine Wiederverwendung
Kein Ablaufdatum
Wenn Personen über einen Drittanbieter auf Workspace zugreifen, gelten diese Anforderungen nicht.
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 Auth-Token eines Dienstkontos zu zugreifen, das an eine VM in den Metadaten angehängt ist.
Es können einige Konflikte auftreten, wenn sowohl IAM als auch Zugriffsumfänge verwendet werden. Zum Beispiel kann Ihr Dienstkonto die IAM-Rolle compute.instanceAdmin haben, aber die Instanz, die Sie kompromittiert haben, wurde mit der Umfangsbeschränkung https://www.googleapis.com/auth/compute.readonly eingeschränkt. Dies würde verhindern, dass Sie Änderungen mit dem OAuth-Token vornehmen, das Ihrer Instanz automatisch zugewiesen wird.
Es ist ähnlich wie IAM-Rollen von AWS. Aber im Gegensatz zu AWS kann jedes Dienstkonto an jeden Dienst angehängt werden (es muss dies nicht über eine Richtlinie erlauben).
Mehrere der Dienstkonten, die Sie finden werden, werden tatsächlich automatisch von GCP generiert, wenn Sie einen Dienst zu verwenden beginnen, wie:
Es ist jedoch auch möglich, benutzerdefinierte Dienstkonten zu erstellen und an Ressourcen anzuhängen, die so aussehen:
Access scopes
Access Scopes sind an generierte OAuth-Tokens angehängt, 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 den entsprechenden Scope im Token hat, um auf diese Ressource zuzugreifen, das Token nicht verwendet werden kann, um diese Privilegien (aus)zu nutzen.
Google empfiehlt tatsächlich, dass Access Scopes nicht verwendet werden und vollständig auf IAM vertraut wird. Das Web-Management-Portal erzwingt dies tatsächlich, aber Access Scopes können programmgesteuert weiterhin auf Instanzen mit benutzerdefinierten Servicekonten angewendet werden.
Sie können sehen, welche Scopes zugewiesen sind, indem Sie abfragen:
Die vorherigen Scopes sind die, die standardmäßig mit gcloud generiert werden, um auf Daten zuzugreifen. Dies liegt daran, dass Sie, wenn Sie gcloud verwenden, zuerst ein OAuth-Token erstellen und es dann verwenden, um die Endpunkte zu kontaktieren.
Der wichtigste Scope davon ist potenziell cloud-platform, was im Wesentlichen bedeutet, dass es möglich ist, auf jeden Dienst in GCP zuzugreifen.
Sie können eine Liste aller möglichen Scopes hier finden.
Wenn Sie gcloud-Browser-Anmeldeinformationen haben, ist es möglich, ein Token mit anderen Scopes zu erhalten, indem Sie etwas wie:
Terraform IAM Policies, Bindings und Memberships
Wie von terraform definiert in https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam gibt es verschiedene Möglichkeiten, einem Principal mit terraform in GCP Zugriff auf eine Ressource zu gewähren:
Memberships: Sie setzen Principals als Mitglieder von Rollen ohne Einschränkungen über die Rolle oder die Principals. Sie können einen Benutzer als Mitglied einer Rolle setzen und dann eine Gruppe als Mitglied derselben Rolle setzen und auch diese Principals (Benutzer und Gruppe) als Mitglieder anderer Rollen setzen.
Bindings: Mehrere Principals können an eine Rolle gebunden werden. Diese Principals können weiterhin an andere Rollen gebunden oder Mitglieder anderer Rollen sein. Wenn jedoch ein Principal, der nicht an die Rolle gebunden ist, als Mitglied einer gebundenen Rolle gesetzt wird, verschwindet die Mitgliedschaft beim nächsten Anwenden der Bindung.
Policies: Eine Policy ist maßgeblich, sie gibt Rollen und Principals an und dann können diese Principals keine weiteren Rollen und diese Rollen keine weiteren Principals haben, es sei denn, diese Policy wird geändert (nicht einmal in anderen Policies, Bindings oder Memberships). Daher sind alle Privilegien einer in der Policy angegebenen Rolle oder eines Principals durch diese Policy eingeschränkt. Offensichtlich kann dies umgangen werden, wenn dem Principal die Möglichkeit gegeben wird, die Policy zu ändern oder Berechtigungen zur Privilegieneskalation zu erhalten (wie das Erstellen eines neuen Principals und das Binden einer neuen Rolle).
Referenzen
Last updated
