Sécurité du segment sol : ce qu'un opérateur de satellites vérifie avant d'ouvrir l'accès à un fournisseur

Avant qu’un fournisseur n’entre dans un segment sol, un opérateur de satellites vérifie qui aura accès, comment la connexion se fait et ce que cet accès permet d’atteindre : des utilisateurs nommés, l’authentification à plusieurs facteurs (MFA) sur chaque chemin d’accès, un serveur de rebond avec journalisation des sessions, la séparation du côté du fournisseur, la correction des logiciels fournis et les sous-traitants. Dans l’UE, NIS2 impose aux opérateurs de segment sol qui entrent dans son champ d’application de gérer ce risque lié aux fournisseurs.

Ce guide explique pourquoi le segment sol est la cible, les six volets que vérifient les opérateurs, d’où viennent les exigences, si la taille de l’opérateur compte, ce qu’il en est de l’EU Space Act, ce qui suit le questionnaire et ce qu’il faut mettre en place d’abord. Il se termine par une liste de contrôle.

Volet	Ce que l’opérateur vérifie	Preuves qui y répondent
Identité et accès	Utilisateurs nommés, MFA sur chaque chemin, aucun compte partagé	Liste des accès rapprochée des données RH, couverture MFA
Chemin de connexion	Serveur de rebond, journalisation des sessions, accès limité dans le temps, terminaux gérés	Architecture d’accès, échantillon de journaux de session
Séparation de votre côté	Ce que le poste de l’ingénieur peut atteindre par ailleurs	Schéma réseau, registres de gestion des terminaux
Logiciel que vous fournissez	Développement sécurisé, SBOM, délais de correctif et de notification	SBOM, historique des correctifs, conditions de notification
Vos sous-traitants	Qui hérite de votre accès, et si l’opérateur le sait	Registre des sous-traitants, communiqué à l’opérateur
Personnel et juridiction	Contrôle des antécédents du personnel à privilèges, localisation du personnel	Dossiers de contrôle, liste de localisation du personnel

Pourquoi le segment sol est-il la cible des attaques ?

Attaquer un satellite en orbite est difficile. Attaquer le réseau qui le commande est une intrusion ordinaire contre une infrastructure ordinaire, et le chemin le plus court passe souvent par un fournisseur qui dispose d’un accès à distance et de contrôles plus faibles que ceux de l’opérateur.

Le Space Threat Landscape de l’ENISA (mars 2025) range les centres de contrôle et les stations de contrôle au sol parmi les actifs du segment sol. L’un de ses scénarios commence par de l’ingénierie sociale et atteint un satellite par le logiciel de contrôle de mission relié à la station sol de télémesure, de poursuite et de télécommande, avec l’aide d’une segmentation réseau faible et d’un protocole de sécurité de liaison vulnérable. Le rapport du CCSDS sur les menaces contre les missions spatiales cite les partenaires commerciaux de confiance et le personnel de maintenance et des systèmes malhonnête parmi les sources de menaces internes. Un fournisseur disposant d’un accès à distance est les deux à la fois.

Que vérifie un opérateur de satellites avant d’ouvrir l’accès à un fournisseur ?

Le questionnaire varie. Les préoccupations de fond, non. Dans les examens que nous voyons, elles se répartissent en six volets : c’est une pratique, pas une liste juridique.

Identité et accès

Qui a accès, nommément, et pas une équipe. La MFA sur chaque chemin d’entrée, y compris celui qu’utilisent vos ingénieurs à deux heures du matin. Aucun compte partagé, et aucun identifiant partagé dans un dossier de gestionnaire de mots de passe intitulé « ops ». Les accès à privilèges séparés des accès courants. Des registres des arrivées et des départs, datés, car la question derrière la question est de savoir si une personne partie le trimestre dernier peut encore atteindre leurs systèmes.

Comment la connexion est établie

Un serveur de rebond (jump host) ou un bastion plutôt qu’un accès direct. La journalisation des sessions et, pour les travaux à privilèges, parfois leur enregistrement. Un accès demandé et limité dans le temps plutôt qu’ouvert en permanence. Des ingénieurs qui se connectent depuis des terminaux gérés, et non depuis le premier ordinateur portable venu.

La séparation de votre côté

L’environnement que vous utilisez pour atteindre leurs systèmes est-il séparé de votre réseau d’entreprise, de votre environnement de développement et de la navigation web ? Un opérateur qui accorde l’accès à votre poste de travail a, de fait, accordé l’accès à tout ce que ce poste peut atteindre.

Le logiciel que vous fournissez

