Points d'accès et propriété des objets

Les ACL héritées (listes de contrôle d'accès) permettent d'accorder un accès au niveau des objets, mais elles sont antérieures à IAM et aux politiques de compartiment et sont difficiles à auditer à grande échelle.

Le principal danger concerne les chargements entre comptes : un objet écrit par un autre compte peut appartenir à ce compte, ce qui empêche le propriétaire du compartiment de le contrôler.

S3 Object Ownership détermine qui possède les objets chargés. Son paramètre recommandé, Bucket owner enforced, désactive entièrement les ACL et attribue automatiquement chaque objet au propriétaire du compartiment.

Lorsque les ACL sont désactivées, tous les accès sont gérés clairement par IAM et les politiques de compartiment — ce qui facilite grandement leur compréhension et leur audit.

Lorsque Object Ownership est défini sur Bucket owner enforced, les ACL ne s'appliquent plus et ne peuvent plus accorder aucun accès.

Il s'agit désormais du paramètre par défaut des nouveaux compartiments et de la bonne pratique recommandée par AWS. Ce paramètre élimine d'un seul coup toute une catégorie de problèmes déroutants et sujets aux erreurs liés à la propriété entre comptes.

Imaginez que le compte A possède un compartiment, tandis que le compte B y charge des journaux. Avec l'ancien fonctionnement des ACL, B possède ces objets ; A ne peut donc ni lire ni supprimer le contenu de son propre compartiment.

Bucket owner enforced résout ce problème : A devient automatiquement propriétaire de chaque objet, quel que soit son téléverseur, ce qui rend au propriétaire du compartiment le contrôle total.

Les S3 Access Points sont des points de terminaison réseau nommés, associés à un compartiment, chacun disposant de sa propre politique d'accès.

Au lieu d'utiliser une seule politique de compartiment gigantesque et complexe pour toutes les applications, vous créez un point d'accès dédié pour chaque cas d'usage, avec une politique simple et limitée ; la gestion et l'audit des accès sont ainsi beaucoup plus faciles.

Une politique de compartiment partagée devient complexe et risquée à mesure que davantage d'équipes utilisent le compartiment. Les points d'accès la décomposent en nombreuses petites politiques.

Chaque point d'accès peut être limité à un VPC, recevoir son propre nom et ses propres autorisations, puis être révoqué indépendamment. Les besoins d'une équipe ne vous obligent donc jamais à assouplir les accès pour tout le monde.

Un point d'accès peut être configuré pour n'accepter les demandes que depuis un VPC (Virtual Private Cloud) spécifique. Les objets auxquels on accède par son intermédiaire sont alors totalement inaccessibles depuis l'Internet public.

C'est une manière claire de garantir que les données sensibles ne sont accessibles qu'à vos charges de travail internes, via un chemin réseau privé.

Les Multi-Region Access Points vous fournissent un point de terminaison mondial unique qui achemine les demandes vers des compartiments situés dans plusieurs régions.

Du point de vue de la sécurité, ils simplifient la gestion des politiques pour les données distribuées à l'échelle mondiale et fournissent un basculement automatique, afin que les applications continuent de fonctionner sans coder en dur les noms de compartiments régionaux.

Pour partager des données entre comptes, combinez les politiques de compartiment, les points d'accès et Object Ownership plutôt que les ACL.

Définissez Bucket owner enforced, accordez l'accès à l'autre compte au moyen d'une politique de compartiment ou de point d'accès limitée, et vous obtenez un accès entre comptes auditable et révocable, sans la confusion liée à la propriété que provoquent les ACL.

Chaque point d'accès possède sa propre politique de point d'accès, évaluée conjointement avec la politique du compartiment. La politique du compartiment peut même déléguer aux points d'accès et n'accorder l'accès que par leur intermédiaire.

Vous pouvez ainsi conserver une politique de compartiment unique, simple et restrictive, tout en exprimant les autorisations propres à chaque application dans de petites politiques de points d'accès indépendantes, faciles à examiner et à révoquer.

La configuration moderne des accès S3 est claire : désactivez les ACL avec Bucket owner enforced, gérez les accès au moyen d'IAM et des politiques de compartiment, et utilisez les points d'accès pour conserver des politiques limitées propres à chaque application.

Cette combinaison est à la fois plus sûre et nettement plus facile à auditer que l'ancien modèle fondé sur les ACL.

Choisissez la correction la plus claire.

Les ACL héritées causent des problèmes de propriété entre comptes et sont difficiles à auditer. Définissez Object Ownership de S3 sur Bucket owner enforced pour désactiver les ACL et attribuer proprement chaque objet au propriétaire, puis gérez les accès avec IAM et les politiques de compartiment. Utilisez les S3 Access Points pour fournir à chaque application une politique concise et limitée, éventuellement restreinte à un VPC, ainsi que les Multi-Region Access Points pour les données mondiales. Ensemble, ces mécanismes remplacent les ACL par un modèle d'accès auditable appliquant le principe du moindre privilège.