DSGVO, Freelancer, E-Mails und ein Umzug KVM-virtualisierter Linux-E-Mail-Server auf verschlüsselte Platten/Partitionen – I

Als Freelancer hat man seine liebe Not mit der deutschen Last-Minute-DSGVO-Panik. Das Problem ist nicht der Datenschutz an sich; da sind die allgemeinen Anstrengungen eher lobenswert. Das Problem sind vielmehr pauschale Verträge oder Vereinbarungen zur Auftragsverarbeitung, die viele Datenschutzbeauftragte (in ihrer Hilflosigkeit?) uns Freelancern aufdrängen möchten. Dabei spiegeln solche pauschalen Verträge nach meiner Auffassung gerade nicht den Geist der DSGVO wider:

Verkannt wird dabei, dass Datenschutz und Datensicherheit gemeinsame Festlegungen erfordert (s. etwa Art.32 DSGVO). Der Auftraggeber muss nämlich die technischen und organisatorischen Maßnahmen kennen und damit in gewisser Weise auch gutheißen, die Bestandteil eines Vertrages werden sollen. Viele Datenschützer übersehen auch, dass die zu erwartenden personenbezogenen Daten und deren Schutzniveau erstmal definiert werden müssen. Entsprechend inhaltsleer fällt denn auch die Antwort auf die Rückfrage aus, welche personenbezogenen Daten denn in der Zusammenarbeit auftauchen werden.

Man ist als Freelancer also gut beraten, die Schutzbedingungen selbst mit zu definieren - gerade im Geiste der DSGVO, Art. 32, Pkt.1. Das gilt dann u.a. auch für den Austausch von Mails zwischen Auftraggeber und Auftragnehmer.

E-Mail-Verkehr als DSGVO-Problemzone

Das Thema E-Mail ist im Kontext des Datenschutzes für Freelancer durchaus ein kritisches. E-Mails sind von Haus aus mit personenbezogenen Daten behaftet und können weitere schützenswerte Inhalte beinhalten. Hier muss man das zu erreichende Schutzniveau von beiden Seiten also sorgfältig definieren. Dabei muss man einen zwischengeschalteten Provider berücksichtigen - aber natürlich auch die hauseigene E-Mail-Installation. Letztere wird bei Linux-Lovern und -Profis durchaus komplex ausfallen, da der Linux-Anwender/Admin aus vielen vernünftigen Gründen heraus ggf. einen eigenen Mail-Server mit oder ohne Zusammenspiel mit einem Mail-Server bei einem Providern betreiben wird.

Ende-zu-Ende-Verschlüsselung?
Sinnvolle Schutzwege führen bei E-Mail aus meiner Sicht eigentlich immer über Ende-zu-Ende-Verschlüsselung. Kann man die DSGVO also als eine Gelegenheit begreifen, Verschlüsselungspflichten endlich auch für den Auftraggeber zu fixieren? Am besten auf der Basis von OpenPGP? Ich bezweifle aus Jahren eigener schlechter Erfahrung leider, dass alle eure Auftraggeber zu diesem Schritt der Vernunft bereit sein dürften.
Alternative? DE-Mail mit OpenPGP? Ehrlich gesagt: Ich weiß nicht, warum das technisch einfacher sein soll, als gleich selber die Schlüsselverwaltung zu übernehmen - und dabei ganz ohne Browser- oder Client-Plugins auszukommen. DE-Mail ist zudem kostenpflichtig - und man handelt sich ein paar unangenehme Verbindlichkeiten bzgl. der Nutzung ein.
Dennoch ist Mail-Verschlüsselung (ob mit oder ohne DE-Mail) der zu wählende Königsweg.

Nur Verschlüsselung des Übertragungsweges?
Leider fühlen sich viele AGer mit OpenPGP überfordert. Was dann? Nun, meistens haben die Auftraggeber selber E-Mail-Provider - und zumindest erfolgt der Zugang zu den E-Mail-Servern selbiger Provider verschlüsselt. Dito natürlich beim Freelancer. An dieser Stelle erscheint es geboten, als Freelancer einen Auftragsverarbeitungs-Vertrag mit dem Provider abzuschließen, den die meisten Hosting-Provider in Deutschland in pauschaler, aber ggf. hinreichender Weise anbieten.

Schutz unverschlüsselter Mails?
Leider ist man mit der Verschlüsselung des Übertragungsweges als Freelancer nicht aus dem Schneider.

