Stratégies WORM de niveau conteneur pour les données blob immuables
Une stratégie WORM de niveau conteneur est un type de stratégie d’immuabilité pouvant être définie au niveau du conteneur. 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 WORM de niveau conteneur (CLW) sont disponibles pour tous les conteneurs nouveaux et existants. Ces stratégies sont prises en charge pour les comptes v2 universels, d’objets blob de blocs Premium et v1 universels (hérités) ainsi que pour les comptes de stockage d’objets blob (hérités).
Conseil
Microsoft recommande de mettre à niveau les comptes v1 universels vers des comptes v2 universels pour vous permettre de tirer parti d’un plus grand nombre de fonctionnalités. Pour plus d’informations sur la mise à niveau d’un compte de stockage v1 universel, consultez Mettre à niveau un compte de stockage.
Cette fonctionnalité est prise en charge pour les comptes d’espace de noms hiérarchique. Si l’espace de noms hiérarchique est activé, vous ne pouvez pas renommer ni déplacer un objet blob si cet objet blob se trouve à l’état immuable. Le nom de l’objet blob et la structure de répertoire fournissent des données essentielles de niveau conteneur qui ne peuvent pas être modifiées une fois la stratégie immuable en place.
Il n’existe aucun processus d’activation pour cette fonctionnalité ; elle est automatiquement disponible pour tous les conteneurs. Pour en savoir plus sur la définition d’une stratégie sur un conteneur nouveau ou existant, consultez Configurer des stratégies d’immuabilité WORM de niveau conteneur.
Suppression
Vous devez vider un conteneur pour lequel une stratégie WORM de niveau conteneur est définie avant de le supprimer. Si une stratégie est définie sur un conteneur avec un espace de noms hiérarchique activé, vous devez vider un répertoire avant de le supprimer.
Scénarios
| Scénario | Opérations interdites | Protection des objets blob | Protection des conteneurs | Protection des comptes |
|---|---|---|---|---|
| Un conteneur est protégé par une stratégie de rétention basée sur le temps active avec une étendue de conteneur et/ou une conservation légale est en vigueur. | Delete Blob, Put Blob1, Set Blob Metadata, Put Page, Set Blob Properties, Snapshot Blob, Incremental Copy Blob, Append Block2 | Tous les objets blob du conteneur sont immuables pour le contenu et les métadonnées utilisateur. | La suppression du conteneur échoue si une stratégie WORM de niveau conteneur est en vigueur. | La suppression du compte de stockage échoue si un conteneur compte au moins un objet blob. |
| Un conteneur est protégé par une stratégie de rétention basée sur le temps expirée avec une étendue de conteneur et aucune conservation légale n’est en vigueur. | Put Blob1, Set Blob Metadata, Put Page, Set Blob Properties, Snapshot Blob, Incremental Copy Blob, Append Block2 | Aucune opération de suppression n'est autorisée. Les opérations de remplacement ne sont pas autorisées. | 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 si au moins un conteneur présente 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 Le Stockage Azure permet à l’opération Put Blob de créer un nouvel objet blob. Les opérations de remplacement ultérieures sur un chemin d’accès d’objets blob existant dans un conteneur immuable ne sont pas autorisées.
2 L’opération Append Block n’est autorisée que pour les stratégies avec la propriété allowProtectedAppendWrites ou allowProtectedAppendWritesAll activée.
Autoriser les écritures protégées d’objets blob d’ajout
Les objets blob d’ajout sont constitués de blocs de données et sont optimisés pour les opérations d’ajout de données nécessaires dans les scénarios d’audit et de journalisation. Du fait de la conception des objets blob d’ajout, les nouveaux blocs ne peuvent être ajoutés qu’à la fin des objets blob. Indépendamment de l’immuabilité, la modification ou la suppression de blocs existants dans un objet blob d’ajout ne sont absolument pas autorisées. Pour en savoir plus sur les objets blob d’ajout, consultez À propos des objets blob d’ajout.
Le paramètre de propriété allowProtectedAppendWrites autorise l’écriture de nouveaux blocs dans un objet blob d’ajout tout en conservant la protection et la conformité de l’immuabilité. Si ce paramètre est activé, vous êtes autorisé à créer un objet blob d’ajout directement dans le conteneur protégé par une stratégie et à continuer à ajouter de nouveaux blocs de données à la fin des objets blob d’ajout existants via l’opération Append Block. Seuls de nouveaux blocs peuvent être ajoutés ; les blocs existants ne peuvent pas être modifiés ou supprimés. L’activation de ce paramètre n’affecte pas le comportement d’immuabilité des objets blob de blocs ou de pages.
Le paramètre de propriété AllowProtectedAppendWritesAll fournit les mêmes autorisations que la propriété allowProtectedAppendWrites et offre en plus la possibilité d’écrire de nouveaux blocs dans un objet blob de blocs. L’API Stockage Blob ne permet pas aux applications de le faire directement. En revanche, les applications peuvent effectuer cette opération à l’aide des méthodes d’ajout et de vidage disponibles dans l’API Data Lake Storage Gen2. De plus, cette propriété permet aux applications Microsoft comme Azure Data Factory d’ajouter des blocs de données à l’aide d’API internes. Si vos charges de travail dépendent de l’un de ces outils, vous pouvez utiliser cette propriété pour éviter les erreurs qui peuvent apparaître quand ces outils tentent d’ajouter des données à des objets blob.
Les objets blob d’ajout restent à l’état immuable pendant la période de rétention effective. Sachant qu’il est possible d’ajouter de nouvelles données après la création initiale de l’objet blob d’ajout, la façon dont la période de rétention est déterminée est légèrement différente. La rétention effective est égale à la différence entre le moment où l’objet blob d’ajout est modifié pour la dernier fois et l’intervalle de rétention spécifié par l’utilisateur. De la même manière, quand la période de conservation est allongée, le stockage immuable utilise la valeur la plus récente de la période de conservation spécifiée par l’utilisateur pour calculer la durée de rétention effective.
Par exemple, supposez qu’un utilisateur crée une stratégie de rétention à durée définie avec la propriété allowProtectedAppendWrites activée et une période de conservation de 90 jours. Un objet blob d’ajout, logblob1, est créé aujourd’hui dans le conteneur et de nouveaux journaux continuent d’y être ajoutés les 10 jours suivants. Ainsi, la période de conservation effective de logblob1 est de 100 jours à partir d’aujourd’hui (dernier ajout il y a + 90 jours).
Les stratégies de rétention à durée définie déverrouillées permettent à tout moment d’activer et de désactiver les paramètres de propriété allowProtectedAppendWrites et AllowProtectedAppendWritesAll. Une fois que la stratégie de rétention à durée définie est verrouillée, les paramètres de propriété allowProtectedAppendWrites et AllowProtectedAppendWritesAll ne peuvent pas être modifiés.
Limites
Pour un compte de stockage, le nombre maximal de conteneurs disposant d’une stratégie immuable (conservation légale ou rétention à durée définie) est de 10 000.
Pour un conteneur, le nombre maximal d’étiquettes de conservation légale est de 10.
La longueur minimale d’une balise de conservation légale est de trois caractères alphanumériques. La longueur maximale est de 23 caractères alphanumériques.
Pour un conteneur, 10 journaux d’audit de stratégie de conservation légale au maximum sont conservés pendant la durée d’application de la stratégie.