Apache Kafka pour la défense : architecture de messagerie sécurisée en temps réel

Les systèmes de défense génèrent des données à un rythme et un volume que les architectures conventionnelles de type requête-réponse ne peuvent pas absorber. Un seul UAS transmet des dizaines de paramètres de télémétrie par seconde. Un nœud C2 au niveau brigade traite des centaines de rapports de position et d'événements de statut par minute. Une cellule de fusion ISR ingère simultanément des flux provenant du radar, du renseignement sur les signaux et des rapports humains, tous nécessitant une corrélation en moins d'une seconde. Lorsque ces flux doivent circuler de manière fiable au sein d'une infrastructure résiliente, auditée et classifiée, Apache Kafka est devenu le choix architectural de référence.

Cet article explique comment déployer Kafka spécifiquement pour les cas d'usage de défense : stratégie de partitionnement pour les environnements multi-classification, configuration complète du chiffrement, déploiement air-gap avec le mode KRaft, et les compromis entre clusters auto-hébergés et alternatives managées telles qu'Azure Event Hubs pour les charges de travail GovCloud.

Pourquoi le streaming d'événements s'adapte aux architectures de défense

Les flux de travail de défense sont intrinsèquement pilotés par les événements. La télémétrie des capteurs n'arrive pas en lots ordonnés — c'est un flux continu de mesures qui doit être traité au moment même de son arrivée pour être utile opérationnellement. Les événements C2 — mouvement des unités, changements de mission, mises à jour de statut — sont des messages discrets dont plusieurs systèmes consommateurs ont besoin simultanément : le tableau de situation commun, la logistique, la coordination des tirs et les comptes-rendus d'opération ont tous besoin du même événement sous-jacent sans que le producteur sache qui écoute.

Le modèle publish-subscribe de Kafka correspond parfaitement à cette exigence. Un producteur écrit une lecture de capteur ou un événement C2 dans un topic. Un nombre quelconque de groupes de consommateurs — chacun représentant une application en aval différente — rejoue l'événement indépendamment à son propre rythme. Ce découplage signifie qu'ajouter une nouvelle charge de travail analytique ne nécessite pas de modifications au système producteur, ce qui est essentiel dans les environnements de défense où le contrôle des changements logiciels est lent et les cycles d'approbation sont longs.

Au-delà du découplage, le log durable de Kafka fournit une piste d'audit en ajout uniquement qui satisfait les exigences forensiques que portent la plupart des systèmes de défense. Chaque message est conservé sur disque pendant une période configurable. En cas d'incident, les opérateurs peuvent rejouer la séquence exacte des événements qui y ont conduit sans dépendre de la journalisation au niveau applicatif.

Architecture Kafka de base pour les environnements classifiés

Topologie des brokers

Un cluster Kafka classifié de niveau production nécessite au minimum trois nœuds de brokers pour supporter un facteur de réplication de trois et un paramètre min.insync.replicas de deux. Cette configuration tolère la perte d'un broker unique sans perte de données ni erreurs de producteur. Pour les déploiements classifiés haute disponibilité, cinq brokers — répartis sur au moins trois racks physiques ou zones de disponibilité — offrent une meilleure tolérance aux pannes avec de la marge pour les mises à jour glissantes.

Depuis Kafka 3.3, le mode KRaft remplace ZooKeeper pour la gestion des métadonnées du cluster. Pour les déploiements de défense air-gap, ce n'est pas optionnel — c'est le défaut correct. Un ensemble ZooKeeper séparé ajoute trois nœuds supplémentaires, un domaine de défaillance distinct et une surface d'attaque additionnelle. KRaft consolide la gestion des métadonnées dans les brokers Kafka eux-mêmes en utilisant un quorum basé sur Raft de nœuds contrôleurs, généralement co-hébergés avec les brokers dans les petits clusters ou séparés dans les grands.

Partitionnement des topics par niveau de classification

La décision architecturale la plus importante dans un déploiement Kafka multi-classification est la façon d'imposer l'isolation entre les données de différents niveaux de sensibilité. Il existe deux approches.

La première approche utilise un cluster unique avec isolation ACL au niveau des topics. Les topics sont nommés par classification : ts.sensor.uav-telemetry pour la télémétrie très secrète, s.c2.position-reports pour les données C2 de niveau secret, c.logistics.supply-events pour la logistique confidentielle. Chaque compte de service se voit accorder des droits de production et de consommation uniquement pour les topics correspondant à son niveau d'habilitation. Cette approche réduit la complexité opérationnelle mais nécessite une grande confiance dans l'application des ACL de Kafka et une segmentation réseau rigoureuse pour s'assurer que les processus des brokers eux-mêmes ne constituent pas un vecteur de déplacement latéral.

