Drücke „Enter”, um zum Inhalt zu springen.
Ausprobieren
Online Webseiten-Check
sofort das Ergebnis sehen
Auf meiner Webseite sind externe Links mit dem Symbol gekennzeichnet. Datenschutzhinweise · Wissensartikel

Protokollierung von IP-Adressen in Server Logs: erlaubt oder nicht?

8

Laut Datenschutzhinweisen auf vielen Webseiten werden IP-Adressen in Server Log Files in voller länger gespeichert, und zwar oft angeblich aus Sicherheitsgründen und ohne jeden Anlass. Ob die anlasslose Protokollierung zulässig ist, hängt davon ab, ob es technisch notwendig ist oder ob es mildere Mittel gibt.

Einleitung

Abgrenzung: Der Beitrag betrachtet nur öffentlich zugängliche Server von gewöhnlichen Betreibern, also NICHT von ISPs, Strafverfolgungsstellen usw. Es geht hier also insbesondere nicht um die Fälle, die durch § 172 TKG abgedeckt sind. Eine Rechtsgrundlage gemäß Art. 6 DSGVO, etwa eine Einwilligung, wird als nicht gegeben angenommen (ansonsten wäre die Frage schnell beantwortet).

IP-Adressen sind Netzwerkadressen. Sie sind Teil der Metadaten, die bei jedem Aufruf einer Webseite immer übertragen werden. Diese Metadaten werden gelegentlich auch als Verkehrsdaten oder Verbindungsdaten bezeichnet. Die Bedeutung dieser beiden Begriffe scheint im technischen und im juristischen Kontext unterschiedlich zu sein. Daher verwende ich den Begriff der Metadaten.

IP-Adressen sind laut höchstrichterlicher Rechtssprechung von EuGH und BGH personenbezogene Daten. Das gilt auch für dynamische IP-Adressen, und zwar bereits seit dem Jahr 2016 (EuGH) und 2017 (BGH). Die DSGVO gilt erst seit Ende Mai 2018.

IP-Adressen erlauben es möglicherweise, Angriffe zu erkennen und somit gegebenenfalls die Sicherheit von Servern zu erhöhen. Außerdem kann durch Kenntnis einer IP-Adresse eventuell eine Strafverfolgung stattfinden. Das alles erscheint mir plausibel, wenngleich nicht für jedes beliebige Angriffsszenario. Meine Gesprächspartner, zahlreiche Experten aus IT-Sicherheit und Recht, bestätigen dies.

IP-Adressen sind also nützlich, um die Sicherheit eines Servers zu erhöhen und um Täter zu ermitteln. Die Nützlichkeit ist aber kein Ausschlag gebender Rechtfertigungsgrund.

Die Frage lautet:

Müssen volle IP-Adressen anlasslos von Betreibern von eigenen Servern protokolliert werden, oder gibt es mildere Mittel?

Frage dieses Beitrags.

Dieser Beitrag konzentriert sich also auf Betreiber von Servern. Internet Service Provider (ISP) wie die Deutsche Telekom oder Vodafone sollen hier aus Gründen der Komplexität nicht betrachtet werden.


Update: Der EuGH hatte sogar die anlasslose Vorratsdatenspeicherung für rechtswidrig erklärt, wenn sie zur Aufklärung schwerer Straftaten genutzt werden könnte. Siehe EuGH-Urteil vom 05.04.2022 (Az.: C-140/20).

Selbst Rechtsvorschriften, die präventiv zur Bekämpfung schwerer Kriminalität und zur Verhütung schwerer Bedrohungen der öffentlichen Sicherheit eine allgemeine und unterschiedslose Vorratsspeicherung der Verkehrs- und der Standortdaten vorsehen, sind rechtswidrig.

Meine Formulierung des EuGH-Urteils vom 05.04.2022, RN. 101.

Der EuGH stellt ferner fest, dass es nur zur Verhütung der Bedrohung der öffentlichen Sicherheit und zur Bekämpfung schwerer Kriminalität erlaubt ist, „für einen auf das absolut Notwendige begrenzten Zeitraum eine allgemeine und unterschiedslose Vorratsspeicherung der IP‑Adressen, die der Quelle einer Verbindung zugewiesen sind“ vorzunehmen (Rn. 101 des Urteils). Der EuGH bestätigt somit, nach meinem Verständnis, das, was ich folgend schon früher ausgeführt hatte. Denn private Betreiber von (Web) Servern haben wenig bis nichts mit der öffentlichen Sicherheit zu tun und schon gar nicht etwas mit der Bekämpfung schwerer Kriminalität.


Nun weiter im Text, ohne direkten Bezug zum o.g. EuGH-Urteil, das erst nach Verfassung meines Textes getroffen wurde.

Es geht in meinem Beitrag um folgende drei Bedingungen, die auf einmal zutreffen:

  • ANLASSLOSE (!!!)
  • PROTOKOLLIERUNG (= persistente Speicherung, etwa in Dateien)
  • VOLLER IP-ADRESSEN

Der Zweck ist die Gefahrenabwehr. Strafverfolgung geht Sie und mich nichts an und auch nicht Ihren Server, außer, Sie sind Polizei, Staatsanwaltschaft o.ä.

Bitte verinnerlichen Sie diese Bedingungen, bevor Sie weiterlesen und meinen, Sie können die Frage dieses Beitrags beantworten!

Es geht NICHT um:

  • Anlassbehaftete Protokollierung und/oder
  • nur flüchtig im Hauptspeicher gehaltene Daten und/oder
  • Verwendung anderer Daten als der vollen IP-Adressen und/oder
  • Strafverfolgung durch Behörden, Polizei, Staatsanwaltschaft.

Haben Sie dies verinnerlicht? Dann lesen Sie bitte weiter und melden Sie sich bitte bei mir, wenn Sie der erste sein wollen, der ein konkretes Beispiel für die anlasslose Protokollierung von IP-Adressen nennen kann, das eine Rechtsgrundlage erkennen lässt.

Anlasslos bedeutet, dass IP-Adressen immer protokolliert werden. Anlassbezogen würde bedeutet, dass mit der IP-Adressenprotokollierung erst bei Eintritt eines Ereignisses, wie eines angenommenen Hacker-Befalls oder zur Fehlersuche bei Netzwerkproblemen oder bei einem Anmeldeversuch mit einem Passwort, gestartet wird. Der Anlass gilt erst ab dem Zeitpunkt als gegeben, zu dem er festgestellt oder angenommen wurde. Eine rückwirkende Annahme eines Anlasses ist unzulässig. Denn dann müsste immer protokolliert werden, um später 99 % der Daten zu verwerfen (die dann anlasslos und somit, wie behauptet, rechtswidrig, protokolliert worden wären), nur um 1 % der Daten für den erst später festgestellten Anlass zu verwenden. Ein Anlass kann auch dann als gegeben angesehen werden, wenn ein Automatismus mit einer hinreichend hohen Wahrscheinlichkeit einen Anlass als vorliegend ansieht. Diese hohe Wahrscheinlichkeit kann aber ganz sicher nicht für jeden beliebigen (somit anlasslosen) Zugriff vorliegen (außer, jeder Zugriff auf einen Server erfolgt von einem Hacker). In diesem Beitrag geht es nicht darum, Wahrscheinlichkeitswerte zu diskutieren. Eine dauernde Protokollierung jedenfalls basiert auf einer Wahrscheinlichkeit von null Prozent, dass ein Anlass vorliegt, und ist nicht zulässig, behaupte ich.

