Comptes de stockage Azure

Un compte Storage Azure est la ressource fondamentale qui vous donne accès aux services de stockage principaux d’Azure : Blob Storage (stockage d’objets), Azure Files (partages de fichiers gérés), Queue Storage (files d’attente de messages), Table Storage (magasin clé-valeur NoSQL) et Azure Data Lake Storage Gen2 (espace de noms hiérarchique pour l’analytique). Un seul compte Storage peut héberger simultanément tous ces services et fournit un espace de noms unique dans Azure — le nom du compte devient une partie de l’URL de chaque objet qu’il contient.

Azure propose plusieurs types de comptes Storage : Standard usage général v2 (GPv2) — le type recommandé pour la plupart des scénarios, prenant en charge tous les services de stockage et toutes les options de redondance avec des performances Standard. Objets blob de blocs Premium — stockage reposant sur des SSD pour les scénarios nécessitant une très faible latence lors des opérations Blob Storage. Partages de fichiers Premium — partages Azure Files reposant sur des SSD pour les charges de travail à IOPS élevées, telles que les bases de données ou les répertoires personnels. Objets blob de pages Premium — stockage SSD pour les disques OS et de Data des VM Azure (les disques gérés l’utilisent en arrière-plan). Pour la plupart des cas d’usage, commencez par un compte Standard GPv2.

Azure réplique automatiquement vos Data afin de les protéger contre les défaillances matérielles. Les quatre options de redondance sont les suivantes : LRS (Stockage localement redondant) — trois copies synchrones dans un seul centre de données. ZRS (Stockage redondant interzone) — trois copies synchrones réparties entre trois zones de disponibilité d’une même région. GRS (Stockage géoredondant) — LRS dans la région principale, avec réplication asynchrone vers une région secondaire (LRS). GZRS (Stockage géoredondant interzone) — ZRS dans la région principale, avec réplication asynchrone vers une région secondaire. Une redondance accrue signifie une durabilité et un coût plus élevés.

Choisissez votre niveau de redondance en fonction de vos besoins en matière de RTO, RPO et budget : LRS — le moins coûteux, avec une durabilité de 11 neufs, mais sans protection contre la défaillance d’un centre de données. À utiliser pour le développement, les tests ou les Data que vous pouvez recréer. ZRS — protège contre la défaillance d’un centre de données et convient aux Data de production dans une seule région. GRS/GZRS — protège contre la mise hors ligne d’une région Azure entière ; les Data sont répliquées de manière asynchrone vers la région appairée. Pour les Data d’entreprise critiques qui doivent survivre à une catastrophe régionale, GRS ou GZRS constitue le choix approprié malgré le coût supplémentaire.

Azure Storage propose deux niveaux de performance : Standard — reposant sur des disques durs (HDD), adapté à la plupart des charges de travail avec un coût par GB inférieur. Premium — reposant sur des disques SSD, conçu pour les scénarios sensibles à la latence nécessitant des entrées-sorties en quelques millisecondes. Le stockage Standard est facturé par GB stocké ; Premium est plus coûteux par GB, mais offre des performances cohérentes et prévisibles. Pour les ressources web, les sauvegardes, les journaux et l’archivage, Standard convient. Pour les VM équipées de bases de données intensives en entrées-sorties ou de partages de fichiers auxquels accèdent des utilisateurs sur ordinateur, Premium constitue le meilleur choix.

Les noms des comptes Storage doivent être uniques à l’échelle mondiale dans Azure (car ils constituent une partie d’un nom DNS public tel que mystorageacct.blob.core.windows.net). Les noms doivent comporter de 3 à 24 caractères et contenir uniquement des lettres minuscules et des chiffres — aucun trait d’union, trait de soulignement ou lettre majuscule. Comme les noms doivent être uniques à l’échelle mondiale, les mots courants et les noms de marque sont déjà pris. Il est recommandé de combiner un préfixe d’entreprise, l’environnement (prod/dev) et l’usage (store/media), puis d’ajouter un suffixe aléatoire si nécessaire : par exemple, contosoprodmedia7x2.

