Confidentialité des données pour l’analytique à l’échelle du cloud dans Azure

Article
10/11/2023

L’analytique à l’échelle du cloud dans Azure permet aux organisations de déterminer librement les meilleurs modèles en fonction de leurs besoins, tout en protégeant les données personnelles à plusieurs niveaux. Les données personnelles sont des données qui peuvent être utilisées pour identifier des personnes, par exemple, les numéros de permis de conduire, les numéros de sécurité sociale, les numéros de comptes bancaires, les numéros de passeport, les adresses de messagerie et bien plus encore. De nombreuses réglementations existent aujourd’hui pour protéger la confidentialité des utilisateurs.

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 les classer comme confidentielles ou moins ou sensibles (données personnelles) :

Les données peuvent être triées en éléments confidentiels ou moins si un utilisateur a accès à la ressource de données enrichie ou curée. Les utilisateurs peuvent afficher toutes les colonnes et les lignes.
Les données peuvent être classées comme sensibles (données personnelles) s’il existe des restrictions concernant les colonnes et les lignes qui sont visibles par les différents utilisateurs.

Important

Un jeu de données peut passer de confidentiel ou moins à sensible (données personnelles) lorsque les données sont combinées. Dans les situations où les données doivent être persistantes, elles doivent être copiées dans un dossier distinct qui s’aligne sur la classification de la confidentialité des données et le processus d’intégration de celles-ci.

Confidentiel ou moins

Pour chaque produit de données intégré, nous créons deux dossiers de lac de données dans les couches enrichies et organisées, de niveau confidentiel ou inférieur et sensibles (données personnelles). Nous utilisons des listes de contrôle d’accès pour activer l’authentification directe du répertoire Microsoft Azure Directory (Microsoft Entra ID).

Si une équipe d’application de données intègre une ressource de données de niveau confidentiel ou inférieur, les noms d’utilisateurs principaux et les objets du principal de service peuvent être ajoutés à deux groupes Microsoft Entra (un pour l’accès en lecture/écriture et l’autre pour l’accès en lecture seule). Ces deux groupes Microsoft Entra doivent être créés pendant le processus d’intégration et triés dans le dossier de produit de données approprié avec des conteneurs de niveau confidentiel ou inférieur pour les données brutes et enrichies.

Ce modèle active tout produit de calcul prenant en charge l’authentification directe Microsoft Entra pour se connecter au lac de données et authentifier les utilisateurs connectés. Si un utilisateur fait partie du groupe Microsoft Entra de la ressource de données, il peut accéder aux données via l’authentification directe Microsoft Entra. Cela permet à ces utilisateurs au sein du groupe de lire la totalité de la ressource de données sans filtres de stratégie. L’accès peut ensuite être audité en détail avec les journaux appropriés et Microsoft Graph.

Pour obtenir des recommandations sur la disposition de votre lac de données, consultez Provisionner trois comptes Azure Data Lake Storage Gen2 pour chaque zone d’atterrissage des données.

Remarque

Les exemples de produits de calcul sont les pools à la demande Azure Databricks, Azure Synapse Analytics, Apache Spark et Azure Synapse SQL activés avec l’authentification directe Microsoft Entra.

Données sensibles (données personnelles)

Pour les données sensibles (données personnelles), l’entreprise doit limiter ce que les utilisateurs peuvent voir par le biais d’une stratégie, de copies de données ou d’un calcul. Dans ce cas, l’organisation doit envisager de déplacer ou d’injecter le contrôle d’accès dans la couche de calcul. Il existe quatre options pour l’approche de la sécurisation des données dans l’analytique à l’échelle du cloud.

Exemple de scénario

L’exemple suivant décrit les options de sécurisation sensible (données personnelles) :

Une application de données ingère un produit de données personnelles liées aux ressources humaines pour l’Amérique du Nord et l’Europe. Le cas d’usage nécessite que les utilisateurs européens voient uniquement les enregistrements de personnel européen et les utilisateurs nord-américains pour voir uniquement les enregistrements de personnel nord-américain. Il est encore plus restreint, de sorte que seuls les responsables RH voient les colonnes contenant des données liées aux salaires.

Option 1 : moteur de stratégie (recommandé)

Les deux premières options offrent un moyen de gérer les données sensibles (données personnelles) . Elles accordent également le contrôle aux opérations d’intégration et aux équipes de produits de données pour identifier et restreindre l’accès. Cela peut être suffisant pour une plateforme d’analyse à petite échelle, mais un moteur de stratégie doit être placé dans la zone d’atterrissage de la gestion des données pour une grande entreprise avec des centaines de produits de données. Les moteurs de stratégie offrent un moyen central de gérer, de sécuriser et de contrôler :

Accès aux données
Gestion du 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

