Confidentialité des données pour l’analytique à l’échelle du cloud dans Azure
L’analytique à l’échelle du cloud permet aux organisations de déterminer les modèles d’accès aux données optimaux adaptés à leurs besoins tout en protégeant les données personnelles à plusieurs niveaux. Les données personnelles incluent toute information pouvant identifier de manière unique des individus, par exemple, les numéros de permis de conduire, les numéros de sécurité sociale, les détails des comptes bancaires, les numéros de passeport, les adresses email, et plus encore. De nombreuses réglementations existent aujourd’hui pour protéger la confidentialité des utilisateurs.
Pour protéger la confidentialité des données dans un environnement cloud tel qu’Azure, vous pouvez commencer par créer un schéma de confidentialité des données qui spécifie des stratégies d’accès aux données. Ces stratégies peuvent définir l’architecture sous-jacente sur laquelle réside l’application de données, définir la façon dont l’accès aux données est autorisé et spécifier les lignes ou colonnes accessibles après son octroi.
Créer un schéma de classification de la confidentialité des données
| Classification | Description |
|---|---|
| Public | Tous les utilisateurs peuvent accéder aux données. Elles peuvent être envoyées à tout le monde. Par exemple, des données gouvernementales publiques. |
| À usage interne uniquement | Seuls les employés peuvent accéder aux données. Elles ne peuvent pas être envoyées à des personnes hors de l’entreprise. |
| Confidentiel | Les données peuvent être partagées uniquement si elles sont nécessaires pour une tâche spécifique. Les données ne peuvent pas être envoyées à des personnes hors de l’entreprise sans accord de confidentialité. |
| Sensible (données personnelles) | Les données contiennent des informations privées qui doivent être masquées et partagées uniquement quand cela est nécessaire et pour une durée limitée. Les données ne peuvent pas être envoyées au personnel non autorisé ni à des personnes externes à l’entreprise. |
| Limitées | Les données peuvent être partagées uniquement avec des personnes nommées qui sont responsables de leur protection. Par exemple, des documents juridiques ou des secrets commerciaux. |
Avant d’ingérer des données, vous devez catégoriser les données comme étant confidentielles ou moins ou sensibles (données personnelles) :
- Les données peuvent être triées en confidentielles ou inférieures à s’il n’existe aucune restriction sur les colonnes et les lignes visibles par différents utilisateurs.
- Les données peuvent être triées en sensibles (données personnelles) s’il existe des restrictions sur les colonnes et les lignes visibles par différents utilisateurs.
Important
Un jeu de données peut passer de confidentiel ou moins à sensible (données personnelles) lorsque des données sont combinées avec d’autres produits de données ayant précédemment une classification inférieure. Lorsque les données doivent être persistantes, elles doivent être déplacées vers un dossier désigné correspondant à leur niveau de confidentialité et au processus d’intégration.
Créer un ensemble de politiques Azure
Une fois que vous avez mappé votre classification des données, vous devez aligner la classification avec vos exigences de stratégie du secteur et vos stratégies d’entreprise internes. Cette étape vous aide à créer un ensemble de politiques Azure qui régit quelle infrastructure peut être déployée, l’emplacement où elle peut être déployée, et précise les normes de mise en réseau et de chiffrement.
Pour les industries réglementées, Microsoft a développé de nombreuses initiatives de politiques de conformité réglementaire qui agissent comme une base pour les cadres de conformité.
Pour la classification des données, qui suit les mêmes règles de chiffrement, les types d'infrastructure autorisés, et les initiatives politiques, les données peuvent se trouver dans la même "zone d'atterrissage".
Pour les données restreintes, nous recommandons d’héberger les données dans une zone d’atterrissage de données dédiée sous un groupe d’administration où vous pouvez définir un ensemble de critères plus élevés pour l’infrastructure, tels que des clés gérées par le client pour le chiffrement, et des restrictions d’entrée ou de sortie appliquées à la zone d’atterrissage.
Remarque
Les recommandations ont évalué la mise des données sensibles (données personnelles) et confidentielles ou moins dans la même zone d’atterrissage de données mais dans des comptes de stockage différents. Cependant, cela pourrait compliquer la solution au niveau de la couche réseau, par exemple avec les groupes de sécurité réseau.
Toute solution de gouvernance des données déployée doit limiter qui peut rechercher des données restreintes dans le catalogue.
Vous devez également envisager de mettre en œuvre l’accès conditionnel Microsoft Entra ID pour tous les actifs et services de données, ainsi que l’accès juste-à-temps pour les données restreintes afin d’améliorer la sécurité.
Chiffrement
En plus de définir des politiques pour l’emplacement et les services Azure autorisés, vous devez considérer les exigences de chiffrement pour chacune des classifications de données.
- Quelles sont vos exigences pour la gestion des clés ?
- Quelles sont vos exigences pour le stockage de ces clés ?
- Quelles sont vos exigences, par classification, pour le chiffrement des données au repos ?
- Quelles sont vos exigences, par classification, pour le chiffrement des données en transit ?
- Quelles sont vos exigences, par classification, pour le chiffrement des données en cours d’utilisation ?
Pour la gestion des clés, les clés de chiffrement peuvent être gérées par la plateforme ou par le client. Microsoft a documenté la gestion des clés dans Azure pour vous aider à choisir une solution de gestion des clés. Pour plus d’informations, veuillez consulter la section Vue d’ensemble de la gestion des clés dans Azure et Comment choisir la bonne solution de gestion des clés.
Microsoft a publié une documentation expliquant le chiffrement des données au repos dans Azure et les modèles de chiffrement des données qui vous aident à comprendre les options de chiffrement disponibles.
Microsoft offre aux clients la possibilité d’utiliser le protocole TLS (Transport Layer Security) pour protéger les données lorsqu’elles transitent entre les services cloud et les clients. Pour plus d’informations, veuillez consulter la section Chiffrement des données en transit.
Si votre scénario exige que les données restent chiffrées en cours d’utilisation, le modèle de menace Azure Confidential Computing vise à minimiser la confiance ou à éliminer la possibilité pour un opérateur de fournisseur cloud ou d’autres acteurs dans le domaine du locataire d’accéder au code et aux données pendant l’exécution.
Pour les dernières offres de calcul confidentiel Azure, veuillez consulter la section Produits de calcul confidentiel Azure.
Gouvernance des données
Après avoir défini les stratégies pour le déploiement des services Azure autorisés, vous devez décider de la façon dont vous accordez l’accès au produit de données.
Si vous avez une solution de gouvernance des données telle que Microsoft Purview ou Azure Databricks Unity Catalog, vous pouvez alors créer des actifs/produits de données pour des couches de lacs de données enrichies et organisées. Assurez-vous de définir les autorisations dans le catalogue de données pour sécuriser ces objets de données.
Microsoft Purview fournit un moyen central de gestion, de sécurisation et de contrôle :
- Accès aux données
- Cycle de vie des données
- Stratégies et réglementations internes et externes
- Stratégies de partage de données
- Identification des données sensibles (données personnelles)
- Informations sur la protection et la conformité
- Stratégies pour la création de rapports de protection des données
Pour plus d’informations sur la gestion des accès en lecture ou en modification avec Microsoft Purview, veuillez consulter la section Concepts des politiques de propriétaires de données Microsoft Purview.
Que vous décidez d’implémenter Microsoft Purview ou une autre solution de gouvernance des données, il est essentiel d’utiliser des groupes d’ID Microsoft Entra pour appliquer des stratégies aux produits de données.
Il est important d’utiliser l’API REST des solutions de gouvernance des données pour intégrer un nouveau jeu de données. Les équipes d’applications de données créent des produits de données et les enregistrent dans la solution de gouvernance des données pour aider à identifier les données sensibles (données personnelles). La solution de gouvernance des données importe la définition et refuse tout accès aux données jusqu’à ce que les équipes mettent en place ses politiques d’accès.
Utiliser des modèles pour protéger les données sensibles
Il existe plusieurs modèles qui peuvent être adoptés en fonction des données, des services et des stratégies que vous devez implémenter pour la protection des données sensibles.
Copies multiples
Pour chaque produit de données classé comme sensibles (données personnelles), deux copies sont créées par son pipeline. La première copie est classée comme confidentielle ou moins. Cette copie a toutes les colonnes de données sensibles (données personnelles) supprimées et est créée sous le dossier confidentiel ou moins pour le produit de données. L’autre copie est créée dans le dossier données sensibles (données personnelles) et inclut toutes les données sensibles. Chaque dossier est attribué à un groupe de sécurité Microsoft Entra ID lecteur et à un groupe de sécurité Microsoft Entra ID writer.
Si Microsoft Purview est utilisé, vous pouvez enregistrer les deux versions du produit de données et utiliser des politiques pour sécuriser les données.
Ce processus sépare les données sensibles (données personnelles) et les données confidentielles ou moins, mais un utilisateur à qui l’accès aux données sensibles (données personnelles) est accordé pourra interroger toutes les lignes. Votre organisation pourrait devoir envisager d’autres solutions offrant une sécurité au niveau des lignes pour filtrer les lignes.
Sécurité au niveau des lignes et des colonnes
Si vous devez filtrer les lignes visibles par les utilisateurs, vous pouvez déplacer vos données vers une solution de calcul qui utilise la sécurité au niveau des lignes.
Sélectionner le service Azure approprié ou la solution Microsoft Fabric pour votre cas d’utilisation particulier est essentiel pour éviter une réingénierie. Une base de données OLTP est inadaptée à une analyse poussée, tout comme une solution conçue pour l’analytique big data ne peut atteindre les temps de réponse en millisecondes requis par une application de commerce électronique.
Pour travailler avec des solutions prenant en charge la sécurité au niveau des lignes, les équipes d’applications de données créent différents groupes Microsoft Entra ID et assignent des autorisations en fonction de la sensibilité des données.
Prenons l’exemple d’un scénario où, en plus de la sécurité au niveau des lignes, il est nécessaire de restreindre l’accès à certaines colonnes. Les équipes d’applications de données ont créé les quatre groupes Microsoft Entra ID avec un accès en lecture seule comme montré dans le tableau suivant :
| Groupe | Permission |
|---|---|
DA-AMERICA-HRMANAGER-R |
Affichez la ressource de données de personnel RH d’Amérique du Nord avec des informations sur les salaires. |
DA-AMERICA-HRGENERAL-R |
Affichez la ressource de données de personnel RH d’Amérique du Nord sans informations sur les salaires. |
DA-EUROPE-HRMANAGER-R |
Affichez la ressource de données de personnel RH d’Europe avec des informations sur les salaires. |
DA-EUROPE-HRGENERAL-R |
Affichez la ressource de données de personnel RH d’Europe sans informations sur les salaires. |
Le premier niveau de restrictions prendrait en charge le masquage des données dynamiques, qui masque les données sensibles des utilisateurs sans privilèges. L’un des avantages de cette approche est qu’elle peut être intégrée à l’intégration d’un jeu de données à l’aide d’une API REST.
Le deuxième niveau de restrictions consiste à ajouter une sécurité au niveau des colonnes pour restreindre l’accès des managers non-RH aux salaires, et une sécurité au niveau des lignes pour restreindre les lignes que les membres des équipes européennes et nord-américaines peuvent consulter.
Chiffrement de colonne
Bien que le masquage dynamique des données masque les données au moment de l’affichage, certains cas d’utilisation exigent que la solution n’ait jamais accès aux données en texte clair.
SQL Always Encrypted est une fonctionnalité puissante introduite par Microsoft qui renforce la sécurité des données sensibles stockées dans les bases de données SQL Server. SQL Always Encrypted garantit que les données sensibles stockées dans les bases de données SQL Server restent sécurisées et protégées contre tout accès non autorisé. Cette fonctionnalité aide à maintenir une confidentialité maximale des données et une conformité réglementaire en chiffrant les données à la fois au repos et en transit.
En effectuant les opérations de chiffrement et de déchiffrement côté client, Always Encrypted garantit que les données sensibles restent protégées contre tout accès non autorisé. Sa facilité d’intégration et ses avantages en matière de conformité en font un outil essentiel pour les organisations cherchant à protéger leurs actifs de données les plus précieux.