Chaque compte Storage possède deux clés d’accès de 512 bits qui accordent un accès administratif complet à tout ce qu’il contient. Ces clés doivent être traitées comme des mots de passe — stockées dans Azure Key Vault plutôt que dans du code ou des fichiers de configuration. Azure génère deux clés afin que vous puissiez effectuer une rotation des clés sans interruption de service : mettez à jour vos applications pour utiliser la clé 2, régénérez ensuite la clé 1, basculez les applications vers la clé 1, puis régénérez la clé 2. Pour un contrôle des accès plus précis, utilisez les signatures d’accès partagé (SAS) ou Azure RBAC au lieu de partager les clés principales.

Azure RBAC (contrôle d’accès en fonction des rôles) est la méthode recommandée pour autoriser l’accès aux Data de stockage sans partager de clés. Attribuez le rôle Storage Blob Data Reader pour autoriser un accès en lecture seule à Blob Storage, ou Storage Blob Data Contributor pour autoriser la lecture et l’écriture. Ces rôles sont attribués aux utilisateurs, groupes ou identités managées d’Entra ID ; l’accès est ainsi lié à une identité authentifiée plutôt qu’à un secret partagé. L’autorisation RBAC pour Storage est disponible pour les services Blob, Queue et Table (mais pas File — ce dernier utilise les protocoles SMB/NFS avec leurs propres contrôles d’accès).

Par défaut, les comptes Storage acceptent les connexions provenant de n’importe quel réseau. Pour sécuriser un environnement de production, limitez l’accès à l’aide du pare-feu du compte Storage : n’autorisez que certaines plages d’adresses IP publiques ou certains sous-réseaux de réseaux virtuels. Pour bénéficier du niveau de sécurité le plus élevé, désactivez entièrement l’accès à Internet public et utilisez un point de terminaison privé — une adresse IP privée au sein de votre VNet qui achemine le trafic vers le compte Storage via le réseau privé principal d’Azure, sans jamais l’exposer sur Internet public. Les points de terminaison privés sont l’approche recommandée pour les comptes Storage contenant des Data sensibles ou soumises à une réglementation.

Azure Storage fournit des fonctionnalités intégrées de protection des Data contre les suppressions accidentelles : suppression réversible des blobs — les blobs et versions supprimés sont conservés pendant une période configurable (de 1 à 365 jours) et peuvent être récupérés sans restauration depuis une sauvegarde. Gestion des versions des blobs — chaque remplacement crée une nouvelle version, ce qui vous permet de restaurer n’importe quelle version précédente d’un blob. Suppression réversible des conteneurs — les conteneurs supprimés accidentellement peuvent être récupérés. Ces fonctionnalités sont désactivées par défaut et doivent être activées pour les comptes Storage de production qui contiennent des Data importantes ne faisant pas l’objet d’une sauvegarde ailleurs.

Azure Monitor collecte automatiquement des métriques pour chaque compte Storage : capacité totale utilisée, nombre de transactions, octets entrants et sortants, ainsi que latence de bout en bout. Vous pouvez les consulter dans le volet Insights du portail Azure pour votre compte Storage, qui fournit des graphiques prédéfinis sur la capacité, la disponibilité et les performances. Pour un audit détaillé des accès, activez les journaux de diagnostic Storage afin d’enregistrer chaque opération de lecture, d’écriture et de suppression dans une destination de journaux — ce qui est utile pour les enquêtes de sécurité et les rapports de conformité.

Vérifiez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) abordés dans cette leçon.

Dans cette leçon, vous avez appris qu’un compte Storage est la ressource racine de tous les services de stockage Azure et qu’il est identifié par un nom unique à l’échelle mondiale, que les options de redondance — LRS, ZRS, GRS et GZRS — offrent des niveaux croissants de durabilité pour un coût croissant, et que l’accès doit être contrôlé au moyen de RBAC et de points de terminaison privés plutôt qu’en partageant les clés d’accès principales. Nous allons maintenant nous plonger dans Blob Storage — le stockage d’objets d’Azure pour les Data non structurées.