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

Last reviewed 2025-04-04 UTC

Une plate-forme de gestion et d'analyse des données d'entreprise fournit une enclave dans laquelle vous pouvez stocker, analyser et manipuler des informations sensibles tout en conservant des 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 pour la gestion et l'analyse des données. L'architecture est conçue pour fonctionner dans un environnement hybride, où les composants Google Cloud interagissent avec vos composants et processus d'exploitation 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 de Cloud Data Management (CDMS).
  • 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 compatible avec plusieurs domaines de données. Les domaines de données sont des regroupements logiques d'éléments de données.
  • Environnement client au sein de la plate-forme de données, compatible avec plusieurs projets client.
  • Service de transfert de données qui utilise Workload Identity Federation et la bibliothèque de chiffrement Tink pour vous aider à transférer des données vers 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 qui permet 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 cette architecture s'appuie, 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 réseaux maillés de données, des Google Cloudservices de données et de l' Google Cloud implémentation du framework CDMC.

Architecture

L'architecture de maillage de données d'entreprise adopte une approche en couches pour fournir les fonctionnalités permettant l'ingestion, le traitement et la gouvernance des données. L'architecture est destinée à ê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 se rapporte 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 référence 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 de données.
• Le CI/CD fournit les outils nécessaires pour 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 présente les processus suivants: gouvernance des données, ingestion de 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 de 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 d'entreprise.
Mise en réseau	L'architecture comprend 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 comprend des rôles de producteur de données segmentés, des rôles de consommateur de données, des rôles de gouvernance des données et des rôles de plate-forme de données.
Services de données courants
Métadonnées	L'architecture utilise Data Catalog pour gérer les métadonnées de données.
Gestion centralisée des règles	Pour gérer les stratégies, 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 oblige les consommateurs de données à demander l'accès aux éléments de données au propriétaire des données.
Qualité des données	L'architecture utilise Cloud Data Quality Engine pour définir et exécuter des règles de qualité des données sur des 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 des données
Environnements de données	L'architecture comprend trois environnements. Deux environnements (hors production et production) sont des environnements opérationnels gérés par des pipelines. L'un des environnements (développement) est un environnement interactif.
Propriétaires des données	Les propriétaires de données insèrent, traitent, exposent et accordent l'accès aux composants de données.
Consommateurs de données	Les consommateurs de données demandent l'accès aux éléments 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égrégation des responsabilités.
Flux de traitement	Le processus exige que les modifications apportées à l'environnement de production incluent un expéditeur et un approbateur.
Cloud Operations
Tableaux de données des produits de données	Le moteur de rapports génère des tableaux de données sur les produits de données.
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 maillage de données 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 attribués directement aux utilisateurs. Les groupes constituent la méthode principale pour attribuer des rôles et des autorisations dans IAM. Les rôles et les autorisations IAM sont attribués lors de la création du projet via le pipeline de base.

Le réseau de données associe des 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 champs d'application des autorisations pour ces groupes sont les suivants:

• Le champ d'application des autorisations du groupe d'infrastructure correspond à la grille de données dans son ensemble.
• Le champ d'application des autorisations des groupes de gouvernance des données est le projet de gouvernance des données.
• Les autorisations des producteurs et des consommateurs basées sur le domaine 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 réseau de données et les autorisations associées.

Infrastructure

Groupe	Description	Rôles
[e-mail]	Administrateurs globaux du réseau 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]	Les 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 les rôles roles/viewer, BigQuery et Data Catalog
[e-mail]	Lecteurs d'informations sur la gouvernance des données	roles/viewer
[e-mail]	Administrateurs de 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	Aucun Il s'agit d'un groupe d'appartenance, et un compte de service est créé avec ce nom, qui 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 pour modifier les entrées Data Catalog
gcp-dm-{data_domain_name}[e-mail]	Les responsables des données du domaine de données	Rôles permettant de gérer les métadonnées et les aspects de 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 sur un projet client	Plusieurs rôles dans le projet client, y compris les rôles roles/viewer et BigQuery
gcp-dm-consumer-{project_name}[e-mail]	Lecteurs des informations sur le projet client	roles/viewer

