Déploiements air-gapped pour les logiciels de défense : défis et bonnes pratiques

Un air gap est l'isolement physique d'un système informatique ou d'un réseau par rapport aux réseaux non sécurisés, y compris l'internet public. Les systèmes air-gapped ne disposent d'aucune connexion filaire ou sans fil vers des réseaux externes ; le transfert de données nécessite le déplacement physique de supports de stockage approuvés ou de dispositifs de transfert de données unidirectionnels. Les air gaps constituent le contrôle de sécurité le plus fondamental pour les systèmes d'information classifiés les plus sensibles : aucun niveau de sécurité logicielle ne peut compenser une connexion réseau physique lorsque le modèle de menace inclut des adversaires étatiques dotés de capacités offensives cyber avancées.

Le déploiement et la maintenance de logiciels modernes sur des systèmes air-gapped nécessitent une approche d'ingénierie fondamentalement différente de celle des déploiements connectés à internet. Les fonctionnalités de commodité sur lesquelles s'appuient les équipes de développement — gestionnaires de paquets automatisés qui récupèrent des dépendances depuis des dépôts publics, images de conteneurs tirées de Docker Hub, pipelines CI/CD qui appellent des services SaaS externes — échouent toutes dans les environnements air-gapped. Le logiciel doit fonctionner sans aucune de ces connexions, et le processus de développement et d'exploitation doit être conçu pour le prendre en charge dès le début.

Ce que signifie l'air gap et où il est requis

Les air gaps sont requis partout où la classification ou la sensibilité des données traitées ou des systèmes contrôlés justifie un isolement physique du réseau. Dans les contextes militaires :

Les Sensitive Compartmented Information Facilities (SCIF) sont des salles ou des bâtiments physiquement sécurisés où des informations classifiées au-delà de SECRET — notamment les SCI (Sensitive Compartmented Information) — peuvent être traitées et discutées. Les systèmes informatiques au sein d'un SCIF traitant des données de niveau SCI doivent être isolés des réseaux non accrédités au même niveau de classification.

Les réseaux opérationnels classifiés — SECRET ou au-dessus — sont isolés des réseaux non classifiés. Le transfert de données entre niveaux de classification nécessite une Cross-Domain Solution (CDS) : un système matériel-logiciel qui applique des règles de transfert d'informations entre les deux niveaux de réseau.

Les contrôleurs de systèmes d'armes et systèmes embarqués — ordinateurs de conduite de tir, systèmes de navigation, contrôleurs radar et capteurs — sont isolés des réseaux opérationnels dans le cadre de leur architecture de sécurité. Les mises à jour logicielles de ces systèmes sont livrées via l'interface de maintenance de la plateforme, en utilisant des supports approuvés.

Déploiement logiciel sans internet : registres d'artefacts et miroirs de paquets

Dans un environnement air-gapped, chaque dépendance logicielle dont une application a besoin doit être présente dans l'environnement avant le déploiement. Rien ne peut être extrait d'internet au moment du déploiement. Cela nécessite de construire un écosystème d'artefacts interne qui reflète les ressources externes sur lesquelles l'application s'appuierait autrement.

Harbor est le registre de conteneurs open source diplômé par la CNCF, et c'est le choix standard pour les registres d'images de conteneurs internes dans les environnements de défense air-gapped. Harbor fournit : le stockage et la réplication d'images, l'analyse de vulnérabilités des images (via Trivy), la confiance dans le contenu (vérification de signature numérique des images) et des contrôles d'accès basés sur les rôles. Le remplissage du registre Harbor nécessite un processus d'importation d'images de conteneurs pré-approuvées et pré-scannées depuis l'extérieur de l'air gap via des supports approuvés.

