Gérer les ACL et la propriété des objets

Une ACL accorde des permissions à des utilisateurs canoniques ou groupes S3. Elle intervient avec IAM, les politiques de bucket et Block Public Access. Une permission ACL ne garantit donc pas que l’accès sera accepté. Object Ownership détermine qui possède les objets et si les ACL contrôlent l’accès.

Préparer le compte et les droits#

Ouvrez File > Accounts…, sélectionnez le compte, cliquez sur Edit…, puis ouvrez Capabilities > ACL policy. Enable ACL operations for this account active les opérations configurées. Object ACL read scope et Object ACL write scope doivent autoriser l’objet courant, ou Current object and specific versions pour les versions. Réglez Bucket ACL response et Object ACL response selon ce que le service renvoie : l’ACL stockée complète, une ACL filtrée, les permissions du bucket présentées comme ACL d’objet, ou une ACL générée par le service. Les formes de requête et permissions proposées viennent aussi de cette politique. Voir les capacités avant de changer ces réglages avancés.

Les droits habituels sont s3:GetBucketAcl et s3:PutBucketAcl pour un bucket, s3:GetObjectAcl et s3:PutObjectAcl pour un objet. Pour une version, vérifiez s3:GetObjectVersionAcl et s3:PutObjectVersionAcl. Object Ownership utilise s3:GetBucketOwnershipControls en lecture et s3:PutBucketOwnershipControls en écriture.

Activer une fonction locale n’accorde aucun droit. Désactiver la politique ACL du compte ne désactive pas IAM ni les politiques du service.

Désactiver les opérations ACL dans S3Client#

Décochez Enable ACL operations for this account pour empêcher S3Client de lire ou d’écrire les ACL de ce compte. Ce réglage local ne change ni les ACL déjà stockées, ni les permissions IAM ou les politiques de bucket, ni le mode Object Ownership du service.

Les onglets ACL des propriétés des buckets, dossiers et objets ne sont plus proposés. Les choix d’ACL explicites des transferts et de création de dossiers sont indisponibles. Les autres propriétés restent accessibles selon leurs propres capacités et permissions, y compris Object Ownership.

Les téléversements, copies, déplacements, synchronisations et créations de marqueurs de dossier qui utilisent le défaut de destination continuent sans requête ni en-tête ACL. Cela vaut aussi pour les transferts multipart et entre comptes. Les lectures de contenu et de propriétés, les tags, le chiffrement et les protections gardent leurs propres prérequis.

Pour un renommage, un changement de classe, de métadonnées ou de chiffrement nécessitant une copie, ou Make current…, S3Client choisit alors le défaut de destination au lieu de demander la conservation de l’ACL source. Cette règle vaut aussi pour les réécritures récursives. Si les ACL restent actives sur le serveur, l’ACL et le propriétaire de l’objet réécrit ne sont pas garantis identiques à ceux de la source, même dans le même bucket.

Une demande explicite d’ACL est refusée avec AclDisabled, même pour private ou bucket-owner-full-control. Une opération qui exige expressément la conservation de l’ACL est refusée avec AclPreservationImpossible ; cette exigence n’est pas ignorée. Une ACL déjà chargée en mémoire ne contourne pas ces refus. Une écriture sans ACL ne déclenche pas de relecture ACL de vérification.

Ne confondez pas ces situations :

La configuration utilisée est celle capturée lors de la préparation de l’opération. Après un changement du compte, rouvrez le dialogue et préparez une nouvelle opération pour utiliser les nouveaux réglages.

Les droits supplémentaires des journaux d’accès (TargetGrants) suivent une capacité distincte ; voir Journaliser les accès.

Modifier une ACL#

Les propriétés d’une seule ressource affichent son ACL complète. Les propriétés de plusieurs objets regroupent les bénéficiaires et permettent de préparer des changements ciblés pour toute la sélection. Avec Show versions, les cibles sont les versions choisies ; sans cette option, ce sont les objets courants. Un marqueur de suppression n’a pas d’ACL.

Pour une seule ressource, la sauvegarde remplace l’ACL complète. Retirer un bénéficiaire retire ses permissions ACL, sans retirer les accès accordés par d’autres politiques. Accorder un groupe public peut exposer données ou droits de modification ; l’application demande une confirmation.

