HSM-Backup-Tresor verstärkt die End-to-End-Verschlüsselung für Backups. Die Architektur schließt den Zugriff der Plattform auf die Schlüssel aus und führt überprüfbares Vertrauen ein.
Das Problem tritt auf, wenn Backups das Gerät verlassen und in die Cloud gelangen. Selbst bei End-to-End-Verschlüsselung bleibt die Frage: Wer kontrolliert die Wiederherstellungsschlüssel und wie kann bewiesen werden, dass der Anbieter keinen Zugriff darauf hat? In Systemen mit hoher Last (Highload) und verteilter Infrastruktur wird dies verstärkt: Die Schlüssel müssen widerstandsfähig gespeichert werden, jedoch ohne ein Vertrauenszentrum. Wenn der Schlüssel dem Betreiber oder der Cloud zugänglich ist, wird das Sicherheitsmodell untergraben.
Die Lösung besteht darin, die Speicherung des Wiederherstellungscodes in Hardware-Sicherheitsmodule (HSM) auszulagern und diese von der Plattform zu isolieren. Im HSM-basierten Backup-Schlüssel-Tresor werden die Schlüssel in einer manipulationssicheren Umgebung gespeichert und sind weder für den Dienst noch für den Cloud-Anbieter zugänglich. Die Architektur wird als geo-verteilte Flotte von HSM mit Replikation nach Mehrheitskonsens (majority-consensus replication) bereitgestellt. Dies ist ein Kompromiss: erhöhte Komplexität des Managements und Latenz (latency) gegen Widerstandsfähigkeit und Fehlertoleranz. Zusätzlich wird ein strenges Authentifizierungsmodell der Flotte über öffentliche Schlüssel vor der Sitzungseinrichtung eingeführt.
Ein kritischer Teil ist die Lieferung und Validierung der öffentlichen Schlüssel der Flotte. In einem Client sind die Schlüssel in die Anwendung integriert, was die vertrauenswürdige Initialisierung vereinfacht, jedoch Aktualisierungen bei Änderungen der Flotte erfordert. Für Szenarien, in denen Aktualisierungen unerwünscht sind, wurde eine Over-the-Air-Verteilung der Schlüssel implementiert. Die öffentlichen Schlüssel kommen als Validierungsbundle, das von einer Seite signiert und von der anderen gegengezeichnet wird. Dies bietet einen unabhängigen kryptografischen Nachweis (cryptographic proof) ihrer Authentizität. Zusätzlich wird ein Audit-Log jedes Schlüsselsatzes geführt, was eine Überprüfung der Änderungsverläufe ermöglicht. Der Client validiert die Schlüssel vor der Sitzungseinrichtung und beseitigt somit das Risiko einer Manipulation auf Netzwerkebene.
Eine separate Schicht ist die Transparenz der Bereitstellung. Die Veröffentlichung von Beweisen (evidence) für jede neue HSM-Flotte ermöglicht eine externe Überprüfung, dass das System korrekt bereitgestellt wurde und dem angegebenen Bedrohungsmodell entspricht. Bereitstellungen erfolgen selten, was den operativen Lärm reduziert, jedoch strenge Prüfverfahren erfordert. Der Benutzer oder Ingenieur kann die Schritte des Audits aus der Spezifikation nachverfolgen und sicherstellen, dass die aktuelle Flotte gültig ist. Dies verschiebt das Vertrauen von „wir vertrauen dem Anbieter“ zu „wir überprüfen die Kryptografie und die Protokolle“.
Das Ergebnis ist ein strengeres Modell der End-to-End-Verschlüsselung für Backups ohne Vertrauen in die Plattform. Das System kombiniert HSM-Isolation, Mehrheitskonsens-Replikation und eine überprüfbare Vertrauenskette für Schlüssel. Quantitative Metriken werden nicht offengelegt, aber das Risiko einer Kompromittierung durch den Betreiber oder die Cloud wird qualitativ gesenkt. Der Preis ist eine Komplexität der Client-Logik, die Notwendigkeit der Unterstützung des Validierungsprotokolls und das Management der HSM-Flotte. Dies ist eine pragmatische Wahl für Systeme, in denen der Schutz der Benutzerdaten wichtiger ist als die operationale Einfachheit.