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 politiche per ACLs
Puoi utilizzare le chiavi di condizione nelle policy dei bucket per controllare l'accesso ad Amazon S3.
Argomenti
Concessione di s3: PutObject autorizzazione con una condizione che richiede al proprietario del bucket di ottenere il pieno controllo
L'operazione PUTObject consente di utilizzare intestazioni specifiche di access control list (ACL), che è possibile utilizzare per concedere autorizzazioni basate su autorizzazioni. 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.
Si supponga che l'Account A sia proprietario di un bucket e che l'amministratore dell'account voglia assegnare a Dave, un utente dell'Account B, le autorizzazioni per caricare oggetti. Per default, gli oggetti che carica Dave sono di proprietà dell'Account B e l'Account A non dispone di autorizzazioni su tali oggetti. Dato che il proprietario del bucket paga i conti, vuole avere le autorizzazioni complete sugli oggetti che carica Dave. L'amministratore dell'account A può farlo concedendo l's3:PutObject
autorizzazione a Dave, a condizione che la richiesta includa intestazioni ACL specifiche che concedano esplicitamente l'autorizzazione completa o ne utilizzino una predefinita. ACL Per ulteriori informazioni, consulta Object. PUT
Richiedi l' x-amz-full-controlintestazione
È possibile richiedere l'intestazione x-amz-full-control
nella richiesta con autorizzazione al controllo completo al proprietario del bucket. La seguente policy di bucket assegna l'autorizzazione s3:PutObject
all'utente Dave con la condizione di utilizzare la chiave di condizione s3:x-amz-grant-full-control
che prevede 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/Dave" }, "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 Dave (che sta ottenendo l'autorizzazione) appartiene al proprietario del Account AWS bucket, questa autorizzazione condizionata non è necessaria. Questo perché l'account padre a cui Dave appartiene è proprietario degli oggetti caricati dall'utente.
Aggiunta del rifiuto esplicito
La precedente policy di bucket assegna l'autorizzazione condizionale all'utente Dave nell'Account B. Quando questa policy è attiva, per Dave è possibile ottenere la stessa autorizzazione senza alcuna condizione tramite qualche altra policy. Ad esempio, Dave può appartenere a un gruppo a cui viene assegnata l'autorizzazione s3:PutObject
senza alcuna condizione. Per evitare questi espedienti riguardo alle autorizzazioni, è possibile scrivere una policy di accesso più rigida aggiungendo un rifiuto esplicito. In questo esempio, all'utente Dave viene esplicitamente rifiutata l'autorizzazione a eseguire caricamenti se non include le intestazioni necessarie nella richiesta che assegnano 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 utilizzate le credenziali di Dave per testare l'autorizzazione utilizzando il seguente AWS CLI
put-object
comando. Le credenziali di Dave vengono fornite 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, consulta Sviluppare con Amazon S3 usando il AWS CLI nel Amazon API S3 Reference.
aws s3api put-object --bucket
examplebucket
--key HappyFace.jpg --body c:\HappyFace.jpg --grant-full-control id="AccountA-CanonicalUserID
" --profile AccountBUserProfile
Richiedi l'intestazione x-amz-acl
Puoi richiedere che l'x-amz-acl
intestazione con un codice predefinito ACL conceda il pieno controllo 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 testare l'autorizzazione utilizzando il AWS CLI, è necessario specificare il parametro. --acl
AWS CLI Quindi aggiunge l'x-amz-acl
intestazione quando invia la richiesta.
aws s3api put-object --bucket
examplebucket
--key HappyFace.jpg --body c:\HappyFace.jpg --acl "bucket-owner-full-control" --profile AccountBadmin
Concessione di s3: PutObject autorizzazione con una condizione nell'intestazione x-amz-acl
La seguente policy sui bucket concede l's3:PutObject
autorizzazione per due persone Account AWS se la richiesta include l'x-amz-acl
intestazione che rende l'oggetto leggibile pubblicamente. Il blocco Condition
utilizza la condizione StringEquals
ed è dotato di una coppia chiave-valore, "s3:x-amz-acl":["public-read"]
, per la valutazione. Nella coppia chiave-valore, la s3:x-amz-acl
è una chiave specifica di Amazon S3, come indicato dal prefisso s3:
.
{ "Version":"2012-10-17", "Statement": [ { "Sid":"AddCannedAcl", "Effect":"Allow", "Principal": { "AWS": [ "arn:aws:iam::
Account1-ID
:root", "arn:aws:iam::Account2-ID
:root" ] }, "Action":"s3:PutObject", "Resource": ["arn:aws:s3:::awsexamplebucket1
/*"], "Condition": { "StringEquals": { "s3:x-amz-acl":["public-read"] } } } ] }
Importante
Non tutte le condizioni hanno significato per tutte le operazioni. Ha senso, ad esempio, includere una condizione s3:LocationConstraint
in una policy che concede l'autorizzazione s3:CreateBucket
di Amazon S3. Non ha tuttavia senso includere questa condizione in una policy che concede l'autorizzazione s3:GetObject
. Amazon S3 può verificare la presenza di errori semantici di questo tipo che riguardano condizioni specifiche di Amazon S3. Tuttavia, se stai creando una policy per un IAM utente o un ruolo e includi una condizione Amazon S3 semanticamente non valida, non viene segnalato alcun errore perché non è possibile convalidare IAM le condizioni di Amazon S3.