Partager via

Stocker des données d’objets blob critiques pour l’entreprise avec un stockage immuable en écriture une fois, lire de nombreux états (WORM)

  • Article

Le stockage immuable pour le Stockage Blob Azure permet aux utilisateurs de stocker des données vitales pour l’entreprise dans un état WORM (Write Once Read Many - écriture unique, lecture multiple). Dans un WORM, les données ne peuvent pas être modifiées ni supprimées pendant un intervalle spécifié par l’utilisateur. En configurant des stratégies d’immuabilité pour les données blob, vous pouvez protéger vos données contre les remplacements et les suppressions.

Le stockage immuable du service Stockage Blob Azure prend en charge deux types de stratégies d’immuabilité.

  • Stratégies de rétention basée sur le temps : avec une stratégie de rétention basée sur le temps, les utilisateurs peuvent définir des stratégies pour stocker des données pendant un intervalle spécifié. Lorsqu’une stratégie de rétention basée sur le temps est définie, des objets peuvent être créés et lus, mais ils ne peuvent être ni modifiés ni supprimés. Après l’expiration de la période de rétention, les objets peuvent être supprimés, mais pas remplacés.

  • Stratégies de conservation légale : la conservation légale stocke des données immuables jusqu’à ce que la conservation légale soit explicitement désactivée. Lorsqu’une conservation juridique est définie, des objets peuvent être créés et lus, mais ils ne peuvent être ni modifiés ni supprimés.

Ces stratégies peuvent être définies en même temps. Par exemple, un utilisateur peut avoir à la fois une stratégie de rétention temporelle et une conservation légale définie au même niveau et en même temps. Pour que l’écriture réussisse, vous devez avoir activé le contrôle de version ou n’avoir ni conservation légale, ni stratégie de rétention temporelle sur les données. Pour qu’une suppression réussisse, il ne doit pas y avoir de conservation légale ou de stratégie de rétention temporelle sur les données.

Le diagramme suivant montre comment les stratégies de rétention basées sur le temps et les conservations légales empêchent les opérations d’écriture et de suppression quand elles sont appliquées.

Diagramme montrant comment les stratégies de rétention et les conservations légales empêchent les opérations d’écriture et de suppression

Il existe deux fonctionnalités sous l’ombrelle de stockage immuable : WORM de niveau conteneur et WORM de niveau version. Le WORM de niveau conteneur permet aux stratégies d’être définies au niveau du conteneur uniquement, tandis que le WORM de niveau version permet de définir les stratégies au niveau du compte, du conteneur ou de la version.

À propos du stockage immuable pour des objets blob

Le stockage immuable permet aux établissements de santé, aux institutions financières et aux secteurs associés, en particulier les organisations de courtage, de stocker des données en toute sécurité. Le stockage immuable peut être utilisé dans n’importe quel scénario pour protéger les données vitales contre la modification ou la suppression.

Les applications typiques incluent :

  • Conformité réglementaire : la fonctionnalité de stockage immuable du service Stockage Blob Azure permet notamment aux organisations de respecter les réglementations SEC 17a-4(f), CFTC 1.31(d) et FINRA.

  • Conservation sécurisée des documents : avec le stockage immuable des objets blob, les données ne sont ni modifiables ni supprimables par les utilisateurs, même s’ils disposent d’un compte avec privilèges administratifs.

  • Conservation légale : le stockage immuable des objets blob permet aux utilisateurs de stocker dans un état de protection inviolable des informations sensibles critiques dans le cadre d’une utilisation professionnelle ou portant sur un litige, pour la durée souhaitée jusqu’à ce que la conservation prenne fin. Cette fonctionnalité n’est pas limitée aux seuls cas d’utilisation légale, mais peut également être considérée comme une conservation basée sur un événement ou un verrou de l’entreprise, lorsqu’il est nécessaire de protéger les données sur la base de déclencheurs d’événements ou d’une stratégie d’entreprise.

Conformité aux normes

Microsoft a choisi les services de Cohasset Associates, une importante société d’évaluation indépendante spécialisée dans la gestion des dossiers et la gouvernance de l’information, afin d’évaluer le stockage immuable des objets blob et sa conformité aux exigences propres au secteur des services financiers. Cohasset a confirmé que le stockage immuable d’objets blob, lorsqu’il est utilisé pour conserver les objets blob dans un état WORM, répond aux exigences de stockage appropriées décrites par la réglementation FINRA 4511, le paragraphe 1.31(c)-(d) de la réglementation CFTC et le paragraphe 17a-4(f) de la réglementation SEC. Microsoft a opté pour cet ensemble de règles, car elles représentent les recommandations les plus normatives au monde en matière de rétention des enregistrements pour les institutions financières.

