Google ACE: Ressourcenhierarchie, IAM und Abrechnungsverwaltung — Lernleitfaden

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

Überblick

Ressourcenhierarchie, Identitäts- und Zugriffsmanagement (IAM) und die Abrechnungsverwaltung bilden die Steuerungsebene (Control Plane) des Google Cloud-Betriebs. Ein resilientes Design beginnt mit einer klaren Hierarchie (Organisation, Ordner, Projekte) zur Festlegung des Geltungsbereichs von Richtlinien und Verantwortlichkeiten; wendet IAM nach dem Prinzip der geringsten Rechte (Least Privilege) mit gruppenbasierter Verwaltung und kurzlebigen Anmeldedaten für Workloads an; nutzt Budgets, Exporte und Labels zur Kostenzuordnung; und setzt Governance mit Organisationsrichtlinien und umfassender Audit-Protokollierung durch. Operative Exzellenz wird durch die Standardisierung der Vererbung, die Zentralisierung von Abrechnung und Protokollen und die Verwendung von Service Account Impersonation anstelle von langlebigen Schlüsseln erreicht. Dieser Abschnitt beschreibt die Kernkonstrukte, ihre beabsichtigte Verwendung und häufige Fehlermodi, die es zu vermeiden gilt.

Ressourcenhierarchie und Identitätsmodell

Ressourcenhierarchie
- Organisation: Der Stammknoten (Root Node), wird mit Cloud Identity oder Google Workspace erstellt. Besitzt globale Richtlinien (IAM, Organisationsrichtlinien, Tags).
- Ordner: Optionale Gruppierung für Abteilungen, Umgebungen (z. B. Dev, Prod) oder Anwendungen. Nützlich für delegierte Administration und die Festlegung von Richtlinienbereichen.
- Projekte: Administrative Grenze für Ressourcen, APIs, Kontingente, IAM und die Zuordnung zur Abrechnung. Die meisten Google Cloud-Ressourcen sind untergeordnete Elemente von Projekten.
- Vererbung: IAM-Richtlinien und Organisationsrichtlinien werden von oben nach unten vererbt. Ablehnungen (Denies) und Einschränkungen auf höheren Ebenen haben Vorrang. Planen Sie die Platzierung (Organisation → Ordner → Projekte) so, dass Ausnahmen und Break-Glass-Notwendigkeiten minimiert werden.
Prinzipale
- Google-Konten (Nutzer), Google Groups, Service Accounts und externe Identitäten über Workload Identity Federation.
- Google Groups sollten das primäre Ziel für die Zuweisung von Zugriff für Menschen sein, um Änderungen im Lebenszyklus und Überprüfungen zu vereinfachen.
- Service Accounts repräsentieren Anwendungen oder Dienste; bevorzugen Sie Workload Identity gegenüber Schlüsseln.
Workload Identities
- In Google Cloud: GCE/GAE/Cloud Run/GKE verwenden den Metadatenserver, um kurzlebige Token für das angehängte Service Account zu erstellen (minting).
- Außerhalb von Google Cloud: Workload Identity Federation bildet externe Identitäten (OIDC/SAML/AWS) auf Service Accounts ab, ohne statische Schlüssel zu verwenden.
Design-Abwägungen und Fehlermodi
- Ein Wildwuchs an Projekten ohne Ordnerstruktur führt zu doppelten Richtlinien und Abweichungen (Drift).
- Die direkte Zuweisung von Rollen an Benutzer erhöht den manuellen Aufwand (Toil); bevorzugen Sie gruppenbasierte Zuweisungen (Bindings).
- Die Verwendung des Compute Engine-Standard-Service-Accounts mit weitreichenden Berechtigungen erhöht das Risiko; erstellen Sie pro Workload Service Accounts mit den geringsten Rechten.
- Das Platzieren eines Projekts im falschen Ordner führt zur Vererbung falscher Richtlinien; verwenden Sie Tags oder verschieben Sie Projekte sorgfältig unter Anwendung von Change Control.

IAM-Rollen und Richtliniendesign

