Importer des données depuis un réseau externe dans un entrepôt de données BigQuery sécurisé

Last reviewed 2023-08-15 UTC

De nombreuses organisations déploient des entrepôts de données qui stockent des informations confidentielles afin de pouvoir analyser les données à des fins diverses. Ce document est destiné aux ingénieurs de données et aux administrateurs de sécurité qui déploient et sécurisent des entrepôts de données à l'aide de BigQuery. Il fait partie d'un plan de sécurité comprenant les éléments suivants:

  • Un dépôt GitHub contenant un ensemble de configurations et de scripts Terraform. La configuration Terraform configure un environnement Google Cloud compatible avec un entrepôt de données qui stocke les données confidentielles.
  • Un guide des contrôles d'architecture, de conception et de sécurité que vous utilisez pour la mise en œuvre (ce document).

Ce document traite les points suivants :

  • L'architecture et les services Google Cloud que vous pouvez utiliser pour sécuriser un entrepôt de données dans un environnement de production.
  • Bonnes pratiques pour l'importation de données dans BigQuery à partir d'un réseau externe tel qu'un environnement sur site.
  • Bonnes pratiques pour la gouvernance des données lors de la création, du déploiement et de l'exploitation d'un entrepôt de données dans Google Cloud, y compris du chiffrement au niveau des colonnes, de la gestion différentielle de données confidentielles et des contrôles d'accès au niveau des colonnes.

Ce document part du principe que vous avez déjà configuré un ensemble fondamental de contrôles de sécurité, comme décrit dans le plan de base d'entreprise de Google Cloud. Il vous aide à intégrer des contrôles supplémentaires à vos contrôles de sécurité existants pour protéger les données confidentielles dans un entrepôt de données.

Cas d'utilisation de l'entrepôt de données

Ce plan est compatible avec les cas d'utilisation suivants :

Présentation

Les entrepôts de données tels que BigQuery permettent aux entreprises d'analyser leurs données d'entreprise pour en extraire des renseignements. Les analystes accèdent aux données d'entreprise stockées dans des entrepôts de données afin de générer des insights. Si votre entrepôt de données inclut des données que vous considérez comme confidentielles, vous devez prendre des mesures pour préserver la sécurité, la confidentialité, l'intégrité et la disponibilité des données d'entreprise pendant qu'elles sont importées et stockées, pendant leur transit. ou pendant leur analyse. Dans ce plan, vous allez :

  • Chiffrez vos données source situées en dehors de Google Cloud (par exemple, dans un environnement sur site) et importez-les dans BigQuery.
  • Configurer des contrôles permettant de sécuriser l'accès aux données confidentielles
  • Configurer des contrôles permettant de sécuriser le pipeline de données
  • Configurer une séparation des tâches appropriée pour les différents personnages
  • Configurez la journalisation et des contrôles de sécurité appropriés pour protéger les données confidentielles
  • Utilisez la classification des données, les tags avec stratégie, le masquage dynamique des données et le chiffrement au niveau des colonnes pour limiter l'accès à des colonnes spécifiques de l'entrepôt de données.

Architecture

Pour créer un entrepôt de données confidentiel, vous devez importer les données de manière sécurisée, puis les stocker dans un périmètre VPC Service Controls. L'image suivante montre comment les données sont ingérées et stockées.

Architecture sécurisée d'entrepôt de données pour les réseaux externes.

