Gouvernance des données dans une plateforme de données unifiée

Cet article aide les décideurs à établir la gouvernance des données au sein de l’organisation.

Les organisations doivent définir des exigences communes en matière de gouvernance des données, que chaque domaine de données applique aux données dont il est responsable. La gouvernance cohérente permet à l’organisation d’utiliser des données avec confiance et de gérer les risques métier ou réglementaires, quel que soit l’emplacement des données. Cet article fournit des conseils pour établir ces exigences et les appliquer de manière cohérente dans votre organisation.

Architecture et arbre de décision

1. Inventaire des données

Comment comprendre les données que nous avons ? L’organisation doit établir Microsoft Purview comme système de gouvernance commun pour les métadonnées de données d’entreprise. Microsoft Purview Data Map fournit l’inventaire technique et Catalogue unifié Microsoft Purview aide les utilisateurs à découvrir les données. Ces fonctionnalités stockent les métadonnées. Ils ne copient pas les données sous-jacentes et n’y donnent pas accès.

L’organisation doit établir une stratégie d’inventaire des données qui définit les données qui doivent être repérables via Microsoft Purview et l’ordre dans lequel des données supplémentaires entrent dans l’inventaire. La couverture technique complète ne doit pas être l’objectif initial, sauf si une obligation légale ou réglementaire l’exige.

• Couverture prioritaire : La première limite d’inventaire doit inclure des données qui prennent en charge les processus métier critiques ou les rapports d’entreprise. Il doit également inclure les données utilisées par les solutions IA où la provenance ou l’utilisation autorisée affecte les risques.

• Données Microsoft 365 : Le contenu Microsoft 365 doit être inclus lorsque des documents ou des communications contiennent des informations qui se trouvent dans l’étendue de gouvernance de l’organisation. Consultez les guides de configuration de Microsoft Purview.

• Microsoft Fabric : inscrivez le locataire Fabric et analysez-le afin d’intégrer les métadonnées et les informations de traçabilité prises en charge de Fabric dans Microsoft Purview. Consultez Inscrire et analyser Microsoft Fabric.

• Données multiclouds, SaaS et locales : l’analyse basée sur le connecteur est requise pour les données stockées dans Azure, Microsoft Dataverse, des systèmes locaux et d’autres clouds (AWS, Google Cloud, Oracle). L’organisation doit inscrire des sources prises en charge lorsque la visibilité des métadonnées centrales offre un avantage de gouvernance clair. Cet avantage peut notamment prendre la forme de preuves de conformité réglementaire ou de la possibilité de découvrir des données sur plusieurs plateformes. Les sources non prises en charge ou de faible priorité doivent rester enregistrées dans l’étendue de gouvernance avec un propriétaire identifié et un traitement planifié. Consultez Bonnes pratiques d’analyse de Data Map. Consultez Catalogue unifié de Microsoft Purview et Data Map.

2. Signification métier partagée

Comment garantir la cohérence de nos définitions de données ? L’organisation doit normaliser les concepts métier lorsque la signification incohérente affecterait les décisions entre les domaines de données. Il ne doit pas tenter de créer une définition pour chaque concept local.

• Concepts à l’échelle de l’organisation : les concepts doivent avoir une définition à l’échelle de l’organisation lorsque plusieurs domaines de données dépendent de la même signification pour la création de rapports ou l’IA. Hiérarchiser les concepts dans lesquels les définitions incohérentes affectent déjà les décisions d’entreprise. Chaque concept partagé doit avoir une définition approuvée et un propriétaire d’entreprise responsable. La définition doit identifier une variation acceptable dans laquelle les contextes métier diffèrent légitimement.

• Concepts spécifiques au domaine de données : les domaines de données doivent conserver l’autorité sur les concepts qui ne nécessitent pas une signification cohérente en dehors de leur domaine de données. Ces concepts doivent devenir des concepts à l’échelle de l’organisation uniquement lorsque l’utilisation inter-domaines crée un besoin de signification partagée.

• Gouvernance du glossaire : les définitions approuvées doivent être publiées via Catalogue unifié Microsoft Purview afin que les utilisateurs puissent découvrir la signification associée aux données régies. Les domaines de gouvernance peuvent organiser les termes du glossaire et les connecter à des produits de données ou des ressources de données pertinents. Consultez Termes du glossaire dans le catalogue unifié.

3. Conformité

