Migrer des entrepôts de données vers BigQuery : gouvernance de données

Ce document fait partie d'une série consacrée à la migration de votre entrepôt de données sur site vers BigQuery. Ce document vous aide à comprendre la gouvernance des données et les contrôles dont vous avez besoin.

La série sur la migration comprend les éléments suivants :

Présentation

La gouvernance des données est une approche fondée sur des principes qui permet de gérer le cycle de vie des données de bout en bout, de l'acquisition à la suppression, en passant par leur utilisation. Votre programme de gouvernance des données doit clairement décrire les règles, procédures, responsabilités et contrôles qui régissent les activités relatives aux données. Ce programme contribue à garantir la collecte, la maintenance, l'utilisation et la diffusion des informations de manière à répondre aux besoins d'intégrité des données et de sécurité de votre organisation. En outre, il offre à vos employés la possibilité d'explorer et d'utiliser les données de manière optimale.

Depuis l'ingestion des données jusqu'à leur utilisation pour obtenir des informations précieuses, la gestion et la gouvernance des données doivent être considérées comme primordiales pour toute organisation.

Nous vous recommandons de développer votre pratique en matière de gouvernance des données autour de trois éléments clés :

  • Cadre permettant aux individus de définir, d'accepter et d'appliquer des règles relatives aux données.
  • Processus efficaces de contrôle, de supervision et de gérance de tous les éléments de données des systèmes sur site, de stockage dans le cloud et des plates-formes d'entrepôt de données.
  • Les outils et les technologies appropriés pour superviser et gérer la conformité des règles en matière de données.

Les sections suivantes présentent un cadre de gouvernance des données basé sur la gouvernance des données Gartner dans l'architecture de référence de Data Lake, ainsi que les outils et technologies permettant sa mise en œuvre. Pour en savoir plus sur les besoins de l'entreprise qui sont visés par la gouvernance et les processus d'opérationnalisation de la gouvernance des données, consultez les principes et bonnes pratiques pour la gouvernance des données dans le cloud.

Gérer les accès aux données

Traditionnellement, les entreprises s'appuyaient sur la sécurité du périmètre pour protéger leurs ressources internes. La sécurité périmétrique, également appelée eggshell security (sécurité de type coquille d'œuf) ou castle-and-moat security (sécurité de type douves), suppose que les menaces sont extérieures à ses murs et que tout élément à l'intérieur des murs est fiable. Cette hypothèse s'est avérée incorrecte et a eu des conséquences coûteuses pour les entreprises, car lorsqu'un pirate parvient à accéder au réseau interne, il peut accéder à d'autres systèmes et explorer des éléments de données précieux sans rencontrer presque aucun obstacle.

Les pirates informatiques accèdent aux réseaux internes par le biais de vulnérabilités, de logiciels malveillants installés par les employés, d'ingénierie sociale et d'autres moyens. Cependant, les agents externes malveillants qui créent des ouvertures dans le modèle de sécurité du périmètre ne constituent pas la seule menace. Les employés de confiance peuvent sciemment ou non, modifier, supprimer ou exfiltrer des données lorsque les éléments du réseau interne ne sont pas correctement protégés.

Enfin et surtout, la sécurité du périmètre est devenue de plus en plus complexe en raison de l'évolution du réseau d'entreprise. Par exemple, un périmètre est difficile à mettre en place dans les situations suivantes :

  • Lorsque les employés doivent travailler à distance depuis des réseaux non fiables, tels que des sites clients, des aéroports ou lorsqu'ils travaillent de chez eux.
  • Lorsque les fournisseurs, les partenaires et les sous-traitants ont besoin d'un accès plus direct à vos ressources de données.
  • Lorsque certains des systèmes de l'entreprise sont désormais hébergés dans le cloud.

Si vous migrez à partir d'un entrepôt de données d'entreprise existant sur site, il est possible que le processus actuel d'autorisation d'accès aux requêtes ou à l'affichage des données par les utilisateurs soit complexe ou coûteux, voire les deux. Le transfert vers un entrepôt de données cloud tel que BigQuery offre une sécurité optimale et, de votre côté, une maintenance réduite, car l'infrastructure de sécurité fait partie de l'offre de services gérés.

Le reste de ce document présente et explique comment gérer l'accès aux données sur Google Cloud et BigQuery. Notre objectif est de fournir un aperçu de ce que vous obtenez grâce à cette infrastructure de sécurité lors de la migration de votre entrepôt de données d'entreprise. Les mêmes principes s'appliquent si vous effectuez une migration depuis un autre cloud ou créez vos ressources BigQuery à partir de zéro.

Gestion des ressources

La configuration de vos charges de travail dans Google Cloud nécessite de respecter la structure qui régit toutes les ressources de Google Cloud, ainsi que les consignes spécifiques à chacun de ses produits.

Toutes les ressources de Google Cloud sont organisées de façon hiérarchique. Au niveau le plus bas, vous disposez des composants fondamentaux tels que les ensembles de données BigQuery, les buckets Cloud Storage, les machines virtuelles (VM) Compute Engine, etc. Ces ressources de bas niveau sont regroupées dans des conteneurs logiques appelés projets. Les projets constituent la base de l'utilisation de tous les services Google Cloud. Ils gèrent la facturation et attribuent des rôles et des autorisations aux ressources du projet. Les projets sont à leur tour regroupés dans des dossiers qui peuvent correspondre à différents services ou équipes au sein d'une entreprise. En haut de la hiérarchie se trouve le nœud d'organisation qui représente l'entreprise à laquelle il appartient et qui contient plusieurs dossiers. Pour en savoir plus, consultez la documentation sur la hiérarchie des ressources.

Du point de vue de Google Cloud, les ensembles de données BigQuery se situent au niveau le plus bas de la hiérarchie des ressources. Si on les observe du point de vue de BigQuery, ce sont des conteneurs de premier niveau qui permettent d'organiser et de contrôler l'accès à vos tables et vues. Ils sont similaires en principe aux bases de données ou aux espaces de noms dans les environnements de traitement transactionnel en ligne (OLTP) et de traitement analytique en ligne (OLAP) traditionnels. Au moment de la création, vous choisissez un emplacement pour votre ensemble de données. Une requête ne peut faire référence qu'à des ensembles de données d'un même emplacement. Il est donc important de tenir compte de l'emplacement lors de la création des ensembles de données et de la conception des requêtes.

Framework de sécurité

L'initiative BeyondCorp de Google établit un framework de sécurité basé sur le modèle de sécurité Zero Trust (zéro confiance). Dans ce framework, le principe des contrôles d'accès dynamiques requiert que tout utilisateur ou appareil qui souhaite accéder à une ressource remplisse les critères suivants :

  1. Doit s'authentifier avec ses identifiants.
  2. Doit être autorisé à accéder à cette ressource.
  3. Doit communiquer en employant le chiffrement.

Ces critères doivent être respectés quel que soit l'emplacement du réseau de l'utilisateur ou de l'appareil, qu'il se trouve sur l'intranet de l'entreprise, un réseau Wi-Fi public, un avion, etc.

Les sections suivantes de cet article abordent les concepts et les bonnes pratiques en matière de gestion de l'accès aux données, y compris les principes exposés dans BeyondCorp. Cet article explique également comment mettre en œuvre une superposition de sécurité périmétrique afin d'éviter l'exfiltration.

Authentification et autorisation

L'authentification fait référence au processus de détermination et de vérification de l'identité d'un client interagissant avec BigQuery. L'autorisation fait référence au processus permettant de déterminer les autorisations dont dispose l'identité validée pour interagir avec BigQuery et ses ensembles de données. En résumé, l'authentification vous identifie et l'autorisation détermine ce que vous pouvez faire.

Identité

Sur Google Cloud, Cloud Identity est le fournisseur d'identité intégré. Lors de la migration à partir de votre entrepôt de données sur site, envisagez de fédérer votre fournisseur d'identité existant tel que Microsoft Active Directory avec Cloud Identity. Vous pouvez ensuite continuer à utiliser votre fournisseur d'identité existant pour effectuer les tâches suivantes :

  • Provisionner et gérer des utilisateurs et des groupes.
  • Configurer l'authentification unique.
  • Configurer l'authentification multi-facteurs.

Les utilisateurs de BigQuery sont parfois des individus mais il peut également s'agir parfois d'applications non humaines qui communiquent à l'aide d'une bibliothèque cliente BigQuery ou de l'API REST. Ces applications doivent s'identifier elles-mêmes à l'aide d'un compte de service, le type spécial d'identité Google destiné à représenter un utilisateur non humain.

