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

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 section Gérer les accès.

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.

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.

Formats des attributs

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

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

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

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

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 à 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 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.
• Soyez prudent lorsque vous utilisez l'expression resource.name.startsWith dans votre condition, car les chemins d'accès aux tables BigQuery sont précédés de leur ID de projet parent et de leur ID d'ensemble de données. Les conditions qui ne sont pas assez spécifiques peuvent accorder un accès trop permissif. Toutefois, l'expression resource.name.startsWith est utile si vous souhaitez permettre à vos utilisateurs d'exécuter des requêtes génériques. Par exemple, 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 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 créer des ressources (bigquery.RESOURCE.create) 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 ou aux routines autorisées avec des conditions IAM.
• Lorsqu'un utilisateur dispose d'un accès conditionnel à un ensemble de données ou à une table, il ne peut pas modifier les autorisations associées à cette ressource via la console Google Cloud. Seuls l'outil bq et l'API sont acceptés.
• 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.

Examples

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 à [email protected] 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": [[email protected]],
  "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 à [email protected] 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": [[email protected]],
  "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 à [email protected] 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": [[email protected]],
  "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 à [email protected] 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": [[email protected]],
  "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": [[email protected]],
  "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": [[email protected]],
  "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

• Découvrez comment configurer un accès temporaire à l'aide de conditions IAM.
• Découvrez comment configurer l'accès basé sur les ressources à l'aide de conditions IAM.