Déployer une plate-forme de gestion et d'analyse des données d'entreprise

Last reviewed 2025-04-04 UTC

Une plate-forme d'analyse et de gestion des données d'entreprise fournit un enclave où vous pouvez stocker, analyser et manipuler des informations sensibles tout en conservant les contrôles de sécurité. Vous pouvez utiliser l'architecture de maillage de données d'entreprise pour déployer une plate-forme sur Google Cloud afin de gérer et d'analyser les données. L'architecture est conçue pour fonctionner dans un environnement hybride, où les composants Google Cloud interagissent avec vos composants et processus opérationnels sur site existants.

L'architecture de maillage de données d'entreprise comprend les éléments suivants :

• Un dépôt GitHub contenant un ensemble de configurations, de scripts et de code Terraform pour créer les éléments suivants :
  • Projet de gouvernance qui vous permet d'utiliser l'implémentation par Google du framework des principaux contrôles Cloud Data Management Capabilities (CDMC).
  • Exemple de plate-forme de données compatible avec les workflows interactifs et de production.
  • Environnement de production au sein de la plate-forme de données qui prend en charge plusieurs domaines de données. Les domaines de données sont des regroupements logiques d'éléments de données.
  • Environnement consommateur au sein de la plate-forme de données qui prend en charge plusieurs projets consommateurs.
  • Service de transfert de données qui utilise la fédération d'identité de charge de travail et la bibliothèque de chiffrement Tink pour vous aider à transférer des données dans Google Cloud de manière sécurisée.
  • Exemple de domaine de données contenant des projets d'ingestion, non confidentiels et confidentiels.
  • Exemple de système d'accès aux données permettant aux consommateurs de données de demander l'accès à des ensembles de données et aux propriétaires de données d'accorder l'accès à ces ensembles de données. L'exemple inclut également un gestionnaire de workflow qui modifie les autorisations IAM de ces ensembles de données en conséquence.
• Un guide de l'architecture, de la conception, des contrôles de sécurité et des processus opérationnels que vous utilisez pour mettre en œuvre cette architecture (ce document).

L'architecture de maillage de données d'entreprise est conçue pour être compatible avec le plan de base d'entreprise. Le plan de base d'entreprise fournit un certain nombre de services de base sur lesquels repose cette architecture, tels que les réseaux VPC et la journalisation. Vous pouvez déployer cette architecture sans déployer le plan de base d'entreprise si votre environnementGoogle Cloud fournit les fonctionnalités nécessaires.

Ce document est destiné aux architectes cloud, aux data scientists, aux ingénieurs de données et aux architectes de sécurité qui peuvent utiliser l'architecture pour créer et déployer des services de données complets sur Google Cloud. Dans ce document,nous partons du principe que vous connaissez les concepts de data mesh, Google Cloudles services de données et l'implémentation Google Cloud du framework CDMC.

Architecture

L'architecture de maillage de données d'entreprise adopte une approche par couches pour fournir les fonctionnalités permettant l'ingestion, le traitement et la gouvernance des données. L'architecture est conçue pour être déployée et contrôlée via un workflow CI/CD. Le diagramme suivant montre comment la couche de données déployée par cette architecture est liée aux autres couches de votre environnement.

Ce schéma comprend les éléments suivants :

• L'infrastructureGoogle Cloud fournit des fonctionnalités de sécurité telles que le chiffrement au repos et le chiffrement en transit, ainsi que des éléments de base tels que le calcul et le stockage.
• La base d'entreprise fournit une base de ressources telles que les systèmes d'identité, de mise en réseau, de journalisation, de surveillance et de déploiement qui vous permettent d'adopter Google Cloud pour vos charges de travail de données.
• La couche de données offre diverses fonctionnalités telles que l'ingestion de données, le stockage de données, le contrôle des accès aux données et la gouvernance des données, ainsi que la surveillance et le partage des données.
• La couche Application représente différentes applications qui utilisent les composants de la couche Données.
• CI/CD fournit les outils permettant d'automatiser le provisionnement, la configuration, la gestion et le déploiement de l'infrastructure, des workflows et des composants logiciels. Ces composants vous aident à garantir des déploiements cohérents, fiables et contrôlables, à limiter les erreurs manuelles et à accélérer le cycle de développement global.

Pour illustrer l'utilisation de l'environnement de données, l'architecture inclut un exemple de workflow de données. L'exemple de workflow de données vous guide à travers les processus suivants : gouvernance des données, ingestion des données, traitement des données, partage des données et consommation des données.

Principales décisions en termes d'architecture

Le tableau suivant récapitule les décisions générales relatives à l'architecture.