Cloud Identity est la première partie d'un produit plus vaste appelé Identity and Access Management (IAM).

Une fois qu'un utilisateur a été authentifié, il faut déterminer si l'utilisateur dispose des droits nécessaires pour interagir avec BigQuery et ses ensembles de données.

Gestion des accès

En plus de l'authentification, IAM offre un contrôle centralisé pour accorder aux identités des autorisations spécifiques à BigQuery et ses ensembles de données. IAM gère les règles de sécurité de BigQuery au sein de votre organisation et vous permet d'accorder l'accès aux ressources BigQuery de façon ultraprécise, et pas juste au niveau du projet.

Dans IAM, les autorisations déterminent les opérations autorisées sur une ressource, mais vous ne pouvez pas les attribuer directement aux identités Google (utilisateurs, comptes de service, groupes Google, domaines Google Workspace ou Cloud Identity). À la place, vous attribuez des rôles (ensembles d'autorisations) aux identités Google et utilisez une stratégie (déclarée dans un fichier JSON ou YAML) pour appliquer ces liaisons à l'un des niveaux de ressources Google Cloud suivants :

  • Organisation
  • Dossier
  • Projet
  • Niveau de ressource (ensembles de données BigQuery)

Les rôles BigQuery peuvent être liés à n'importe lequel des niveaux de ressources répertoriés ci-dessus, par exemple :

  • Au niveau du projet, un utilisateur peut avoir les rôles suivants : admin, metadataViewer, jobUser.
  • Au niveau de la ressource d'ensemble de données BigQuery, un utilisateur (ou une vue) peut avoir les rôles suivants : dataEditor, dataOwner ou dataViewer.
IAM pour les tables et les vues

BigQuery vous permet d'attribuer des rôles individuels à certains types de ressources dans des ensembles de données (tables et vues par exemple) sans avoir à fournir un accès complet aux ressources de l'ensemble de données. Les autorisations au niveau de la table déterminent les utilisateurs, les groupes et les comptes de service autorisés à accéder à une table ou à une vue.

Pour plus d'informations sur le contrôle des accès aux tables et aux vues, consultez la page Présentation des contrôles d'accès aux tables.

Les rôles ne peuvent pas être appliqués aux ressources individuelles suivantes : routines ou modèles.

Vous pouvez également utiliser une vue autorisée pour accorder à des utilisateurs spécifiques l'accès aux résultats de requête, sans leur donner accès aux tables sous-jacentes. Utilisez des vues autorisées pour restreindre l'accès à un niveau de ressource inférieur, tel qu'une table, une colonne, une ligne ou une cellule. Cependant, les mises en œuvre modernes de sécurité au niveau des colonnes et de sécurité au niveau des lignes sont toutes deux des formes de classification de données qui sont recommandées en lieu et place des vues autorisées pour cette utilisation, même si ce sont vos besoins et votre situation spécifiques qui déterminent au final les méthodes les plus adaptées.

IAM pour les points de terminaison

IAM vous permet de gérer l'authentification et l'autorisation en fonction des identités. Il permet également de créer un périmètre sécurisé autour de services qui ont des points de terminaison publics, tels que BigQuery. Pour plus d'informations sur cette méthode de contrôle d'accès, consultez la section sur la sécurité réseau.

Méthodes de mise en œuvre

Lors d'une migration, vous êtes souvent amené à connecter une application sur site à BigQuery. Exemples de circonstances dans lesquelles cet accès est requis :

  • Pipelines de données sur site qui chargent des données dans BigQuery.
  • Rapports sur site, analyses ou autres applications d'entreprise qui interrogent ou extraient des données à partir de BigQuery.

Pour accéder aux données de BigQuery, une application doit obtenir et envoyer des identifiants avec les requêtes d'API. Les identifiants de courte durée ou de longue durée peuvent être utilisés pour interagir avec l'API BigQuery à partir d'une application sur site ou d'une autre application cloud publique.

Un client BigQuery doit être authentifié à l'aide d'un compte de service ou des identifiants d'un utilisateur. Une fois qu'un client est authentifié, un jeton d'accès ou une clé doit être transmis à l'API BigQuery. Ces identifiants sont ensuite vérifiés afin de vérifier que le client dispose des autorisations IAM suffisantes pour toutes ses interactions avec BigQuery.

Identifiants de courte durée

Les identifiants de courte durée expirent automatiquement après une courte durée (durée maximale de 1 heure pour OAuth2.0 et OpenID, 12 heures pour JWT), qui est spécifiée au moment de la création. Si vous souhaitez éviter de gérer des clés de compte de service ou que vous souhaitez émettre des licences avec expiration dans les services Google Cloud, utilisez des identifiants de courte durée.

Les types d'identifiants suivants peuvent être définis comme étant de courte durée :

  • Jetons d'accès OAuth 2.0
  • Jetons d'identification OpenID Connect
  • Jetons Web JSON (JWT) autosignés
  • Objets binaires (blobs) autosignés

Les identifiants de courte durée permettent aux services sur site de communiquer avec BigQuery sans avoir besoin d'une identité Google Cloud. Bien qu'une identité Google Cloud doive obtenir des identifiants de courte durée, l'application ou le service qui utilise le jeton n'a pas besoin d'une identité Google Cloud.

Identifiants de longue durée

Les identifiants de longue durée (clés privées de compte de service ou jetons d'accès OAuth 2.0 avec jetons d'actualisation, par exemple) autorisent l'accès à BigQuery tant qu'ils ne sont pas supprimés ou révoqués. Une fois créées, les clés privées du compte de service ne nécessitent pas d'actualisation. Les jetons d'accès OAuth 2.0 ont une date d'expiration, mais ils peuvent être utilisés sur une longue durée grâce à un jeton d'actualisation. Ce jeton d'actualisation vous permet de demander de nouveaux jetons d'accès (sans nécessiter de nouvelle authentification) tant que le jeton d'actualisation reste actif. Ce processus est illustré dans OAuth 2.0 Playground de Google.

Compte tenu de leur durée de vie étendue, faites preuve de prudence lorsque vous gérez les identifiants de longue durée sur les machines clientes distantes ou les nœuds de calcul. Nous vous recommandons de les stocker dans un emplacement sûr qui limite l'accès aux seuls utilisateurs autorisés. Ne jamais stocker d'identifiants dans un dépôt de code : toute personne ayant accès à votre code aurait également accès à votre clé et, par conséquent, à vos données. En cas de fuite d'identifiants, vous pouvez utiliser les périmètres de service pour limiter le risque d'accès indésirable provenant de l'extérieur.

Voici quelques stratégies recommandées pour le stockage des identifiants de longue durée :

  • Cloud Storage avec ou sans service de gestion des clés (Key Management Service, KMS)
  • Stockage sécurisé sur site
  • Solution tierce de gestion d'informations secrètes

Une clé privée de compte de service est un jeton JWT signé de manière cryptographique qui appartient à un compte de service individuel. Le jeton JWT signé est directement utilisé en tant que jeton de support. Par conséquent, une demande réseau adressée au serveur d'autorisation de Google n'est pas nécessaire. Étant donné que les clés n'expirent pas automatiquement ou ne sont pas révoquées en cas de fuite, il est recommandé de faire pivoter les clés régulièrement. Ce processus nécessite la génération d'une nouvelle clé, en veillant à ce que tous les utilisateurs et services autorisés aient accès à la nouvelle clé et en supprimant l'ancienne. La rotation des clés garantit que si une clé est piratée, l'accès de la clé piratée à BigQuery sera automatiquement révoqué, même si la fuite n'est pas détectée.

Requêtes BigQuery non anonymes

Les clés de compte de service privé et les jetons d'actualisation sont compatibles avec l'authentification via les comptes de service. Plusieurs utilisateurs et applications peuvent avoir accès au même compte de service. Ces requêtes sont donc anonymes, car l'utilisateur ou l'application ne peuvent pas être identifiés. Cependant, de nombreuses entreprises clientes exigent que l'accès aux ressources Google Cloud, telles que BigQuery, soit attribuable à l'utilisateur ayant émis la requête. Dans ce cas, vous pouvez utiliser le flux d'autorisation à trois acteurs (3LO) OAuth 2.0 pour une authentification au nom d'un utilisateur final plutôt qu'au nom d'un compte de service.

Dans un flux à deux acteurs, une application détient directement les identifiants d'un compte de service et appelle l'API BigQuery au nom de ce compte de service. Cependant, dans un flux à trois acteurs, le propriétaire de la ressource donne à un client l'accès aux ressources BigQuery sans partager directement ses identifiants ; les requêtes sont effectuées au nom de l'utilisateur et le consentement de l'utilisateur est parfois requis. Une fois l'authentification de l'utilisateur effectuée, un code d'autorisation peut être échangé contre un jeton d'accès et un jeton d'actualisation.

Sécurité du réseau

Un réseau cloud privé virtuel s'apparente à un réseau physique, mais est virtualisé dans Google Cloud. Vous définissez des règles de pare-feu au niveau du réseau pour contrôler le trafic vers et depuis vos instances de machine virtuelle. Cependant, vous ne pouvez pas définir de règles de pare-feu pour les services basés sur les API, tels que BigQuery ou Cloud Storage. Pour ces types de services, vous pouvez utiliser Google VPC Service Controls afin de limiter le trafic.

Un VPC définit des périmètres de service autour de services basés sur des API Google qui ont un point de terminaison public, tel que BigQuery ou Cloud Storage. Les périmètres de service atténuent les risques d'exfiltration des données en limitant la sortie et l'entrée des données entre les ressources à l'intérieur du périmètre et les ressources en dehors du périmètre. Lorsque vous mettez en œuvre ces contrôles correctement, les réseaux non autorisés ne peuvent pas accéder aux données et aux services, et les données ne peuvent pas être copiées vers des projets Google Cloud non autorisés. Une communication libre peut toujours se produire dans le périmètre, mais la communication est limitée sur tout le périmètre.

Nous vous recommandons d'utiliser VPC Service Controls conjointement avec les contrôles d'accès IAM. Alors que IAM offre un contrôle des accès détaillé basé sur les identités, VPC Service Controls permet une sécurité de périmètre contextuelle plus large.

Contrôle contextuel des accès

Les requêtes API provenant du réseau Internet public sont autorisées ou non à accéder aux ressources d'un périmètre de service en fonction des niveaux d'accès de ce périmètre. Les requêtes sont classées en fonction du contexte du client, telles que les plages d'adresses IP et les identités d'utilisateur ou de compte de service. Par exemple, si une requête API BigQuery provient d'un identifiant valide, mais d'un réseau non fiable, l'accès au réseau VPC et au périmètre de service peut être refusé.

Une requête API BigQuery provenant d'un identifiant valide mais d'un réseau non fiable peut se voir refuser l'accès au réseau VPC et au périmètre de service.

Périmètres de service

Les périmètres de service VPC sont configurés au niveau de l'organisation Google Cloud. Les règles de sécurité peuvent donc être gérées de manière centralisée. Plusieurs projets au sein de cette organisation et de ces services (par exemple, l'API BigQuery) peuvent être affectés à chaque périmètre. Les projets et les données d'un même périmètre de service peuvent traiter, transformer et copier des données de manière flexible, tant que ces actions restent à l'intérieur du périmètre. Le schéma suivant montre comment utiliser les périmètres de service.

