Listes de contrôle d'accès (LCA)

Utilisation

Cette page présente les listes de contrôle d'accès (LCA). Pour en savoir plus sur les autres manières de contrôler l'accès aux buckets et aux objets, reportez-vous à la page Présentation du contrôle des accès.

Faut-il utiliser les listes de contrôle d'accès ?

Dans la plupart des cas, vous devez éviter d'utiliser des LCA et activer l'accès uniforme au niveau du bucket pour vos buckets, ce qui empêche l'utilisation de LCA:

  • Vous ne pouvez pas utiliser exclusivement des LCA pour contrôler l'accès à vos ressources Google Cloud, car les LCA ne peuvent pas être définies sur le projet global ni sur les ressources en dehors de Cloud Storage.
  • Activer l'accès uniforme au niveau du bucket crée une surface de contrôle des accès plus simple et vous permet d'utiliser d'autres fonctionnalités Google Cloud. Pour en savoir plus, consultez la section Devriez-vous utiliser l'accès uniforme au niveau du bucket ?
  • La règle d'administration Partage restreint au domaine et les règles d'administration personnalisées n'empêchent pas l'accès accordé par les LCA, ce qui peut entraîner un accès non intentionnel.
  • Des comportements et des accès inattendus peuvent se produire lors de l'utilisation de LCA dans des projets dont les conditions IAM sont définies au niveau du projet ou au-dessus.

Vous souhaiterez probablement utiliser les LCA dans les cas suivants :

  • Vous devez personnaliser l'accès à des objets spécifiques d'un bucket, par exemple si vous souhaitez que l'utilisateur qui a importé un objet dispose d'un contrôle total sur cet objet, mais d'un accès plus limité aux autres objets du bucket.
  • Vous utilisez exclusivement l'API XML ou vous avez besoin de l'interopérabilité avec Amazon S3.

Identity and Access Management (IAM) (Gestion des identités et des accès) et les LCA fonctionnent conjointement pour accorder l'accès à vos buckets et objets. Cela signifie qu'un utilisateur n'a besoin que des autorisations appropriées provenant de l'un de ces systèmes pour accéder à un bucket ou à un objet. En général, les autorisations attribuées au moyen des stratégies IAM ne figurent pas dans les LCA, et inversement. Pour en savoir plus, consultez la section Relation entre IAM et les LCA.

Qu'est-ce qu'une liste de contrôle d'accès ?

Une liste de contrôle d'accès (LCA) est un mécanisme permettant de déterminer qui a accès à vos buckets et objets, et de définir le niveau d'accès accordé. Dans Cloud Storage, vous appliquez des LCA à des buckets et des objets spécifiques. Chaque LCA comprend une ou plusieurs entrées. Une entrée permet à un utilisateur (ou à un groupe) spécifique d'effectuer des actions particulières. Chaque entrée comporte deux informations :

  • Une autorisation déterminant quelles actions peuvent être effectuées (par exemple, lecture ou écriture)

  • Un champ d'application (parfois appelé bénéficiaire) définissant qui peut exécuter les actions spécifiées (par exemple, un utilisateur ou un groupe d'utilisateurs donné)

Supposons, par exemple, que vous disposiez d'un bucket dont les objets doivent être accessibles à tous les utilisateurs. Vous souhaitez également que votre collaborateur puisse ajouter des objets au bucket ou en supprimer. Dans ce cas, votre LCA doit comporter deux entrées :

  • Dans l'une, vous attribuez l'autorisation READER au champ d'application allUsers.

  • Dans l'autre, vous attribuez l'autorisation WRITER au champ d'application de votre collaborateur. Vous pouvez spécifier cette personne de plusieurs manières, y compris au moyen de son adresse e-mail.

Le nombre maximal d'entrées que vous pouvez créer dans une LCA pour un bucket ou un objet est de 100. Lorsque le champ d'application de l'entrée correspond à un groupe ou à un domaine, il compte comme une seule entrée de LCA, quel que soit le nombre d'utilisateurs présents dans le groupe ou le domaine.

