Rapport sur le modèle de menace BigQuery

Dernière mise à jour : 16 avril 2026

Ce document identifie les vecteurs d'attaque potentiels et les stratégies d'atténuation pour la confidentialité, l'intégrité et la disponibilité des données dans BigQuery. Le champ d'application de ce rapport est limité à votre point de vue. Il se concentre sur les risques que vous pouvez gérer dans votre environnement BigQuery.

Ces modèles de menace sont une évaluation probabiliste basée sur les vecteurs d'attaque actuellement connus, les hypothèses architecturales et le champ d'application spécifié du système au moment de la publication. Ces modèles ne sont pas exhaustifs et sont destinés à servir de référence pour les évaluations de sécurité et des risques des clients Google Cloud, ainsi qu'à guider les décisions de réduction des risques.

Les menaces suivantes ont été identifiées pour ce service :

• Destruction des données par falsification du schéma
• Élévation des privilèges par falsification des stratégies d'autorisation IAM
• Abus de type "confused deputy" à l'aide de services en aval déclenchés par BigQuery
• Exfiltration de données à l'aide d'une sortie réseau non restreinte
• Dérive de l'intégrité des données à l'aide de tables de référence ou de recherche corrompues
• Falsification de données à l'aide de tâches de chargement malveillantes
• Autorisations IAM excessives entraînant la divulgation d'informations
• Exfiltration à l'aide d'un transfert vers un projet ou un compte Cloud contrôlé par un pirate informatique
• Divulgation d'informations à l'aide de vues autorisées ou d'une logique de sécurité au niveau des lignes mal configurées
• Divulgation d'informations à l'aide de l'exposition d'ensembles de données publics ou interprojets
• Utilisation abusive par un employé d'un accès BigQuery autorisé (requêtes légitimes utilisées pour la collecte malveillante)
• Persistance à l'aide de liaisons IAM BigQuery furtives sur des ensembles de données, des vues autorisées ou des requêtes planifiées
• Usurpation d'identité à l'aide d'identifiants de compte de service ou d'un jeton OAuth compromis utilisés pour accéder à BigQuery
• Déni de service basé sur les coûts à l'aide de requêtes coûteuses

Détails de la menace

Les sections suivantes fournissent des informations sur chaque menace, leurs manifestations et les mesures d'atténuation recommandées.

Destruction de données à l'aide de la falsification de schémas

Un pirate informatique disposant des autorisations nécessaires pour modifier le schéma d'une table peut potentiellement entraîner une perte de données ou rendre la table inutilisable pour les applications en aval. Cette forme de falsification cible les métadonnées et la structure des données, ce qui peut être aussi destructeur que la modification des données elles-mêmes.

Catégorie STRIDE	Falsification
Tactique MITRE ATT&CK	Impact
Manifestations	Mise à jour malveillante du schéma : un principal disposant de l'autorisation bigquery.tables.update peut appeler la méthode d'API tables.patch sur une table BigQuery pour modifier son schéma. Modifier les types de données des colonnes peut corrompre les données ou entraîner une perte d'informations. Cela peut également casser les requêtes des applications clientes ou des outils d'informatique décisionnelle, ce qui peut entraîner une perte de confiance dans les rapports en aval.
Mesures d'atténuation	Limitez strictement l'autorisation bigquery.tables.update, qui fait partie de rôles tels que roles/bigquery.dataOwner. N'accordez cette autorisation qu'à un petit nombre d'administrateurs ou de comptes de service CI/CD automatisés responsables des migrations de schéma gérées. Activez les sauvegardes de table BigQuery ou utilisez des instantanés de tables pour vous protéger contre les modifications de schéma accidentelles ou malveillantes. Surveillez les journaux d'audit Cloud pour les appels d'API tables.patch et définissez des alertes pour toute modification apportée en dehors d'un intervalle de maintenance planifié.

Élévation des privilèges par falsification des stratégies d'autorisation IAM

Un pirate informatique qui compromet un compte principal autorisé à modifier les règles d'autorisation IAM BigQuery peut escalader ses privilèges pour obtenir un contrôle total sur les ressources de données. Cette menace permet au pirate informatique d'accorder l'accès en lecture, en modification ou en suppression à des données sensibles, en contournant les contrôles d'accès existants.

