Skip to main content
Une version plus récente de ce produit est disponible.
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Comment StorageGRID utilise les politiques AWS pour contrôler l'accès aux compartiments et objets S3

PDF

StorageGRID utilise le langage de stratégie Amazon Web Services (AWS) pour permettre aux locataires S3 de contrôler l'accès aux compartiments et aux objets au sein de ces compartiments. Le système StorageGRID implémente un sous-ensemble du langage de stratégie de l'API REST S3. Les stratégies d'accès pour l'API S3 sont écrites en JSON.

Aperçu de la politique d'accès

StorageGRID prend en charge trois types de politiques d'accès :

  • Les stratégies de compartiment, qui sont gérées à l'aide des opérations d'API S3 GetBucketPolicy, PutBucketPolicy et DeleteBucketPolicy, ou du Gestionnaire de locataires ou de l'API de gestion des locataires. Les stratégies de compartiment sont rattachées aux compartiments. Elles sont donc configurées pour contrôler l'accès au compartiment et aux objets qu'il contient par les utilisateurs du compte propriétaire du compartiment ou d'autres comptes. Une stratégie de compartiment s'applique à un seul compartiment et potentiellement à plusieurs groupes.

  • Politiques de groupe, qui sont configurées à l'aide du Tenant Manager ou de l'API Tenant Management. Les politiques de groupe sont associées à un groupe du compte, elles sont donc configurées pour autoriser ce groupe à accéder à des ressources spécifiques détenues par ce compte. Une politique de groupe s'applique à un seul groupe et éventuellement à plusieurs compartiments.

  • Politiques de session, qui sont incluses dans une demande AssumeRole. Les politiques de session ne s'appliquent qu'à la session donnée, définissant plus précisément les autorisations dont l'utilisateur dispose, en plus de celles accordées par la politique de groupe et de compartiment.

Remarque ${post_edited_translations.segment}

Les politiques de compartiment et de groupe StorageGRID suivent une grammaire spécifique définie par Amazon. Chaque politique contient un tableau d'instructions de stratégie, et chaque instruction contient les éléments suivants :

  • ${post_edited_translations.segment}

  • ${post_edited_translations.segment}

  • Principal/NotPrincipal

  • Ressource/NotResource

  • Action/NotAction

  • Condition (facultative)

Les instructions de stratégie sont construites à l'aide de cette structure pour spécifier les autorisations : Accorder <Effect> pour autoriser/refuser à <Principal> d'effectuer <Action> sur <Resource> lorsque <Condition> s'applique.

${post_edited_translations.segment}

Élément Description

Sid

L'élément Sid est facultatif. Le Sid est uniquement destiné à servir de description pour l'utilisateur. Il est stocké mais n'est pas interprété par le système StorageGRID.

${post_edited_translations.segment}

Utilisez l'élément Effect pour déterminer si les opérations spécifiées sont autorisées ou refusées. Vous devez identifier les opérations que vous autorisez (ou refusez) sur les compartiments ou les objets à l'aide des mots-clés de l'élément Action pris en charge.

Principal/NotPrincipal

Vous pouvez autoriser des utilisateurs, des groupes et des comptes à accéder à des ressources spécifiques et à effectuer des actions spécifiques. Si aucune signature S3 n'est incluse dans la requête, l'accès anonyme est autorisé en spécifiant le caractère générique (*) comme principal. Par défaut, seul le compte racine a accès aux ressources dont il est propriétaire.

Il vous suffit de spécifier l'élément Principal dans une stratégie de compartiment. Pour les stratégies de groupe, le groupe auquel la stratégie est rattachée constitue l'élément Principal implicite.

Ressource/NotResource

L'élément Resource identifie les compartiments et les objets. Vous pouvez autoriser ou refuser des autorisations aux compartiments et aux objets en utilisant l'ARN (Amazon Resource Name) pour identifier la ressource.

Action/NotAction

Les éléments Action et Effect sont les deux composants des autorisations. Lorsqu'un groupe demande une ressource, l'accès à celle-ci lui est accordé ou refusé. L'accès est refusé à moins que vous n'attribuiez spécifiquement des autorisations, mais vous pouvez utiliser un refus explicite pour remplacer une autorisation accordée par une autre règle.

Condition

L'élément Condition est facultatif. Les conditions permettent de créer des expressions pour déterminer quand une règle doit être appliquée.