Ein Anlass ist ein angenommenes Ereignis. Eine immer stattfindende Protokollierung ist offensichtlich ohne Anlass.

Feststellung.

Ein Anlass wird an anderer Stelle auch als Ereignis bezeichnet. Siehe hierzu das IT-Grundschutz-Kompendium des BSI. Dort findet sich, wenn ich es richtig gesehen habe, kein konkreter Hinweis darauf, dass volle IP-Adressen ohne Ereignis (also ohne Anlass) protokolliert werden müssen. Selbst, wenn dieser Hinweis im BSI Kompendium stehen würde, fehlte das konkrete Beispiel zur Rechtfertigung eines berechtigten Interesses als Rechtsgrundlage gemäß Art. 6 DSGVO.

Ich betrachte zur Beantwortung der Frage, ob IP-Adressen anlasslos protokolliert werden müssen, zunächst den Zweck der IP-Adresse zur Strafverfolgung, danach den zur Absicherung von Systemen.

Strafverfolgung

Ein Server hat nicht die Aufgabe, Strafverfolgung zu betreiben. Auch ein Betreiber eines Servers hat nicht die Aufgabe, Strafverfolgung zu betreiben. Fragen Sie einen Juristen, wenn Sie dies anders sehen.

Somit scheidet der Zweck der Strafverfolgung als Rechtfertigung für die anlasslose Speicherung von IP-Adressen aus.

Strafverfolgung obliegt weder dem Betreiber eines Servers noch dem Server. Somit scheidet dieser Grund als Rechtfertigung für die anlasslose Protokollierung von Netzwerkadressen aus.

Leider scheint es so zu sein, so sinnvoll manchmal möglicherweise ein Hilfssheriff sein mag.

Ein aktuelles Beispiel für eine nützliche, aber dennoch verbotene Datenverarbeitung war die Auswertung einer Kontaktdatenerfassung in einem Restaurant zur Corona-Nachverfolgung. Die Mainzer Polizei suchte nämlich einen Zeugen für einen Todesfall eines Gastes des Restaurants. Dazu nahm die Polizei Daten aus der Luca-App, die der Restaurantbetreiber pflichtgemäß erfasste. Die Polizei kontaktierte daraufhin die Restaurantbesucher, die zur fraglichen Zeit im Restaurant waren. Das war sicher nützlich. Aber es war verboten. Denn die Daten wurden nur zum Zweck des Gesundheitsschutzes erhoben. Die Staatsanwaltschaft ermittelte daraufhin gegen die Polizei und entschuldigte sich bei den rechtswidrig kontaktierten Zeugen.

Ein anderes Beispiel: Sogenannte Krypto-Handys werden oder wurden von Kriminellen gerne verwendet, um sich geheim zu unterhalten. Der Polizei gelang es, die Kommunikation über diese Handys zu entschlüsseln. Diese Art der Beweiserhebung wurde in Frage gestellt (ich glaube, weil kein Gerichtsbeschluss vorlag). Allerdings wurde (nur?) aufgrund der Tatsache, dass es sich um einen Zufallsfund handele, der Fund der Nachrichten in den entschlüsselten Handys als Beweis zugefallen. Es hätte ansonsten sein können, dass dieser nützliche Fund rechtswidrig gewesen wäre und somit nicht als Beweis hätte herhalten dürfen. Das KG Berlin hatte den Fund als Zufallsfund im Sinne des § 100e Abs. 6 Nr. 1 StPO klassifiziert.

Gefahrenabwehr

Die Sicherheit der Verarbeitung ist in Art. 32 DSGVO gefordert. Demnach müssen IT-Systeme so betrieben werden, dass das Risiko von Sicherheitsvorfällen in angemessener Weise reduziert ist. Die Gefahrenabwehr ist allerdings nicht nur eine rechtliche Forderung, sondern sollte ureigenstes Interesse von Verantwortlichen sein.

Beispiele für Sicherheitsvorfälle

Eine rein illustrative Liste mit Beispielen für das, was mir als Sicherheitsvorfall einfällt und nicht nur pauschal mit dem Begriff des Hackerangriffs benannt wird:

  • Denial of Service Attacke (DoS)
  • Distributed Denial of Service Attacke (DDoS)
  • Malware, Ransomware, Viren
  • Erbeuten von Zugangsdaten
  • Umfunktionieren eines Systems zum Zombie-Rechner

Einige der genannten Angriffe finden über Mechanismen wie Session Hijacking, Phishing, Spam-Mails oder Ausnutzen von Exploits/Sicherheitslücken (Beispiel: Log4J) statt.

Die Aufzählung ist sicher nicht vollständig. Sofern ein wichtiges Szenario fehlt, bitte ich um Nachricht (etwa über das Kommentarfeld unten).

IP-Adressen

Jeder Internetzugang basiert auf einer Netzwerkadresse, die auch IP-Adresse genannt wird. Jeder Nutzer hat eine IP-Adresse (die über ein Gerät, wie beispielsweise einen Router, zugeteilt wird). Oft erhalten Privatpersonen eine dynamische IP-Adresse von Ihrem Provider. Diese ändert sich in unregelmäßigen Abständen, manchmal vielleicht auch in regelmäßigen Abständen. Bei kabelgebundenen Internetzugängen scheint der IP-Adresswechsel seltener stattzufinden als etwa bei Zugängen über Telefonleitungen. Bei einem Stromausfall findet wohl auch ein (ungeplanter) Wechsel einer IP-Adresse statt, wie ich selber feststellen konnte. Über einen Reset der Fritz!Box-Verbindung, sofern diese verwendet wird, kann oft ebenfalls eine neue IP-Adresse erhalten werden.

Einige Provider bieten zudem statische IP-Adressen an. Diese werden üblicherweise eher von Geschäftskunden genutzt und weniger von Privatpersonen. Statische IP-Adressen ändern sich im Lauf der Zeit nicht.