Catégorie STRIDE	Élévation des privilèges
Tactique MITRE ATT&CK	Élévation des privilèges
Manifestations	Modification des règles d'ensemble de données : un principal disposant de l'autorisation bigquery.datasets.update peut appeler la méthode d'API datasets.patch sur un ensemble de données BigQuery pour ajouter sa propre identité à un rôle de propriétaire, ce qui lui donne le contrôle total sur toutes les ressources de cet ensemble de données. Emprunt d'identité d'un compte de service : une identité disposant de l'autorisation iam.serviceAccounts.actAs sur un compte de service peut associer le compte de service à d'autres ressources, telles qu'une instance Compute Engine, pour exécuter du code avec l'identité du compte de service associé. Une identité disposant de l'autorisation iam.serviceAccounts.getAccessToken peut également générer des jetons d'accès pour ce compte de service. Si le compte de service cible dispose d'autorisations élevées sur les ressources BigQuery, le pirate informatique hérite de ces droits.
Mesures d'atténuation	Limitez strictement les autorisations permettant de modifier les stratégies d'autorisation IAM (par exemple, bigquery.datasets.update, qui fait partie de rôles tels que roles/bigquery.dataOwner). N'attribuez ces rôles qu'à un nombre minimal d'administrateurs de confiance. De même, contrôlez strictement les rôles IAM autorisés à agir en tant que comptes de service ou à les usurper, et limitez ces rôles aux principaux spécifiques qui en ont besoin. Surveillez les journaux d'audit Cloud pour les appels d'API SetIamPolicy et datasets.patch afin de détecter les modifications non autorisées apportées aux règles.

Abus de délégation confuse à l'aide de services en aval déclenchés par BigQuery

Un pirate informatique disposant d'autorisations BigQuery limitées crée un job ou une requête qui déclenche un service en aval (par exemple, une fonction Cloud, un job Dataflow ou un DAG Cloud Composer), qui s'exécute avec des droits d'accès plus élevés. Le service en aval, qui pense effectuer une action légitime au nom de BigQuery, est amené à effectuer une action sur une ressource ou avec des données différentes de celles prévues par les concepteurs du système.

Catégorie STRIDE	Élévation des privilèges
Tactique MITRE ATT&CK	Élévation des privilèges
Manifestations	Déclencheur de fonction malveillant : une modification BigQuery déclenche une fonction Cloud disposant de nombreuses autorisations. L'auteur de l'attaque manipule les données BigQuery pour contrôler les actions de la fonction. Exploitation du pipeline Dataflow : les résultats d'une requête BigQuery sont utilisés comme entrée pour une tâche Dataflow. L'auteur de l'attaque écrit les résultats de la requête pour que la tâche Dataflow ingère des données corrompues.
Mesures d'atténuation	Appliquez le principe du moindre privilège aux comptes de service utilisés par les services en aval déclenchés par BigQuery. Assurez-vous que ces services valident et nettoient les entrées ou les paramètres reçus des jobs BigQuery. Utilisez VPC Service Controls pour restreindre les chemins réseau et les interactions de service. Concevez les services en aval de manière à ne pas faire confiance aux entrées de BigQuery sans les vérifier.

Exfiltration de données à l'aide d'une sortie réseau non restreinte

Si des contrôles de sécurité au niveau du réseau ne sont pas en place, un compte interne compromis peut accéder à BigQuery et exfiltrer des données sensibles vers un emplacement arbitraire sur Internet. Même avec des contrôles IAM stricts, l'absence de périmètre réseau permet à un pirate informatique qui a obtenu des identifiants valides de contourner les défenses basées sur la localisation et de transférer des données en dehors de l'environnement de confiance.

