Conformité & réglementation

SecNumCloud : les obligations qui touchent l'authentification

SecNumCloud et authentification : ce que la qualification ANSSI exige du prestataire, ce qui reste à votre charge, et comment le vérifier en appel d'offres.

SecNumCloud est une qualification délivrée par l'ANSSI à des prestataires de services cloud. Ce n'est pas une loi, et ce n'est pas votre organisation qui est qualifiée : c'est le service que vous consommez. La question utile pour un RSSI n'est donc pas de savoir s'il est « conforme SecNumCloud », mais quel niveau d'exigence imposer aux briques qu'il externalise, et comment le vérifier. Sur l'authentification, la qualification fournit un langage commun avec vos fournisseurs — à condition de savoir ce qu'elle couvre et ce qu'elle laisse chez vous.

Cet article propose une lecture opérationnelle et ne constitue pas un avis juridique. SecNumCloud relève d'une démarche volontaire de qualification, distincte d'une obligation réglementaire : l'opportunité de l'exiger dans un contrat donné doit être appréciée avec vos conseils.

Une qualification, pas une réglementation

Le mécanisme tient en trois temps. Un référentiel fixe des exigences techniques et organisationnelles applicables au service cloud. Un évaluateur audite le prestataire au regard de ces exigences. L'ANSSI prononce ensuite une décision de qualification portant sur un service précis. Rien de tout cela ne s'applique à votre système d'information : l'objet qualifié est l'hébergement et l'exploitation d'un service, pas la manière dont vos agents s'y connectent.

Le référentiel est exigeant sur plusieurs axes qui parlent à un RSSI : contrôle d'accès et authentification des accès d'administration, cloisonnement, journalisation, protection des données, localisation des données et des opérations, et des critères visant à protéger les données vis-à-vis de législations extra-européennes à portée extraterritoriale. Le vocabulaire de la qualification s'arrête là ; le reste de cet article traite de ce que vous pouvez en faire.

Ce que le référentiel fait peser sur l'authentification du prestataire

Un administrateur d'infrastructure chez un fournisseur cloud dispose d'un pouvoir supérieur à celui de vos propres administrateurs : il peut, selon les cas, atteindre l'hyperviseur, les sauvegardes ou les journaux. Le référentiel traite cette population comme un risque de premier rang : robustesse de l'authentification de ces accès privilégiés, séparation des rôles d'exploitation, limitation des accès permanents, capacité à retracer les opérations menées sur le service.

L'effet côté client est un point d'appui pour poser des questions habituellement esquivées. Comment ces administrateurs s'authentifient-ils ? Que reste-t-il comme trace d'une intervention sur votre environnement, et cette trace vous est-elle accessible ? La logique rejoint celle des accès à privilèges internes : ce qui n'est pas journalisé de façon exploitable ne se démontre pas six mois plus tard.

Le partage des responsabilités : la moitié qui reste chez vous

La qualification porte sur l'hébergement et l'exploitation. Elle ne dit rien de la façon dont vos utilisateurs et vos administrateurs délégués accèdent au service. Un service qualifié piloté depuis une console client protégée par un mot de passe et un code reçu par SMS reste exposé aux techniques de relais courantes — le NIST SP 800-63B classe d'ailleurs l'OTP par SMS ou voix comme « restricted », c'est-à-dire déconseillé. La qualification du fournisseur ne compense pas une faiblesse située de votre côté de la frontière.

Restent donc intégralement à votre charge : les comptes de vos utilisateurs, les administrateurs que vous désignez sur la console d'administration, les comptes de service et clés d'API que vous créez, la fédération d'identité que vous branchez, et surtout les parcours de récupération de compte, qui constituent la porte d'entrée la plus souvent négligée.