Lorsqu'un utilisateur demande l'accès à un bucket ou à un objet, le système Cloud Storage lit la LCA associée, puis détermine s'il convient d'autoriser ou de refuser cette requête. Si la LCA autorise l'utilisateur à exécuter l'opération concernée, la requête est acceptée. Dans le cas contraire, la requête échoue, ce qui génère une erreur 403 Forbidden.

Notez que, même si les LCA permettent de gérer la plupart des actions impliquant des buckets et des objets, la création d'un bucket requiert l'obtention de l'autorisation de projet appropriée.

Autorisations

Les autorisations décrivent les opérations pouvant être exécutées sur un objet ou un bucket donné.

Cloud Storage vous permet d'attribuer les autorisations concentriques ci-dessous pour vos buckets et vos objets, comme indiqué dans le tableau.

Bucket Objet
READER Permet à un utilisateur de répertorier le contenu d'un bucket. L'utilisateur peut également lire les métadonnées du bucket, à l'exclusion des LCA. Permet à un utilisateur de télécharger les données d'un objet.
WRITER Donne à un utilisateur tous les accès accordés par l'autorisation READER. Autorise également l'utilisateur à créer, remplacer et supprimer des objets dans un bucket, y compris en créant des objets à l'aide d'importations en plusieurs parties. N/A. Vous ne pouvez pas appliquer cette autorisation aux objets.
OWNER Donne à un utilisateur tous les accès accordés par l'autorisation WRITER. Autorise également l'utilisateur à lire et écrire des métadonnées dans le bucket, y compris les LCA, et à utiliser des tags sur le bucket. Donne à un utilisateur tous les accès accordés par l'autorisation READER. Autorise également l'utilisateur à lire et écrire des métadonnées dans l'objet, y compris les LCA.
Par défaut La LCA prédéfinie project-private est appliquée aux buckets lors de leur création. Les buckets appartiennent toujours au groupe project-owners. La LCA prédéfinie project-private est appliquée aux objets lors de leur importation. Les objets appartiennent toujours à l'utilisateur qui a effectué la requête initiale et importé l'objet.

Sur cette page, les autorisations sont généralement désignées sous la forme READER, WRITER et OWNER, c'est-à-dire de la même manière que dans l'API JSON et Google Cloud Console. Si vous faites appel à l'API XML, les autorisations équivalentes sont respectivement READ, WRITE et FULL_CONTROL.

Niveaux d'accès

Les champs d'application spécifient qui dispose d'une autorisation donnée.

Une LCA comprend une ou plusieurs entrées. Chaque entrée accorde des autorisations à un champ d'application. Vous pouvez spécifier un champ d'application de LCA à l'aide de l'une des entités ci-dessous :