Pour une saisie personnalisée, Save this grantee in the account enregistre le bénéficiaire dès le OK du sélecteur. Annuler ensuite les propriétés ne retire pas cette entrée du compte. Local alias est facultatif.

1. Dans le panneau S3, sélectionnez le bucket, l’objet ou le marqueur de dossier.
2. Ouvrez Properties, puis ACL. Pour un bucket avec l’onglet Object Ownership, cet onglet se nomme Access control list (ACL).
3. Attendez le chargement ; utilisez Try again après une lecture échouée.
4. Si les deux modes sont proposés, sélectionnez Individual permissions, puis cliquez sur Add.
5. Dans Choose an ACL grantee, choisissez Available grantees ou renseignez Direct entry.
6. Choisissez Canonical user et l’identifiant canonique S3, ou S3 group et l’URI autorisée par le compte. Un identifiant canonique n’est ni une clé d’accès ni un numéro de compte AWS.
7. Pour un utilisateur canonique, renseignez éventuellement Remote display name. Pour conserver l’entrée personnalisée, cochez Save this grantee in the account et renseignez éventuellement Local alias.
8. Validez avec OK et cochez les permissions dans la ligne ajoutée.
9. Utilisez Remove sur les bénéficiaires à retirer ; vérifiez l’ensemble et les avertissements.
10. Cliquez sur OK dans les propriétés et lisez les confirmations.
11. Rouvrez l’ACL après l’opération pour contrôler les permissions observées.

Les groupes proposés dépendent de la politique. http://acs.amazonaws.com/groups/global/AllUsers inclut les accès anonymes ; http://acs.amazonaws.com/groups/global/AuthenticatedUsers vise tous les comptes AWS authentifiés. http://acs.amazonaws.com/groups/s3/LogDelivery, lorsqu’il est proposé, vise le groupe de livraison des journaux S3. Vérifiez le groupe et ses permissions avant validation.

La politique du compte peut limiter le nombre d’autorisations ACL. Une ligne avec plusieurs permissions peut compter pour plusieurs autorisations envoyées au service. Le nombre de lignes ne suffit donc pas à vérifier cette limite. Un dépassement bloque l’enregistrement.

Le nom distant peut être ignoré par S3. L’alias reste dans S3Client. Les bénéficiaires enregistrés sont gérés dans Accounts > Edit… > Saved ACL grantees, avec Add…, Edit… et Remove ; validez ensuite le compte. Retirer un raccourci ne retire aucune permission distante. Copy grantee identifier dans le menu contextuel copie l’identifiant brut ; Owner ID: dispose aussi d’un bouton de copie. Les identifiants longs sont abrégés à l’écran ; leur infobulle et leur copie conservent la valeur complète. Owner: affiche séparément le nom fourni par le service. La colonne Display name est masquée lorsqu’aucun bénéficiaire n’a de nom.

Le contrôle complet correspond aux permissions applicables à la ressource. L’éditeur bloque les lignes sans identifiant ou permission, les doublons et les permissions exclues par le compte. Une ligne de type Email reste visible mais doit être retirée avant d’enregistrer une ACL construite à partir du tableau ; vous ne pouvez pas créer ces bénéficiaires. Cette restriction ne bloque pas le remplacement par une ACL prédéfinie.

Refresh recharge l’ACL et demande de confirmer l’abandon des changements locaux. Reset to private, lorsqu’il est proposé pour le bucket, remplace toutes les entrées d’autorisation ACL par le contrôle complet du propriétaire. Préservez d’abord les accès nécessaires dans une politique : cette commande prépare la suppression de toutes les autres entrées d’autorisation ACL.

Pour un bucket ou marqueur de dossier, S3Client relit l’ACL avant l’enregistrement. ACL changed demande confirmation du remplacement si l’ACL distante a changé ou si la comparaison est incomplète. No recharge l’ACL distante et abandonne les changements locaux. Unable to verify ACL bloque l’enregistrement et conserve les changements. Les propriétés d’un fichier n’utilisent pas ce dialogue de conflit.

Modifier les ACL de plusieurs objets#