Catégorie STRIDE	Divulgation d'informations
Tactique MITRE ATT&CK	Exfiltration
Manifestations	Accès à l'API depuis des réseaux non fiables : un pirate informatique utilise des identifiants compromis pour se connecter à l'API BigQuery publique ou à l'API BigQuery Storage Read depuis une machine externe, en contournant les contrôles réseau configurés pour les hôtes sur site ou les appareils utilisateur. Exporter vers un service Google Cloud externe : un compte de service compromis disposant des autorisations bigquery.jobs.create et Cloud Storage exécute une requête qui exporte les résultats vers un bucket Cloud Storage public hors du contrôle de l'organisation.
Mesures d'atténuation	Implémentez des contrôles de sortie réseau pour limiter l'exfiltration de données vers des services externes arbitraires. Implémentez un périmètre VPC Service Controls autour du projet contenant les ressources BigQuery. Ce périmètre permet de limiter l'exfiltration de données vers les services Google Cloud situés en dehors du périmètre. Configurez des niveaux d'accès pour le périmètre afin d'autoriser uniquement les requêtes API provenant de plages d'adresses IP approuvées ou de réseaux VPC spécifiques. Vous empêcherez ainsi l'accès aux données ou leur déplacement en dehors de la limite de sécurité définie.

Dérive de l'intégrité des données à l'aide de tables de référence ou de recherche corrompues

Un pirate informatique ayant accès en écriture aux tables de référence ou de conversion (par exemple, les tables de dimensions) modifie subtilement leur contenu. Les requêtes qui effectuent une jointure avec ces tables corrompues produisent des résultats incorrects et trompeurs, ce qui compromet l'intégrité des analyses et des décisions commerciales en aval, potentiellement sans aucune erreur évidente.

Catégorie STRIDE	Falsification
Tactique MITRE ATT&CK	Impact
Manifestations	Manipulation des tables de dimensions : modification des valeurs clés ou des attributs dans une table de dimensions de produit. Corruption de la recherche : modification des données de mise en correspondance dans un tableau de conversion.
Mesures d'atténuation	Limitez strictement l'accès en écriture (bigquery.tables.updateData) aux tables de référence ou de recherche aux seuls processus d'ingestion de données fiables. Implémenter des contrôles de qualité des données et des pipelines de validation Utilisez des instantanés de table ou la gestion des versions pour suivre les modifications et permettre les rollbacks. Surveillez les journaux d'audit pour détecter les modifications apportées à ces tables critiques.

Falsification de données à l'aide de tâches de chargement malveillantes

Un pirate informatique disposant des autorisations suffisantes peut intentionnellement corrompre ou écraser des données critiques dans une table BigQuery en exécutant une tâche de chargement malveillante. Cette menace compromet l'intégrité des données, ce qui peut entraîner des analyses commerciales incorrectes, des échecs d'application et une perte de confiance des clients.

Catégorie STRIDE	Falsification
Tactique MITRE ATT&CK	Impact
Manifestations	Écrasement de table : un principal disposant des autorisations bigquery.jobs.create et bigquery.tables.updateData lance un job de chargement avec la disposition d'écriture définie sur WRITE_TRUNCATE, ce qui efface toutes les données existantes et les remplace par des données malveillantes provenant d'une source externe. Ajout de données malveillantes : un pirate informatique utilise une tâche de chargement avec WRITE_APPEND pour injecter des données inutiles ou malveillantes dans une table existante, ce qui corrompt les données analytiques sans supprimer les enregistrements d'origine.
Mesures d'atténuation	Appliquez le principe du moindre privilège. Contrôlez précisément les autorisations telles que bigquery.jobs.create et bigquery.tables.updateData (disponibles dans des rôles tels que roles/bigquery.dataEditor). N'accordez ces autorisations qu'aux comptes principaux de confiance et limitez-les à des ensembles de données ou des tables spécifiques. Surveillez les journaux d'audit Cloud pour les tâches de chargement terminées, en particulier celles avec une disposition WRITE_TRUNCATE, et créez des alertes pour les tâches qui proviennent d'utilisateurs inattendus ou qui chargent des données provenant de sources non fiables.

Autorisations IAM excessives entraînant la divulgation d'informations

Des rôles IAM trop permissifs peuvent autoriser un accès excessif aux données sensibles stockées dans les tables BigQuery. Un pirate informatique qui compromet un compte principal disposant d'autorisations d'accès aux données étendues peut exfiltrer de grands volumes de données, ce qui entraîne une violation de données importante. Cette menace se concrétise lorsque des autorisations telles que bigquery.tables.getData ou bigquery.jobs.create sont accordées à un large champ d'application (par exemple, au niveau du projet) au lieu d'être limitées à des ensembles de données ou des tables spécifiques nécessaires à une fonction métier.

