Cloud Identity and Access Management

Cette page présente Cloud Identity and Access Management (Cloud IAM) et explique comment l'utiliser pour contrôler l'accès aux buckets et aux objets dans Cloud Storage. Pour apprendre à définir et à gérer les autorisations Cloud IAM pour les buckets et les projets Cloud Storage, consultez la page Utiliser des autorisations Cloud IAM. Pour découvrir les autres méthodes de contrôle des accès aux buckets et aux objets, consultez la page Présentation du contrôle des accès.

Cette page se concentre sur les aspects de Cloud IAM qui concernent spécifiquement Cloud Storage. Pour obtenir des informations détaillées sur Cloud IAM et ses fonctionnalités en général, consultez le guide du développeur relatif à Cloud Identity and Access Management, en particulier la section Gérer les stratégies IAM Cloud.

Présentation

Cloud Identity and Access Management (Cloud IAM) vous permet de contrôler qui a accès aux ressources de votre projet Google Cloud Platform. Les ressources incluent des buckets Cloud Storage et des objets stockés dans ces buckets, ainsi que d'autres entités GCP telles que des instances Compute Engine.

L'ensemble de règles d'accès que vous appliquez à une ressource est appelé stratégie IAM Cloud. Une stratégie IAM Cloud appliquée à votre projet définit les actions que les utilisateurs peuvent exécuter sur tous les objets ou buckets de votre projet. Une stratégie IAM Cloud appliquée à un seul bucket définit les actions que les utilisateurs peuvent exécuter sur ce bucket spécifique et les objets qu'il contient.

Par exemple, vous pouvez créer une stratégie IAM Cloud pour l'un de vos buckets qui permet à un utilisateur d'exercer un contrôle administratif sur ce bucket. En parallèle, vous pouvez ajouter un autre utilisateur à la stratégie IAM Cloud définie pour l'ensemble de votre projet, qui permet à cet utilisateur d'afficher les objets de n'importe quel bucket de votre projet.

Les membres sont les "acteurs" de Cloud IAM. Il peut s'agir d'utilisateurs individuels, de groupes, de domaines ou même du public dans son ensemble. Les membres se voient attribuer des rôles, qui leur accordent l'autorisation d'exécuter des actions dans Cloud Storage ainsi que dans GCP plus généralement. Chaque rôle est un ensemble constitué d'une ou plusieurs autorisations. Les autorisations sont les unités de base de Cloud IAM : chaque autorisation vous permet d'effectuer une action donnée.

Par exemple, l'autorisation storage.objects.create vous permet de créer des objets. Cette autorisation est présente dans des rôles tels que roles/storage.objectCreator, où il s'agit de la seule autorisation, et roles/storage.objectAdmin, qui regroupe plusieurs autorisations. Si vous attribuez à un membre le rôle roles/storage.objectCreator sur un bucket spécifique, il ne peut que créer des objets dans ce bucket. Si vous attribuez à un autre membre le rôle roles/storage.objectAdmin sur le même bucket, il peut exécuter des tâches supplémentaires, comme supprimer des objets, mais uniquement dans ce bucket. Si ces deux utilisateurs se voient attribuer ces rôles et aucun autre, ils n'auront accès à aucun des autres buckets de votre projet. Si vous attribuez à un troisième membre le rôle roles/storage.objectAdmin, non pas sur un seul bucket mais sur votre projet, il a accès à n'importe quel objet de n'importe quel bucket de votre projet.

L'utilisation de Cloud IAM avec Cloud Storage permet de limiter facilement les autorisations accordées à un membre sans avoir à modifier une à une les autorisations relatives à chaque bucket ou objet.

Autorisations

Les autorisations permettent aux membres de réaliser des opérations spécifiques sur des buckets ou des objets dans Cloud Storage. Par exemple, l'autorisation storage.buckets.list permet à un membre de répertorier les buckets de votre projet. Vous n'accordez pas directement des autorisations aux membres, mais vous leur attribuez des rôles auxquels sont associées une ou plusieurs autorisations.

Pour obtenir la liste de référence des autorisations Cloud IAM qui s'appliquent à Cloud Storage, consultez la page Autorisations Cloud IAM pour Cloud Storage.

Rôles

Les rôles sont des ensembles constitués d'une ou plusieurs autorisations. Par exemple, le rôle roles/storage.objectViewer contient les autorisations storage.objects.get et storage.objects.list. Vous attribuez des rôles aux membres, ce qui leur permet d'effectuer des actions sur les buckets et les objets de votre projet.

Pour obtenir la liste de référence des rôles Cloud IAM qui s'appliquent à Cloud Storage, consultez la page Rôles Cloud IAM pour Cloud Storage.

Rôles au niveau du projet et rôles au niveau du bucket

L'attribution de rôles au niveau du bucket n'affecte pas les rôles existants que vous avez attribués au niveau du projet, et inversement. Ainsi, vous pouvez utiliser ces deux niveaux de précision pour personnaliser vos autorisations. Par exemple, imaginons que vous souhaitiez autoriser un utilisateur à lire des objets dans n'importe quel bucket, mais en ne l'autorisant à créer des objets que dans un bucket spécifique. Pour ce faire, attribuez à l'utilisateur le rôle roles/storage.objectViewer au niveau du projet, ce qui l'autorisera à lire tout objet stocké dans un bucket de votre projet, et attribuez-lui le rôle roles/storage.objectCreator au niveau d'un bucket spécifique, ce qui ne l'autorisera à créer des objets que dans ce bucket.

