Identity and Access Management

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 comptes principaux 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 comptes principaux se voient attribuer des rôles qui leur permettent d'effectuer 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 compte principal pour un bucket spécifique, il ne peut que créer des objets dans ce bucket. Si vous accordez à un autre compte principal 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 accorder ces rôles et aucun autre, ils n'auront accès à aucun des autres buckets de votre projet. Si vous attribuez à un troisième compte principal 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 compte principal sans avoir à modifier une à une les autorisations relatives à chaque bucket ou objet.

Autorisations

Les autorisations permettent aux comptes principaux 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 compte principal de répertorier les buckets dans votre projet. Vous n'accordez pas directement d'autorisations aux comptes principaux. Vous accordez plutôt 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 accordez des rôles aux comptes principaux, 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 pouvez appliquer uniquement le rôle Propriétaire des anciens objets de l'espace de stockage 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 comptes principaux 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 comptes principaux

Il existe plusieurs types de comptes principaux. 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 comptes principaux courants dans IAM, consultez la section Concepts liés à l'identité.

Valeurs d'usage

Cloud Storage est compatible avec les valeurs d'usage, c'est-à-dire un ensemble spécial de comptes principaux pouvant être appliqués spécifiquement à vos stratégies de bucket IAM. Vous devez généralement éviter d'utiliser des valeurs d'usage dans les environnements de production, car cela nécessite d'accorder des rôles de base : une pratique déconseillée dans les environnements de production.

Une valeur d'usage est un identifiant à deux parties composé d'un rôle de base et d'un ID de projet :

  • projectOwner:PROJECT_ID
  • projectEditor:PROJECT_ID
  • projectViewer:PROJECT_ID

Une valeur d'usage agit en tant que pont entre les comptes principaux auxquels ont été attribués le rôle de base et un rôle IAM. Le rôle IAM accordé à la valeur d'usage est également appliqué à tous les comptes principaux du rôle de base spécifié pour l'ID de projet spécifié.

Par exemple, supposons que jane@example.com et john@example.com disposent du rôle de base Lecteur pour un projet nommé my-example-project, et d'un bucket dans ce projet nommé my-bucket. Si vous attribuez le rôle Créateur des objets de l'espace de stockage pour my-bucket à la valeur d'usage projectViewer:my-example-project, jane@example.com et john@example.com obtiennent tous deux les autorisations associées au rôle Créateur des objets de l'espace de stockage pour my-bucket.

Vous pouvez accorder et révoquer l'accès à des valeurs d'usage pour vos buckets, mais sachez que Cloud Storage les applique automatiquement dans certaines circonstances. Pour plus d'informations, consultez la section Comportement modifiable pour les rôles de base dans Cloud Storage.

Conditions

Les conditions IAM vous permettent de définir des conditions qui contrôlent la façon dont les autorisations sont accordées aux comptes principaux. 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 comptes principaux 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.

  • É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 accordant un rôle approprié, par exemple Administrateur de l'espace de stockage, à vous-même ou à un autre compte principal 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.

    Vous devez vous assurer que vos buckets et vos ressources peuvent toujours être gérés par d'autres membres de l'équipe lorsqu'une personne dotée d'un accès administrateur quitte le groupe. Voici deux méthodes couramment utilisées :

    • Accordez le rôle Administrateur de l'espace de stockage de votre projet à un groupe plutôt qu'à une personne.

    • Accordez le rôle Administrateur de l'espace de stockage de votre projet à au moins deux personnes.

Étape suivante