Contrôler les accès avec des conditions IAM

Ce document explique comment contrôler les accès aux ressources BigQuery à l'aide de conditions IAM.

Les conditions IAM vous permettent de n'accorder l'accès aux ressources BigQuery que si les conditions spécifiées sont remplies. Par exemple, vous pouvez accorder l'accès à une ressource pendant une durée limitée ou de manière périodique à certaines heures de la journée. Les conditions IAM sont acceptées au niveau du projet, du dossier et de l'organisation, et peuvent être appliquées aux ensembles de données, tables, vues, routines et modèles BigQuery.

Les conditions IAM sont utiles pour accorder des autorisations Identity and Access Management (IAM) à de nombreuses ressources associées en même temps, y compris à celles qui n'existent pas encore. Pour accorder des autorisations à des groupes de ressources BigQuery non liés, envisagez d'utiliser des tags IAM.

Avant de commencer

Activez l'API IAM et attribuez des rôles IAM qui donnent aux utilisateurs les autorisations nécessaires pour effectuer chaque tâche de ce document.

Activer l'API IAM

Pour activer l'API IAM, sélectionnez l'une des options suivantes :

Console

Accédez à la page API Identity and Access Management (IAM) et activez l'API.

Activer l'API

gcloud

Exécutez la commande gcloud services enable :

gcloud services enable iam.googleapis.com

Autorisations requises

Pour obtenir l'autorisation dont vous avez besoin pour appliquer des conditions IAM aux ressources BigQuery, demandez à votre administrateur de vous accorder le rôle IAM Administrateur de projet IAM (roles/resourcemanager.projectIamAdmin). Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Ce rôle prédéfini contient l'autorisation resourcemanager.projects.setIamPolicy, qui est nécessaire pour appliquer des conditions IAM aux ressources BigQuery.

Vous pouvez également obtenir cette autorisation avec des rôles personnalisés ou d'autres rôles prédéfinis.

Si vous envisagez d'utiliser des conditions IAM au sein de votre organisation, vous devez également disposer d'autorisations permettant de gérer les règles d'administration.

Pour plus d'informations sur les rôles et les autorisations IAM dans BigQuery, consultez la page Présentation d'IAM.

Attributs de condition

Vous pouvez définir des conditions IAM sur vos ressources BigQuery en fonction des attributs suivants :

  • request.time : heure à laquelle l'utilisateur tente d'accéder à une ressource BigQuery. Pour obtenir plus d'informations et des exemples, consultez la section Attribut Date/Heure.
  • resource.name : chemin d'accès à la ressource BigQuery. Pour en savoir plus sur le format, consultez les tableaux de la section Formats des attributs.
  • resource.type : type de la ressource BigQuery. Pour en savoir plus sur le format, consultez les tableaux de la section Formats des attributs.
  • resource.service : service Google Cloud utilisé par la ressource BigQuery. Pour en savoir plus sur le format, consultez les tableaux de la section Formats des attributs.
  • resource.tags : tags associés à la ressource BigQuery. Les tags ne sont compatibles qu'avec les ressources de tables, d'ensembles de données et de vues BigQuery. Pour en savoir plus sur le format, consultez les tableaux de la section Formats des attributs et de la documentation IAM.

Formats des attributs

Lorsque vous créez des conditions pour les ensembles de données BigQuery, utilisez les formats suivants :

Attribut Valeur
resource.type bigquery.googleapis.com/Dataset
resource.name projects/PROJECT_ID/datasets/DATASET_ID
resource.service bigquery.googleapis.com
resource.tags Compatible avec hasTagKey, hasTagKeyId, matchTag et matchTagId. Pour en savoir plus, consultez la section Tags de ressource.

Lorsque vous créez des conditions pour les tables et les vues BigQuery, utilisez les formats suivants:

Attribut Valeur
resource.type bigquery.googleapis.com/Table
resource.name projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_ID
resource.service bigquery.googleapis.com
resource.tags Compatible avec hasTagKey, hasTagKeyId, matchTag et matchTagId. Pour en savoir plus, consultez la section Tags de ressource.

Lorsque vous créez des conditions pour les routines BigQuery, utilisez les formats suivants :

Attribut Valeur
resource.type bigquery.googleapis.com/Routine
resource.name projects/PROJECT_ID/datasets/DATASET_ID/routines/ROUTINE_ID
resource.service bigquery.googleapis.com

Lorsque vous créez des conditions pour les modèles BigQuery, utilisez les formats suivants :

Attribut Valeur
resource.type bigquery.googleapis.com/Model
resource.name projects/PROJECT_ID/datasets/DATASET_ID/models/MODEL_ID
resource.service bigquery.googleapis.com