Das erste Thema sind E-Mail-Clients (PCs, Notebooks, ..), die E-Mails in einer unverschlüsselten Umgebung puffern, öffnen oder gar mit Servern synchronisieren (unter Linux etwa über KDE's Akonadi oder z.B. über Evolutions und Thunderbirds eigene Tools). Auf den Clients bleibt dann halt viel auf deren meist unverschlüsselten Platten liegen.

Das zweite Thema, das vermutlich gerade Linux-Lover trifft, sind eigene E-Mail-Server im (Home-) Office-LAN. Jeder Freelancer oder auch der Admin eines KMU, der bei seiner Infrastruktur auf Linux setzt, wird aus einer Vielzahl von Gründen früher oder später einen eigenen Mail-Server aufgesetzt und den ggf. an einen Mail-Server bei einem Provider angeschlossen haben. Das gilt im Besonderen dann, wenn noch weitere Mitarbeiter oder Unterauftragnehmer im Spiel sind: Unter Upgrade-, Migrations- und Backup-Gesichtspunkten stellen eigene Mail-Server (trotz der Mühen beim Setup) für den Freelancer letztlich eine Arbeitserleichterung dar. Auf einem solchen Server lagert nun womöglich eine Masse an unverschlüsselten Mails auf unverschlüsselten Festplattenpartitionen. Steht etwa im eigenen (Home-)Office-LAN ein eigener Linux-Mail-Server, stellt sich die Frage wo und wie man die dort auflaufenden E-Mails bei Abwesenheiten/Urlaub von der Wohnung oder seines Office schützt.

Physikalischer Zugangsschutz? Nun, Freelancer werden kaum die Möglichkeit haben, ihre Wohnungen voll zu verriegeln, ohne sich Ärger mit Vermietern einzuhandeln. Wie sichert man sich dann gegen Diebstahl zu schützender Mails im Falle eines Einbruchs während eines Urlaubs ab? Tja - genau mit diesem Problem muss man sich nun ggf. wegen relativ strikter (pauschaler) Auftragsverarbeitungsvereinbarungen mal wieder auseinandersetzen. Das halte ich persönlich für durchaus sinnvoll ...

Gefordert ist natürlich erneut Verschlüsselung - diesmal aber von Platten oder Partitionen.

Verschlüsselung von Platten und Partitionen - auf Mail-Servern wie Mail-Clients?

Während Notebooks sowieso durchgehend kryptierte HHDs/SSDs erfordern, ist eine Vollverschlüsselung von Festplatten/ Partitionen bei Servern und umfänglichen Workstations ein viel komplexeres und problematischeres Thema, das auch mit Risiken verbunden ist. Ich nenne nur mal beschädigte Krypto-Header als eines der potentiellen Probleme.

Nehmen wir mal an, man traut sich zu, die Risiken, die mit Kryptographie verbunden sind, zu beherrschen. Wie kann dann für den Linux-Lover ein praktikables Modell für den Schutz unverschlüsselter Mails aussehen? Ich meine, dass drei strategische Elemente zum Ziel führen:

  1. Abseparation von bestimmten E-Mail-Accounts für Kunden
  2. Virtualisierung der E-Mail-Server - wie einer E-Mail-Client-Umgebung unter KVM/QEMU
  3. Verschlüsselung der (Raw-) Partitionen/Volumes, auf denen E-Mail-Server oder aber die Client-Umgebung operieren.

Auf mobilen Laptops/Notebooks ist eine Kryptierung der benutzten Partitionen sowieso Pflicht. Für SSDs ist dabei zu beachten, dass die Verschlüsselung schon im jungfräulichen Zustand erfolgen muss.

Nun wollen wir die Verschlüsselung aber auch auf Workstation-Clients und Server anwenden. Der E-Mail-Datenverkehr läuft dann meiner Ansicht etwa wie folgt aus:

Ein Router mit Perimeter-Firewall übernimmt die Kommunikation mit dem Internet. Er trennt ggf. ein Gastnetz [GNS} von einem Frontend-Segment [FNS]ab. Ein System mit einer Paket-Filter-Firewall und/oder WAF-Firewall trennt weitere nachgelagerte Segmente ab. Ein zweites System GWS2 realisiert einen E-Mail-Server in einer Art sekundärer DMZ. Dieser Server wird entweder direkt von normalen Clients in weiteren Zonen angesprochen (Lösung für "Arme") oder synchronisiert Mails ggf. mit einem weiteren Groupware-Server in internen Segmenten (Lösung für "Reiche").

Kennt man sich gut mit Paketfiltern im Kontext virtualisierter Netze gut aus, kann das angedeutete System "GWS1" ggf. entfallen. Auch der Groupware-Server ist für einen reinen Mail-Betrieb nicht erforderlich.

Die Verschlüsselung der Volumes, die von den unter KVM/QEMU virtualisierten Servern/Clients genutzt werden, kann dabei auf dem Host bereits auf der Ebene einer Linux-"Raw"-Partition oder eines "Raw"-LVM-Volumes genutzt werden. Ich halte in einem solchen Szenario allein aus Performance-Gründen Einiges davon, die Verschlüsselung dem Virtualisierungshost zu überlassen. Sollte jemand dagegen gute Einwände haben, bitte ich um Kontakt per E-Mail ....

Zusammenfassung und Ausblick auf den folgenden Artikel

Der regelmäßige Austausch von E-Mails, die personenbezogene und andere vertrauliche Daten beinhalten, erfordert mit Auftraggebern ggf. einen Vertrag, der die Art und Qualität personenbezogener Daten definiert, zu erreichende Schutzniveaus festlegt und technische wie organisatorische Maßnahme zu deren Umsetzung regelt.

Eine wichtige Maßnahme bei Freelancern, die keinen hinreichenden Zugangsschutz zu eigenen Systemen garantieren können, erscheint mir dabei die Lagerung der E-Mails auf verschlüsselten Partitionen und Volumes zu sein. Will man nicht gleich alles verschlüsseln können virtualisierte Systeme zum Zuge kommen.

In kommenden Artikel

DSGVO, Freelancer, E-Mails und Umzug KVM-virtualisierter Linux-E-Mail-Server auf verschlüsselte Platten/Partitionen – II

gehe ich zunächst noch einmal auf ein paar Aspekte der DSGVO ein und begründe etwas genauer, warum ein vertragliches Abkommen mit einem Auftraggeber sinnvoll ist. In einem dritten Artikel widme mich dann mal dem Umzug eines Linux-E-Mail-Servers - und dabei speziell dem Umzug einer bereits existierenden virtualisierten Lösung - auf neue, verschlüsselte Partitionen oder LVM-Volumes des Hosts. Entsprechende Arbeiten für Client-Systeme sind dann recht ähnlich.

firejail firecfg – Problem mit dem KDE-Login unter Opensuse Leap 42.3 – .ssh-Dateien und ssh-agent als Ursache

Experimentiert man unbedarft mir neuen Dingen, muss man sich nicht wundern, wenn man sich Probleme schafft. Jetzt passierte mir das mit firejail.

Ich muss manchmal Skype benutzen. Zu meinem großen Ärger, da jede Art von Closed Source UDP-Streaming Applikation ein prinzipielles Sicherheitsrisiko darstellt. In einen UDP-Datenstrom können immer Pakete integriert werden, die ganz anderen Zwecken dienen als der Übertragung der eigentlichen Audio- und Videodaten. Und wenn man dann den Code nicht kennt ... Neben dem Aufsetzen eines speziell konfigurierten Containers ist die Nutzung von Firejail eine Gegenmaßnahme, solchen Applikationen das Vordringen ins System zu erschweren.

Opensuse 42.3 bietet im Repository "Virtualization"
ein RPM-Paket firejail 0.9.5 zum Download an. Das habe ich installiert. nach der Installation war zunächst auch ein kein Problem feststellbar.

Aber dann habe ich ein wenig in der Dokumentation gestöbert. Auf der Seite https://firejail.wordpress.com/documentation-2/ findet man dann unter dem Titel "I’ve just installed Firejail, now what?!" Hinweise zu bestimmten Kommandos, um "pulseaudio" [PA] zu korrigieren (wundert mich nicht) und auch das Kommando "firecfg" auszuführen:

$ firecfg --fix-sound
$ sudo firecfg

Beides hat u.U. aber unangenehme Nebenwirkungen:

1) Pulseaudio zunächst nicht mehr deaktivierbar
Das erste Kommando korrigiert "pulseaudio"-Konfigurationsdateien zwar; es sorgt aber auch dafür, dass man unter Opensuse PA nicht mehr einfach über YaST und die dortige Audio-Konfiguraiton abschalten kann. Bekanntermaßen verwende ich PA nur, wenn nicht umgehbar. So erzwangen etwa frühere Skype Versionen für Linux ( u.a. die Version 4.3) die Nutzung von PA. Das ist beim aktuellen "skypeforlinux" (Beta) nicht der Fall; das kooperiert auch direkt mit Alsa.

