• Bad@jlai.lu
    link
    fedilink
    Français
    arrow-up
    9
    ·
    edit-2
    7 months ago

    Ce n’est pas nouveau, ils le disent ouvertement depuis longtemps, on a mĂȘme dĂ©jĂ  lĂ©gifĂ©rĂ© sur cette impossibilitĂ© de garantir la protection des donnĂ©es au niveau europĂ©en (la fin du Privacy Shield). Ce qui est nouveau c’est que c’est devant le sĂ©nat français.

    En 2019 j’ai basculĂ© le run d’une trĂšs grosse entreprise d’AWS vers Azure, les ingĂ©s Microsoft qui nous aidaient devaient dĂ©limiter la protection des donnĂ©es qu’ils pouvaient garantir (pour que l’entreprise garde sa certification ISO 27001), une des garanties impossibles de leur part Ă©tait que les donnĂ©es des clients soient protĂ©gĂ©es du gouvernement amĂ©ricain, vu qu’ils ont leur loi CLOUD Act Ă  respecter.

    En thĂ©orie ça ressemble Ă  une brĂšche du RGPD, mais entre temps il y a eu l’arrĂȘt Schrems II cĂŽtĂ© UE qui dit comment rendre ça RGPD compatible : c’est aux entreprises de chiffrer toutes les donnĂ©es considĂ©rĂ©es “sensibles” qui sont stockĂ©es dans un cloud. Comme ça, mĂȘme si les USA mettent leur nez dedans, ils n’en tireront que des donnĂ©es impossibles Ă  exploiter. Donc on part du principe que les clouds amĂ©ricains sont incompatibles avec l’Europe
 mais qu’on peut s’adapter Ă  leur usage, et qu’il y a donc une compatibilitĂ© possible.

    Bien entendu, ce n’est pas fait par la majoritĂ© des entreprises, ne serait-ce que parce que l’impact du chiffrage sur les performances des recherches parmi les donnĂ©es sensibles serait lourd, or le business de beaucoup d’entreprises inclut l’exploitation des donnĂ©es sensibles qu’elles ont sous la main (rappel que chaque info que vous donnez Ă  une entrerpise va ĂȘtre exploitĂ©e). Par expĂ©rience de la façon de fonctionner dans le monde de la tech, trouver une façon de faire semblant de respecter le RGPD (par ex. une pseudonymisation foireuse) est plus attirant que de trouver une façon de chiffrer les donnĂ©es sensibles tout en conservant la performance lors de leur exploitation. Donc l’illĂ©galitĂ© sera gĂ©nĂ©ralement prĂ©fĂ©rĂ©e pour faire des Ă©conomies d’efforts. Les amendes ne sont pas assez Ă©levĂ©es pour dissuader (elles le sont en thĂ©orie mais jamais en pratique).

    TL;DR: Ça fait longtemps que les donnĂ©es sensibles sont impossibles Ă  protĂ©ger quand un cloud amĂ©ricain est utilisĂ©.

    • RelativityRanger@jlai.lu
      link
      fedilink
      Français
      arrow-up
      1
      ·
      7 months ago

      rendre ça RGPD compatible : c’est aux entreprises de chiffrer toutes les donnĂ©es considĂ©rĂ©es “sensibles” qui sont stockĂ©es dans un cloud. Comme ça, mĂȘme si les USA mettent leur nez dedans, ils n’en tireront que des donnĂ©es impossibles Ă  exploiter.

      Pour la nuance RĂ©colter maintenant, dĂ©chiffrer plus tard 🌈
      Le chiffrement actuel est basĂ© sur des problĂšmes difficiles pour les ordinateurs classiques, mais faciles Ă  rĂ©soudre pour un ordinateur quantique avec l’algorithme de Shor. Si un responsable est assez stupide pour choisir MS de nos jours alors il l’est suffisamment pour utiliser un chiffrement asymĂ©trique (ou pire).

  • marud@piefed.marud.fr
    link
    fedilink
    Français
    arrow-up
    6
    ·
    7 months ago

    J’en parlais hier à un des commerciaux à mon boulot et j’avais pas remis la main sur un article, je vais m’empresser de lui montrer de ce pas !

  • mel ♀@jlai.lu
    link
    fedilink
    Français
    arrow-up
    5
    ·
    7 months ago

    Ce qui me choque un peu avec le chmilblik :

    • ça fait un mois que l’audition a Ă©tĂ© diffusĂ©e
    • si Microsoft se retire, le hub de santĂ© est dead de chez dead (Ă©videmment c’est du propriĂ©taire)
    • marud@piefed.marud.fr
      link
      fedilink
      Français
      arrow-up
      3
      ·
      7 months ago

      Ca serait un bon argument pour forcer une obligation de compatibilité de format de données pour ce genre de choses

      • mel ♀@jlai.lu
        link
        fedilink
        Français
        arrow-up
        2
        ·
        7 months ago

        Sur un cloud comme ça, le problĂšme est mĂȘme plus au niveau de la donnĂ©e, mais juste d’un lock in au niveau du code. Tout ce que tu peux dev c’est du spĂ©cifique que tu peux pas porter ou alors le choix d’Azure est largement surdimensionnĂ©. La grosse question que je me pose, c’est quels sont les besoins rĂ©els pour le hub de santĂ© pour qu’openstack ne soit pas suffisant (ou alors capg et orange sont complices du mauvais choix)

        • marud@piefed.marud.fr
          link
          fedilink
          Français
          arrow-up
          3
          ·
          7 months ago

          C’est intĂ©ressant ce que tu dis et ça dĂ©passe mon domaine de connaissance (je suis pas dev et pas utilisateur du hub de santĂ©).

          Forcer d’avoir son code de traitement de donnĂ©es de santĂ© en opensource serait l’étape qui manque alors ?

          • mel ♀@jlai.lu
            link
            fedilink
            Français
            arrow-up
            3
            ·
            7 months ago

            LĂ  tu viens toucher Ă  mon cĂŽtĂ© libriste et je pense que tous les logiciels d’État se doivent d’ĂȘtre publiĂ© en open source (voire domaine publique). Mon opinion suivante c’est que aucun argent publique ne devrait aller vers des solutions propriĂ©taires (coucou Pronote, les big esns, les deals avec microsoft).

            AprĂšs, openstack n’est pas azure, il manquerait le cĂŽtĂ© saas, mais quitte Ă  monter un opĂ©rateur azure, pourquoi ne pas se tourner vers l’Open source ça me termine