Champ d'application ("bénéficiaire") Type d'entité Exemple
Identifiant spécial pour toutes les entités Utilisateur allUsers
Identifiant spécial pour tous les comptes valides Utilisateur allAuthenticatedUsers
Adresse e-mail du compte utilisateur Utilisateur collaborator@gmail.com
Adresse e-mail du compte de service Utilisateur my-service-account@my-project.iam.gserviceaccount.com
Adresse e-mail du groupe Google Groupe work-group@googlegroups.com
Valeurs d'usage pour les projets Projet owners-123456789012
Domaine Google Workspace Domaine dana@example.com
Domaine Cloud Identity Domaine dana@example.com

  • Identifiant spécial pour toutes les entités :

    L'identifiant spécial de champ d'application allUsers représente n'importe quelle entité sur Internet. Bien que cet identifiant soit un type d'entité User, il est associé à un libellé de type Public dans la console Google Cloud.

  • Identifiant spécial pour tous les comptes valides :

    L'identifiant spécial de champ d'application allAuthenticatedUsers représente la plupart des comptes authentifiés, y compris les comptes de service. Pour en savoir plus, consultez la Présentation d'IAM. Bien que cet identifiant soit un type d'entité User, il est associé à un libellé de type Public dans la console Google Cloud.

  • Adresse e-mail du compte utilisateur

    Chaque utilisateur titulaire d'un compte utilisateur doit disposer d'une adresse e-mail unique qui est associée à ce compte. Vous pouvez spécifier un champ d'application en utilisant une adresse e-mail associée à un compte utilisateur.

    Cloud Storage mémorise les adresses e-mail telles qu'elles sont indiquées dans les LCA, tant que les entrées ne sont pas supprimées ni remplacées. Si un utilisateur change d'adresse e-mail, vous devez mettre à jour les entrées de LCA pour refléter ces modifications.

  • Adresse e-mail du compte de service:

    Chaque compte de service est associé à une adresse e-mail unique. Vous pouvez spécifier un champ d'application à l'aide de l'adresse e-mail associée au compte de service.

  • Adresse e-mail du groupe Google :

    Chaque groupe Google possède une adresse e-mail unique qui lui est associée. Par exemple, le groupe Google Cloud Storage - Announce dispose de l'adresse e-mail suivante : gs-announce@googlegroups.com. Vous pouvez trouver l'adresse e-mail associée à un groupe Google en accédant à sa page d'accueil, puis en cliquant sur À propos de.

    Comme pour les adresses e-mail de comptes utilisateur, Cloud Storage mémorise les adresses e-mail de groupe telles qu'elles sont indiquées dans les LCA, tant que les entrées ne sont pas supprimées. Vous n'avez pas à vous soucier de la mise à jour des adresses e-mail des groupes Google, car ces adresses sont permanentes et peu susceptibles de changer.

  • Valeurs d'usage pour les projets :

    Les valeurs d'usage vous permettent d'accorder un accès groupé aux lecteurs, aux éditeurs et aux propriétaires de votre projet. Les valeurs d'usage combinent un rôle de projet et un numéro de projet associé. Par exemple, dans le projet 867489160491, les éditeurs sont identifiés comme suit : editors-867489160491. Le numéro de projet se trouve sur la page d'accueil de Google Cloud Console.

    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.

  • Google Workspace ou Cloud Identity :

    Les clients qui utilisent Google Workspace et Cloud Identity peuvent associer leur compte de messagerie à un nom de domaine Internet. Chaque compte de messagerie se présente alors sous la forme USERNAME@YOUR_DOMAIN.com. Vous pouvez spécifier un champ d'application en utilisant n'importe quel nom de domaine Internet associé à Google Workspace ou à Cloud Identity.

Champs d'application et autorisations concentriques

Lorsque vous spécifiez des LCA dans Cloud Storage, il n'est pas nécessaire d'afficher plusieurs champs d'application pour accorder différentes autorisations. Cloud Storage utilise des autorisations concentriques. Par conséquent, si vous attribuez l'autorisation WRITER, vous accordez également l'autorisation READER. Si vous attribuez l'autorisation OWNER, vous accordez également les autorisations READER et WRITER.

Lorsque vous spécifiez une LCA, la plupart des outils vous permettent de spécifier plusieurs champs d'application pour la même entrée. L'autorisation la plus permissive correspond à l'accès accordé au champ d'application. Par exemple, si vous spécifiez deux entrées pour un utilisateur en attribuant à l'une d'elles l'autorisation READER sur un bucket et à l'autre l'autorisation WRITER, l'utilisateur dispose de l'autorisation WRITER sur le bucket.

Dans l'API XML, il est impossible de spécifier deux entrées de LCA avec le même champ d'application. Par exemple, si vous attribuez à un utilisateur les autorisations READ et WRITE sur un bucket, une erreur est renvoyée. Accordez-lui plutôt l'autorisation WRITE, qui octroie également l'autorisation READ.

LCA prédéfinies

Une LCA prédéfinie, parfois appelée LCA standardisée, est un alias correspondant à un ensemble d'entrées de LCA spécifiques. Vous pouvez l'utiliser pour appliquer rapidement et simultanément plusieurs entrées de LCA à un bucket ou à un objet.

