Stratégie multi-cloud pour la défense : éviter la dépendance aux fournisseurs dans les systèmes militaires

La dépendance à un seul fournisseur cloud est un risque stratégique pour les systèmes de défense analytiquement similaire à la dépendance à un seul fournisseur dans tout autre domaine de capacité critique. Lorsque l'intégralité de l'infrastructure cloud d'un programme de défense fonctionne chez un seul fournisseur, ce fournisseur peut exercer un effet de levier par la tarification, la discontinuation de service ou les modifications contractuelles lors du renouvellement du programme. Les développements géopolitiques peuvent compliquer ou éliminer l'accès à l'infrastructure cloud appartenant à des entités étrangères. Une panne majeure de cloud peut dégrader ou éliminer les capacités opérationnelles de défense qui en dépendent.

La stratégie multi-cloud répond à ce risque stratégique en distribuant les charges de travail entre plusieurs fournisseurs, en maintenant la portabilité au niveau de l'architecture et en évitant l'imbrication profonde avec des services cloud propriétaires qui rendraient la migration prohibitivement coûteuse. Cet article examine comment fonctionnent les patterns de déploiement multi-cloud, comment les outils d'Infrastructure-as-Code cloud-agnostiques soutiennent la portabilité et comment la complexité de conformité est gérée lors du maintien des contrôles de classification chez plusieurs fournisseurs.

Risque stratégique de la dépendance à un seul fournisseur cloud

Le risque géopolitique est le risque le plus distinctement lié à la défense dans la dépendance aux fournisseurs cloud. La relation entre les organisations de défense et les fournisseurs cloud est médiatisée par des structures politiques et juridiques qui peuvent changer. La législation européenne sur la souveraineté des données (RGPD, exceptions de sécurité nationale, EUCS) crée une incertitude juridique persistante sur la légalité à long terme du stockage de données de défense sur l'infrastructure de fournisseurs dont le siège est aux États-Unis.

Le risque opérationnel des pannes est une préoccupation plus immédiate. Les grands fournisseurs cloud subissent des pannes significatives : les pannes AWS us-east-1 en 2021 et 2023 ont perturbé de grandes portions de l'internet commercial pendant des heures. Pour les systèmes de défense avec des exigences de disponibilité, la dépendance à un seul fournisseur cloud sans capacité de repli est opérationnellement inacceptable.

L'effet de levier tarifaire est un risque commercial aux implications stratégiques. Les fournisseurs cloud peuvent augmenter les prix lors du renouvellement des contrats ; les coûts de migration sur des architectures profondément intriquées rendent la réaction difficile. L'expérience du DoD avec les compétitions de contrats cloud JEDI et JWCC reflétait la conscience de ce risque.

Patterns de déploiement multi-cloud

Le partage des charges de travail actif-actif distribue différents types de charges de travail entre différents fournisseurs cloud en fonction des avantages comparatifs de chaque fournisseur : un programme de défense peut exécuter des applications classifiées chez le fournisseur avec les accréditations cloud classifiées les plus solides, des charges analytiques et ML chez le fournisseur avec la meilleure infrastructure ML, et des outils de collaboration chez un troisième fournisseur souverain UE pour des raisons de résidence des données.

La reprise après sinistre primaire-secondaire exécute les charges de travail de production chez un fournisseur primaire avec un environnement de secours chaud chez un fournisseur secondaire. L'environnement secondaire est maintenu à une disponibilité suffisante pour prendre en charge dans un RTO (Recovery Time Objective) défini si le primaire échoue. Ce pattern est plus simple opérationnellement, mais nécessite des tests de basculement réguliers.

IaC cloud-agnostique : Terraform et Crossplane

Terraform (de HashiCorp, maintenant un produit sous licence BSL avec un fork open source à OpenTofu) est l'outil standard d'Infrastructure-as-Code pour le provisionnement de ressources cloud-agnostique. Des providers Terraform existent pour toutes les grandes plateformes cloud (AWS, Azure, GCP, OVHcloud et des dizaines d'autres), et la syntaxe de configuration Terraform est cloud-agnostique.

Pour les architectures multi-cloud, le système d'espaces de travail et de modules de Terraform permet d'instancier la même infrastructure applicative chez différents fournisseurs : un module Terraform pour une « application web à trois niveaux » peut avoir des implémentations spécifiques au fournisseur (une pour AWS, une pour Azure, une pour OVHcloud) qui exposent la même interface.

Crossplane est un projet diplômé CNCF qui fournit un plan de contrôle basé sur Kubernetes pour le provisionnement de ressources cloud. Le système Crossplane Composition permet l'abstraction des ressources cloud : une Composition définit un type de ressource composite (par exemple, une « DefenceDatabase ») qui se mappe sur des ressources spécifiques au fournisseur, permettant aux équipes applicatives de demander une DefenceDatabase sans savoir si elle est soutenue par AWS RDS, Azure Database for PostgreSQL ou une instance PostgreSQL sur site.

Crossplane est particulièrement précieux pour les programmes de défense adoptant un modèle d'ingénierie de plateforme : une équipe de plateforme centrale gère les compositions Crossplane et les configurations de fournisseurs, et les équipes applicatives consomment les ressources cloud en libre-service.

Portabilité des données : formats ouverts et stockage compatible S3

Le vendor lock-in au niveau des données — où les données sont stockées dans des formats propriétaires ou des services sans mécanisme d'export standard — est la forme la plus difficile de lock-in à fuir. L'éviter nécessite une conception explicite de la portabilité des données :

Le stockage objet compatible S3 est le standard pratique pour le stockage de données cloud-agnostique. L'API Amazon S3 est devenue le standard de facto pour le stockage objet, avec des API compatibles S3 fournies par Azure Blob Storage, GCP Cloud Storage, OVHcloud Object Storage et des solutions sur site comme MinIO.

Le SQL standard sur des bases de données gérées compatibles PostgreSQL évite le lock-in des services de bases de données propriétaires. Les applications utilisant SQL standard et le protocole PostgreSQL peuvent migrer entre fournisseurs avec seulement des changements de configuration.

Complexité de conformité : contrôles de classification chez plusieurs fournisseurs

Le défi opérationnel le plus significatif dans les architectures de défense multi-cloud est le maintien cohérent des contrôles de classification chez plusieurs fournisseurs, chacun avec des capacités de services différentes, des certifications de conformité différentes et des outils différents pour implémenter les contrôles de sécurité.

Les contrôles de classification — contrôles d'accès indexés sur le niveau d'accréditation, journalisation d'audit de tous les accès aux données classifiées, gestion des clés de chiffrement, application de la résidence des données — doivent être implémentés de manière équivalente chez chaque fournisseur utilisé pour les charges de travail classifiées.

L'approche pratique consiste à construire une couche de conformité agnostique au fournisseur : un ensemble de modules Terraform/Crossplane et de politiques de contrôleurs d'admission Kubernetes qui implémentent les contrôles de conformité requis indépendamment du fournisseur cloud qui provisionne les ressources sous-jacentes.