Définir l’expiration des objets blob

Article
02/12/2024

L’opération Set Blob Expiry définit une date d’expiration sur un objet blob existant. Cette opération est autorisée uniquement sur les comptes hiérarchiques avec espace de noms. S’applique au service version 2020-02-10 et ultérieure.

Requête

La demande Set Blob Expiry peut être construite comme indiqué ci-dessous. Nous vous recommandons d’utiliser HTTPS. Remplacez moncompte par le nom de votre compte de stockage :

URI de demande de méthode PUT	Version HTTP
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=expiry`	HTTP/1.1

URI du service de stockage émulé

Lorsque vous effectuez une demande auprès du service de stockage émulé, spécifiez le nom d’hôte de l’émulateur et le port Stockage Blob comme 127.0.0.1:10000, suivi du nom du compte de stockage émulé :

URI de demande de méthode PUT	Version HTTP
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=expiry`	HTTP/1.1

Pour plus d’informations, consultez Utiliser l’émulateur Azurite à des fins de développement local pour Stockage Azure.

Paramètres URI

Vous pouvez spécifier les paramètres supplémentaires suivants dans l’URI de requête :

Paramètre	Description
`timeout`	facultatif. Le paramètre `timeout` est exprimé en secondes. Pour plus d’informations, consultez Définir des délais d’attente pour les opérations de stockage Blob.

En-têtes de requête

Les en-têtes de requête obligatoires et facultatifs sont décrits dans le tableau suivant :

En-tête de requête	Description
`Authorization`	Obligatoire. Spécifie le schéma d'authentification, le nom du compte et la signature. Pour plus d’informations, consultez Authentification pour les services stockage Azure .
`Date` ou `x-ms-date`	Obligatoire. Spécifie la date/heure en temps universel coordonné (UTC) pour la requête. Pour plus d’informations, consultez Authentification pour les services stockage Azure.
`x-ms-version`	Obligatoire pour toutes les demandes authentifiées. Spécifie la version de l'opération à utiliser pour cette demande. Pour plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft Azure.
`x-ms-lease-id:<ID>`	Obligatoire si l'objet blob a un bail actif. Pour effectuer cette opération sur un objet blob avec un bail actif, spécifiez l'ID de bail valide pour cet en-tête.
`x-ms-expiry-option`	Obligatoire. Pour spécifier l’option de date d’expiration de la demande, consultez ExpiryOption.
`x-ms-expiry-time`	facultatif. Heure à laquelle le fichier est défini pour expirer. Le format de la date d’expiration varie en fonction de `x-ms-expiry-option`. Pour plus d’informations, consultez ExpiryOption.
`x-ms-client-request-id`	facultatif. Fournit une valeur opaque générée par le client avec une limite de caractères de 1 kibioctet (Kio) enregistrée dans les journaux lors de la configuration de la journalisation. Nous vous recommandons vivement d’utiliser cet en-tête pour mettre en corrélation les activités côté client avec les demandes reçues par le serveur. Pour plus d’informations, consultez Surveiller Stockage Blob Azure.

ExpiryOption

Vous pouvez envoyer les valeurs suivantes en tant qu’en-tête x-ms-expiry-option . Cet en-tête ne respecte pas la casse.

Option Expiration	Description
`RelativeToCreation`	Définit la date d’expiration par rapport à l’heure de création du fichier. `x-ms-expiry-time` doit être spécifié comme le nombre de millisecondes à s’écouler à partir du moment de la création.
`RelativeToNow`	Définit la date d’expiration par rapport à l’heure actuelle. `x-ms-expiry-time` doit être spécifié comme le nombre de millisecondes à écouler à partir de l’heure actuelle.
`Absolute`	`x-ms-expiry-time` doit être spécifié en tant qu’heure absolue, au format RFC 1123.
`NeverExpire`	Définit le fichier pour qu’il n’expire jamais ou supprime la date d’expiration actuelle. `x-ms-expiry-time` ne doit pas être spécifié.

Corps de la demande

Le corps de la demande pour cette demande est vide.

