Verschlüsselung und TSM

Mit der Umsetzung des Prinzips „Privacy-by-default“ in TSM/SP, hat IBM in den Versionen ab 7.1.8 bzw. 8.1.2 die Nutzung von SSL/TLS zwingend eingeführt:

  • die Kontroll-Sessions (z.B. Knotennamen + Password, Dateilisten) werden TLS-verschlüsselt (siehe auch die WICHTIG-Box)
  • die Übertragung der eigentlichen Backupdaten erfolgt weiterhin unverschlüsselt.

Letztendlich werden damit die Vorteile aus Transport- und Client-Verschlüsselung kombiniert und wir bleiben daher bei der bisherigen Empfehlung, die Datenverschlüsselung anstelle der SSL/TLS-Transportverschlüsselung für die Massendaten zu nutzen und sehen folgenden Vorteile

  • Die Daten sind auf dem gesamten Weg vom Client bis zum Band verschlüsselt
  • seitens der GWDG besteht keine Möglichkeit, Einblick in die Daten nehmen zu können.
  • Es gibt keine zusätzliche Rechenlast auf dem TSM-Server.

Allerdings gibt es auch ein paar Nachteile:

  • Der Schlüssel liegt beim Nutzer, geht dieser verloren, kann seitens der GWDG keine Hilfestellung gegeben werden.
  • Die Kompression der verschlüsselten Daten durch die Bandlaufwerke ist um ca. 10% weniger effektiv, es werden etwas mehr Bänder benötigt.
  • DeDuplikation ist für verschlüsselte Daten kaum effektiv nutzbar – diese Technik kommt aber bei der GWDG (bisher) nicht zum Einsatz.

Umgekehrt verhielte es sich bei der ausschließlichen Nutzung von SSL/TLS als Transportverschlüsselung.

Vorteile:

  • Unverschlüsselte Daten können auch seitens der GWDG auf expliziten Auftrag des Nutzers restored werden.
  • Kompression und DeDuplikation arbeiten besser.

Nachteile:

  • Die Daten liegen unverschlüsselt und damit nur durch die üblichen IT-Sicherheitsmaßnahmen der GWDG geschützt auf den SP-Servern.
  • Teilweise erhebliche Rechenlast für die Ver- bzw. Entschlüsselung der Daten.

Leider gab es mit den TSM-Servern bis Version 8.1.4 Probleme mit dem Einspielen der Zertiftkate. Daher gibt es seit Version 8.1.5 TOFU, also Trust_On_First_Use, d.h. SP-Clients in den Versionen 8.1.5 und neuer akzeptieren bei der ersten Verbindung die Serverzertifikate und installieren sie selbstständig – ohne Eingriff des Nutzers.

Die ganze Wahrheit ist aber, dass es zum einen trotzdem nicht immer funktioniert und es zum zweiten auch Konstellationen mit mehreren Knoten/Clients auf einem Rechner gibt oder diese sich mit mehreren TSM-Servern verbinden. TOFU greift dann leider nur bei der ersten Client-Server-Beziehung.

Wir haben daher die Zertifikate aller GWDG-TSM-Server in unserem GitLab veröffentlicht. Außerdem liegen dort Anleitungen zum Prüfen der bereits installierten Zertifikate und zum manuellen Installieren und Löschen von TSM-Zertifikaten.

https://gitlab-ce.gwdg.de/tsmadm/cert256

Transportverschlüsselung einrichten

Wie zuvor geschrieben, sollten Clients ab Version 8.1.5 die für die Verschlüsselung notwendigen Zertifikate selbstständig einrichten. Sollte dies nicht der Fall sein, müssen Sie manuell installiert werden. Die Anleitungen für Linux und Windows befinden sich im GWDG-GitLab bei den Zertifikaten: https://gitlab-ce.gwdg.de/tsmadm/cert256

Client-Side-Verschlüsselung einrichten

Die Verschlüsselung im Client wird über entsprechende Einträge in der dsm.sys (Linux, MacOS, sonstige Unices und BSDen) bzw. dsm.opt (Windows) eingerichtet:

  • ENCRYPTIONType <AES128|AES256> Voreingestellt ist AES128, wir empfehlen aber die sicherere AES256-Verschlüsselung zu wählen.
  • ENCRYPTKey <save|prompt|generate> Voreingestellt ist save, d.h. der Schlüssel wird auf dem Client gespeichert. Von prompt raten wir ausdrücklich ab, da jedes Mal nach dem Passwort gefragt wird – auch beim automatischen Backup. generate speichert den Schlüssel im TSM-Server und hebelt so das Ziel, die Daten der GWDG nur verschlüsselt zu überlassen aus.
  • INCLUDE.ENCRYPT <Muster> TSM verschlüsselt auch beim Setzen der zuvor genannten Optionen keine Daten, diese müssen explizit ausgewählt werden, dabei bitte Bedenken, dass jede Partition / jedes Fileshare separat behandelt wird, auch wenn mit VIRTUALMOUNTPOINTS gearbeitet wird:

Beispiel für Linux in der dsm.sys

* irgendwelche sonstige Optionen
VIRTUALMOUNTPOINT /etc
INCLUDE.ENCRYPT /*
INCLUDE.ENCRYPT /etc/*
INCLUDE.ENCRYPT /home/*
* irgendwelche weiteren Optionen

Beispiel für Windows in der dsm.opt

* irgendwelche sonstige Optionen
INCLUDE.ENCRYPT C:\*
INCLUDE.ENCRYPT D:\*
INCLUDE.ENCRYPT \\192.168.0.1\irgend-ein-netzlaufwerk-das-gesichert-wird\*
* irgendwelche weiteren Optionen
Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information