Das ist auf meinem Laptop auch gut so, denn PA erzeugt dort ein dauerhaftes unangenehmes Hintergrundsgeräusch (niederfrequenter Pfeifton; keine Rückkopplung) auf meinem eingebauten Mikrophon (unabhängig von Skype). Das ließ sich auch durch Ändern der Empfindlichkeit und der Regelung von Verstärkungsfaktoren unter dem PA-eigenen "pavucontrol" nie beseitigen. Ein solches Geräusch tritt bei mir im reinen Alsa-Betrieb dagegen nicht auf.

Beseitigt habe ich die Aktivierung von PA dann durch Umbenennen/Verschieben der Datei "~/.pulseaudio" und anschließende erneute Deaktivierung von PA über YaST.

2) Kein KDE-Login und kein X11-Start mehr für bestimmte Accounts möglich
Schlimmer ist dagegen eine Auswirkung des zweiten Kommandos: Es erzeugt eine Liste von Links unter dem Verzeichnis von "/usr/local/bin", die alle auf firejail verweisen. Normalerweise führt das dazu, dass viele Programme/Anwendungen über firejail gestartet und geschützt werden. Leider ist die Liste der Profile für Anwendungen aber keineswegs vollständig. Wird für eine Anwendung nichts gefunden, dann kommt wohl ein "default.profile" zum Einsatz. Letzteres verhindert aber den Zugriff u.a. auf ~/.ssh und ~/.gnupg-Verzeichnisse und dortige Dateien. Das wird aber unter Umständen unter Opensuse zu einem Megaproblem beim Start von KDE aus SDDM oder KDM heraus:

Ich konnte mich unter bestimmten Accounts nach dem Absetzen von firecfg nicht mehr von KDM oder SDDM aus in KDE (Plasma 5) einloggen. X11 wurde nicht gestartet; man landet nach ca. 1 Sekunde wieder auf dem KDM oder SDDM-Login-Schirm.

Die Fehlermeldungen hierzu waren unzureichend. Nach mühsamen Experimenten mit Konfigurationsdateien stieß ich schließlich darauf, dass allein die Existenz eines "~/.ssh"-Verzeichnisses zu Fehlern beim KDE-Start führte. Entfernte ich das Verzeichnis komplett, ließen sich KDE und X11 wieder regulär starten.

Wer oder was will im Start "~/.ssh" auslesen? Mir fiel dazu zunächst nichts ein. Dann stieß ich auf ssh-agent. Und tatsächlich ergab sich unter Opensuse Leap 42.3 folgendes Bild:

mytux:~ # ps aux | grep ssh
root      1574  0.0  0.0  53492  5816 ?        Ss   13:30   0:00 /usr/sbin/
sshd -D
myself       4065  0.0  0.0  20136  1868 ?        S    13:30   0:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/myself/.gnupg/
agent.info-mytux.mydomain.de:0 /etc/X11/xinit/xinitrc
myself       4067  0.0  0.0  13312   332 ?        Ss   13:30   0:00 /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/myself/.gnupg/agent.info-mytux.mydomain.de:0 /etc/X11/xinit/xinitrc

Offenbar klappt diese Art des X-Starts nicht mit dem komplett gefüllten "/usr/local/bin" (genauer mit den dortigen Links). Ich sehe die Ursache - wie gesagt - im "default.profile".

Die Link-Orgie unter "/usr/local/bin" beseitigt man übrigens mit

firecfg --clean

Danach klappt der Login in das X11/KDE-Gespann alles wieder. Meine Strategie ist im Moment, die Profile für verschiedene Anwendungen zu checken und "/usr/local/bin" langsam und systematisch mit Links zu füllen, die nur bestimmte Anwendungen betreffen.

Bei manchen alten Accounts habe ich zudem festgestellt, dass die Anlage der Links unter /usr/local/bin" auch dazu führt, dass jeglicher Netzwerkzugriff unterbunden ist. Hier bin ich noch an der Ursachenforschung.

Merke: Nicht gleich alles machen, was Manuals vorschlagen, wenn man von einer neuen Anwendung noch zu wenig versteht.

Veracrypt, SSHFS und sichere Datenhaltung auf gehosteten Servern – II – die Client-Seite …

Vor einigen Tagen habe ich abends ein paar begeisterte Linux-Anhänger getroffen; einige Gesprächspartner haben mir gegenüber die Sicherheit von Linux gegenüber MS Windows hervorhoben. Bei allem Respekt: IT-Sicherheit ist selten nur eine Frage des Betriebssystems. Wer meint, dass die Installation von Linux "Sicherheit" quasi garantieren würde, irrt gewaltig. Der Einsatz von Linux entbindet den Nutzer keineswegs

  • von einer detaillierten Risiko-Analyse/-Bewertung für potentiell bedrohte Daten oder Systeme
  • und von der Festlegung geeigneter Gegenmaßnahmen.

Dieser Artikel liefert hierfür ein relativ einfaches Beispiel:

Wir betrachten die Sicherheit der Inhalte von Dateien, die wir in verschlüsselten Datei-Containern verwahren. Wir öffnen solche Dateien bei Bedarf beispielsweise auf einem Laptop. Der Kontext wurde durch den vorhergehenden Artikel dieser Miniserie

Veracrypt, SSHFS und kryptierte Datenhaltung auf gehosteten Servern – I

vorgegeben: Dort hatte ich beschrieben, wie man verschlüsselte Veracrypt-Container auf gehosteten Servern zur Lagerung geheimzuhaltender Informationen einsetzen kann. Ich hatte bereits im letzten Artikel betont, dass die Dateien auf dem Server selbst nie in entschlüsselter Form verwendet werden sollten. Um diesen Punkt herum rankten sich dann zwei durchzuführende Mount-Prozesse, um die Container-Inhalte remote auf einem Client - z.B. auf einem mobilen Laptop - bequem nutzen zu können.

Der Client ist also das System, auf dem wir unsere geheimen Daten entschlüsseln und konkret nutzen. Ich gehe nachfolgend auf einige ausgewählte und prinzipielle Sicherheitsaspekte ein, die man dort im Auge behalten sollte. Die Liste der sicherheitsrelevanten Punkte ist damit keineswegs abgedeckt; aber unsere Diskussion wird zeigen, dass Sicherheit immer nur durch eine Kombination verschiedener Maßnahmen entsteht - unter Linux ebenso wie unter anderen Betriebssystemen. Linux erleichtert dem User dabei im Idealfall die Umsetzung der notwendigen Maßnahmen; der Einsatz von Linux allein ist für die Erfüllung von Geheimhaltungspflichten in der Regel aber unzureichend.

Ausgangssituation und Nutzerverhalten

Die zu schützenden Güter (im ISO 27001-Jargon: Assets) sind in unserem Beispiel geheimzuhaltende Informationen, welche in Dateiform vorliegen. Nehmen wir als extremes Beispiel etwa eine "odt"-Datei, in der der User etliche schwer zu merkende Passwörter hinterlegt hinterlegt hat. Ein ebenso brisantes Beispiel wäre etwa die Hinterlegung von Patientendaten, auf die eine Ärztin im mobilen Einsatz zugreifen möchte, in einem verschlüsselten Dateicontainer. Der Container kann remote vorliegen - etwa als Veracrypt-Archiv auf einem über das Internet erreichbaren Server. Verschlüsselte Container können aber auch lokal auf dem Laptop selbst angelegt sein.

Als Anwender/Anwenderin vertrauen wir dabei völlig auf die Verschlüsselung der Dateien. Unser Linux-Laptop für den mobilen Einsatz sei zeitgemäß ausgestattet und beinhalte u.a eine SSD. Als Anwender greifen wir auf unsere Dateien, wie im letzten Artikel beschrieben, bei Bedarf mit SSHFS und in jedem Fall mittels lokalet VC-Mounts auf dem Client zu.

