Définir la stratégie d’immuabilité des objets blob

Article
02/03/2024

L’opération Set Blob Immutability Policy définit la stratégie d’immuabilité sur un objet blob. Cette opération ne met pas à jour l’ETag de l’objet blob. Cette API est disponible à partir de la version 2020-06-12.

Requête

La demande Set Blob Immutability Policy peut être construite comme indiqué ci-dessous. Nous vous recommandons d’utiliser HTTPS. Remplacez myaccount par le nom de votre compte de stockage et myblob par le nom de l’objet blob pour lequel la stratégie d’immuabilité doit être modifiée.

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

Paramètres URI

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

Paramètre	Description
`snapshot`	facultatif. Le paramètre instantané est une valeur opaque `DateTime` qui, lorsqu’il est présent, spécifie l’objet blob instantané sur lequel définir un niveau. Pour plus d’informations sur l’utilisation des instantanés d’objets blob, consultez Create un instantané d’un objet blob
`versionid`	Facultatif pour les versions 2019-12-12 et ultérieures. Le `versionid` paramètre est une valeur opaque `DateTime` qui, lorsqu’il est présent, spécifie la version de l’objet blob sur laquelle définir un niveau.
`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’autorisation, le nom du compte de stockage et la signature. Pour plus d’informations, consultez Autoriser les requêtes auprès du 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 Autoriser les requêtes auprès du Stockage Azure.
`x-ms-immutability-policy-until-date`	Obligatoire. Indique la rétention jusqu’à la date à définir sur l’objet blob. Il s’agit de la date jusqu’à laquelle l’objet blob peut être protégé contre la modification ou la suppression. Pour le stockage d’objets blob ou le compte v2 à usage général, les valeurs valides sont au format RFC1123. Les heures passées ne sont pas valides.
`x-ms-immutability-policy-mode`	facultatif. Si elle n’est pas spécifiée, la valeur par défaut est `Unlocked`. Indique le mode de stratégie d’immuabilité à définir sur l’objet blob. Pour le stockage d’objets blob ou le compte v2 à usage général, les valeurs valides sont `Unlocked`/`Locked`. `unlocked` indique que l’utilisateur peut modifier la stratégie en augmentant ou en diminuant la rétention jusqu’à la date. `locked` indique que ces actions sont interdites.
`x-ms-version`	Obligatoire pour toutes les demandes autorisé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-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 que le serveur reçoit. Pour plus d’informations, consultez Surveiller Stockage Blob Azure.

Cette opération prend également en charge l’utilisation d’en-têtes conditionnels pour définir l’objet blob uniquement si une condition spécifiée est remplie. Pour plus d’informations, consultez Spécifier des en-têtes conditionnels pour les opérations de stockage Blob.

Corps de la demande

Aucun.

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 à cette opération inclut les en-têtes ci-dessous. 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
`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 de Stockage Blob qui a été utilisée pour exécuter la demande. Retourné pour les demandes effectuées sur la version 2009-09-19 et ultérieure.
`x-ms-client-request-id`	Peut être utilisé pour résoudre les problèmes liés aux demandes et aux réponses correspondantes. La valeur de cet en-tête est égale à la valeur de l’en-tête `x-ms-client-request-id` s’il est présent dans la requête et que la valeur ne contient pas plus de 1 024 caractères ASCII visibles. Si l’en-tête `x-ms-client-request-id` n’est pas présent dans la demande, il ne sera pas présent dans la réponse.
`x-ms-immutability-policy-until-date`	Indique la date de rétention jusqu’à définir sur l’objet blob. Il s’agit de la date jusqu’à laquelle l’objet blob peut être protégé contre la modification ou la suppression.
`x-ms-immutability-policy-mode`	Indique le mode de stratégie d’immuabilité défini sur l’objet blob. Les valeurs sont `unlocked` et `locked`. La`unlocked` valeur indique que l’utilisateur peut modifier la stratégie en augmentant ou en diminuant la date de rétention jusqu’à , et `locked` indique que ces actions sont interdites.

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 Immutability Policy comme décrit ci-dessous.

Important

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

Le 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 Immutability Policy, 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/immutableStorage/runAsSuperUser/action
Rôle intégré le moins privilégié :Propriétaire des 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 accéder aux données 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 signature d’accès partagé.

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

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

Lorsque l’accès à la clé partagée n’est pas autorisé 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 en savoir plus, 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 signature d’accès partagé.

L’appel de l’opération à l’aide Set Blob Immutability Policy d’un jeton SAP délégué à un conteneur ou à une ressource d’objet blob nécessite l’autorisation stockage immuable (i) dans le cadre du jeton SAP de délégation d’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 de stockage Azure, tel que le stockage d’objets blob.

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 la stratégie d’immuabilité des objets blob	Blob (b)	Objet (o)	Stockage immuable (i)

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

L’opération Set Blob Immutability Policy prend en charge l’autorisation de clé partagée. L’autorisation avec des clés de compte n’est pas recommandée pour 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 définition de la stratégie d’immuabilité de l’objet blob sur un stockage d’objets blob ou un compte v2 à usage général présente les restrictions suivantes :

La définition d’une stratégie d’immuabilité sur un instantané ou une version est autorisée à compter de la version REST 2020-06-12.
Lorsque la stratégie d’immuabilité est en unlocked mode, les utilisateurs peuvent mettre à jour la rétention jusqu’à la date. Lorsque la stratégie d’immuabilité est en locked mode, les utilisateurs peuvent étendre la rétention jusqu’à la date uniquement. Le mode de stratégie d’immuabilité peut être modifié de unlocked à locked, mais pas de locked à unlocked.
Lorsqu’il existe une stratégie d’immuabilité sur un objet blob et qu’il existe également une stratégie d’immuabilité par défaut sur un conteneur ou un compte, la stratégie d’immuabilité d’objet blob a un précédent.
Pour une stratégie d’immuabilité au niveau de l’objet blob, PutBlockList/PutBlob/CopyBlob les opérations sont autorisées, car ces opérations génèrent une nouvelle version.
Lorsque la stratégie d’immuabilité est en mode, les utilisateurs peuvent supprimer la stratégie d’immuabilité à unlocked l’aide de l’API suivante :

Méthode	URI de demande	Version HTTP
`Delete`	`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=immutabilityPolicies`	HTTP/1.1

Notes

Pour plus d’informations, consultez Stockage immuable.

Facturation

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

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

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

Voir aussi

Autoriser les demandes dans le Stockage Azure
Codes d’état et d’erreur
Codes d’erreur stockage Blob
Définir des délais d’attente pour les opérations de stockage Blob

Partager via