Definir Expiração do Blob

Artigo
02/03/2024

A Set Blob Expiry operação define uma data de expiração num blob existente. Esta operação só é permitida em contas com espaço de nomes hierárquico ativado. Aplica-se à versão de serviço 2020-02-10 e posterior.

Pedir

O Set Blob Expiry pedido pode ser construído da seguinte forma. Recomendamos que utilize HTTPS. Substitua myaccount pelo nome da sua conta de armazenamento:

URI do pedido de método PUT	Versão HTTP
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=expiry`	HTTP/1.1

URI do Serviço de Armazenamento Emulado

Quando estiver a fazer um pedido contra o serviço de armazenamento emulado, especifique o nome do anfitrião do emulador e a porta de Armazenamento de Blobs como 127.0.0.1:10000, seguido do nome da conta de armazenamento emulada:

URI do pedido de método PUT	Versão HTTP
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=expiry`	HTTP/1.1

Para obter mais informações, veja Utilizar o emulador do Azurite para o desenvolvimento local do Armazenamento do Azure.

Parâmetros URI

Pode especificar os seguintes parâmetros adicionais no URI do pedido:

Parâmetro	Description
`timeout`	Opcional. O `timeout` parâmetro é expresso em segundos. Para obter mais informações, veja Definir tempos limite para operações de Armazenamento de Blobs.

Cabeçalhos do pedido

Os cabeçalhos de pedido obrigatórios e opcionais estão descritos na seguinte tabela:

Cabeçalho do pedido	Description
`Authorization`	Obrigatório. Especifica o esquema de autenticação, o nome da conta e a assinatura. Veja Autenticação dos serviços de Armazenamento do Azure para obter mais informações.
`Date` ou `x-ms-date`	Obrigatório. Especifica a Hora Universal Coordenada (UTC) do pedido. Para obter mais informações, veja Autenticação para os serviços de Armazenamento do Azure.
`x-ms-version`	Necessário para todos os pedidos autenticados. Especifica a versão da operação a utilizar para este pedido. Para obter mais informações, veja Controlo de versões dos serviços de Armazenamento do Azure.
`x-ms-lease-id:<ID>`	Necessário se o blob tiver uma concessão ativa. Para efetuar esta operação num blob com uma concessão ativa, especifique o ID de concessão válido para este cabeçalho.
`x-ms-expiry-option`	Obrigatório. Para especificar a opção de data de expiração do pedido, consulte ExpiryOption.
`x-ms-expiry-time`	Opcional. A hora em que o ficheiro está definido para expirar. O formato da data de expiração varia de acordo `x-ms-expiry-option`com . Para obter mais informações, consulte ExpiryOption.
`x-ms-client-request-id`	Opcional. Fornece um valor opaco gerado pelo cliente com um limite de carateres de 1 kibibyte (KiB) que é registado nos registos quando o registo é configurado. Recomendamos vivamente que utilize este cabeçalho para correlacionar as atividades do lado do cliente com os pedidos que o servidor recebe. Para obter mais informações, veja Monitorizar Armazenamento de Blobs do Azure.

ExpiryOption

Pode enviar os seguintes valores como cabeçalho x-ms-expiry-option . Este cabeçalho não é sensível a maiúsculas e minúsculas.

Opção de expiração	Description
`RelativeToCreation`	Define a data de expiração relativamente à hora de criação do ficheiro. `x-ms-expiry-time` tem de ser especificado como o número de milissegundos a decorrer desde o momento da criação.
`RelativeToNow`	Define a data de expiração relativamente à hora atual. `x-ms-expiry-time` tem de ser especificado como o número de milissegundos a decorrer a partir do momento atual.
`Absolute`	`x-ms-expiry-time` tem de ser especificado como uma hora absoluta, no formato RFC 1123.
`NeverExpire`	Define o ficheiro para nunca expirar ou remove a data de expiração atual. `x-ms-expiry-time` não pode ser especificado.

Corpo do pedido

O corpo do pedido para este pedido está vazio.

