La protocole de l'adresse IP dans les journaux du serveur: autorisé ou non ?

Selon les avertissements sur la protection des données présents sur de nombreuses pages Web, les adresses IP sont stockées dans les fichiers journaux serveur en plein texte et souvent sans motif apparent, prétendument à des fins de sécurité. Il est question de savoir si l'enregistrement sans motif est autorisé ou non, c'est-à-dire s'il est techniquement nécessaire ou s'il existe des moyens moins rigoureux.

Introduction

Délimitation: Le présent article ne considère que des serveurs accessibles au public gérés par des opérateurs courants, donc PAS par les FAI, les services de police etc. Il s'agit ici en particulier pas des cas couverts par § 172 TKG. Une base légale conforme à Art. 6 DSGVO, comme une autorisation, est considérée comme non donnée (sinon la question serait rapidement répondu).

Pour éviter les malentendus: la compréhension du concept "motif" est fondamentale ! Il est expliqué dans le texte. La conservation des données à grande échelle s'appelle ainsi, car elle a lieu sans motif, c'est-à-dire toujours!

Les adresses IP sont des adresses de réseau. Elles font partie des metadonnées, qui sont transmises à chaque appel d'une page web. Ces métadonnées sont parfois également appelées données de trafic ou données de connexion. L'importance de ces deux termes semble être différente dans le contexte technique et juridique. C'est pourquoi j'utilise le terme des métadonnées.

Les adresses IP sont, selon la jurisprudence suprême du CJUE et du BGH des données personnelles. Cela vaut également pour les adresses IP dynamiques, et cela depuis 2016 (CJUE) et 2017 (BGH). La RGPD est en vigueur depuis la fin mai 2018.

Les adresses IP permettent peut-être de attaques identifier et ainsi d'augmenter la sécurité des serveurs si nécessaire. De plus, grâce à la connaissance d'une adresse IP, une enquête pourrait avoir lieu. Tout cela me semble plausible, même si ce n'est pas pour tout scénario d'attaque. Mes interlocuteurs, de nombreux experts en sécurité informatique et en droit, confirment ceci.

Les adresses IP sont donc utiles pour améliorer la sécurité d'un serveur et pour identifier les coupables. La Utilité n'est cependant pas un motif de justification décisif.

La question est:

Doit-on que les fournisseurs de serveurs propres enregistrent des adresses IP complètes sans motif, ou y a-t-il des moyens plus doux ?

Question de cet article.

Cet article se concentre donc sur les exploitants de serveurs. Les fournisseurs d'accès à Internet (FAI) comme la Deutsche Telekom ou Vodafone ne doivent pas être considérés ici en raison de leur complexité.

---

Mise à jour: Le juge de l'Union européenne avait même déclaré illégale la collecte de données sans motif, si elle pouvait être utilisée pour éclairer des enquêtes sur des crimes graves. Voir Arrêt du 05.04.2022 (C-140/20).

Les règlements juridiques même qui prévoient à titre préventif la lutte contre des crimes graves et la prévention de menaces graves pour la sécurité publique, en prévoyant une stockage généralisé et sans distinction des données de trafic et des localisations, sont illégaux.

Ma formulation de l'arrêt du Tribunal de justice de l'Union européenne du 05.04.2022, affaire n° 101.

Le juge de l'Union européenne constate en outre que seule la prévention des menaces pour la sécurité publique et la lutte contre les graves infractions pénales permettent d'autoriser «une stockage généralisé et sans distinction des adresses IP, attribuées à la source d'une connexion, pour un temps limité au strict nécessaire» (Rn. 101 de l'arrêt). Le juge de l'Union européenne confirme ainsi, selon ma compréhension, ce que j'avais déjà énoncé plus tôt. En effet, les opérateurs privés de serveurs (Web) ont peu ou rien à voir avec la sécurité publique et encore moins avec la lutte contre les graves infractions pénales.

---

Passons au texte suivant, sans lien direct avec l'arrêt du Tribunal de justice de l'Union européenne mentionné ci-dessus, qui a été rendu après la rédaction de mon texte.

Il s'agit dans mon article de trois conditions qui se réalisent brusquement:

• ANCIENNE LOI SUR LE SÉRIEL (!!!)
• PROTOCOOLISATION (enregistrement persistant, par exemple dans des fichiers)
• TOUTES LES ADRESSES IP

L'objectif est la prévention des dangers. La poursuite pénale ne vous concerne ni moi, et pas non plus votre serveur, à moins que vous soyez police, procureure d'état etc.

Veuillez intégrer ces conditions avant de poursuivre la lecture et de penser que vous pouvez répondre à la question de cet article !

