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

BigQuery fournit un accès précis aux colonnes sensibles à l'aide de tags avec stratégie, autrement dit une classification des données basée sur le type. La sécurité au niveau des colonnes de BigQuery vous permet de créer des stratégies qui vérifient, au moment de la requête, si un utilisateur dispose d'un accès approprié. Par exemple, une stratégie peut appliquer des contrôles d'accès comme suit :

  • Vous devez figurer dans group:high-access pour voir les colonnes contenant TYPE_SSN.

Workflow de la sécurité au niveau des colonnes

Workflow

Pour restreindre l'accès aux données au niveau des colonnes, procédez comme suit :

  1. Définissez une taxonomie et des tags avec stratégie de données. Utilisez Data Catalog pour créer et gérer une taxonomie et des tags avec stratégie pour vos données. Pour plus d'informations, consultez la page sur les bonnes pratiques d'utilisation des tags avec stratégie.

  2. Attribuez des tags avec stratégie à vos colonnes BigQuery. Dans BigQuery, utilisez des annotations de schéma pour attribuer un tag avec stratégie à chaque colonne dont vous souhaitez restreindre l'accès.

  3. Gérez les accès sur les tags avec stratégie. Utilisez des stratégies Identity and Access Management (IAM) pour limiter l'accès à chaque tag avec stratégie. La stratégie s'applique à chaque colonne appartenant au tag avec stratégie.

Lorsqu'un utilisateur tente d'accéder aux données d'une colonne au moment de la requête, BigQuery vérifie le tag avec stratégie de la colonne et sa stratégie pour voir si l'utilisateur est autorisé à y accéder.

Exemple d'utilisation

Prenons l'exemple d'une organisation qui doit classer les données sensibles en deux catégories: High (Élevé) et Medium (Moyen).

Tags avec stratégie

Pour configurer la sécurité au niveau des colonnes, un responsable des données, qui dispose des autorisations appropriées, effectue les étapes suivantes pour configurer une hiérarchie de classification des données.

  1. Le responsable de données crée une taxonomie nommée "Criticité métier" dans Data Catalog. La taxonomie inclut les nœuds ou les tags avec stratégie élevé et moyen.

  2. Le responsable des données décide que la stratégie définie pour le nœud High (Élevé) inclut l'accès pour un groupe nommé high-tier-access.

  3. Le responsable de données crée davantage de niveaux de nœuds dans la taxonomie, sous Élevée et Moyenne. Le nœud de niveau le plus bas est un nœud feuille, tel que le nœud feuille employee_ssn. Le responsable de données peut créer une règle d'accès différente pour le nœud feuille employee_ssn.

  4. Le responsable de données affecte un tag avec stratégie à des colonnes de table spécifiques. Dans cet exemple, le responsable de données attribue la stratégie d'accès High (Élevé) à la colonne employee_ssn d'une table.

  5. Sur la page Current schema (Schéma actuel) de la console, le responsable des données peut voir le tag avec stratégie qui régit une colonne particulière. Dans cet exemple, la colonne employee_ssn se trouve sous le tag avec stratégie High (Élevé). Ainsi, lorsque vous affichez le schéma pour employee_ssn, la console affiche le nom de la taxonomie et le tag avec stratégie dans le champ Policy tags: Business criticality:High.

    Interface utilisateur des tags avec stratégie

    Pour en savoir plus sur la définition d'un tag avec stratégie à l'aide de la console, consultez la section Définir un tag avec stratégie sur une colonne.

    Vous pouvez également définir le tag avec stratégie à l'aide de la commande bq update. Le champ names de policyTags inclut l'ID du tag avec stratégie High (Élevé), projects/project-id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id :

    [
     ...
     {
       "name": "ssn",
       "type": "STRING",
       "mode": "REQUIRED",
       "policyTags": {
         "names": ["projects/project-id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id",]
       }
     },
     ...
    ]
    

    Pour en savoir plus sur la définition d'un tag avec stratégie à l'aide de la commande bq update, consultez la section Définir un tag avec stratégie sur une colonne.

  6. L'administrateur effectue des étapes similaires pour le tag avec stratégie Medium (Moyen).

Grâce à ces accès précis, vous pouvez gérer l'accès à de nombreuses colonnes en contrôlant simplement un petit nombre de tags avec stratégie servant à classer les données.

Pour plus d'informations sur ces étapes, consultez la page Restreindre l'accès avec la sécurité au niveau des colonnes de BigQuery.

Rôles utilisés avec la sécurité au niveau des colonnes

Les rôles Data Catalog suivants sont utilisés pour la sécurité au niveau des colonnes de BigQuery.