L'architecture utilise une combinaison des fonctionnalités et services Google Cloud suivants :

  • L'interconnexion dédiée vous permet de transférer des données entre votre réseau et Google Cloud. Vous pouvez utiliser une autre option de connectivité, comme décrit dans la page Choisir un produit de connectivité réseau.

  • La gestion de l'authentification et des accès (IAM) et Resource Manager limitent les ressources d'accès et de segment. Les contrôles d'accès et la hiérarchie des ressources suivent le principe du moindre privilège.

  • VPC Service Controls crée des périmètres de sécurité qui isolent les services et les ressources en configurant l'autorisation, les contrôles d'accès et l'échange de données sécurisé. Les périmètres sont les suivants :

    • Un périmètre d'ingestion de données qui accepte les données entrantes (par lot ou par flux). Un périmètre distinct permet de protéger le reste de vos charges de travail contre les données entrantes.
    • Un périmètre de données qui isole les données de chiffrement des autres charges de travail.
    • Un périmètre de gouvernance qui stocke les clés de chiffrement et définit ce qui est considéré comme des données confidentielles.

    Ces périmètres sont conçus pour protéger le contenu entrant, isoler les données confidentielles en configurant des contrôles d'accès et une surveillance supplémentaires, et séparer votre gouvernance des données réelles de l'entrepôt. Votre gouvernance inclut la gestion des clés, la gestion du catalogue de données et la journalisation.

  • Cloud Storage et Pub/Sub reçoivent les données comme suit :

  • Cloud Functions est déclenché par Cloud Storage et écrit les données que Cloud Storage importe dans le bucket d'ingestion dans BigQuery.

  • Un pipeline Dataflow écrit des flux de données dans BigQuery. Pour protéger les données, Dataflow utilise un compte de service et des contrôles d'accès uniques. Pour sécuriser l'exécution du pipeline en le déplaçant vers le service de backend, Dataflow utilise Streaming Engine. Pour en savoir plus, consultez la section Sécurité et autorisations pour Dataflow.

  • Cloud Data Loss Prevention (Cloud DLP) analyse les données stockées dans BigQuery pour rechercher les données sensibles qui ne sont pas protégées. Pour en savoir plus, consultez la page Utiliser Cloud DLP pour analyser les données BigQuery.

  • Cloud HSM héberge la clé de chiffrement de clé (KEK, Key Encryption Key). Cloud HSM est un service de module de sécurité matériel basé sur le cloud. Vous utilisez Cloud HSM pour générer la clé de chiffrement que vous utilisez pour chiffrer les données de votre réseau avant de les envoyer à Google Cloud.

  • Data Catalog classe automatiquement les données confidentielles avec des métadonnées, également appelées tags avec stratégie, lorsqu'elles sont découvertes dans BigQuery. Data Catalog utilise également des métadonnées pour gérer l'accès aux données confidentielles. Pour plus d'informations, consultez la page Présentation de Data Catalog. Pour contrôler l'accès aux données dans l'entrepôt de données, vous devez appliquer des tags avec stratégie aux colonnes qui incluent des données confidentielles.

  • BigQuery stocke les données chiffrées et la clé de chiffrement encapsulée dans des tables distinctes.

    BigQuery utilise divers contrôles de sécurité pour protéger le contenu, y compris les contrôles d'accès, le chiffrement au niveau des colonnes, la sécurité au niveau des colonnes et le chiffrement des données.

  • Security Command Center surveille et examine les résultats de sécurité de votre environnement Google Cloud de manière centralisée.

  • Cloud Logging collecte tous les journaux des services Google Cloud pour le stockage et la récupération par vos outils d'analyse et d'investigation.

  • Cloud Monitoring collecte et stocke les informations et les métriques de performances des services Google Cloud.

  • Data Profiler for BigQuery recherche automatiquement les données sensibles dans toutes les tables et colonnes BigQuery de l'ensemble de l'organisation, y compris les dossiers et projets.

Structure organisationnelle

Vous regroupez les ressources de votre organisation de façon à pouvoir les gérer et séparer vos environnements de test de votre environnement de production. Resource Manager vous permet de regrouper les ressources de manière logique par projet, dossier et organisation.

Le schéma suivant montre une hiérarchie de ressources avec des dossiers qui représentent différents environnements, tels que l'environnement d'amorçage, l'environnement commun, de production, hors production (ou de préproduction) et de développement. Cette hiérarchie s'aligne sur la structure organisationnelle utilisée par le plan de base d'entreprise. Vous déployez la plupart des projets du plan dans le dossier de production, ainsi que le projet de gouvernance des données dans le dossier commun utilisé pour la gouvernance.

Hiérarchie des ressources pour un entrepôt de données sécurisé pour les réseaux externes

Pour découvrir d'autres hiérarchies de ressources, consultez la page Choisir une hiérarchie de ressources pour votre zone de destination Google Cloud.

Dossiers

Vous utilisez des dossiers pour isoler vos environnements de production et de gouvernance de vos environnements hors production et de test. Le tableau suivant décrit les dossiers du plan de base de l'entreprise utilisés par ce plan.

Dossier Description
Amorçage Contient les ressources requises pour déployer le plan de base d'entreprise.
Courant Contient des services centralisés pour l'organisation, tels que le projet de gouvernance des données.
Production Contient des projets dont les ressources cloud ont été testées et sont prêtes à être utilisées. Dans ce plan, le dossier de production contient le projet d'ingestion de données et le projet de données.
Hors production Contient des projets comportant des ressources cloud en cours de test et de préproduction pour la diffusion. Dans ce plan, le dossier hors production contient le projet d'ingestion de données et le projet de données.
Développement Contient les projets comportant des ressources cloud en cours de développement. Dans ce plan, le dossier "Development" contient le projet d'ingestion de données et le projet de données.

Vous pouvez modifier les noms de ces dossiers pour qu'ils correspondent à la structure des dossiers de votre organisation, mais nous vous recommandons de conserver une structure similaire. Pour en savoir plus, consultez le plan de base d'entreprise de Google Cloud.

Projets

Vous isolez des parties de votre environnement à l'aide de projets. Le tableau suivant décrit les projets nécessaires à l'organisation. Vous créez ces projets lorsque vous exécutez le code Terraform. Vous pouvez modifier les noms de ces projets, mais nous vous recommandons de conserver une structure de projet similaire.

Projet Description
Ingestion de données Contient les services requis pour recevoir des données et les écrire dans BigQuery.
Gouvernance des données Contient des services qui fournissent des fonctionnalités de gestion des clés, de journalisation et de catalogage des données.
Données Contient les services requis pour stocker les données.