Rollentypen
- Basisrollen (Betrachter, Bearbeiter, Inhaber): Weitreichend, veraltet. Vermeiden Sie sie, außer für streng kontrollierte Break-Glass-Szenarien.
- Vordefinierte Rollen: Pro Dienst kuratiert; für die meisten Anwendungsfälle zu bevorzugen.
- Benutzerdefinierte Rollen: Auf Organisations- oder Projektebene definierte Zusammenfassung von Berechtigungen für maßgeschneiderte Anforderungen.
- Bedingte Rollen: IAM Conditions (CEL) fügen Kontext wie Ressourcenname, Ordner, Tags oder Zeit hinzu; verwenden Sie sie, um mächtige Rollen einzuschränken.
Richtlinienprinzipien
- Geringste Rechte (Least Privilege): Weisen Sie nur die minimale Rolle auf dem engsten Geltungsbereich (Ressource/Projekt/Ordner) zu.
- Funktionstrennung (Separation of Duties): Trennen Sie Aufgaben (z. B. Netzwerk-Admin vs. Sicherheits-Admin vs. Abrechnungs-Admin). Koppeln Sie nicht die Aktionen zur Bereitstellung und Genehmigung in einem einzigen Prinzipal.
- Bewusstsein für Vererbung: Eine Zuweisung (Binding) auf Organisations-/Ordnerebene betrifft alle untergeordneten Elemente; dokumentieren Sie den beabsichtigten „Blast Radius“ vor der Anwendung.
Deny-Richtlinien
- IAM Deny blockiert explizit Berechtigungen, selbst wenn sie an anderer Stelle gewährt wurden; verwenden Sie dies für Leitplanken (Guardrails) (z. B. deny iam.serviceAccountKeys.create).
- Deny hat Vorrang; stellen Sie dokumentierte Break-Glass-Prozesse mit zeitlich begrenzten Ausnahmeregelungen sicher.
Beispiele
- Kopieren einer benutzerdefinierten Rolle von Dev nach Prod: gcloud iam roles copy ROLE_ID
  –source=projects/DEV_PROJECT
  –destination=projects/PROD_PROJECT
- Gewähren von gruppenbasiertem SSH-Admin-Zugriff mit OS Login: gcloud projects add-iam-policy-binding PROJECT_ID
  –member=group:ops-admins@example.com
  –role=roles/compute.osAdminLogin
Fehlermodi
- Die Rolle „Bearbeiter“ (Editor), die auf Organisations- oder Ordnerebene gewährt wird, wird unbeabsichtigt auf alle Projekte kaskadiert.
- Bedingte Rollen mit zu strengen Bedingungen können unbemerkt Automatisierungen stören; testen Sie sie vor der Einführung mit dem Policy Troubleshooter.
- Benutzerdefinierte Rollen hinken neuen Berechtigungen hinterher; überprüfen Sie sie regelmäßig.

Abrechnungs- und Kostenverwaltung

Abrechnungskonten und Zuordnung
- Ein Projekt muss für kostenpflichtige Dienste mit genau einem Abrechnungskonto verknüpft sein.
- Rollen: Der Billing Account Administrator verwaltet das Konto und die Zahlungsmethoden; der Billing Account User verknüpft Projekte; der Project Billing Manager verwaltet die Abrechnungsverknüpfung eines Projekts.
- Zentralisieren Sie alles in einem Unternehmenskonto für die Abrechnung; migrieren Sie Projekte, indem Sie die Abrechnungszuordnung des Projekts aktualisieren.
Budgets, Warnungen und Zuordnung
- Budgets generieren Warnungen, keine Ausgabenlimits (Spend Caps). Nutzen Sie programmatische Korrekturmaßnahmen mit Pub/Sub und Cloud Functions/Cloud Run, wenn eine Durchsetzung erforderlich ist.
- Exportieren Sie Abrechnungsdaten nach BigQuery für tägliche/monatliche Kostenanalysen und Prognosen; kombinieren Sie sie mit Ressourcen-Labels und Tags zur Zuordnung.
- Labels und Tags: Standardisieren Sie die Schlüssel (z. B. cost_center, env, app). Fehlende Labels verringern die Genauigkeit der Zuordnung.
Kostenanalyse
- Verwenden Sie den BigQuery-Export, um gleitende Prognosen nach SKU/Dienst mit SQL zu berechnen. Verknüpfen Sie diese mit Ressourcen-Metadaten (z. B. GCE-Labels) für granulare Berichte.
- Für projektübergreifende Analysen aggregieren Sie die Daten über alle Projektexporte oder exportieren Sie sie in ein einziges zentrales Dataset.
Häufige Fallstricke
- Budgets werden für neue Projekte nicht konfiguriert; etablieren Sie eine Richtlinie zur automatischen Erstellung von Budgets bei der Projekterstellung.
- Kein BigQuery-Export bedeutet begrenzte historische Einblicke; aktivieren Sie ihn frühzeitig, um eine Historie aufzubauen.
- Persönliche Kreditkarten für Projekte fragmentieren die Verantwortlichkeit; konsolidieren Sie diese unter dem zentralen Unternehmenskonto für die Abrechnung mit entsprechenden IAM- und Zahlungsprofilen.
- Kostenanomalien in Projekten für gemeinsam genutzte Dienste erfordern Tagging und eine Richtlinie zur internen Weiterverrechnung (Cross-Charging).