Pedido de exemplo

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=expiry HTTP/1.1  
  
Request Headers:  
x-ms-version: 2020-02-10  
x-ms-date: Sun, 25 Sep 2020 14:37:35 GMT
x-ms-expiry-option: RelativeTonow
x-ms-expiry-time: 30000  
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=

Resposta

A resposta inclui um código de estado HTTP e um conjunto de cabeçalhos de resposta.

Código de estado

Uma operação bem-sucedida devolve o código de estado 200 (OK).

Para obter mais informações sobre códigos de estado, veja Códigos de estado e de erro.

Cabeçalhos de resposta

A resposta para esta operação inclui os seguintes cabeçalhos. 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 do protocolo HTTP/1.1.

Cabeçalho de resposta	Descrição
`ETag`	Contém um valor que representa a versão do ficheiro. O valor está entre aspas.
`Last-Modified`	Devolve a data e hora em que o diretório foi modificado pela última vez. O formato de data segue RFC 1123. Para obter mais informações, veja Representar valores de data/hora em cabeçalhos. Qualquer operação que modificou o diretório ou as respetivas propriedades atualiza a hora da última modificação. As operações em ficheiros não afetam a última hora modificada do diretório.
`x-ms-request-id`	Identifica exclusivamente o pedido que foi feito e pode ser utilizado para resolver o pedido. Para obter mais informações, veja Resolver problemas de operações da API.
`x-ms-version`	Indica a versão do Armazenamento de Blobs que foi utilizada para executar o pedido.
`Date`	Um valor de data/hora UTC gerado pelo serviço, que indica a hora em que a resposta foi iniciada.

Resposta de amostra

Response Status:  
HTTP/1.1 200 OK  
  
Response Headers:  
Date: Sun, 25 Sep 2011 23:47:09 GMT  
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. Pode autorizar a Set Blob Expiry operação conforme descrito abaixo.

Importante

A Microsoft recomenda a utilização de Microsoft Entra ID com identidades geridas para autorizar pedidos para o Armazenamento do Azure. Microsoft Entra ID fornece segurança e facilidade de utilização superiores em comparação com a autorização de Chave Partilhada.

O Armazenamento do Azure suporta a utilização de Microsoft Entra ID para autorizar pedidos a dados de blobs. Com Microsoft Entra ID, pode utilizar o controlo de acesso baseado em funções do Azure (RBAC do Azure) para conceder permissões a um principal de segurança. O principal de segurança pode ser um utilizador, grupo, principal de serviço de aplicação ou identidade gerida do Azure. O principal de segurança é autenticado por Microsoft Entra ID para devolver um token OAuth 2.0. Em seguida, o token pode ser utilizado para autorizar um pedido contra o serviço Blob.

Para saber mais sobre a autorização através de Microsoft Entra ID, veja Autorizar o acesso a blobs com Microsoft Entra ID.

Permissões

Abaixo estão listadas as ações RBAC necessárias para que um utilizador Microsoft Entra, grupo, identidade gerida ou principal de serviço chame a Set Blob Expiry operação e a função RBAC do Azure com menos privilégios que inclua esta ação:

Ação RBAC do Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Função incorporada com menos privilégios:Contribuidor de Dados do Blob de Armazenamento

Para saber mais sobre como atribuir funções com o RBAC do Azure, veja Atribuir uma função do Azure para acesso a dados de blobs.

Uma assinatura de acesso partilhado (SAS) fornece acesso delegado seguro aos recursos numa conta de armazenamento. Com uma SAS, tem controlo granular sobre como um cliente pode aceder aos dados. Pode especificar o recurso a que o cliente pode aceder, que permissões têm para esses recursos e quanto tempo a SAS é válida.

A Set Blob Expiry operação suporta três tipos de assinaturas de acesso partilhado: SAS de delegação de utilizador, SAS de serviço e SAS de conta.