En plus de ces projets, votre environnement doit également inclure un projet qui héberge une tâche de modèle Flex Dataflow. La tâche de modèle Flex est requise pour le pipeline de flux de données.

Mapper des rôles et des groupes à des projets

Vous devez autoriser différents groupes d'utilisateurs de votre organisation à accéder aux projets qui composent l'entrepôt de données confidentiel. Les sections suivantes décrivent les recommandations de plan pour les groupes d'utilisateurs et les attributions de rôles dans les projets que vous créez. Vous pouvez personnaliser les groupes pour qu'ils correspondent à la structure existante de votre organisation, mais nous vous recommandons de maintenir une séparation similaire des tâches et de l'attribution de rôles.

Groupe d'analystes de données

Les analystes de données affichent et analysent les données dans l'entrepôt. Ce groupe peut afficher les données après leur chargement dans l'entrepôt de données et effectuer les mêmes opérations que le groupe de lecteurs de données chiffrées. Ce groupe nécessite des rôles dans différents projets, comme décrit dans le tableau suivant.

Champ d'application de l'attribution Rôles
Projet d'ingestion de données
Projet de données
Niveau de stratégie de données Lecteur masqué (roles/bigquerydatapolicy.maskedReader)

Groupe de lecteurs de données chiffrées

Le groupe de lecteurs de données chiffrées peut afficher les données chiffrées à partir des tables de rapports BigQuery via Cloud Looker Studio et d'autres outils de création de rapports, tels que SAP Business Objects. Le groupe de lecteurs de données chiffrées ne peut pas afficher les données en texte clair des colonnes chiffrées.

Ce groupe nécessite le rôle "Utilisateur BigQuery" (roles/bigquery.jobUser) dans le projet "Données". Ce groupe nécessite également celui de lecteur masqué (roles/bigquerydatapolicy.maskedReader) au niveau de la stratégie de données.

Groupe de lecteurs de texte brut

Le groupe de lecteurs de texte brut dispose de l'autorisation requise pour appeler la fonction de déchiffrement définie par l'utilisateur (UDF) pour afficher les données en texte brut et l'autorisation supplémentaire pour lire les données non masquées. Ce groupe nécessite des rôles dans le projet Data, comme décrit dans le tableau suivant.

Ce groupe nécessite les rôles suivants dans le projet de données:

En outre, ce groupe nécessite le rôle Lecteur détaillé (roles/datacatalog.categoryFineGrainedReader) au niveau de Data Catalog.

Groupe d'ingénieurs de données

Les ingénieurs de données configurent et gèrent le pipeline et l'entrepôt de données. Ce groupe nécessite des rôles dans différents projets, comme décrit dans le tableau suivant.

Champ d'application de l'attribution Rôles
Projet d'ingestion de données
Projet de données
  • Éditeur de données BigQuery (roles/bigquery.dataeditor)
  • Utilisateur de job BigQuery (roles/bigquery.jobUser)
  • Éditeur Cloud Build (roles/cloudbuild.builds.editor)
  • Lecteur Cloud KMS (roles/cloudkms.viewer)
  • Utilisateur de réseau Compute (roles/compute.networkuser)
  • Administrateur Dataflow (roles/dataflow.admin)
  • Administrateur DLP (roles/dlp.admin)
  • Visionneuse de journaux (roles/logging.viewer)

Groupe d'administrateurs réseau

Les administrateurs réseau configurent le réseau. En règle générale, ils sont membres de l'équipe réseau.

Les administrateurs réseau ont besoin des rôles suivants au niveau de l'organisation :

  • Administrateur de Compute (roles/compute.networkAdmin)
  • Visionneuse de journaux (roles/logging.viewer)

Groupe d'administrateurs de la sécurité

Les administrateurs de sécurité administrent les contrôles de sécurité tels que l'accès, les clés, les règles de pare-feu, VPC Service Controls et Security Command Center.

Les administrateurs de sécurité ont besoin des rôles suivants au niveau de l'organisation :

Groupe d'analystes de la sécurité

Les analystes de sécurité surveillent les incidents de sécurité et les résultats de Cloud DLP, et y répondent.

Les analystes de sécurité ont besoin des rôles suivants au niveau de l'organisation :

Exemples de flux d'accès de groupe

Les sections suivantes décrivent les flux d'accès pour deux groupes dans la solution d'entrepôt de données sécurisé.

Flux d'accès pour le groupe de lecteurs de données chiffrées

Le schéma suivant montre ce qui se produit lorsqu'un utilisateur du groupe de lecteurs de données chiffrées tente d'accéder aux données chiffrées dans BigQuery.

Flux du groupe de lecteurs de données chiffrés.