Dans l'élément Action, vous pouvez utiliser le caractère générique (*) pour spécifier toutes les opérations ou un sous-ensemble d'opérations. Par exemple, cette Action correspond à des permissions telles que s3:GetObject, s3:PutObject et s3:DeleteObject.

s3:*Object

Dans l'élément Resource, vous pouvez utiliser les caractères génériques () et (?). L'astérisque () correspond à zéro ou plusieurs caractères, tandis que le point d'interrogation (?) correspond à n'importe quel caractère.

Dans l'élément Principal, les caractères génériques ne sont pas pris en charge, sauf pour définir l'accès anonyme, qui accorde l'autorisation à tous. Par exemple, vous définissez le caractère générique (*) comme valeur de Principal.

"Principal":"*"
"Principal":{"AWS":"*"}

Dans l'exemple suivant, l'instruction utilise les éléments Effect, Principal, Action et Resource. Cet exemple présente une instruction de stratégie de compartiment complète qui utilise l'effet « Allow » pour accorder aux Principals, le groupe admin federated-group/admin et le groupe finance federated-group/finance, les autorisations d'effectuer l'Action s3:ListBucket sur le compartiment nommé mybucket et l'Action s3:GetObject sur tous les objets à l'intérieur de ce compartiment.

{
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::27233906934684427525:federated-group/admin",
          "arn:aws:iam::27233906934684427525:federated-group/finance"
        ]
      },
      "Action": [
        "s3:ListBucket",
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::mybucket",
        "arn:aws:s3:::mybucket/*"
      ]
    }
  ]
}

${post_edited_translations.segment}

${post_edited_translations.segment}

Par défaut, toutes les mises à jour que vous apportez aux règles de groupe sont cohérentes à terme. Lorsqu'une règle de groupe devient cohérente, l'application des modifications peut prendre 15 minutes supplémentaires en raison de la mise en cache des règles. Par défaut, toutes les mises à jour que vous apportez aux règles de compartiment sont fortement cohérentes.

Vous pouvez, si nécessaire, modifier les garanties de cohérence pour les mises à jour des règles d'accès du compartiment. Par exemple, vous pouvez souhaiter qu'une modification d'une règle d'accès de compartiment soit disponible lors d'une panne de site.

Dans ce cas, vous pouvez soit définir l'en-tête Consistency-Control dans la requête PutBucketPolicy, soit utiliser la requête de cohérence PUT Bucket. Lorsqu'une politique de compartiment devient cohérente, la prise d'effet des modifications peut prendre 8 secondes supplémentaires en raison de la mise en cache des politiques.

Remarque Si vous modifiez la cohérence pour contourner un problème temporaire, veillez à rétablir la valeur d'origine du paramètre au niveau du compartiment une fois la modification terminée. Sinon, toutes les requêtes ultérieures au compartiment utiliseront le paramètre modifié.

${post_edited_translations.segment}

Une règle de session est une règle d'accès qui restreint temporairement les autorisations disponibles lors d'une session spécifique, par exemple lorsqu'un utilisateur assume un groupe. Une règle de session ne peut autoriser qu'un sous-ensemble d'autorisations et ne peut pas accorder d'autorisations supplémentaires. Le groupe lui-même peut disposer d'autorisations plus larges.

${post_edited_translations.segment}

${post_edited_translations.segment}

  • ${post_edited_translations.segment}

    arn:aws:s3:::bucket-name
arn:aws:s3:::bucket-name/object_key

  • Utilisez cette syntaxe pour spécifier l'ARN de la ressource d'identité (utilisateurs et groupes) :

    arn:aws:iam::account_id:root
arn:aws:iam::account_id:user/user_name
arn:aws:iam::account_id:group/group_name
arn:aws:iam::account_id:federated-user/user_name
arn:aws:iam::account_id:federated-group/group_name

${post_edited_translations.segment}

  • ${post_edited_translations.segment}

  • Les caractères internationaux, qui peuvent être spécifiés dans la clé d'objet, doivent être encodés à l'aide de JSON UTF-8 ou de séquences d'échappement JSON \u. L'encodage en pourcentage n'est pas pris en charge.

    "${post_edited_translations.segment}"

    Le corps de la requête HTTP pour l’opération PutBucketPolicy doit être encodé avec charset=UTF-8.

Spécifiez les ressources dans une règle