Il ne s'agit PAS de:

• Enregistrement lié à l'occasion et/ou
• Données conservées de manière fugace dans la mémoire principale et/ou
• L'utilisation d'autres données que les adresses IP complètes et/ou
• Répression par les autorités, la police, le procureur de l'État.

Avez-vous compris cela ? Alors, lisez-le encore et faites-moi signe si vous voulez être le premier à citer un exemple concret de la protocole d'adresses IP sans motif qui reconnaît une base juridique.

Inutilement signifie que les adresses IP sont toujours protocollées. Anlassbezogen serait signifier que la protocoller des adresses IP ne commence qu'à l'entrée d'un événement, comme une attaque de hacking ou à la recherche d'erreurs dans les problèmes réseau ou lors d'une tentative d'accès avec un mot de passe, qu'il soit accepté ou non. L'événement est considéré comme donné à partir du moment où il a été établi ou supposé. Il ne peut pas être admis que l'on suppose un événement après coup. Car alors, on aurait toujours dû protocoller pour jeter 99 % des données (qui auraient ensuite été considérées comme anlasslos et donc, comme prétendu, illégales), afin de conserver 1 % des données pour l'événement qui a été établi plus tard. Un événement peut également être considéré comme donné lorsque un automatisme avec une probabilité suffisamment élevée considère que l'événement est réel. Cette probabilité élevée ne peut pas cependant s'appliquer à chaque accès (à moins que tous les accès sur un serveur soient effectués par un hacker). Dans cet article, il ne s'agit pas de discuter des valeurs de probabilité. Une protocoller permanente n'est toutefois basée qu'à une probabilité de 0 % d'avoir affaire à un événement et est donc inacceptable, selon moi.

Un motif est un événement supposé. Une protocole en cours de manière permanente est manifestement sans motif.

Déclaration.

Un motif est également appelé événement ailleurs. Voir à ce sujet le Compendium de la sécurité informatique du BSI (German federal security agency). Là, je n'ai trouvé aucun indice concret sur le fait que les adresses IP complètes doivent être protocollées sans événement (c'est-à-dire sans motif). Même si ce renseignement se trouvait dans le Compendium du BSI (German federal security agency), il manquerait l'exemple concret pour justifier un intérêt légitime en tant que base juridique conformément à l'article 6 de la RGPD.

Je considère d'abord l'utilisation de l'adresse IP pour la poursuite pénale, puis celle pour la protection des systèmes lors de la réponse à la question de savoir si les adresses IP doivent être protocollisées sans motif.

Répression pénale

Un serveur n'a pas pour mission de mener des enquêtes pénales. Même le propriétaire d'un serveur n'a pas pour mission de mener des enquêtes pénales. Demandez à un juriste si vous voyez les choses différemment.

Ainsi, la finalité de l'instruction pénale ne justifie plus la conservation sans motif des adresses IP.

La poursuite pénale ne relève ni du propriétaire d'un serveur, ni du serveur lui-même. Ainsi, cette raison s'élimine comme justification pour la prise de protocole sans motif des adresses réseau.

Malheureusement, il semble que ce soit ainsi, qu'il puisse parfois être raisonnable d'être un adjoint de shérif.

Un exemple actuel d'une traitement des données utile, mais encore interdit était l'analyse d'un recensement de contacts dans un restaurant pour la traçabilité du coronavirus. La police de Mayence cherchait en effet un témoin pour une affaire de décès d'un client du restaurant. Pour cela, la police a consulté des données de l'application Luca, que le propriétaire du restaurant avait collectées de manière obligatoire. La police a ensuite contacté les clients du restaurant qui étaient présents à l'époque en question. C'était probablement utile. Mais c'était interdit. Car les données avaient été recueillies uniquement pour la protection de la santé. Le procureur a donc ouvert une enquête contre la police et s'est excusé auprès des témoins qui avaient été contactés illégalement.