Des pratiques de développement sécurisé, la gestion des dépendances, une nomenclature logicielle (SBOM), la rapidité de vos correctifs et la manière dont vous informez l’opérateur d’une vulnérabilité dans un produit qu’il exploite déjà. Parmi ses recommandations, l’ENISA cite la correction et le durcissement réguliers des systèmes spatiaux : attendez-vous à des questions sur votre délai de correctif. C’est de plus en plus la section la plus longue.

Vos propres sous-traitants

Quels sous-traitants interviennent sur le travail, s’ils héritent de votre accès, et si l’opérateur en est informé. Des sous-traitants non déclarés qui ont hérité d’un accès sont un constat récurrent, et un moyen rapide de perdre un contrat.

Personnel et juridiction

Le contrôle des antécédents du personnel disposant d’accès à privilèges, et le lieu où ce personnel se trouve. Pour les activités spatiales, cela soulève aussi des questions de contrôle des exportations et de double usage, qui n’ont rien à voir avec la cybersécurité mais arrivent dans le même document.

Si vous avez reçu un tel questionnaire et que la moitié des questions est restée sans réponse, la méthode se trouve dans comment répondre à un questionnaire de sécurité.

D’où viennent les exigences de sécurité du segment sol ?

De NIS2, et des contrats situés en amont de l’opérateur.

Annexe I de NIS2 : l’espace

L’annexe I range l’espace parmi les secteurs hautement critiques et vise les exploitants d’infrastructures terrestres, détenues, gérées et exploitées par des États membres ou par des parties privées, qui soutiennent la fourniture de services spatiaux, à l’exclusion des fournisseurs de réseaux de communications électroniques publics. Le considérant 37 précise que les infrastructures détenues, gérées ou exploitées par l’Union ou pour son compte dans le cadre de son programme spatial ne sont pas couvertes.

Le segment sol, pas l’orbite : un opérateur de téléport, de réseau de stations sol ou de contrôle de mission est concerné. Une entreprise qui fabrique des roues de réaction ne l’est pas, du moins pas au titre de cette entrée.

Article 21 : comment l’obligation de l’opérateur devient votre clause

Quatre points de l’article 21 transforment l’obligation de l’opérateur en clauses de votre contrat :

• Article 21, paragraphe 2, point d) : la sécurité de la chaîne d’approvisionnement, y compris les aspects liés à la sécurité des relations entre chaque entité et ses fournisseurs directs ou prestataires de services.
• Article 21, paragraphe 3 : l’opérateur doit tenir compte des vulnérabilités propres à chaque fournisseur direct et de la qualité globale de ses produits et de ses pratiques en matière de cybersécurité, y compris ses procédures de développement sécurisé.
• Article 21, paragraphe 2, point i) : la sécurité des ressources humaines, les politiques de contrôle d’accès et la gestion des actifs.
• Article 21, paragraphe 2, point j) : l’authentification à plusieurs facteurs ou l’authentification continue et des communications sécurisées, le cas échéant.

Le considérant 89 cite la segmentation du réseau et la gestion des identités et des accès parmi les pratiques de base en matière de cyberhygiène, et le considérant 85 encourage les entités à intégrer des mesures de sécurité dans les contrats avec leurs fournisseurs. NIS2 ne parle jamais de « serveur de rebond ». En pratique, un serveur de rebond avec MFA et journalisation est la manière dont les opérateurs y répondent pour l’accès à distance des fournisseurs. Les dix mesures sont présentées dans NIS2 article 21 : les 10 mesures, le point de vue de l’opérateur dans l’évaluation des risques de la chaîne d’approvisionnement NIS2.

Pas de règles d’exécution détaillées pour l’espace

Le règlement d’exécution (UE) 2024/2690 fixe des exigences détaillées au titre de l’article 21 uniquement pour les fournisseurs de services DNS, les registres de noms de domaine de premier niveau, les fournisseurs de services d’informatique en nuage, de centres de données et de réseaux de diffusion de contenu (CDN), les fournisseurs de services gérés et de services de sécurité gérés, les places de marché en ligne, les moteurs de recherche en ligne, les plateformes de services de réseaux sociaux et les prestataires de services de confiance. Les opérateurs de segment sol ne figurent pas sur la liste : le détail de leurs obligations vient du droit national, de leur analyse de risques et de leurs contrats. L’annexe du règlement, avec ses sections sur la sécurité de la chaîne d’approvisionnement et le contrôle d’accès, reste une référence utile.

Une exception peut vous concerner. Si vous installez, gérez, exploitez ou maintenez les systèmes d’un opérateur, sur site ou à distance, vous pouvez être un fournisseur de services gérés au sens de l’article 6, point 39, de NIS2. Un MSP de taille moyenne ou plus grande entre dans le champ d’application à part entière, et le règlement 2024/2690 s’applique directement à lui.