${post_edited_translations.segment}

  • Chaque énoncé de politique requiert un élément Resource. Dans une politique, les ressources sont désignées par l’élément Resource, ou alternativement, NotResource pour l’exclusion.

  • Vous spécifiez les ressources avec un ARN de ressource S3. Par exemple :

    "Resource": "arn:aws:s3:::mybucket/*"

  • Vous pouvez également utiliser des variables de stratégie dans la clé de l'objet. Par exemple :

    "Resource": "arn:aws:s3:::mybucket/home/${aws:username}/*"

  • La valeur de la ressource peut spécifier un compartiment qui n'existe pas encore lors de la création d'une stratégie de groupe.

${post_edited_translations.segment}

${post_edited_translations.segment}

  • Chaque déclaration de stratégie dans une stratégie de compartiment doit inclure un élément Principal. Les déclarations de stratégie dans une stratégie de groupe n'ont pas besoin de l'élément Principal car le groupe est considéré comme le principal.

  • Dans une politique, les principaux sont désignés par l'élément "Principal" ou, alternativement, "NotPrincipal" pour l'exclusion.

  • Les identités basées sur un compte doivent être spécifiées à l'aide d'un ID ou d'un ARN :

    "Principal": { "AWS": "account_id"}
"Principal": { "AWS": "identity_arn" }

  • ${post_edited_translations.segment}

     "Principal": { "AWS": "27233906934684427525" }

  • Vous pouvez spécifier uniquement le compte racine :

    "Principal": { "AWS": "arn:aws:iam::27233906934684427525:root" }

  • ${post_edited_translations.segment}

    "Principal": { "AWS": "arn:aws:iam::27233906934684427525:federated-user/Alex" }

  • Vous pouvez spécifier un groupe fédéré particulier (« Managers ») :

    "Principal": { "AWS": "arn:aws:iam::27233906934684427525:federated-group/Managers"  }

  • ${post_edited_translations.segment}

    "Principal": "*"

  • Pour éviter toute ambiguïté, vous pouvez utiliser l'UUID de l'utilisateur au lieu du nom d'utilisateur :

    arn:aws:iam::27233906934684427525:user-uuid/de305d54-75b4-431b-adb2-eb6b9e546013

    Par exemple, supposons qu'Alex quitte l'organisation et que le nom d'utilisateur Alex soit supprimé. Si un nouvel Alex rejoint l'organisation et qu'on lui attribue le même Alex nom d'utilisateur, le nouvel utilisateur pourrait hériter involontairement des autorisations accordées à l'utilisateur d'origine.

  • La valeur principale peut spécifier un nom de groupe/utilisateur qui n'existe pas encore lors de la création d'une règle de compartiment.

${post_edited_translations.segment}

Dans une stratégie, l'élément Action est utilisé pour autoriser ou refuser des autorisations sur une ressource. Il existe un ensemble d'autorisations que vous pouvez spécifier dans une stratégie, qui sont désignées par l'élément "Action" ou, alternativement, "NotAction" pour l'exclusion. Chacun de ces éléments correspond à des opérations d'API REST S3 spécifiques.

Les tableaux répertorient les autorisations qui s'appliquent aux compartiments et les autorisations qui s'appliquent aux objets.

Remarque Amazon S3 utilise désormais l'autorisation s3:PutReplicationConfiguration pour les actions PutBucketReplication et DeleteBucketReplication. StorageGRID utilise des autorisations distinctes pour chaque action, ce qui correspond à la spécification Amazon S3 d'origine.
Remarque ${post_edited_translations.segment}

Autorisations applicables aux compartiments

Autorisations ${post_edited_translations.segment} ${post_edited_translations.segment}

s3:CreateBucket

CreateBucket

Oui.

Remarque : À utiliser uniquement dans la stratégie de groupe.

s3:DeleteBucket

DeleteBucket

s3:DeleteBucketMetadataNotification

SUPPRIMER la configuration de notification des métadonnées du compartiment

Oui

s3:DeleteBucketPolicy

DeleteBucketPolicy

s3:DeleteReplicationConfiguration

DeleteBucketReplication

Oui, des autorisations distinctes pour PUT et DELETE

s3:GetBucketAcl

GetBucketAcl

s3:GetBucketCompliance

GET Bucket compliance (obsolète)

Oui

s3:GetBucketConsistency

