Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
Cet article répond aux questions courantes sur la zone d’atterrissage souverain (SLZ).
Nous avons déjà déployé des zones d’atterrissage Azure (ALZ). Avons-nous besoin de SLZ ?
Pas forcément. La zone d’atterrissage souveraine (SLZ) est une variante d’ALZ et non un remplacement.
Vous pouvez étendre votre ALZ existant avec des contrôles souverains (niveau 1 à 3) au lieu de déployer un SLAZ distinct ou de le redéployer si vous avez déjà :
- Utiliser une hiérarchie de groupe d’administration structurée (plateforme et charge de travail)
- Appliquer des restrictions de région pour les charges de travail sensibles
- Appliquer des clés gérées par le client de manière cohérente pour les données classifiées
- Disposer d’un processus (ou feuille de route) pour l’adoption de l’informatique confidentielle
Adoptez des modèles SLZ lorsque vous faites face à :
- Pression sur les échéances réglementaires
- Absence de séparation des charges de travail (confidentielle ou standard)
- Expansion de régions non gouvernées
- Stratégies clés mixtes ou incohérentes
- Besoin d’intégration structurée à grande échelle
Conseil / Astuce
Commencez par une « superposition de stratégie » (mode d’audit) au-dessus d’ALZ pour mesurer l’impact avant d’introduire des effets de refus. Consultez Adoptez des garde-fous pilotés par des stratégies politiques pour découvrir comment utiliser les modes d’application pour faciliter cette opération.
Quelle est la différence entre les contrôles souverains de niveau 1, de niveau 2 et de niveau 3 ?
Les trois niveaux représentent un modèle de maturité progressif pour les contrôles souverains :
| Level | Scope | Contrôles courants |
|---|---|---|
| Niveau 1 | Résidence des données et étendue du service | Liste d'autorisation de région ; interdire les services globaux (le cas échéant) ; autorisation/rejet de service ; valeurs par défaut du chiffrement en transit |
| Niveau 2 | Chiffrement au repos/en transit | CMK/HSM managé requis ; interdire le chiffrement de plateforme uniquement pour les types de ressources ciblés |
| Niveau 3 | Chiffrement en cours d’utilisation | Imposer les SKU de machines virtuelles / conteneurs confidentiels ; exiger des preuves d’attestation pour la libération des clés |
Comment fonctionnent les exceptions ?
Le framework SLZ suppose que certaines exceptions sont inévitables. Utilisez ces instructions :
- Documentez la justification commerciale, la durée, les mesures d'atténuation et le propriétaire.
- Appliquez par le biais du paramétrage (par exemple, liste des régions autorisées) au lieu de désactiver des initiatives entières.
- Suivre le nombre d’exceptions et l’âge ; les exceptions obsolètes indiquent l’érosion de la gouvernance.
- Utilisez les fonctionnalités d’exemption d’Azure Policy pour la visibilité, le suivi et la création de rapports.
Comment SLZ se rapporte-t-il à d’autres frameworks de conformité ?
SLZ se concentre sur trois domaines de contrôle souverain fondamentaux (résidence, chiffrement, calcul confidentiel) et l’activation opérationnelle. Il est complémentaire aux frameworks tels que ISO, NIST, PCI ou des addendas spécifiques au secteur. Lorsque le chevauchement se produit (par exemple, les exigences de chiffrement), réutilisez les mêmes stratégies pour éviter la duplication.
Quel est le rôle de la gestion des clés externes (EKM) ?
La gestion des clés externes (EKM , hold-your-own-key) est généralement appliquée de manière sélective aux charges de travail de classification les plus élevées où la garde de clé exclusive est une exigence légale ou contractuelle. Utiliser une stratégie de clés hiérarchisée : gérées par la plateforme (référence de base) → CMK/HSM managé (par défaut pour les données classées) → EKM (sélectionner des charges de travail à impact élevé). Évitez l’EKM universel, sauf s’il est mandaté ; elle ajoute la latence et la complexité opérationnelle.