Les contrats en amont

Les exigences des agences et des maîtres d’œuvre arrivent sous forme de clauses contractuelles, pas de loi. Il n’y a pas de délai de transposition à attendre ni de critère de proportionnalité à invoquer. Les clauses que vous rencontrerez probablement sont décortiquées dans l’annexe de sécurité, clause par clause.

La taille de l’opérateur change-t-elle ce que l’on demande au fournisseur ?

Moins qu’on ne le pense. Au titre de NIS2, un opérateur de segment sol plus grand qu’une moyenne entreprise est une entité essentielle, un opérateur de taille moyenne une entité importante, et tous deux prennent les mêmes mesures de l’article 21. La supervision diffère : les entités essentielles font l’objet d’une supervision proactive, y compris des audits réguliers, les entités importantes d’une supervision a posteriori. Les petits opérateurs et les micro-opérateurs sont en général hors du champ de NIS2, sauf si l’un des cas prévus à l’article 2 indépendamment de la taille s’applique.

En pratique, l’accès que vous détiendriez pèse davantage sur l’examen que la taille de l’opérateur. Un petit opérateur au service d’une agence répercute de toute façon les exigences de celle-ci. La taille se voit dans le suivi : d’après notre expérience, les grands opérateurs demandent des preuves plus tôt et inscrivent des droits d’audit dans le contrat. La façon dont les régimes se superposent est expliquée dans fournisseurs du spatial : les quatre régimes.

Et l’EU Space Act ?

La Commission a proposé l’EU Space Act (législation spatiale de l’UE), un règlement, le 25 juin 2025 sous la référence COM(2025) 335. Il contient des exigences de cybersécurité pour les opérateurs spatiaux, dont une gestion des risques de la chaîne d’approvisionnement avec des clauses de sécurité dans les contrats fournisseurs (article 92). L’article 75, paragraphe 1, en ferait un acte sectoriel pour les opérateurs spatiaux qui sont des entités essentielles ou importantes au sens de NIS2, uniquement en ce qui concerne les mesures de gestion des risques de l’article 21. Les obligations de notification d’incidents de NIS2 continueraient de s’appliquer (article 93, paragraphe 4). Tel que proposé, il s’appliquerait à partir du 1er janvier 2030.

Ce n’est encore qu’une proposition. En septembre 2026, la commission compétente au fond du Parlement européen dispose d’un projet de rapport du 3 mars 2026 mais ne l’a pas voté, et le rapport sur l’état d’avancement des travaux du Conseil du 8 mai 2026 indique que plusieurs questions restent ouvertes, notamment le champ d’application et la gouvernance. Les trilogues n’ont pas commencé.

Pour un fournisseur, ce n’est pas l’EU Space Act qui créera la première obligation. Ce sera le contrat client, et c’est déjà le cas. Construisez pour le contrat, et le règlement arrivera comme une formalité plutôt que comme un projet.

Que se passe-t-il après le questionnaire de sécurité ?

Pour un accès permanent à des systèmes opérationnels, le questionnaire est le filtre, pas l’aboutissement. Les opérateurs poursuivent avec des demandes de preuves, un entretien technique, parfois une visite sur site, et un droit d’audit. C’est là que les réponses déclaratives se heurtent à la réalité. Les échecs courants n’ont rien d’exotique :

• une liste des accès qui ne correspond pas aux personnes qui détiennent réellement des comptes ;
• la MFA sur le fournisseur d’identité de l’entreprise, mais contournée sur un ancien serveur de rebond ;
• un processus de départ qui révoque la messagerie mais pas le certificat VPN ;
• un sous-traitant que personne n’a mentionné.

Ce sont des défauts de rapprochement, pas de capacité, et un rapprochement se corrige en quelques semaines.

Que doit mettre en place un fournisseur en premier ?

Pour un fournisseur de trente à cent personnes, cette séquence permet de passer la plupart des examens :

1. Une liste exacte de qui a accès à quoi, rapprochée de la paie et des contrats.
2. La MFA sur chaque chemin vers les environnements clients, sans contournement hérité.
3. Un environnement séparé pour le travail client, même s’il se limite à quelques terminaux gérés et un serveur de rebond.
4. Une gestion des arrivées et des départs datée et prouvée, le contrôle le plus souvent testé et le plus souvent en échec.
5. La journalisation des sessions à privilèges, conservée assez longtemps pour répondre à une question sur le trimestre dernier.
6. Un engagement de notification que vous pouvez tenir, avec un contact nommé et un délai annoncé. Un opérateur concerné doit adresser une alerte précoce à son CSIRT ou à son autorité dans les 24 heures après avoir pris connaissance d’un incident important (article 23), et c’est souvent par vous qu’il l’apprend.
7. Une liste écrite des sous-traitants disposant d’un accès, communiquée plutôt que découverte.

