Jede Sicherungslösung verkündet Verschlüsselung. Das ist zu einem Kästchen zum Ankreuzen geworden, ähnlich wie „DSGVO-konform". Hinter demselben Wort stecken jedoch Modelle, die nicht vor denselben Bedrohungen schützen.
Die nützliche Frage ist nicht „ist es verschlüsselt?", sondern „wer besitzt den Schlüssel, und wo ist die Entschlüsselung möglich?"
Drei Modelle, drei Reichweiten
Verschlüsselung bei der Übertragung
Die Daten laufen über TLS zwischen dem gesicherten Rechner und dem Server. Das ist das absolute Minimum, und davon weicht niemand mehr ab.
Schützt vor: dem Mithören im Netz. Schützt nicht vor: allem, was geschieht, sobald die Daten angekommen sind.
Verschlüsselung im Ruhezustand, serverseitig
Die Daten sind auf der Platte des Sicherungsservers verschlüsselt. Den Schlüssel besitzt der Server, der beim Schreiben verschlüsselt und beim Lesen entschlüsselt.
Schützt vor: dem physischen Diebstahl einer Platte, der Aussonderung von Hardware, einem direkten Zugriff auf den Speicher. Schützt nicht vor: jedem, der Zugang zum Server erhält — denn der Server hat den Schlüssel. Das gilt für einen befugten Administrator genauso wie für einen Angreifer.
Das ist das verbreitetste Modell, und es wird oft einfach als „AES-256-Verschlüsselung" dargestellt, was zutrifft, aber unvollständig ist.
Verschlüsselung an der Quelle
Die Daten werden auf dem gesicherten Rechner verschlüsselt, bevor sie diesen verlassen, mit einem Schlüssel, der den Rechner nie verlässt. Der Server erhält und speichert nichts als unverständliche Blöcke.
Schützt vor: Plattendiebstahl, Übernahme des Servers, der Neugier eines Hosters, der eines Dienstleisters, der eines Softwareherstellers. Schützt nicht vor: der Übernahme des Rechners selbst, wo die Daten ohnehin im Klartext liegen.
Integritätsprüfung ohne den Schlüssel
Ein berechtigter technischer Einwand: Wenn der Server nicht entschlüsseln kann, wie prüft er dann, dass die Daten im Lauf der Zeit nicht verfallen?
Die Antwort liegt darin, wo die Prüfsummen berechnet werden. Trägt jeder Block seine eigenen Prüfsummen, vor und nach der Kompression, kann der Server einen Block zurücklesen, seine Prüfsumme neu berechnen, sie mit der gespeicherten vergleichen und daraus schließen, dass der Block unversehrt ist — ohne je zu wissen, was er enthält.
Das versöhnt zwei Anforderungen, die man oft für unvereinbar hält: die vollständige Vertraulichkeit gegenüber dem Hoster und die Integritätsprüfung auf Serverseite.
Was das bei einer Datenschutzverletzung ändert
Hier hat das Modell sehr konkrete Folgen, und nicht nur technische.
Die DSGVO verlangt, eine Verletzung binnen 72 Stunden der Aufsichtsbehörde zu melden (Artikel 33) und die betroffenen Personen zu benachrichtigen, wenn die Verletzung voraussichtlich ein hohes Risiko für ihre Rechte und Freiheiten mit sich bringt (Artikel 34).
Artikel 34 sieht ausdrücklich vor, dass diese Benachrichtigung der Personen nicht erforderlich ist, wenn der Verantwortliche Maßnahmen getroffen hat, die die Daten für jede unbefugte Person unverständlich machen — wobei die Verschlüsselung als Beispiel genannt wird.
Praktisch übersetzt: Wird ein Sicherungsserver übernommen und waren die Daten an der Quelle verschlüsselt, wobei der Schlüssel nie auf diesem Server lag oder dorthin übertragen wurde, ist das Risiko für die Personen erheblich geringer. Das wirkt sich unmittelbar auf die Pflicht aus, jede betroffene Person zu benachrichtigen — und auf die Art des Gesprächs, das Sie mit Ihrem Kunden führen werden.
Bei Verschlüsselung im Ruhezustand auf Serverseite hat der Angreifer, der den Server übernommen hat, auch den Schlüssel. Das Argument trägt dann nicht mehr.
Dies beschreibt einen Grundsatz, keine automatische Befreiung. Die Bewertung einer Verletzung bleibt eine Einzelfallprüfung, mit Ihrem Rechtsbeistand oder Ihrem Datenschutzbeauftragten.
Die Kehrseite, die man annehmen muss
Eine Verschlüsselung, deren Schlüssel beim Kunden bleibt, hat eine nicht verhandelbare Folge: Ist der Schlüssel verloren, sind die Daten es auch. Niemand kann ihn neu erzeugen. Nicht der Softwarehersteller, nicht der Hoster, nicht Sie.
Das ist kein Mangel: Es ist genau dieselbe Eigenschaft, von der anderen Seite gesehen. Eine Lösung, die Ihnen den Zugang zu Ihren Daten ohne Ihren Schlüssel zurückgeben kann, kann diese Daten konstruktionsbedingt auch ohne Sie lesen.
Die Verwahrung des Wiederherstellungsschlüssels ist daher als eigene Betriebsaufgabe zu behandeln:
- Nicht auf dem gesicherten Rechner aufbewahrt. Ein Schlüssel, der auf dem Server liegt, den er schützt, schützt nichts.
- In einem Passworttresor, mit nachvollziehbarem Zugang und mindestens zwei befugten Personen.
- Überprüft: Ein Schlüssel, der nie ausprobiert wurde, ist eine Annahme. Ein Wiederherstellungstest bestätigt ihn nebenbei.
- Dokumentiert im Wiederanlaufverfahren, nicht im Gedächtnis dessen, der es eingerichtet hat.
Für einen Dienstleister mit mehreren Dutzend Kunden lohnt es, das vor der ersten Inbetriebnahme zu ordnen, nicht nach der fünfzigsten.
Die Fragen an einen Hersteller
Vier genügen, um jede Lösung einzuordnen:
- Wo findet die Verschlüsselung statt? Auf dem gesicherten Rechner oder auf dem Server?
- Geht der Schlüssel durch das Netz? Wenn ja, hat er den Vertrauensbereich verlassen.
- Kann der Server die Integrität prüfen, ohne zu entschlüsseln? Die Antwort verrät den tatsächlichen Entwurf.
- Was passiert, wenn ich den Schlüssel verliere? Kann der Hersteller Ihnen aushelfen, dann kann er Ihre Daten lesen.
Die vierte ist die aufschlussreichste und die am seltensten gestellte.
Bei BeBackup findet die AES-256-Verschlüsselung auf dem Rechner statt, der Schlüssel geht nie durch das Netz, und der Server besitzt nur dessen Prüfsumme. Zur Sicherheitsseite oder eine Demo anfordern.