# Exemplos de política para ACLs É possível usar chaves de condição em políticas de bucket para controlar o acesso ao Amazon S3. **Topics** + [ ## Conceder a permissão s3:PutObject com uma condição que exige que o proprietário do bucket obtenha controle total ](#grant-putobject-conditionally-1) + [ ## Conceder a permissão s3:PutObject com uma condição no cabeçalho x-amz-acl ](#example-acl-header) ## Conceder a permissão s3:PutObject com uma condição que exige que o proprietário do bucket obtenha controle total A operação [PUT Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html) permite cabeçalhos específicos da lista de controle de acesso (ACL) que você usa para conceder permissões baseadas em ACL. Usando essas chaves, o proprietário do bucket pode definir uma condição para exigir permissões de acesso específicas quando o usuário faz upload de um objeto. Suponha que a conta A seja proprietária de um bucket e que o administrador da conta queira conceder a Dave, um usuário na conta B, permissões para fazer upload de objetos. Por padrão, os objetos que Dave carrega são de propriedade da conta B, e a conta A não tem permissões nesses objetos. Como o proprietário do bucket é quem paga a fatura, ele quer permissões completas nos objetos que Dave carrega. O administrador da conta A pode fazer isso concedendo a Dave a permissão `s3:PutObject`, com a condição de que a solicitação inclua cabeçalhos específicos da ACL, que concede permissão total explícita ou usa uma ACL pré-configurada. Para obter mais informações, consulte [Objeto PUT](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html). ### Exigir o cabeçalho x-amz-full-control Você pode exigir o cabeçalho `x-amz-full-control` na solicitação com permissão de controle total do proprietário do bucket. A política de bucket a seguir concede ao usuário Dave a permissão `s3:PutObject` com uma condição de uso da chave de condição `s3:x-amz-grant-full-control`, que exige que a solicitação inclua o cabeçalho `x-amz-full-control`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:user/Dave" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } } ] } ``` ------ **nota** Este exemplo trata da permissão entre contas. Contudo, se Dave (a quem é concedida a permissão) pertencer à Conta da AWS que é proprietária do bucket, essa permissão condicional não será necessária. Isso acontece porque a conta pai à qual o Dave pertence é proprietária dos objetos que o usuário carrega. **Adicionar negação explícita** A política de bucket anterior concede permissão condicional ao usuário Dave na conta B. Enquanto essa política estiver em vigor, Dave poderá obter a mesma permissão sem nenhuma condição por meio de alguma outra política. Por exemplo, Dave pode pertencer a um grupo e você concede ao grupo a permissão `s3:PutObject` sem nenhuma condição. Para evitar essas brechas de permissão, você pode elaborar uma política de acesso mais estrita adicionando uma negação explícita. Neste exemplo, você nega explicitamente a permissão de upload ao usuário Dave se ele não incluir os cabeçalhos necessários na solicitação, concedendo permissões totais ao proprietário do bucket. A negação explícita sempre se sobrepõe a qualquer outra permissão concedida. Veja a seguir um exemplo de política de acesso revisada com a negação explícita adicionada. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333: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::111122223333:user/AccountBadmin" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringNotEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } } ] } ``` ------ **Testar a política com a AWS CLI** Se você tiver duas Contas da AWS, teste a política usando a AWS Command Line Interface (AWS CLI). Anexe a política e use as credenciais de Dave para testar a permissão usando o seguinte comando AWS CLI da `put-object`. Você fornece as credenciais de Dave adicionando o parâmetro `--profile`. Você concede permissão de controle total ao proprietário do bucket adicionando o parâmetro `--grant-full-control`. Consulte mais informações sobre como configurar e usar a AWS CLI em [Developing with Amazon S3 using the AWS CLI](https://docs.aws.amazon.com/AmazonS3/latest/API/setup-aws-cli.html) na *Referência de API do Amazon S3*. ``` aws s3api put-object --bucket examplebucket --key HappyFace.jpg --body c:\HappyFace.jpg --grant-full-control id="AccountA-CanonicalUserID" --profile AccountBUserProfile ``` ### Exigir o cabeçalho x-amz-acl Você pode exigir o cabeçalho `x-amz-acl` com uma ACL padrão que concede permissão de controle total ao proprietário do bucket. Para exigir o cabeçalho `x-amz-acl` na solicitação, você pode substituir o par de chave-valor no bloco `Condition` e especificar a chave de condição `s3:x-amz-acl`, conforme o exemplo abaixo. ``` "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" } } ``` Para testar a permissão usando a AWS CLI, especifique o parâmetro `--acl`. Em seguida, a AWS CLI adiciona o cabeçalho `x-amz-acl` ao enviar a solicitação. ``` aws s3api put-object --bucket examplebucket --key HappyFace.jpg --body c:\HappyFace.jpg --acl "bucket-owner-full-control" --profile AccountBadmin ``` ## Conceder a permissão s3:PutObject com uma condição no cabeçalho x-amz-acl A política de bucket a seguir concederá a permissão `s3:PutObject` a duas Contas da AWS se a solicitação incluir o cabeçalho `x-amz-acl`, tornando o objeto publicamente legível. O bloco `Condition` usa a condição `StringEquals` e recebe um par de chave/valor, `"s3:x-amz-acl":["public-read"]`, para avaliação. No par de chave-valor, `s3:x-amz-acl` é uma chave específica do Amazon S3, conforme indicado pelo prefixo `s3:`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AddCannedAcl", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::111122223333:root" ] }, "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::awsexamplebucket1/*" ], "Condition": { "StringEquals": { "s3:x-amz-acl": [ "public-read" ] } } } ] } ``` ------ **Importante** Nem todas as condições fazem sentido para todas as ações. Por exemplo, faz sentido incluir uma condição `s3:LocationConstraint` em uma política que concede a permissão `s3:CreateBucket` do Amazon S3. No entanto, não faz sentido incluir essa condição em uma política que conceda a permissão `s3:GetObject`. O Amazon S3 pode testar erros de semântica para esse tipo que envolve condições específicas do Amazon S3. Contudo, se você estiver criando uma política para um perfil ou usuário do IAM e incluir uma condição do Amazon S3 semanticamente inválida, nenhum erro será relatado porque o IAM não pode validar condições do Amazon S3.