Rien de tout cela ne demande une équipe de sécurité. Tout cela demande un responsable. Un registre par environnement client permet de toujours pouvoir répondre :

REGISTRE D'ACCÈS AU SEGMENT SOL (un par environnement client)
Client / environnement :     ...
Utilisateurs nommés :        nom, rôle, employeur, date du contrôle
Chemin d'accès :             serveur de rebond / VPN / portail fournisseur, d'où
Authentification :           méthode MFA par chemin ; comptes partagés : aucun
Comptes à privilèges :       lesquels, approuvés par, dernière revue
Journaux de session :        lieu de stockage, conservation, qui les examine
Séparation de notre côté :   terminaux gérés, réseau admin, pas de web
Logiciel fourni :            versions déployées, SBOM, délai de correctif
Conditions de notification : contact, canal, délai selon le contrat
Sous-traitants avec accès :  nom, périmètre, date de déclaration au client
Déclencheur de révocation :  départ ou fin de contrat, révoqué sous ...
Dernier rapprochement :      date, comptes trouvés, comptes supprimés

Que laissent les règles sans réponse ?

L’accès est accordé à une identité et révoqué dans un tableur. L’octroi est précis : une personne est nommée, un compte créé, un certificat émis. La révocation repose sur la mémoire et la bonne volonté. Quelqu’un part, un projet se termine, un sous-traitant est remercié, et le compte subsiste parce qu’aucun processus ne relie l’événement métier à l’événement technique.

NIS2 demande à l’opérateur de gérer le risque lié aux fournisseurs et, le cas échéant, d’utiliser la MFA. Elle ne dit rien de la manière dont le fournisseur sait, un jour donné, qui détient encore un accès. Les contrôles de l’opérateur sont généralement solides ; la liste des accès du fournisseur est généralement fausse, et personne ne s’en aperçoit avant un audit ou une intrusion. Un questionnaire ne peut pas le détecter : il demande si vous avez un processus de départ, et vous répondez oui en toute sincérité.

Pour combler cette lacune, il faut générer la liste des accès à partir des systèmes qui les accordent (fournisseur d’identité, VPN, serveur de rebond, autorité de certification), la rapprocher en continu des données RH et des dates de fin de contrat, et traiter les comptes orphelins comme des constats confiés à un responsable, plutôt que de les découvrir une fois par an. C’est ainsi que fonctionne la plateforme CloudSoul : collecte automatisée des preuves, avec une expertise humaine dans la boucle pour les exceptions. Un audit de sécurité mesure ce rapprochement avant qu’un opérateur ne le fasse. La vue sectorielle se trouve sur la page espace.

Liste de contrôle : accès des fournisseurs au segment sol

• Nommez chaque personne ayant accès à chaque environnement client, en rapprochement avec les données RH.
• Imposez la MFA sur chaque chemin d’accès, y compris les serveurs de rebond et les portails fournisseurs.
• Faites passer les accès par un serveur de rebond, depuis des terminaux gérés et séparés, avec journalisation des sessions à privilèges.
• Reliez les départs et les fins de contrat à la révocation, avec la date enregistrée.
• Tenez une SBOM et un délai de correctif pour le logiciel que vous fournissez, et convenez des conditions de notification avec chaque opérateur.
• Déclarez chaque sous-traitant qui détient ou hérite d’un accès.

Sources

• Directive (UE) 2022/2555 (NIS2), articles 2, 3, 6, 21 et 23, annexe I et considérants 37, 85 et 89, EUR-Lex.
• Règlement d’exécution (UE) 2024/2690 de la Commission, article 1 et annexe, EUR-Lex.
• Commission européenne, proposition de règlement relatif à la sécurité, à la résilience et à la durabilité des activités spatiales dans l’Union (EU Space Act), COM(2025) 335, articles 75, 92, 93 et 119, EUR-Lex ; Service de recherche du Parlement européen, note d’information sur l’EU Space Act.
• Parlement européen, Observatoire législatif, procédure 2025/0335(COD) ; Conseil de l’UE, rapport sur l’état d’avancement des travaux 8861/26 du 8 mai 2026, registre du Conseil.
• ENISA, Space Threat Landscape 2025, 26 mars 2025, ENISA.
• CCSDS 350.1-G-3, Security Threats Against Space Missions, rapport d’information (Informational Report), février 2022, CCSDS.

Questions fréquentes