Partager via

Comptes de stockage et la fiabilité

  • Article

Les comptes de stockage Azure sont parfaits pour les charges de travail qui nécessitent des temps de réponse rapides et cohérents ou qui ont un nombre élevé d’opérations d’entrée-sortie (IOP) par seconde. Les comptes de stockage contiennent tous vos objets de données du Stockage Azure, notamment :

  • Objets blob
  • Partages de fichiers
  • Files d’attente
  • Tables
  • Disques

Les comptes de stockage fournissent un espace de noms unique pour vos données, qui est accessible partout via HTTP ou HTTPS.

Pour plus d’informations sur les différents types de comptes de stockage qui prennent en charge différentes fonctionnalités, reportez-vous à la section Types de comptes de stockage.

Pour comprendre la façon dont un compte de stockage Azure prend en charge la résilience de la charge de travail de votre application, consultez les articles suivants :

Les sections suivantes incluent des considérations relatives à la conception, une liste de vérification de configuration et des options de configuration recommandées spécifiques aux comptes de stockage Azure et à la fiabilité.

Remarques relatives à la conception

Les comptes de stockage Azure incluent les considérations de conception suivantes :

  • Les comptes de stockage v1 universels offrent un accès à tous les services de Stockage Azure, mais ils ne proposent pas les fonctionnalités les plus récentes, ni les tarifs par gigaoctet les plus bas. Il est recommandé d’utiliser des comptes de stockage v2 universels dans la plupart des cas. Les raisons d’utiliser des comptes v1 sont les suivantes :

    • Les applications nécessitent le modèle de déploiement classique.
    • Les applications sont gourmandes en transactions ou utilisent beaucoup de bande passante de géoréplication, mais ne nécessitent pas une capacité importante.
    • L’utilisation d’une API REST du service de stockage antérieure au 14 février 2014 ou d’une bibliothèque de client dont la version est antérieure à la version 4.x est nécessaire. Une mise à niveau de l’application n’est pas possible.

Pour plus d’informations, reportez-vous à la présentation du compte de stockage.

  • Les noms de compte de stockage doivent comporter entre 3 et 24 caractères et peuvent contenir des chiffres et des lettres minuscules uniquement.
  • Pour connaître les spécifications actuelles des Contrats de niveau de service, reportez-vous à la page SLA pour Comptes de stockage.
  • Consultez la page Redondance de Stockage Azure pour déterminer quelle option de redondance est la mieux adaptée à un scénario spécifique.
  • Les noms de compte de stockage doivent être unique dans Azure. Deux comptes de stockage ne peuvent avoir le même nom.

Liste de contrôle

Avez-vous configuré votre compte de stockage Azure en tenant compte de la fiabilité ?

  • Activez la suppression réversible pour les données de blob.
  • Utilisez Microsoft Entra ID pour autoriser l’accès aux données blob.
  • Tenez compte du principe des privilèges minimum lorsque vous attribuez des autorisations à un principal de sécurité Microsoft Entra via Azure RBAC.
  • Utilisez des identités managées pour accéder aux données de blob et de file d’attente.
  • Utilisez le contrôle de version des blobs ou des blobs immuables pour stocker les données critiques de l’entreprise.
  • Limitez l’accès Internet par défaut pour les comptes de stockage.
  • Activez des règles de pare-feu.
  • Limitez l’accès réseau à des réseaux spécifiques.
  • Autorisez les services Microsoft approuvés à accéder au compte de stockage.
  • Activez l’option Transfert sécurisé requis sur tous vos comptes de stockage.
  • Limitez les jetons de signature d’accès partagé (SAP) aux seules connexions HTTPS.
  • Évitez d’utiliser l’autorisation Shared Key pour accéder aux comptes de stockage et empêchez son utilisation.
  • Régénérez régulièrement vos clés de compte.
  • Créez un plan de révocation et mettez-le en place pour toute SAP que vous émettez pour les clients.
  • Utilisez des délais d’expiration à court terme sur une SAP improvisée, une SAP de service ou une SAP de compte.