Certains rôles peuvent être utilisés à la fois au niveau du projet et au niveau du bucket. Lorsque les rôles sont utilisés au niveau du projet, les autorisations qu'ils contiennent s'appliquent à tous les buckets et objets du projet. Lorsqu'ils sont utilisés au niveau du bucket, les autorisations associées ne s'appliquent qu'à un bucket spécifique et aux objets qu'il contient. Exemples de rôles de ce type : roles/storage.admin , roles/storage.objectViewer et roles/storage.objectCreator.

Certains rôles ne peuvent être appliqués qu'à un seul niveau. Par exemple, vous ne pouvez appliquer le rôle Viewer qu'au niveau du projet, tandis que vous ne pouvez appliquer le rôle roles/storage.legacyObjectOwner qu'au niveau du bucket.

Lien avec les LCA

Dans Cloud IAM, les rôles Legacy Bucket fonctionnent en tandem avec les LCA de bucket : lorsque vous ajoutez ou supprimez un rôle de ce type, les LCA associées au bucket reflètent vos modifications. De même, la modification d'une LCA spécifique à un bucket met à jour le rôle "Legacy Bucket" correspondant au bucket.

Rôle "Legacy Bucket" LCA équivalente
roles/storage.legacyBucketReader Lecteur de bucket
roles/storage.legacyBucketWriter Rédacteur de bucket
roles/storage.legacyBucketOwner Propriétaire de bucket

Tous les autres rôles Cloud IAM au niveau du bucket et tous les rôles Cloud IAM au niveau du projet fonctionnent indépendamment des LCA. Par exemple, si vous attribuez à un utilisateur le rôle Lecteur des objets de l'espace de stockage, les LCA demeurent inchangées. Cela signifie que vous pouvez utiliser des rôles Cloud IAM au niveau du bucket pour accorder un accès étendu à tous les objets d'un bucket, et utiliser les LCA d'objet qui permettent un contrôle ultraprécis pour personnaliser l'accès à des objets spécifiques dans le bucket.

Autorisation Cloud IAM permettant de modifier les LCA

Vous pouvez utiliser Cloud IAM pour accorder aux membres l'autorisation nécessaire pour modifier les LCA d'objets. Les autorisations storage.buckets suivantes permettent aux utilisateurs de travailler avec des LCA de bucket et les LCA d'objet par défaut : .get, .getIamPolicy, .setIamPolicy et .update.

De la même manière, les autorisations storage.objects suivantes permettent aux utilisateurs de travailler avec des LCA d'objet : .get, .getIamPolicy, .setIamPolicy et .update.

Rôles personnalisés

Bien que Cloud IAM dispose de nombreux rôles prédéfinis qui couvrent les cas d'utilisation courants, vous pouvez définir vos propres rôles qui regroupent les autorisations que vous spécifiez. Pour ce faire, Cloud IAM propose des rôles personnalisés.

Types de membres

Il existe plusieurs types de membres. Par exemple, les comptes Google et les groupes Google représentent deux types généraux, alors que allAuthenticatedUsers et allUsers sont deux types spécialisés. Pour obtenir la liste des types de membres courants dans Cloud IAM, consultez la page Concepts liés à l'identité. En plus des types énumérés ici, Cloud IAM accepte les types de membres suivants, qui peuvent être appliqués de manière spécifique à vos stratégies IAM Cloud :

  • projectOwner:[PROJECT_ID]
  • projectEditor:[PROJECT_ID]
  • projectViewer:[PROJECT_ID]

[PROJECT_ID] est l'ID d'un projet spécifique.

Lorsque vous accordez un rôle à l'un des types de membres ci-dessus, tous les membres dotés de l'autorisation spécifiée pour le projet indiqué se voient attribuer le rôle que vous avez sélectionné. Par exemple, supposons que vous souhaitiez attribuer à tous les membres disposant du rôle Viewer pour le projet my-example-project, le rôle roles/storage.objectCreator pour l'un de vos buckets. Pour ce faire, octroyez au membre projectViewer:my-example-project le rôle roles/storage.objectCreator pour ce bucket.

Utiliser les autorisations Cloud IAM avec les outils Cloud Storage

Bien que les autorisations Cloud IAM ne puissent pas être définies via l'API XML, les utilisateurs disposant d'autorisations Cloud IAM peuvent tout de même utiliser l'API XML, ainsi que tout autre outil permettant d'accéder à Cloud Storage.

Pour savoir quelles sont les autorisations Cloud IAM permettant aux utilisateurs d'effectuer des actions avec différents outils Cloud Storage, consultez les pages Cloud IAM avec Cloud Console, Cloud IAM avec gsutil, Cloud IAM avec JSON et Cloud IAM avec XML.

Bonnes pratiques

