SecNumCloud : l’ANSSI adapte son référentiel au Cloud de confiance, qu’est-ce qui change ?

Après plusieurs mois d'attente, l'Agence Nationale de la Sécurité des Systèmes d'Information (ANSSI) livre la version révisée de son référentiel d’exigences applicables aux prestataires de services d’informatique en nuage (SecNumCloud) pour l'adapter « Cloud de confiance » et l'isoler des lois extraterritoriales.

En mai dernier, le Gouvernement dévoilait sa nouvelle « doctrine cloud », mettant l'informatique en nuage « au centre » des choix de l'administration. Elle permettait également à des acteurs français de distribuer des services étrangers sous licence dans le cadre du « Cloud de confiance », donnant des garanties pour des données sensibles.

• Cloud de confiance : derrière le vernis souverain, le pied dans la porte des Américains
• Cloud de confiance : pour Guillaume Poupard (ANSSI), un enjeu politique

Cloud de confiance : l'ANSSI tente de marier la chèvre et le chou

Un label reposant en majeure partie sur la qualification SecNumCloud de l'ANSSI et donc de son référentiel qui vient expliquer les règles à suivre en matière d'organisation, de gouvernance, d'accès aux infrastructures, de gestion des sous-traitants, etc. Il valide l'existence de procédures précises et contraignantes, et n'est attribué que service par service, ce qui explique qu'il n'ait pour le moment que très peu d'entreprises candidates.

OVHcloud l'a par exemple obtenu pour son Hosted Private Cloud fourni depuis Roubaix et Strasbourg, mais pas encore pour son cloud public. Ses clients peuvent ainsi choisir cette offre, mais cela ne les qualifie pas SecNumCloud pour autant. Ils doivent eux aussi demander cette certification indépendamment.

C'est ce que fait Scalingo, un fournisseur de PaaS français basé sur l'infrastructure de 3DS Outscale, qualifiée SecNumCloud. Il est lui-même en cours de qualification, qu'il espère obtenir en 2022. 

Les modifications apportées par la nouvelle doctrine cloud viennent bien entendu modifier le référentiel de l'ANSSI. Ce dernier précise désormais comment une entreprise peut s'organiser pour se placer hors d'atteinte des lois extraterritoriales. En ligne de mire : le Cloud Act américain, mais aussi FISA ou l’Executive Order 12333.