Comment devons-nous respecter nos obligations de conformité des données ? L’organisation doit traduire des obligations légales et contractuelles en exigences de données avant de sélectionner des contrôles techniques. Gestionnaire de conformité Microsoft Purview peut aider à évaluer les contrôles et à organiser le travail d’amélioration.

3.1 Exigences de conformité

Comment devons-nous établir des exigences de conformité ? L’organisation doit établir un processus permettant de traduire les exigences légales applicables et les obligations contractuelles en exigences de gouvernance des données.

• Responsabilités : les autorités juridiques ou chargées de la conformité doivent déterminer les obligations applicables. Les domaines de données doivent identifier les données affectées. Les équipes de sécurité doivent déterminer la façon dont les exigences approuvées se traduisent en contrôles techniques.

• Documentation : l’organisation doit conserver ces exigences dans un registre central. Chaque exigence doit identifier son autorité responsable et les données affectées. Il doit également définir la preuve requise et la fréquence d’examen.

• Outillage : les évaluations de Gestionnaire de conformité Microsoft Purview doivent aider à identifier les lacunes de contrôle et à organiser le travail d’amélioration. Un score de conformité doit servir d’indicateur de gestion. Il ne doit pas être considéré comme une preuve que l’organisation satisfait à une obligation légale. Consultez les évaluations Purview.

3.2 Suivi de la conformité des données

Comment surveiller la conformité des données ? L’organisation doit établir des exigences de surveillance et d’escalade en fonction des risques réglementaires et métier. Les exigences ayant un plus grand impact potentiel devraient faire l’objet d’une surveillance et de mesures correctives renforcées. La surveillance doit fournir des preuves que les équipes responsables peuvent utiliser pour identifier les lacunes importantes en matière de conformité et suivre leur résolution.

• Outils : le Gestionnaire de conformité Microsoft Purview peut fournir des évaluations et des actions d’amélioration pour les exigences prises en charge. Les décideurs doivent utiliser ces informations pour surveiller la posture de conformité et les lacunes de contrôle non résolues. Elles ne doivent pas considérer le score de conformité comme une preuve de conformité effective. Consultez Compliance Manager et Multicloud .

• Preuve de conformité : l’organisation doit conserver les preuves nécessaires pour démontrer que les contrôles requis fonctionnent comme prévu. Les exigences en matière de preuve et les périodes de rétention doivent suivre l’obligation documentée dans le registre de conformité.

3.3. Lignage des données

Comment suivre l’historique des données ? L’organisation doit exiger la traçabilité des données lorsque la compréhension de leur origine ou de leurs transformations contribue au respect d’une exigence organisationnelle importante. La traçabilité ne doit pas devenir un objectif pour documenter chaque déplacement de données.

• Couverture de traçabilité : les domaines de données doivent capturer suffisamment de traçabilité pour les produits de données importants afin de prendre en charge les décisions de gouvernance requises.

• Traçabilité dans les systèmes sources : elle doit être exigée lorsque l’organisation doit démontrer l’origine de données importantes ou remonter à une source faisant autorité pour examiner des problèmes.

• Traçabilité dans la couche de consommation : une plateforme telle que Fabric peut constituer la limite centralisée de traçabilité lorsque les systèmes en amont fournissent déjà des preuves suffisantes. Consultez Analyser Fabric.

• Les couches source et de consommation doivent être incluses lorsque la transformation peut modifier matériellement la signification des données ou l’utilisation autorisée.

• Outils : le catalogue unifié Microsoft Purview doit fournir une vue centralisée de la traçabilité des ressources de données soumises à une gouvernance. Les détails de la ressource de données peuvent afficher la traçabilité en amont et en aval avec le contexte métier, comme la description et le propriétaire de la ressource. Consultez Rechercher des produits de données dans le catalogue unifié.

• Collecte des informations de traçabilité : dans la mesure du possible, l’organisation doit automatiser cette collecte à l’aide des intégrations de sources prises en charge. Les domaines de données doivent identifier les lacunes importantes lorsque la traçabilité automatisée ne fournit pas les preuves nécessaires aux décisions de gouvernance. Consultez les métadonnées et la traçabilité de Fabric dans Microsoft Purview et la configuration manuelle de la traçabilité.

3.4 Conservation des données

