Systemd: resolved verkauft User u.U. an Google und Cloudflare

Was so alles ans Licht kommt, wenn man Mailinglisten verfolgt. Quasi in einem Nebensatz hat Herr Pöttering kurz mal erklärt, daß systemd gegen die DSGVO verstößt.

Systemd: resolved verkauft User u.U. an Google und Cloudflare

Die DSGVO legt fest, daß alle Systeme die zum Einsatz kommen, in einer datenschutzfreundlichen Voreinstellung daher kommen müssen. Merkt Euch das mal für später.

Hier erstmal ein Auszug aus dem Posting von Herrn Pöttering:

„Also, people would react very allergic if we’d start sending all DNS traffic to google or so. I mean, you can’t believe how pissed people are that we have a fallback in place that if no DNS servers have been configured at all or acquired via DHCP we fall back to Cloudflare + Google DNS servers. Downstream distros (Debian…) tend to patch that fallback out even…“ (Fedora ML, 29.9. 10:19)

Meint auf deutsch:

„Außerdem würden Menschen sehr allergisch reagieren, wenn wir anfangen würden, alle DNS Verkehr zu googlen oder so. Ich meine, Sie werden es nicht glauben, wie sauer die Leute sind, dass wir einen Fallback haben, der, wenn überhaupt keine DNS-Server konfiguriert sind oder über DHCP erworben werden, greifen wir auf Cloudflare + Google DNS-Server zurück. Downstream-Distributionen (Debian…) neigen dazu, das sogar raus zupatchen …“

Oh, ja, da reagieren wir Menschen allergisch drauf, weil das einen Verstoß gegen den Datenschutz darstellt. Die Debinaleute sehen das ganz richtig. Man kann nicht einfach heimlich am Benutzerwunsch oder Adminunvermögen hinweg Daten an Google oder Cloudflare schicken. Wenn das in einer Firma, einem Verein oder einer Behörde passieren würde, dann wäre das ein DSGVO Verstoß der bestraft würde! Scheinbar hat hier jemand die Jahre 2016-2019 verschlafen, als die EU Gerichte mit so etwas aufgeräumt haben. Zur Erinnerung: US Privacy Shield .. zusammengebrochen, Facebook droht mit Rückzug aus der EU, Google & MS verlegen Ressourcen in die EU, damit sie weiter im Spiel bleiben können und dann kommt ein Systemd daher, der die DSGVO unterminiert.

Man stelle sich mal vor, eine größere Firma in der auch Linux als Desktop zum Einsatz kommt und dann steht in irgendsoeiner hart gecodeten .so drin, sie soll Google kontaktieren. Für alle die nicht wissen, was Datenschutz in Firmen heutzutage bedeutet:

  1. Zuerst muß man mal ermitteln wohin was für Daten abfließenund wen das genau betrifft
  2. Dann muß man eine Datenschutzfolgeabschätzung dafür machen
  3. Dann muß man geeignete Schutzmaßnahmen ergreifen.
  4. Das muß als Vorgang mit laufender Nummer in die Datenschutzmappe eingetragen werden.

Jetzt habe ich als Admin also einen DNS Cache für die Firma hingestellt und per DHCP teile ich dieses DNSCache allen PCs mit. Die PCs fragen also meinen DNS Cache und der fragt dann wen auch immer.Das DNS Cache wird also schon eine Reihe von meinen Abfragen so beantworten können, was den Datenschutzvorteil hat, daß der DNS, den das Cache wiederum fragt, nur einen Bruchteil davon sieht und so kein vollständiges Profil erstellen kann. Den DNS Cache ( z.b. nscd ) kann man auch per Round-Robin mehrere andere Server fragen lassen um die Profilbildung weiter zu erschweren.

Der Problemfall

Jetzt funktioniert der lokale DNS aber nicht, weil es ein Update gab, oder die VM abgestürzt ist. Systemd würde jetzt keine gültigen DNS bekommen und Google+Cloudflare fragen. Damit wäre meine komplette Datenschutzabschätzung fürn Arsch. Schlimmer noch ist der Umstand, daß diese Art Datenfluß als Vorgang überhaupt gar nicht in meiner Datenschutzmappe vorkommt. Zum Glück ist das ein minder schwerer Fall, den der Datenschutzbeauftragte selbst regeln kann, indem er den Vorfall in die Mappe einträgt und Maßnahmen ergriffen werden, dies zukünftig zu verhindern.

Sollte aber ein Datenschutzaudit ergeben, daß es diesen Abfluß gibt ohne das das intern gefunden wurde, sieht die Sache schon anders aus. Je nach Umfang könnte die Datenschutzbehörde ein Bußgeld verhängen und das nur weil einer, den keiner in der Firma kennt, meinte schlauer sein zu müssen, als alle anderen. Na danke!

Jetzt kommt der nächste Oberschlaue mit dem Hinweis, daß bei DSL ja eh alle die gleiche IP von der Firma haben und individuelle Profile gar nicht erstellt werden können und außerdem wären das ja keine privaten Domainanfragen. Das fällt bei größeren Firmennetzen seit IPv6 unter „Es war einmal..“ . Wenn ich einen Businesszugang mit einem reinen IPv6 Netz bekommen, habe ich einen ganzen Block zur Verfügung. Dies Netz kann ich direkt an alle Pcs durchreichen, denn dann habe ich kein NAT Problem mehr. Per Firewall kann ich den Direktzugang zu den Pcs sperren, kein Problem und wenn doch mal jemand von außen drauf muß, wären individuelle Freigaben möglich. Das muß man als Admin natürlich auch mit IPv6 nicht so machen, aber es wurde mal so vermarktet, als für IPv6 geworben wurde.

