Gestion de l'authentification et des accès

Accéder aux exemples

Cette page présente la gestion de l'authentification et des accès (IAM) et explique comment vous pouvez l'utiliser pour contrôler l'accès aux buckets et aux objets dans Cloud Storage. 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 d'IAM qui concernent spécifiquement Cloud Storage. Pour en savoir plus sur IAM et ses fonctionnalités générales, consultez la page Gestion de l'authentification et des accès, en particulier la section sur la gestion des stratégies IAM.

Présentation

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

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

Par exemple, vous pouvez créer une stratégie IAM 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 définie pour l'ensemble de votre projet, ce qui permet à cet utilisateur d'afficher les objets de n'importe quel bucket de votre projet.

Les membres sont les "acteurs" d'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 Google Cloud plus généralement. Chaque rôle est un ensemble constitué d'une ou plusieurs autorisations. Les autorisations sont les unités de base d'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 Créateur des objets de l'espace de stockage, où il s'agit de la seule autorisation, et Administrateur des objets de l'espace de stockage qui regroupe plusieurs autorisations. Si vous attribuez le rôle Créateur des objets de l'espace de stockage à un membre 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 Administrateur des objets de l'espace de stockage 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 Administrateur des objets de l'espace de stockage au niveau du projet et pas sur un seul bucket, il aura accès à n'importe quel objet dans n'importe quel bucket du projet.

L'utilisation d'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 dans 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 IAM qui s'appliquent à Cloud Storage, consultez la page Autorisations IAM pour Cloud Storage.

Rôles

Les rôles sont des ensembles constitués d'une ou plusieurs autorisations. Par exemple, le rôle Lecteur des objets de l'espace de stockage 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 IAM qui s'appliquent à Cloud Storage, consultez la page Rôles 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 Lecteur des objets de l'espace de stockage au niveau du projet, afin de lui permettre de lire n'importe quel objet stocké dans n'importe quel bucket de votre projet, puis attribuez-lui le rôle Créateur des objets de l'espace de stockage au niveau du bucket pour un bucket spécifique, afin de lui permettre de créer des objets uniquement 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 : Administrateur de l'espace de stockage, Lecteur des objets de l'espace de stockage et Créateur des objets de l'espace de stockage.

Certains rôles ne peuvent être appliqués qu'à un seul niveau. Par exemple, vous ne pouvez appliquer le rôle Lecteur qu'au niveau du projet, tandis que vous ne pouvez appliquer le rôle Propriétaire des anciens objets de l'espace de stockage qu'au niveau du bucket.

Lien avec les LCA

Dans IAM, les rôles liés aux anciens buckets 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 IAM associé aux anciens buckets correspondant au bucket.

Rôle associé aux anciens buckets LCA équivalente
Lecteur des anciens buckets Storage Lecteur de bucket
Rédacteur des anciens buckets Storage Rédacteur de bucket
Propriétaire des anciens buckets Storage Propriétaire de bucket

Tous les autres rôles IAM au niveau du bucket et tous les rôles 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 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 IAM permettant de modifier les LCA

Vous pouvez utiliser 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 même, 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 qu'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, 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, tandis que les types allAuthenticatedUsers et allUsers sont deux types spécialisés. Pour obtenir la liste des types de membres courants dans IAM, consultez la section Concepts liés à l'identité. En plus des types énumérés ici, IAM accepte les types de membres suivants, qui peuvent être appliqués de manière spécifique à vos stratégies IAM :

  • 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 Lecteur pour le projet my-example-project le rôle Créateur des objets de l'espace de stockage pour l'un de vos buckets. Pour ce faire, attribuez aux membres projectViewer:my-example-project le rôle Créateur des objets de l'espace de stockage pour ce bucket.

Conditions

Les conditions IAM vous permettent de définir des conditions qui contrôlent la façon dont les autorisations sont accordées aux membres. Cloud Storage accepte les types d'attributs de condition suivants :

  • resource.name : accordez l'accès aux buckets et aux objets en fonction du nom de bucket ou d'objet. Vous pouvez également utiliser resource.type pour accorder l'accès à des buckets ou à des objets, mais cela est généralement redondant avec l'utilisation de resource.name. L'exemple de condition suivant applique un paramètre IAM à tous les objets ayant le même préfixe :
    resource.name.startsWith('projects/_/buckets/BUCKET_NAME/objects/OBJECT_PREFIX')
  • Date et heure : définissez une date d'expiration pour l'autorisation.
    request.time < timestamp('2019-01-01T00:00:00Z')

Ces expressions conditionnelles sont des instructions logiques qui utilisent un sous-ensemble de CEL (Common Expression Language). Vous spécifiez des conditions dans les liaisons de rôle de la stratégie IAM d'un bucket.

