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.
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.