Cohérence du bucket GET

Oui

${post_edited_translations.segment}

GetBucketCors

s3:GetEncryptionConfiguration

GetBucketEncryption

s3:GetBucketLastAccessTime

Obtenir le temps d'accès du compartiment

Oui

s3:GetBucketLocation

GetBucketLocation

s3:GetBucketMetadataNotification

Obtenir la configuration de notification des métadonnées du bucket

Oui

s3:GetBucketNotification

GetBucketNotificationConfiguration

s3:GetBucketObjectLockConfiguration

GetObjectLockConfiguration

s3:GetBucketPolicy

GetBucketPolicy

s3:GetBucketTagging

GetBucketTagging

s3:GetBucketVersioning

GetBucketVersioning

s3:GetLifecycleConfiguration

GetBucketLifecycleConfiguration

s3:GetReplicationConfiguration

GetBucketReplication

s3:ListAllMyBuckets

  • ListBuckets

  • Obtenir l'utilisation du stockage

${post_edited_translations.segment}

Remarque : À utiliser uniquement dans la stratégie de groupe.

s3:ListBucket

  • ListObjects

  • HeadBucket

  • RestoreObject

s3:ListBucketMultipartUploads

  • ListMultipartUploads

  • RestoreObject

s3:ListBucketVersions

${post_edited_translations.segment}

s3:PutBucketCompliance

${post_edited_translations.segment}

Oui

s3:PutBucketConsistency

Cohérence PUT Bucket

Oui

s3:PutBucketCORS

  • DeleteBucketCors†

  • PutBucketCors

s3:PutEncryptionConfiguration

  • DeleteBucketEncryption

  • PutBucketEncryption

s3:PutBucketLastAccessTime

PUT temps d'accès du dernier accès au compartiment

Oui

s3:PutBucketMetadataNotification

Configuration de notification des métadonnées du compartiment PUT

Oui

s3:PutBucketNotification

PutBucketNotificationConfiguration

s3:PutBucketObjectLockConfiguration

  • CreateBucket avec l'en-tête de requête x-amz-bucket-object-lock-enabled: true (requiert également l'autorisation s3:CreateBucket)

  • PutObjectLockConfiguration

s3:PutBucketPolicy

PutBucketPolicy

s3:PutBucketTagging

  • DeleteBucketTagging†

  • PutBucketTagging

s3:PutBucketVersioning

PutBucketVersioning

s3:PutLifecycleConfiguration

  • DeleteBucketLifecycle†

  • PutBucketLifecycleConfiguration

s3:PutReplicationConfiguration

PutBucketReplication

Oui, des autorisations distinctes pour PUT et DELETE

${post_edited_translations.segment}

Autorisations ${post_edited_translations.segment} ${post_edited_translations.segment}

s3:AbortMultipartUpload

  • AbortMultipartUpload

  • RestoreObject

s3:BypassGovernanceRetention

  • DeleteObject

  • DeleteObjects

  • PutObjectRetention

s3:DeleteObject

  • DeleteObject

  • DeleteObjects

  • RestoreObject

s3:DeleteObjectTagging

DeleteObjectTagging

s3:DeleteObjectVersionTagging