Combien de temps devons-nous conserver nos données ? L’organisation doit définir les exigences de conservation à partir des obligations légales et des besoins métier avant de configurer les différentes plateformes. Chaque grande catégorie de classification des données ou type d’enregistrement doit disposer d’une durée de conservation approuvée et d’une exigence de disposition. La stratégie doit également identifier les circonstances qui empêchent la suppression normale, telle qu’une conservation légale.

Les domaines de données doivent appliquer ces exigences organisationnelles aux données qu’ils possèdent. Les équipes chargées des plateformes doivent fournir des modèles d’implémentation approuvés pour les services qu’elles exploitent.

3.4.1 conservation des données Microsoft 365

Les stratégies de rétention et étiquettes de rétention Microsoft 365 doivent mettre en œuvre les exigences de conservation organisationnelles pour le contenu Microsoft 365 pris en charge. Les organisations doivent utiliser les fonctionnalités de gestion du cycle de vie des données et de gestion des enregistrements de Microsoft Purview qui répondent à leurs exigences de conservation et de disposition. Conservation des données Microsoft 365.

3.4.2 Conservation des données Azure

Les normes relatives à la plateforme Azure doivent définir comment les exigences organisationnelles de conservation se traduisent en paramètres de sauvegarde et de gestion du cycle de vie propres à chaque service. L’organisation doit distinguer la rétention à des fins métier ou réglementaires de la sauvegarde requise pour la récupération opérationnelle. Ces objectifs peuvent nécessiter différents contrôles. Consultez stockage Azure, SQL Database, Cosmos DB et MySQL.

3.4.3 Rétention des données sur site et multicloud

Les exigences de rétention organisationnelles doivent s’appliquer quel que soit l’emplacement des données. Les domaines de données doivent identifier les plateformes qui ne peuvent pas satisfaire aux stratégies de rétention ou de destruction requises. Si une plateforme ne peut pas satisfaire à une exigence, l’organisation doit établir un contrôle compensatoire approuvé ou déplacer des documents soumis à gouvernance vers une plateforme qui peut satisfaire à l’exigence.

4. Sécurité des données

Comment classifier et protéger les données ? L’organisation doit établir un modèle de sécurité des données cohérent qui protège les données en fonction de leur sensibilité et du risque métier. Le modèle doit définir des exigences à l’échelle de l’organisation pour identifier les données sensibles et empêcher l’utilisation ou la divulgation inappropriées. Chaque plateforme doit implémenter ces exigences au moyen des contrôles de sécurité qu’elle prend en charge.

4.1 Classification des données

Comment devons-nous classifier nos données ? L’organisation doit établir un modèle de classification des informations sur les plateformes prises en charge. Chaque classification doit définir sa signification métier et les résultats de protection requis. Les plateformes doivent implémenter ce modèle par le biais de mécanismes pris en charge, y compris les étiquettes de sensibilité le cas échéant.

• Taxonomie organisationnelle : la taxonomie doit utiliser des termes qui ont déjà une signification organisationnelle acceptée. Un modèle peut utiliser des classifications telles que Public, Général, Confidentiel et Hautement Confidentiel. L’organisation ne doit créer des étiquettes de confidentialité que lorsqu’elles correspondent à un résultat distinct en matière de protection ou de traitement des données. Un trop grand nombre d’étiquettes rendent la classification difficile à comprendre et à appliquer de manière cohérente. Consultez Bien démarrer avec les étiquettes de confidentialité.

• Classification par défaut : l’organisation doit établir une valeur par défaut sécurisée pour les plateformes où les données non étiquetées créeraient un risque important. Une classification par défaut fournit un point de départ. Cela ne remplace pas la classification effectuée par le domaine de données responsable. Consultez les étiquettes et stratégies de sensibilité par défaut.

• Autorité de dérogation : l’organisation doit définir qui peut abaisser un niveau de classification et quelles preuves sont requises. Les classifications hautement sensibles doivent nécessiter l’approbation d’un responsable métier redevable ou d’une autorité de sécurité désignée.

• Microsoft 365 : les étiquettes de confidentialité Microsoft Purview peuvent classifier le contenu Microsoft 365 et appliquer les mesures de protection configurées, notamment le chiffrement et les restrictions d’utilisation. Voir Microsoft 365.

• Microsoft Fabric : Fabric utilise des étiquettes de confidentialité Microsoft Purview pour la classification. Une étiquette de confidentialité appliquée à un élément Fabric ne suffit pas, à elle seule, à imposer des restrictions d’accès équivalentes à cet élément. Les autorisations Fabric continuent de contrôler l’accès. Lorsqu’une classification exige un accès restreint, utilisez les contrôles d’accès Fabric ou les stratégies de protection prises en charge pour appliquer cette restriction. Consultez les étiquettes de confidentialité protégées et Fabric stratégies d’étiquette par défaut.