La deuxième approche — préférée lors du traitement de données au-dessus du niveau SECRET sur la même infrastructure physique — utilise des clusters de brokers séparés par domaine de classification, reliés via une solution inter-domaines (CDS) pour les rares cas où des données déclassifiées doivent franchir une frontière. Cela élimine entièrement le risque lié aux brokers partagés au prix d'une surcharge opérationnelle accrue. Pour un traitement plus approfondi des architectures inter-domaines, voir l'article sur les solutions inter-domaines pour la défense.

Rétention et nombre de partitions

Définissez le nombre de partitions en fonction du débit attendu, pas par commodité. Un topic traitant 10 000 messages par seconde depuis un réseau de capteurs doit avoir suffisamment de partitions pour que chaque consommateur d'un groupe puisse traiter ses partitions assignées sans retard. Une règle empirique : le nombre de partitions doit être au moins égal au nombre de consommateurs dans le groupe consommateur, et idéalement deux à trois fois ce nombre pour permettre le rééquilibrage des groupes sans introduire de points chauds.

Les décisions de politique de rétention doivent être documentées et justifiables. La télémétrie des capteurs analysée en quasi-temps réel n'a généralement besoin que de 24 à 72 heures de rétention avant de pouvoir être déchargée vers le stockage froid ou supprimée. Les journaux d'événements C2 requis pour les comptes-rendus post-opération doivent être conservés 30 à 90 jours dans le niveau chaud, après quoi ils doivent être exportés vers une archive chiffrée et immuable. Ne vous fiez pas à Kafka seul comme magasin d'audit à long terme — c'est un bus d'événements, pas une base de données d'archivage.

Chiffrement en transit : TLS 1.3 et SASL SCRAM

Les environnements classifiés imposent le chiffrement sur chaque chemin de données. Pour Kafka, cela signifie deux contrôles distincts : le chiffrement du transport et l'authentification client.

Configuration TLS 1.3

Configurez chaque écouteur Kafka — y compris la communication inter-brokers — avec TLS 1.3. Dans server.properties :

listeners=SASL_SSL://0.0.0.0:9093
advertised.listeners=SASL_SSL://broker-1.internal:9093
ssl.protocol=TLSv1.3
ssl.enabled.protocols=TLSv1.3
ssl.keystore.location=/etc/kafka/ssl/broker.keystore.jks
ssl.keystore.password=${KEYSTORE_PASSWORD}
ssl.truststore.location=/etc/kafka/ssl/ca.truststore.jks
ssl.truststore.password=${TRUSTSTORE_PASSWORD}
ssl.client.auth=required

Le paramètre ssl.client.auth=required impose le TLS mutuel (mTLS) : chaque client qui se connecte doit présenter un certificat signé par votre autorité de certification interne. Cela garantit que seuls les systèmes connus et provisionnés peuvent se connecter au cluster — une exigence dans toute enclave classifiée. N'utilisez pas requested ni none dans les environnements classifiés.

Les certificats doivent provenir de votre PKI interne. N'utilisez pas de certificats signés par des CA publiques dans un environnement air-gap — et n'autorisez pas les racines de CA publiques dans le truststore du broker, car cela pourrait permettre à un certificat externe compromis de se faire passer pour un client légitime.

SASL SCRAM-SHA-512

En plus du mTLS, utilisez SASL SCRAM-SHA-512 pour l'authentification au niveau utilisateur. Cela lie une identité nommée — comme un compte de service pour une application spécifique — à la connexion TLS, permettant une application fine des ACL basée sur le nom du principal plutôt que sur le seul sujet du certificat.

sasl.enabled.mechanisms=SCRAM-SHA-512
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512
security.inter.broker.protocol=SASL_SSL

Provisionnez les identifiants avec kafka-configs.sh et stockez-les dans votre système de gestion des secrets — HashiCorp Vault, ou un magasin de secrets air-gap équivalent — plutôt que dans des fichiers de configuration. Faites pivoter les identifiants selon un calendrier aligné sur la politique de gestion des clés de votre accréditation, généralement tous les 90 jours ou lors de changements de personnel.

Chiffrement au repos : AES-256 et contrôles au niveau du stockage

