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 compte 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 aux ressources 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 compte 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 Cloud de Confiance .

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

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

Examinez l'erreur pour déterminer 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 Messages d'erreur d'autorisation 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 Cloud de Confiance , accédez à la page Explorateur de journaux.

    Accéder à l'explorateur de journaux

    Vous pouvez également accéder au menu de navigation, puis sélectionner Surveillance > Explorateur de journaux.

  2. Dans l'explorateur de journaux, sélectionnez Journaux de projet pour le 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'échec de l'opération.

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

    Le tableau authorizationInfo affiche chaque vérification d'autorisation 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 compte principal a tenté d'accéder. Exemple : projects/myproject/datasets/mydataset/tables/mytable.
    • principalEmail (si disponible) : référencé dans protoPayload.authenticationInfo, il s'agit du compte principal qui a tenté d'effectuer l'action.

    La section authorizationInfo du protoPayload, qui indique l'autorisation, la ressource et l'adresse e-mail du compte principal.

Utiliser Policy Analyzer pour les stratégies 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.

Après avoir recueilli 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 pour les stratégies 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 Cloud de Confiance , accédez à la page Policy Analyzer.

    Accéder à Policy Analyzer

    Vous pouvez également sélectionner IAM et administration>Policy Analyzer 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 le Paramètre 1, sélectionnez Compte principal, puis saisissez l'adresse e-mail de l'utilisateur, du groupe ou du compte de service dans le champ Compte principal.

    3. Cliquez sur Ajouter un paramètre.

    4. Pour le paramètre 2, sélectionnez Autorisation. 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 le 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. Le résultat peut être l'un des suivants :

    • Une liste vide. L'absence de résultat confirme que le compte principal ne dispose pas de l'autorisation requise. Vous devez attribuer au compte principal un rôle qui fournit les autorisations appropriées.
    • Un ou plusieurs résultats. Si l'analyseur trouve une stratégie d'autorisation, cela signifie qu'un accès existe. Cliquez sur Afficher la liaison pour chaque résultat afin d'afficher les rôles qui fournissent l'accès à la ressource dont le compte principal est membre. La liaison de stratégie indique si l'accès est accordé via l'appartenance à un groupe ou l'héritage, ou si l'accès 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 vérifié 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 répertoriant tous les rôles personnalisés créés dans votre projet ou votre organisation. Par exemple, dans la console Cloud de Confiance , 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 Autorisations BigQuery de la page "Rôles et autorisations IAM BigQuery".

  2. Dans la barre de recherche Saisir 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 d'une 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 attribuer un rôle IAM à une ressource BigQuery, consultez Contrôler l'accès aux ressources avec IAM.

Conditions d'utilisation de BigQuery non acceptées

Chaîne d'erreur : BigQuery Terms of Service have not been accepted

Cette erreur HTTP 403 Forbidden (reason: termsOfServiceNotAccepted) se produit lorsque les conditions d'utilisation de BigQuery n'ont pas été acceptées. L'erreur n'est pas due à des autorisations IAM manquantes. Elle peut être renvoyée pour des requêtes telles que la création d'un ensemble de données ou le chargement de données.

Pour résoudre ce problème, procédez comme suit :

  1. Dans la console Cloud de Confiance , accédez à la page BigQuery.

    Accéder à BigQuery

  2. Si la page de bienvenue s'affiche, sélectionnez votre pays, cochez la case Conditions d'utilisation, puis cliquez sur Accepter et continuer. Pour en savoir plus, consultez Activer le bac à sable BigQuery.

Une fois les conditions d'utilisation acceptées, relancez la requête.

Résoudre les erreurs de non-respect des règles

Lorsque vous recevez une erreur HTTP 403 PERMISSION_DENIED dans BigQuery avec le motif d'erreur policyViolation, cela indique un échec dû à des règles d'administration, des périmètres de données ou VPC Service Controls.

Les sections suivantes décrivent les messages d'erreur les plus courants associés à ce motif d'erreur, leurs causes et comment les résoudre.

La requête est interdite par une règle de l'organisation

Chaîne d'erreur : VPC Service Controls: Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: VPC_SERVICE_CONTROLS_UNIQUE_IDENTIFIER

Diagnostic

Votre requête provient d'une adresse réseau ou d'un client situé en dehors du périmètre VPC Service Controls désigné, ou elle ne respecte pas les règles d'entrée et de sortie définies pour votre espace de travail. Cela se produit fréquemment lorsque votre requête s'étend sur plusieurs projets. Par exemple, le projet de facturation de la requête se trouve en dehors du périmètre sécurisé du projet de données.

Solution

  1. Trouvez l'identifiant unique. Récupérez le vpcServiceControlsUniqueIdentifier inclus dans le message d'erreur. Utilisez cet ID pour filtrer l'explorateur de journaux Cloud de Confiance by S3NSafin de trouver le journal VPC Service Controls correspondant avec les détails du motif :

    protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="VPC_SERVICE_CONTROLS_UNIQUE_IDENTIFIER"

    Recherchez la valeur violationReason sous protoPayload.metadata.violationReason. Une fois identifié, étudiez les détails supplémentaires de l'entrée de journal et suivez le guide de dépannage de VPC Service Controls existant. Envisagez également d'utiliser l'analyseur de cas de non-conformité.

  2. Corrigez la facturation multiprojets. Pour les requêtes multiprojets, assurez-vous que le projet de facturation qui exécute la requête se trouve dans le même périmètre que les données interrogées. Si nécessaire, spécifiez manuellement un projet de facturation conforme à l'aide du sélecteur de projet de la console Cloud de Confiance , de l'option --project_id dans l'outil de ligne de commande bq, ou de votre requête d'API ou de bibliothèque cliente.

  3. Vérifiez les niveaux d'accès. Assurez-vous que votre réseau client, votre adresse IP ou votre compte utilisateur sont autorisés à l'aide d'Access Context Manager. La consoleCloud de Confiance nécessite des règles d'entrée spécifiquement configurées pour autoriser l'accès des utilisateurs aux environnements protégés.

