Rollen, Zugriff und Schutz
Ein sicheres und robustes Backup-Konzept erfordert klare Verantwortlichkeiten, sauber getrennte Zugriffsrechte sowie definierte Abläufe für Backup-, Restore- und Monitoring-Prozesse. Dieses Kapitel beschreibt die vier zentralen Rollen im Betrieb sowie die Prinzipien für Zugriffskontrolle, Schutzmaßnahmen und Benachrichtigungen.
Rollen und Verantwortlichkeiten
Das Backupkonzept definiert sieben spezialisierte Rollen mit klar abgegrenzten Verantwortlichkeiten. Die ersten vier Rollen decken den operativen Backup- und Restore-Betrieb ab, die weiteren drei Rollen unterstützen ein DSGVO-konformes Löschkonzept.
Operative Rollen
| Rolle | Ziel | Typische Zuordnung |
|---|---|---|
| Cluster-Initialisierer | Neuen Cluster initial ausrollen, Restore-Pipeline auf Anforderung starten – ohne operative Verantwortung für Backup/Restore | DevOps / Platform-Team |
| Restore-Admin | Restore-Prozesse steuern, überwachen und fachlich mit dem Kunden koordinieren | Operations-Team |
| Backup-Admin | Sicherstellen, dass Backups regelmäßig, vollständig und wiederherstellbar sind – ohne direkten Zugriff auf produktive Live-Daten | Operations-Team |
| Kundenansprechpartner | Fachliche und funktionale Validierung, dass der Restore aus Geschäfts-/Anwendungssicht erfolgreich ist | Kunde |
DSGVO-Löschrollen
| Rolle | Ziel | Typische Zuordnung |
|---|---|---|
| Löschverantwortlicher | Durchführung manueller und vollständiger Löschungen (Bucket-Wipe, Prune-All), Löschung bei Vertragsende | Operations-Team |
| Prüfinstanz | Kontrolle der Retention-Policy-Einhaltung, Validierung von Löschberichten und S3-Delete-Events | Quality / Compliance |
| Datenschutzbeauftragter | Jährliche Prüfung der DSGVO-Konformität, Bewertung des Löschkonzepts, Einbindung bei Offboarding | DSB / Legal |
Aufgaben und Zugriffsrechte je Rolle
Cluster-Initialisierer
Aufgaben:
- Befüllt initiale Pipeline-Parameter (z.B.
cluster_name) - Startet die Initial-Deployment-Pipeline (Basis-Infrastruktur, Applikation, K8up-Komponenten)
- Im Restore-Fall: Startet auf Anforderung des Restore-Admin die Restore-Pipeline mit den gelieferten Parametern
Zugriffsrechte:
| Bereich | Berechtigung |
|---|---|
| CI/CD | Ausführen: Initial-Deployment-Pipeline, Restore-Pipeline |
| CI/CD | Kein Schreibzugriff auf Pipeline-Definitionen, Skripte oder Secrets |
| Kubernetes | Optional: Minimalrechte für Verifikation (get namespaces, get deployments) |
Restore-Admin
Aufgaben:
- Absprache mit Kundenansprechpartner vor und nach dem Restore
- Finalen Parameter-Stand an Cluster-Initialisierer übermitteln
- Monitoring der Alerts während des Restores
- Bestätigung vom Kundenansprechpartner nach Abschluss einholen
- Eskalation bei Problemen (zweiter Restore-Versuch, Rollback)
Zugriffsrechte:
| Bereich | Berechtigung |
|---|---|
| Kubernetes | Read-Only: Pods, Jobs, Events in relevanten Namespaces |
| Monitoring | Voller Lesezugriff auf Restore-Dashboards und Alerts (K8up jobType="restore", Pipeline-Status) |
Backup-Admin
Aufgaben:
- Überwacht regelmäßige K8up-Jobs (backup, check, prune) und deren Status
- Analysiert Backup-Warnungen und -Fehler, eskaliert an zuständige Stellen
- Verantwortlich für den Backup-Prozess und dessen Qualität
- Prüft S3-Backups auf Vollständigkeit und Struktur (erwartete Prefixes, Anzahl Snapshots)
- Dokumentiert Löschvorgänge und Reports
Zugriffsrechte:
| Bereich | Berechtigung |
|---|---|
| S3-Bucket | Read-Only: List + Get auf begrenzte Backup-Pfade |
| Monitoring | Zugriff auf Alarme für backup-, prune- und check-Jobs |
| Kubernetes | Read-Only: K8up-CRDs und K8up-Operator-Status |
Kundenansprechpartner
Aufgaben:
- Vor dem Restore: Bestätigt, dass ein Restore gewünscht und fachlich vertretbar ist
- Nach dem Restore: Testet Kernfunktionen der Anwendung (UIs, Workflows)
- Prüft Plausibilität und Konsistenz relevanter Daten
Zugriffsrechte:
| Bereich | Berechtigung |
|---|---|
| Applikation | Zugriff ausschließlich auf Kundenapplikation (Frontend, definierte API-Endpoints) |
Löschverantwortlicher
Aufgaben:
- Führt manuelle und vollständige Löschungen durch (Bucket-Wipe, Prune-All)
- Verantwortlich für Löschung bei Vertragsende
- Arbeitet nach Vier-Augen-Prinzip mit Prüfinstanz zusammen
Prüfinstanz
Aufgaben:
- Kontrolliert periodisch die Einhaltung der Retention-Policy
- Validiert Löschberichte und S3-Delete-Events
- Bestätigt die Wirksamkeit der Löschprozesse
Datenschutzbeauftragter
Aufgaben:
- Prüft jährlich die Wirksamkeit und DSGVO-Konformität
- Bewertet das Löschkonzept
- Ist in Offboarding-Löschungen eingebunden
RACI-Matrix
Die RACI-Matrix definiert die Verantwortlichkeiten für alle backup-relevanten Aktivitäten:
- R = Responsible (führt aus)
- A = Accountable (verantwortlich, genehmigt)
- C = Consulted (wird konsultiert)
- I = Informed (wird informiert)
Backup-Operationen
| Aktivität | Cluster-Init. | Restore-Admin | Backup-Admin | Kunde | Löschverantw. | Prüfinstanz | DSB |
|---|---|---|---|---|---|---|---|
| Backup-Schedule konfigurieren | - | I | R/A | - | - | I | - |
| Backup-Monitoring | - | I | R/A | - | - | I | - |
| Tägliche Backup-Validierung | - | - | R/A | - | - | I | - |
| Backup-Fehler analysieren | - | I | R/A | - | - | C | - |
| S3-Backup-Struktur prüfen | - | - | R/A | - | - | C | - |
| Retention-Policy anpassen | - | I | R | - | C | C | A |
| Prune-Jobs überwachen | - | - | R/A | - | I | I | - |
Restore-Operationen
| Aktivität | Cluster-Init. | Restore-Admin | Backup-Admin | Kunde | Löschverantw. | Prüfinstanz | DSB |
|---|---|---|---|---|---|---|---|
| Restore-Anforderung genehmigen | - | C | - | R/A | - | - | - |
| Restore-Parameter definieren | - | R/A | C | C | - | - | - |
| Restore-Pipeline starten | R | A | - | I | - | - | - |
| Restore-Monitoring | - | R/A | C | I | - | - | - |
| Funktionale Validierung | - | I | - | R/A | - | - | - |
| Restore-Eskalation | C | R/A | C | I | - | - | - |
| Restore-Abschluss bestätigen | - | R | - | A | - | I | - |
Cluster-Initialisierung & Disaster Recovery
| Aktivität | Cluster-Init. | Restore-Admin | Backup-Admin | Kunde | Löschverantw. | Prüfinstanz | DSB |
|---|---|---|---|---|---|---|---|
| Initial-Deployment-Pipeline starten | R/A | - | I | I | - | - | - |
| Cluster-Parameter befüllen | R/A | - | - | C | - | - | - |
| Cluster-Verifikation | R | - | - | - | - | - | - |
| DR-Plan aktivieren | R | A | C | I | - | - | - |
| DR-Restore durchführen | R | A | C | I | - | - | - |
Löschoperationen (DSGVO)
| Aktivität | Cluster-Init. | Restore-Admin | Backup-Admin | Kunde | Löschverantw. | Prüfinstanz | DSB |
|---|---|---|---|---|---|---|---|
| Manuelle Löschung durchführen | - | - | I | - | R | A | I |
| Bucket-Wipe bei Vertragsende | - | - | I | I | R | A | C |
| Retention-Einhaltung kontrollieren | - | - | C | - | I | R/A | I |
| Löschberichte validieren | - | - | C | - | I | R/A | I |
| S3-Delete-Events prüfen | - | - | C | - | I | R/A | - |
| Jährliche DSGVO-Prüfung | - | - | C | - | C | C | R/A |
| Löschkonzept bewerten | - | - | C | - | C | C | R/A |
| Offboarding-Löschung freigeben | - | - | I | A | R | C | A |
Dokumentation & Compliance
| Aktivität | Cluster-Init. | Restore-Admin | Backup-Admin | Kunde | Löschverantw. | Prüfinstanz | DSB |
|---|---|---|---|---|---|---|---|
| Backup-Konzept pflegen | C | C | R/A | - | C | C | A |
| Restore-Runbooks aktualisieren | C | R/A | C | - | - | I | - |
| Löschvorgänge dokumentieren | - | - | R | - | R | A | I |
| Audit-Logs bereitstellen | - | - | R/A | - | C | C | I |
| Quartals-Review durchführen | I | I | R | - | C | R | A |
Segregation of Duties (SoD)
Die Funktionstrennung stellt sicher, dass kritische Operationen nicht von einer einzelnen Person durchgeführt werden können. Dies unterstützt das Vier-Augen-Prinzip und schützt die Integrität der Backups.
SoD-Matrix: Konfliktpaare
| Rolle A | Rolle B | Konflikt | Begründung |
|---|---|---|---|
| Cluster-Initialisierer | Backup-Admin | ✗ Unvereinbar | Trennung zwischen Ausführung und Überwachung |
| Cluster-Initialisierer | Löschverantwortlicher | ✗ Unvereinbar | Wer provisioniert, darf nicht löschen |
| Restore-Admin | Backup-Admin | ⚠ Bedingt | Erlaubt mit zusätzlicher Kontrolle |
| Restore-Admin | Löschverantwortlicher | ✗ Unvereinbar | Wer wiederherstellt, darf nicht löschen |
| Backup-Admin | Löschverantwortlicher | ✗ Unvereinbar | Wer überwacht, darf nicht löschen |
| Löschverantwortlicher | Prüfinstanz | ✗ Unvereinbar | Vier-Augen-Prinzip bei Löschungen |
| Prüfinstanz | DSB | ✓ Vereinbar | Ergänzende Kontrollfunktionen |
Pflicht-Kontrollen nach Rolle
| Rolle | Darf | Darf nicht |
|---|---|---|
| Cluster-Initialisierer | Pipelines ausführen, Cluster verifizieren | Pipeline-Definitionen ändern, Secrets ändern, Backups löschen, Restore-Parameter definieren |
| Restore-Admin | Restore koordinieren, Parameter definieren, Monitoring | Pipelines direkt ausführen, Backup-Konfiguration ändern, Daten löschen |
| Backup-Admin | Jobs überwachen, S3 prüfen, Fehler analysieren, dokumentieren | Restores durchführen, Cluster provisionieren, Daten löschen |
| Kundenansprechpartner | Restore genehmigen, funktional validieren | Technische Operationen, Zugriff auf Infrastruktur |
| Löschverantwortlicher | Genehmigte Löschungen durchführen | Selbst genehmigen, Backups wiederherstellen, überwachen |
| Prüfinstanz | Löschungen validieren, Compliance prüfen | Löschungen durchführen, operative Backup-Aufgaben |
| DSB | DSGVO-Konformität prüfen, Konzepte bewerten | Operative Tätigkeiten, technische Zugriffe |
Kritische Prozesse mit Vier-Augen-Prinzip
| Prozess | Ausführende Rolle | Kontrollierende Rolle |
|---|---|---|
| Manuelle Löschung (Bucket-Wipe) | Löschverantwortlicher | Prüfinstanz |
| Löschung bei Vertragsende | Löschverantwortlicher | Prüfinstanz + DSB |
| Restore-Durchführung | Cluster-Initialisierer | Restore-Admin |
| Retention-Policy-Änderung | Backup-Admin | DSB |
| DR-Aktivierung | Cluster-Initialisierer | Restore-Admin |
Technische Durchsetzung
| Maßnahme | Implementierung |
|---|---|
| CI/CD-Berechtigungen | Cluster-Initialisierer: nur Execute-Rechte auf definierte Pipelines |
| Kubernetes RBAC | Restore-Admin: Read-Only auf Pods/Jobs/Events; Backup-Admin: Read-Only auf K8up-CRDs |
| S3-IAM-Policies | Backup-Admin: nur List/Get; Löschverantwortlicher: Delete nur mit MFA |
| GitOps-Workflow | Keine direkten Änderungen an Pipeline-Definitionen, nur via Pull-Request |
| Audit-Logging | Alle Aktionen werden protokolliert und sind durch Prüfinstanz einsehbar |
| MFA | Pflicht für Löschverantwortlicher bei Delete-Operationen |
Zugriff auf Backup-Daten
Die im Rahmen des Backup-Prozesses erzeugten Artefakte enthalten produktive Kundendaten und unterliegen daher besonders hohen Sicherheitsanforderungen. Der Zugriff auf diese Daten ist strikt geregelt und folgt dem Prinzip der minimalen Rechte (Least Privilege).
Zugriffsmodell
Im operativen Betrieb erhält nur der Backup-Admin direkten Zugriff – und das ausschließlich in Read-only-Form. Alle übrigen Rollen interagieren mit Backup-Daten ausschließlich über kontrollierte technische Pfade (Build-Pipeline, Restore-Pipeline, k8up).
Zugriffsbeschränkung Offsite-Backup: Der Zugriff auf die Offsite-Repliken (Disaster Recovery Copy) ist streng limitiert. Lediglich das Backup-Team und die Teamleitung (TL) besitzen die notwendigen Berechtigungen, um auf diese Daten zuzugreifen. Dies dient als Schutz vor Insider-Threats und verhindert unautorisierte Manipulationen an der "Letzten Verteidigungslinie".
Technische Schutzmechanismen
- Clientseitige Verschlüsselung
-
Backups werden vor dem Transfer in den Object Storage durch Restic vollständig clientseitig verschlüsselt.
-
Die Verschlüsselung erfolgt über das
repoPasswordSecretRef.
-
Zugriffsschutz durch S3-Bucket Policies
Der Zugriff auf Backup-Daten wird zusätzlich durch dedizierte Bucket Policies sichergestellt:
- Erlaubt sind nur ListBucket und GetObject für den Backup-Admin.
- Löschen oder Manipulieren von Objekten ist für menschliche Rollen vollständig ausgeschlossen.
-
Rollenbasierter Zugriff (IAM)
Im STACKIT IAM erhält der Backup-Admin ausschließlich die Rolle "s3-bucket.reader" auf dem Backup-Projekt.
Schutz vor unautorisierten Restores
Restore-Prozesse greifen produktive Daten an und können den aktuellen Zustand einer Applikation überschreiben. Daher ist der Schutz vor unautorisierten oder versehentlich ausgelösten Restores ein zentraler Bestandteil des Backup-Konzepts.
Restore nur über definierte Kontrollpfade
Ein Restore kann ausschließlich über die Build-Pipeline ausgelöst werden. Der Restore wird über einen expliziten Pipeline-Parameter aktiviert:
RESTORE_FROM_BACKUP = "true"
Ohne diese manuelle Aktivierung führt dieselbe Pipeline einen normalen Applikations-Deploymentprozess durch.
Trennung von Frontend-Operationen und Backend-/Archivzugriffen
Frontend-Ebene (operative Steuerungsebene)
Rollen wie Cluster-Initialisierer, Restore-Admin und Kundenansprechpartner interagieren ausschließlich über definierte technische Kontrollpfade:
Diese Rollen besitzen keinerlei direkten Zugriff auf die gespeicherten Backup-Daten.
Sie können Backups auslösen, überwachen oder Restores initiieren, aber nicht auf den zugrunde liegenden Speicher zugreifen oder Backup-Artefakte ansehen, verändern oder löschen.
Backend-Ebene (Speicher- und Kontrollebene)
Der direkte Zugriff auf die physisch gespeicherten Backup-Daten ist streng limitiert und ausschließlich folgenden Rollen vorbehalten:
- Backup-Admin (Read-only auf Hot Storage)
- Löschverantwortlicher (Delete-Operationen nur mit MFA)
- Teamleitung / Prüfinstanz (Kontrolle, Audit, Validierung)
Diese Rollen arbeiten auf der Datenhaltungsebene und besitzen keinen Einfluss auf die Steuerungs- oder Deployment-Pipelines. Damit wird verhindert, dass operativ agierende Rollen Veränderungen an der „letzten Verteidigungslinie“ vornehmen können.
Archiv- und Cold-Storage-Trennung
Langzeitarchive (Cold Storage) werden in einem separaten Speicherbereich mit eigenen IAM-Policies verwaltet.
Zugriffe darauf sind ausschließlich dem Backup-Team vorbehalten und werden organisatorisch vom operativen Betrieb getrennt.
Damit wird ein Cloud-basiertes Äquivalent zum traditionellen Offsite-Tape-Modell geschaffen:
Der operative Betrieb verwaltet Workloads und Prozesse, hat jedoch keinen Zugriff auf die ausgelagerten Archivkopien.
Sicherheits- und Compliance-Ziele
Diese Trennung stellt sicher, dass:
- operative Rollen keine Möglichkeit haben, gespeicherte Backups zu manipulieren,
- Archivkopien vor Insider-Threats geschützt sind,
- Restore- und Deploymentpfade sauber von Speicherzugriffen getrennt bleiben.