Como melhor prática de segurança, recomendamos que utilize Microsoft Entra credenciais em vez da chave da conta de armazenamento, o que pode ser mais facilmente comprometido. Se a estrutura da aplicação exigir assinaturas de acesso partilhado, utilize Microsoft Entra credenciais para criar uma SAS de delegação de utilizador, sempre que possível.

Quando o acesso à Chave Partilhada não for permitido para a conta de armazenamento, não será permitido um token de SAS de serviço ou um token de SAS de conta num pedido para o Armazenamento de Blobs. Para saber mais, veja Compreender como a desativação da Chave Partilhada afeta os tokens de SAS.

SAS de delegação de utilizador

Uma SAS de delegação de utilizador é protegida com credenciais Microsoft Entra e também pelas permissões especificadas para a SAS.

Chamar a Set Blob Expiry operação com um token de SAS delegado a um contentor ou recurso de blob requer a permissão de Escrita (w) como parte do token de SAS de delegação de utilizador.

Para saber mais sobre a SAS de delegação de utilizador, veja Create uma SAS de delegação de utilizador.

SAS de Serviço

Uma SAS de serviço é protegida com a chave da conta de armazenamento. Uma SAS de serviço delega o acesso a um recurso num único serviço de Armazenamento do Azure, como o armazenamento de blobs.

Chamar a Set Blob Expiry operação com um token de SAS delegado a um contentor ou recurso de blob requer a permissão de Escrita (w) como parte do token de SAS do serviço.

Para saber mais sobre a SAS do serviço, veja Create uma SAS de serviço.

SAS de Conta

Uma SAS de conta é protegida com a chave da conta de armazenamento. Uma conta SAS delega o acesso aos recursos em um ou mais dos serviços de armazenamento. Todas as operações disponíveis através de um serviço ou saS de delegação de utilizador também estão disponíveis através de uma SAS de conta.

A tabela seguinte indica o tipo de recurso assinado e as permissões assinadas a especificar ao delegar o acesso:

Operação	Serviço assinado	Tipo de recurso assinado	Permissão assinada
Definir Expiração do Blob	Blob (b)	Objeto (o)	Escrever (w)

Para saber mais sobre a SAS da conta, veja Create uma SAS de conta.

A Set Blob Expiry operação suporta a autorização de Chave Partilhada. A autorização com chaves de conta não é recomendada para a maioria dos cenários, uma vez que é menos segura.

A Microsoft recomenda a desativação da autorização de Chave Partilhada para a conta de armazenamento sempre que possível. Para obter mais informações, veja Impedir a autorização com a Chave Partilhada.

Observações

A semântica para definir uma data de expiração num blob é a seguinte:

Set Expiry só pode ser definido num ficheiro e não num diretório.
Set Expiry com um expiryTime no passado não é permitido.
ExpiryTime não pode ser especificado com um expiryOption valor de Never.

Nota

Não é possível restaurar um ficheiro expirado com a funcionalidade de eliminação recuperável de blobs. Mesmo que tenha ativado a eliminação recuperável para a conta, um ficheiro expirado não se torna um blob eliminado de forma recuperável quando expira. Apenas os ficheiros eliminados podem tornar-se ficheiros eliminados de forma recuperável.

Faturação

Os pedidos de preços podem ter origem em clientes que utilizam APIs de Armazenamento de Blobs, diretamente através da API REST do Armazenamento de Blobs ou a partir de uma biblioteca de cliente do Armazenamento do Azure. Estes pedidos acumulam custos por transação. O tipo de transação afeta a forma como a conta é cobrada. Por exemplo, as transações de leitura acumulam-se numa categoria de faturação diferente das transações de escrita. A tabela seguinte mostra a categoria de faturação dos Set Blob Expiry pedidos com base no tipo de conta de armazenamento:

Operação	Tipo de conta de armazenamento	Categoria de faturação
Definir Expiração do Blob	Blob de blocos Premium Standard para fins gerais v2	Outras operações
Definir Expiração do Blob	Standard para fins gerais v1	Operações de escrita

Para saber mais sobre os preços da categoria de faturação especificada, veja Preços do Armazenamento de Blobs do Azure.

Partilhar via