SecNumCloud / EUCS : plaidoyer pour une analyse de risques rationnelle

Les débats font rage autour du projet de directive européenne EUCS (European Cybersecurity Certification Scheme) portant sur la sécurité et la souveraineté dans le cloud. Il suffit de lire les prises de position des uns et des autres pour réaliser que, plus que la sécurité de nos données, ce sont les milliards du marché de l'IaaS/PaaS qui sont en jeu.

Dans ce billet, je propose ma vision de ces enjeux. Et puisque c'est de sécurité informatique dont il s'agit, cette réflexion prendra la forme d'une analyse de risques (outil numéro 1 de n'importe quel DSI/RSSI qui se respecte). Mais d'abord :

EUCS : enjeu du débat et parties en présence ?

Au coeur de la controverse, le fait d'inclure ou non dans le futur référentiel européen un niveau d'exigence ultime dont le critère serait la "sécurité juridique", qui garantirait dans les faits que seules des entreprises aux capitaux strictement européens pourraient assurer (avec des salariés également européens uniquement) ce niveau de service, excluant de facto les hyperscalers américains.

Cette exigence est poussée par la France, qui l'a formalisée dans son propre référentiel SecNumCloud, et rejetée par une bonne partie des pays européens (et pas seulement l'Irlande et le Luxembourg qui ont des intérêts forts liés aux hyperscalers).

Tête de pont de la fronde française, l'ancien directeur de l'ANSSI, G. Poupard avait réussi à influer dans ce sens sur la doctrine "Cloud au Centre" entre son annonce en 2021 et sa formalisation en 2023, pour ensuite pantoufler chez DocaPoste, qui développe avec NumPost sa propre offre de cloud.

Mais il suffit de consulter la liste de ceux qui se sont joints à lui (Airbus, OVHCloud, Orange, Capgemini, Sopra Steria, Dassault Systèmes…) pour constater que la barrière de sécurité que ceux-là veulent construire a d'abord comme objectif de leur garantir un pré carré à l'abri de la concurrence américaine, plus que garantir la sécurité de vos données.

Mais cessons là la polémique et analysons un peu ce dont il s'agit concrètement.

Les risques en présence

La première étape de toute analyse de risques est d'identifier les sources de risques.

Quels sont donc les dispositions juridiques qui permettraient à des puissances étrangères d'accéder à vos données ?

Elles sont de deux types :

• Le CLOUD Act qui, comme son nom ne l'indique pas, ne concerne pas que le Cloud (il s'agit du Clarifying Lawful Overseas Use of Data), nécessite qu'une cour de justice américaine se prononce, et ne peut concerner que les données d'une personne américaine.
• Le US Code, dans son Titre 50, chapitre 36, comporte deux dispositions, permettant soit à l'Attorney General (l'équivalent du Procureur Général auprès de la cour de cassation) seul (art. 1802) soit conjointement avec le directeur de la NSA (art. 1881, introduit par la section 702 de la loi FISA) d'ordonner l'interception de données. Ces deux articles sont assortis d'un certain nombre de limitations.

Les scénarios :

S'agissant de risques juridiques, le scénario d'exploitation (S1) est assez immédiat : il s'agit de requêtes conformes à la loi qui arriveraient auprès d'un cloud provider.

Faisons preuve d'un peu d'imagination (voire de fiction) et ajoutons à ce scénario d'autres scenarii extra-légaux :

• (S2) un cloud provider pourrait volontairement et de sa propre initiative transmettre à une agence gouvernementale des données stockées par ses clients. Ou collaborer avec une agence gouvernementale hors du cadre légal (par ex. en prévoyant une backdoor).
• (S3) un employé pourrait faire de même, sans que son entreprise ne cautionne ses agissements.
• (S4) une agence gouvernementale pourrait utiliser des méthodes d'intrusion pour accéder aux données stockées chez un opérateur de cloud
• (S5) Tout ou partie des données collectées par les scénarios S1 à S4 pourraient se retrouver diffusées hors du cadre judiciaire prévu initialement (publiquement dans le but de nuire à la réputation, ou auprès de concurrents américains etc.)

Evaluation des scenarii

Chaque scénario peut être évalué selon les critères classiques, à savoir

• la probabilité d'occurence
• la gravité d'un événement

La gravité d'un événement dépend essentiellement du type de données traitées :

