Stocker des données blob critiques pour l’entreprise avec un stockage immuable
Le stockage immuable pour le Stockage Blob Azure permet aux utilisateurs de stocker des données critiques pour l’entreprise dans un état WORM (écriture unique, lectures multiples). Dans l’état WORM, les données ne peuvent pas être modifiées ou 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. Pour plus d’informations sur les stratégies de rétention basées sur le temps, consultez Stratégies de rétention basées sur le temps pour les données d’objets blob immuables.
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. Pour en savoir plus sur les stratégies de conservation légale, consultez Conservation légale pour les données d’objets blob immuables.
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.
À 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é. Il 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.
Étendue des stratégies d’immuabilité
Les stratégies d’immuabilité peuvent être étendues à une version d’objet blob ou à un conteneur. Dans le cadre d’une stratégie d’immuabilité, le comportement d’un objet dépend de l’étendue de la stratégie. Pour plus d’informations sur l’étendue des stratégies pour chaque type de stratégie d’immuabilité, consultez les sections suivantes :
Vous pouvez configurer une stratégie de rétention basée sur le temps et une conservation légale pour une ressource (version de conteneur ou d’objet blob), en fonction de l’étendue.
Étendue au niveau de la version
Pour configurer une stratégie d’immuabilité s’étendant à une version de blob, vous devez activer la prise en charge de l’immuabilité au niveau de la version sur le compte de stockage ou un conteneur. Après avoir activé la prise en charge de l’immuabilité au niveau de la version sur un compte de stockage, vous pouvez configurer une stratégie par défaut au niveau du compte, qui s’applique à tous les objets créés par la suite dans le compte de stockage. Si vous activez la prise en charge de l’immuabilité au niveau de la version sur un conteneur individuel, vous pouvez configurer une stratégie par défaut pour ce conteneur, qui s’applique à tous les objets créés par la suite dans le conteneur.
Le tableau suivant récapitule les stratégies d’immuabilité prises en charge pour chaque étendue des ressources :
| Ressource | Activer les stratégies d’immuabilité au niveau de la version | Prise en charge de stratégie |
|---|---|---|
| Compte | Oui, lors de la création d’un compte uniquement. | Prend en charge une stratégie d’immuabilité par défaut au niveau de la version. La stratégie par défaut s’applique à toutes les nouvelles versions de blob créées dans le compte une fois la stratégie configurée. Ne prend pas en charge la conservation légale. |
| Conteneur | Oui, lors de la création d’un conteneur. Les conteneurs existants doivent être migrés pour prendre en charge les stratégies d’immuabilité au niveau de la version. | Prend en charge une stratégie d’immuabilité par défaut au niveau de la version. La stratégie par défaut s’applique à toutes les nouvelles versions de blob créées dans le conteneur une fois la stratégie configurée. Ne prend pas en charge la conservation légale. |
| Version de blob | N/A | Prend en charge une stratégie d’immuabilité au niveau de la version et une conservation légale. Une stratégie portant sur une version de blob peut remplacer une stratégie par défaut spécifiée sur le compte ou le conteneur. |
Étendue au niveau du conteneur
Lorsque la prise en charge des stratégies d’immuabilité au niveau de la version n’a pas été activée pour un compte de stockage ou un conteneur, l’étendue des stratégies d’immuabilité est limitée au conteneur. Un conteneur prend en charge une stratégie d’immuabilité et une conservation légale. Les stratégies s’appliquent à tous les objets au sein du conteneur.
Résumé des scénarios d’immuabilité
La protection offerte par une stratégie d’immuabilité dépend de l’étendue de la stratégie d’immuabilité et, dans le cas d’une stratégie de rétention basée sur le temps, de son état verrouillée ou déverrouillée et de son état actif ou expiré.
Scénarios avec étendue au niveau de la version
Le tableau suivant fournit un résumé des protections fournies par les stratégies d’immuabilité au niveau de la version.
| 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, Put Page et Append Block1 | 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 un nouvelle version.2 |
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 au niveau de la version est activé, ou si le stockage immuable au niveau de la version 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, Put Page et Append Block1 | La version blob peut ê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 un nouvelle version2. |
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 contient une version blob avec une stratégie de rétention basée sur le temps verrouillée. Les stratégies déverrouillées ne permettent pas de supprimer la protection. |
1 L’opération Append Block n’est autorisée que pour les stratégies avec la propriété allowProtectedAppendWrites ou allowProtectedAppendWritesAll activée. Pour plus d’informations, consultez Autoriser les écritures protégées de blobs d’ajout. 2 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.
Scénarios avec étendue au niveau du conteneur
Le tableau suivant fournit un résumé des protections fournies par les stratégies d’immuabilité au niveau du conteneur.
| 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 au niveau du conteneur est en vigueur. | La suppression du compte de stockage échoue si un conteneur présente 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 ne permettent pas de supprimer la protection. |
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’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. Pour plus d’informations, consultez Autoriser les écritures protégées de blobs d’ajout.
Notes
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.
Configurations de compte prises en charge
Les stratégies d’immuabilité sont prises en charge pour les comptes de stockage nouveaux et existants. Le tableau suivant répertorie les types de comptes de stockage pris en charge pour chaque type de stratégie :
| Type de stratégie d’immuabilité | Étendue de la stratégie | Types de comptes de stockage pris en charge | Prend en charge l’espace de noms hiérarchique |
|---|---|---|---|
| Stratégie de rétention limitée dans le temps | Étendue au niveau de la version | Usage général v2 Objet blob de blocs Premium |
Non |
| Stratégie de rétention limitée dans le temps | Étendue au niveau du conteneur | Usage général v2 Objet blob de blocs Premium v1 universel (héritée)1 Stockage d’objets blob (hérité) |
Oui |
| Conservation légale | Étendue au niveau de la version | Usage général v2 Objet blob de blocs Premium |
Non |
| Conservation légale | Étendue au niveau du conteneur | Usage général v2 Objet blob de blocs Premium v1 universel (héritée)1 Stockage d’objets blob (hérité) |
Oui |
Notes
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é.
1 Microsoft recommande de mettre à niveau les comptes v1 universels vers v2 universel 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.
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 chaud, froid et archive pour les données d’objet 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.
Prise en charge de l’espace de noms hiérarchique
Les comptes qui ont un espace de noms hiérarchique prennent en charge les stratégies d’immuabilité limitées au conteneur. Mais vous ne pouvez pas renommer ou déplacer un objet blob lorsque cet objet blob se trouve à l’état immuable et que l’espace de noms hiérarchique est activé sur le compte. Le nom de l’objet blob et la structure de répertoires fournissent des données essentielles de niveau conteneur qui ne peuvent pas être modifiées une fois la stratégie immuable en place.
Types d’objets blob recommandés
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 stockant un disque dur virtuel pour une machine virtuelle active est déconseillée, car les écritures sur le disque sont bloquées. 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 seront définitivement supprimés une fois la stratégie de rétention de suppression conditionnelle expirée. 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’a pas été 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.
Tarifs
L’utilisation du stockage immuable en génère pas de frais de capacité supplémentaires. Les données immuables sont facturées de la même façon que les données modifiables classiques. 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.
La prise en charge de cette fonctionnalité peut être impactée par l’activation de Data Lake Storage Gen2, du protocole NFS (Network File System) 3.0 ou du protocole SFTP (SSH File Transfer Protocol). Si vous avez activé l’une de ces fonctionnalités, consultez Prise en charge des fonctionnalités Stockage Blob dans les comptes Stockage Azure pour évaluer la prise en charge de cette fonctionnalité.
Étapes suivantes
- Vue d’ensemble de la protection des données
- Stratégies de rétention limitées dans le temps pour les données d’objets blob immuables
- Conservation légale des données d’objets blob immuables
- Configurer des stratégies d’immuabilité pour les versions d’objets blob
- Configurer des stratégies d’immuabilité pour les conteneurs