lupus

Author Archives: lupus

Serie „Europäische Datenschutz-Grundverordnung (DS-GVO)“ 1.3

Teil 1 Grundlagen

1.3. Räumlicher Anwendungsbereich

Der räumliche Anwendungsbereich einer Verordnung definiert, wo sie gilt. Der Artikel 3 „Räumlicher Anwendungsbereich“ der DS-GVO zunächst im Wortlaut:

  1. Diese Verordnung findet Anwendung auf die Verarbeitung personenbezogener Daten, soweit diese im Rahmen der Tätigkeiten einer Niederlassung eines Verantwortlichen oder eines Auftragsverarbeiters in der Union erfolgt, unabhängig davon, ob die Verarbeitung in der Union stattfindet.
  2. Diese Verordnung findet Anwendung auf die Verarbeitung personenbezogener Daten von betroffenen Personen, die sich in der Union befinden, durch einen nicht in der Union niedergelassenen Verantwortlichen oder Auftragsverarbeiter, wenn die Datenverarbeitung im Zusammenhang damit steht
    1. betroffenen Personen in der Union Waren oder Dienstleistungen anzubieten, unabhängig davon, ob von diesen betroffenen Personen eine Zahlung zu leisten ist;
    2. das Verhalten betroffener Personen zu beobachten, soweit ihr Verhalten in der Union erfolgt.
  3. Diese Verordnung findet Anwendung auf die Verarbeitung personenbezogener Daten durch einen nicht in der Union niedergelassenen Verantwortlichen an einem Ort, der aufgrund Völkerrechts dem Recht eines Mitgliedstaats unterliegt.

Das bedarf einiger Erklärungen für juristische Laien. Die Verordnung findet also Anwendung, wenn die Verarbeitung personenbezogener Daten im Rahmen der Tätigkeiten einer Niederlassung eines Verantwortlichen in der (Europäischen) Union erfolgt. Und zwar unabhängig davon, ob sie auf dem Boden der Union stattfindet oder nicht.

Was konkret mit „personenbezogen Daten“ und „Verarbeitung“ gemeint ist lesen Sie hier.

„Verantwortlicher“ meint die Person, Behörde, Organisation oder juristische Person (Unternehmen), die über die Mittel und Zwecke der Verarbeitung personenbezogener Daten entscheidet. Der Begriff ersetzt die „Verantwortliche Stelle“ aus dem BDSG (alt).

Absatz 1 sagt also aus, dass der Verantwortliche, der in der Union eine Niederlassung hat (gleichgültig, ob das die Hauptniederlassung, die einzige Niederlassung oder eine Zweigstelle eines großen Unternehmens ist), wenn er personenbezogene Daten verarbeitet, er sich an die DS-GVO halten muss. Dabei ist völlig gleichgültig, ob es sich um Daten von EU-Bürgern oder um Daten von Nicht-EU-Bürgern handelt. Und eben ist es auch unabhängig davon, ob die Server, mit denen das geschieht in Kalifornien oder in Katalonien stehen.

Abs. 2 regelt, dass sich auch jene Verantwortliche, die ihren Sitz nicht in der EU haben, sich an die DS-GVO halten müssen, wenn sie ihre Waren und Dienstleistungen Menschen anbieten, die sich in der EU aufhalten. Das heißt auch, dass die DS-GVO auf alle Menschen angewendet wird; nicht etwa nur auf EU-Bürger. Dafür genügt es aber nicht, dass man einen Dienst oder einen Shop aus der heraus EU erreichen kann. Wenn man beispielsweise die Seite https://amazon.com aufruft, gilt für den Verantwortlichen die DS-GVO nicht. Ruft man hingegen in Deutschland die Seite http:// amazon.de auf, hat sich der Verantwortliche an die DS-GVO zu halten. Festzumachen ist das aber nicht etwa an der Endung „.de“, sondern allein daran, ob sich der Anbieter an Menschen in der EU wendet. Das ist zum Beispiel daran erkennbar, dass die Landessprache verwendet wird, und/oder die Bezahlung in der landesüblichen Währung angeboten wird. Entscheidend ist auch, ob überhaupt in das Land geliefert wird. Es kann also durchaus dazu kommen, dass ein US-Bürger, der während seines Urlaubs in Europa bei Amazon in Europa einkauft, vor dem Missbrauch seiner personenbezogenen Daten durch den US-Konzern Amazon durch die DS-GVO geschützt wird.

