Sender Policy Framework – SPF

Dieser Beitrag handelt von SPF (Sender Policy Framework). Mit SPF kann ein E-Mail-Server für den Versand von E-Mails mit einer bestimmten Absender-Adresse autorisiert werden. Damit lässt sich die Reputation eines E-Mail-Versenders wirksam steigern.

E-Mail-Versender können in den Einträgen für die Domain-Namen, den so genannten DNS-Servern (DNS=Domain Name System) hinterlegen, welchen IP-Adressen es gestattet ist, E-Mails in ihrem Namen zu versenden. Dabei kann jede Adresse (lupus@dirkwolf.de) oder auch eine komplette Domain (*@dirkwolf.de) einer oder mehreren IP-Adressen zugewiesen werden. Da die DNS-Server ohnehin abgefragt werden – DNS-Server lösen die für Menschen leichter verständlichen „Klarnamen“ wie www.dirkwolf.de in die für Computer leichter zu verarbeitenden IP-Adressen (5.9.121.204) auf – war es logisch, diese Information dort abzulegen. Der DNS-Server fungiert in diesem Fall also als Autorisierungs-Stelle.

Wird nun eine E-Mail versendet kann der Empfänger abfragen, ob im DNS-Server des Absenders eine Sender Policy Framework-Information hinterlegt ist. Hier zeigt sich schon die erste Einschränkung für die Wirksamkeit von SPF. Der Empänger kann, aber muss die Information nicht abrufen. Zwar beteiligen sich einige der großen Provider, wie zum Beispiel GMX, Microsoft mit Hotmail und outlook.com, web.de, Gmail oder Yahoo daran, andere, wie die Deutsche Telekom mit T-Online lassen SPF allerdings links liegen. Und bei vielen Hostern, die billige Hosting-Angebote unterbreiten, ist das Thema auch nicht beliebt, weil man sich darum dauerhaft kümmern muss.

Findet der empfangende Server eine gültige Information, kann er entscheiden, wie weiter mit der E-Mail umgegangen wird.

Man-in-the-middle-Angriff

Dieser Beitrag behandelt Man-in-the-middle-Angriffe auf Internet-Verbindungen zwischen Server (Website) und Client (Browser).

Bei Man-in-the-middle-Angriffen steht der Angreifer zwischen dem Webserver, der eine Website zur Verfügung stellt und dem Browser, mit dem diese aufgerufen wird. Gelingt es dem Angreifer, beiden vorzutäuschen, dass er der echte Kommunikationspartner ist, kann er nach belieben Daten abgreifen oder manipulieren. Beispielsweise könnte er im Falle einer Verbindung vom Kunden mit seiner Bank den Betrag einer Überweisung und die begünstigte Kontonummer ändern. Oder er könnte, wenn er denn Geheimdienst ist, die Kommunikation abhören und falsche Informationen einstreuen. Der Man-in-the-middle-Angriff ist also sehr ernst zu nehmen.

Man-in-the-middle-Angriffe fallen besonders leicht innerhalb eines Wireless Local Arrea Networks (WLAN). Vor allem öffentliche WLANs, bspw. an Flughäfen, Bahnhöfen oder in Cafés werden dazu genutzt. Dabei wird dem Browser entweder ein falscher Access Point vorgetäuscht oder der Angreifer erlangt Kontrolle über den Router.

