GuiGui's Show

La CJUE a rendu son jugement (contre Meta) :

• Dans le cadre d'une enquête pour abus de position dominante, une autorité de la concurrence peut examiner les pratiques de l'entité contrôlée sous le prisme du RGPD lorsque ce constat est nécessaire pour établir l'abus (de position dominante) ;
  
  
• Une autorité de la concurrence ne peut pas sanctionner les manquements au RGPD autrement que sous le prisme du droit de la concurrence, cela reste de la compétence des APD. Elle ne peut pas diverger des décisions identiques ou similaires rendues par les APD ;
  
  
• Une position dominante ne fait pas obstacle à la base légale du consentement, mais c'est un élément pour apprécier s'il a été donné librement et valablement (la charge est au responsable du traitement) ;
  
  
• Les boutons « like » ou « partager » sur un site web, y compris leur activation, ne signifient pas que l'internaute rend manifestement publiques les données sensibles (origine raciale ou éthique, opinions politiques, convictions religieuses, orientation sexuelle, etc.) contenues sur le site web, sauf s'il a, au préalable, activé un paramètre visant à rendre ces données publiquement accessibles à un nombre illimité de personnes ;
  
  
• La pub personnalisée n'empêche pas l'objet principal d'un contrat d'être atteint, donc sa base légale ne peut pas être la nécessité pour exécuter un contrat. De même, les bases légales de sauvegarde des intérêts vitaux (avec le suivi de la pandémie Covid, c'était bien tenté), de l'obligation légale et de la mission d'intérêt public (car FB prétend effectuer des « recherche[s] pour le bien de la société ») ne sont pas adaptées ;
  
  
• Concernant l'intérêt légitime :
  • La publicité personnalisée ne peut pas être fondée sur l'intérêt légitime, surtout que le traitement de FB est étendu (la quasi-totalité des activités en ligne sont prises en compte). Suivant le point précédent, cela signifie qu'il reste uniquement le consentement ;
    
    
  • Garantir la sécurité du réseau peut être fondé sur cette base légale, sous réserve que les données soient effectivement nécessaires, s'il n'y a pas moyen de faire moins attentatoire et/ou avec moins de données ;
    
    
  • L'amélioration du service peut reposer sur cette base légale, là encore sous réserve de l'ampleur du traitement, et des autres paramètres de l'intérêt légitime.

Communiqué de presse ici.
Décision C-252/21 là.

Suite ici.

Via https://twitter.com/bayartb/status/1676223642626142208.

J'étais en train de mettre un serveur distant à la casse en révoquant toutes les clés d'un conteneur chiffré (cryptsetup luksErase <dev>) puis en écrasant la table des partitions au format GPT avec dd quand Johndescs me demande si j'ai supprimé « la table GPT de backup en fin de disque ».

Ha oui, tiens, plusieurs sources web disent qu'il y a une sauvegarde de la table GPT dans les 33 derniers secteurs d'un disque au max, soit 16,5 octets au max ((33 * 512 octets) / 1024).

Pour le fun, je veux constater ça par moi-même.

fdisk -lu me dit : « Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors ».

Regardons les 1000 derniers secteurs. 3907029168 - 1000 = 3907028168.

dd if=/dev/sda skip=3907028167 | hexdump -vC
[…]
00078e00  48 61 68 21 49 64 6f 6e  74 4e 65 65 64 45 46 49  |Hah!IdontNeedEFI|
00078e10  90 ca 57 b3 c7 18 fa 48  97 a9 9e ae 35 69 6c e0  |..W....H....5il.|
00078e20  28 00 00 00 00 00 00 00  00 08 00 00 00 00 00 00  |(...............|
00078e30  00 00 00 00 00 00 00 00  62 00 69 00 6f 00 73 00  |........b.i.o.s.|
00078e40  5f 00 67 00 72 00 75 00  62 00 2d 00 73 00 64 00  |_.g.r.u.b.-.s.d.|
00078e50  61 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |a...............|
00078e60  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00078e70  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00078e80  af 3d c6 0f 83 84 72 47  8e 79 3d 69 d8 47 7d e4  |.=....rG.y=i.G}.|
00078e90  34 ea 7a 69 e4 99 67 40  b9 df c0 40 3e 12 a8 4c  |4.zi..g@...@>..L|
00078ea0  00 10 00 00 00 00 00 00  ff 07 80 3e 00 00 00 00  |...........>....|
00078eb0  00 00 00 00 00 00 00 00  70 00 72 00 69 00 6d 00  |........p.r.i.m.|
00078ec0  61 00 72 00 79 00 00 00  00 00 00 00 00 00 00 00  |a.r.y...........|
00078ed0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00078ee0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00078ef0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00078f00  af 3d c6 0f 83 84 72 47  8e 79 3d 69 d8 47 7d e4  |.=....rG.y=i.G}.|
00078f10  2d 41 c0 3f a0 c1 12 49  bf 5c cf ee 89 d0 6e 77  |-A.?...I.\....nw|
00078f20  00 08 80 3e 00 00 00 00  ff 6f d0 e8 00 00 00 00  |...>.....o......|
00078f30  00 00 00 00 00 00 00 00  70 00 72 00 69 00 6d 00  |........p.r.i.m.|
00078f40  61 00 72 00 79 00 00 00  00 00 00 00 00 00 00 00  |a.r.y...........|
00078f50  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00078f60  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00078f70  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00078f80  6d fd 57 06 ab a4 c4 43  84 e5 09 33 c8 4b 4f 4f  |m.W....C...3.KOO|
00078f90  3e d2 b7 22 c5 0e 82 44  80 e4 62 e0 85 fb 59 fc  |>.."...D..b...Y.|
00078fa0  00 70 d0 e8 00 00 00 00  ff 67 e0 e8 00 00 00 00  |.p.......g......|
00078fb0  00 00 00 00 00 00 00 00  70 00 72 00 69 00 6d 00  |........p.r.i.m.|
00078fc0  61 00 72 00 79 00 00 00  00 00 00 00 00 00 00 00  |a.r.y...........|
0007ce00  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
0007ce10  29 6e 0e d5 00 00 00 00  af 88 e0 e8 00 00 00 00  |)n..............|
0007ce20  01 00 00 00 00 00 00 00  22 00 00 00 00 00 00 00  |........".......|
0007ce30  8e 88 e0 e8 00 00 00 00  d0 d2 1f c2 dc 91 bb 4f  |...............O|
0007ce40  9f e7 c8 a4 04 7b 91 bc  8f 88 e0 e8 00 00 00 00  |.....{..........|
0007ce50  80 00 00 00 80 00 00 00  90 23 af 95 00 00 00 00  |.........#......|

Utilisons Wikipedia pour déchiffrer ça.

L'entête secondaire est sur le dernier secteur du disque. On la reconnaît grâce à sa signature, « 45 46 49 20 50 41 52 54 » (« EFI PART » en ASCII ).

Ensuite, on a la table des partitions. Habituellement, une entrée de la table occupe 128 octets soit 8 lignes de hexdump. On y voit quatre partitions (la distinction primaire / logique n'existe plus) :

• La première depuis l'entête (et donc la dernière sur le disque) est une partition swap de Linux. Je le sais grâce à l'identifiant unique de son type : « 6d fd 57 06 ab a4 c4 43 84 e5 09 33 c8 4b 4f 4f ». Attention, comme l'explique la note de Wikipedia, une partie des octets est inversée à cause du little-endian.

  • Son nom est « p.r.i.m.a.r.y » (nom par défaut quand on en donne aucun ?). Je le sais car le nom commence au 57e octet d'une entrée de la table des partoches ;
    
    
  • Elle commence au secteur numéro « 00 70 d0 e8 » = 0xE8D07000 (hexadécimal après suppression de l'endianness) = 3905974272 (décimal). Elle termine au secteur « ff 67 e0 e8 » = 0xE8E067FF = 3907020799. Elle occupe donc 3907020799 - 3905974272 = 1046527 secteurs. Un secteur = 512 octets (fdisk le dit) donc la taille de la partition est : 1046527 * 512 = 535821824 octets soit 512 Mo environ ;
• La deuxième partition (depuis la fin, toujours) est une partoche Linux. On la reconnaît grâce à son type : « af 3d c6 0f 83 84 72 47 8e 79 3d 69 d8 47 7d e4 ». Son nom est identique à la première. Elle occupe 1,3 To environ ;
  
  
• Idem pour la troisième partition. Elle occupe environ 500 Go ;
  
  
• La dernière partition (et donc la première sur le disque) est une partition de boot BIOS (qui permet d'utiliser GPT sans EFI, en gros). Là encore, on la reconnaît grâce à son type : « 48 61 68 21 49 64 6f 6e 74 4e 65 65 64 45 46 49 », qui, interprété en ASCII nous donne « Hah!IdontNeedEFI ». Son nom est « b.i.o.s._.g.r.u.b.-.s.d.a ». Elle occupe environ 1 Mo.

Aucune de ces partitions n'a un quelconque attribut (drapeau). Ils sont situés dans les 8 octets qui précédent le nom de la partition.

Un drapeau = 1 bit. Une partition cachée = bit 62 = 63e bit. Pas de montage auto = bit 63 = 64e bit.

Les logiciels n'ont pas l'air d'accord sur le rôle de chaque bit de drapeau. sgdisk considère que le 1er bit (bit 0) signifie partition système là où parted considère qu'il signifie partition cachée. Inversement, gparted ne reconnaît pas ce que sgdisk considère être une partition cachée (63e bit). Les deux outils sont d'accord sur le 3e bit (amorçable par d'anciens BIOS). gparted reconnaît aucun des autres drapeaux.

Sur ce coup, gparted est mal fichu, notamment parce qu'il présente comme drapeau ce qui n'en est pas, comme « bios_grub » (qui désigne une partition de boot BIOS, qui est un type de partition).

Évidemment, y'a encore cette histoire de little-endian, donc (binaire avec xxd, hexa avec hexdump, format gdisk, format sgdisk, sens pour parted) :

• bit 0 = 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000 = 01 00 00 00 00 00 00 00 = 0000000000000001 = 1:0:1 (system partition) = hidden ;
  
  
• bit 1 = 00000010 00000000 00000000 00000000 00000000 00000000 00000000 00000000 = 02 00 00 00 00 00 00 00 = 0000000000000002 = 1:1:1 (hide from EFI) = rien ;
  
  
• bit 2 = 00000100 00000000 00000000 00000000 00000000 00000000 00000000 00000000 = 04 00 00 00 00 00 00 00 = 0000000000000004 = 1:2:1 (legacy BIOS bootable) = legacy_boot ;
  
  
• bit 60 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00010000 = 00 00 00 00 00 00 00 10 = 1000000000000000 = 1:60:1 (read-only) = rien ;
  
  
• bit 62 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01000000 = 00 00 00 00 00 00 00 40 = 4000000000000000 = 1:62:1 (hidden) = rien ;
  
  
• bit 63 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 10000000 = 00 00 00 00 00 00 00 80 = 8000000000000000 = 1:63:1 (do not automount) = rien.

Du coup, j'ai également effacé cette table GPT secondaire avec dd if=/dev/urandom seek=3907028167 of=/dev/sda.

Ça me rappelle l'un de mes articles vieux de 13 ans dans lequel je décortique un MBR. :D

Deleting or removing all emails from Postfix queue

To remove all mail from the queue, enter:
postsuper -d ALL

To remove all mails in the deferred queue, enter:
postsuper -d ALL deferred

(J'arrive pas à croire que je ne l'ai pas shaarlié plus tôt, ce logiciel.)

Merci Alex.

En France, comme dans le reste de l'UE, les opérateurs de communications électroniques ouverts au public et les hébergeurs informatiques de contenus accessibles au public sont tenus de conserver certaines données durant un certain temps pour certaines finalités légales. On nomme ça la rétention des données de connexion. (Cette désignation est trompeuse puisque la conservation d'autres jeux de données est également obligatoire.) Le régime juridique des données de connexion est distinct de celui des interceptions (portant sur le contenu des communications) qui ne sera pas traité ici.

Durant les dix dernières années, ce cadre a évolué, donc je voulais faire le point. De plus, je me suis toujours demandé quelles obligations précises pèsent sur moi avec mon site web perso, mes serveurs emails et de messagerie instantanée persos, etc. Voyons ça.

Plan :

• Historique

• Actuellement

  • Rétention ciblée et droit de communication

• Futur

• Concrètement

  • Qui est concerné ?

    • Un site web ?
      
      
    • Un serveur emails ? Un serveur de messagerie instantanée ?

  • Que faut-il collecter et conserver ? Combien de temps ?

    • De l'ambiguïté historique à la légende urbaine
  • Journaux techniques
    
    
  • RGPD

Historique

• 2002 : la directive européenne 2002/58/CE (dite e-privacy) protège la vie privée en ligne, et, par exception / dérogation, elle définit ce que les intermédiaires techniques peuvent conserver, pendant combien de temps, etc. ;
  
  
• 2004 : la France met en place la rétention des données de connexion, notamment dans la loi 2004-575 dite de confiance dans l'économie numérique (LCEN) ;
  
  
• 2006 : adoption de la directive européenne 2006/24/CE qui précise et oblige la rétention des données de connexion. Le cadre français, antérieur, n'en est pas une transposition, mais y est conforme. Normal, la France poussait l'UE à adopter ladite rétention. À l'inverse, l'Allemagne a traîné des pieds pour transposer cette directive et a limité la conservation à quelques semaines avec un mécanisme de gel de leur suppression en cas de réquisition ;
  
  

• 2011 : le décret 2011-219 est le dernier fixant, avec l'ancienne version du R10-13 Code des Postes et des Communications Électroniques (CPCE), le cadre français avant le grand chamboulement. Il prévoit la conservation des données de connexion, des données d'identification, de facturation, etc. ;

• 2014-2022 : dans plusieurs arrêts, via plusieurs questions préjudicielles posées par plusieurs juridictions nationales, la Cour de Justice de l'UE (CJUE) invalide la directive 2006/24/CE et précise le cadre européen. Arrêts notables (y'en a d'autres) : Digital Rights Ireland (2014), Tele2 Sverige (2016), LQDN et Privacy International (2020), H. K. / Prokuratuur (2021), Commissioner of the Garda Síochána (2022), SpaceNet (2022) ;

  • La conservation préventive, généralisée et indifférenciée des données de connexion est une atteinte disproportionnée à la vie privée, même si lesdites données ne sont pas exploitées ;

  • Pour la même raison, l'accès aux données de connexion doit être réservé :

    • à une autorité judiciaire ou administrative indépendante de l'autorité de poursuite ;
      
      
    • dans le cadre de la lutte contre une menace grave, réelle, et actuelle ou prévisible pesant sur la sécurité nationale (la conservation demeure généralisée et indifférenciée) ou pour la prévention des menaces graves à la sécurité publique ou pour la lutte contre la criminalité grave (dans ces deux derniers cas, la conservation doit alors être ciblée, sans discrimination donc par temporalité et/ou géographie). Les données ne sont donc plus communicables dans le cadre d'un procès civil ;
  • Les données relatives à l'état civil (identification des utilisateurs) font toujours l'objet d'une conservation généralisée et indifférenciée pour tout motif (mais ne sont communicables que dans un procès pénal).
• 2015 : la plupart des affaires initiées par les Exégètes amateurs (LQDN, FFDN, FDN) ont mené, in fine, après de nombreux détours et baroud d'honneur, à certaines des décisions de la CJUE référencées au point précédent, mais je me souviens tout de même de l'article L246-1 du Code de la sécurité intérieure (CSI) codifié par la Loi de Programmation Militaire (LPM) de 2013 renuméroté L851-1 par la loi Renseignement de 2015 à laquelle il sert de fondement pour la collecte des données. Il prévoit un accès aux « informations ou documents ». Dans sa décision 2015-478 QPC, le Conseil constitutionnel a interprété qu'il s'agit uniquement des données prévues par la LCEN et le CPCE dont nous parlons ici. De même, il a rappelé que le contenu des communications est hors du périmètre ;
  
  

• 2020 : dans son arrêt Breyer contre Allemagne (résumé ici), la Cour Européenne des Droits de l'Homme (CEDH) valide la collecte de données d'identification des détenteurs d'une carte SIM prépayée (l'ingérence est nécessaire et proportionnée) ;

• 2021-2022 : le Conseil d'État (avril 2021) et la Cour de cassation (juillet 2022) adaptent, à contrecœur, le droit français au droit de l'UE ;

  • Jusqu'au bout, la France aura prétendu ne pas être concernée d'une part car sa législation nationale, conforme à la directive 2006/24/CE, n'en est pas une transposition (la décision 388134 de février 2016 du Conseil d'État est révélatrice), et d'autre part, car la conservation est mise en branle pour un motif de sécurité nationale (alors qu'en vrai, pas que), qui est une prérogative des États, pas de l'UE. Comme l'Allemagne (rachat de la dette des États par la BCE), ce qui a retenu le Conseil d'État, malgré une analyse en droit tout de même, c'est la peur des nationalistes qui pourraient eux aussi remettre en cause la primauté du droit européen dans leurs thématiques favorites, façon Hongrie. Petite comparaison européenne de la mise en conformité avec les arrêts de la CJUE ;
    
    
  • Il y a désormais un panachage de la durée de conservation et des pratiques par finalité (sécurité nationale, criminalité grave, autre), cf. pages 3 et 4 ;
    
    
  • Les OPJ et le Parquet, qui sont l'autorité de poursuite (en sus de ne pas être indépendants de l'exécutif), ne peuvent plus demander l'accès aux données, seuls le juge d'instruction et le juge des libertés et de la détention (JLD) le peuvent. Cependant, pour rappel, le juge d'instruction est impliqué dans une enquête et le JLD, débordé, est saisi par le Parquet et dispose, au moment de sa prise de décision, de très peu d'informations sur le dossier en cours, donc son accord est majoritairement automatique afin de ne pas entraver l'action publique… La CJUE risque donc de ne pas être convaincue ;
    
    
  • L'arrêt de la Cour de cassation tolère l'exploitation, par ricochet, des données de connexion recueillies à des fins de sécurité nationale (cf. point suivant sur les décrets de 2021…) dans des affaires qui n'en relèvent pas, et le repêchage de données de connexion obtenues illégalement, ce que la CJUE interdit.

