Architecture GovCloud pour la défense: Azure Government vs AWS GovCloud

Choisir une plateforme cloud pour les charges de travail de défense n'est pas principalement une décision technologique — c'est une décision de conformité et de souveraineté des données. L'infrastructure de calcul sous-jacente d'Azure Government et d'AWS GovCloud est globalement similaire à leurs équivalents commerciaux. Ce qui diffère, c'est la posture de conformité réglementaire, l'isolation physique et logique des locataires commerciaux, le modèle de support et le niveau de classification maximum supportable.

Se tromper dans cette décision a des conséquences difficiles à inverser. Migrer une application de défense d'une plateforme cloud à une autre après déploiement en production est une entreprise considérable au niveau du programme. La décision de sélection de plateforme, prise tôt, contraint l'architecture pour toute la durée de vie du programme.

Cadres de conformité : FedRAMP, niveaux IL et exigences NATO

Le principal cadre de conformité américain pour les charges de travail cloud est FedRAMP (Federal Risk and Authorization Management Program), qui définit trois niveaux d'impact : Faible, Modéré et Élevé. FedRAMP High est la base de référence pour les données gouvernementales sensibles mais non classifiées. Azure Government et AWS GovCloud détiennent des autorisations FedRAMP High sur la plupart de leurs services.

Au-delà de FedRAMP, le DoD Cloud Computing Security Requirements Guide (CC SRG) définit les niveaux d'impact 4 à 6. IL4 couvre les informations contrôlées non classifiées (CUI) avec une désignation de sécurité nationale. IL5 couvre les systèmes de sécurité nationale (NSS) et les informations classifiées DoD jusqu'au niveau SECRET. IL6 couvre les données SECRET. Seules des régions cloud physiquement isolées et spécifiques se qualifient pour les charges de travail IL5 et IL6 — pas les régions GovCloud standard.

Pour les nations membres de NATO hors des États-Unis, les cadres pertinents sont les exigences de sécurité cloud de la NATO NCIA (Communications and Information Agency) et leurs équivalents nationaux. NATO NCIA a approuvé des offres de services cloud spécifiques pour les données NATO RESTRICTED et NATO CONFIDENTIAL après ses propres processus d'audit. Ces approbations ne sont pas automatiquement conférées par FedRAMP — une évaluation séparée est requise.

Azure Government vs AWS GovCloud : différenciateurs clés

Isolation physique. Les deux plateformes exploitent une infrastructure physiquement séparée de leurs clouds commerciaux, gérée uniquement par des citoyens américains examinés (pour les programmes américains) ou par des exigences d'examen national équivalentes. Les deux fournissent une séparation logique via des options d'infrastructure dédiée (hôtes dédiés, calcul bare metal).

Parité de disponibilité des services. Les services cloud commerciaux apparaissent souvent dans GovCloud avec un décalage de 12 à 24 mois. AWS GovCloud a historiquement une meilleure parité de catalogue de services avec AWS commercial. Azure Government a une forte parité dans ses services IaaS et PaaS de base et a considérablement amélioré la couverture des services IA/ML, bien que certains services Azure commerciaux restent indisponibles dans le cloud gouvernemental.

Services spécifiques DoD. Microsoft détient le contrat DoD JEDI/JWCC et a réalisé des investissements significatifs dans les régions Azure Government capables IL5. AWS exploite l'environnement C2S (Commercial Cloud Services) pour la communauté IC et dispose de régions GovCloud East et West capables IL5. Pour les programmes nécessitant IL5, les deux sont viables — la disponibilité spécifique des services à IL5 varie selon la région et doit être vérifiée dans la documentation actuelle du fournisseur.

Modèle de support. Les deux fournisseurs proposent des niveaux de support gouvernemental dédiés avec du personnel de support habilité. Pour les programmes avec des exigences de sécurité opérationnelle strictes, vérifier que l'accès au support est limité au personnel convenablement habilité — et auditnable — est une exigence contractuelle, pas une hypothèse.

Cloud hybride pour les charges de travail classifiées

La plupart des programmes de défense au-dessus de la classification SECRET ne peuvent pas placer de charges de travail dans un cloud commercial — pas même dans une région GovCloud accréditée. Les charges de travail classifiées au niveau SECRET et au-dessus doivent fonctionner dans des installations accréditées exploitées par le gouvernement ou des contractants, avec des contrôles de sécurité physique et des exigences d'accès du personnel au niveau SCIF. Le cloud, pour ces charges de travail, est soit un déploiement cloud privé (matériel appartenant au gouvernement exécutant une IaaS de type cloud), soit un environnement cloud classifié tel que C2S ou Azure Government Top Secret.

L'architecture pratique pour la plupart des programmes est hybride : les composants non classifiés et CUI fonctionnent dans GovCloud, les composants classifiés fonctionnent dans un environnement cloud privé ou classifié, et des solutions interdomaines (CDS) gèrent le transfert de données entre les deux environnements. Concevoir correctement le CDS — notamment la logique de validation des données, de conversion de format et de reclassification — est généralement l'un des éléments les plus complexes et critiques pour le calendrier de l'architecture.

Exigences de résidence des données

De nombreux programmes de défense ont des exigences contractuelles ou légales précisant où les données peuvent être stockées et traitées. Les données classifiées des États membres de l'UE peuvent être soumises à des restrictions empêchant leur stockage dans une infrastructure exploitée par les États-Unis (même dans des centres de données européens appartenant aux États-Unis). Les données classifiées NATO ont des exigences de traitement spécifiques qui limitent les lieux de traitement.

Azure et AWS disposent tous deux de régions cloud gouvernementales en Europe (Pays-Bas, Allemagne) avec des postures de conformité spécifiques pour les exigences de données souveraines de l'UE. L'évaluation de ces options nécessite une révision juridique des instructions de classification spécifiques au programme et des lois nationales, pas seulement les supports marketing du fournisseur cloud.

Base zéro confiance pour le cloud de défense

L'architecture de référence zéro confiance du DoD définit sept piliers : Utilisateur, Appareil, Réseau, Application/Charge de travail, Données, Automatisation/Orchestration et Visibilité/Analytique. Pour un déploiement GovCloud, implémenter une base zéro confiance signifie : accès basé sur l'identité (Microsoft Entra ID / AWS IAM avec MFA et accès conditionnel), application de la posture des appareils (pas d'accès depuis des appareils non gérés ou non conformes), microsegmentation réseau (pare-feu de couche application, pas de confiance implicite entre les services dans le même VNet/VPC), et contrôles d'accès basés sur la classification des données (chiffrement au repos avec des clés gérées par le client, étiquettes de classification appliquées au niveau de la couche applicative).

L'isolation multi-locataire au niveau de l'infrastructure — garantissant qu'une charge de travail d'un locataire ne peut pas accéder aux données ou à l'infrastructure d'un autre locataire — est garantie par le fournisseur cloud. Ce qui n'est pas garanti, c'est l'isolation au niveau applicatif. Une application de défense multi-locataire qui stocke toutes les données des locataires dans une base de données partagée avec une sécurité au niveau des lignes n'est pas conforme zéro confiance, quelle que soit la plateforme cloud sur laquelle elle s'exécute. L'isolation des locataires doit être implémentée et vérifiée au niveau de la couche applicative.