Aufgrund des begrenzten Adressraums der IPv4-Adressen findet unter Umständen eine Zuteilung derselben IP-Adresse an mehrere verschiedene Anschlüsse, also Personen, statt. Diese Zuteilung wird technisch über unterschiedliche Ports realisiert. Ein Begriff hierfür ist Carrier Grade NAT (CGN), was in etwa so viel bedeutet wie Netzwerkaufschlüsselung über den Internetzugangsdienstleister.

Der EuGH entschied am 19.10.2016 (C-582/14), dass IP-Adressen als personenbezogene Daten anzusehen sind, wenn eine Ermittlung des Anschlussinhabers im jeweiligen Land der EU rechtlich möglich ist. In Deutschland ist dies möglich, etwa zur Strafverfolgung. Es reicht die objektive Möglichkeit, diese Auskunft zum Anschluss unter Umständen auch erst unter Einschaltung mehrerer Stellen (Telekommunikationsanbieter, Geheimdienst, Polizei…) zu erhalten. Das EuGH gilt auch für dynamische IP-Adressen. Der BGH bestätigte dieses Urteil am 16.05.2017 (VI ZR 135/13).

Anhand einiger konkreter Beispiele möchte ich nun prüfen, ob eine anlasslose Speicherung von IP-Adressen gerechtfertigt sein kann.

Denial of Service Attacken

Bei dieser Art Angriff wird ein Server mit bösartigen Massenanfragen derart bombardiert, dass er zusammenbricht und seine normale Arbeit nicht mehr verrichten kann.

Es ist leicht festzustellen, ob von derselben IP-Adresse zahlreiche Zugriffe innerhalb einer Zeiteinheit stattfanden. Dazu wird jede IP-Adresse im Hauptspeicher des Servers gehalten, also nicht protokolliert und im technischen Sinne nicht abgespeichert . Erfolgt ein Folgezugriff von derselben IP-Adresse, wird ein Zähler um eins erhöht. Erreicht der Zähler für eine IP-Adresse beispielsweise innerhalb einer Minute einen Wert von 200, kann von einem bösartigen Zugriff ausgegangen werden.

Ein Anlass kann eine Rechtfertigung für die Protokollierung einer vollen IP-Adresse sein.

Anlasslos scheint die Protokollierung nicht zulässig zu sein.

Mein aktueller Kenntnisstand.

Ist die Wahrscheinlichkeit für einen bösartigen Angriff hinreichend groß, ist ein Anlass für eine Protokollierung der IP-Adressen gegeben. Erst ab diesem Zeitpunkt muss die IP-Adresse, falls überhaupt, wirklich erst protokolliert werden. So kann diese eine IP-Adresse für zukünftige Zugriffe gesperrt werden.

Distributed Denial of Service Attacken

Bei dieser Art von Attacke, auch mit DDoS abgekürzt, werden Massenanfragen von zahlreichen Rechnern aus auf einen Opfer-Server ausgeführt. Im vorigen Angriffsszenario wurden diese Massenanfragen nur von einem Rechner aus geführt, oder höchstens von wenigen Angriffsrechnern aus.

Verteile Angriffe zeichnen sich insbesondere dadurch aus, dass die Angreiferrechner unterschiedliche IP-Adressen haben. Sperrt der angegriffene Server nur einzelne IP-Adressen, wird er mit dem Sperren vielleicht nicht schnell genug fertig. Denn es gibt ja zahlreiche Angreifersysteme und nicht nur eines, welches es auszuschalten gilt.

Eine Möglichkeit, verteilte Angreifer zu erkennen, ist das weiter gefasste Interpretieren der Angreiferadressen. Hierzu lässt man beispielsweise das letzte Byte einer IPv4-Adresse (=IP-Adresse mit 4 Bytes) weg. Beispiel:

  • Denial of Service
    • Angreifer-IP: 10.20.30.40.
    • Angriff ausschalten: Sperren der IP 10.20.30.40
  • Distributed Denial of Service
    • Angreifer-IPs: 10.20.30.40, 10.20.30.45, 10.20.30.53, 10.20.30.88
    • Angriff ausschalten: Sperren der IP-Bereiche 10.20.30.x oder gar von Zugriffen aus einer geographischen Region, wie etwa einem Land

Um zu erkennen, ob Angreifer mit unterschiedlichen Netzwerkadressen zusammenhängen, können weitere Metadaten ausgewertet werden. Eine IP-Adresse hat insbesondere folgende Merkmale, die beispielsweise über Datenbanken automatisiert festgestellt werden können.

  • Land. Beispiel: Deutschland.
  • Provider. Beispiel: Vodafone.
  • Hostadresse. Für manche IP-Adressen direkt vorliegende Zusatzinformationen. Beispiele: xdsl-87-79-57-01.nc.de, ip-178-11-19-33.hsi05.unitymediagroup.de, p549e3719.dip0.t-ipconnect.de, x4dfc0e22.dyn.telefonica.de, 91-145-240-240.subs.proxad.net
  • ASN: Autonomous System Number. Ein autonomes System ist eine Art Postamt. Vom Hauptpostamt wird ein Datenpaket an das lokale Postamt geschickt, welches es dann vor Ort verteilt. Ein Provider hält mehrere Postämter, also ASNs.
  • Subnetz. Mehrere aufeinander folgende IP-Adressen. Beispiel: 10.20.30.0 bis 10.20.30.255, also 10.20.30.x oder 10.20.30.0/24.
  • Reputation. Wird oft in Form eines Wertes (Score) oder als Negativliste (Black List) geführt.