Recommandations relatives à la configuration

Tenez compte des recommandations suivantes pour optimiser la fiabilité lors de la configuration de votre compte de stockage Azure :

Recommandation Description
Activez la suppression réversible pour les données de blob. La suppression réversible des blobs de Stockage Azure vous permet de récupérer les données de blob après leur suppression.
Utilisez Microsoft Entra ID pour autoriser l’accès aux données blob. Microsoft Entra ID offre une sécurité et une facilité d’utilisation supérieures par rapport à la clé partagée pour autoriser les demandes au stockage d’objets blob. Il est recommandé d’utiliser l’autorisation Microsoft Entra avec vos applications d’objet blob et de file d’attente lorsque cela est possible pour réduire les vulnérabilités de sécurité potentielles inhérentes à la clé partagée. Pour plus d’informations, consultez Autoriser l’accès aux objets blob et files d’attente Azure à l’aide de l’ID de Microsoft Entra.
Tenez compte du principe des privilèges minimum lorsque vous attribuez des autorisations à un principal de sécurité Microsoft Entra via Azure RBAC. Quand vous attribuez un rôle à un utilisateur, un groupe ou une application, accordez à ce principal de sécurité seulement les autorisations nécessaires à l’exécution de ses tâches. La limitation de l’accès aux ressources permet d’éviter une mauvaise utilisation accidentelle et malveillante de vos données.
Utilisez des identités managées pour accéder aux données de blob et de file d’attente. Le stockage d’objets blob et de file d’attente Azure prend en charge l’authentification Microsoft Entra avec des identités managées pour les ressources Azure. Les identités managées pour les ressources Azure peuvent autoriser l’accès aux données d’objet blob et de file d’attente à l’aide des informations d’identification Microsoft Entra des applications s’exécutant sur des machines virtuelles Azure, des applications de fonction, des groupes de machines virtuelles identiques et d’autres services. En utilisant des identités managées pour les ressources Azure avec l’authentification Microsoft Entra, vous pouvez éviter de stocker les informations d’identification avec vos applications qui s’exécutent dans le cloud et les problèmes liés à l’expiration des principaux de service. Pour plus d’informations, reportez-vous à Autoriser l’accès à des données blob et de files d’attente avec des identités managées pour les ressources Azure.
Utilisez le contrôle de version des blobs ou des blobs immuables pour stocker les données critiques de l’entreprise. Envisagez d’utiliser le contrôle de version des blobs pour conserver les versions précédentes d’un objet ou d’utiliser des conservations légales et des stratégies de conservation basées sur le temps pour stocker des données de blob dans un état WORM (Write Once, Read Many). Les blobs immuables peuvent être lus, mais ne peuvent pas être modifiés ni supprimés pendant la période de rétention. Pour plus d’informations, reportez-vous à Stocker des données blob critiques pour l’entreprise avec un stockage immuable.
Limitez l’accès Internet par défaut pour les comptes de stockage. Par défaut, l’accès réseau aux comptes de stockage n’est pas restreint et est ouvert à tout le trafic provenant d’Internet. L’accès aux comptes de stockage doit être accordé seulement à des réseaux virtuels Azure spécifiques chaque fois que cela est possible ou utiliser des points de terminaison privés pour permettre aux clients d’un réseau virtuel (VNet) d’accéder aux données en toute sécurité via une liaison privée. Pour plus d’informations, reportez-vous à Utiliser des points de terminaison privés pour Stockage Azure. Des exceptions peuvent être faites pour les comptes de stockage qui doivent être accessibles sur Internet.
Activez des règles de pare-feu. Configurez des règles de pare-feu pour limiter l’accès à votre compte de stockage aux demandes provenant d’adresses IP ou de plages d’adresses IP spécifiées, ou d’une liste de sous-réseaux dans un réseau virtuel Azure (VNet). Pour plus d’informations sur la configuration des règles de pare-feu, reportez-vous à Configurer des pare-feu et des réseaux virtuels dans Stockage Azure.
Limitez l’accès réseau à des réseaux spécifiques. Limiter l’accès réseau aux réseaux hébergeant des clients nécessitant un accès réduit l’exposition de vos ressources aux attaques de réseau, soit en utilisant la fonctionnalité intégrée de pare-feu et de réseaux virtuels, soit en utilisant des points de terminaison privés.
Autorisez les services Microsoft approuvés à accéder au compte de stockage. L’activation des règles de pare-feu pour les comptes de stockage bloque par défaut les demandes entrantes de données, sauf si les demandes proviennent d’un service opérant dans un réseau virtuel (VNet) Azure ou d’IP publiques autorisées. Les demandes bloquées incluent les demandes émanant d’autres services Azure, du portail Azure, des services de journalisation et de métriques, etc. Vous pouvez autoriser les demandes provenant d’autres services Azure en ajoutant une exception pour autoriser les services Microsoft approuvés à accéder au compte de stockage. Pour plus d’informations sur l’ajout d’une exception pour les services Microsoft approuvés, reportez-vous à Configuration des pare-feu et des réseaux virtuels dans Stockage Azure.
Activez l’option Transfert sécurisé requis sur tous vos comptes de stockage. Quand vous activez l’option Transfert sécurisé requis, toutes les demandes effectuées auprès du compte de stockage doivent se faire via des connexions sécurisées. Toutes les demandes effectuées sur HTTP échouent. Pour plus d’informations, reportez-vous à Exiger un transfert sécurisé dans Stockage Azure.
Limitez les jetons de signature d’accès partagé (SAP) aux seules connexions HTTPS. Le fait d’exiger HTTPS quand un client utilise un jeton SAP pour accéder à des données de blob permet de réduire le risque d’écoute clandestine. Pour plus d’informations, reportez-vous à Accorder un accès limité aux ressources du Stockage Azure à l’aide des signatures d’accès partagé (SAS).
Évitez d’utiliser l’autorisation Shared Key pour accéder aux comptes de stockage et empêchez son utilisation. Il est recommandé d’utiliser l’ID Microsoft Entra pour autoriser les demandes adressées au Stockage Azure et pour empêcher l’autorisation de clé partagée. Pour les scénarios qui nécessitent une autorisation par clé partagée, préférez toujours les jetons SAP à la distribution de la clé partagée.
Régénérez régulièrement vos clés de compte. Effectuer une rotation des clés de compte régulièrement réduit le risque d’exposer vos données à des acteurs malveillants.
Créez un plan de révocation et mettez-le en place pour toute SAP que vous émettez pour les clients. Si une signature d’accès partagé est compromise, vous voudrez le révoquer immédiatement. Pour révoquer une signature d’accès partagé de délégation d’utilisateur, révoquez la clé de délégation d’utilisateur pour invalider rapidement toutes les signatures associées à cette clé. Pour révoquer une signature d’accès partagé de service associée à une stratégie d’accès stockée, vous pouvez supprimer la stratégie d’accès stockée, renommer la stratégie ou changer son délai d’expiration pour qu’il se situe dans le passé.
Utilisez des délais d’expiration à court terme sur une SAP improvisée, une SAP de service ou une SAP de compte. Si une signature d’accès partagé est compromise, elle n’est valide que pendant une courte durée. Cette pratique est particulièrement importante si vous ne pouvez pas référencer une stratégie d’accès stockée. Des heures d’expiration avec une échéance à court terme permettent également de limiter la quantité de données pouvant être écrites dans un objet blob en limitant le temps disponible pour le chargement vers ce dernier. Les clients doivent renouveler la signature d’accès partagé bien avant l’heure d’expiration pour avoir le temps d’effectuer de nouvelles tentatives si le service qui fournit la signature est indisponible.

Étape suivante

Comptes de stockage et la sécurité