Résoudre les problèmes de contrôle des accès

Ce document explique comment résoudre les problèmes de sécurité liés aux autorisations Identity and Access Management (IAM), au contrôle des accès au niveau des colonnes et aux clés de chiffrement gérées par le client (CMEK) dans BigQuery. Les problèmes d'autorisation IAM entraînent généralement des erreurs Access Denied telles que les suivantes :

  • Access Denied: Project PROJECT_ID: User does not have bigquery.jobs.create permission in project PROJECT_ID.
  • Access Denied: Project PROJECT_ID: User does not have bigquery.datasets.get permission on dataset DATASET.
  • User does not have permission to query table PROJECT_ID:DATASET.TABLE.
  • Access Denied: Table PROJECT_ID:DATASET.TABLE: User does not have permission to query table PROJECT_ID:DATASET.TABLE, or perhaps it does not exist.
  • Access Denied: User PRINCIPAL does not have permission to perform bigquery.tables.getData on resource 'projects/PROJECT_ID/datasets/DATASET/tables/TABLE'.

Avant de commencer

  • Pour résoudre les problèmes d'accès d'un principal à une ressource BigQuery, assurez-vous de disposer des autorisations IAM requises.

Recueillir des informations sur le problème

La première étape pour résoudre un problème d'accès à une ressource consiste à déterminer l'autorisation manquante, le compte principal IAM dont l'accès a été refusé et la ressource à laquelle le compte principal tentait d'accéder.

Obtenir des informations à partir de l'historique des erreurs ou des jobs

Pour obtenir des informations sur le principal, la ressource et les autorisations, examinez le résultat de l'outil de ligne de commande bq, la réponse de l'API ou BigQuery dans la console Google Cloud .

Par exemple, si vous essayez d'exécuter une requête avec des autorisations insuffisantes, une erreur semblable à celle ci-dessous s'affiche dans l'onglet Informations sur le job de la section Résultats de la requête de la console Google Cloud .

Une erreur d'accès refusé s'affiche dans l'onglet "Informations sur le job" de la section "Résultats de la requête".

Examinez l'erreur pour identifier le compte principal, la ressource et les autorisations.

Dans certains cas, vous pouvez demander les autorisations manquantes directement à partir du message d'erreur. Pour en savoir plus, consultez la section Messages d'erreur liés aux autorisations dans la documentation IAM.

Obtenir des informations à partir de Cloud Audit Logs

Si le message d'erreur est générique, s'il manque des informations ou si l'action a échoué dans un processus en arrière-plan, utilisez l'explorateur de journaux Cloud Audit Logs pour obtenir des informations sur l'erreur.

  1. Dans la console Google Cloud , accédez à la page Explorateur de journaux.

    Accéder à l'explorateur de journaux

    Vous pouvez également sélectionner Surveillance > Explorateur de journaux dans le menu de navigation.

  2. Dans l'explorateur de journaux, sélectionnez Journaux de projet comme champ d'application des journaux.

  3. Dans la fenêtre de requête, saisissez la requête suivante pour obtenir les erreurs liées aux autorisations à partir des journaux d'accès aux données BigQuery :

    resource.type="bigquery_resource" AND
logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access" AND
protoPayload.status.message:"Access Denied" OR
protoPayload.status.message:"Permission denied" OR
protoPayload.status.code=7

    Remplacez PROJECT_ID par l'ID du projet.

  4. Dans les résultats de la requête, développez l'entrée de journal correspondant à l'opération ayant échoué.

  5. Dans la section protoPayload, développez le tableau authorizationInfo, puis développez chaque nœud du tableau authorizationInfo.

    Le tableau authorizationInfo affiche chaque vérification des autorisations effectuée lors de l'appel d'API.

  6. Pour connaître la cause de l'erreur, recherchez l'entrée granted: false. L'entrée granted: false affiche les informations suivantes :

    • permission : chaîne d'autorisation IAM qui a été vérifiée. Exemple :bigquery.tables.getData
    • resource : nom complet de la ressource à laquelle le principal a tenté d'accéder. Exemple : projects/myproject/datasets/mydataset/tables/mytable.
    • principalEmail (le cas échéant) : référencé dans protoPayload.authenticationInfo, il s'agit du compte principal qui a tenté d'effectuer l'action.

    Section "authorizationInfo" du protoPayload qui affiche l'autorisation, la ressource et l'adresse e-mail du compte principal.

