Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Exemples de politiques basées sur l'identité pour Amazon S3

Cette section présente plusieurs exemples AWS Identity and Access Management (IAM) de politiques basées sur l'identité pour contrôler l'accès à Amazon S3. Par exemple, les politiques de compartiment (politiques basées sur les ressources), voir. Politiques relatives aux compartiments pour Amazon S3 Pour plus d'informations sur le langage des IAM politiques, consultezPolitiques et autorisations dans Amazon S3.

Les exemples de politique suivants fonctionnent si vous les testez par programmation. Cependant, pour les utiliser avec la console Amazon S3, vous devez accorder des autorisations supplémentaires qui sont requises par la console. Pour des informations sur l'utilisation de stratégies comme celles-ci avec la console Amazon S3, veuillez consulter Contrôle de l'accès à un compartiment avec des stratégies d'utilisateur.

Pour plus d'informations sur les autorisations relatives aux API opérations S3 par type de ressource S3, consultezAutorisations requises pour les API opérations Amazon S3.

Permettre à un IAM utilisateur d'accéder à l'un de vos buckets

Dans cet exemple, vous souhaitez accorder à un IAM utilisateur de votre choix l' Compte AWS accès à l'un de vos buckets, amzn-s3-demo-bucket1, et autorisez l'utilisateur à ajouter, mettre à jour et supprimer des objets.

En plus de l'octroi des autorisations s3:PutObject, s3:GetObject et s3:DeleteObject à l'utilisateur, la stratégie octroie aussi les autorisations s3:ListAllMyBuckets, s3:GetBucketLocation et s3:ListBucket. Ces conditions supplémentaires sont requises par la console. De la même manière, les actions s3:PutObjectAcl et s3:GetObjectAcl sont nécessaires pour que les objets puissent être copiés, coupés et collés dans la console. Pour afficher un exemple qui octroie les autorisations aux utilisateurs et qui les teste en utilisant la console, consultez Contrôle de l'accès à un compartiment avec des stratégies d'utilisateur.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action": "s3:ListAllMyBuckets",
         "Resource":"*"
      },
      {
         "Effect":"Allow",
         "Action":["s3:ListBucket","s3:GetBucketLocation"],
         "Resource":"arn:aws:s3:::amzn-s3-demo-bucket1"
      },
      {
         "Effect":"Allow",
         "Action":[
            "s3:PutObject",
            "s3:PutObjectAcl",
            "s3:GetObject",
            "s3:GetObjectAcl",
            "s3:DeleteObject"
         ],
         "Resource":"arn:aws:s3:::amzn-s3-demo-bucket1/*"
      }
   ]
}

Autoriser chaque IAM utilisateur à accéder à un dossier dans un bucket

Dans cet exemple, vous souhaitez que deux IAM utilisateurs, Mary et Carlos, aient accès à votre bucket, amzn-s3-demo-bucket1, afin qu'ils puissent ajouter, mettre à jour et supprimer des objets. Cependant, vous souhaitez restreindre l'accès de chaque utilisateur à un seul préfixe (dossier) dans le compartiment. Vous pouvez créer des dossiers dont le nom correspond à leur nom d'utilisateur.

amzn-s3-demo-bucket1
   Mary/
   Carlos/

Pour uniquement octroyer à chaque utilisateur l'accès à son dossier, vous pouvez écrire une stratégie pour chaque utilisateur et l'attacher individuellement. Par exemple, vous pouvez attacher la politique suivante à l'utilisateur Mary pour lui octroyer des autorisations spécifiques à Amazon S3 sur le dossier amzn-s3-demo-bucket1/Mary.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "s3:PutObject",
            "s3:GetObject",
            "s3:GetObjectVersion",
            "s3:DeleteObject",
            "s3:DeleteObjectVersion"
         ],
         "Resource":"arn:aws:s3:::amzn-s3-demo-bucket1/Mary/*"
      }
   ]
}

Vous pouvez alors attacher une stratégie similaire à l'utilisateur Carlos, en spécifiant le dossier Carlos dans la valeur Resource.

