• # Organisations plutĂ´t qu'entreprises

    Posté par  . Évalué à 4 (+3/-0).

    Ça s'applique aussi aux organismes publiques.

    D'ailleurs dans la nature, je n'ai eu vent de l'utilisation de ce genre d'outil que pour un des services du premier ministre il y a 15 ans.

    • [^] # Re: Organisations plutĂ´t qu'entreprises

      Posté par  . Évalué à 3 (+2/-0).

      Utilisé depuis des années là où je travaille, et je ne suis pas ministre :-)

    • [^] # Re: Organisations plutĂ´t qu'entreprises

      Posté par  . Évalué à 2 (+0/-0).

      De mon expérience, toutes les grosses boites font ça.

      • [^] # Re: Organisations plutĂ´t qu'entreprises

        Posté par  . Évalué à 0 (+0/-1).

        Dans mon expérience, pas chez Orange, ni PSA, ni le groupe Rocher ni le groupe Mousquetaire, ni Cagemini et aucun écho ailleurs.

        L'idée est parfois émise mais…

        Misc dans son commentaire donne une bonne idée du merdier que ça peut-être à mettre en place dans des environnements qui s'efforcent de respecter la loi, et ça crée un bon gros SPOF. Il faut une énorme confiance dans les responsables du proxy (du niveau d'EDR dont on ne sépare pas les rôles) pour un bénéfice ridicule (par rapport à EDR et autres joyeusetés à la mode).

        J'imaginais que ça ne pouvait se mettre en place que sur des organisations de taille intermédiaire qui n'ont pas de bons juristes et une notion particulière de la sécurité.

        Des mandataire oui, mais chiffrant (dechiffrant le flux avant de le chiffrer pour renvoyer au navigateur qui doit être configuré pour accepter cette nouvelle clef) pratiquement jamais. Il me semble même que ce n'est plus possible pour toute une série de sites avec Firefox (et probablement d'autres navigateurs) pour lesquels il hurle si la clef ne correspond pas au site.

        Je serai curieux de savoir qui fait ça et pour quel bénéfices (dans le cas que je citais, ça s'adressait à des profils qui n'ont pas besoin de foule d'outils sur leur PC, avec droits restreint, au final le problème est déplacé et tout le monde est parano)

        • [^] # Re: Organisations plutĂ´t qu'entreprises

          Posté par  (site web personnel) . Évalué à 4 (+1/-0).

          Un endroit ou ça peut se faire, c'est sur les serveurs. Les problèmes juridiques lié à la vie privée sont quand même largement absent quand tu retires les utilisateurs, et c'est utile de savoir si un serveur a téléchargé quelque chose tout en rendant la tache d'un attaquant plus dur.

          (et squid se mets en HA sans grand souci, ça réduit le SPOF)

        • [^] # Re: Organisations plutĂ´t qu'entreprises

          Posté par  . Évalué à 3 (+1/-0). Dernière modification le 28 mars 2026 Ă  15:32.

          Dans mon expérience, pas chez […] aucun écho ailleurs.

          Si on ne sait pas ce qu'on cherche, on ne s'en aperçois pas. Car le poste de travail livré - navigateur et autorité de certification - est déjà prévu pour.

          Et je te confirme que la première que tu cites a (avait quand j'y étais) un proxy filtrant déchiffrant.

          Misc dans son commentaire donne une bonne idée du merdier que ça peut-être à mettre en place

          On peut mettre en place un proxy filtrant sans logguer les connexion. D'autant que le but premier est de bloquer le trafics illégale/dangereux/inapproprié au travail ; pas de pister les employés.

          D'ailleurs le PDF est explicite sur le déchiffrement (p9):

          Déchiffrement HTTPS
          Les solutions de filtrage d’URL peuvent nécessiter le déchiffrement HTTPS pour détecter des fichiers malveillants.
          […] elles entraînent la rupture d’un canal sécurisé et exposent des données en clair au niveau de l’équipement en charge de l’opération.
          Ainsi, lorsqu’un déchiffrement est nécessaire, celui-ci ne devrait être réalisé que sur les domaines non listés dans les listes d’exceptions et les données échangées dans les requêtes HTTPS ne devraient pas être conservées

          La seule précaution que demande ici la CNIL est de ne pas déchiffrer la connexion vers ta banque (en gros) et de ne rien logguer.

          • [^] # Re: Organisations plutĂ´t qu'entreprises

            Posté par  (site web personnel) . Évalué à 6 (+3/-0).

            La seule précaution que demande ici la CNIL est de ne pas déchiffrer la connexion vers ta banque (en gros) et de ne rien logguer.

            C'est donné beaucoup de crédit à la CNIL que de lire ce texte comme ça.

            La CNIL dit qu'elle attire l'attention sur "le fait que l’URL complète, accessible lors d’un déchiffrement HTTPS, est susceptible de donner accès à des données à caractère personnel".

            Comme dit dans mon commentaire, c'est l'IP dans les logs (et l'implication que la personne qui va lire les logs peut retrouver le poste et donc une personne) qui fait qu'il y a des "données à caractère personnel" vu que savoir qui a été ou, c'est une donnée sur une personne, c'est la définition même. Ça n'est pas l'URL qui fait que ç'est personnel, donc c'est trompeur.

            Et même si la CNIL voulait dire "des données à caractère sensible", ça serait trompeur car oui, l'URL complète est sensible, mais pas à cause du reste de l'URL, mais aussi à cause du nom d'hôte, cf mon exemple de Grindr ou du syndicat, c'est aussi trompeur.

            Et c'est pas le seul passage mal rédigé.

            Plus tôt dans le document, la CNIL dit qu'"il faut faire une AIPD" quand 2 critères sur 4 sont remplis. Sauf que dans le cadre classique du travail qui est le sujet du document comme dit au début, ("employeurs publics ou privés"), mais aussi dans le reste du document qui mentionne "activité des salariés", "Attribuer un profil aux employés", "ensemble des employés" p3, et 'politique d’entreprise" p2, tu as 1 critère rempli de base, vu que "personne vulnérable", comme le rappelle la note de bas page, ça compte les employés (je peux même donner le document exact qui en parle, §21, page 10). Donc déjà, ça, ç'est pas clair et qu'en général, c'est fait ça de façon systématique (genre sur tout le monde dans la boite), et comme j'ai dit, un nom d’hôte peut être une donnée sensible, donc sans doute 3 critères sur 4 dans la configuration classique d'un proxy classique. Donc tout le passage est trompeur.

            Il serait sans doute plus opportun de dire qu'il faut sans doute faire un AIPD tout le temps, sauf exception, et indiquer quelles exceptions, parce que la, quelqu'un qui ne connaît pas toute la jurisprudence européenne pourrait croire que seules les violations les plus flagrantes sont un souci, alors que non, ça n'est pas ce que les textes disent.

            Et c'est en voyant ce genre d'imprécision que je comprends comment la CNIL se retrouve à se faire taper sur les doigts par la CJUE. Car dans l'affaire en question, il n'y a pas eu de demande préjudicielle de sa part comme la plupart du temps (quand une APD n'est pas sure, elle peut passer l'affaire à "plus haut", comme l'a fait le Conseil d'État quand ça a été escaladé à son niveau après le refus de la CNIL).

            Ici la CNIL a refusé de regarder la demande alors que ça concernait un principe de base du RGPD, à savoir la minimisation des données. Et la SNCF a filé des excuses tellement pourries qu'on pourrait les mettre sur le marché comme fromage AOC de l'Aveyron.

            Les 2 arguments principaux de la SNCF, c’était quand même: "On a besoin de toujours demander, car on offre certains trains de nuit non mixtes" et "On a besoin de ça parce qu'on sait pas comment faire des mails respectueux sans ça, c'est pour l'image de marque".

            Dans ses conclusions, l'avocat général a pointé à juste titre que SNCF Connect envoie parfois des mails sans Mr/Mme (§49), et qu'il suffit de demander uniquement pour les trains non mixtes (§51).

            C'était pas de la haute voltige juridique que de montrer la mauvaise foi de la SNCF sur ce sujet, mais pour ça, faut regarder les plaintes, ce que la CNIL ne semble pas faire de façon routinière (comme d'autres DPAs en Europe), sans doute parce qu'on leur file pas de moyens. C'est bien joli de faire plus de lois tout le temps, mais il faut aussi plus de moyen à la justice.

  • # On est pas sorti de l'auberge

    Posté par  (site web personnel) . Évalué à 10 (+11/-0).

    Franchement, la CNIL a oublié un truc assez important sur ce coup la.

    Le RGPD a été promulgué pour harmoniser la législation sur la vie privée en Europe, et donc, dans le chapitre VII, ça parle de la cohérence entre les différents DPAs (Data Protection Autority, Autorité de protection des données en français). En gros, ce qu'une DPA décide s'applique aux autres, et si il y a différence, il faut se mettre d'accord avec le reste, voir passer devant la Cour de Justice (CJUE).

    La CNIL dit au paragraphe 4 qu'on peut décider de mettre un proxy sous la base de l'article 6, mais omets de préciser que ça tombe aussi très probablement sous le coup de l'article 9, et c'est un assez gros souci, car il faut une condition sous l'article 6 et 9 pour autoriser le traitement.

    Et on va me dire "mais pourquoi l'article 9, une url avec une date (et une IP) ne rentre pas dans les cas listés" ?

    Alors primo, une IP, si on peut relier ça à quelqu'un (et j'ose croire qu'on peut dans une entreprise), c'est une information personnelle, c'est pour ça que la CNIL en parle.

    Mais pourquoi l'article 9 ?

    Pour ça, il faut justement que je pointe un jugement de la CJUE, et une décision en Norvège. Pour la CJUE, il faut comprendre l'étendu de l'article 9 de façon large depuis l'affaire C-184/20. Ce que dit le jugement, c'est que dire "Elton John est gay" tombe sous l'article 9, mais "Elton John est marié à David Furnish" aussi.

    Ce qui est protégé par l'article 9 n'est pas que l'information précise (exemple, l'orientation sexuelle), mais aussi ce qu'on peut utiliser pour la déduire (exemple, "Jeanne et Marie sont mariées"), même si on peut pas déduire précisément l'orientation sexuelle (parce que les discriminations ne s'arrêtent pas devant l'exquise subtilité des labels contemporains sur l'orientation sexuelle), et même si on ne parle pas d'une orientation sexuelle minoritaire (parce que ça serait de la discrimination de donner des droits en moins pour les hétéros, en plus d'être contre productif vis à vis de la protection).

    Et d'ailleurs la CNIL est au courant du jugement en question vu qu'elle en parle dans un arrĂŞt de 2024.

    Mais ça s'applique aussi au domaine de la santé (également une donnée sensible), comme la même CJUE l'a décidé dans l'affaire C-21/23 en 2023. Savoir qu'une personne achète des médicaments sur le diabète, c'est une donnée de santé, même si c'est pour quelqu'un d'autre de temps en temps.

    La DPA de Norvége, suite à une plainte de NOYB, a mis Grindr à l'amende entre autre pour la vente de pub, car vu qu'il s'agit d'une application visant principalement les mecs gays/bis (comme tant d'autres), et donc savoir que quelqu'un a un compte dessus tombe sous le coup de l'article 9. L'amende est tombé en 2021, et a été confirmée en 2024 par la justice norvégienne. Je ne crois pas que Grindr a fait appel, donc c'est assez définitif.

    Ou est ce que je veux en venir ?

    La CNIL parle des logs, mais suivant ce qui est logué, on peut se retrouver avec des données couvertes par l'article 9.

    Par exemple, si un-e salarié-e va sur Grindr, par le mécanisme de cohérence que j'ai pointé et en appliquant les jugements que j'ai pointé, savoir quel machine qu'on peut relier à l’existence d'un compte utilisateur qui a été sur Grindr (vu que le proxy logue l'info, et quand on a 250 lignes, c'est assez clair que c'était pas une erreur), ça serait un traitement qui tombe sous l'article 9. Alors on peut dire qu'on ne devrait pas se connecter au travail sur Grindr ou un site de rencontre et qu'il y a les séminaires d'entreprises pour choper. Mais d'une part, ça n'est pas spécialement interdit (voir ce cas en 2013 d'une salarié qui s'est fait viré pour connexion excessive en 2009, mais dont le licenciement a été retoqué par la Cour de cassation en 2013, insistant sur le coté excessif nuisant au travail non démontré, car je rappelle qu'on a droit à des pauses), et il y a sans doute des gens qui se font chier royalement et qui le font quand même (genre, le support de niveau 1 qui attends une alerte la nuit).

    Mais pas besoin d'aller sur Grindr, ça marche aussi avec les données de santé. Poser un rdv à l’hôpital sur sa pause de travail, c'est légal pour les salariés, mais si le proxy enregistre l'info, c'est un problème pour l'employeur. Ça marche aussi avec le fait de faire parti d'un syndicat. Par exemple, aller sur le Nextcloud de son syndicat pour sauvegarder la capture d'écran d'une dinguerie de ta hiérarchie pour porter plainte, c'est légal, mais loguer l'information revient à traiter que quelqu'un est probablement membre du dit syndicat, ça serait un souci pour l'employeur. Et ça marche aussi avec les églises mais j'ai pas d'exemple.

    Donc pour traiter des infos couvertes par l'article 9, il faut une raison qui tombe dans les exceptions de l'article 9.2.

    Spoiler, sans doute aucune ne s'applique. De "c" à "j", ça va pas s'appliquer à la plupart des employeurs dans le cadre d'un proxy.

    L'exception "b", c'est pour le traitement des données par les RHs et c'est dur à relier ce cas aux logs d'un proxy. Et l'exception "a", ça va quand même être difficile de mettre un proxy obligatoire et de venir parler de consentement libre et éclairé quand on peut pas dire "non".

    Et du coup, c'est assez vite super chaud quand tu enregistres les flux des salariés. Pas parce que le réchauffement climatique est la, pas parce le RGPD peut coûter cher en Europe, mais parce ça peut envoyer en tôle en France par la magie de l'article 226-19 qui reprends presque à l'identique les critères de l'article 9 du RGPD en rajoutant l'identité de genre.

    Et bien sûr, comme y a de la prison possible, il y a l'article 40: "aller direct à la case procureur de la république, ne passez pas par la case de la CNIL".

    Mais tout ça, la CNIL a complètement oublié de le noter dans son document et le mot "sensible" est écrit une seule fois. Pourtant, c'est quand même pas trop dur de penser à des risques d'abus, c'est un peu leur boulot.

    Et si j’étais taquin, je dirais que même sans proxy, on peut avoir des soucis avec des logs DNS. Par exemple, une entreprise mets un wifi invité, les invités connectent leur tél perso, et "oups, j'ai un log qui dit qu'il y a une résolution de api.grindr.com par le tel d'un invité dans nos locaux qui a donné son email pour avoir l'accès au wifi". Ça serait dommage d'avoir ça dans le casier quand même.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.