Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
de:services:storage_services:backup:tsm:anleitungen:tls [2018/12/10 11:45] – [Beispiele] bnachtwde:services:storage_services:backup:tsm:anleitungen:tls [2022/05/27 09:39] (aktuell) – [Client-Side-Verschlüsselung einrichten] bnachtw
Zeile 1: Zeile 1:
 +====== Verschlüsselung und TSM======
 +<WRAP center round tip 90%>
 +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.
 +</WRAP>
 +<WRAP center round important 90%>
 +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 //T//rust_//O//n_//F//irst_//U//se, 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]]
 +</WRAP>
 +===== 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:
 +<WRAP center round info 90%>
 +Beispiel für Linux in der ''dsm.sys''
 +<code>
 +* irgendwelche sonstige Optionen
 +VIRTUALMOUNTPOINT /etc
 +INCLUDE.ENCRYPT /*
 +INCLUDE.ENCRYPT /etc/*
 +INCLUDE.ENCRYPT /home/*
 +* irgendwelche weiteren Optionen
 +</code>
 +</WRAP>
 +<WRAP center round info 90%>
 +Beispiel für Windows in der ''dsm.opt''
 +<code>
 +* irgendwelche sonstige Optionen
 +INCLUDE.ENCRYPT C:\*
 +INCLUDE.ENCRYPT D:\*
 +INCLUDE.ENCRYPT \\192.168.0.1\irgend-ein-netzlaufwerk-das-gesichert-wird\*
 +* irgendwelche weiteren Optionen
 +</code>
 +</WRAP>
 +
 +
 +
 +
 +