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, IAM (Identity and Access Management) est la méthode recommandée pour contrôler les accès à vos ressources :

• IAM fournit un contrôle des accès sur l'ensemble de Google Cloud.
• IAM offre davantage de contrôle sur les actions que les utilisateurs sont autorisés à effectuer.
• Les autorisations IAM accordées aux ressources parentes, telles que les projets, sont héritées par les ressources enfants, telles que les buckets et les objets, ce qui vous permet de gérer plus facilement l'accès aux ressources.
• Les autorisations IAM peuvent être appliquées aux dossiers gérés, contrairement aux LCA.
• Vous ne pouvez pas utiliser exclusivement des LCA pour contrôler l'accès à vos ressources, car les LCA ne peuvent pas être définies sur le projet global ou d'autres ressources parentes.

L'utilisation exclusive d'IAM et de l'accès uniforme au niveau du bucket vous permet d'utiliser d'autres fonctionnalités de sécurité de Google Cloud, telles que le partage restreint de domaine, la fédération d'identité de personnel et les conditions IAM

Vous souhaiterez probablement utiliser les LCA dans les cas suivants :

• Vous devez personnaliser l'accès à des objets spécifiques d'un bucket. Les LCA peuvent être définies pour des objets individuels, tandis que les autorisations IAM ne peuvent être accordées qu'au niveau du bucket ou à un niveau supérieur.
• Vous utilisez exclusivement l'API XML ou vous avez besoin de l'interopérabilité avec Amazon S3.

IAM 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.

Remarque : En général, les autorisations attribuées au moyen des stratégies IAM ne figurent pas dans les LCA, et inversement. Les seules exceptions concernent les LCA appliquées directement à un bucket et certaines stratégies IAM définies au niveau du bucket. Ces cas de figure sont décrits dans la section Lien avec les LCA. Pour réduire les frais de gestion et de suivi, il est recommandé de désactiver le système de LCA et d'utiliser exclusivement IAM.

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.

Remarque : Vous ne pouvez pas accorder d'autorisations discrètes pour la lecture ou l'écriture des LCA ou d'autres métadonnées. Pour permettre à un utilisateur de lire et d'écrire des LCA, vous devez lui attribuer l'autorisation OWNER.

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	[e-mail]
Adresse e-mail du groupe Google	Groupe	[e-mail]
Valeurs d'usage pour les projets	Projet	owners-123456789012
Domaine Google Workspace	Domaine	USERNAME@YOUR_DOMAIN.com
Domaine Cloud Identity	Domaine	USERNAME@YOUR_DOMAIN.com
Identité unique d'un pool d'identités de personnel	Compte principal	//iam.googleapis.com/locations/global/workforcePools/my-pool/subject/[e-mail]
Toutes les identités de personnel d'un groupe	PrincipalSet	//iam.googleapis.com/locations/global/workforcePools/my-pool/group/my-group

• 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 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 : [e-mail]. 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.

• Identités de personnel :

  La fédération d'identité du personnel vous permet d'utiliser un fournisseur d'identité externe (IdP) pour authentifier et autoriser un groupe d'utilisateurs à l'aide d'IAM, afin que les utilisateurs puissent accéder aux services Google Cloud.

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.

Attention : En appliquant une LCA prédéfinie à un bucket ou à un objet existant, vous remplacez complètement sa LCA par la LCA prédéfinie. Dans certains cas, cette modification peut vous faire perdre l'accès à la LCA de l'objet ou du bucket. Par exemple, si vous faites partie du groupe des propriétaires d'un projet, mais que vous n'êtes pas le propriétaire d'un objet associé à la LCA projectPrivate, vous perdrez l'autorisation OWNER si vous appliquez la LCA prédéfinie publicRead à l'objet. Par conséquent, vous ne pourrez plus accéder à la LCA de l'objet. Dans ce cas, vous pouvez utiliser le rôle IAM storage.objectAdmin pour obtenir l'autorisation nécessaire pour mettre à jour la LCA de l'objet et corriger la modification.

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. Important : Lorsque vous définissez un bucket sur publicReadWrite, tout internaute peut y effectuer une importation. Vous êtes responsable de ce contenu. * 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.

Important : Si vous modifiez la LCA d'objet par défaut d'un bucket, la propagation de la modification peut prendre du temps. Il est possible que les objets créés dans le bucket continuent à utiliser l'ancienne LCA d'objet par défaut pendant un court laps de temps (consultez la page Cohérence). Pour vous assurer que les objets créés dans le bucket utilisent la LCA d'objet par défaut mise à jour, vous devez attendre au moins 30 secondes entre la modification de la LCA d'objet par défaut et la création d'objets.

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é.

Remarque : Vous pouvez désactiver tous les paramètres de propriété d'un bucket et de ses objets en activant l'accès uniforme au niveau du bucket. Cela supprime également toute utilisation des LCA dans le bucket, faisant des stratégies IAM le seul système de contrôle des accès utilisé par le bucket.

Étape suivante

• Apprenez à utiliser les LCA.
• Découvrez comment simplifier votre contrôle des accès à l'aide d'un accès uniforme au niveau du bucket.
• Découvrez les bonnes pratiques concernant l'utilisation des LCA.