Catégorie STRIDE	Divulgation d'informations
Tactique MITRE ATT&CK	Exfiltration
Manifestations	Lecture directe des données : un principal disposant de l'autorisation bigquery.tables.getData peut lire directement les données des tables à l'aide de la méthode d'API tabledata.list ou de l'API BigQuery Storage Read à haut débit. Exfiltration basée sur les requêtes : un principal disposant de l'autorisation bigquery.jobs.create peut exécuter un job de requête à l'aide de jobs.insert ou jobs.query pour lire les données de n'importe quelle table à laquelle il a accès, puis récupérer les résultats à l'aide de jobs.getQueryResults. Accessibilité publique : une stratégie IAM d'autorisation sur un ensemble de données ou une table BigQuery peut être configurée pour autoriser l'accès public en accordant des rôles à des principaux spéciaux tels que allUsers ou allAuthenticatedUsers, ce qui expose les données sur Internet.
Mesures d'atténuation	Appliquez le principe du moindre privilège à toutes les stratégies d'autorisation IAM. Accordez les autorisations au niveau de précision le plus élevé requis (par exemple, des tables BigQuery ou des ensembles de données spécifiques) plutôt qu'au niveau du projet. Utilisez des rôles IAM avec le moindre privilège, qui ne contiennent que les autorisations nécessaires (par exemple, bigquery.tables.getData, bigquery.jobs.create) pour des tâches spécifiques. Vérifiez régulièrement les stratégies d'autorisation IAM pour les rôles trop permissifs tels que roles/bigquery.dataViewer ou roles/bigquery.user appliqués à un niveau élevé de la hiérarchie des ressources.

Exfiltration à l'aide d'un transfert vers un compte ou un projet cloud contrôlé par le pirate informatique

