Backup-Verschlüsselung und Schlüsselverwaltung#

Backups enthalten sensible Daten (Konfigurationsdaten, Applikationszustände, Benutzerdaten) und müssen daher sowohl im Speicher (Data at Rest) als auch während der Übertragung (Data in Transit) geschützt werden.
Die Verschlüsselung und das Management der zugehörigen Schlüssel sind zentrale Sicherheitskomponenten des Backup-Designs. Die Umsetzung basiert vollständig auf dem STACKIT Secrets Manager, der als Vault-kompatibler, verwalteter Secret-Store eingesetzt wird.

Verschlüsselung im Ruhezustand und bei Übertragung#

Verschlüsselung im Ruhezustand (Data at Rest)#

Folgende Verschlüsselung kommt im Backup-Prozess zum Einsatz:

• Client-seitige Verschlüsselung durch Restic (k8up)

  • Im Kubernetes-Cluster werden alle Backups vor dem Upload vollständig clientseitig durch Restic verschlüsselt.

  • Grundlage ist das Restic-Repository-Passwort, das ausschließlich im STACKIT Secrets Manager gespeichert ist.

  • Dadurch sind Backups selbst dann geschützt, wenn der S3-Bucket kompromittiert würde.

Verschlüsselung bei Übertragung (Data in Transit)#

Die folgenden Übertragungswege sind durch Sicherheitsmechanismen geschützt:

• K8up -> STACKIT S3
  • Die Datenübertragung erfolgt ausschließlich über HTTPS mit TLS 1.2 oder höher.
  • Backups werden bereits clientseitig verschlüsselt, sodass während der Übertragung keine Klartext-Daten über die Netzwerkverbindung gesendet werden.
• CI/CD-Pipeline -> STACKIT Secrets Manager
  • Secrets werden über die Vault-API abgerufen. Die Kommunikation erfolgt vollständig TLS-gesichert.
• Pipeline -> Restic Restore -> S3
  • Auch für den Restore-Prozess werden ausschließlich TLS-geschützte Verbindungen genutzt, um die Integrität und Vertraulichkeit der Daten sicherzustellen.

Schlüsselmanagement#

Das Schlüsselmanagement verfolgt einen hybriden Ansatz, um maximale Sicherheit mit operativer Wiederherstellbarkeit zu kombinieren.

Primärer Speicherort (Operativer Betrieb): Jedes Kundenprojekt verfügt über eine dedizierte Instanz des STACKIT Secrets Managers. Der Zugriff auf diese Instanz erfolgt über projektspezifische Service-Credentials (kein zentrales OIDC), was eine strikte Isolation zwischen den Mandanten gewährleistet. Hier liegen die für den automatisierten Backup-Betrieb essentiellen Schlüssel:

• S3 Access Key & Secret Key (für den Zugriff auf den Backup-Storage)
• Restic Repository Passwort (zur Entschlüsselung der Backups)

Sekundärer Speicherort (Disaster Recovery & Externe Abhängigkeiten): Um im Falle eines Ausfalls des STACKIT Secrets Managers oder bei administrativen Notfällen handlungsfähig zu bleiben, werden kritische Schlüssel redundant gesichert. Diese liegen im internen Vaultwarden des Betriebsteams. Dazu gehören:

• Eine Kopie des Restic Repository Master-Passworts (Masterbackuppasswort).
• Route53 Credentials

Umgang mit Applikations-Secrets: Anwendungsspezifische Zugangsdaten (z. B. Datenbank-Passwörter, S3-Auth-Daten für Apps) werden nicht extern verwaltet, sondern sind Teil der Kubernetes-Secrets im Cluster. Da das Backup-Konzept den Export aller Kubernetes-Secrets umfasst, ist sichergestellt, dass diese Credentials im Restore-Fall automatisch wiederhergestellt werden. Sollten S3-Zugangsdaten für Anwendungen fehlen, können diese alternativ auf der Infrastruktur neu generiert werden.

Schlüsselrotation#

Die Rotation von secrets und kryptografischen Schlüsseln ist ein zentraler Bestandteil eines sicheren Backup- und Restore-Konzepts. Im vorliegenden Design — basierend auf Restic, k8up sowie dem STACKIT Secrets Manager — gelten folgende Best Practices:

1. Regelmäßige Rotation des Restic Repository Passwords

• Das Restic-Passwort ist der zentralste Schlüssel im gesamten Backup-System.
• Best Practices:
  • Rotation mindestens jährlich, besser alle 6–12 Monate
  • Rotation nach jedem sicherheitsrelevanten Vorfall (Credential Leak, verdächtige Aktivität, Personalwechsel)
  • Nach Rotation:
    • Neue Backups werden mit dem neuen Schlüssel erstellt
    • Alte Backups bleiben mit ihrem alten Schlüssel erhalten (Restic-Design)
    • Dokumentation, welcher Key für welchen Zeitraum gültig war

2. S3 Access Keys regelmäßig rotieren (IAM Credentials)

• S3 Keys sind operative Zugangsdaten, keine Kryptoschlüssel — sie müssen strenger rotiert werden.
• Best Practices:
  • Rotation alle 90 Tage