Diretrizes para políticas de acesso - Amazon Simple Storage Service

Diretrizes para políticas de acesso

O Amazon S3 oferece suporte para políticas com base em recursos e políticas de usuário para gerenciar o acesso aos recursos do Amazon S3. Para obter mais informações, consulte Gerenciar o acesso aos recursos. As políticas com base em recursos incluem políticas de bucket, listas de controle de acesso (ACLs) de bucket e ACLs de objeto. Esta seção descreve cenários específicos para usar políticas de acesso com base em recursos para gerenciar o acesso aos recursos do Amazon S3.

Quando usar uma política de acesso com base em ACL (ACLs de bucket e objeto)

Os buckets e objetos têm ACLs associadas que você pode usar para conceder permissões. As seguintes seções descrevem cenários para usar ACLs de objeto e ACLs de bucket.

Quando usar uma ACL de objeto

Além de uma ACL de objeto, o proprietário de objeto pode gerenciar permissões de objeto de outras formas. Por exemplo:

  • Se a Conta da AWS que possui o objeto também possuir o bucket, poderá gravar uma política de bucket para gerenciar permissões de objeto.

  • Se a Conta da AWS que possui o objeto desejar conceder permissão a um usuário em sua conta, poderá usar uma política de usuário.

Então quando usar ACLs de objeto para gerenciar permissões de objeto? Veja a seguir os cenários em que você faria isso.

Objetos não pertencentes ao proprietário do bucket

Uma ACL de objeto é a única maneira de gerenciar o acesso a objetos não pertencentes ao proprietário do bucket. Uma Conta da AWS que possui o bucket pode conceder permissão para outra conta da Conta da AWS fazer upload de objetos. O proprietário do bucket não detém esses objetos. A Conta da AWS que criou o objeto deve conceder permissões usando ACLs de objeto.

nota

Um proprietário do bucket não pode conceder permissões em objetos que não possui. Por exemplo, uma política de bucket que concede permissões de objeto aplica-se somente a objetos do proprietário do bucket. Contudo, o proprietário do bucket, que paga as faturas, pode gravar uma política de bucket para negar acesso a todos os objetos no bucket, independentemente de quem o possui. O proprietário do bucket também pode excluir todos os objetos no bucket.

Você precisa gerenciar permissões no nível do objeto

Suponha que as permissões variem de acordo com o objeto e você precise gerenciar permissões no nível do objeto. É possível gravar uma única instrução de política que conceda a uma Conta da AWS permissão de leitura e milhões de objetos com um prefixo específico de nome de chave. Por exemplo, você pode permissão de leitura em objetos que começam com “logs” como prefixo de nome de chave. Contudo, se as permissões de acesso variam por objeto, conceder permissões para objetos individuais usando uma política de bucket talvez não seja prático. Além disso, as políticas de bucket são limitadas a 20 KB.

Nesse caso, você pode considerar o uso de ACLs de objeto como uma boa alternativa. No entanto, mesmo uma ACL de objeto é limitada a, no máximo, 100 concessões. Para obter mais informações, consulte Visão geral da lista de controle de acesso (ACL).

As ACLs de objeto controlam somente permissões no nível do objeto

Há uma política de bucket para o bucket todo, mas as ACLs de objeto são especificadas por objeto.

Uma Conta da AWS que possui um bucket pode conceder outra permissão de Conta da AWS para gerenciar a política de acesso. Ela permite que a conta altere algo na política. Para gerenciar permissões melhor, você pode optar por não conceder uma permissão tão ampla e conceder somente as permissões READ-ACP e WRITE-ACP em um subconjunto de objetos. Isso limita a conta para gerenciar permissões somente em objetos específicos atualizando ACLs de objeto individuais.

Quando usar uma ACL de bucket

O único caso de uso recomendado para a ACL de bucket é conceder a permissão de gravação para o grupo de entrega de logs do Amazon S3 para gravar objetos de log de acesso no bucket. Para obter mais informações, consulte Registrar em log as solicitações com registro em log de acesso ao servidor.