Structure organisationnelle

Pour différencier 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 désignent les 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 avec l'environnement et ajouter des services via un catalogue de solutions sélectionné. Les environnements d'exploitation sont gérés via des pipelines qui ont codifié l'architecture et la configuration.

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 les projets de niveau supérieur utilisés dans l'architecture de réseau maillé de données d'entreprise.

Le tableau suivant décrit les dossiers et les 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 des ressources du 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 diagramme 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 éléments de données au sein d'une organisation. Le schéma suivant montre 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 flux de données vers BigQuery, Cloud Storage et Pub/Sub. Le projet d'ingestion contient également des exemples de Dataflow et de Cloud Composer que vous pouvez utiliser pour orchestrer la transformation et le transfert 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 des données. Utilisez des balises de règles pour contrôler la présentation des donné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 "consumer" contient les projets clients. Les projets destinés aux 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, auquel est accordé l'accès aux composants de données requis 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 réseau de données d'entreprise.

Architecture du 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 du 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 qui protègent les données sensibles.
Gestionnaire d'enregistrements	Cloud Run	Application qui gère 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èglement sur l'archivage	BigQuery	Table BigQuery contenant la stratégie de stockage des données.
Droits	BigQuery	Table BigQuery qui stocke des informations sur les utilisateurs autorisés à accéder aux données sensibles. Ce tableau garantit que seuls les utilisateurs autorisés peuvent accéder à des données spécifiques en fonction de leurs rôles et de leurs droits.
Composants d'analyse
Perte de données	Protection des données sensibles	Service utilisé pour inspecter les composants afin d'identifier les données sensibles.
Résultats de la protection contre la perte de données	BigQuery	Table BigQuery qui répertorie les classifications de données dans la plate-forme de données.
Règles	BigQuery	Table BigQuery contenant des pratiques de gouvernance des données cohérentes (par exemple, types d'accès aux données).
Exportation de la facturation	BigQuery	Tableau 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 liés à 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 de la protection des données sensibles se produit.
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 incohérences dans les contrôles de gestion des données, tels que des balises manquantes, des classifications incorrectes ou des emplacements de stockage non conformes.
Exportations de tags	BigQuery	Table BigQuery contenant des informations sur les balises 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 les emplacements géographiques où les données peuvent être stockées.
Règles d'accès basées sur des 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 à partir d'emplacements et d'appareils autorisés puissent accéder aux informations sensibles.
Métadonnées	Data Catalog	Service qui stocke des 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	Looker Studio	Tableaux de bord permettant à vos analystes de consulter les rapports générés par les moteurs d'architecture CDMC.

Implémentation du CDMC

Le tableau suivant décrit comment l'architecture implémente les principaux contrôles dans le 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 éléments 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 Looker 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 d'entreprise tels que 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 des informations sur le propriétaire pour assurer la conformité. Ce processus de taggage automatique permet de garantir la gouvernance et la conformité des données en identifiant et en étiquetant les données sensibles avec les informations sur le propriétaire appropriées.
L'approvisionnement et la consommation des données sont régis et soutenus par l'automatisation.	Data Catalog classe les éléments de données en les taguant avec un indicateur is_authoritative lorsqu'ils sont une source faisant autorité. Data Catalog stocke automatiquement les informations, ainsi que les métadonnées techniques, dans un registre de données. Le moteur de rapports et le moteur de tags peuvent valider et générer des rapports sur 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 éléments de données, et 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 balises à l'emplacement réel des composants de données dans BigQuery et publie les écarts en tant que résultats à l'aide de Pub/Sub. Security Command Center fournit 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 éléments de données BigQuery, créant ainsi un catalogue de données 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, et le niveau de sensibilité le plus élevé est attribué en tant que balise 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é, que vous pouvez surveiller et sur laquelle vous pouvez créer des rapports à l'aide de Pub/Sub et d'outils de création de rapports 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, ce qui garantit 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 au data warehouse, 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 disposent de tags de stratégie correspondants. Les écarts sont signalés à l'aide de Pub/Sub pour être corrigés.
L'accès éthique, l'utilisation et les résultats des données sont gérés.	Les contrats de partage des 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 aux éléments de données les informations du contrat du fournisseur, tandis que les contrats des consommateurs sont associés aux liaisons IAM pour le contrôle des accès. Les libellés de requête appliquent des objectifs de consommation, obligeant les consommateurs à spécifier un objectif valide lorsqu'ils interrogent des données sensibles, qui sont validées par rapport à leurs droits d'accès dans BigQuery. Une piste d'audit dans BigQuery suit tous les accès aux données et garantit le respect des accords de partage des 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 aide à 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 des clés améliorée. BigQuery implémente le masquage dynamique des données au niveau des colonnes pour la désidentification et prend en charge la désidentification au niveau de l'application lors de l'ingestion des données. Data Catalog stocke des tags de métadonnées pour les techniques de chiffrement et d'anonymisation appliquées aux éléments de données. Les vérifications automatisées garantissent que les méthodes de chiffrement et de désidentification sont conformes aux règles de sécurité prédéfinies, et que les écarts sont signalés en tant que résultats à 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 de l'objet et les liens vers les rapports d'évaluation. Tag Engine applique ces balises 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 personnes concernées. Ce processus de taggage automatisé permet de surveiller et de signaler en continu le respect des exigences d'évaluation de l'impact, en veillant à ce que des évaluations de l'impact sur la protection des données (AIPD) ou des évaluations de l'impact sur la confidentialité (EIP) soient effectuées si nécessaire.
Le cycle de vie des données est planifié et géré.	Data Catalog attribue des libellés aux éléments de données avec des règles de conservation, en spécifiant les périodes de conservation et les actions d'expiration (par exemple, 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é aux exigences de conservation des données, et détecte et signale les écarts à 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, en mesurant la qualité des données en fonction de métriques telles que la justesse et l'exhaustivité. Les résultats de ces vérifications, y compris les pourcentages et les seuils de réussite, sont stockés sous forme de balises dans Data Catalog. L'enregistrement de ces résultats permet de surveiller et de générer des rapports continuellement sur la qualité des données. Les problèmes ou écarts par rapport aux seuils acceptables sont publiés en tant que résultats à l'aide de Pub/Sub.
Les principes de gestion des coûts sont établis et appliqués.	Data Catalog stocke des métriques liées aux coûts pour les composants de données, tels que les coûts de requête, les coûts de stockage et les coûts de sortie des données, qui sont calculés à l'aide des informations de facturation exportées de Cloud Billing vers BigQuery. Le stockage de métriques liées aux coûts permet de suivre et d'analyser de manière exhaustive les coûts, ce qui garantit le respect des règles de coût et une utilisation efficace des ressources. Les anomalies sont 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 de Data Catalog permettent de suivre la provenance et la traçabilité des éléments de données, en représentant 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 tâches 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énieurs cloud. L'accès d'un utilisateur aux Google Cloud composants de données (par exemple, une table BigQuery) est un problème 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é via 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 éléments de données à partir de Data Catalog.
• Les propriétaires de données sont intégrés au gestionnaire de workflow.

La gestion de l'accès aux données fonctionne comme suit:

1. Un consommateur de données demande un composant spécifique.
2. Le propriétaire des données de l'élément est informé de la requête.
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, l'élément et la balise associée au mappeur IAM.
5. Le mappeur IAM traduit les balises du gestionnaire de workflow en autorisations IAM et attribue au groupe spécifié des autorisations IAM pour l'asset de données.
6. Lorsqu'un utilisateur souhaite accéder à l'asset de données, IAM évalue l'accès à l' Google Cloud asset en fonction des autorisations du groupe.
7. Si l'utilisateur est autorisé, il accède à l'asset de données.

Mise en réseau

Le processus de sécurité des données commence à l'application source, qui peut se trouver sur site ou dans un autre environnement externe au projetGoogle Cloud cible. Avant tout transfert 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 initial et la désidentification 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 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 les services d'ingestion cibles (Cloud Storage, BigQuery et Pub/Sub) 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 de ce projet spécifique.

Journalisation

Cette architecture utilise les fonctionnalités de journalisation Cloud 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 de ressources de l'architecture utilisent Terraform comme outil IaC (Infrastructure as Code) 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 Control
Pipeline d'infrastructure	Pipeline de base	Projets clients Compte de service catalogue de services Déclencheur Cloud Build pour le pipeline du catalogue de services Compte de service du pipeline d'artefacts Déclencheur Cloud Build du 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 codebase utilisé par le maillage de données.

Chaque pipeline possède son propre ensemble de dépôts à partir desquels il extrait du code et des fichiers de configuration. Chaque dépôt comporte une séparation des tâches, où les envois et les approbations des déploiements de code opérationnel sont la responsabilité de différents groupes.

Déploiement interactif via catalogue de services

Les environnements interactifs sont l'environnement de développement 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, et empêchent également vos utilisateurs d'avoir un accès direct aux API Google.

Le diagramme suivant montre les composants de l'environnement interactif et la façon dont les data scientists déploient des 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 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 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 Cloud Composer et Dataflow pour orchestrer le transfert 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 y aient accès. 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, les services et les fonctionnalités de sécurité par défaut configurés via le plan de base de l'entreprise. Google Cloud Google CloudLe schéma suivant illustre la stratification des différents contrôles de sécurité de 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	Google Cloud Implémentation du CDMC	Fournit un framework de gouvernance qui aide à sécuriser, gérer et contrôler vos ressources 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 d'assurer 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	Crée l'infrastructure système.
	Open Policy Agent	Permet de s'assurer que la plate-forme respecte les règles sélectionnées.
Réseau	Private Service Connect	Fournit des protections contre l'exfiltration de données autour des ressources de l'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 adresses IP privées	Aide à réduire 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	Vous n'avez plus besoin d'identifiants externes pour transférer des données sur la plate-forme à partir d'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 via le chiffrement au repos et le chiffrement 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 Google Cloud organisation.
	Architecture continue	Vérifie en permanence votre Google Cloud organisation 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 les règles de pare-feu trop permissives et suggère des pare-feu plus restrictifs pour renforcer votre posture de sécurité globale.
	Cloud Logging	Fournit une 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 une activité suspecte.
Prévention	Règles d'administration	Vous permet de contrôler et de restreindre les actions au sein de votre Google Cloud organisation.

Workflows

Les sections suivantes décrivent le workflow du producteur de données et du consommateur de données, garantissant des contrôles d'accès approprié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 lors de leur transfert 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 au 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 balises sont appliquées 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 suivantes est autorisé:

• Les utilisateurs ayant accès au projet confidentiel peuvent accéder à toutes les données en texte brut brutes.
• 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 du consommateur de données

Les étapes suivantes expliquent 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 éléments qu'il recherche, il demande l'accès aux éléments de données.
3. Le propriétaire des données décide de fournir ou non 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 éléments de données.

Conclusion

Le dépôt GitHub fournit des instructions détaillées sur le déploiement du réseau de données surGoogle Cloud après avoir déployé la base 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 réseau 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 plan 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 réseau de données, copiez les fichiers et les répertoires pertinents de 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 d'initialisation, de planification et d'application Terraform sur chaque dépôt.
   5. Validez vos modifications, transférez le code vers votre dépôt distant, créez des requêtes pull et fusionnez-les dans vos environnements de développement, hors production et 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.
• Découvrez le plan de base de l'entreprise.