Zone de décision	Décision
Google Cloud architecture
Hiérarchie des ressources	L'architecture utilise la hiérarchie des ressources du plan de base de l'entreprise.
Mise en réseau	L'architecture inclut un exemple de service de transfert de données qui utilise la fédération d'identité de charge de travail et une bibliothèque Tink.
Rôles et autorisations IAM	L'architecture inclut des rôles de producteur de données, de consommateur de données, de gouvernance des données et de plate-forme de données segmentés.
Services de données courants
Métadonnées	L'architecture utilise Data Catalog pour gérer les métadonnées.
Gestion centralisée des règles	Pour gérer les règles, l'architecture utilise l'implémentation du framework CDMC par Google Cloud.
Gestion des accès aux données	Pour contrôler l'accès aux données, l'architecture inclut un processus indépendant qui exige que les consommateurs de données demandent l'accès aux éléments de données au propriétaire des données.
Qualité des données	L'architecture utilise le Cloud Data Quality Engine pour définir et exécuter des règles de qualité des données sur les colonnes de table spécifiées, en mesurant la qualité des données en fonction de métriques telles que l'exactitude et l'exhaustivité.
Sécurité des données	L'architecture utilise le taggage, le chiffrement, le masquage, la tokenisation et les contrôles IAM pour assurer la sécurité des données.
Domaine de données
Environnements de données	L'architecture comprend trois environnements. Deux environnements (hors production et de production) sont des environnements opérationnels pilotés par des pipelines. Un environnement (développement) est un environnement interactif.
Propriétaires des données	Les propriétaires de données ingèrent, traitent et exposent les composants de données, et accordent l'accès à ces composants.
Consommateurs de données	Les consommateurs de données demandent l'accès aux assets de données.
Intégration et opérations
Pipelines	L'architecture utilise les pipelines suivants pour déployer des ressources : Pipeline de base Pipeline d'infrastructure Pipelines d'artefacts Pipeline catalogue de services
Dépôts	Chaque pipeline utilise un dépôt distinct pour permettre la séparation des responsabilités.
Flux de processus	Le processus exige que les modifications apportées à l'environnement de production incluent un demandeur et un approbateur.
Opérations Cloud
Tableaux de données des produits	Le moteur de rapports génère des tableaux de données de produits.
Cloud Logging	L'architecture utilise l'infrastructure de journalisation du plan de base de l'entreprise.
Cloud Monitoring	L'architecture utilise l'infrastructure de surveillance du plan de base d'entreprise.

Identité : mapper des rôles à des groupes

Le data mesh s'appuie sur l'architecture existante de gestion du cycle de vie des identités, d'autorisation et d'authentification du plan de base de l'entreprise. Les rôles ne sont pas directement attribués aux utilisateurs. Les groupes constituent la méthode principale pour attribuer des rôles et des autorisations dans IAM. Les rôles et autorisations IAM sont attribués lors de la création du projet via le pipeline de base.

Le data mesh associe les groupes à l'un des quatre domaines clés suivants : infrastructure, gouvernance des données, producteurs de données basés sur le domaine et consommateurs basés sur le domaine.

Les niveaux d'autorisation pour ces groupes sont les suivants :

• Le champ d'application des autorisations du groupe d'infrastructure est l'ensemble du maillage de données.
• Le champ d'application des autorisations des groupes de gouvernance des données correspond au projet de gouvernance des données.
• Les autorisations des producteurs et des consommateurs basés sur les domaines sont limitées à leur domaine de données.

Les tableaux suivants présentent les différents rôles utilisés dans cette implémentation de data mesh et les autorisations associées.

Infrastructure

Groupe	Description	Rôles
[e-mail]	Administrateurs généraux du maillage de données	roles/owner (plate-forme de données)

Gouvernance des données

Groupe	Description	Rôles
[e-mail]	Administrateurs du projet de gouvernance des données	roles/owner sur le projet de gouvernance des données
[e-mail]	Développeurs qui créent et gèrent les composants de gouvernance des données	Plusieurs rôles dans le projet de gouvernance des données, y compris roles/viewer, les rôles BigQuery et les rôles Data Catalog
[e-mail]	Lecteurs des informations sur la gouvernance des données	roles/viewer
[e-mail]	Administrateurs de la sécurité du projet de gouvernance	roles/orgpolicy.policyAdmin et roles/iam.securityReviewer.
[e-mail]	Groupe autorisé à utiliser des modèles de tags	roles/datacatalog.tagTemplateUser
[e-mail]	Groupe autorisé à utiliser des modèles de tags et à ajouter des tags	roles/datacatalog.tagTemplateUser et roles/datacatalog.tagEditor.
[e-mail]	Groupe de comptes de service pour les notifications Security Command Center	Aucune. Il s'agit d'un groupe pour les membres. Un compte de service est créé avec ce nom et dispose des autorisations nécessaires.

Producteurs de données basés sur les domaines

Groupe	Description	Rôles
gcp-dm-{data_domain_name}[e-mail]	Administrateurs d'un domaine de données spécifique	roles/owner sur le projet de domaine de données
gcp-dm-{data_domain_name}[e-mail]	Développeurs qui créent et gèrent des produits de données dans un domaine de données	Plusieurs rôles dans le projet de domaine de données, y compris les rôles roles/viewer, BigQuery et Cloud Storage
gcp-dm-{data_domain_name}[e-mail]	Lecteurs des informations sur le domaine de données	roles/viewer
gcp-dm-{data_domain_name}-metadata-editors@{var.domain}	Éditeurs des entrées Data Catalog	Rôles permettant de modifier les entrées Data Catalog
gcp-dm-{data_domain_name}[e-mail]	Intendants de données pour le domaine de données	Rôles permettant de gérer les métadonnées et les aspects liés à la gouvernance des données

Consommateurs de données basés sur le domaine

