Contrôle d’accès S3 : stratégies de compartiment et ACL

S3 propose plusieurs mécanismes de contrôle des accès qui se recouvrent : les politiques IAM (fondées sur l'identité, elles contrôlent ce que les principaux peuvent faire), les politiques de compartiment (politiques JSON fondées sur les ressources et appliquées au compartiment), les listes de contrôle d'accès (ACL) (autorisations héritées accordées par objet ou par compartiment) et le blocage de l'accès public S3 (remplacement au niveau du compte ou du compartiment qui bloque tout accès public, quelles que soient les autres politiques). Pour la plupart des cas d'utilisation actuels, l'approche recommandée consiste à associer les politiques de compartiment au blocage de l'accès public ; les ACL sont considérées comme obsolètes.

Une politique de bucket est un document JSON directement associé au bucket S3. Elle définit quels principaux (utilisateurs IAM, rôles, comptes AWS, services ou le public) peuvent effectuer quelles actions sur quelles ressources (le bucket et/ou des préfixes de clés spécifiques). Les politiques de bucket prennent en charge l’accès inter-comptes sans nécessiter de rôles IAM : vous pouvez accorder directement dans la politique de bucket à un rôle IAM d’un autre compte AWS un accès en lecture à des objets spécifiques. Chaque bucket peut avoir une politique, dont la taille maximale est de 20 KB.

Pour diffuser du contenu public (par exemple, des ressources de site web statique ou des jeux de données publics), vous pouvez rendre des objets lisibles publiquement au moyen d’une politique de bucket. Commencez par désactiver Block Public Access au niveau du bucket, puis ajoutez une instruction de politique de bucket contenant Principal: '*' et Action: s3:GetObject. Il est nécessaire à la fois de désactiver le paramètre Block Public Access et d’utiliser Allow dans la politique de bucket : activer l’un sans l’autre ne fonctionnera pas. Limitez toujours Resource à un préfixe spécifique plutôt qu’au bucket entier, sauf si vous souhaitez volontairement rendre tous les objets publics.

S3 Block Public Access est un filet de sécurité composé de quatre paramètres qui prévalent sur les politiques de bucket et les ACLs : BlockPublicAcls (refuse les requêtes visant à définir des ACLs publiques), IgnorePublicAcls (ignore les ACLs publiques existantes), BlockPublicPolicy (refuse les politiques de bucket qui accordent un accès public) et RestrictPublicBuckets (restreint l’accès selon la politique publique). Les quatre paramètres sont activés par défaut. Vous pouvez aussi activer Block Public Access au niveau du compte, ce qui le bloque pour tous les buckets, quels que soient les paramètres de chaque bucket. C’est idéal pour éviter toute exposition publique accidentelle.

Les ACLs S3 constituent le mécanisme de contrôle d’accès d’origine, antérieur à IAM. Une ACL accorde des autorisations prédéfinies (READ, WRITE, FULL_CONTROL) à des comptes AWS ou à des groupes prédéfinis (tous les utilisateurs, utilisateurs AWS authentifiés, livraison de journaux). Les ACLs peuvent être appliquées au niveau du bucket ou de chaque objet. AWS recommande désormais de désactiver les ACLs (le paramètre S3 « Bucket Owner Enforced » attribue au propriétaire du bucket tous les objets et désactive les ACLs) et d’utiliser plutôt les politiques de bucket et IAM. Les ACLs sont toujours évaluées dans l’examen SAA-C03 comme concept hérité.

Lorsque vous diffusez du contenu S3 via CloudFront, vous souhaitez que le bucket reste privé tout en permettant à CloudFront de récupérer les objets. Utilisez Origin Access Control (OAC), le remplaçant moderne d’Origin Access Identity (OAI). OAC crée une identité CloudFront à laquelle vous accordez l’autorisation s3:GetObject dans la politique de bucket, tout en gardant Block Public Access activé. Ainsi, les utilisateurs doivent passer par CloudFront (pour la mise en cache, WAF et HTTPS) et ne peuvent pas accéder directement au bucket : c’est un modèle d’architecture sécurisée courant dans l’examen SAA-C03.

Il existe deux façons d’accorder à un autre compte AWS l’accès à votre bucket S3. Option 1 — Politique de bucket : ajoutez une instruction contenant l’ARN du compte externe comme Principal et les actions S3 souhaitées. Les utilisateurs et rôles IAM du compte externe ont toujours besoin d’autorisations IAM pour appeler S3, et la politique de bucket doit aussi les Allow. Option 2 — Rôle IAM avec politique de confiance : créez dans votre compte un rôle approuvé par le compte externe ; les identités du compte externe endossent ce rôle et obtiennent les autorisations de votre bucket. La politique de bucket est plus simple dans les scénarios en lecture seule ; les rôles sont préférables pour les accès opérationnels.

Cross-Origin Resource Sharing (CORS) permet à une application web hébergée sur un domaine d’effectuer des requêtes JavaScript de récupération vers un bucket S3 situé sur un autre domaine. Sans configuration CORS, les navigateurs bloquent ces requêtes pour des raisons de sécurité. Vous ajoutez au bucket une configuration CORS qui spécifie les origines, méthodes HTTP et en-têtes autorisés. CORS est couramment nécessaire lorsqu’une SPA React hébergée sur example.com récupère directement des images ou des fichiers depuis l’URL d’un bucket S3.

Une URL pré-signée accorde un accès limité dans le temps à un objet S3 privé (pour GET ou PUT), sans modifier les autorisations du bucket ni de l’objet. L’URL intègre vos identifiants et une heure d’expiration : toute personne possédant l’URL peut accéder à l’objet jusqu’à son expiration. Utilisez des URL pré-signées pour permettre aux utilisateurs authentifiés de votre application de télécharger des fichiers privés, autoriser les clients à envoyer des fichiers directement vers S3 sans passer par votre backend, ou partager temporairement des rapports. L’expiration peut aller de 1 seconde à 7 jours (lors de l’utilisation d’identifiants temporaires STS, le maximum est de 12 heures).

Utilisez les conditions des politiques de bucket pour ajouter une sécurité contextuelle. Modèles courants : aws:SourceIp limite l’accès à des plages IP spécifiques (par exemple, des points de terminaison VPC ou des réseaux d’entreprise) ; aws:SecureTransport: true impose HTTPS en refusant les requêtes via HTTP (une bonne pratique pour tous les buckets stockant des données sensibles) ; s3:x-amz-server-side-encryption garantit que les objets doivent être envoyés avec un chiffrement côté serveur ; et aws:PrincipalOrgID limite l’accès aux principaux de votre organisation AWS, empêchant l’exfiltration des données vers des comptes externes.

Par défaut, les instances EC2 d’un sous-réseau privé accèdent à S3 par Internet (via une passerelle NAT), ce qui entraîne des coûts NAT et expose le trafic à Internet public. Les Gateway Endpoints S3 fournissent une connectivité privée à S3 depuis un VPC sans passerelle NAT, sans coût supplémentaire. Vous ajoutez le Gateway Endpoint à votre table de routage ; le trafic vers S3 est automatiquement acheminé par le réseau privé d’AWS. Vous pouvez aussi ajouter des conditions à la politique de bucket en utilisant aws:SourceVpce afin de limiter l’accès aux seules requêtes passant par le point de terminaison.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris que les politiques de bucket sont des documents JSON basés sur les ressources qui contrôlent l’accès inter-comptes et l’accès des services à S3, que S3 Block Public Access est un mécanisme de sécurité qui empêche les expositions publiques accidentelles, et que les URL pré-signées, les points de terminaison VPC et les configurations CORS répondent de manière sécurisée à des modèles d’accès spécifiques. Nous aborderons ensuite le versionnage S3, MFA Delete et la réplication.