Présentation du contrôle des accès au niveau des colonnes

Remarque : 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.

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. Grâce au contrôle des accès au niveau des colonnes de BigQuery, vous pouvez 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.

Pour améliorer le contrôle des accès au niveau des colonnes, vous pouvez éventuellement utiliser le masquage des données dynamiques. Le masquage des données vous permet de masquer les données sensibles en remplaçant la valeur réelle de la colonne par du contenu vide, du contenu par défaut ou du contenu haché.

Workflow de contrôle des accès au niveau des colonnes

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. Créez et gérez une taxonomie et des tags avec stratégie pour vos données. Pour plus d'informations, consultez la page 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. Appliquer le contrôle des accès à la taxonomie Appliquer le contrôle des accès entraîne l'application des restrictions d'accès définies pour tous les tags avec stratégie de la taxonomie.

4. 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.

Remarque : Le contrôle des accès au niveau des colonnes est appliqué en plus des listes de contrôle d'accès aux ensembles de données existantes. Un utilisateur doit disposer d'autorisations à la fois sur les ensembles de données et sur les tags avec stratégie pour accéder à des données protégées par le contrôle des accès au niveau des colonnes.

Identifier les éléments devant recevoir des tags

Pour déterminer les types de données sensibles dont vous disposez et les colonnes nécessitant des tags avec stratégie, envisagez de générer des profils de données couvrant l'organisation, un dossier ou un projet, à l'aide de la protection des données sensibles. Les profils de données contiennent des métriques et des métadonnées relatives à vos tables, et vous permettent de déterminer l'emplacement des données sensibles et à haut risque. La protection des données sensibles signale ces métriques au niveau du projet, de la table et de la colonne. Pour en savoir plus, consultez la page Profils de données pour les données BigQuery.

L'image suivante montre une liste de profils de données de colonne (cliquez sur l'image pour l'agrandir). Les colonnes présentant un risque élevé lié aux données peuvent contenir des données à haute sensibilité sans aucun contrôle d'accès au niveau des colonnes. Ces colonnes peuvent également contenir des données de sensibilité moyenne ou élevée accessibles à un grand nombre de personnes.

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).

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". 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.

   

   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.

   Remarque : Vous ne pouvez attribuer qu'un seul tag avec stratégie par 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 le contrôle des accès au niveau des colonnes.

Rôles utilisés avec le contrôle des accès au niveau des colonnes

Les rôles suivants sont utilisés pour le contrôle des accès au niveau des colonnes de BigQuery.

Le rôle "Administrateur de tags avec stratégie Data Catalog" est requis pour les utilisateurs devant créer et gérer des taxonomies et des tags avec stratégie.

Rôle/Identifiant	Autorisations	Description
Administrateur de tags avec stratégie Data Catalog/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	S'applique au niveau du projet. Ce rôle permet d'effectuer les opérations suivantes : Créer, lire, mettre à jour et supprimer des taxonomies et des tags avec stratégie Obtenir et définir des stratégies IAM au niveau de tags avec stratégie

Le rôle Administrateur BigQuery ou Propriétaire de données BigQuery est requis pour créer et gérer des stratégies de données. Lorsque vous utilisez Google Cloud Console pour appliquer le contrôle des accès à une taxonomie, le service crée une stratégie de données en mode silencieux.

Rôle/Identifiant	Autorisations	Description
Administrateur BigQuery/bigquery.admin Propriétaire de données BigQuery/bigquery.dataOwner	bigquery.dataPolicies.create bigquery.dataPolicies.delete bigquery.dataPolicies.get bigquery.dataPolicies.getIamPolicy bigquery.dataPolicies.list bigquery.dataPolicies.setIamPolicy bigquery.dataPolicies.update	Les autorisations bigquery.dataPolicies.create et bigquery.dataPolicies.list s'appliquent au niveau du projet. Les autres autorisations s'appliquent au niveau de la stratégie de données. Ce rôle permet d'effectuer les opérations suivantes : Créer, lire, mettre à jour et supprimer des stratégies de données Obtenir et définir des stratégies IAM sur des stratégies de données

Vous avez également besoin de l'autorisation datacatalog.taxonomies.get, que vous pouvez obtenir à partir de plusieurs rôles prédéfinis de Data Catalog.

Le rôle "Lecteur détaillé Data Catalog" est requis pour les utilisateurs ayant besoin d'accéder aux données de colonnes sécurisées.

Rôle/Identifiant	Autorisations	Description
Lecteur détaillé/datacatalog.categoryFineGrainedReader	datacatalog.categories.fineGrainedGet	S'applique au niveau du tag avec stratégie. Ce rôle permet d'accéder au contenu des colonnes limitées par un tag avec stratégie.

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

Impact des écritures