• 2021 :

  • Dans son arrêt Big Brother Watch et autres contre Royaume-Uni (communiqué de presse), la CEDH dégage des critères pour valider une législation nationale implémentant la surveillance de masse (en clair : les digues ont sauté, il est loin le temps de Klass et autres c. Allemagne et de son paragraphe 41) : nécessité, proportionnalité, autorité indépendante y compris pour définir l'objet et l'étendue de la surveillance, et supervision indépendante des opérations de surveillance (aka contrôle a posteriori). Elle juge que l'ancienne législation britannique (remplacée en 2016), pourtant axée sur la sécurité nationale, n'est pas conforme à la ConvEDH par absence d'autorisation indépendante et de définition de l'étendue de la recherche et/ou des termes de celle-ci. Ensuite, la CEDH dégage des critères pour valider une législation nationale prévoyant des échanges de renseignements avec des services de renseignement étrangers : prévoir les circonstances des collaborations et celles d'utilisation des renseignements obtenus, et contrôle indépendant a posteriori. Le régime britannique satisfait à ces exigences ;

  • Loi renseignement 2 (relative à la prévention d’actes de terrorisme et au renseignement) puis édiction des trois décrets français qui régissent actuellement la conservation des données de connexion : 2021-1361 pour les opérateurs au titre du CPCE, 2021-1362 pour les hébergeurs et les opérateurs au titre de la LCEN, et 2021-1363 pour la conservation des données de connexion et de localisation à des fins de prévention de la menace grave et actuelle contre la sécurité nationale (qui est la conséquence de la jurisprudence CJUE interprétée par le CE pour sauver les miches de la France : la conservation généralisée est autorisée pour prévenir les menaces à la sécu nationale sous réserve d'une évaluation régulière du risque, donc hop, un décret d'injonction que l'on oubliera de réviser régulièrement et si quelqu'un rouspète, on l'abrogera pour en prendre un autre). Comme craint, le décret 2022-1327 a pris la suite du 2021-1363, puis le 2023-933, puis le 2024-901 ;

    • Contre-arguments de LQDN : une injonction doit être individualisée ; la collecte généralisée des données de connexion doit rester une exception (CJUE) ; la CJUE a une définition beaucoup plus restrictive de la sécurité nationale que notre droit national qui englobe (cf. L811-3 CSI) les violences collectives (auxquelles le Conseil constitutionnel a rattaché, en 2015, les manif' non déclarées), la prévention de la délinquance et de la criminalité organisées, les atteintes à la forme républicaine des institutions, et auxquelles le Conseil d'État, a ajouté, en 2021, les activités de groupes radicaux ;
      
      
    • Notons que ces décrets prévoient enfin la conservation du port source, ce qui permet d'identifier les utilisateurs d'un service en ligne qui partagent une même adresse IP (surtout en mobilité), plutôt que de geindre dans la presse que les réseaux sociaux ne collaborent pas avec la police (alors que si, mais c'était infructueux puisqu'aucune correspondance ne pouvait être établie).

• 2022 :

  • mai : le Conseil constitutionnel juge conforme la réquisition des données de connexion en enquête de flagrance. Au moment de sa décision, la loi a déjà changé. Garanties suffisantes. À rebours de la CJUE, il juge qu'il n'y a point besoin d'un contrôle préalable par une juridiction ou autorité indépendante. Comme quoi, notre Constitution ou son interprétation ne sont pas forcément le nec plus ultra (une disposition peut y être conforme tout en étant non conforme au droit de l'UE). Il revient au juge européen de trancher (mais, comme dit, la loi a déjà changé). L'« identité constitutionnelle de la France » s'applique seulement si le principe / droit / liberté n'a pas d'équivalent dans le droit européen (lire ceci ou cela) ;
    
    
  • septembre : arrêt C-339/20 de la CJUE : les infractions d'abus de marché ne peuvent faire l'objet d'une collecte de données de connexion (l'AMF avait obtenu des données de connexion recueillies en enquête pénale). À rebours, la CEDH a jugé, en mai 2023, que les données de connexion recueillies en enquête pénale peuvent être utilisées par une autorité de la concurrence. L'affaire a été renvoyée en grande chambre en septembre 2023, probablement pour cette divergence. Affaire à suivre, donc. Avant renvoi, la Cour de cassation avait perçu l'absence d'indépendance de l'AMF. Dans ces deux cas précis (AMF et ADLC), la France a mis en place, un « contrôleur des demandes de données de connexion », cf. section « Rétention ciblée et droit de communication ».