Résultat, un document de 53 pages (plus 3 pages d'annexes) qui promet notamment une « clarification des exigences relatives à la protection contre toute réglementation extracommunautaire ». Il intègre au passage quelques changements, comme la prise en compte du CaaS (Container-as-a-Service).

Il fait aujourd'hui l'objet d'un appel public à commentaires. Chacun peut donc transmettre ses observations, remarques et propositions « jusqu’au 15 novembre 2021, par courriel, à l’adresse qualification[at]ssi.gouv.fr et à l’aide de la fiche de lecture. L’ANSSI remercie par avance tous ceux qui répondront à cet appel à commentaires ».

SecNumCloud : le changement, c'est maintenant

Ici, nous ne viendrons donc pas juger de la pertinence des choix effectués, qui peuvent évoluer. Nous détaillerons néanmoins les modifications apportées. En la matière, on ne peut d'ailleurs que féliciter la publication d'une version avec marques de révision par l'ANSSI qui facilite le travail d'analyse par les acteurs concernés.

Dans les premières pages du référentiel, peu modifiées, l'Agence rappelle quelques acronymes et définitions, le rôle des différents intervenants, mais aussi la structure et l'objet de ce document visant les services « Cloud » : 

« Il a vocation à permettre la qualification de cette famille de prestataires selon les modalités décrites au chapitre 3. Il permet au commanditaire de disposer de garanties sur les compétences du prestataire et de son personnel, sur la qualité de sa prestation et sur la confiance que le commanditaire peut accorder au prestataire. Il peut également être utilisé, à titre de bonnes pratiques, en dehors de tout contexte réglementaire.

Il n’exclut ni l’application de la législation et de la réglementation nationale, ni l’application des règles générales imposées aux prestataires en leur qualité de professionnels et notamment leur devoir de conseil vis-à-vis de leurs commanditaires. Ce référentiel est conçu sans présomption des technologies qui peuvent être utilisées pour implémenter les services. En particulier, l’expression « informatique en nuage » utilisée au sein de ce référentiel ne sous-entend pas forcément l’utilisation de solutions de virtualisation. »

La modification de certaines définitions donne un avant-goût de la suite. Outre un nettoyage, il y est désormais précisé dans la section consacrée au support technique qu'« aucun accès aux données des commanditaires n’est autorisé dans le cadre de ces tâches ». Le rôle d'administrateur d'infrastructure « est toujours sous la responsabilité du prestataire. Selon le mode de partage des responsabilités respectives décrites entre le prestataire et le commanditaire décrit dans la convention de service des rôles d'administrateur de sécurité, d’administrateur système, d’administrateur réseau... peuvent se trouver sous la responsabilité du prestataire ou celle du commanditaire ».

La convention de service doit d'ailleurs désormais « indiquer que la collecte, la manipulation et le stockage des données faits dans le cadre de l’avant-vente, de la mise en œuvre, de la maintenance et l’arrêt du service sont conformes aux exigences édictées par la législation française et européenne en vigueur et que ces mêmes données ne sont pas soumises à d’autres régimes juridiques ».

Concernant le CaaS qui fait son entrée, il a également droit à sa propre définition :

« Ce service concerne la mise à disposition d’environnements d’exécution permettant le déploiement et l’orchestration de conteneurs. Le commanditaire n’a pas la maîtrise de l’infrastructure technique sous-jacente (réseau, stockage, serveurs, système d’exploitation), gérée et contrôlée par le prestataire. Le commanditaire a cependant la maîtrise des outils systèmes, bibliothèques, intergiciels, et du code de l’application. »

Le tout est accompagné de l'habituel visuel détaillant qui gère quoi selon les cas (IaaS, CaaS, PaaS et SaaS) :

Plus loin il sera précisé que « lorsque le prestataire utilise un service de type CaaS comme socle d’un autre type de service (PaaS ou SaaS), les ressources affectées à l’usage du prestataire ne doivent en aucun cas être accessibles via l’interface publique mise à disposition des autres commanditaires du service CaaS ».

Quelques rappels...

L'ANSSI rappelle également que la qualification SecNumCloud n'est qu'une parmi d'autres et « ne se substitue pas aux exigences légales ou réglementaires applicables à certaines données spécifiques telles que les données de niveau Diffusion Restreinte ou les données de santé. L’hébergement de données spécifiques dans un service qualifié SecNumCloud nécessite le respect d’exigences complémentaires décrites dans les documents ».

Autre rappel intéressant au regard de l'évolution de la doctrine cloud de l'état et l'ouverture aux licences, notamment à des fournisseurs de services américains :

« Ce référentiel repose sur un objectif de protection des données du commanditaire, mais n’apporte pas de garanties techniques fortes contre un accès du prestataire aux données traitées sur le système d’information du service, uniquement des engagements contractuels. Les commanditaires souhaitant assurer la protection, sur le plan technique, de leurs données contre un accès par le prestataire, devront par conséquent mettre en œuvre des moyens complémentaires de chiffrement, sous leur maîtrise, de leurs données. »

Tout le but des modifications apportées étant d'expliquer comment le prestataire (l'entreprise française qui distribuera les services fournis par un acteur étranger) pourra elle-même se « protéger » d'acteurs extérieurs.

Dernier point de vigilance, classique : « la virtualisation généralement utilisée dans les services d’informatique en nuage ne doit pas être considérée comme un mécanisme de cloisonnement équivalent à une séparation physique ».

... et de nouvelles règles

