Présentation de la sécurité au niveau des lignes de BigQuery

Cette page présente le concept de sécurité au niveau des lignes et explique comment l'utiliser pour sécuriser vos données, en plus d'autres informations.

Qu'est-ce que la sécurité au niveau des lignes ?

La sécurité au niveau des lignes vous permet de filtrer les données et d'accéder à des lignes spécifiques d'une table, en fonction des conditions éligibles de l'utilisateur.

BigQuery est déjà compatible avec les contrôles d'accès du projet, de l'ensemble de données et de la table, ainsi qu'avec la sécurité au niveau des colonnes à l'aide de tags avec stratégie. La sécurité au niveau des lignes étend le principe du moindre privilège en permettant un contrôle d'accès précis à un sous-ensemble de données d'une table BigQuery, au moyen de règles d'accès au niveau des lignes.

Une même table peut disposer de plusieurs règles d'accès au niveau des lignes. Les règles d'accès au niveau des lignes peuvent coexister sur une table avec une sécurité au niveau des colonnes, ainsi que des contrôles d'accès au niveau de la table, au niveau de l'ensemble de données et au niveau du projet.

Fonctionnement de la sécurité au niveau des lignes

En règle générale, la sécurité au niveau des lignes implique la création de règles d'accès au niveau des lignes sur une table BigQuery cible. Cette règle sert ensuite de filtre pour masquer ou afficher certaines lignes de données, selon qu'un utilisateur ou un groupe figure dans une liste autorisée.

Un utilisateur autorisé, doté des rôles IAM (Identity and Access Management) administrateur BigQuery ou DataOwner, peut créer des règles d'accès au niveau des lignes sur une table BigQuery.

Lorsque vous créez une règle d'accès au niveau des lignes, vous spécifiez la table par son nom, et les utilisateurs ou groupes (appelés grantee-list) doivent avoir accès à certaines données de ligne. La règle inclut également les données à filtrer, appelées filter_expression. La fonction filter_expression agit comme une clause WHERE dans une requête type.

Pour découvrir comment créer et utiliser une règle d'accès au niveau des lignes, consultez la page Utiliser la sécurité au niveau des lignes.

Consultez la documentation de référence sur le LDD pour connaître la syntaxe complète, l'utilisation et les options lors de la création de règles d'accès au niveau des lignes.

Exemples de cas d'utilisation

Filtrer les données de ligne en fonction de la région

Prenons l'exemple d'une table qui contient des lignes appartenant à différentes régions, indiquées par la colonne region de la table dataset1.table1.

La sécurité au niveau des lignes permet à un propriétaire de données ou à un administrateur de mettre en œuvre des règles, telles que "Les utilisateurs du groupe:apac ne peuvent voir que les partenaires de la région APAC."

Cas d'utilisation de la sécurité au niveau des lignes pour les régions

Par conséquent, les utilisateurs du groupe sales-apac@example.com ne peuvent afficher que les lignes où Region = "APAC". De même, les utilisateurs du groupe sales-us@example.com ne peuvent afficher que les lignes de la région US. Les utilisateurs qui ne font pas partie des groupes APAC ou US ne voient aucune ligne.

Notez que la règle d'accès au niveau des lignes nommée us_filter accorde l'accès à plusieurs entités, y compris au responsable commercial jon@example.com, qui peuvent toutes accéder aux lignes appartenant à US.

Filtrer les données de ligne en fonction de données sensibles

Prenons un cas d'utilisation différent, dans lequel nous disposons d'une table de données sur les salaires.

Cas d'utilisation de la sécurité au niveau des lignes pour les salaires

La méthode grantee_list limite les requêtes aux membres du domaine de l'entreprise. En outre, l'utilisation de la fonction SESSION_USER() limite davantage l'accès aux lignes appartenant à l'utilisateur exécutant la requête, en fonction de sa propre adresse e-mail. Dans ce cas, il s'agit de jim@example.com.