Un pirate informatique utilise les fonctionnalités de transfert de données de BigQuery (par exemple, les tâches d'exportation vers Cloud Storage, les requêtes inter-projets et le service de transfert de données BigQuery) pour transférer des données sensibles du projet sécurisé vers un projet Google Cloud ou un autre compte cloud sous son contrôle.

Catégorie STRIDE	Divulgation d'informations
Tactique MITRE ATT&CK	Exfiltration
Manifestations	Exporter vers un bucket externe : utiliser un job d'exportation pour enregistrer les données d'une table dans un bucket Cloud Storage du projet d'un pirate informatique. Destination de requête inter-projets : exécution d'une requête et définition de la table de destination sur un ensemble de données dans un projet contrôlé par un pirate informatique.
Mesures d'atténuation	Implémentez VPC Service Controls pour créer un périmètre autour du projet, ce qui empêchera les données de sortir vers des projets situés en dehors du périmètre. Contrôlez précisément les autorisations telles que bigquery.tables.export et bigquery.jobs.create. Utilisez des contraintes de règle d'administration pour limiter le partage et la création de projets. Surveillez les journaux d'audit Cloud pour les tâches ou requêtes d'exportation dont les destinations se trouvent en dehors des limites de projet attendues.

Divulgation d'informations à l'aide d'une logique de sécurité au niveau des lignes ou de vues autorisées mal configurées

Les failles dans la logique SQL des vues autorisées ou des règles de sécurité au niveau des lignes entraînent un accès aux données plus large que prévu. Les utilisateurs qui interrogent la vue ou la table peuvent accéder par inadvertance à des lignes ou des colonnes qu'ils ne devraient pas pouvoir voir, ce qui contourne la ségrégation prévue.

Catégorie STRIDE	Divulgation d'informations
Tactique MITRE ATT&CK	Collection
Manifestations	Logique de vue défectueuse : la requête d'une vue autorisée omet les clauses WHERE nécessaires qui sont présentes dans les règles de sécurité au niveau des lignes de la table de base. Contournement de la sécurité au niveau des lignes : une règle de sécurité complexe au niveau des lignes contient une erreur logique qui permet un accès plus large que prévu.
Mesures d'atténuation	Mettez en œuvre un processus strict de revue du code pour la logique SQL utilisée dans les vues autorisées et les règles de sécurité au niveau des lignes. Testez minutieusement la logique de sécurité. Limitez les autorisations (par exemple, bigquery.tables.create, bigquery.tables.update ou bigquery.rowAccessPolicies.create) pour créer ou mettre à jour des vues et des règles de sécurité au niveau des lignes. Auditez régulièrement les vues et les configurations de sécurité au niveau des lignes existantes. Suivez les bonnes pratiques de sécurité au niveau des lignes.

Divulgation d'informations à l'aide de l'exposition d'ensembles de données publics ou interprojets

Des données sensibles sont exposées, car des ensembles de données BigQuery sont rendus publics par inadvertance ou de manière malveillante (par exemple, à l'aide de "allUsers" ou "allAuthenticatedUsers") ou partagés trop largement avec d'autres projets Google Cloud en dehors de la limite de confiance prévue. Un pirate informatique peut accéder directement aux données ou les copier sans authentification ou en utilisant n'importe quel compte Google authentifié.

Catégorie STRIDE	Divulgation d'informations
Tactique MITRE ATT&CK	Exfiltration
Manifestations	Ensemble de données public : une stratégie d'autorisation IAM sur un ensemble de données accorde des autorisations de lecteur à allUsers. Partage excessif entre projets : un ensemble de données est partagé avec une organisation externe ou un compte de service dans un projet non fiable.
Mesures d'atténuation	Appliquez le principe du moindre privilège aux règles d'autorisation IAM des ensembles de données. Utilisez des règles d'administration telles que constraints/iam.allowedPolicyMemberDomains pour limiter le partage à des domaines spécifiques. Vérifiez régulièrement les stratégies d'autorisation IAM des ensembles de données à l'aide de Security Command Center pour détecter les autorisations publiques ou trop larges. Utilisez VPC Service Controls pour créer des périmètres autour des projets contenant des données sensibles afin d'empêcher les sorties non autorisées.

Utilisation abusive par un employé d'un accès BigQuery autorisé (requêtes légitimes utilisées pour une collecte malveillante)

Un employé malveillant disposant d'un accès légitime à BigQuery utilise ses autorisations pour exécuter des requêtes et collecter des données sensibles à des fins non autorisées (par exemple, pour son propre profit ou pour espionnage). Bien que l'accès soit autorisé, l'intention et l'utilisation des données sont malveillantes.

Catégorie STRIDE	Divulgation d'informations
Tactique MITRE ATT&CK	Collection
Manifestations	Accaparement de données : interroger et télécharger régulièrement des données client au-delà des exigences du job. Analyse sensible : analyses visant à extraire des secrets commerciaux ou des informations permettant d'identifier personnellement l'utilisateur à des fins d'exfiltration.
Mesures d'atténuation	Activez et surveillez les journaux d'audit des accès aux données pour suivre les modèles d'accès aux données. Utilisez des outils comme Sensitive Data Protection pour analyser les résultats des requêtes et détecter les informations sensibles. Implémentez l'analyse du comportement des utilisateurs (UBA) pour détecter les schémas de requêtes ou les volumes d'accès aux données anormaux. Appliquez des règles claires de gestion des données et proposez des formations sur la sensibilisation à la sécurité. Utilisez la sécurité au niveau des lignes et des colonnes pour limiter l'exposition des données, même pour les utilisateurs autorisés.

Persistance à l'aide de liaisons IAM BigQuery furtives sur des ensembles de données, des vues autorisées ou des requêtes planifiées

Un pirate informatique, après avoir obtenu un accès initial, établit une présence à long terme en créant des mécanismes d'accès difficiles à détecter dans BigQuery. Cette menace inclut l'ajout de liaisons IAM aux ensembles de données, la création de vues autorisées qui interrogent des données sensibles ou la configuration de requêtes planifiées qui s'exécutent sous un compte de service privilégié pour exfiltrer des données ou maintenir l'accès.

Catégorie STRIDE	Élévation des privilèges
Tactique MITRE ATT&CK	Persistance
Manifestations	IAM pour les ensembles de données masqués : accorder des droits de lecteur à un compte personnel sur un ensemble de données spécifique moins surveillé. Accès détourné aux vues autorisées : création d'une vue autorisée à accéder à une table restreinte et octroi de l'accès à la vue. Requête planifiée malveillante : configuration d'une requête planifiée pour copier régulièrement des données vers un emplacement externe.
Mesures d'atténuation	Vérifiez régulièrement toutes les stratégies IAM d'autorisation, y compris les autorisations au niveau des ensembles de données, à l'aide d'outils tels que Security Command Center. Contrôlez précisément les autorisations de création ou de mise à jour des ensembles de données (bigquery.datasets.update), des routines (bigquery.routines.create/update) et des transferts de données (bigquery.transfers.update).

Usurpation d'identité à l'aide d'identifiants de compte de service ou d'un jeton OAuth compromis utilisés pour accéder à BigQuery

Un pirate informatique obtient les identifiants d'un compte de service (par exemple, des clés JSON exportées) et les utilise pour s'authentifier auprès de BigQuery en tant que compte de service piraté, en héritant de toutes ses autorisations. Cette menace permet au pirate informatique d'effectuer toutes les actions que le compte de service est autorisé à effectuer, comme lire des données, exécuter des tâches ou modifier des ressources.

Catégorie STRIDE	Spoofing
Tactique MITRE ATT&CK	Accès initial
Manifestations	Clé de compte de service divulguée : un fichier de clé JSON est exposé dans des dépôts de code, un stockage public ou des métadonnées d'instance. Application compromise : une application qui utilise un compte de service est compromise, ce qui permet au pirate informatique d'extraire et d'utiliser ses identifiants. Jeton OAuth volé : un pirate informatique intercepte ou divulgue un jeton OAuth à partir d'une application cliente ou d'une session de navigateur. Jeton avec un champ d'application trop étendu : une application demande et stocke des jetons avec des champs d'application excessifs (par exemple, un accès complet à BigQuery alors qu'un accès en lecture seule est suffisant).
Mesures d'atténuation	Évitez d'exporter les clés de compte de service. Utilisez plutôt des comptes de service associés ou la fédération d'identité de charge de travail, si possible. Si des clés sont nécessaires, alternez-les régulièrement et n'accordez au compte de service que les autorisations minimales requises. Surveillez les journaux d'audit cloud et Security Command Center pour détecter toute activité anormale de compte de service ou toute exposition de clé. Utilisez la contrainte de règle d'administration constraints/iam.disableServiceAccountKeyCreation pour désactiver la création de clés de compte de service. Stockez et transmettez les jetons OAuth de manière sécurisée. Suivez les bonnes pratiques OAuth 2.0. Ne demandez que les niveaux d'accès nécessaires. Utilisez des jetons de courte durée et des jetons d'actualisation de manière sécurisée. Mettez en place des mécanismes permettant de détecter et de révoquer les jetons compromis. Surveillez les schémas d'utilisation anormaux des jetons. Appliquez les mesures de protection standards pour les clés de compte de service. Configurez la durée de session pour les services Google Cloud afin d'appliquer des jetons éphémères et de réduire le risque de fuite de jeton.

Déni de service basé sur les coûts à l'aide de requêtes coûteuses

Un principal authentifié exécute des requêtes conçues pour consommer des ressources BigQuery excessives (telles que des emplacements et des octets analysés). Cette menace peut entraîner des dépassements de coûts massifs dans les projets à la demande ou une pénurie de créneaux pour les autres utilisateurs dans les projets basés sur les réservations, ce qui entrave les opérations commerciales.

Catégorie STRIDE	Déni de service
Tactique MITRE ATT&CK	Impact
Manifestations	Requêtes non optimisées : exécution de requêtes avec des jointures croisées sur de grandes tables sans filtres. Exécution répétitive : script permettant d'exécuter fréquemment des requêtes coûteuses.
Mesures d'atténuation	Utilisez les quotas personnalisés BigQuery pour définir des limites d'utilisation des requêtes au niveau de l'utilisateur et au niveau du projet (par exemple, les octets analysés par jour). Utilisez le paramètre maximumBytesBilled dans les tâches de requête. Utilisez les réservations BigQuery pour isoler les charges de travail et garantir la capacité. Configurez des alertes de facturation dans la facturation Cloud et surveillez l'utilisation des emplacements dans Cloud Monitoring pour détecter les anomalies et y réagir.