DeleteObjectTagging (une version spécifique de l'objet)

s3:DeleteObjectVersion

DeleteObject (une version spécifique de l'objet)

s3:GetObject

  • GetObject

  • HeadObject

  • RestoreObject

  • SelectObjectContent

s3:GetObjectAcl

GetObjectAcl

s3:GetObjectLegalHold

GetObjectLegalHold

s3:GetObjectRetention

GetObjectRetention

s3:GetObjectTagging

GetObjectTagging

s3:GetObjectVersionTagging

GetObjectTagging (une version spécifique de l'objet)

s3:GetObjectVersion

GetObject (une version spécifique de l'objet)

s3:ListMultipartUploadParts

ListParts, RestoreObject

s3:PutObject

  • PutObject

  • CopyObject

  • RestoreObject

  • CreateMultipartUpload

  • CompleteMultipartUpload

  • UploadPart

  • UploadPartCopy

s3:PutObjectLegalHold

PutObjectLegalHold

s3:PutObjectRetention

PutObjectRetention

s3:PutObjectTagging

PutObjectTagging

s3:PutObjectVersionTagging

PutObjectTagging (une version spécifique de l'objet)

s3:PutOverwriteObject

  • PutObject

  • CopyObject

  • PutObjectTagging

  • DeleteObjectTagging

  • CompleteMultipartUpload

Oui

s3:RestoreObject

RestoreObject

Utilisez l'autorisation PutOverwriteObject

L'autorisation s3:PutOverwriteObject est une autorisation StorageGRID personnalisée qui s'applique aux opérations de création ou de mise à jour d'objets. Le paramétrage de cette autorisation détermine si le client peut écraser les données d'un objet, les métadonnées définies par l'utilisateur ou le balisage d'objet S3.

${post_edited_translations.segment}

  • Autoriser : le client peut écraser un objet. Il s'agit du paramètre par défaut.

  • Deny : le client ne peut pas écraser un objet. Lorsqu’elle est définie sur Deny, l’autorisation PutOverwriteObject fonctionne comme suit :

    • Si un objet existant est trouvé au même chemin :

      • Les données de l'objet, les métadonnées définies par l'utilisateur ou le balisage de l'objet S3 ne peuvent pas être écrasés.

      • Toute opération d'ingestion en cours est annulée et une erreur est renvoyée.

      • Si le versionnement S3 est activé, le paramètre Deny empêche les opérations PutObjectTagging ou DeleteObjectTagging de modifier le TagSet pour un objet et ses versions non actuelles.

    • ${post_edited_translations.segment}

  • Lorsque cette autorisation est absente, l'effet est le même que si l'option Allow était activée.

Remarque Si la politique S3 actuelle autorise l'écrasement et que l'autorisation PutOverwriteObject est définie sur Deny, le client ne peut pas écraser les données d'un objet, ses métadonnées définies par l'utilisateur ou son balisage d'objet. De plus, si la case à cocher Empêcher la modification par le client est sélectionnée (Configuration > Paramètres de sécurité > Réseau et objets), ce paramètre remplace le paramètre de l'autorisation PutOverwriteObject.

${post_edited_translations.segment}

Les conditions définissent quand une politique sera en vigueur. Les conditions se composent d'opérateurs et de paires clé-valeur.

Les conditions utilisent des paires clé-valeur pour l'évaluation. Un élément Condition peut contenir plusieurs conditions, et chaque condition peut contenir plusieurs paires clé-valeur. Le bloc de condition utilise le format suivant :

Condition: {
     condition_type: {
          condition_key: condition_values

Dans l'exemple suivant, la condition IpAddress utilise la clé de condition SourceIp.

"Condition": {
    "IpAddress": {
      "aws:SourceIp": "54.240.143.0/24"
		...
},
		...

${post_edited_translations.segment}

${post_edited_translations.segment}

  • Chaîne

  • Numérique

  • ${post_edited_translations.segment}

  • Adresse IP

  • ${post_edited_translations.segment}

${post_edited_translations.segment} Description

StringEquals

${post_edited_translations.segment}

StringNotEquals

Compare une clé à une valeur de chaîne en fonction d'une correspondance négative (sensible à la casse).

StringEqualsIgnoreCase

Compare une clé à une valeur de chaîne en fonction d'une correspondance exacte (ignore la casse).

StringNotEqualsIgnoreCase

${post_edited_translations.segment}

StringLike

Compare une clé à une valeur de chaîne de caractères en fonction d'une correspondance exacte (sensible à la casse). Peut inclure les caractères génériques * et ?.

StringNotLike

Compare une clé à une valeur de chaîne sur la base d'une correspondance inversée (sensible à la casse). Peut inclure les caractères génériques * et ?.

NumericEquals

Compare une clé à une valeur numérique en fonction d'une correspondance exacte.

NumericNotEquals

${post_edited_translations.segment}

NumericGreaterThan

${post_edited_translations.segment}

NumericGreaterThanEquals

Compare une clé à une valeur numérique en fonction d'une correspondance « supérieur ou égal à ».

NumericLessThan

Compare une clé à une valeur numérique en fonction de la correspondance « inférieur à ».

NumericLessThanEquals

${post_edited_translations.segment}

${post_edited_translations.segment}

${post_edited_translations.segment}

IpAddress

${post_edited_translations.segment}

NotIpAddress

Compare une clé à une adresse IP ou à une plage d'adresses IP en se basant sur une correspondance négative.

${post_edited_translations.segment}

Vérifie si une clé de condition est présente dans le contexte de la requête actuelle.

IfExists

Ajouté à tout opérateur de condition, à l'exception de la condition Null, pour vérifier l'absence de cette clé de condition. Renvoie TRUE si la clé de condition n'est pas présente.

Clés de condition prises en charge

Clés de condition Actions Description

aws:SourceIp

opérateurs IP

Sera comparée à l'adresse IP à partir de laquelle la requête a été envoyée. Peut être utilisé pour les opérations sur les compartiments ou les objets.

${post_edited_translations.segment}

Remarque : Si un équilibreur de charge tiers non transparent est utilisé, la comparaison portera sur l’adresse IP de cet équilibreur. Tout en-tête X-Forwarded-For sera ignoré, car sa validité ne peut être vérifiée.

${post_edited_translations.segment}

${post_edited_translations.segment}

Sera comparé au nom d'utilisateur de l'expéditeur à partir duquel la requête a été envoyée. Peut être utilisé pour les opérations sur les compartiments ou les objets.

s3: délimiteur

s3:ListBucket et

Autorisations s3 : ListBucketVersions

Sera comparé au paramètre délimiteur spécifié dans une requête ListObjects ou ListObjectVersions.

s3:ExistingObjectTag/<tag-key>

s3:DeleteObjectTagging

s3:DeleteObjectVersionTagging

s3:GetObject

s3:GetObjectAcl

3:GetObjectTagging

s3:GetObjectVersion

s3:GetObjectVersionAcl

s3:GetObjectVersionTagging

s3:PutObjectAcl

s3:PutObjectTagging

s3:PutObjectVersionAcl

s3:PutObjectVersionTagging

Nécessitera que l'objet existant possède la clé et la valeur de balise spécifiques.

s3:max-keys

s3:ListBucket et

Autorisations s3 : ListBucketVersions

Sera comparé au paramètre max-keys spécifié dans une requête ListObjects ou ListObjectVersions.

s3:object-lock-mode

s3:PutObject

Compare avec le object-lock-mode développé à partir de l'en-tête de requête dans la requête PutObject, CopyObject et CreateMultipartUpload.

s3:object-lock-mode

s3:PutObjectRetention

Comparé à l' `object-lock-mode`élément développé à partir du corps XML dans la requête PutObjectRetention.

${post_edited_translations.segment}

s3:PutObject

Compare à la date de conservation obligatoire spécifiée dans l'en-tête de requête x-amz-object-lock-retain-until-date ou calculée à partir de la période de rétention par défaut du compartiment pour s'assurer que ces valeurs se situent dans la plage autorisée pour les requêtes suivantes :

  • PutObject

  • CopyObject

  • CreateMultipartUpload

${post_edited_translations.segment}

s3:PutObjectRetention

Compare à la date de conservation limite spécifiée dans la requête PutObjectRetention pour s'assurer qu'elle s'inscrit dans la plage autorisée.

${post_edited_translations.segment}

s3:ListBucket et

Autorisations s3 : ListBucketVersions

Sera comparé au paramètre de préfixe spécifié dans une requête ListObjects ou ListObjectVersions.

s3:RequestObjectTag/<tag-key>

s3:PutObject

s3:PutObjectTagging

s3:PutObjectVersionTagging

Une clé et une valeur d'étiquette spécifiques seront requises lorsque la requête d'objet inclut un balisage.

s3:x-amz-server-side-encryption-customer-algorithm

s3:PutObject

Compare à la sse-customer-algorithm ou à la copy-source-sse-customer-algorithm valeur développée à partir de l'en-tête de la requête dans la demande PutObject, CopyObject, CreateMultipartUpload, UploadPart, UploadPartCopy et CompleteMultipartUpload.

Spécifiez les variables dans une politique

Vous pouvez utiliser des variables dans les politiques pour renseigner les informations de politique lorsqu'elles sont disponibles. Vous pouvez utiliser des variables de politique dans l' `Resource`élément et dans les comparaisons de chaînes dans l' `Condition`élément.

Dans cet exemple, la variable ${aws:username} fait partie de l'élément Resource :

"Resource": "arn:aws:s3:::bucket-name/home/${aws:username}/*"

Dans cet exemple, la variable ${aws:username} fait partie de la valeur de la condition dans le bloc de condition :

"Condition": {
    "StringLike": {
      "s3:prefix": "${aws:username}/*"
		...
},
		...
Variable Description

${aws:SourceIp}

Utilise la clé SourceIp comme variable fournie.

${aws:username}

${post_edited_translations.segment}

${s3:prefix}

Utilise la clé de préfixe spécifique au service comme variable fournie.

${s3:max-keys}

Utilise la clé max-keys spécifique au service comme variable fournie.

${*}

Caractère spécial. Utilise le caractère comme un caractère * littéral.

${?}

Caractère spécial. Utilise le caractère en tant que caractère ? littéral.

${$}

Caractère spécial. Utilise le caractère comme un symbole $ littéral.

${post_edited_translations.segment}

Il arrive qu'une politique accorde des autorisations dangereuses pour la sécurité ou la continuité des opérations, comme le blocage de l'utilisateur racine du compte. L'implémentation de l'API REST S3 de StorageGRID est moins restrictive lors de la validation des politiques qu'Amazon, mais tout aussi stricte lors de leur évaluation.

Description de la politique Type de stratégie Comportement d'Amazon Comportement de StorageGRID

Refusez-vous toute autorisation sur le compte racine

Bucket

Valide et appliquée, mais le compte utilisateur root conserve l'autorisation pour toutes les opérations de stratégie de compartiment S3

Même

Refuser à soi-même toutes les autorisations à l’utilisateur/groupe

Groupe

${post_edited_translations.segment}

Même

${post_edited_translations.segment}

Bucket

Principal invalide

${post_edited_translations.segment}

${post_edited_translations.segment}

Bucket

${post_edited_translations.segment}

Même

Autoriser à tous les autorisations pour toutes les actions

Bucket

Valide, mais les autorisations pour toutes les opérations de stratégie de compartiment S3 renvoient une erreur 405 Method Not Allowed pour le compte racine et les utilisateurs du compte externe.

Même

Refuser à tous l'autorisation d'effectuer toutes les actions

Bucket

Valide et appliquée, mais le compte utilisateur root conserve l'autorisation pour toutes les opérations de stratégie de compartiment S3

Même

${post_edited_translations.segment}

Bucket

Principal invalide

${post_edited_translations.segment}

La ressource est un compartiment S3 inexistant

Groupe

${post_edited_translations.segment}

Même

Le principal est un groupe local

Bucket

Principal invalide

${post_edited_translations.segment}

Cette politique accorde à un compte non propriétaire (y compris les comptes anonymes) l'autorisation de placer des objets.

Bucket

Valide. Les objets appartiennent au compte créateur, et la politique de compartiment ne s'applique pas. Le compte créateur doit accorder des autorisations d'accès pour l'objet à l'aide des ACL d'objet.

Valide. Les objets appartiennent au compte du propriétaire du compartiment. La politique de compartiment s'applique.

${post_edited_translations.segment}

Vous pouvez créer des compartiments WORM (write-once-read-many) afin de protéger les données, les métadonnées d'objet définies par l'utilisateur et le balisage d'objet S3. Vous configurez les compartiments WORM pour autoriser la création de nouveaux objets et empêcher la surécriture ou la suppression du contenu existant. Utilisez l'une des approches décrites ici.

Pour garantir que les écrasements soient toujours refusés, vous pouvez :

  • Dans le Grid Manager, accédez à Configuration > Sécurité > Paramètres de sécurité > Réseau et objets, et cochez la case Prevent client modification.

  • Appliquez les règles et politiques S3 suivantes :

    • Ajoutez une opération DENY PutOverwriteObject à la stratégie S3.

    • Ajoutez une opération DENY DeleteObject à la stratégie S3.

    • Ajoutez une opération PutObject ALLOW à la stratégie S3.

Remarque Le paramètre DeleteObject sur REFUSER dans une stratégie S3 n'empêche pas ILM de supprimer des objets lorsqu'une règle telle que « zéro copie après 30 jours » existe.
Remarque Même en appliquant toutes ces règles et politiques, elles ne protègent pas contre les écritures simultanées (voir Situation A). Elles protègent en revanche contre les écrasements séquentiels complets (voir Situation B).

${post_edited_translations.segment}

/mybucket/important.doc
PUT#1 ---> OK
PUT#2 -------> OK

Situation B : Écrasements séquentiels terminés (protégés)

/mybucket/important.doc
PUT#1 -------> PUT#2 ---X (denied)
Informations connexes