Sichere Authentifizierungs- und Zugriffsmuster für Workloads

Identitätswechsel von Servicekonten
- Bevorzugen Sie den Identitätswechsel gegenüber Schlüsseln. Vergeben Sie die Rolle roles/iam.serviceAccountTokenCreator an eine Aufrufer-Identität; der Aufrufer erhält kurzlebige Token, um als das Servicekonto zu agieren.
- Beispiel: gcloud auth print-access-token
  –impersonate-service-account sa-deployer@PROJECT_ID.iam.gserviceaccount.com
Schlüssel und Rotation
- Vermeiden Sie benutzerverwaltete Schlüssel. Falls erforderlich, speichern Sie diese im Secret Manager, rotieren Sie sie mindestens alle 90 Tage, überwachen Sie die Nutzung und schränken Sie sie mit VPC Service Controls und CMEK ein.
- Erzwingen Sie Einschränkungen, um die Erstellung von Schlüsseln zu blockieren: constraints/iam.disableServiceAccountKeyCreation = true
OS Login und SSH
- Verwenden Sie OS Login mit gruppenbasierten IAM-Rollen (compute.osLogin, compute.osAdminLogin). Jeder Benutzer lädt seinen öffentlichen SSH-Schlüssel in sein Google-Konto hoch, um einen zuordenbaren Zugriff zu ermöglichen. Die Überwachung erfolgt über Admin Activity- und Data Access-Logs.
- Vermeiden Sie es, gemeinsam genutzte SSH-Schlüssel in Images zu integrieren.
Workload Identity Federation
- Für On-Premises-Umgebungen oder andere Clouds, konfigurieren Sie die Identitätsföderation, um Zugriff auf Google Cloud zu gewähren, ohne Schlüssel erstellen zu müssen, was das Risiko der Datenexfiltration reduziert.
Fehlerszenarien und Gegenmaßnahmen
- Das Speichern von Schlüsseln in Repositories oder CI/CD-Variablen führt zu Kompromittierungen; wechseln Sie zu Identitätswechsel oder Föderation.
- Standard-Servicekonten mit weitreichenden Rollen sind riskant; schränken Sie diese mit constraints/iam.allowedPolicyMemberDomains ein und entfernen Sie primitive Rollen.
- Fehlende Geltungsbereiche (Scopes) bei älteren GCE-Instanzen können den API-Zugriff blockieren; bevorzugen Sie die Verwendung von IAM pro API zusammen mit den Default Application Credentials.

Governance, Organisationsrichtlinien, Audit und Fehlerbehebung