Le rapport Cohasset est disponible dans le Centre de gestion de la confidentialité des services Microsoft. Le Centre de confidentialité Azure contient des informations détaillées sur les certifications de conformité Microsoft. Pour demander une lettre d’attestation de Microsoft concernant la conformité à l’immuabilité WORM, contactez le Support Azure.

Stratégies de rétention limitée dans le temps

Une stratégie de rétention temporelle stocke les données blob dans un format WORM pour une période spécifiée. Quand une stratégie de rétention temporelle est définie, les clients peuvent créer et lire des objets blob, mais ils ne peuvent pas les modifier ou les supprimer. Après expiration de la période de conservation, les objets blob peuvent être effacés, mais pas remplacés.

Étendue

Une stratégie de rétention temporelle peut être configurée sur l’une des étendues suivantes :

  • Stratégie WORM de niveau version : une stratégie de rétention temporelle peut être configurée au niveau du compte, du conteneur ou de la version. Si elle est configurée au niveau du compte ou du conteneur, elle sera héritée par tous les objets blob du compte ou du conteneur respectif. S’il existe une conservation légale sur un conteneur, un WORM de niveau version ne peut pas être créé pour le même conteneur. Cela est dû au fait que les versions ne peuvent pas être générées en raison de la conservation légale.
  • Stratégie WORM de niveau conteneur : une stratégie de rétention temporelle configurée au niveau du conteneur s’applique à tous les objets blobs de ce conteneur. Les objets blob individuels ne peuvent pas être configurés avec leurs propres stratégies d’immuabilité.

Période de conservation pour une stratégie limitée dans le temps

La période de conservation minimale pour une stratégie de rétention limitée dans le temps est d’un jour et la valeur maximale est de 146 000 jours (400 ans). Quand vous configurez une stratégie de rétention temporelle, les objets concernés restent à l’état immuable pendant la période de rétention effective. La période de conservation effective pour les objets blob est égale à la différence entre l’heure de création de l’objet blob et la période de conservation spécifiée par l’utilisateur. Dans la mesure où la période de conservation d’une stratégie peut être étendue, 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 conservation effective.

Par exemple, supposons qu’un utilisateur crée une stratégie de rétention limitée dans le temps avec une période de conservation de cinq ans. Un objet blob existant dans ce conteneur, testblob1, a été créé il y a un an. Autrement dit, la période de conservation effective de testblob1 est de quatre ans. Quand un nouvel objet blob, testblob2, est chargé dans le conteneur, la période de conservation effective de testblob2 est de cinq ans à partir du moment où il est créé.

Stratégies verrouillées et déverrouillées

Lorsque vous configurez pour la première fois une stratégie de rétention limitée dans le temps, la stratégie est déverrouillée à des fins de test. Une fois les tests terminés, vous pouvez verrouiller la stratégie pour qu’elle soit entièrement conforme à la norme SEC 17a-4 (f) et à toute autre conformité réglementaire.

Les stratégies verrouillées et déverrouillées protègent contre les suppressions et les remplacements. Toutefois, vous pouvez modifier une stratégie déverrouillée en réduisant ou en étendant la période de conservation. Vous pouvez également supprimer une stratégie déverrouillée. Vous ne pouvez pas supprimer une stratégie de rétention temporelle verrouillée. Vous pouvez étendre la période de conservation, mais vous ne pouvez pas la diminuer. Un maximum de cinq augmentations de la période de conservation effective est autorisé sur la durée de vie d’une stratégie verrouillée définie au niveau du conteneur. Pour une stratégie configurée pour une version d’objet blob, il n’existe pas de limite au nombre d’augmentations de la période effective.

Important

Une stratégie de rétention limitée dans le temps doit être verrouillée pour que l’objet blob ait un état immuable conforme (protégé contre l’écriture et la suppression) conformément entre autres à la réglementation SEC 17a-4(f). Microsoft recommande de verrouiller la stratégie au bout d’un délai raisonnable, en général inférieur à 24 heures. Tant que l’état déverrouillé protège l’immuabilité, nous recommandons de ne pas utiliser l’état déverrouillé pour d’autres raisons que des évaluations de fonctionnalités à court terme.

Journalisation d’audit de stratégie de rétention

Chaque conteneur avec une stratégie de rétention limitée dans le temps activée fournit un journal d’audit de stratégie. Le journal d’audit contient jusqu’à sept commandes de rétention limitées dans le temps pour les stratégies de rétention limitées dans le temps verrouillées. La journalisation démarre généralement une fois que vous avez verrouillé la stratégie. Les entrées de journal incluent l’ID d’utilisateur, le type de commande, les horodatages et la période de conservation. Ce journal d’audit est conservé pendant la durée de vie de la stratégie, conformément aux instructions réglementaires SEC 17a-4(f).