Wenn erforderlich öffnen wir die Datei auf dem Laptop mit Hilfe einer passenden Anwendung (z.B. LibreOffice). Ggf. legen wir dort sogar eine Kopie der Datei an. Die Kopie lagern wir auf dem Laptop in einem der dortigen verschlüsselten VC-Containern. Geöffnete, entschlüsselte Dateien schließen wir nach Beendigung unserer Arbeit sofort wieder.

Als potentielles Bedrohungsszenario betrachten wir im Rahmen dieses Artikels primär den Verlust oder Diebstahl des Laptops. In diesem Fall ist ein physikalischer Zugriff Unbefugter oder Krimineller auf das Gerät möglich. Frage:

Sind unsere Dateien, die dort in einem Veracrypt-Container lagern, sicher?

Schlüsselfragen

Zunächst ist festzuhalten, dass die letzte Frage im Kern falsch gestellt. Es geht ja letztlich nicht um die Dateien, sondern um deren Inhalte. Die richtige Frage wäre: Sind die Informationen, die (u.a.) in den Dateien hinterlegt wurden, im vorgegebenen Bedrohungsszenario vor dem Zugriff Unbefugter sicher?

Ich nehme die Antwort vorweg: Nein, sie sind es nicht - zumindest nicht ohne eine Reihe von Zusatzmaßnahmen. Das liegt an einer Vielzahl von potentiellen "Schwachstellen", die sich bereits im Zuge der Entschlüsselung der Dateien auf unserem Laptop ergeben. Bereits für den Server hatten wir ja ansatzweise diskutiert, dass einmal entschlüsselte Datei-Inhalte trotz des späteren Schließens der Datei und trotz des Löschens von evtl. angelegten Kopien im Filesystem erhalten bleiben könnten. Schlüsselfragen sind also:

  • Was machen die Anwendungen, die wir zum Öffnen, Auslesen oder Bearbeiten der Dateien benutzt habe, mit den Datei-Inhalten? Wo verbleiben ggf. Reste entschlüsselter Daten nach Beendigung der Anwendung?
  • Was machen das Betriebssystem, das Desktop-System (KDE, Gnome, ...) und die eingesetzten Filesysteme mit den Dateien? Wo verbleiben ggf. Reste entschlüsselter Information?
  • Was macht unsere Hardware mit unseren Dateien? Wo verbleiben ggf. Reste entschlüsselter Information?

Wir können das nachfolgend nur schlaglichtartig beleuchten. Das ist aber schon hinreichend, um unsere Ausgangsthese zu belegen.

Anwendungen als Schwachstelle

Zur Ansicht der (durch Veracrypt) entschlüsselten Datei verwenden wir geeignete Linux-Programme (Editoren, Office-Programme, IDEs etc.). Im Beispiel etwa LibreOffice [LO]. Nun legen die meisten solcher Programme temporär oder gar dauerhaft Kopien der Datei im Originalzustand oder nach vorgenommenen Änderungen an. Das Problem ist, dass diese Kopien i.d.R. nicht im Bereich des gemounteten VC-Datei-Containers landen, sondern in anderen vordefinierten Verzeichnissen, die auch ohne gemounteten Container erreichbar sind. Dort wird die Information aber ohne weitere Maßnahmen unverschlüsselt hinterlegt!

