La mesure op.nub.1 de l’annexe II de l’ENS exige que les services en nuage de tiers soient conformes à l’ENS ou respectent un guide CCN-STIC équivalent sur le pentesting, la transparence, le chiffrement/la gestion des clés et la juridiction des données. Elle s’applique déjà dès la catégorie basique, sans renforcement. Et un prestataire certifié ne vous décharge pas de votre responsabilité : l’article 13.5 du décret royal 311/2022 la laisse à l’entité qui fournit le service final.
Le Schéma national de sécurité espagnol (ENS) exige une mesure spécifique lorsqu’un système utilise des services en nuage : op.nub.1, protection des services en nuage. Et non, contracter un prestataire cloud « certifié » ou « compatible ENS » ne vous décharge pas de votre responsabilité : le décret royal 311/2022 lui-même indique, littéralement, que la responsabilité ultime reste celle de votre organisation.
La mesure spécifique : op.nub.1, « Protection des services en nuage »
Si vous envisagez de migrer, ou si vous travaillez déjà avec une infrastructure en nuage, voici ce que l’ENS exige de ce prestataire. La mesure op.nub.1 de l’annexe II du décret royal 311/2022 est la seule de sa famille (op.nub) et s’applique déjà dès la catégorie basique, sans renforcement. L’exigence [op.nub.1.1] renvoie la conformité aux guides CCN-STIC applicables selon le modèle de service contracté, et l’exigence [op.nub.1.2] ajoute, pour les services fournis par des tiers, l’exigence littérale suivante :
« Lorsque des services en nuage fournis par des tiers sont utilisés, les systèmes d’information qui les supportent doivent être conformes à l’ENS ou respecter les mesures développées dans un guide CCN-STIC qui inclura, entre autres, des exigences relatives à : a) l’audit de tests d’intrusion (pentesting) ; b) la transparence ; c) le chiffrement et la gestion des clés ; d) la juridiction des données. »
— Décret royal 311/2022, annexe II, exigence [op.nub.1.2] (BOE-A-2022-7191)
Cette mesure fait partie de la même annexe II que nous avons déjà détaillée ici, et elle s’applique déjà en basique : pour voir le reste des mesures de votre catégorie, consultez la liste complète de la catégorie basique.
Ce qu’elle exige selon le modèle de service : SaaS, PaaS et IaaS
L’exigence [op.nub.1.1] ne traite pas un SaaS comme un IaaS : plus le prestataire assume de responsabilité de gestion (SaaS), plus l’application des guides CCN-STIC correspondants lui incombe ; plus la responsabilité repose sur le client (IaaS), plus vous disposez d’un contrôle technique direct et plus vous devrez fournir vous-même de preuves. Nous avons déjà expliqué ici la différence entre ces trois modèles : l’ENS exige des choses différentes selon celui que vous contractez, non parce que la norme fait de la discrimination entre modèles, mais parce que la répartition réelle de la responsabilité technique change.
Dans un SaaS, le prestataire gère toute la pile technique : système d’exploitation, réseau, application. Là, les preuves que vous pouvez exiger sont surtout documentaires — certifications, rapports d’audit, clauses contractuelles — car vous n’avez pas d’accès direct à l’infrastructure sous-jacente. Dans un IaaS, le prestataire ne gère que la couche d’infrastructure physique et de virtualisation ; le système d’exploitation, les applications et une bonne partie de la configuration de sécurité restent de votre côté, si bien que les preuves qu’exige op.nub.1 sur le « service en nuage » se répartissent entre ce qu’apporte le prestataire et ce que vous devez documenter vous-même. Un PaaS se situe à mi-chemin : le prestataire gère l’environnement d’exécution, mais le code et une bonne partie de la configuration de l’application restent de votre responsabilité. Confondre ces trois répartitions est la cause la plus fréquente d’une déclaration d’applicabilité incomplète pour op.nub.1 : on documente ce qu’apporte le prestataire et on oublie ce qui reste du côté du client.
Ce qu’il faut exiger d’un prestataire cloud tiers : conformité ENS ou guide CCN-STIC équivalent
L’annexe II elle-même prévoit deux voies valables pour un prestataire tiers : que le service soit conforme à l’ENS, ou qu’il respecte un guide CCN-STIC équivalent couvrant les quatre points cités dans la citation ci-dessus. Il ne suffit pas de demander « une certification de sécurité » de façon générique : il faut demander une preuve concrète de ces quatre points, ou de la conformité ENS du service contracté. Il ne suffit pas non plus de supposer qu’un prestataire connu internationalement respecte cela automatiquement du fait de sa taille ou de sa réputation : l’exigence est documentaire et précise, pas une présomption de confiance.
Dans la pratique, cela se traduit par le fait de demander au prestataire, avant de signer, la documentation concrète attestant chacun de ces quatre points — pas une déclaration générique du type « nous respectons les standards du secteur » —, et de consigner par écrit quel guide CCN-STIC ou quel schéma de conformité ENS couvre le service contracté. Si le prestataire ne peut pas identifier précisément laquelle des deux voies couvre son service, c’est le signe que l’analyse n’a pas encore été faite, ni de son côté ni du vôtre.
Les quatre points que le guide exige de vérifier : pentesting, transparence, chiffrement et gestion des clés, juridiction des données
- Audit de tests d’intrusion (pentesting) : exiger une preuve que le service est soumis à des tests d’intrusion périodiques. L’exigence de pentesting envers le prestataire cloud renvoie directement à pentesting et red teaming, détaillé dans ce guide.
- Transparence : une visibilité réelle sur où et comment les données sont traitées, pas une déclaration générique de confiance.
- Chiffrement et gestion des clés : le chiffrement en transit qu’exige ce guide repose sur les mêmes fondamentaux du TLS déjà traités ici, en plus de la gestion du cycle de vie des clés.
- Juridiction des données : à quelle loi le prestataire est soumis, pas seulement dans quel pays physique se trouve le centre de données. Cette nuance — un prestataire peut être soumis à une législation étrangère même s’il héberge les données dans un centre de données européen — mérite d’être vérifiée au cas par cas dans le contrat, pas tenue pour acquise.
Les renforcements : certification reconnue (R1) et guides de configuration spécifiques (R2)
Au-dessus de la mesure de base, l’annexe II ajoute deux renforcements : R1 exige que le service soit certifié selon une méthodologie reconnue par l’organisme de certification du CCN, et R2 exige que la configuration du service suive un guide CCN-STIC de configuration de sécurité spécifique.
Ce qu’exige chaque catégorie : basique, moyenne et haute pour op.nub.1
- Catégorie basique : op.nub.1 sans renforcement.
- Catégorie moyenne : op.nub.1 + R1 (certification reconnue).
- Catégorie haute : op.nub.1 + R1 + R2 (certification reconnue et guide de configuration spécifique).
La responsabilité ne se transfère PAS au prestataire (même certifié)
L’article 13.5 du décret royal 311/2022 est explicite sur ce point. Dans les services externalisés, le prestataire désigne un point de contact de sécurité, mais :
« [...] sans préjudice du fait que la responsabilité ultime incombe à l’entité du secteur public destinataire desdits services. »
— Décret royal 311/2022, art. 13.5 (BOE-A-2022-7191)
Un prestataire cloud certifié ENS réduit le risque et facilite la preuve, mais ne transfère pas la responsabilité juridique. Si votre prestataire cloud fait défaut, la continuité du service dépend toujours d’un véritable plan de sauvegarde et de reprise, pas seulement de la promesse du prestataire ; et du fait que ces sauvegardes restaurent réellement, pas seulement qu’elles existent.
Cette répartition de la responsabilité a une conséquence pratique souvent négligée : si un incident de sécurité trouve son origine dans l’infrastructure du prestataire cloud, l’entité qui fournit le service final reste celle qui répond devant l’auditeur de conformité de l’ENS, reste celle qui doit notifier l’incident selon ses propres procédures, et reste celle qui assume les conséquences d’une éventuelle sanction ou d’un manquement. Le contrat avec le prestataire peut ensuite répartir cette responsabilité économique entre les parties, mais cela se joue sur un plan différent — civil ou commercial — de celui que fixe l’article 13.5 : face à l’ENS, la responsabilité ne se sous-traite pas.
Comment cela se traduit dans la pratique : clauses contractuelles et preuves à demander
Dans un contrat ou un cahier des charges avec un prestataire cloud soumis à op.nub.1, il convient d’exiger par écrit : la preuve de conformité ENS ou du respect du guide CCN-STIC équivalent ; des rapports de pentesting périodiques ; une documentation du chiffrement en transit et au repos avec une gestion des clés clairement définie, propre ou partagée ; et une clause explicite de juridiction des données. Calculez en outre le coût réel d’une sauvegarde en nuage respectant ces exigences avec cet outil (disponible en espagnol).
Une erreur fréquente lors de la préparation de la déclaration d’applicabilité consiste à documenter op.nub.1 par une seule phrase générique du type « on utilise un prestataire cloud de confiance » et à considérer le sujet clos. L’auditeur de conformité — ou le responsable de la sécurité lui-même dans une autoévaluation en basique — a besoin de preuves concrètes et datées : le contrat ou l’annexe technique où figure la voie de conformité choisie, le dernier rapport de pentesting reçu du prestataire (ou commandé à un tiers sur le service contracté), et la politique de chiffrement et de gestion des clés appliquée, en précisant qui détient les clés et dans quelles conditions on peut y accéder. Sans ces trois documents datés, la mesure est déclarée mais pas démontrée, ce qui est précisément la distinction entre une autoévaluation solide et une autoévaluation de pure forme.
Auditer si votre prestataire cloud actuel respecte ce qu’exige op.nub.1 fait partie de notre service de mise en œuvre technique de l’ENS.
Questions fréquentes
Un prestataire cloud certifié ENS me décharge-t-il de ma responsabilité ?
Non. L’article 13.5 du décret royal 311/2022 établit que la responsabilité ultime incombe à l’entité qui fournit le service final, même si le prestataire cloud sous-traité est certifié et désigne son propre point de contact de sécurité.
Ai-je besoin d’un prestataire avec une déclaration de conformité ENS, ou une certification internationale (ISO 27001, SOC 2) suffit-elle ?
L’exigence [op.nub.1.2] exige soit la conformité à l’ENS, soit le respect d’un guide CCN-STIC équivalent couvrant le pentesting, la transparence, le chiffrement/la gestion des clés et la juridiction des données. Une certification internationale générique ne remplace pas automatiquement cette exigence : il faut demander une preuve précise de ces quatre points.
À partir de quelle catégorie cette mesure s’applique-t-elle ?
Dès la catégorie basique, sans renforcement. Le renforcement R1 (certification reconnue) s’ajoute en moyenne, et R1 et R2 (en plus du guide de configuration spécifique) s’ajoutent en haute.
Ce contenu a un caractère informatif et pédagogique. Il ne constitue pas un conseil juridique et ne remplace pas l’analyse d’un professionnel qualifié pour votre cas concret.