• 2023 : le 30/06/2023, le Conseil d'État a rendu ses décisions sur les décrets de 2021 / 2022.
  • Arrêt 468361 sur le décret 2022-1327 (injonction à conserver les données de trafic et de localisation pour la sécurité nationale), attaqué par Free et des individus : la menace est grave et actuelle (terrorisme ‒ 8 attaques depuis 2020, 10 projets déjoués ‒, l'instabilité au Sahel qui vise la France, l'ingérence et l'espionnage liées à la guerre en Ukraine, les groupes radicaux d'ultra-droite et d'ultra-gauche qui troublent la paix publique, et les cyberattaques visant les OIV) ; le gouv' peut invoquer des menaces de natures différentes de celles qui l'ont poussé à prendre le décret ; il n'y a pas d'atteinte disproportionnée à la vie privée (sans argument) ; il y a un ré-examen périodique (1 an, possibilité d'y mettre fin prématurément, etc.) et un recours effectif devant le Conseil d'État, donc c'est conforme aux arrêts de la CJUE ;
    
    
  • Arrêt 459724 sur les décrets 2021-1361 et 2021-1362, attaqués par Free :
    • Énième confirmation que l'on conserve uniquement ce qu'on collecte dans le cadre de l'activité, ce qui est nécessaire / utile à l'activité, "tu donnes que ce que t'as" ;
      
      
    • Énième confirmation que l'on n'a pas à vérifier la véracité des données relatives à l'identité civile (adresse postale, par ex.) ;
      
      
    • Le panachage des finalités pour chaque jeux de données (paragraphe 18) diffère de celui de la Cour de cassation (cf. 2021-2022 ci-dessus). Sur les données de trafic et de localisation, CE et Cass sont raccord : sauvegarde de la sécurité nationale, néanmoins le CE ne rappelle pas qu'une conversation ciblée et limitée est possible pour criminalité grave et sécurité publique. Données relatives à la source d'une connexion ou aux terminaux : en sus de la criminalité grave et à la sauvegarde de la sécurité nationale prévues par la Cour de cass, le CE prévoit lutte contre la délinquance grave (ce qui ne fait pas partie du périmètre délimité par la CJUE) et la menace grave contre la sécurité publique. Pour le reste (identité civile, contrat, facturation, etc.), Cour de cass' et CE sont raccord sur recherche des infractions pénales, délinquance et criminalité graves, menaces graves contre la sécurité publique, et sauvegarde de la sécurité nationale ;
      
      
    • L'obligation de conserver l'identité civile 5 ans, qui conduit à détenir un historique des adresses postales, emails, numéros de téléphone, etc. n'est pas disproportionnée ;
      
      
    • La date+heure + le lieu des transactions physiques (pour payer l'abo, etc.) ne sont pas des données de localisation au sens de la directive ePrivacy donc elles peuvent être utilisées pour toutes les finalités, pas juste pour sauvegarder la sécu nationale, la sécu publique, et pour la criminalité et la délinquance graves. Notons ici que le CE contredit son paragraphe 18 : la délinquance grave n'en fait pas partie… ;
      
      
    • Le décret attaqué ne fixe pas les durées de conservation, donc on ne peut pas débattre, dans cette procédure, de la durée de conservation des infos de paiement qui serait excessive, et donc contraire au droit de l'UE ;
      
      
    • Le décret ne traitant pas de l'accès, par les autorités, aux jeux de données qu'il impose de conserver, on ne peut en parler non plus ;
      
      
    • L'ingérence dans la vie privée est nécessaire et proportionnée ;
      
      
    • Des précisions ont été apportées sur les données à conserver, voir la section « Que faut-il collecter et conserver ? Combien de temps ? » ci-dessous.

Sources pour rédiger cette section :

• FDN et autres contre gouvernement à PSES 2015 ;
  
  
• Big Brother habite place Beauvau ? chez Thinkerview en 2018 ;
  
  
• Legal update: on en est où de l'accès aux logs ? au FRnOG 36 de septembre 2022 ;
  
  
• Les innombrables tweets d'Alexandre Archambault auxquels je n'ai plus accès puisque Twitter est désormais fermé aux non-inscrits.

Actuellement

Gros résumé à la truelle de la section précédente :

• Données d'identification (état civil, contrat, facturation, etc.) :

  • Doivent être conservées 5 ans pour l'identité (contre 1 an auparavant ;) ), et 1 an pour le reste, après la fin de validité du contrat ;
    
    
  • Doivent être communiquées en toute circonstance (peu importe la gravité de l'infraction) dans un procès pénal. Pas au civil (si c'est demandé, il faut contester durant le procès, car la juridiction est tenue par les propos et prétentions des parties, cf. Wikipédia qui a été contrainte, à tort, de communiquer les données d'un contributeur ‒ sources : 1, 2, 3, 4 ‒) ;
    
    
  • Il n'y a pas d'obligation de vérifier les informations fournies par le client ni de collecter des justificatifs, c'est une légende urbaine, seul le milieu financier fait l'objet d'une telle obligation. L'arrêt 459724 du CE confirme cela.

• Données de connexion / de trafic / d'activité / de localisation :

  • Cour de cassation : que dalle pour les infractions qui ne relèvent pas de la criminalité grave ; conservation ciblée (lieux exposés à la criminalité, par ex.) et limitée (quick freeze) suite à une injonction pour la criminalité grave et la prévention des menaces graves contre la sécurité publique ; conservation généralisée et indifférenciée pour la sécurité nationale. En somme, on revient à l'ancien temps, avant la généralisation, où la conservation était autorisée uniquement pour lutter contre la criminalité et la délinquance graves (>3 ans de taule). Le Conseil d'État ajoute la délinquance grave. (Je passe sur la divergence entre droit français et européen sur la définition de la sécurité nationale, cf. 2021 dans la section « Historique ») ;
    
    
  • En France, ça ne change rien pour les intermédiaires techniques : tant qu'il y a une injonction ministérielle au motif de la sécurité nationale (actuellement, le décret 2021-1363, cf. ci-dessus), il faut tout conserver sur tout le monde, seul l'accès / la communication devra être autorisé ou interdit en fonction de la finalité poursuivie par les autorités. Les questions qu'ils restent : en quoi notre gouvernement fait la preuve que la menace est 1) grave ; 2) réelle, 3) actuelle ou prévisible (conditions posées par la CJUE) ? Les données de connexion collectées pour une finalité (sécurité nationale) ne risquent-elles pas d'être utilisées pour d'autres finalités (petite criminalité, par ex.) ? ;
    
    
  • Doivent être conservées un an, comme avant les joutes devant la CJUE.
• Dans les deux cas, les entités conservent uniquement les données qu'elles détiennent dans le cadre normal de leur activité (cf. 2023 dans la section « Historique »), et ceux qui peuvent demander sont le juge d'instruction, le juge des libertés et de la détention, et les autorités administratives réellement indépendantes (cf. section suivante). Pour les demandes venues de l'étranger (internationales), les intermédiaires techniques doivent renvoyer vers la BEFTI ou la sous-direction de la lutte contre la cybercriminalité (ex-OCLCTIC), car, a priori, y'a pas de raison que si une entité étrangère n'est pas tenue de répondre à une réquisition directe des autorités françaises, l'inverse soit vrai.

Rétention ciblée et droit de communication

En sus de ça, la LCEN permet à l'autorité judiciaire de prescrire des mesures de surveillance ciblées et temporaires (source, point 7 de l'article 6). La CJUE ne s'y oppose pas, tant que c'est pour lutter contre la criminalité grave ou préserver la sécurité nationale ou publique, cf. arrêt SpaceNet ci-dessus. (C'pas déconnant, il existe bien les écoutes téléphoniques.)

A priori, c'est dans un cadre suisse similaire que ProtonMail a mouchardé l'adresse IP, le modèle et l'identifiant du terminal de militants français (source). On notera que la France a utilisé une procédure de coopération dédiée à la criminalité grave pour une affaire qui n'en relève pas et que les autorités suisses ont laissé faire (car ce n'est pas leur boulot de vérifier si des faits relèvent ou non des conventions d'entraide). Pour obtenir une collaboration, il faut une équivalence de l'infraction dans le droit suisse (je ne suis pas convaincu que ça freine les demandes puisque les autorités ne reprochent jamais d'être un mouvement social mais des infractions précises comme trouble à l'ordre public, destruction ou dégradation de bien, etc. qui existent dans toutes les législations…). Comme le note Reflets, on peut déplorer le flou dans la communication de ProtonMail, qui a changé plusieurs pages de son site web depuis cette histoire. Lire aussi l'analyse d'Alex Archambault.

Comme le note à nouveau Reflets, il en irait de même pour une surveillance ciblée par les services de renseignement ou par une administration, sous réserve d'un contrôle par une autorité indépendante. L'article 20 de la LPM 2013, qui sert de base à la collecte prévue par la loi Renseignement de 2015, prévoit un droit de communication pour les ministères de la Défense, de l'Intérieur, de l'Économie+Finances, etc., mais, j'imagine que, par sa nature et à l'aune de la jurisprudence de la CJUE, ce droit de communication de l'administration est ciblé. (Là encore, c'pas déconnant, il existe aussi les écoutes téléphoniques administratives, contrôlées par la CNCTR.)

Plein d'administrations ont un droit de communication (en dehors de tout contrôle préalable d'un juge donc) initialement accordé au fisc : AMF, DGCCRF et ADLC, douanes, sécu dont CAF, Pôle emploi, URSSAF, ANSSI, HADOPI, etc. Toutes n'ont pas accès aux données de connexion genre la Sécu ou Pôle emploi (pour ce dernier, le R5312-47 du Code du taff référence le L5312-13-2 du même Code qui exclut le L96 G du livre des procédures fiscales, c'est-à-dire les opérateurs de communications électroniques). Concernant la CAF, le Conseil constitutionnel a dit non en ce qui concerne les données de connexion, la loi n'a pas été modifiée (seul le renvoi au L83B du livre des procédures fiscale a été retiré, mais il ne concerne nullement les données de connexion), et au moins un dossier est devant la CEDH.

