Cybersécurité, logiciel de vol et résilience opérationnelle
Protéger les fonctions numériques d’une base isolée : architecture de confiance, authentification, mises à jour, logiciels critiques, journaux, segmentation et récupération après compromission.
Objectifs de maîtrise
- relier les principes à une décision d’architecture ou d’opération
- refaire les calculs simples et vérifier unités et hypothèses
- identifier modes dégradés, interfaces et incertitudes
- produire une procédure ou un plan vérifiable
1. Sur Mars, une cyberattaque peut devenir une panne physique
Le logiciel commande énergie, air, eau, communications, robots et inventaires. Une action non autorisée ou une erreur logicielle peut donc avoir des effets matériels. La cybersécurité doit être intégrée à la sûreté de fonctionnement : protéger les données ne suffit pas si une commande falsifiée peut arrêter une pompe.
2. Réduire la surface d’attaque par l’architecture
Les systèmes critiques ne doivent pas tous partager le même réseau plat. Segmenter habitat, atelier, science, visiteurs, robots et administration limite la propagation d’une compromission. Les passerelles doivent autoriser uniquement les flux nécessaires et enregistrer les échanges sensibles.
3. Identité, authentification et moindre privilège
Un compte utilisateur ne doit pas posséder plus de droits que sa mission l’exige. Les opérations critiques peuvent demander authentification renforcée, double validation ou séparation des rôles. Le système doit aussi continuer à fonctionner lorsque la connexion avec la Terre est indisponible.
4. Mises à jour et chaîne de confiance
Un correctif logiciel utile peut devenir un risque s’il est corrompu ou incompatible. Les paquets doivent être signés, vérifiés, testés sur un environnement de référence puis déployés progressivement. Une image système connue et des versions antérieures doivent permettre le retour arrière.
5. Journalisation et détection sans noyer l’équipage
Les journaux doivent enregistrer commandes critiques, changements de configuration, échecs d’authentification et anomalies de communication. Trop d’alertes rend cependant l’outil inutile. La détection doit donc hiérarchiser les événements et conserver des données suffisantes pour reconstruire un incident.
6. Sauvegarde, mode sûr et restauration
Une base doit pouvoir repartir depuis des configurations propres hors ligne. Les sauvegardes doivent être séparées du système qu’elles protègent, testées et documentées. Certains automatismes critiques peuvent posséder un mode local minimal qui maintient pression, température ou circulation même si le réseau supérieur est indisponible.
7. Construire une frontière de confiance entre fonctions vitales et fonctions de confort
Tous les réseaux d'une base n'ont pas la même criticité. Un poste de divertissement, un serveur scientifique et le contrôleur d'une boucle d'oxygène ne devraient pas disposer des mêmes chemins ni des mêmes privilèges. La segmentation réduit le nombre de systèmes qu'un défaut logiciel ou une compromission peut atteindre. Mais elle doit rester compatible avec les opérations de secours : isoler un réseau ne doit pas empêcher un équipage autorisé d'accéder localement aux fonctions vitales. L'architecture doit donc définir zones de confiance, passerelles contrôlées, services indispensables, accès de maintenance et modes hors réseau. La cybersécurité devient une propriété de l'architecture fonctionnelle, pas une couche ajoutée après la mise en service.
8. Mettre à jour sans transformer un correctif en nouvelle panne
Une mise à jour logicielle peut corriger une vulnérabilité et introduire simultanément un défaut de compatibilité. Sur Mars, l'équipe ne peut pas compter sur un remplacement rapide du matériel ni sur l'intervention immédiate du fournisseur. Les correctifs doivent donc être authentifiés, testés sur une configuration représentative, installés par étapes et accompagnés d'un mécanisme de retour arrière. Les systèmes critiques peuvent maintenir une image logicielle connue comme sûre, séparée de la version courante. Les journaux doivent permettre de prouver quelle version tournait au moment d'un incident. Le patch management devient ainsi un processus de configuration et de sûreté autant qu'une activité de sécurité informatique.
9. Réponse à incident : préserver la mission avant de chercher le coupable
Lorsqu'un comportement suspect apparaît, la priorité opérationnelle est de maintenir les fonctions vitales et empêcher la propagation. L'équipe doit pouvoir isoler une machine, basculer vers un mode dégradé, préserver les journaux, vérifier l'intégrité des commandes puis reconstruire le service depuis une base de confiance. Une analyse forensique détaillée peut venir ensuite. Dans un système distant, la réponse à incident doit être répétée en simulation : qui décide l'isolement, quelles fonctions peuvent être coupées, quels éléments doivent rester disponibles et comment confirmer que la restauration est saine ? La procédure doit fonctionner même avec une liaison Terre indisponible.
10. Exemple calculé : budget de correctifs
Supposons 120 équipements logiciels. Une mise à jour demande 25 min de préparation et vérification par équipement. En séquence, cela représente 3 000 min = 50 h de travail. Si l’on automatise 80 % des vérifications et que l’opérateur ne consacre plus que 5 min par équipement, la charge tombe à 10 h. L’automatisation doit toutefois produire des preuves et des journaux, pas simplement masquer le travail.
Approfondissement : patcher un système vital sans fabriquer une panne commune
Un correctif logiciel peut réduire une vulnérabilité et créer simultanément un risque opérationnel. Sur Mars, la stratégie de mise à jour doit donc séparer les fonctions vitales, contrôler l'origine des paquets et prévoir un retour vers la dernière configuration connue comme stable. Les référentiels NASA de logiciel imposent des pratiques de planification, de sécurité et de contrôle de configuration précisément parce qu'un changement de code est aussi un changement du système physique qu'il commande. NASA NPR 7150.2D
Exemple calculé. Un habitat comporte 40 contrôleurs identiques. Mettre à jour les 40 simultanément expose potentiellement 100 % de cette famille à une régression commune. Une stratégie en quatre vagues de 10 contrôleurs ne change pas la probabilité intrinsèque qu'un paquet contienne un défaut, mais elle limite le rayon d'exposition initial à 10 ÷ 40 = 25 %. Si la première vague fonctionne pendant une période d'observation définie, la suivante peut commencer. Pour une fonction réellement vitale, on ferait encore mieux : versions redondantes indépendantes, banc de test représentatif et capacité de rollback vérifiée avant le déploiement.
Le chiffre de 25 % n'est pas une recommandation universelle. Il illustre la différence entre risque individuel et risque de cause commune. Une mise à jour parfaitement authentifiée peut être dangereuse si elle installe le même défaut partout. La résilience cyber d'une colonie dépend donc autant de la segmentation, de la diversité et de la restauration que du chiffrement ou des mots de passe. NASA — Spacecraft Software Engineering
11. Exercice progressif
Dessinez un réseau comportant ECLSS, production électrique, laboratoire, robots et réseau personnel. Indiquez quelles communications sont nécessaires et lesquelles doivent être bloquées par défaut.
Mini-projet
Écrire le plan de réponse à compromission d’un serveur de maintenance : détection, isolement, continuité des fonctions vitales, collecte de preuves, restauration, validation et retour en service.