Gardez ces restrictions à l'esprit :

  • Vous devez activer l'accès uniforme au niveau du bucket dans un bucket avant d'ajouter des conditions au niveau du bucket. Bien que les conditions soient autorisées au niveau du projet, vous devez transférer tous les buckets du projet vers un accès uniforme au niveau du bucket pour empêcher les LCA Cloud Storage de remplacer les conditions IAM au niveau du projet. Vous pouvez appliquer une contrainte d'accès uniforme au niveau du bucket pour activer un accès uniforme au niveau du bucket pour tous les nouveaux buckets de votre projet.
  • La commande gsutil iam ch ne fonctionne pas avec les stratégies contenant des conditions. Pour modifier une stratégie comportant des conditions, utilisez gsutil iam get pour récupérer la stratégie du bucket concerné, modifiez-la localement, puis utilisez gsutil iam set pour la réappliquer au bucket.
  • Pour utiliser des conditions, vous devez disposer de la version 4.38 ou d'une version ultérieure de gsutil.
  • Lorsque vous utilisez l'API JSON pour appeler getIamPolicy et setIamPolicy sur des buckets avec des conditions, vous devez définir la version de la stratégie IAM sur 3.
  • L'autorisation storage.objects.list étant accordée au niveau du bucket, vous ne pouvez pas utiliser l'attribut de condition resource.name pour limiter l'accès à une liste d'objets à un sous-ensemble d'objets du bucket. Pour les utilisateurs qui ne disposent pas de l'autorisation storage.objects.list au niveau du bucket, les fonctionnalités de la console et de gsutil peuvent être dégradées.
  • Les conditions expirées restent dans votre stratégie IAM jusqu'à ce que vous les supprimiez.

Utiliser les autorisations IAM avec les outils Cloud Storage

Bien que les autorisations IAM ne puissent pas être définies via l'API XML, les utilisateurs disposant d'autorisations 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 IAM permettant aux utilisateurs d'effectuer des actions avec différents outils Cloud Storage, consultez les pages IAM avec Cloud Console, IAM avec gsutil, IAM avec JSON et IAM avec XML.

Bonnes pratiques

Comme tous les autres paramètres d'administration, 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 IAM associés aux buckets et aux projets, surtout 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 mesure de sécurité appliquée au moment d'accorder l'accès à vos ressources. Lorsque vous accordez un accès basé sur le principe du moindre privilège, vous accordez à un utilisateur uniquement l'accès dont il a besoin pour accomplir la tâche qui lui est attribuée. Par exemple, si vous souhaitez partager des fichiers avec un autre utilisateur, vous devez lui attribuer 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 les rôles avec l'autorisation setIamPolicy que si vous souhaitez déléguer le contrôle administratif sur les objets et les buckets.

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

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

  • Comprendre les rôles de base Lecteur, Éditeur et Propriétaire dans Cloud Storage

    Les rôles de base Lecteur/Éditeur/Propriétaire 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 Lecteur permet aux membres de répertorier des buckets, mais pas d'afficher des buckets ou des objets. Toutefois :

    • Les membres disposant du rôle Lecteur obtiennent généralement le rôle Lecteur des anciens buckets Storage et ses autorisations pour chaque bucket du projet. En effet, lorsque vous créez un bucket, le comportement par défaut de Cloud Storage consiste à accorder le rôle Lecteur des anciens buckets Storage pour le nouveau bucket au rôle de base Lecteur. Par conséquent, tous les membres disposant du rôle de base Lecteur pour le projet disposent également du rôle Lecteur des anciens buckets Storage pour le nouveau bucket. Ce comportement permet aux membres disposant du rôle Lecteur d'afficher des buckets.

    • La LCA d'objet par défaut projectPrivate s'applique aux buckets, ce qui signifie que la LCA projectPrivate par défaut est appliquée aux objets ajoutés au bucket. Cette LCA permet aux membres disposant du rôle Lecteur d'afficher des objets.

    De même, les rôles de base Éditeur et Propriétaire ont par nature un accès limité à Cloud Storage, mais les membres auxquels ces rôles sont attribués acquièrent le rôle Propriétaire des anciens buckets Storage 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 Lecteur/Éditeur/Propriétaire, 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 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 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 attribuant un rôle approprié, par exemple Administrateur de l'espace de stockage, à vous-même ou à un autre membre au niveau du projet. Sachez que cela donne accès à tous les buckets et objets du projet. Vous devrez 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 Propriétaire au niveau du projet sont les seules entités disposant du rôle Propriétaire des anciens buckets de l'espace de stockage pour un nouveau bucket. Le rôle Propriétaire 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