Au lieu d'attacher des politiques à des utilisateurs individuels, vous pouvez en écrire une seule qui utilise une variable de politique, puis attacher la politique à un groupe. Vous devez d'abord créer un groupe et ajouter Mary et Carlos à ce groupe. L'exemple de stratégie suivant octroie un ensemble d'autorisations Amazon S3 dans le dossier amzn-s3-demo-bucket1/${aws:username}. Lorsque la politique est évaluée, la variable de stratégie ${aws:username} est remplacée par le nom d'utilisateur du demandeur. Par exemple, si Mary envoie une demande pour placer un objet, l'opération est autorisée uniquement si Mary télécharge l'objet dans le dossier amzn-s3-demo-bucket1/Mary.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "s3:PutObject",
            "s3:GetObject",
            "s3:GetObjectVersion",
            "s3:DeleteObject",
            "s3:DeleteObjectVersion"
         ],
         "Resource":"arn:aws:s3:::amzn-s3-demo-bucket1/${aws:username}/*"
      }
   ]
}

Si vous souhaitez tester la politique précédente sur la console Amazon S3, la console nécessite des autorisations supplémentaires, comme indiqué dans la politique suivante. Pour en savoir plus sur la façon dont la console utilise ces autorisations, consultez Contrôle de l'accès à un compartiment avec des stratégies d'utilisateur.

{
 "Version":"2012-10-17",
  "Statement": [
    {
      "Sid": "AllowGroupToSeeBucketListInTheConsole",
      "Action": [ 
      	"s3:ListAllMyBuckets", 
      	"s3:GetBucketLocation" 
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::*"  
    },
    {
      "Sid": "AllowRootLevelListingOfTheBucket",
      "Action": "s3:ListBucket",
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
      "Condition":{ 
            "StringEquals":{
                    "s3:prefix":[""], "s3:delimiter":["/"]
                           }
                 }
    },
    {
      "Sid": "AllowListBucketOfASpecificUserPrefix",
      "Action": "s3:ListBucket",
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
      "Condition":{  "StringLike":{"s3:prefix":["${aws:username}/*"] }
       }
    },
      {
     "Sid": "AllowUserSpecificActionsOnlyInTheSpecificUserPrefix",
         "Effect":"Allow",
         "Action":[
            "s3:PutObject",
            "s3:GetObject",
            "s3:GetObjectVersion",
            "s3:DeleteObject",
            "s3:DeleteObjectVersion"
         ],
         "Resource":"arn:aws:s3:::amzn-s3-demo-bucket1/${aws:username}/*"
      }
  ]
} 

Bien que les noms IAM d'utilisateur soient des identifiants conviviaux et lisibles par l'homme, il n'est pas nécessaire qu'ils soient uniques au monde. Par exemple, si l'utilisateur Carlos quitte l'organisation et qu'un autre Carlos la rejoint, le nouvel employé Carlos pourrait accéder aux informations de l'ancien employé Carlos.

Au lieu d'utiliser des noms d'utilisateur, vous pouvez créer des dossiers en fonction de IAM l'utilisateurIDs. Chaque IAM nom d'utilisateur est unique. Dans ce cas, vous devez modifier la stratégie précédente pour utiliser la variable de stratégie ${aws:userid}. Pour plus d'informations sur les identifiants utilisateur, consultez la section IAMIdentifiants dans le guide de l'IAMutilisateur.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "s3:PutObject",
            "s3:GetObject",
            "s3:GetObjectVersion",
            "s3:DeleteObject",
            "s3:DeleteObjectVersion"
         ],
         "Resource":"arn:aws:s3:::amzn-s3-demo-bucket1/home/${aws:userid}/*"
      }
   ]
}

