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 apprendre des données sensibles via l'observation ou la recherche de données de facturation, de journalisation ou 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.
Rôles de lecteur Stackdriver Metrics et Monitoring pour BigQuery Afficher les métriques des requêtes, y compris les octets traités et les données associées.
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.
  • Grâce à des requêtes répétées et élaborées, un utilisateur malveillant peut apprendre des informations sensibles en observant les messages d'erreur qui en résultent. Plus précisément, un utilisateur malveillant ayant accès à la table sous-jacente peut potentiellement dériver des valeurs de ligne protégées lorsque la requête renvoie une exception de division par zéro, même s'il existe un prédicat de sécurité en place pour empêcher cet utilisateur d'interroger directement les mêmes données. Ce type d'attaque nécessite souvent un grand nombre de tentatives répétées sur une table disposant d'une sécurité au niveau des lignes.
  • 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.

Éviter d'ouvrir par inadvertance l'accès lors 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 :

  1. Commencez par supprimer tous les accès à la table à l'aide des contrôles d'accès à la table.
  2. Supprimez toutes les règles d'accès au niveau des lignes.
  3. Recréez les règles d'accès au niveau de la ligne souhaitée.
  4. Réactivez l'accès à la table à l'aide de contrôles d'accès aux tables.

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.