Pour accéder aux données dans BigQuery, procédez comme suit:

  1. La visionneuse de données chiffrées exécute la requête suivante sur BigQuery pour accéder aux données confidentielles:

    SELECT ssn, pan FROM cc_card_table

  2. BigQuery vérifie l'accès comme suit:

    • L'utilisateur est authentifié à l'aide d'identifiants Google Cloud valides et non expirés.
    • L'identité de l'utilisateur et l'adresse IP d'origine de la requête font partie de la liste d'autorisation de la règle de niveau d'accès/d'entrée du périmètre VPC Service Controls.
    • IAM vérifie que l'utilisateur dispose des rôles appropriés et qu'il est autorisé à accéder aux colonnes chiffrées sélectionnées dans la table BigQuery.

BigQuery renvoie les données confidentielles au format chiffré.

Flux d'accès pour le groupe de lecteurs de texte brut

Le schéma suivant montre ce qui se produit lorsqu'un utilisateur du groupe de lecteurs de texte brut tente d'accéder aux données chiffrées dans BigQuery.

Flux du groupe de lecteurs de texte brut.

Pour accéder aux données dans BigQuery, procédez comme suit:

  1. Le lecteur de texte brut exécute la requête suivante sur BigQuery pour accéder aux données confidentielles dans un format déchiffré:

    SELECT decrypt_ssn(ssn) FROM cc_card_table

  2. BigQuery appelle la fonction définie par l'utilisateur (UDF) de déchiffrement dans la requête pour accéder aux colonnes protégées.

  3. L'accès est validé comme suit:

    • IAM vérifie que l'utilisateur dispose des rôles appropriés et qu'il est autorisé à accéder à la fonction de déchiffrement UDF sur BigQuery.
    • Cette fonction récupère la clé de chiffrement des données (DEK) encapsulée qui a été utilisée pour protéger les colonnes de données sensibles.

    La fonction de déchiffrement UDF appelle la clé de chiffrement de clé (KEK) dans Cloud HSM pour désencapsuler la DEK. La fonction de déchiffrement UDF utilise la fonction de déchiffrement AEAD BigQuery pour déchiffrer les colonnes de données sensibles.

  4. L'utilisateur est autorisé à accéder aux données en texte brut dans les colonnes de données sensibles.

Comprendre les contrôles de sécurité nécessaires

Cette section décrit les contrôles de sécurité au sein de Google Cloud qui vous permettent de sécuriser votre entrepôt de données. Les principes de sécurité clés à prendre en compte sont les suivants :

  • Sécurisez l'accès en adoptant les principes du moindre privilège.
  • Sécurisez les connexions réseau grâce à la conception de la segmentation et aux règles de segmentation.
  • Sécurisez la configuration de chacun des services.
  • Classez et protégez les données en fonction de leur niveau de risque.
  • Comprenez les exigences de sécurité pour l'environnement qui héberge l'entrepôt de données.
  • Configurez des fonctionnalités de surveillance et de journalisation suffisantes pour la détection, l'enquête et la réponse.

Contrôles de sécurité pour l'ingestion de données

Pour créer votre entrepôt de données, vous devez transférer les données depuis une autre source dans votre environnement sur site, un autre cloud ou une autre source Google Cloud. Ce document porte sur le transfert de données depuis votre environnement sur site ou un autre cloud. Si vous transférez des données depuis une autre source Google Cloud, consultez la page Importer des données depuis Google Cloud vers un entrepôt de données BigQuery sécurisé.

Vous pouvez utiliser l'une des options suivantes pour transférer vos données vers l'entrepôt de données sur BigQuery :

  • Tâche par lot qui charge des données dans un bucket Cloud Storage.
  • Tâche de streaming utilisant Pub/Sub.

Pour protéger les données lors de l'ingestion, vous pouvez utiliser le chiffrement côté client, les règles de pare-feu et les stratégies de niveau d'accès. Le processus d'ingestion est parfois appelé processus extraction, transformation, chargement (ETL).

Connexion chiffrée à Google Cloud

Vous pouvez utiliser Cloud VPN ou Cloud Interconnect pour protéger toutes les données qui circulent entre Google Cloud et votre environnement. Ce plan recommande l'interconnexion dédiée, car il fournit une connexion directe et un débit élevé, ce qui est important si vous diffusez de nombreuses données.

Pour autoriser l'accès à Google Cloud depuis votre environnement, vous devez définir des adresses IP sur liste d'autorisation dans les règles de stratégie de niveaux d'accès.

Règles de réseau et de pare-feu

Les règles de pare-feu de cloud privé virtuel (VPC) contrôlent le flux de données dans les périmètres. Vous créez des règles de pare-feu qui refusent toutes les sorties, à l'exception de connexions spécifiques pour le port TCP 443 provenant des noms de domaine spéciaux restricted.googleapis.com. L'utilisation du domaine restricted.googleapis.com présente les avantages suivants :

  • Il contribue à réduire la surface d'attaque du réseau en utilisant l'accès privé à Google lorsque les charges de travail communiquent avec les API et les services de Google.
  • Cette opération garantit que vous n'utilisez que les services compatibles avec VPC Service Controls.

Pour plus d'informations, consultez la page Configurer l'accès privé à Google.