Groupe	Description	Rôles
gcp-dm-consumer-{project_name}[e-mail]	Administrateurs d'un projet client spécifique	roles/owner sur le projet du client
gcp-dm-consumer-{project_name}[e-mail]	Développeurs travaillant dans un projet client	Plusieurs rôles dans le projet consommateur, y compris roles/viewer et les rôles BigQuery
gcp-dm-consumer-{project_name}[e-mail]	Lecteurs des informations sur le projet client	roles/viewer

Structure organisationnelle

Pour faire la différence entre les opérations de production et les données de production, l'architecture utilise différents environnements pour développer et publier des workflows. Les opérations de production incluent la gouvernance, la traçabilité et la répétabilité d'un workflow, ainsi que l'auditabilité des résultats du workflow. Les données de production font référence à des données potentiellement sensibles dont vous avez besoin pour gérer votre organisation. Tous les environnements sont conçus pour inclure des contrôles de sécurité qui vous permettent d'ingérer et d'exploiter vos données.

Pour aider les data scientists et les ingénieurs, l'architecture inclut un environnement interactif dans lequel les développeurs peuvent travailler directement et ajouter des services via un catalogue de solutions sélectionnées. Les environnements opérationnels sont gérés par des pipelines dont l'architecture et la configuration sont codifiées.

Cette architecture utilise la structure organisationnelle du plan de base d'entreprise comme base pour le déploiement des charges de travail de données. Le diagramme suivant montre les dossiers et projets de premier niveau utilisés dans l'architecture de maillage de données d'entreprise.

Le tableau suivant décrit les dossiers et projets de premier niveau qui font partie de l'architecture.

Dossier	Composant	Description
common	prj-c-artifact-pipeline	Contient le pipeline de déploiement utilisé pour créer les artefacts de code de l'architecture.
	prj-c-service-catalog	Contient l'infrastructure utilisée par catalogue de services pour déployer des ressources dans l'environnement interactif.
	prj-c-datagovernance	Contient toutes les ressources utilisées par l'implémentation du framework CDMC par Google Cloud.
development	fldr-d-dataplatform	Contient les projets et les ressources de la plate-forme de données pour développer des cas d'utilisation en mode interactif.
non-production	fldr-n-dataplatform	Contient les projets et les ressources de la plate-forme de données pour tester les cas d'utilisation que vous souhaitez déployer dans un environnement opérationnel.
production	fldr-p-dataplatform	Contient les projets et les ressources de la plate-forme de données à déployer en production.

Dossier de la plate-forme de données

Le dossier de la plate-forme de données contient tous les composants du plan de données et certaines ressources CDMC. De plus, le dossier de la plate-forme de données et le projet de gouvernance des données contiennent les ressources CDMC. Le schéma suivant montre les dossiers et les projets déployés dans le dossier de la plate-forme de données.

Chaque dossier de plate-forme de données inclut un dossier d'environnement (production, hors production et développement). Le tableau suivant décrit les dossiers de chaque dossier de plate-forme de données.

Dossiers	Description
Producteurs	Contient les domaines de données.
Clients	Contient les projets clients.
Domaine de données	Contient les projets associés à un domaine spécifique.

Dossier "Producers"

Chaque dossier de producteurs inclut un ou plusieurs domaines de données. Un domaine de données fait référence à un regroupement logique d'éléments de données qui partagent une signification, un objectif ou un contexte métier communs. Les domaines de données vous permettent de classer et d'organiser les ressources de données au sein d'une organisation. Le schéma suivant illustre la structure d'un domaine de données. L'architecture déploie des projets dans le dossier de la plate-forme de données pour chaque environnement.

Le tableau suivant décrit les projets déployés dans le dossier de la plate-forme de données pour chaque environnement.

Projet	Description
Ingestion	Le projet d'ingestion ingère les données dans le domaine de données. L'architecture fournit des exemples de diffusion de données dans BigQuery, Cloud Storage et Pub/Sub. Le projet d'ingestion contient également des exemples de Dataflow et de Managed Service for Apache Airflow que vous pouvez utiliser pour orchestrer la transformation et le déplacement des données ingérées.
Non confidentiel	Le projet non confidentiel contient des données anonymisées. Vous pouvez masquer, conteneuriser, chiffrer, tokeniser ou obscurcir les données. Utilisez des tags de règles pour contrôler la façon dont les données sont présentées.
Confidentiel	Le projet confidentiel contient des données en texte brut. Vous pouvez contrôler l'accès à l'aide des autorisations IAM.

Dossier "consumer"

Le dossier consommateur contient des projets consommateurs. Les projets consommateurs fournissent un mécanisme permettant de segmenter les utilisateurs de données en fonction de la limite de confiance requise. Chaque projet est attribué à un groupe d'utilisateurs distinct, et ce groupe a accès aux composants de données requis, projet par projet. Vous pouvez utiliser le projet consommateur pour collecter, analyser et enrichir les données du groupe.

Dossier commun

Le dossier "common" contient les services utilisés par différents environnements et projets. Cette section décrit les fonctionnalités ajoutées au dossier commun pour activer le maillage de données d'entreprise.

Architecture CDMC

L'architecture utilise l'architecture CDMC pour la gouvernance des données. Les fonctions de gouvernance des données se trouvent dans le projet de gouvernance des données du dossier commun. Le schéma suivant montre les composants de l'architecture CDMC. Les numéros indiqués dans le schéma représentent les principaux contrôles adressés aux services Google Cloud.