Autoriser IAM les non-utilisateurs (utilisateurs d'applications mobiles) à accéder aux dossiers d'un compartiment

Supposons que vous souhaitez développer une application mobile, un jeu qui stocke les données utilisateur dans un compartiment S3. Pour chaque utilisateur d'application, vous souhaitez créer un dossier dans votre compartiment. Vous souhaitez également limiter l'accès de chaque utilisateur à son propre dossier. Mais vous ne pouvez pas créer de dossiers avant que quelqu'un ne télécharge votre application et ne commence à jouer au jeu, car vous n'avez pas son nom d'utilisateur.

Dans ce cas, vous pouvez demander que les utilisateurs se connectent à votre application en utilisant des fournisseurs d'identité publics tels que Login with Amazon, Facebook ou Google. Une fois que les utilisateurs se sont connectés à votre application via l'un de ces fournisseurs, ils ont un ID utilisateur que vous pouvez utiliser afin de créer des dossiers spécifiques aux utilisateurs au moment de l'exécution.

Vous pouvez ensuite utiliser la fédération d'identité Web AWS Security Token Service pour intégrer les informations du fournisseur d'identité à votre application et obtenir des informations de sécurité temporaires pour chaque utilisateur. Vous pouvez ensuite créer des IAM politiques qui permettent à l'application d'accéder à votre compartiment et d'effectuer des opérations telles que la création de dossiers spécifiques à l'utilisateur et le téléchargement de données. Pour plus d'informations sur la fédération d'identité Web, voir À propos de la fédération d'identité Web dans le guide de IAM l'utilisateur.

Autoriser un groupe à avoir un dossier partagé dans Amazon S3

Le fait d'attacher la stratégie suivante au groupe octroie à tous les membres du groupe l'accès au dossier suivant dans Amazon S3 : amzn-s3-demo-bucket1/share/marketing. Les membres du groupe sont uniquement autorisés à accéder aux autorisations spécifiques à Amazon S3 indiquées dans la stratégie et uniquement pour les objets dans le dossier spécifié.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "s3:PutObject",
            "s3:GetObject",
            "s3:GetObjectVersion",
            "s3:DeleteObject",
            "s3:DeleteObjectVersion"
         ],
         "Resource":"arn:aws:s3:::amzn-s3-demo-bucket1/share/marketing/*"
      }
   ]
}

Autoriser tous vos utilisateurs à lire des objets dans une partie d'un compartiment

Dans cet exemple, vous créez un groupe nomméAllUsers, qui contient tous les IAM utilisateurs appartenant au Compte AWS. Vous attachez ensuite une stratégie qui donne au groupe l'accès à GetObject et à GetObjectVersion, mais uniquement pour les objets dans le dossier amzn-s3-demo-bucket1/readonly.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "s3:GetObject",
            "s3:GetObjectVersion"
         ],
         "Resource":"arn:aws:s3:::amzn-s3-demo-bucket1/readonly/*"
      }
   ]
}

Autoriser un partenaire à déposer des fichiers dans une partie spécifique d'un compartiment

Dans cet exemple, vous créez un groupe appelé AnyCompany qui représente une société partenaire. Vous créez un IAM utilisateur pour la personne ou l'application spécifique de l'entreprise partenaire qui a besoin d'un accès, puis vous le placez dans le groupe.

Vous attachez ensuite une politique qui donne au groupe l'accès PutObject au dossier suivant dans le compartiment :

amzn-s3-demo-bucket1/uploads/anycompany

Vous voulez empêcher le groupe AnyCompany de faire quoi que soit d'autre avec le compartiment et vous ajoutez donc une instruction qui refuse explicitement l'autorisation à toutes les actions Amazon S3 à l'exception de PutObject sur n'importe quelle ressource Amazon S3 du Compte AWS.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":"s3:PutObject",
         "Resource":"arn:aws:s3:::amzn-s3-demo-bucket1/uploads/anycompany/*"
      },
      {
         "Effect":"Deny",
         "Action":"s3:*",
         "NotResource":"arn:aws:s3:::amzn-s3-demo-bucket1/uploads/anycompany/*"
      }
   ]
}

Restriction de l'accès aux compartiments Amazon S3 dans un Compte AWS spécifique

