Derrière ce titre un brin provocateur, et parce que les gens me reprochent souvent de ne pas laisser de trace en dehors des réseaux sociaux, faisons un article de blog rapide sur les deux problèmes finalement communs que j’ai abordé récemment : le Health Data Hub et le Play Integrity de Google.
Pour ceux du fond qui n’auraient pas tout suivi, un bref rappel des deux problèmes :
-
Pour le Health Data Hub (HDH), l’hébergement a été assigné à Microsoft malgré un avis pas très enthousiaste de la CNIL, ce qui a fait se lever une tonne de boucliers en brandissant Schrems II, qui interdit tout traitement de données personnelles sur un système américain
-
Pour le Play Integrity, c’est le fait que les applications bancaires imposent actuellement l’usage des Google Services et (tentent de) détecter et bloquer les téléphones rootés, interdisant l’accès aux utilisateurs d’OS alternatifs.
Ces deux problèmes sont pour moi au final liés et ne sont pas de la (seule) responsabilité des GAFAM. En tout cas pour ces deux cas précis. Les personnes critiquant ces décisions sont juste en train de tirer sur le mauvais cheval…
Le problème est en fait extrêmement simple : il n’existe tout simplement pas d’alternatives légalement (et j’insiste sur ce légalement) valides pour faire autre chose. Et la responsabilité n’est pas à chercher chez les GAFAM pour une fois mais… chez le législateur européen, qui n’a fait que son boulot, et les entités européennes, qui ne veulent pas le faire !
Dans le cas du HDH, la communication faite par OVH montre assez clairement que l’entreprise n’est en aucune manière capable d’accueillir le moindre projet d’envergure tout simplement parce qu’ils ne proposent aucun des outils de conformité qui sont dorénavant obligatoires avec le RGPD depuis 2016.
Pour avoir déjà dû utiliser ces services, effectivement, des obligations légales issues de préconisations ANSSI aussi simples que « R18 je n’opère pas mon réseau d’administration sur des interfaces réseaux exposées sur Internet » n’est juste pas possible à mettre en œuvre sans du bricolage hautement expérimental. Vous êtes dans le noir total pour avoir accès aux logs des firewalls matériels. Vous n’avez pas de SIEM (journalisation avancée et notification d’évènements louches) ou de IAM (politique d’accès) dignes de ce nom. Vous n’avez pas de possibilité de DNS privé.
AWS, Azure et GCP, si. Et ont même défini l’état de l’art de ce que c’est puisque ce sont eux et seulement eux qui proposent actuellement quelque chose là-dessus depuis… 13 ans ?
13 ans, c’est plus ou moins le même retard d’implémentation de S3, lancé en 2006 côté AWS mais seulement 2013 côté OVH, et encore de manière très très laborieuse à l’époque, et avec une compatiblité S3 seulement en 2022.
Impossible de voir la moindre trace de lobbying de GAFAM pour avoir rédigé le RGPD, ils y étaient même plus que farouchement opposés. Oui, les obligations dedans sont par contre actuellement remplies par eux pour leurs solutions cloud et pas par celles de nos entreprises nationales, quand elles survivent (Numergy, CloudWatt, paix à vos âmes…).
Du coup, on a le choix, ou plutôt le non-choix .
Travailler avec les US, en mettant un peu Schrems II de côté qui n’est en pratique (et c’est moi qui le dit) pas un véritable problème critique de fond (la France fait pire avec ses propres ressortissants) et en tout cas assez loin de ce que la plupart de ce que les gens pensent que c’est (on pourrait a priori lui rédiger un équivalent de de la surveillance de masse à la paranoïa généralisée) ?
Ou avec des boîtes françaises qui en pratique vont juste déployer des données sensibles sur des infras ne pouvant pas du tout répondre aux obligations légales les plus élémentaires, de contrôle d’accès, sécurisation, journalisation, détection d’intrusion, cloisonnement, défense en profondeur et j’en passe ? Coucou Viamedis ! Bonjour Almerys !
J’ai aussi vu pas mal de monde pour critiquer que les appels d’offre ont été fait sur mesure pour permettre aux seuls GAFAM de répondre.
Sérieusement, vous avez été voir le BODAAC ?
En y cherchant les appels d’offre d’équivalents de HDH, je suis tombé sur des appels d’offre que je suspecte avoir été rédigé par l’éditeur du logiciel lui-même et où l’administration lance un appel d’offre public « pour faire semblant », mais où une seule boîte en France, en Europe, voire dans le monde est en capacité de répondre : l’éditeur qui l’a rédigé.
Donc du coup, les GAFAM qui b(i)aisent la concurrence, c’est mal, mais si c’est une startup française, c’est bien ?
En dehors de la forme, j’ai aussi beaucoup de mal avec cet argument sur le fond sur ce cas précis. Encore, on parlerait de AWS lambda dans le cahier des charges, oui ça pourrait être vu comme une tentative de AWS de forcer la main sur la sélection du candidat. S3 déjà on aurait du mal à dire que c’est 100% AWS (MinIO, Ceph), mais alors SIEM, IAM ou journalisation de pare-feu, vraiment qu’on m’explique…
Pour moi, c’est juste la somme des obligations légales ou des choix initiaux (cloud au centre) qui effectivement ne laisse en pratique que 3 candidats possibles, et que pas de bol, tous américains. Et encore même pas complètement conformes (Schrems II), mais du coup en pratique plus que le néant absolu côté européen.
Le même problème s’était déjà pourtant posé plusieurs fois par le passé, avec à mon sens les mêmes mauvaises réflexions sur les mauvais problèmes. La certification des logiciels de caisse par exemple avait posé des problèmes pour les logiciels libres. Est-ce qu’on peut estimer légitime de vouloir certifier les logiciels de caisse pour éviter la fraude à la TVA ? A priori oui. Est-ce qu’on doit du coup procéder à des aménagements pour les 2 logiciels du fond qui n’ont pas les moyens de se certifier ou une gouvernance incompatible ? Vous avez 2h. Mais en tout cas, il existe plein d’autres domaines ou le changement d’obligations légales implique la disparition de ceux qui ne peuvent pas les remplir. Et on n’en avait jamais fait tout un fromage.
J’ai cité la DSP2 et les applications bancaires en introduction : c’est en train d’arriver. Spoiler : ça va encore piquer pour le libre souverain. Les article 8 et 9 de la réglementation bancaire imposent le contrôle fort des périphériques d’authentification auprès des banques (vos téléphones donc) et en particulier la détection de modifications logicielles ou la présence d’outils de debug/émulation, souvent utilisés dans des activités illicites de fraudes bancaires. Et à nouveau, les exigences imposées par le législateur me semblent légitimes : limiter la fraude de plus en plus intelligente et avancée, l’escroquerie, le siphonnage des comptes bancaires, le dropshipping… Des trucs relativement nouveaux, qui n’existaient pas encore il y a 10 ans, pas aussi massifs, pas aussi sophistiqués. Qui est actuellement capable de répondre aux exigences ? Allez, c’est ici et là. Mais on va encore crier au cartel et demander des exemptions pour faire du souverain ou du libre alors qu’on ne sait toujours pas se sortir les doigts à la place et qu’aucune ébauche de début de réflexion sur ce sujet n’existe. On préfère du LineageOS rooté récupéré sur des liens de direct download russes via un obscur forum random. Ou du FairPhone qui a arrêté les mises-à-jour de sécurité de son téléphone après 7 ans. Apple, ça a été 9 ans pour le 6S de la même année.
Je vous spoile la suite : cherchez MED-2023-019 page 92 ici. On fait quoi du coup ? On va encore demander aux législateurs de foutre des rustines pour gérer le cas du libre souverain qui ne sait toujours pas répondre à des obligations légales minimales de 2024 et continue à vivre dans le monde des bisounours de 1970 avec des dépendances logicielles obsolètes « parce que c’est trop chiant de livrer une nouvelle version tous les matins » ?
Au boulot, je fais aussi face à ça. On fait quoi du coup ? On va réclamer des trous dans la loi pour le libre et le souverain qui continuent à shiper en 2024 des trucs avec trouzmilles dépendances récupérées depuis des github yolo à coup de curl | sudo bash
ou des images docker sorties d’outre-tombe ou des bricolages qui ne juste fonctionnent pas en terme d’infra pour du projet un tant soit peu important ?
Ou alors on va vers des éditeurs logiciels qui eux ne livreront pas du soft « THERE IS NO WARRANTY FOR THE PROGRAM » et vers qui leurs clients pourront se retourner en cas de défaut (et payeront très cher leur éditeur en échange) ?
Pour qu’un organisme causant sérieusement de PCI-DSS cite officiellement du XKCD, on a quand même poussé le bouchon un poil loin…
Le libre et la souveraineté sont juste en train de devenir des arguments de médiocrité pour continuer à faire comme en 1970 sans prendre en compte les exigences inévitables de 2024. « Entente réalisée entre des entreprises juridiquement indépendantes d’un même secteur d’activité, afin de limiter la concurrence » Bizarrement, ça s’applique dorénavant aux deux camps… Le cartel n’est peut-être pas que du côté qu’on le pense et en pratique l’advocacy pour le bien collectif qui pouvait exister il y a 10 ou 20 ans sur ces deux sujets est juste en train de tourner au lobbying pur et dur pour protéger des intérêts purement privés très éloignés.
Comme j’ai dis à mon banquier l’autre jour, « c’est pas nous qui sommes mauvais clients, c’est juste vous qui fournissez un service de merde ». Si l’objectif est de tout niveler par le bas pour permettre à des entités absolument incapables de se remettre en question, d’innover et d’avancer dans le monde moderne, en particulier en s’opposant à toute mise à niveau des obligations légales qui sont pourtant l’évidence même en 2024, le résultat ne sera pas plus joli qu’avec du GAFAM américain partout.
Et donc j’aime bien les cartels. Ou pas.
Comments !