Évaluer les exigences souveraines
Microsoft Cloud Adoption Framework pour Azure est un cadre de cycle de vie complet qui aide les architectes du cloud, les professionnels de l’informatique et les décisionnaires à atteindre leurs objectifs en matière d’adoption du cloud. Il propose des meilleures pratiques, de la documentation et des outils qui vous aident à créer et mettre en œuvre des stratégies d’entreprise et de technologie pour le cloud. Les organisations du secteur public qui ont des exigences strictes en matière de souveraineté peuvent incorporer leurs objectifs de souveraineté dans leurs efforts de planification, afin que les décisions stratégiques sur l’adoption du cloud soient alignées sur ces exigences de souveraineté.
Cet article présente les domaines dans lesquels les organisations peuvent souhaiter évaluer, identifier et documenter leurs exigences en matière de souveraineté, et fournit des recommandations sur où ces exigences peuvent s’intégrer dans leurs efforts de planification élargis associés au Cloud Adoption Framework pour Azure.
Identifier les données souveraines
Les exigences en matière de souveraineté des données peuvent inclure des mandats pour conserver la propriété des données et spécifier des méthodes pour le stockage, l’utilisation et la transmission des données. Parfois, les exigences en matière de souveraineté des données peuvent également inclure des limitations ou des mandats concernant la résidence des données. Comprendre ces exigences dès le début du parcours cloud d’une organisation peut aider à établir des modèles de conception communs pour la souveraineté des données, plutôt que d’attendre que les propriétaires de charges de travail développent des solutions pour répondre aux exigences de souveraineté.
Les organisations qui suivent le Cloud Adoption Framework pour Azure identifient les charges de travail candidates à migrer vers le cloud pendant la phase de planification, puis conçoivent l’environnement pour héberger ces charges de travail pendant la phase de préparation. Ces activités peuvent permettre à une organisation d’identifier les types de données souveraines qui nécessitent un traitement spécial dans l’environnement cloud de l’état cible.
Microsoft utilise de nombreux types de données, comme les informations personnelles fournies à Microsoft et les données des clients chargées dans les services cloud pour fournir des services professionnels et en ligne. Les responsabilités sur la protection des données de Microsoft sont documentées dans l’Addendum sur la protection des données des produits et services Microsoft (DPA) et incluses dans les accords d’une organisation avec Microsoft. Le DPA spécifie les différents types de données gérés par Microsoft et décrit les pratiques utilisées par Microsoft pour protéger ces types de données.
De nombreuses organisations ont des programmes de gouvernance des données existants qui spécifient les exigences pour le traitement des données sensibles et peuvent utiliser ces informations pour déterminer si les exigences en matière de souveraineté des données s’appliquent à toutes ou uniquement à un sous-ensemble de classifications de données. Lorsqu’une organisation charge et maintient ses données dans un service cloud, il lui incombe de classer, d’étiqueter et de gérer avec précision les données conformément à ses exigences en matière de traitement des données. Certaines organisations souhaitent peut-être utiliser l’adoption du cloud comme une opportunité de réviser leurs programmes de classification des données.
Pour plus d’informations sur la façon dont la classification des données s’applique à l’adoption du cloud, consultez Classification des données dans Azure et Guides de gouvernance du cloud.
Exemples d’exigences en matière de souveraineté des données
Les organisations qui ont des exigences strictes en matière de souveraineté des données doivent peut-être planifier certains des scénarios représentatifs suivants lorsqu’elles migrent des charges de travail vers le cloud.
Étiquettes de classification des données
Les étiquettes de classification identifient les ressources avec des exigences de traitement spéciales. Bien que les étiquettes de classification soient appliquées aux documents, elles peuvent également être appliquées aux actifs. Les clients peuvent utiliser les fonctionnalités de marquage natives dans Azure pour appliquer des étiquettes de classification à des ressources comme des services de calcul et des magasins de données, et pour des structures logiques dans Azure, comme des abonnements et des groupes de gestion.
Pour plus d’informations, consultez Marquage dans Azure et Solutions Microsoft Purview eDiscovery.
Limites de classification des données
Lorsqu’une organisation choisit de regrouper des données (ou des applications) d’une classification similaire, un périmètre de sécurité est souvent déployé pour servir de limite à l’emplacement où le stockage des données est autorisé. Lorsque les clients déploient des charges de travail dans Azure, ils peuvent utiliser des abonnements et des groupes d’administration pour créer des limites logiques au sein de l’environnement cloud de l’organisation. Ces limites aident à atténuer les risques de confidentialité liés à l’accès non autorisé et les risques de confidentialité liés à l’agrégation et l’attribution des données.
Les organisations qui ont des exigences strictes en matière de souveraineté des données peuvent se demander si elles souhaitent organiser leur environnement selon un modèle hiérarchique, dans lequel des niveaux de privilèges plus élevés héritent de niveaux de privilèges inférieurs (par exemple, comme dans le modèle Bell-LaPadula), ou si elles préfèrent mettre en œuvre un modèle non hiérarchique dans lequel des contrôles d’accès obligatoires sont utilisés pour créer des limites qui compartimentent certaines parties de l’environnement du reste de l’environnement. Les décisions sur la manière dont une organisation gère les limites de classification des données sont cruciales lors de la conception de zones d’atterrissage dans la phase de préparation du Cloud Adoption Framework pour Azure.
Pour plus d’informations, consultez Groupes de gestion dans Azure et Gouvernance des données.
Résidence des données
Les organisations qui doivent répondre aux exigences de résidence des données doivent accorder une attention particulière aux services Azure nécessaires pour prendre en charge une charge de travail, et à l’endroit où ces services sont géographiquement disponibles. Les services Azure sont déployés dans des régions qui prennent en charge les connexions réseau à faible latence et des fonctionnalités telles que les zones de disponibilité. Ces régions sont regroupées en zones géographiques, qui offrent des fonctionnalités supplémentaires de résilience et de reprise après sinistre.
Si une organisation doit maintenir la résidence des données pour sa charge de travail, elle doit s’assurer que les services Azure utilisés sont disponibles dans sa région et sa zone géographiquee préférées. De plus, certains services sont déployés globalement et n’offrent pas de résidence des données dans une région ou une zone géographique donnée pour les données stockées dans ce service.
Pour plus d’informations sur la résidence des données, les régions et zones de disponibilité Azure, ainsi que la disponibilité régionale des services Azure, consultez les articles suivants :
- Résidence des données pour Microsoft Cloud for Sovereignty
- Résidence des données dans Azure
- Azure régions et zones de disponibilité.
- Azure produits par région.
Propriété, conservation et portabilité des données
Les clients ayant des exigences strictes en matière de souveraineté des données se posent souvent de nombreuses questions : qui conserve la propriété des données stockées dans Azure, qui peut accéder à ces données et que deviennent ces données si un client choisit de déplacer sa charge de travail vers une autre plateforme. Ces exigences peuvent varier en termes de portée et de spécificité, mais elles ont généralement tendance à être liées à la question fondamentale de savoir ce que deviennent les données lorsque vous les hébergez dans Microsoft Cloud Service.
Pour aider à répondre à ces questions à un niveau élevé et donner aux clients un point de départ pour identifier leurs exigences en matière de souveraineté des données qui s’appliquent aux fournisseurs de services cloud, Microsoft a publié une série d’articles sur la protection et la gestion des données des clients qui répondent à bon nombre de ces questions, et ces articles sont disponibles en ligne dans le centre de gestion de la confidentialité.
Pour plus d’informations, consultez Gestion des données chez Microsoft.
Maintenir la souveraineté opérationnelle dans le cloud
Les exigences en matière de souveraineté opérationnelle peuvent affecter la façon dont un environnement dans Azure est conçu, mis à jour et géré. Il est donc important de bien comprendre ces exigences avant de finaliser les conceptions techniques dans le cadre de la phase de préparation du Cloud Adoption Framework pour Azure. Les exigences courantes en matière de souveraineté opérationnelle peuvent inclure :
- Limitations concernant l’emplacement et la nationalité du personnel administratif.
- Exigences de contrôle d’accès qui limitent l’accès privilégié des fournisseurs de services cloud.
- Mandats pour la haute disponibilité et la reprise d’activité.
Il est important de comprendre clairement l’intention et les risques que ces exigences atténuent, car bon nombre de ces exigences sont satisfaites dans le cloud en utilisant des méthodes différentes de celles couramment utilisées en local.
Une fois que l’organisation a identifié les exigences en matière de souveraineté opérationnelle, elle peut sélectionner les contrôles de souveraineté techniques et administratifs appropriés pour fournir le bon niveau d’atténuation et de garantie des risques. Lors de la sélection des contrôles de souveraineté, il est important de comprendre que la sélection de certaines fonctionnalités pouvant fournir une souveraineté opérationnelle supplémentaire limite les options d’une organisation pour adopter d’autres services Azure.
Par exemple, une organisation qui a besoin de l’informatique confidentielle pour ses charges de travail Azure doit limiter ses choix d’architecture aux services pouvant s’exécuter sur l’informatique confidentielle Azure, comme les machines virtuelles confidentielles ou les conteneurs confidentiels. Pour cette raison, il est souvent judicieux d’associer les exigences de souveraineté opérationnelle à une classification de données spécifiée, plutôt que d’adopter une approche où toutes les charges de travail et données doivent répondre à l’ensemble d’exigences de souveraineté le plus restrictif.
De plus, certaines exigences en matière de souveraineté opérationnelle, comme Autarky (par exemple, pouvoir s’exécuter indépendamment des réseaux et systèmes externes) sont irréalisables dans les plateformes de cloud computing hyperscale comme Azure, qui dépendent des mises à jour régulières de la plateforme pour maintenir les systèmes dans un état optimal.
Exemples d’exigences en matière de souveraineté opérationnelle
Voici quelques exigences courantes en matière de souveraineté opérationnelle ainsi que des exemples de services et de fonctionnalités Azure pertinents qui peuvent répondre à ces exigences :
Sécurité des logiciels
Les exigences en matière de sécurité logicielle peuvent inclure des activités de développement, telles que l’application de protections cryptographiques spécifiques, la réalisation de révisions de code et la réalisation de tests de sécurité et d’intrusion des applications. Cela peut également inclure des processus opérationnels, tels que la mise en œuvre de contrôles d’accès, l’utilisation de technologies de chiffrement et la surveillance des événements de sécurité.
Microsoft fournit diverses fonctionnalités pour aider les clients à répondre aux exigences de souveraineté opérationnelle pour les logiciels développés par Microsoft et le client. Microsoft suit le cycle de vie de développement sécurisé (SDL) lors du développement de logiciels au niveau de la plateforme pour Azure. Les 12 pratiques du SDL sont incorporées dans les processus et procédures d’ingénierie de Microsoft et sont régulièrement évaluées dans le cadre des activités d’assurance de Microsoft. De plus, Microsoft fournit des fonctionnalités pour aider les clients à adopter les pratiques du cycle de vie de développement sécurisé dans le cadre de leur cycle de vie de développement de logiciels.
Pour plus d’informations, consultez Cycle de vie de développement sécurisé de Microsoft et Meilleures pratiques de développement sécurisé dans Azure.
Sécurité des infrastructures
Les charges de travail qui s’exécutent sur Azure peuvent profiter des nombreuses fonctionnalités développées par Microsoft pour garantir l’intégrité de la plateforme. Les fonctionnalités incluent ses microprogrammes, ses logiciels et son infrastructure hôte. Les organisations peuvent avoir des exigences de souveraineté opérationnelle pour isoler leurs données des opérateurs cloud. Azure fournit des fonctionnalités que les clients peuvent utiliser pour tirer parti de l’agilité et de la résilience du cloud public tout en maintenant l’isolement des fournisseurs de services cloud et de leur personnel administratif. Les organisations ayant des exigences liées à l’attestation au niveau matériel, à la vérification de l’intégrité des logiciels (par exemple, le démarrage sécurisé) et à la gestion sécurisée des clés peuvent examiner les pratiques d’intégrité et de sécurité de la plateforme de Microsoft et accéder à la documentation d’audit pour valider la mise en œuvre de ces fonctionnalités.
Pour plus d’informations, consultez Intégrité et sécurité de la plateforme et Sécurité de l’infrastructure Azure.
Le chiffrement des données au repos, des données en transit et des données en cours d’utilisation peut aider à satisfaire un large éventail d’exigences de souveraineté opérationnelle liées à la confidentialité des données. Cependant, les organisations qui ont besoin de ces fonctionnalités doivent planifier la création et la gestion des clés de chiffrement. Azure propose aux clients une large éventail de modèles de chiffrement des données au repos, depuis les méthodes de chiffrement côté client qui fournissent un chiffrement sans connaissance pour les données hébergées dans le cloud jusqu’aux clés gérées par le service qui offrent le plus haut degré d’interopérabilité avec les services cloud natifs.
De plus, les organisations qui souhaitent réduire le besoin de confiance dans les composants de la plateforme, tels que le système d’exploitation hôte, le noyau, l’hyperviseur et le personnel administratif, peuvent mettre en œuvre le chiffrement des données en cours d’utilisation. L’informatique confidentielle Azure comprend plusieurs services de calcul déployés dans des enclaves de sécurité basés sur le matériel qui chiffrent les données en mémoire à l’aide d’Intel Software Guard Extensions (SGX) ou d’AMD Secure Encrypted Virtualization (SEV-SNP).
Les organisations ayant des exigences de souveraineté opérationnelle qui nécessitent la mise en œuvre du chiffrement doivent se familiariser avec les fonctionnalités de chiffrement suivantes dans Azure :
- Azure Chiffrement de disque
- Azure Chiffrement du service de stockage
- Azure SQL Toujours crypté
- Coffre-fort à clés Azure
- Azure HSM géré
- Clés gérées par le client (apportez votre propre clé)
- Azure Services informatiques confidentiels
Opérations et résilience
Les exigences de sécurité opérationnelle peuvent s’appliquer à la fois aux logiciels au niveau de la plateforme créés et gérés par Microsoft pour faire fonctionner la plateforme Azure et aux logiciels gérés par le client qui font partie d’une charge de travail. Le modèle de responsabilité partagée pour le cloud computing transfère la responsabilité administrative du client au fournisseur de services cloud. Selon le type de service cloud utilisé, Microsoft peut être responsable de la gestion et de la mise à jour de l’infrastructure de base dans nos centres de données, des systèmes d’exploitation et des temps d’exécution du service. L’organisation d’ingénierie de sécurité de Microsoft met en œuvre un programme de sécurité opérationnelle qui se base sur les pratiques du cycle de vie de développement sécurisé (SDL) de Microsoft avec des pratiques de sécurité opérationnelle. Les pratiques comprennent la gestion des secrets, les tests d’intrusion et la surveillance de la sécurité, mis en œuvre par le Centre de réponse aux problèmes de sécurité Microsoft.
Dans de rares cas, Microsoft peut exiger l’accès aux données des clients pour résoudre un problème pouvant affecter les services. Les clients ayant des exigences de souveraineté opérationnelle liées au contrôle des modifications et à la gestion des accès privilégiés peuvent souhaiter activer Customer Lockbox pour Azure afin de pouvoir approuver les demandes d’accès dans le cadre des flux de travail de support de Microsoft.
De plus, les clients ayant des exigences strictes en matière d’approbation et de planification des mises à jour logicielles de la plateforme peuvent envisager d’utiliser Azure Dedicated Host, qui permet aux clients d’utiliser les configurations de maintenance pour contrôler les activités de maintenance de la plateforme au niveau de l’hôte. De plus, les clients doivent examiner leurs exigences en matière de résilience pour déterminer s’il existe des limitations basées sur la souveraineté sur les services et régions utilisés pour héberger les charges de travail.
Les exigences de souveraineté opérationnelle concernant la continuité des opérations (par exemple, exiger que les charges de travail soient déployées dans des configurations hautement disponibles pour maintenir la disponibilité) peuvent entrer en conflit avec les exigences de souveraineté des données liées à la résidence des données (par exemple, restreindre les charges de travail à une limite géographique qui n’offre pas divers emplacements).
Les organisations doivent évaluer ces exigences dès le début et réfléchir à la meilleure façon de les équilibrer.