ENS et cloud : exigences et guide CCN-STIC 823.

En bref : Le Schéma National de Sécurité (ENS) peut être respecté dans le cloud, et de plus en plus de cahiers des charges l'exigent. La colonne vertébrale est le guide CCN-STIC 823 et la mesure op.nub.1 « Protection des services dans le cloud » de l'Annexe II du Décret royal 311/2022, qui renvoie aux guides CCN-STIC selon le modèle de service. La règle qui ne change pas : l'organisme propriétaire de l'information reste responsable, même s'il délègue l'exploitation à un tiers. Je distingue ici les deux points de vue — l'Administration qui consomme du cloud et le SaaS qui veut le lui vendre —, j'explique le modèle de responsabilité partagée sous l'angle de l'ENS, les profils CCN-STIC 884-887 des hyperscalers, le rôle du catalogue CPSTIC et les étapes pour un prestataire qui part de zéro.

Oui, on peut respecter l'ENS dans le cloud, mais il ne suffit pas de contracter un prestataire « sécurisé ». La référence est le guide CCN-STIC 823 (utilisation des services dans le cloud) ; la mesure op.nub.1 de l'Annexe II vous oblige à exiger la conformité du prestataire selon le modèle de service (SaaS, PaaS, IaaS), et l'organisme reste responsable de sa part dans le cadre du modèle de responsabilité partagée.

Cet article traite d'une chose précise : comment se conformer à l'ENS (schéma national de sécurité espagnol) dans le cloud. Ce n'est pas la même chose que la sécurité cloud en général. Si vous cherchez comment protéger les données de votre entreprise dans le cloud — chiffrement, sauvegardes, contrôle des accès, RGPD — je le développe dans mon guide sur la sécurité dans le cloud pour les entreprises. Ici, c'est plus spécifique et plus exigeant : la conformité au Schéma National de Sécurité lorsque le service vit dans le cloud, avec le guide CCN-STIC 823 comme référence et le secteur public en jeu. Je l'aborde à la fois du côté de l'organisme qui veut migrer et du côté du prestataire SaaS qui veut entrer dans un appel d'offres.

Peut-on respecter l'ENS dans le cloud ? (réponse rapide)

Oui, et ce n'est pas une interprétation : l'ENS lui-même le prévoit. Voici les cinq points qui résument tout le reste :

• Il existe un guide spécifique. Le CCN-STIC 823 encadre l'utilisation des services dans le cloud au sein du périmètre de l'ENS : modèles de service, modèles de déploiement et conditions pour consommer du cloud avec des garanties.
• Il existe une mesure spécifique. La famille op.nub de l'Annexe II — en particulier op.nub.1, « Protection des services dans le cloud » — s'applique dès la catégorie BASIQUE et exige que le service cloud respecte l'ENS ou les mesures du guide CCN-STIC correspondant.
• La responsabilité ne s'externalise pas. L'organisme propriétaire de l'information reste garant de la conformité même s'il contracte avec un tiers.
• Les grands fournisseurs ont déjà fait le chemin. Azure, Microsoft 365 ou AWS disposent de profils de conformité CCN-STIC (884, 885, 887), mais ils couvrent leur part, pas la vôtre.
• La conformité s'atteste. Par déclaration en catégorie BASIQUE ou par certification en MOYENNE et HAUTE, avec un périmètre qui doit véritablement couvrir le service fourni.

Le reste de l'article développe chaque point et le traduit en décisions concrètes selon que vous soyez du côté de l'acheteur public ou du prestataire.

Qu'est-ce que le guide CCN-STIC 823 et que résout-il

Le CCN-STIC 823, « Utilisation des services dans le cloud », est le guide de la série 800 du Centre Cryptologique National consacré à transposer l'ENS aux environnements cloud. Il répond à un problème réel : l'Annexe II a été pensée pour des systèmes où l'organisation contrôle l'infrastructure, alors que dans le cloud ce contrôle se partage avec le prestataire. Le guide traduit ce partage en critères opérationnels.

Ce que fixe le guide 823, en pratique :