Organisationsrichtlinien und Einschränkungen
- Leitplanken mithilfe von Einschränkungen durchsetzen: externe IPs auf VMs verbieten, Regionen einschränken, Schlüsselerstellung verhindern, zulässige Dienste einschränken, einheitlichen Zugriff auf Bucket-Ebene fordern, Domain-Freigaben einschränken.
- Anwendung auf die Ressourcenhierarchie und Verfeinerung mit Tags für umgebungsspezifische Ausnahmen.
Cloud Identity und Lebenszyklus
- Cloud Identity stellt das Benutzerverzeichnis, SSO und administrative Rollen bereit. Delegieren Sie Rechte eng gefasst (z. B. Group Admin, User Management Admin) und automatisieren Sie Joiner-Mover-Leaver-Workflows, um Gruppenzugehörigkeiten und Zugriffe zu aktualisieren.
- Verwenden Sie Access Approvals und Access Transparency für sensible Umgebungen.
Audit-Logging
- Admin Activity- und System Event-Logs sind immer aktiviert; Data Access-Logs müssen explizit aktiviert werden und können Kosten verursachen.
- Zentralisieren Sie Logs, indem Sie aggregierte Senken von Ordnern/der Organisation an ein Sicherheitsprojekt weiterleiten. Schützen Sie diese mit CMEK und eingeschränktem Zugriff.
- Überwachen Sie Policy Denied-Logs, um Konflikte mit Organisationsrichtlinien zu erkennen.
Toolkit zur Fehlerbehebung über mehrere Projekte hinweg
- Policy Troubleshooter: Diagnostiziert, warum der Zugriff angesichts der effektiven IAM- und Ablehnungsrichtlinien gewährt oder verweigert wird.
- Cloud Asset Inventory: Fragt IAM-Bindungen und den Richtlinienverlauf über die Organisation/Ordner/Projekte hinweg ab. Beispiel: gcloud asset search-all-iam-policies
  –scope=organizations/ORG_ID
  –query=‘policy:roles/storage.objectAdmin AND “bucket-name”’
- Logs Explorer: Filtern nach Principal, Methode und Ressource, um Aktionen über Projekte hinweg nachzuverfolgen.
- gcloud-Konfigurationen für den Kontextwechsel von Operatoren: gcloud config configurations activate PROD
- Häufige Fehlermodi: widersprüchliche Organisationsrichtlinien, die Deployments blockieren, fehlende Data Access-Logs, die Untersuchungen behindern, und IAM-Berechtigungen, die auf der falschen Ebene erteilt wurden. Etablieren Sie Runbooks und Vorschauen vor Änderungen, um die MTTR bei Incidents zu reduzieren.

Praktisches Problemszenario

Aurelia Retail konsolidiert nach einer Übernahme mehrere Teams und Projekte. Das Unternehmen muss die Abrechnung zentralisieren, eine konsistente IAM- und SSH-Verwaltung für Hunderte von Compute Engine-VMs durchsetzen und eine Governance mit minimaler Unterbrechung etablieren.

Ein Unternehmensrechnungskonto erstellen und Projekte verknüpfen

Begründung: Ein einziges Rechnungskonto zentralisiert Zahlungsmethoden, Guthaben und Budgets. Weisen Sie einer Projektmigrationsgruppe die Rolle Billing Account User und den Teamleitern die Rolle Project Billing Manager zu, um Projekte neu zu verknüpfen, ohne übermäßige Rechte zu vergeben.
Maßnahme: Erstellen Sie das Rechnungskonto in der Konsole. Aktualisieren Sie für jedes Projekt dessen Abrechnungszuordnung. Aktivieren Sie sofort den Billing-Export nach BigQuery in einem zentralen Analyseprojekt.

Ressourcenhierarchie mit Ordnern und Tags standardisieren

Begründung: Das Platzieren von Projekten in Umgebungsordnern (prod, nonprod) unterstützt die Vererbung von Leitplanken und gezielte Ausnahmen. Tags ermöglichen eine feingranulare Anwendung von Organisationsrichtlinien, ohne Ordnerstrukturen duplizieren zu müssen.
Maßnahme: Erstellen Sie Ordner für prod und nonprod; verschieben Sie die Projekte entsprechend. Definieren Sie Tags wie env=prod|nonprod und App-Identifikatoren.

Gruppenbasiertes IAM mit dem Prinzip der geringsten Rechte und Funktionstrennung implementieren

Begründung: Gruppen vereinfachen den Lebenszyklus und die Auditierung. Die Aufteilung der Rollen auf Deployer, Sicherheits- und Netzwerkadministratoren reduziert den „Blast Radius“ (Schadensradius).
Maßnahme: Erstellen Sie Google-Gruppen für app-operators, net-admins, sec-admins und billing-managers. Binden Sie vordefinierte Rollen je nach Bedarf auf Ordner-/Projektebene; vermeiden Sie einfache Rollen.

SSH-Verwaltung auf Basis von OS Login erzwingen

