C’est pas tant de dire que tout est foutu mais que la décision du HDH n’est pas forcément si débile que ça. Oui on peut encore réagir, mais à date, ça va être difficile. Et si tu ne veux pas accumuler du retard côté santé, faut AUSSI avancé sur le HDH.
Déjà que leur juridiction a vocation supra-nationale
Question simple : as-tu déjà vu réellement un débordement de FISA ou du Cloud Act ? La réponse est assez simple a priori : ça n’existe juste pas. Manhack avait débunké ça dans son article cité dans le mien, et les gens se font tout un patakès d’un truc qui en vrai sont juste des accès juridiques rapides comme il en existe des tonnes un peu partout dans le monde et en Europe. Ce n’est pas une porte ouverte à toutes les fenêtres.
Cet argument est juste un argument pour aller taper gratuitement sur les US sans avoir à se justifier plus que ça (et je reconnais moi-même l’utiliser en ce sens), mais sans action AUSSI côté EU, Schrems II est un non argument.
Qu’est-ce qu’un gouvernement étranger peut faire de mes données de santé ? Globalement rien.J’ai bien plus peur d’une action de mon gouvernement qui peut me foutre en zonzon quand il a envie sans avoir à se justifier que d’un gouvernement étranger qui voudrait en faire de même.
Je veux dire, quitte à choisir entre la peste et le scorbut, prends le scorbut
et achète des fruits, au final tu t'en sortiras mieux, et pour moins cher !
Je pige toujours pas l'argument moi.
Tu supposes qu’on a des fruits. On n’en a pas.
de l'autre on pourrait faire des appels à projet et des subventions, qui pour
une fois pourraient ne pas être perdus, et reviendraient moins cher. Parce que
bon, ça coûte une blinde de se faire plumer.
Ça aurait été vrai si on avait agit au départ. On a dorénavant une 15aine d’années sinon plus de retard sur les systèmes US et rattraper le retard coûtera HORRIBLEMENT plus cher que de continuer à engraisser l’Oncle Sam.
Oui, on peut encore agir, mais ça va faire VRAIMENT SA MÈRE mal.
On parle de rattraper au moins 15 à 20 ans de subventions à 2 milliards d’euro sur un seul projet pour quatre hébergeurs. Soit au bas mot une enveloppe de quelques centaines sinon milliers de milliards à foutre sur la table en quelques années. Et en provisionnant déjà les subventions à venir et à maintenir chaque année.
C’est un peu différent pour les US. Ou la Chine d’ailleurs. Ils ont fait en sorte d’avoir des entreprises nationales qui répondent à leurs besoins et ne les tiennent pas en vie sous perfusion aux soins palliatifs alors qu’elles sont totalement obsolètes. Au contraire ils injectent de l’argent pour les conserver dans la course au niveau décent attendu par l’état de l’art.
Pour faire le parallèle avec ce qu’on vit en France avec le parc nucléaire, c’est la différence entre maintenir dans la course ton fleuron industriel national en lui commandant chaque année des réacteurs en plus qui lui subventionnent les études de la prochaine génération et le maintenir sous perfusion d’argent public pour qu’il ne meurt pas parce que tu ne lui en as plus commandé depuis 20 ans et qu’il s’avère incapable d’en faire dorénavant…
Ça coûte le même pognon, sauf que dans un cas tu as de la Gen3 et tu attaques la R&D de la Gen4 et dans l’autre de la Gen2.5 où tu patauges à sortir de la Gen3…
C’est aussi tout le problème du truc, c’est que le jour où tu arrêtes la commande publique… le système s’effondre tout seul. A priori Google ou Amazon cessent d’exister tels qu’on les connaît si la commande publique disparaît.
Et oui, une fois que tu es compétitif par rapport à tout le reste, ben tu profites aussi de ta position dominante… Les Chinois et les Américains peuvent se tirer la bourre avec leur techno et envisager de striker le concurrent du marché, ils s’en foutent ils n’ont pas besoin du voisin et ça fait parti des négociations.
Quand t’es l’Europe et dépendant des 2 autres, c’est pas la même chose… Difficile de mettre dans la balance l’arrêt des imports ou des exports, t’as rien à leur proposer et ils savent que sans eux, tu crèves 🤣
Alors il n’y a pas beaucoup plus de volonté de certification de la part des éditeurs eux-mêmes hein.
C’est long, chiant, pénible, ça limite tes possibilités de développement et les entreprises préfèrent violer la loi que de la respecter, parce que sinon viser les 10% de croissance n’est plus possible…
Va demander à une boîte d’interdire à ses devs d’avoir le moindre accès à la prod. Pour quelques raisons que ce soit. Même pour debug, même pour avoir des logs. Même pour faire des déploiements. Ça va couiner. Beaucoup.
Et je sais de quoi je parle, c’est extrêmement galère au quotidien à gérer et faut encaisser la direction qui comprend pas pourquoi le moindre déploiement prend 7 jours juste pour ajouter un filtre dans un formulaire web.
Parce que tu dois avoir l’approbation de la Q/A, de la qualif PCI-DSS et les 3 paraphes de la DSI. Que les ¾ des libs disponibles sur Terre te sont interdites parce que ne passent pas les prérequis techniques minimaux.
Ajouter un lien sur le site web, ça a été 6 mois de taff, avec implication de la DSI, du responsable juridique, etc.
Après on a un énorme avantage : on a l’ACPR qui est un régulateur qui est « un poil » plus chiant que la CNIL. 2 contrôles annuels de fond en comble avec insta strike de tout ton business pendant X mois à la moindre case qui passe en rouge, ça motive assez sévère à envoyer chier la direction 🤣
Et on a 2 personnes à plein temps juste pour gérer les audits permanents.
Je ne vois aucune raison de privilégier plus les entreprises locales des entreprises étrangères. On est actuellement dans un monde globalisé où on s’en cogne un peu complètement de ta nationalité. Pourquoi est-ce qu’on irait payer plus cher un produit plus merdique juste parce qu’il est FR alors que le concurrent DE ou US fait mieux pour moins cher ?
Si encore le produit FR n’est pas foncièrement trop éloigné des caractéristiques et des coûts de la concurrence, bon ok pourquoi pas faire un petit effort pour le privilégier et payer 10% de plus pour faire local avec peu ou prou les mêmes fonctionnalités. Mais quand les écarts sont juste abyssaux…
Sans parler que typiquement, s’il y a bien un truc que t’as pas spécialement envie de voir dans les mains de ton État, c’est bien tes données de santé…
Point Godwin, mais il n’y a pas si longtemps, la Stasi aurait été ravie d’avoir juste un select à faire dans une base de données pour choper tous les handicapés, les juifs ou les homosexuels de sa population et que c’est aussi ce genre de problème qui a conduit à la fondation de la CNIL en 1978…
Il y a du coup certainement un compromis à faire à ce niveau entre favoriser du national et se protéger d’un éventuel petit problème de changement de régime politique…
Le 100% FR n’est pas non plus une balle en argent. Surtout à l’approche de 2027…
Pour l’avoir vécu en direct avec la réquisition illicite de mes machines sur décision illicite d’un juge sur impulsion illicite politique après une décente de police illicite dans le datacenter d’un hébergeur français, les avoir héberger en Allemagne ou aux Pays-Bas m’aurait éviter beaucoup d’ennuis et de frais de justice…
Il faut savoir être honnête aussi : un tel système construit par l’État risque de coûter bien trop cher pour être financé exclusivement par l’impôt. Les partenariats public-privés sont aussi là en mode « nous on peut pas vous financer intégralement, vous financez le complément et vous repartez avec les bénéfices ».
Le problème en France est effectivement surtout qu’on est très mauvais pour réellement avoir des contrats donnant-donnant et qu’on finit souvent complètement plumé par le privé.
Autant je ne suis pas pour le protectionnisme, ou en tout cas pas à outrance, mais j’y suis carrément opposé quand c’est uniquement pour sauver des éco-systèmes qui n’ont juste pas réussi du tout à se tenir à jour.
Je ne saurai dire si ça relève d’un cercle vicieux du protectionnisme (US) qui appelle le protectionnisme (EU) ou si c’est juste qu’on a totalement été à côté de nos pompes, certainement un truc entre les 2 comme toujours. Mais aujourd’hui vouloir continuer à maintenir en vie des trucs qu’on devrait plutôt euthanasier parce qu’ils arrivent très clairement au bout du rouleau, c’est quand même assez con…
On est totalement passé à côté de la réalité concrète du bordel sur plein de sujet et on le paie dorénavant très cher.
On a le même problème avec la plupart des business modèles du moment qui sont juste totalement illégaux, mais on préfère avoir des politiques qui tentent de sauver les meubles quitte à juste reculer pour encore plus mal sauter que de juste dire « déso pas déso, mais pour vous c’est la fin ».
Mais forcément, un politique qui va annoncer des millions de licenciement et la remise à plat de tout le système… c’est pas méga vendeur…
Très clairement le problème est aussi politique de ce côté. Les GAFAM sont aussi ce qu’ils sont parce que les US font de la commande publique et des subventions à mort.
L’intégralité du budget de Google est déjà rempli pour les 10 prochaines années juste avec les contrats étatiques de l’armée américaine… 9 milliards de dollars à se partager entre les 4 fournisseurs cloud américains rien que pour le budget 2020 du JWCC. Etc.
Forcément que tu peux innover…
Être certifié n’est pas une garantie de ne pas se faire trouver.
Ne pas être certifié est l’assurance d’avoir des problèmes.
Les certifications, surtout en terme de sécurité quand on parle de PCI-DSS ou HDS sont quand même autrement moins bullshit que certaines autres et imposent surtout un minimum vital de respect de l’état de l’art.
Ce n’est par contre effectivement pas une garantie d’aucune sorte sur la qualité du truc derrière.
Ah oui, comme dit aussi dans mon article, c’est le cumul des exigences qui posent aussi problème. Par exemple sur les 117 hébergeurs, combien sont aussi compatibles avec l’orientation obligatoire des projets étatiques du moment (« cloud au centre ») qui impose une certification SecNumCloud en complément ?
Et tu peux aussi demander à InterHop, ils utilisent un hébergeur HDS mais ont aussi eu à mettre en place des procédures très lourdes de leur côté, que ce soit en terme de code, d’automatisation, d’isolement réseau, etc. La certification HDS de l’hébergeur n’a été que l’étape initiale obligatoire, et pas du tout la balle en argent…
HDS qui n’est qu’un des certifications nécessaires pour faire tourner un tel projet.
Manipuler des données de santé implique être HDS. Ne nous trompons pas dans la contraposée, être juste HDS n’implique pas de pouvoir automatiquement manipuler des données de santé, ne pas être HDS t’interdit de traiter un tel projet.
Mais être HDS ne suffit pas. Tu dois aussi possiblement être ISO-27001, PCI-DSS, RGPD, DSA, SecNumCloud et j’en passe possiblement d’autres.
Ici HDS n’est pas le seul critère, il y a au moins le RGPD (vu que données perso) et SecNumCloud (vu que politique cloud au centre de l’État) aussi.
Modulo que ce n’est pas du deb/debian, ça coche tout le reste des cases et tu as du KDE au poil, natif et récent (c’est en cours de préparation de KDE 6 là).
Les commerçants ne veulent pas de cette solution parce qu’à la moindre erreur sur le parcours côté banque, ils ont perdu le client (pas de moyen de garantir que tu reviens sur la page du marchand à un moment). L’iframe te permet dans tous les cas de revenir chez le marchand (généralement un bouton quelque part pour relancer une tentative de paiement) vu que tu ne le quittes jamais.
En matière de paiement en ligne, les demandes de la sécurité informatique devraient être considérées comme des ordres non négociables, prioritaires sur tout le reste.
Justement. L’iframe est là pour ça.
Il ne faut SURTOUT PAS que ton n° de CB se retrouve sur une page sous le contrôle du marchand à un moment donné, parce que le marchand n’est pas certifié ACPR ni audité PCI/DSS.
Sans iframe, le marchand aurait accès à ton n° de CB puisque le formulaire serait de son côté et qu’il devrait a minima le transmettre ensuite au PSP.
L’iframe te permet de saisir l’information sur un domaine contrôlé par le PSP et non par le marchand, et donc te garantie un environnement certifié PCI/DSS (le PSP dispose d’un agrément ACPR et est audité PCI/DSS chaque année).
En fait c’est très souvent refusé par le marchand et pour une bonne/mauvaise raison : ça casse complètement son tunnel de paiement (« mes stats d’audience !!!! ») et ça conduit à une très mauvaise intégration sur le site web.
Tu passes successivement sur 3 sites avec des rendus différents, site marchand, site psp pour les données bancaires, site banque porteur pour le 3DS et re site marchand à la fin, avec 3 expériences utilisateurs difféntes et 3 thèmes différents.
C’est refusé par la très très très très grande majorité des sites marchands pour tout un tas de raisons bonnes ou mauvaises. Au moindre problème tu ne reviens pas facilement sur le site marchand par exemple, tu ne peux plus facilement modifier ton panier au tout dernier moment, c’est difficile de te placer des produits « supplémentaires » en cours de funnel, etc.
À #taff, on ne propose principalement que de l’intégration par redirection, et on se fait taper dessus en permanence par les marchands qui veulent de l’intégration iframe voire carrément des frameworks JS d’intégration (« seamless UX », avec juste des champs de formulaires iframisés pour une intégration parfaite avec l’écosystème du marchand)
Les iframes sont là parce que la page de départ n’a PAS LE DROIT d’avoir accès aux données de cette iframe. C’est un niveau d’isolation qui te permet par exemple de saisir ton n° de CB sur une infrastructure PCI-DSS (c’est obligatoire) alors que le site de ton marchand est un vulgaire prestashop moisi avec 36 failles de sécurité et en PHP-mutu sur une infra virtualisée.
Seuls les gros comptes marchands sont eux-même habilités PCI-DSS et peuvent du coup manipuler les données bancaires (n° de CB, date d’expiration et CVV).
Le problème est même double dans le cas de 3DS, parce que ce n’est pas l’interface de la banque ou du PSP du marchand qui doit s’ouvrir, mais celle de la banque du porteur, pour validation de la 2FA.
Du coup tu as site marchand -> banque/PSP du marchand -> banque/PSP du porteur en cascade.
C’est une solution loin d’être parfaitement étanche (un site pété pourrait faire de la merde avec ses iframes) mais dans le cas nominal, le site marchand n’a du coup pas accès aux données de CB du porteur et le PSP du marchand pas accès aux données 2FA DSP2 du porteur.
Donc « les banques ne peuvent pas utiliser du TOTP simple parce que c'est illégal », je ne pense pas que ce soit vrai, en tout cas pas de façon aussi simpliste.
Les banques ne le font pas parce qu’elles sont empêtrées justement dans le bourbier technologique qu’elles ont elles-mêmes demandé (et pour une mauvaise raison : miner le terrain lors de l’arrivée des agrégateurs bancaires).
3DS est actuellement « facultatif » au sens où un commerçant peut effectivement décider de ne pas demander de 3DS. Il endosse alors 100% de la responsabilité de la fraude et a obligation de rembourser le client à la moindre contestation.
Toutes les banques ne l’autorisent pas, et l’acceptation du paiement est conditionné à ce que la banque du porteur lui permet (si tu fais une demande sans 3DS sur une carte 3DS only, ton paiement sera rejeté en code A1 Repli VADS https://doc-api.centralpay.net/les-codes-de-retour-d-autorisation-bancaire).
Le droit de faire de la transaction sans 3DS dépend de négociation avec ta banque, de si tu as un faible taux de contestation, de ton volume de vente, etc. Tout le monde n’a pas le droit de le faire.
Ben non. Le formulaire dans lequel on rentre un OTP est une page de la banque, qui précise justement le montant et le commerçant.
Ce n’est pas légal actuellement.
L’info doit bien être présente à côté de l’OTP et non sur la page de saisie (qui peut venir effectivement de n’importe où et n’est donc pas réputée contractuelle).
L’info de contexte doit être routée « out of band » par ta banque directement à toi et ne peut pas venir du site du vendeur (qui peut injecter ce qu’il veut où il veut).
Compte tenu des avantages et des inconvénients, la grille de nombres arrive très loin devant tous les autres. À se demander pourquoi les banques ne proposent pas tout simplement cela, ne serait-ce qu'aux clients qui en font la demande, plutôt que d'acheter des boîtiers TOTP.
La raison est très simple et fait que beaucoup (sinon tous) des moyens listés sont juste… illégaux ?
DSP2 impose une 2FA contextuelle, aka qu’il soit impossible de procéder à un MITM par un site de phishing ou de drop shipping (l’objectif est que tu puisses être certain du montant et du destinataire de la transaction et que tu ne vas pas filer une 2FA qui va en vrai te débiter 2000€ chez un revendeur chinois obscur au lieu de 2€ chez Ebay).
Le moyen de 2FA doit afficher obligatoirement le montant et le destinataire à côté de l’OTP de manière à ce que l’utilisateur ne puisse pas les ignorer. Il est réputé les avoir vérifier avant de communiquer l’OTP.
Tous les moyens offline sont donc de facto illicites.
C’est aussi ça qui « oblige » les banques à des applis mobiles (nécessiter d’accès à internet pour récupérer l’info contextuelle) et à imposer la vérification du root (appli pas officielle = plus de garantie de l’affichage du contexte à côté de la 2FA ou modification possible des données.
Les boîtiers dédiés coûtent trop chers vu la nécessité de connectivité et d’affichage, de perte, de casse, etc. D’où le passage au tout mobile.
Dans tous les cas oui, l’entreprise est responsable de par le RGPD et le fait qu’elle aurait du mettre en place les moyens techniques et opérationnels pour l’empêcher.
La vraie question à se poser est surtout : est-ce que toi tu es responsable.
En effet l’un n’empêche pas l’autre et tu peux très bien avoir le salarié ET l’entreprise de considérés comme responsable et condamnés pour ça.
L’exemple est extrême avec un salarié qui a volontairement fuité des données, mais les deux ont fini condamnés, le salarié pour la fuite et l’entreprise pour « responsable du fait d’autrui ».
Tu serais éventuellement aussi responsable si tu n’avais pas tenu compte des préconisations de ton RSSI, mais sinon non.
Ceci aide à comprendre la notion d'"intéret légitime"
Cette notion est très mal comprise généralement, et les exemples donnés sont à mon sens justement de très mauvais exemples puisque devraient relever du strict consentement.
Pour pouvoir se prévaloir de la base légale « intérêt légitime », il faut 1- avoir un intérêt légitime 2- passer le triple test de balance des droits.
Le 1 est évident mais tout le monde oublie le 2. Avoir un intérêt légitime ne suffit pas à pouvoir utiliser cette base légale.
Le triple test consiste en :
1- finalité : démontrer formellement l’existence de l’intérêt légitime, en particulier que tu ne sais pas faire autrement
2- nécessité : analyser l’impact sur les droits de la personne concernée, pour vérifier que l’intrusion sur la vie privée n’est pas trop importante et que la solution retenue est celle minimisant le plus les informations collectés
3- proportionnalité : faire l’étude de la balance entre 1 & 2 pour voir si l’effet n’est pas vraiment trop important par rapport à l’impact
Il suffit d’une seule étape en rouge pour que la base légale « intérêt légitime » ne puisse pas être retenue et qu’on doit se reporter sur le strict consentement, même si l’intérêt légitime, lui, existe réellement éventuellement.
Typiquement dans le cas de la publicité en ligne, 1 est souvent complètement inexistant (mesurer des perfs qui ne servent à rien en pratique), 2 est souvent trop important et 3 dans tous les cas pas du tout équilibré.
Je suppose que dans les cas cités précédemment, la plupart ne supporterait pas ce passage du triple test… et devrait donc relever du consentement.
Cela dit je ne comprend pas on donne le choix de consentement pour intéret légitime alors que par définition, lorsque l'intéret est légitime, pas besoin du consentement …
La base légale « intérêt légitime » suppose l’existence d’un droit d’opposition (en opt-out, et non en opt-in comme le consentement), du coup ils l’ont peut-être (mal) implémenté comme ça.
Là, on parle d'une adresse e-mail, utilisée à des fins de communication, adresse e-mail non obligatoire.
C’est pareil, même justification légale. Une plainte finirait de la même manière.
Droit de rectification, etc. Les fondements juridiques sont les mêmes.
Et peu importe que ça soit facultatif ou non, à partir du moment où il y a un champ, qui plus est quand la contrainte fonctionnelle est à l’opposée de la réalité technique.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 1.
C’est pas tant de dire que tout est foutu mais que la décision du HDH n’est pas forcément si débile que ça. Oui on peut encore réagir, mais à date, ça va être difficile. Et si tu ne veux pas accumuler du retard côté santé, faut AUSSI avancé sur le HDH.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -4.
Question simple : as-tu déjà vu réellement un débordement de FISA ou du Cloud Act ? La réponse est assez simple a priori : ça n’existe juste pas. Manhack avait débunké ça dans son article cité dans le mien, et les gens se font tout un patakès d’un truc qui en vrai sont juste des accès juridiques rapides comme il en existe des tonnes un peu partout dans le monde et en Europe. Ce n’est pas une porte ouverte à toutes les fenêtres.
Cet argument est juste un argument pour aller taper gratuitement sur les US sans avoir à se justifier plus que ça (et je reconnais moi-même l’utiliser en ce sens), mais sans action AUSSI côté EU, Schrems II est un non argument.
Qu’est-ce qu’un gouvernement étranger peut faire de mes données de santé ? Globalement rien.J’ai bien plus peur d’une action de mon gouvernement qui peut me foutre en zonzon quand il a envie sans avoir à se justifier que d’un gouvernement étranger qui voudrait en faire de même.
Tu supposes qu’on a des fruits. On n’en a pas.
Ça aurait été vrai si on avait agit au départ. On a dorénavant une 15aine d’années sinon plus de retard sur les systèmes US et rattraper le retard coûtera HORRIBLEMENT plus cher que de continuer à engraisser l’Oncle Sam.
Oui, on peut encore agir, mais ça va faire VRAIMENT SA MÈRE mal.
On parle de rattraper au moins 15 à 20 ans de subventions à 2 milliards d’euro sur un seul projet pour quatre hébergeurs. Soit au bas mot une enveloppe de quelques centaines sinon milliers de milliards à foutre sur la table en quelques années. Et en provisionnant déjà les subventions à venir et à maintenir chaque année.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 1.
C’est un peu différent pour les US. Ou la Chine d’ailleurs. Ils ont fait en sorte d’avoir des entreprises nationales qui répondent à leurs besoins et ne les tiennent pas en vie sous perfusion aux soins palliatifs alors qu’elles sont totalement obsolètes. Au contraire ils injectent de l’argent pour les conserver dans la course au niveau décent attendu par l’état de l’art.
Pour faire le parallèle avec ce qu’on vit en France avec le parc nucléaire, c’est la différence entre maintenir dans la course ton fleuron industriel national en lui commandant chaque année des réacteurs en plus qui lui subventionnent les études de la prochaine génération et le maintenir sous perfusion d’argent public pour qu’il ne meurt pas parce que tu ne lui en as plus commandé depuis 20 ans et qu’il s’avère incapable d’en faire dorénavant…
Ça coûte le même pognon, sauf que dans un cas tu as de la Gen3 et tu attaques la R&D de la Gen4 et dans l’autre de la Gen2.5 où tu patauges à sortir de la Gen3…
C’est aussi tout le problème du truc, c’est que le jour où tu arrêtes la commande publique… le système s’effondre tout seul. A priori Google ou Amazon cessent d’exister tels qu’on les connaît si la commande publique disparaît.
Et oui, une fois que tu es compétitif par rapport à tout le reste, ben tu profites aussi de ta position dominante… Les Chinois et les Américains peuvent se tirer la bourre avec leur techno et envisager de striker le concurrent du marché, ils s’en foutent ils n’ont pas besoin du voisin et ça fait parti des négociations.
Quand t’es l’Europe et dépendant des 2 autres, c’est pas la même chose… Difficile de mettre dans la balance l’arrêt des imports ou des exports, t’as rien à leur proposer et ils savent que sans eux, tu crèves 🤣
[^] # Re: Il n'a pas trop cherché
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 0.
Alors il n’y a pas beaucoup plus de volonté de certification de la part des éditeurs eux-mêmes hein.
C’est long, chiant, pénible, ça limite tes possibilités de développement et les entreprises préfèrent violer la loi que de la respecter, parce que sinon viser les 10% de croissance n’est plus possible…
Va demander à une boîte d’interdire à ses devs d’avoir le moindre accès à la prod. Pour quelques raisons que ce soit. Même pour debug, même pour avoir des logs. Même pour faire des déploiements. Ça va couiner. Beaucoup.
Et je sais de quoi je parle, c’est extrêmement galère au quotidien à gérer et faut encaisser la direction qui comprend pas pourquoi le moindre déploiement prend 7 jours juste pour ajouter un filtre dans un formulaire web.
Parce que tu dois avoir l’approbation de la Q/A, de la qualif PCI-DSS et les 3 paraphes de la DSI. Que les ¾ des libs disponibles sur Terre te sont interdites parce que ne passent pas les prérequis techniques minimaux.
Ajouter un lien sur le site web, ça a été 6 mois de taff, avec implication de la DSI, du responsable juridique, etc.
Après on a un énorme avantage : on a l’ACPR qui est un régulateur qui est « un poil » plus chiant que la CNIL. 2 contrôles annuels de fond en comble avec insta strike de tout ton business pendant X mois à la moindre case qui passe en rouge, ça motive assez sévère à envoyer chier la direction 🤣
Et on a 2 personnes à plein temps juste pour gérer les audits permanents.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -2.
Je ne vois aucune raison de privilégier plus les entreprises locales des entreprises étrangères. On est actuellement dans un monde globalisé où on s’en cogne un peu complètement de ta nationalité. Pourquoi est-ce qu’on irait payer plus cher un produit plus merdique juste parce qu’il est FR alors que le concurrent DE ou US fait mieux pour moins cher ?
Si encore le produit FR n’est pas foncièrement trop éloigné des caractéristiques et des coûts de la concurrence, bon ok pourquoi pas faire un petit effort pour le privilégier et payer 10% de plus pour faire local avec peu ou prou les mêmes fonctionnalités. Mais quand les écarts sont juste abyssaux…
Sans parler que typiquement, s’il y a bien un truc que t’as pas spécialement envie de voir dans les mains de ton État, c’est bien tes données de santé…
Point Godwin, mais il n’y a pas si longtemps, la Stasi aurait été ravie d’avoir juste un select à faire dans une base de données pour choper tous les handicapés, les juifs ou les homosexuels de sa population et que c’est aussi ce genre de problème qui a conduit à la fondation de la CNIL en 1978…
Il y a du coup certainement un compromis à faire à ce niveau entre favoriser du national et se protéger d’un éventuel petit problème de changement de régime politique…
Le 100% FR n’est pas non plus une balle en argent. Surtout à l’approche de 2027…
Pour l’avoir vécu en direct avec la réquisition illicite de mes machines sur décision illicite d’un juge sur impulsion illicite politique après une décente de police illicite dans le datacenter d’un hébergeur français, les avoir héberger en Allemagne ou aux Pays-Bas m’aurait éviter beaucoup d’ennuis et de frais de justice…
[^] # Re: L'auteur oublie l'essentiel...
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 1.
Il faut savoir être honnête aussi : un tel système construit par l’État risque de coûter bien trop cher pour être financé exclusivement par l’impôt. Les partenariats public-privés sont aussi là en mode « nous on peut pas vous financer intégralement, vous financez le complément et vous repartez avec les bénéfices ».
Le problème en France est effectivement surtout qu’on est très mauvais pour réellement avoir des contrats donnant-donnant et qu’on finit souvent complètement plumé par le privé.
[^] # Re: L'auteur oublie l'essentiel...
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -2.
Autant je ne suis pas pour le protectionnisme, ou en tout cas pas à outrance, mais j’y suis carrément opposé quand c’est uniquement pour sauver des éco-systèmes qui n’ont juste pas réussi du tout à se tenir à jour.
Je ne saurai dire si ça relève d’un cercle vicieux du protectionnisme (US) qui appelle le protectionnisme (EU) ou si c’est juste qu’on a totalement été à côté de nos pompes, certainement un truc entre les 2 comme toujours. Mais aujourd’hui vouloir continuer à maintenir en vie des trucs qu’on devrait plutôt euthanasier parce qu’ils arrivent très clairement au bout du rouleau, c’est quand même assez con…
On est totalement passé à côté de la réalité concrète du bordel sur plein de sujet et on le paie dorénavant très cher.
On a le même problème avec la plupart des business modèles du moment qui sont juste totalement illégaux, mais on préfère avoir des politiques qui tentent de sauver les meubles quitte à juste reculer pour encore plus mal sauter que de juste dire « déso pas déso, mais pour vous c’est la fin ».
Mais forcément, un politique qui va annoncer des millions de licenciement et la remise à plat de tout le système… c’est pas méga vendeur…
[^] # Re: L'auteur oublie l'essentiel...
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 3.
Très clairement le problème est aussi politique de ce côté. Les GAFAM sont aussi ce qu’ils sont parce que les US font de la commande publique et des subventions à mort.
L’intégralité du budget de Google est déjà rempli pour les 10 prochaines années juste avec les contrats étatiques de l’armée américaine… 9 milliards de dollars à se partager entre les 4 fournisseurs cloud américains rien que pour le budget 2020 du JWCC. Etc.
Forcément que tu peux innover…
[^] # Re: Il n'a pas trop cherché
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 1.
Être certifié n’est pas une garantie de ne pas se faire trouver.
Ne pas être certifié est l’assurance d’avoir des problèmes.
Les certifications, surtout en terme de sécurité quand on parle de PCI-DSS ou HDS sont quand même autrement moins bullshit que certaines autres et imposent surtout un minimum vital de respect de l’état de l’art.
Ce n’est par contre effectivement pas une garantie d’aucune sorte sur la qualité du truc derrière.
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 2.
Je valide que je ne porte vraiment pas les GAFAM dans mon cœur 🤣
[^] # Re: Il n'a pas trop cherché
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 4.
Ah oui, comme dit aussi dans mon article, c’est le cumul des exigences qui posent aussi problème. Par exemple sur les 117 hébergeurs, combien sont aussi compatibles avec l’orientation obligatoire des projets étatiques du moment (« cloud au centre ») qui impose une certification SecNumCloud en complément ?
[^] # Re: Il n'a pas trop cherché
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à 4.
Et tu peux aussi demander à InterHop, ils utilisent un hébergeur HDS mais ont aussi eu à mettre en place des procédures très lourdes de leur côté, que ce soit en terme de code, d’automatisation, d’isolement réseau, etc. La certification HDS de l’hébergeur n’a été que l’étape initiale obligatoire, et pas du tout la balle en argent…
[^] # Re: Il n'a pas trop cherché
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1.
HDS qui n’est qu’un des certifications nécessaires pour faire tourner un tel projet.
Manipuler des données de santé implique être HDS. Ne nous trompons pas dans la contraposée, être juste HDS n’implique pas de pouvoir automatiquement manipuler des données de santé, ne pas être HDS t’interdit de traiter un tel projet.
Mais être HDS ne suffit pas. Tu dois aussi possiblement être ISO-27001, PCI-DSS, RGPD, DSA, SecNumCloud et j’en passe possiblement d’autres.
Ici HDS n’est pas le seul critère, il y a au moins le RGPD (vu que données perso) et SecNumCloud (vu que politique cloud au centre de l’État) aussi.
# Arch ?
Posté par Aeris (site web personnel) . En réponse au journal Ma version rêvée de Debian. Évalué à 9.
Modulo que ce n’est pas du deb/debian, ça coche tout le reste des cases et tu as du KDE au poil, natif et récent (c’est en cours de préparation de KDE 6 là).
# La France avance aussi
Posté par Aeris (site web personnel) . En réponse au journal Copie d'une pièce d'identité. Évalué à 10.
Le gouvernement FR bosse aussi sur le sujet et une 1ère version d’un outil en ligne est disponible ici : https://filigrane.beta.gouv.fr/
[^] # Re: Le pourquoi du comment
Posté par Aeris (site web personnel) . En réponse au journal Les banques et l'authentification à deux facteurs. Évalué à 3.
Les commerçants ne veulent pas de cette solution parce qu’à la moindre erreur sur le parcours côté banque, ils ont perdu le client (pas de moyen de garantir que tu reviens sur la page du marchand à un moment). L’iframe te permet dans tous les cas de revenir chez le marchand (généralement un bouton quelque part pour relancer une tentative de paiement) vu que tu ne le quittes jamais.
[^] # Re: Le pourquoi du comment
Posté par Aeris (site web personnel) . En réponse au journal Les banques et l'authentification à deux facteurs. Évalué à 1.
Justement. L’iframe est là pour ça.
Il ne faut SURTOUT PAS que ton n° de CB se retrouve sur une page sous le contrôle du marchand à un moment donné, parce que le marchand n’est pas certifié ACPR ni audité PCI/DSS.
Sans iframe, le marchand aurait accès à ton n° de CB puisque le formulaire serait de son côté et qu’il devrait a minima le transmettre ensuite au PSP.
L’iframe te permet de saisir l’information sur un domaine contrôlé par le PSP et non par le marchand, et donc te garantie un environnement certifié PCI/DSS (le PSP dispose d’un agrément ACPR et est audité PCI/DSS chaque année).
[^] # Re: Le pourquoi du comment
Posté par Aeris (site web personnel) . En réponse au journal Les banques et l'authentification à deux facteurs. Évalué à 3. Dernière modification le 15 juin 2023 à 22:50.
En fait c’est très souvent refusé par le marchand et pour une bonne/mauvaise raison : ça casse complètement son tunnel de paiement (« mes stats d’audience !!!! ») et ça conduit à une très mauvaise intégration sur le site web.
Tu passes successivement sur 3 sites avec des rendus différents, site marchand, site psp pour les données bancaires, site banque porteur pour le 3DS et re site marchand à la fin, avec 3 expériences utilisateurs difféntes et 3 thèmes différents.
C’est refusé par la très très très très grande majorité des sites marchands pour tout un tas de raisons bonnes ou mauvaises. Au moindre problème tu ne reviens pas facilement sur le site marchand par exemple, tu ne peux plus facilement modifier ton panier au tout dernier moment, c’est difficile de te placer des produits « supplémentaires » en cours de funnel, etc.
À #taff, on ne propose principalement que de l’intégration par redirection, et on se fait taper dessus en permanence par les marchands qui veulent de l’intégration iframe voire carrément des frameworks JS d’intégration (« seamless UX », avec juste des champs de formulaires iframisés pour une intégration parfaite avec l’écosystème du marchand)
[^] # Re: Le pourquoi du comment
Posté par Aeris (site web personnel) . En réponse au journal Les banques et l'authentification à deux facteurs. Évalué à 5. Dernière modification le 14 juin 2023 à 23:53.
Les iframes sont là parce que la page de départ n’a PAS LE DROIT d’avoir accès aux données de cette iframe. C’est un niveau d’isolation qui te permet par exemple de saisir ton n° de CB sur une infrastructure PCI-DSS (c’est obligatoire) alors que le site de ton marchand est un vulgaire prestashop moisi avec 36 failles de sécurité et en PHP-mutu sur une infra virtualisée.
Seuls les gros comptes marchands sont eux-même habilités PCI-DSS et peuvent du coup manipuler les données bancaires (n° de CB, date d’expiration et CVV).
Le problème est même double dans le cas de 3DS, parce que ce n’est pas l’interface de la banque ou du PSP du marchand qui doit s’ouvrir, mais celle de la banque du porteur, pour validation de la 2FA.
Du coup tu as site marchand -> banque/PSP du marchand -> banque/PSP du porteur en cascade.
C’est une solution loin d’être parfaitement étanche (un site pété pourrait faire de la merde avec ses iframes) mais dans le cas nominal, le site marchand n’a du coup pas accès aux données de CB du porteur et le PSP du marchand pas accès aux données 2FA DSP2 du porteur.
[^] # Re: Le pourquoi du comment
Posté par Aeris (site web personnel) . En réponse au journal Les banques et l'authentification à deux facteurs. Évalué à 4.
Les banques s’en cognent actuellement de la légalité malheureusement (ou heureusement selon certains). Les SMS OTP auraient du être éradiqué du marché depuis déjà 5 ans.
https://www.eba.europa.eu/single-rule-book-qa/-/qna/view/publicId/2018_4039
Les banques ne le font pas parce qu’elles sont empêtrées justement dans le bourbier technologique qu’elles ont elles-mêmes demandé (et pour une mauvaise raison : miner le terrain lors de l’arrivée des agrégateurs bancaires).
3DS est actuellement « facultatif » au sens où un commerçant peut effectivement décider de ne pas demander de 3DS. Il endosse alors 100% de la responsabilité de la fraude et a obligation de rembourser le client à la moindre contestation.
Toutes les banques ne l’autorisent pas, et l’acceptation du paiement est conditionné à ce que la banque du porteur lui permet (si tu fais une demande sans 3DS sur une carte 3DS only, ton paiement sera rejeté en code A1 Repli VADS https://doc-api.centralpay.net/les-codes-de-retour-d-autorisation-bancaire).
Le droit de faire de la transaction sans 3DS dépend de négociation avec ta banque, de si tu as un faible taux de contestation, de ton volume de vente, etc. Tout le monde n’a pas le droit de le faire.
[^] # Re: Le pourquoi du comment
Posté par Aeris (site web personnel) . En réponse au journal Les banques et l'authentification à deux facteurs. Évalué à 3.
Ce n’est pas légal actuellement.
L’info doit bien être présente à côté de l’OTP et non sur la page de saisie (qui peut venir effectivement de n’importe où et n’est donc pas réputée contractuelle).
L’info de contexte doit être routée « out of band » par ta banque directement à toi et ne peut pas venir du site du vendeur (qui peut injecter ce qu’il veut où il veut).
# Le pourquoi du comment
Posté par Aeris (site web personnel) . En réponse au journal Les banques et l'authentification à deux facteurs. Évalué à 8. Dernière modification le 14 juin 2023 à 00:15.
La raison est très simple et fait que beaucoup (sinon tous) des moyens listés sont juste… illégaux ?
DSP2 impose une 2FA contextuelle, aka qu’il soit impossible de procéder à un MITM par un site de phishing ou de drop shipping (l’objectif est que tu puisses être certain du montant et du destinataire de la transaction et que tu ne vas pas filer une 2FA qui va en vrai te débiter 2000€ chez un revendeur chinois obscur au lieu de 2€ chez Ebay).
Le moyen de 2FA doit afficher obligatoirement le montant et le destinataire à côté de l’OTP de manière à ce que l’utilisateur ne puisse pas les ignorer. Il est réputé les avoir vérifier avant de communiquer l’OTP.
Tous les moyens offline sont donc de facto illicites.
C’est aussi ça qui « oblige » les banques à des applis mobiles (nécessiter d’accès à internet pour récupérer l’info contextuelle) et à imposer la vérification du root (appli pas officielle = plus de garantie de l’affichage du contexte à côté de la 2FA ou modification possible des données.
Les boîtiers dédiés coûtent trop chers vu la nécessité de connectivité et d’affichage, de perte, de casse, etc. D’où le passage au tout mobile.
# Oui mais ce n’est pas la bonne question
Posté par Aeris (site web personnel) . En réponse au journal L'entreprise est-elle responsable des fuites de données dans le cadre du télétravail ?. Évalué à 7. Dernière modification le 19 décembre 2022 à 21:03.
Dans tous les cas oui, l’entreprise est responsable de par le RGPD et le fait qu’elle aurait du mettre en place les moyens techniques et opérationnels pour l’empêcher.
La vraie question à se poser est surtout : est-ce que toi tu es responsable.
En effet l’un n’empêche pas l’autre et tu peux très bien avoir le salarié ET l’entreprise de considérés comme responsable et condamnés pour ça.
L’exemple est extrême avec un salarié qui a volontairement fuité des données, mais les deux ont fini condamnés, le salarié pour la fuite et l’entreprise pour « responsable du fait d’autrui ».
Tu serais éventuellement aussi responsable si tu n’avais pas tenu compte des préconisations de ton RSSI, mais sinon non.
[^] # Re: Une explication de la CNIL sur "l'intéret légitime"
Posté par Aeris (site web personnel) . En réponse au journal RGPD, bannieres de configuration des préférences cookies et "intéret légitime". Évalué à 10.
Cette notion est très mal comprise généralement, et les exemples donnés sont à mon sens justement de très mauvais exemples puisque devraient relever du strict consentement.
Pour pouvoir se prévaloir de la base légale « intérêt légitime », il faut 1- avoir un intérêt légitime 2- passer le triple test de balance des droits.
Le 1 est évident mais tout le monde oublie le 2. Avoir un intérêt légitime ne suffit pas à pouvoir utiliser cette base légale.
Le triple test consiste en :
1- finalité : démontrer formellement l’existence de l’intérêt légitime, en particulier que tu ne sais pas faire autrement
2- nécessité : analyser l’impact sur les droits de la personne concernée, pour vérifier que l’intrusion sur la vie privée n’est pas trop importante et que la solution retenue est celle minimisant le plus les informations collectés
3- proportionnalité : faire l’étude de la balance entre 1 & 2 pour voir si l’effet n’est pas vraiment trop important par rapport à l’impact
Il suffit d’une seule étape en rouge pour que la base légale « intérêt légitime » ne puisse pas être retenue et qu’on doit se reporter sur le strict consentement, même si l’intérêt légitime, lui, existe réellement éventuellement.
Typiquement dans le cas de la publicité en ligne, 1 est souvent complètement inexistant (mesurer des perfs qui ne servent à rien en pratique), 2 est souvent trop important et 3 dans tous les cas pas du tout équilibré.
Je suppose que dans les cas cités précédemment, la plupart ne supporterait pas ce passage du triple test… et devrait donc relever du consentement.
La base légale « intérêt légitime » suppose l’existence d’un droit d’opposition (en opt-out, et non en opt-in comme le consentement), du coup ils l’ont peut-être (mal) implémenté comme ça.
[^] # Re: Oui et ça a même déjà été acté par une sanction
Posté par Aeris (site web personnel) . En réponse au journal RGPD et adresse mail. Évalué à 0. Dernière modification le 10 février 2022 à 16:48.
C’est pareil, même justification légale. Une plainte finirait de la même manière.
Droit de rectification, etc. Les fondements juridiques sont les mêmes.
Et peu importe que ça soit facultatif ou non, à partir du moment où il y a un champ, qui plus est quand la contrainte fonctionnelle est à l’opposée de la réalité technique.