Si vous voulez vous assurer que vos principaux Amazon S3 accèdent uniquement aux ressources qui se trouvent dans un environnement sécurisé Compte AWS, vous pouvez restreindre l'accès. Par exemple, cette IAMpolitique basée sur l'identité utilise un Deny effet pour bloquer l'accès aux actions Amazon S3, sauf si la ressource Amazon S3 à laquelle vous accédez est prise en compte. 222222222222 Pour empêcher le IAM principal d'un utilisateur Compte AWS d'accéder aux objets Amazon S3 en dehors du compte, joignez la IAM politique suivante :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyS3AccessOutsideMyBoundary",
      "Effect": "Deny",
      "Action": [
        "s3:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:ResourceAccount": [
            "222222222222"
          ]
        }
      }
    }
  ]
}

Assurez-vous de remplacer l'ID de compte 222222222222 dans la politique par votre propre Compte AWS. Pour appliquer une politique à plusieurs comptes tout en conservant cette restriction, remplacez l'ID de compte par la clé de condition aws:PrincipalAccount. Cette condition exige que le principal et la ressource soient dans le même compte.

Restreindre l'accès aux compartiments Amazon S3 au sein de votre unité organisationnelle

Si vous avez configuré une unité organisationnelle (UO) AWS Organizations, vous souhaiterez peut-être restreindre l'accès au compartiment Amazon S3 à une partie spécifique de votre organisation. Dans cet exemple, nous utiliserons la clé aws:ResourceOrgPaths pour restreindre l'accès au compartiment Amazon S3 à une unité organisationnelle de votre organisation. Dans cet exemple, l'ID de l'unité organisationnelle est ou-acroot-exampleou. Assurez-vous de remplacer cette valeur dans votre propre politique par votre propre unité d'organisationIDs.

{
   "Version": "2012-10-17",
   "Statement": [
     {
       "Sid": "AllowS3AccessOutsideMyBoundary",
       "Effect": "Allow",
       "Action": [
         "s3:*"
       ],
       "Resource": "*",
       "Condition": {
         "ForAllValues:StringNotLike": {
           "aws:ResourceOrgPaths": [
             "o-acorg/r-acroot/ou-acroot-exampleou/"
           ] 
         }
       }
     }
   ]
 }

La politique refuse l'accès aux actions Amazon S3, sauf si l'objet Amazon S3 auquel on accède se trouve dans l'unité organisationnelle ou-acroot-exampleou de votre organisation. La condition IAM de politique exige aws:ResourceOrgPaths qu'une clé de condition à valeurs multiples contienne l'un des chemins d'unité d'organisation répertoriés. La politique utilise l'ForAllValues:StringNotLikeopérateur pour comparer les valeurs de aws:ResourceOrgPaths à celles répertoriées OUs sans distinction majuscules/majuscules.

Restriction de l'accès aux compartiments Amazon S3 au sein de votre organisation

Pour restreindre l'accès aux objets Amazon S3 au sein de votre organisation, associez une IAM politique à la racine de l'organisation, en l'appliquant à tous les comptes de votre organisation. Pour obliger vos IAM principaux à suivre cette règle, utilisez une politique de contrôle des services (). SCP Si vous choisissez d'utiliser unSCP, assurez-vous de bien le tester SCP avant d'associer la politique à la racine de l'organisation.

Dans l'exemple de politique suivant, l'accès aux actions Amazon S3 est refusé sauf si l'objet Amazon S3 auquel on accède appartient à la même organisation que le IAM principal qui y accède :

{
   "Version": "2012-10-17",
   "Statement": [
     {
       "Sid": "DenyS3AccessOutsideMyBoundary",
       "Effect": "Deny",
       "Action": [
         "s3:*"
       ],
       "Resource": "arn:aws:s3:::*/*",
       "Condition": {
         "StringNotEquals": {
           "aws:ResourceOrgID": "${aws:PrincipalOrgID}"
         }
       }
     }
   ]
 }

Dans cet exemple, la condition de IAM politique exige que aws:ResourceOrgID et aws:PrincipalOrgID soient égaux les uns aux autres. Avec cette exigence, le principal qui fait la demande et la ressource accédée doivent faire partie de la même organisation.

