Kennen Sie diesen Moment, in dem das Herz kurz aussetzt – weil Ihnen klar wird, dass Sie gerade versehentlich wichtige Daten aus der Datenbank gelöscht oder das Produktivsystem statt der Dev-Umgebung geleert haben? Und als wäre das nicht schon Albtraum genug, stellen Sie fest: Es waren keine Backups aktiviert. Ein Szenario, das vielen von uns nur allzu vertraut ist. Bei DoiT erreichen uns fast wöchentlich Tickets mit genau solchen Geschichten. In diesem Beitrag erfahren Sie, wie Sie verhindern, dass Ihnen das noch einmal passiert.
Werfen wir zunächst einen Blick auf Organizational Policies.
Organizational Policies
Wie der Name schon nahelegt, sind Organizational Policies ein Werkzeug, mit dem Administratoren das Verhalten von Ressourcen innerhalb ihrer GCP-Organisation und ihrer Projekte steuern können. Es handelt sich um Regeln auf Organisations-, Ordner- oder Projektebene, die festlegen, welche Aktionen mit Ressourcen auf der jeweiligen Ebene erlaubt oder unzulässig sind. Damit lassen sich Sicherheits-, Compliance- und Betriebsvorgaben durchsetzen – und für unser Szenario besonders praktisch: auch CloudSQL-Backups verbindlich vorschreiben.
Wie das geht? Leider helfen die GCP-Dokumentation und die zugehörigen Guides hier kaum weiter. Die Beispiele funktionieren entweder nicht oder bleiben unverständlich, wenn man nicht ohnehin schon mit Common Expression Language vertraut ist. Ich bin nur durch Zufall darauf gestoßen, als ich einen Kunden bei genau diesem Problem unterstützt habe. Gehen wir es Schritt für Schritt durch. Wir nutzen Custom Constraints, um die Erstellung oder Änderung jeder CloudSQL-Datenbank zu blockieren, für die kein Point-in-Time Recovery (PITR) aktiviert ist. PITR ist ein Wiederherstellungsverfahren, mit dem sich eine Datenbank auf einen bestimmten Zeitpunkt zurücksetzen lässt – typischerweise auf einen Stand vor einem Datenverlust oder einer Datenkorruption.
Schritt-für-Schritt-Anleitung
Schritt 1: Custom Constraint anlegen
Im ersten Schritt legen wir ein Constraint an, das jeden Versuch ablehnt, eine CloudSQL-Datenbank ohne aktiviertes PITR zu starten oder zu ändern. Wichtig: Wenn Sie eine bestehende CloudSQL-Datenbank ohne PITR ändern möchten, wird auch diese Änderung blockiert – es sei denn, Sie aktivieren gleichzeitig PITR.
- Zur Konsole für Organizational Policies wechseln
Öffnen Sie die Google Cloud Console und wählen Sie Ihre Organisation aus.
2. Custom Constraint anlegen
- Klicken Sie auf CUSTOM CONSTRAINT.

- Vergeben Sie einen Namen und eine Beschreibung. Das hilft dabei, das Constraint später wiederzuerkennen und einzuordnen.
- Wählen Sie unter Enforcement Type den Eintrag `sqladmin.googleapis.com/instance` aus.
- Legen Sie fest, dass das Constraint bei Create- und Update-Aktionen greift.
- Klicken Sie auf das Stiftsymbol neben [define condition], um die Bedingung einzugeben.
3. Bedingung definieren
- Tragen Sie folgende Bedingung ein, um PITR-Backups zu erzwingen:
resource.settings.backupConfiguration.pointInTimeRecoveryEnabled == false
- Setzen Sie die Action auf `deny`.
Schritt 2: Constraint durchsetzen
Sobald das Custom Constraint angelegt ist, geht es im nächsten Schritt darum, es in Ihrer Organisation auch durchzusetzen:
1. Constraint öffnen:
Falls Sie nicht ohnehin schon dort sind, navigieren Sie in der Konsole für Organizational Policies zu dem Constraint, das Sie eben erstellt haben.
2. Policy verwalten:
- Klicken Sie oben auf der Constraint-Seite auf MANAGE POLICY.

- Wählen Sie Override parent's policy, falls bereits eine Policy existiert.
- Setzen Sie die Enforcement-Regel auf On.
- Das Ergebnis sollte so aussehen:

Soll die PITR-Pflicht nur für einen Teil Ihrer Cloud SQL-Datenbanken gelten, können Sie über Conditions filtern, welche Ressourcen davon betroffen sind.
- Klicken Sie auf ADD CONDITION.
- Geben Sie Ihre Filterkriterien ein, etwa den Tag, und wählen Sie den passenden Value path:

Damit wir nicht versehentlich bestehende Ressourcen lahmlegen (siehe der Hinweis weiter oben: Bestehende CloudSQL-Datenbanken lassen sich ohne PITR nicht mehr ändern), empfiehlt es sich, die Policy vorher zu testen:
- Klicken Sie auf Test Policy und warten Sie, bis die Validierung abgeschlossen ist.
- Wechseln Sie auf die Seite SIMULATION HISTORY und prüfen Sie, ob das Ergebnis Ihren Erwartungen entspricht.

- Wenn alles passt, kehren Sie zum Custom Constraint zurück und wählen MANAGE POLICY.
- Falls die Änderungen noch nicht übernommen wurden, konfigurieren Sie die Policy wie zuvor (siehe oben). Klicken Sie auf SET POLICY und bestätigen Sie etwaige Warnhinweise.
Schritt 3: Wirksamkeit der Policy prüfen
Es ist wichtig, zu testen und nachzuweisen, dass die Policy wie vorgesehen greift. Mit den folgenden Schritten stellen Sie das sicher:
- Policy testen:
Der Versuch, eine Cloud SQL-Instanz ohne aktiviertes Point-in-Time Recovery zu erstellen oder zu aktualisieren, sollte von der Organizational Policy abgelehnt werden.
- Führen Sie folgenden Befehl aus:
gcloud sql instances create test-instance --region=us-central1 --no-backup
- Sie sollten eine Fehlermeldung erhalten, die darauf hinweist, dass Point-in-Time Recovery aktiviert sein muss.
2. Konforme Cloud SQL-Instanz erstellen:
Erstellen Sie nun eine Cloud SQL-Instanz mit aktiviertem Point-in-Time Recovery, sodass sie der Policy entspricht.
- Führen Sie folgenden Befehl aus:
gcloud sql instances create compliant-instance — region=us-central1 — backup-start-time=23:00 — enable-point-in-time-recovery
Dieser Befehl sollte zugelassen werden.
Mit diesen Schritten haben Sie ein Custom Constraint in den Policies Ihrer Organisation angelegt und durchgesetzt, das sicherstellt, dass alle Cloud SQL-Instanzen über Point-in-Time-Recovery-Backups verfügen. Das entspricht nicht nur den Best Practices für den Schutz Ihrer Daten, sondern sorgt organisationsweit für Compliance Ihrer Cloud-Ressourcen. Und es erspart Ihnen jede Menge Kopfzerbrechen, wenn mal wieder jemand kritische Daten löscht.
Keine Panik!
Wenn Sie Daten verloren haben, sind Sie damit nicht allein. DoiT International unterstützt Sie sowohl bei der Wiederherstellung als auch beim verbindlichen Erzwingen Ihrer Cloud SQL-Backups, damit Ihnen so etwas nicht noch einmal passiert. Mit über 180 Senior Cloud Experts, spezialisiert auf maßgeschneiderte Cloud-Lösungen, begleitet Sie unser Team reibungslos durch den Prozess und optimiert Ihre Infrastruktur so, dass sie compliant bleibt und auch künftigen Anforderungen effizient gewachsen ist.
Sprechen Sie uns an – wir sorgen dafür, dass Ihre Cloud SQL-Backup-Policies professionell und nahtlos verwaltet werden. Wir helfen Ihnen dabei, fundierte Entscheidungen zu treffen und die für Sie passenden Lösungen umzusetzen. Über Cloud SQL hinaus prüfen wir bei Bedarf all Ihre Policies in AWS, GCP und Azure, um umfassende Compliance und Sicherheit zu gewährleisten.
Unsere Experten unterstützen Sie in jedem Schritt mit strategischer Beratung und technischem Know-how. Lassen Sie uns gemeinsam besprechen, was in dieser Phase der Policy-Durchsetzung für Ihr Unternehmen am sinnvollsten ist – damit Ihre Cloud-Infrastruktur robust, compliant und auf Erfolg ausgerichtet ist.