Aller au contenu principal
own2pwn
appsec/easm-souverain-france.tsx

EASM souverain : une alternative française et européenne pour votre surface d'attaque

Un EASM souverain garde la carte de votre surface d'attaque en France. Pourquoi « datacenter en Europe » ne suffit pas face au Cloud Act, et les vrais critères d'un EASM français.

own2pwn··9 min de lecture

Deux plateformes EASM peuvent rendre le même service technique et se séparer sur un point qu'on examine souvent trop tard : où atterrit la donnée qu'elles produisent sur vous, et sous quelle loi. Cette donnée, l'inventaire de vos actifs exposés et de leurs failles classées par exploitabilité, compte parmi les plus sensibles que votre SI génère. La confier, c'est déjà choisir une juridiction.

C'est tout l'enjeu d'un EASM souverain. Ces failles cartographiées n'ont rien à faire dans un cloud extra-européen, ni sous le coup d'une loi étrangère. Choisir un EASM français, édité et hébergé en France, tient d'abord de la gestion du risque. Le reste, c'est du drapeau sur une plaquette, et il faut apprendre à faire la différence. Si le sujet de l'outil lui-même est neuf pour vous, commencez par qu'est-ce que l'EASM et comment il fonctionne.

Ce qu'un EASM sait de vous (et pourquoi c'est explosif)

Un scanner de vulnérabilités classique regarde une machine que vous lui désignez. Un EASM part de trois fois rien : un nom de domaine, une marque, un ASN. À partir de là, il reconstitue seul tout ce que vous exposez, du point de vue de l'attaquant. Le résultat va bien plus loin qu'une liste de serveurs. Il tient en deux volets, et c'est leur combinaison qui pèse :

  • L'inventaire complet des actifs exposés : chaque sous-domaine, chaque IP, chaque service, y compris le shadow IT que votre CMDB ignore. La cartographie que votre propre équipe n'a jamais réussi à tenir à jour, un attaquant l'obtient en la lisant chez vous.
  • Les faiblesses priorisées : pour chaque actif, les CVE corrélées, les mauvaises configurations, les versions vulnérables, triées par exploitabilité. Le classement de ce qui cède en premier.

Corrélés et hiérarchisés, ces deux volets forment un mode opératoire déjà priorisé : par où entrer, dans quel ordre, sur quel actif. Si cette base de données fuite, ou si un tiers y accède par une porte légale que vous n'aviez pas vue venir, vous n'avez pas perdu « des données ». Vous avez remis à quelqu'un la notice de piratage de votre organisation. D'où la question de la juridiction.

Cloud Act, FISA 702 : pourquoi « datacenter en Europe » ne suffit pas

Le réflexe classique du commercial, quand vous soulevez la souveraineté : « Rassurez-vous, nos serveurs sont dans un datacenter en Irlande, en Allemagne, à Paris. » C'est vrai. Et ça ne règle rien. La localisation physique des serveurs et la juridiction applicable sont deux choses distinctes. Ce qui décide, c'est le droit dont relève l'entité qui opère ces serveurs.

Le CLOUD Act américain (2018) le dit sans détour : un fournisseur soumis au droit des États-Unis doit livrer aux autorités américaines les données qu'il détient, quel que soit l'endroit du monde où elles sont stockées. Une filiale européenne d'un groupe américain reste, via sa maison-mère, dans le champ de cette obligation. Le FISA 702 va dans le même sens côté renseignement, en autorisant la collecte auprès des fournisseurs de communications électroniques de droit US. Un datacenter à Francfort n'éteint ni l'un ni l'autre : ils visent l'éditeur, pas le rack.

juridiction
  SCENARIO A : EASM d'un editeur de droit americain
  +----------------+     +----------------+     +-------------------------+
  | Votre surface  | --> | Cloud "en UE"  | --> | CLOUD Act / FISA 702    |
  | d'attaque      |     | editeur US     |     | acces legal possible    |
  +----------------+     +----------------+     +-------------------------+

  SCENARIO B : EASM souverain, editeur francais
  +----------------+     +----------------+     +-------------------------+
  | Votre surface  | --> | Heberge en FR  | --> | Droit europeen seul     |
  | d'attaque      |     | editeur FR     |     | RGPD, hors CLOUD Act    |
  +----------------+     +----------------+     +-------------------------+
Deux fois la même donnée, deux régimes juridiques : la localisation des serveurs ne dit pas tout.

Ce n'est pas un fantasme juridique. En 2020, la Cour de justice de l'Union européenne a invalidé le Privacy Shield dans l'arrêt dit Schrems II, au motif que les programmes de surveillance américains ne garantissaient pas un niveau de protection équivalent à celui du droit européen. Un successeur est arrivé depuis, l'EU-US Data Privacy Framework adopté en juillet 2023. Mais ce cadre ne touche pas à l'extraterritorialité du CLOUD Act sur un éditeur de droit américain. La CNIL et l'ANSSI raisonnent dans cette logique : pour les données vraiment sensibles, la géographie ne dit pas tout, encore faut-il savoir qui peut être contraint d'y accéder, et selon quelle loi. Un inventaire complet de votre surface d'attaque tombe en plein dans cette catégorie.