Ferner stellt Abs. 2 auch die Menschen unter Schutz, deren Verhalten beobachtet wird, sofern sie sich in der EU aufhalten. Diese Bestimmung ist aufgenommen worden für Unternehmen, die ihre Dienstleistungen nicht diesen Bürgern anbieten, sondern die Menschen beobachten, die sich in der EU befindenden, um diese Informationen an Unternehmen zu verkaufen, die wiederum Waren und Dienstleistungen in der EU anbieten.

Abs. 3 schließt letzte Lücken, indem sie ausdrücklich auch die Gebiete einschließt, die außerhalb Europas liegen, die aber dem Recht der EU unterstehen. Dabei geht es um ehemalige Kolonien, deren Bürger die Staatsangehörigkeit eines europäischen Landes besitzen.

Artikel 3 DS-GVO weitet den räumlichen Anwendungsbereich damit im Vergleich mit dem BDSG erheblich aus. Wann immer es irgendeinen Bezug zur EU gibt, verlangt die EU, die DS-GVO anzuwenden. Es wird interessant sein, zu beobachten, wie das beispielsweise gegenüber US-amerikanischen Internetgiganten durchgesetzt wird.

 

Serie „Europäische Datenschutz-Grundverordnung (DS-GVO)“ 1.2

Teil 1 Grundlagen

1.2. Sachlicher Anwendungsbereich

Der sachliche Anwendungsbereich einer Verordnung definiert, in welchen Fällen sie gilt. Der Artikel 2 „Sachlicher Anwendungsbereich“ der DS-GVO zunächst im Wortlaut:

  1. Diese Verordnung gilt für die ganz oder teilweise automatisierte Verarbeitung personenbezogener Daten sowie für die nichtautomatisierte Verarbeitung personenbezogener Daten, die in einem Dateisystem gespeichert sind oder gespeichert werden sollen.
  2. Diese Verordnung findet keine Anwendung auf die Verarbeitung personenbezogener Daten
    1. im Rahmen einer Tätigkeit, die nicht in den Anwendungsbereich des Unionsrechts fällt,
    2. durch die Mitgliedstaaten im Rahmen von Tätigkeiten, die in den Anwendungsbereich von Titel V Kapitel 2 EUV fallen,
    3. durch natürliche Personen zur Ausübung ausschließlich persönlicher oder familiärer Tätigkeiten,
    4. durch die zuständigen Behörden zum Zwecke der Verhütung, Ermittlung, Aufdeckung oder Verfolgung von Straftaten oder der Strafvollstreckung, einschließlich des Schutzes vor und der Abwehr von Gefahren für die öffentliche Sicherheit.
  3. Für die Verarbeitung personenbezogener Daten durch die Organe, Einrichtungen, Ämter und Agenturen der Union gilt die Verordnung (EG) Nr. 45/2001. Die Verordnung (EG) Nr. 45/2001 und sonstige Rechtsakte der Union, die diese Verarbeitung personenbezogener Daten regeln, werden im Einklang mit Artikel 98 an die Grundsätze und Vorschriften der vorliegenden Verordnung angepasst.
  4. Die vorliegende Verordnung lässt die Anwendung der Richtlinie 2000/31/EG und speziell die Vorschriften der Artikel 12 bis 15 dieser Richtlinie zur Verantwortlichkeit der Vermittler unberührt.

Das bedarf einiger Erklärungen für juristische Laien. Die Verordnung soll also immer dann gelten, wenn personenbezogene Daten ganz oder teilweise automatisiert verarbeitet werden.

