Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Esempi di chiavi di condizioni di Amazon S3
È possibile utilizzare in linguaggio delle policy di accesso per specificare le condizioni quando si concedono le autorizzazioni. È possibile utilizzare l'elemento Condition facoltativo o il blocco Condition per specificare le condizioni per l'applicazione di una policy.
Per le policy che utilizzano le chiavi di condizioni di Amazon S3 per operazioni su oggetti e bucket, consulta gli esempi seguenti. Per ulteriori informazioni su queste chiavi di condizione, consulta Chiavi di condizione di Amazon S3. Per un elenco completo di azioni, chiavi di condizione e risorse di Amazon S3 che puoi specificare nelle politiche, consulta Azioni, risorse e chiavi di condizione per Amazon S3 nel Service Authorization Reference.
Esempi – Chiavi di condizione di Amazon S3 per le operazioni sugli oggetti
In questa sezione vengono forniti esempi che illustrano come utilizzare le chiavi di condizione specifiche di Amazon S3 per le operazioni sugli oggetti. Per un elenco completo di azioni, chiavi di condizione e risorse di Amazon S3 che puoi specificare nelle politiche, consulta Azioni, risorse e chiavi di condizione per Amazon S3 nel Service Authorization Reference.
Molte delle policy di esempio mostrano come è possibile utilizzare le chiavi di condizione con le operazioni PUT Object. Le operazioni PUT Object permettono intestazioni specifiche della lista di controllo degli accessi (ACL) che è possibile utilizzare per concedere autorizzazioni basate sulle liste ACL. Utilizzando queste chiavi, il proprietario del bucket può impostare una condizione per richiedere determinate autorizzazioni di accesso specifiche quando l'utente carica un oggetto. Puoi anche concedere autorizzazioni basate su ACL con l'operazione. PutObjectAcl Per ulteriori informazioni, consulta il riferimento PutObjectAclall'API Amazon S3 Amazon Simple Storage Service. Per ulteriori informazioni sulle ACL, consulta Panoramica delle liste di controllo accessi (ACL).
Argomenti
- Esempio 1: concessione di s3: PutObject autorizzazione con una condizione che richiede al proprietario del bucket di ottenere il pieno controllo
- Esempio 2: Concessione di s3: PutObject autorizzazione che richiede l'autorizzazione agli oggetti archiviati utilizzando la crittografia lato server
- Esempio 3: Concessione a s3: PutObject autorizzazione a copiare oggetti con una restrizione sulla fonte di copia
- Esempio 4: assegnazione dell'accesso a una versione specifica di un oggetto
- Esempio 5: limitazione dei caricamenti degli oggetti ai soli oggetti con una classe di storage specifica
- Esempio 6: concessione delle autorizzazioni in base ai tag dell'oggetto
- Esempio 7: limitazione dell'accesso in base all' Account AWS ID del proprietario del bucket
- Esempio 8: richiesta di una versione TLS minima
Esempio 1: concessione di s3: PutObject autorizzazione con una condizione che richiede al proprietario del bucket di ottenere il pieno controllo
L'operazione PUT Object permette intestazioni specifiche della lista di controllo degli accessi (ACL) che è possibile utilizzare per concedere autorizzazioni basate sulle liste ACL. Utilizzando queste chiavi, il proprietario del bucket può impostare una condizione per richiedere determinate autorizzazioni di accesso specifiche quando l'utente carica un oggetto.
Supponiamo che l'Account A possieda un bucket e che l'amministratore dell'account voglia concedere ad Akua, un utente dell'Account B, le autorizzazioni per caricare oggetti. Per impostazione predefinita, gli oggetti caricati da Akua sono di proprietà dell'Account B e l'Account A non ha autorizzazioni su questi oggetti. Poiché il proprietario del bucket paga le bollette, desidera le autorizzazioni complete sugli oggetti caricati da Akua. L'account Un amministratore può farlo concedendo l's3:PutObjectautorizzazione ad Akua, a condizione che la richiesta includa intestazioni specifiche per ACL che concedano esplicitamente l'autorizzazione completa o utilizzino un ACL predefinito. Per ulteriori informazioni, consulta PUT Object.
Richiedi l'intestazione x-amz-full-control
È possibile richiedere l'intestazione x-amz-full-control nella richiesta con autorizzazione al controllo completo al proprietario del bucket. La seguente politica sui bucket concede l's3:PutObjectautorizzazione all'utente Akua con una condizione utilizzando la chiave s3:x-amz-grant-full-control condition, che richiede che la richiesta includa l'intestazione. x-amz-full-control
{ "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AccountB-ID:user/Akua" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } } ] }
Nota
Questo esempio riguarda l'autorizzazione tra account. Tuttavia, se Akua (che sta ottenendo l'autorizzazione) appartiene al proprietario del Account AWS bucket, questa autorizzazione condizionata non è necessaria. Questo perché l'account principale a cui appartiene Akua possiede gli oggetti che l'utente carica.
Aggiunta del rifiuto esplicito
La precedente politica bucket concede un'autorizzazione condizionata all'utente Akua nell'Account B. Sebbene questa politica sia in vigore, è possibile che Akua ottenga la stessa autorizzazione senza alcuna condizione tramite un'altra politica. Ad esempio, Akua può appartenere a un gruppo e tu concedi l'autorizzazione al gruppo senza alcuna condizione. s3:PutObject Per evitare questi espedienti riguardo alle autorizzazioni, è possibile scrivere una policy di accesso più rigida aggiungendo un rifiuto esplicito. In questo esempio, neghi esplicitamente all'utente Akua il permesso di caricamento se non include le intestazioni necessarie nella richiesta che concede le autorizzazioni complete al proprietario del bucket. Il rifiuto esplicito sovrascrive sempre qualsiasi altra autorizzazione assegnata. Di seguito è illustrato un esempio della policy di accesso modificata con il rifiuto esplicito aggiunto.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AccountB-ID:user/AccountBadmin" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } }, { "Sid": "statement2", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::AccountB-ID:user/AccountBadmin" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringNotEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } } ] }
Prova la politica con AWS CLI
Se ne hai due Account AWS, puoi testare la politica usando AWS Command Line Interface (AWS CLI). Allegate la policy e usate le credenziali di Akua per testare l'autorizzazione usando il seguente AWS CLI put-object comando. Fornisci le credenziali di Akua aggiungendo il parametro. --profile L'autorizzazione al controllo completo al proprietario del bucket viene assegnata aggiungendo il parametro --grant-full-control. Per ulteriori informazioni sulla configurazione e l'utilizzo di AWS CLI, vedere. Sviluppo con Amazon S3 tramite la AWS CLI
aws s3api put-object --bucketexamplebucket--key HappyFace.jpg --body c:\HappyFace.jpg --grant-full-control id="AccountA-CanonicalUserID" --profile AccountBUserProfile
Richiedi l' x-amz-acl intestazione
È possibile richiedere l'intestazione x-amz-acl con una lista di controllo degli accessi predefinita che assegna l'autorizzazione al controllo completo al proprietario del bucket. Per richiedere l'intestazione x-amz-acl nella richiesta, è possibile sostituire la coppia chiave-valore nel blocco Condition e specificare la chiave di condizione s3:x-amz-acl come mostrato nell'esempio seguente.
"Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" } }
Per verificare l'autorizzazione utilizzando il AWS CLI, è necessario specificare il --acl parametro. AWS CLI Quindi aggiunge l'x-amz-aclintestazione quando invia la richiesta.
aws s3api put-object --bucketexamplebucket--key HappyFace.jpg --body c:\HappyFace.jpg --acl "bucket-owner-full-control" --profile AccountBadmin
Esempio 2: Concessione di s3: PutObject autorizzazione che richiede l'autorizzazione agli oggetti archiviati utilizzando la crittografia lato server
Si supponga che l'Account A possieda un bucket. L'amministratore dell'account vuole concedere a Jane, un'utente dell'Account A, l'autorizzazione per il caricamento di oggetti con la condizione che Jane richieda sempre la crittografia lato server in modo che Amazon S3 salvi gli oggetti crittografati. L'amministratore dell'Account A può procedere utilizzando la chiave di condizione s3:x-amz-server-side-encryption come mostrato. La coppia chiave-valore nel blocco Condition specifica la chiave s3:x-amz-server-side-encryption.
"Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "AES256" }}
Quando si verifica l'autorizzazione utilizzando il AWS CLI, è necessario aggiungere il parametro richiesto utilizzando il parametro. --server-side-encryption
aws s3api put-object --bucket example1bucket --key HappyFace.jpg --body c:\HappyFace.jpg --server-side-encryption "AES256" --profile AccountBadmin
Esempio 3: Concessione a s3: PutObject autorizzazione a copiare oggetti con una restrizione sulla fonte di copia
Nella richiesta PUT Object, quando specifichi un oggetto di origine, viene eseguita un'operazione di copia (consulta PUT Object - Copy). Di conseguenza è possibile che il proprietario del bucket assegni all'utente l'autorizzazione a copiare gli oggetti con qualche limitazione sull'origine, ad esempio:
-
Consentire la copia di oggetti solo dal bucket
sourcebucket. -
Consentire la copia di oggetti dal bucket di origine e solo di quegli oggetti il cui prefisso del nome della chiave inizia con public/ f (ad esempio, sourcebucket/public/*).
-
Consentire la copia di un solo oggetto specifico dal bucket di origine (ad esempio, sourcebucket/example.jpg).
La seguente politica sui bucket concede l'autorizzazione all'utente (Akua). s3:PutObject che gli consente di copiare solo gli oggetti con la condizione che la richiesta includa l'intestazione s3:x-amz-copy-source e il valore di intestazione specifichi il prefisso del nome della chiave /awsexamplebucket1/public/*.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "cross-account permission to user in your own account", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/Akua" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*" }, { "Sid": "Deny your user permission to upload object if copy source is not /bucket/folder", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:user/Akua" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringNotLike": { "s3:x-amz-copy-source": "awsexamplebucket1/public/*" } } } ] }
Prova la politica con AWS CLI
È possibile verificare l'autorizzazione utilizzando il AWS CLI copy-object comando. È possibile specificare l'origine aggiungendo il parametro --copy-source; il prefisso del nome della chiave deve corrispondere al prefisso consentito nella policy. È necessario fornire all'utente le credenziali Akua utilizzando il --profile parametro. Per ulteriori informazioni sulla configurazione di AWS CLI, vedere. Sviluppo con Amazon S3 tramite la AWS CLI
aws s3api copy-object --bucketawsexamplebucket1--key HappyFace.jpg --copy-sourceexamplebucket/public/PublicHappyFace1.jpg --profile AccountAAkua
Concessione dell'autorizzazione a copiare solo un oggetto specifico
La policy di cui sopra utilizza la condizione StringNotLike. Per assegnare l'autorizzazione a copiare solo un determinato oggetto, è necessario modificare la condizione da StringNotLike a StringNotEquals e quindi specificare l'esatta chiave dell'oggetto, come illustrato.
"Condition": { "StringNotEquals": { "s3:x-amz-copy-source": "awsexamplebucket1/public/PublicHappyFace1.jpg" } }
Esempio 4: assegnazione dell'accesso a una versione specifica di un oggetto
Si supponga che l'Account A possieda un bucket abilitato per le versioni. Il bucket ha diverse versioni dell'oggetto HappyFace.jpg. L'amministratore dell'account ora vuole concedere all'utente Akua il permesso di ottenere solo una versione specifica dell'oggetto. L'amministratore dell'account può farlo concedendo l's3:GetObjectVersionautorizzazione ad Akua in modo condizionale, come mostrato di seguito. La coppia chiave-valore nel blocco Condition specifica la chiave di condizione s3:VersionId. In questo caso, Akua deve conoscere l'ID esatto della versione dell'oggetto per recuperarlo.
Per ulteriori informazioni, consulta GetObject in Amazon Simple Storage Service API Reference (Guida di riferimento per l'API di Amazon Simple Storage Service).
{ "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/Akua" }, "Action": "s3:GetObjectVersion", "Resource": "arn:aws:s3:::examplebucketversionenabled/HappyFace.jpg" }, { "Sid": "statement2", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:user/Akua" }, "Action": "s3:GetObjectVersion", "Resource": "arn:aws:s3:::examplebucketversionenabled/HappyFace.jpg", "Condition": { "StringNotEquals": { "s3:VersionId": "AaaHbAQitwiL_h47_44lRO2DDfLlBO5e" } } } ] }
Prova la politica con AWS CLI
È possibile testare le autorizzazioni utilizzando il AWS CLI get-object comando con il --version-id parametro che identifica la versione specifica dell'oggetto. Il comando recupera l'oggetto e lo salva nel file OutputFile.jpg.
aws s3api get-object --bucketexamplebucketversionenabled--key HappyFace.jpg OutputFile.jpg --version-idAaaHbAQitwiL_h47_44lRO2DDfLlBO5e--profile AccountAAkua
Esempio 5: limitazione dei caricamenti degli oggetti ai soli oggetti con una classe di storage specifica
Supponiamo che l'account A, rappresentato dall'ID account 123456789012, sia proprietario di un bucket. L'amministratore dell'account desidera limitare Akua, un utente dell'Account A, in modo che possa caricare nel bucket solo oggetti archiviati con la STANDARD_IA classe di archiviazione. Per limitare il caricamento di oggetti con una classe di storage specifica, l'amministratore dell'Account A può utilizzare la chiave di condizione s3:x-amz-storage-class, come illustrato nella policy di bucket di esempio seguente.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/Akua" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET1/*", "Condition": { "StringEquals": { "s3:x-amz-storage-class": [ "STANDARD_IA" ] } } } ] }
Esempio 6: concessione delle autorizzazioni in base ai tag dell'oggetto
Per esempi su come utilizzare le chiavi di condizione per il tagging di oggetti con le operazioni di Amazon S3, consulta Tagging e policy di controllo degli accessi.
Esempio 7: limitazione dell'accesso in base all' Account AWS ID del proprietario del bucket
Puoi utilizzare la chiave di condizione aws:ResourceAccount o s3:ResourceAccount per scrivere policy IAM o di endpoint del cloud privato virtuale (VPC) che limitano l'accesso di utenti, ruoli o applicazioni ai bucket Amazon S3 di proprietà di un determinato ID dell' Account AWS . Ciò è utile se desideri impedire ai client all'interno del tuo VPC di accedere a bucket di cui non sei proprietario.
Tuttavia, tieni presente che alcuni AWS servizi si basano sull'accesso a bucket AWS gestiti. Pertanto, l'utilizzo della chiave di condizione aws:ResourceAccount o s3:ResourceAccount nella policy IAM potrebbe anche influire sull'accesso a tali risorse.
Per ulteriori informazioni ed esempi, consulta le seguenti risorse:
-
Limitazione dell'accesso ai bucket in un Account AWS specificato nella Guida di AWS PrivateLink
-
Limitazione dell'accesso ai bucket utilizzati da Amazon ECRnella Guida di Amazon ECR
-
Fornisci l'accesso richiesto a Systems Manager per i bucket Amazon S3 AWS gestiti nella guida AWS Systems Manager
-
Limitazione dell'accesso ai bucket Amazon S3 di proprietà di specifici Account AWS
nel Blog di archiviazione AWS
Esempio 8: richiesta di una versione TLS minima
Puoi utilizzare s3: TlsVersion condition key per scrivere policy IAM, Virtual Private Cloud Endpoint (VPCE) o bucket che limitano l'accesso di utenti o applicazioni ai bucket Amazon S3 in base alla versione TLS utilizzata dal client. È possibile utilizzare questa chiave di condizione per scrivere policy che richiedono una versione TLS minima.
Questo esempio di bucket policy nega le PutObject richieste dei client con una versione TLS inferiore alla 1.2, ad esempio 1.1 o 1.0.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::", "arn:aws:s3:::DOC-EXAMPLE-BUCKET1/*" ], "Condition": { "NumericLessThan": { "s3:TlsVersion": 1.2 } } } ] }DOC-EXAMPLE-BUCKET1
Questo esempio di bucket policy consente PutObject le richieste da parte di client con una versione TLS superiore alla 1.1, ad esempio 1.2, 1.3 o successiva.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::", "arn:aws:s3:::DOC-EXAMPLE-BUCKET1/*" ], "Condition": { "NumericGreaterThan": { "s3:TlsVersion": 1.1 } } } ] }DOC-EXAMPLE-BUCKET1
Esempi – Chiavi di condizione di Amazon S3 per le operazioni sui bucket
In questa sezione vengono fornite policy di esempio che illustrano come utilizzare le chiavi di condizione specifiche di Amazon S3 per le operazioni sui bucket.
Argomenti
Esempio 1: concessione di un'autorizzazione utente per creare un bucket solo in una regione specifica
Supponiamo che un Account AWS amministratore voglia concedere al proprio utente (Akua) l'autorizzazione a creare un bucket solo nella regione del Sud America (San Paolo). L'amministratore dell'account può collegare la seguente policy utente assegnando l'autorizzazione s3:CreateBucket con una condizione, come mostrato. La coppia chiave-valore nel blocco Condition specifica la chiave s3:LocationConstraint e la regione sa-east-1 come valore corrispondente.
Nota
In questo esempio, il proprietario di bucket sta assegnando un'autorizzazione a uno dei suoi utenti, in modo da poter utilizzare una policy di bucket o una policy utente. Questo esempio mostra una policy utente.
Per un elenco delle regioni di Amazon S3, consultare la sezione relativa a regioni ed endpoint nella Riferimenti generali di AWS.
{ "Version":"2012-10-17", "Statement":[ { "Sid":"statement1", "Effect":"Allow", "Action": "s3:CreateBucket", "Resource": "arn:aws:s3:::*", "Condition": { "StringLike": { "s3:LocationConstraint": "sa-east-1" } } } ] }
Aggiunta del rifiuto esplicito
La policy precedente limita l'utente impedendogli di creare un bucket in qualsiasi altra regione al di fuori di sa-east-1. Tuttavia, qualche altra policy potrebbe assegnare a questo utente l'autorizzazione a creare bucket in un'altra regione. Ad esempio, se l'utente appartiene a un gruppo, è possibile che questo gruppo abbia una policy collegata che assegna a tutti gli utenti del gruppo stesso l'autorizzazione a creare bucket in un'altra regione. Per essere certi che l'utente non ottenga l'autorizzazione a creare bucket in qualsiasi altra regione, è possibile aggiungere una dichiarazione di rifiuto esplicito nelle policy precedente.
L'istruzione Deny utilizza la condizione StringNotLike. Cioè, la richiesta di creazione del bucket viene rifiutata se il vincolo di posizione non è sa-east-1. Il rifiuto esplicito non consente all'utente di creare un bucket in alcuna altra regione, indipendentemente da quale altra autorizzazione ottenga l'utente. La seguente policy include una dichiarazione di rifiuto esplicito.
{ "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" } } } ] }
Prova la politica con AWS CLI
È possibile testare la politica utilizzando il seguente create-bucket AWS CLI comando. Questo esempio utilizza il file bucketconfig.txt per specificare il vincolo di posizione. Notare il percorso dei file Windows. È necessario aggiornare il nome del bucket e il percorso come opportuno. È necessario fornire le credenziali utente utilizzando il parametro --profile. Per ulteriori informazioni sulla configurazione e l'utilizzo di AWS CLI, vedereSviluppo con Amazon S3 tramite la AWS CLI.
aws s3api create-bucket --bucketexamplebucket--profile AccountAAkua --create-bucket-configuration file://c:/Users/someUser/bucketconfig.txt
Il file bucketconfig.txt specifica la configurazione come segue:
{"LocationConstraint": "sa-east-1"}
Esempio 2: recupero di un elenco di oggetti in un bucket con un prefisso specifico
È possibile utilizzare la chiave s3:prefix condition per limitare la risposta dell'API GET Bucket (ListObjects) ai nomi di chiave con un prefisso specifico. Se si è il proprietario del bucket, è possibile limitare un utente a elencare il contenuto di un prefisso specifico nel bucket. Questa chiave di condizione risulta utile se gli oggetti nel bucket sono organizzati per prefissi del nomi delle chiavi. La console di Amazon S3 utilizza i prefissi dei nomi delle chiavi per mostrare un concetto di cartella. Solo la console supporta il concetto di cartelle, mentre l'API Amazon S3 supporta solo bucket e oggetti. Per ulteriori informazioni sull'utilizzo di prefissi e delimitatori per filtrare le autorizzazioni di accesso, consulta Procedura guidata: controllo dell'accesso a un bucket con policy utente.
Ad esempio, se vi sono due oggetti con nomi delle chiavi public/object1.jpg e public/object2.jpg, la console mostra gli oggetti nella cartella public. Nell'API Amazon S3 questi sono oggetti con prefissi, non oggetti nelle cartelle. Se tuttavia nell'API Amazon S3 organizzi le chiavi degli oggetti utilizzando tali prefissi, puoi concedere l'autorizzazione s3:ListBucket con la condizione s3:prefix che permette all'utente di ottenere un elenco dei nomi delle chiavi con un tali prefissi specifici.
In questo esempio, il proprietario del bucket e l'account padre a cui appartiene l'utente corrispondono. Quindi, il proprietario del bucket può utilizzare una policy di bucket o una policy utente. Per ulteriori informazioni su altre chiavi condizionali che puoi utilizzare con l'API GET Bucket (ListObjects), consulta. ListObjects
Policy utente
La policy utente seguente concede l'autorizzazione s3:ListBucket (consulta GET Bucket (List Objects)) con una condizione che richiede all'utente di specificare prefix nella richiesta con il valore projects.
{ "Version":"2012-10-17", "Statement":[ { "Sid":"statement1", "Effect":"Allow", "Action": "s3:ListBucket", "Resource":"arn:aws:s3:::awsexamplebucket1", "Condition" : { "StringEquals" : { "s3:prefix": "projects" } } }, { "Sid":"statement2", "Effect":"Deny", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::awsexamplebucket1", "Condition" : { "StringNotEquals" : { "s3:prefix": "projects" } } } ] }
La condizione limita l'utente a elencare solo le chiavi degli oggetti con il prefisso projects. Il rifiuto esplicito aggiunto rifiuta all'utente la richiesta di elencazione delle chiavi con qualsiasi altro prefisso, indipendentemente da quale altra autorizzazione possa avere l'utente. Ad esempio, è possibile che l'utente ottenga l'autorizzazione a elencare le chiavi degli oggetti senza alcuna limitazione in base agli aggiornamenti alla precedente policy utente oppure tramite una policy di bucket. Poiché il rifiuto esplicito è sempre prevalente, la richiesta dell'utente di elencare chiavi diverse dal prefisso projects viene rifiutata.
Policy del bucket
Se si aggiunge l'elemento Principal alla policy utente precedente, identificando l'utente, si ottiene una policy di bucket come illustrato.
{ "Version":"2012-10-17", "Statement":[ { "Sid":"statement1", "Effect":"Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/bucket-owner" }, "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::awsexamplebucket1", "Condition" : { "StringEquals" : { "s3:prefix": "projects" } } }, { "Sid":"statement2", "Effect":"Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:user/bucket-owner" }, "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::awsexamplebucket1", "Condition" : { "StringNotEquals" : { "s3:prefix": "projects" } } } ] }
Testate la politica con AWS CLI
È possibile testare la politica utilizzando il seguente list-object AWS CLI comando. Nel comando, vengono fornite le credenziali utente utilizzando il parametro --profile. Per ulteriori informazioni sulla configurazione e l'utilizzo di AWS CLI, vedereSviluppo con Amazon S3 tramite la AWS CLI.
aws s3api list-objects --bucketawsexamplebucket1--prefix examplefolder --profile AccountAAkua
Se il bucket è abilitato per le versioni, al fine di elencare gli oggetti nel bucket invece dell'autorizzazione s3:ListBucket è necessario assegnare l'autorizzazione s3:ListBucketVersions nella policy precedente. Questa autorizzazione supporta la chiave di condizione s3:prefix.
Esempio 3: impostazione del numero massimo di chiavi
È possibile utilizzare la chiave s3:max-keys condition per impostare il numero massimo di chiavi che il richiedente può restituire in un GET Bucket (ListObjects) o ListObjectVersionsin una richiesta. Per impostazione predefinita, l'API restituisce fino a 1.000 chiavi. Per un elenco di operatori di condizione numerici che è possibile utilizzare con s3:max-keys e i relativi esempi, consulta Operatori di condizione numerici nella Guida per l'utente di IAM.
