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

Cette page présente les listes de contrôle d'accès (LCA). Pour apprendre à définir et à gérer ces listes, consultez la page Créer et gérer des listes de contrôle d'accès. 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, Cloud IAM (Cloud Identity and Access Management) est la méthode recommandée pour contrôler l'accès à vos ressources. Cloud 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 Cloud IAM ou une LCA pour accéder à un bucket ou à un objet.

Vous souhaiterez probablement utiliser les LCA si vous devez personnaliser l'accès à des objets spécifiques d'un bucket, étant donné que les autorisations Cloud IAM s'appliquent à tous les objets de ce dernier. Toutefois, vous devrez quand même faire appel à l'outil Cloud 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, d'écraser 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 ou OWNER, c'est-à-dire de la même manière que dans l'API JSON et la console Google Cloud Platform. 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 [NOM D'UTILISATEUR]@[VOTRE_DOMAINE].com
Domaine Cloud Identity Domaine [NOM D'UTILISATEUR]@[VOTRE_DOMAINE].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 ou écrasé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 ou écrasées. Vous n'avez pas à vous soucier de la mise à jour des adresses e-mail des groupes Google, car ces dernières sont permanentes et peu susceptibles de changer.

  • Valeurs d'usage pour les projets :

    Les valeurs d'usage owners-<project-number>, editors-<project-number> et viewers-<project-number> représentent les listes de propriétaires, d'éditeurs et de lecteurs du projet dont le numéro est <numéro-projet>.

  • 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 [NOM D'UTILISATEUR]@[VOTRE_DOMAINE].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.

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

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 la console Google Cloud Platform, 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. Les LCA prédéfinies sont utilisées pour des scénarios courants tels que la révocation de toutes les autorisations d'accès, à l'exception de l'autorisation "OWNER" (LCA prédéfinie private), ou la création d'un objet lisible publiquement (LCA prédéfinie publicRead).

Le tableau ci-dessous répertorie les LCA prédéfinies que vous pouvez utiliser et indique pour chacune d'elles les entrées appliquées. Lorsque vous utilisez le tableau ci-dessous, tenez compte des 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 ces derniers. Toutes les autres autorisations d'accès sont supprimées.
    bucketOwnerRead bucket-owner-read Attribue au propriétaire d'un objet l'autorisation OWNER et au propriétaire d'un bucket l'autorisation READER. Toutes les autres autorisations sont supprimées. 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. Toutes les autres autorisations sont supprimées. 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. Toutes les autres autorisations sont supprimées.
    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 relative à 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, écraser et supprimer des objets.

    * Voir la remarque relative à 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. Si vous devez vous assurer que les mises à jour soient visibles immédiatement, définissez 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 Configurer des 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. Ces derniers se voient automatiquement attribuer l'autorisation OWNER sur tous les buckets inclus dans le projet. Lorsque vous créez un projet, vous êtes automatiquement ajouté à ce dernier en tant que propriétaire.

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. La LCA projectPrivate accorde des autorisations supplémentaires aux membres de l'équipe de projet en fonction de leur rôle. Ces autorisations sont définies comme indiqué ci-dessous.

  • Lecteurs du projet

    La LCA projectPrivate accorde aux lecteurs d'un projet l'accès READER aux buckets de ce dernier. Tous les membres de l'équipe du projet peuvent répertorier les objets présents dans les buckets. Ils ont également la possibilité de répertorier les buckets du projet, indépendamment des LCA associées à ces derniers.

  • Éditeurs du projet

    La LCA projectPrivate attribue aux éditeurs d'un projet les autorisations OWNER sur les buckets de ce dernier. Les éditeurs peuvent répertorier le contenu d'un bucket, de même que créer, écraser ou supprimer des objets dans ce dernier. Ils ont également la possibilité de répertorier, créer et supprimer des buckets, indépendamment des LCA associées à ces derniers.

  • Propriétaires du projet

    La LCA projectPrivate attribue aux propriétaires d'un projet les autorisations OWNER. En plus des tâches administratives telles que l'ajout et la suppression de membres d'équipe ou la modification des informations de facturation, les propriétaires peuvent effectuer toutes les tâches exécutables par les éditeurs du projet.

Vous pouvez identifier les lecteurs, les éditeurs et les propriétaires d'un projet en combinant leur rôle au numéro de projet associé. Par exemple, dans le projet 867489160491, les éditeurs sont identifiés comme suit : project-editors-867489160491. Le numéro de projet se trouve sur la page d'accueil de la console Google Cloud Platform.

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 changer la propriété d'un objet qu'en écrasant ce dernier.

    • 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 vigilant 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 écrasant. L'écrasement 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 à l'écrasement (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é.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Besoin d'aide ? Consultez notre page d'assistance.