• Vérification de la protection : l’organisation doit tester si sa protection requise survit à des transitions importantes entre plateformes. Les tests doivent couvrir les chemins d’accès où les données peuvent quitter un environnement plus contrôlé, comme l’exportation de Fabric vers Microsoft 365.

4.2 Données sensibles

Comment protéger les données sensibles ? L’organisation doit définir les informations qui créent des risques d’entreprise ou de conformité significatifs et établir des méthodes cohérentes pour les détecter. Les domaines de données doivent identifier les informations sensibles dans leur contexte métier. Les équipes chargées de la sécurité et de la conformité doivent traduire ces définitions en classificateurs réutilisables et en contrôles de protection.

• Détection standard : les types d’informations sensibles ou la correspondance exacte des données doivent être utilisés lorsque les données sensibles présentent un schéma fiable ou un ensemble de références faisant autorité. Les exemples incluent des identificateurs nationaux ou des enregistrements clients connus.

• Détection contextuelle : les classifieurs pouvant être formés doivent être utilisés lorsque la sensibilité dépend de la signification du contenu plutôt que d’un modèle prévisible. Les exemples incluent des documents de stratégie confidentiels ou des travaux de recherche exclusifs.

Microsoft Purview fournit des types d’informations sensibles et des classifieurs pouvant prendre en charge ces définitions organisationnelles. Consultez vue d’ensemble des classifieurs Microsoft Purview.

4.3 Protection contre la perte de données

Comment configurer la protection contre la perte de données (DLP) ? L’organisation doit établir des stratégies DLP pour des scénarios de perte de données spécifiques où la prévention ou la détection d’une action réduit un risque important pour l’entreprise. N’appliquez pas le contrôle le plus strict disponible à chaque site. DLP doit être un contrôle dans le modèle de protection des données plus large, car la couverture varie selon la plateforme et l’activité.

• Scénarios de risque : chaque stratégie DLP doit définir les données sensibles et l’action risquée à laquelle elle répond. Elle doit également définir la population ou le service concerné. Par exemple, une stratégie peut traiter le partage externe de données personnelles des clients à partir de Microsoft 365.

• Phase de supervision : les nouvelles stratégies doivent normalement commencer en mode audit ou simulation. L’équipe responsable doit examiner les correspondances à partir d’activités métier représentatives et définir les exceptions approuvées avant d’activer les restrictions. Consultez le mode de simulation DLP.

• Phase d’application : le blocage doit s’appliquer lorsque l’effet attendu de l’exposition des données dépasse l’effet métier de l’interruption du travail légitime. L’organisation doit définir qui est habilité à approuver les exceptions avant d’activer le blocage.

• Examen des stratégies : des dérogations répétées ou des faux positifs doivent entraîner un examen des stratégies. Ces modèles peuvent indiquer une détection inexacte ou un processus métier légitime qui est en conflit avec la politique.

Consultez DLP pour Protection contre la perte de données Microsoft Purview et des conseils spécifiques pour Microsoft Fabric et Microsoft Copilot.

4.4 sécurité des données Azure

Comment sécuriser les données dans les systèmes Azure ? L’organisation doit établir des normes Azure de protection des données qui traduisent la classification des données en exigences de sécurité minimales. Microsoft Purview classification peut identifier la sensibilité et l’importance métier des données. Azure services doivent appliquer les exigences résultantes par le biais de leurs contrôles de sécurité pris en charge.

• Base de référence de la protection : les équipes de plateforme doivent fournir des modèles Azure approuvés qui répondent à ces exigences afin que les équipes responsables des charges de travail ne conçoivent pas le modèle de sécurité de l'organisation indépendamment.

• Implémentation de service : Les services Azure doivent appliquer la base de référence organisationnelle par le biais de leurs fonctionnalités natives. La classification des données doit guider les protections requises plutôt que de dicter une implémentation technique spécifique pour chaque service.

• Vérification des contrôles : les équipes de sécurité doivent vérifier périodiquement que les services contenant des données sensibles respectent le socle de référence de l’organisation, et identifier les exceptions nécessitant une correction ou une acceptation formelle des risques.