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.
La différence est grande entre une opinion (ce que je souhaiterais) et une analyse jurisprudentielle (les orientations que prennent les condamnations) :D
Là il se trouve que la tendance des condamnations me va plutôt bien, mais ça aurait pu ne pas être le cas et ça aurait été tout aussi intéressant à étudier.
Pour moi, ça indique bien qu'un SaaS avec un service pré-existant peut quand même être un data processor (sous certaines conditions).
Aligné, ça reste(rait) possible, mais les conditions ont l’air tellement minces qu’en pratique tu as plutôt intérêt à envisager autre chose (self-hosting ou au moins on premise) qui coûtera moins cher et sera moins complexe administrativement parlant.
Les requalifications de DP en DC sont quand même vachement nombreuses et avec des cas où je n’aurai même pas parié un kopec dessus à l’origine (typiquement celle de l’IAB, certains considérants me semblent complètement hallucinants, comme 328 par exemple…).
Et dans les lignes EDPB, le « a detailed description » me semble assez hors de portée d’une relation de sous-traitance conventionnelle en tout cas telle qu’envisagée en 2022…
Tu dois littéralement collé au cul de ton sous-traitant pour connaître l’intégralité de tous ses petits secrets… à date et surtout sur toute la durée de la prestation. Avec côté sous-traitant de sacrées restrictions dont on n’a(vait) pas l’habitude aujourd’hui (peu de liberté d’innovation, pas de gestion/évolution de son propre produit, en tout cas pas sans accord de tous ces clients, etc).
Ça me semble vachement changer des relations de sous-traitances telles qu’on les connaît aujourd’hui.
En outre, on considère généralement que la définition des finalités du traitement l'emporte sur celle des moyens lorsqu'il s'agit d'établir la responsabilité d'une organisation.
Oui, mais justement. Définir les finalités implique être responsable de traitement. Ça c’est clair net et précis.
Mais l’inverse n’est pas vrai : ne pas définir les finalités n’impliquent pas de ne pas être responsable, il reste encore au moins à étudier la définition des moyens. D’autant plus que l’un des 2 soit responsable de traitement n’empêche pas l’autre de pouvoir l’être (co-responsable de traitement). Et que, y compris pour une même donnée, le statut de processeur de données n’est pas exclusif d’être aussi responsable de traitement.
Le 1er diagramme de la page 46 évacue rapidement les cas où tu es responsable de traitement de manière évidente (tu as dis ou écris que tu l’étais ou une loi t’y contraint).
On arrive sur « tu fais quoi en pratique ». Les 2 portes de sortie « data processor » implique « decision based on general security objective set by the other party » et « solely in accordance with its instruction ».
Dans le cas du SaaS, c’est pas évident parce que le logiciel existait déjà avant la conclusion du contrat, donc les décisions ayant été prises sans lui, le cas « 2- solely » est difficile à défendre. Et pour le cas « 1- set by the other party », le mécanisme de décision est au mieux inversé. On part de finalité et de moyens déjà offerts par un logiciel existant et on s’arrange pour faire matcher les objectifs du client avec les possibilités (« oh vous conservez 6 mois chez vous ? On aurait plutôt dit 3, mais aller, on va marquer 6, ça nous va aussi mais on est bien d’accord qu’on n’écrit ça nul part hein » ou autre « ah zut, vous fait machin-truc pour votre maintenance ? Bon, on va l’indiquer aussi chez nous et on en prend la DC et on vous dit DP »).
L’arrangement est au final un jeu de dupe, on change le registre de traitement du client avec les possibilités du logiciel SaaS plutôt que d’arranger le logiciel SaaS pour coller avec le registre de traitement.
Sur un contrôle APD, ça ferait quand même vachement mauvaise foi d’avoir trouver un presta 100% conforme à tes exigences alors qu’il existait depuis 10 ans et n’a pas fait de développement spécifique notable pour toi.
Surtout que l’objectif de ce jeu de dupe est clair : éviter la responsabilité de traitement du prestataire (qu’il préférerait ne pas assumer ou te le fera payer, cf Microsoft & IAB), éviter de devoir aller voir ailleurs, et en plus risquer de devoir constater qu’il n’existe pas d’offre SaaS correspondant strictement aux besoins et donc de devoir investir dans un développement de produit ad-hoc ou on-premise (cher, long, etc).
En pratique sur un produit SaaS, on devrait donc plutôt sortir sur 4.1 « you are the controller ». Ce qui ne serait pas/moins vrai pour un logiciel à façon du coup, développé spécifiquement pour tes besoins propres (quitte à partir d’une base SaaS existante), ou on-premise où tu gères assez finement ton paramétrage et tes accès, et où tu sortirais en 4.2/4.3.
Sur toutes les finalités offertes par un logiciel SaaS, la proba d’avoir du 100% « data processor » est quand même faible… En pratique, on va avoir :
- « client DC, presta DP » sur peu de finalité : celles spécifiquement créées par le client à partir du logiciel en SaaS et dont le presta se fout un peu (« gérer le service client via un chatbot », « réserver un billet de train via un chatbot »…)
- « client/presta co-DC » sur un petit bout : toutes les finalités existantes dans le produit avant l’arrivée du nouveau client et correspondant à 100% à un besoin précis de ce client avant le choix du prestataire (« conserver un historique des échanges », « répondre à une demande d’accès RGPD »).
- « presta DC » pour le reste : toutes celles existantes dans le produit avant l’arrivée du nouveau client et ne correspondant pas à un besoin précis à 100% du client avant le choix du prestataire (« maintenir la plateforme », « offrir du support à mes clients », « obtenir des stats/KPI de ma plateforme »). Pour moi ça risque d’être ça le très gros du paquet.
J’ai même des cas assez chiants à faire rentrer dans les cases…
Quid d’une analyse côté client qui montre un besoin de rétention d’historique à 3 mois côté client quand la seule possibilité côté SaaS est de le faire à 6 mois ? Tu vas quand même chez ton prestataire en violant ton propre registre de traitement ? 🤔
Ton analyse dit 6 mois mais le SaaS fait 3 mois. Tu revois ton analyse à 3 mois en reconnaissant avoir mal fait ton boulot de minimisation dans l’analyse préliminaire vu qu’a priori c’était nécessaire de conserver 6 mois minimum ? 🤔
En théorie tu es supposé aller voir ailleurs dans les 2 cas du coup… 🤷
Et si tu trouves un presta SaaS capable d’adapter son soft existant et ses paramétrages à tes propres besoins de conformité sans toucher à ceux de ses autres clients (par exemple garantir cette suppression à 3 mois pour un client et à 6 mois pour les autres, ou désactiver toute télémétrie et acte de maintenance pour l’un mais pas pour l’autre, ou virer de stats de KPI tout ce qui est généré par les usages d’un client donné), je doute que le tarif soit si intéressant que ça par rapport à un développement à façon… On serait rapidement plus proche en pratique au moins du on-premise, ou à des usines à gaz type SAP… 🤔
Or, je ne pense pas que tous les services SaaS déterminent eux-mêmes les finalités pour leurs clients. Si un service fournit un chatbot, il peut servir pour des finalités commerciales, ou du support, ou d'autres raisons, et c'est au client de ce service de définir la finalité pour laquelle il compte utiliser le services en question.
Tout à fait, ils fournissent un service « as is » et ce qu’en fait le client est effectivement de sa propre responsabilité.
Mais ils ont aussi fait LEURS propres choix (techniques, infras…), le soft est souvent fournis avec d’autres fonctionnalités qui ne sont pas directement une demande du client (debug & maintenance, au moins, voir ici l’IAPD des Pays-Bas sur ce sujet pour Microsoft Office 365, § 16.2.4 Microsoft does not act as a data processor), ce qui fait qu’ils en deviennent de fait un co-responsable de traitement.
Au final on a 3 bouts distincts : les parties à la charge stricte du client (faire du support sur le chatbot), les parties à la charge stricte du prestataire (maintenance, debug…) mais un gros bout en co-responsabilité de traitement qui représente l’essentiel des finalités (vu que le presta a quasi tout développé de sa propre initiative, donc a minima choisi les moyens).
Pour le cas du ET ou du OU entre les 3 clauses, ici l’APD a fait son taff en pointant tous les manquements, mais le texte est clair : c’est bien finalité OU moyens. Et il me semble qu’il existe une ligne directrice EDPB qui formalise justement cette compréhension du OU, je vais la rechercher :)
C’était le taff de l’APD d’aligner le plus de non-conformités possibles pour estimer l’amende à la fin. Ils ont condamné pour l’ensemble de l’œuvre, mais ils auraient pu condamner juste avec un seul chapitre.
Tu peux avoir un logiciel SaaS hébergé en Europe par une société européenne.
Non justement. La décision prise envers l’IAB Europe s’applique également aux SaaS européen du coup.
Il n’y a de toute façon pas de notion de localisation des services dans le délibéré, uniquement de responsable de traitement contre sous-traitant. Une boîte EU hébergeant un service SaaS EU est du coup tout aussi dans la mouise.
Après ça va certainement mettre du temps à percoler avec d’autres condamnations arrivants à des sanctions pour ce même motif, mais c’est ce que j’entrevois entre les lignes du délibéré.
Schrems II a éradiqué les US. Panoptikon a éradiqué le SaaS.
Si on lit le délibéré de la sanction, c’est bien plus que la publicité en ligne qui est mise à mal pour le coup. C’est extrêmement violent, plus ou moins du même niveau que l’arrêt Schrems II qui invalide tout service US… Ça remet en question complètement l’usage voire l’existence même du SaaS…
En TLDR (mais IANAL hein…), c’est essentiellement la notion même de « responsable de traitement » du RGPD qui a été étudié, en particulier dans le cas d’une sous-traitance.
Si on lit les considérants, en particulier à partir du 326-341, il devient vraiment assez difficile d’être sous-traitant dans une relation commerciale, et on endosse la responsabilité du traitement très très rapidement. Dès qu’on décide d’une modalité (326), dès qu’on vend/loue son produit (328), dès qu’on a décidé d’une orientation (330), en gros dès qu’on a développé une solution informatique (341), et ce y compris si on n’a pas accès directement aux données à caractère personnel (327), on est co-responsable avec son client de tous les traitements. Y compris des usages de son client du coup.
En pratique ça devient du coup très difficile pour une entreprise de pouvoir recourir à un sous-traitant, qui n’a aucune raison d’accepter cette responsabilité, en tout cas pas sans la faire payer, et à un coût qui risque fort d’être prohibitif…
La porte ouverte à l’obligation légale d’arrêter la sous-traitance pour n’autoriser que au mieux du on-premise assez drastique et à contraindre les entreprises à reprendre le contrôle de leur système, ouvrant la voie royale au libre et à l’auto-hébergement ? Peut-être bien ! 😊
Si tu as une bibliothèque à disposition pour analyser les iCal et sortir les données souhaitées dans une base de données supportée par Metabase, ça fera le travail sans problème !
Avec 2 bouts de python ou de ruby, ça doit être rapide à faire.
C’est exactement le point. La BI telle qu’on la faisait avant est mise pas mal à mal avec l’entrée en vigueur du RGPD en 2016.
Beaucoup des traitements effectués avant sont dorénavant très touchy niveau RGPD, avec des bases légales frileuses.
EDPB est assez clair sur le sujet : ces stats ne sont pas une obligation légale et n’ont généralement pas un intérêt légitime suffisant devant les dérives possibles (oui, le RGPD adore raisonner selon les possibilités théoriques et non selon les réalités pratiques), la seule base légale a priori recevable sauf justification très forte est le consentement.
Et la plupart des utilités supposées de la BI disparaissent encore plus avec du consentement, parce que ça veut dire que tes chiffres deviennent imprécis (fort probabilité de refus du consentement = données non fiables = pertes d’intérêts = encore moins de légalité du traitement) et que le process de détention des données devient trop chronophage et coûteux par rapport à la plus-value qui en ressort (gestion de la rétractation du consentement nécessitant la suppression des données et des traitements ultérieurs, droits d’accès et rectifications, DPIA avant intégration au registre de traitement, etc)
Les 2 sont importants. J’ai peut-être donné l’impression de ne parler que de l’un, mais ce n’est pas le cas. Et à mon sens les 2 sont assez liés, une nouvelle finalité risque fort de réclamer une nouvelle base légale.
C’est particulièrement vrai dans le cas de la BI, les données à dispo sont souvent sous une base légale de collecte (obligation légale ou nécessaire au contrat) incompatible avec des finalités statistiques qui elles nécessitent obligatoirement de l’intérêt légitime voire du consentement d’après EDPB.
Et les produits de BI sont souvent marketés comme « vous avez des données dont vous ne faites rien, sortez-en des stats utiles ». Typiquement chez Metabase, « Meet the easy, open source way for everyone in your company to ask questions and learn from data ».
De plus, le RGPD interdit l’ajout préventif de finalité/base légale « pour des besoins ultérieurs » selon les mots de EDPB. Les besoins doivent être factuels, présents et justifiés. Les finalités de collectes sont du coup nécessairement incompatibles avec l’ajout ultérieur à la volée de filtres/recroisement dans des outils comme Metabase.
C’est uniquement mon point soulevé : la facilité d’ajout de dashboard/filtre/graphe, de recroisement ou d’accès à la donnée est en décalage comparée à la rigidité et la difficulté d’ajout de telles nouvelles finalités dans le cadre d’une conformité RGPD correcte.
[^] # 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.
# 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é à 3. Dernière modification le 10 février 2022 à 12:54.
Cf ici : https://gdprhub.eu/index.php?title=Court_of_Appeal_of_Brussels_-_2019/AR/1006
Le fournisseur a l’obligation de se conformer à ce que tu lui demandes de mettre, quitte à devoir refaire tout son système d’information et à changer de langage si nécessaire.
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . En réponse au journal Une surprenante décision de la justice belge. Évalué à 3.
La différence est grande entre une opinion (ce que je souhaiterais) et une analyse jurisprudentielle (les orientations que prennent les condamnations) :D
Là il se trouve que la tendance des condamnations me va plutôt bien, mais ça aurait pu ne pas être le cas et ça aurait été tout aussi intéressant à étudier.
Aligné, ça reste(rait) possible, mais les conditions ont l’air tellement minces qu’en pratique tu as plutôt intérêt à envisager autre chose (self-hosting ou au moins on premise) qui coûtera moins cher et sera moins complexe administrativement parlant.
Les requalifications de DP en DC sont quand même vachement nombreuses et avec des cas où je n’aurai même pas parié un kopec dessus à l’origine (typiquement celle de l’IAB, certains considérants me semblent complètement hallucinants, comme 328 par exemple…).
Et dans les lignes EDPB, le « a detailed description » me semble assez hors de portée d’une relation de sous-traitance conventionnelle en tout cas telle qu’envisagée en 2022…
Tu dois littéralement collé au cul de ton sous-traitant pour connaître l’intégralité de tous ses petits secrets… à date et surtout sur toute la durée de la prestation. Avec côté sous-traitant de sacrées restrictions dont on n’a(vait) pas l’habitude aujourd’hui (peu de liberté d’innovation, pas de gestion/évolution de son propre produit, en tout cas pas sans accord de tous ces clients, etc).
Ça me semble vachement changer des relations de sous-traitances telles qu’on les connaît aujourd’hui.
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . En réponse au journal Une surprenante décision de la justice belge. Évalué à 2. Dernière modification le 07 février 2022 à 15:58.
Oui, mais justement. Définir les finalités implique être responsable de traitement. Ça c’est clair net et précis.
Mais l’inverse n’est pas vrai : ne pas définir les finalités n’impliquent pas de ne pas être responsable, il reste encore au moins à étudier la définition des moyens. D’autant plus que l’un des 2 soit responsable de traitement n’empêche pas l’autre de pouvoir l’être (co-responsable de traitement). Et que, y compris pour une même donnée, le statut de processeur de données n’est pas exclusif d’être aussi responsable de traitement.
C’est aussi plutôt visible dans les lignes directrices EDPB.
Le 1er diagramme de la page 46 évacue rapidement les cas où tu es responsable de traitement de manière évidente (tu as dis ou écris que tu l’étais ou une loi t’y contraint).
On arrive sur « tu fais quoi en pratique ». Les 2 portes de sortie « data processor » implique « decision based on general security objective set by the other party » et « solely in accordance with its instruction ».
Dans le cas du SaaS, c’est pas évident parce que le logiciel existait déjà avant la conclusion du contrat, donc les décisions ayant été prises sans lui, le cas « 2- solely » est difficile à défendre. Et pour le cas « 1- set by the other party », le mécanisme de décision est au mieux inversé. On part de finalité et de moyens déjà offerts par un logiciel existant et on s’arrange pour faire matcher les objectifs du client avec les possibilités (« oh vous conservez 6 mois chez vous ? On aurait plutôt dit 3, mais aller, on va marquer 6, ça nous va aussi mais on est bien d’accord qu’on n’écrit ça nul part hein » ou autre « ah zut, vous fait machin-truc pour votre maintenance ? Bon, on va l’indiquer aussi chez nous et on en prend la DC et on vous dit DP »).
L’arrangement est au final un jeu de dupe, on change le registre de traitement du client avec les possibilités du logiciel SaaS plutôt que d’arranger le logiciel SaaS pour coller avec le registre de traitement.
Sur un contrôle APD, ça ferait quand même vachement mauvaise foi d’avoir trouver un presta 100% conforme à tes exigences alors qu’il existait depuis 10 ans et n’a pas fait de développement spécifique notable pour toi.
Surtout que l’objectif de ce jeu de dupe est clair : éviter la responsabilité de traitement du prestataire (qu’il préférerait ne pas assumer ou te le fera payer, cf Microsoft & IAB), éviter de devoir aller voir ailleurs, et en plus risquer de devoir constater qu’il n’existe pas d’offre SaaS correspondant strictement aux besoins et donc de devoir investir dans un développement de produit ad-hoc ou on-premise (cher, long, etc).
En pratique sur un produit SaaS, on devrait donc plutôt sortir sur 4.1 « you are the controller ». Ce qui ne serait pas/moins vrai pour un logiciel à façon du coup, développé spécifiquement pour tes besoins propres (quitte à partir d’une base SaaS existante), ou on-premise où tu gères assez finement ton paramétrage et tes accès, et où tu sortirais en 4.2/4.3.
Sur toutes les finalités offertes par un logiciel SaaS, la proba d’avoir du 100% « data processor » est quand même faible… En pratique, on va avoir :
- « client DC, presta DP » sur peu de finalité : celles spécifiquement créées par le client à partir du logiciel en SaaS et dont le presta se fout un peu (« gérer le service client via un chatbot », « réserver un billet de train via un chatbot »…)
- « client/presta co-DC » sur un petit bout : toutes les finalités existantes dans le produit avant l’arrivée du nouveau client et correspondant à 100% à un besoin précis de ce client avant le choix du prestataire (« conserver un historique des échanges », « répondre à une demande d’accès RGPD »).
- « presta DC » pour le reste : toutes celles existantes dans le produit avant l’arrivée du nouveau client et ne correspondant pas à un besoin précis à 100% du client avant le choix du prestataire (« maintenir la plateforme », « offrir du support à mes clients », « obtenir des stats/KPI de ma plateforme »). Pour moi ça risque d’être ça le très gros du paquet.
J’ai même des cas assez chiants à faire rentrer dans les cases…
Quid d’une analyse côté client qui montre un besoin de rétention d’historique à 3 mois côté client quand la seule possibilité côté SaaS est de le faire à 6 mois ? Tu vas quand même chez ton prestataire en violant ton propre registre de traitement ? 🤔
Ton analyse dit 6 mois mais le SaaS fait 3 mois. Tu revois ton analyse à 3 mois en reconnaissant avoir mal fait ton boulot de minimisation dans l’analyse préliminaire vu qu’a priori c’était nécessaire de conserver 6 mois minimum ? 🤔
En théorie tu es supposé aller voir ailleurs dans les 2 cas du coup… 🤷
Et si tu trouves un presta SaaS capable d’adapter son soft existant et ses paramétrages à tes propres besoins de conformité sans toucher à ceux de ses autres clients (par exemple garantir cette suppression à 3 mois pour un client et à 6 mois pour les autres, ou désactiver toute télémétrie et acte de maintenance pour l’un mais pas pour l’autre, ou virer de stats de KPI tout ce qui est généré par les usages d’un client donné), je doute que le tarif soit si intéressant que ça par rapport à un développement à façon… On serait rapidement plus proche en pratique au moins du on-premise, ou à des usines à gaz type SAP… 🤔
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . En réponse au journal Une surprenante décision de la justice belge. Évalué à 1. Dernière modification le 07 février 2022 à 11:22.
Tout à fait, ils fournissent un service « as is » et ce qu’en fait le client est effectivement de sa propre responsabilité.
Mais ils ont aussi fait LEURS propres choix (techniques, infras…), le soft est souvent fournis avec d’autres fonctionnalités qui ne sont pas directement une demande du client (debug & maintenance, au moins, voir ici l’IAPD des Pays-Bas sur ce sujet pour Microsoft Office 365, § 16.2.4 Microsoft does not act as a data processor), ce qui fait qu’ils en deviennent de fait un co-responsable de traitement.
Au final on a 3 bouts distincts : les parties à la charge stricte du client (faire du support sur le chatbot), les parties à la charge stricte du prestataire (maintenance, debug…) mais un gros bout en co-responsabilité de traitement qui représente l’essentiel des finalités (vu que le presta a quasi tout développé de sa propre initiative, donc a minima choisi les moyens).
Pour le cas du ET ou du OU entre les 3 clauses, ici l’APD a fait son taff en pointant tous les manquements, mais le texte est clair : c’est bien finalité OU moyens. Et il me semble qu’il existe une ligne directrice EDPB qui formalise justement cette compréhension du OU, je vais la rechercher :)
C’était le taff de l’APD d’aligner le plus de non-conformités possibles pour estimer l’amende à la fin. Ils ont condamné pour l’ensemble de l’œuvre, mais ils auraient pu condamner juste avec un seul chapitre.
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . En réponse au journal Une surprenante décision de la justice belge. Évalué à 3. Dernière modification le 05 février 2022 à 22:21.
Non justement. La décision prise envers l’IAB Europe s’applique également aux SaaS européen du coup.
Il n’y a de toute façon pas de notion de localisation des services dans le délibéré, uniquement de responsable de traitement contre sous-traitant. Une boîte EU hébergeant un service SaaS EU est du coup tout aussi dans la mouise.
Après ça va certainement mettre du temps à percoler avec d’autres condamnations arrivants à des sanctions pour ce même motif, mais c’est ce que j’entrevois entre les lignes du délibéré.
Schrems II a éradiqué les US. Panoptikon a éradiqué le SaaS.
# Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . En réponse au journal Une surprenante décision de la justice belge. Évalué à 7. Dernière modification le 04 février 2022 à 20:58.
Si on lit le délibéré de la sanction, c’est bien plus que la publicité en ligne qui est mise à mal pour le coup. C’est extrêmement violent, plus ou moins du même niveau que l’arrêt Schrems II qui invalide tout service US… Ça remet en question complètement l’usage voire l’existence même du SaaS…
En TLDR (mais IANAL hein…), c’est essentiellement la notion même de « responsable de traitement » du RGPD qui a été étudié, en particulier dans le cas d’une sous-traitance.
Si on lit les considérants, en particulier à partir du 326-341, il devient vraiment assez difficile d’être sous-traitant dans une relation commerciale, et on endosse la responsabilité du traitement très très rapidement. Dès qu’on décide d’une modalité (326), dès qu’on vend/loue son produit (328), dès qu’on a décidé d’une orientation (330), en gros dès qu’on a développé une solution informatique (341), et ce y compris si on n’a pas accès directement aux données à caractère personnel (327), on est co-responsable avec son client de tous les traitements. Y compris des usages de son client du coup.
En pratique ça devient du coup très difficile pour une entreprise de pouvoir recourir à un sous-traitant, qui n’a aucune raison d’accepter cette responsabilité, en tout cas pas sans la faire payer, et à un coût qui risque fort d’être prohibitif…
La porte ouverte à l’obligation légale d’arrêter la sous-traitance pour n’autoriser que au mieux du on-premise assez drastique et à contraindre les entreprises à reprendre le contrôle de leur système, ouvrant la voie royale au libre et à l’auto-hébergement ? Peut-être bien ! 😊
[^] # Re: Un petit peu HS
Posté par Aeris (site web personnel) . En réponse à la dépêche Metabase - Business intelligence open source. Évalué à 5.
Si tu as une bibliothèque à disposition pour analyser les iCal et sortir les données souhaitées dans une base de données supportée par Metabase, ça fera le travail sans problème !
Avec 2 bouts de python ou de ruby, ça doit être rapide à faire.
[^] # Re: Attention quand même au RGPD :D
Posté par Aeris (site web personnel) . En réponse à la dépêche Metabase - Business intelligence open source. Évalué à 1. Dernière modification le 29 novembre 2021 à 10:43.
C’est exactement le point. La BI telle qu’on la faisait avant est mise pas mal à mal avec l’entrée en vigueur du RGPD en 2016.
Beaucoup des traitements effectués avant sont dorénavant très touchy niveau RGPD, avec des bases légales frileuses.
EDPB est assez clair sur le sujet : ces stats ne sont pas une obligation légale et n’ont généralement pas un intérêt légitime suffisant devant les dérives possibles (oui, le RGPD adore raisonner selon les possibilités théoriques et non selon les réalités pratiques), la seule base légale a priori recevable sauf justification très forte est le consentement.
Et la plupart des utilités supposées de la BI disparaissent encore plus avec du consentement, parce que ça veut dire que tes chiffres deviennent imprécis (fort probabilité de refus du consentement = données non fiables = pertes d’intérêts = encore moins de légalité du traitement) et que le process de détention des données devient trop chronophage et coûteux par rapport à la plus-value qui en ressort (gestion de la rétractation du consentement nécessitant la suppression des données et des traitements ultérieurs, droits d’accès et rectifications, DPIA avant intégration au registre de traitement, etc)
Ça donne par exemple :
https://www.linkedin.com/pulse/gdpr-has-big-implications-business-intelligence-nick-ringle?articleId=6408376440735301632
https://wiiisdom.com/white-paper/business-objects-gdpr-compliance/
https://tdwi.org/articles/2018/06/04/biz-all-gdpr-impact-on-bi-1.aspx
et tant d’autres sujets qui sont actuellement complètement passés sous silence devant la facilité de ces outils de sortir du cadre réglementaire.
Voir aussi par exemple cette condamnation à 50.000€ d’amende, pour avoir eu un outil de BI trop ouvert.
[^] # Re: Attention quand même au RGPD :D
Posté par Aeris (site web personnel) . En réponse à la dépêche Metabase - Business intelligence open source. Évalué à 2.
Les 2 sont importants. J’ai peut-être donné l’impression de ne parler que de l’un, mais ce n’est pas le cas. Et à mon sens les 2 sont assez liés, une nouvelle finalité risque fort de réclamer une nouvelle base légale.
C’est particulièrement vrai dans le cas de la BI, les données à dispo sont souvent sous une base légale de collecte (obligation légale ou nécessaire au contrat) incompatible avec des finalités statistiques qui elles nécessitent obligatoirement de l’intérêt légitime voire du consentement d’après EDPB.
Et les produits de BI sont souvent marketés comme « vous avez des données dont vous ne faites rien, sortez-en des stats utiles ». Typiquement chez Metabase, « Meet the easy, open source way for everyone in your company to ask questions and learn from data ».
De plus, le RGPD interdit l’ajout préventif de finalité/base légale « pour des besoins ultérieurs » selon les mots de EDPB. Les besoins doivent être factuels, présents et justifiés. Les finalités de collectes sont du coup nécessairement incompatibles avec l’ajout ultérieur à la volée de filtres/recroisement dans des outils comme Metabase.
C’est uniquement mon point soulevé : la facilité d’ajout de dashboard/filtre/graphe, de recroisement ou d’accès à la donnée est en décalage comparée à la rigidité et la difficulté d’ajout de telles nouvelles finalités dans le cadre d’une conformité RGPD correcte.