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

Posted on by

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.

nVerschlimmert 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: DSGVO, Freelancer, E-Mails und Umzug KVM-virtualisierter Linux-E-Mail-Server auf verschlüsselte Platten/Partitionen – III

 

MySQL/MariaDB, MyISAM – DROP INDEX, CREATE INDEX oder ALTER TABLE- Statements?

Posted on by

Im Zuge eines datenbank-lastigen PHP-Projektes stolperte ich gerade über ein Problem, bei dem etwa 20 MyISAM-Tabellen um relative viele generierte Datensätze ergänzt werden müssen. Nun greife ich ja schon von Haus aus zu den üblichen Maßnahmen: einer Behandlung möglichst vieler Records in in einem INSERT-Statement oder aber im Fall großer Record-Anzahlen auch zum Umweg über Dateien und LOAD DATA INFILE.

Beim Einsatz von LOAD DATA INFILE ist es klug, auf Indices erstmal zu verzichten. D.h., man wählt folgende Vorgehensweise:

  • Schritt 1: Ggf. TRUNCATE TABLE,
  • Schritt 2: Elimination erforderlicher Indices,
  • Schritt 3: Durchführung von LOAD DATA INFILE,
  • Schritt 4: Aufbau der Indices

Das ist nach meiner Erfahrung immer schneller als ein LOAD DATA INFILE bei gleichzeitigem Update mehrerer aktiver Indices.

Die Performance von “LOAD DATA INFILE” ist dann zwar sehr gut, aber das Löschen/Anlegen von Indices kostet im Vergleich u.U. erheblich (!) Zeit. Also ist man bemüht, auch an dieser Ecke da noch etwas an Performance herauszuholen.

“ALTER TABLE tablename DROP INDEX” statt “DROP INDEX indexname ON tablename”

Mein erster Tipp aufgrund der aktuellen Erfahrungen ist, nicht den bequemen Weg des SQL-Statements “DROP INDEX” zu wählen. Es zeigt sich, dass ein Statement der Art:

ALTER TABLE tablename DROP INDEX indexname

auf MyISAM-Tabellen fast immer um einen spürbaren Betrag schneller ist als

DROP INDEX indexname ON tablename

Man gewinnt mit “ALTER TABLE” zwischen 30% bis 45% an Schnelligkeit.

Was ist mit mehreren Indices?

Als PHP-Entwickler neigt man dazu, bekannte Indices in einem Loop – also nacheinander – zu löschen. Threading auf der PHP-Seite ist auf den meisten Web-Servern ja nicht gegeben. Es geht dennoch schneller. Das “ALTER TABLE” Statement bietet nämlich die Möglichkeit, mehrere zu eliminierende Indices anzugeben:

ALTER TABLE tablename DROP INDEX indexname1, DROP INDEX indexname2, DROP INDEX indexname3, …

Und siehe da, in einem Testbeispiel ging die Zeit in einem Testbeispiel mit einer kleineren Tabelle mit drei Indices von 0,14 Sek auf 0,072 Sek runter. Das sind in meinem Fall dann also nochmal ca. 45% Reduktion. Ich erkläre mir das in meinem Fall so, dass der Datenbankserver dabei 2 Prozessor-Cores einsetzen kann.

Wie sieht es bei CREATE INDEX aus?

Auch das Aufbauen der Indices geht mit

ALTER TABLE tablename ADD INDEX indexname1, ADD INDEX indexname2, ADD INDEX indexname3, …

deutlich schneller als mit einem “Create Index”-Statement.

Merke:
Benötigt man optimale Performance beim Löschen oder beim Aufbau von Indices, so sind “ALTER TABLE”-Statements den klassischen “Drop Index”- oder “CREATE INDEX”-Statements vorzuziehen. Das gilt im besonderen bei MySQL/MariaDB-Datenbankservern mit mehreren Prozessorcores.

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

Posted on by

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.

Firefox unter Linux – Cache reaktivieren nach Update auf Quantum

Posted on by

