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

Ce document 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 compatible avec les contrôles d'accès au niveau 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 contrôle des 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 l'ensemble de données, au niveau de la table 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. Ces règles servent de filtres pour masquer ou afficher certaines lignes de données, selon qu'un utilisateur ou un groupe figure dans une liste autorisée. Les utilisateurs ou groupes ne figurant pas spécifiquement dans la liste des accès autorisés se voient refuser l'accès.

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 (désignés par le terme "grantee-list") peuvent accéder à certaines données de ligne. La règle inclut également les données suivant lesquelles 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 Gérer 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

Les exemples suivants illustrent les cas d'utilisation potentiels de la sécurité au niveau des lignes.

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

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

Vous pouvez créer et renseigner l'exemple de table à l'aide de la requête suivante:

CREATE TABLE IF NOT EXISTS
  dataset1.table1 (partner STRING,
    contact STRING,
    country STRING,
    region STRING);
INSERT INTO
  dataset1.table1 (partner,
    contact,
    country,
    region)
VALUES
  ('Example Customers Corp', 'alice@examplecustomers.com', 'Japan', 'APAC'),
  ('Example Enterprise Group', 'bob@exampleenterprisegroup.com', 'Singapore', 'APAC'),
  ('Example HighTouch Co.', 'carrie@examplehightouch.com', 'USA', 'US'),
  ('Example Buyers Inc.', 'david@examplebuyersinc.com', 'USA', 'US');

La sécurité au niveau des lignes permet à un propriétaire de données ou à un administrateur de mettre en œuvre des règles. L'instruction suivante implémente une règle qui limite les utilisateurs du groupe de diffusion APAC à ne voir que les partenaires de la région APAC:

CREATE ROW ACCESS POLICY
  apac_filter
ON
  dataset1.table1 GRANT TO ("group: sales-apac@example.com")
FILTER USING
  (region="APAC" );

Par conséquent, les utilisateurs du groupe sales-apac@example.com ne peuvent afficher que les lignes où la valeur de region est APAC.

L'instruction suivante implémente une stratégie qui limite les utilisateurs individuels et les groupes à n'afficher que les partenaires de la région des États-Unis:

CREATE ROW ACCESS POLICY
  us_filter
ON
  dataset1.table1 GRANT TO ("group:sales-us@example.com",
"user: jon@example.com")
FILTER USING
  (region="US");

Par conséquent, les utilisateurs du groupe sales-us@example.com et l'utilisateur jon@example.com ne peuvent afficher que les lignes où la valeur de region est US.

L'image suivante montre comment les deux stratégies d'accès précédentes limitent les utilisateurs et les groupes autorisés à afficher les lignes du tableau:

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

Les utilisateurs qui ne font pas partie des groupes APAC ou US ne voient aucune ligne.

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

Prenons un cas d'utilisation différent, dans lequel vous disposez d'un tableau contenant des informations sur les salaires.

Vous pouvez créer et renseigner l'exemple de table à l'aide de la requête suivante:

CREATE OR REPLACE TABLE
  dataset1.table1 (name STRING,
    department STRING,
    salary INT64,
    email STRING);
INSERT INTO
  dataset1.table1 ( name,
    department,
    salary,
    email)
VALUES
  ('Jim D', 'HR', 100000, 'jim@example.com'),
  ('Anna K', 'Finance', 100000, 'anna@example.com'),
  ('Bruce L', 'Engineering', 100000, 'bruce@example.com'),
  ('Carrie F', 'Business', 100000, 'carrie@example.com');

La règle d'accès aux lignes de l'instruction suivante limite les requêtes aux membres du domaine de l'entreprise. En outre, l'utilisation de la fonction SESSION_USER() limite l'accès aux lignes appartenant à l'utilisateur exécutant la requête, en fonction de son adresse e-mail.

CREATE ROW ACCESS POLICY
  salary_personal
ON
  dataset1.table1 GRANT TO ("domain:example.com")
  FILTER USING
  (Email=SESSION_USER());

L'image suivante montre comment la règle d'accès aux lignes restreint le tableau contenant les informations sur les salaires. Dans cet exemple, l'utilisateur s'appelle Jim et son adresse e-mail est jim@example.com.

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

Filtrer les données de ligne en fonction du tableau de conversion

Pour envoyer des commentaires ou demander de l'aide concernant cette fonctionnalité, envoyez un e-mail à l'adresse bigquery-row-level-security-support@google.com.

Grâce à la compatibilité avec les sous-requêtes, les règles d'accès aux lignes peuvent référencer d'autres tables et les utiliser en tant que tableaux de conversion. Les données utilisées dans les règles de filtrage peuvent être stockées dans une table. Une seule règle d'accès aux lignes de sous-requête peut remplacer plusieurs règles d'accès aux lignes configurées. Pour mettre à jour les règles d'accès aux lignes, il vous suffit de mettre à jour le tableau de conversion, qui remplace plusieurs règles d'accès aux lignes. Vous n'avez pas besoin de mettre à jour chaque règle d'accès aux lignes.

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.