• Modèles de service. Il distingue l'IaaS (le client contrôle les systèmes d'exploitation, le stockage et les applications), le PaaS (il contrôle les applications, pas l'infrastructure) et le SaaS (il consomme le logiciel sans administrer la plateforme). Plus le service est « haut », plus le prestataire assume de responsabilité.
• Modèles de déploiement. Cloud public, privé, communautaire et hybride, chacun avec des implications différentes en matière d'isolement et de contrôle.
• Niveaux et dimensions de sécurité. Le service est évalué selon les cinq dimensions de l'ENS — disponibilité, intégrité, confidentialité, authenticité et traçabilité — et se voit attribuer un niveau qui entraîne les mesures exigibles.
• Ce qu'il faut exiger du prestataire par contrat. Description du service, niveaux de sécurité, localisation des données, procédures de sauvegarde et d'effacement, et conformité aux mesures de l'Annexe II selon la catégorisation.

Une nuance utile du guide : si vous chiffrez l'information avant de la transférer vers le cloud et que vous gérez vous-même les clés, une bonne partie des exigences envers le prestataire se concentrent sur la dimension de disponibilité, car le prestataire ne peut pas accéder au contenu. Cela n'élimine pas les obligations, mais cela change le point de focalisation.

La mesure op.nub de l'Annexe II : ce qu'elle impose dans le cloud

La réforme du Décret royal 311/2022 a intégré à l'Annexe II une nouvelle famille de mesures au sein du cadre opérationnel : op.nub, services dans le cloud. C'est le point où l'ENS cesse de traiter le cloud comme un cas particulier de « services externes » et lui donne une entité propre.

La mesure op.nub.1, « Protection des services dans le cloud », s'applique dès la catégorie BASIQUE — c'est-à-dire dans toutes — et signifie ceci : les systèmes qui fournissent des services dans le cloud au secteur public respectent l'ensemble des mesures de sécurité selon le modèle de service (SaaS, PaaS, IaaS), conformément aux guides CCN-STIC applicables. Et lorsque des services cloud tiers sont utilisés, les systèmes qui les soutiennent doivent être conformes à l'ENS ou respecter les mesures d'un guide CCN-STIC qui inclut, entre autres, des exigences de tests d'audit.

La conséquence pratique est double. Pour l'organisme, op.nub.1 transforme « contracter du cloud » en « contracter du cloud conforme » : l'exigence cesse d'être optionnelle. Pour le prestataire, elle fixe le standard qu'il devra démontrer. Et comme la mesure elle-même renvoie aux guides CCN-STIC, le 823 et les profils spécifiques de chaque plateforme cessent d'être des recommandations pour devenir la voie attendue.

Responsabilité partagée : ce que vous pouvez déléguer et ce que vous ne pouvez pas

Le modèle de responsabilité partagée est l'endroit où le plus de projets déraillent. L'idée que répète le CCN-STIC 823 est catégorique : la responsabilité de la conformité à l'ENS incombe toujours à l'organisme propriétaire de l'information. Vous pouvez déléguer l'exploitation ; vous ne pouvez pas déléguer la responsabilité.

La ligne qui sépare ce qu'assume le prestataire de ce qui reste de votre ressort dépend du modèle de service :

• En IaaS, le prestataire répond du centre de données, de la virtualisation et de la disponibilité physique ; vous répondez du système d'exploitation vers le haut : correctifs, configuration, identités, données.
• En PaaS, le prestataire monte d'un échelon et gère la plateforme ; vous continuez à répondre de l'application, de ses accès et de l'information.
• En SaaS, le prestataire assume presque toute la pile technique, mais vous ne cessez jamais de répondre de la gestion des identités, de la configuration du service, de la classification de l'information et de son cycle de vie.

Il y a une constante dans les trois modèles : l'identité, la configuration et les données restent presque toujours de votre côté. L'erreur classique est de considérer que « puisque le prestataire a l'ENS, je suis déjà conforme ». Non : sa conformité couvre sa part du partage. La vôtre, vous devez toujours la mettre en œuvre et la démontrer.

Si vous êtes une Administration : comment contracter du cloud conforme à l'ENS

Lorsqu'un organisme veut consommer du cloud sans sortir du cadre de l'ENS, le travail commence avant même de choisir un prestataire. La séquence que je recommande :

• Catégorisez d'abord le système. Évaluez l'information et les services selon les cinq dimensions et déterminez la catégorie (BASIQUE, MOYENNE ou HAUTE). Cette catégorie fixe ce que vous pouvez exiger du cloud.
• Transposez la catégorie dans le cahier des charges. Ne demandez pas « un prestataire avec l'ENS » : demandez la conformité dans la catégorie qui correspond, avec un périmètre qui couvre le service concret que vous allez utiliser, pas une autre unité du prestataire.
• Fixez la localisation des données. Selon la catégorie et le type d'information, exigez un traitement dans l'UE et, le cas échéant, sur le territoire national, avec la juridiction clarifiée par contrat.
• Réservez vos responsabilités. Précisez par écrit quelles mesures vous mettez en œuvre vous-même (identité, chiffrement avec des clés sous votre contrôle, journalisation de l'activité, continuité) et lesquelles relèvent du prestataire.
• Demandez des preuves auditables. Rapports de conformité, journaux accessibles, résultats des tests d'audit que la mesure op.nub.1 elle-même mentionne.

Si vous comptez exiger l'ENS à vos prestataires dans un cahier des charges, il convient de clarifier au préalable qui est tenu de respecter l'ENS et dans quelles conditions, afin de ne pas en demander ni trop ni trop peu.

Si vous êtes un SaaS ou un prestataire cloud : comment vendre à l'Administration grâce à l'ENS

De l'autre côté de la table, la question change : de quoi ai-je besoin pour qu'un organisme public puisse me contracter sans être en infraction ? La réponse courte est d'attester la conformité ENS de votre service dans la catégorie que demandent les cahiers des charges, et d'avoir un périmètre bien défini.

Ce qui, d'après mon expérience, fait la différence :

• Périmètre de la déclaration ou de la certification. Le certificat doit couvrir le service que vous vendez et la plateforme depuis laquelle vous le fournissez. Un certificat réel dont le périmètre n'inclut pas votre produit ne vous sert à rien pour soumissionner.
• Catégorie adéquate. La catégorie BASIQUE peut s'attester par déclaration de conformité ; MOYENNE et HAUTE exigent une certification par un organisme accrédité. Visez celle que vous demanderont vos clients publics.
• Héritage des contrôles. Si vous vous appuyez sur un hyperscaler doté d'un profil CCN-STIC, vous pouvez hériter d'une partie de ses contrôles, mais vous devez documenter ce que vous ajoutez par-dessus.
• Audit préparé. Le processus comprend des tests d'audit ; arriver avec la documentation et les preuves classées raccourcit les délais et le coût. J'en détaille le parcours dans le processus et les coûts de la certification ENS.

Si vous évoluez habituellement dans les appels d'offres publics, je développe dans ENS pour les prestataires de l'Administration comment cette exigence apparaît dans les cahiers des charges et comment elle se répercute en cascade sur les sous-traitants.

Les services cloud dans le CPSTIC et les profils CCN-STIC 884-887

C'est là que beaucoup de prestataires se perdent, car deux mécanismes distincts coexistent.

D'un côté, le catalogue CPSTIC du CCN inclut une taxonomie des services dans le cloud : il recense des produits et services qualifiés pour les systèmes concernés par l'ENS en catégories MOYENNE et HAUTE. Qu'un service figure au CPSTIC donne à l'acheteur public une confiance minimale vérifiée par le Centre lui-même. L'accès au catalogue complet nécessite une inscription en tant qu'utilisateur du CCN.

De l'autre, il existe des profils de conformité spécifiques : des guides CCN-STIC qui détaillent comment déployer un hyperscaler donné de façon conforme à l'ENS. Ceux qu'il convient de connaître :

• CCN-STIC 884 — profil de conformité spécifique pour Azure (service de cloud d'entreprise).
• CCN-STIC 885 — profil pour Microsoft 365, avec ses guides de configuration sécurisée associés.
• CCN-STIC 886 — profil pour les clouds privés et communautaires.
• CCN-STIC 887 — profil de conformité spécifique pour AWS (service de cloud d'entreprise), avec son guide de configuration.

L'idée de ces profils est que vous ne partiez pas de zéro : si vous déployez sur Azure ou AWS en suivant son guide, vous héritez d'une base de contrôles déjà travaillée et vous vous concentrez sur votre part. Cela dit, un profil de plateforme n'est pas un certificat de votre service : il atteste comment utiliser le cloud de façon conforme, pas que votre SaaS l'est. Cette distinction évite bien des malentendus lors de la négociation.

Mesures de l'Annexe II en lecture cloud : chiffrement, données et localisation

Les mesures de sécurité de l'Annexe II ne changent pas dans le cloud, mais leur application et la répartition des responsabilités, si. Ce tableau résume la lecture cloud de celles qui pèsent le plus dans un projet réel.

La lecture transversale est celle de toujours dans le cloud : le prestataire apporte la capacité technique ; vous apportez la gouvernance. Chiffrement, identité et données restent rarement en dehors de votre responsabilité, même si c'est sa plateforme qui les exécute.

Étapes pour un SaaS qui part de zéro

Si vous avez un produit et voulez le vendre à l'Administration mais n'avez jamais touché à l'ENS, voici l'ordre qui fonctionne :

• 1. Délimitez le périmètre. Quel service exact allez-vous attester et sur quelle infrastructure tourne-t-il. Tout le reste dépend de cette phrase.
• 2. Catégorisez. Évaluez votre service selon les cinq dimensions et fixez la catégorie cible en fonction de ce que demandent vos clients potentiels.
• 3. Choisissez votre base cloud. Si vous comptez vous appuyer sur un hyperscaler, adoptez son profil CCN-STIC (884, 885, 887) et héritez de ce que vous pouvez hériter.
• 4. Analyse des risques et déclaration d'applicabilité. Documentez quelles mesures de l'Annexe II s'appliquent et comment vous les couvrez, en distinguant ce qui est hérité de ce qui vous est propre.
• 5. Mettez en œuvre ce qui manque. Identité, chiffrement, journalisation, continuité et gestion des incidents dans votre couche de service.
• 6. Auditez et attestez. Déclaration de conformité en BASIQUE ou certification par un organisme accrédité en MOYENNE et HAUTE, après avoir réussi l'audit de conformité.

Il n'y a pas de raccourcis, mais il existe un ordre qui évite de refaire le travail : périmètre, catégorie, héritage, documentation, mise en œuvre et audit. Sauter l'étape du périmètre au départ est l'erreur qui coûte le plus cher.

Conclusion : le cloud ne vous sort pas de l'ENS, il change la répartition

Migrer vers le cloud ne dilue pas le Schéma National de Sécurité ; cela redistribue qui fait quoi. Le guide CCN-STIC 823 et la mesure op.nub.1 fixent les règles, les profils CCN-STIC et le CPSTIC vous font gagner du chemin, mais la responsabilité de l'information ne migre vers aucun serveur tiers : elle reste avec vous. Un organisme qui le comprend contracte mieux ; un prestataire qui le comprend vend plus vite.

Si vous envisagez de migrer un système public vers le cloud, ou si vous avez un SaaS et qu'on vient de vous demander l'ENS pour entrer dans un appel d'offres, racontez-moi votre cas et on l'examine ensemble, sans engagement.

Besoin d'attester la conformité de votre service cloud pour vendre à l'Administration ? Découvrez mon service de conseil ENS pour les entreprises qui veulent soumissionner ou devenir prestataires du secteur public.

Sources

• Décret royal 311/2022 (ENS), Annexe II · BOE — texte consolidé officiel.
• Guide CCN-STIC 823 · Utilisation des services dans le cloud.
• Catalogue CPSTIC du CCN · produits et services STIC.
• Portail de l'ENS · Centre Cryptologique National.
• CCN-CERT · profils de conformité CCN-STIC 884-887.

Contenu rédigé par Ángel Ortega Castro pour angelortegacastro.com. Information à visée pédagogique ; pour toute obligation légale, consultez le texte en vigueur du Décret royal 311/2022 et le guide CCN-STIC 823 correspondant.