Google PCA: Organisationsdesign, IAM und Cloud-Governance — Lernleitfaden

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Teil des Google Professional Cloud Architect — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Organisationsdesign, IAM und Governance bilden die Grundlage, auf der alle Google Cloud-Architekturen aufbauen. Gute Designs schaffen klare administrative Grenzen, minimieren den Blast-Radius, ermöglichen das Prinzip der geringsten Rechte (Least Privilege), kontrollieren Kosten und skalieren operativ über viele Teams und Umgebungen hinweg. Governance sollte Leitplanken statt Schranken betonen: Automatisieren Sie Standardeinstellungen, die sicher, messbar und umkehrbar sind, während Sie die tägliche Kontrolle an die Teams delegieren, die der Workload am nächsten sind.

Ressourcenhierarchie und Identitätsgrundlagen

Google Cloud-Ressourcen bilden eine strikte Baumstruktur: Organisation → Ordner → Projekte → Ressourcen (z. B. Compute Engine-Instanzen, Buckets). IAM-Richtlinien und Einschränkungen der Organisationsrichtlinie werden in der Baumstruktur nach unten vererbt.

Wichtige Designprinzipien:

Verwenden Sie eine einzige Organisation, um die Governance zu zentralisieren. Erstellen Sie Ordner auf oberster Ebene für wichtige administrative Grenzen (z. B. Geschäftsbereiche, Regionen oder regulierte vs. nicht regulierte Bereiche).
Erstellen Sie innerhalb jeder Grenze Umgebungsordner (prod, nonprod), um differenzierte Richtlinien anzuwenden. Halten Sie Projekte nach Möglichkeit Workload-bezogen und kurzlebig (ephemeral), um den Blast-Radius zu reduzieren und die Kostenverrechnung zu vereinfachen.
Vererbung: Zulassungsberechtigungen akkumulieren sich (Vereinigungsmenge der Zulassungsbindungen von übergeordneten Elementen und dem Knoten). IAM Deny-Richtlinien haben, falls verwendet, Vorrang und können den Zugriff blockieren, auch wenn eine Zulassung existiert. Vermeiden Sie es, weitreichende Rollen weit oben in der Hierarchie zu platzieren; der Blast-Radius ist groß und schwer rückgängig zu machen.

Identitätsquellen:

Cloud Identity ist die Identitätsebene für Mitarbeiter. Integrieren Sie es mit Ihrem unternehmenseigenen IdP (SAML/OIDC), um die Authentifizierung und den Mitarbeiterlebenszyklus (Onboarding, Versetzungen, Offboarding) zu zentralisieren. Verwenden Sie bei Bedarf Google Cloud Directory Sync zur Synchronisierung von Attributen und Gruppen.
Gruppen sind die primären Subjekte in IAM. Gruppenbasierter Zugriff ermöglicht skalierbare Änderungen und eine nachvollziehbare Zuständigkeit. Verwenden Sie ein Gruppe-von-Gruppen-Muster (z. B. net-admins, sec-admins, app-team-A) und schränken Sie ein, wer die Gruppenmitgliedschaft verwalten darf.
Dienstkonten (Service Accounts) repräsentieren Workloads. Bevorzugen Sie den Identitätswechsel für Dienstkonten (Service Account Impersonation) mit kurzlebigen Anmeldedaten gegenüber gespeicherten Schlüsseln. Vermeiden Sie benutzerverwaltete Dienstkontoschlüssel; behandeln Sie diese als Ausnahmen mit strengen Genehmigungen und Rotation.
Muster für Workload-Identitäten:
- GKE Workload Identity bindet Kubernetes Service Accounts an Google Service Accounts; dies eliminiert knotenweite Anmeldedaten.
- Workload Identity Federation ermöglicht es externen Identitäten (On-Premises, andere Clouds, GitHub Actions), kurzlebigen Zugriff auf Google-Ressourcen ohne Schlüssel zu erhalten. Verwenden Sie den Geltungsbereich auf Pool/Provider-Ebene und Attributbedingungen, um den Zugriff einzuschränken.

Häufige Fehlermodi und Gegenmaßnahmen:

Die Vergabe von Basisrollen (Inhaber/Bearbeiter/Betrachter) auf Ordner- oder Organisationsebene führt zu weitreichender Überprivilegierung. Verwenden Sie diese nur in eng begrenzten Break-Glass-Projekten.
Gruppenwildwuchs mit unklaren Zuständigkeiten untergräbt das Least-Privilege-Prinzip. Erzwingen Sie Namenskonventionen, Zweck-Tags und Eigentümer-Metadaten für Gruppen.
Verwaiste Dienstkonten und veraltete Bindungen stellen ein akkumuliertes Risiko dar. Planen Sie wiederkehrende Zugriffsüberprüfungen und nutzen Sie den IAM Recommender, um ungenutzte Berechtigungen zu reduzieren.

IAM-Modelle, Rollen und Zugriffsvorgänge

Rollen und Bindungen:

Vordefinierte Rollen sind für bestimmte Dienste zusammengestellt und sollten die Standardwahl sein.
Benutzerdefinierte Rollen füllen Lücken, wenn vordefinierte Rollen zu grob sind. Erstellen Sie sie aus dem minimalen Satz an Berechtigungen, die als notwendig erachtet werden; versionieren und testen Sie diese.
Basisrollen (Betrachter/Bearbeiter/Inhaber) sind veraltet und übermäßig weitreichend. Vermeiden Sie sie auf Organisations- und Ordnerebene. Verwenden Sie die Rolle „Inhaber“ nicht für den täglichen Betrieb; reservieren Sie sie für Notfallszenarien (Break-Glass) auf der Plattform mit starken kompensatorischen Kontrollen.
Bedingte Rollenbindungen (IAM Conditions) schränken ein, wann und wo eine Bindung gilt, indem sie Attribute wie resource.name, resource.matchTag, request.time oder request.auth.audiences verwenden. Nutzen Sie Bedingungen für zeitlich begrenzten Zugriff, auf Tags beschränkten Zugriff auf die Produktionsumgebung oder standortbezogene Aktionen.

Least Privilege und Rechteerweiterung:

Trennen Sie die Aufgaben „Lesen“, „Betreiben“ und „Verwalten“. Beispielsweise erhalten Netzwerk-, Sicherheits- und Anwendungsteams unterschiedliche Rollen in unterschiedlichen Geltungsbereichen.
Nutzen Sie Just-in-Time-Rechteerweiterung mit Access Approval-Workflows oder ticketbasierter Automatisierung, um zeitlich begrenzte Rollen über Bedingungen zu binden.

Deny-Richtlinien und deren Gefahren:

IAM Deny kann riskante Berechtigungen (z. B. resourcemanager.projects.delete) zentral blockieren. Eine Ablehnung (Deny) überschreibt eine Zulassung (Allow) und gilt für den gesamten Teilbaum. Validieren Sie sorgfältig; falsch konfigurierte Deny-Richtlinien können die Automatisierung aussperren oder Deployments lahmlegen.

Überprüfbarkeit und Audits:

Aktivieren Sie Administratorenaktivitäts-Logs auf Organisationsebene; diese werden standardmäßig 400 Tage aufbewahrt. Aktivieren Sie für sensible Dienste Datenzugriffs-Logs und leiten Sie diese zur langfristigen Aufbewahrung und für Audits an BigQuery weiter.
Implementieren Sie regelmäßige Zugriffsüberprüfungen: Listen Sie Bindungen mit Cloud Asset Inventory auf, vergleichen Sie sie mit Eigentümerverzeichnissen, entfernen Sie ungenutzte Rollen, die vom IAM Recommender vorgeschlagen werden, und überprüfen Sie das Ablaufdatum von Ausnahmen.

Nützliches Beispiel (zeitlich und auf Tags beschränkte Bindung):

undefined

Finanz-Governance und Schutzplanken durch Organisationsrichtlinien

Abrechnungsarchitektur:

Zentralisieren Sie ein oder mehrere Abrechnungskonten unter der Verantwortung der Finanzabteilung. Verwenden Sie mehrere Abrechnungskonten nur, wenn dies rechtlich oder betrieblich erforderlich ist (z. B. bei separaten juristischen Personen oder Reseller-Modellen).
Verknüpfen Sie Projekte über Automatisierung mit Abrechnungskonten; erlauben Sie keine manuelle Verknüpfung außerhalb genehmigter Arbeitsabläufe.

Kostenumlage und Kostentransparenz:

Verwenden Sie Labels und Kostenzuordnungs-Tags konsistent. Labels sind Freiform-Metadaten für Filterung und Berichterstattung; Tags sind hierarchisch und können in IAM Conditions und Richtlinien verwendet werden. Aktivieren Sie die Kostenzuordnung für ausgewählte Tags, damit diese in Abrechnungsexporten erscheinen.
Exportieren Sie Abrechnungsdaten zur Analyse nach BigQuery; erstellen Sie Dashboards pro Verantwortlichem, Kostenstelle und Umgebung. Fordern Sie für jedes Projekt einen verantwortlichen Eigentümer und ein Budget.

Budgets und Anomalieerkennung:

Erstellen Sie Budgets mit Benachrichtigungen auf Ordner- und Projektebene. Fügen Sie programmatische Reaktionen hinzu (z. B. Benachrichtigung des Bereitschaftsdienstes, Eröffnung von Tickets oder Deaktivierung neuer Kontingenterhöhungen), um ausufernde Kosten einzudämmen.
Nutzen Sie Quotas und zugesicherte Rabatte (CUDs) entsprechend der erwarteten Nutzung; überwachen Sie die Auslastung.

Einschränkungen durch Organisationsrichtlinien (standardmäßig sicher):

Setzen Sie Schutzplanken auf Organisations- oder Ordnerebene durch und lockern Sie diese nur in begründeten Fällen. Gängige Einschränkungen:
- constraints/iam.disableServiceAccountKeyCreation = true
- constraints/compute.requireOsLogin = true
- constraints/compute.trustedImageProjects zur Einschränkung von VM-Images
- constraints/sql.restrictPublicIp = true
- constraints/storage.uniformBucketLevelAccess = true
- constraints/compute.disableSerialPortAccess = true
Verwenden Sie VPC Service Controls, um das Risiko der Datenexfiltration für unterstützte Dienste über sensible Perimeters hinweg zu reduzieren.

Umgang mit Richtlinienausnahmen:

Ausnahmen müssen beantragbar, genehmigt, zeitlich begrenzt und prüfbar sein. Bevorzugen Sie IAM Conditions, um den Geltungsbereich von Ausnahmen nach Tag/Zeit einzugrenzen. Gleichen Sie Ausnahmen regelmäßig ab und lassen Sie sie über Policy-as-Code-Pipelines automatisch auslaufen.