Outre les très nombreuses obligations déjà imposées par le référentiel SecNumCloud, d'autres ont été ajoutées à l'occasion de cette mise à jour. Ainsi, dans les risques à prendre en compte, le prestataire doit désormais considérer ceux concernant « l'atteinte à la confidentialité des données des commanditaires par des tiers impliqués dans la fourniture du service (fournisseurs, sous-traitants, etc.) ».

Il doit également lister « dans un document spécifique, les risques résiduels liés à l’existence de lois extraterritoriales ayant pour objectif la collecte de données ou métadonnées des commanditaires sans leur consentement préalable » et « mettre à la disposition du commanditaire, sur demande de celui-ci, les éléments d’appréciation des risques liés à la soumission des données du commanditaire au droit d’un état non-membre de l’Union européenne ». Comprendre que le client d'une offre sous licence pourra se voir confirmer s'il existe ou non une possibilité d'accès à des données dans ce cadre, mais sur demande uniquement. 

Ainsi, il n'existe pas en l'état d’obligation de publier un tel document sur le site du prestataire par exemple, ou même de s'assurer qu'il soit visible, lu (et donc accepté) dans le processus de commande. Une précision qui aurait l'intérêt de permettre aux clients potentiels et au public de savoir de quoi il en retourne clairement. 

SecNumCloud concerne également le processus de sélection et d'embauche du personnel. Un point crucial puisque les employés sont susceptibles d'avoir accès aux données et services des clients, ils font donc l'objet de vérifications. Le prestataire doit ainsi « renforcer ces vérifications lorsqu’il s’agit de personnels disposant de privilèges d’administration élevés sur les composants logiciels et matériels de l’infrastructure du service. Il est entendu par des privilèges d’administration élevés, des actions permettant l’élévation de privilèges ou la possibilité de réaliser des actions sans traces techniques ou de désactiver, altérer les traces techniques ».

Dans le contrat de travail de tels employés, doit être ajouté « un engagement de responsabilité avec un renvoi aux clauses du code du travail sur la protection du secret des affaires et de la propriété intellectuelle. Il est entendu par des privilèges d’administration élevés, des actions permettant l’élévation de privilèges ou la possibilité de réaliser des actions sans traces techniques ou de désactiver, altérer les traces techniques ».

Pour ce qui est du contrôle d'accès « en cas d’intervention (actions de diagnostic, de maintenance, ou d’administration) en zone privée par un tiers visiteur, le prestataire doit faire superviser (suivre, autoriser, interdire, questionner) les actions par un personnel ayant satisfait aux vérifications de l’exigence 7.1.a) [une référence au processus de sélection des candidats, nldr] ». En zone dite sensible, « le prestataire doit faire superviser (suivre, autoriser, interdire, questionner) les actions par un personnel ayant satisfait aux vérifications de l’exigence 7.1.a ».

Géographie et procédures à suivre

Plus loin, il est aussi question de racine de confiance (root of trust) sur l’infrastructure technique. Le prestataire doit « utiliser exclusivement des certificats de clé publique issus d’une autorité de certification d’un état membre de l’Union européenne (les cérémonies de génération des clés maîtresses doivent avoir lieu dans un pays membre de l’Union européenne et en présence du prestataire) ».

On retrouve une telle obligation plus loin : « [il] doit stocker et traiter les données techniques (identités des bénéficiaires et des administrateurs de l’infrastructure technique, données manipulées par le Software Defined Network, journaux de l’infrastructure technique, annuaire, certificats, configuration des accès, etc.) au sein de l’Union européenne ».

En cas de besoin d'intervention par le support technique, « si les actions nécessaires au diagnostic et à la résolution
d’un problème rencontré par un commanditaire nécessitent un accès aux données du commanditaire » de nouvelles règles sont aussi imposées :

