Politiques et autorisations dans Amazon S3

Cette page présente les stratégies de compartiment et utilisateur dans Amazon S3 et décrit les éléments de base d'une stratégie. Chaque élément répertorié renvoie vers des informations complémentaires sur cet élément et des exemples de son utilisation.

Pour obtenir la liste complète des actions, ressources et conditions d'Amazon S3, consultez la section Actions, ressources et clés de condition pour Amazon S3 dans la référence d'autorisation de service.

Une stratégie de base contient les éléments suivants :

• Ressource : le compartiment, l'objet, le point d'accès ou la tâche Amazon S3 auxquels s'applique la politique. Utilisez l'Amazon Resource Name (ARN) du compartiment, de l'objet, du point d'accès ou de la tâche pour identifier la ressource.

  Exemple d'opérations au niveau du compartiment :

  - "Resource": "arn:aws:s3:::bucket_name".

  Exemples d'opérations au niveau de l'objet :

  – "Resource": "arn:aws:s3:::bucket_name/*" pour tous les objets du compartiment.

  – "Resource": "arn:aws:s3:::bucket_name/prefix/*" pour les objets placés sous un certain préfixe dans le compartiment.

  Pour plus d’informations, consultez Ressources relatives aux politiques pour Amazon S3.

• Actions – Pour chaque ressource, Amazon S3 prend en charge un ensemble d'opérations. Vous identifiez les opérations de ressource que vous accordez (ou refusez) en utilisant des mots clés d'action.

  Par exemple, l'autorisation s3:ListBucket permet à l'utilisateur d'effectuer l'opération Amazon S3 GET Bucket (List Objects). Pour plus d'informations sur l'utilisation des actions Amazon S3, consultez Actions politiques pour Amazon S3. Pour obtenir la liste complète des actions Amazon S3, consultez Actions.

• Effet – L'effet produit lorsque l'utilisateur demande l'action spécifique, qui peut être un accord ou un refus.

  Si vous n'octroyez pas explicitement l'accès pour (autoriser) une ressource, l'accès est implicitement refusé. Vous pouvez explicitement refuser l'accès à une ressource. Vous pouvez le faire afin de vous assurer qu'un utilisateur n'y a pas accès, même si une stratégie différente accorde cet accès. Pour plus d’informations, consultez Éléments de politique JSON IAM : Effect.

• Principal – Compte ou utilisateur autorisé à accéder aux actions ou aux ressources dans l'instruction. Dans une stratégie de compartiment, le principal est l'utilisateur, le compte, le service ou toute autre entité destinataire de cette autorisation. Pour plus d’informations, consultez Principes relatifs aux politiques relatives aux compartiments.

• Condition – Conditions relatives au moment où une stratégie entre en vigueur. Vous pouvez utiliser AWS des clés larges et des clés spécifiques à Amazon S3 pour spécifier les conditions d'une politique d'accès Amazon S3. Pour plus d’informations, consultez Exemples de politiques relatives aux compartiments utilisant des clés de condition.

L'exemple de stratégie de compartiment suivant montre les éléments Effect (effet), Principal (mandataire), Action et Resource (ressource). La politique autorise Akua, un utilisateur inscrit dans le compte Account-ID,, s3:GetObjects3:GetBucketLocation, et s3:ListBucket Amazon S3 à accéder au compartiment. awsexamplebucket1