Comme tous les autres paramètres administratifs, Cloud IAM requiert une gestion active pour être efficace. Avant de rendre un bucket ou un objet accessible aux autres utilisateurs, veillez à bien savoir avec qui vous souhaitez le partager et quels rôles vous souhaitez attribuer à chaque personne. Au fil du temps, les modifications apportées au processus de gestion de projet, aux modèles d'utilisation et à la propriété organisationnelle peuvent vous contraindre à modifier les paramètres Cloud IAM associés aux buckets et aux objets. Cette remarque s'applique tout particulièrement si vous gérez Cloud Storage dans le cadre d'une grande organisation ou pour un grand groupe d'utilisateurs. Lorsque vous évaluez et planifiez vos paramètres de contrôle des accès, gardez à l'esprit les bonnes pratiques présentées ci-dessous.

  • Utilisez le principe du moindre privilège lorsque vous accordez l'accès.

    Le principe du moindre privilège est une consigne de sécurité qui s'applique à l'attribution de privilèges ou de droits. Lorsque vous accordez l'accès selon ce principe, vous attribuez le privilège minimal requis pour qu'un utilisateur puisse accomplir la tâche qui lui est assignée. Par exemple, si vous souhaitez partager un fichier avec un autre utilisateur, accordez-lui le rôle storage.objectReader, et non le rôle storage.admin.

  • Évitez d'accorder des rôles comportant l'autorisation setIamPolicy à des personnes que vous ne connaissez pas.

    L'autorisation setIamPolicy permet à un utilisateur de modifier les autorisations et de prendre le contrôle des données. Vous ne devez utiliser des rôles avec l'autorisation setIamPolicy que si vous souhaitez déléguer le contrôle administratif appliqué aux objets et aux buckets.

  • Soyez prudent lorsque vous accordez des autorisations aux utilisateurs anonymes.

    Les types de membres allUsers et allAuthenticatedUsers ne doivent être utilisées que s'il est acceptable que tout internaute puisse lire et analyser vos données. Même si ces champs d'application peuvent être utiles pour des applications et des scénarios particuliers, il n'est généralement pas recommandé d'accorder certaines autorisations telles que setIamPolicy, update, create ou delete à tous les utilisateurs.

  • Comprendre les rôles de projet Viewer/Editor/Owner dans Cloud Storage

    Les rôles au niveau du projet Viewer/Editor/Owner accordent bien l'accès que leur nom implique dans Cloud Storage ; toutefois, ils le font indirectement via un accès supplémentaire fourni au niveau du bucket et des objets, à l'aide de types de membres propres à Cloud Storage. Bien que cet accès soit ajouté par défaut, vous pouvez le révoquer.

    Par exemple, le rôle Viewer seul n'accorde que l'autorisation storage.buckets.list à un membre, mais les nouveaux buckets accordent par défaut le rôle roles/storage.legacyBucketReader à tous les membres disposant du rôle Viewer pour le projet. C'est ce rôle de bucket qui permet à un utilisateur disposant du rôle Viewer d'afficher un bucket. De plus, la LCA d'objet par défaut projectPrivate s'applique au bucket, ce qui signifie que les objets ajoutés au bucket se voient appliquer la LCA projectPrivate par défaut. C'est cette LCA qui permet au membre disposant du rôle Viewer d'afficher l'objet.

    De même, les rôles de projet Editor et Owner ont intrinsèquement un accès limité à Cloud Storage, mais les membres auxquels ces rôles sont attribués acquièrent le rôle roles/storage.legacyBucketOwner pour les nouveaux buckets, ainsi que le rôle de propriétaire des objets via la LCA projectPrivate.

    Notez que l'accès aux objets et aux buckets n'étant pas inhérent aux rôles de projet Viewer/Editor/Owner, il est possible de révoquer l'accès que les membres pourraient autrement s'attendre à avoir.

  • Évitez de définir des autorisations qui rendent des buckets et des objets inaccessibles.

    Un bucket ou un objet devient inaccessible lorsque personne n'a l'autorisation de le lire. Cela peut se produire pour un bucket lorsque toutes les autorisations Cloud IAM sur le bucket sont supprimées. Dans le cas d'un objet, cela peut se produire lorsque le propriétaire de l'objet quitte un projet et qu'aucune stratégie IAM Cloud au niveau du bucket ou du projet n'accorde l'accès aux objets. Dans les deux cas, vous pouvez rétablir l'accès en affectant au niveau du projet un rôle approprié, tel que roles/storage.admin, à vous-même ou à un autre membre. Sachez que cela donne accès à tous les buckets et objets du projet. Vous voudrez donc probablement révoquer le rôle après avoir réinitialisé l'accès au bucket ou à l'objet concerné.

  • Veillez à déléguer le contrôle administratif de vos buckets.

    Par défaut, les membres disposant du rôle Owner au niveau du projet sont les seules entités disposant du rôle roles/legacyBucketOwner sur un bucket nouvellement créé. Le rôle Owner doit toujours être attribué à au moins deux membres de sorte que, si un membre de l'équipe quitte le groupe, les buckets puissent être gérés par les autres membres.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Besoin d'aide ? Consultez notre page d'assistance.