In bestimmten Testphasen von Weblösungen stelle ich mit Hilfe von Add-Ons oder auch über die in FF integrierten Developer-Tools öfter den Cache meines Lieblingsbrowsers Browsers ab. Im alten Firefox (etwa der unter Opensuse Leap 42.3 ausgelieferten FF-Version 52.8 ESR) gab es im Add-On “Web Developer” lange Zeit eine Möglichkeit zum dauerhaften Ab- und Anstellen des FF-Caches. Diese Möglichkeit bietet selbiges Add-On unter Quantum nicht mehr.

Bei einem Update auf Firefox Quantum unter Linux hatte sich die vorher gewählte Einstellung zur Deaktivierung des Caches im alten Firefox (Vers. 52.8, ESR) aber irgendwie verselbständigt:

Nach dem Update auf Quantum wurden keine Dateien mehr aus dem Cache gezogen – die Netzanalyse in den FF-eigenen Entwicklertools zeigte ein permanentes Nachladen aller Seitenelemente an. Das führt beim Wechseln zwischen den Seiten einer Web-Site, bei denen größere Hintergrundsbilder angezeigt werden, typischerweise zu spürbaren Verzögerungen und ggf. zu Flacker-Effekten. An diesen Effekten haben wir gemerkt, dass etwas nicht mehr stimmte.

