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

Accéder aux exemples

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 et les LCA fonctionnent conjointement pour accorder l'accès à vos buckets et objets. Les utilisateurs n'ont besoin que des autorisations attribuées par IAM ou une LCA pour accéder à un bucket ou à un objet.

Vous devrez probablement utiliser les LCA si vous souhaitez personnaliser l'accès à des objets individuels au sein d'un bucket, car les autorisations IAM s'appliquent à tous les objets d'un bucket. Toutefois, vous devrez quand même faire appel à l'outil IAM pour tout accès commun à l'ensemble des objets d'un bucket, car il permet de limiter les tâches de microgestion.

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 Permet à un utilisateur de répertorier, de créer, de remplacer et de supprimer des objets dans un bucket1. N/A. Vous ne pouvez pas appliquer cette autorisation aux objets.
OWNER Attribue à un utilisateur les autorisations READER et WRITER sur le bucket. L'utilisateur peut également lire et écrire des métadonnées dans le bucket, y compris les LCA. Attribue à un utilisateur l'accès READER. L'utilisateur peut également lire et écrire des métadonnées dans l'objet, y compris les LCA.
Default 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.

1 Les propriétés suivantes de métadonnées de bucket ne peuvent pas être modifiées : acl, cors, defaultObjectAcl, lifecycle, logging, versioning et website.

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. Par ailleurs, lorsque vous utilisez l'authentification OAuth 2.0 pour authentifier des outils et des applications (et leur accorder des autorisations) de sorte qu'ils puissent accéder à l'API Google Cloud Storage en votre nom, l'accès est limité par les champs d'application OAuth devstorage.read_only, devstorage.read_write et devstorage.full_control. Le tableau ci-dessous récapitule la terminologie courante relative aux autorisations :

API JSON API XML Champ d'application OAuth2
READER READ https://www.googleapis.com/auth/devstorage.read_only
WRITER WRITE https://www.googleapis.com/auth/devstorage.read_write
OWNER FULL_CONTROL https://www.googleapis.com/auth/devstorage.full_control

Champs d'application

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
Adresse e-mail du compte Google Utilisateur collaborator@gmail.com
Adresse e-mail du groupe Google Groupe work-group@googlegroups.com
Valeurs d'usage pour les projets Projet owners-123456789012
Domaine G Suite Domaine USERNAME@YOUR_DOMAIN.com
Domaine Cloud Identity Domaine USERNAME@YOUR_DOMAIN.com
Identifiant spécial pour tous les titulaires de compte Google Utilisateur allAuthenticatedUsers
Identifiant spécial pour tous les utilisateurs Utilisateur allUsers
  • Adresse e-mail du compte Google :

    Chaque utilisateur titulaire d'un compte Google 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 Google, telle qu'une adresse gmail.com.

    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 : 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. Pour en savoir plus sur les groupes Google, consultez la page d'accueil correspondante.

    Comme pour les adresses e-mail de comptes Google, 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 Google Groupes, 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 les membres doivent disposer des rôles de base : une pratique déconseillée dans les environnements de production.

  • G Suite ou Cloud Identity :

    Les clients qui utilisent G Suite 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é à G Suite ou à Cloud Identity.

  • Identifiant spécial pour tous les titulaires de compte Google :

    Cet identifiant spécial de champ d'application représente toute personne authentifiée avec un compte Google. Il correspond à allAuthenticatedUsers pour tous les titulaires de compte Google. Bien que cet identifiant soit un type d'entité User, il est associé à un libellé de type Public dans Cloud Console.

  • Identifiant spécial pour tous les utilisateurs :

    Cet identifiant spécial de champ d'application représente tout internaute possédant ou non un compte Google. Il correspond à allUsers pour tous les utilisateurs. Bien que cet identifiant soit un type d'entité User, il est associé à un libellé de type Public dans Cloud Console.

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 à l'aide de Google Cloud Console, de l'API JSON ou de gsutil, vous pouvez définir 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 ou "prête à l'emploi" 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 API XML/gsutil 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 Google 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.

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

Bonnes pratiques

Comme tous les autres paramètres administratifs, les LCA requièrent une gestion active pour être efficaces. 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é de l'organisation peuvent vous contraindre à modifier les paramètres des LCA appliquées aux buckets et aux objets. Cette remarque s'applique tout particulièrement si vous gérez des buckets et des objets 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 à vos buckets et objets.

    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 un 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 l'autorisation READER, et non l'autorisation OWNER.

  • Évitez d'accorder l'autorisation OWNER à des personnes que vous ne connaissez pas.

    L'autorisation OWNER permet à un utilisateur de modifier les LCA et de prendre le contrôle des données. Vous ne devez utiliser l'autorisation OWNER 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 champs d'application 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 champs d'application peuvent être utiles pour certains besoins et scénarios particuliers, il n'est généralement pas recommandé d'accorder l'autorisation OWNER à tous les utilisateurs.

  • Évitez de définir des LCA qui rendent des objets inaccessibles.

    Un objet inaccessible ne peut pas être téléchargé (lu). Vous ne pouvez que le supprimer. Ce cas de figure peut se présenter si le propriétaire d'un objet quitte un projet sans accorder à un autre utilisateur l'autorisation OWNER ou READER sur l'objet. Pour éviter ce problème, vous pouvez utiliser les LCA prédéfinies bucket-owner-read ou bucket-owner-full-control lorsque vous (ou un autre utilisateur) importez des objets dans vos buckets.

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

    Par défaut, le groupe des propriétaires d'un projet est la seule entité disposant de l'autorisation OWNER sur un bucket lorsque ce dernier est créé. Ce groupe doit comporter à tout moment 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 propriétaires du projet.

  • Tenez compte du comportement interopérable de Cloud Storage.

    Lorsque vous utilisez l'API XML pour permettre un accès interopérable avec d'autres services de stockage, tels qu'Amazon S3, l'identifiant de signature détermine la syntaxe des LCA. Par exemple, si l'outil ou la bibliothèque que vous employez demande à Cloud Storage de récupérer les LCA, et si la requête inclut l'identifiant de signature d'un autre fournisseur de stockage, Cloud Storage renvoie un document XML utilisant la syntaxe de LCA de ce fournisseur. Si l'outil ou la bibliothèque que vous employez demande à Cloud Storage d'appliquer les LCA, et si la requête inclut l'identifiant de signature d'un autre fournisseur de stockage, Cloud Storage s'attend à recevoir un document XML utilisant la syntaxe de LCA de ce fournisseur.

    Pour savoir comment utiliser l'API XML pour permettre un accès interopérable avec Amazon S3, consultez la page Migrer depuis Amazon S3 vers Cloud Storage.

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