Utiliser Policy Analyzer pour les règles d'autorisation

Policy Analyzer pour les stratégies d'autorisation vous permet d'identifier quels comptes principaux IAM disposent de quel accès à quelles ressources BigQuery selon vos stratégies d'autorisation IAM.

Une fois que vous avez rassemblé des informations sur l'erreur d'autorisation, vous pouvez utiliser Policy Analyzer pour comprendre pourquoi le compte principal ne dispose pas de l'accès requis. Cet outil analyse toutes les stratégies pertinentes, les appartenances à des groupes Google et l'héritage des ressources parentes telles qu'un projet, un dossier et votre organisation.

Pour utiliser Policy Analyzer avec des règles d'autorisation, vous devez créer une requête d'analyse, spécifier un champ d'application pour l'analyse, puis exécuter la requête.

  1. Dans la console Google Cloud , accédez à la page Analyseur de règles.

    Accéder à Policy Analyzer

    Vous pouvez également sélectionner IAM et administration> Analyseur de règles dans le menu de navigation.

  2. Cliquez sur Créer une requête personnalisée.

  3. Sur la page Configurer votre requête, saisissez les informations que vous avez recueillies précédemment :

    1. Dans la section Sélectionner le champ d'application, dans le champ Sélectionner le champ d'application de la requête, vérifiez que votre projet actuel s'affiche ou cliquez sur Parcourir pour choisir une autre ressource.

    2. Dans la section Définir les paramètres de requête, pour Paramètre 1, sélectionnez Principal, puis dans le champ Principal, saisissez l'adresse e-mail de l'utilisateur, du groupe ou du compte de service.

    3. Cliquez sur  > Ajouter un paramètre.

    4. Pour Paramètre 2, sélectionnez Autorisation, puis dans le champ Autorisation, cliquez sur Sélectionner, choisissez l'autorisation BigQuery, puis cliquez sur Ajouter. Par exemple, sélectionnez bigquery.tables.getData.

    5. Cliquez sur  > Ajouter un paramètre.

    6. Pour Paramètre 3, sélectionnez Ressource, puis saisissez le nom complet de la ressource dans le champ Ressource. Le nom de la ressource doit inclure le préfixe du service, comme dans les exemples suivants :

      • Projet BigQuery : //cloudresourcemanager.googleapis.com/projects/PROJECT_ID
      • Ensemble de données BigQuery : //bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET
      • Table BigQuery : //bigquery.googleapis.com/projects/PROJECT/datasets/DATASET/tables/TABLE

  4. Dans le volet Requête personnalisée, cliquez sur Analyser > Exécuter la requête.

  5. Examinez les résultats de la requête. Voici les différents résultats possibles :

    • Une liste vide. L'absence de résultat confirme que le compte principal ne dispose pas de l'autorisation requise. Vous devrez attribuer un rôle au compte principal qui lui accorde les autorisations appropriées.
    • Un ou plusieurs résultats Si l'analyseur trouve une règle d'autorisation, cela signifie qu'il existe une forme d'accès. Cliquez sur Afficher la liaison pour chaque résultat afin d'afficher les rôles qui donnent accès à la ressource dont le principal est membre. L'association de stratégie indique si l'accès est accordé par le biais de l'appartenance à un groupe ou de l'héritage, ou s'il est refusé par une condition IAM ou une stratégie de refus IAM.

Trouver le rôle IAM approprié qui accorde les autorisations requises