L'exportation vers Google Drive est bloquée pour les projets pour lesquels VPC Service Controls est activé

Chaîne d'erreur : Export to Google Drive is blocked for projects with VPC-SC enabled

Diagnostic

Google Drive n'est pas compatible avec VPC Service Controls. Comme Google Drive ne peut pas appliquer le périmètre de sécurité, BigQuery désactive automatiquement l'exportation des extraits d'API vers Google Drive pour toute requête provenant d'une limite VPC Service Controls afin d'empêcher l'exfiltration de données.

Solution

Au lieu d'exporter directement vers Google Drive, extrayez les résultats de votre requête dans un bucket Cloud Storage situé dans le même périmètre VPC Service Controls, ou enregistrez-les dans un fichier local.

Les tables externes Google Drive sont bloquées pour les projets pour lesquels VPC Service Controls est activé

Chaîne d'erreur : Google Drive external tables are blocked for projects with VPC-SC enabled

Diagnostic

Par défaut, VPC Service Controls ne bloque pas l'interrogation des tables externes Google Drive (comme les feuilles connectées). Toutefois, cette erreur s'affiche, car votre organisation Cloud de Confiance by S3NS a explicitement demandé à Cloud de Confiance by S3NSd'appliquer une configuration de blocage stricte pour votre projet afin de remplacer le comportement permissif par défaut, ce qui empêche toute requête entrante vers les données Google Drive depuis un périmètre VPC Service Controls.

Solution

Importez les données du fichier Google Sheet ou Google Drive directement dans une table BigQuery standard de votre périmètre VPC Service Controls, plutôt que de les interroger de manière dynamique en tant que table fédérée externe. Vous pouvez également contacter votre administrateur Cloud interne pour discuter des limites d'exportation de données de votre organisation.

L'exportation vers Google Drive est bloquée pour votre projet

Chaîne d'erreur : Export to Google Drive is blocked for your project.

Diagnostic

Même sans périmètre VPC Service Controls, vos administrateurs Cloud de Confiance by S3NS ont demandé qu'une configuration organisationnelle stricte et spécifique soit appliquée à votre projet, refusant toutes les fonctionnalités d'extraction de données vers Google Drive.

Solution

Choisissez une autre destination d'extraction, telle qu'un bucket Cloud Storage ou un fichier local, ou contactez votre administrateur Cloud interne pour discuter des limites d'exportation de données de votre organisation.

L'emplacement ne respecte pas la contrainte de règle d'administration

Chaîne d'erreur : LOCATION violates constraint CONSTRAINT_NAME on the resource projects/PROJECT_ID ou LOCATION violates constraint CONSTRAINT_NAME on the resource projects/PROJECT_ID/datasets/DATASET_ID

Diagnostic

Votre administrateur Cloud a configuré une contrainte de règle d'administration pour limiter précisément les emplacements où les ressources peuvent être créées ou analysées. Cette erreur s'affiche généralement dans les cas suivants :

  • Créer un ensemble de données dans une région géographique non autorisée (par exemple, limitée par constraints/gcp.resourceLocations)
  • Tentative d'utilisation de BigQuery Omni sur des clouds externes alors que cela n'est pas autorisé (par exemple, bloqué par constraints/bigquery.disableBQOmniAWS ou constraints/bigquery.disableBQOmniAzure).

Solution

  1. Vérifiez l'élément CONSTRAINT_NAME exact fourni dans le message d'erreur pour comprendre quelle action est bloquée.
  2. Sélectionnez une autre région non bloquée pour vos données ou contactez l'Cloud de Confiance by S3NS administrateur de votre organisation pour examiner la règle d'administration au niveau du dossier ou de l'organisation. Pour en savoir plus, consultez Structurer et définir des emplacements de ressources.

Résoudre les problèmes de 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 consoleCloud de Confiance . 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 avec stratégie, vous obtenez peut-être des résultats du cache des résultats de la 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 plus d'informations sur la mise en cache, consultez la section 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 IAM.

J'ai défini un contrôle ultraprécis des accès dans la taxonomie des tags avec stratégie, mais les utilisateurs voient les 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 en position 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'option --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;"

Considérations sur la migration de projets

Les tags avec stratégie et les taxonomies sont hébergés dans une organisation Cloud de Confiance by S3NS 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 avec stratégie ne sont plus gérables dans la console Cloud de Confiance 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 Cloud de Confiance doit intervenir manuellement pour réassocier la taxonomie à la nouvelle organisation. Si vous avez migré un projet avec des tags avec stratégie 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 utiliser 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 à la région 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 la page Restreindre les clés Cloud KMS d'un projet BigQuery.

Étapes suivantes