Le tableau ci-dessous répertorie les LCA prédéfinies et indique pour chacune d'elles les entrées appliquées. Lorsque vous utilisez le tableau ci-dessous, notez les points suivants :

  • Le groupe des propriétaires d'un projet est le propriétaire des buckets du projet. Par ailleurs, l'utilisateur qui crée un objet en est le propriétaire. Si un objet a été créé par un utilisateur anonyme, le groupe des propriétaires du projet en est le propriétaire.

  • Le tableau ci-dessous décrit les autorisations OWNER, WRITER et READER de l'API JSON. Les champs d'application équivalents de l'API XML sont FULL_CONTROL, WRITE et READ.

    API JSON/gcloud storage API XML Description
    private private Attribue au propriétaire d'un bucket ou d'un objet l'autorisation OWNER sur ceux-ci.
    bucketOwnerRead bucket-owner-read Attribue au propriétaire d'un objet l'autorisation OWNER et au propriétaire d'un bucket l'autorisation READER. Cette LCA n'est utilisée qu'avec des objets.
    bucketOwnerFullControl bucket-owner-full-control Attribue au propriétaire d'un objet et au propriétaire d'un bucket l'autorisation OWNER. Cette LCA n'est utilisée qu'avec des objets.
    projectPrivate project-private Attribue des autorisations aux membres d'une équipe de projet en fonction de leur rôle. L'autorisation READER est accordée à tous les membres de l'équipe. Les propriétaires et les éditeurs de projets disposent de l'autorisation OWNER. Cette LCA est définie par défaut pour les nouveaux buckets. Il s'agit également de la LCA par défaut des nouveaux objets, sauf si la LCA d'objet par défaut du bucket a été modifiée.
    authenticatedRead authenticated-read Attribue au propriétaire d'un bucket ou d'un objet l'autorisation OWNER. Tous les titulaires d'un compte utilisateur authentifié disposent de l'autorisation READER.
    publicRead public-read Attribue au propriétaire d'un bucket ou d'un objet l'autorisation OWNER. Tous les utilisateurs, authentifiés et anonymes, disposent de l'autorisation READER. Lorsque vous appliquez cette LCA à un objet, tout internaute peut le lire sans s'authentifier. Lorsque vous l'appliquez à un bucket, tout internaute peut répertorier les objets qu'il contient sans s'authentifier.

    * Voir la remarque sur la mise en cache qui figure à la fin du tableau.
    publicReadWrite public-read-write Attribue au propriétaire d'un bucket l'autorisation OWNER. Tous les utilisateurs, authentifiés et anonymes, disposent des autorisations READER et WRITER. Cette LCA ne peut être utilisée que pour les buckets. Lorsque vous l'appliquez à un bucket, tout internaute peut, sans s'authentifier, répertorier, créer, remplacer et supprimer des objets.

    * Voir la remarque sur la mise en cache qui figure à la fin du tableau.

* Par défaut, les objets lisibles publiquement sont diffusés avec un en-tête Cache-Control qui permet leur mise en cache pendant 3 600 secondes. Pour vous assurer que les mises à jour sont visibles immédiatement, vous devez définir les métadonnées Cache-Control des objets sur Cache-Control:private, max-age=0, no-transform.

LCA par défaut

Lorsque vous créez des buckets ou importez des objets, la LCA par défaut leur est appliquée si vous ne leur attribuez pas explicitement une LCA. Vous pouvez modifier la LCA par défaut appliquée à un objet. Pour ce faire, suivez la procédure décrite dans la section Modifier les LCA d'objet par défaut. Notez que, lorsque vous modifiez la LCA par défaut, les LCA des objets qui sont déjà présents dans les buckets du projet demeurent inchangées.

LCA de bucket par défaut

Tous les buckets appartiennent au groupe des propriétaires d'un projet. En outre, les propriétaires de projet disposent de l'autorisation OWNER pour tous les buckets de leur projet qui utilisent une LCA prédéfinie.

Si vous créez un bucket avec la LCA de bucket par défaut (ce qui signifie que vous ne spécifiez pas de LCA prédéfinie lors de la création du bucket), la LCA prédéfinie projectPrivate lui est appliquée.

LCA d'objet par défaut