Depuis 2018-2019, pour répondre au critère d'indépendance posé par la CJUE (l'autorité de poursuite ne peut pas être celle qui accède aux données de connexion), l'AMF (avant de se faire retoquer par la CJUE, j'imagine) et l'ADLC demandent une autorisation préalable d'accéder aux données de connexion au contrôleur des demandes de données de connexion (CDCD), c'est-à-dire un membre du Conseil d'État suppléé par un magistrat de la Cour de cassation (et inversement, par alternance). Voir ici et là. Quid de l'indépendance des autres administrations ? HADOPI, CAF, ANSSI, etc. ?

De même, est-ce que les infractions dont ces autorités ont la charge relèvent de la gravité délimitée par la CJUE ? L'AMF s'est fait retoquer là-dessus (cf. 2022 dans la section « Historique »). La lutte contre la fraude sociale (CAF), contre les entraves à la concurrence (ADLC), ou contre le téléchargement illégal (HADOPI) relèvent-elles de la criminalité grave, de la sécurité publique, etc. ? J'en doute. De là, se faire communiquer les données de connexion que les opérateurs collectent dans le cadre de la sécurité nationale (cf. 2021 dans la section « Historique ») pour traiter des affaires qui n'en relèvent pas, tient-il la route ? A priori, la CJUE a dit non, mais la Cour de cassation a dit oui (cf. 2022 dans la section « Historique »).

Futur

• Malgré les arrêts du Conseil d'État de 2023 sur les décrets de 2021, il reste des interrogations : durée de conservation (1 an) excessive des données de trafic et de localisation (dans son arrêt Télé2, la CJUE table sur 15-30 jours) et peut-être des infos de paiement (en tout cas Free le pense), une injonction de conservation généralisée peut-elle être nationale alors que la CJUE en fait une exception ? Divergence sur le périmètre (la définition) de la sécurité nationale (cf. 2021 dans section « Historique »). Quand on renouvelle x fois un décret, la menace est-elle toujours réelle et actuelle ou prévisible, comme le veut la CJUE ? Le gouvernement a-t-il au moins réévalué le dispositif ? (Le CE a répondu, mais ça laisse songeur…) Les données de trafic et de localisation collectées seront-elles utilisées uniquement dans des dossiers portant sur la sécurité nationale (pas de réutilisation) ? Les modalités d'accès sont-elles règlos ? ;
  
  
• Le traitement des adresses IP par la HADOPI est toujours devant la CJUE, dossier C-470/21. Même chose pour la CAF devant la CEDH. Quid de l'ADLC (CEDH et CJUE doivent s'accorder, cf. 2022 dans section « Historique »), de la DGCCRF, de l'URSSAF (même article de loi que la CAF), de l'ANSSI, etc. ? Deux questions : 1) indépendance ; 2) infractions graves ;
  
  
• Il reste des divergences entre le Conseil d'État, la Cour de cassation, et le Conseil constitutionnel sur l'implémentation des décisions de la CJUE (divergences entre ces trois cours suprêmes, comme sur les finalité pour chaque jeu de données, et entre certaines d'elles et la CJUE, cf. 2021-2022 de la section « Historique »). En 2023, au Sénat, une mission d'information « sur les modalités d'investigation recourant aux données de connexion dans le cadre des enquêtes pénales » a eu lieu. Des auditions ont eu lieu en juillet et septembre 2023 (source : agenda de la rapporteure). Un rapport a été produit.

Concrètement

Une fois que l'on a écrit tout ça, comment savoir dans quelle catégorie entre un service usuel genre un site web personnel, et les obligations qui s'imposent à nous ?

Pour rédiger cette section, je me suis appuyé sur le travail du feu groupe juridique de la FFDN (copie ici) et sur le travail de LQDN (copie ici). On notera qu'il s'agit de brouillons. Ils sont faux en cela qu'ils ne tiennent pas compte des décrets de 2021. Le premier écrit ne faisait pas consensus au sein du groupe de travail, notamment sur l'interprétation à retenir (celle, militante, de la CJUE, ou celle du droit français). Ce pan du droit est vraiment ardu.

Qui est concerné ?

Deux catégories d'intermédiaires techniques sont concernées :

• Les hébergeurs de contenus publics. Pour concourir à identifier l'auteur d'une création / modification / suppression de contenu. Article 6, I, 2 de la LCEN ;
  
  
• Les opérateurs de communications électroniques ouverts au public. Pour concourir à identifier l'auteur d'une communication. Article R10-13 du CPCE. ET pour concourir à identifier l'auteur d'une création / modification / suppression de contenu. Article 6, I, 1 de la LCEN.

Les deux régimes (CPCE et LCEN) se recoupent en partie, notamment sur les données à conserver.

Dans les deux cas, la prestation peut être gratuite ou payante, et le fournisseur peut être une personne morale ou physique.

La définition d'un hébergeur est plutôt claire (stockage de signaux, d'écrits, d'images, de sons ou de messages pour leur mise à dispo via des services de communication au public en ligne), mais qu'est-ce qu'un opérateur de communications électroniques ? Les définitions sont dans les articles 34-1 et 32-1 du CPCE mais rien n'est clair. En gros, ça regroupe les personnes qui exploitent un réseau de communications électroniques (ouvert au public) ou qui fournissent un service de communications électroniques (idem), ou qui offrent un accès à des services de communication au public en ligne, ou qui offrent au public, au titre d'une activité professionnelle principale ou accessoire, une connexion permettant une communication en ligne. Sachant qu'une communication électronique, c'est toute transmission de signes, signaux, écrits, d'images ou de son par voie électromagnétique et qu'un service de communications électroniques est une prestation qui consiste à fournir de telles communications. Pourquoi le vocable change en plein milieu pour « communication au public » ? Bonne question.

On retrouve les opérateurs réseaux (première définition), les services de voix sur IP (VOIP) comme SkypeOut (deuxième), les Fournisseurs d'Accès à Internet (troisième), les fournisseurs de hotspots Wi-Fi (quatrième), etc. Les hébergeurs ne sont pas englobés dans la deuxième définition. Par défaut, les fournisseurs de messagerie électronique non plus (je vais y revenir).

La notion qui revient est le caractère public. Un réseau privé n'est pas concerné. C'est d'ailleurs pour cela que plusieurs entités qui opèrent un réseau informatique à une échelle métropolitaine, par exemple, destiné à un nombre prévisible d'utilisateurs (les salariés et clients / usagers de ces entités, par exemple) prennent le statut juridique de Groupe Fermé d'Utilisateurs, pour s'éviter les contraintes du CPCE. Les services non-publiés (intranet, correspondance privée) ne sont pas concernés.

Un site web ?

J'ai un blog Wordpress et un shaarli. Il s'agit de services de communication au public en ligne (article 6, III, 2 de la LCEN) dont je suis l'éditeur (au sens de la loi sur la presse). À ce titre, mon hébergeur doit conserver des données sur moi.

Dans les deux cas, comme sur les réseaux sociaux, d'autres personnes peuvent écrire des articles ou des commentaires. La loi permet deux statuts : soit je suis éditeur (au sens de la loi sur la presse), soit hébergeur (au sens de la LCEN).

Si je modère mes commentaires a priori et à la mano, je suis éditeur de facto, car je choisis les contenus, j'ai le contrôle de ce qui est publié. Le Bon Coin a été reconnu hébergeur en 2014 car les annonces sont modérées par un logiciel (source).

A priori, si j'octroie des droits de publication à un nombre restreint de personnes que je choisis, je suis aussi éditeur, je choisis toujours le contenu, ce n'est pas le tout-venant qui peut publier sur mon site. On notera qu'en droit de la presse, il y a une cascade de responsabilités : l'éditeur (ou le dirlo de publication) sera poursuivi, à défaut ou au titre de complicité, les auteurs aussi, à défaut les imprimeurs, à défaut les diffuseurs, donc, a priori, un éditeur n'a pas obligation de consigner qui a écrit quoi.

Les réseaux sociaux jouent sur les deux tableaux : ils se prétendent hébergeurs mais rendent visibles ou invisibles des contenus, les hiérarchisent, les font modérer selon une charte qui leur est propre par des travailleurs sous-payés (troisième point du 2e bloc), etc., ce qui semble constituer un rôle éditorial. Cependant, la question est loin d'être évidente à résorber, lire 1, 2, 3, 4.

Généralement, la consignation des données relatives aux auteurs de contenus (commentaires, articles, etc.) est effectuée par le site web lui-même, par son code, dans sa propre base de données. Les requêtes de consultation d'une page web ne doivent pas faire l'objet d'une journalisation au nom d'une prétendue obligation légale qui n'existe pas (Pages Jaunes s'est ramassée sur ce point). (D'autres finalités peuvent y conduire, cf. section « Journaux techniques » ci-dessous.

Dans mon cas, j'ai fermé les commentaires sur mon blog (mais sinon Wordpress consigne le cœur des données qu'il est obligatoire de conserver), je n'ai plus publié de contributions extérieures depuis 2011 (et Wordpress ne consigne pas les informations nécessaires), et je suis le seul auteur sur mon shaarli. Je suis uniquement éditeur, donc j'ai rien à conserver au titre d'hébergeur.

