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.

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 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.

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.

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

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.

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

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 put-object da AWS CLI. 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. Para obter mais informações sobre a configuração e o uso da AWS CLI, consulte Desenvolvimento com o Amazon S3 usando a AWS CLI.

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:.

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

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.