Le pipeline de données nécessite l'ouverture des ports TCP dans le pare-feu, comme défini dans le fichier dataflow_firewall.tf du dépôt module harness-projects. Pour en savoir plus, consultez la section Configurer l'accès à Internet et les règles de pare-feu.

Pour refuser aux ressources la possibilité d'utiliser des adresses IP externes, la règle d'administration Définir les adresses IP externes autorisées pour les instances de VM (compute.vmExternalIpAccess) est définie sur "Tout refuser".

Contrôles du périmètre

Comme illustré dans le diagramme d'architecture, vous placez les ressources de l'entrepôt de données dans des périmètres distincts. Pour permettre aux services de différents périmètres de partager des données, vous devez créer des liaisons de périmètre.

Les liaisons de périmètre permettent aux services protégés d'effectuer des requêtes de ressources situées en dehors de leur périmètre. Ces liaisons établissent les connexions suivantes :

  • Elles connectent le projet Data ingestion au projet Data afin que les données puissent être ingérées dans BigQuery.
  • Elles associent le projet "Data" au projet de gouvernance des données afin que Cloud DLP puisse analyser BigQuery à la recherche de données confidentielles non protégées.
  • Elles associent le projet d'ingestion de données au projet de gouvernance des données afin d'accéder à la journalisation, la surveillance et aux clés de chiffrement.

Outre les liaisons de périmètre, vous utilisez des règles de sortie pour permettre aux ressources protégées par des périmètres d'accéder à des ressources situées en dehors du périmètre. Dans cette solution, vous configurez des règles de sortie pour obtenir les tâches externes de modèle Flex Dataflow situées dans Cloud Storage dans un projet externe. Pour plus d'informations, consultez la section Accéder à une ressource Google Cloud en dehors du périmètre.

Règles d'accès

Pour vous assurer que seules des identités spécifiques (utilisateur ou service) peuvent accéder aux ressources et aux données, vous devez activer les groupes et les rôles IAM.

Pour vous assurer que seules des sources spécifiques peuvent accéder à vos projets, vous devez activer une règle d'accès pour votre organisation Google. Nous vous recommandons de créer une règle d'accès qui spécifie la plage d'adresses IP autorisée pour les requêtes provenant de votre environnement sur site et n'autorise que les requêtes provenant d'utilisateurs ou de comptes de service spécifiques. Pour en savoir plus, consultez la section Attributs de niveau d'accès.

Chiffrement côté client

Avant de déplacer vos données sensibles vers Google Cloud, chiffrez-les localement pour les protéger au repos et en transit. Vous pouvez utiliser la bibliothèque de chiffrement Tink ou d'autres bibliothèques de chiffrement. La bibliothèque de chiffrement Tink est compatible avec le chiffrement BigQuery AEAD, que le plan utilise pour déchiffrer les données chiffrées au niveau des colonnes après l'importation des données.

La bibliothèque de chiffrement Tink utilise des DEK que vous pouvez générer localement ou à partir de Cloud HSM. Pour encapsuler ou protéger la DEK, vous pouvez utiliser une KEK générée dans Cloud HSM. La KEK est une collection de clés de chiffrement CMEK symétrique qui est stockée de manière sécurisée dans Cloud HSM et gérée à l'aide des rôles et autorisations IAM.

Lors de l'ingestion, la DEK encapsulée et les données sont stockées dans BigQuery. BigQuery inclut deux tables: l'une pour les données et l'autre pour la DEK encapsulée. Lorsque les analystes doivent afficher des données confidentielles, BigQuery peut utiliser le déchiffrement AEAD pour désencapsuler la DEK avec la KEK et déchiffrer la colonne protégée.

En outre, le chiffrement côté client à l'aide de Tink protège davantage vos données en chiffrant des colonnes de données sensibles dans BigQuery. Le plan utilise les clés de chiffrement Cloud HSM suivantes:

  • Une clé CMEK pour le processus d'ingestion, également utilisée par Pub/Sub, le pipeline Dataflow pour le streaming, l'importation par lot Cloud Storage et les artefacts Cloud Functions pour les importations par lot ultérieures.
  • Clé cryptographique encapsulée par Cloud HSM pour les données chiffrées sur votre réseau à l'aide de Tink.
  • Clé CMEK de l'entrepôt BigQuery dans le projet Data.

Spécifiez l'emplacement CMEK, qui détermine l'emplacement géographique où la clé est stockée et accessible. Vous devez vous assurer que votre clé CMEK se trouve au même emplacement que vos ressources. Par défaut, la clé CMEK est alternée tous les 30 jours.

Si les obligations de conformité de votre organisation vous obligent à gérer vos propres clés en externe depuis Google Cloud, vous pouvez activer Cloud External Key Manager. Si vous utilisez des clés externes, vous êtes responsable des activités de gestion des clés, y compris de la rotation des clés.

Comptes de service et contrôles des accès