Kafka ne chiffre pas nativement les données écrites dans ses segments de log. Le chiffrement au repos est de la responsabilité de la couche de stockage. Pour les déploiements sur serveur physique ou machine virtuelle, utilisez LUKS (Linux Unified Key Setup) avec AES-256 en mode XTS sur les périphériques de blocs hébergeant le log.dirs de Kafka. Pour les déploiements basés sur Kubernetes, provisionnez des ressources StorageClass adossées à des volumes chiffrés — sur Azure Government, utilisez le chiffrement côté serveur avec des clés gérées par le client (SSE-CMK) sur Azure Disk. Les équivalents sur site incluent NetApp avec des disques NSE ou LUKS logiciel pur sur NVMe standard.

Pour les charges de travail où même l'opérateur de stockage ne doit pas pouvoir lire le contenu des messages — particulièrement pertinent pour les programmes d'accès spécial — implémentez le chiffrement au niveau applicatif : le producteur chiffre la charge utile du message avant l'écriture, et seuls les consommateurs autorisés détiennent la clé de déchiffrement. Cette approche est indépendante de la configuration de Kafka et fournit une confidentialité de bout en bout qui persiste même si le stockage des brokers est compromis. La contrepartie est que le filtrage et la compaction côté broker deviennent impossibles sur les charges utiles chiffrées, puisque le broker ne peut pas inspecter le contenu.

Déploiement Kafka air-gap avec le mode KRaft

Un déploiement Kafka air-gap n'a pas de connectivité internet, pas de résolution DNS externe et pas d'accès aux registres de conteneurs publics ni aux miroirs de paquets. Chaque composant doit être disponible localement avant que le cluster puisse démarrer. Cette section couvre les pièges spécifiques qui surprennent les ingénieurs lors du déploiement dans cet environnement.

Mode KRaft et fonctionnement sans ZooKeeper

Utilisez Kafka 3.6 ou version ultérieure avec le mode KRaft activé. Le cluster nécessite un quorum de contrôleurs — généralement trois nœuds contrôleurs, qui peuvent être co-localisés avec les brokers dans les déploiements de trois à cinq nœuds. Chaque nœud se voit attribuer un node.id et une valeur process.roles de controller, broker, ou les deux.

Amorcez le cluster avec kafka-storage.sh format pour générer un UUID de cluster et écrire le log de métadonnées initial. Cette étape doit être exécutée sur chaque nœud avec le même UUID avant de démarrer tout processus broker. Dans un environnement air-gap, générez l'UUID sur un nœud, copiez-le sur les autres, puis exécutez format sur chacun.

CLUSTER_ID=$(kafka-storage.sh random-uuid)
kafka-storage.sh format -t $CLUSTER_ID -c /etc/kafka/server.properties

DNS interne et gestion des certificats

Configurez advertised.listeners pour utiliser des noms d'hôtes pleinement qualifiés résolubles au sein de l'enclave — soit via un serveur DNS interne, soit via /etc/hosts sur chaque hôte qui se connectera au cluster. Utiliser directement des adresses IP dans advertised.listeners fonctionne mais complique la gestion des certificats, car les SAN des certificats doivent lister chaque adresse IP.

Exécutez une CA racine hors ligne en utilisant step-ca ou CFSSL, qui n'ont tous deux aucune dépendance externe à l'exécution. Générez des certificats de broker avec des SAN couvrant le nom d'hôte du broker. Distribuez le certificat racine de la CA dans le truststore de chaque client. Définissez des périodes de validité des certificats alignées sur votre calendrier de re-accréditation, et maintenez un inventaire des certificats afin que les renouvellements n'entraînent pas de pannes inattendues.

Gestion des images de conteneurs et des artefacts

Récupérez toutes les images requises — Kafka, votre pile de supervision et les éventuels plugins Kafka Connect — sur une machine connectée à internet, exportez-les avec docker save, transférez-les vers l'environnement air-gap via une diode de données approuvée ou un processus de support amovible, et chargez-les dans un registre local avec docker load. Épinglez les tags d'image à des digests spécifiques dans vos manifestes de déploiement pour prévenir les changements inattendus si le registre local est mis à jour. Pour plus de détails sur les déploiements Kubernetes air-gap dans les contextes de défense, voir l'article sur les modèles de déploiement air-gap pour la défense.

Azure Event Hubs comme alternative compatible Kafka