Le Journal d’activité Azure fournit un journal plus complet de l’ensemble des activités du service de gestion. Les Journaux de ressources Azure conservent des informations sur les opérations de données. Il est de la responsabilité de l’utilisateur de stocker ces journaux d’activité de manière permanente, si les obligations réglementaires ou autres l’imposent.

Les modifications apportées aux stratégies de rétention temporelle au niveau de la version ne sont pas auditées.

Une conservation légale est une stratégie d’immuabilité temporaire qui peut être appliquée à des fins d’investigation légale ou de protection générale. Une conservation légale stocke les données blob dans un format WORM (Write-Once, Read-Many) jusqu’à ce que la conservation soit explicitement effacée. Lorsqu’une conservation légale est définie, des objets blob peuvent être créés et lus, mais ils ne peuvent pas être modifiés ni supprimés. Utilisez une conservation légale lorsque la période pendant laquelle les données doivent être conservées à l’état WORM est inconnue.

Étendue

Une stratégie de conservation légale peut être configurée sur l’une des étendues suivantes :

  • Stratégie WORM de niveau version : une conservation légale peut être configurée sur un niveau de version de l’objet blob individuel pour la gestion granulaire des données sensibles.

  • Stratégie WORM de niveau conteneur : une conservation légale configurée au niveau du conteneur s’applique à tous les objets blob de ce conteneur. Les objets blob individuels ne peuvent pas être configurés avec leurs propres stratégies d’immuabilité.

Balises

Une conservation légale au niveau du conteneur doit être associée à une ou plusieurs balises alphanumériques définies par l’utilisateur qui servent de chaînes d’identificateurs. Par exemple, une balise peut inclure un ID de cas ou un nom d’événement.

Journalisation d’audit

Chaque conteneur avec une conservation légale en vigueur fournit un journal d’audit de stratégie. Le journal comporte l’identifiant utilisateur, le type de commande, les timestamps et les balises d’archivage juridique. Ce journal d’audit est conservé pendant la durée de vie de la stratégie, conformément aux instructions réglementaires SEC 17a-4(f).

Le Journal d’activité Azure fournit un journal plus complet de l’ensemble des activités du service de gestion. Les Journaux de ressources Azure conservent des informations sur les opérations de données. Il est de la responsabilité de l’utilisateur de stocker ces journaux d’activité de manière permanente, si les obligations réglementaires ou autres l’imposent.

Les modifications apportées aux conservations légales au niveau de la version ne sont pas auditées.

Options de fonctionnalité de stockage immuable

Le tableau suivant présente une répartition des différences entre la stratégie WORM de niveau conteneur et la stratégie WORM de niveau version :

Catégorie WORM de niveau conteneur WORM de niveau version
Niveau de granularité de stratégie Les stratégies ne peuvent être configurées qu’au niveau du conteneur. Chaque objet qui est chargé dans le conteneur hérite du jeu de stratégies immuable. Les stratégies peuvent être configurées au niveau du compte, du conteneur ou de l’objet blob. Si une stratégie est définie au niveau du compte, tous les objets blob chargés dans ce compte héritent de la stratégie. La même logique est appliquée aux conteneurs. Si une stratégie est définie à plusieurs niveaux, l’ordre de priorité est toujours Blob -> Conteneur -> Compte.
Types de stratégies disponibles Deux types de stratégies différents peuvent être définis au niveau du conteneur : les stratégies de rétention temporelles et les conservations légales. Au niveau du compte et du conteneur, seules les stratégies de rétention temporelles peuvent être définies. Au niveau de l’objet blob, les stratégies de rétention temporelles et les conservations légales peuvent être définies.
Dépendances des fonctionnalités Aucune autre fonctionnalité n’est requise pour que cette fonctionnalité soit effective. Le contrôle de version est un prérequis pour que cette fonctionnalité soit utilisée.
Activation pour les comptes/conteneurs existants Cette fonctionnalité peut être activée à tout moment pour les conteneurs existants. Selon le niveau de granularité, cette fonctionnalité peut ne pas être activée pour tous les comptes/conteneurs existants.
Suppression de compte/conteneur Une fois qu’une stratégie de rétention temporelle est verrouillée sur un conteneur, les conteneurs peuvent uniquement être supprimés s’ils sont vides. Une fois que la stratégie WORM de niveau version est activée sur un niveau de compte ou de conteneur, il se peut qu’elles soient supprimées uniquement si elles sont vides.
Prise en charge d’Azure Data Lake Storage (comptes de stockage pour lesquels un espace de noms hiérarchique est activé) Les stratégies WORM de niveau conteneur sont prises en charge dans les comptes qui ont un espace de noms hiérarchique. Les stratégies WORM de niveau version ne sont pas encore prises en charge dans les comptes qui ont un espace de noms hiérarchique.

