Présentation des contrôles d'accès aux tables

Ce document présente la LCA BigQuery Table.

La LCA BigQuery Table vous permet de définir des autorisations au niveau de la table sur des ressources telles que les tables et les vues. Les autorisations au niveau de la table déterminent les utilisateurs, les groupes et les comptes de service autorisés à accéder à une table ou à une vue. Vous pouvez autoriser un utilisateur à accéder à des tables ou des vues spécifiques, sans lui accorder l'accès à l'ensemble de données entier. Par exemple, attribuez le rôle "Lecteur de données BigQuery" (roles/bigquery.dataViewer) à un utilisateur pour permettre à cet utilisateur d'interroger uniquement la table ou la vue, même s'il n'a pas accès à l'ensemble de données.

Contrôle des accès avec les stratégies de gestion de l'authentification et des accès

Vous pouvez configurer la stratégie de contrôle d'accès sur une table ou une vue à l'aide d'une stratégie de gestion de l'authentification et des accès (IAM).

Afficher la stratégie IAM d'une table ou d'une vue

Une fois la table ou la vue créée, vous pouvez afficher la stratégie IAM de l'une des manières suivantes :

Définir la stratégie IAM d'une table ou d'une vue

Vous pouvez définir ou mettre à jour la stratégie de contrôle d'accès d'une ressource de différentes manières :

Une vue peut également faire référence à d'autres tables et vues source que vous avez partagées à l'aide de la LCA de la table BigQuery.

L'accès avec la LCA de la table BigQuery vient en supplément. Pour en savoir plus sur le contrôle des accès supplémentaire, consultez la page Contrôler l'accès aux vues. La LCA de table BigQuery n'accepte pas l'autorisation deny.

Vous pouvez vérifier si un utilisateur a accès à une table ou à une vue spécifique à l'aide de la méthode tables.testIamPermissions. Pour en savoir plus, consultez la section Tester les autorisations.

Pour en savoir plus sur la définition d'une stratégie, consultez les instructions détaillées de la page Contrôler l'accès aux tables et aux vues.

Exemple d'utilisation

Alice est propriétaire de données pour une entreprise qui souhaite partager la table inventory avec les propriétaires de magasins franchisés. La table se trouve dans un ensemble de données contenant d'autres tables qu'Alice ne souhaite pas partager avec les propriétaires des magasins franchisés.

Bob est propriétaire d'un magasin franchisé. Alice utilise l'outil de ligne de commande bq pour attribuer à Bob et aux autres propriétaires de magasins franchisés le rôle de lecteur de données BigQuery (roles/bigquery.dataViewer) au niveau de la table inventory. Bob peut désormais interroger directement la table inventory sans avoir besoin d'accéder à l'ensemble de données complet.

Si Alice souhaite également que Bob puisse afficher une liste des tables auxquelles il a accès, elle peut accorder à Bob l'autorisation bigquery.tables.list sur l'ensemble de données. Le rôle lecteur de métadonnées BigQuery (roles/bigquery.metadataViewer) inclut l'autorisation bigquery.tables.list.

Stratégies IAM

Les contrôles d'accès au niveau de la table s'appuient sur IAM. Grâce à l'IAM, vous pouvez contrôler qui (utilisateurs) dispose de quel accès (rôles) à quelles ressources en définissant des stratégies. Une stratégie définit et applique les rôles attribués aux membres. Cette stratégie est associée à une ressource. Lorsqu'un membre authentifié tente d'accéder à une ressource, IAM vérifie la stratégie de la ressource pour déterminer si l'action est autorisée.

Pour la LCA de la table BigQuery, la ressource est une table BigQuery, et les membres sont des utilisateurs de la table.

L'exemple suivant illustre une stratégie dans laquelle :

  • Le rôle de propriétaire de données BigQuery (roles/bigquery.dataOwner) a été attribué à alice@example.com.

  • Le rôle de lecteur de données BigQuery (roles/bigquery.dataViewer) a été attribué à bob@example.com.

{
  "bindings":[
    {
      "members":[
        "user:alice@example.com"
      ],
      "role":"roles/bigquery.dataOwner"
    },
    {
      "members":[
        "user:bob@example.com"
      ],
      "role":"roles/bigquery.dataViewer"
    }
  ],
  "etag":"ABAC",
  "version":1
}

Pour en savoir plus sur les stratégies IAM, consultez la page Comprendre les stratégies.

Autorisations LCA de table BigQuery

Pour définir ou modifier l'accès à une table ou une vue, vous devez disposer de l'autorisation bigquery.tables.setIamPolicy. Les rôles prédéfinis BigQuery suivants disposent de l'autorisation bigquery.tables.setIamPolicy.

  • Administrateur BigQuery (roles/bigquery.admin)
  • Propriétaire de données BigQuery (roles/bigquery.dataOwner)

Pour récupérer l'accès défini sur une table ou une vue, vous devez disposer de l'autorisation bigquery.tables.getIamPolicy. Les rôles prédéfinis BigQuery suivants disposent de l'autorisation bigquery.tables.getIamPolicy.

  • Administrateur BigQuery (roles/bigquery.admin)
  • Éditeur de données BigQuery (roles/bigquery.dataEditor)
  • Lecteur de métadonnées BigQuery (roles/bigquery.metadataViewer)
  • Propriétaire de données BigQuery (roles/bigquery.dataOwner)
  • Lecteur de données BigQuery (roles/bigquery.dataViewer)

Délai avant modification des stratégies

En règle générale, toute modification de stratégie prend effet dans les 60 secondes. Toutefois, dans certaines circonstances, la diffusion complète des modifications dans le système peut demander jusqu'à 7 minutes. Pour en savoir plus, consultez la page Accorder, modifier et révoquer les accès à des ressources. En outre, consultez la section Impact sur la mise en cache.