{
    "Version": "2012-10-17",
    "Id": "ExamplePolicy01",
    "Statement": [
        {
            "Sid": "ExampleStatement01",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/Akua"
            },
            "Action": [
                "s3:GetObject",
                "s3:GetBucketLocation",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::awsexamplebucket1/*",
                "arn:aws:s3:::awsexamplebucket1"
            ]
        }
    ]
}

Pour obtenir des informations complètes sur le langage des politiques, consultez les sections Politiques et autorisations dans IAM et Référence des politiques IAM JSON dans le guide de l'utilisateur IAM.

Délégation d'autorisations

Si une personne Compte AWS possède une ressource, elle peut accorder ces autorisations à une autre personne Compte AWS. Ce compte peut alors déléguer à ces utilisateurs, l'ensemble de ces autorisations ou un sous-ensemble de celles-ci. C'est ce que l'on appelle la délégation d'autorisation. Mais un compte qui reçoit des autorisations d'un autre compte ne peut pas déléguer des autorisations entre comptes à un autre Compte AWS.

Propriété du compartiment et de l'objet Amazon S3

Les compartiments et les objets sont des ressources Amazon S3. Par défaut, seul le propriétaire de ressource peut accéder à ces ressources. Le propriétaire de la ressource fait référence à Compte AWS celui qui crée la ressource. Par exemple :

• Celui Compte AWS que vous utilisez pour créer des buckets et télécharger des objets possède ces ressources.

• Si vous chargez un objet à l'aide des informations d'identification d'utilisateur ou de rôle AWS Identity and Access Management (IAM), l' Compte AWS utilisateur ou le rôle auquel appartient l'utilisateur ou le rôle est propriétaire de l'objet.

• Le propriétaire d'un bucket peut accorder des autorisations entre comptes à un autre Compte AWS (ou à des utilisateurs d'un autre compte) pour le téléchargement d'objets. Dans ce cas, Compte AWS celui qui télécharge les objets est propriétaire de ces objets. Le propriétaire du compartiment n'a aucune autorisation sur les objets dont sont propriétaires d'autres comptes, à l'exception des cas suivants :

  • Le propriétaire du compartiment paie les factures. Le propriétaire du compartiment peut refuser l'accès aux objets ou supprimer des objets dans le compartiment, quel que soit le propriétaire de ces derniers.

  • Le propriétaire du compartiment peut archiver n'importe quel objet ou restaurer des objets archivés, quel que soit le propriétaire de ces derniers. L'archivage fait référence à la classe de stockage utilisée pour stocker les objets. Pour plus d’informations, consultez Gestion du cycle de vie de votre stockage.

Titularité et authentification de demande

Toutes les demandes à un compartiment sont soit authentifiées ou non authentifiées. Les demandes authentifiées doivent inclure une valeur de signature qui authentifie l'expéditeur de la demande, alors que les demandes non authentifiées. Pour plus d'informations sur l'authentification des demandes, veuillez consulter Demandes.

Un propriétaire de compartiment peut choisir d'autoriser les demandes non authentifiées. Par exemple, les PUT Objectdemandes non authentifiées sont autorisées lorsqu'un bucket dispose d'une politique de bucket public, ou lorsqu'une ACL de bucket accorde un FULL_CONTROL accès au All Users groupe WRITE ou à l'utilisateur anonyme en particulier. Pour plus d’informations sur les politiques de compartiment public et les listes de contrôle d’accès (ACL) publiques, consultez La signification du mot « public ».

Toutes les demandes non authentifiées sont faites par l'utilisateur anonyme. Cet utilisateur est représenté dans les listes ACL par l'ID d'utilisateur canonique spécifique 65a011a29cdf8ec533ec3d1ccaae921c. Si un objet est chargé sur un compartiment via une demande non authentifiée, l'utilisateur anonyme est propriétaire de l'objet. L'ACL d'objet par défaut autorise le FULL_CONTROL pour l'utilisateur anonyme en tant que propriétaire de l'objet. Ainsi, Amazon S3 autorise les demandes non authentifiées pour récupérer l'objet ou modifier son ACL.

Pour empêcher que les objets soient modifiés par un utilisateur anonyme, nous vous recommandons de ne pas implémenter des stratégies de compartiment qui autorisent des écritures publiques anonymes sur votre compartiment ou qui utilisent des ACL pour permettre à l'utilisateur anonyme de disposer d'un accès en écriture à votre compartiment. Vous pouvez faire appliquer ce comportement recommandé à l'aide du blocage de l'accès public Amazon S3.

Pour en savoir plus sur le blocage de l'accès public, consultez Blocage de l'accès public à votre stockage Amazon S3. Pour en savoir plus sur les listes ACL, consultez Présentation de la liste de contrôle d'accès (ACL).

Important

Nous vous recommandons de ne pas utiliser les informations d'identification de l'utilisateur Compte AWS root pour effectuer des demandes authentifiées. Il est préférable de créer un rôle IAM, puis de lui accorder un accès total. Nous appelons les utilisateurs possédant ce rôle des administrateurs. Vous pouvez utiliser les informations d'identification attribuées au rôle d'administrateur, au lieu des informations d'identification de l'utilisateur Compte AWS root, pour interagir avec AWS et effectuer des tâches, telles que créer un bucket, créer des utilisateurs et accorder des autorisations. Pour plus d'informations, consultez les informations d'identification AWS de sécurité dans le guide de l'utilisateur IAM et les meilleures pratiques de sécurité dans IAM dans le guide de l'utilisateur IAM.