Nom et ID du rôle Autorisations incluses Applicable à Description
Administrateur de tags avec stratégie
datacatalog.categoryAdmin datacatalog.categories.getIamPolicy
datacatalog.categories.setIamPolicy
datacatalog.taxonomies.create
datacatalog.taxonomies.delete
datacatalog.taxonomies.get
datacatalog.taxonomies.getIamPolicy
datacatalog.taxonomies.list
datacatalog.taxonomies.setIamPolicy
datacatalog.taxonomies.update
resourcemanager.projects.get
resourcemanager.projects.list
Projet Ce rôle est autorisé à effectuer les opérations suivantes :
  • créer, lire, mettre à jour et supprimer des taxonomies ;
  • définir des stratégies IAM sur des tags avec stratégie
Un utilisateur doté de ce rôle est normalement chargé de définir les règles de gouvernance des données de l'organisation.

Lecteur détaillé
datacatalog.categoryFineGrainedReader datacatalog.categories.fineGrainedGet Tag avec stratégie Ce rôle est autorisé à accéder au contenu des colonnes BigQuery limitées par un tag avec stratégie.

Généralement, un utilisateur doté de ce rôle interroge les données.

Pour en savoir plus sur les rôles Data Catalog, consultez la page Gestion de l'authentification et des accès Data Catalog (IAM).

Impact des écritures

Pour lire les données d'une colonne protégée par la sécurité au niveau des colonnes, l'utilisateur doit toujours disposer d'une autorisation de lecture, via le rôle de lecteur détaillé, sur les tags avec stratégie de la colonne.

Cela s'applique :

  • Tables, y compris les tables génériques
  • Vues
  • Copie de tables

Pour écrire des données sur une ligne d'une colonne protégée par la sécurité au niveau des colonnes, l'utilisateur doit respecter des exigences qui dépendent du type d'écriture.

Si l'opération d'écriture est une insertion, le rôle de lecteur détaillé n'est pas nécessaire. Cependant, l'utilisateur ne dispose pas d'un accès permettant de lire les données insérées, sauf s'il est doté du rôle de lecteur détaillé.

Si l'opération d'écriture est une mise à jour, une suppression ou une fusion, l'utilisateur ne peut pas effectuer l'opération, sauf s'il est doté du rôle de lecteur détaillé.

Un utilisateur ne peut pas charger des données à partir de fichiers locaux ou de Cloud Storage, sauf s'il est doté du rôle de lecteur détaillé. Cependant, il peut charger des données diffusées à partir d'un flux, car ce type de chargement ne vérifie pas les tags avec stratégie. L'utilisateur ne dispose pas d'un accès permettant de lire les données chargées à partir d'un flux, sauf s'il est doté du rôle de lecteur détaillé.

Pour en savoir plus, consultez la page Impact sur les opérations d'écriture avec la sécurité au niveau des colonnes de BigQuery.

Interroger des tables

Si un utilisateur dispose d'un accès à un ensemble de données et possède le rôle "Lecteur détaillé Data Catalog", il peut accéder aux données des colonnes. L'utilisateur exécute une requête selon la procédure habituelle.

Si un utilisateur dispose d'un accès à un ensemble de données, mais ne possède pas le rôle "Lecteur détaillé Data Catalog", il ne peut pas accéder aux données des colonnes. Si cet utilisateur exécute SELECT *, il reçoit une erreur qui répertorie la ou les colonnes auxquelles il ne peut pas accéder. Pour résoudre cette erreur, vous pouvez procéder comme suit :

  • Modifier la requête pour exclure la ou les colonnes auxquelles l'utilisateur n'a pas accès. Par exemple, si l'utilisateur n'a pas accès à la colonne ssn, mais a accès aux colonnes restantes, il peut exécuter la requête suivante :

    SELECT * EXCEPT (ssn) FROM ...
    

    Dans l'exemple ci-dessus, la clause EXCEPT exclut la colonne ssn.

  • demander à un administrateur Data Catalog d'ajouter l'utilisateur en tant que lecteur détaillé Data Catalog à la classe de données correspondante. Le message d'erreur fournit le nom complet du tag avec stratégie auquel l'utilisateur aurait besoin d'accéder.

Interroger les vues

L'impact de la sécurité au niveau des colonnes sur une vue ne dépend pas du fait qu'il s'agisse ou non d'une vue autorisée. Dans les deux cas, la sécurité au niveau des colonnes est appliquée de manière transparente.

S'il ne s'agit pas d'une vue autorisée :

Si l'utilisateur dispose d'un accès au niveau des colonnes dans les tables sous-jacentes de la vue, il peut interroger les colonnes de la vue. Sinon, il ne peut pas les interroger.

S'il s'agit d'une vue autorisée :