Impact sur la mise en cache

Si la mise en cache est activée, un compte peut afficher les résultats de la requête précédemment autorisée une fois que le compte n'a plus accès à la table. Plus précisément, si l'utilisateur a déjà exécuté la requête avec succès, puis supprimé son accès, il peut obtenir des résultats à partir du cache des résultats de la requête. BigQuery ne met en cache que les accès autorisés, et ils ne sont mis en cache que pendant quelques minutes.

Impact sur les fonctionnalités temporelles

La clause FOR SYSTEM_TIME AS OF correspond à la fonctionnalité temporelle de BigQuery, qui vous permet d'extraire des données datant d'il y a jusqu'à 7 jours. Si vous utilisez cette fonctionnalité, BigQuery applique la LCA de la table actuelle à votre requête. Si vous aviez déjà accès à la table, mais que votre accès a été supprimé, vous ne pouvez pas accéder aux versions précédentes de la table.

Impact lors de la copie de tables

Lorsque vous copiez des données dans une nouvelle table, les LCA de la table source ne sont pas copiées automatiquement. Si vous souhaitez créer une LCA de table sur une nouvelle table créée via une copie, vous devez définir explicitement une LCA de table sur la nouvelle table.

Comparaison avec les vues autorisées

BigQuery fournit également un accès à l'aide de vues autorisées. Une vue autorisée vous permet de partager des résultats de requête avec des utilisateurs et des groupes particuliers sans leur donner accès aux tables sous-jacentes. L'accès en lecture autorisée est toujours en lecture seule.

Par exemple, la vue autorisée dept_view permet à l'utilisateur joe@example.com de consulter le salaire moyen par service, mais pas le salaire individuel dans l'ensemble de données salary sous-jacent. Si dept_view a accès à la source de données, joe@example.com n'a besoin que des autorisations sur dept_view.

La principale différence entre une vue standard et une vue autorisée se porte sur l'autorité utilisée pour contrôler l'accès aux données de la table source. L'accès d'une vue standard aux données de la table source est vérifié pour le compte de l'autorité de l'utilisateur final. L'accès d'une vue autorisée aux données de la table source est vérifié à l'aide de l'autorité de la vue autorisée.

Avec la LCA BigQuery Table, vous disposez désormais des options suivantes pour accéder à la table :

  • Partager un ensemble de données, y compris toutes ses tables sources, avec les utilisateurs. Cette option correspond au contrôle des accès IAM défini au niveau de l'ensemble de données.
  • Créer une vue autorisée pour accéder aux données sources auxquelles l'utilisateur n'a pas l'accès IAM. Les données sources sont accessibles en fonction de l'autorité de la vue autorisée et non de celle de l'utilisateur. Il s'agit de la fonctionnalité de vues autorisées.
  • Partagez une table ou une vue avec des utilisateurs spécifiques sans partager toutes les données de l'ensemble de données parent. Il s'agit de la fonctionnalité de LCA d'une table BigQuery.

Compatibilité avec d'autres fonctionnalités BigQuery

Dans le modèle d'accès IAM, les autorisations sont additives. Les autorisations de ressource sont héritées d'une ressource parente, comme décrit dans la section Hiérarchie des ressources. Toutes les autorisations ajoutées à la ressource entraînent l'octroi d'un accès supplémentaire. Une LCA de table ne peut autoriser qu'un accès supplémentaire et ne peut pas supprimer l'accès à un ensemble de données ou à un projet Google Cloud. Si une fonctionnalité BigQuery ne peut pas vérifier l'accès au niveau de la table, elle revient au contrôle des accès existant au niveau de l'ensemble de données. Par conséquent, la LCA de la table BigQuery est compatible avec d'autres fonctionnalités BigQuery.

Compatibilité avec VPC Service Controls

VPC Service Controls utilise IAM pour contrôler l'accès à des services tels que BigQuery et Cloud Storage. La LCA BigQuery Table utilise IAM pour fournir un niveau de détail plus précis du contrôle des accès aux tables BigQuery individuelles. Étant donné qu'ils utilisent IAM de manière complémentaire, VPC Service Controls et la LCA de table BigQuery sont compatibles.

Journaux d'audit

La définition d'une règle sur une table ou une vue est une activité d'administration. Une activité d'administration est toujours enregistrée. Pour afficher l'activité enregistrée, utilisez Cloud Audit Logging pour rechercher des occurrences de methodName définies sur "google.iam.v1.IAMPolicy.SetIamPolicy".

Journalisation des LCA de tables

Limites

  • Les vues autorisées au niveau de la table ne sont pas acceptées. Les vues autorisées ne peuvent accéder qu'à des ensembles de données entiers. Toutefois, vous pouvez utiliser la LCA de table BigQuery pour accorder aux utilisateurs l'accès à une table ou à une vue individuelle.

  • Actuellement, si une table est directement partagée sans son ensemble de données sous-jacent, la table partagée n'apparaît pas dans les résultats de recherche Data Catalog.

  • Les contrôles d'accès au niveau de la table ne sont pas vérifiés lors de l'interrogation de tables génériques. Si vous avez l'intention de partager les tables auxquelles les utilisateurs accèdent via un caractère générique de table dans une requête, vous devez accorder l'accès utilisateur à l'ensemble de données contenant les tables.

  • À l'instar des tables génériques, les tables de l'ensemble de données INFORMATION_SCHEMA ne sont pas soumises au contrôle d'accès au niveau de la table. Elles nécessitent également des autorisations au niveau de l'ensemble de données.

Étape suivante