• la fuite des plans du dernier Rafale auprès d'un gouvernement étranger aura des conséquences autrement plus grandes que celles de mes dernières commandes UberEats.
• on a sanctuarisé le domaine des données de santé, mais vis-à-vis du gouvernement américain, reconnaissons que c'est quand même plus grave s'ils récupèrent celles de M. Macron que les miennes. Et que c'est plus grave s'il est capable facilement d'associer ces données à un individu en particulier que si elles sont efficacement pseudonymisées.
• certains me qualifieront de laxiste, mais quand je vois la difficulté qu'ont les entreprises à exploiter des datasets qu'elles ont elles-mêmes créées et des données très structurées, je considère que certaines data présentent une difficulté d'exploitation telle que le coût, pour un attaquant, excéderait largement le bénéfice. Personne ne veut fouiller vos poubelles. En particulier si elles sont chiffrées et même si quelque part dans la poubelle se trouve un logiciel qui, lorsqu'il sera lancé, saura les déchiffrer.
• enfin, il y a sans doute des données que vous préféreriez voire tomber (au pire) dans les mains d'un gouvernement tiers que dans celles d'un gouvernement qui a juridiction sur vous ! Et ce n'est pas une fiction : certains ont voulu profiter de la révision de la directive eIDas pour introduire la possibilité pour les Etats de forcer les navigateurs à reconnaître leur Autorité de Certification SSL. Concrètement, ça veut dire qu'en s'incrustant comme tiers de confiance, l'Etat peut faire du man-in-the-middle et espionner tranquillement vos connexions sur n'importe quel site web. Je n'ai pas lu de tribune énervée de Guillaume Poupard sur le sujet !

Venons-en maintenant à la probabilité d'occurrence. Il me semble qu'il faut prendre ici l'efficacité des protections (légales pour le S1, techniques pour les S2 à S5) disponibles ainsi que les dommages pour l'attaquant lui-même, dommages qui résulteraient de la perte de réputation consécutive à la révélation de la transmission des données.

Je m'explique :

• Le refus d'Apple de communiquer au FBI les moyens nécessaires au déverrouillage d'un iPhone (y compris pour un cas de terrorisme allégué) a fait plus pour la réputation d'Apple de protection des données personnelles que tout audit de conformité ;
• idem, quand Amazon choisit d'acheter 1.5 million de licences Office 365 pour ses salariés, il y a là une déclaration de confiance dans les mécanismes de conformité que Microsoft met en place (et de la sévérité des sanctions qu'il subirait en cas de défaut, volontaire ou non).
• Si un Cloud provider se mettait à transmettre illégalement (S2) des données de ses clients, en particulier si les données arrivaient dans les mains de concurrents (S5), ce provider perdrait dans l'année la quasi-totalité de sa clientèle extra-américaine. Et un whistleblower est si vite arrivé !

Attardons-nous sur les scénarios S3 et S4.

• L'attaque par un insider (S3) me semble beaucoup plus difficile à commettre chez un hyperscaler qu'un petit opérateur d'hébergement local.
  • L'approche "zero trust" y est implémentée rigoureusement (au point que les services ne se font pas confiance les uns les autres si le client ne les autorise pas explicitement à le faire).
  • AWS a également par exemple développé son propre hyperviseur et garantit qu'un opérateur ayant un accès console à une machine ne peut voir le contenu des machines virtuelles s'exécutant par dessus. Si votre opérateur d'hébergement utilise VMWare, il ne peut en dire autant : un ops ayant accès à la console de l'hyperviseur peut accéder à n'importe quelle VM.
  • Les hyperscalers facilitent la mise en place du chiffrement au repos permettant de garantir qu'un vol de disque dur n'implique pas une perte de données.
• Vient enfin l'intrusion par un gouvernement dans le système de l'opérateur de Cloud.
  • Là encore, étant dans le domaine extralégal, SecNumCloud et EUCS ne vous protégeront pas, que vous soyez sur un datacenter à capitaux européens ou non.
  • De mon côté, entre un opérateur qui protège chaque jour mes charges de travail des attaques du monde entier, et un opérateur qui conçoit ses datacenters avec un tel sérieux que l'incendie de l'un d'eux impacte celui d'une autre zone de disponibilité, j'ai fait mon choix !

En conclusion

En dehors des domaines nécessitant une vraie souveraineté, comme La Défense et certaines infrastructures critiques (a minima leurs systèmes opérationnels), vouloir absolument un "cloud souverain français" (ou européen) ne me semble absolument pas justifié, si ce n'est pas la volonté de leurs promoteurs de s'assurer un marché non-concurrentiel, où ils pourront proposer (cher) des offres bas de gamme.

Ne vous méprenez pas : je peux aussi avoir mon patriotisme économique et je n'ai pas de préférence pour les solutions américaines en tant que telles. Mais pas quand ce patriotisme sert de cache-sexe à la médiocrité. Et, à date, je ne vois aucune offre de cloud européen proposant le "tiercé gagnant" du cloud suivant :

1. des APIs permettant d'automatiser la totalité de la gestion de l'infrastructure (clé pour tout acteur qui veut maîtriser ses déploiements et travailler en mode agile/devops) et de la déployer à la demande
2. un éventail de services larges (e.g. bases de données purpose-built, et pas juste de la BDD relationnelle), très managés (e.g. des functions-as-a-service, un bus d'événement managé, une infrastructure de monitoring managée)
3. un modèle économique de paiement 100% à l'usage avec un pricing public transparent.

Le jour où j'en verrai, promis, je fais un blog post.