L'accès n'est contrôlé que par la sécurité au niveau des colonnes dans les tables sous-jacentes de la vue. Les stratégies IAM au niveau de la table et de l'ensemble de données, le cas échéant, ne sont pas utilisées pour contrôler l'accès. Si l'utilisateur a accès aux tags avec stratégie utilisés dans les tables sous-jacentes de la vue autorisée, il peut interroger les colonnes de cette vue.

Le schéma suivant illustre l'évaluation de l'accès à une vue.

Accéder aux vues

Impact des instantanés

BigQuery permet aux utilisateurs d'interroger une table dans un état précédent. Ainsi, vous pouvez interroger les lignes d'un instantané précédent de la table. Cette fonctionnalité vous permet également d'effectuer un rollback de la table à la date à laquelle l'instantané a été pris.

En ancien SQL, vous interrogez un instantané en utilisant des décorateurs d'instantanés sur le nom de la table. En SQL standard, vous interrogez un instantané en utilisant la clause FOR SYSTEM_TIME AS OF sur la table.

Le délai pour interroger un instantané est la valeur la plus récente parmi les suivantes :

  • Les sept derniers jours
  • Les date et heure de création de la table

Vous ne pouvez pas interroger une table précédente si la table a été supprimée et recréée avec le même nom.

Pour voir comment les instantanés fonctionnent avec la sécurité au niveau des colonnes, supposons que :

  • vous ayez un point d'origine, qui est une table existante à l'heure actuelle ;

  • vous disposiez de l'instantané de la même table ;

  • le schéma de l'instantané soit identique au schéma de l'origine ou à un sous-ensemble de celui-ci. Autrement dit, toutes les colonnes de l'instantané sont incluses dans l'origine.

Avec ces hypothèses, les autorisations sont vérifiées par rapport à la dernière sécurité au niveau des colonnes sur la table d'origine (actuelle). Si l'utilisateur est autorisé à lire les colonnes actuelles, il pourra interroger un instantané de ces colonnes.

Si le schéma de l'origine et l'instantané diffèrent pour les colonnes de la requête, une requête de récupération d'un instantané échouera.

Considérations relatives aux zones

Lorsque vous choisissez un emplacement pour votre taxonomie, tenez compte des limitations suivantes.

Tags avec stratégie

Les taxonomies sont des ressources régionales, telles que des tables et des ensembles de données BigQuery. Lorsque vous créez une taxonomie, vous spécifiez la région, ou l'emplacement, pour la taxonomie.

Vous pouvez créer une taxonomie et appliquer des tags avec stratégie aux tables de toutes les régions où BigQuery est disponible. Toutefois, pour appliquer des tags avec stratégie d'une taxonomie à une colonne de table, la taxonomie elle-même et la table doivent exister au même emplacement régional.

Bien que vous ne puissiez pas appliquer un tag avec stratégie à une colonne de table qui se trouve à un autre emplacement, vous pouvez copier la taxonomie dans un autre emplacement en le dupliquant explicitement ici.

Si vous souhaitez utiliser la même taxonomie et les mêmes tags avec stratégie sur plusieurs emplacements régionaux, découvrez comment répliquer des taxonomies dans la section Gérer les tags avec stratégie sur plusieurs emplacements.

Organisations

Vous ne pouvez pas utiliser de références dans plusieurs organisations. Une table et tous les tags avec stratégie que vous souhaitez appliquer à ses colonnes doivent exister au sein de la même organisation.

Limites

  • Si vous écrasez une table de destination, tous les tags avec stratégie existants sont supprimés de la table, sauf si vous utilisez l'option --destination_schema pour spécifier un schéma avec des tags avec stratégie. L'exemple suivant montre comment utiliser --destination_schema.

    bq query --destination_table mydataset.mytable2 \
      --use_legacy_sql=false --destination_schema=schema.json \
      'SELECT * FROM mydataset.mytable1'
    
  • Une colonne ne peut contenir qu'un seul tag avec stratégie.

  • Une table peut contenir au maximum 1 000 tags avec stratégie.

  • Vous ne pouvez pas utiliser l'ancien SQL si vous avez activé la sécurité au niveau des colonnes. Toutes les requêtes en ancien SQL sont rejetées s'il existe des tags avec stratégie dans les tables cibles.

Tarifs

La sécurité au niveau des colonnes nécessite l'utilisation de BigQuery et de Data Catalog.Pour plus d'informations sur la tarification de ces produits, consultez les rubriques suivantes:

Journaux d'audit

Lorsque des données de table contenant des tags avec stratégie sont lues, nous enregistrons les tags avec stratégie référencés dans Cloud Logging. Toutefois, la vérification des tags avec stratégie n'est pas associée à la requête qui l'a déclenchée.

Grâce à Cloud Logging, les auditeurs peuvent déterminer qui dispose de quel type d'accès pour quelles catégories de données sensibles. Pour en savoir plus, consultez la page Audit des tags avec stratégie.

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