Exemple de requête

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=

response

La réponse inclut un code d'état HTTP et un ensemble d'en-têtes de réponse.

Code d’état

Une opération réussie envoie le code d'état 200 (OK).

Pour plus d’informations sur les codes status, consultez Codes d’état et d’erreur.

En-têtes de réponse

La réponse de l'opération inclut les en-têtes suivants. La réponse peut aussi inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification du protocole HTTP/1.1.

En-tête de réponse	Description
`ETag`	Contient une valeur qui représente la version du fichier. La valeur est placée entre guillemets.
`Last-Modified`	Retourne la date et l’heure de la dernière modification du répertoire. Le format de date est conforme à la RFC 1123. Pour plus d’informations, consultez Représenter les valeurs de date/heure dans les en-têtes. N'importe quelle opération qui modifie le répertoire ou ses propriétés entraîne la mise à jour de l'heure de la dernière modification. Les opérations sur les fichiers n’affectent pas l’heure de dernière modification du répertoire.
`x-ms-request-id`	Identifie de manière unique la demande qui a été effectuée et peut être utilisée pour résoudre la demande. Pour plus d’informations, consultez Résoudre les problèmes liés aux opérations d’API.
`x-ms-version`	Indique la version du Stockage Blob qui a été utilisée pour exécuter la demande.
`Date`	Valeur de date/heure UTC générée par le service, qui indique l’heure à laquelle la réponse a été lancée.

Exemple de réponse

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

Autorisation

Une autorisation est requise lors de l’appel d’une opération d’accès aux données dans Stockage Azure. Vous pouvez autoriser l’opération Set Blob Expiry comme décrit ci-dessous.

Important

Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour autoriser les demandes à Stockage Azure. Microsoft Entra ID offre une sécurité et une facilité d’utilisation supérieures par rapport à l’autorisation de clé partagée.

Stockage Azure prend en charge l’utilisation de Microsoft Entra ID pour autoriser les demandes de données blob. Avec Microsoft Entra ID, vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour accorder des autorisations à un principal de sécurité. Le principal de sécurité peut être un utilisateur, un groupe, un principal de service d’application ou une identité managée Azure. Le principal de sécurité est authentifié par Microsoft Entra ID pour retourner un jeton OAuth 2.0. Le jeton peut ensuite être utilisé pour autoriser une requête auprès du service BLOB.

Pour en savoir plus sur l’autorisation à l’aide de Microsoft Entra ID, consultez Autoriser l’accès aux objets blob à l’aide de Microsoft Entra ID.

Autorisations

Vous trouverez ci-dessous l’action RBAC nécessaire pour qu’un utilisateur, un groupe, une identité managée ou un principal de service Microsoft Entra appelle l’opérationSet Blob Expiry, ainsi que le rôle RBAC Azure intégré le moins privilégié qui inclut cette action :

Action RBAC Azure :Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Rôle intégré le moins privilégié :Contributeur aux données blob de stockage

Pour en savoir plus sur l’attribution de rôles à l’aide d’Azure RBAC, consultez Attribuer un rôle Azure pour l’accès aux données d’objets blob.

Une signature d’accès partagé (SAP) fournit un accès délégué sécurisé aux ressources d’un compte de stockage. Avec une SAP, vous disposez d’un contrôle granulaire sur la façon dont un client peut accéder aux données. Vous pouvez spécifier la ressource à laquelle le client peut accéder, les autorisations dont il dispose sur ces ressources et la durée de validité de la SAP.

L’opération Set Blob Expiry prend en charge trois types de signatures d’accès partagé : sas de délégation d’utilisateur, SAP de service et SAP de compte.

Comme meilleure pratique de sécurité, nous vous recommandons d’utiliser Microsoft Entra informations d’identification plutôt que la clé de compte de stockage, qui peut être plus facilement compromise. Si la conception de votre application nécessite des signatures d’accès partagé, utilisez Microsoft Entra informations d’identification pour créer une sap de délégation d’utilisateur, si possible.