Le tableau suivant décrit les composants de l'architecture CDMC utilisés par l'architecture de maillage de données d'entreprise.

Composant CDMC	ServiceGoogle Cloud	Description
Composants d'accès et de cycle de vie
Gestion des clés	Cloud KMS	Service qui gère de manière sécurisée les clés de chiffrement protégeant les données sensibles.
Gestionnaire d'enregistrements	Cloud Run	Une application qui conserve des journaux et des enregistrements complets des activités de traitement des données, ce qui permet aux organisations de suivre et d'auditer l'utilisation des données.
Règles d'archivage	BigQuery	Table BigQuery contenant la règle de stockage des données.
Droits	BigQuery	Table BigQuery qui stocke des informations sur les personnes autorisées à accéder aux données sensibles. Ce tableau permet de s'assurer que seuls les utilisateurs autorisés peuvent accéder à des données spécifiques en fonction de leurs rôles et privilèges.
Composants d'analyse
Perte de données	Sensitive Data Protection	Service utilisé pour inspecter les composants à la recherche de données sensibles.
Résultats DLP	BigQuery	Table BigQuery qui catalogue les classifications de données au sein de la plate-forme de données.
Règles	BigQuery	Table BigQuery contenant des pratiques cohérentes de gouvernance des données (par exemple, les types d'accès aux données).
Exportation de la facturation	BigQuery	Table qui stocke les informations sur les coûts exportées depuis Cloud Billing pour permettre l'analyse des métriques de coût associées aux composants de données.
Cloud Data Quality Engine	Cloud Run	Application qui exécute des contrôles de qualité des données pour les tables et les colonnes.
Résultats sur la qualité des données	BigQuery	Table BigQuery qui enregistre les écarts identifiés entre les règles de qualité des données définies et la qualité réelle des composants de données.
Composants de reporting
Programmeur	Cloud Scheduler	Service qui contrôle le moment où Cloud Data Quality Engine s'exécute et où l'inspection Sensitive Data Protection a lieu.
Moteur de rapports	Cloud Run	Application qui génère des rapports permettant de suivre et de mesurer le respect des contrôles du framework CDMC.
Résultats et composants	BigQuery et Pub/Sub	Rapport BigQuery sur les écarts ou les incohérences dans les contrôles de gestion des données, tels que les tags manquants, les classifications incorrectes ou les emplacements de stockage non conformes.
Exportations de tags	BigQuery	Table BigQuery contenant les informations sur les tags extraites de Data Catalog.
Autres composants
Gestion des règles	Service de règles d'administration	Service qui définit et applique des restrictions sur l'emplacement géographique où les données peuvent être stockées.
Règles d'accès basées sur les attributs	Access Context Manager	Service qui définit et applique des règles d'accès précises basées sur des attributs afin que seuls les utilisateurs autorisés, depuis des lieux et des appareils autorisés, puissent accéder aux informations sensibles.
Métadonnées	Data Catalog	Service qui stocke les informations de métadonnées sur les tables utilisées dans le maillage de données.
Tag Engine	Cloud Run	Application qui ajoute des tags aux données des tables BigQuery.
Rapports CDMC	Data Studio	Tableaux de bord permettant à vos analystes de consulter les rapports générés par les moteurs de l'architecture CDMC.

Implémentation de CDMC

Le tableau suivant décrit comment l'architecture implémente les principaux contrôles du framework CDMC.

Exigence de contrôle CDMC	Implémentation
Conformité des paramètres de traitement des données	Le moteur de rapports détecte les composants de données non conformes et publie les résultats dans un sujet Pub/Sub. Ces résultats sont également chargés dans BigQuery pour la création de rapports à l'aide de Data Studio.
La propriété des données est établie pour les données migrées et générées dans le cloud.	Data Catalog capture automatiquement les métadonnées techniques de BigQuery. Tag Engine applique des tags de métadonnées métier, comme le nom du propriétaire et le niveau de sensibilité, à partir d'un tableau de référence. Cela permet de s'assurer que toutes les données sensibles sont taguées avec les informations du propriétaire pour la conformité. Ce processus de taggage automatique permet d'assurer la gouvernance et la conformité des données en identifiant et en libellant les données sensibles avec les informations appropriées sur leur propriétaire.
L'approvisionnement et la consommation des données sont régis et soutenus par l'automatisation	Data Catalog classe les composants de données en les taguant avec un indicateur is_authoritative lorsqu'ils constituent une source faisant autorité. Data Catalog stocke automatiquement les informations, ainsi que les métadonnées techniques, dans un registre de données. Les moteurs de rapports et de tags peuvent valider et signaler le registre de données des sources fiables à l'aide de Pub/Sub.
La souveraineté des données et le transfert des données à l'international sont gérés.	Le service de règles d'administration définit les régions de stockage autorisées pour les composants de données, tandis qu'Access Context Manager restreint l'accès en fonction de l'emplacement de l'utilisateur. Data Catalog stocke les emplacements de stockage approuvés en tant que tags de métadonnées. Le moteur de rapports compare ces tags à l'emplacement réel des composants de données dans BigQuery et publie les éventuelles différences en tant que résultats à l'aide de Pub/Sub. Security Command Center offre une couche de surveillance supplémentaire en générant des résultats de failles si des données sont stockées ou consultées en dehors des règles définies.
Les catalogues de données sont mis en œuvre, utilisés et interopérables.	Data Catalog stocke et met à jour les métadonnées techniques de tous les composants de données BigQuery, ce qui crée un catalogue de données synchronisé en continu. Data Catalog garantit que toutes les tables et vues nouvelles ou modifiées sont immédiatement ajoutées au catalogue, ce qui permet de maintenir un inventaire à jour des éléments de données.
Les classifications de données sont définies et utilisées.	La protection des données sensibles inspecte les données BigQuery et identifie les types d'informations sensibles. Ces résultats sont ensuite classés en fonction d'un tableau de référence de classification. Le niveau de sensibilité le plus élevé est attribué en tant que tag dans Data Catalog au niveau des colonnes et des tables. Tag Engine gère ce processus en mettant à jour Data Catalog avec des tags de sensibilité chaque fois que de nouveaux éléments de données sont ajoutés ou que des éléments existants sont modifiés. Ce processus garantit une classification des données constamment mise à jour en fonction de leur sensibilité. Vous pouvez la surveiller et générer des rapports à son sujet à l'aide de Pub/Sub et d'outils de reporting intégrés.
Les droits d'accès aux données sont gérés, appliqués et suivis.	Les tags avec stratégie BigQuery contrôlent l'accès aux données sensibles au niveau des colonnes. Ils permettent de s'assurer que seuls les utilisateurs autorisés peuvent accéder à des données spécifiques en fonction du tag avec stratégie qui leur est attribué. IAM gère l'accès global à l'entrepôt de données, tandis que Data Catalog stocke les classifications de sensibilité. Des vérifications régulières sont effectuées pour s'assurer que toutes les données sensibles sont associées à des tags de règles correspondants. Toute incohérence est signalée à l'aide de Pub/Sub pour être corrigée.
L'accès éthique, l'utilisation et les résultats des données sont gérés.	Les contrats de partage de données pour les fournisseurs et les consommateurs sont stockés dans un entrepôt de données BigQuery dédié afin de contrôler les objectifs de consommation. Data Catalog attribue des libellés aux composants de données avec les informations du contrat du fournisseur, tandis que les contrats des consommateurs sont associés à des liaisons IAM pour le contrôle des accès. Les libellés de requête appliquent des objectifs de consommation. Ils obligent les consommateurs à spécifier un objectif valide lorsqu'ils interrogent des données sensibles, qui est validé par rapport à leurs droits d'accès dans BigQuery. Dans BigQuery, une piste d'audit permet de suivre tous les accès aux données et d'assurer la conformité avec les accords de partage de données.
Les données sont sécurisées, et les contrôles sont prouvés.	Le chiffrement au repos par défaut de Google permet de protéger les données stockées sur le disque. Cloud KMS est compatible avec les clés de chiffrement gérées par le client (CMEK) pour une gestion améliorée des clés. BigQuery implémente le masquage dynamique des données au niveau des colonnes pour la désidentification et est compatible avec la désidentification au niveau des applications lors de l'ingestion de données. Data Catalog stocke les tags de métadonnées pour les techniques de chiffrement et d'anonymisation appliquées aux composants de données. Des vérifications automatisées permettent de s'assurer que les méthodes de chiffrement et de désidentification sont conformes aux règles de sécurité prédéfinies. Toute incohérence est signalée en tant que résultat à l'aide de Pub/Sub.
Un cadre spécifique à la confidentialité des données est défini et opérationnel.	Data Catalog tague les éléments de données sensibles avec des informations pertinentes pour l'évaluation de l'impact, telles que l'emplacement du sujet et les liens vers les rapports d'évaluation. Tag Engine applique ces tags en fonction de la sensibilité des données et d'un tableau de règles dans BigQuery, qui définit les exigences d'évaluation en fonction des données et de la résidence des sujets. Ce processus de taggage automatisé permet de surveiller et de signaler en continu la conformité avec les exigences d'évaluation de l'impact, en veillant à ce que des évaluations de l'impact sur la protection des données (DPIA) ou des évaluations de l'impact sur la protection (PIA) soient effectuées lorsque cela est nécessaire.
Le cycle de vie des données est planifié et géré.	Data Catalog libelle les éléments de données avec des règles de conservation, en spécifiant les durées de conservation et les actions d'expiration (comme l'archivage ou la suppression). Record Manager automatise l'application de ces règles en supprimant ou en archivant les tables BigQuery en fonction des tags définis. Cette application garantit le respect des règles de cycle de vie des données et la conformité avec les exigences de conservation des données. Toutes les incohérences détectées sont signalées à l'aide de Pub/Sub.
Gestion de la qualité des données	Cloud Data Quality Engine définit et exécute des règles de qualité des données sur les colonnes de table spécifiées. Il mesure la qualité des données en fonction de métriques telles que l'exactitude et l'exhaustivité. Les résultats de ces vérifications, y compris les pourcentages de réussite et les seuils, sont stockés sous forme de tags dans Data Catalog. Le stockage de ces résultats permet de surveiller et de générer des rapports en continu sur la qualité des données. Tout problème ou écart par rapport aux seuils acceptables est publié sous forme de résultats à l'aide de Pub/Sub.
Les principes de gestion des coûts sont établis et appliqués.	Data Catalog stocke les métriques liées aux coûts pour les assets de données, comme les coûts de requête, les coûts de stockage et les coûts de sortie des données. Ces métriques sont calculées à l'aide des informations de facturation exportées de Cloud Billing vers BigQuery. Le stockage des métriques liées aux coûts permet un suivi et une analyse complets des coûts, garantissant le respect des règles relatives aux coûts et une utilisation efficace des ressources, avec toutes les anomalies signalées à l'aide de Pub/Sub.
La provenance et la traçabilité des données sont comprises.	Les fonctionnalités de traçabilité des données intégrées à Data Catalog permettent de suivre la provenance et la traçabilité des éléments de données, et de représenter visuellement le flux de données. De plus, les scripts d'ingestion de données identifient et taguent la source d'origine des données dans Data Catalog, ce qui améliore la traçabilité des données jusqu'à leur origine.