Sélectionnez les objets ou versions, puis ouvrez Properties > ACL. Le tableau indique combien de cibles lues contiennent chaque bénéficiaire et chaque permission. Il ne présente pas une ACL unique à appliquer à tous les objets.

Add et Edit ouvrent les choix de permissions : Keep unchanged, Allow on all selected objects ou Remove from all selected objects. Remove prépare le retrait du bénéficiaire de toutes les cibles ; Undo change annule le changement préparé pour la ligne. Vérifiez Change, puis cliquez sur OK dans les propriétés et relisez les ACL après l’opération. Seules les modifications explicitement préparées sont appliquées ; les autres permissions sont conservées pour chaque objet.

Pour des versions exactes, soumettez séparément les changements d’ACL et de chiffrement. Voir les propriétés de plusieurs objets pour le chargement et les limites de cette sélection.

Appliquer une ACL prédéfinie à une ressource existante#

Dans le panneau S3, sélectionnez un seul bucket, fichier ou marqueur de dossier existant, puis ouvrez Properties > ACL, ou Access control list (ACL) pour un bucket avec l’onglet Object Ownership. Après une lecture réussie, les modes Individual permissions et Predefined ACL sont proposés si la politique du compte autorise la forme Canned ACL header et au moins une valeur pour PutBucketAcl ou PutObjectAcl, selon la ressource. Avec Show versions, la cible objet est la version sélectionnée ; les comptes limités à l’objet courant ne proposent pas cette modification sur une version. Les préfixes virtuels et marqueurs de suppression ne proposent pas ce choix.

Individual permissions est sélectionné au départ et affiche les permissions observées. Si leur édition est interdite, Read-only apparaît près de Permissions. Un compte peut autoriser le remplacement par une ACL prédéfinie tout en interdisant les modifications individuelles.

Predefined ACL remplace toutes les permissions ACL de la cible. Sélectionnez ce mode, choisissez une valeur autorisée dans ACL, puis cliquez sur OK et lisez les confirmations éventuelles. Les valeurs utilisent les noms S3 et dépendent de l’opération configurée. La politique Amazon S3 propose private, public-read, public-read-write et authenticated-read pour PutBucketAcl. Pour PutObjectAcl, elle propose aussi aws-exec-read, bucket-owner-read et bucket-owner-full-control ; ces trois valeurs ne sont pas proposées pour un bucket. Le tableau et Refresh sont masqués dans ce mode : aucune prévisualisation des permissions résultantes n’est affichée. Les bénéficiaires email du tableau ne sont pas renvoyés au service.

Revenir à Individual permissions rétablit le brouillon du tableau. Dans ce mode, Refresh demande confirmation avant d’abandonner les changements et revient aux permissions observées. Annuler les propriétés n’applique pas l’ACL prédéfinie.

Une lecture échouée, une ACL générée ou dérivée du bucket, ou une restriction Object Ownership, ne débloque pas le choix Predefined ACL. Pour un objet, une modification simultanée des métadonnées, du stockage ou du chiffrement peut nécessiter une copie ; la politique de cette opération doit alors autoriser l’ACL choisie. Pour un bucket, l’ACL est relue avant l’écriture ; les confirmations ACL changed et Unable to verify ACL décrites plus haut s’appliquent aussi au remplacement prédéfini. Rouvrez les propriétés après l’opération pour vérifier les permissions observées.

ACL prédéfinies et création de dossiers#

Ouvrez le dossier parent en vue liste, ou sélectionnez-le dans l’arborescence, puis utilisez Create folder with an ACL… dans le menu contextuel. Cette commande applique une Canned ACL au marqueur créé. Selon la politique, les choix incluent Private, Public read, Public read and write, Authenticated users read, AWS execution read, Bucket owner read et Bucket owner full control. Seuls les choix autorisés pour l’opération apparaissent ; le premier est sélectionné au départ, pas nécessairement Private. Choisissez la valeur, cliquez sur OK et confirmez une éventuelle ACL publique. Dans le panneau, nommez ensuite New folder et validez avec Entrée ; vérifiez le dossier après l’opération.