Remplacez les éléments suivants :

  • PROJECT_ID : ID du projet contenant les ressources auquel vous accordez l'accès.
  • DATASET_ID : ID de l'ensemble de données auquel vous accordez l'accès.
  • TABLE_ID: ID de la table ou de la vue à laquelle vous accordez l'accès.
  • ROUTINE_ID : ID de la routine à laquelle vous accordez l'accès.
  • MODEL_ID : ID du modèle auquel vous accordez l'accès.

Ajouter des conditions à une ressource

Pour ajouter une condition à un ensemble de données, une table, une vue, une routine ou un modèle dans BigQuery, consultez la section Stratégies d'autorisation avec des conditions. Lorsque vous créez vos conditions, référez-vous aux tableaux des formats d'attributs.

Bonnes pratiques concernant les conditions

Lorsque vous créez des conditions dans BigQuery, suivez les bonnes pratiques suivantes :

  • N'utilisez pas de conditions négatives pour resource.type, resource.name ou resource.service, car les types non compatibles utilisent la chaîne vide et correspondent à presque toutes les conditions négatives. Pour en savoir plus, consultez la section Conditions négatives.
  • Incluez resource.type, resource.name et resource.service dans votre condition, même lorsque ce niveau de précision n'est pas nécessaire. Cette pratique vous aide à mettre en œuvre vos conditions à mesure que les ressources de votre workflow changent, afin que d'autres ressources ne soient pas incluses involontairement à l'avenir.
  • Lorsque vous accordez des autorisations, incluez l'ensemble d'autorisations le plus restreint possible pour vous assurer de ne pas accorder involontairement un accès trop permissif.
  • Utilisez resource.name.startsWith avec précaution. Les chemins d'accès aux tables et aux vues BigQuery sont précédés de leur ID de projet parent et de leur ID d'ensemble de données. Des conditions qui ne sont pas suffisamment spécifiques peuvent accorder un accès trop étendu. Toutefois, vous pouvez utiliser l'attribut resource.name.startsWith pour permettre aux utilisateurs d'exécuter des requêtes génériques sur des tables. Par exemple, l'accès accordé à l'aide de la condition resource.name.startsWith("projects/my_project/datasets/my_dataset/tables/table_prefix") permet aux utilisateurs d'exécuter la requête SELECT * FROM my_dataset.table_prefix*.
  • N'ajoutez pas de conditions aux ressources BigQuery autres que les ensembles de données, les tables, les vues, les routines et les modèles.
  • Vérifiez que vous accordez les autorisations appropriées sur la ressource adéquate. Par exemple, l'autorisation de répertorier des ressources (bigquery.RESOURCE.list) doit être accordée au niveau du parent, mais l'autorisation de supprimer des ressources (bigquery.RESOURCE.delete) doit être accordée au niveau des ressources. La suppression d'un ensemble de données, y compris de toutes les ressources qu'il contient, nécessite des autorisations de suppression de tables, de modèles et de routines sur l'ensemble de données.
  • Sachez que les instantanés de table et les fonctionnalités temporelles n'ont aucun effet sur les autorisations.

Conditions négatives

Des conditions négatives telles que resource.name != resource peuvent accorder par inadvertance un accès trop permissif. Les ressources BigQuery non compatibles comportent des attributs de ressource vides, ce qui signifie qu'elles correspondent à toutes les conditions négatives. Les ressources des services en dehors de BigQuery peuvent également correspondre à des conditions négatives.

En outre, les conditions négatives créent des problèmes lorsque les utilisateurs exécutent des requêtes avec des caractères génériques. Examinons par exemple la condition négative resource.name != /projects/my_project/datasets/my_dataset/tables/secret. Cette condition semble accorder l'accès à toutes les ressources, à l'exception de la table secret. Toutefois, l'utilisateur peut toujours interroger cette table à l'aide d'une requête générique, telle que SELECT * from my_project.my_dataset.secre*;.

En outre, les conditions négatives des tables, des routines et des modèles peuvent donner un accès trop permissif à leurs ensembles de données parents. Les utilisateurs peuvent ensuite supprimer ces ressources, car les autorisations de suppression sont gérées au niveau de l'ensemble de données.