Quand utiliser la sécurité au niveau des lignes par rapport à d'autres méthodes ?

Les vues autorisées, les règles d'accès au niveau des lignes et le stockage des données dans des tables distinctes présentent différents niveaux de sécurité, de performances et de commodité. Il est important de choisir le mécanisme adéquat pour votre cas d'utilisation afin de garantir un niveau de sécurité approprié pour vos données.

Comparaison avec les vues autorisées : failles

La sécurité au niveau des lignes et l'application d'un accès au niveau des lignes avec une vue autorisée peuvent présenter des failles si elles sont utilisées de manière incorrecte.

Lorsque vous utilisez des vues autorisées ou des règles d'accès au niveau des lignes pour la sécurité au niveau des lignes, nous vous recommandons de surveiller les activités suspectes à l'aide de la journalisation d'audit.

  • Des requêtes élaborées peuvent divulguer des informations via des messages d'erreur. Par exemple, une requête conçue pour déclencher une division par zéro sur une valeur spécifique peut révéler la présence de cette valeur, même si elle est exclue par la définition de la vue.

  • D'autres canaux secondaires, tels que la durée de la requête, peuvent divulguer des informations sur les lignes situées à la périphérie d'une partition de stockage. De telles attaques nécessiteront soit une certaine connaissance de la partition de la table, soit un grand nombre de requêtes.

Pour plus d'informations sur la protection contre de telles attaques par canal secondaire, consultez les Limites de sécurité et les Bonnes pratiques en matière de sécurité au niveau des lignes dans BigQuery.

Comparaison des vues autorisées, de la sécurité au niveau des lignes et des tables distinctes

Le tableau ci-dessous compare les performances et la sécurité des vues autorisées, des règles d'accès au niveau des lignes et des tables distinctes.

Sécurité Recommandations pour…
VUES
AUTORISÉES
Vulnérabilité à des requêtes élaborées, à la durée des requêtes et à d'autres types d'attaques par canal secondaire. Lorsque la flexibilité et les performances sont primordiales.

Exemple : partage de données au sein d'un même groupe de travail.
Règles d'accès au niveau des lignes Vulnérabilité aux requêtes élaborées, à d'autres types d'attaques par canal secondaire comme la durée des requêtes. Lorsqu'il est pratique de demander à tous les utilisateurs d'interroger la même table. Par exemple, lorsque tout le monde partage le même tableau de bord, mais que certains utilisateurs ont accès à davantage de données.

Pour renforcer la sécurité des vues.

Exemple : partage de tranches de table au sein de votre organisation.
Tables distinctes Isolation complète. Lorsque l'isolation est primordiale. Par exemple, le nombre total de lignes doit être secret.

Exemple : partage de données en dehors de votre organisation, par exemple avec des partenaires et des fournisseurs tiers

Créer et gérer des règles d'accès au niveau des lignes

Pour en savoir plus sur la création, la mise à jour (recréation), la liste, l'affichage et la suppression des règles d'accès au niveau des lignes d'une table, ainsi que sur l'interrogation de tables avec des règles d'accès au niveau des lignes, consultez la page Utiliser la sécurité d'accès au niveau des lignes.

Quotas

Pour en savoir plus sur les quotas et les limites concernant la sécurité au niveau des lignes, consultez la page Quotas et limites de BigQuery.

Tarifs

La sécurité au niveau des lignes est incluse dans BigQuery, sans frais supplémentaires.

Les coûts de facturation pour accéder aux règles d'accès au niveau des lignes d'une table sont semblables à ceux d'une requête. Toutefois, les règles d'accès au niveau des lignes peuvent affecter indirectement le nombre d'octets traités, des manières suivantes.

  • Lorsqu'une requête est exécutée sur une table avec une règle d'accès au niveau des lignes, le nombre d'octets facturés est calculé de la même manière que si vous aviez composé une requête identique avec une clause WHERE, au lieu de l'expression de filtre.
  • 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.