Public read vise notamment les utilisateurs anonymes. Authenticated users read vise tous les comptes AWS authentifiés, pas seulement votre organisation. Bucket owner full control accorde le contrôle complet au propriétaire du bucket et peut influencer la propriété avec Bucket owner preferred.

Private réserve les droits ACL au propriétaire de l’objet. Public read and write ajoute les entrées d’autorisation ACL publiques, mais aucun droit WRITE ne s’applique au marqueur objet. AWS execution read accorde à EC2 la lecture d’un bundle AMI. Bucket owner read accorde la lecture au propriétaire du bucket. ACL prédéfinies Amazon S3.

Un préfixe virtuel n’a pas d’ACL ; sans marqueur correspondant, ses propriétés ne proposent pas d’éditeur d’ACL. Une ACL de marqueur ne s’applique pas aux descendants. Pour ceux-ci, utilisez Modify child objects… ou Modify child object versions…, décrits dans les modifications en lot.

Choisir Object Ownership#

Dans Accounts > Edit… > Capabilities > Object Ownership, Read Object Ownership settings et Change Object Ownership settings doivent correspondre au service. L’onglet est proposé uniquement pour un bucket General purpose avec au moins une de ces capacités. Ses actions dépendent des capacités disponibles.

Avant de choisir Bucket owner enforced, l’ACL du bucket doit accorder le contrôle complet à son propriétaire et aucune permission aux autres bénéficiaires. Retirez les autres autorisations ACL et accordez les accès nécessaires par les politiques du service. Les ACL restent stockées mais cessent de contrôler l’accès. Réactiver les ACL peut rétablir les anciens accès qu’elles accordaient.

1. Sélectionnez un seul bucket et ouvrez Properties > Object Ownership.
2. Dans Ownership mode, repérez le mode distant avec Current et la mention ACLs enabled ou ACLs disabled.
3. Sélectionnez le bouton du mode voulu. Current continue de désigner le mode distant pendant que vous préparez ce choix.
4. Pour Bucket owner enforced, corrigez au préalable l’ACL du bucket.
5. Cliquez sur OK et vérifiez les confirmations de changement ou remplacement.
6. Rouvrez les propriétés pour contrôler le mode. Après réactivation, rouvrez aussi l’ACL.

Lorsque le mode distant n’est pas établi, Current mode: affiche son état : Not loaded avant la lecture, Not configured (ACLs enabled) si aucun mode explicite n’est défini, ou Unknown si le mode n’a pas pu être établi. Not configured (ACLs enabled) correspond au comportement historique avec ACL actives. Si l’écriture est autorisée mais la lecture indisponible, S3Client avertit qu’elle peut remplacer une configuration non vérifiée. Un changement distant depuis l’ouverture peut aussi demander remplacement ou rechargement.

Restrictions et vérification#

Une ACL en lecture seule peut résulter d’Object Ownership, de la politique du compte ou d’une réponse générée ou dérivée du bucket. Si les permissions du bucket sont affichées comme ACL d’un objet, vous ne pouvez pas les enregistrer comme ACL propre à cet objet. AccessDenied signifie un refus d’accès, pas une preuve d’API non prise en charge.

Si le service masque des entrées d’autorisation ACL, remplacer l’ACL affichée ou réécrire un objet peut perdre les permissions invisibles ; S3Client avertit de ce risque. Une écriture publique peut être acceptée sans être confirmée par relecture. Un résultat non vérifié ne prouve pas l’accès réel : vérifiez les permissions relues, puis l’accès du bénéficiaire lorsque cela importe.

Permissions du bucket projetées sur une version#

Dans le panneau S3, activez Show versions, sélectionnez une version de fichier ou de marqueur de dossier existant, puis ouvrez Properties > ACL. Lorsque le compte autorise la lecture des versions et que Object ACL response vaut Object ACL derived from the bucket ACL, S3Client affiche les permissions provenant du bucket en lecture seule. Elles ne représentent pas une ACL indépendante enregistrée avec cette version, ni l’état des permissions à sa date de création. Leur lecture ne permet pas de les modifier ou de les préserver exactement comme ACL de l’objet lors d’une copie. Un marqueur de suppression ou un préfixe virtuel ne possède pas d’ACL objet à consulter.