Les comptes de service sont des identités que Google Cloud peut utiliser pour exécuter des requêtes API en votre nom. Les comptes de service garantissent que les identités des utilisateurs ne disposent pas d'un accès direct aux services. Pour permettre la séparation des tâches, vous devez créer des comptes de service avec différents rôles à des fins spécifiques. Ces comptes de service sont définis dans le module data-ingestion-sa et le module data-governance-sa.

Les comptes de service sont les suivants :

  • Le compte de service Cloud Storage exécute le processus d'importation automatisé des données par lot dans le bucket de stockage d'ingestion.
  • Le compte de service Pub/Sub permet de diffuser des données en streaming vers le service Pub/Sub.
  • Le compte de service du contrôleur Dataflow est utilisé par le pipeline Dataflow pour transformer et écrire des données de Pub/Sub dans BigQuery.
  • Le compte de service Cloud Functions écrit les données par lot ultérieures importées de Cloud Storage dans BigQuery.
  • Le compte de service Storage Upload permet au pipeline ETL de créer des objets.
  • Le compte de service Pub/Sub Write permet au pipeline ETL d'écrire des données dans Pub/Sub.

Le tableau suivant répertorie les rôles attribués à chaque compte de service :

Nom Rôles Champ d'application de l'attribution
Compte de service du contrôleur Dataflow Projet d'ingestion de données
Projet de données
Gouvernance des données
Compte de service Cloud Functions Projet d'ingestion de données
  • Éditeur de données BigQuery (roles/bigquery.dataEditor)
  • Lecteur de métadonnées BigQuery (roles/bigquery.metadataViewer)
 Projet de données
Compte de service d'importation Storage Projet d'ingestion de données
Compte de service Pub/Sub Write Projet d'ingestion de données

Contrôles de sécurité pour le stockage des données

Pour protéger les données stockées dans l'entrepôt BigQuery, vous devez configurer les contrôles de sécurité suivants :

  • Contrôles des accès au niveau des colonnes
  • Comptes de service avec des rôles limités
  • Masquage dynamique des données des champs sensibles
  • Règles d'administration
  • Analyse automatique et profilage des données Cloud DLP
  • Périmètres VPC Service Controls entre le projet d'ingestion de données et le projet de données, avec des liaisons de périmètre appropriées
  • Chiffrement et gestion de clés, comme suit :
    • Chiffrement au repos avec des clés CMEK stockées dans Cloud HSM
    • Chiffrement au niveau des colonnes à l'aide de Tink et du chiffrement AEAD et de BigQuery

Masquage dynamique des données

Pour vous aider à partager et à appliquer des règles d'accès aux données à grande échelle, vous pouvez configurer le masquage des données dynamiques. Le masquage dynamique des données permet aux requêtes existantes de masquer automatiquement les données des colonnes à l'aide des critères suivants:

  • Les règles de masquage appliquées à la colonne au moment de l'exécution de la requête.
  • Les rôles attribués à l'utilisateur qui exécute la requête. Pour accéder aux données de colonne non masquées, l'analyste de données doit disposer du rôle Lecteur détaillé.

Pour définir l'accès aux colonnes dans BigQuery, vous devez créer des tags avec stratégie. Par exemple, la taxonomie créée dans l'exemple autonome crée le tag avec stratégie 1_Sensitive pour les colonnes qui incluent des données qui ne peuvent pas être rendues publiques, telles que la limite de crédit. La règle de masquage de données par défaut est appliquée à ces colonnes pour masquer leur valeur.

Tout élément sans tag est disponible pour tous les utilisateurs ayant accès à l'entrepôt de données. Ces contrôles d'accès garantissent que, même après l'écriture des données dans BigQuery, les données des champs sensibles ne peuvent toujours pas être lues tant que l'accès n'est pas explicitement accordé à l'utilisateur.

Chiffrement et déchiffrement au niveau des colonnes

Le chiffrement au niveau des colonnes vous permet de chiffrer les données dans BigQuery de manière plus précise. Plutôt que de chiffrer une table entière, vous sélectionnez les colonnes contenant des données sensibles dans BigQuery, et seules ces colonnes sont chiffrées. BigQuery utilise des fonctions de chiffrement et déchiffrement AEAD qui créent les collections de clés contenant les clés de chiffrement et de déchiffrement. Ces clés permettent ensuite de chiffrer et de déchiffrer les valeurs individuelles d'une table, et d'alterner les clés d'une collection de clés. Le chiffrement au niveau des colonnes fournit un contrôle d'accès double sur les données chiffrées dans BigQuery, car l'utilisateur doit disposer d'autorisations sur la table et la clé de chiffrement pour lire des données en texte clair.

Profiler des données pour BigQuery avec Cloud DLP

Le profileur de données vous permet d'identifier les emplacements des données sensibles et à haut risque dans les tables BigQuery. Le profileur de données analyse automatiquement toutes les tables et colonnes BigQuery dans l'ensemble de l'organisation, y compris tous les dossiers et projets. Le profileur de données génère ensuite des métriques telles que les infoTypes prévus, les niveaux de sensibilité et de risque liés aux données évalués, ainsi que les métadonnées liées à vos tables. À l'aide de ces insights, vous pouvez prendre des décisions avisées pour la protection, le partage et l'utilisation de vos données.