Pour en savoir plus sur la stratégie WORM de niveau conteneur, consultez Stratégies WORM de niveau conteneur. Pour en savoir plus sur la stratégie WORM de niveau version, consultez Stratégies WORM de niveau version.

WORM de niveau conteneur vs niveau version

Le tableau suivant vous aide à déterminer quel type de stratégie WORM utiliser.

Critères Utilisation de stratégie WORM de niveau conteneur Utilisation de stratégie WORM de niveau version
Organisation des données Vous souhaitez définir des stratégies pour des jeux de données spécifiques, qui peuvent être catégorisées par conteneur. Toutes les données de ce conteneur doivent être conservées dans un état WORM pendant la même durée. Vous ne pouvez pas regrouper d’objets par période de rétention. Tous les objets blob doivent être stockés avec une durée de rétention individuelle en fonction de ces scénarios d’objets blob, ou l’utilisateur a une charge de travail mixte, afin que certains groupes de données puissent être groupés dans des conteneurs, tandis que d’autres objets blob ne le peuvent pas. Vous pouvez également définir des stratégies au niveau du conteneur et des stratégies au niveau de l’objet blob au sein du même compte.
Quantité de données nécessitant une stratégie immuable Vous n’avez pas besoin de définir des stratégies sur plus de 10 000 conteneurs par compte. Vous souhaitez définir des stratégies sur toutes les données ou de grandes quantités de données pouvant être délimitées par compte. Vous savez que si vous utilisez la stratégie WORM de niveau conteneur, vous devrez dépasser la limite de 10 000 conteneurs.
Intérêt pour l’activation du contrôle de version Vous ne souhaitez pas activer le contrôle de version en raison du coût, ou parce que la charge de travail créerait de nombreuses versions supplémentaires à gérer. Vous souhaitez utiliser le contrôle de version ou cela ne vous dérange pas de l’utiliser. Vous savez que si le contrôle de version n’est pas activé, vous ne pouvez pas conserver les modifications ou les remplacements dans des objets blob immuables en tant que versions distinctes.
Emplacement de stockage (Stockage Blob et Data Lake Storage) Votre charge de travail est entièrement axée sur Azure Data Lake Storage. Vous n’avez pas d’intérêt ou plan immédiats de passer à l’utilisation d’un compte pour lequel la fonctionnalité d’espace de noms hiérarchique n’est pas activée. Votre charge de travail se trouve sur Stockage Blob dans un compte pour lequel la fonctionnalité d’espace de noms hiérarchique n’est pas activée et elle peut utiliser un WORM de niveau version maintenant, ou vous êtes disposé à attendre que le contrôle de version soit disponible pour les comptes où un espace de noms hiérarchique est activé (Azure Data Lake Storage).

Niveaux d’accès

Tous les niveaux d’accès des objets blob prennent en charge le stockage immuable. Vous pouvez modifier le niveau d’accès d’un objet blob à l’aide de l’opération Set Blob Tier. Pour plus d’informations, consultez Niveaux d’accès pour les données d’objets blob.

Configurations de redondance

Toutes les configurations de redondance prennent en charge le stockage immuable. Pour plus d’informations sur les configurations de redondance, consultez Redondance du stockage Azure.

Microsoft vous recommande de configurer des stratégies d’immuabilité principalement pour les objets blob de blocs et les objets blob d’ajouts. La configuration d’une stratégie d’immuabilité pour un objet blob de pages qui stocke un disque VHD pour une machine virtuelle active est déconseillée, car les écritures sur le disque seront bloquées ou si le contrôle de version est activé, chaque écriture est stockée en tant que nouvelle version. Avant de verrouiller des stratégies limitées dans le temps, Microsoft vous recommande de consulter attentivement la documentation et de tester vos scénarios.

Stockage immuable avec suppression conditionnelle d’objets blob

Lorsque la suppression conditionnelle des objets blob est configurée pour un compte de stockage, elle s’applique à tous les objets blob du compte, qu’une stratégie de rétention basée dans le temps ou conservation légale soit appliquée ou non. Microsoft recommande d’activer la suppression conditionnelle pour une protection supplémentaire avant d’appliquer des stratégies immuables.