Pour lire les données d'une colonne protégée par le contrôle des accès 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 pour une colonne protégée par le contrôle des accès 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 possède le 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 effectuer l'opération que s'il est doté du rôle de lecteur détaillé sur les colonnes en lecture.

Un utilisateur peut charger des données à partir de fichiers locaux ou de Cloud Storage. Lors du chargement de données dans une table, BigQuery ne vérifie pas l'autorisation de lecteur détaillé sur les colonnes de la table de destination. En effet, le chargement de données ne nécessite pas de lire le contenu de la table de destination. De même, un utilisateur 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 le contrôle des accès au niveau des colonnes.

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 les colonnes auxquelles il ne peut pas accéder. Pour résoudre cette erreur, vous pouvez :

• Modifier la requête pour exclure 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 précédent, 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 des 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.

Une vue autorisée correspond à l'un des éléments suivants :

• Vue explicitement autorisée à accéder aux tables d'un ensemble de données
• Vue implicitement autorisée à accéder aux tables d'un ensemble de données, car elle est contenue dans un ensemble de données autorisé

Pour en savoir plus, consultez les sections Vues autorisées et Ensembles de données autorisés.

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

Si l'utilisateur dispose d'un accès IAM aux tables et à l'ensemble de données sous-jacents de la vue, ainsi qu'un accès au niveau des colonnes des 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 :

Seule la sécurité au niveau des colonnes dans les tables sous-jacentes de la vue contrôle l'accès. 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.

Impact des fonctionnalités temporelles et des vues matérialisées avec l'option max_staleness

BigQuery vous permet d'interroger une table dans un état précédent. Cette fonctionnalité vous permet d'interroger les lignes à un moment passé précis. Cela vous permet également de restaurer une table à un moment précis.

En ancien SQL, vous interrogez des données historiques en utilisant des décorateurs temporels sur le nom de la table. Dans GoogleSQL, vous interrogez des données historiques en utilisant la clause FOR SYSTEM_TIME AS OF sur la table.

Les vues matérialisées pour lesquelles l'option max_staleness est définie renvoient des données historiques dans leur intervalle d'obsolescence. Ce comportement est semblable à une requête utilisant FOR SYSTEM_TIME AS OF au moment de la dernière actualisation de la vue, car il permet à BigQuery d'interroger les enregistrements qui ont été supprimés ou mis à jour. Supposons que vous interrogez les données historiques d'une table à l'instant t. Dans ce cas :

• Si le schéma à l'instant t est identique au schéma actuel de la table ou en constitue un sous-ensemble, BigQuery vérifie les dernières informations de sécurité au niveau des colonnes sur la table actuelle. Si l'utilisateur est autorisé à lire les colonnes actuelles, il peut interroger les données historiques de ces colonnes. Pour supprimer ou masquer des données sensibles situées dans des colonnes protégées par la sécurité au niveau des colonnes, la sécurité au niveau des colonnes ne peut être assouplie en toute sécurité qu'après expiration de la fenêtre de fonctionnalité temporelle configurée, à l'issue du nettoyage des données sensibles.

• Si le schéma à l'instant t diffère du schéma actuel pour les colonnes figurant dans la requête, celle-ci échoue.

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 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

• 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.

• BigQuery n'accepte le contrôle d'accès au niveau des colonnes que pour les tables BigLake, les tables BigQuery et les tables BigQuery Omni.

• 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'
  

  Les modifications de schéma se produisent dans une opération distincte de l'exécution de la requête. Si vous écrivez des résultats de requête dans une table en spécifiant l'option --destination_table et que la requête génère ensuite une exception, il est possible que toutes les modifications de schéma soient ignorées. Dans ce cas, vérifiez le schéma de la table de destination et mettez-le à jour manuellement si nécessaire.

• 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é le contrôle des accès 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.

• Une hiérarchie de tags avec stratégie ne peut pas dépasser cinq niveaux de profondeur du nœud racine au sous-tag de niveau le plus bas, comme illustré dans la capture d'écran suivante:

  

• Les noms de taxonomie doivent être uniques parmi tous les projets d'une organisation.

• Vous ne pouvez pas copier une table d'une région à une autre si vous avez activé le contrôle des accès au niveau des colonnes ou des lignes. Toutes les copies de tables dans plusieurs régions sont rejetées s'il existe des tags avec stratégie dans les tables sources.

Tarifs

Le contrôle des accès 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 :

• Tarifs de BigQuery
• Tarifs de Data Catalog

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

• Pour en savoir plus sur l'utilisation du contrôle des accès au niveau des colonnes, consultez la page Restreindre l'accès avec le contrôle des accès au niveau des colonnes.

• Pour en savoir plus sur les bonnes pratiques concernant les tags avec stratégie, consultez la page Bonnes pratiques pour BigQuery : utiliser des tags avec stratégie.