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 de politiques basées sur l'identité AWS Identity and Access Management (IAM) pour contrôler l'accès à Amazon S3. Pour obtenir des exemples de politiques de compartiment (politiques basées sur les ressources), consultez Politiques de compartiment pour Amazon S3. Pour plus d’informations sur le langage des politiques IAM, consultez Politiques, stratégies 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, consultez Contrôle de l’accès à un compartiment avec des stratégies d’utilisateur.

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

Autoriser un accès utilisateur IAM à l’un de vos compartiments

Dans cet exemple, vous souhaitez accorder à un utilisateur IAM l' Compte AWS accès à l'un de vos compartiments et lui permettre d'ajouteramzn-s3-demo-bucket1, de mettre à jour et de 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 utilisateur IAM à accéder à un dossier dans un compartiment

Dans cet exemple, vous voulez que deux utilisateurs IAM, Mary et Carlos, aient accès à votre compartiment, amzn-s3-demo-bucket1, de sorte 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 avec des noms qui correspondent à 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 sera évaluée, la variable de politique ${aws:username} sera remplacée par le nom 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 d’utilisateur IAM soient des identifiants conviviaux et compréhensibles, il n’est pas nécessaire qu’ils soient uniques à l’échelle mondiale. 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 basés sur l'utilisateur IAM. IDs Chaque ID d’utilisateur IAM 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 Identificateurs IAM dans le Guide de l’utilisateur IAM.

{
   "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 des utilisateurs non IAM (utilisateurs d’application mobile) à accéder à des dossiers dans 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 aussi limiter l’accès de chaque utilisateur à son propre dossier. Mais vous ne pouvez pas créer de dossier avant qu’une personne télécharge votre application et commence à jouer au jeu, car vous n’avez pas son ID 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 politiques IAM qui permettent à l’application d’accéder à votre compartiment et d’effectuer des opérations comme la création de dossiers spécifiques à l’utilisateur et le chargement de données. Pour plus d’informations sur la fédération d’identités Web, consultez À propos de la fédération d’identité Web dans le Guide de l’utilisateur IAM.

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 appelé AllUsers, qui contient tous les utilisateurs IAM que possède le 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 utilisateur IAM pour la personne ou l’application spécifique de la société partenaire ayant besoin d’un accès, puis vous placez l’utilisateur 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 politique IAM basée sur une identité utilise un effet Deny pour bloquer l’accès aux actions Amazon S3, sauf si la ressource Amazon S3 concernée appartient au compte 222222222222. Pour empêcher le principal IAM Compte AWS d'accéder aux objets Amazon S3 en dehors du compte, joignez la politique IAM 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.

Restriction de 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'organisation IDs.

{
   "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 de politique IAM a besoin de aws:ResourceOrgPaths, clé de condition à valeurs multiples, pour contenir un des chemins d’unité organisationnelle 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, attachez une politique IAM à la racine de l’organisation, en l’appliquant à tous les comptes de votre organisation. Pour demander à vos principaux IAM de respecter cette règle, utilisez une politique de contrôle des services (SCP). Si vous choisissez d’utiliser une SCP, veillez à bien tester la SCP avant d’attacher la politique à la racine de l’organisation.

Dans l’exemple de politique suivant, l’accès est refusé aux actions Amazon S3, sauf si l’objet Amazon S3 accédé se trouve dans la même organisation que le principal IAM 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 politique IAM nécessite 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 utilisateur suivant octroie l’autorisation s3:GetAccountPublicAccessBlock à un utilisateur. Pour ces autorisations, définissez la valeur Resource sur "*". Pour plus d'informations sur ARNs les ressources, consultezRessources de politique pour Amazon S3.

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

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

Supposons qu'un Compte AWS administrateur souhaite autoriser son utilisateur (Dave) à créer un bucket uniquement dans la région Amérique du Sud (São Paulo). 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’obtienne pas l’autorisation de créer des compartiments dans une autre région, vous pouvez ajouter une instruction 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 compartiment dans une autre région, quelles que soient les autres autorisations obtenues par l’utilisateur. La politique ci-dessous inclut une instruction 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 avec le 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 à l'aide de la AWS CLI dans le manuel Amazon S3 API Reference.

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"}