Après avoir confirmé que le compte principal ne dispose pas d'un accès suffisant, l'étape suivante consiste à trouver le rôle IAM prédéfini ou personnalisé approprié qui accorde les autorisations requises. Le rôle que vous choisissez doit respecter le principe du moindre privilège.

Si votre organisation utilise des rôles personnalisés, vous pouvez trouver le rôle approprié en listant tous les rôles personnalisés créés dans votre projet ou votre organisation. Par exemple, dans la console Google Cloud , sur la page Rôles, vous pouvez filtrer la liste par Type : Personnalisé pour n'afficher que les rôles personnalisés.

Pour trouver le rôle IAM prédéfini approprié, procédez comme suit.

  1. Ouvrez la section sur les autorisations BigQuery de la page sur les rôles et autorisations IAM BigQuery.

  2. Dans la barre de recherche Saisissez une autorisation, saisissez l'autorisation que vous avez récupérée à partir du message d'erreur, de l'historique des jobs ou des journaux d'audit. Exemple : bigquery.tables.getData.

    Les résultats de recherche affichent tous les rôles BigQuery prédéfinis qui accordent l'autorisation.

  3. Appliquez le principe du moindre privilège : dans la liste des rôles, choisissez le rôle le moins permissif qui accorde les autorisations requises. Par exemple, si vous avez recherché bigquery.tables.getData pour accorder la possibilité d'interroger les données de table, Lecteur de données BigQuery est le rôle le moins permissif qui accorde cette autorisation.

  4. Attribuez le rôle approprié au compte principal. Pour savoir comment accorder un rôle IAM à une ressource BigQuery, consultez Contrôler l'accès aux ressources avec IAM.

Résoudre les problèmes liés au contrôle des accès au niveau des colonnes

Les sections suivantes expliquent comment résoudre les problèmes liés au contrôle des accès au niveau des colonnes et aux tags avec stratégie Data Catalog.

Je ne vois pas les rôles Data Catalog

Si vous ne voyez pas de rôles tels que Lecteur détaillé Data Catalog, il est possible que vous n'ayez pas activé l'API Data Catalog dans votre projet. Pour en savoir plus sur l'activation de l'API Data Catalog, consultez la section Avant de commencer. Les rôles Data Catalog s'affichent quelques minutes après l'activation de l'API Data Catalog.

Je ne peux pas afficher la page "Taxonomies"

Vous devez disposer d'autorisations supplémentaires pour afficher la page Catégories de tags avec stratégie dans la consoleGoogle Cloud . Par exemple, le rôle Administrateur de tags avec stratégie de Data Catalog a accès à la page Taxonomies.

J'ai appliqué des tags avec stratégie, mais cela ne semble pas fonctionner

Si vous recevez toujours des résultats de requête pour un compte qui ne devrait pas y avoir accès, il est possible que le compte reçoive des résultats mis en cache. Plus précisément, si vous avez déjà exécuté la requête avec succès, puis appliqué des tags de règles, vous pouvez obtenir des résultats à partir du cache des résultats de requête. Par défaut, les résultats des requêtes sont mis en cache pendant 24 heures. La requête échoue immédiatement si vous désactivez le cache des résultats. Pour en savoir plus sur la mise en cache, consultez Impact du contrôle des accès au niveau des colonnes.

En règle générale, la propagation des mises à jour de Cloud IAM prend environ 30 secondes. La propagation des modifications apportées à la hiérarchie des tags avec stratégie peut prendre jusqu'à 30 minutes.

Je ne dispose pas de l'autorisation de lire dans une table avec une sécurité définie au niveau des colonnes

Vous devez disposer du rôle Lecteur détaillé ou du rôle Lecteur masqué à différents niveaux, par exemple au niveau de l'organisation, du dossier, du projet et du tag avec stratégie. Le rôle Lecteur détaillé accorde l'accès aux données brutes, tandis que le rôle Lecteur masqué accorde l'accès aux données masquées. Vous pouvez vérifier cette autorisation au niveau du projet à l'aide de l'outil de dépannage des stratégies IAM.