Limites

  • Vous ne pouvez pas accorder d'autorisations aux vues autorisées, aux routines autorisées ou aux ensembles de données autorisés avec des conditions IAM.
  • Les utilisateurs disposant d'un accès conditionnel à un ensemble de données ou à une table ne peuvent pas modifier les autorisations associées à cette ressource via la console Google Cloud. Les modifications d'autorisation ne sont acceptées que via l'outil bq et l'API BigQuery.
  • Le contrôle des accès au niveau des lignes et des colonnes n'est pas directement compatible avec les conditions IAM. Toutefois, un utilisateur disposant d'un accès conditionnel peut s'attribuer le rôle d'administrateur BigQuery (roles/bigquery.admin) sur la table, puis modifier les règles d'accès aux lignes et aux colonnes.
  • La prise en compte des modifications apportées aux stratégies IAM peut prendre jusqu'à cinq minutes.
  • Les utilisateurs disposant d'un accès conditionnel peuvent ne pas être en mesure d'interroger les vues INFORMATION_SCHEMA.
  • Les utilisateurs qui ne disposent que d'un accès conditionnel aux tables ne peuvent pas exécuter de fonctions de caractères génériques de table.

Exemples

Vous trouverez ci-dessous des exemples de cas d'utilisation des conditions IAM dans BigQuery.

Accorder un accès en lecture à une table spécifique

Cet exemple accorde à cloudysanfrancisco@gmail.com le rôle de lecteur de données BigQuery sur la table table_1 de l'ensemble de données dataset_1. Ce rôle permet à l'utilisateur d'interroger la table et d'y accéder via l'outil bq. L'utilisateur ne peut pas afficher la table dans la console Google Cloud, car il ne dispose pas de l'autorisation bigquery.tables.list sur l'ensemble de données.

{
  "members": [cloudysanfrancisco@gmail.com],
  "role": roles/bigquery.dataViewer,
  "condition": {
    "title": "Table dataset_1.table_1",
    "description": "Allowed to read table with name table_1 in dataset_1 dataset",
    "expression":
resource.name == projects/project_1/datasets/dataset_1/tables/table_1
&& resource.type == bigquery.googleapis.com/Table
  }
}

Accorder un accès permettant de répertorier des ressources sur un ensemble de données spécifique

Cet exemple accorde à cloudysanfrancisco@gmail.com le rôle de lecteur de métadonnées BigQuery sur l'ensemble de données dataset_2. Avec ce rôle, l'utilisateur peut répertorier toutes les ressources de l'ensemble de données, mais ne peut pas exécuter de requêtes sur ces ressources.

{
  "members": [cloudysanfrancisco@gmail.com],
  "role": roles/bigquery.metadataViewer,
  "condition": {
    "title": "Dataset dataset_2",
    "description": "Allowed to list resources in dataset_2 dataset",
    "expression":
resource.name == projects/project_2/datasets/dataset_2
&& resource.type == bigquery.googleapis.com/Dataset
  }
}

Accorder un accès propriétaire à toutes les tables des ensembles de données comportant un préfixe spécifique

Cet exemple accorde à cloudysanfrancisco@gmail.com le rôle de propriétaire de données BigQuery sur toutes les tables des ensembles de données commençant par le préfixe public_ :

{
  "members": [cloudysanfrancisco@gmail.com],
  "role": roles/bigquery.dataOwner,
  "condition": {
    "title": "Tables public_",
    "description": "Allowed owner access to tables in datasets with public_ prefix",
    "expression":
resource.name.startsWith("projects/project_3/datasets/public_")
&& resource.type == bigquery.googleapis.com/Table
  }
}

Accorder un accès propriétaire à l'ensemble des tables, modèles et routines des ensembles de données comportant un préfixe spécifique

Cet exemple accorde à cloudysanfrancisco@gmail.com le rôle de propriétaire de données BigQuery sur l'ensemble des tables, modèles et routines des ensembles de données commençant par le préfixe general_ :

{
  "members": [cloudysanfrancisco@gmail.com],
  "role": roles/bigquery.dataOwner,
  "condition": {
    "title": "Tables general_",
    "description": "Allowed owner access to tables in datasets with general_ prefix",
    "expression":
resource.name.startsWith("projects/project_4/datasets/general_")
&& resource.type == bigquery.googleapis.com/Table
  }
},
{
  "members": [cloudysanfrancisco@gmail.com],
  "role": roles/bigquery.dataOwner,
  "condition": {
    "title": "Models general_",
    "description": "Allowed owner access to models in datasets with general_ prefix",
    "expression":
resource.name.startsWith("projects/project_4/datasets/general_")
&& resource.type == bigquery.googleapis.com/Model
  }
},
{
  "members": [cloudysanfrancisco@gmail.com],
  "role": roles/bigquery.dataOwner,
  "condition": {
    "title": "Routines general_",
    "description": "Allowed owner access to routines in datasets with general_ prefix",
    "expression":
resource.name.startsWith("projects/project_4/datasets/general_")
&& resource.type == bigquery.googleapis.com/Routine
  }
}

Étapes suivantes