Gestion des accès aux données

L'accès de l'architecture aux données est contrôlé par un processus indépendant qui sépare le contrôle opérationnel (par exemple, l'exécution de jobs Dataflow) du contrôle des accès aux données. L'accès d'un utilisateur à un service Google Cloud est défini par un problème environnemental ou opérationnel, et est provisionné et approuvé par un groupe d'ingénierie cloud. L'accès d'un utilisateur aux composants de données Google Cloud (par exemple, une table BigQuery) est une question de confidentialité, de réglementation ou de gouvernance. Il est soumis à un accord d'accès entre les parties productrices et consommatrices, et contrôlé par les processus suivants. Le schéma suivant montre comment l'accès aux données est provisionné grâce à l'interaction de différents composants logiciels.

Comme le montre le schéma précédent, l'intégration des accès aux données est gérée par les processus suivants :

• Les composants de données cloud sont collectés et inventoriés par Data Catalog.
• Le gestionnaire de workflow récupère les composants de données à partir de Data Catalog.
• Les propriétaires de données sont intégrés au gestionnaire de workflows.

Le fonctionnement de la gestion des accès aux données est le suivant :

1. Un consommateur de données demande un asset spécifique.
2. Le propriétaire des données de l'élément est averti de la demande.
3. Le propriétaire des données approuve ou refuse la demande.
4. Si la demande est approuvée, le gestionnaire de workflow transmet le groupe, le composant et le tag associé au mappeur IAM.
5. Le mappeur IAM traduit les tags du gestionnaire de workflow en autorisations IAM et accorde au groupe spécifié les autorisations IAM pour le composant de données.
6. Lorsqu'un utilisateur souhaite accéder au composant de données, IAM évalue l'accès au composant Google Cloud en fonction des autorisations du groupe.
7. Si l'accès est autorisé, l'utilisateur peut accéder au composant de données.

Mise en réseau

Le processus de sécurité des données commence au niveau de l'application source, qui peut résider sur site ou dans un autre environnement externe au projetGoogle Cloud cible. Avant tout transfert de données sur le réseau, cette application utilise la fédération d'identité de charge de travail pour s'authentifier de manière sécurisée auprès des API Google Cloud. À l'aide de ces identifiants, il interagit avec Cloud KMS pour obtenir ou encapsuler les clés nécessaires, puis utilise la bibliothèque Tink pour effectuer le chiffrement et la désidentification initiaux de la charge utile de données sensibles selon des modèles prédéfinis.

Une fois la charge utile de données protégée, elle doit être transférée de manière sécurisée dans le projet d'ingestion Google Cloud . Pour les applications sur site, vous pouvez utiliser Cloud Interconnect ou éventuellement Cloud VPN. Dans le réseauGoogle Cloud , utilisez Private Service Connect pour acheminer les données vers le point de terminaison d'ingestion dans le réseau VPC du projet cible. Private Service Connect permet à l'application source de se connecter aux API Google à l'aide d'adresses IP privées, ce qui garantit que le trafic n'est pas exposé à Internet.

L'ensemble du chemin réseau et des services d'ingestion cibles (Cloud Storage, BigQuery et Pub/Sub) au sein du projet d'ingestion sont sécurisés par un périmètre VPC Service Controls. Ce périmètre applique une limite de sécurité, garantissant que les données protégées provenant de la source ne peuvent être ingérées que dans les servicesGoogle Cloud autorisés au sein de ce projet spécifique.

Journalisation

Cette architecture utilise les fonctionnalités Cloud Logging fournies par le plan de base d'entreprise.

Pipelines

L'architecture de maillage de données d'entreprise utilise une série de pipelines pour provisionner l'infrastructure, l'orchestration, les ensembles de données, les pipelines de données et les composants d'application. Les pipelines de déploiement des ressources de l'architecture utilisent Terraform comme outil Infrastructure as Code (IaC) et Cloud Build comme service CI/CD pour déployer les configurations Terraform dans l'environnement de l'architecture. Le schéma suivant illustre la relation entre les pipelines.

Le pipeline de base et le pipeline d'infrastructure font partie du plan de base de l'entreprise. Le tableau suivant décrit l'objectif des pipelines et les ressources qu'ils provisionnent.

Pipeline	Provisionné par	Ressources
Pipeline de base	Amorçage	Dossier et sous-dossiers de la plate-forme de données Projets courants Compte de service du pipeline d'infrastructure Déclencheur Cloud Build pour le pipeline d'infrastructure VPC partagé Périmètre VPC Service Controls
Pipeline d'infrastructure	Pipeline de base	Projets clients Compte de service catalogue de services Déclencheur Cloud Build pour le pipeline catalogue de services Compte de service du pipeline d'artefacts Déclencheur Cloud Build pour le pipeline d'artefacts
Pipeline catalogue de services	Pipeline d'infrastructure	Ressources déployées dans le bucket catalogue de services
Pipelines d'artefacts	Pipeline d'infrastructure	Les pipelines d'artefacts produisent les différents conteneurs et autres composants du code utilisé par le maillage de données.

Chaque pipeline possède son propre ensemble de dépôts à partir desquels il extrait le code et les fichiers de configuration. Dans chaque dépôt, les tâches sont séparées : les responsables de l'envoi et de l'approbation des déploiements de code opérationnel appartiennent à des groupes différents.

Déploiement interactif via catalogue de services

Les environnements interactifs sont l'environnement de développement au sein de l'architecture et se trouvent dans le dossier de développement. L'interface principale de l'environnement interactif est le catalogue de services, qui permet aux développeurs d'utiliser des modèles préconfigurés pour instancier des services Google. Ces modèles préconfigurés sont appelés modèles de service. Les modèles de service vous aident à renforcer votre posture de sécurité, par exemple en rendant le chiffrement CMEK obligatoire. Ils empêchent également vos utilisateurs d'accéder directement aux API Google.

Le schéma suivant montre les composants de l'environnement interactif et comment les data scientists déploient les ressources.

Pour déployer des ressources à l'aide du catalogue de services, procédez comme suit :

1. L'ingénieur MLOps place un modèle de ressource Terraform pour Google Clouddans un dépôt Git.
2. La commande Git Commit déclenche un pipeline Cloud Build.
3. Cloud Build copie le modèle et tous les fichiers de configuration associés dans Cloud Storage.
4. L'ingénieur MLOps configure manuellement catalogue de services et catalogue de services. L'ingénieur partage ensuite le catalogue de services avec un projet de service dans l'environnement interactif.
5. Le data scientist sélectionne une ressource dans catalogue de services.
6. Catalogue de services déploie le modèle dans l'environnement interactif.
7. La ressource extrait tous les scripts de configuration nécessaires.
8. Le data scientist interagit avec les ressources.

Pipelines d'artefacts

Le processus d'ingestion de données utilise Managed Airflow et Dataflow pour orchestrer le déplacement et la transformation des données dans le domaine de données. Le pipeline d'artefacts crée toutes les ressources nécessaires à l'ingestion de données et les déplace vers l'emplacement approprié pour que les services puissent y accéder. Le pipeline d'artefacts crée les artefacts de conteneur utilisés par l'orchestrateur.

Contrôles de sécurité

L'architecture de maillage de données d'entreprise utilise un modèle de sécurité de défense en profondeur par couches qui inclut les fonctionnalités Google Cloud , les services Google Cloudet les fonctionnalités de sécurité par défaut configurés via le plan de base de l'entreprise. Le schéma suivant illustre la superposition des différents contrôles de sécurité pour l'architecture.

Le tableau suivant décrit les contrôles de sécurité associés aux ressources de chaque couche.

intégrée	Ressource	Contrôle de sécurité
Framework CDMC	Implémentation deGoogle Cloud CDMC	Fournit un framework de gouvernance qui vous aide à sécuriser, gérer et contrôler vos ensembles de données. Pour en savoir plus, consultez le framework des principaux contrôles CDMC.
Déploiement	Pipeline d'infrastructure	Fournit une série de pipelines qui déploient l'infrastructure, créent des conteneurs et créent des pipelines de données. L'utilisation de pipelines permet l'auditabilité, la traçabilité et la reproductibilité.
	Pipeline d'artefacts	Déploie différents composants non déployés par le pipeline d'infrastructure.
	Modèles Terraform	Développe l'infrastructure système.
	Open Policy Agent	Permet de s'assurer que la plate-forme est conforme aux règles sélectionnées.
Réseau	Private Service Connect	Fournit des protections contre l'exfiltration de données autour des ressources d'architecture au niveau de la couche API et de la couche IP. Vous permet de communiquer avec les API Google Cloud à l'aide d'adresses IP privées afin d'éviter d'exposer le trafic à Internet.
	Réseau VPC avec des adresses IP privées	Aide à éviter l'exposition aux menaces sur Internet.
	VPC Service Controls	Aide à protéger les ressources sensibles contre l'exfiltration de données.
	Pare-feu	Protège le réseau VPC contre les accès non autorisés.
Gestion des accès	Access Context Manager	Contrôle qui peut accéder à quelles ressources et permet d'éviter toute utilisation non autorisée de vos ressources.
	Fédération d'identité de charge de travail	Il n'est plus nécessaire d'utiliser des identifiants externes pour transférer des données vers la plate-forme depuis des environnements sur site.
	Data Catalog	Fournit un index des composants disponibles pour les utilisateurs.
	IAM	Fournit un accès précis.
Chiffrement	Cloud KMS	Vous permet de gérer vos clés de chiffrement et vos secrets, et de protéger vos données grâce au chiffrement au repos et en transit.
	Secrets Manager	Fournit un magasin de secrets pour les pipelines contrôlés par IAM.
	Chiffrement au repos	Par défaut, Google Cloud chiffre les données au repos.
	Chiffrement en transit	Par défaut, Google Cloud chiffre les données en transit.
Détection	Security Command Center	Vous aide à détecter les erreurs de configuration et les activités malveillantes dans votre organisation Google Cloud.
	Architecture continue	Vérifie en permanence votre organisation Google Cloud par rapport à une série de règles OPA que vous avez définies.
	Outil de recommandation IAM	Analyse les autorisations des utilisateurs et fournit des suggestions sur la réduction des autorisations afin d'appliquer le principe du moindre privilège.
	Firewall Insights	Analyse les règles de pare-feu, identifie celles qui sont trop permissives et suggère des pare-feu plus restrictifs pour vous aider à renforcer votre stratégie de sécurité globale.
	Cloud Logging	Fournit de la visibilité sur l'activité du système et permet de détecter les anomalies et les activités malveillantes.
	Cloud Monitoring	Suit les signaux et événements clés qui peuvent aider à identifier les activités suspectes.
Prévention	Règles d'administration	Vous permet de contrôler et de restreindre les actions dans votre organisation Google Cloud.

Workflows

Les sections suivantes décrivent le workflow du producteur de données et celui du consommateur de données, en veillant à ce que les contrôles d'accès appropriés soient appliqués en fonction de la sensibilité des données et des rôles des utilisateurs.

Workflow du producteur de données

Le schéma suivant montre comment les données sont protégées lorsqu'elles sont transférées vers BigQuery.

Le workflow de transfert de données est le suivant :

1. Une application intégrée à la fédération d'identité de charge de travail utilise Cloud KMS pour déchiffrer une clé de chiffrement encapsulée.
2. L'application utilise la bibliothèque Tink pour anonymiser ou chiffrer les données à l'aide d'un modèle.
3. L'application transfère les données vers le projet d'ingestion dans Google Cloud.
4. Les données arrivent dans Cloud Storage, BigQuery ou Pub/Sub.
5. Dans le projet d'ingestion, les données sont déchiffrées ou réidentifiées à l'aide d'un modèle.
6. Les données déchiffrées sont chiffrées ou masquées en fonction d'un autre modèle d'anonymisation, puis placées dans le projet non confidentiel. Les tags sont appliqués par le moteur de taggage, le cas échéant.
7. Les données du projet non confidentiel sont transférées vers le projet confidentiel et réidentifiées.

L'accès aux données suivant est autorisé :

• Les utilisateurs ayant accès au projet confidentiel peuvent accéder à toutes les données brutes en texte brut.
• Les utilisateurs ayant accès au projet non confidentiel peuvent accéder aux données masquées, tokenisées ou chiffrées en fonction des tags associés aux données et de leurs autorisations.

Workflow de consommateur de données

Les étapes suivantes décrivent comment un consommateur peut accéder aux données stockées dans BigQuery.

1. Le consommateur de données recherche des éléments de données à l'aide de Data Catalog.
2. Une fois que le consommateur a trouvé les composants qu'il recherche, il demande l'accès aux composants de données.
3. Le propriétaire des données décide s'il autorise l'accès aux composants.
4. Si le consommateur obtient l'accès, il peut utiliser un notebook et le catalogue de solutions pour créer un environnement dans lequel il peut analyser et transformer les composants de données.

Conclusion

Le dépôt GitHub vous fournit des instructions détaillées sur le déploiement du data mesh surGoogle Cloud après avoir déployé la fondation d'entreprise. Le processus de déploiement de l'architecture implique de modifier vos dépôts d'infrastructure existants et de déployer de nouveaux composants spécifiques au maillage de données.

Effectuer les actions suivantes :

1. Remplissez toutes les conditions préalables, y compris les suivantes :
   1. Installez Google Cloud CLI, Terraform, Tink, Java et Go.
   2. Déployez le plan de base de l'entreprise (v4.1).
   3. Gérez les dépôts locaux suivants :
      • gcp-data-mesh-foundations
      • gcp-bootstrap
      • gcp-environments
      • gcp-networks
      • gcp-org
      • gcp-projects
2. Modifiez le blueprint de base existant, puis déployez les applications de maillage de données. Pour chaque élément, procédez comme suit :
   1. Dans votre dépôt cible, examinez la branche Plan.
   2. Pour ajouter des composants de maillage de données, copiez les fichiers et répertoires concernés depuis gcp-data-mesh-foundations dans le répertoire de base approprié. Écrasez les fichiers si nécessaire.
   3. Mettez à jour les variables, les rôles et les paramètres du maillage de données dans les fichiers Terraform (par exemple, *.tfvars et *.tf). Définissez les jetons GitHub comme variables d'environnement.
   4. Effectuez les opérations Terraform "initialize", "plan" et "apply" sur chaque dépôt.
   5. Validez vos modifications, transférez le code vers votre dépôt distant, créez des requêtes d'extraction et fusionnez-les dans vos environnements de développement, hors production et de production.

Étapes suivantes

• Découvrez l'architecture et les fonctions d'un maillage de données.
• Importer des données depuis Google Cloud dans un entrepôt de données BigQuery sécurisé
• Mettez en œuvre le framework des principaux contrôles CDMC dans un entrepôt de données BigQuery.
• Consultez le plan de base de l'entreprise.