Es muss also zunächst geklärt werden, was personenbezogene Daten sind. Es handelt sich dabei um alle Informationen über identifizierte oder identifizierbare natürliche Personen. Natürliche Personen sind in Abgrenzung zu juristischen Personen (Firmen, Behörden, Vereine usw.) schlicht Menschen. Identifizierbar sind natürliche Personen, wenn eine direkte Zuordnung über Name, Kennziffer, Standortdaten, Online-Kennung, besondere Merkmals usw. möglich ist. Es müssen also nicht bspw. der Name und die Adresse bekannt sein, um personenbezogene Daten zu sein. Wenn anhand von Daten ein einzelner Mensch (wieder)erkannt werden kann, handelt es sich um personenbezogene Daten. Selbst wenn die Personenbezogenheit nicht direkt, sondern nur indirekt mithilfe der Daten Dritter hergestellt werden kann, fallen sie unter die DS-GVO. Allerdings muss diese indirekte Möglichkeit auch tatsächlich bestehen; eine rein theoretisch bestehende Möglichkeit, die aber nicht ausgeübt werden kann, reicht dafür nicht aus. Alle Informationen in Wort, Schrift, Bild, Audio oder Video heißt, dass wirklich selbst banalste Tatsachen, wie zum Beispiel, dass die Person zwei Arme hat, personenbezogene Daten sind. Es gibt im Zusammenhang mit personenbezogenen Daten keine irrelevanten Informationen.

Nachdem wir geklärt haben, was personenbezogene Daten sind, wenden wir uns der ganz oder teilweise automatisierten Verarbeitung zu. Auch hier ist zunächst zu klären, was Verarbeitung bedeutet. Artikel 4 Nummer 2 DS-GVO definiert Verarbeitung als „jeden mit oder ohne Hilfe automatisierter Verfahren ausgeführten Vorgang oder jede solche Vorgangsreihe im Zusammenhang mit personenbezogenen Daten wie das Erheben, das Erfassen, die Organisation, das Ordnen, die Speicherung, die Anpassung oder Veränderung, das Auslesen, das Abfragen, die Verwendung, die Offenlegung durch Übermittlung, Verbreitung oder eine andere Form der Bereitstellung, den Abgleich oder die Verknüpfung, die Einschränkung, das Löschen oder die Vernichtung;“. Das ist zweifellos eine Vereinfachung gegenüber der Regelung im Bundesdatenschutzgesetz (BDSG), das in § 11 noch zwischen erheben, verarbeiten und nutzen unterschieden hat. Die DS-GVO schenkt uns die Definition, dass schlicht alles, was mit personenbezogenen Daten passiert „verarbeiten“ ist.

Wenn also eine Verarbeitung personenbezogener Daten ganz oder teilweise automatisiert, das heißt mithilfe von Computern, passiert, soll die DS-GVO zur Anwendung kommen.

Aber auch wenn die Verarbeitung nicht automatisiert erfolgt soll die DS-GVO gelten. Allerdings nur dann, wenn die Daten in einem Dateisystem gespeichert werden oder werden sollen. Hier gilt es nun einen weitverbreiteten Irrtum zu korrigieren. Ein Dateisystem ist gemäß Artikel 4 Nummer 6 DS-GVO „jede strukturierte Sammlung personenbezogener Daten, die nach bestimmten Kriterien zugänglich sind, unabhängig davon, ob diese Sammlung zentral, dezentral oder nach funktionalen oder geografischen Gesichtspunkten geordnet geführt wird;“ Dateisysteme sind also bei weitem nicht nur in Computern zu finden, sondern bspw. auch in Akten. Selbst in Schuhkartons gesammelte Zettel mit personenbezogenen Daten sind ein Dateisystem, wenn sie nach bestimmten Kriterien zugänglich sind. Das ist im Zweifel sogar dann schon anzunehmen, wenn sie einfach in chronologischer Reihenfolge übereinander liegen, schlicht, weil der letzte Zettel immer obenauf gelegt wird. Letzteres könnte bspw. für Messe-Notizen gelten, die immer gleich nach einem Gespräch in einen vorbereiteten Karton gelegt werden. Selbst wenn die Zettel gar nicht streng übereinander gelegt werden, sondern ohne jedes System einfach abgelegt werden, stellen sie ein Dateisystem dar, wenn die Absicht besteht, sie später, in welcher Form auch immer, zu sortieren.

Einige Ausnahmen sieht Artikel 2 allerdings vor. Die wichtigste Ausnahme für alle, die nicht Behörde sind, ist, dass alle durch natürliche Personen zur Ausübung ausschließlich persönlicher oder familiärer Tätigkeiten verarbeiteten personenbezogenen Daten nicht unter die DS-GVO fallen sollen.

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.

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.

>