Comptes de service avec des rôles limités

Vous devez limiter l'accès au projet Data afin que seuls les utilisateurs autorisés puissent afficher les champs de données sensibles. Pour ce faire, vous devez créer un compte de service doté du rôle roles/iam.serviceAccountUser dont les utilisateurs autorisés doivent emprunter l'identité. L'emprunt d'identité du compte de service permet aux utilisateurs d'utiliser des comptes de service sans télécharger les clés de compte de service. Cela permet d'améliorer la sécurité globale de votre projet. L'usurpation d'identité crée un jeton à court terme que les utilisateurs autorisés disposant du rôle roles/iam.serviceAccountTokenCreator sont autorisés à télécharger.

Règles d'administration

Ce plan inclut les contraintes liées aux règles d'administration utilisées par le plan de base d'entreprise et ajoute des contraintes supplémentaires. Pour en savoir plus sur les contraintes utilisées par le plan de base d'entreprise, consultez la section Contraintes liées aux règles d'administration.

Le tableau suivant décrit les contraintes de règles d'administration supplémentaires définies dans le module règles d'administration.

Règle Nom de la contrainte Valeur recommandée
Limitez les déploiements de ressources à des emplacements physiques spécifiques gcp.resourceLocations Choisissez l'une des options suivantes :
in:us-locations
in:eu-locations
in:asia-locations
Exiger la protection CMEK gcp.restrictNonCmekServices bigquery.googleapis.com
Désactiver la création de comptes de service iam.disableServiceAccountCreation true
Désactiver la création de clés de compte de service disableServiceAccountKeyCreation true
Activez OS Login pour les VM créées dans le projet. compute.requireOsLogin true
Désactiver les attributions automatiques de rôles pour les comptes de service par défaut automaticIamGrantsForDefaultServiceAccounts true
Paramètres d'entrée autorisés (Cloud Functions) cloudfunctions.allowedIngressSettings ALLOW_INTERNAL_AND_GCLB
Limitez les nouvelles règles de transfert à une utilisation interne uniquement, en fonction de l'adresse IP. compute.restrictProtocolForwardingCreationForTypes INTERNAL
Désactivez la journalisation des données en sortie du port série sur Cloud Logging. compute.disableSerialPortLogging true
Définissez l'ensemble des sous-réseaux VPC partagés que les ressources Compute Engine peuvent utiliser. compute.restrictSharedVpcSubnetworks projects/PROJECT_ID/regions/REGION/subnetworks/SUBNETWORK-NAME

Remplacez SUBNETWORK-NAME par l'ID de ressource du sous-réseau privé que vous souhaitez utiliser dans le plan.

Contrôles opérationnels

Vous pouvez activer la journalisation et les fonctionnalités de niveau Premium de Security Command Center, telles que l'analyse de l'état de la sécurité et la détection des menaces. Ces contrôles vous aident à effectuer les opérations suivantes :

  • Surveiller qui accède à vos données.
  • Assurez-vous de mettre en place un audit approprié.
  • Générez des résultats pour les ressources cloud mal configurées.
  • Permettre à vos équipes chargées de la gestion des incidents et des opérations de résoudre les problèmes susceptibles de survenir.

Access Transparency

Access Transparency vous fournit une notification en temps réel si le personnel de l'assistance Google a besoin d'accéder à vos données. Des journaux Access Transparency sont générés chaque fois qu'une personne accède au contenu, et seul le personnel de Google justifiant de motifs valables (par exemple, une demande d'assistance) peut obtenir l'accès. Nous vous recommandons d'activer Access Transparency.

Journalisation

Pour vous aider à répondre aux exigences d'audit et à mieux comprendre vos projets, configurez Google Cloud Observability avec des journaux de données pour les services que vous souhaitez suivre. Le module harness-logging configure les bonnes pratiques suivantes:

Pour tous les services des projets, vos journaux doivent inclure des informations sur les lectures et les écritures de données, ainsi que sur les informations lues par les administrateurs. Pour en savoir plus sur les bonnes pratiques de journalisation, consultez la page Contrôles de détection du plan de base d'entreprise.

Alertes et surveillance

Après avoir déployé le plan, vous pouvez configurer des alertes pour avertir votre centre d'opérations de sécurité (SOC) qu'un incident de sécurité peut se produire. Par exemple, vous pouvez utiliser des alertes pour informer votre analyste de la sécurité d'une modification d'une autorisation IAM. Pour en savoir plus sur la configuration des alertes Security Command Center, consultez la section Configurer des notifications de recherche. Pour les alertes supplémentaires qui ne sont pas publiées par Security Command Center, vous pouvez configurer des alertes avec Cloud Monitoring.

Autres considérations sur la sécurité