Zusätzlich zur IP-Adresse existieren zumindest beim Zugriff auf Webseiten weitere Metadaten. Diese sind unter anderem:

  • User-Agent: Browsertyp, Browser-Version, Betriebssystemtyp, Betriebssystemversion. Beispiel: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100203 Firefox/95.0.
  • Im Browser eingestellte Sprache des Nutzers. Beispiel: de,en-US;q=0.7,en;q=0.3
  • Cache-Konfiguration. Beispiel: no-cache (Cache deaktiviert)
  • Referrer: Seite, über die der Aufruf erfolgte (etwa durch Klick auf einen Link. Beispiel: https://dr-dsgvo.de/
  • Aufgerufene URL: Seite mitsamt URL-Parametern, die aufgerufen wurde. Beispiel: https://dr-dsgvo.de/cookiegeddon/?unsinnsparameter=1
  • Inhaltsdaten: Ergeben sich oft aus URL-Parameter (GET) oder der Anfrage (POST). Beispiel: Username=SELECT * from users
  • Zugriffszeitpunkt: Liegt immer vor, auch bei allen anderen Netzwerkanfragen. Schließlich weiß der Empfänger einer Nachricht, wann er sie erhalten hat.
  • Zustellstatus: Erhält der Absender Antworten auf seine Anfragen oder verwendet er eine unerreichbare (weil gefälschte) Absenderadresse?

Diese Daten können, zumindest in Kombination, als personenbeziehbare und somit personenbezogene Daten angesehen werden (vgl. Art. 4 Nr. 1 DSGVO). Würde man diese Daten unverschlüsselt und ungekürzt speichern, hätte man nicht viel gewonnen. Es bietet sich an, diese Daten, sofern sie zur Gefahrenabwehr nützlich erscheinen, zu verschlüsseln. Dieses Verschlüsseln kann über ein mathematisches Verfahren erreicht werden.

Verschlüsselung von personenbezogenen Daten

Ein Verschlüsseln von Daten geschieht derart, dass ein Datenwert mit einem frei wählbaren, geeigneten Schlüsselwert kombiniert wird. Das Ergebnis ist ein Zielwert. Mit einem kryptographischen Hash-Verfahren könnten auch Werte generiert werden, die nicht eindeutig sein müssen. Mehrere verschiedene Eingabewerte könnten also durchaus auf denselben Zielwert abgebildet werden. Die Wahrscheinlichkeit hierfür kann durch Wahl geeigneter Verfahren und Parameter sehr gering gehalten oder faktisch ausgeschlossen werden (sogenannte injektive Abbildung bzw. perfektes Verfahren ohne Kollisionen).

Ein Zielwert ist ein pseudonymes Datum, solange der Schlüsselwert bekannt ist. Hierzu ein Beispiel:

  1. Nutzer X greift mit IP-Adresse A1 auf eine Webseite zu. Die Adresse A1 wird mit dem Schlüssel S1 in den Zielwert H1 überführt.
  2. H1 kann nicht in A1 rückgeführt werden, weil das Verfahren asymmetrisch ist.
  3. Ruft Nutzer X nun aber wieder mit seiner Adresse A1 die Webseite auf, entsteht über S1 wieder der Zielwert H1. H1 war aber schon in der Datenbank gespeichert. Man findet diesen Wert H1 also für einen früheren Zugriffszeitpunkt. Somit ist bekannt, dass Nutzer X jetzt und zum früheren Zeitpunkt die Webseite aufrief. Somit kann H1 in A1 rückgeführt werden.

Mittels zeitlich begrenzt gültiger Schlüssel kann eine temporäre Pseudonymisierung mit anschließender Anonymisierung erfolgen. Hierzu sind Einweg-Funktionen geeignet. Eine Einweg-Funktion erlaubt das Verschlüsseln, aber nicht das Entschlüsseln. Liegt ein Klarwert vor, der zuvor bereits verschlüssel wurde, kann der Klarwert nach dem Verschlüsseln mit dem zuvor verschlüsselten Wert verglichen werden. So kann festgestellt werden, dass der Klarwert bereits zuvor vorlag. Der verschlüsselte Wert kann aber nicht ohne den erneut vorliegenden Klarwert auf den Klarwert rückgeführt werden.

Für recht kurze Eingabewerte muss mit geeigneten Maßnahmen dafür gesorgt werden, dass eine effiziente Entschlüsselung nicht möglich ist. Insbesondere dürfen keine Rainbow-Tabellen verwendet werden. Am besten, das Verfahren ist so ausgelegt, dass solche Tabellen gar nicht anwendbar sind.

Gilt der Schlüssel S1 nur 24 Stunden lang und wird danach vergessen, können alle mit diesem Schlüssel generierten Zielwerte nicht mehr entschlüsselt werden. Somit liegen nach 24 Stunden anonymisierte Daten vor und nicht mehr pseudonymisierte Daten. Dies würde auch einen Schutz gegen Rainbow-Tabellen bedeuten, zumindest nach Ablauf des Schlüssels.

Gefahrenabwehr über Metadaten oder Pseudonymisierung

Die Frage war ja, ob man DDoS Attacken nur abwehren kann, wenn IP-Adressen anlasslos protokolliert werden. Ich behaupte, für die Abwehr von DDoS Attacken ist die Kenntnis der IP-Adressen nicht erforderlich.

Im datenschutzrechtlich nicht optimalen Fall würden IP-Adressen in Form eines pseudonymen Datums mit einem Verschlüsselungsverfahren protokolliert, das womöglich keine Einwegfunktion darstellt. Eine DDoS Attacke zeichnet sich wohl dadurch aus, dass Angreifer schnell hintereinander Attacken fahren. Ein zeitabhängiger Schlüssel liefert also eine Möglichkeit der Pseudonymisierung, die ohne Anlass genutzt werden könnte. Dieses Verfahren wäre in Echtzeit nicht schlechter als die Nutzung voller IP-Adressen. Nur bei retrospektiver Betrachtung wäre es schlechter. Eine rückwirkende Betrachtung ist oft sinnvoll, um Angriffswellen zu analysieren.

Gefahren können leistungsfähiger abgewehrt werden, wenn gekürzte IP-Adressen oder Metadaten zu IP-Adressen gespeichert werden. Welche Metadaten dies nützlicherweise sein können, habe ich oben beschrieben.

Bei DoS- oder DDoS-Attacken können Angreifer problemlos ihre Absenderadresse (IP-Adresse) fälschen. Denn sie sind nicht darauf angewiesen, eine Antwort auf ihre bösartige Anfrage zu erhalten. Der Angreifer würde also wechselnde IP-Adressen verwenden können. Würde man die vollen IP-Adressen speichern, hätte man hier also rein gar nichts gewonnen, zumindest nicht in Echtzeit.

Nur wenige Zugriffe: Angreifer, die nur einmal oder wenige Male auf ein Opfersystem zugreifen, können entweder gar nicht oder anlassbezogen erkannt werden. Ein Anmelden (Login) mit erbeuteten Nutzerdaten kann anlassbezogen mit einem IP-Protokoll versehen werden. Das Ausnutzen einer Sicherheitslücke, wie bei Log4J, über nur einen Zugriff kann nicht durch ein IP-Protokoll verhindert oder ad hoc erkannt werden. So blöd es auch ist, aber die anlasslose Speicherung der IP-Adresse, um einen möglichen Täter zu überführen, ist nicht zulässig. Dashcams in Autos, die permanent und ohne jeden Anlass filmen, sind ebenso wenig zulässig. Schade, aber ist so, auch wenn dadurch der ein oder andere Schuldige leider nicht überführt werden kann. Schreibt ein Angreifer einen Schadcode in ein Formularfeld, um Daten zu erbeuten, kann dies womöglich durch Auswerten der Eingabedaten festgestellt werden. Beispielsweise können so SQL-Injektionen erkannt werden. Weiterhin kann Schadcode unwirksam gemacht werden, indem auf dem Server eine entsprechende Programmierung vorliegt. Das ist leichter gesagt als getan, wie man an der weit verbreiteten Hilfsbibliothek Log4J sah, die effektive Hackerangriffe ohne großen Aufwand zuließ. Allerdings hilft eine protokollierte volle IP-Adresse auch nicht besser, den Angriff zu erkennen, als dies anders möglich wäre (behaupte ich).

Verwenden Angreifer zeitlich halbwegs stabile IP-Adressen, helfen die Metadaten der IP-Adressen in Echtzeit dabei, Angriffe zu erkennen. Außerdem ist mithilfe der Metadaten eine rückwirkende automatisierte oder manuelle Auswertung viel leichter möglich, als wenn nur die volle IP-Adresse gespeichert würde und die Metadaten für eine Angriffsanalyse erst gewonnen werden müssten. Das erste Mal ist immer das erste Mal. Das bedeutet: Bei einer ersten Attacke, die nachträglich analysiert wird, muss das Opfer mühsam die Metadaten für die protokollierten vollen IP-Adressen ermitteln. Außer, die Metadaten wurden direkt protokolliert, am besten ohne volle IP-Adresse. Eine volle Protokollierung von IP-Adressen ohne Metadaten hat also offensichtlich auch technische Nachteile.

Einer Attacke, die immer dieselbe Zielseite (URL) aufruft, kann leicht erkannt werden. Wird eine Zielseite viel öfter aufgerufen als dies normal wäre, könnte von einem Anlass für eine IP-Protokollierung ausgegangen werden. Eine anlasslose Protokollierung wäre hier für die Gefahrenabwehr also nicht notwendig.

DDoS-Attacken, die einem bestimmten Land zuzuordnen sind, finden üblicherweise nicht aus Deutschland statt. In Deutschland haben wir recht gute Rechtsverfolgungsmöglichkeiten. Andererseits könnten Zombie-Rechner für einen Angriff aus dem Inland verwendet werden. Deutsche Webseiten jedenfalls könnten als Angriffe anzusehende Zugriffe aus dem Ausland jedenfalls gut erkennen und blockieren. Das ginge ganz ohne Kenntnis voller IP-Adressen (siehe oben: ASN, Land, Provider). Für Zombie-Attacken hingegen würde eine Analyse der Aufrufe weiterhelfen (Ziel-URLs, Parameter, Frequenz, User-Agent…).

Bestimmte Angriffe könnten weder mithilfe voller IP-Protokollierung noch mit anderen Mitteln wirksam blockiert werden. Über diese Art von Angriffen muss also nicht weiter gesprochen werden, wenn es um die Frage der anlasslosen Protokollierung vollständiger Netzwerkadressen geht. Beispiele für solche Attacken sind:

  • Schadcode: Einem angemeldeten Nutzer wird ein schadhafter Link zugeschickt. Entweder wird für den Mailversand ein Zombie-Rechner genutzt oder eine Proxy oder eine infiltrierte Webseite. Wenn der Hacker besonders dumm ist, nutzt er seinen eigenen Anschluss zum Senden der Mail. Wie auch immer: Im Mail Header ist oft die IP-Adresse des Absenders verankert und muss nicht gesondert protokolliert werden. Unabhängig davon, könnte auch der Erhalt einer E-Mail könnte als Anlass angesehen werden. Bei gehackten Webseiten, auf denen ein Schadcode platziert wird, bringt die IP-Protokollierung im Moment des Link-Anklickens nichts.
  • IP-Spoofing: Angreifer nutzen zufällig generierte Absender-IP-Adressen und Metadaten. Die Antwort erhalten die Angreifer nicht, ihnen geht es nur um eine Schädigung des Opfers durch bösartige Anfragen. Früher (heute auch?) war es Angreifern möglich, Antworten für andere Adressen zu erhalten (Backscatter-Attacke).
  • Erbeutete Zugangsdaten: Die Kenntnis von Zugangsdaten lässt einen Hacker wie einen legitimen Nutzer erscheinen. Höchstens durch auffällige Aktivitäten oder durch andere tiefer gehende Untersuchungen oder gar Hinweise vom eigentlichen Inhaber der Zugangsdaten können derartige Zugriffe entdeckt werden. Liegt ein Zugriff aus dem Ausland oder von einem anderen Gerät vor als es bisher normal war, kann anlassbezogen eine Sicherheitsabfrage (CAPTCHA, Frage nach Geburtsdatum etc.) eingestreut werden. Aber auch hier hilft die Kenntnis der vollen IP-Adresse nicht weiter, jedenfalls nicht weiter als die Metadaten, die zudem eine weiter gefasste Analyse zulassen.

In einer recht losen Übersicht habe ich ein paar Arten von Attacken zusammengestellt. Die Arten überschneiden sich womöglich (DoS ist aus dem Inland oder Ausland möglich etc.). Die Tabelle soll nur einen Überblick geben und ist sicher nicht vollständig.

Art der AttackeErkennung
Übermäßig häufiger Zugriff Konkrete IP-Adresse im Speicher vergleichen.
Denial of ServiceKonkrete IP-Adresse im Speicher vergleichen.
Distributed Denial of ServiceGekürzte IP-Adressen oder Metadaten auswerten.
Einbringen von Schadcode (SQL Injektion o.ä.)Inhaltsdaten gegen
Schlüsselworte und Steuerzeichen prüfen.
Login durch Hacker (erbeuteter Zugang)Konkrete IP-Adresse in Datenbank suchen, wenn die IP-Adressen angemeldeter Nutzer gespeichert werden, oder direkte Protokollierung (Anlass = Login)
Angriff aus dem AuslandMetadaten auswerten, insbesondere Land, ASN, Subnetz.
Angriff aus dem InlandMetadaten auswerten, insbsondere ASN, Subnetz.
IP-SpoofingWenn möglich, die Absenderadresse gegen den als gültig angesehenen Adressrau prüfen, was beispielsweise in lokalen Netzwerken gut möglich ist.
Ggf. hilft Unicast RPF (ist nicht mein Spezialgebiet)
Erkennung von Attacken ohne anlasslose Protokollierung der vollen IP-Adresse.

Nachdem eine Attacke derart erkannt oder als wahrscheinlich vorliegend angesehen wurde, kann (darf) eine anlassbezogene Protokollierung von IP-Adressen stattfinden, sofern diese für die Gefahrenabwehr notwendig ist.

Wird eine IP-Adresse gesperrt, weil sie als Angreiferadresse angesehen wird, bestehen folgende Gefahren:

  1. Die Adresse ist tatsächlich kein Angreifer, sondern wurde zu Unrecht verdächtigt (dies erscheint vor allem bei automatisierten Sperren als möglich).
  2. Die Adresse war gefälscht und gehört entweder zu einem anderen (gutartigen) Anschluss oder zu gar keinem (dann wäre der Effekt einer Sperre gleich null).
  3. Die Adresse gehörte einem Angreifer, wurde mittlerweile aber einem anderen (gutartigen) Anschluss zugewiesen. Dies kann bei dynamischen IP-Adressen immer wieder passieren, aber auch bei Zugriff über das Tor-Netzwerk.
  4. Die Adresse ist durch Carrier Grade NAT mehreren Anschlüssen zugewiesen. Alle Anschlüsse bis auf einen sind somit potentiell gutartig und werden ungewollt ausgesperrt.
  5. Die Adresse repräsentiert eine Proxy. Wird die Proxy-Adresse gesperrt, kann kein Anschluss mehr eine Verbindung über die Proxy herstellen.

Wie zu sehen, ist die Sperre einer IP-Adresse nicht unbedingt die Lösung aller Probleme, sondern kann die Probleme in einigen Fällen noch vergrößern.

Weitere Anlässe, die keine Angriffe sind, können sein:

  • Testzwecke, etwa Fehlersuche, Optimierungen oder Neuentwicklungen
  • Anmeldeversuche über Benutzername und/oder Passwort
  • Eingabe von merkwürdig anmutenden Daten in ein Formular (hier ist nicht unbedingt Schadcode gemeint)

Auf diese Anlässe gehe ich hier nicht näher ein, da es hier um die Frage der anlasslosen Protokollierung geht!

Fazit

Das anlasslose Protokollieren von IP-Adressen zur Gefahrenabwehr erscheint technisch nicht notwendig. Ich sehe keinen Anhaltspunkt für das Gegenteil. Statt voller IP-Adressen können folgende Daten protokolliert werden:

  • IP-Adressbereiche (also Subnetze)
  • IP-Adressblöcke
  • Pseudonyme, wie zeitlich nur begrenzt rückführbare Zielwerte, die nach kurzer Zeit anonym werden
  • Metainformationen zu den IP-Adressen:
    • Land
    • Provider
    • ASN
    • Hostnamen
    • Reputation
  • Metainformationen zur Verbindung
    • Aufgerufenes Ziel (URL o.ä.)
    • Absendermetadaten wie User-Agent oder Cache-Konfiguration
    • Zugriffszeitpunkt
    • Erreichbarkeit der Gegenstelle

Wenn hingegen ein Anlass vorliegt, kann die vollständige Protokollierung der IP-Adresse gerechtfertigt sein. Beispiele für solche Anlässe könnten sein:

  • Übermäßig häufiger Aufruf durch eine Quelle
  • Abnormales Nutzerverhalten
  • Abnormale Aufrufe (etwa ungewöhnliche URL-Parameter oder nicht existente Adressen)
  • Verdächtige Metadaten (Beispiel: Zugriffe aus Land X oder von Subnetz Y)
  • Mehrfache Unzustellbarkeit der Antwort
  • Fehlersuche (Beispiel: eigene Zugriffe protokollieren, um Netzwerkfehler zu finden)

Es mag Unterschiede in der Beurteilung der Bedrohungsszenarien bei kleinen und großen Netzwerken bzw. kleinen und großen Webseiten geben. Dass hieraus ein relevanter Unterschied für die Fragestellung aus diesem Beitrag entsteht, kann ich jedenfalls aktuell nicht erkennen und freue mich über jede Rückmeldung.

Übrigens ist das Abschicken einer Meinungsäußerung auf einem Meinungsportal kein Grund für das Anlegen eines Eintrags im Webserver-Logfile mit IP-Adresse. Vielmehr wird man die Meinungsäußerung, möglicherweise samt IP-Adresse des Absenders, in einer Datenbank abspeichern.

Anfangs hatte ich geschrieben, es geht nur um eigene Server, nicht um Internetzugangsanbieter (ISPs). Ob ISPs zur Abwehr mancher Gefahren unbedingt und anlasslos die volle IP-Adresse protokollieren müssen, wage ich bis auf Weiteres zu bezweifeln, auch wenn es bei ISPs schon eher sein kann, dass diese Zweifel unbegründet sind. Gleiches kann wohl über Content Delivery Networks (CDNs) gesagt werden. Sofern CDNs anlasslos volle IP-Adressen protokollieren, muss das vom CDN-Anbieter kommuniziert werden. Mir ist von Akamai bekannt, dass diese anlasslose Protokollierung stattfindet. Deshalb wurde der Einsatz des Dienstes Cookiebot untersagt, der Akamai Server einsetzt.

Die anlasslose Protokollierung vollständiger IP-Adressen durch Betreiber von Servern zur Gefahrenabwehr ist technisch nicht notwendig.

Mein Kenntnisstand bis zum Beweis des Gegenteils.

Sofern Sie anderer Meinung sind, sehe ich zwei Möglichkeiten:

  1. Sie können ein konkretes, nachvollziehbares Beispiel nennen. In diesem Fall prüfe ich das Beispiel gerne und ändere meine Meinung, wenn Ihr Beispiel es hergibt.
  2. Sie können kein konkretes Beispiel nennen. In diesem Fall sollten Sie Ihre Meinung ändern, ob Sie es wollen oder nicht, denn die Meinung wäre haltlos und unbegründet.

Bitte schreiben Sie mir, wen Sie ein konkretes Beispiel kennen, dass für den Betreiber eines Servers relevant sein könnte. Ich rufe erneut in Erinnerung, dass es um die Frage der anlasslosen Protokollierung geht, nicht um die der Protokollierung zu einem erkannten Anlass! Es geht auch nicht um eine Betrachtung der Nützlichkeit, sondern um eine Betrachtung der Notwendigkeit. Als Stichwort sei hier das mildeste Mittel genannt. Und es gibt zahlreiche andere Mittel, die genauso gut geeignet sind wie IP-Adressen, oder sogar besser geeignet sind, um Gefahren zu erkennen oder abzuwehren.

Nicht die Nützlichkeit ist entscheidend, sondern die Notwendigkeit und die Verfügbarkeit milderer Mittel.

Dieser Grundsatz gilt wohl in vielen Bereichen des Datenschutzes.

Hier ein kurzer Abriss zur Nützlichkeit:

VorfallNützlich?Notwendig/Erlaubt?
Steuererklärung unterlassenJa, für alle, die keine Lust dazu habenNein, sagt das Gesetz
BanküberfallJa, für den, der Geld brauchtNein, sagt das Gesetz
Anlassloses Dashcam-Video (mit dauerhafter Speicherung)Ja, um später einem Unfallgegner die Schuld nachweisen zu könnenNein, jedenfalls nicht andauernd (soweit ich weiß)
Anlasslos volle IP-Adressen protokollierenJa, bestimmt für vieleNein, behaupte ich in diesem Beitrag
Nützlichkeit versus Notwendigkeit

Ebenso geht es nicht um Strafverfolgung, da diese nicht Sache eines Betreibers eines Servers und schon gar nicht Sache eines Servers ist (außer, der Server gehört einer für die Strafverfolgung autorisierten Stelle).

Meine Gespräche mit Experten und meine Frage in mehrere Expertengruppen eines sozialen Netzwerks ergaben jedenfalls, dass mir niemand auch nur ein einziges Beispiel nennen konnte, welches meine Haltung widerlegen würde. Auch das BSI konnte mir kein konkretes Beispiel nennen. Statt dessen erhielt ich eine Antwort mit wenig spannenden Informationen. Darin war etwa erwähnt, dass IP-Adressen personenbezogene Daten seien und dass Rechtsgrundlagen aus der DS-GVO zu beachten seien. Dies alles war mir bekannt. Weiterhin wurde auf das BSI Kompendium verwiesen, in dem aber auch kein einziges konkretes Beispiel zu finden war (ich hoffe, nichts überlesen zu haben).

Sofern Sie die volle-IP Adresse von Nutzern Ihres öffentlich zugänglichen Netzwerks immer in Ihren Server Logs speichern: Stoppen Sie dies sofort oder nennen Sie ein konkretes Beispiel zur Gefahrenabwehr oder zu einem anderen legitimen Grund, warum dies Ihnen erlaubt sein soll?

Diese Forderung richtet sich an gewöhnliche Betreiber von Servern, nicht an IPS, Strafverfolgungsbehörden o. ä.

Kürzlich hatte ich festgestellt, dass auf dem FTP-Server eines Kunden ein Server-Protokoll mit vollen IP-Adressen weggeschrieben wird. Daraus stellt sich die Frage, welchen Nutzen diese Information überhaupt für den Kunden haben kann. Der Nutzen dürfte in der Praxis nahe gegen null gehen. Der Kunde kann auf seinem virtuellen Server beispielsweise gar keine DoS-Attacken eindämmen, wenn er die IP-Adressen des Angreifers kennt. Gleiches gilt oft für Managed Server. Dies nur nebenbei, auch wenn es an der eigentlichen Fragestellung nichts ändert.

Übrigens protokolliert der NDR als Verantwortlicher für die Tagesschau-Webseite laut Datenschutzhinweisen die volle IP-Adresse von allen Besuchern. Warum das passiert, wird nicht erklärt. Sicher wird auch der Datenschutzbeauftragte des NDR dies nicht wissen und/oder nicht verraten.

In einem eigenen Beitrag widme ich mich der maximal zulässigen Speicherdauer von Webseiten-Logfiles.

Wer schreibt hier?
Mein Name ist Klaus Meffert. Ich bin promovierter Informatiker und beschäftige mich seit über 30 Jahren professionell und praxisbezogen mit Informationstechnologie. In IT und Datenschutz bin ich auch als Sachverständiger tätig. Mir sind juristische Gegebenheiten nicht fremd. Meine Ergebnisse gewinne ich durch Betrachtung von Technik und Recht. Das scheint mir absolut notwendig, wenn es um digitalen Datenschutz geht. Über neue Beiträge werden Sie informiert, wenn Sie meinen Newsletter abonnieren. Über Ihre Unterstützung für meine Arbeit würde ich mich besonders freuen.
Bitte nutzen Sie bei Verwendung meiner Ergebnisse die Quellenangabe oder verlinken Sie gut wahrnehmbar auf diesen Artikel:
Einen Kurzlink oder eine Bestätigung für Ihre Quellenangabe erhalten Sie kurzfristig auf Anfrage. Ein Teilen oder Verteilen dieses Beitrags ist natürlich ohne weiteres möglich und gewünscht.

Kommentare von Lesern

Die Kommentare drücken die Meinungen der jeweiligen Kommentargeber aus
  1. RA Michael Seidlitz

    BGH, Urteil vom 13. Januar 2011, III ZR 146/10 – Speicherung dynamischer IP-Adressen

    a) Zu den Voraussetzungen für die Befugnis, dynamische IP-Adressen zum Zweck der Entgeltermittlung und Abrechnung gemäß § 97 Abs. 1 Satz 1, Abs. 2 Nr. 1 TKG zu speichern.

    b) Die Befugnis zur Speicherung von IP-Adressen zum Erkennen, Eingrenzen oder Beseitigen von Störungen oder Fehlern an Telekommunikationsanlagen gemäß § 100 Abs. 1 TKG setzt nicht voraus, dass im Einzel- fall bereits Anhaltspunkte für eine Störung oder einen Fehler vorliegen. Es genügt vielmehr, dass die in Rede stehende Datenerhebung und -verwendung geeignet, erforderlich und im engeren Sinn verhältnismäßig ist, um abstrakten Gefahren für die Funktionstüchtigkeit des Telekommunikationsbetriebs entgegenzuwirken.

    http://juris.bundesgerichtshof.de/cgi-bin/rechtsprechung/document.py?Gericht=bgh&Art=en&Datum=Aktuell&nr=54979&anz=1&pos=0&Frame=4&.pdf

    bestätigt von:

    BGH, Urteil vom 03.07.2014, III ZR 391/13

    Online-Dienstanbieter dürfen dynamische IP-Adressen anlasslos zur Erkennung und Beseitigung von Netzstörungen und Fehlern 7 Tage speichern

    http://juris.bundesgerichtshof.de/cgi-bin/rechtsprechung/document.py?Gericht=bgh&Art=en&nr=68350&pos=0&anz=1

    In diesem Zusammenhang ebenfalls interessant folgende hier:

    https://www.daten-speicherung.de/index.php/klage-gegen-surfprotokollierung/

    zu findende Sachverständigengutachten:

    http://www.daten-speicherung.de/wp-content/uploads/Surfprotokollierung_2011-07-29_Sachverst_an_LG.pdf

    http://www.daten-speicherung.de/wp-content/uploads/Surfprotokollierung_2012-04-30_Sachverst_an_LG.pdf

    http://www.daten-speicherung.de/wp-content/uploads/Surfprotokollierung_2012-11-30_Privatgutachten_Bekl_an_LG.pdf

    • Dr. DSGVO

      Danke, Herr Seidlitz. Ich glaube aber, das sind veraltete Angaben:

      Ist unter den von Ihnen genannten Belegen einer dabei mit Datum nach dem EuGH-Urteil von 2016 (“Breyer”), wonach auch dynamische IP-Adressen personenbezogene Daten sind?

  2. RA Michael Seidlitz

    Das Thema ist rechtlich etwas komplexer.

    Dass (auch) dynamische IP-Adressen personenbezogene Daten sind, war eigentlich auch schon unter der Geltung der EU-Datenschutzrichtlinie (Richtlinie 95/46/EG) klar, da es auch dort schon nur auf die Personenbeziehbarkeit ankam.

    Die benannten Sachverständigengutachten stammen aus dem Instanzenzug des Breyer-Prozesses.

    Dort ging es um die Frage, ob eine dynamische IP-Adresse auch für einen Webseiten-Betreiber ein personenbezogenes Datum sei, da dieser einen Personenbezug nur durch Hinzunahme von ergänzenden Daten herstellen könne, die er erst noch von Dritten ( z. B. der Staatsanwaltschaft) bekommen müsse.

    Demgegenüber richtete sich das von mir benannte BGH-Verfahren gegen die Deutsche Telekom AG, für die dynamische IP-Adressen in jedem Falle personenbezogene Daten sind.

    Folglich ging es in diesem Verfahren vorrangig nicht um den Personenbezug von dynamischen IP-Adressen, sondern um die Frage der Zulässigkeit und Höchstdauer der Speicherung von dynamischen IP-Adressen zur Erkennung und Beseitigung von Netzstörungen und Fehlern.

    Wie dem Urteil zu entnehmen ist, hatte der damalige Bundesbeauftragte für den Datenschutz und Informationsfreiheit (Peter Schaar) für die vorgenannten Zwecke – trotz dynamischer IP-Adressen als personenbezoegener Daten – eine 80-tägige Speicherfrist für unzulässig, aber eine siebentägige Speicherfrist für noch angemessenen gehalten.

    Dem folgte das Gericht.

    Auch ist MIR bis heute keine Datenschutzaufsichtsbehörde bekannt, die die Entscheidung des BGH unter Geltung der DSGVO für nicht mehr anwendbar hielte.

    Aber selbstverständlich kann man das heute auch anders sehen.

    • Dr. DSGVO

      Was Datenschutzbehörden sagen, ist keine zivilrechtliche Betrachtung, soweit ich weiß, sondern eine reine Behördenbetrachtung, die dazu noch dem Opportunitätsprinzip unterliegt.

      Was Herr Schaar damals meinte, deckt sich mit dem, was ich damals meinte. Durch meine Untersuchung sehe ich es aber anders. Sofern es keine erwiesene Notwendigkeit gibt, IP-Adressen anlasslos zu protokollieren, kann man m.E. nicht anderer Meinung als ich sein.

  3. Harald M.

    Inhaltlich d’accord.

    Drei Anmerkungen:
    Eine Abgrenzung scheint mir zu fehlen: IP-Adressen von Server-Systemen, die nicht Personen zugeordnet werden können, sollte man – etwa bei Aufrufen von Webservices – auch bedenkenlos loggen dürfen. Wie man feststellt, ob eine IP-Adresse nicht-personenbezogen ist, müsste man beschreiben; aber ich hätte keine Bedenken, die IP-Adresse 172.217.16.67 – die mir “ping google.de” ausgegeben hat – vollständig anlasslos zu protokollieren.

    Der Satz “Allerdings wurde (nur?) aufgrund der Tatsache, dass es sich um einen Zufallsfund handele, der Fund der Nachrichten in den entschlüsselten Handys als Beweis zugefallen.” ist (mir) unverständlich: “der Fund wurde zugefallen”?

    Der Abschnitt “Verschlüsselung …” ist m.E. ein Durcheinander aus Hashing und Verschlüsselung. Wenn das Ziel ist, DOCH (eine Zeitlang) den ursprünglichen Datenwert zu rekonstruieren, dann ist “Verschlüsseln” das richtige – dann ist aber die Aussage “Das Ergebnis ist ein Zielwert, der nicht eindeutig sein muss. Mehrere verschiedene Eingabewerte können also durchaus auf denselben Zielwert abgebildet werden.” zumindest stark irreführend – sowas würde man von keiner Verschlüsselung erwarten; und der Link zum Perfekten Hashing ist dann inhaltlich daneben. Wenn das Ziel nicht Rekonstruktion, sondern nur Matching ist, dann nennt man das eben Hashing und NICHT Verschlüsseln – und dann stimmt der Satz mit der Nicht-Eindeutigkeit und ist auch relevant. Das Wort “asymmetrisch” würde ich da aber nicht nennen, weil es nur mit Verschlüsseln verbunden wird – auch wenn man es prinzipiell auf Hashen anwenden könnte. Wenn die Rekonstruktion garantiert unmöglich sein soll (d.h. die Daten keinesfalls als p.b. gelten sollen), was hier wohl der Fall sein soll, dann muss man ein kryptographisches Hashverfahren verwenden (was aber, noch einmal betont, kein Verschlüsselungsverfahren ist).

    • Dr. DSGVO

      Danke für Ihre Anmerkungen!

      zum 1. Punkt (Abgrenzung(;
      Wahrscheinlich sind wir einer Meinung. Ich hatte öffentliche Server erwähnt, insb. Web Server. “Öffentlich” wird nun noch mal ganz oben im Beitrag ergänzt.

      zum 2. Punkt (Zufallsfund EncroChat):
      Hierzu habe ich folgende Info:
      Das Kammergericht Berlin entschied auf Beschwerde der Staatsanwaltschaft und ordnet die „EncroChat“-Daten als Zufallsfunde im Sinne des § 100e Abs. 6 Nr. 1 StPO ein.
      Das Thema tut hier ach nichts zur Sache. Es ist nur eine Randnotiz zur Illustration.

      zum 3. Punkt (Hashing):
      Ja, kann man besser schreiben. Ich passe den Beitrag an, soweit es mir als Nichtmathematiker möglich ist.

      Danke und viele Grüße

  4. Horst Greifeneder

    Danke für den überaus interessanten Artikel zu Server Logs. Mildere Mittel, nämlich die IP-Anonymisierung, gibt’s ja zumindest bei Apache Webserver. Wobei hier ja auch eine Verarbeitung stattfindet, die aber mE nachvollziehbarer zu rechtfertigen sein sollte.

    Ich erlaube mir abschließend noch einen Hinweis auf eine möglerweiae missverständlich Formulierung im Text zu IP-Adressen: “Jeder Nutzer hat eine IP-Adresse.” Nach meinem Verständnis werden IP-Adressen Geräten zugeteilt. Hinter einer IP-Adresse eines Routers können dann auch mehrere Benutzer stecken.

    • Dr. DSGVO

      Danke für Ihre Rückmeldung, Herr Greifeneder Ja, Sie haben recht mit Ihrem Hinweis. Ein Nutzer hat eine IP-Adresse, die diesem über ein Gerät zugeteilt wird. Der Halbsatz ist sicher sinnvoll. Ich habe den Artikel entsprechend ergänzt.

Schreiben Sie einen Kommentar

Ihre Mail-Adresse wird nicht veröffentlicht.

Nächster Beitrag

Google Fonts: Bequemlichkeit und Ausreden statt Datenschutz