Se você quiser que o Amazon S3 forneça logs de acesso ao seu bucket, deve conceder permissão de gravação no bucket ao grupo de entrega de log. A única maneira de conceder as permissões necessárias para o grupo de entrega de log é usar uma ACL de bucket, conforme exibido no seguinte fragmento de ACL de bucket.

<?xml version="1.0" encoding="UTF-8"?> <AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <Owner> ... </Owner> <AccessControlList> <Grant> ... </Grant> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group"> <URI>http://acs.amazonaws.com/groups/s3/LogDelivery</URI> </Grantee> <Permission>WRITE</Permission> </Grant> </AccessControlList> </AccessControlPolicy>

Quando usar uma política de bucket

Se uma Conta da AWS que possui um bucket desejar conceder permissão aos usuários em sua conta, ela poderá usar uma política de bucket ou de usuário. Mas, nos cenários a seguir, você deve usar uma política de bucket.

Você deseja gerenciar permissões entre contas para todas as permissões do Amazon S3

Você pode usar ACLs para conceder permissões entre contas a outras contas. Mas as ACLs são compatíveis apenas com um conjunto finito de permissões, e essas não incluem todas as permissões do Amazon S3. Para obter mais informações, consulte Quais permissões posso conceder?. Por exemplo, você não pode conceder permissões em sub-recursos de bucket usando uma ACL. Para obter mais informações, consulte Identity and Access Management no Amazon S3.

As políticas de bucket e de usuário são compatíveis com a concessão de permissão para todas as operações do Amazon S3. (Para obter mais informações, consulte Ações do Amazon S3.) No entanto, as políticas de usuário se destinam a gerenciar permissões para usuários em sua conta. Para permissões entre contas para outras Contas da AWS ou usuários em outra conta, você deve usar uma política de bucket.

Quando usar uma política de usuário

Geralmente, você pode usar uma política de usuário ou uma política de bucket para gerenciar permissões. Você pode optar por gerenciar permissões criando usuários e gerenciando permissões individualmente com a associação de políticas a usuários (ou grupos de usuários). Também é possível que você considere as políticas baseadas em recursos, como a política de bucket, funcionam melhor para o seu cenário.

Com o AWS Identity and Access Management (IAM), é possível criar vários usuários em sua Conta da AWS e gerenciar as permissões deles por meio de políticas de usuário. Um usuário do IAM deve ter permissões na conta pai a qual pertence e na Conta da AWS que tem o recurso que o usuário deseja acessar. As permissões podem ser concedidas do seguinte modo:

  • Permissão na conta pai: a conta pai pode conceder permissões para seu usuário anexando uma política de usuário.

  • Permissão do proprietário do recurso: o proprietário do recurso pode conceder permissão para o usuário do IAM (usando uma política de bucket) ou para a conta pai (usando uma política de bucket, uma ACL de bucket ou uma ACL de objeto).

É semelhante a uma criança que deseja brincar com um brinquedo que pertence a outra pessoa. Nesse caso, a criança precisa obter permissão de um responsável para brincar com o brinquedo e permissão do proprietário do brinquedo.

Políticas de bucket e políticas de usuário

Delegação de permissão

Se uma Conta da AWS possuir um recurso, poderá conceder essas permissões para outra conta da Conta da AWS. Essa conta pode então delegar essas permissões, ou um subconjunto delas, para usuários da conta. Isso é chamado de delegação de permissão. Mas uma conta que recebe permissões de outra conta não pode delegar permissão entre contas para outra Conta da AWS.

Recomendamos que você analise, primeiramente, todos os tópicos introdutórios que explicam como gerenciar o acesso aos recursos do Amazon S3 e as diretrizes relacionadas. Para obter mais informações, consulte Identity and Access Management no Amazon S3. Você pode usar os seguintes tópicos para obter mais informações sobre as opções específicas da política de acesso.