Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article fournit une vue d’ensemble de la façon d’implémenter des charges de travail dans le cloud public souverain.
Classifier les données pour la souveraineté
En catégorisant les données en fonction des exigences réglementaires et de confidentialité, les organisations peuvent protéger les données, maintenir la conformité et réduire les risques.
| Sensibilité des risques | Descriptif |
|---|---|
| Low | La perte de confidentialité, d’intégrité ou de disponibilité a un effet négatif limité sur les opérations organisationnelles, les ressources ou les individus. |
| Modéré | La perte a un effet négatif grave sur les opérations, les actifs ou les individus. |
| High | La perte a un effet négatif grave ou catastrophique sur les opérations, les biens ou les individus. |
Toutes les données organisationnelles ne nécessitent pas les mêmes contrôles ; la classification permet aux équipes de hiérarchiser les efforts de sécurité et de souveraineté et d’allouer des ressources où elles sont les plus efficaces. Les données à haut risque, telles que les données personnelles ou les secrets d’état, nécessitent des garanties plus fortes et une surveillance plus rigoureuse. Les données à faible risque peuvent être éligibles pour des services de plateforme plus larges qui permettent la modernisation et l’innovation.
Définissez des critères clairs et prédéfinis pour la classification. Les classifications formelles ne sont pas imposées par des normes telles que NIST, de sorte qu’elles adoptent un cadre basé sur les risques approprié pour leur organisation.
Conseil / Astuce
Vous trouverez des informations sur la définition du modèle de classification des données de votre organisation dans le cadre Well-Architected : stratégies d’architecture pour la classification des données.
Les critères de risque peuvent inclure le type de données, la sensibilité, les obligations réglementaires et la valeur métier. Utilisez des outils qui analysent les attributs, les modèles et les métadonnées pour attribuer des classifications de manière cohérente et efficace. Après l’étiquetage des données, appliquez les contrôles de sécurité, le chiffrement et les actions de stratégie appropriés pour chaque classification.
Bien que NIST définit trois niveaux d’impact, de nombreuses organisations utilisent un schéma de classification à quatre étiquettes : Public, Interne, Confidentiel et Secret.
Évaluer les services Azure pour les contrôles de souveraineté
Azure offre des centaines de services, chacun avec des caractéristiques de configuration et de gestion des données uniques. Tous les contrôles souverains ne s’appliquent pas à chaque service. Par exemple, certains services ne prennent pas en charge les clés gérées par le client (CMK), et d’autres peuvent ne pas stocker les données client du tout. Pour appliquer des contrôles significatifs de souveraineté des données, il est essentiel de comprendre comment chaque service traite et stocke des données.
Considérations clés :
- Stockage des données : Le service stocke-t-il les données client ? Si ce n’est pas le cas, certains contrôles (comme le chiffrement au repos) peuvent ne pas s’appliquer.
- Prise en charge de CMK : Le service prend-il en charge les clés gérées par le client et peut-il utiliser azure Managed HSM ?
- Informatique confidentielle : L’informatique confidentielle est-elle pertinente (par exemple, si le trafic TLS est inspecté) ?
- Résidence des données : Où sont stockées et traitées les données ?
- Rôle de service : Quel type de données le service gère-t-il (par exemple, les données sensibles et les métadonnées) ?
Exemples :
- Un équilibreur de charge ne stocke pas de données. Par conséquent, le chiffrement au repos n’est pas obligatoire. Toutefois, l’informatique confidentielle peut être pertinente si le trafic TLS est inspecté.
- Certains services, tels qu’Azure Front Door CDN, cachent temporairement ou distribuent du contenu globalement.
- Une base de données de métadonnées avec des noms de machine virtuelle ou des GUID nécessite des contrôles moins stricts qu’une machine virtuelle hébergeant des données de carte de crédit.
- Azure Network Manager stocke la configuration réseau, mais ne traite pas le trafic réseau réel.
Bonnes pratiques
Pour chaque service, évaluez ses fonctionnalités, son rôle architectural et le type de données qu’il gère. Cette évaluation vous aide à appliquer le niveau de contrôle approprié et garantit la conformité aux exigences de souveraineté. Vous pouvez documenter des services à l’aide d’une matrice comme suit :
| Résidence de service | Résidence des données | Chiffrement du transit des données | Chiffrement des données au repos | ACC |
|---|---|---|---|---|
| L’instance de service s’exécute dans la région choisie. | Les données stockées par le service se trouvent dans la région choisie. (N/A indique que le service ne stocke pas activement les données client.) | La connectivité au service est chiffrée (par exemple, HTTPS/TLS). | Si des données sont stockées, utilisez des clés gérées par le client (CMK) via Key Vault (Standard/Premium) ou un HSM managé. « Plateforme » indique le chiffrement Azure par défaut. | Indique si le service peut utiliser l’informatique confidentielle Azure (ACC) pour protéger les données en mémoire. |
Établir des stratégies de gouvernance pour une conformité cohérente
- Exiger des clés gérées par le client (CMK) pour les services de stockage persistants (par exemple, Stockage Azure, Azure SQL Database, Cosmos DB).
- Appliquez l’affinité régionale pour les services susceptibles de répliquer ou de mettre en cache des données globalement (telles que Front Door, CDN ou Traffic Manager).
- Limitez l’utilisation des services dans les charges de travail sensibles s’ils ne disposent pas de fonctionnalités de résidence ou de chiffrement.
- Activez l’informatique confidentielle le cas échéant (par exemple, les séries de machines virtuelles avec AMD SEV-SNP ou Intel TDX).
Comment utiliser la matrice avec votre modèle de classification des données
Utilisez la matrice de capacité comme référence lors de la conception de votre architecture d’application. Le mappage des contrôles souverains pris en charge pour chaque service aide les architectes et les équipes de sécurité à comprendre quelles garanties peuvent et ne peuvent pas être appliquées.
- Pour les services qui traitent des données restreintes ou hautement confidentielles (telles que des transactions financières, des dossiers de santé ou des identificateurs gouvernementaux), appliquez une utilisation stricte de CMK, des garanties de résidence fortes et l'informatique confidentielle (ACC) le cas échéant.
- Pour les services qui gèrent uniquement les métadonnées opérationnelles (telles que les noms de machines virtuelles, la configuration de topologie ou les GUID), le chiffrement de plateforme ou les contrôles réduits peut être suffisant.
En combinant la matrice de capacité avec votre modèle de classification des données, vous pouvez concevoir chaque charge de travail avec une posture de sécurité claire et applicable. Cette approche permet de répondre aux obligations réglementaires et renforce la confiance et la résilience opérationnelle dans les environnements cloud souverains.