Les miroirs de paquets hors ligne répliquent les dépôts de paquets publics pour une utilisation à l'intérieur de l'air gap. Pour Python, un miroir PyPI interne (utilisant des outils comme bandersnatch ou devpi) sert les requêtes pip depuis l'intérieur de l'environnement. Pour npm, une instance Nexus ou Artifactory (ou l'open source Verdaccio) sert les requêtes npm. Le miroir de paquets doit être alimenté et maintenu à jour par le processus de transfert de supports approuvés.

Le processus de gestion des dépendances doit être explicite : avant de commencer le développement d'une fonctionnalité destinée à être déployée dans un environnement air-gapped, le développeur doit identifier explicitement toutes les dépendances (y compris les dépendances transitives) et vérifier qu'elles sont présentes dans le miroir interne. L'ajout d'une nouvelle dépendance nécessite une demande de transfert de support et un processus d'approbation.

Gestion des correctifs : bundles testés et contrôle des modifications

La gestion des correctifs dans les environnements air-gapped ne peut pas utiliser des systèmes automatisés qui récupèrent des mises à jour depuis les services cloud des fournisseurs. Elle nécessite un processus défini et documenté pour amener les correctifs de l'extérieur de l'air gap vers l'intérieur, les tester dans un environnement représentatif et les appliquer de manière contrôlée.

La préparation du bundle de correctifs commence à l'extérieur de l'air gap : l'équipe de gestion des correctifs identifie les correctifs requis, les télécharge depuis les sources des fournisseurs, vérifie leur authenticité (somme de contrôle et vérification de signature numérique) et les conditionne pour le transfert.

Le transfert via des supports amovibles approuvés est le mécanisme standard pour déplacer les correctifs à travers l'air gap. Les procédures typiques comprennent : l'utilisation uniquement de supports gérés par l'organisation, le scan antivirus des supports des deux côtés de l'air gap, l'utilisation de supports à écriture unique (disques optiques) pour des pistes d'audit irréversibles, la documentation de chaque transfert.

Les tests par étapes sont non négociables pour les systèmes opérationnels air-gapped : les correctifs doivent être testés dans un environnement de staging qui reflète la configuration de production avant d'être appliqués en production. Un correctif qui déstabilise un système de production air-gapped ne peut pas être annulé en récupérant simplement la version précédente depuis une source internet.

Rotation des secrets dans les environnements air-gapped

Les secrets — certificats TLS, identifiants de base de données, clés API — expirent et doivent être renouvelés. Dans les environnements air-gapped, aucun de ces mécanismes automatisés ne fonctionne car ils reposent sur la connectivité réseau vers les autorités de certification et les API de gestion des secrets qui ne sont pas accessibles depuis l'intérieur de l'air gap.

Les modules de sécurité matériels (HSM) fournissent la racine de confiance pour les opérations cryptographiques dans les environnements classifiés air-gapped. Un HSM (tel qu'un appareil Thales Luna ou nCipher nShield) stocke les clés privées dans un matériel résistant aux manipulations, effectue des opérations cryptographiques sans exposer le matériel clé et fournit une sécurité validée FIPS 140-2 Niveau 3 ou Niveau 4.

Les procédures de coffre-fort hors ligne et de cérémonie de clés définissent comment les secrets sont renouvelés sans outillage automatisé. Une cérémonie de clés est une procédure formelle et documentée — avec plusieurs membres du personnel autorisés présents — pour la génération, le chargement ou la rotation de clés cryptographiques. Pour la rotation des certificats TLS, la cérémonie implique la génération d'une nouvelle demande de certificat, sa signature avec la clé CA hors ligne (stockée dans le HSM) et la distribution du nouveau certificat aux systèmes consommateurs via des supports approuvés.

CI/CD pour les environnements air-gapped

Les pipelines d'intégration et de déploiement continus peuvent fonctionner dans des environnements air-gapped avec les bons choix d'outillage. L'infrastructure du pipeline doit être entièrement autonome au sein de l'air gap, sans dépendances aux services cloud.

GitLab Community Edition déployé sur site est la plateforme git et CI/CD auto-hébergée standard pour les environnements air-gapped. GitLab CE fournit : l'hébergement de dépôts git, les flux de travail de merge request, l'exécution de pipelines CI/CD (en utilisant des GitLab Runners déployés dans le même environnement), le registre de paquets et le registre de conteneurs. Aucune connectivité cloud n'est requise.

Les GitLab Runners doivent être configurés avec accès aux miroirs de paquets internes (PyPI interne, npm, Maven) plutôt qu'aux dépôts de paquets externes. Les étapes du pipeline qui appelleraient normalement des services externes doivent être reconfigurées pour utiliser des équivalents internes ou désactivées.