Definir ACL de contêiner
A operação Set Container ACL define as permissões para o contêiner especificado. As permissões indicam se os blobs em um contêiner podem ser acessados publicamente.
A partir da versão 2009-09-19, as permissões de contêiner fornecem as seguintes opções para gerenciar o acesso ao contêiner:
acesso de leitura público completo: Dados de contêiner e blob podem ser lidos por meio de solicitação anônima. Os clientes podem enumerar blobs dentro do contêiner por meio de solicitação anônima, mas não podem enumerar contêineres dentro da conta de armazenamento.
acesso público de leitura somente para blobs: os dados de Blob dentro desse contêiner podem ser lidos por meio de solicitação anônima, mas os dados do contêiner não estão disponíveis. Os clientes não podem enumerar blobs dentro do contêiner por meio de solicitação anônima.
Nenhum acesso de leitura público: dados de contêiner e blob podem ser lidos apenas pelo proprietário da conta.
Set Container ACL também define uma política de acesso armazenado para uso com assinaturas de acesso compartilhado. Para obter mais informações, consulte Definir uma política de acesso armazenada.
Todo o acesso público ao contêiner é anônimo, assim como o acesso por meio de uma assinatura de acesso compartilhado.
Pedir
A solicitação Set Container ACL pode ser construída da seguinte maneira. Recomendamos que você use HTTPS. Substitua myaccount pelo nome da sua conta de armazenamento:
| Método | URI de solicitação | Versão HTTP |
|---|---|---|
PUT |
https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl |
HTTP/1.1 |
Solicitação de serviço de armazenamento emulado
Ao fazer uma solicitação no serviço de armazenamento emulado, especifique o nome do host do emulador e a porta do serviço Blob como 127.0.0.1:10000, seguido pelo nome da conta de armazenamento emulado:
| Método | URI de solicitação | Versão HTTP |
|---|---|---|
PUT |
http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container&comp=acl |
HTTP/1.1 |
Para obter mais informações, consulte Usar o emulador do Azurite paralocais de desenvolvimento do Armazenamento do Azure.
Parâmetros de URI
Você pode especificar os seguintes parâmetros adicionais no URI da solicitação:
| Parâmetro | Descrição |
|---|---|
timeout |
Opcional. O parâmetro timeout é expresso em segundos. Para obter mais informações, consulte Definir tempos limite para operações de serviço blob. |
Cabeçalhos de solicitação
Os cabeçalhos de solicitação obrigatórios e opcionais são descritos na tabela a seguir:
| Cabeçalho de solicitação | Descrição |
|---|---|
Authorization |
Necessário. Especifica o esquema de autorização, o nome da conta e a assinatura. Para obter mais informações, consulte Autorizar solicitações para o Armazenamento do Azure. |
Date ou x-ms-date |
Necessário. Especifica o UTC (Tempo Universal Coordenado) para a solicitação. Para obter mais informações, consulte Autorizar solicitações para o Armazenamento do Azure. |
x-ms-version |
Opcional. Especifica a versão da operação a ser usada para essa solicitação. Para obter mais informações, consulte Controle de versão para os serviços de Armazenamento do Azure. |
x-ms-blob-public-access |
Opcional. Especifica se os dados no contêiner podem ser acessados publicamente e o nível de acesso. Os valores possíveis incluem: - container: especifica o acesso de leitura público completo para dados de contêiner e blob. Os clientes podem enumerar blobs dentro do contêiner por meio de solicitação anônima, mas não podem enumerar contêineres dentro da conta de armazenamento.- blob: Especifica o acesso público de leitura para blobs. Os dados de blob dentro desse contêiner podem ser lidos por meio de solicitação anônima, mas os dados do contêiner não estão disponíveis. Os clientes não podem enumerar blobs dentro do contêiner por meio de solicitação anônima.Se esse cabeçalho não estiver incluído na solicitação, os dados do contêiner serão privados para o proprietário da conta. Observe que a configuração do acesso público para um contêiner em uma conta de Armazenamento Premium do Azure não é permitida. |
x-ms-lease-id: <ID> |
Opcional, versão 2012-02-12 e posterior. Se for especificado, Set Container ACL terá êxito somente se a concessão do contêiner estiver ativa e corresponder a essa ID. Se não houver nenhuma concessão ativa ou a ID não corresponder, 412 (Falha de Pré-condição) será retornado. |
x-ms-client-request-id |
Opcional. Fornece um valor opaco gerado pelo cliente com um limite de caracteres kib (1 kibibyte) que é registrado nos logs quando o registro em log é configurado. É altamente recomendável que você use esse cabeçalho para correlacionar atividades do lado do cliente com solicitações recebidas pelo servidor. Para obter mais informações, consulte Monitorar o Armazenamento de Blobs do Azure. |
Essa operação também dá suporte ao uso de cabeçalhos condicionais para executar a operação somente se uma condição especificada for atendida. Para obter mais informações, consulte Especificar cabeçalhos condicionais para operações de serviço blob.
Corpo da solicitação
Para especificar uma política de acesso armazenado, forneça um identificador exclusivo e uma política de acesso no corpo da solicitação para a operação de Set Container ACL.
O elemento SignedIdentifier inclui o identificador exclusivo, conforme especificado no elemento Id e os detalhes da política de acesso, conforme especificado no elemento AccessPolicy. O comprimento máximo do identificador exclusivo é de 64 caracteres.
Os campos Start e Expiry devem ser expressos como horários UTC e devem aderir a um formato ISO 8061 válido. Os formatos ISO 8061 com suporte incluem o seguinte:
YYYY-MM-DDYYYY-MM-DDThh:mmTZDYYYY-MM-DDThh:mm:ssTZDYYYY-MM-DDThh:mm:ss.fffffffTZD
Para a parte de data desses formatos, YYYY é uma representação de ano de quatro dígitos, MM é uma representação de mês de dois dígitos e DD é uma representação de dia de dois dígitos. Para a parte de tempo, hh é a representação de hora na notação de 24 horas, mm é a representação de dois dígitos, ss é a representação de dois dígitos e fffffff é a representação de milissegundos de sete dígitos. Um designador de hora T separa as partes de data e hora da cadeia de caracteres e um designador de fuso horário TZD especifica um fuso horário.
<?xml version="1.0" encoding="utf-8"?>
<SignedIdentifiers>
<SignedIdentifier>
<Id>unique-64-character-value</Id>
<AccessPolicy>
<Start>start-time</Start>
<Expiry>expiry-time</Expiry>
<Permission>abbreviated-permission-list</Permission>
</AccessPolicy>
</SignedIdentifier>
</SignedIdentifiers>
Solicitação de exemplo
Request Syntax:
PUT https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl HTTP/1.1
Request Headers:
x-ms-version: 2011-08-18
x-ms-date: Sun, 25 Sep 2011 00:42:49 GMT
x-ms-blob-public-access: container
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=
Request Body:
<?xml version="1.0" encoding="utf-8"?>
<SignedIdentifiers>
<SignedIdentifier>
<Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>
<AccessPolicy>
<Start>2009-09-28T08:49:37.0000000Z</Start>
<Expiry>2009-09-29T08:49:37.0000000Z</Expiry>
<Permission>rwd</Permission>
</AccessPolicy>
</SignedIdentifier>
</SignedIdentifiers>
Resposta
A resposta inclui um código de status HTTP e um conjunto de cabeçalhos de resposta.
Código de status
Uma operação bem-sucedida retorna o código de status 200 (OK).
Para obter mais informações sobre códigos de status, consulte Status e códigos de erro.
Cabeçalhos de resposta
A resposta dessa operação inclui os cabeçalhos a seguir. A resposta também pode incluir cabeçalhos HTTP padrão adicionais. Todos os cabeçalhos padrão estão em conformidade com a especificação de protocolo HTTP/1.1 .
| Cabeçalho de resposta | Descrição |
|---|---|
ETag |
A ETag para o contêiner. Se a versão da solicitação for 2011-08-18 ou posterior, o valor ETag será colocado entre aspas. |
Last-Modified |
Retorna a data e a hora em que o contêiner foi modificado pela última vez. O formato de data segue o RFC 1123. Para obter mais informações, consulte Representar valores de data/hora em cabeçalhos. Qualquer operação que modifique o contêiner ou suas propriedades ou metadados atualiza a hora da última modificação, incluindo a definição das permissões do contêiner. As operações em blobs não afetam a hora da última modificação do contêiner. |
x-ms-request-id |
Identifica exclusivamente a solicitação que foi feita e pode ser usada para solucionar problemas da solicitação. Para obter mais informações, consulte Solucionar problemas de operações de API |
x-ms-version |
Indica a versão do serviço Blob que foi usada para executar a solicitação. Esse cabeçalho é retornado para solicitações feitas na versão 2009-09-19 e posterior. |
Date |
Um valor de data/hora UTC gerado pelo serviço, que indica a hora em que a resposta foi iniciada. |
x-ms-client-request-id |
Pode ser usado para solucionar problemas de solicitações e respostas correspondentes. O valor desse cabeçalho é igual ao valor do cabeçalho x-ms-client-request-id se ele estiver presente na solicitação e o valor não contiver mais de 1.024 caracteres ASCII visíveis. Se o cabeçalho x-ms-client-request-id não estiver presente na solicitação, ele não estará presente na resposta. |
Resposta de exemplo
Response Status:
HTTP/1.1 200 OK
Response Headers:
Transfer-Encoding: chunked
Date: Sun, 25 Sep 2011 22:42:55 GMT
ETag: "0x8CB171613397EAB"
Last-Modified: Sun, 25 Sep 2011 22:42:55 GMT
x-ms-version: 2011-08-18
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
Autorização
A autorização é necessária ao chamar qualquer operação de acesso a dados no Armazenamento do Azure. Você pode autorizar a operação de Set Container ACL, conforme descrito abaixo.
Importante
A Microsoft recomenda usar a ID do Microsoft Entra com identidades gerenciadas para autorizar solicitações ao Armazenamento do Azure. A ID do Microsoft Entra fornece segurança superior e facilidade de uso em comparação com a autorização de Chave Compartilhada.
O Armazenamento do Azure dá suporte ao uso da ID do Microsoft Entra para autorizar solicitações para dados de blob. Com a ID do Microsoft Entra, você pode usar o RBAC (controle de acesso baseado em função) do Azure para conceder permissões a uma entidade de segurança. A entidade de segurança pode ser um usuário, grupo, entidade de serviço de aplicativo ou identidade gerenciada do Azure. A entidade de segurança é autenticada pela ID do Microsoft Entra para retornar um token OAuth 2.0. Em seguida, o token pode ser usado para autorizar uma solicitação no serviço Blob.
Para saber mais sobre a autorização usando a ID do Microsoft Entra, consulte Autorizar o acesso a blobs usando a ID do Microsoft Entra.
Permissões
Veja abaixo a ação RBAC necessária para que um usuário, grupo, identidade gerenciada ou entidade de serviço do Microsoft Entra chame a operação Set Container ACL e a função rbac interna do Azure com menos privilégios que inclua esta ação:
- ação RBAC do Azure:Microsoft.Storage/storageAccounts/blobServices/containers/setAcl/action
- função interna com privilégios mínimos:proprietário de dados de blob de armazenamento
Para saber mais sobre como atribuir funções usando o RBAC do Azure, consulte Atribuir uma função do Azure para acesso a dados de blob.
Observações
Quando você define permissões para um contêiner, as permissões existentes são substituídas. Para atualizar as permissões do contêiner, chame Obter acl de contêiner para buscar todas as políticas de acesso associadas ao contêiner. Modifique a política de acesso que você deseja alterar e chame Set Container ACL com o conjunto completo de dados para executar a atualização.
Habilitar o acesso público anônimo em de dados de contêiner
Para habilitar o acesso anônimo de leitura pública nos dados do contêiner, chame Set Container ACL com o cabeçalho x-ms-blob-public-access definido como container ou blob. Para desabilitar o acesso anônimo, chame Set Container ACL sem especificar o cabeçalho x-ms-blob-public-access.
Se você definir x-ms-blob-public-access como blob, os clientes poderão chamar as seguintes operações anonimamente:
obter de Blob
obter de metadados de blob
Obter de Lista de Blocos (somente para a lista de blocos confirmada)
Se você definir x-ms-blob-public-access como container, os clientes poderão chamar as seguintes operações anonimamente:
As operações de acesso a blob listadas na seção anterior.
obter de metadados de contêiner
Estabelecer políticas de acesso no nível do contêiner
Uma política de acesso armazenada pode especificar a hora de início, a hora de expiração e as permissões para as assinaturas de acesso compartilhado com as quais está associada. Dependendo de como você deseja controlar o acesso ao seu contêiner ou recurso de blob, você pode especificar todos esses parâmetros dentro da política de acesso armazenado e omiti-los da URL para a assinatura de acesso compartilhado. Ao fazer isso, você pode modificar o comportamento da assinatura associada a qualquer momento ou revogá-la. Ou você pode especificar um ou mais parâmetros de política de acesso dentro da política de acesso armazenada e os outros na URL. Por fim, você pode especificar todos os parâmetros na URL. Nesse caso, você pode usar a política de acesso armazenada para revogar a assinatura, mas não para modificar seu comportamento. Para obter mais informações, consulte Definir uma política de acesso armazenada.
Juntos, a assinatura de acesso compartilhado e a política de acesso armazenado devem incluir todos os campos necessários para autorizar a assinatura. Se algum campo necessário estiver ausente, a solicitação falhará. Da mesma forma, se um campo for especificado na URL de assinatura de acesso compartilhado e na política de acesso armazenada, a solicitação falhará com o código de status 400 (Solicitação Incorreta).
No máximo, cinco políticas de acesso separadas podem ser definidas para um único contêiner a qualquer momento. Se mais de cinco políticas de acesso forem passadas no corpo da solicitação, o serviço retornará o código de status 400 (Solicitação Incorreta).
Uma assinatura de acesso compartilhado pode ser emitida em um contêiner ou em um blob, independentemente de os dados do contêiner estarem disponíveis para acesso de leitura anônimo. Uma assinatura de acesso compartilhado fornece uma medida maior de controle sobre como, quando e para quem um recurso se torna acessível.
Nota
Quando você estabelece uma política de acesso armazenado em um contêiner, a política pode levar até 30 segundos para entrar em vigor. Durante esse intervalo, até que a política se torne ativa, uma assinatura de acesso compartilhado associada à política de acesso armazenada falhará com o código de status 403 (Proibido).
Faturamento
As solicitações de preços podem ser originadas de clientes que usam APIs de Armazenamento de Blobs, diretamente por meio da API REST do Armazenamento de Blobs ou de uma biblioteca de clientes do Armazenamento do Azure. Essas solicitações acumulam encargos por transação. O tipo de transação afeta a forma como a conta é cobrada. Por exemplo, as transações de leitura se acumulam em uma categoria de cobrança diferente das transações de gravação. A tabela a seguir mostra a categoria de cobrança para solicitações Set Container ACL com base no tipo de conta de armazenamento:
| Operação | Tipo de conta de armazenamento | Categoria de cobrança |
|---|---|---|
| Definir ACL de contêiner | Blob de blocos Premium Uso geral padrão v2 |
Outras operações |
| Definir ACL de contêiner | Uso geral padrão v1 | Operações de gravação |
Para saber mais sobre os preços da categoria de cobrança especificada, consulte de Preços do Armazenamento de Blobs do Azure.
Consulte também
Restringir o acesso a contêineres e blobs
Delegar acesso com uma assinatura de acesso compartilhado
Criar e usar uma assinatura de acesso compartilhado
Definir uma política de acesso armazenada
obter de ACL do contêiner
autorizar solicitações para o Armazenamento do Azure
status e códigos de erro
códigos de erro do serviço blob