Bonnes pratiques concernant la sécurité au niveau des lignes dans BigQuery
Ce document décrit les bonnes pratiques à adopter lors de l'utilisation de la sécurité au niveau des lignes.
Avant de lire ce document, familiarisez-vous avec la sécurité au niveau des lignes en consultant les pages Présentation de la sécurité au niveau des lignes de BigQuery et Utiliser la sécurité au niveau des lignes.
Limiter les autorisations des utilisateurs pour limiter les attaques sur les versions secondaires
Une attaque sur les versions secondaires est une attaque de sécurité basée sur les informations obtenues à partir du système lui-même. Un pirate informatique disposant d'autorisations plus larges que nécessaire peut installer plus facilement des attaques de canaux secondaires et apprendre des données sensibles en observant ou en recherchant la facturation, la journalisation ou le système.
Pour limiter ces opportunités, BigQuery masque les statistiques sensibles sur toutes les requêtes portant sur des tables sécurisées au niveau des lignes. Ces statistiques sensibles incluent le nombre d'octets traités, le nombre de partitions traitées, le nombre d'octets facturés et les étapes du plan de requête.
Nous recommandons aux administrateurs de ne pas accorder les autorisations suivantes aux utilisateurs qui ne doivent voir que les données filtrées, afin d'éviter de donner accès à des données sensibles.
| Autorisations | données sensibles |
|---|---|
| Rôle Propriétaire de projet ou Créateur de projet | Les propriétaires de projet peuvent afficher les octets traités et les données associées dans les journaux d'audit. Les créateurs de projet peuvent créer des projets dont ils sont propriétaires, et afficher les journaux d'audit et de facturation. |
| Rôles d'éditeur, de propriétaire ou de lecteur de données BigQuery | Afficher les messages d'erreur sur les requêtes. |
| Autorisations de lecteur Cloud Billing | Afficher la facturation BigQuery |
Exemples
- En effectuant une observation répétée de la durée des requêtes lors de l'interrogation de tables dotées de règles d'accès au niveau des lignes, l'utilisateur peut déduire les valeurs des lignes qui seraient autrement protégées par des règles d'accès au niveau des lignes. Ce type d'attaque nécessite un grand nombre de tentatives répétées sur une plage de valeurs de clés dans des colonnes de partitionnement ou de clustering. Même si le bruit est inhérent à l'observation ou à la mesure de la durée des requêtes, avec des tentatives répétées, un pirate informatique pourrait obtenir une estimation fiable. Si vous êtes sensible à ce niveau de protection, nous vous recommandons plutôt d'utiliser des tables distinctes pour isoler les lignes soumises à des exigences de contrôle d'accès différentes.
- Un pirate informatique pourrait rechercher les octets traités par une requête en surveillant les erreurs qui se produisent lorsque les limites des tâches de requête (telles que le nombre maximal d'octets facturés ou les contrôles de coût personnalisés) sont dépassées. Cependant, cette attaque nécessite un grand nombre de requêtes.
- À l'aide de requêtes répétées et en observant le montant de la facturation BigQuery dans Cloud Billing, un utilisateur peut déduire les valeurs des lignes qui seraient autrement protégées par des règles d'accès au niveau des lignes. Ce type d'attaque nécessite un grand nombre de tentatives répétées sur une plage de valeurs de clés dans des colonnes de partitionnement ou de clustering. Si vous êtes sensible à ce niveau de protection, nous vous recommandons de limiter l'accès aux données de facturation pour les requêtes.
Nous recommandons également aux administrateurs de surveiller les journaux d'audit Cloud (/bigquery/docs/reference/auditlogs) pour détecter toute activité suspecte sur les tables sécurisées au niveau des lignes, telles que les ajouts, modifications et suppressions inattendus de règles d'accès au niveau des lignes.
Limiter les autorisations des utilisateurs afin de limiter l'altération de données
Les utilisateurs disposant d'autorisations d'écriture sur une table peuvent insérer des données dans la table à l'aide de la commande bq load ou de l'API BigQuery Storage Write. Cela permet à l'utilisateur disposant des autorisations en écriture de modifier les résultats de requête d'autres utilisateurs.
Nous recommandons aux administrateurs de créer des groupes Google distincts pour les règles d'accès en écriture aux tables et au niveau des lignes. Les utilisateurs qui ne doivent voir que les résultats de table filtrée ne doivent pas disposer d'un accès en écriture à la table filtrée.
Éviter les accès par inadvertance lorsque de la recréation des règles d'accès au niveau des lignes
Lorsque vous ajoutez une règle d'accès aux lignes d'une table pour la première fois, vous commencez immédiatement à filtrer les données dans les résultats de la requête. Lorsque vous supprimez la dernière règle d'accès au niveau des lignes dans une table, même si vous ne souhaitez recréer que la règle d'accès au niveau de la ligne, vous pouvez accorder par inadvertance un accès non filtré à une audience plus large.
Nous recommandons aux administrateurs de prêter une attention particulière à la recréation de la dernière règle d'accès au niveau des lignes en suivant les instructions ci-dessous :
- Commencez par supprimer tous les accès à la table à l'aide des contrôles d'accès à la table.
- Supprimez toutes les règles d'accès au niveau des lignes.
- Recréez les règles d'accès au niveau de la ligne souhaitée.
- Réactivez l'accès à la table.
Vous pouvez également créer des règles d'accès au niveau des lignes de la table, puis supprimer les anciennes règles d'accès au niveau des lignes qui ne sont plus nécessaires.
Utiliser la sécurité au niveau des lignes uniquement au sein des organisations, et non entre les organisations
N'utilisez pas la fonctionnalité de sécurité au niveau des lignes au sein des organisations, pour éviter les fuites de données lors d'attaques sur les versions secondaires et pour maintenir un meilleur contrôle sur l'accès aux données sensibles.
Nous vous recommandons d'utiliser la fonctionnalité de sécurité au niveau des lignes uniquement pour les contraintes de sécurité au sein d'une organisation (par exemple, pour le partage de données au sein d'une organisation/entreprise), et non pour la sécurité interorganisationnelle ou publique.
Exemple
En dehors de votre organisation, vous avez moins de contrôle sur qui a accès aux données. Au sein de votre organisation, vous pouvez contrôler qui a accès aux informations de facturation des requêtes sur les tables avec des règles d'accès au niveau des lignes. Les informations de facturation constituent un vecteur d'attaque par canal secondaire.
Utiliser le rôle Filtered Data Viewer avec prudence
Lorsque vous créez une règle d'accès au niveau des lignes, les comptes principaux de la règle se voient automatiquement attribuer le rôle bigquery.filteredDataViewer. Vous ne pouvez ajouter ou supprimer des comptes principaux de la règle qu'avec une instruction LDD.
Toutefois, il est possible d'accorder le rôle bigquery.filteredDataViewer via IAM à une ressource de niveau supérieur, telle qu'une table, un ensemble de données ou un projet. L'attribution du rôle bigquery.filteredDataViewer à un utilisateur lui permet d'afficher les lignes définies par toutes les règles d'accès au niveau des lignes de cette table, de cet ensemble de données ou de ce projet.
Toutefois, l'attribution du rôle bigquery.filteredDataViewer sur une table ne signifie pas nécessairement que l'utilisateur peut voir toutes les lignes de la table. L'union de toutes les expressions de filtre des règles d'accès au niveau des lignes peut former ou non une fermeture sur l'ensemble de la table.
Nous vous recommandons d'être prudent avant d'attribuer le rôle bigquery.filteredDataViewer sur une ressource.
Le filtrage sur des colonnes partitionnées a un impact sur les performances
Les filtres des règles d'accès au niveau des lignes ne participent pas à l'élimination des requêtes sur les tables partitionnées et en cluster.
Si votre règle d'accès au niveau des lignes nomme une colonne partitionnée, votre requête ne bénéficie pas des avantages en termes de performances de l'élimination des requêtes.