En règle générale, un moteur de stratégie s’intègre à un catalogue de données comme Azure Purview. La Place de marché Azure propose des solutions de fournisseurs tiers, et certains fournisseurs travaillent avec Azure Synapse et Azure Databricks pour chiffrer et déchiffrer les informations tout en fournissant également une sécurité au niveau des lignes et des colonnes. À compter de janvier 2022, Azure Purview a lancé une préversion publique des stratégies d’accès pour contrôler l’accès aux données stockées dans Blob et Azure Data Lake Storage (ADLS) Gen2. Consultez Provisionnement de jeu de données par le propriétaire des données pour le service Stockage Azure (préversion).

Le moteur de stratégie doit utiliser des groupes Microsoft Entra pour appliquer des stratégies aux produits de données. L’attente d’une solution de stratégie qui garantit la confidentialité des données consiste à utiliser des jetons pour les données sensibles (données personnelles) et à toujours vérifier le contrôle d’accès aux attributs afin que l’utilisateur puisse supprimer les jetons pour les colonnes auxquelles il a besoin d’accéder.

Comme nous l’avons vu, pour qu’un moteur de stratégie soit une réussite, il est important qu’il s’intègre au catalogue de données et que DevOps utilise une API REST pour intégrer un nouveau jeu de données. À mesure que les équipes d’application de données créent des sources de données en lecture, elles sont inscrites dans le catalogue de données et permettent d’identifier les données sensibles (données personnelles). Le moteur de stratégie doit importer la définition et refuser tout accès aux données jusqu’à ce que les équipes aient configuré leurs stratégies d’accès. Tout cela doit être effectué via un workflow d’API REST à partir de la solution de gestion des services informatiques.

Option 2 : versions de niveau confidentiel ou inférieur et de niveau sensible (données personnelles)

Pour chaque produit de données classifiées comme étant sensibles (données personnelles), deux copies sont créées par le pipeline. L’une des copies est classifiée au niveau confidentiel ou inférieur dans laquelle toutes les colonnes sensibles (données personnelles) sont supprimées et est créée dans le dossier confidentiel ou inférieur pour le produit de données. L’autre copie est créée dans le dossier sensible (données personnelles), pour le produit de données qui contient toutes les données sensibles. Un groupe de sécurité Lecture Microsoft Entra et un groupe de sécurité Écriture est attribué à chaque dossier. Un utilisateur peut demander l’accès à un produit de données via la Gestion de l’accès aux données.

Bien que cette opération s’exécute en séparant les données sensibles (données personnelles) et confidentielles ou inférieures, un utilisateur autorisé à accéder aux données sensibles (données personnelles) via l’authentification directe Active Directory est en mesure d’interroger toutes les lignes. Si vous avez besoin d’une sécurité au niveau des lignes, vous devez utiliser l’option 1 : moteur de stratégie (recommandé) ou l’option 3 : Azure SQL Database, SQL Managed Instance ou pools SQL Azure Synapse Analytics.

Option 3 : Azure SQL Database, Azure SQL Managed Instance ou pools SQL Azure Synapse Analytics

Une application de données utilise des pools SQL Database, SQL Managed Instance ou Azure Synapse Analytics SQL pour charger les produits de données dans une base de données qui prend en charge la sécurité au niveau des lignes, la sécurité au niveau des colonnes et le masquage dynamique des données. Les équipes d’applications de données créent différents groupes Microsoft Entra et attribuent des autorisations qui prennent en charge la sensibilité des données.

Pour le cas d’usage de ce scénario, les équipes d’application de données doivent créer les quatre groupes Microsoft Entra suivants avec 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 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 consiste à ajouter la sécurité au niveau des colonnes pour empêcher les responsables non RH de voir les salaires et la sécurité au niveau des lignes pour limiter les lignes que les membres de l’équipe européenne et nord-américaine peuvent voir.

En plus du chiffrement transparent des données, la couche de sécurité consiste à chiffrer la colonne de données et à la déchiffrer lors de la lecture.

Les tables peuvent être mises à disposition d’Azure Databricks avec le connecteur Apache Spark : SQL Server et Azure SQL Database.

Option 4 : Azure Databricks

La quatrième option consiste à utiliser Azure Databricks pour explorer les données sensibles (données personnelles). L’utilisation d’une combinaison de bibliothèques de chiffrement Fernet, de fonctions définies par l’utilisateur, de secrets Databricks, de contrôle d’accès de tables et de fonctions d’affichage dynamique permet de chiffrer et de déchiffrer des colonnes.

En tant que billet de blog, Appliquer un chiffrement au niveau des colonnes et éviter la duplication des données, décrit :