Outre les contrôles de sécurité décrits dans cette solution, vous devez examiner et gérer la sécurité et les risques dans les domaines clés qui se chevauchent et interagissent avec votre utilisation de cette solution. Ces considérations de sécurité incluent les considérations suivantes:

  • Sécurité du code que vous utilisez pour configurer, déployer et exécuter des tâches Dataflow et Cloud Functions.
  • Classification de données que vous utilisez avec cette solution.
  • Génération et gestion des clés de chiffrement
  • Le contenu, la qualité et la sécurité des ensembles de données que vous stockez et analysez dans l'entrepôt de données.
  • Environnement global dans lequel vous déployez la solution, y compris les éléments suivants :
    • La conception, la segmentation et la sécurité des réseaux que vous connectez à cette solution.
    • La sécurité et la gouvernance des contrôles IAM de votre organisation.
    • Les paramètres d'authentification et d'autorisation pour les acteurs auxquels vous accordez l'accès à l'infrastructure faisant partie de cette solution, et qui ont accès aux données stockées et gérées dans cette infrastructure.

Conclusion

Pour mettre en œuvre l'architecture décrite dans ce document, procédez comme suit :

  1. Déterminez si vous allez déployer le plan avec le plan de base d'entreprise ou seul. Si vous choisissez de ne pas déployer le plan de base d'entreprise, assurez-vous que votre environnement dispose d'une référence de sécurité similaire.
  2. Configurez une connexion par interconnexion dédiée avec votre réseau.
  3. Consultez le fichier README du plan et assurez-vous que vous remplissez toutes les conditions requises.
  4. Vérifiez que votre identité utilisateur dispose des rôles iam.serviceAccountUser et iam.serviceAccountTokenCreator pour le dossier de développement de votre organisation, comme décrit dans la section Structure de l'organisation. Si vous ne disposez d'aucun dossier à utiliser pour les tests, créez un dossier et configurez l'accès.
  5. Enregistrez l'ID de votre compte de facturation, le nom à afficher de l'organisation, l'ID de votre dossier de test ou de démonstration, ainsi que les adresses e-mail des groupes d'utilisateurs suivants :
    • Analystes de données
    • Lecteur de données chiffrées
    • Lecteur de texte brut
    • Ingénieurs de données
    • Administrateurs réseau
    • Administrateurs de sécurité
    • Analystes de sécurité
  6. Créer les projets de données, de gouvernance des données, d'ingestion de données et de modèle Flex. Pour obtenir la liste des API que vous devez activer, consultez le fichier README.
  7. Créez le compte de service pour Terraform et attribuez les rôles appropriés à tous les projets.
  8. Configurer la stratégie de contrôle d'accès

  9. Dans votre environnement de test, déployez la solution:

    1. Clonez et exécutez les scripts Terraform pour configurer un environnement dans Google Cloud.
    2. Installez la bibliothèque de chiffrement Tink sur votre réseau.
    3. Configurez les identifiants par défaut de l'application afin de pouvoir exécuter la bibliothèque Tink sur votre réseau.
    4. Créez des clés de chiffrement avec Cloud KMS.
    5. Générez des collections de clés chiffrées avec Tink.

    6. Chiffrez les données avec Tink à l'aide de l'une des méthodes suivantes:

    7. Importer des données chiffrées dans BigQuery à l'aide d'importations en flux continu ou par lot.

  10. Vérifiez que les utilisateurs autorisés peuvent lire des données non chiffrées depuis BigQuery à l'aide de la fonction de déchiffrement AEAD de BigQuery. Par exemple, exécutez la fonction de création de déchiffrement suivante:

    CREATE OR REPLACE FUNCTION `{project_id}.{bigquery_dataset}.decrypt`(encodedText STRING) RETURNS STRING AS
(
AEAD.DECRYPT_STRING(
KEYS.KEYSET_CHAIN('gcp-kms://projects/myProject/locations/us/keyRings/myKeyRing/cryptoKeys/myKeyName', b'\012\044\000\321\054\306\036\026…..'),
FROM_BASE64(encodedText), "")
);

    Exécutez la requête de création de vue :

    CREATE OR REPLACE VIEW `{project_id}.{bigquery_dataset}.decryption_view` AS

SELECT
 Card_Type_Code,
 Issuing_Bank,
 Card_Number,
 `bigquery_dataset.decrypt`(Card_Number) AS Card_Number_Decrypted
FROM `project_id.dataset.table_name`

    Exécutez la requête de sélection à partir de la vue:

    SELECT
  Card_Type_Code,
  Issuing_Bank,
  Card_Number,
  Card_Number_Decrypted
FROM
`{project_id}.{bigquery_dataset}.decrypted_view`

    Pour obtenir d'autres requêtes et cas d'utilisation, consultez la page Chiffrement au niveau des colonnes avec Cloud KMS.

  11. Utilisez Security Command Center pour analyser les projets nouvellement créés et vérifier qu'ils répondent à vos exigences de conformité.

  12. Déployez le plan dans votre environnement de production.

Étapes suivantes