Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
Une politique WORM (écriture unique, lecture multiple) au niveau de la version est un type de politique d'immuabilité qui peut être définie au niveau du compte, du conteneur ou de la version. Pour en savoir plus sur le stockage immuable de Stockage Blob Azure, consultez Stocker des données blob stratégiques à l’aide d’un stockage immuable à l’état WORM.
Disponibilité
Les stratégies d’immuabilité au niveau de version (VLW) sont prises en charge au niveau du compte pour les nouveaux comptes, et au niveau du conteneur et du blob pour les comptes et conteneurs nouveaux et existants. Ces stratégies sont prises en charge pour les comptes v2 universels et les comptes d’objets blob de blocs premium. Cette fonctionnalité n’est pas prise en charge sur les comptes d’espace de noms hiérarchiques.
Dépendance de version
Les stratégies de niveau version requièrent l’activation du contrôle de version des objets blob pour le compte de stockage. Pour savoir comment activer le contrôle de version des objets blob, consultez Activer et gérer le contrôle de version des objets blob. N’oubliez pas que l’activation du contrôle de version peut avoir un impact sur la facturation. Pour en savoir plus, consultez la section Tarification et facturation pour le contrôle de version des objets blob.
Une fois le contrôle de version activé, lorsqu’un objet blob est chargé pour la première fois, cette version de l’objet blob est la version actuelle. Chaque fois que l’objet blob est remplacé, une nouvelle version est créée qui stocke l’état précédent de l’objet blob. Lorsque vous supprimez la version actuelle d’un objet blob, la version actuelle devient une version précédente et est conservée jusqu’à la suppression explicite. Une version de BLOB précédente possède la politique de rétention temporelle qui était en vigueur lorsque la version actuelle est devenue une version antérieure.
Si une stratégie par défaut est en vigueur pour le compte de stockage ou le conteneur, lorsqu’une opération de remplacement crée une version précédente, la nouvelle version actuelle hérite de la stratégie par défaut pour le compte ou le conteneur.
Chaque version peut avoir une seule stratégie de rétention basée sur le temps configurée. Une version peut également avoir une conservation légale configurée.
Pour savoir comment configurer des stratégies de rétention temporelles au niveau des versions, consultez Configurer des stratégies d’immuabilité pour les versions de blob.
Activation et définition d’une stratégie
L’utilisation de stratégies immuables avec WORM au niveau de la version est un processus en deux étapes. Tout d’abord, activez l’immuabilité au niveau de la version. Vous pouvez ensuite définir des stratégies d’immuabilité au niveau de la version.
Pour définir une stratégie au niveau du compte de stockage, vous devez d’abord activer WORM au niveau de la version sur le compte de stockage. Vous ne pouvez le faire qu’au moment de la création du compte. Il n'y a pas d'option pour activer WORM au niveau de la version pour les comptes préexistants.
Pour définir une stratégie au niveau du conteneur, vous devez d'abord activer WORM au niveau de la version soit sur le compte, soit sur le conteneur.
Si vous envisagez d’activer WORM au niveau de la version sur un conteneur, Microsoft vous recommande de l’activer au moment de la création du conteneur. Toutefois, vous pouvez migrer un conteneur avec WORM de niveau autre que version vers un conteneur avec WORM de niveau version. Si vous choisissez de ne pas migrer un conteneur, vous pouvez toujours définir une stratégie WORM au niveau du conteneur sur ce conteneur, mais l’option permettant de définir des stratégies au niveau de l’objet blob ne sera pas disponible sur ce conteneur.
Pour définir une stratégie au niveau de l’objet blob, vous devez activer WORM de niveau version sur le compte ou sur le conteneur. Il n’existe aucune option permettant d’activer le WORM de niveau version au niveau de l’objet blob ; il doit être hérité.
Migration
Les conteneurs existants peuvent prendre en charge l’immuabilité au niveau de la version, mais doivent d’abord subir un processus de migration. Ce processus peut prendre un certain temps. Une fois activé, la prise en charge de WORM au niveau de la version pour ce conteneur ne peut pas être supprimée. Vous pouvez migrer dix conteneurs à la fois par compte de stockage. Le temps nécessaire à la migration dépend principalement de la quantité d’objets blob dans le conteneur. Les conteneurs avec un grand nombre de blobs mettront beaucoup plus de temps à migrer. Pour plus d’informations sur la migration d’un conteneur pour prendre en charge l’immuabilité au niveau de la version, consultez Migrer un conteneur existant pour prendre en charge l’immuabilité au niveau de la version.
Configurer une stratégie sur la version actuelle
Après avoir activé la prise en charge de l’immuabilité au niveau de la version pour un compte de stockage ou un conteneur, vous avez la possibilité de configurer une stratégie de rétention basée sur le temps par défaut pour le compte ou le conteneur. Lorsque vous configurez une stratégie de rétention basée sur le temps par défaut pour le compte ou le conteneur, puis chargez un objet blob, l’objet blob hérite de cette stratégie par défaut. Vous pouvez également choisir de remplacer la stratégie par défaut pour n’importe quel objet blob lors du chargement en configurant une stratégie personnalisée pour cet objet blob.
Si la stratégie de rétention basée sur le temps par défaut pour le compte ou le conteneur est déverrouillée, la version actuelle d’un objet blob qui hérite de la stratégie par défaut aura également une stratégie déverrouillée. Une fois qu’un objet blob individuel est chargé, vous pouvez raccourcir ou prolonger la période de rétention de la stratégie appliquée à la version actuelle de l’objet blob, ou supprimer cette version actuelle. Vous pouvez également verrouiller la stratégie pour la version actuelle, même si la stratégie par défaut sur le compte ou le conteneur reste déverrouillée.
Si la stratégie de rétention basée sur le temps par défaut pour le compte ou le conteneur est verrouillée, la version actuelle d’un objet blob qui hérite de la stratégie par défaut aura également une stratégie verrouillée. Toutefois, si vous remplacez la stratégie par défaut lorsque vous chargez un objet blob en définissant une stratégie uniquement pour cet objet blob, la stratégie de cet objet blob reste déverrouillée jusqu’à ce que vous le verrouillez explicitement. Lorsque la stratégie sur la version actuelle est verrouillée, vous pouvez étendre l’intervalle de rétention, mais vous ne pouvez pas supprimer la stratégie ni raccourcir l’intervalle de rétention.
S’il n’existe aucune stratégie par défaut configurée pour le compte de stockage ou le conteneur, vous pouvez charger un objet blob avec une stratégie personnalisée ou sans stratégie.
Si la stratégie par défaut sur un compte de stockage ou un conteneur est modifiée, les stratégies sur les objets de ce conteneur restent inchangées, même si ces stratégies ont été héritées de la stratégie par défaut.
Le tableau suivant présente les différentes options disponibles pour définir une stratégie de rétention limitée dans le temps sur un objet blob lors du chargement :
| État de la stratégie par défaut sur le compte ou le conteneur | Télécharger un objet blob avec la stratégie par défaut | Télécharger un objet blob avec une stratégie personnalisée | Télécharger un objet blob sans stratégie |
|---|---|---|---|
| Politique par défaut sur le compte ou le conteneur (déverrouillé) | L’objet blob est téléchargé avec la stratégie déverrouillée par défaut | L’objet blob est téléchargé avec la stratégie déverrouillée personnalisée | L’objet blob est téléchargé sans aucune stratégie |
| Stratégie par défaut pour le compte ou le conteneur (verrouillé) | L’objet blob est téléchargé avec la stratégie verrouillée par défaut | L’objet blob est téléchargé avec la stratégie déverrouillée personnalisée | L’objet blob est téléchargé sans aucune stratégie |
| Aucune stratégie par défaut sur un compte ou un conteneur | N/A | L’objet blob est téléchargé avec la stratégie déverrouillée personnalisée | L’objet blob est téléchargé sans aucune stratégie |
Configurer une politique sur une ancienne version
Lorsque le contrôle de version est activé, une opération d’écriture ou de suppression dans un objet blob crée une nouvelle version précédente de cet objet blob qui enregistre l’état de l’objet blob avant l’opération. Par défaut, une version précédente possède la stratégie de rétention basée sur le temps qui était en vigueur pour la version actuelle, le cas échéant, lorsque la version actuelle est devenue une version précédente. La nouvelle version actuelle hérite de la stratégie sur le conteneur, le cas échéant.
Si la stratégie héritée par une version précédente est déverrouillée, l’intervalle de rétention peut être raccourci ou tronqué, ou la stratégie peut être supprimée. La stratégie sur une version précédente peut également être verrouillée pour cette version, même si la stratégie sur la version actuelle est déverrouillée.
Si la politique héritée d'une version précédente est verrouillée, alors l’intervalle de rétention peut être prolongé. La stratégie ne peut pas être supprimée, ni l’intervalle de rétention ne peut pas être raccourci. Si aucune stratégie n’est configurée sur la version actuelle, la version précédente n’hérite d’aucune stratégie.
Vous pouvez configurer une stratégie personnalisée pour la version. Si la stratégie sur une version actuelle est modifiée, les stratégies sur les versions précédentes existantes restent inchangées, même si la stratégie a été héritée d’une version actuelle.
Suppression
Une fois qu’un compte ou un conteneur est activé pour une stratégie immuable, il ne peut pas être supprimé tant qu’il n’est pas vide. Il est important de noter que peu importe si une stratégie immuable a été définie sur un compte WORM ou sur un conteneur au niveau de la version ; ce qui compte, c'est si elle est activée pour une politique. Une fois l’opération terminée, le compte ou le conteneur doit être vide pour être supprimé.
Vous pouvez supprimer un conteneur activé pour une stratégie immuable uniquement à l’aide d’opérations de plan de contrôle. Toutes ces demandes sont envoyées à l’URL Azure Resource Manager. Par exemple, la commande PowerShell Remove-AzRmStorageContainer utilise une opération de plan de contrôle pour supprimer un conteneur. En revanche, la commande Remove-AzStorageContainer tente d’utiliser une opération de plan de données, qui ne réussit pas. De même, la commande Azure CLI az storage container-rm delete utilise une opération de plan de contrôle, tandis qu’az storage container delete s’appuie sur une opération de plan de données. Vous pouvez également supprimer un conteneur via le portail Azure, car il effectue la tâche à l’aide d’une opération de plan de contrôle.
Scénarios
| Scénario | Opérations interdites | Protection des objets blob | Protection des conteneurs | Protection du compte |
|---|---|---|---|---|
| Une version blob est protégée par une stratégie de rétention active et/ou une conservation légale est en vigueur | Supprimer le Blob, Définir les métadonnées du Blob et Déposer une page | La version blob ne peut pas être supprimée. Les métadonnées utilisateur ne peuvent pas être écrites. Le remplacement d’un objet blob avec Put Blob, Put Block List ou Copy Blob crée une nouvelle version1. |
La suppression du conteneur échoue si au moins un blob existe dans le conteneur, que la stratégie soit verrouillée ou déverrouillée. | La suppression du compte de stockage échoue s’il existe au moins un conteneur avec un stockage immuable au niveau de la version activé ou s’il est activé pour le compte. |
| Une version blob est protégée par une stratégie de rétention expirée et/ou une conservation légale est en vigueur | Set Blob Metadata et Put Page | Une version blob est protégée par une stratégie de rétention expirée et/ou une conservation légale est en vigueur | La version du blob de données peut être supprimée. Le remplacement d’un objet blob avec Put Blob, Put Block List ou Copy Blob crée une nouvelle version1. |
La suppression du compte de stockage échoue si au moins un conteneur contient une version blob avec une stratégie de rétention basée sur le temps verrouillée. Les stratégies déverrouillées n’assurent pas de protection contre la suppression. |
1 Les versions d’objets blob sont toujours immuables pour le contenu. Si le contrôle de version est activé pour le compte de stockage, une opération d’écriture dans un objet blob de blocs crée une nouvelle version, à l’exception de l’opération Put Block.
Limites
Il ne peut y avoir que 10 000 conteneurs définis avec des stratégies de rétention basées sur le temps uniques dans un compte ; Toutefois, vous pouvez définir une stratégie au niveau du compte qui sera héritée par plus de 10 000 conteneurs.