Traiter, transformer et copier les données dans le même périmètre de service.

Si les ressources Google Cloud de différents périmètres de service doivent communiquer (par exemple, BigQuery au sein d'un projet et d'un périmètre de service spécifiques et Compute Engine dans d'autres), vous pouvez créer une liaison de périmètre au niveau de l'organisation. Une liaison de périmètre permet la communication entre les ressources Google Cloud sur plusieurs périmètres de service. Bien qu'un projet Google Cloud ne puisse appartenir qu'à un seul périmètre de service, il peut faire partie de plusieurs liaisons de périmètre.

Accès aux données dans des environnements hybrides

Pour les environnements hybrides sur site et les environnements cloud, vous pouvez configurer l'accès privé à Google pour les réseaux locaux afin de permettre une communication privée entre le périmètre de service et les environnements sur site. Cela peut permettre aux environnements sur site d'accéder aux ensembles de données BigQuery. Ces requêtes doivent être envoyées via une connexion privée avec Google Cloud, qui peut être soit un VPN basé sur le routage, soit une connexion Cloud Interconnect. Les requêtes ne traversent pas le réseau Internet public.

Cette configuration étend le périmètre de service des réseaux sur site aux données stockées dans les services Google Cloud, garantissant ainsi la confidentialité des données sensibles. Vous ne pouvez utiliser cette configuration de communication privée que pour les API sur restricted.googleapis.com. Le schéma suivant illustre un exemple de cette configuration.

Extension du périmètre de service des réseaux sur site aux données stockées dans les services Google Cloud

Chiffrement

Lorsque vous examinez le mode de stockage et de transit des données dans Google Cloud et BigQuery par rapport à votre entrepôt de données sur site, il est utile de reconsidérer le framework de sécurité.

Selon le principe des contrôles d'accès dynamiques de BeyondCorp, tous les accès doivent être chiffrés. Il est donc essentiel d'adopter le chiffrement comme méthode de protection des données pour garantir que les données ne seront pas lisibles au repos ou en transit, même dans le cas improbable d'exposition de données. De cette façon, le chiffrement renforce la protection des données.

Chiffrement au repos

Google Cloud chiffre par défaut les données stockées au repos, sans aucune action supplémentaire de votre part. La norme AES (Advanced Encryption Standard) est utilisée pour chiffrer les données au repos, conformément aux recommandations du National Institute of Standards and Technology.

Avant d'être écrites sur le disque, les données d'un ensemble de données BigQuery sont divisées en plusieurs fragments. Chaque fragment est chiffré avec une clé de chiffrement de données unique. En utilisant des clés différentes, le "rayon d'impact" (blast radius) ne concerne que ce fragment de données dans le cas peu probable où les clés de chiffrement seraient compromises. Ces clés sont ensuite elles-mêmes chiffrées à l'aide de clés de chiffrement de clé uniques (KEK). Alors que les DEK chiffrées sont stockées à proximité des données associées, les KEK sont stockées de manière centralisée dans le Cloud Key Management Service (KMS). Cette méthode hiérarchique de gestion des clés est appelée chiffrement encapsulé. Pour plus d'informations, consultez la section sur la gestion des clés de l'article sur le chiffrement au repos.

Le schéma suivant illustre le fonctionnement du chiffrement au repos.

Chiffrement au repos.

Par défaut, toutes les clés sont gérées par Google. Toutefois, vous pouvez choisir de gérer vous-même les clés. Cette technique est connue sous le nom de "Clés de chiffrement gérées par le client" (Customer Managed Encryption Keys, CMEK). Avec cette technique, vous utilisez Cloud KMS pour créer, faire pivoter, faire pivoter automatiquement et détruire les clés de chiffrement symétriques. Pour plus d'informations sur l'utilisation de CMEK avec BigQuery, consultez la section Protéger des données avec des clés Cloud KMS.

Chiffrement en transit

Google Cloud chiffre et authentifie toutes les données en transit lorsque les données sortent des limites physiques contrôlées par Google ou pour le compte de Google. À l'intérieur de ces limites, les données en transit sont généralement authentifiées, mais pas nécessairement chiffrées.

Une fois une connexion établie et authentifiée, le chiffrement en transit protège vos données contre des pirates potentiels en :

  • supprimant la nécessité d'approuver les couches inférieures du réseau, qui sont généralement fournies par des tiers ;
  • empêchant les pirates d'accéder aux données lorsque des communications sont interceptées.

À un niveau élevé, le chiffrement en transit fonctionne comme suit : vos données sont chiffrées avant la transmission ; puis les points de terminaison sont authentifiés. Lorsque les données atteignent leur destination, elles sont déchiffrées et validées. Néanmoins, les méthodes de sécurité utilisées dépendent du type de connexion sécurisée. Cette section porte sur l'utilisation du chiffrement pour sécuriser les connexions vers et depuis BigQuery.

BigQuery est un service Google Cloud. Ainsi, lorsqu'un utilisateur ou une application lui envoie une requête, celle-ci atteint d'abord un système distribué dans le monde entier et appelé Google Front End (GFE). GFE interrompt le trafic entrant HTTP(S), TCP et TLS, fournit des contre-mesures contre les attaques DDoS, gère le routage et l'équilibrage de charge du trafic vers n'importe quel service.

Vous devez tenir compte du fait que le trafic vers ou depuis un service Google Cloud peut nécessiter la mise en place de mesures de sécurité supplémentaires. Ces mesures sont pertinentes lorsque vous effectuez la migration de vos processus en amont et en aval. Par exemple, les requêtes entre un utilisateur ou une application vers une application personnalisée hébergée sur Google Cloud peuvent être acheminées de plusieurs manières. En général, si vous utilisez Cloud Load Balancing, le trafic passe par le GFE. Cet itinéraire appartient donc à la catégorie précédente. Si vous utilisez Cloud VPN, la connexion est protégée par IPsec. En revanche, si vous vous connectez directement à une VM à l'aide d'une adresse IP externe, d'une adresse IP d'équilibreur de charge réseau ou de Cloud Dedicated Interconnect, la connexion n'est pas chiffrée par défaut. Par conséquent, nous vous recommandons vivement d'utiliser un protocole de sécurité tel que TLS.

Pour en savoir plus sur la manière dont Google Cloud gère le chiffrement en transit pour chaque flux de connexion, consultez la page Chiffrement en transit dans Google Cloud.

Crypto-suppression

En plus du chiffrement fourni par défaut par Google, votre application peut utiliser son propre chiffrement si nécessaire, par exemple lors du masquage de données de colonnes spécifiques dans une table ou lorsque la crypto-suppression est requise.

La crypto-suppression (crypto-shredding) est un processus qui consiste à supprimer la clé utilisée pour chiffrer des données afin de rendre ces données illisibles. Les données ne pouvant plus être déchiffrées, elles sont supprimées.

Étant donné que ce processus requiert la suppression de la clé uniquement et non l'ensemble des données chiffrées, cette méthode de suppression est rapide, permanente et couramment utilisée dans les cas suivants :

  • Lorsque les données chiffrées sont beaucoup plus volumineuses que la clé, par exemple dans les disques, les téléphones et les enregistrements de base de données chiffrés.
  • Lorsque la suppression des données chiffrées est trop coûteuse, complexe ou irréalisable, par exemple pour des données réparties dans de nombreux dépôts ou dans un espace de stockage non modifiable.

BigQuery fournit des fonctions permettant de créer des clés et de chiffrer et déchiffrer des données dans vos requêtes à l'aide des concepts de chiffrement AEAD.

Découverte de données

Le volume, la variété et la vitesse des données disponibles pour les organisations de toutes tailles sont en hausse. Cette prolifération des données présente plusieurs défis :

  • Les données sont de plus en plus difficiles à trouver, car elles sont dispersées, pas toujours organisées et souvent dupliquées dans plusieurs dépôts de données.
  • Même lorsque vous trouvez des données, l'origine des données n'est pas claire. Vous ne savez pas si elles correspondent vraiment à ce que vous recherchiez et si elles sont suffisamment fiables pour engendrer une décision commerciale.
  • Les données deviennent également difficiles à gérer. Il est difficile de savoir qui est le propriétaire d'une donnée, qui a accès aux données et quel est le processus d'accès aux données.

Les métadonnées sont des attributs qui décrivent les données et répondent aux questions soulevées ci-dessus. La collecte de métadonnées s'apparente à la création d'un catalogue de fiches pour une bibliothèque, où chaque livre est associé à une fiche physique indiquant son auteur, l'année de publication, l'édition, le thème, etc. Comme un livre, une donnée peut également être associée à un ensemble d'attributs, tels que son propriétaire, son origine, sa date de traitement ou son niveau de qualité.

Traditionnellement, les entreprises tentaient de capturer et d'organiser leurs métadonnées à l'aide de plusieurs méthodes : feuilles de calcul, pages wiki, systèmes développés en interne et logiciels tiers. Cela pose les problèmes suivants : saisie manuelle, traitement et maintenance, et compatibilité et portée du système. Dernier problème : la découverte des données et la collecte de métadonnées sont souvent des processus naturels qui reposent sur des expériences personnelles transmises d'une personne à une autre, ce qui n'est pas évolutif pour une organisation en plein développement. Dans ce contexte, comment un analyste extérieur à ce groupe de personnes découvre-t-il les données auxquelles il peut accéder et la façon de les interpréter ?

En plus de ces défis internes, les entreprises sont confrontées à une hausse des exigences réglementaires et de conformité telles que le règlement général sur la protection des données (General Data Protection Regulation, RGPD), les exigences du Comité de Bâle sur le contrôle bancaire 239 (Basel Committee for Banking Supervision 239, BCBS239) et la loi de confidentialité des informations des établissements de santé (Health Insurance Portability and Accountability Act. HIPAA) qui les obligent à effectuer le suivi de leurs données, à les sécuriser et à générer des rapports les concernant.

Google Cloud répond à ces besoins grâce à Data Catalog, un service de gestion des métadonnées entièrement géré et évolutif qui permet à votre organisation de découvrir, classer et comprendre vos données dans Google Cloud.

L'architecture du catalogue de données repose sur les éléments suivants :

  • Magasin de métadonnées : basé sur Cloud Spanner, la base de données cohérente distribuée à l'échelle mondiale pour le stockage de toutes les entrées de métadonnées.
  • Synchroniseurs en temps réel et par lots : pour l'intégration automatique de métadonnées techniques.
  • Index de recherche Google : grâce à la même technologie opérant les recherches Gmail et Google Drive, ce système évolutif et performant intègre des listes de contrôle d'accès (LCA).

Data Catalog vous offre une vue unifiée de tous vos éléments de données. Par conséquent, cela permet de créer un processus de gouvernance des données fiable.

Le schéma suivant illustre une architecture simplifiée, avec Data Catalog offrant des fonctionnalités de métadonnées, de recherche et de prévention contre la perte de données pour BigQuery, Pub/Sub et Cloud Storage. Ces fonctionnalités sont décrites dans les sections suivantes.

Architecture simplifiée à l'aide de Data Catalog pour fournir des métadonnées ainsi que des fonctions de recherche et pour empêcher les pertes de données.

Métadonnées

La capacité à trouver les bonnes données pour prendre des décisions est au cœur du processus de découverte des données. Comme dans l'analogie de la bibliothèque, où pour trouver un livre vous devez disposer des métadonnées sur les livres disponibles dans cette bibliothèque, dans le monde des données, vous devez également disposer de métadonnées sur vos données pour pouvoir les trouver.

Data Catalog peut ingérer automatiquement les métadonnées de BigQuery, Pub/Sub et Cloud Storage. Il distingue également deux types de métadonnées : les métadonnées techniques et commerciales.

D'une part, les métadonnées techniques incluent des informations telles que les noms des tables, les noms des colonnes, les descriptions et les dates de création. Ce type de métadonnées est déjà présent dans le système source. Data Catalog ingère automatiquement les métadonnées techniques dans son index, dès que ces éléments sont créés, sans que vous ayez manuellement à enregistrer de nouveaux éléments de données.

En revanche, les éléments de données sont associées à un contexte commercial implicite, tel que de savoir si une colonne contient des informations personnelles identifiables (PII), savoir qui est le propriétaire de l'élément de données, savoir si il s'agit d'une date de suppression ou de conservation et identifier le niveau de qualité des données. Ce type de métadonnées est appelé métadonnées commerciales.

Les métadonnées commerciales sont plus complexes que les métadonnées techniques, car en fonction de leur rôle, les utilisateurs sont intéressés par différents sous-ensembles de l'aspect commercial. Par exemple, un analyste de données peut être intéressé par l'état d'une tâche ETL : a-t-elle été exécutée correctement, combien de lignes ont-elles été traitées, contenait-elle des erreurs ou des avertissements, etc. Un chef de produit peut être intéressé par la classification des données : publique ou privée, l'état actuel de son cycle de vie (production, test, contrôle qualité), son exhaustivité, son niveau de qualité, etc.

Pour gérer ces complexités, Data Catalog vous permet de regrouper des métadonnées commerciales dans des modèles. Un modèle est un groupe de paires clé/valeur de métadonnées appelé attributs. Disposer d'un ensemble de modèles s'apparente à disposer d'un schéma de base de données pour vos métadonnées.

Les tags de métadonnées sont des instances de modèles qui peuvent être appliquées à la fois aux tables et aux colonnes. Lorsque ces tags sont appliqués à des colonnes, les utilisateurs peuvent déterminer, par exemple, si une colonne contient des informations personnelles, si elles sont obsolètes et quelle formule a été utilisée pour calculer une certaine quantité. En substance, les métadonnées commerciales fournissent le contexte nécessaire afin d'utiliser les données de manière significative.

Le schéma suivant illustre un exemple de table de clients (cust_tbl) ainsi que plusieurs tags de métadonnées commerciales associées à cette table et à ses colonnes.

Exemple de table client

En plus d'une interface utilisateur intuitive, Data Catalog fournit également une API permettant aux utilisateurs techniques d'annoter ou de récupérer des métadonnées de manière groupée. Les langages acceptés sont Python, Java et NodeJS. L'API vous permet non seulement de mettre à l'échelle vos tâches de métadonnées, mais également de les intégrer à Data Catalog, ce qui ouvre la voie à la création d'applications d'entreprise personnalisées qui utilisent Data Catalog dans le cadre de leur backend.

L'ajout de métadonnées à vos éléments de données est la base de la découverte de données, mais ce n'est que la moitié du processus. L'autre moitié consiste à pouvoir découvrir un élément grâce à une fonctionnalité de recherche performante qui utilise à la fois des métadonnées techniques et commerciales pour obtenir des résultats pertinents.

Data Catalog indexe toutes les métadonnées de ses sources et les rend disponibles via une interface utilisateur conviviale et une API pour l'intégration par programme. Ce service fonctionne comme avec une recherche Google, en utilisant des mots clés correspondant aux métadonnées. En outre, il propose également une fonctionnalité de recherche par attribut pour les utilisateurs expérimentés. Grâce à ses filtres intuitifs et à ses prédicats qualifiés, la recherche par attribut permet aux utilisateurs d'affiner les résultats. Par exemple, ils peuvent ne rechercher que des tables, des ensembles de données ou des fichiers, ou encore n'effectuer des recherches que dans un projet, une organisation ou un produit Google Cloud spécifique.

Dans son interface utilisateur, Data Catalog affiche également une liste des tables BigQuery fréquemment recherchées. Cette fonctionnalité permet d'accéder rapidement aux détails de la table, au schéma et à la console BigQuery.

Contrôle des accès

En permettant à vos utilisateurs d'effectuer des recherches dans les métadonnées et de découvrir des éléments de données, vous leur permettez d'être plus productifs, indépendants et impliqués. Cependant, tout le monde ne doit pas forcément avoir accès à toutes les métadonnées. Lorsque les bonnes personnes ont accès aux bonnes données, vous permettez à vos employés de se concentrer sur un sous-ensemble d'éléments de données adaptés à leurs rôles respectifs.

Data Catalog est intégré à IAM, ce qui vous permet de contrôler quels utilisateurs peuvent trouver les données sélectionnées dans leurs recherches ou créer des métadonnées métier pour les éléments.

Pour les métadonnées techniques, afin de simplifier la gestion des accès, l'intégration automatique applique le même ensemble d'autorisations aux métadonnées accordées aux données qui ont des tags. Si un utilisateur a accès aux données, il a également accès aux métadonnées techniques extraites et peut rechercher les éléments de données à l'aide d'une recherche dans Data Catalog. Cette méthode offre un choix par défaut raisonnable qui ne nécessite aucune intervention manuelle, par opposition à l'attente de l'enregistrement d'un élément de données et à l'octroi d'un ensemble distinct d'autorisations.

Pour les métadonnées commerciales, vous définissez quels utilisateurs ou groupes d'utilisateurs ont accès aux métadonnées. Certains de ces utilisateurs auront accès aux métadonnées ou/et aux données, ou bien à aucune de ces informations.

  • S'ils n'ont pas accès aux métadonnées, ils ne peuvent pas trouver les éléments de données lors des recherches dans Data Catalog.
  • S'ils ont accès aux métadonnées, mais pas aux données, ils pourront trouver les éléments de données, mais ne pourront pas lire les données. Cette fonctionnalité permet aux utilisateurs de découvrir des ensembles de données utiles sans exposer les données sous-jacentes, ce qui facilite l'utilisation des données d'une organisation sans compromettre la sécurité. Les utilisateurs peuvent ensuite envoyer des requêtes d'accès aux propriétaires de données, qui peuvent être approuvées ou refusées en fonction de l'utilisation commerciale, de la sensibilité des données et d'autres facteurs.

Cette section explique comment Data Catalog s'intègre à IAM pour assurer le contrôle des accès sur les métadonnées. De plus, vous pouvez contrôler qui a accès à Data Catalog en attribuant des rôles Data Catalog à vos utilisateurs. Pour contrôler l'accès à vos éléments de données, utilisez conjointement IAM et VPC Service Controls. Pour plus d'informations, consultez la documentation IAM Data Catalog.

Traçabilité

Dans le contexte de l'entrepôt de données, la traçabilité fait référence au chemin emprunté par un élément de données entre son origine et sa destination. L'origine d'un élément de données peut être une source externe telle que des données de marché fournies par un tiers ou une source interne telle qu'une base de données relationnelle stockant des transactions client. La destination de l'élément de données peut être un tableau de bord, un rapport ou un flux de données exposé en tant qu'API.

Dans tous ces cas, il est important de savoir que les données présentées à destination reflètent fidèlement les transformations appliquées aux données d'origine. De plus, les utilisateurs de données doivent pouvoir faire confiance aux données reçues, les autorités de régulation doivent vérifier et comprendre les données transmises et les acteurs internes doivent identifier les lacunes dans les processus commerciaux et les interrelations des processus de traitement des données.

Les données à collecter dépendent de vos besoins commerciaux. Elles peuvent inclure des métadonnées telles que la source des données d'origine, les propriétaires des données, le processus commercial où l'élément de données est transformé ou encore les applications et services impliqués lors des transformations.

La capture manuelle de ces informations est sujette aux erreurs et non adaptable aux cas particuliers. Par conséquent, nous vous recommandons d'aborder la traçabilité de données d'un point de vue faisant appel à l'automatisation :

  • Déterminez l'ensemble des attributs de métadonnées que vous allez capturer afin de répondre à vos besoins commerciaux ou réglementaires.
  • Créez des modèles pour capturer ces métadonnées commerciales. Data Catalog accepte cinq types de données que vous pouvez combiner pour créer des tags enrichis : double, string, boolean, datetime et enum. Ce dernier type peut utiliser un ensemble de valeurs personnalisées pour décrire une étape de la transformation de données ou des valeurs énumérées similaires.
  • Utilisez l'API Data Catalog pour enregistrer les métadonnées de traçabilité pertinentes à chaque étape pertinente de votre pipeline de données.

Outre Data Catalog, Cloud Data Fusion, la version gérée de CDAP de Google, peut vous aider à mettre en œuvre la transformation de vos données. Cloud Data Fusion encapsule l'environnement de traitement des données dans un environnement contrôlé unique, ce qui permet d'enregistrer automatiquement la traçabilité au niveau de l'ensemble de données et du champ. Pour plus d'informations, consultez la documentation CDAP sur la traçabilité.

Classification et gestion des données

Dans un entrepôt de données d'entreprise, le volume, la vélocité et la variété de données ingérées peuvent compliquer la classification et la gestion des données.

La classification des données consiste à catégoriser les données en types, formulaires ou catégories en utilisant leurs caractéristiques distinctes. Il est essentiel que vous puissiez classer vos données de manière efficace afin d'appliquer les règles de gouvernance appropriées aux différents types de données.

Par exemple, selon le contenu d'un document commercial, vous pouvez le classer selon un niveau de sensibilité comme par exemple non sécurisé ou confidentiel. Chacun de ces types peut ensuite être associé à des règles spécifiques de gestion par exemple : les documents confidentiels ne sont accessibles qu'à certains groupes d'utilisateurs et doivent être conservés pendant sept ans.

Plusieurs aspects sont à prendre en compte en ce qui concerne la gestion des données :

  • Gestion de la modification des données : contrôlez les effets dus aux changements de dimensions des données. Même si les dimensions changent peu souvent, la modification obtenue peut entraîner des répercussions, car les données des tables de faits peuvent ne plus correspondre aux dimensions mises à jour.
  • Gestion des données de référence : assurez-vous que tous les systèmes de votre organisation disposent d'une vue précise et cohérente de vos données de référence.
  • Conservation et suppression : empêchez les utilisateurs de modifier ou de supprimer des données et faire expirer automatiquement des données.

Lorsque vous migrez vers BigQuery, profitez des fonctionnalités automatisées de classification des données, telles que Cloud Data Loss Prevention (DLP). Les sections suivantes présentent des fonctionnalités et des techniques qui vous aideront à résoudre ces problèmes de classification et de gestion des données dans Google Cloud.

Prévenir la perte de données

De nombreuses organisations possèdent des milliers de tables avec des centaines de colonnes. Certaines de ces tables ont même des noms de colonne, tels que Column_5, qui sont incorrects ou non descriptifs, mais qui contiennent des informations personnelles. Ces faits compliquent l'identification des informations personnelles et l'application de règles aux données.

Cloud DLP vous donne accès à une puissante plate-forme d'inspection, de classification et de suppression d'identification des données. L'API DLP analyse automatiquement les données et crée des tags Data Catalog pour identifier les données sensibles. Elle peut être utilisée dans vos tables BigQuery existantes, vos buckets Cloud Storage ou vos flux de données.

Cloud DLP peut analyser vos données et identifier les informations personnelles, telles que les e-mails, les numéros de carte de paiement, les numéros de sécurité sociale et les signale automatiquement en imputant un degré de confidence (par exemple 99 %) ce qui permet de traiter automatiquement de grandes quantités de données. Pour simplifier la reconnaissance des informations personnelles dans votre pipeline ETL/ELT, vous pouvez effectuer les opérations suivantes :

  • Ingérez les données dans un bucket de zone de quarantaine.
  • Exécutez Cloud DLP pour identifier les informations personnelles. Pour ce faire, vous pouvez analyser l'intégralité de l'ensemble de données ou échantillonner les données. L'API DLP peut être appelée à partir des étapes de transformation de votre pipeline ou à partir de scripts autonomes, tels que Cloud Functions. Cet article présente un exemple utilisant la deuxième option.
  • Déplacez les données vers l'entrepôt.

Cloud DLP est fourni avec plus d'une centaine de détecteurs prédéfinis pour identifier les modèles, les formats et les sommes de contrôle. Cloud DLP fournit également un ensemble d'outils permettant de supprimer l'identification de vos données, y compris le masquage, la tokenisation, la pseudonymisation, le décalage de date, etc. Ce service permet également de créer des détecteurs personnalisés à l'aide d'un dictionnaire ou d'une expression régulière. Vous pouvez ajouter des règles "Hotword" (avec mot clé) pour améliorer la précision des résultats et définir des règles d'exclusion afin de réduire le nombre de faux positifs.

L'utilisation de Cloud DLP permet d'améliorer la gouvernance des données en vous aidant à classer vos données et à accorder le bon accès aux bonnes personnes.

Sécurité au niveau des colonnes

Se basant sur le concept de classification des données, BigQuery fournit un accès précis aux colonnes sensibles à l'aide de tags avec stratégie, une classification basée sur le type de vos données. Grâce à la sécurité au niveau des colonnes de BigQuery, vous pouvez créer des stratégies qui vérifient, au moment de la requête, si un utilisateur dispose d'un accès approprié.

Pour en savoir plus sur l'utilisation des tags avec stratégie pour la sécurité au niveau des colonnes, consultez la page Présentation de la sécurité au niveau des colonnes de BigQuery.

Sécurité au niveau des lignes

La sécurité au niveau des lignes vous permet de filtrer les données et d'accéder à des lignes spécifiques d'une table, en fonction des conditions éligibles de l'utilisateur. La sécurité au niveau des lignes étend le principe du moindre privilège en permettant un contrôle d'accès précis à un sous-ensemble de données d'une table BigQuery, au moyen de règles d'accès au niveau des lignes. Les stratégies d'accès au niveau des lignes peuvent coexister avec la sécurité au niveau des colonnes sur une table.

Pour en savoir plus sur l'utilisation des règles d'accès aux lignes pour la sécurité au niveau des lignes, consultez Présentation de la sécurité au niveau des lignes de BigQuery.

Gestion des données de référence

Les données de référence, en anglais master data, sont des données utilisées dans toute l'organisation. Les clients, les produits, les fournisseurs, les zones géographiques et les comptes sont des exemples courants d'éléments de données de référence. La gestion des données de référence (Master Data Management, MDM) est un ensemble de procédures qui garantissent la précision et la cohérence des données de référence dans l'ensemble de l'organisation.

Pour que les différents systèmes et divisions fonctionnent et interagissent correctement, la précision et la cohérence des données sont essentielles. Si ce n'est pas le cas, les différentes divisions d'une organisation peuvent avoir des enregistrements différents pour une même entité, ce qui peut entraîner des erreurs coûteuses. Par exemple, lorsqu'un client met à jour son adresse sur le site Web de l'entreprise et que le service de facturation consulte un autre dépôt client, les factures émises dans le futur risquent de ne pas parvenir à ce client.

En gestion de données, un système faisant autorité est la source de vérité pour des éléments de données de référence spécifiques. Idéalement, les autres systèmes de l'organisation consomment les données de référence du système faisant autorité pour cet élément. Toutefois, cela n'est pas toujours possible, comme le montrent les scénarios suivants.

Communication directe avec un système faisant autorité

Dans ce scénario, les systèmes communiquent directement avec le système faisant autorité en charge d'un élément de données de référence donné. Les systèmes faisant autorité créent et mettent à jour les données de référence, tandis que les autres systèmes de l'organisation les consomment toujours à partir des systèmes faisant autorité.

Système de gestion de l'information produit (PIM) utilisé comme système faisant autorité pour l'ensemble de l'entreprise en matière de produits

Par exemple, dans le diagramme, un système de gestion de l'information produit (Product Information Management, PIM) est le système le plus fiable au sein de l'entreprise pour les produits. Lorsqu'un autre système, tel qu'un système de gestion de la relation client (CRM), a besoin des données de base produit, il récupère les données du PIM. Le système CRM peut lui-même faire autorité pour un autre élément de données, tel que les clients de l'entreprise.

Ce scénario est idéal, car il permet de conserver les données de référence dans leurs systèmes respectifs, sans avoir recours à des pipelines de transformation complexes. Si le système grand public n'a besoin que d'un certain sous-ensemble de données de référence ou nécessite des données dans un format différent de celui fourni, ce système a la responsabilité de le filtrer ou de le convertir.

Copie officielle provenant d'une source unique

Dans ce scénario, le système grand public ne peut pas communiquer directement avec le système faisant autorité. Les raisons de ces restrictions peuvent varier, par exemple :

  • Le système faisant autorité ne dispose peut-être pas d'une capacité ou d'une disponibilité suffisantes pour gérer le volume de requêtes provenant de toute l'organisation.
  • La communication entre les systèmes peut être limitée par des règles de sécurité ou être impossible en raison des limites de l'infrastructure.

Pour contourner ces restrictions, vous pouvez utiliser votre entrepôt de données pour mettre les données de référence à la disposition des systèmes grand public. Lorsque vous migrez vers le cloud, BigQuery fournit déjà un dépôt hautement disponible, capable de gérer des niveaux de concurrence élevés et largement accessible dans votre organisation, conformément aux règles IAM. Par conséquent, BigQuery est un candidat idéal pour héberger votre copie officielle.

Nous vous recommandons de créer un pipeline de données ELT afin de lire les données de référence du système faisant autorité, le charger dans votre entrepôt de données et le distribuer aux consommateurs. Nous préférons un pipeline ELT à un pipeline ETL, car différents consommateurs peuvent avoir différents besoins pour un même élément de données de référence. Il est donc pertinent de d'abord charger l'élément tel quel dans votre entrepôt de données et de créer des transformations spécialisées pour les consommateurs. Dans Google Cloud, vous pouvez utiliser Dataflow pour créer des pipelines pouvant se connecter de manière native à BigQuery. Vous pouvez ensuite utiliser Cloud Composer pour organiser ces pipelines.

Le système faisant autorité reste la source de vérité pour l'élément de données, tandis que les données de référence copiées dans votre entrepôt de données sont appelées copies officielles (golden copy). Votre entrepôt de données ne devient pas un système faisant autorité.

Le système faisant autorité reste la source de vérité pour l'élément de données.

Par exemple, dans le diagramme, le système CRM ne peut pas demander de données produit directement à partir du système PIM. Vous créez un pipeline ETL qui extrait les données du système PIM, les copie dans l'entrepôt de données, effectue des transformations et les distribue à d'autres systèmes, dont le système CRM.

Si vos systèmes récupèrent les données de référence par lots ou à des fins d'analyse, BigQuery est un emplacement idéal pour vos copies officielles. Toutefois, si la majorité des accès à vos données de référence proviennent de systèmes effectuant des recherches sur une seule ligne, vous pouvez envisager d'utiliser un autre dépôt optimisé pour ces conditions, tel que Cloud Bigtable. Vous pouvez également trouver un équilibre en utilisant les deux dépôts. Celui qui enregistre le trafic le plus élevé détient la copie officielle. Nous vous recommandons de toujours extraire les données du système de copie officielle et de les synchroniser avec l'autre dépôt. Pour ce faire, vous pouvez utiliser un pipeline de données.

Copie officielle provenant de plusieurs sources

Les scénarios précédents utilisaient un seul système faisant autorité pour un élément de données de référence donné. Toutefois, en pratique, plusieurs systèmes d'une organisation peuvent être utilisés pour conserver des caractéristiques différentes du même élément. Par exemple, un système PIM peut être une source de vérité pour des informations techniques et logistiques sur un produit telles que les dimensions, la pondération et la provenance. Toutefois, un système de gestion de catalogues de produits peut être source de fiabilité pour les informations relatives à la vente de produits, telles que les couleurs, les canaux de vente, le prix et la saisonnalité. Il est également fréquent d'avoir des systèmes avec des attributs qui se chevauchent pour un même élément, par exemple des systèmes qui ne faisaient pas partie de MDM ou qui ont été intégrés à l'organisation lors d'acquisitions ou de fusions.

Dans ce cas, un pipeline plus complexe est nécessaire pour fusionner les données de référence de plusieurs sources en une seule copie officielle stockée dans l'entrepôt de données, comme illustré dans le schéma suivant. Les données sont ensuite distribuées aux systèmes grand public de la même manière que dans la section précédente. Votre entrepôt de données n'est pas un système faisant autorité, mais simplement un dépôt pour la copie officielle des données de référence.

Pipeline complexe qui fusionne les données de référence de plusieurs sources en une seule copie officielle stockée dans l'entrepôt de données.

Dans Google Cloud, Dataflow est bien placé pour créer des pipelines complexes représentés par un graphe orienté acyclique (DAG, Directed Acyclic Graph). Ces pipelines lisent à partir de plusieurs sources et rédigent les résultats fusionnés dans BigQuery. Vous pouvez également utiliser un outil visuel tel que Cloud Data Fusion pour créer le pipeline. Cloud Data Fusion fournit également de nombreux plug-ins pour les sources de données et les récepteurs.

Dimensions à évolution lente

Les attributs des tables de dimensions d'un schéma en étoile ou en flocon de neige ne sont normalement jamais modifiés ou de manière très peu fréquente. Un attribut qui ne change jamais est appelé un attribut d'origine. Par exemple, la date de naissance et la notation de crédit d'origine. Si un attribut n'est pas modifié régulièrement, la dimension à laquelle il appartient s'appelle une dimension à évolution lente (SCD, slowly changing dimension). Lorsqu'une SCD change, les données déjà présentes dans la table de faits doivent faire référence à la version précédente de la SCD. Par conséquent, vous avez besoin d'une méthode pour conserver l'historique des SCD.

Lors de la migration de votre entrepôt de données, profitez de l'occasion pour intégrer une méthode de traitement des SCD ou améliorer les méthodes existantes :

  • Pendant que vous modifiez votre schéma au cours de la phase de schéma et de transfert de données pour vous assurer que les SCD sont pris en compte.
  • Pendant la phase de migration du pipeline, pour veiller à conserver l'historique de SCD et à l'utiliser de façon reproductible dans les scénarios suivants : recalculer les résultats pour les remplissages, retraitement pour cause de changement de processus, suivi de la traçabilité, etc.

Méthodes traditionnelles de gestion des SCD

Les méthodes traditionnelles de gestion des modifications de SCD sont appelées types SCD de 0 à 6. La méthode la plus couramment utilisée est le type SCD 2, où les données historiques font l'objet d'un suivi en créant des colonnes supplémentaires dans la table de dimensions. Les colonnes ajoutées sont une clé de substitution et l'une des colonnes suivantes : une version, les dates de début et de fin de validité, ou une date actuelle plus un indicateur signalant laquelle des lignes est actuelle. Pour plus d'informations sur l'application de cette technique et d'autres techniques dans BigQuery, consultez la documentation sur la gestion des changements.

Ingénierie des données fonctionnelles

Une autre méthode pour gérer les SCD a été présentée par Maxime Beauchemin, créateur d'Apache Airflow, dans son article Functional Data Engineering (Ingénierie des données fonctionnelles). Cet article propose un paradigme dans lequel un pipeline de données est composé d'un ensemble de tâches déterministes et idempotentes organisées dans un DAG pour refléter leurs interdépendances directionnelles.

Une tâche est déterministe lorsque son résultat dépend uniquement de ses entrées, et non de n'importe quel état local ou global, suivant ainsi des concepts de programmation fonctionnelle. Une tâche est considérée comme idempotente lorsqu'elle peut être exécutée plusieurs fois avec les mêmes paramètres d'entrée et produire le même résultat. En d'autres termes, elle n'entraîne pas d'effets secondaires supplémentaires. L'opération REST PUT en est un exemple. Une exécution de tâche est appelée instance de tâche. Les instances de tâche avec différentes entrées écrivent des données dans différentes partitions de la même table de sortie.

L'une des entrées des tâches étant les dimensions, Beauchemin préconise de créer des instantanés de dimension chaque fois qu'une exécution ETL est déclenchée. Un instantané de dimension duplique toutes les lignes de dimension requises pour l'exécution ETL avec un horodatage. Les tables de dimensions deviennent une collection d'instantanés à différents moments. Ces instantanés conservent l'historique des modifications apportées aux SCD, autorisent la réexécution des instances de tâche et permettent d'obtenir des résultats reproductibles et cohérents.

Cette méthode s'écarte de la méthode traditionnelle de traitement des SCD, telle que le type SCD 2. Elle évite la complexité de la gestion des clés de substitution et des colonnes supplémentaires, ce qui réduit le temps d'ingénierie, au prix d'un stockage relativement bon marché. L'article reconnaît que les deux méthodes peuvent coexister.

Gérer les SCD dans BigQuery

BigQuery est compatible avec les schémas en étoile et en flocon de neige, y compris avec leurs tables de dimensions. Par conséquent, n'importe laquelle des deux méthodes précédentes est applicable.

BigQuery va plus loin, en favorisant la dénormalisation des schémas via une compatibilité en mode natif avec les champs imbriqués et répétés. Ces champs peuvent être utilisés dans des tables de faits lorsque l'attribut au moment de l'événement est important. Ils peuvent également être utilisés dans les tables de dimension pour enregistrer les valeurs historiques avec une approche de type 2 ou une approche instantanée uniquement pour les attributs changeants et non pour la ligne entière de la dimension.

Conservation et suppression de données

Dans certaines situations, vous pouvez empêcher les utilisateurs de modifier ou de supprimer des données dans BigQuery. Vous pouvez appliquer cette restriction en supprimant ces utilisateurs des rôles qui incluent des autorisations autorisant ces opérations. Ces rôles sont bigquery.dataOwner, bigquery.dataEditor et bigquery.admin. Vous pouvez également créer des rôles IAM personnalisés qui n'incluent pas les autorisations de modification et de suppression spécifiques.

Dans le cas où l'exigence provient du besoin de respecter les réglementations en matière de conservation des enregistrements électroniques, nous vous recommandons plutôt d'exporter les données vers Cloud Storage et d'utiliser la fonctionnalité de verrou de bucket afin d'appliquer ces réglementations.

Dans d'autres cas, vous devrez peut-être supprimer les données automatiquement après un certain délai. BigQuery peut répondre à ce besoin via la configuration d'une date d'expiration. Vous pouvez appliquer la date d'expiration à un ensemble de données, une table ou des partitions de table spécifiques. Faire expirer des données inutiles est une mesure relative au contrôle des coûts et à l'optimisation de stockage. Pour en savoir plus, consultez les bonnes pratiques de BigQuery. Pour en savoir plus sur la suppression de données sur Google Cloud, consultez cette page de documentation.

Si un client Google Cloud constate que l'une des réglementations susmentionnées est applicable à sa situation, il doit effectuer sa propre évaluation de conformité avec les exigences concernées, sous la supervision de son conseiller juridique et de l'autorité de réglementation correspondante.

Gestion de la qualité des données

Les processus de gestion de la qualité des données sont les suivants :

  • Création des contrôles pour la validation.
  • Activation de la surveillance de la qualité et de la création de rapports.
  • Prise en charge du processus de tri pour évaluer le niveau de gravité des incidents.
  • Activation de l'analyse des causes premières et des recommandations de solutions aux problèmes relatifs aux données.
  • Suivi des incidents relatifs aux données.

Différents consommateurs de données peuvent avoir des exigences de qualité différentes. Il est donc important de documenter les attentes en termes de qualité des données, ainsi que les techniques et outils utilisés pour la validation des données et le processus de surveillance. L'établissement de processus efficaces de gestion de la qualité des données permet de fournir des données plus fiables pour l'analyse.

Métadonnées de qualité

Un entrepôt de données permet aux décideurs d'accéder à une immense quantité de données organisées. Cependant, toutes les données de votre entrepôt de données ne doivent pas être traitées de la même manière :

  • Dans un contexte de la prise de décision, les données de haute qualité doivent avoir une plus grande influence sur vos décisions que les données de basse qualité.
  • Dans le cadre de la surveillance de la qualité des données, les données de basse qualité peuvent être utilisées pour déclencher des alertes automatisées ou manuelles afin de vérifier leur processus de production même avant que les données atteignent l'entrepôt de données.

De plus, différentes parties de l'organisation peuvent avoir des seuils de qualité des données différents. Par exemple, des données de basse qualité peuvent être parfaitement utilisables pour le développement et les tests, mais elles peuvent être considérées comme inutilisables pour la finance ou la conformité.

Cette section présente les métadonnées qui agissent en tant que mécanisme permettant d'apporter aux décideurs et aux processus le contexte nécessaire pour évaluer les données qui leur sont présentées.

Structure et format

Les métadonnées sont des informations structurées qui sont associées à un élément de données qui les qualifie. Dans le contexte de la qualité des données, les métadonnées permettent de collecter des attributs pertinents, tels que la précision, la nouveauté et l'exhaustivité.

La sémantique et les attributs spécifiques qui sont capturés dans vos métadonnées de qualité des données (data quality metadata, DQM) dépendent du contexte commercial qu'ils qualifient. Nous vous recommandons vivement d'adopter un ensemble standard d'attributs propre à toute l'entreprise afin de faciliter la communication et la gestion. L'ensemble des attributs que vous choisissez peut être dérivé des standards dans l'industrie tels que : Modèle ISO/IEC 25012:2008 de qualité des données ou les recommandations d'organisations professionnelles, telles que Gestion des données (DAMA).

Le format dans lequel vos DQM sont stockées et présentées aux décideurs est également important. Différents formats peuvent être adaptés à différentes tâches de prise de décision. Par exemple, Moges et al., compile et présente une liste des formats suivants pour les DQM :

  • Ordinal de niveau "n" : ensemble défini de valeurs (excellent, bon et moyen).
  • Plage : échelle numérique avec des limites inférieures et supérieures telles que 0-100 pour représenter le niveau de qualité avec plus de flexibilité qu'un ordinal.
  • Probabilité : qualité des données sur une échelle de 0 à 1 indiquant la probabilité que l'élément de données soit correct.
  • Graphique : files d'attente visuelles telles que des couleurs pour indiquer le niveau de qualité.

Métadonnées de qualité dans le cloud

Traditionnellement, les entreprises ne disposent pas d'un dépôt de DQM cohérent, et dépendent plutôt du partage de connaissances. Ces connaissances sont parfois capturées dans des dépôts disjoints, tels que des feuilles de calcul, des pages intranet et des tables de base de données ad hoc. Les efforts déployés pour découvrir, rechercher, comprendre et gérer ces sources disparates de DQM entravent la collaboration et peuvent l'emporter sur leur valeur d'aide à la décision.

Data Catalog offre un moyen centralisé de gérer les métadonnées :

  • Les tags de métadonnées personnalisées, également appelées métadonnées commerciales, sont compatibles avec tous les attributs de qualité des données que vous ajoutez à vos définitions standards et les regroupent en modèles logiques que vous pouvez personnaliser pour chaque besoin commercial spécifique.
  • Ce service est compatible avec les types énumérés personnalisés pour représenter les attributs ordinaux, et les types double et string pour représenter les plages, les probabilités et les valeurs numériques pouvant être utilisées pour différentes représentations graphiques. Vous pouvez accéder à ces valeurs de métadonnées via l'interface utilisateur de Data Catalog, ou via ses API et bibliothèques clientes qui vous permettent de créer des applications personnalisées pour vos décideurs.
  • Vous pouvez utiliser l'API Data Catalog dans vos processus en amont. Lorsque la qualité des données pour une source donnée tombe en dessous d'un seuil, le processus étiquette les données de basse qualité en tant que telles et déclenche une alerte avant qu'elles atteignent BigQuery. Les données elles-mêmes peuvent être envoyées dans un bucket de zone de quarantaine dans Cloud Storage pour vérification et, éventuellement, correction et retraitement.

Considérations relatives aux métadonnées de qualité des données

On peut supposer que sans DQM, les décideurs ont plus de chance d'utiliser des données de basse qualité et d'engendrer ainsi la prise de mauvaises décisions. En réalité, l'ajout de DQM peut submerger les décideurs en raison de la quantité d'informations qu'ils doivent absorber pour générer des alternatives, qui peuvent à leur tour avoir un impact négatif sur la qualité des décisions et le moment où elles sont mises en application.

Par conséquent, il est essentiel de former les décideurs à la sémantique et aux bonnes pratiques en matière de DQM. Moges et al. suggère que fournir les DQM ainsi qu'une formation est bénéfique pour ce qui est des tâches critiques pour lesquelles les conséquences de l'utilisation de données de basse qualité sont importantes. Toutefois, l'utilisation de DQM peut être contre-productif en ce qui concerne les tâches nécessitant une grande efficacité ou lorsque le personnel n'est pas correctement formé.

Audits

Les organisations doivent être en mesure de contrôler leurs systèmes afin de s'assurer qu'ils fonctionnent comme prévu. La surveillance, l'audit et le suivi aident les équipes chargées de la sécurité à collecter des données, à identifier les menaces et à agir en conséquence avant que ces menaces entraînent des dommages ou des pertes commerciales. Il est important d'effectuer des audits réguliers, car ces audits vérifient l'efficacité des contrôles afin d'atténuer rapidement les menaces et d'évaluer l'état global de la sécurité. Un audit peut également être nécessaire pour démontrer la conformité réglementaire avec les auditeurs externes.

La première étape à suivre pour garantir des contrôles d'accès aux données sains consiste à auditer régulièrement les utilisateurs et les groupes associés à votre projet Google Cloud et aux ensembles de données BigQuery. Ces utilisateurs doivent-ils être propriétaires ou administrateurs, ou un rôle plus restrictif suffit-il pour leur travail ? Il est également important de vérifier qui peut modifier les stratégies IAM de vos projets.

La deuxième étape de l'analyse de vos journaux consiste à répondre aux questions suivantes : "Qui a fait quoi, où et quand ?" en lien avec les données et métadonnées BigQuery.

  • Pour vos données, BigQuery inclut par défaut dans Cloud Logging deux flux de journaux immuables : les journaux d'audit des activités d'administration et d'accès aux données.
  • Pour vos métadonnées, Data Catalog est également compatible avec les deux flux de journaux d'audit. Toutefois, contrairement à BigQuery, la journalisation de l'accès aux données doit être activée manuellement.

Les journaux des activités d'administration contiennent des entrées de journal d'appels ou d'autres actions administratives qui modifient la configuration ou les métadonnées des ressources. Par exemple, la création de nouveaux comptes de service ou les modifications apportées aux autorisations IAM, comme l'octroi à un nouvel utilisateur d'un accès en lecture aux ensembles de données BigQuery, seront consignées dans les journaux des activités d'administration.

Les journaux d'accès aux données enregistrent les appels d'API authentifiés par l'utilisateur qui créent, modifient ou lisent les données fournies par l'utilisateur. Par exemple, les journaux d'accès aux données enregistrent si un utilisateur a interrogé un ensemble de données BigQuery ou a demandé les résultats de la requête. L'attribution de requêtes à un utilisateur plutôt qu'à un compte de service facilite l'audit de l'accès aux données.

Pour les deux types de journaux, vous pouvez créer des alertes Cloud Monitoring qui se déclenchent sous certaines conditions que vous spécifiez. Lorsqu'elles sont déclenchées, ces alertes peuvent envoyer des notifications par le biais de plusieurs canaux, dont des e-mails, des SMS, des services tiers, et même des webhooks vers une URL personnalisée.

Sachez que les journaux d'audit peuvent contenir des informations sensibles. Vous voudrez donc peut-être limiter l'accès aux journaux. L'accès aux journaux d'audit peut être restreint à l'aide des rôles IAM.

Vous devez également envisager d'exporter les journaux d'audit BigQuery de Cloud Logging vers un ensemble de données BigQuery pour les raisons suivantes :

  • Cloud Logging ne conserve les journaux d'audit que pendant une période de conservation des journaux limitée. L'exportation vers un autre emplacement de stockage sécurisé, tel que BigQuery ou Cloud Storage, vous permet de bénéficier d'une période de conservation plus longue.
  • Dans BigQuery, vous pouvez exécuter des requêtes SQL dans les journaux, ce qui permet un filtrage complexe pour l'analyse.
  • De plus, vous pouvez créer des tableaux de bord à l'aide d'outils de visualisation tels que Data Studio.

Pour plus d'informations, consultez cet article de blog sur les bonnes pratiques pour travailler avec les journaux d'audit Google Cloud.

Étapes suivantes