• n’autoriser l’accès aux données du commanditaire qu’après consentement explicite du commanditaire ;
• vérifier que la personne à qui l’accès doit être autorisé a satisfait aux vérifications de l’exigence 7.1.a) relative à la sensibilité ou à la spécificité des données du commanditaire ;
• vérifier que la personne à qui l’accès doit être autorisé est localisée au sein de l’Union européenne ;
• dans le cas d'une intervention réalisée à distance par une personne n’ayant pas satisfait aux vérifications de l’exigence 7.1.a), mettre en œuvre une passerelle sécurisée (poste de rebond) par laquelle la personne devra se connecter et permettant une supervision (autorisation ou interdiction des actions, demande d’explications, etc..) en temps réel, par une personne ayant elle-même satisfait aux vérifications de l’exigence 7.1.a) ;
• considérer les actions menées, une fois l’accès autorisé, comme des actions d’administration et les journaliser comme telles ;
• supprimer l’autorisation d’accès aux données du commanditaire au terme de ces actions.

Il en est de même en cas de télédiagnostic ou de télémaintenance de composants de l’infrastructure, « considérant les risques d’atteinte à la confidentialité des données des commanditaires ». Outre les règles ci-dessus, le prestataire doit « supprimer l’autorisation d’accès à l’issue de l’intervention ».

De manière générale, il doit également « fournir une capacité d'inspection et de suppression, si nécessaire, des entrants (contrôle de l’authenticité et de l'innocuité des mises à jour, contrôle de l’innocuité des outils fournis, etc.) relatifs au périmètre de l’infrastructure technique. [Elle] doit générer des journaux d'activité et doit pouvoir faire l'objet d'un audit de code, les entrants doivent être traités sur des dispositifs spécifiques opérés et maintenus par le prestataire et hébergés dans une zone cloisonnée du reste de l’infrastructure ».