J'ai défini un contrôle des accès précis dans la taxonomie des tags avec stratégie, mais les utilisateurs voient des données protégées

Pour résoudre ce problème, vérifiez les points suivants :

  • Sur la page Taxonomies de tags avec stratégie du Centre de sécurité BigQuery, vérifiez que le bouton Appliquer le contrôle des accès est sur Activé.

  • Assurez-vous que vos requêtes n'utilisent pas de résultats de requête mis en cache. Si vous utilisez l'outil de ligne de commande bq pour tester vos requêtes, utilisez l'indicateur --nouse_cache pour désactiver le cache de requêtes. Exemple :

    bq query --nouse_cache --use_legacy_sql=false "SELECT * EXCEPT (customer_pii) FROM my_table;"

Points à prendre en compte pour la migration de projets

Les tags et les taxonomies de règles sont associés à une Google Cloud organisation spécifique et ne sont pas automatiquement réassociés lorsqu'un projet est migré vers une nouvelle organisation. Si vous migrez un projet qui utilise des tags avec stratégie pour le contrôle des accès au niveau des colonnes vers une autre organisation, les problèmes suivants se produisent :

  • Les tags de règles ne sont plus gérables dans la console Google Cloud du projet migré.
  • Vous ne pouvez pas appliquer ces tags avec stratégie aux nouvelles colonnes du projet migré.
  • Les contrôles des accès au niveau des colonnes existants peuvent sembler toujours en place, mais le lien vers la taxonomie source dans l'organisation d'origine est rompu à des fins de gestion.

Pour résoudre ce problème, l'assistance Google Cloud doit intervenir manuellement pour réassocier la taxonomie à la nouvelle organisation. Si vous avez migré un projet avec des tags de règles et que vous rencontrez ces problèmes, contactez Cloud Customer Care.

Résoudre les problèmes liés aux clés de chiffrement gérées par le client

La liste suivante décrit les erreurs courantes et les solutions recommandées lorsque vous utilisez des clés de chiffrement gérées par le client (CMEK) avec Cloud Key Management Service :

Erreur : Please grant Cloud KMS CryptoKey Encrypter/Decrypter role
Résolution : le compte de service BigQuery associé à votre projet ne dispose pas des autorisations IAM suffisantes pour fonctionner sur la clé Cloud KMS spécifiée. Pour accorder l'autorisation IAM requise, suivez les instructions du message d'erreur ou de la section Accorder une autorisation de chiffrement et de déchiffrement.
Erreur : Existing table encryption settings don't match encryption settings specified in the request
Résolution : cette erreur peut se produire lorsque la table de destination possède des paramètres de chiffrement différents de ceux de votre requête. Pour résoudre ce problème, remplacez la table à l'aide de la disposition d'écriture TRUNCATE ou spécifiez une table de destination différente.
Erreur : This region is not supported
Solution : la région de la clé Cloud KMS ne correspond pas à celle de l'ensemble de données BigQuery pour la table de destination. Pour résoudre ce problème, sélectionnez une clé dans la région de votre ensemble de données ou chargez les données dans un ensemble de données appartenant à la même région que la clé.
Erreur : Your administrator requires that you specify an encryption key for queries in project PROJECT_ID.
Résolution : une règle d'administration a empêché la création d'une ressource ou l'exécution d'une requête. Pour en savoir plus sur cette règle, consultez Exiger des CMEK pour toutes les ressources.
Erreur : Your administrator prevents using KMS keys from project KMS_PROJECT_ID to protect resources in project PROJECT_ID.
Résolution : une règle d'administration a empêché la création d'une ressource ou l'exécution d'une requête. Pour en savoir plus sur cette règle, consultez Restreindre les clés Cloud KMS pour un projet BigQuery.

Étapes suivantes