Stratégies WORM de niveau version pour les données blob immuables
Une stratégie WORM de niveau version est un type de stratégie d’immuabilité pouvant ê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é de niveau version (VLW) sont prises en charge au niveau du compte pour les nouveaux comptes, et au niveau du conteneur et de l’objet blob pour les comptes/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 dans les comptes d’espace de noms hiérarchique.
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 blobs, consultez Activer et gérer le contrôle de version des blobs. 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é, quand 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, cette version actuelle devient une version antérieure et est conservée jusqu’à ce qu’elle soit explicitement supprimée. Une version d’objet blob antérieure possède la stratégie de rétention limitée dans le temps 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, quand une opération de remplacement crée une version antérieure, la nouvelle version actuelle hérite de la stratégie par défaut pour le compte ou le conteneur.
Une seule stratégie de rétention limitée dans le temps peut être configurée pour chaque version. Une version peut également avoir une conservation légale configurée.
Pour savoir comment configurer des stratégies de rétention au niveau de la version, consultez Configurer des stratégies d’immuabilité pour les versions d’objets blob.
Activation et définition d’une stratégie
L’utilisation de stratégies immuables avec WORM de niveau version est un processus en deux étapes. Commencez par activer l’immuabilité au niveau de la version. Vous pouvez alors 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 de niveau version sur le compte de stockage. Vous ne pouvez le faire qu’au moment de la création du compte. Aucune option ne permet d’activer WORM de niveau version pour les comptes préexistants.
Pour définir une stratégie au niveau du conteneur, vous devez d’abord activer WORM de niveau version sur le compte OU sur le conteneur.
Si vous envisagez d’activer WORM de niveau version sur un conteneur, Microsoft vous recommande de l’activer lors 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 de niveau 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. Aucune option ne permet d’activer une stratégie WORM de niveau version au niveau de l’objet blob ; elle doit être héritée.
Migration
Les conteneurs existants peuvent prendre en charge l’immuabilité de niveau version, mais doivent d’abord subir un processus de migration. Ce processus peut prendre du temps. Une fois activée, la prise en charge de WORM de niveau version pour ce conteneur ne peut pas être supprimée. Vous pouvez migrer dix conteneurs à la fois par compte de stockage. 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
Une fois que vous avez 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 limitée dans le temps par défaut pour le compte ou le conteneur. Quand vous configurez une stratégie de rétention limitée dans le temps par défaut pour le compte ou le conteneur, puis chargez un blob, celui-ci 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 limitée dans le temps par défaut pour le compte ou le conteneur est déverrouillée, la version actuelle d’un blob qui hérite de la stratégie par défaut aura également une stratégie déverrouillée. Après le chargement d’un objet blob individuel, vous pouvez raccourcir ou étendre la période de rétention de la stratégie sur la version actuelle de l’objet blob ou supprimer la 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 temporelle 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 aussi 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, alors la stratégie de cet objet blob reste déverrouillée jusqu’à ce que vous la verrouilliez explicitement. Quand la stratégie sur la version actuelle est verrouillée, vous pouvez prolonger la période de conservation, mais vous ne pouvez pas supprimer la stratégie ou raccourcir la période de conservation.
Si aucune stratégie par défaut n’est configurée pour le compte de stockage ou le conteneur, vous pouvez charger un objet blob avec une stratégie personnalisée ou sans aucune stratégie.
Si la stratégie par défaut d’un compte de stockage ou d’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 |
|---|---|---|---|
| Stratégie 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 sur 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 le compte ou le 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 stratégie sur une version précédente
Lorsque le contrôle de version est activé, une opération d’écriture ou de suppression sur un objet blob crée une nouvelle version antérieure de cet objet blob qui enregistre l’état de l’objet blob avant l’opération. Par défaut, une version antérieure possède la stratégie de rétention limitée dans le temps qui était en vigueur pour la version actuelle, le cas échéant, lorsque la version actuelle est devenue une version antérieure. 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, la période de conservation peut être réduite ou prolongée, 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 stratégie héritée par une version précédente est verrouillée, la période de conservation peut être prolongée. La stratégie ne peut pas être supprimée et la période de conservation ne peut pas être réduite. Si aucune stratégie n’est configurée sur la version actuelle, la version précédente n’hérite alors 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. La principale chose à noter est qu’il importe peu qu’une stratégie immuable ait été définie sur un compte ou un conteneur WORM de niveau version, ce qui compte, c’est s’il est activé pour une stratégie. Le cas échéant, le compte ou le conteneur doit être vide pour être supprimé.
Scénarios
| Scénario | Opérations interdites | Protection des objets blob | Protection des conteneurs | Protection des comptes |
|---|---|---|---|---|
| Une version blob est protégée par une stratégie de rétention active et/ou une conservation légale est en vigueur | Delete Blob, Set Blob Metadata et Put Page | La version blob ne peut pas être supprimée. Les métadonnées de l’utilisateur ne peuvent pas être écrites. Le remplacement d’un objet blob par 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 pour lequel le stockage immuable de niveau version est activé ou si celui-ci 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 blob peut être supprimée. Le remplacement d’un objet blob par 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 un compte de stockage, une opération d’écriture sur un objet blob de bloc crée une nouvelle version, à l’exception de l’opération Put Block.
Limites
Seuls 10 000 conteneurs peuvent être configurés avec des stratégies de rétention définies dans le temps uniques dans un compte. Toutefois, vous pouvez définir une stratégie de niveau compte qui sera héritée par plus de 10 000 conteneurs.