Eine weitere Methode des Man-in-the-middle-Angriffs ist das Domain Name Server (DNS) Cache Poisoning. Domains (zum Beispiel https://dirkwolf.de) werden im Internet nicht direkt aufgerufen, sondern müssen über DNS zu den tatsächlich benötigten Internet Protocol-Adressen (IP-Adressen, zum Beispiel 5.9.121.204 für den Server, auf dem https://dirkwolf.de gehostet wird) geleitet werden. Beim DNS Cache Poisoning leitet der Angreifer statt auf die echte IP-Adresse auf eine vom ihm kontrollierte.

Schutz vor Man-in-the-middle-Angriffen bietet grundsätzlich die Verschlüsselung via SSL/TLS. Dazu muss entweder der Nutzer explizit https://… eingeben oder – was definitiv besser ist – der Server leitet alle Anfragen, egal ob https:// oder http://… auf eine verschlüsselte Seite um. Ist das so passiert, vereinbaren der Server, auf dem die Website gehostet ist und der Browser, der die Website aufruft, die Kommunikation verschlüsselt aufzubauen und den gesamten Inhalt nur verschlüsselt zu übermitteln.

Selbstverständlich haben mögliche Angreifer nach Wegen gesucht, auch das zu umgehen. Darauf reagiert die Internetgemeinde mit einer relativ neuen Abwehrmethode, der HTTPS Strict Transport Security (HSTS). Dazu lesen Sie hier mehr.

HTTPS Strict Transport Security (HSTS)

Dieser Beitrag behandelt HTTPS Strict Transport Security (HSTS), eine Methode zur Abwehr von Man-in-the-middle-Angriffen im Internet.

Man-in-the-middle-Angriffe in Internet-Verbindungen sind gefährlich und können teuer werden. Eine Erklärung dazu finden Sie hier.

SSL Stripping

Zu verhindern sind sie grundsätzlich mit einer SSL/TLS-Verschlüsselung. Allerdings haben findige Angreifer Mittel und Wege gefunden, auch die Verschlüsselung in ungeschützten Umgebungen, bspw. in öffentlichen WLANs auszuschalten. Beim so genannte SSL-Stripping werden Access Points eingesetzt, die den Weg der Verbindung hin zu einem Angreifer verändern. Er sitzt nun in der Mitte der Verbindung und täuscht dem Browser vor, der richtige Server und dem Server, der richtige Browser zu sein. Nun lenkt er die vom Server ausgehenden https-Seiten, also verschlüsselte Seiten, um auf http-Seiten, die im Zweifelsfall genauso aussehen, wie die echten. Zwar könnte der Nutzer das an der geänderten Adresszeile erkennen. Dort steht eben nicht mehr https://…, sondern http://… Allerdings sehen sich das wohl die wenigsten Nutzer bei Aufruf jeder Seite wieder neu an. Warnhinweise des Browsers gibt es auch nicht. Denn die gibt der nur aus, wenn eine https-Seite angefordert wird und eine http-Seite ausgegeben wird. Da aber der „Man-in-the-middle“ die Anfrage des Browsers auf seine Seite umgelenkt hat, wird gar keine https-Seite mehr angefordert.

Was kann HSTS (HTTPS Strict Transport Security) daran ändern?

Beim ersten Aufruf einer Website, zum Beispiel einer Online-Banking-Seite teilt der Server dem Browser mit, dass er nur https-Verbindungen mit ihm akzeptieren darf. Außerdem teilt er ihm mit, wie lange er das so halten soll (sinnvoll ist meist ein langer Zeitraum, bspw. ein Jahr). Wenn sich nun bei einer erneuten Einwahl ein „Man-in-the-middle“ zwischenschaltet und versucht, http-Seiten auszuliefern, unterbricht der „echte“ Server sofort die Verbindung. Damit wird verhindert, dass – was leider oft passiert – Menschen trotz Warnungen, dass die Verbindung nun nicht mehr sicher ist, weiter Daten eingeben und versuchen, Transaktionen auszuführen. HTTPS Strict Transport Security bedeutet eben, dass streng auf Sicherheit geachtet wird, indem der Browser eine unverschlüsselte Verbindung zu einer ihm bekannten Website immer zurückweist.

Ein Nachteil von HTTPS Strict Transport Security ist natürlich, dass es, wenn der Nutzer sich erstmals auf eine Seite einwählt und ein „Man-in-the-middle“ schon zwischengeschaltet ist, keinerlei Sicherheit bietet. Allerdings wird sich wohl kaum jemand erstmals mit einer so wichtigen Seite wie dem Online-Banking oder der Einrichtung einer neuen E-Mail-Adresse in einem öffentlichen, ungesicherten WLAN anmelden. Andererseits…

HTTPS Public Key Pinning (HPKP)

Dieser Beitrag handelt von HPKP (HTTPS Public Key Pinning). HPKP verhindert wirksam „Man-in-the-middle“-Angriffe bei mit Zertifikaten geschützten Websites

Eigentlich schützt ein SSL/TLS-Zertifikat wirksam vor dem so genannten „Man-in-the-middle“-Angriff auf eine Website (bzw. auf einen Webserver). Schlecht nur, wenn das Zertifikat korrupt ist, was in den letzten Monaten leider häufiger vorgekommen ist. Da wurden von einigen CAs (Certification Authority; autorisierte Zertifizierungsstelle) Zertifikate ausgestellt für Domains, die dem Antragsteller gar nicht gehörten. Ein Zertifikat wird von einer CA ausgestellt, um dem eine Website aufrufenden Web-Browser zu bestätigen, dass die aufgerufene Domain tatsächlich die ist, die aufgerufen wurde. Niemand kann sich als https://dirkwolf.de ausgeben, außer die von einer CA zertifizierten Website https://dirkwolf.de. Das eine Website zertifiziert ist, erkennt man leicht daran, dass vor allen aufgerufenen Seiten https:// steht. Der Nutzer kann so sicher sein, dass er tatsächlich auf der Website https://dirkwolf.de ist, wenn er diese Domain aufruft. Außerdem werden Daten, die über diese Verbindung ausgetauscht werden, verschlüsselt. Das können bspw. Adressdaten sein, die eingegeben werden, um Infomaterial anzufordern oder die Kommentarfunktion unter diesem Beitrag.

Um dem Problem korrupter Zertifikate zu begegnen, ist nun eben jener neue Standard HPKP eingeführt worden. Ruft ein Nutzer eine Website, die mit HPKP geschützt ist erstmalig auf, wird dem aufrufenden Browser ein so genannter Pin übergeben, in dem zwei Schlüssel abgelegt sind und eine zeitliche Vorgabe. Der erste Schlüssel wird genutzt, um beim nächsten Aufruf zu prüfen, ob es sich tatsächlich um die richtige Website handelt. Hat ein anderer ein Zertifikat für die Domain erworben, nützt das nichts, weil er nicht den richtigen Schlüssel mitliefert, den der aufrufende Browser bei sich gespeichert hat. Der zweite Schlüssel dient als Backup, für den Fall, dass der erste Schlüssel kompromittiert wird. In diesem Fall würde der aufrufende Browser ansonsten die Website nicht mehr anzeigen. Die zeitliche Vorgabe (meist 60 Tage) dient dazu, dem Browser anzuweisen, 60 Tage lang den Schlüssel zu verlangen. Ruft der Nutzer die Website bspw. nach einer Woche erneut auf, beginnen die 60 Tage von vorn. Das sorgt dafür, dass nach einem Wechsel des Zertifikats, bspw. wenn das alte Zertifikat ausläuft, ein reibungsloser Übergang zum neuen Zertifikat gewährleistet wird. In diesem Fall wird einfach der alte Backup-Schlüssel als neuer erster Schlüssel definiert und ein neuer Backup-Schlüssel hinterlegt. Das erfordert jedoch eine saubere Hosting-Leistung, denn wird das beim Einbinden eines neuen Zertifikats vergessen, können alle regelmäßigen Besucher die Website nicht mehr sehen.

Der HPKP-Standard sieht außerdem vor, dass eine URL angegeben werden kann, an die eine Meldung abgesetzt wird, wenn ein Web-Browser den Aufruf einer Website abgelehnt hat, weil ein falscher Schlüssel verwendet wurde. So kann der Website-Betreiber feststellen, dass ein korruptes Zertifikat existiert.

 

 

 

HPKP, dargestellt im Test von ssllabs.com

HPKP ist besonders sinnvoll im Zusammenhang mit (HSTS) Strict Transport Security. Darüber können Sie hier einen anderen Beitrag lesen.

 

Entwicklung des Datenschutzes in Deutschland

Dieser Beitrag behandelt die Entwicklung des Datenschutzes in Deutschland und Europa.

Anfänge der Datenschutzgesetzgebung

Der Schutz personenbezogener Daten ist seit langem in Standes- oder Berufsethiken geregelt. Beispiele sind die ärztliche Schweigepflicht, das Steuergeheimnis, das Postgeheimnis oder auch das Beichtgeheimnis. Erste Überlegungen, Datenschutz in einem Gesetz zu regeln wurden in Deutschland in den 1960er Jahren angestellt. Das Bundesland Hessen hat 1970 das erste Datenschutzgesetz weltweit vorgelegt, der Bund zog 1977 nach. Bereits in diesen frühen Fassungen wurde vor allem auf die automatisierte Verarbeitung von Daten durch Behörden und Unternehmen eingegangen. Aktenmäßig erfasste Daten waren ausdrücklich ausgenommen. Unternehmen wurde die Speicherung, Verarbeitung und Nutzung – hier vor allem: Übermittlung, also Überlassung von Daten für andere, meist zu Werbezwecken – von personenbezogenen Daten ausdrücklich erlaubt, wenn sie sich auf

  1. Namen
  2. Titel, akademische Grade,
  3. Geburtsdatum,
  4. Beruf, Branchen- oeder Geschäftsbezeichnung,
  5. Anschrift,
  6. Rufnummer

beschränkten und nicht mehr als eine „Angabe der Zugehörigkeit des Betroffenen zu einer Personengruppe“ enthielt.

Entwicklung des Datenschutzes in Deutschland und Europa

Bereits wenige Jahre nach der Einführung des BDSG 1977 hat das Bundesverfassungsgericht in seinem berühmten Urteil zur Volkszählung am 15. Dezember 1983 den Grundsatz der „informationellen Selbstbestimmung“ aufgestellt und damit dem BDSG bescheinigt, dass es den verfassungsrechtlichen Ansprüchen nicht genüge. Wieder war es das Bundesland Hessen, das diesen Grundsatz 1986 als erstes in ein Landesdatenschutzgesetz übernahm. Der Bund hat die informationelle Selbstbestimmung erst 1990 ins BDSG eingearbeitet.

Die Richtlinie 95/46/EG

Am 24. Oktober 1995 erließ die Europäische Union die Richtlinie 95/46/EG des Europäischen Parlaments und des Rates. In ihr wird erstmals auf europäischer Ebene der „Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten und zum freien Datenverkehr“ geregelt. Allein die Begründung für die Richtlinie umfasst in 72 Artikeln 4501 Wörter.

„Gegenstand der Richtlinie
(1) Die Mitgliedstaaten gewährleisten nach den Bestimmungen dieser Richtlinie den Schutz der Grundrechte und Grundfreiheiten und insbesondere den Schutz der Privatsphäre natürlicher Personen bei der Verarbeitung personenbezogener Daten.
(2) Die Mitgliedstaaten beschränken oder untersagen nicht den freien Verkehr personenbezogener Daten zwischen Mitgliedstaaten aus Gründen des gemäß Absatz 1 gewährleisteten Schutzes.“

Europäische Richtlinien sind nicht direkt geltendes Recht, sondern müssen innerhalb gesetzter Fristen in nationales Recht umgesetzt werden. In Deutschland wurde die Richtlinie durch das „Gesetz zur Änderung des Bundesdatenschutzgesetzes und anderer Gesetze“ am 23. Mai 2001 umgesetzt. Es bedurfte dazu erst der Einleitung eines Vertragsverletzungsverfahrens, weil die ursprünglich gesetzte Frist von drei Jahre bereits 1998 verstrichen war.

2010 unterlag Deutschland in einem weiteren, 2005 eingeleiteten, Vertragsverletzungsverfahren vor dem Europäischen Gerichtshof (EuGH). Der EuGH urteilte, dass die Bundesländer „staatliche Aufsicht über die Instanzen der Datenschutzkontrolle“ ausübten.

Datenschutznovelle 2009

Eine bedeutsame Änderung für die Werbewirtschaft wurde mit der zweiten Datenschutznovelle am 3. Juli 2009 vom Deutschen Bundestag verabschiedet. Dieser „Novelle II“ genannten Änderung des BDSG gingen jahrelange, teils erbittert geführte Verhandlungen zwischen der Werbewirtschaft und dem Deutschen Bundestag voraus. Hardliner auf Seiten der Datenschützer forderten eine schriftliche Einverständniserklärung für jeden Kontaktversuch eines Unternehmens mit einem potenziellen Kunden. Diese „opt-in“ genannte Regelung galt seit 2004 bereits für telefonische Kontaktanbahnung. Rechtliche Grundlage war hier allerdings nicht das BDSG, sondern das „Gesetz gegen den unlauteren Wettbewerb“. Es zielte vor allem auf am Telefon geschlossene Verkaufsverträge, die in den Jahren zuvor immens zugenommen hatten und zu einer regelrechten Plage wurden.

Die konsequente Anwendung des opt-in-Verfahrens für alle Werbeformen, besonders für die Werbung mit postalisch zugestellten Briefen (Mailings), hätte die Werbewirtschaft vor unlösbare Probleme gestellt. Der letztlich gefundene Kompromiss hat sich in der Praxis durchaus bewährt.

Bedeutsame Änderungen waren vor allem die faktische Aufhebung des Listenprivilegs, die zur Folge hatte, dass die qualitativ beste Quelle für Adressen weitgehend versiegt ist und die Einführung des opt-in-Verfahrens für Mailings, die aber abgemildert werden konnte.

Die Zukunft: Die Datenschutz-Grundverordnung

Mit der am 25. Januar 2012 im Rahmen der EU-Datenschutzreform von der Europäischen Kommission vorgestellten EU Datenschutz-Grundverordnung kommt eine Regelung, die europaweit einheitliche Datenschutz-Standards bringen wird, die für alle Unternehmen und Behörden gelten, die in Europa personenbezogene Daten nutzen, auch wenn sie außerhalb Europas ihren Sitz haben. Im Gegensatz zur Richtlinie 95/46/EG wird die Datenschutz-Grundverordnung unmittelbar geltendes Recht sein. Es bedarf nicht der Umsetzung in nationales Recht. Die EU Datenschutz-Grundverordnung ist am 24. Mai 2016 in Kraft getreten und wird ab dem 25. Mai 2018 angewendet. In Kürze wird es hier einen ausführlichen Artikel über die EU Datenschutz-Grundverordnung geben.

 

Die Sicherheit der eigenen Website testen ssllabs

Dieser Beitrag handelt von ssllabs.com, einer Website zur Überprüfung der Qualität von SSL/TLS-Servern.

Es gibt eine sehr einfache Methode, die Sicherheit der eigenen Website zu testen. Das US-Amerikanische Unternehmen QUALYS stellt ein Forum zur Verfügung, das sich in IT-Sicherheitskreisen hohes Ansehen erarbeitet hat.

ssllabs.com versteht sich als ein nicht-kommerzielles Forum, das die Sicherheit von Websites allgemein verbessern will. Es handelt sich um eine „Sammlung von Dokumenten, Tools und Gedanken zu SSL“ (Text von ssllabs.com). ssllabs.com wird betrieben und unterstützt von dem US-Amerikanischen Unternehmen QUALYS, das professionell Unternehmen zu sicheren Websites verhilft.

Wie hilft ssllabs.com mir?

Was müssen Sie tun, um Ihre Website auf die Sicherheit zu überprüfen? Ganz einfach: gehen Sie auf die Seite https://www.ssllabs.com/ssltest/, geben die URL Ihrer Website (www.meineseite.de) in das Eingabefeld ein und klicken auf „Submit“. Jetzt müssen Sie sich noch ein paar Minuten gedulden, dann erscheint das Ergebnis. Ist es kein A gibt es Handlungsbedarf. ssllabs.com liefert Ihnen die konkreten Gründe, warum Ihre Website nicht so sicher ist, wie sie sein sollte.

Sollten Sie kein SSL/TLS-Zertifikat für Ihre Website eingebunden haben, können Sie sich den Test sparen. Ihre Website ist dann eh nicht sicher.

Wenn alles in bester Ordnung ist, sieht das Ergebnis des Tests auf ssllabs.com so aus:

So sieht ein gutes Ergebnis auf ssllabs. com aus: A+ für dirkwolf.de

Wenn nicht so gut gearbeitet wurde, kann es aber auch so aussehen:

So sieht es aus, wenn sich um die Sicherheit der Website nicht gekümmert wird

Die Noten orientieren sich am amerikanischen Schulnoten-System von A (sehr gut) als Bestnote bis F (ungenügend) als Höchststrafe. Es kommt aber noch viel schlimmer. Denn die Browser-Hersteller bestrafen solch ein Verhalten inzwischen teils völlig zu Recht gnadenlos:

Googles Browser Chrome sagt klar: hier ist nichts sicher!

Der Firefox ist noch rigoroser. Er öffnet die Seite gar nicht

Internet Explorer hingegen scheint es egal zu sein.

Checkliste Verarbeitungsverzeichnis

Aufbau eines Verarbeitungsverzeichnisses nach der DS-GVO

Über das „Verzeichnis von Verarbeitungstätigkeiten“ gibt es viele Schauermärchen im Internet zu lesen. Es sei viel zu kompliziert. Es sei ein Bürokratiemonster. „Die da“ in Europa könnten sich überhaupt nicht vorstellen, wie viele Stunden, ja Wochen man daran arbeiten müsse…

Dabei hilft ein einfacher Blick in das Gesetz, um erstaunt festzustellen, dass das „Verarbeitungsverzeichnis“, wie es vereinfacht genannt wird, genau 8 Einträge pro Tätigkeit verlangt:

  • Der/Dir Verantwortliche und, wenn vorhanden, der/die Datenschutzbeauftragte mit Kontaktdaten
  • Der Zweck der Verarbeitung
  • Die Kategorien der von der Verarbeitung Betroffenen
  • Die Kategorien der personenbezogenen Daten
  • Die Empfänger der personenbezogenen Daten
  • Ob die Daten in Drittländer übermittelt werden und wenn ja, wie dort der Schutzstatus ist
  • Eine eventuelle Löschfrist
  • Ein allgemeiner Hinweis auf die technischen und organisatorischen Maßnahmen

Nach meiner Erfahrung fällt es den Menschen erstaunlich leicht, den Rest des Verzeichnisses selbst in wenigen Minuten zu erstellen, nachdem sie mit mir gemeinsam die ersten zwei Einträge erstellt haben. Das Ausfüllen der wenigen geforderten Zeilen ist dabei meist nicht das größte Hindernis.

Wie lässt sich also die Hürde der ersten zwei Einträge ohne teure persönliche Beratung durch einen Datenschutz-Praktiker nehmen? Die folgende Checkliste soll Ihnen dabei eine praktische Unterstützung sein.

Zuvor sollten wir noch kurz klären, was eigentliche eine zu beschreibende Verarbeitung personenbezogene Daten ist. Denn daran scheitern nach meiner Erfahrung die meisten Menschen, weil ihnen dieser Begriff viel zu Abstrakt ist. Verarbeitungen personenbezogener Daten sind beispielsweise:

  • Der E-Mail-Verkehr
  • Die Personalverwaltung
  • Die Arbeitszeiterfassung
  • Urlaubspläne
  • Telefonlisten
  • Geburtstagskalender
  • Dienstpläne
  • Vertriebsaktivitäten (Telefonische Terminvereinbarung)
  • Auftragsabwicklung (sofern personenbezogene Daten dabei eine Rolle spielen)

Um sich ein Verarbeitungsverzeichnis zu erstellen schlage ich Ihnen vor, dies in Form einer Excel-Tabelle zu tun. In diese tragen Sie den Verantwortlichen ein, dessen Kontaktdaten sowie die entsprechenden Daten eines eventuellen Datenschutzbeauftragten (Grundeinträge). In die Spaltenüberschriften gehören die oben aufgezählten 8 Einträge. Eine Spalte für die Daten der Überprüfungen gehört in jedes Verarbeitungsverzeichnis. Zu den Daten sollten Sie Namenskürzel dazuschreiben, damit später nachvollzogen werden kann, wer die Einträge vorgenommen bzw. überprüft hat. Ans Ende der Tabelle gehört eine Legende dazu.

Zu den einzelnen Einträgen:

  • Der/Dir Verantwortliche und, wenn vorhanden, der/die Datenschutzbeauftragte mit Kontaktdaten
    • Name und Anschrift des Unternehmens/des Vereins/ der Stiftung usw., Daten des/der zuständigen Geschäftsführers/Geschäftsführerin, Name und Kontaktdaten der/des Datenschutzbeauftragten, alle Einträge können oberhalb der eigentlichen Tabelle eingetragen werden
  • Der Zweck der Verarbeitung
    • Der E-Mail-Verkehr
    • Die Personalverwaltung
    • Die Arbeitszeiterfassung
    • Urlaubspläne
    • Telefonlisten
    • Geburtstagskalender
    • Dienstpläne
    • Vertriebsaktivitäten (Telefonische Terminvereinbarung)
    • Auftragsabwicklung (sofern personenbezogene Daten dabei eine Rolle spielen)
  • Die Kategorien der von der Verarbeitung Betroffenen
    • MitarbeiterInnen, MitarbeiterInnen von Lieferanten, Dienstleistern, Kunden, Interessenten. Kunden, Interessierte, Klienten, Patienten usw. (Betroffene)
  • Die Kategorien der personenbezogenen Daten
    • Name, Titel, Anschrift, Sozialversicherungsnummer, Kirchenzugehörigkeit, Arbeitszeiten, Vorlieben, Kundenhistorie usw.
  • Die Empfänger der personenbezogenen Daten
    • Externe Lohnbuchhaltung, Auftragsverarbeiter, Steuerbüro, Banken usw. Jede(r), der/die die Daten für welchen Zwecke auch immer bekommt bzw. Einsicht hat
  • Ob die Daten in Drittländer übermittelt werden und wenn ja, wie dort der Schutzstatus ist
    • Drittländer sind alle Länder außerhalb des Europäischen Wirtschaftraums (EU plus Norwegen, Liechtenstein, Island), siehe dazu meine Ausarbeitung „Drittländerverkehr“
  • Eine eventuelle Löschfrist
    • Wann müssen die Daten gelöscht werden (evtl. beim Steuerberater zu erfragen oder „googeln“.
  • Ein allgemeiner Hinweis auf die technischen und organisatorischen Maßnahmen
    • Hier bitte eintragen, wo die TOM (technischen und organisatorischen Maßnahmen) zu finden sind, siehe dazu meine Ausarbeitung „Technische und organisatorischen Maßnahmen – TOM“

 

 

Checkliste Verarbeitungsverzeichnis

 

  • Excel-Liste erstellen
  • Grundeinträge vornehmen
  • Spalten anlegen
    • Laufende Nummer in die erste Spalte
    • Tag der ersten Eintragung in die zweite Spalte
    • Kürzel der/des Eintragenden
    • 8 Einträge als Spaltenüberschriften anlegen
    • Eine Spaltenüberschrift für die Daten der Überprüfungen
  • Legende für die Namenskürzel unter die Tabelle schreiben
  • Tabelle unter einem „sprechenden Namen“ in ein Datenschutz-Verzeichnis auf dem Server legen
  • Einträge vornehmen (siehe oben „Zu den einzelnen Einträgen)
  • Tabelle, wenn gewünscht, ausdrucken und abheften

Forward Secrecy

Dieser Beitrag handelt von Forward Secrecy, einer Methode, um verschlüsselte Kommunikation direkt nach Ende der Session unbrauchbar zu machen und damit vor späterer Entschlüsselung zu schützen.

Wenn über Sicherheit von Websites gesprochen wird, betrachten wir vor allem das Hier und Heute. Aber das ist nicht alles. Es wird befürchtet, dass in exorbitant großen Mengen verschlüsselte Kommunikation auf den Servern der Geheimdienste der Welt gespeichert wird. Diese kann zwar (hoffentlich) heute noch nicht entschlüsselt werden. Doch ganz sicher arbeiten diverse legale und, vor allem, illegale Organisationen daran, den heute vorhandenen Schutz durch Verschlüsselung zu knacken.

Der Weg dahin ist die Art, wie SSL/TLS-Verbindungen sich verschlüsseln. Jede Internet-SSL-Verbindung beginnt mit einem sogenannten handshake (Händedruck), bei dem beide Seiten – der Web-Browser des Nutzers und der Webserver der angewählten Website – Ihre Fähigkeit zur Verschlüsselung bekannt geben und, wenn das festgestellt ist, sich auf einen (kurzlebigen) Session-Schlüssel einigen . Dabei authentifiziert sich der Server gegenüber dem anfragenden Web-Browser. Neben der Authentifizierung dient der Schlüsseltausch auch zur Verschlüsselung der Kommunikation während der gesamten Session. Die Schlüssel werden anschließend gelöscht. Das Ziel der Schlüsselaustauschphase ist also, beiden Seiten zu ermöglichen, andere zu hindern, an der Session teilzunehmen, also mitzuhören oder ggf. auch zu manipulieren.

Sitzungsschlüssel: Generierung und Austausch

Es gibt mehrere Verfahren zum Schlüsseltausch. Das traditionell verwendete Verfahren nutzt den RSA-Schlüssel des Servers, um den Session-Schlüssel sicher vom Client zum Server zu übertragen. Das ist ein äußerst effizientes Verfahren.

Allerdings kann damit jeder, der eine Kopie des privaten Schlüssels des Servers besitzt, die Session-Schlüssel aufdecken und damit die Session entschlüsseln. Das ist durchaus für einige Sicherheits-Techniken wünschenswert, weil sie ohne das nicht arbeiten könnten.

Mögliche Angreifer verfügen vielleicht heute nicht über den privaten Schlüssel vieler Server. Aber vielleicht verfügen sie später über Techniken, an den privaten Schlüssel zu gelangen und damit im Nachhinein jede gespeicherte, verschlüsselte Kommunikation des Webservers mit allen Beteiligten zu entschlüsseln.

Der Diffie-Hellmann-Schlüsseltausch

Eine Alternative zu dem RSA-basierte Schlüsselaustausch besteht darin, den vergänglichen Diffie-Hellman-Algorithmus zu verwenden. Dieser erzeugt den Session-Schlüssel so, dass nur die an der Kommunikation Beteiligten ihn erhalten. Niemand, auch niemand, der den privaten Schlüssel des Servers besitzt, kann ihn bekommen. Nachdem sie Sitzung beendet ist, zerstören beide Seiten den Session-Schlüssel. Auf diese Weise kann die Session nur noch entschlüsselt werden, wenn der Session -Schlüssel bekannt ist. Diese Funktion wird Forward Secrecy genannt.

Einen Session-Schlüssel zu knacken ist eindeutig viel schwieriger als an den privaten Schlüssel eines Servers zu kommen. Darüber hinaus können Sie mit einem Sitzungsschlüssel nur die eine Session entschlüsseln, mit dem privaten Schlüssel des Servers aber alle Sessions, die auf dem Server laufen.

SSL und Forward Secrecy

SSL unterstützt Forward Secrecy mit zwei Algorithmen, die der Standard-Diffie-Hellman-Methode (DHE) und die angepasste Version zur Verwendung mit Elliptic Curve Cryptography (ECDHE).

 

 

Forward Secrecy dargestellt auf ssllabs.com

DHE ist deutlich langsamer als RSA, weshalb Website-Betreiber dazu neigen, die DHE-Suiten zugunsten der Serverleistung zu deaktivieren. Außerdem unterstützen nicht alle Browser alle notwendigen Suiten.

ECDHE ist fast so schnell wie RSA und damit derzeit die Methode der Wahl.

In der Praxis kann man, um sicher zu sein, sämtliche Kommunikation durchführen zu können, die Server so konfigurieren, dass zunächst ein handshake nach ECDHE erfolgt, wenn das nicht funktioniert, einer nach DHE und wenn der Kommunikationspartner (die anfragende Website) das auch nicht beherrscht, RSA. Sicherheitsbewusste Webmaster verzichten allerdings darauf, auch RSA zu akzeptieren. Da nur veraltete Systeme weder DHE- noch ECDHE-Verfahren unterstützen, sollte hier Konsequenz walten.