Versiegeln ja, öffnen nein
Die Plattform kennt nur den öffentlichen Schlüsselteil. Der private entsteht einmalig und wird serverseitig sofort überschrieben. Wer die Plattform übernimmt, gewinnt damit kein einziges Notfallpaket.
Der Plan, den Sie ohne Netz, ohne Server und ohne uns erreichen
Notfallpläne haben eine unangenehme Eigenschaft: Sie liegen meist genau in dem System, das im Ernstfall nicht mehr erreichbar ist. Das Notfallsystem ist für den Fall gebaut, in dem Plattform und Rechenzentrum verschlüsselt sind. Der Krisenstab kommt dann ohne Netz und ohne Server an Notfall- und Wiederanlaufpläne, an die BIA mit RTO und RPO, an Sicherungspläne samt Lagerort und Restore-Verfahren, an Asset-, Rack- und Netzinventar, an das Firewall-Regelwerk, an Erreichbarkeiten und an die freigegebenen Dokumente im Original. Das Bedrohungsmodell dahinter ist ungewöhnlich, aber konsequent: Im Ernstfall gilt die Plattform selbst als kompromittiert. Sie kann Pakete deshalb versiegeln und keines davon öffnen.
Die Plattform kennt nur den öffentlichen Schlüsselteil. Der private entsteht einmalig und wird serverseitig sofort überschrieben. Wer die Plattform übernimmt, gewinnt damit kein einziges Notfallpaket.
Im Paket steht kein Passwort, sondern der Verwahrort: welcher Umschlag, welcher Tresor, welche Person. Die organisatorische Frage bleibt organisatorisch gelöst.
Aus BIA-Zeitvorgaben, Abhängigkeiten und den Stromketten und Rackpositionen des DCIM entsteht ein Kaltstart-Plan für das Rechenzentrum, mit kritischem Pfad und kumulierter Wiederanlaufzeit.
Drei Prüfarten mit klarer Aussagekraft: Signatur prüfen, Paket testweise öffnen, Übung unter Zeitdruck. Nur der Öffnungstest findet den Fall, in dem die Datei tadellos ist und der Geräteschlüssel fehlt.
Notfallfähigkeit, die sich nachweisen lässt: nicht die Zusage, dass ein Paket existiert, sondern die gemessene Zeit, bis jemand es geöffnet hat.
Vereinbaren Sie eine unverbindliche Demo – wir zeigen Ihnen das Modul an Ihren eigenen Anwendungsfällen.