Si vous activez la suppression conditionnelle d’objets blob, puis configurez une stratégie d’immuabilité, tous les objets blob déjà supprimés de manière conditionnelle sont définitivement supprimés une fois que la stratégie de rétention de suppression conditionnelle a expiré. Les objets supprimés de manière conditionnelle peuvent être restaurés au cours de la période de rétention de la suppression conditionnelle. Un objet blob (ou une version) qui n’a pas encore été supprimé de manière conditionnel est protégé par la stratégie d’immuabilité et ne peut pas être supprimé de manière conditionnelle tant que la stratégie de rétention basée sur la temps n’a pas expiré ou que la conservation légale n’est pas supprimée.

Utiliser l’inventaire d’objets blob pour suivre les stratégies d’immuabilité

L’inventaire d’objets blob Stockage Azure offre une vue d’ensemble des conteneurs de vos comptes de stockage, ainsi que des objets blob, instantanés et versions blob qu’ils contiennent. Vous pouvez utiliser le rapport d’inventaire d’objets blob pour comprendre les attributs des objets blob et des conteneurs, notamment si une stratégie d’immuabilité est configurée pour une ressource.

Lorsque vous activez l’inventaire d’objets blob, le Stockage Azure génère quotidiennement un rapport d’inventaire. Il vous fournit une synthèse de vos données pour les besoins de l’entreprise et ses exigences de conformité.

Pour plus d’informations sur l’inventaire des objets blob, consultez Inventaire des objets blob du Stockage Azure.

Remarque

Vous ne pouvez pas configurer une stratégie d'inventaire dans un compte si la prise en charge de l'immuabilité au niveau de la version est activée sur ce compte, ou si la prise en charge de l'immuabilité au niveau de la version est activée sur le conteneur de destination défini dans la stratégie d'inventaire.

Configuration des stratégies à grande échelle

Vous pouvez utiliser une tâche de stockage pour configurer des stratégies d'immuabilité à grande échelle sur plusieurs comptes de stockage en fonction d'un ensemble de conditions que vous définissez. Une tâche de stockage est une ressource disponible dans Azure Storage Actions; infrastructure serverless que vous pouvez utiliser pour effectuer des opérations de données courantes sur des millions d’objets sur plusieurs comptes de stockage. Pour plus d’informations, consultez Qu’est-ce qu’Azure Storage Actions ?.

Tarification

Il n’y a pas de frais de capacité supplémentaires pour utiliser un stockage immuable. Les données immuables sont facturées de la même façon que les données modifiables classiques. Si vous utilisez une stratégie WORM de niveau version, la facture peut être plus élevée, car vous avez activé le contrôle de version et il y a un coût associé à des versions supplémentaires stockées. Pour plus d’informations, consultez la stratégie de tarification du contrôle de version. Pour plus d’informations sur les prix du stockage Blob Azure, consultez la page des tarifs du stockage Azure.

La création, la modification ou la suppression d’une stratégie de conservation légale ou de rétention limitée dans le temps portant sur une version blob entraîne des frais de transaction d’écriture.

Si vous ne vous acquittez pas de votre facture et que votre compte présente une stratégie de rétention basée sur le temps active, les stratégies de rétention des données classiques s’appliquent comme stipulé dans les conditions générales du contrat Microsoft. Pour obtenir des informations générales, consultez Gestion des données chez Microsoft.

Prise en charge des fonctionnalités

Cette fonctionnalité n’est pas compatible avec la restauration à un point dans le temps et le suivi du dernier accès. Cette fonctionnalité est compatible avec le basculement non planifié géré par le client, mais toutes les modifications apportées à la stratégie immuable après la dernière heure de synchronisation (par exemple, le verrouillage d’une stratégie de rétention basée sur le temps, son extension, etc.) ne seront pas synchronisées avec la région secondaire. Une fois le basculement terminé, vous pouvez rétablir les modifications apportées vers la région secondaire pour vous assurer qu’elle est à jour avec vos exigences d’immuabilité. Les stratégies d’immuabilité ne sont pas prises en charge dans les comptes sur lesquels le protocole NFS (Network File System) 3.0 ou le protocole SFTP (SSH File Transfer Protocol) est activé.

Certaines charges de travail, telles que Sauvegarde SQL vers une URL, créent un blob et l’ajoutent ensuite. Si un conteneur est doté d’une stratégie active de rétention basée sur le temps ou d’une conservation légale en place, ce modèle échouera. Pour plus d’informations, consultez les écritures d’objets blob d’ajout protégés.

Pour plus d’informations, consultez Prise en charge des fonctionnalités de Stockage Blob dans les comptes stockage Azure.

Étapes suivantes