Eigentlich wäre das auch OK – schließlich hatte ich die Einstellung ja selbst gewählt.
Irritierend ist aber, dass man in keinem Entwicklertool irgendwo eine Information zum dauerhaft deaktivierten Cache sehen würde. Mit den in FF integrierten Entwickler-Tools (unter dem Menü “Extras >> Web-Entwickler …” findet man etwa im Bereich der “Netzwerkanalyse” eine Möglichkeit, den Cache temporär ab- und wieder anzuschalten. Eine Abschaltung für den gesamten Zeitraum, in dem man die Entwickler-Toolpalette nutzt, bietet auch der dortige Punkt “Werkzeugkasten-Einstellungen”. Diese Einstellungen sind aber sitespezifisch wie temporär und verschwinden spätestens mit dem Schließen des FF-Developer-Werkzeugkastens.

Leider zeigten die genannten Werkzeuge nach dem Update auf Quantum nicht an, dass der Cache deaktiviert war. War er aber. Wegen der Einstellmöglichkeiten und der zuletzt getroffenen Wahl unter der alten FF-Version.

Die Behebung dieses Problems ist einfach, wenn man weiß, wo man zu suchen hat:

Man öffne die URL “about:config“. Dort gibt man dann im Suchfeld den String “browser.cache.*.enable” ein. In meinem Fall ergab die Suche 5 verschiedene Einstell-Optionen:

browser.cache.disk.enable – browser.cache.disk.smart_size.enabled – browser.cache.memory.enable – browser.cache.offline.enable – browser.cache.offline.insecure.enable

Bei mir waren die Werte für “browser.cache.disk.enable” und “browser.cache.memory.enable” leider auf “false” gesetzt. Man stelle diese Werte auf “true” um – und schon funktioniert der FF-Cache wieder!

Für das temporäre Abschalten nutzt man die Optionen im FF-eigenen Entwickler-Werkzeugkasten. Mir reicht diese Möglichkeit zum temporären Abschalten in der Regel für das Testen von Webseiten.

Leider gibt es hier unter Quantum wohl noch Bugs: Die Kuchendiagramme des Punktes “Netzwerkanalyse starten” weisen bei vielen Seiten aus meiner Sicht fehlerhafterweise nicht aus, was unter Nutzung des Caches passieren würde. Angezeigt wird dort für bestimmte Sites “Antworten aus dem Cache:0”. Obwohl die reguläre Darstellung der Downloadzeiten für die Seitenelemente mittels “Balkendiagrammen” die Nutzung des Caches mit korrekten Werten ausweist.

Dennoch viel Spaß weiterhin mit FF.

DSGVO, Datenschutz – und manche verdienen mit – ohne das Richtige zu leisten …

Posted on by

Meine Leser wissen, dass mir Datenschutz ziemlich wichtig ist. Aber manchmal könnte man sich die Haare raufen. Da gibt es endlich eine im Kern vernünftige Vorgabe des Gesetzgebers (nämlich die DSGVO) – und schon wird es von einer bestimmten Art von “Datenschützern” verdreht und missbraucht …

So erlebe ich gerade bei einem Kunden, den wir vor einer Weile auf die DSGVO aufmerksam gemacht haben, eine Art panikartiges Verhalten – nicht durch den Kunden selbst, sondern durch dessen externen “Datenschutzbeauftragten”. Es geht um die Erstellung von HTML-/CSS-Codes für statische Webseiten ohne Cookies – mit einer Ausnahme, nämlich Google Analytics. Das hatten/haben gar nicht wir zu verantworten. Vielmehr hat der Kunde auf einer Seite die Einbindung einer Google-Maps-Lagekarte gemäß der technischen Vorgaben von Google verlangt. Der Kunde hat einen klassischen Web-Hosting-Vertrag bei einem ISO 271001-zertifizierten Provider. Alles bestens. Wir erstellen Webseiten-Codes für statische (!) Seiten nach fachlicher Vorgabe und liefern die dem Kunden auftragsgemäß zu. Aus technischer Sicht ziemlich langweilig.

Nun sollen wir gemäß des besagten externen Datenschutzbeauftragten aber einen ADV-Vertrag (Auftragsdatenverarbeitungs-Vertrag) abschließen, weil “wir und nicht (!) der Provider die Web-Seite pflegen würden und durch die Webseite IP-Daten erfasst würden”.

Da hat wohl jemand was in den falschen Hals bekommen. Leider erweist sich selbiger “Datenschutzbeauftragte” als beratungsresistent.

Ihr wisst schon – ADV-Verträge, das sind die Verträge, bei denen es um die Verarbeitung personenbezogener Daten durch Dienstleister im Auftrag eines Auftraggebers geht. Zielvorstellung von zugehörigen Musterverträgen ist (übrigens ganz im Sinne einer Lieferanten-Einbindung in Datenschutz und Security) die Erfassung der Datenart, der Kreis potentiell betroffener Personen, der Kritikalität der Daten, der Reichweite der Bearbeitungsschritte, etc.. Typischerweise werden zweifache Controller (einer auf AG- und einer auf AN-Seite) eingesetzt, Datenschutzbeauftragte benannt und technische Maßnahmen zum Schutz der Daten vereinbart. Pönalen werden für den Fall angedroht, dass der Auftragnehmer mit dem ihm überantworteten Daten Missbrauch betreiben sollte. Alles gut und richtig so.

Ziel der ganzen Geschichte sind in erster Linie Auftragnehmer, die sich für Auftraggeber mit elektronischen Diensten und deren Wartung/Pflege befassen müssen, bei denen z.B. Kundendaten, Bankdaten, Personaldaten etc. erfasst werden. In diesem Umfeld ist das auch alles völlig berechtigt. Das betrifft potentiell Pfleger von Web-Shops, manchmal aber auch Blogs, Personalabrechnungssysteme, Hosting-Provider, etc..

Worum aber geht es in unserem Fall?
Wir erstellen wie gesagt im Zuge von Einzelaufträgen statischen (!) HTML/CSS-Code für ein paar Webseiten nach Vorgaben des Kunden. (Ausnahme: Das kleine Google Analytics-Script für die Maps-Karte). Die einzigen “personenbezogenen Daten”, mit denen wir dabei direkt zu tun hatten/haben, sind dabei die Daten, die im Handelsregister zur Firma veröffentlicht sind und auf den statischen Seiten wiedergegeben werden. Die Zulieferung der von uns erstellten HTML/CSS-Dateien kann von uns per Mail und zip-Datei erfolgen. Wir müssen die nicht mal auf die gehosteten Server hochladen. Mit dem Hosting-Vertrag unseres Kunden haben wir weiter nichts zu tun.

Nun hat der externe Datenschutzbeauftragte aber brav gelernt, dass der Hosting-Provider Zugriffsdaten bzgl. seiner Web-Server und auch bzgl. die Webseiten des Kunden erfasst – u.a. IP-Adressen der Besucher. Wie jeder Hosting-Betreiber halt, der einen ordentlichen Job macht. Wobei gerade der in diesem Fall relevante Provider erfasste IP-Adressen für seine Kunden nur begrenzt und nur verfälscht bereitstellt. Gelernt hat der “Datenschutzbeauftragte” auch, dass Google Analytics womöglich noch mehr Daten sammelt.

Wir haben den Datenschutzmenschen
deswegen schon beim ersten Kontakt darauf aufmerksam gemacht, dass sein und unser Kunde deshalb (aber nicht nur deshalb; man denke etwa an die Mailaccounts) wohl einen ADV-Vertrag mit dem Webhosting-Provider und auch Google braucht. Und dass es entsprechende Hinweise und Erläuterungen in der zu erstellenden Datenschutzvereinbarung für die Web-Site unseres gemeinsamen Kunden geben muss.

Statt dessen will er aber nun einen ADV-Vertrag mit uns, weil ja wir die “Website pflegen würden”. Das sei vom EuGH so geregelt. Und der gute Datenschutz-Mann bezieht sich dabei ausdrücklich auf die ggf. vom Provider und von Google Analytics erfassten IP-Adressen ….

Man fasst es ja nicht! Wir pflegen erstens gar nichts. Wir liefern beim Kunden HTML- und CSS-Code nach Vorgabe ab. Wir können zweitens auf die Elemente des Hosting-Vertrages, die Webserver und auf Log-Daten des Providers nicht zugreifen. Wir wollen das auch gar nicht. Wir haben auch keine Google Analytics Account für die Website unseres Kunden.

Und nun braucht es trotzdem wegen eines Web-Providers, zu dem wir nicht mal Zugang haben, und wegen von Google Analytics erhobenen IP-Adressen einen ADV-Vertrag mit uns? Wo wir von Google Analytics abraten?

Für diese Art von Wahnsinn und technischem Unverstand kann nicht mal Google etwas …

Ich meine: Hier versuchen Leute mit der Not von Kunden in geradezu halsbrecherischer Weise Geld zu verdienen. Leute, die mich kennen, wissen, dass ein ADV-Vertrag mit mir eine fachlich und technisch ausgefeilte Sache werden würde, die sicher mehr als 15 Seiten Vertragstext erfordern würde. Wieviele Stunden würde der externe “Datenschutzbeauftragte” wohl für den Erstellungsmarathon zu welchem Satz abrechnen? Und welchen Sinn hätte im vorliegenden Fall ein solcher ADV-Vertrag für den Kunden?

Wir hätten ja verstanden, wenn der “Datenschutzbeauftragte” aus grundsätzlichen Erwägungen eine Verschlüsselung des künftigem E-Mail-Verkehrs mit unserem Kunden verlangt hätte. Bieten wir natürlich auf OpenPGP-Basis an. Und ggf. eine Lagerung von Vorgabetexten für kommende Webseiten in irgendwelchen Crypto-Containern, falls es denn dabei den jemals um hochsensible Firmeninformationen gegangen wäre. Was alles nicht der Fall ist. Aber nein – er will einen ADV-Vertrag mit uns wegen eines Providers, der nicht unserer ist, und Google Analytics, die IP-Adressen sammeln.

Übrigens: Zu den für den Kunden wirklich relevanten Dingen – nämlich dessen ADV-Verträge mit dem Provider, mit Google, ggf. Facebook haben wir noch nichts gehört. Und eine textliche Vorgabe für eine Datenschutzerklärung, für die wir dann eine statische Website erstellen müssten, wobei wir auch alle anderen Seiten wegen des zugehörigen Link neu generieren würden, haben wir noch nicht bekommen. Sind ja noch 10 Tage Zeit …

Herr, bitte schmeiß mehr Hirn vom Himmel … bitte gleich … vor dem 25.05.2018!

Ein Einzelfall? Schreibt mir doch per Mail oder über Xing, wenn ihr gerade Ähnliches erlebt.