Toutes les charges de travail de défense ne nécessitent pas un cluster entièrement déconnecté et auto-géré. Pour les programmes opérant dans les limites GovCloud — Azure Government, IL4 ou IL5 — les niveaux Premium et Dedicated d'Azure Event Hubs fournissent un point de terminaison compatible Kafka qui accepte les producteurs et consommateurs Kafka standard sans modification du code. La surface du protocole est compatible avec les bibliothèques clientes Kafka 1.0 et ultérieures.

Event Hubs dans Azure Government satisfait l'autorisation FedRAMP High et, pour le niveau Dedicated, prend en charge les clés gérées par le client via Azure Key Vault Managed HSM, fournissant le contrôle de chiffrement AES-256 au repos que les charges de travail classifiées requièrent. L'avantage opérationnel est significatif : pas de provisionnement de brokers, pas de rotation de certificats pour le cluster lui-même, redondance géographique intégrée et disponibilité garantie par SLA.

La contrepartie est claire : Event Hubs ne prend pas en charge la totalité de la surface de l'API Kafka (pas de transactions, pas de sémantique exactly-once entre topics au niveau du broker, et pas de modèle ACL personnalisé au-delà du RBAC au niveau de l'espace de noms). Et pour les charges de travail devant être entièrement air-gap — sans connectivité à un réseau externe — Event Hubs n'est pas une option. Pour ces programmes, les clusters KRaft auto-hébergés restent la seule voie viable.

Intégration zero-trust pour les consommateurs Kafka

Le modèle ACL de Kafka est un contrôle de sécurité nécessaire mais insuffisant dans un environnement zero-trust. Chaque service consommateur devrait s'authentifier en utilisant un identifiant de courte durée émis par votre fournisseur d'identité au démarrage du pod ou du processus, plutôt qu'un mot de passe statique de longue durée. Le moteur de secrets Kafka de Vault peut émettre des identifiants SCRAM de courte durée de manière dynamique, avec révocation automatique à l'expiration du bail. Combiné avec des certificats clients mTLS pivotés régulièrement, cela garantit qu'un identifiant de compte de service compromis n'offre qu'une fenêtre opérationnelle limitée à un attaquant.

Appliquez des politiques réseau au niveau Kubernetes ou pare-feu pour vous assurer que seuls les pods avec les bons labels peuvent atteindre les ports des brokers Kafka. Les ACL natives de Kafka doivent être la deuxième ligne de défense, pas la première. Pour un traitement complet de l'architecture zero-trust appliquée aux réseaux de défense, voir l'article sur l'architecture zero-trust pour les réseaux militaires.

Corvus.Quantum : streaming basé sur Kafka avec chiffrement post-quantique

Corvus.Quantum est une plateforme de streaming d'événements éprouvée au combat, construite sur Kafka, déployée opérationnellement en Ukraine pour le traitement de données de défense en temps réel. Elle étend Kafka standard avec un chiffrement post-quantique au niveau applicatif — utilisant CRYSTALS-Kyber pour l'encapsulation de clé et AES-256-GCM pour le chiffrement de la charge utile — de sorte que les messages sont protégés contre l'interception actuelle par l'adversaire et les futures attaques de déchiffrement à capacité quantique. Cela répond à la menace de type « collecter maintenant, déchiffrer plus tard », particulièrement pertinente pour les données SIGINT et ISR ayant une longue durée de vie en termes de sensibilité.

Au-delà du chiffrement, Corvus.Quantum fournit une configuration de broker pré-durcie pour les déploiements classifiés : modèles de cluster en mode KRaft, automatisation des certificats TLS 1.3 via une instance step-ca intégrée, rotation des identifiants SCRAM intégrée à HashiCorp Vault, et modèles d'ACL de topics sensibles à la classification. La plateforme a été validée dans des environnements sans connectivité internet, traitant des milliers d'événements capteurs par seconde avec une latence bout-en-bout inférieure à 100 ms.

Pour les équipes d'approvisionnement évaluant Kafka pour des programmes de défense, Corvus.Quantum réduit l'effort d'ingénierie pour sécuriser un cluster Kafka de plusieurs mois à quelques jours, tout en fournissant une base de configuration auditable alignée sur les exigences CNSA 2.0 et supportant l'intégration avec les solutions inter-domaines existantes.

Articles connexes

• Architecture zero-trust pour les réseaux militaires
• Modèles de déploiement air-gap pour les charges de travail de défense
• Cryptographie post-quantique et conformité CNSA 2.0 pour la défense