La première étape de ce processus consiste à protéger les données en les chiffrant lors de l’ingestion et la bibliothèque Fernet Python constitue une solution possible. Fernet utilise le chiffrement symétrique, qui est généré avec plusieurs primitives de chiffrement standard. Cette bibliothèque est utilisée dans une fonction définie par l’utilisateur du chiffrement qui nous permettra de chiffrer une colonne donnée dans un tableau de données. Pour stocker la clé de chiffrement, nous utilisons des secrets Databricks avec des contrôles d’accès en place pour autoriser uniquement notre processus d’ingestion de données à y accéder. Une fois les données écrites dans nos tables delta Lake, les colonnes de données personnelles contenant des valeurs telles que le numéro de sécurité sociale, le numéro de téléphone, le numéro de carte de crédit et d’autres identificateurs sont impossibles pour un utilisateur non autorisé à lire.

Une fois que vous avez écrit et protégé les données sensibles, vous devez disposer d’un moyen pour les utilisateurs privilégiés de lire les données sensibles. La première chose à faire est de créer une fonction UDF permanente à ajouter à l’instance Hive s’exécutant sur Databricks. Pour qu’une fonction UDF soit permanente, elle doit être écrite en Scala. Heureusement, Fernet dispose également une implémentation de Scala que vous pouvez utiliser pour vos lectures déchiffrées. Cette fonction FDU accède également au secret utilisé dans l’écriture chiffrée pour effectuer le déchiffrement, et, dans ce cas, elle est ajoutée à la configuration Spark du cluster. Cela nous oblige à ajouter des contrôles d’accès de cluster pour les utilisateurs disposant ou non de privilèges afin de contrôler leur accès à la clé. Une fois la fonction UDF définie par l’utilisateur créée, nous pouvons l’utiliser dans nos définitions de vue pour les utilisateurs privilégiés afin de voir les données déchiffrées.

Avec les fonctions d’affichage dynamique, vous ne pouvez créer qu’une seule vue et retourner les valeurs chiffrées ou déchiffrées en fonction du groupe Databricks auquel elles appartiennent.

Dans l’exemple précédent, vous créez deux fonctions d’affichage dynamique, une pour l’Amérique du Nord et une autre pour l’Europe, et implémentez les techniques de chiffrement dans ce notebook.

Affichage de l’Amérique du Nord :

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_us AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-AMERICA-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='US'

Affichage de l’Europe :

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_eu AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-EUROPE-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='EU'

Pour que cela fonctionne, vous devez activer le contrôle d’accès à la table Azure Databricks dans l’espace de travail et appliquer les autorisations suivantes :

Accordez aux groupes Microsoft Entra DA-AMERICA-HRMANAGER-R et DA-AMERICA-HRGENERAL-R un accès à l’affichage vhr_us.
Accordez aux groupes Microsoft Entra DA-EUROPE-HRMANAGER-R et DA-EUROPE-HRGENERAL-R un accès à l’affichage vhr_eu.

Étant donné que les colonnes sont chiffrées et ne peuvent pas être déchiffrées dans l’espace de travail de niveau confidentiel ou inférieur, les espaces de travail confidentiels ou inférieurs peuvent toujours utiliser l’authentification directe Microsoft Entra et permettre aux utilisateurs d’explorer le lac en fonction de leurs autorisations.

Lorsque l’accès à la table est utilisé, les équipes qui requièrent l’accès sont ajoutées à l’espace de travail Azure Databricks. Azure Databricks utiliserait des principaux de service pour le mappage à Azure Data Lake Storage, mais les données seraient sécurisées avec le contrôle d’accès à la table Azure Databricks.

À mesure que de nouveaux produits de données sont déployés, une partie du processus DevOps doit exécuter des scripts pour configurer les autorisations de table dans l’espace de travail Azure Databricks et ajouter les groupes Microsoft Entra appropriés à ces autorisations.

Remarque

Le contrôle d’accès à la table Azure Databricks ne peut pas être combiné à l’authentification directe Microsoft Entra. Par conséquent, vous ne pouvez utiliser qu’un seul espace de travail Azure Databricks et utiliser le contrôle d’accès à la table à la place.

Données restreintes

En plus d’implémenter des options pour les données confidentielles ou restreintes, nous vous recommandons également d’héberger les données hautement confidentielles dans une zone d’atterrissage des données et une zone d’atterrissage de gestion des données dédiées.

Il permet des exigences spécifiques telles que l’accès juste-à-temps, les clés gérées par le client pour le chiffrement et les restrictions entrantes ou sortantes appliquées à la zone d’atterrissage. L’aide a évalué le stockage des données de ce type dans la même zone d’atterrissage de données, mais avec des comptes de stockage différents. Toutefois, cela peut compliquer la solution au niveau de la couche de mise en réseau, par exemple, avec des groupes de sécurité réseau et autres.

La zone d’atterrissage de gestion des données « restreinte » dédiée doit se connecter pour cataloguer les données dans la zone d’atterrissage des données « restreinte ». Elle doit limiter les personnes pouvant rechercher ces données dans le catalogue.

Étapes suivantes

Gestion de l’accès aux données

Partager via