Begründung: Individuelle, an Benutzerkonten gebundene SSH-Schlüssel bieten einen zuordenbaren und widerrufbaren Zugriff. OS Login-Rollen verwalten Linux-Konten über IAM, wodurch gemeinsam genutzte Schlüssel überflüssig werden.
Maßnahme: Aktivieren Sie in jedem Projekt die OS Login-Metadaten. Weisen Sie der Gruppe ops-admins die Rolle compute.osAdminLogin zu. Beispiel: gcloud compute project-info add-metadata
–metadata enable-oslogin=TRUE

Service-Account-Schlüssel durch Identitätsübernahme (Impersonation) ersetzen

Begründung: Kurzlebige Anmeldedaten mindern das Risiko der Exfiltration von Schlüsseln und vereinfachen deren Rotation. Audit-Logs erfassen, wer die Identität eines anderen Kontos übernommen hat, was die Nachverfolgbarkeit verbessert.
Maßnahme: Weisen Sie CI/CD-Runner-Identitäten die Rolle roles/iam.serviceAccountTokenCreator für die Workload-Service-Accounts zu. Entfernen Sie benutzerverwaltete Schlüssel und wenden Sie eine Organisationsrichtlinie an, um die Erstellung neuer Schlüssel zu blockieren.

Organisationsrichtlinien als Leitplanken anwenden

Begründung: Einschränkungen verhindern riskante Konfigurationen in allen Projekten, erlauben aber getaggte Ausnahmen, wo diese gerechtfertigt sind.
Maßnahme: Setzen Sie Einschränkungen durch, um externe IPs in der Prod-Umgebung zu verbieten, Regionen auf genehmigte Standorte zu beschränken und die Erstellung von Service-Account-Schlüsseln zu deaktivieren. Verwenden Sie Tags, um Ausnahmen für bestimmte Projekte mit dokumentierter Genehmigung zu erlauben.

Kostengovernance etablieren

Begründung: Budgets benachrichtigen die Verantwortlichen vor einer Budgetüberschreitung; der BigQuery-Export ermöglicht die Kostenzuordnung und -prognose. Labels und Tags ordnen die Ressourcenausgaben den Kostenstellen zu.
Maßnahme: Erstellen Sie Budgets pro Ordner und pro wichtiger Anwendung mit Pub/Sub-Benachrichtigungen. Setzen Sie Label-Richtlinien über Deployment-Vorlagen und Richtlinienvalidierung in der CI-Pipeline durch.

Audits zentralisieren und Fehlerbehebung beschleunigen

Begründung: Aggregiertes Logging und ein Asset-Inventar über die gesamte Organisation beschleunigen Untersuchungen und Compliance-Berichte.
Maßnahme: Erstellen Sie aggregierte Senken zu einem Sicherheitsprojekt mit CMEK-geschützten Buckets. Aktivieren Sie Data Access-Logs für kritische Dienste (Cloud Storage, BigQuery). Verwenden Sie Cloud Asset Inventory, um regelmäßig IAM-Bindungen zu scannen. Schulen Sie Operatoren darin, den Policy Troubleshooter bei Zugriffsproblemen und den Logs Explorer zur Nachverfolgung von Admin Activity/Data Access zu verwenden.

Änderungen mit Vorschauen und gestaffeltem Rollout operationalisieren

Begründung: Die Validierung von IAM- und Richtlinienauswirkungen vor der Durchsetzung reduziert Ausfälle.
Maßnahme: Testen Sie IAM- und Organisationsrichtlinien zuerst in der Non-Prod-Umgebung. Nutzen Sie Probeläufe (Dry-Runs) und Richtliniensimulationen, wo verfügbar. Implementieren Sie für die Deployment-Automatisierung Canary-Deployments und Rollback-Pläne.

Dieser Ansatz führt zu einer zentralisierten Abrechnung und Kostentransparenz, einer nachvollziehbaren SSH-Verwaltung über OS Login, einem IAM mit geringsten Rechten durch Identitätsübernahme, starken präventiven Kontrollen durch Organisationsrichtlinien sowie robusten Audit- und Fehlerbehebungsfunktionen in der neuen Umgebung mit mehreren Projekten.

Alle Domänen · Compute Engine und Betrieb virtueller Maschinen →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →