Confidentialité des données pour l’analytique à l’échelle du cloud dans Azure
L’analytique à l’échelle du cloud vous aide à déterminer les modèles d’accès aux données optimaux qui répondent à vos besoins tout en protégeant les données personnelles à plusieurs niveaux. Les données personnelles incluent toutes les informations qui peuvent identifier de manière unique les personnes, par exemple les numéros de permis de conduire, les numéros de sécurité sociale, les détails du compte bancaire, les numéros de passeport et les adresses e-mail. De nombreuses réglementations existent pour protéger la confidentialité des utilisateurs.
Pour protéger la confidentialité des données dans un environnement cloud tel qu’Azure, vous pouvez 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 comment autoriser l’accès aux données et spécifier les lignes ou colonnes auxquelles les utilisateurs peuvent accéder.
Créer un schéma de classification de 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 classer les données comme confidentielles ou inférieures ou données personnelles sensibles:
- Triez les données en données confidentielles ou inférieures si vous n’avez pas besoin de restreindre les colonnes et lignes que les utilisateurs peuvent afficher.
- Triez les données en données personnelles sensibles si vous devez restreindre les colonnes et lignes que les utilisateurs peuvent afficher.
Important
Un jeu de données peut passer de confidentiel ou inférieur à des données personnelles sensibles lorsque vous combinez des données avec d’autres produits de données ayant précédemment une classification inférieure. Si vous avez besoin de données persistantes, déplacez-la vers un dossier désigné qui s’aligne sur son niveau de confidentialité et le processus d’intégration.
Créer un ensemble de politiques Azure
Après avoir classé vos données, vous devez aligner la classification avec les exigences de votre stratégie du secteur et les stratégies d’entreprise internes. Vous souhaitez créer un jeu de stratégies Azure qui régit l’infrastructure à déployer, l’emplacement où elle peut être déployée et les normes de mise en réseau et de chiffrement.
Pour les secteurs réglementés, vous pouvez utiliser Microsoft initiatives de stratégie de conformité réglementaire comme base de référence pour les infrastructures de conformité.
La classification des données suit les mêmes règles pour le chiffrement, les références SKU d’infrastructure autorisées et les initiatives de stratégie. Vous pouvez donc stocker toutes les données dans la même zone d’atterrissage.
Pour les données restreintes, vous devez héberger des 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 plus élevé de conditions requises pour l’infrastructure. Par exemple, vous pouvez définir des clés gérées par le client pour le chiffrement ou les restrictions entrantes ou sortantes pour la zone d’atterrissage.
Remarque
Vous pouvez placer des données personnelles sensibles et des données confidentielles ou inférieures dans la même zone d’atterrissage de données, mais des comptes de stockage différents. Toutefois, cette pratique peut compliquer la solution sur la couche réseau, par exemple avec des groupes de sécurité réseau.
Une solution de gouvernance des données déployée doit limiter les utilisateurs pouvant rechercher des données restreintes dans le catalogue. Envisagez d’implémenter l’accès conditionnel Microsoft Entra ID pour toutes les ressources et services de données. Pour améliorer la sécurité, appliquez un accès juste-à-temps aux données restreintes.
Prendre en compte les exigences de chiffrement
En plus de définir des stratégies pour les emplacements et les services Azure autorisés, tenez compte des exigences de chiffrement pour chaque classification des données. Tenez compte des conditions requises pour les domaines suivants :
- Gestion des clés
- Stockage de clés
- Chiffrement de données au repos
- Chiffrement de données en transit
- Chiffrement des données en cours d’utilisation
Pour la gestion des clés, vous pouvez utiliser des clés de chiffrement gérées par la plateforme ou gérées par le client. Pour plus d’informations, consultez Vue d’ensemble de la gestion des clés dans Azure et Comment choisir la solution de gestion des clés appropriée.
Pour plus d’informations sur les options de chiffrement, consultez Chiffrement Des Données Azure "au repos" et Modèles De Chiffrement De Données.
Vous pouvez utiliser le protocole de sécurité de la couche de transport (TLS) pour protéger les données qui 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 nécessite que les données restent chiffrées pendant l’utilisation, le modèle de menace Azure Confidential Computing permet de réduire la confiance. Cela réduit la possibilité que les opérateurs de fournisseur de cloud ou d’autres acteurs du domaine du locataire puissent accéder au code et aux données pendant l’implémentation.
Pour plus d’informations, consultez produits d’informatique confidentielle Azure.
Implémenter la gouvernance des données
Après avoir défini les stratégies pour le déploiement des services Azure autorisés, déterminez comment accorder 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 créer des ressources de données ou des produits pour des couches de lac de données enrichies et organisées. Veillez à définir les autorisations dans le catalogue de données pour sécuriser ces objets de données.
Utilisez Microsoft Purview pour gérer, sécuriser et contrôler de manière centralisée les domaines suivants :
- 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
- 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 l’utilisation de Microsoft Purview pour gérer l’accès en lecture ou en modification, consultez Concepts pour les stratégies de propriétaire de données Microsoft Purview.
Que vous décidez d’implémenter Microsoft Purview ou une autre solution de gouvernance des données, utilisez des groupes d’ID Microsoft Entra pour appliquer des stratégies aux produits de données.
Utilisez l’API REST de la solution de gouvernance des données pour intégrer un nouveau jeu de données. Vos équipes d’application de données créent des produits de données et les inscrivent dans la solution de gouvernance des données pour vous aider à identifier les données sensibles. La solution de gouvernance des données importe la définition et refuse tout accès aux données jusqu’à ce que vos équipes configurent ses stratégies d’accès.
Utiliser des modèles de protection des données
Pour protéger les données sensibles, choisissez un modèle de protection des données en fonction des données, des services et des stratégies que vous implémentez.
Copies multiples
Le pipeline crée deux copies pour chaque produit de données disposant d’une classification de données personnelles sensibles. Le pipeline classe la première comme confidentielle ou à un niveau inférieur. Cette copie n’inclut pas les colonnes sensibles de données personnelles. Elle est créée dans le dossier confidentiel ou inférieur du produit de données. L’autre copie est créée dans le dossier de données personnelles sensibles. Cette copie inclut 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 vous utilisez Microsoft Purview, vous pouvez inscrire les deux versions du produit de données et utiliser des stratégies pour sécuriser les données.
Le modèle de copie multiple sépare les données personnelles sensibles et les données confidentielles ou inférieures. Toutefois, si vous accordez à un utilisateur l’accès aux données personnelles sensibles, il peut interroger toutes les lignes. Votre organisation peut avoir besoin d’autres solutions qui fournissent 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 que les utilisateurs peuvent afficher, vous pouvez déplacer vos données dans une solution de calcul qui utilise la sécurité au niveau des lignes.
Pour empêcher la ré-ingénierie, sélectionnez le service Azure approprié ou la solution Microsoft Fabric pour votre cas d’usage particulier. Différents types de bases de données sont conçus à des fins différentes. Par exemple, vous ne devez pas utiliser une base de données OLTP (Online Transaction Processing) pour une analytique étendue. Et si vous utilisez une application de commerce électronique, vous ne devez pas utiliser une solution adaptée à l’analytique Big Data, car elle ne peut pas atteindre les temps de réponse de millisecondes requis.
Si vous implémentez des solutions qui prennent en charge la sécurité au niveau des lignes, vos équipes d’applications de données doivent créer différents groupes d’ID Microsoft Entra et attribuer des autorisations en fonction de la sensibilité des données.
Outre la sécurité au niveau des lignes, vous pouvez restreindre l’accès à certaines colonnes. Le tableau suivant présente un exemple de quatre groupes d’ID Microsoft Entra qui ont un accès en lecture seule :
| Groupe | Autorisation |
|---|---|
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 prend en charge le masquage dynamique des données, qui masque les données sensibles des utilisateurs qui n’ont pas de privilèges. Vous pouvez utiliser une API REST pour intégrer cette approche à l’intégration d’un jeu de données.
Le deuxième niveau de restriction ajoute une sécurité au niveau des colonnes pour empêcher les gestionnaires non RH de voir les salaires. Le pipeline ajoute également une sécurité au niveau ligne pour restreindre les lignes que les membres des équipes européenne et nord-américaine peuvent consulter.
Chiffrement de colonne
Le masquage dynamique des données masque les données au moment de la présentation, mais certains cas d’usage nécessitent que la solution n’ait jamais accès aux données en texte clair.
La fonctionnalité SQL Always Encrypted améliore la sécurité des données sensibles dans les bases de données SQL Server. SQL Always Encrypted permet de s’assurer que les données sensibles dans les bases de données SQL Server restent sécurisées et protégées contre l’accès non autorisé. Cette fonctionnalité chiffre les données au repos et en transit, ce qui permet de maintenir la confidentialité maximale des données et la conformité réglementaire. SQL Always Encrypted effectue des opérations de chiffrement et de déchiffrement côté client. Intégrez cette fonctionnalité pour protéger vos ressources de données les plus précieuses.