Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung

Diese Artikelserie behandelt die Verschlüsselung eines Laptops unter Opensuse Leap 15.0. Nicht nur die DSGVO verlangt von IT-Freelancern Verschlüsselung als Teil eines Katalogs von Maßnahmen zum Schutz personenbezogener Daten von Kunden. Das fängt u.a. beim Austausch von Mails mit Kundenvertretern an. Da Sicherheit nicht durch Verschlüsselung irgendwelcher Partitionen entsteht, hatten wir im letzten Beitrag
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen
mit Vorüberlegungen zur Voll- oder Teil-Verschlüsselung begonnen. Ein Punkt, auf den ich dabei noch nicht eingegangen bin, ist das Thema Virtualisierung: Ein moderner Laptop kann selbstverständlich auch als Host für virtualisierte Gastsysteme eingesetzt werden.

Ein typischer Anwendungsfall für einen Freelancer, der primär auf Linux setzt, ist die Virtualisierung von MS-Windows-Gastsystemen. (Leider braucht man für die effiziente Kooperation mit den meisten Kunden ja weiterhin MS-Windows Programme 🙁 ) Weil wir gerade dabei sind: Als Linux-Profi ist man sich hoffentlich der Tatsache bewusst, dass virtualisierte Windows-10-Clients in Standardausführung zumindest potentiell eine Bedrohung der gesamten Geheimhaltungskette darstellen können (https://www.lda.bayern.de/media/windows_10_report.pdf; Heise Artikel zum Bundesclient). Wir werden dieser Problematik im Rahmen der Artikelserie noch mal gesondert Raum widmen müssen.

Virtualisierung ist aber auch unabhängig von Windows-Gastsystemen ein gutes Mittel zur Separation von Arbeits- und Kunden-Domänen. Insbesondere kann man die Netzwerkfähigkeiten von Gastsystemen jedweder Art für den kundenbezogenen Einsatz auf ganz bestimmte Server - z.B. die des Kunden - einschränken. Web-Browsing und den nicht kundenbezogenen Mail-Verkehr verlagert man dagegen auf einen anderen abgegrenzten Gast des Laptop-Hosts mit minimaler Ausstattung. (Nebenbei: Die Abtrennung von Prozessen und Daten von Gästen gegeneinander und gegenüber dem Host ist bei KVM/QEMU-Vollvirtualisierung aus Sicherheitssicht deutlich besser gewährleistet als bei Containern.) Virtualisierung bietet also zusätzliche Möglichkeiten, die Sicherheit insgesamt zu verbessern. Man sollte das Thema deshalb im Kontext einer Verschlüsselungsstrategie berücksichtigen. Ich gehe im vorliegenden Beitrag allerdings nur auf einige Aspekte des Themas "Virtualisierung und Verschlüsselung" ein. Ich bezeichne dabei - wie im letzten Beitrag - sowohl LVM-Volums als auch echte Partitionen als "Volumes".

Voll-Verschlüsselung virtualisierter Gast-Systeme - Varianten

Spricht man über Virtualisierung und Verschlüsselung, so ist zwischen den Gastsystemen, dem Host und den jeweiligen Storage-Systemen zu unterscheiden. Meine im ersten Artikel angegebene Liste von Devices, die im Rahmen einer Vollverschlüsselung kryptiert werden müssen, relativiert sich deshalb: Meint man den Storage des Hosts, meint man dem Gastsystem zugeordnete Devices, meint man beides? Wir konzentrieren uns gedanklich zunächst auf die Voll-Verschlüsselung des Gastsystems - und sehen, wie weit wir damit kommen. Dieser Ansatz entspricht dem eines unverschlüsselten Laptop-Hosts mit einem oder mehreren "voll verschlüsselten virtuellen Gast-System(en)" (z.B. unter KVM/QEMU).

Dafür gibt es technisch mehrere Lösungen:

  1. Das virtuelle System kann in einem oder mehreren mit LUKS verschlüsselten Volume/s des Hosts untergebracht werden. Der Host sorgt dann dafür, dass nur verschlüsselte Daten auf die Storage-Systeme des Gastes geschrieben werden.
  2. Wie Punkt 1; dem Gastsystem wird allerdings erlaubt, ergänzend aber auch selbst weitere kryptierte Daten-Volumes zu mounten und bzgl. dieser Devices über den eigenen Kernel und LUKS für die Verschlüsselung sorgen.
  3. Das Gastsystem wird von vornherein so installiert, dass es selbst für die Verschlüsselung sämtlicher von ihm benutzten Storage Devices sorgt - u.a. auch des Devices mit dem eigenen root-Filesystem.

Paranoide können natürlich auch Variante 1 und 3 kombinieren - und so zwei ineinandergreifende Schichten der Verschlüsselung aufbauen. Das wird sich aber womöglich in einer Reduktion der Performance niederschlagen. Eine weitere Variante wäre die, das root-Filesystem des virtualisierten Systems in einem datei-basierten Krypto-Container zu nutzen. Die unten diskutierten Konsequenzen sind im Wesentlichen aber vergleichbar mit jenen, die sich aus der Variante (1) ergeben.

Daten-Leackage über Host-RAM

Grundsätzlich muss man sich über etwas klar sein, das unabhängig davon gilt, ob man Volume-Verschlüsselung über den Gast oder den Host betreibt: Alle (De-)Kryptierungs-Schlüssel landen irgendwo im RAM des Systems.

Im hier diskutierten Fall - Freelancer mit Laptop als Virtualisierungshost - wäre die Tatsache, dass der Host-Admin das Gastsystem einsehen und Speicherabzüge machen kann, kein primäres Problem. ( Off topic: Das ist ganz anders im Fall von Systemen, die von und bei Providern gehostet werden! Siehe:
https://security.stackexchange.com/questions/64102/vps-privacy-openvz-vs-kvm-vs-xen
https://www.ibm.com/blogs/cloud-computing/2013/07/29/how-your-data-leaks-from-a-virtual-machine/)

Dennoch ist der RAM des Laptops ein potentielles Angriffsziel zum Knacken verschlüsselter Systeme. Sein Inhalt darf im Betrieb nicht von Unbefugten ausgelesen werden; auf einem gehackten Host bietet weder die Voll-Kryptierung von Gästen noch des Hostes selbst einen hinreichenden Schutz. Ist ein Crypto-Schlüssel (des Hosts oder eines Gastsystems) erst einmal zum Angreifer gelangt, kann er nach einem Diebstahl des Laptops die kryptierten Volumes in Ruhe auslesen. Sicherheit erschöpft sich somit grundsätzlich nicht in der Verschlüsselung von Daten- oder OS-Volumes!

Die Inhalte von RAM-Bereichen der Gäste bzw. des Hosts dürfen aber auch nicht durch unachtsame Aktionen unsererseits auf unverschlüsselte Plattenbereiche des Hosts gelangen. Das führt zu Einschränkungen bei der Nutzung verschlüsselter Gastsysteme.

Verschlüsseltes Gastsystem, unverschlüsselter Host - das Problem der "Save"-Funktionalität

In den Fällen 2 und 3 der obigen Liste darf man den Zustand der virtuellen Maschinen (inkl. RAM !) nie auf einem unverschlüsselten Volume des Hosts speichern. Im Besonderen darf man das nicht, wenn der Laptop-Host auf SSDs operiert (s. meine letzten Post.) Grund: Der auf der Platte abgelegte RAM-Bereich des Gasts beherbergt einen oder mehrere LUKS-Master-Key(s).

Die meisten Virtualisierungssysteme (Voll-, Para-Virtualisierung; Container) bieten uns eine gut gemeinte Möglichkeit zum vollständigen Speichern des Zustands eines Gastsystems in Form einer "Save"-Funktion an. Das entspricht einer Art gezielt ausgelöster Hibernation des Gastes auf Storage-Bereichen dem Host. Diese "Save"-Funktionalität lösen etwa virtmanager/libvirt auf einem Suse-KVM-Hostautomatisch aus, wenn ein Shutdown des KVM-Host erfolgt - und seine Gastsysteme vorab nicht heruntergefahren wurden. Es kann aber sogar zeitgesteuerte Programme geben, die die Save-Funktion nach einer gewissen Zeit ohne User-Interaktion mit dem Gastsystem auslösen. Wenn der Host selbst auf unverschlüsselten Volumes operiert, wird das zu einem massiven Sicherheits-Problem. Wenn die System-Platte in diesem Zustand in die Hände eines Angreifers geraten sollte, kann er über eine Daten-Analyse den oder die Verschlüsselungs-Keys ermitteln und/oder die abgespeicherte Maschine gar in den operativen Zustand versetzen.

Mir ist es selbst schon in aus Unachtsamkeit oder in zeitkritischen Situationen passiert, dass ich mich auf die Save-Funktionalität von Virtualisierungshosts verlassen habe. Hier geht es also wieder um "Disziplin" des Anwenders. Der traue ich nicht - nicht mal bei mir selbst. Deshalb spricht der diskutierte Punkt für eine Verschlüsselung auch der Volumes des Host-Systems. Mindestens muss man sich aber darum kümmern, wohin der Zustand von Gastsystemen gespeichert wird - und entsprechende Verzeichnisse auf ein verschlüsseltes Volume verlagern, das am Host gemountet wird.

Verschlüsseltes Gastsystem, unverschlüsselter Host - das Problem der "Suspend"- oder Hibernate-Funktionalität des Hosts

Virtualisierungsprozesse für den Gast und zugehörige RAM-Bereich auf dem Host sind in bestimmten Situationen genauso zu sehen wie andere Prozesse/RAM-Bereiche des Hosts auch. Aus diesem Grund darf man in beiden oben unterschiedenen Fällen die Suspend- und Hibernate-Funktionalitäten des Hosts nicht benutzen, solange die verschlüsselte virtuelle Maschine noch läuft. Im Suspend-to-RAM-Zustand wird der Speicher womöglich nach einem Diebstahl über Spezialwerkzeuge zugänglich. Im schlimmsten Fall (kein Passwortschutz für den Pausenzustand) landet man nach dem Wieder-Erwecken des Systems in einer offenen virtuellen Maschine. Hibernation hatten wir bereits im letzten Post diskutiert - die dort aufgeführten Argumente gelten in gleicher Weise für Gastsysteme: Der RAM-Inhalt landet samt Verschlüsselungskeys und ggf. auch dekryptierten Daten auf unverschlüsselten Bereichen des Hosts.

Hibernate auf einen verschlüsselten (!) SWAP des Hosts ist ein sinnvoller Ansatz. Sicher ist in problematischen Situationen aber nur das Befolgen folgender Regel:

Gastsysteme sind vor jeglichem Suspend oder Hibernate des Hosts herunterzufahren.

Eine Zusammenfassung der Rahmenbedingungen für Voll-Verschlüsselung von Virtualisierungsgästen findet man übrigens unter folgendem Link:
https://security.stackexchange.com/questions/29535/full-disk-encryption-within-a-vm-how-secure-is-it

Wir landen somit erneut beim Thema "Disziplin des Anwenders". Es spricht einiges dafür, im Falle von Virtualisierung die Suspend-Funktionalität des Hosts zu deaktivieren und Hibernate nur zu nutzen, wenn die dabei genutzten (SWAP-) Volumes verschlüsselt sind.

Verschlüsseltes Gastsystem, unverschlüsselter Host - das Problem der Disziplin bei Datenzugriffen

In der Praxis benötigt man oft eine Kombination aus Linux- und Windows-Gastsystemen, um mit Kundendaten zu arbeiten und letztlich die Formate zu erzeugen, die die Kunden für notwendig erachten. Wählt man eine Lösung mit voll-verschlüsselten Gastsystemen, so darf man denn auch nur ausschließlich diese Gäste für den Zugriff auf und die Verarbeitung von schützenswerten Kundendaten nutzen. Das ist in der (mobilen) Praxis nicht so einfach, wie man meinen möchte. Virtualisierung ist zwar ein gutes Mittel zur organisatorischen Separierung von Arbeitsdomänen - speziell in einer servergestützten Umgebung. Aber gerade auf einem Laptop ist es verführerisch einfach, auch den "Host" (=Laptop) direkt für bestimmte Arbeiten einzusetzen. Da gilt es, nicht den Überblick verlieren und aus Bequemlichkeit unvorsichtig zu werden. Wie oft möchte man schnell mal eine Datei, die man auf dem Host herunter geladen hat, zum Gast transferieren. Oder eben umgekehrt ... Mounten von Gast-Devices am Host ist z.B. tabu, wenn man desktop-weite Suchmaschinen und Daten-Indexer am Laufen hat. Wir haben es also erneut mit dem Thema der Anwender-Disziplin zu tun ...

Zu nennen ist aber auch das Thema der Protokolle für den grafischen Zugriff auf den Gast (Spice, diverse VNCs, X2GO, ...). Zugehörige Client-Porgramme muss man auf dem Laptop (Host) ausführen; sie beherbergen oft auch eine Reihe von Komfort-Funktionen. Dann ist zu fragen: Werden wirklich keine relevanten Daten in den jeweiligen Clients unter Nutzung des Host-Storage gepuffert? Was passiert bei Copy/Paste-Aktionen? Sind Share-Optionen für den Datei-Austausch alle abgeschaltet? Der Teufel steckt hier möglicherweise im Detail des jeweiligen Protokolls - und wer kennt die schon alle ....

Ferner müssen die genutzten Gastsysteme voll netz- und internet-fähig werden - ohne dass direkte Verbindungen vom Host oder anderen unbefugten Gastsystemen zu den Gästen für die kundenbezogenen Aufgaben zugelassen werden. Das zieht sofort eine sorgfältige Dienste-Konfiguration auf dem Gast-System und komplexeres Firewalling in virtuellen Netzen nach sich - insbesondere dann, wenn man auch noch die Kommunikation zwischen Windows-Gästen und Linux-Gästen kontrollieren muss.

Es ist nicht so, dass man das nicht alles in den Griff bekommt. Aber eine Vollverschlüsselung auch des Hosts (hier des Laptops) dämpft einen Teil der Risiken.

Verschlüsseltes Gastsystem, unverschlüsselter Host - das Problem des Host-Swaps

SWAP-Space dient dem Abfangen von RAM-Engpässen und auch für Hibernation. Auf einem Virtualisierungs-Host - zumal einem Laptop - ist die Wahrscheinlichkeit hoch, dass der RAM knapp wird, wenn mehrere Gäste unterstützt werden müssen. Konsequenz ist, dass der SWAP des Hosts in jedem Fall verschlüsselt werden muss.

Verschlüsseltes Gastsystem, unverschlüsselter Host - das Problem von Dumps

Eine Sache, die oft übersehen wird, sind Dumps des Hosts im Fehlerfall. Auch Linux ist ja nicht gegen (seltene!) Abstürze gefeit. Auch dann würden Infos aus dem RAM ungewollt auf dem ggf. unverschlüsselten Storage des Hosts landen.

Verschlüsselung auch der Gast-Volumes dem Host überlassen?

Wir hatte weiter oben Alternativen unterschieden, bei denen der Host oder aber die Gastsysteme für die Verschlüsselung zuständig sind. Abschließend möchte ich deshalb noch kurz einen Punkt ansprechen, der in der Praxis relevant werden kann: Verschlüsselung erfordert zusätzliche CPU-Prozesse, die auf die vorhandenen CPU-Cores entweder des Hosts oder der Gäste verteilt werden müssen.

Jemand, der auf einem Laptop ernsthaft Virtualisierung betreibt, wird eine entsprechende CPU mit Hyperthreading und 4 bis 6 Standard-Cores wählen. Das entspricht dann 8 bis 12 Threads (virtuellen CPU-Cores) für die Virtualisierung. Wie man die Cores verteilt, sollte bei der Frage, ob das Gast-System oder der Host verschlüsselt, beachtet werden. Hat der Host insgesamt noch mehr Cores als die Gastsysteme selbst zur Verfügung, so erscheint es mir aus Performance-Gründen klug, die Verschlüsselung auch von Volumes, die die Gäste als Storage nutzen, gänzlich dem Host zu überlassen. Ich habe damit auf KVM-Virtualisierungsservern gute Erfahrungen gemacht.

Fazit - lieber auch den Host voll verschlüsseln

Virtualisierung kann auch auf einem professionell genutzten Laptop relevant sein. Die oben diskutierten Punkte sprechen dafür, den Virtualisierungshost( = Laptop-OS samt Storage-Volumes) neben den Gästen voll zu verschlüsseln. Man kann versuchen, alle Bereiche des Hosts zu identifizieren, die potentiell Inhalte des Gastes (RAM) in verschiedenen Situationen aufnehmen würden. Mir persönlich wäre das Risiko, dabei etwas zu übersehen, ehrlich gesagt zu groß.

Im nächsten Beitrag

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer

widme ich mich der Frage, wie die verschiedenen Zugriffs-Layer eines verschlüsselten Laptops (LVM, LUKS, ggf. RAID) geschichtet werden können.

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

Im letzten Artikel dieser Serie

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

hatte ich festgestellt, dass ein regelmäßiger Mailaustausch mit Kunden zu einem DSGVO-Thema werden kann. Die Herausforderung für einen Freelancer ist dabei, dass Datenschutz auf seiner Seite auch in Maßnahmen zur Datensicherheit für Mailinhalte münden muss. Diese Maßnahmen muss der Auftraggeber kennen (s. Art. 28 und Art. 32 der DSGVO).

Datensicherheit von E-Mails - im Besonderen im Sinne der Vertraulichkeit - erstreckt sich natürlicherweise auf die Absicherung des Transports und der Lagerung. Der alleinige Zugriff durch den Berechtigten (Adressaten) ist zu gewährleisten. Das ist nicht so viel anders als bei Dateien auch. Akzeptiert man erst einmal, dass E-Mails eine Personenbezug aufweisen, muss man sich um dieses Thema im Sinne DSGVO kümmern - und zwar von vornherein in Kooperation mit seinem Auftraggeber (s. Art. 28).

Ich möchte in diesem Artikel nochmals auf meine Motivation zu vertraglichen Regelungen eingehen, obwohl das für den einen oder anderen technisch interessierten Leser womöglich langweilig sein mag. Der Grund für diesen Einschub ist, dass ich in einigen Diskussionen, die ich seit dem letzten Artikel geführt habe, immer wieder von Kollegen darauf hingewiesen wurde, dass ein solcher Aufwand bei Kleinst-Unternehmen (mit einer Mitarbeiterzahl < 250) womöglich gar nicht nicht nötig sei.

Wirklich nicht ?

DSGVO und vertragliche Vereinbarungen auch für KMU?

Ja, es gibt in der DSGVO den Hinweis auf Unternehmen mit weniger als 250 Mitarbeitern. Primär in Art. 30. In Art. 40 wird ferner darauf hingewiesen, dass die EU-Mitgliedsländer "Verhaltensregeln" erarbeiten sollen, die auf die besonderen Bedürfnisse von Kleinst- und Kleinunternehmen Rücksicht nehmen. Tja, kennt die Regeln für Deutschland jemand? Ich nicht ....

In Art. 30 geht es aber "nur" um eine mögliche Befreiung von der Pflicht zum Führen eines "Verzeichnisses von Verarbeitungstätigkeiten" (für personenbezogene Daten). Dies ersetzt jedoch nicht Art. 28 - und der verlangt eindeutig eine Verarbeitung zu schützender personenbezogener Daten auf Basis eines Vertrages. Das ist meine erste Motivation für vertragliche Regelungen in puncto E-Mail-Austausch.

Nun könnte man ins Feld führen, dass der Zugriff auf E-Mails, die einem ein Kunde (freiwillig) schickt, keine echte Weiterverarbeitung von persönlichen Daten darstelle. Der Kunde willige durch das Senden ja in eine potentiell unsichere Form der Verarbeitung ein. Das mag im Einzelfall vielleicht so sein. In größeren Projekten hat man es aber mit einer Vielzahl von Mails verschiedener Personen zu tun, die sich systematisch mit Sachverhalten auseinandersetzen. In den Mails befinden sich im Abspann meist weitere persönliche Kontaktdaten; damit ist ein Personenbezug gegeben. In den vielen Mail-Texten befinden sich zudem ggf. Inhalte vertraulicher Natur über den Absender oder Dritte oder aber das Projekt. Im Zuge eines Projekts werden Aufgaben, Verhalten, Arbeitsweise, Probleme und ggf. Meinungen der verschiedenen Absender meist deutlich aus dem Mailverkehr ersichtlich. Ist man ehrlich, so wird man zugeben: In projektbezogenen Mails stecken in Summe erhebliche Mengen an direkt oder indirekt personenbezogenen Informationen. Das ist meine zweite Motivation.

Hinzu kommt: In Projekten ist ein solcher Informationsfluss auch an externe Freelancer sehr regelmäßiger Natur. Und Mails werden ebenso regelmäßig von selbigen Externen gespeichert - auch um im Bedarfsfall nachweisen zu können, was man wann und warum für den Auftraggeber geleistet hat. Mach ich auch genau so. Deswegen scheinen mir hier dann die Einschränkungen von Art 30. Punkt 5 der DSGVO zu greifen: Da ist die Verpflichtung zum Tätigkeitsverzeichnis nur bei nicht regelmäßigem Datenaustausch ausgenommen. Ich meine aber ganz generell, dass im Kontext des regelmäßigen Mailaustauschs in Projekten ein Nachdenken über Datenschutz gefragt ist. Das ist meine dritte Motivation für vertragliche Vereinbarungen.

In Projektmails werden zudem oft Dateien als Anhänge transportiert, die Informationen über Projektinhalte enthalten. Mit irgendwas muss der externe Freelancer ja arbeiten! Nun wird jeder vernünftige Arbeits- oder auch Berater-Vertrag den Freelancer zur Geheimhaltung solcher Informationen verpflichten und dazu auch technische Maßnahmen auf der Höhe der Zeit einfordern. Es geht dann also um eine direkte Anforderung des Auftraggebers, elektronisch übermittelte Informationen des Auftraggebers zu schützen. Hierfür gelten Datenschutzgesetze ganz generell und auch ganz unabhängig von der DSGVO - brisant wird der Informationsaustausch über Mail im Sinne der DSGVO aber zusätzlich durch die Kopplung an einen identifizierbaren Absender. Das ist meine vierte Motivation für vertragliche Regelungen.

Ein weiterer Beweggrund ist folgender: Man sollte sich auch als Kleinst-Auftragnehmer sehr klar darüber werden, welches Schutzniveau man als Einzelperson zu vertraulichen Daten (hier: Mails) überhaupt mit welchen Maßnahmen anbieten kann - und welche Restrisiken verbleiben.

Eine letzte starke Motivation für eine vertragliche Fixierung von Maßnahmen ist sozusagen die "Mithaftung" des Auftraggebers: Ich denke, es ist für einen Auftragnehmer immer besser, wenn er im Schadensfall nachweisen kann, dass der Auftraggeber über die Maßnahmen und Risiken bei der Daten-/Informations-Vrarbeitung durch den Auftragnehmer - also durch den Freelancer - volle Kenntnis hatte. Und dies gilt eben auch bzgl. der Mail-Verarbeitung.

Aus all diesen Gründen sollte man wegen der DSGVO (aber nicht nur wegen ihr) verschiedene Punkte zur Mailverarbeitung mit dem Auftraggeber in einem Vertrag hinterlegen. Die Grundlage für solche Vereinbarungen bieten wie gesagt Art. 28 und auch 32 der DSGVO - auch für Unternehmen mit weniger als 250 Mitarbeitern.

Kritische Punkte bzgl. des Mailschutzes

Die Liste der Hauptkapitel in einem Katalog an Verarbeitungstätigkeiten bzgl. Mails ist im Prinzip recht einfach:

Empfang, Versand, Einhaltung von Transport-Verfahren und Transportwegen, Lagerung, Löschung, Umgang mit Anhängen.

Zu den kritischen Punkten zählt dabei vor allem der Umgang mit nicht oder nicht mehr verschlüsselten Mails an Stationen, an denen Vertraulichkeit potentiell gefährdet ist. Das betrifft u.a. Postfächer beim Provider als auch die Mailhandhabung in Postfächern auf eigenen Server- und Client-Systemen.

Wie sichert man also E-Mails dauerhaft, etwa im Sinne der Vertraulichkeit? Die vernünftigste Antwort darauf hatten wir schon im letzten Artikel angesprochen:
Ende-zu-Ende-Verschlüsselung mit OpenPGP - insbesondere dann, wenn neben personenbezogenen auch wirtschaftlich relevante Geheimnisse ausgetauscht werden. Die Option zur OpenPGP-Verschlüsselung bietet deswegen u.a. auch DE-Mail an.

Was, wenn sich der Auftraggeber darauf aber nicht einlässt? Im Einzelfall besteht dann zwar noch die Option, Zip-Anhänge mit AES zu verschlüsseln und sich die Passwörter über einen anderen Kanal mitzuteilen. Bei hoher Mailfrequenz wird dieser Weg aber schnell unpraktisch. Es bleibt die Verschlüsselung des Transportwegs; die Mails selbst landen hingegen unverschlüsselt in Postfächern.

E-Mail-Lagerung beim Provider?

Typischerweise passieren Mails in Richtung auf einen eigenen Server oder Client des Freelancers zunächst einen Provider. Aus Sicht des Kunden und der DSGVO ist also ein Unterauftragnehmer involviert. Gemäß der DSGVO gilt es für den Freelancer also, mit seinem Internet und/oder Mail-Provider einen Auftrags-Daten-Verarbeitungsvertrag abzuschließen.

Man ist als Freelancer versucht, Mails z.T. sowohl in Postfächern beim Provider als auch auf eigenen Servern zu halten. Motive sind : Mobilität und eine Art "Backup"-Politik. Die Frage ist, ob das deinem Auftraggeber so überhaupt recht ist. Ggf. traut dein Auftraggeber deinem Provider ja noch weniger als dir ...

Wird ein deutscher Provider mit Servern in Deutschland und ggf. ISO 27001-Zertifizierung für eine Lagerung von E-Mails auch vom Auftraggeber als hinreichend sicher akzeptiert, sollte man dies in jedem Fall als gemeinsame Vereinbarung in einem Vertrag festhalten.

Im anderen Fall wird dein Auftraggeber den Mailserver des Providers höchstens als Durchgangsstation akzeptieren. Deshalb sollte man die Risiken, die mit einer temporären Zwischenlagerung beim Provider verbunden sind, nennen und vom Auftraggeber akzeptieren lassen. Dazu gehört potentiell auch, dass der Provider ggf. an gesetzliche Vorgaben bzgl. einer Datenvorratshaltung gebunden ist und bestimmte Mail-Daten ggf. auch an Sicherheitsbehörden weitergibt.

Spam-Filterung auf Servern von Drittanbietern?

Eine weitere Station, die eine Mail ggf. auf dem Weg zum eigenen IMAP-Server passiert, mag ein Spam-Filter auf einem Server im Internet sein. Mails passieren bei mir zunächst Amavis, werden auf Viren geprüft und an Spamassassin mit Bayes-Filter weitergereicht. Danach wird für Mails unbekannter Absender aber auch ein Spam-Server im Internet - nämlich ein Razor-Server - für die Spam-Filterung eingebunden.

Hier ist die Frage, was genau passiert: Wird die gesamte Mail für einen Check übermittelt - oder werden wie im Fall von "Razor" nur Prüfsummen übermittelt? Und in welchem Land genau stehen die Spamfilter-Server und welcher Rechtsprechung unterliegen sie?

Auch hier ist eine Vereinbarung mit dem Auftraggeber gefragt, was er denn so zulassen möchte. In der Regel wird eine Übermittlung des Volltextes ausgeschlossen werden müssen. Das erfordert ggf., dass man Mails, die on bestimmten Absendern oder aus bestimmten Postfächern beim Provider stammen, auf eigenen Mail-Gateways absenderspezifischen Filter- und Verarbeitungsregeln unterwerfen muss.

E-Mail-Lagerung auf eigenen Systemen und Verschlüsselung

Irgendwann landen die Mails aber auf eigenen Systemen. Dort gilt meiner Meinung nach vor allem eins:

Die Mails dürfen nicht unverschlüsselt gelagert werden!

Es besteht sonst die Gefahr des Datenklaus bei Einbrüchen oder anderen unerlaubten Systemzugängen - auch im heruntergefahrenen Zustand. Das gilt nicht nur für Laptops; es betrifft auch Desktop- und Server-Systeme im Heim- oder Firmennetz. Denn normalerweise kann ein Freelancer keinen hinreichenden Zugangsschutz zu seinen Systemen gewährleisten. Die schöne Klausel

gemäß oder unter Berücksichtigung des "Stands der Technik",

die im Zusammenhang mit Datenschutz und der DSGVO immer wieder auftaucht, schließt heute wohl Verschlüsselungslösungen als Standard ein. Deren Einsatz beträfe dann eigene Mail-Server und Mail-Client-Systeme gleichermaßen.

Übrigens: Das gilt nicht nur für Mails sondern im Grunde für jede Art vertraulich zu behandelnder Dateien.

Reichen Verschlüsselungscontainer etwa auf Basis von Veracrypt?

OK, E-Mail-Lagerung in verschlüsselter Form. Damit sind wir schon beim nächsten Problem:

Reine Datei-Container allein sind für eine verschlüsselte Lagerung unzureichend, da Programme, mit denen man E-Mails oder deren Anhänge öffnet und verarbeitet, ggf. Backups- oder Kopien in unverschlüsselten Bereichen der Systemplatten ablegen. Typisch sind etwa "bak"-Dateien von Office-Programmen oder Editoren.

Verschlimmert wird die Situation zudem noch durch den Einsatz von SSDs mit Wear Leveling. In die SSD integrierte Controller schaufeln ggf. unverschlüsselte Daten in SSD-Bereiche, die vom OS aus nicht ohne Spezialtools zugänglich sind. Ein Hautpentwickler von Veracrypt warnt etwa explizit vor dem Einsatz des Veracrypt-Containers auf (unverschlüsselten) SSDs.

Um Leckagen über solche Seitenkanäle zu vermeiden, sind deshalb verschlüsselte Partitionen oder verschlüsselte "Volumes" erforderlich, auf denen das Betriebssystem [OS] und seine Applikationen in Gänze arbeiten.

In der Größe flexibel anpassbare "Volumes" werden unter Linux typischerweise über einen LVM-Layer oberhalb von Partition der Festplatten genutzt. Unter Linux muss man sich also auch Gedanken über das Zusammenspiel von LVM und Verschlüsselung machen.

Mehr dazu im nächsten Artikel !