Le test simple
Devant n'importe quel EASM, posez une seule question : « Quelle est la nationalité de la société éditrice et de sa maison-mère ? » Si la réponse remonte, même de loin, vers un groupe de droit américain, la localisation des serveurs ne vous met pas hors du champ du CLOUD Act. Tout le reste est du marketing.

RGPD, NIS2 et souveraineté : ce que le droit européen attend

La souveraineté glisse peu à peu du registre de l'opinion vers celui de la conformité. Le RGPD encadre déjà les transferts de données hors UE et impose de documenter qui accède à quoi. Mais c'est surtout la directive NIS2 qui rebat les cartes pour des milliers d'organisations. On a détaillé le lien entre EASM et conformité NIS2 pour cartographier sa surface d'attaque externe : son article 21 impose des mesures de gestion des risques proportionnées, ce qui suppose en pratique de connaître et de gérer ses actifs exposés. Et si vous pensez que ça ne concerne que les grands groupes, la réalité de la sous-traitance rattrape vite les PME en première ligne de NIS2.

NIS2 vous demande de gérer le risque sur votre surface exposée, un EASM le fait, et il concentre au passage la donnée la plus sensible que vous puissiez produire. La confier à un éditeur soumis à une loi extraterritoriale revient à réinjecter du risque là où vous vouliez en retirer. Prendre un EASM souverain, c'est simplement éviter ce retour de bâton. Pour aller plus loin, le référentiel SecNumCloud de l'ANSSI formalise ces critères de souveraineté (immunité aux lois extra-européennes, hébergement et opération dans l'UE) pour les offres cloud les plus exigeantes. Des hébergeurs qualifiés comme OVHcloud, Scaleway ou 3DS Outscale s'y conforment.

« EASM souverain », concrètement : les critères

Le mot « souverain » est devenu un argument de vente, donc il ne veut plus dire grand-chose tout seul. Voici la grille qui sépare une vraie alternative française et européenne d'un habillage :

  • Hébergement en France ou dans l'UE : les données, les traitements et les sauvegardes restent sur des infrastructures situées dans l'Union. Pas juste le front-end, tout le pipeline, y compris les logs et les scans stockés.
  • Éditeur de droit français ou européen : la société qui opère l'outil, et sa maison-mère, relèvent du droit d'un État membre. C'est le critère qui neutralise le CLOUD Act, celui que la localisation des serveurs ne remplace pas.
  • Aucune sous-traitance des données hors UE : pas de brique d'IA, de stockage ou de monitoring déléguée en douce à un service américain. La chaîne de sous-traitants compte autant que l'éditeur principal, sinon la fuite se fait par un maillon.
  • Transparence sur la localisation : l'éditeur nomme ses hébergeurs, ses régions, ses sous-traitants, et l'écrit dans le contrat. « Vos données sont en sécurité » sans nom d'hébergeur, ça reste un slogan.
  • Scans non-intrusifs compatibles production : la souveraineté ne sert à rien si l'outil casse ce qu'il observe. Un EASM sérieux cartographie et corrèle sans marteler vos services, pour tourner en continu sur du vrai trafic sans vous mettre en incident.

À retenir

À retenir
  • Un EASM concentre la donnée la plus sensible de votre SI : inventaire complet des actifs exposés plus faiblesses priorisées, soit un mode opératoire d'intrusion déjà priorisé s'il tombe entre de mauvaises mains.
  • « Datacenter en Europe » ne protège ni du CLOUD Act ni du FISA 702 : ces lois s'appliquent à l'éditeur de droit américain où que soient ses serveurs.
  • L'arrêt Schrems II de la CJUE et la doctrine CNIL / ANSSI placent le curseur sur la juridiction applicable, plus que sur la seule géographie.
  • Un EASM souverain répond à une logique de conformité (RGPD, NIS2) et de réduction de risque.
  • Les vrais critères : hébergement UE, éditeur de droit français ou européen, zéro sous-traitance hors UE, transparence contractuelle, scans non-intrusifs. Le référentiel SecNumCloud les formalise.

Revenons à la question du début : vos données, elles vivent où ? Pour notre EASM hébergé en France, la réponse tient en trois mots : sous droit français, rien qui sorte de l'UE. Si le fonctionnement de l'outil vous paraît encore flou, revenez sur comment fonctionne un EASM. Le reste tient à une décision assez banale, au moment de signer : ne pas laisser le plan de vos faiblesses sous une loi qui n'est pas la vôtre.

Articles liés