De nombreuses entreprises déploient des entrepôts de données qui stockent des informations confidentielles afin de pouvoir les analyser à 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é composé des é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 à mettre en œuvre (ce document).
Un tutoriel qui déploie un exemple d'environnement.
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 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 de l'anonymisation des données et 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 les fondations de sécurité 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 :
Importer des données depuis Google Cloud dans un entrepôt de données BigQuery sécurisé (ce document)
Importer des données depuis un environnement sur site ou un autre cloud vers un entrepôt BigQuery
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 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 stockées, en transit ou pendant leur analyse. Dans ce plan, vous allez :
- 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
- Configurer des modèles pour rechercher et anonymiser les données confidentielles
- Configurez des journaux et des contrôles de sécurité appropriés pour protéger les données confidentielles
- Limiter l'accès à des colonnes spécifiques de l'entrepôt de données à l'aide de tags avec classification et de règles
Architecture
Pour créer un entrepôt de données confidentiel, vous devez classer les données comme étant confidentielles et non confidentielles, puis les stocker dans des périmètres distincts. L'image suivante montre comment les données ingérées sont classifiées, anonymisées et stockées. Elle indique également comment restaurer l'identification des données confidentielles à la demande pour l'analyse.
L'architecture utilise une combinaison des fonctionnalités et services Google Cloud suivants :
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) et les anonymise. Une zone de destination distincte permet de protéger le reste de vos charges de travail contre les données entrantes.
Un périmètre de données confidentiel qui peut restaurer l'identification des données confidentielles et les stocker dans une zone restreinte.
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 Storage : reçoit et stocke les données par lot avant l'anonymisation. Cloud Storage utilise TLS pour chiffrer les données en transit et chiffre par défaut les données stockées. La clé de chiffrement est une clé de chiffrement gérée par le client (CMEK, Customer-Managed Encryption Key). Vous pouvez contribuer à sécuriser l'accès aux buckets Cloud Storage à l'aide de contrôles de sécurité tels que Identity and Access Management, de listes de contrôle d'accès (LCA) et de documents de stratégie. Pour en savoir plus sur les contrôles d'accès compatibles, consultez la page Présentation du contrôle des accès.
Pub/Sub : reçoit et stocke les données de streaming avant l'anonymisation. Pub/Sub assure la protection de vos données à l'aide de l'authentification, des contrôles d'accès et du chiffrement au niveau du message avec une clé CMEK.
Deux pipelines Dataflow permettent d'anonymiser les données confidentielles et de restaurer leur identification comme suit :
- Le premier pipeline anonymise les données confidentielles à l'aide de la pseudonymisation.
- Le second pipeline rétablit l'identification des données confidentielles lorsque les utilisateurs autorisés ont besoin d'un accès.
Pour protéger les données, Dataflow utilise un compte de service et une clé de chiffrement uniques pour chaque pipeline, ainsi que des contrôles d'accès. Pour faciliter 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 Cloud Dataflow.
La protection des données sensibles anonymise les données confidentielles lors de l'ingestion.
La protection des données sensibles anonymise les données structurées et non structurées en fonction des infoTypes ou des enregistrements détectés.
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 sur le cloud.
Data Catalog classe automatiquement les données confidentielles avec des métadonnées, également appelées tags avec stratégie, lors de l'ingestion. 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 confidentielles dans le périmètre de données confidentiel.
BigQuery utilise divers contrôles de sécurité pour protéger le contenu, y compris les contrôles d'accès, la sécurité au niveau des colonnes pour les données confidentielles, et le chiffrement des données.
Security Command Center surveille et examine les résultats de sécurité depuis votre environnement Google Cloud de manière centralisée.
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 les disques d'amorçage, de production, hors production (ou de préproduction) et de développement. 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.
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 sécurité de base utilisés par ce plan.
| Dossier | Description |
|---|---|
| Production | Contient des projets dont les ressources cloud ont été testées et sont prêtes à être utilisées. |
| Courant | Contient des services centralisés pour l'organisation, tels que le projet de gouvernance. |
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 sécurité de base 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 anonymiser des données confidentielles. |
| Gouvernance | Contient des services qui fournissent des fonctionnalités de gestion des clés, de journalisation et de catalogage des données. |
| Données non confidentielles | Contient les services requis pour stocker les données anonymisées. |
| Données confidentielles | Contient les services requis pour stocker les données confidentielles et en restaurer l'identification. |
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 analysent les données dans l'entrepôt. Ce groupe nécessite des rôles dans différents projets, comme décrit dans le tableau suivant.
| Mappage de projet | Rôles |
|---|---|
| Ingestion de données |
Rôle supplémentaire pour les analystes de données nécessitant un accès aux données confidentielles : |
| Données confidentielles |
|
| Données non confidentielles |
|
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.
| Mappage de projet | Rôles |
|---|---|
| Ingestion de données | |
| Données confidentielles |
|
| Données non confidentielles |
|
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 :
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 sur la protection des données sensibles, et y répondent.
Les analystes de sécurité ont besoin des rôles suivants au niveau de l'organisation :
roles/cloudkms.viewerroles/logging.viewerroles/securitycenter.findingsEditorL'un des rôles suivants de Security Command Center :
roles/securitycenter.findingsBulkMuteEditorroles/securitycenter.findingsMuteSetterroles/securitycenter.findingsStateSetter
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 un entrepôt de données, vous devez transférer les données depuis une autre source Google Cloud (par exemple, un lac de données). 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 utilisant Cloud Storage.
Tâche de streaming utilisant Pub/Sub. Pour protéger les données lors de l'ingestion, vous pouvez utiliser des règles de pare-feu, des stratégies d'accès et le chiffrement.
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 au port TCP 443 provenant des noms de domaine spéciaux restricted.googleapis.com. Le 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.
Vous devez configurer des sous-réseaux distincts pour chaque tâche Dataflow. Des sous-réseaux distincts permettent de s'assurer que les données anonymisées sont correctement séparées des données en cours de restauration.
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 dans le module dwh-networking. Pour en savoir plus, consultez la section Configurer les règles d'accès à Internet et de pare-feu.
Pour refuser aux ressources la possibilité d'utiliser des adresses IP externes, la règle d'administration 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 confidentielle 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 associent le projet d'ingestion de données au projet de gouvernance afin que l'anonymisation puisse avoir lieu pendant l'ingestion.
Elles connectent le projet de données non confidentielles et le projet de données confidentielles afin que les données confidentielles puissent être restaurées lorsqu'un analyste de données les demande.
Elles associent le projet confidentiel au projet de gouvernance des données afin que la restauration de l'identification puisse avoir lieu lorsqu'un analyste de données le demande.
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 de service 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.
Stratégie 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 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.
Gestion des clés et chiffrement pour l'ingestion
Les deux options d'ingestion utilisent Cloud HSM pour gérer le chiffrement CMEK. Utilisez les clés CMEK pour protéger vos données lors de l'ingestion. La protection des données sensibles protège davantage vos données en chiffrant les données confidentielles à l'aide des détecteurs que vous configurez.
Pour ingérer des données, utilisez les clés de chiffrement suivantes :
Une clé CMEK pour le processus d'ingestion, également utilisée par le pipeline Dataflow et le service Pub/Sub. Le processus d'ingestion est parfois appelé processus extraction, transformation, chargement (ETL).
Clé cryptographique encapsulée par Cloud HSM pour le processus d'anonymisation des données à l'aide de la protection des données sensibles.
Deux clés CMEK, une pour l'entrepôt BigQuery dans le projet de données non confidentiel et l'autre pour l'entrepôt dans le projet de données confidentiel. Pour en savoir plus, consultez la section Gestion des clés.
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 et le module confidential-data. Les comptes de service sont les suivants :
Compte de service du contrôleur Dataflow pour le pipeline Dataflow qui anonymise les données confidentielles.
Compte de service de contrôleur Dataflow pour le pipeline Dataflow qui désanonymise les données confidentielles.
Un compte de service Cloud Storage pour ingérer des données à partir d'un fichier par lot.
Un compte de service Pub/Sub pour ingérer les données d'un service de streaming.
Un compte de service Cloud Scheduler pour exécuter la tâche Dataflow par lot qui crée le pipeline Dataflow.
Le tableau suivant répertorie les rôles attribués à chaque compte de service :
| Compte de service | Nom | Projet | Rôles |
|---|---|---|---|
Contrôleur Dataflow Ce compte est utilisé pour l'anonymisation. |
sa-dataflow-controller |
Ingestion de données | |
Contrôleur Dataflow Ce compte est utilisé pour la restauration de l'identification. |
sa-dataflow-controller-reid |
Données confidentielles | |
| Cloud Storage | sa-storage-writer |
Ingestion de données |
|
| Pub/Sub | sa-pubsub-writer |
Ingestion de données |
|
| Cloud Scheduler | sa-scheduler-controller |
Ingestion de données |
|
Anonymisation des données
Vous utilisez la protection des données sensibles pour anonymiser vos données structurées et non structurées pendant la phase d'ingestion. Pour les données structurées, vous utilisez des transformations d'enregistrement basées sur des champs pour anonymiser des données. Pour obtenir un exemple de cette approche, consultez le dossier /examples/de_identification_template/. Cet exemple vérifie les données structurées pour détecter les numéros de carte de crédit et les codes PIN. Pour les données non structurées, vous utilisez des types d'information pour anonymiser des données.
Pour anonymiser les données marquées en tant que données confidentielles, vous utilisez la protection des données sensibles et un pipeline Dataflow pour les tokeniser. Ce pipeline extrait les données de Cloud Storage, les traite, puis les envoie à l'entrepôt de données BigQuery.
Pour en savoir plus sur le processus d'anonymisation des données, consultez la page Gouvernance des 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
Règles d'administration
Périmètres VPC Service Controls entre le projet confidentiel et le projet non confidentiel, avec des liaisons de périmètre appropriées
Chiffrement et gestion de clés
Contrôles des accès au niveau des colonnes
Afin de protéger les données confidentielles, vous utilisez des contrôles d'accès pour des colonnes spécifiques dans l'entrepôt BigQuery. Pour accéder aux données de ces colonnes, un 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, le fichier taxonomy.tf de l'exemple bigquery-confidential-data crée les tags suivants :
Tag de stratégie
3_Confidentialpour les colonnes qui incluent des informations très sensibles, telles que des numéros de carte de crédit. Les utilisateurs ayant accès à ce tag ont également accès aux colonnes qui comportent le tag avec stratégie2_Privateou1_Sensitive.Tag de stratégie
2_Privatepour les colonnes qui incluent des informations personnelles sensibles, telles que le prénom d'une personne. Les utilisateurs ayant accès à ce tag ont également accès aux colonnes marquées du tag avec stratégie1_Sensitive. Les utilisateurs n'ont pas accès aux colonnes marquées du tag avec stratégie3_Confidential.Tag de stratégie
1_Sensitivepour les colonnes qui incluent des données qui ne peuvent pas être rendues publiques, telles que la limite de crédit. Les utilisateurs ayant accès à ce tag n'ont pas accès aux colonnes marquées avec les tags avec stratégie2_Privateou3_Confidential.
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 la restauration de l'identification des données, les données ne peuvent toujours pas être lues tant que l'accès n'est pas explicitement accordé à l'utilisateur.
Comptes de service avec des rôles limités
Vous devez limiter l'accès au projet de données confidentielles afin que seuls les utilisateurs autorisés puissent les consulter. 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 de règle d'administration utilisées par le plan de sécurité de base 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 org_policies :
| Règle | Nom de la contrainte | Valeur recommandée |
|---|---|---|
| Limitez les déploiements de ressources à des emplacements physiques spécifiques. Pour connaître les autres valeurs, consultez la section Groupes de valeurs. |
gcp.resourceLocations
|
Choisissez l'une des options suivantes :in:us-locationsin:eu-locationsin:asia-locations
|
| Désactiver la création de comptes de service |
iam.disableServiceAccountCreation
|
true
|
| Activez OS Login pour les VM créées dans le projet. Pour en savoir plus, consultez les pages Gérer OS Login dans une organisation et OS Login. |
compute.requireOsLogin
|
true
|
| Limitez les nouvelles règles de transfert à une utilisation interne uniquement, en fonction de l'adresse IP. | compute.restrictProtocolForwardingCreationForTypes
|
INTERNAL
|
| 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/s
ubnetworks/SUBNETWORK-NAME.Remplacez SUBNETWORK-NAME par l'ID de ressource du sous-réseau privé que vous souhaitez utiliser dans le plan. |
| Désactivez la journalisation des données en sortie du port série sur Cloud Logging. | compute.disableSerialPortLogging |
true |
Gestion et chiffrement des clés pour le stockage et la restauration de l'identification
Vous gérez les clés CMEK distinctes pour vos données confidentielles afin de pouvoir restaurer l'identité des données. Utilisez Cloud HSM pour protéger vos clés. Pour restaurer l'identification de vos données, utilisez les clés suivantes :
Une clé CMEK utilisée par le pipeline Dataflow pour le processus de restauration de l'identification.
Clé cryptographique d'origine utilisée par la protection des données sensibles pour anonymiser vos données.
Clé CMEK de l'entrepôt BigQuery dans le projet de données confidentielles.
Comme indiqué précédemment dans la section Gestion des clés et chiffrement pour l'ingestion, vous pouvez spécifier l'emplacement CMEK et les périodes de rotation. Vous pouvez utiliser Cloud EKM si votre organisation l'exige.
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 :
Surveillez les accès à vos données.
Assurez-vous de mettre en place un audit approprié.
Permettez à 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'un humain accède au contenu, et seul le personnel de Google avec des justifications commerciales valides (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 centralized-logging configure les bonnes pratiques suivantes :
Créez un récepteur de journaux agrégés sur l'ensemble des projets.
Stockage de vos journaux dans la région appropriée.
Ajout de clés CMEK à votre récepteur de journaux.
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.
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 page 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é
Les contrôles de sécurité décrits dans ce plan ont été examinés par l'équipe chargée de la cybersécurité de Google et par une équipe de sécurité tierce. Pour demander l'accès à un modèle de menace et au rapport d'évaluation récapitulatif dans le cadre d'un NDA, envoyez un e-mail à l'adresse secured-dw-blueprint-support@google.com
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. En voici quelques-uns :
Le code que vous utilisez pour configurer, déployer et exécuter des tâches Dataflow.
Classification de données que vous utilisez avec cette solution.
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 :
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 sécurité de base, assurez-vous que votre environnement dispose d'une référence de sécurité similaire.
Consultez le fichier README du plan et assurez-vous que vous remplissez toutes les conditions requises.
Dans votre environnement de test, déployez le tutoriel pour voir la solution en action. Dans le cadre de votre processus de test, réfléchissez aux éléments suivants :
Utilisez Security Command Center pour analyser les projets nouvellement créés et vérifier qu'ils répondent à vos exigences de conformité.
Ajoutez vos propres exemples de données dans l'entrepôt BigQuery.
Collaborez avec un analyste de données de votre entreprise pour tester son accès aux données confidentielles et voir s'il peut interagir avec les données de BigQuery de la manière attendue.
Déployez le plan dans votre environnement de production.
Étapes suivantes
Consultez le plan de sécurité de base de Google Cloud pour découvrir un environnement sécurisé de référence.
Pour en savoir plus sur le plan, consultez le fichier readme de la configuration Terraform.
Pour découvrir d'autres bonnes pratiques et plans, consultez le centre des bonnes pratiques de sécurité.