Das die meisten am Arbeitsplatz auch privat surfen, braucht man wohl kaum noch erwähnen.

Die Technisch -Organisatorischen Maßnahmen zum Datenschutz einer Firma ( TOM ) beinhalten alle Maßnahmen die man so als Firma macht und wenn da steht, wir leiten DNS über ein Cache zum minimieren von Profilbildungen, dann kann man da schlecht ein Linux betreiben, daß sich da nicht dran hält, oder seht Ihr das anders? Linux muß also auch in der Datenschutz freundlichen Einstellung daher kommen, was damit einen Einsatz von systemd-resolved ausschließt, da man sich da ja nicht drauf verlassen kann wie man oben sieht.

Update

Ein Leserbrief erreichte mich vorhin. Hier ist der Link, in dem das Fallbackfeature bei Systemd besprochen wird: https://github.com/systemd/systemd/pull/11666

Und gleich noch die Diskussion, wieso CloudFlare DNS besser wären: https://github.com/systemd/systemd/issues/8899

So richtig viel Gegenwind gabs aus der Peergruppe anscheinend nicht.

DS GVO: Email Transportverschlüsselung wird Pflicht sein

Willkommen im Chaos des Datenschutzes. Ich hatte ja schon lange den Verdacht, daß EMails auch nur noch mit TLS übertragen werden dürfen, wenn man zum Datenschutz verpflichtet ist. Dabei habe ich mich aber immer gewundert, wieso das nie in der Presse steht. Jetzt wird sich das hoffentlich hektisch ändern.

Die Meinungen zur TLS Verschlüsselung von Emails

Wie uns Rechtsanwalt Schwartmann auf seiner Webseite wissen läßt, ist ab Freitag aufgrund der Datenschutz Grundverordnung wahrscheinlich eine TLS Verschlüsselung für eingehende und ausgehende Emails Pflicht, sofern man ein Unternehmen betreibt oder aus anderen Gründen zum Datenschutz verpflichtet ist.

Nach Ansicht des Landesbeauftragten für Datenschutz und Informationsfreiheit Nordrhein-Westfalen ist eine Transportverschlüsselung auf jeden Fall erforderlich:
Bezüglich der sicheren Implementierung der Transportebene hat das Bundesamt für Sicherheit in der Informationstechnologie die Technische Richtlinie „BSI TR-03108-1: Secure E-Mail Transport“ herausgegeben.
Unter datenschutzrechtlichen Gesichtspunkten ist diese Richtlinie als Stand der Technik zu betrachten, so dass ihre Umsetzung eine notwendige Voraussetzung für die datenschutzkonforme E-Mail-Kommunikation ist.

Quelle: https://www.rechtsanwalt-schwartmann.de/verschluesselungspflicht/
„(Ende Zitat)

Die Bundesbeauftragte für den Datenschutz und die Informationsfreiheit hat uns heute morgen endlich wissen lassen, daß nur der Einsatz von TLS 1.2 in Frage kommt:

„Inwieweit ein Provider, der die Infrastruktur zur Verfügung stellt, eine Option anbieten muss, die ausschließlich den Empfang von TLS 1.2 transportverschlüsselten E-Mails zulässt, beurteilt sich nach dem gegenwärtigen Stand der Technik.

Der gegenwärtige Stand der Technik ist, daß TLS 1.2 seit 2008 das Maß der Dinge ist. Der Nachfolger TLS 1.3 wird aber bald kommen, da die Planung des Standards kürzlich beendet wurde. Das hält aber gerade den BUND, wo die Information her ist, nicht davon ab, auch heute noch mit TLS 1.0 zu senden 😀 (Böser Dienstleister vom Bundmailserver 😉 )

IMHO

Ich schließe mich dieser Meinung an, da auch ich die DS GVO so interpretiere, daß alle Kommunikationskanäle verschlüsselt sein müssen. Wie einfach das gehen kann, zeigt folgende Anleitung :

Zunächst mal wählen wir im Account unter „Mailserver“ die „EMail-Options“ aus:

Nun aktivieren wir die beiden obersten Punkte:

„Verbindung zum Server benötigt Verschlüsselung“ und „Empfangener Mailserver muß TLS benutzen“

Das war es dann auch schon, jetzt kommen nur noch TLS gesicherte EMails an den Mailserver ran. Damit entspricht das Mailserververhalten dem geltenden Datenschutzrecht.

Wer es ganz genau nehmen will, der müßte auch noch DANE implementieren, da dies in einer BSI Richtlinie zum Thema gefordert wird. Da DANE aber AFAIK noch nicht 100% ausgereift ist, könnte der Teil schwierig werden, was nicht heißt, das einige Provider dies nicht schon implementiert hätten.

Bei Exim ist grade eine passende Diskussion gestartet worden.

Quellenlinks:

https://www.ldi.nrw.de/mainmenu_Aktuelles/Inhalt/Technische-Anforderungen-an-technische-und-organisatorische-Massnahmen-beim-E-Mail-Versand/Technische-Anforderungen-an-technische-und-organisatorische-Massnahmen-beim-E-Mail-Versand.html

https://www.rechtsanwalt-schwartmann.de/verschluesselungspflicht/

https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03108/index_htm.html