Ce que la qualification adresse chez le prestataire Ce qu'elle ne dit pas de votre côté Question à poser dans l'appel d'offres
Authentification des accès d'administration du service La robustesse de l'authentification de vos administrateurs sur la console client Quelles méthodes peut-on imposer, et lesquelles peut-on interdire, aux comptes que vous administrez ?
Journalisation des opérations d'exploitation Ce que vous pourrez produire en cas de litige interne Quels journaux me sont restitués, sous quel format, et exploitables par quel outil ?
Cloisonnement entre clients L'étanchéité de vos propres environnements Comment la séparation est-elle démontrée, et qui peut la franchir côté exploitant ?
Localisation des données et des opérations La localisation des briques que vous ajoutez par-dessus Où sont les données, et où sont physiquement les personnes qui les administrent ?
Protection vis-à-vis de législations extraterritoriales Vos comptes de service et vos clés d'API Quels sous-traitants interviennent, et quel droit s'applique à chacun ?

Articulation avec ISO 27001 et avec la souveraineté

ISO/IEC 27001 et SecNumCloud ne se substituent pas l'une à l'autre. La première atteste d'un système de management de la sécurité, dont le périmètre est déclaré par l'organisation elle-même. La seconde qualifie un service au regard d'un référentiel imposé, avec une décision rendue par une autorité publique. La question à poser n'est donc jamais « êtes-vous certifié ? » mais « quel périmètre exact est couvert, et par quel dispositif ? ». Pour comparer des fournisseurs, la grille d'évaluation est plus utile qu'une liste de logos.

Sur la souveraineté, la qualification agit comme un filtre : elle intègre la localisation et la protection face aux législations extraterritoriales, sujet qu'un questionnaire sécurité classique traite mal. C'est la logique dans laquelle s'inscrit HIAsecure, conçue, développée et hébergée en France, avec une architecture décentralisée et aucune donnée identifiante détenue ; HIAsecure est engagée dans une démarche de qualification SecNumCloud, aujourd'hui en cours.

Par où commencer

  1. Listez les briques externalisées qui participent à une décision d'accès : fournisseur d'identité, service de MFA, annuaire, portail d'authentification, service de messagerie utilisé pour la récupération de compte.
  2. Classez-les par conséquence en cas de compromission, pas par coût. Une brique modeste qui arbitre une ouverture de session pèse plus lourd qu'un stockage volumineux.
  3. Séparez par contrat les responsabilités : ce qui relève du fournisseur, ce qui relève de vous. L'ambiguïté sur les comptes d'administration client est le trou le plus fréquent.
  4. Traduisez vos attentes en résultats — nominativité, non-rejouabilité, journalisation restituable — plutôt qu'en produits imposés.
  5. Testez la sortie : que récupérez-vous, sous quel format, si le contrat s'arrête ?
  6. Vérifiez la localisation des opérations d'administration, pas seulement celle des données.

FAQ

Mon organisation peut-elle être « conforme SecNumCloud » ?

Non, la formulation n'a pas de sens. La qualification vise des prestataires de services cloud et porte sur un service donné. Vous pouvez en revanche décider d'imposer ce niveau d'exigence à certaines briques que vous externalisez, et l'écrire dans vos contrats.

Un service qualifié me dispense-t-il de renforcer mes propres accès ?

Non. La qualification couvre l'hébergement et l'exploitation du service. L'authentification de vos utilisateurs et de vos administrateurs délégués reste sous votre responsabilité, y compris les parcours de récupération de compte et les comptes de service.

La qualification remplace-t-elle une certification ISO 27001 ?

Non, les deux dispositifs ne recouvrent ni le même objet ni la même portée. Ils se complètent : l'un porte sur la gouvernance de la sécurité dans une organisation, l'autre sur les caractéristiques d'un service précis. Demandez systématiquement le périmètre couvert.

Comment traiter un fournisseur indispensable mais non qualifié ?

Par l'équivalence documentée : identifiez les exigences qui comptent réellement, demandez comment il les satisfait, et contractualisez les points sensibles — accès d'administration, journaux restituables, localisation, sous-traitance, réversibilité.


Aller plus loin : le pilier : authentification cognitive · ISO 27001 et authentification · les risques liés aux législations extraterritoriales · héberger ses données en France

Demander une démonstration

Prouver l'intention, pas un secret

Découvrez le 4ᵉ facteur cognitif appliqué à vos parcours sensibles.

Demander une démonstration