Les 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 en savoir plus sur la prévention de ces attaques, vous pouvez consulter les bonnes pratiques de sécurité au niveau des lignes.

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

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

Méthode Considérations de sécurité Recommandation
Vues
autorisées		 Recommandé pour la flexibilité. Peut être vulnérable aux requêtes élaborées, à la durée des requêtes et à d'autres types d'attaques par canal secondaire. Les vues autorisées constituent un bon choix lorsque vous devez partager des données avec d'autres personnes, et que la flexibilité et les performances sont importantes. Par exemple, vous pouvez utiliser des vues autorisées pour partager des données dans votre groupe de travail.
Règles d'accès au niveau des lignes Option recommandée pour un équilibre entre flexibilité et sécurité. Peut être vulnérable aux attaques par canal secondaire exploitant la durée des requêtes. Les règles d'accès au niveau des lignes sont un bon choix lorsque vous devez partager des données avec d'autres utilisateurs et que vous souhaitez renforcer la sécurité des vues ou des tranches de table. Par exemple, vous pouvez utiliser des règles d'accès au niveau des lignes pour partager des données avec des personnes utilisant le même tableau de bord, même si certaines personnes ont accès à plus de données que d'autres.
Tables distinctes Recommandé pour la sécurité. Les utilisateurs ne peuvent pas déduire des données sans accéder à la table. Les tables distinctes constituent un bon choix lorsque vous devez partager des données avec d'autres personnes et que vous devez isoler les données. Par exemple, vous pouvez utiliser des tables distinctes pour partager des données avec des partenaires et des fournisseurs tiers, alors que le nombre total de lignes doit rester secret.

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. Toutefois, une règle d'accès au niveau des lignes peut affecter le coût d'exécution d'une requête de différentes manières :

  • Des règles d'accès au niveau des lignes, en particulier des règles incluant des sous-requêtes faisant référence à d'autres tables, peuvent entraîner une facturation supplémentaire.

  • 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. Cela ne signifie pas qu'ils lisent davantage de données lors de l'exécution de la requête principale. Il n'exploite pas les prédicats des règles d'accès aux lignes pour l'ajuster davantage.

  • Avec les filtres des règles d'accès au niveau des lignes, tous les filtres utilisateur ne sont pas appliqués de manière anticipée. Cela peut entraîner une augmentation de la quantité de données lues dans les tables, ainsi que la lecture et la facturation d'un plus grand nombre de lignes.

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

Limites

Pour en savoir plus sur les limites de sécurité au niveau des lignes, consultez la section Limites de sécurité au niveau des lignes de BigQuery. Les sections suivantes décrivent des limites de sécurité supplémentaires au niveau des lignes.

Limites de performances

  • Certaines fonctionnalités de BigQuery ne sont pas accélérées lorsque vous utilisez des tables contenant des règles d'accès au niveau des lignes, comme BigQuery BI Engine et les vues matérialisées.

  • La sécurité au niveau des lignes ne participe pas à l'élimination des requêtes, qui constitue une fonctionnalité des tables partitionnées. Pour en savoir plus, consultez la page Tables partitionnées et en cluster. Cette limitation ne ralentit pas l'exécution de la requête principale.

  • Vous risquez de constater une légère dégradation des performances lorsque vous interrogez des tables avec une sécurité au niveau des lignes.

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.

Autres limites

  • Cette fonctionnalité peut ne pas être disponible si vous utilisez des réservations créées avec certaines éditions BigQuery. Pour en savoir plus sur les fonctionnalités activées dans chaque édition, consultez la page Présentation des éditions BigQuery.

  • 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 GoogleSQL. Les requêtes en ancien SQL sont rejetées et renvoient une erreur.

  • Vous ne pouvez pas appliquer de règles d'accès au niveau des lignes sur des colonnes JSON.

  • Vous ne pouvez pas appliquer de règles d'accès au niveau des lignes aux tables qui font référence à d'autres tables dotées de la sécurité au niveau des lignes.

  • Certaines fonctionnalités de BigQuery ne sont pas compatibles avec la sécurité au niveau des lignes. Pour plus d'informations, consultez la section 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 TRUE. 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 la console Google Cloud ou l'outil de ligne de commande bq.

  • L'aperçu ou la navigation dans les tables n'est pas compatible avec la sécurité au niveau des lignes.

  • L'échantillonnage de table n'est pas compatible avec la sécurité au niveau des lignes.

  • Les résultats des règles de sous-requêtes de premier niveau sont limités à 100 Mo. Cette limite s'applique à chaque règle d'accès au niveau des lignes.

  • Si le prédicat de la règle d'accès au niveau des lignes ne peut pas être évalué en raison de la suppression de toute table référencée, la requête échoue.

  • Les règles d'accès aux lignes des sous-requêtes ne sont compatibles qu'avec les tables BigQuery, les tables externes BigLake et les tables gérées BigLake.

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 et toutes les tables correspondantes référencées dans les sous-requêtes apparaissent dans les informations d'autorisation IAM pour 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