Par défaut, toute personne disposant de l'autorisation OWNER ou WRITER sur un bucket peut importer des objets dans ce dernier. Lorsque vous importez un objet, vous pouvez indiquer une LCA prédéfinie ou ne pas en spécifier du tout. Si vous ne spécifiez pas de LCA, Cloud Storage applique à l'objet la LCA d'objet par défaut du bucket. Chaque bucket dispose d'une LCA d'objet par défaut qui est appliquée à tous les objets importés s'il n'existe pas de LCA prédéfinie ou si la requête ne spécifie pas de LCA (API JSON uniquement). La valeur initiale de la LCA d'objet par défaut de chaque bucket est projectPrivate.

Les LCA d'objet sont appliquées selon le mode d'importation des objets :

  • Importations authentifiées

    Si vous envoyez une requête authentifiée pour importer un objet et ne spécifiez aucune LCA d'objet lors de l'importation, vous êtes identifié comme propriétaire de l'objet, et la LCA prédéfinie projectPrivate lui est appliquée par défaut. Autrement dit :

    • Vous (utilisateur ayant importé l'objet) êtes identifié comme propriétaire de l'objet. Il est impossible de changer la propriété d'un objet en modifiant les LCA. Vous ne pouvez modifier la propriété d'un objet qu'en remplaçant cet objet.

    • Vous (propriétaire de l'objet) disposez de l'autorisation OWNER sur l'objet. Si vous essayez d'attribuer au propriétaire un niveau d'autorisation inférieur à OWNER, Cloud Storage le redéfinit automatiquement sur OWNER.

    • Le groupe des propriétaires et des éditeurs de projet dispose de l'autorisation OWNER sur l'objet.

    • Le groupe des membres de l'équipe de projet dispose de l'autorisation READER sur l'objet.

  • Importations anonymes

    Si un utilisateur non authentifié (anonyme) importe un objet (ce qui est possible si un bucket accorde au groupe allUsers l'autorisation WRITER ou OWNER), les LCA de bucket par défaut sont appliquées à l'objet comme décrit ci-dessus.

    Les utilisateurs anonymes ne peuvent pas spécifier de LCA prédéfinie lors de l'importation d'un objet.

Comportement des LCA

Cloud Storage vous aide à respecter les bonnes pratiques ci-dessous en appliquant des règles de modification des LCA qui vous empêchent de définir des LCA rendant les données inaccessibles :

  • Il est impossible d'appliquer une LCA spécifiant un autre propriétaire pour un bucket ou un objet.

    Vous ne pouvez pas changer la propriété des buckets et des objets en modifiant les LCA. Si vous appliquez une nouvelle LCA à un bucket ou à un objet, assurez-vous que le propriétaire du bucket ou de l'objet y reste inchangé.

  • Le propriétaire d'un bucket ou d'un objet dispose toujours de l'autorisation OWNER sur eux.

    Le propriétaire d'un bucket est le groupe des propriétaires du projet. Le propriétaire d'un objet est l'utilisateur qui a importé l'objet ou le groupe de propriétaires du projet si l'objet a été importé par un utilisateur anonyme.

    Lorsque vous appliquez une nouvelle LCA à un bucket ou à un objet, Cloud Storage ajoute l'autorisation OWNER respectivement au propriétaire du bucket ou au propriétaire de l'objet si vous omettez d'attribuer cette autorisation. Il n'accorde pas l'autorisation OWNER au groupe des propriétaires du projet pour un objet (sauf si l'objet a été créé par un utilisateur anonyme). Vous devez donc l'inclure explicitement.

Vous ne pouvez pas appliquer de LCA modifiant la propriété d'un bucket ou d'un objet (à ne pas confondre avec l'autorisation OWNER). Une fois définie dans Cloud Storage, la propriété des buckets et des objets est permanente. Vous pouvez toutefois modifier la propriété des objets (mais pas des buckets) en les remplaçant. Le remplacement est une opération de suppression suivie immédiatement d'une importation. La personne qui procède à l'importation devient le propriétaire de l'objet. Notez que l'utilisateur qui procède au remplacement (et devient ainsi propriétaire de l'objet) doit disposer de l'autorisation WRITER ou OWNER sur le bucket dans lequel l'objet est importé.

Étape suivante