Pour en savoir plus sur la tarification des requêtes BigQuery, consultez la section Tarifs de BigQuery.

Limites

La sécurité au niveau des lignes est soumise aux limites suivantes.

Limites de performances

Pour en savoir plus sur l'interaction de la sécurité au niveau des lignes avec certaines fonctionnalités et des services BigQuery spécifiques, consultez la page Utiliser la sécurité au niveau des lignes avec d'autres fonctionnalités BigQuery.

Limites de sécurité

Exemple

Supposons que vous disposiez d'une table contenant des informations sur les revenus. Vous protégez ces données sensibles avec une règle d'accès au niveau des lignes pour filtrer les lignes en fonction de l'unité commerciale. Même si un prédicat de filtre de sécurité est en place pour empêcher un utilisateur ayant accès à cette table d'interroger directement les lignes protégées, il est possible qu'il dérive les informations sur les revenus d'autres unités commerciales, à l'aide de requêtes répétées et élaborées, ainsi qu'en observant les messages d'erreur de requête qui en résultent.

  • Plus précisément, un utilisateur malveillant ayant accès à la table sous-jacente peut déduire les valeurs de ligne protégée lorsque la requête renvoie une exception de division par zéro.
  • Une exception de division par zéro résulte d'une requête, par exemple : SELECT * FROM dataset.table WHERE 1/(100000-revenue) = 1. Le résultat peut permettre à l'utilisateur malveillant d'apprendre que les revenus s'élèvent à 100 000 $.
  • 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. Nous recommandons aux administrateurs de surveiller les journaux d'audit Cloud pour détecter toute activité suspecte sur les tables sécurisées au niveau des lignes.

Pour en savoir plus sur la limitation des attaques par canal secondaire, consultez la section Bonnes pratiques en matière de sécurité au niveau des lignes dans BigQuery.

Autres limites

  • Les règles d'accès aux lignes ne sont pas compatibles avec l'ancien SQL. Les requêtes de tables avec des règles d'accès au niveau des lignes doivent utiliser le langage SQL standard. Les requêtes en ancien SQL sont rejetées et renvoient une erreur.

  • Certaines fonctionnalités de BigQuery ne sont pas compatibles avec la sécurité au niveau des lignes. Pour en savoir plus, consultez la page Utiliser la sécurité au niveau des lignes.

  • Les opérations autres que les requêtes, y compris les tâches de compte de service, qui nécessitent un accès complet aux données des tables peuvent utiliser la sécurité au niveau des lignes avec le filtre "Vrai". Exemples : copie de table, workflows Dataproc, etc. Pour plus d'informations, consultez la section Utiliser la sécurité au niveau des lignes.

  • La création, le remplacement ou la suppression de règles d'accès au niveau des lignes doivent être effectués avec des instructions LDD. La liste et l'affichage des règles d'accès au niveau des lignes peuvent être effectués via Cloud Console ou l'outil de ligne de commande bq.

Journalisation et surveillance des audits

Lorsque des données d'une table avec une ou plusieurs règles d'accès au niveau des lignes sont lues, les règles d'accès au niveau des lignes autorisées pour l'accès en lecture apparaissent dans les informations d'autorisation IAM de cette requête de lecture.

Les règles d'accès au niveau des lignes créées et supprimées sont consignées dans un journal d'audit et sont accessibles via Cloud Logging. Les journaux d'audit incluent le nom de la règle d'accès au niveau des lignes. Toutefois, les définitions filter_expression et grantee_list d'une règle d'accès au niveau des lignes sont omises des journaux, car elles peuvent contenir des informations sur l'utilisateur ou d'autres informations sensibles. La liste et l'affichage des règles d'accès au niveau des lignes ne sont pas consignés.

Pour plus d'informations sur la journalisation dans BigQuery, consultez la page Présentation de la surveillance BigQuery.

Pour en savoir plus sur la journalisation dans Google Cloud, consultez la page Cloud Logging.

Étape suivante