Un autre exemple: Des Téléphones cryptés appelés ainsi, étaient ou sont utilisés par des criminels pour communiquer en toute discrétion. La police a réussi à décrypter les communications effectuées sur ces téléphones. Ce type de preuve a été mis en question (je pense parce qu'il n'y avait pas d'ordonnance judiciaire). Cependant, en raison du fait que c'était un trouvaille fortuite, le fond des messages dans les téléphones décryptés a été considéré comme une preuve. Sinon, cela aurait pu être illégal et donc ne pas avoir été utilisé comme preuves. Le tribunal supérieur de Berlin avait classifié la trouvaille comme un hasard en vertu de l'article 100e, paragraphe 6, numéro 1 du Code de procédure pénale (StPO).

Prévention des dangers

La sécurité de traitement est exigée en Article 32 du RGPD. D'après cela, les systèmes informatiques doivent être exploités de telle sorte que le risque d'événements de sécurité soit réduit dans une mesure raisonnable. La prévention des dangers n'est cependant pas seulement une exigence juridique, mais devrait être un intérêt propre et naturel des responsables.

Exemples d'incidents de sécurité

Une liste purement illustrative avec exemples de ce qui me vient à l'esprit comme incident de sécurité et non seulement qualifié de cyberattaque:

• Denial of Service Attacke (DoS)
• Distributed Denial of Service Attacke (DDoS)
• Malware, Ransomware, Viren
• Les données de connexion ont été volées
• Réconversion d'un système en ordinateur zombie

Certains des attaques mentionnées se produisent par le biais de mécanismes tels que la capture de session, le phishing, les e-mails spam ou l'exploitation d'exploits/ failles de sécurité (exemples: Log4J).

La liste n'est pas exhaustive. Si un scénario important manque, je vous prie de me faire part d'une notification (environ via le champ de commentaires ci-dessous).

IP adresses

Tout accès à Internet repose sur une adresse de réseau appelée également adresse IP. Chaque utilisateur a une adresse IP (qui lui est attribuée par un appareil, comme par exemple un routeur). Souvent, les particuliers reçoivent une adresse IP dynamique de leur fournisseur. Cette dernière change à des intervalles irréguliers, voire réguliers. Lorsque l'on accède à Internet via câble, le changement d'adresse IP semble moins fréquent que par exemple lorsqu'on utilise les lignes téléphoniques. Lors d'un coup de froid, il est probable qu'il y ait également un (imprévu) changement d'adresse IP, comme je l'ai pu constater moi-même. En réinitialisant la connexion Fritz ! Box, si elle est utilisée, on peut souvent obtenir une nouvelle adresse IP.

Certains fournisseurs proposent également adresses IP statiques. Elles sont généralement utilisées par des clients professionnels et moins souvent par des particuliers. Les adresses IP statiques ne changent pas au fil du temps.

En raison de la plage limitée des adresses IPv4, il peut arriver que plusieurs utilisateurs différents soient attribués la même adresse IP, ce qui est réalisé techniquement par le biais de différents ports. Un terme pour cela est NAT de grade de transport (CGN), ce qui signifie en gros une traduction réseau via l'opérateur d'accès à Internet.

Le CJUE a décidé le 19.10.2016 (C-582/14), que les adresses IP doivent être considérées comme des données personnelles, si une identification du propriétaire de la connexion est juridiquement possible dans l'État membre de l'Union européenne concerné. En Allemagne, c'est possible, par exemple pour la poursuite pénale. Il suffit que la possibilité objective d'obtenir cette information sur la connexion soit présente, même si elle doit être obtenue sous le contrôle de plusieurs services (fournisseurs de télécommunications, services secrets, police…). Le CJUE s'applique également aux adresses IP dynamiques. Le BGH a confirmé ce jugement le 16.05.2017 (VI ZR 135/13).

En prenant quelques exemples concrets, je souhaite maintenant vérifier si une stockage sans motif des adresses IP peut être justifié.

Denial of Service Attacken

Lors de ce type d'attaque, un serveur est bombardé avec demandes malveillantes en masse à tel point qu'il s'effondre et ne peut plus fonctionner normalement.

Il est facile de déterminer si plusieurs accès ont eu lieu depuis la même adresse IP au cours d'une même unité de temps. Pour cela, chaque adresse IP est conservée en mémoire vive du serveur, donc non protocollé et techniquement pas sauvegardé. Si un accès suivant a lieu depuis la même adresse IP, un compteur augmente de 1. Lorsque le compteur pour une adresse IP atteint par exemple 200 au cours d'une minute, on peut supposer qu'il s'agit d'un accès malveillant.

Une raison peut justifier l'enregistrement d'une adresse IP complète. L'enregistrement semble ne pas être autorisé sans motif.

Mon état actuel de connaissance.

Si la probabilité d'un attaque maligne est suffisamment grande, un motif pour enregistrer les adresses IP est donné. Il ne faut pas que l'adresse IP soit réellement enregistrée qu'à ce moment-là. Ainsi, cette adresse IP peut être bloquée pour futures connexions.

Distributed Denial of Service Attacken

À cette sorte d'attaque, également abrégée DDoS, des demandes massives provenant de plusieurs ordinateurs sont lancées sur un serveur ciblé. Dans le scénario précédent d'attaque, ces demandes massives étaient uniquement lancées à partir d'un seul ordinateur ou au plus de quelques attaquant-ordinateurs.

Les attaques par déni de service se caractérisent notamment par le fait que les ordinateurs des attaquants ont différentes adresses IP. Si le serveur ciblé bloque uniquement certaines adresses IP, il ne sera peut-être pas suffisamment rapide pour bloquer l'attaque. Car il existe de nombreux systèmes d'attaques et non seulement un qui doit être éteint.

Une possibilité pour reconnaître les attaquants répartis est l'interprétation plus large des adresses d'attaquants. Pour cela, on laisse par exemple tomber le dernier octet d'une adresse IPv4 (=adresse IP à 4 octets). Exemple:

• Denial of Service
  • Adresse IP de l'agresseur: 10.20.30.40.
  • Désactiver l'attaque: Blocage de l'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
  • Désactiver l'attaque: Blocage des plages d'adresses IP 10.20.30.x ou même les accès provenant d'une région géographique, comme un pays

Pour déterminer si des attaquants ont différentes adresses réseau, d'autres Metadonnées peuvent être analysées. Une adresse IP a notamment les caractéristiques suivantes qui peuvent par exemple être automatiquement constatées à partir de bases de données.

• Terre. Exemple: Allemagne.
• Fournisseur. Exemple: Vodafone.
• Adresse du serveur. Pour certaines adresses IP des informations supplémentaires directement disponibles. Exemples: 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
• Assemblage de la norme: Numéro d'Autonomie de Système. Un système autonome est une sorte de bureau de poste. D'un bureau centralisé, un paquet de données est envoyé au bureau local qui le répartit ensuite sur place. Un fournisseur gère plusieurs bureaux, donc des ASN.
• Réseau sous-réseau. Plusieurs adresses IP consécutives. Exemple: 10.20.30.0 à 10.20.30.255, donc 10.20.30.x ou 10.20.30.0/24.
• Réputation. Est souvent menée sous forme d'un score ou comme liste noire.

En plus de l'adresse IP, il existe d'autres métadonnées au moins lorsqu'on accède à des sites web. Celles-ci sont notamment:

• Agent Utilisateur: Type de navigateur, Version du navigateur, Type d'OS, Version de l'OS. Exemple: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100203 Firefox/95.0.
• La langue du navigateur définie par l'utilisateur. Exemple: de,en-US;q=0.7,en;q=0.3
• Configuration du cache. Exemple: no-cache (cache désactivé)
• Référant: Page à partir de laquelle l'appel a été effectué (par exemple, en cliquant sur un lien. Exemple: https://dr-dsgvo.de/
• URL appelée: Page avec les paramètres URL qui a été appelée. Exemple: https://dr-dsgvo.de/cookiegeddon/?unsinnsparameter=1
• Données de contenu: S'obtiennent souvent à partir des paramètres URL (GET) ou de la requête (POST). Exemple: Username=SELECT * from users
• Moment d'accès: Il est toujours présent, même pour toutes les autres requêtes réseau. En effet, le destinataire d'un message sait quand il l'a reçu.
• État de lit: Recevra-t-on des réponses à ses demandes ou utilisera-t-il une adresse de l'expéditeur inatteignable (car fausse)?

Ces données peuvent, au moins en combinaison, être considérées comme des données personnelles et donc des données à caractère personnel (voir Art. 4 n° 1 DGSV). Si on les stockait sans cryptage et sans troncature, on ne gagnerait pas grand-chose. Il convient de les crypter si elles apparaissent utiles pour la prévention des dangers. Ce cryptage peut être réalisé par un procédé mathématique.

Chiffrement des données à caractère personnel

Un chiffrement de données se produit de telle sorte que une valeur de données est combinée avec un Valeur clé choisi à l'aise, approprié. Le résultat est une valeur cible. Avec un procédé de hachage cryptographique, des valeurs pourraient également être générées qui ne doivent pas nécessairement être uniques. Plusieurs entrées différentes pourraient donc parfaitement correspondre à la même valeur cible. La probabilité de cela peut être maintenue très faible ou en fait exclue par le choix d'une procédure et des paramètres appropriés (appelé image injective ou procédé parfait sans collisions).

Un valeur cible est une date anonyme, tant que la valeur de clé est connue. Voici un exemple:

1. L'utilisateur X accède à un site web avec l'adresse IP A1. L'adresse A1 est convertie en valeur cible H1 avec la clé S1.
2. L'H1 ne peut pas être réduit à l'A1 car le procédé est asymétrique.
3. Lorsque l'utilisateur X accède à nouveau la page web avec son adresse A1, le résultat H1 est réaffirmé par S1. Cependant, ce résultat était déjà enregistré dans la base de données. On retrouve donc ce résultat pour une date d'accès antérieure. Par conséquent, on sait que l'utilisateur X a accédé à la page web à cette date et actuellement. Ainsi, H1 peut être rétrocalculé à partir d'A1.

Moyennant une clé temporairement valable, il est possible d'effectuer une pseudonymisation temporaire suivie d'une anonymisation. Pour cela, des fonctions à sens unique sont appropriées. Une fonction à sens unique permet de chiffrer mais pas de déchiffrer. Si un niveau de clarté a été précédemment chiffré, il est possible de le comparer avec le niveau de clarté obtenu après avoir chiffré. Ainsi, on peut déterminer que ce niveau de clarté existait déjà avant. Le niveau de clarté chiffré ne peut cependant pas être réduit à son niveau original sans disposer du niveau de clarté qui se trouve actuellement.

Pour des valeurs d'entrée très courtes, il faut prendre des mesures appropriées pour s'assurer qu'une déchiffrement efficace n'est pas possible. En particulier, aucune table de Rainbow ne doit être utilisée. Il est préférable que le procédé soit conçu de telle sorte que ces tables ne soient même pas applicables.

Si la clé S1 n'est valable que 24 heures et qu'elle est ensuite oubliée, tous les valeurs cibles générées avec cette clé ne peuvent plus être déchiffrées. Ainsi, après 24 heures, des données anonymisées sont présentes et non plus pseudonymisées. Cela signifierait également une protection contre les tables de pluie, au moins après l'expiration de la clé.

Prévention des dangers par les métadonnées ou pseudonymisation

La question était de savoir si on pouvait se protéger contre les attaques DDoS que si on protocole les adresses IP sans motif. Je soutiens qu'il n'est pas nécessaire de connaître les adresses IP pour se protéger contre les attaques DDoS.

Dans le cas non optimal du point de vue du droit à l'image, les adresses IP seraient enregistrées sous forme d'une date pseudonyme avec un procédé de cryptage qui pourrait ne pas être une fonction d'un seul sens. Une attaque DDoS se caractérise probablement par le fait que les attaquants lancent rapidement des attaques les uns après les autres. Un clé temporel fournit donc une possibilité de pseudonymisation, qui pourrait être utilisée sans motif. Ce procédé ne serait pas pire en temps réel que l'utilisation d'adresses IP complètes. Seulement lorsqu'on regarde à rebours, il serait moins bon. Une analyse à rebours est souvent utile pour analyser les vagues d'attaques.

Les dangers peuvent être efficacement repoussés si les adresses IP raccourcies ou les métadonnées à des adresses IP sont stockées. Quelles métadonnées cela peut être utile d'avoir, j'ai décrit ci-dessus.

Lors d'attaques DoS ou DDoS, les attaquants peuvent facilement falsifier leur adresse de l'expéditeur (adresse IP). Puisqu'ils n'ont pas besoin de recevoir une réponse à leur requête malveillante. L'attaquant utiliserait donc des adresses IP changeantes. Si on enregistrait les adresses IP complètes, on aurait gagné absolument rien, au moins en temps réel.

Nur quelques accès: Les attaquants qui n'accèdent qu'une seule fois ou très rarement à un système victime ne peuvent pas être reconnus, ou le sont de manière circonstancielle. Un connexion (Connexion) avec les données d'utilisateur volées peut être équipée d'un protocole IP en fonction du contexte. L'utilisation d'une faille de sécurité, comme Log4J, sur une seule accès ne peut pas être empêché ou reconnu ad hoc par un protocole IP. Même si c'est stupide, mais la conservation sans motif des adresses IP pour identifier un suspect est inacceptable. Les caméras embarquées dans les voitures, qui enregistrent permanent et sans motif, sont également inacceptables. C'est dommage, mais c'est ainsi, même si cela signifie que le coupable ne peut pas être identifié. Si un attaquant insère du code malveillant dans un champ de formulaire pour voler des données, il est possible de l'identifier en évaluant les données d'entrée. Par exemple, on peut identifier les injections SQL. De plus, le code malveillant peut être rendu inopérant en mettant en place une programmation appropriée sur le serveur. C'est plus facile à dire qu'à faire, comme on l'a vu avec la bibliothèque de logiciels Log4J largement répandue qui permettait des attaques efficaces sans grand effort. Cependant, même une adresse IP complète protocollisée ne peut pas aider à identifier l'attaque mieux que ce qui est possible autrement (je le prétends).

Les attaquants utilisent des adresses IP relativement stables dans le temps, les métadonnées des adresses IP en temps réel aident à détecter les attaques. De plus, grâce aux métadonnées, une évaluation automatisée ou manuelle à posteriori est beaucoup plus facile que si seule l'adresse IP complète était stockée et que les métadonnées devaient être obtenues pour une analyse d'attaque. La première fois c'est toujours la première fois. Cela signifie: lors d'une attaque initiale, qui sera analysée à posteriori, le victime doit difficilement déterminer les métadonnées pour les adresses IP complètes protocollées. Sauf si les métadonnées ont été directement protocollées, de préférence sans adresse IP complète. Une protocole complète des adresses IP sans métadonnées a donc clairement des inconvénients techniques.

Une attaque qui appelle toujours la même page cible (URL) peut être facilement reconnue. Si une page cible est appelée beaucoup plus souvent qu'il ne serait normal, on pourrait penser à un motif pour protocoller l'IP. Une protocoller sans motif serait donc inutile pour la prévention des dangers.

Les attaques DDoS qui sont attribuées à un pays spécifique ne se produisent généralement pas en Allemagne. En Allemagne, nous avons de bonnes possibilités de poursuite juridique. D'un autre côté, des ordinateurs zombies pourraient être utilisés pour une attaque depuis l'intérieur du pays. Les sites Web allemands, d'ailleurs, pourraient reconnaître et bloquer les accès provenant de l'étranger qui semblent être des attaques. Cela pourrait se faire sans connaître les adresses IP complètes (voir ci-dessus: ASN, pays, fournisseur). Pour les attaques par zombies, une analyse des appels serait utile (URLs cibles, paramètres, fréquence, User-Agent…).

Certains attaques ne pourraient pas être bloquées efficacement, même avec une protocole d'IP complet ou par d'autres moyens. Il n'est donc pas nécessaire de discuter davantage de ce type d'attaques lorsqu'il s'agit de la question de la protocole d'adresse réseau complète sans motif. Exemples de telles attaques sont:

• Malware: Un utilisateur enregistré reçoit un lien nuisible. Soit un serveur zombie est utilisé pour l'envoi de la mail, soit une proxy ou un site Web infiltré. Si le hacker est particulièrement bête, il utilise son propre accès à Internet pour envoyer l'e-mail. Quoi qu'il en soit: dans l'en-tête du courrier électronique, on trouve souvent l'adresse IP de l'émetteur et elle ne doit pas être protocollisée séparément. Indépendamment de cela, le fait de recevoir un e-mail pourrait être considéré comme une raison. Lorsque des sites Web sont piratés sur lesquels un code nuisible est placé, la protocollisation IP au moment du clic sur le lien ne donne rien.
• IP-Spoofing: Les attaquants utilisent des adresses IP de destinataires aléatoirement générées et des métadonnées. Ils ne reçoivent pas la réponse, ils veulent uniquement nuire à l'opprimé par des requêtes malveillantes. Il était possible (il est encore?) aux attaquants d'obtenir les réponses pour d'autres adresses (Backscatter-Attacke).
• Données d'accès récupérées: La connaissance de données d'accès permet à un hacker de se faire passer pour un utilisateur légitime. Seuls par des activités anormales ou par une enquête plus approfondie ou encore par les indications du propriétaire réel des données d'accès, ces accès peuvent être détectés. Si l'on a affaire à un accès depuis l'étranger ou sur un autre appareil que ce qui était normal jusqu'alors, on peut introduire une vérification de sécurité (CAPTCHA, question sur la date de naissance etc.) en fonction du motif. Mais même là, la connaissance de l'adresse IP complète ne sert pas à grand-chose, au moins pas plus que les métadonnées qui permettent d'effectuer une analyse plus large.

Dans une vue d'ensemble plutôt vague, j'ai réuni quelques types d'attaques. Les catégories se chevauchent peut-être (un DoS est possible à l'intérieur ou à l'extérieur du pays etc.). La table ne donne qu'un aperçu et n'est pas exhaustive.

Type d'attaque	Reconnaissance
Accès trop fréquent	Comparer une adresse IP concrète en mémoire.
Denial of Service	Comparer une adresse IP concrète en mémoire.
Distributed Denial of Service	Analyser les adresses IP raccourcies ou les métadonnées.
Injection de code malveillant (injection SQL, etc.)	Vérifier les données de contenu contre des mots-clés et des signes de ponctuation.
Accès par les hackers (accès volé)	Rechercher une adresse IP concrète dans la base de données lorsque les adresses IP des utilisateurs connectés sont stockées, ou enregistrer directement le protocole (motif = connexion)
Attaque venue de l'étranger	Évaluer les métadonnées, en particulier le pays, l'ASN, le sous-réseau.
Attaque venue de l'intérieur	Évaluer les métadonnées, en particulier l'ASN, le sous-réseau.
IP-Spoofing	Lorsque possible, vérifiez l'adresse d'expédition contre l'adresse de retour considérée comme valide, ce qui est par exemple possible dans les réseaux locaux. Si nécessaire, Unicast RPF (ce n'est pas mon domaine d'expertise)

Après qu'une attaque ait été reconnue ou considérée comme probable, on peut (doit) procéder à une protocole d'enregistrement lié à l'adresse IP, si elle est nécessaire pour la prévention des dangers.

Si une adresse IP est bloquée parce qu'elle est considérée comme l'adresse d'un attaquant, existent les dangers suivants:

1. L'adresse est en réalité pas un attaquant, mais a été injustement soupçonnée (ce qui peut se produire notamment lors de blocages automatisés).
2. L'adresse était fausse et appartenait soit à un autre (benign) branchement, soit à aucun (alors l'effet d'une fermeture serait égal à zéro).
3. L'adresse appartenait à un attaquant, mais elle a été réattribuée à un autre (bienveillant) accès. Cela peut arriver à tout moment avec des adresses IP dynamiques, mais aussi en passant par le réseau Tor.
4. L'adresse est attribuée à plusieurs connexions par Carrier Grade NAT. Toutes les connexions sauf une sont donc potentiellement bénignes et sont involontairement bloquées.
5. L'adresse représente un proxy. Lorsque l'adresse de la proxy est bloquée, aucune connexion ne peut établir une liaison via la proxy.

La mise en quarantaine d'une adresse IP n'est pas nécessairement la solution à tous les problèmes, mais peut même aggraver certains cas de figure.

D'autres occasions qui ne sont pas des attaques peuvent être:

• Objectifs de test, tels que la recherche d'erreurs, les améliorations ou les développements nouveaux
• Essais d'inscription avec nom d'utilisateur et/ou mot de passe
• Entrée de données étranges dans un formulaire (ici, il ne s'agit pas nécessairement de code malveillant)

Je ne vais pas approfondir ces occasions ici, car il s'agit ici de la question de la protocole sans motif !

Conclusion

L'enregistrement sans motif des adresses IP pour la prévention des dangers semble techniquement non nécessaire. Je ne vois aucun indice du contraire. Au lieu d'adresses IP complètes, les données suivantes peuvent être enregistrées:

• Les plages d'adresses IP (appelées sous-réseaux)
• Les blocs d'adresses IP
• Nom de plume, objectifs à valeur temporellement limitée qui deviennent anonymes après un court laps de temps
• Informations métadonnées sur les adresses IP:
  • Terre
  • Fournisseur
  • Assemblage de la norme
  • Nom d'hôte
  • Réputation
• Informations métadonnées sur la connexion
  • Objectif appelé (URL, etc.)
  • Données métadonnées de l'expéditeur comme User-Agent ou configuration de cache
  • Moment d'accès
  • Accessibilité de l'antithèse

Si toutefois un motif existe, la protocole complète de l'adresse IP peut être justifié. Des exemples de tels motifs pourraient être:

• Appel excessif par une source
• Comportement anormal d'utilisation
• Appels anormaux (par exemple des paramètres URL inhabituels ou des adresses inexistantes)
• Données suspectes (Exemple: Accès provenant du pays X ou du sous-réseau Y)
• Multiples réponses incorrectes
• Recherche d'erreurs (Exemple: enregistrer ses propres accès pour trouver les erreurs de réseau)

Il peut y avoir des différences dans l'évaluation des scénarios de menace pour petits et grands réseaux respectivement petites et grandes pages web. Que cela donne un différence pertinente pour la question posée dans cet article, je ne peux pas le reconnaître actuellement et je me réjouis de toute réponse.

En outre, l'envoi d'une déclaration d'opinion sur un portail d'opinions n'est pas une raison pour enregistrer un article dans le fichier de journal du serveur Web avec l'adresse IP. Au contraire, on enregistrera l'opinion, éventuellement avec l'adresse IP de l'émetteur, dans une base de données.

Au début, j'avais écrit que cela ne concernait que des serveurs propres, et non les fournisseurs d'accès à Internet (FAI). Si les FAI doivent absolument protocoller l'adresse IP complète sans motif pour se défendre contre certaines menaces, je doute de ce fait jusqu'à nouvel ordre, même si cela peut être le cas chez les FAI. La même chose peut être dite des réseaux de distribution de contenu (RDC). Si les RDC protocollent sans motif des adresses IP complètes, ceci doit être communiqué par l'éditeur du RDC. Je sais que Akamai effectue cette protokollier sans motif. C'est pourquoi l'utilisation du service Cookiebot a été interdite, qui utilise les serveurs d'Akamai.

La prise de protocole des adresses IP complètes par les propriétaires de serveurs pour la prévention des dangers n'est pas nécessaire sur le plan technique.

Jusqu'à preuve du contraire.

Si vous avez une autre opinion, je vois deux possibilités:

1. Vous pouvez citer un exemple concret et compréhensible. Dans ce cas, je vérifierai volontiers l'exemple et modifierai mon opinion si votre exemple le justifie.
2. Ils ne peuvent pas citer un exemple concret. Dans ce cas, ils devraient changer d'avis, qu'ils le veuillent ou non, car l'opinion serait sans fondement et injustifiée.

S'il vous plaît, écrivez-moi qui vous connaissez un exemple concret qui pourrait être pertinent pour l'exploitant d'un serveur. Je rappelle à nouveau que il s'agit de la question de l'enregistrement sans motif, et non de l'enregistrement en raison d'une cause identifiée ! Il ne s'agit pas non plus d'une considération sur l'utilité, mais plutôt sur la nécessité. Comme mot-clé, mentionnez ici le moyen le moins contraignant. Et il existe de nombreux autres moyens qui sont tout aussi appropriés que les adresses IP, voire encore mieux adaptés pour reconnaître ou faire face aux dangers.

Ce n'est pas l'utilité qui est décisive, mais la nécessité et la disponibilité de moyens plus doux.

Ce principe s'applique probablement dans de nombreux domaines du droit à la vie privée.

Voici un résumé de la commodité:

Incident	Utilisable ?	Obligatoire/Permis ?
Omission de déclaration fiscale	Oui, pour tous ceux qui n'en ont pas envie	Non, dit la loi
Hold-up bancaire	Oui, pour celui qui a besoin d'argent	Non, dit la loi
Vidéo de caméra embarquée (enregistrement permanent)	Oui, et plus tard prouver à un adversaire de l'accident que la faute était à lui	Non, en tout cas pas durablement (à ce que je sache)
Protocoller des adresses IP sans motif	Oui, certainement pour beaucoup	Non, affirme-t-il dans cet article

Il ne s'agit pas non plus de poursuite pénale, car elle n'est pas affaire d'un exploitant de serveur et encore moins affaire d'un serveur (sauf si le serveur appartient à une autorité habilitée pour la poursuite pénale).

Mes conversations avec des experts et mes questions à plusieurs groupes d'experts dans un réseau social ont eu pour effet que personne ne pouvait me citer un seul exemple qui contredirait ma position. Même le BSI (German federal security agency) ne put pas me donner un exemple concret. Au lieu de cela, j'ai reçu une réponse avec des informations peu passionnantes. On y mentionnait notamment que les adresses IP sont des données personnelles et qu'il faut prendre en compte les fondements juridiques issus du RGPD. Tout cela m'était déjà connu. De plus, on me renvoyait vers le Compendium du BSI (German federal security agency), mais même là, je n'ai trouvé aucun exemple concret (je suppose que je n'ai rien raté).

Si vous enregistrez systématiquement l'adresse IP complète des utilisateurs de votre réseau public dans vos journaux de serveur: Arrêtez immédiatement ou fournissez un exemple spécifique de prévention des dangers ou d'une autre raison légitime pour laquelle cela devrait être autorisé ?

Cette demande s'adresse aux opérateurs de serveur courants et non à des IPS, aux autorités de poursuite ou assimilées.

Récemment, j'ai constaté que sur le serveur FTP d'un client, un protocole de serveur avec des adresses IP complètes était écrit. De là, il se pose la question de savoir quel avantage cette information peut avoir pour le client. L'avantage devrait être proche de zéro dans la pratique. Le client ne peut par exemple pas réduire les attaques DoS sur son serveur virtuel même s'il connaît les adresses IP des attaquants. Même chose pour les serveurs gérés. Cela n'affecte rien à la question en elle-même.

En outre, le NDR enregistre comme responsable de la page Web de la Tagesschau conformément aux informations sur la protection des données, l'adresse IP complète de tous les visiteurs. On ne leur explique pas pourquoi cela se produit. Sans doute, le délégué à la protection des données du NDR n'en saura rien et/ou ne le dira pas.

Dans un article à part, je m'intéresse à la durée maximale d'enregistrement des fichiers de journalisation Web.