Für LO können dies einerseits Dateien mit Recovery-Informationen (in der Regel die vollständige Datei unter "/tmp" in Ordnern/Dateien mit dem Namen "luxxxxx.." sein. Diese temporären Dateien werden nach dem regulären Schließen der Dateien zwar wieder gelöscht; im Fall eines Crashes verbleiben sie aber. Es gibt zudem auch cache-artig hinterlegte Bilder, die langfristig im /tmp-Verzeichnis verbleiben. Hat man in LO gar die Option zum automatischen Anlegen von Backup-Dateien aktiviert, so finden sich letztere dauerhaft - also auch nach dem Schließen der jeweiligen Dokumente - im vorgesehenen Ordner wieder. Bei mir etwa unter dem Standardverzeichnis "~/.config/libreoffice/4-suse/user/backup/". Natürlich unverschlüsselt!

Aber auch gezieltes Löschen und ein anschließendes Leeren des Papierkorbs nutzen nichts: Wer einmal versucht hat, gelöschte Dateien in einer Partition zu restaurieren, weiß, dass ein normales Löschen von Dateien überhaupt keine Sicherheit darstellt. Die Inhalte verbleiben lange auf den HDDs oder SSDs, bis sie wirklich überschrieben werden. Je mehr Platz (bei ext4: Inodes) ein Linux-Filesystem hat, desto größer die Wahrscheinlichkeit für ein Verbleiben der Original-Information in Festplatten-Blöcken. Die Chance, gelöschte Dateien oder Fragmente davon teilweise oder gar vollständig wiederherzustellen, ist somit relativ groß.

Aufpassen muss man natürlich auch auf Anwendungen, die mit internen oder extern Versionsverwaltungssystemen kooperieren. Solche Systeme können bei schreibenden Zugriffen u.U. eine automatische Versionierung vornehmen und eine Serie von unterschiedlichen Dateizuständen im System hinterlegen.

Identifizierte Schwachstellen:
Anwendungen erzeugen typischerweise temporäre und dauerhafte Dateikopien - in unserem Fall unverschlüsselt in Festplatten-Bereichen außerhalb des kryptierten Datei-Containers. Auch nach einem gezielten Löschen solcher Informationen lassen sich die enthaltenen Informationen von Leuten mit physikalischem Zugriff auf die Laptop-Festplatten (HDD/SSD) rekonstruieren. Zu Gegenmaßnahmen s. weiter unten.

Betriebs- und Desktop-Systeme als Schwachstelle

Bei zu geringem RAM beginnt ein Betriebssystem u.U. zu pagen bzw. zu swappen. Auch in diesem Fall landet dekryptierte Information auf der Festplatte. Ein weiteres Übel können in unserem Kontext Desktop-Suchmaschinen (z.B. unter KDE) darstellen, die ggf. automatisch Verzeichnisse, Dateien und deren Inhalte sowie geöffnete Dateien nach Schlagworten scannen. Auch dann landet unverschlüsselte Information dauerhaft auf Festplatten - nämlich in Index-Verzeichnissen oder Datenbanken der Suchmaschinen.

Identifizierte Schwachstellen:
SWAP-Bereiche auf der Platte und Datenbanken von Desktop-Suchmaschinen sind Orte für das potentielle Auffinden entschlüsselter Information.

Eraser-Programme als Gegenmaßnahme?

Wenn man seine Anwendungen sehr gut kennt und weiß, wo überall Datei-Inhalte abgelegt werden, könnte man sich gegen ein Rekonstruieren gezielt gelöschter Information ggf. dadurch absichern, dass man zu Programmen greift, die einen Löschvorgang nicht nur als Freigabe entsprechender Knoten im Filesystem verstehen sondern entsprechende Blöcke tatsächlich mit Nullen oder zufälligen Zeichen überschreiben. Dieses Vorgehen setzt, wie gesagt, voraus, dass man vollständig überblicken muss, welche Anwendungen wo genau Informationen hinterlegen. Und man muss die notwendigen Löschvorgänge auch regelmäßig durchführen.

Nun gibt es zudem Programme, die alle freigegebenen Blöcke einer Festplatte identifizieren und überschreiben können. Auch solche Programme muss man aber regelmäßig laufen lassen - u.a. vor einem Shutdown des Systems. Selbst dann besteht aber immer noch die Gefahr, dass ein Laptop in einem StandBy- oder Hybernation-Zustand verloren geht oder gestohlen wird.

Die Vorstellung, ein gezieltes Löschen und Überschreiben von freigegebenen Speicherblöcken regelmäßig und in typischen Arbeitssituationen rechtzeitig sowie ohne Lücken durchführen zu können, halte ich insgesamt für illusorisch.

Verschlüsselte Partitionen als Lösung?

Das eigentliche Fazit aus den bisherigen Überlegungen ist: Im RAM entschlüsselte und geheimzuhaltende Informationen müssen auf dem Laptop immer in verschlüsselter Form auf die Festplatten gelangen. D.h.:

Alle Partitionen auf den Speichersystemen des Clients sollten vollständig verschlüsselt betrieben werden.

Das muss unabhängig vom Einsatz von verschlüsselten Datei-Containern realisiert werden! Egal, ob letztere lokal oder remote vorliegen. Entscheidend ist, dass das Entschlüsseln und Öffnen von Container-Dateien auf dem Client in unserem Szenario immer zu einer verschlüsselten Ablage von Information auf den Datenträgern des Clients führen muss - egal was die Anwendungen oder das Betriebssystem da genau ablegen wollen.

Systeme mit verschlüsselten Partitionen kann man unter Linux z.B. mit Hilfe LUKS oder eben auch Veracrypt einrichten. Verbunden ist damit typischerweise die Eingabe eines speziellen Codes beim Hochfahren des Systems oder beim Übergang aus einem Hybernation-Zustand in den Normalbetrieb. Erst dann wird die Entschlüsselung der Partitionsinhalte vorgenommen.

Was immer eine Anwendung danach tut: Die Informationen erreichen den Plattencontroller dann nur in verschlüsselter Form (hoffentlich). Wir haben das Prinzip der verschlüsselten VC-Container, das wir bereits im letzten Artikel betrachtet hatten, inzwischen also auf die Festplatten und dortigen Partitionen des Clients ausgedehnt.

Die richtige Konsequenz aus unseren Sicherheitsanforderungen scheint also zu sein, auf den Clients nicht VC-Container für Datei-Kopien anzulegen, sondern gleich alle Platten bzw. deren Partitionen zu verschlüsseln. Nachdem wir dafür entwickelten Verfahren und Verschlüsselungsverfahren unter Linux vertrauen - sind unsere Informationen nun endlich sicher?

SSDs als Schwachstelle

Tja. Die Antwort auf die letzte Frage könnte eigentlich Ja lauten, wären da nicht sehr unangenehme Eigenschaften von modernen SSDs. Ich will hier gar nicht auf alle Details eingehen (davon verstehe ich zu wenig; s. jedoch die unten angegebenen Links). Aber der entscheidende Punkt scheint mir das Wear-Leveling zu sein, das praktisch alle modernen SSDs aufweisen. Da einzelne Speicherbausteine der SSD jederzeit ausfallen können, ist der tatsächliche Speicherplatz auf SSDs deutlich größer ausgelegt als der nutzbare Netto-Platz. Information, die auf reguläre Speicherblöcke geschrieben wird, wird redundant vervielfacht, um gegen einzelne Ausfälle von Speicherzellen gewappnet zu sein. Die Verwaltung übernimmt dabei der herstellerspezifische, in die SSD verbaute SSD-Controller in autonomer Weise. Der bemüht sich wiederum um einen gleichmäßige Auslastung aller vorhandenen Speicherzellen.

An die intern redundant hinterlegten Informationen kommt man mit Mitteln eines normalen Betriebssystems leider nicht heran. Wohl aber mit Spezialtools für das Auslesen von SSDs. Fazit:
Hast du oder hat dein System irgendwann mal unverschlüsselte Information auf die Platte geschrieben, so weißt du nicht, im welchen und wie vielen Speicherzellen diese Information auf der SSD noch vorhanden ist. Das wiederum bedeutet:

Eine SSD, die man unvorsichtigerweise irgendwann mal unverschlüsselt genutzt hat, enthält womöglich noch zu schützende Informationen in Bereichen, an die man ohne spezielle Mittel gar nicht herankommt. Wohl aber Experten, die physikalische Zugriff auf die SSD erhalten!

Nun gibt es jedoch auch Werkzeuge, die angeblich in der Lage sind, alle(!) Speicherzellen einer SSD zu überschreiben. Genau ein solches Tool müsste man bei einer SSD, die man schon benutzt hat und nun verschlüsseln will, vorab zum Einsatz bringen. Diese Tools sind aber mit Risiken verbunden, nach Auskunft mancher Tester im Internet auch nicht zuverlässig und stressen die SSD in jedem Fall.

Schlussfolgerungen

In unserem Szenario führt die bisherige Diskussion zu folgenden Punkten:

  1. Ein halbwegs sicherer Client erfordert gem. der obigen Anforderungen und Diskussion vollständig verschlüsselte Partitionen aller Festplatten und SSDs.
  2. Am besten verzichtet man auf Clients mit höchsten Sicherheitsanforderungen ganz auf den Einsatz von SSDs. Das ist übrigens die Empfehlung von Experten des BSI wie auch der Veracrypt-Entwickler.
  3. Wenn man SSDs dennoch benutzen will oder muss: An den Controller der SSD dürfen von Anfang an nur verschlüsselte Daten übermittelt werden. Die SSD ist also bereits im jungfräulichen Zustand (Fabrikzustand) ausschließlich mit verschlüsselten Partitionen zu versehen - und auch später dürfen nur verschlüsselte Partitionen hinzukommen.
  4. Zudem gibt es die Empfehlung, dass die (hinreichende lange) Passphrase oder notwendige Keyfiles für den Zugang zu den verschlüsselten Partitionen nicht geändert werden sollten. Der Grund dafür ist, dass ein sicheres Überschreiben der alten Header nicht gewährleistet werden kann. Wird also ein Password/Keyfile kompromittiert, ist es am besten eine neue SSD aufzusetzen, als auf der ursprünglichen SSD alte Passwörter zu ändern.

Ferner gilt: Wird ein Laptop im nicht heruntergefahrenen Zustand verloren/entwendet, ist diese Situation ohne weitere Maßnahmen kaum besser als bei einem unverschlüsselten System: Es ist lediglich die Sperre des Bildschirmschoners zu überwinden.

Verschlüsselte virtuelle Maschinen als Maßnahme?

Es gibt noch einen weiteren Ansatz, sich zu schützen: Nämlich virtuelle Maschinen auf verschlüsselten Partitionen oder LVM-Volumes anzulegen - und die Datei-Container vom Server nur dort zu öffnen und zu bearbeiten. Dieser Ansatz, bei dem nicht alle Partitionen des Laptops verschlüsselt werden müssten, erscheint mir halbwegs sicher; ich bin aber auch dabei ein wenig skeptisch:

  • Zum einen muss die Abschottung von Host perfekt sein. Wer überblickt das aber schon?
  • Zum anderen darf man Verzeichnisse des Gastes/Hostes nicht im jeweils anderen System nutzen oder Dateien vom Gast zum Host kopieren oder Gastdateien mit Programmen des Hosts auslesen oder öffnen. Ein Mounten von Verzeichnissen des Gastes im Host verbietet sich daher. Aber auch umgekehrt muss man aufpassen.

Die geheimzuhaltenden Dateien dürfen nur und ausschließlich im Gastsystem und mit Programmen des virtuellen Gastsystems geöffnet werden. Sie dürfen nie unter dem Host-System selbst - also hier unter dem Laptop-Betriebssystem - geöffnet werden. Also ist von Samba und NFS zum gegenseitigen Mounten von Verzeichnissen zwischen virtualisiertem Gast und Host abzusehen! Zudem dürfen sich auf den Platten des (Virtualisierungs-) Hosts keine Informationen befinden, die Hinweise auf Passwörter und die Entschlüsselung der Partitionen für den Gast geben.

Setzt man trotzdem auf den Ansatz mit virtualisierten Gastsystemen, weil man auf dem Client nicht alles verschlüsseln will, so ist es wohl am einfachsten, für das Gastsystem ein verschlüsseltes LVM-Volume des Laptops heranzuziehen. Siehe die Links unten.

Fazit

Eine Sicherheit allein durch den Einsatz verschlüsselter Datei-Container gibt es in unserem Szenario nicht. Auch unter Linux nicht! Egal, ob die Container remote auf gehosteten Servern oder lokal vorhanden sind. Vielmehr ist für eine vollständige Verschlüsselung aller Partitionen des Client-Systems zu sorgen, wobei auf den Einsatz von SSDs im Idealfall verzichtet werden sollte.

Wir haben hier nur einen kleinen Teil von Sicherheitsaspekten betrachtet. Das, was wir diskutiert haben, hätte man in ähnlicher Weise aber auch für andere Betriebssysteme aufschreiben können. Sicherheit ist ein weit komplexeres Thema als nur eine Frage des Betriebssystems. Das gute an Linux ist jedoch, dass man hier alle notwendigen Tools zur Verbesserung der Sicherung geheimzuhaltender Information als Opensource Programme und kostenfrei vorfindet.

Also: Verschlüsselt eure geheimzuhaltenden Informationen. Nicht zuletzt, wenn ihr im Auftrag von Unternehmen unterwegs seid! Verlangt euren (Linux-) Admins entsprechende Lösungen ab. Aber hört nicht auf, Sicherheit zu hinterfragen. Sie ist immer relativ! Auch unter Linux!

Links - weitere Infos

Grundlegende Probleme der Verschlüsselung reiner Datei-Container-Verschlüsselung
https://www.computerwissen.de/it-sicherheit/web-security/artikel/verschluesselte-container-bieten-ihnen-keinen-zuverlaessigen-schutz.html
https://www.cs.washington.edu/research/security/truecrypt.pdf

SSDs mit Wear-Leveling und Sicherheitsprobleme
http://www.zdnet.com/article/ssd-security-the-worst-of-all-worlds/
https://www.pcwelt.de/ratgeber/Datensicherheit-6581465.html
https://www.computerwoche.de/a/die-geheimen-schwaechen-der-ssd,2501912,4
https://www.computerbase.de/forum/showthread.php?t=1395284
https://forum.truecrypt.ch/t/ssds-not-appropriate-for-encryption/486
https://www.veracrypt.fr/en/Wear-Leveling.html
https://www.ghacks.net/2011/02/23/solid-state-drives-and-encryption-a-no-go/
https://debianforum.de/forum/viewtopic.php?t=163274
http://news.softpedia.com/news/systemd-232-supports-veracrypt-encrypted-partitions-adds-60-improvements-509945.shtml

Performance SSDs - Encryption - TRIM
https://security.stackexchange.com/questions/61089/can-truecrypt-encrypt-ssds-without-performance-problems
https://www.heise.de/ct/hotline/Linux-Verschluesselte-SSD-trimmen-2405875.html
http://mgessat.com/verschluesselungssoftware-veracrypt-unabhaengige-ueberpruefung-abgeschlossen/
http://media-addicted.de/ssd-and-truecrypt-durability-and-performance-issues/744/
http://asalor.blogspot.de/2011/08/trim-dm-crypt-problems.html

Sicheres Löschen von Files auf konventionellen HDDs mit Wipe
[funktioniert nicht mit Flash-Speichern/SSDs]
https://superuser.com/questions/19326/how-to-wipe-free-disk-space-in-linux
https://tails.boum.org/doc/encryption_and_privacy/secure_deletion/index.en.html
https://wiki.ubuntuusers.de/Daten_sicher_l%C3%B6schen/
https://www.cyberciti.biz/tips/linux-how-to-delete-file-securely.html

Vollständiges Löschen von SSDs?
https://wiki.ubuntuusers.de/SSD/Secure-Erase/
http://www.pc-magazin.de/ratgeber/festplatte-restlos-loeschen-sicher-saeubern-ssd-secure-erase-anleitung-hdd-3196204.html#
https://wiki.ubuntuusers.de/SSD/Secure-Erase/

Bereinigen des RAMs, Caches, SWAP spaces
https://www.tecmint.com/clear-ram-memory-cache-buffer-and-swap-space-on-linux/

LVM und verschlüsselte Volumes
https://debianforum.de/forum/viewtopic.php?f=12&t=127012

KVM Gastsysteme auf verschlüsselten Volumes
https://www.ibm.com/support/knowledgecenter/en/linuxonibm/liaat/liaatkvmsecencrypt.htm
https://www.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatsecurity_pdf.pdf
https://security.stackexchange.com/questions/20334/memory-dumping-cause-for-concern-in-virtualization
https://forums.whonix.org/t/how-useful-is-in-guest-encryption/1253
https://security.stackexchange.com/questions/29535/full-disk-encryption-within-a-vm-how-secure-is-it/29538#29538

Ein paar Aspekte von LUKS
https://wiki.ubuntuusers.de/LUKS/Containerdatei/
https://www.pcwelt.de/ratgeber/Ausgesperrt__Luks_mit_Ersatzschluessel_oeffnen-Linux-8664088.html
http://www.bocekm.com/enlarge-luks-encrypted-logical-volume/

Backups mit LUKS und SSHFS
https://ruderich.org/simon/notes/encrypted-remote-backups