Évidemment, mes sites web non-publiés (gestionnaire de ToDo, GLPI, agrégateur RSS, etc.), dont je suis le seul utilisateur, et qui font l'objet d'une restriction d'accès par identifiant+mdp ou par adresses IP, ne sont pas des services de communication au public en ligne, donc ils sont hors périmètre (usage strictement personnel).

Garder un journal des accès web pourrait également permettre de se disculper en cas de piratage qui conduirait à la publication d'un contenu illégal plutôt que d'en assumer la responsabilité éditoriale. D'un côté, il faut que l'attaquant publie sa prose via le web (sinon il ne sera pas journalisé par le serveur web, et à part ça, j'ai uniquement un accès SSH (qui ne consigne pas les actions) et la probabilité d'une attaque réussie diminue avec des logiciels maintenus à jour. D'un autre côté, un tel journal sera inexploitable car l'attaquant se dissimulera derrière des rebonds / intermédiaires, et le contenu, qui sera temporaire (car je m'en rendrais compte rapido) et qui ne relèvera pas de la diffamation / injure / harcèlement / appel à la haine / dénigrement / etc. mais plutôt d'actes rentables genre vente de Viagra, ne sera jamais poursuivi, donc l'occasion de dégainer le journal n'existera pas. Tout montre qu'un tel journal est inutile. Sans compter qu'un piratage doit faire partie des cas de force majeur ou équivalent ("j'ai mis en place des mesures de sécurité, elles ont été contournées, c'est pas d'chance").

J'ai jamais lu que des commentaires ou articles de blog constituent une fourniture de service de communications électroniques entraînant l'application du régime prévu par le CPCE. La directive-cadre européenne 2002/21/CE dispose même de l'inverse (cf. arrêt C‑193/18 de la CJUE, points 29 à 31).

Un serveur emails ? Un serveur de messagerie instantanée ?

Il s'agit de correspondance privée qui s'entend comme un nombre prévisible et déterminé de destinataires individualisés. Il y a donc une communauté d'intérêt entre l'expéditeur et les destinataires. Cela a été tranché par les juridictions, y compris pour le spam… C'est différent d'un site web ou d'un profil ouvert sur un réseau social auxquels tout le monde peut accéder sans restriction. Donc le statut d'hébergeur ne s'applique pas (puisqu'il n'y a pas mise à dispo via des services de communication au public en ligne).

A priori, les listes de diffusion, les MUC (discussion de groupe) Jabber, IRC, et tant d'autres entrent également dans ce cadre-là.

Attention : parfois, un même service peut avoir plusieurs statuts. Exemple : la publication web ouverte à tous des archives d'une liste de discussion ou la mise à disposition au public de pièces jointes ou de calendriers par un webmail (type GMail) sortent du cadre de la correspondance privée, donc le statut d'hébergeur s'applique. J'ai rien de tout ça, donc je suis peinard.

Suis-je un opérateur de communications électroniques ? Auquel cas, la rétention à ce titre s'appliquerait, quand bien même celle à titre d'hébergeur ne s'applique pas. La question se pose pour de gros fournisseurs de messagerie, car si la correspondance est privée, le service en lui-même est ouvert au public (tout le monde peut ouvrir une adresse Outlook, par ex.).

La CJUE a tranché : GMail n'est pas un service de communications électroniques car sa fonction première n'est pas la transmission de signaux (cette charge est majoritairement portée par d'autres acteurs du réseau, quand bien même Google dispose de son propre réseau mondial), donc Google n'est pas un opérateur de communications électroniques, donc le CPCE ne concerne pas GMail. Les juridictions suisses ont tranché dans le même sens pour ProtonMail.

Comme le relève le Conseil d'État (note 48 pages 13 et suivante), la CJUE semble se contredire dans son arrêt LQDN de 2020, sauf à considérer que la différence entre SkypeOut (qui a été reconnu service de communications électroniques) et GMail est que SkypeOut assure, contre rémunération, la responsabilité de la transmission des communications en vertu d'accords passés avec des opérateurs télécoms là où GMail n'en fait rien, que l'essentiel du transport des emails est assumé par d'autres acteurs en best effort.

Sur la qualification juridique de GMail, on peut lire cet excellent historique.

Conclusion : je ne suis concerné ni par la LCEN, ni par le CPCE pour mes serveurs emails et de messagerie instantanée.

De toute façon, j'utilise la fonctionnalité « smtpd_sender_login_maps » de Postfix qui permet d'associer une adresse d'expéditeur à un identifiant+mdp. Donc, si, du temps où mon serveur emails hébergeait aussi une partie de ma famille (ce qui n'est plus le cas, j'en suis le seul usager), les autorités avaient débarqué pour me demander qui a émis tel email à telle date, etc., tant qu'elles me donnaient l'adresse de l'expéditeur de l'email litigieux, je pouvais dire avec certitude, et sans journal, qui en était l'auteur (sauf en cas de vol de l'identifiant+mdp, mais bon…).

Que faut-il collecter et conserver ? Combien de temps ?

Cf. les décrets 2021-1361 (pour les opérateurs au titre du CPCE), 2021-1362 (pour les hébergeurs et les opérateurs au titre de la LCEN) et 2021-1363 (pour la conservation des données de connexion et de localisation à des fins de prévention de la menace grave et actuelle pesant sur la sécurité nationale), ainsi que l'arrêt 459724 du Conseil d'État (CE) qui précise de nombreux points (dont le fait qu'on conserve uniquement ce que l'on collecte dans le cadre normal de l'activité ‒ source ‒ et qu'on n'a pas d'obligation de vérifier la véracité des informations d'identité civile).

Pour la participation à l'identification de l'auteur d'un contenu (LCEN), cinq jeux de données sont prévus :

• Identité. Noms, prénoms, date et lieu de naissance, adresse postale, numéro de téléphone, adresse emails. On notera que, pour un service de communication au public en ligne, l'article 6, III, 1, a ne prévoit pas la communication de la date et du lieu de naissance à l'hébergeur. Normalement, un décret ne peut pas prévoir des choses en sus de la loi… Conservation : 5 ans après la fin du contrat. Je rappelle qu'il n'est pas obligatoire de recueillir des justificatifs (cf. section « Actuellement ») ;
  
  
• Autres informations contractuelles. Identifiant utilisé (?), pseudos utilisés, les données permettant à un utilisateur de vérifier ou de modifier son mdp (email de secours, CE : tous les « canaux de communication déclarés au préalable par l'utilisateur pour permettre la récupération de comptes ») dont 2FA. Conservation : 1 an après la fin du contrat ;
  
  

• Facturation. Type de paiement, référence du paiement, montant, date et heure (et lieu si transaction physique). Conservation : 1 ans après la fin du contrat ;

• Informations techniques sur un terminal ou la source d'une connexion. Conservation : 1 an à compter de la connexion ou de l'utilisation du terminal ou la création d'un contenu.

  • Pour les opérateurs : identifiant de la connexion (adresse IP, d'après le CE), identifiants attribués à l'abonné, adresse IP et port source (CE : IP publique + port pour les éditeurs & co, et IP publique + IP privée pour les FAI. Pour l'IP privée (côté FAI, donc), je pensais CGNAT, mais le CE écrit « lorsque elle est partagée entre plusieurs terminaux dans le cas des réseaux locaux », ce qui englobe aussi le NAPT d'une box qui a une IP publique) ;
    
    
  • Pour les hébergeurs : identifiant de la connexion à l'origine de la communication (adresse IP, j'imagine, le CE confirme), les types de protocoles utilisés pour la connexion au service et le transfert des contenus.
• Données de trafic et de localisation. Conservation : 1 an après la connexion ou la création d'un contenu. Uniquement sous injonction du premier ministre (ce qui est le cas, cf. décret 2021-1363).
  • Pour les opérateurs : dates et heures de début et de fin de la connexion ;
    
    
  • Pour les hébergeurs : l'identifiant attribué au contenu (ID dans la BDD, etc.), la nature de l'opération (ajout, modification, suppression ?), les date et heure de l'opération, l'identifiant de l'utilisateur ayant produit le contenu s'il l'a fourni.

Il en va de même pour identifier l'auteur d'une communication (CPCE), à quelques variantes près : il faut conserver également le numéro de téléphone appelant (RTC, par ex.), le numéro d'identification du terminal (CE : « données relatives aux connexions internet fixes par wi-fi ». Je comprends adresse MAC) ; les caractéristiques techniques (CE : « données collectées par l'opérateur pour effectuer et justifier la facturation de l'abonné et gérer son réseau, tels que le sens de l'appel, le type d'appel, le rôle de l'abonné, le type de communication ou le volume de données échangées »), date, heure et durée de chaque communication ; les données relatives aux services complémentaires utilisés (CE : « services complémentaires à la fourniture de communication par internet ou par téléphonie, tels que, notamment, les renvois d'appels ou le recours à un commutateur téléphonique privé ») ; les données techniques relatives au terminal et à la connexion (le 4e jeu de données ci-dessus) du destinataire ; et la localisation des communications par téléphone mobile.

De l'ambiguïté historique à la légende urbaine

Comme le relève Alexandre Archambault, la législation dit que tu peux conserver uniquement ce que tu collectes (cf. article 8 du décret 2021-1362, par ex.), mais l'article 39-3 du CPCE et l'article 6, VI de la LCEN prévoient des peines de prison et d'amende pour non conservation…

J'ai toujours interprété ça comme une manière de sanctionner une intention délibérée d'entraver les services enquêteurs : si t'as aucune donnée, c'est louche, s'il t'en manque certaines, ça passe. Exemples : il n'y a pas de facturation dans le cadre d'une prestation gratuite genre devenir auteur sur mon site web ; il n'y a pas de mécanisme de vérification du mdp pour un commentateur de blog ; il est techniquement impossible de fournir les données techniques du terminal du destinataire s'il n'est pas chez le même opérateur ; un hébergeur de machines virtuelles ne peut pas journaliser les modifications de contenus de son client à cause de la démarcation technique (mais il détient les jeux de données 1 à 3) ; etc. L'arrêt 459724 du CE me conforte dans cette interprétation.

De même, si l'on regarde bien, des outils comme Wordpress ou shaarli ne collectent pas toutes les informations exigées d'un hébergeur : date et lieu de naissance d'un commentateur ? Nature, date et heure d'une opération sur les contenus d'un shaarli ? Etc. Wordpress ne permet même pas de supprimer automatiquement au bout d'un an les données personnelles des auteurs de commentaires (son outil « Effacer les données », en sus de ne pas répondre au besoin ‒ il est conçu pour les demandes RGPD ‒, laisse intacte l'adresse IP, seuls le pseudo et l'adresse emails sont effacés).

Je ne peux m'empêcher de penser que c'est à cause de ça qu'il y a une légende urbaine sur une prétendue obligation de conserver le journal des accès à un serveur web pendant un an (démystification : 1, décision du CE contre Pages Jaunes) ou le journal d'un serveur emails.

En effet, le cœur des informations exigées (identifiant du contenu, adresse IP de l'auteur, protocole, nature de l'opération, date et heure) peuvent apparaître dans le journal des accès d'un serveur web (l'identifiant du contenu et la nature de l'opération peuvent être précisés dans l'URL, genre, pour shaarli : « POST /?edit_link=20230709_204855 »). Un conseil d'avocat sur le vif consistant à recommander cette journalisation permet d'être agnostique du type de site web utilisé et de ses capacités de journalisation, et donc de protéger le client dans le plus de cas possibles (objectif de l'avocat). Sachant que tout dépend de la question posée, du contexte présenté à l'avocat, etc., ça me paraît crédible.

Journaux techniques

Bien évidemment qu'on conserve des journaux informatiques pour d'autres motifs qu'une obligation légale tels que l'identification et le diagnostic d'un incident ou la sécurisation d'un système (détecter une compromission, parer automatiquement une attaque, etc.).

Mais cela ne peut pas être fait sous couvert de l'obligation légale présentée dans ce shaarli, il faut distinguer les finalités et la base légale, adapter la durée de conservation, etc., et, si les journaux consignent des données personnelles (comme une IP), il faut les anonymiser (selon la finalité, genre vaut mieux anonymiser après l'usage du journal par fail2ban, par ex.).

RGPD

Évidemment, le RGPD s'applique aux journaux contenant des données personnelles.

S'ils répondent aux obligations présentées dans ce shaarli, pour les éléments demandés, alors la base légale est l'obligation légale, la finalité et la durée de conservation sont précisées dans les décrets, etc. Il n'y a plus qu'à y appliquer le reste du RGPD (sécurisation, traçabilité des accès, information, ne pas divulguer tout et n'importe quoi même dans le cadre d'une décision de justice, etc.).

En revanche, si les obligations présentées ci-dessus ne t'incombent pas ou si tu souhaites journaliser plus d'éléments ou pour une durée supérieure à celle prévue par la législation ou en faire un autre usage que ceux prévus par la législation, il faut une base légale et une finalité en adéquation. Ex. : faire des stats d'audience à partir d'un journal des accès d'un serveur web reposera très probablement sur le consentement, et la durée de conservation (avant anonymisation) sera proportionnée à cette finalité. Un journal technique reposera probablement sur l'intérêt légitime (idem). Etc.

Cela fait 10 ans que mes seules adresses emails personnelles sont liées à mes noms de domaine personnels, et que j'héberge et administre moi-même mes serveurs emails. \o/

Au global sur dix ans, ça tourne sans trop de douleur ni d'entretien. Mais, attention, cela dépend très fortement de l'usage.

En effet, tout administrateur d'un serveur emails doit s'atteler à deux problématiques : le spam entrant, et l'acceptation collective des emails qu'il envoie (émails sortants).

Je n'ai pas d'antispam, pas même de greylisting. Cela exige organisation et rigueur permanentes. Je communique ma véritable adresse uniquement à des gens de confiance et je file une adresse générique ‒ un alias ‒ ou une version suffixée par un délimiteur / tag aux autres, surtout aux sociétés commerciales, aux windowsiens et aux listes de discussion archivées sur le web. (Les alias et les délimiteurs sont également très pratiques pour tracer la revente / fuite d'une adresse emails et pour trier ses emails ‒ on peut ignorer l'adresse d'expédition et/ou elle peut changer en cours de route, ça n'a pas d'incidence sur le tri opéré sur l'adresse de destination, c'est-à-dire l'alias / le délimiteur ‒.) Mon seul regret est de ne pas avoir filé une telle adresse à plus de gens, par faiblesse. Heureusement, je comptabilise une unique conséquence fâcheuse. Bref, rigueur et ténacité. De plus, je n'ai pas besoin d'être contacté par le tout-venant, ce qui simplifie grandement la problématique.

L'acceptation collective se divise en deux : la norme et l'arbitraire. C’est essentiellement l'usage (volumétrie, contenu, destinataires) qui fait passer un serveur emails de l'une à l'autre de ces catégories.

J'ai mis en place toutes les techniques normalisées et informelles : le nom d'hôte EHLO (durant le dialogue SMTP) est déclaré dans le DNS, les adresses IPv4 et IPv6 pointées par ce nom sont celles de mon serveur, et j'ai configuré un reverse (PTR) pour chacune ; SPF ; DKIM ; ADSP ; DMARC ; TLS (avec un certificat auto-signé) + DNSSEC + DANE TLSA, etc. Pour un petit serveur emails (faible volumétrie), tout cela n'est pas obligatoire : DMARC et DKIM sont rarement imposés (GMail impose SPF ou DKIM), ADSP et DANE TLSA encore moins. C'est un investissement notable, mais quand c'est en place, ça ne coûte pas de temps de maintenance.

Surtout, les adresses IP du serveur emails doivent avoir une excellente réputation, c'est-à-dire ne pas traîner dans des listes de blocage (ce qui n'est pas le cas d'OVH, par ex.). SPF, DKIM, ADSP, DANE, etc. servent à rien si tes IP sont tricardes. Donc, il vaut mieux héberger son serveur emails chez un petit prestataire car plus c'est confidentiel, plus ça diminue la probabilité d'avoir des serveurs voisins spammeurs ou mal configurés. En IPv6, le blocage se fait par réseau de taille /64, donc pour ne pas être pénalisé par le comportement d'un voisin de réseau, il faut que l'hébergeur attribue au moins un /64 à ton serveur emails.

Comme tout cela ne suffit pas pour contrer le spam, il y a l'arbitraire. Des réseaux entiers, notamment ceux résidentiels, et des hébergeurs sont bloqués, temporairement ou non, car ils sont considérés comme des spammeurs notoires. Il existe des formalités administratives spécifiques à chaque fournisseur (ex. : Microsoft SNDS et JMRP) que j'ai toujours refusées d'accomplir (les normes, c'pas pour les chiens). Des mots-clés légitimes dans le corps d'un email sont bloqués. Des liens et des PJ légitimes et sans virus sont bloqués. La cadence de fournisseurs de liste de discussion légitimes est freinée. Sitôt qu'on grossit, à peu près tous les fournisseurs emails d'envergure cassent les pieds. Microsoft et GMail sont souvent cités mais c'est également la corvée avec Orange (qui limite la cadence autant que GMail) ou SFR Business (rejet arbitraire en fonction du contenu) ou…

Beaucoup attribuent une intention malveillante aux gros fournisseurs emails : ils voudraient fermer le marché, maintenir un oligopole afin de rendre captifs les usagers de l'email et exploiter toujours plus leur vie privée (GMail analyse le contenu des emails, La Poste ou ProtonMail modifient celui des emails sortants afin d'ajouter leur pub). C'est vrai, bien sûr, mais il ne faut pas expliquer par la malveillance ce que l'on peut expliquer par l'incompétence : à grande échelle, le spam est difficile à juguler et il est possible que les gros fournisseurs emails agissent pour le Plus Grand Bien (tm), mais leur part de marché, donc l'absence de contre-pouvoir, leur permet des prises de position cavalières qui, de fait, ne sont pas remises en question en interne. Une sorte de "ça marche / ça fait le job, je cherche pas plus loin, je réfléchis pas collectif / global" prononcé par un géant. Le poids des acteurs, voilà le cœur du problème, comme bien souvent. La concentration est néfaste. Et de ça, nous tous sommes responsables (absence de formation, laisser-aller vers la facilité, etc.).

Quand j'écris qu'un serveur emails perso tourne sans douleur ni entretien, c'est donc fonction de l'investissement technique initial sus-relaté, du fait que je suis un utilisateur avancé (alias, délimiteur, etc.), que je n'ai pas une quasi-obligation de recevoir les emails du premier venu, que j'émets un très faible volume d'emails (pas d'emails transactionnels ni de listes de discussion, etc.), que je converse plutôt avec des initiés (donc j'évite de fait les pénibles genre Orange, Microsoft Hotmail / Outlook, etc.), etc. Mon constat n'est pas transposable à des organismes (association, société commerciale, administration, peu importe) qui, eux, ont vocation à être ouverts au public, qui peuvent émettre un volume conséquent d’emails légitimes, qui ont des utilisateurs lambda donc peu formés, peu rigoureux, mais exigeants, etc.

Il y a bientôt un an, cet article a beaucoup circulé. Il dit vrai, bien entendu. Mais il manque des nuances que j'ai tenté d'apporter ici. Sans compter la prédominance erronée de l'analyse économique : à l'échelle de Microsoft / Orange / Google, etc., une analyse bayésienne coûte rien, mais sur un grand volume et une diversité d’usagers, elle est inefficace (beaucoup de faux-positifs), notamment car son apprentissage dépend de chaque usager et de sa bonne volonté et foi. Je partage partiellement son avis sur les bandeaux cookies : beaucoup de traitements de données persos étaient illicites depuis longtemps. Ils ne devaient pas perdurer, mais, plutôt que de changer de modèle économique, les acteurs continuent leurs pratiques crades en essayant d’obtenir un consentement vicié, tel le premier charo venu. Les traitements devraient reposer sur des bases légales plus saines, et le consentement devrait être l'exception, pas un prétexte pour dégainer n'importe quel traitement. La seule chose blâmable est la faiblesse des régulateurs.

En fonction de l'usage, un serveur emails perso est encore vivable.

P.-S. : il y a une différence entre l'offre gratuite de Microsoft (Hotmail / Live / Outlook) et les autres (Office 365, etc.). Mon serveur s'est toujours fait écourter quand je contacte des utilisateurs d'Outlook, et l'année écoulée n'a pas fait exception, mais, comme d'habitude, j'ai reçu des réponses de deux des trois destinataires professionnels dont le nom de domaine est porté par les serveurs emails de Microsoft (aucune idée si le troisième a voulu me répondre, mais, je le suppose, demande de devis, tout ça).

J'ai déménagé mon serveur perso (pas celui qui héberge ce site web). Retour d'expérience.

Historique et problématique

Initialement, ce serveur était hébergé chez moi, sur un Raspberry Pi puis sur un OLinuXino, et raccordé proprement au réseau (condition pour avoir un serveur emails fonctionnel) avec le VPN d'un FAI associatif.

Quand ces ordinateurs ont rendu l'âme (avant les cartes SD, comme quoi), j'avais une contrainte personnelle de forte mobilité. J'ai donc hébergé ce serveur avec les autres auprès d'associations auxquelles je contribuais techniquement et financièrement, ARN et Grifon.

Début 2019, par démotivation et désespoir, j'ai quitté le monde associatif. Comme il est inconvenant de faire porter une charge de travail (héberger mon serveur) sur des bénévoles sans contribuer réellement (ne serait-ce qu'à la prise de décision), j'ai déménagé au plus simple : OVH. Ça fait le boulot pour pas cher. C'était censé être temporaire. Mais la flemme s'est installée.

Mon problème est simple : mes emails arrivent de moins en moins jusqu'à leurs destinataires. Quand j'étais auto-hébergé ou chez des assos, seuls quelques fournisseurs emails hégémoniques donc casse-couilles me rejetaient comme Microsoft. À l'inverse, ces derniers mois, je suis tricard, temporairement ou non, chez pas mal d'autres fournisseurs : Infomaniak, Octopuce (qui utilise Spamhaus), SFR (ceci dit, même les serveurs de Gandi se font rejeter), FDN (qui utilise Spamhaus sur ses anciennes listes de discussion), etc.

Deux explications :

• J'utilise IPv6. OVH attribue une unique IP à chaque client. Or, la norme est d'attribuer un réseau /64 par client. Donc les mécanismes anti-spam bloquent à cette granularité. Donc au moindre voisin (de réseau) spammeur ou mal configuré, vlam, je suis pénalisé. Je suis ainsi listé dans la liste CSS de Spamhaus. Je les ai contactés : un voisin émet en IPv6 sans AAAA ni PTR associé, donc vlam. J'ai contacté ledit voisin : aucune réponse, bien entendu. J'ai contacté l'assistance d'OVH : aucune réponse satisfaisante, bien entendu (l'attribution d'un /64 est en projet, faire un signalement sur l'adresse abuse@). J'ai procédé au signalement abuse : aucune réaction. Quand bien même il y en aurait eu, le problème reviendrait au premier voisin mal-configuré, c'est sans fin ;
  
  
• Mon IPv4 et mon domaine ne sont pas listés dans une liste de blocage (soit on fait le tour des principales, soit on trouve des testeurs multi-listes dans un moteur de recherche). En revanche, OVH est réputé pour être un gros émetteur de spam. Donc, ses réseaux /24 (ou plus grand) et/ou son numéro d'AS sont listés dans des listes de blocage. Aucune solution.

Cahier des charges

• Je veux une organisation commerciale. Je ne souhaite pas m'impliquer dans une association ni faire porter une charge de travail (héberger mon serveur) sur des bénévoles sans contribuer réellement. De plus, j'ai déjà vu des comportements douteux d'adminsys associatifs, et je n'ai pas la motivation de faire le tri. Ça exclut les CHATONS (d'autant qu'au moins la moitié d'entre eux reposent sur des gros hébergeurs style OVH, Scaleway ou Hetzner ‒ source ‒) ;
  
  
• Je veux une machine virtuelle. Cela exclut beaucoup d'hébergeurs dont O2Switch, Netim, Weboupro, etc. ;
  
  
• Je veux une offre grand-public, une commande automatisée et un espace client qui me procure de l'autonomie dans la gestion quotidienne de ma machine virtuelle. Pas de devis ni de montage spécifique à ma personne ni d'infogérance. Là encore, ce critère exclut beaucoup d'entités dont Octopuce, FullSave, Evolix, etc. ;
  
  
• Je veux une société commerciale française avec des infrastructures en France et une majorité de ses affaires en France. Deux objectifs : 1) déterminer quelle législation s'applique (une grande partie de ma vie numérique passe par ce serveur perso) ; 2) favoriser des acteurs locaux (voir critère suivant). Ce critère élimine beaucoup d'entités dont Hetzner, Infomaniak, Amen (actionnaire italien, groupe européen), IONOS (ex-1&1), Gandi (qui, au début 2023, a fusionné avec une entité néerlandaise, sans compter la somptueuse augmentation des tarifs annoncée et la fin de services cool dont les emails inclus avec un nom de domaine), Oxabox, MonoVM, etc. ;
  
  
• Je veux une entité qui n'est pas marquée au fer rouge comme hébergeant des spammeurs, et qui propose un réseau IPv6 de taille /64 au minimum (lire la fin de la section précédente pour comprendre). Cela est difficile à évaluer objectivement. J'ai utilisé UCEPROTECT et Spamhaus (qui est massivement utilisé) pour vérifier le score de l'AS et de plusieurs réseaux IP de chaque hébergeur. Les chiffres portent sur les 7 derniers jours, donc il faut surveiller quelques semaines pour avoir une vision correcte. J'ai également privilégié les petites entités. L'idée est : plus c'est petit, plus c'est confidentiel, plus ça augmente la probabilité d'éviter les spammeurs et les serveurs mal configurés. Là encore, c'est difficile à évaluer objectivement. J'ai pris en compte le chiffre d'affaires déclaré, la taille du réseau (le nombre d'adresses IP), le contenu et l'aspect du site web (j'ai une expérience qui me permet de juger grosso-modo, tel un Etchebest dans Cauchemar en cuisine). Ça exclut Scaleway (trop gros, mais score spam OK), Ikoula (risque de spam en hausse ces dernières semaines) ;
  
  
• Je veux une connectivité décente aux autres réseaux français. Pour l'évaluer, j'utilise le looking glass du NLNOG, RIPEstat, et BGP HE ;
  
  
• Je veux les services et outils usuels : paiement par prélèvement ou virement bancaire, IPv6, VNC, mode rescue, reverse IP, etc. ;
  
  
• Je privilégie une infrastructure en logiciel libre (KVM, etc.).

Candidats

• MilkyWAN : je leur ai posé deux questions techniques (modèle d'hyperviseur et existence d'un VNC) en septembre 2022, pas de réponse. J'ai bien reçu l'accusé de réception émis par leur formulaire web.

• FirstHeberg (anciennement FreeHeberg) :

  • Score spam quasi OK. Moyen mis en œuvre pour le conserver : demander un justificatif d'identité et de domicile. La loi dispose qu'un hébergeur doit collecter noms, prénoms, date et lieu de naissance, adresse postale, numéro de téléphone et adresse emails (mais les hébergeurs n'ont pas la charge de vérifier ces informations en collectant des justificatifs), donc ça ne me paraît pas être excessif ;
    
    
  • Le réseau semble avoir IELO comme transitaire principal (HE et IP Max en sus). J'en ai plutôt une bonne image (bien connecté aux réseaux français), donc ça ne m'inquiète pas ;
    
    
  • Site web et espace client épurés, pas trouzemilles scripts, feuilles de style, etc. téléchargés depuis trouzemilles prestataires. Google reCAPTCHA dans la page de contact et Google Fonts sur la page d'accueil tout de même.

• Ikoula :

  • Score spam en hausse ces dernières semaines, plus élevé que Scaleway. Un réseau blacklisté ;
    
    
  • Quelques merdes sur le site web dont jquery.
    
    
  • Rachetée par Sewan en 2021. Agglomérat de différentes sociétés française, belge, espagnole, allemande, ricaine du monde des télécoms et de l'hébergement. 130 M€ de CA en 2021 (source = societe.com), soit plus que Scaleway. On s'éloigne de la petite entité.

• PulseHeberg :

  • Site web derrière Cloudflare. Ça retire toute crédibilité. T'es hébergeur, mais t'es pas capable d'héberger ta vitrine ? Tu vantes ta capacité à résister aux DDOS, mais pas pour ton site web ? De plus, vu comment j'asticote un tas d'entité sur la non-conformité au RGPD que cela représente, laisser passer ça serait incohérent ;
    
    
  • Quelques merdes sur le site web : Google Fonts, unpkg.com, etc. ;
    
    
  • Un développement tourné vers l'international, notamment vers les États-Unis (leur site web annonce un futur centre de données à San Jose), donc un potentiel conflit de lois à cause du Cloud Act ricain.

• Ligne Web Services (LWS) :

  • Site web derrière Cloudflare ;
    
    
  • Adista en transitaire unique, ça craint un peu.

• OuiHeberg :

  • Cloudflare ;
    
    
  • Connectivité : IPv4 = que des prestataires étrangers dont j'ignore la qualité de leurs interconnexions avec les réseaux français ; IPv6 = uniquement Cogent qui s'est livrée à des guéguerres commerciales avec Google et Hurricane Electric, dont la conséquence était l'impossibilité d'accéder à ces réseaux depuis Cogent.

• OMGSERV :

  • Cloudflare ;
    
    
  • Numéro d'AS introuvable donc impossible de vérifier la réputation et la connectivité du réseau. S'adresse essentiellement aux joueurs en ligne qui sont rarement de bons adminsys, ce qui renforce ma défiance. (Sans compter Teamspeak qui facilite masse d'attaques volumétriques).

• ONETSolutions :

  • Cloudflare ;
    
    
  • Le numéro d'AS que j'ai trouvé annonce aucun préfixe IP, donc impossible de vérifier la réputation et la connectivité du réseau.
• Inulogic (anciennement Free-h) :
  • Pas d'IPv6 ;
    
    
  • Connectivité IPv4 : uniquement Cogent, ça craint.

Ordre de grandeur

Chiffres d'affaires 2021 :

• OVH : 556 millions d'euros ;
  
  
• Scaleway : 94 M€ ;
  
  
• Ikoula : 6,2 M€ (mais société d'un groupe dont la filiale française a déclaré 130 M€) ;
  
  
• FirstHeberg : 1,3 M€ (avec des activités de FAI fibre, téléphonie, etc.) ;
  
  
• PulseHeberg et LWS ne publient pas leur CA. Je n'ai pas cherché les autres entités vu qu'elles ne m'intéressent pas.

Source : societe.com.

Retenu

J'ai choisi FirstHeberg.

Concernant le port tcp/25 (email), il est bloqué uniquement en sortie et en IPv4. Mes justificatifs caviardés (j'ai conservé les seules infos légalement obligatoires, cf. ci-dessus) ont été acceptés. Contrairement à ce que prétend le site web, le port tcp/587 n'est pas bloqué.

L'espace client ne permet pas de définir un reverse IPv6, mais une demande d'assistance permet de l'obtenir.

L'assistance est plutôt réactive et les réponses sont plutôt de qualité.

Évidemment, tout n'est pas parfait :

• Propos publics éruptifs (sur le coût de l'électricité, par ex.) ou plaintifs (sur le coût des attaques DDOS il y a quelques années, là où d'autres gens du métier y voyaient une absence d'anticipation et/ou des mauvais choix techniques en connaissance de cause) ou contraire à mes convictions (sur la neutralité du réseau) tenus par le patron. (Twitter est désormais un réseau fermé, donc impossible de pointer les propos, sans compter que telle n'est pas mon intention) ;
  
  
• Lacunes techniques (VNC en panne quasiment une semaine, pas de prélèvement bancaire, la section facturation de l'espace client, IPv6 pas au même niveau d'intégration qu'IPv4, rejet des adresses emails contenant un délimiteur « + », etc.) et rédactionnelles qui entraînent de la confusion (sur le site web et l'espace client, genre écart entre ce qui est annoncé et pratiqué, comme la définition du mdp ou le déblocage du port tcp/25). J'ai remonté tout ça à l'assistance.

On verra comment ça se passe à la longue.

Procédure de migration

Mon système Debian GNU/Linux est chiffré en intégralité (sauf /boot, même si GRUB permet de s'en passer).

Même procédure que d'habitude. J'ai rencontré aucun des problèmes mentionnés. Ni partition mal copiée ni difficulté pour monter les partitions fraîchement copiées.

J'ai changé la phrase de passe du conteneur chiffré (cryptsetup luksAddKey /dev/sdX + cryptsetup luksRemoveKey /dev/sdX). J'en ai profité pour passer sans encombre à la version 2 de LUKS (cryptsetup convert --type luks2 /dev/sdX) et à l'algo de dérivation de clé argon2id (cryptsetup luksConvertKey --pbkdf argon2id /dev/sdX).

Prenant en compte la panne du VNC (cf. ci-dessus), j'ai mis en place un système me permettant de saisir la phrase de passe de mon système chiffré via SSH.

Le système de mon serveur personnel (pas celui qui héberge ce site web) est totalement chiffré (/boot est une partition indépendante même si GRUB permet de s'en passer). Au démarrage, je saisis la phrase de passe depuis le VNC proposé par l'hébergeur.

Très récemment, j'ai changé d'hébergeur. Avant mon déménagement, son VNC a été dysfonctionnel pendant quasiment une semaine. Ça a été le déclic : comment faire si je dois redémarrer mon serveur pendant une panne ou une maintenance du VNC de mon hébergeur ? Autant une panne du VNC de mon ancien hébergeur me semblait improbable ou très limitée dans le temps au nom du « too big to fail », autant une panne longue de mon nouvel hébergeur me paraît crédible. Donc il m'appartient de concevoir un plan B. (On pourra aussi argumenter qu'une connexion SSH directe sera toujours plus sécurisée que le VNC over HTTPS de l'hébergeur par la simple disparition de l'intermédiaire.)

Il est possible de demander à l'initrd de se connecter au réseau, de proposer un accès SSH (avec l'implémentation minimaliste dropbear) et un terminal (implémentation minimaliste busybox) qui permettent d'ouvrir le conteneur LUKS. J'avais lu ça chez Aeris il y a quelques années, mais on va adapter un peu.

• Installer un serveur SSH minimaliste uniquement dans l'initramfs : apt install dropbear-initramfs ;
  
  

• Ajouter sa clé publique SSH dans /etc/dropbear-initramfs/authorized_keys. L'auth par mot de passe est impossible (cela garantit la sécurité du serveur contre la force brute en cas de redémarrage inattendu suite à un plantage ou à une maintenance côté hébergeur) ;

• Créer un fichier /etc/initramfs-tools/conf.d/ip. Format : « IP=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>:<ntp0-ip> » (via) ;

  • Exemple : (je ne configure ni serveur NFS ni nom d'hôte, ni DNS, ni NTP) : IP=192.0.2.42::192.0.2.1:255.255.255.0::eth0:off ;
    
    
  • ATTENTION : contrairement à ce que dit la doc', « IP= » est en majuscule et sensible à la casse (au moins sur Debian GNU/Linux Bullseye) ;
    
    
  • IPv6 statique n'est pas disponible sans ajouter des scripts persos. Vu la criticité de l'initrd, ça ne me tente pas. Des messages ICMPv6 « Router Solicitation » sont émis par l'initrd, ce qui laisse à penser qu'IPv6 dynamique est disponible. Mais, chez tout hébergeur sérieux, le niveau 2 (ARP, NDP, DHCP, STP, etc.) est filtré ou rendu caduque, donc ça n'a pas d'intérêt.

• Reconstruire les initrd : update-initramfs -uk all ;

• On fabrique un enregistrement DNS de type SSHFP ou une entrée pour le fichier known_hosts (cela permettra d'authentifier la machine, d'être sûr qu'on causera au bon serveur SSH qui aura booté sur l'initrd). Dans les deux cas, ça nécessite de convertir la clé privée du serveur depuis le format dropbear vers une clé publique au format openssh :

  • known_hosts : ssh-keygen -y -f /dev/stdin <<< $(dropbearconvert dropbear openssh /etc/dropbear-initramfs/dropbear_rsa_host_key -). Ajouter la sortie au fichier known_hosts de la machine qui accédera au serveur ;
    
    
  • Enregistrement SSHFP : ssh-keygen -r <FQDN> -f /dev/stdin <<<$(ssh-keygen -y -f /dev/stdin 2>/dev/null <<<$(dropbearconvert dropbear openssh /etc/dropbear-initramfs/dropbear_rsa_host_key -)).
• reboot le serveur ;
  
  
• dropbear n'implémente pas toute la crypto moderne, donc, si comme moi tu blindes ta conf' client SSH, il faudra réduire tes prétentions. Cela peut se faire avec une entrée dédiée dans .ssh/config ;
  
  

• ssh root@<serveur> doit fonctionner ;

• Comme nous le dit le prompt, il suffit d'utiliser la commande cryptroot-unlock. Après la saisie de la phrase de passe, le système démarrera :

  ~ # cryptroot-unlock
  Please unlock disk sda2_crypt: 
  cryptsetup: sda2_crypt set up successfully
  ~ # Connection to 192.0.2.42 closed by remote host.
  Connection to 192.0.2.42 closed.

Visualiser / lister les prochains roulements (renouvellements) de clés DNSSEC planifiés par OpenDNSSEC : ods-enforcer rollover list.

Forcer le renouvellement / roulement / rollover des clés (en cas de compromission, par ex.) : ods-enforcer key rollover --zone <nom_zone>. On peut limiter à un type de clé (KSK ou ZSK) en ajoutant --keytype <KSK|ZSK>.

systemd-journald est conçu pour archiver puis supprimer les vieux journaux (logs) selon une politique d'occupation de l'espace de stockage détails ici.

Parfois, on a besoin de conserver un journal un certain temps, ni plus, ni moins. Exemple ? L'obligation de conservation des données de connexion qui, en France, pèse sur les opérateurs de communications et les hébergeurs. Elles doivent être conservées 1 an. En dessous, l'opérateur / l'hébergeur ne remplit pas son obligation. Au-delà, le traitement est illégal au regard du RGPD car dénué de base légale (l'obligation légale court pour 1 an, pas plus).

Exemple moins pertinent : avec un volumineux système de stockage, on se retrouve avec 4 Go de journaux qui peuvent donc remonter loin et être pénibles à exploiter. Mais dans ce cas, on préférera affiner la valeur des paramètres de journald.

Pour une politique temporelle de conservation, journald propose le paramètre MaxRetentionSec. Source. Délai après lequel un journal contenant des entrées plus vieilles que ce délai sera supprimé. Par défaut, sa valeur est 0 afin de mettre en œuvre uniquement une politique de conservation basée sur l'occupation disque.

Il faut également configurer MaxFileSec. Un journal ne peut pas stocker des entrées au-delà de cette durée (1 mois par défaut). Un nouveau journal sera créé (et, l'ancien, archivé, donc supprimable). Il faut la positionner à « 1day ». Ainsi, lors de la suppression d'un journal archivé, après 1 an, seules les entrées d'il y a 366 jours seront supprimées. De même, seules les entrées du jour seront dans le journal courant, le reste sera archivé. Sans ce paramètre, soit journald supprimera le 12^e mois (improbable), soit il conservera 1 an et 1 mois. Dans les deux cas, ça ne répond pas au besoin.

(Cette réflexion est basée sur le fait, qu'à priori, journald efface un journal en entier, pas les entrées d'un journal qui ont dépassé la date de péremption. Sa doc' consigne, pour le paramètre MaxFileSec : « However, to ensure that not too much data is lost at once when old journal files are deleted, it might make sense to change this value from the default of one month. ». Et le manuel de journalctl, pour l'action rotate, consigne : « Journal file rotation has the effect that all currently active journal files are marked as archived and renamed, so that they are never written to in future ».)

Conséquence logique : il faudra également modifier la valeur de SystemMaxFiles, car il y aura jusqu'à 1 an de journaux archivés chaque jour. Et il faudra désactiver la politique de conservation fondée sur l'occupation de l'espace de stockage (cf) sinon journald pourra supprimer des journaux récents si l'espace de stockage vient à manquer.

On peut aussi désactiver totalement ou partiellement journald (Storage). Il continuera à transmettre les journaux à rsyslog (par défaut sous Debian), et on pourra les traiter à l'ancienne avec logrotate.