Octroi de l'autorisation de récupérer le PublicAccessBlock configuration pour un Compte AWS

L'exemple de politique basée sur l'identité suivant accorde l's3:GetAccountPublicAccessBlockautorisation à un utilisateur. Pour ces autorisations, définissez la valeur Resource sur "*". Pour plus d'informations sur ARNs les ressources, consultezRessources relatives aux politiques pour Amazon S3.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"statement1",
         "Effect":"Allow",
         "Action":[
            "s3:GetAccountPublicAccessBlock" 
         ],
         "Resource":[
            "*"
         ]
       }
    ]
}

Restreindre la création de compartiments à une seule région

Supposons qu'un Compte AWS administrateur souhaite accorder à son utilisateur (Dave) l'autorisation de créer un bucket dans la région Amérique du Sud (São Paulo) uniquement. L'administrateur de compte peut attacher la stratégie d'utilisateur suivant octroyant l'autorisation s3:CreateBucket avec une condition comme indiqué. La paire de clé-valeur dans le bloc Condition spécifie la clé s3:LocationConstraint et la Région sa-east-1 comme sa valeur.

Pour obtenir la liste des régions Amazon S3, consultez Régions et points de terminaison dans Références générales AWS.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"statement1",
         "Effect":"Allow",
         "Action": "s3:CreateBucket",
         "Resource": "arn:aws:s3:::*",
         "Condition": {
             "StringLike": {
                 "s3:LocationConstraint": "sa-east-1"
             }
         }
       }
    ]
}

Ajouter un refus explicite

La stratégie précédente limite la création, par l'utilisateur, d'un compartiment dans une autre Région à l'exception de sa-east-1. Toutefois, une autre stratégie peut accorder à cet utilisateur l'autorisation de créer des compartiments dans une autre Région. Par exemple, si l'utilisateur appartient à un groupe, une stratégie peut être attachée à ce groupe, autorisant tous les utilisateurs du groupe à créer des compartiments dans une autre Région. Pour garantir que l'utilisateur n'est pas autorisé à créer des buckets dans une autre région, vous pouvez ajouter une déclaration de refus explicite dans la politique ci-dessus.

L'instruction Deny utilise la condition StringNotLike. C'est-à-dire qu'une demande de création de compartiment est refusée si la contrainte d'emplacement n'est pas sa-east-1. Le refus explicite n'autorise pas l'utilisateur à créer un bucket dans une autre région, quelle que soit l'autre autorisation qu'il obtient. La politique suivante inclut une déclaration de refus explicite.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"statement1",
         "Effect":"Allow",
         "Action": "s3:CreateBucket",
         "Resource": "arn:aws:s3:::*",
         "Condition": {
             "StringLike": {
                 "s3:LocationConstraint": "sa-east-1"
             }
         }
       },
      {
         "Sid":"statement2",
         "Effect":"Deny",
         "Action": "s3:CreateBucket",
         "Resource": "arn:aws:s3:::*",
         "Condition": {
             "StringNotLike": {
                 "s3:LocationConstraint": "sa-east-1"
             }
         }
       }
    ]
}

Testez la politique à l'aide du AWS CLI

Vous pouvez tester la politique à l'aide de la create-bucket AWS CLI commande suivante. Cet exemple utilise le fichier bucketconfig.txt pour spécifier la contrainte d'emplacement. Notez le Windows chemin du fichier. Vous devez mettre à jour le nom du compartiment et le chemin comme approprié. Vous devez fournir les informations d'identification utilisateur en utilisant le paramètre --profile. Pour plus d'informations sur la configuration et l'utilisation du AWS CLI, consultez la section Développement avec Amazon S3 AWS CLI à l'aide du document de APIréférence Amazon S3.

aws s3api create-bucket --bucket examplebucket --profile AccountADave --create-bucket-configuration file://c:/Users/someUser/bucketconfig.txt

Le fichier bucketconfig.txt spécifie la configuration comme suit.

{"LocationConstraint": "sa-east-1"}