Même chose pour les flux sortants puisqu'il : « doit fournir une capacité d'inspection et de suppression des sortants de l’infrastructure technique relatifs au périmètre du service (informations de facturation, les éventuels journaux nécessaires au traitement d'incidents, etc.). [Ils] doivent pouvoir être expurgés des données pouvant porter atteinte à la confidentialité des données des commanditaires. Cette capacité d'inspection et de suppression doit générer des journaux d'activité et doit pouvoir faire l'objet d'un audit de code. Les sortants sont traités sur des dispositifs spécifiques opérés et maintenus par le prestataire, et hébergés dans une zone cloisonnée du reste de l’infrastructure ».

Quid des sauvegardes ?

De nouvelles obligations concernent la sauvegarde de la configuration de l’infrastructure technique. Le prestataire doit ainsi « documenter et mettre en œuvre une procédure de sauvegarde hors-ligne » de cette dernière. Il doit également « documenter et mettre à disposition du commanditaire un service de sauvegarde de ses données ».

La convention de service doit d'ailleurs préciser « si les données du commanditaire sont automatiquement sauvegardées ou non. Dans la négative, le prestataire doit sensibiliser le commanditaire aux risques encourus et clairement indiquer les opérations à mener par le commanditaire pour que ses données soient sauvegardées ».

On se rappelle en effet que dans le cas de l'incendie du datacenter d'OVHcloud à Strasbourg, nombreux ont été les clients à s'apercevoir que leurs contrats ne comprenaient pas de sauvegarde tierce et qu'elle était de leur responsabilité. Une pratique courante, mais cela a poussé l'écosystème à plus de vigilance sur la question. OVHcloud a d'ailleurs annoncé depuis vouloir généraliser la sauvegarde et revoir sa stratégie de « résilience ».

• Une donnée informatique, ça brûle

En fin de contrat, le prestataire devait déjà procéder à un « effacement sécurisé de l’intégralité des données du commanditaire ». Désormais, il est précisé qu'il « doit faire l’objet d’un préavis formel au commanditaire de la part du prestataire respectant un délai de vingt et un jours calendaires ».

Une attention de chaque instant

De tels services et infrastructures sont bien entendu constamment sous surveillance, avec un audit régulier de la configuration notamment. « Cet audit est réalisé par échantillonnage et doit inclure tous types d’équipements et de serveurs présents dans le système d’information du service ». précisait déjà le référentiel de l'ANSSI.

Cela inclut un test d’intrusion des interfaces d'administration exposées sur un réseau public et de l'interface utilisateur pour les services SaaS. « Si le service bénéficie de développements internes » l'approche en continu doit être privilégiée pour l’audit de code source portant sur les fonctionnalités de sécurité précise l'Agence.

Il est également « recommandé que le prestataire mette en œuvre des mécanismes automatisés d'audit de la configuration adaptés à l’infrastructure technique du service ».

Dans le cadre de sa qualification, une revue initiale doit désormais être menée, indépendante, « par un prestataire d’audit de la sécurité des systèmes d’information [PASSI] qualifié ». Elle doit notamment couvrir :

• pour les services autres que IaaS (CaaS, PaaS, SaaS, etc.), un audit de la configuration des ressources virtuelles ou physiques, des systèmes d'exploitation et logiciels de base (OS, middlewares, bases de données,...) dans le périmètre du service ;
• un test d’intrusion portant sur les interfaces d'administration du service mises à disposition des commanditaires;
• pour un service de type SaaS, un test d'intrusion portant sur l'interface mise à disposition des utilisateurs finaux ainsi qu'un audit du code source portant sur les fonctionnalités de sécurité implémentées (authentification, gestion des sessions, gestion du cloisonnement en cas de mode multi-tenant). Si le SaaS rend un service de sécurité de l'information, une certification produit dédiée est nécessaire.

Dans ce dernier cas, « la délivrance du certificat est subordonnée à la correction des vulnérabilités critiques identifiées lors de la revue initiale » précise le référentiel SecNumCloud.

Il doit enfin y avoir une revue des changements majeurs « pouvant affecter le service », là aussi de manière indépendante, effectuée par un PASSI. Elle est également introduite par la mise à jour du référentiel et couvre :

• audit d’architecture ;
• audit organisationnel et physique ;
• audit de la configuration de l’infrastructure technique du service ;
• un test d’intrusion portant sur les interfaces d'administration du service mises à disposition des commanditaires;
• pour un service de type SaaS, un test d'intrusion portant sur l'interface mise à disposition des utilisateurs finaux ainsi qu'un audit du code source portant sur les fonctionnalités de sécurité implémentées (authentification, gestion des sessions, gestion du cloisonnement en cas de mode multi-tenant). Si le SaaS rend un service de sécurité de l'information, une certification produit dédiée est nécessaire.

Comment assurer l'immunité au droit extracommunautaire ?

Vient enfin le gros morceau : comment un prestataire fournissant un service étranger sous licence peut-il s'assurer de ne pas être soumis aux lois extraterritoriales, notamment américaines ? Si vous vous attendiez à voir des règles imposant au prestataire de disposer de son propre matériel plutôt que d'utiliser celui fourni dans le cadre de la licence (des serveurs Microsoft Azure ou Google Cloud) pour faire fonctionner les services, vous serez déçu.

Il en est de même si vous vous attendiez à voir l'ANSSI imposer des règles en matière de revue du code source ou des mises à jour. L'idée de mettre du gros sel autour du datacenter pour éloigner les services de renseignement étrangers n'a pas non plus été retenue. Qu'est-ce qui est donc censé protéger les données ainsi hébergées ?

Tout d'abord, la structure de l'entreprise qui fournit de tels services. On en avait eu un avant-goût à l'annonce de la création de Bleu, qui doit permettre à Cap Gemini et Orange de proposer des produits Microsoft avec le label Cloud de confiance et donc la qualification SecNumCloud, ou dans le cadre de l'accord entre Google et Thalès.

• Cloud souverain : deux ans après, on fait le point
• Cloud de confiance et licences US : Catherine Morin-Desailly questionne, l'écosystème réagit

Ainsi, « le siège statutaire, administration centrale ou principal établissement du prestataire doit être établi au sein d'un Etat membre de l'Union européenne. Le capital social et les droits de vote dans la société du prestataire ne doivent pas être, directement ou indirectement : individuellement détenus à plus de 24 % et collectivement détenus à plus de 39 % par des entités tierces possédant leur siège statutaire, administration centrale ou principal établissement au sein d’un État non membre de l’Union européenne ».

Comprendre que la société qui sera en charge du fonctionnement des services et de leur facturation sera européenne et ne pourra être contrôlée par l'entité américaine fournissant sa licence. Elle en restera néanmoins dépendante, puisque celle-ci étant la seule à pouvoir fournir son service (seul Microsoft peut accorder des licences Azure et Office par exemple) elle dispose d'un argument de poids dans le cadre de tels partenariats.

Plus loin, le référentiel précise néanmoins que « dans le cadre du paragraphe 3, toute société tierce à laquelle le prestataire recourt pour fournir tout ou partie du service rendu au commanditaire, doit garantir au prestataire une autonomie d’exploitation continue dans la fourniture des services d’informatique en nuage qu’il opère ou doit être qualifié SecNumCloud » ajoutant que « la notion d’autonomie d’exploitation est entendue comme étant la capacité de maintenir la fourniture du service d’informatique en nuage en faisant appel aux compétences propres du prestataire ou en recourant à des prestations disponibles auprès d’au moins deux sociétés tierces ».

On ne sait pas comment un tel engagement pourra être mis en œuvre dans le cas des offres sous licence proposées avec Google et Microsoft, cela fera donc partie des points à préciser d'ici à la constitution des sociétés françaises qui auront à les porter. Le référentiel de l'ANSSI impose également que « ces entités tierces susmentionnées ne peuvent pas individuellement, en vertu d’un contrat ou de clauses statutaires, disposer d’un droit de véto, désigner la majorité des membres des organes d’administration, de direction ou de surveillance du prestataire ».

Ce partenaire ne doit également pas avoir « la compétence pratique d’obtenir les données opérées au travers du service. Ces données visées sont celles qui sont confiées au prestataire par les commanditaires ainsi que toutes données techniques (identités des bénéficiaires et des administrateurs de l’infrastructure technique, données manipulées par le Software Defined Network, journaux de l’infrastructure technique, annuaire, certificats, configuration des accès, etc.) comprenant des informations sur les commanditaires. Pour les besoins du présent article, la notion de contrôle est entendue comme étant celle mentionnée au II de l’article L233-3 du Code de commerce ». Comment s'en assurer ? C'est là que le bât blesse. L'ANSSI ne va pas plus loin dans cette exigence. 

Il sera d'ailleurs intéressant de voir si ce point est précisé dans le cadre de l'appel à commentaires, puisque c'est ici que se noue la majeure partie du problème : par exemple si un prestataire venait à proposer un service qui lui est fourni sous la forme d'une boîte noire contenant du matériel et du logiciel sur lesquels il n'a pas la main puisqu'il n'a pas connaissance du code source. Il aura beau générer ses clés sur le sol européen et disposer d'une facturation européenne, le problème sera toujours présent, les critères nécessaires à la confiance étant absents.

Bien entendu, « le service fourni par le prestataire doit respecter la législation en vigueur en matière de droits fondamentaux et les valeurs de l’Union relatives au respect de la dignité humaine, à la liberté, à l’égalité, à la démocratie et à l’état de droit. Il peut être pris en considération pour l’appréciation de la conformité susmentionnée, le fait que le prestataire entretienne des liens avec un gouvernement ou un organisme public étrangers ».

Il ne s'agit là, précise l'Agence, que d'une formulation reprise de l’article R151-10 du code monétaire et financier à propos du contrôle des investissements étrangers en France.