Lorsque l’accès à la clé partagée est interdit pour le compte de stockage, un jeton SAP de service ou un jeton SAP de compte ne sont pas autorisés lors d’une demande adressée au stockage Blob. Pour plus d’informations, consultez Comprendre comment l’interdiction de la clé partagée affecte les jetons SAP.

SAP de délégation d’utilisateur

Une sap de délégation d’utilisateur est sécurisée avec des informations d’identification Microsoft Entra ainsi que par les autorisations spécifiées pour la sap.

L’appel de l’opération à l’aide Set Blob Expiry d’un jeton SAP délégué à un conteneur ou à une ressource d’objet blob nécessite l’autorisation Write (w) dans le cadre du jeton SAP de délégation utilisateur.

Pour en savoir plus sur la sap de délégation d’utilisateur, consultez Create une SAP de délégation d’utilisateur.

SAP de service

Une SAP de service est sécurisée à l’aide de la clé de compte de stockage. Une sap de service délègue l’accès à une ressource dans un seul service Stockage Azure, tel que le stockage blob.

L’appel de l’opération à l’aide Set Blob Expiry d’un jeton SAP délégué à un conteneur ou à une ressource blob nécessite l’autorisation Write (w) dans le cadre du jeton SAP de service.

Pour en savoir plus sur la SAP de service, consultez Create une SAP de service.

SAP de compte

Une SAP de compte est sécurisée à l’aide de la clé de compte de stockage. Une SAP de compte délègue l’accès aux ressources d’un ou plusieurs des services de stockage. Toutes les opérations disponibles via une SAP de service ou de délégation d’utilisateur sont également disponibles via une SAP de compte.

Le tableau suivant indique le type de ressource signé et les autorisations signées à spécifier lors de la délégation de l’accès :

Opération	Service signé	Type de ressource signé	Autorisation signée
Définir l’expiration des objets blob	Objet blob (b)	Objet (o)	Écriture (w)

Pour en savoir plus sur la SAP de compte, consultez Create une SAP de compte.

L’opération Set Blob Expiry prend en charge l’autorisation de clé partagée. L’autorisation avec des clés de compte n’est pas recommandée dans la plupart des scénarios, car elle est moins sécurisée.

Microsoft recommande d’interdire l’autorisation de clé partagée pour le compte de stockage lorsque cela est possible. Pour plus d’informations, consultez Empêcher l’autorisation avec une clé partagée.

Remarques

La sémantique permettant de définir une date d’expiration sur un objet blob est la suivante :

Set Expiry ne peut être défini que sur un fichier et non sur un répertoire.
Set Expiry avec un expiryTime dans le passé n’est pas autorisé.
ExpiryTimene peut pas être spécifié avec la expiryOption valeur .Never

Notes

Un fichier expiré ne peut pas être restauré à l’aide de la fonctionnalité de suppression réversible d’objet blob. Même si vous avez activé la suppression réversible pour le compte, un fichier expiré ne devient pas un objet blob supprimé de manière réversible à l’expiration. Seuls les fichiers supprimés peuvent devenir des fichiers supprimés de manière réversible.

Facturation

Les demandes de tarification peuvent provenir de clients qui utilisent des API Stockage Blob, soit directement via l’API REST Stockage Blob, soit à partir d’une bibliothèque cliente stockage Azure. Ces demandes cumulent des frais par transaction. Le type de transaction affecte la façon dont le compte est facturé. Par exemple, les transactions de lecture sont comptabilisées dans une catégorie de facturation différente de celle des transactions en écriture. Le tableau suivant montre la catégorie de facturation pour Set Blob Expiry les demandes en fonction du type de compte de stockage :

Opération	Type de compte de stockage	Catégorie de facturation
Définir l’expiration des objets blob	Objet blob de blocs Premium Usage général v2 Standard	Autres opérations
Définir l’expiration des objets blob	Usage général v1 standard	Opérations d’écriture

Pour en savoir plus sur la tarification de la catégorie de facturation spécifiée, consultez Stockage Blob Azure Tarification.

Partager via