Microsoft AZ-500: Sécurité des données, du stockage et des bases de données — Guide d'étude

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Security Engineer Associate AZ-500 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

La sécurité des données, du stockage et des bases de données Azure est axée sur la minimisation de la confiance, l’isolation des plans de données, le chiffrement systématique et l’opérationnalisation du moindre privilège avec des chemins d’accès auditables. Cette section explique comment renforcer la sécurité d’Azure Storage, Azure SQL et Azure Cosmos DB, choisir la bonne stratégie d’identité et de clés, et prévenir l’exfiltration de données. Chaque contrôle décrit est accompagné du raisonnement opérationnel qui le sous-tend afin que vous puissiez justifier et maintenir la configuration en production.

Sécurisation des comptes de stockage Azure et de l’accès aux données

Autorisation et partage du compte de stockage

• Azure RBAC pour Azure Storage : Préférer l’autorisation basée sur Azure AD (Blob et Queue) via des rôles intégrés tels que Lecteur/Contributeur aux données Blob de stockage. Raisonnement : accès basé sur des jetons et limité dans le temps via l’Accès Conditionnel, journalisé dans Entra ID ; évite les clés de compte perpétuelles et prend en charge l’attribution juste-à-temps.
• Clés partagées : Les clés primaires/secondaires du compte accordent des droits complets sur le plan de données. Désactiver l’utilisation des clés dans le code et effectuer une rotation fréquente. Raisonnement : les clés partagées sont des secrets de porteur sans liaison à un utilisateur ou à une autorité de certification ; une compromission équivaut à une exposition totale des données.
• Types de SAS :
  • SAS de service : Accorde un accès délimité à des ressources spécifiques (blob, fichier, file d’attente, table) avec des autorisations, des limites d’IP, de protocole et de temps. Raisonnement : moindre privilège précis pour les applications qui ne peuvent pas utiliser de jetons AD.
  • SAS de compte : Surface plus large (par ex., sur plusieurs services) ; à utiliser avec parcimonie. Raisonnement : étend le rayon d’impact en cas de fuite.
  • SAS de délégation d’utilisateur : Émise en utilisant Azure AD et une clé de délégation d’utilisateur pour Blob. Raisonnement : se lie à une identité Azure AD et à l’Accès Conditionnel ; auditabilité et révocation supérieures.
• Stratégies d’accès stockées : Définissent des contraintes réutilisables (expiration, autorisations) pour les SAS sur les conteneurs/partages ; la révocation ou la mise à jour de la stratégie invalide les SAS émises sous celle-ci. Raisonnement : révocation centralisée sans avoir à regénérer les jetons intégrés dans les clients.

Exemple : générer une SAS de délégation d’utilisateur pour un blob avec Azure AD

az storage blob generate-sas \
  --account-name mystorage \
  --container-name data \
  --name report.csv \
  --permissions r \
  --expiry 2026-12-31T23:59Z \
  --as-user \
  --auth-mode login

Sécurité du service par type

• Blob/Queue/Table : Utiliser Azure AD RBAC là où il est pris en charge (Blob, Queue). Définir AllowBlobPublicAccess sur false, exiger HTTPS, activer le versioning et la suppression réversible (soft delete). Raisonnement : supprime les chemins d’exposition anonymes et permet la récupérabilité.
• Azure Files : Utiliser Azure AD Kerberos pour SMB avec Entra ID (ou l’intégration AD DS) et appliquer des autorisations de moindre privilège au niveau des partages/fichiers. Exiger le chiffrement SMB. Raisonnement : accès lié à l’identité avec sécurité du transport sur SMB ; pas de clés partagées dans l’espace utilisateur.
• Service Table : Utiliser des SAS avec des contraintes strictes d’IP/temps et éviter les SAS de compte. Raisonnement : la granularité au niveau du service n’est pas aussi riche ; délimiter de manière agressive.

Isolation réseau pour tous les services de stockage

• Règles de pare-feu du stockage : Restreindre à des plages d’adresses IP publiques sélectionnées uniquement lorsque Private Link n’est pas réalisable. Raisonnement : réduit la surface d’attaque mais le trafic traverse toujours l’internet public.
• Points de terminaison privés : Préférer Private Link pour Blob, Queue, Table et Files. Mapper des zones DNS privées aux noms spécifiques des ressources. Définir l’accès réseau public sur Désactivé. Raisonnement : le trafic reste sur le backbone Azure ; l’identité de la ressource est validée via le DNS privé ; atténue l’exfiltration vers des services d’apparence similaire.
• Points de terminaison de service et stratégies : Si Private Link n’est pas une option, activer les points de terminaison de service et appliquer des stratégies de point de terminaison de service pour restreindre la sortie (egress) vers des comptes de stockage spécifiques. Raisonnement : contraint le trafic même via la sortie du réseau virtuel ; limite le risque d’envoyer des données à des comptes appartenant à des attaquants.

Paramètres opérationnels à standardiser

• Forcer HTTPS uniquement, TLS 1.2 minimum.
• Désactiver l’accès par clé partagée pour Blob et Queue si vous utilisez AD (dépend de la prise en charge de la fonctionnalité).
• Stratégies d’immuabilité sur les conteneurs/partages critiques pour la rétention réglementaire et la résilience face aux ransomwares.

Chiffrement et gestion des clés

Couches de chiffrement au repos

• Clés gérées par le service (SMK) : Chiffrement côté serveur par défaut géré par Azure. Raisonnement : aucune surcharge opérationnelle ; convient à de nombreuses charges de travail.
• Clés gérées par le client (CMK) : Clés dans Key Vault ou Managed HSM pour Storage, SQL et Cosmos DB. Raisonnement : périmètre de confiance externalisé, contrôle client de la rotation/révocation et preuve de conformité.
• Chiffrement d’infrastructure (double chiffrement) : Couche supplémentaire utilisant des clés distinctes. Raisonnement : défense en profondeur si le chiffrement du support de stockage est contourné ou si un périmètre cryptographique est compromis.

Rotation et opérations des clés

• Les SMK effectuent une rotation automatique ; aucune action n’est requise.
• La rotation des CMK s’effectue en créant une nouvelle version de la clé, en accordant les autorisations wrap/unwrap, et en redirigeant la ressource vers la dernière version (ou une référence de clé sans version lorsque cela est pris en charge). Raisonnement : rotation non disruptive avec un changement auditable.
• Protéger les clés avec la suppression réversible (soft delete) et la protection contre la purge de Key Vault ; contrôler l’administration via RBAC et le plan de données via des stratégies d’accès ou RBAC (pour Managed HSM, utiliser RBAC). Raisonnement : empêche la perte destructrice de clés et applique le moindre privilège.

Exemple : définir une CMK pour un compte de stockage

az storage account update \
  --name mystorage \
  --resource-group rg-secure \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.KeyVault/vaults/mykv \
  --encryption-key-name stor-cmk

Étendues de chiffrement

• Utiliser des étendues de chiffrement par conteneur dans Storage lorsque différents ensembles de données nécessitent des clés distinctes. Raisonnement : segmente le rayon d’impact et permet des cycles de vie de clés différentiels.

Sécurité de la plateforme de base de données : Azure SQL et Azure Cosmos DB

Authentification et accès à Azure SQL

• Authentification Microsoft Entra : Créez un administrateur Azure AD au niveau du serveur ; utilisez des utilisateurs de base de données contenus (CREATE USER FROM EXTERNAL PROVIDER). Raisonnement : évite les identifiants/mots de passe SQL et active l’accès conditionnel (Conditional Access) et PIM.
• Utilisateurs contenus : L’identité réside dans la base de données, pas dans la base master. Raisonnement : simplifie la géo-restauration et le basculement sans avoir à réapprovisionner les identifiants de connexion.
• Règles de pare-feu : Évitez les règles d’adresses IP clientes trop larges ; préférez Private Link avec l’accès au réseau public désactivé. Si des règles IP sont nécessaires, limitez-les à des adresses exactes et automatisez leur révision. Raisonnement : réduit la surface d’attaque et la découverte via les points de terminaison publics.
• Points de terminaison privés : Acheminez tout le trafic du plan de données sur un VNet avec un DNS privé. Raisonnement : élimine l’exposition et simplifie la prévention de l’exfiltration de données.
• Modèles d’authentification : Utilisez l’authentification intégrée Active Directory (pour les appareils joints à un domaine) ou le flux interactif/code d’appareil pour obtenir des jetons ; les charges de travail de service doivent utiliser des identités managées. Raisonnement : supprime les mots de passe et permet de gérer les durées de vie/politiques des jetons.

Fonctionnalités de protection des données

• Transparent Data Encryption (TDE) : Activé par défaut ; chiffre les données/journaux/sauvegardes. Raisonnement : protège les supports au repos sans modification applicative. Utilisez TDE avec une CMK pour un contrôle externalisé.
• Always Encrypted : Chiffrement côté client pour les colonnes sensibles avec des clés dans Key Vault. Raisonnement : empêche les opérateurs SQL ou le moteur de voir le texte en clair ; à utiliser pour les champs contenant des informations PII/PCI.
• Dynamic Data Masking (DDM) : Obfusque les résultats des requêtes pour les utilisateurs non privilégiés. Raisonnement : réduit l’exposition accidentelle des données mais ne constitue pas une barrière de sécurité ; à combiner avec le RBAC.
• Audit : Envoyez les journaux à Log Analytics, Event Hubs ou un compte de stockage. Raisonnement : crée une piste immuable pour les enquêtes et la conformité.

Exemple : activer l’audit au niveau du serveur vers Log Analytics

az sql server audit-policy update \
  --name sql-secure \
  --resource-group rg-secure \
  --state Enabled \
  --log-analytics-workspace /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.OperationalInsights/workspaces/la-secure

Microsoft Defender for SQL

• Évaluation des vulnérabilités (VA) : Établit des bases de référence et analyse le schéma/la configuration ; exporte vers un compte de stockage ; s’intègre aux portes de validation DevSecOps. Raisonnement : hygiène continue et détection de dérive avec des conseils de remédiation clairs.
• Détection des menaces : Détecte l’injection SQL, les connexions anormales, les connexions depuis un emplacement inhabituel, les privilèges abusifs. Raisonnement : détection gérée avec une faible charge opérationnelle ; complète les contrôles réseau.
• Réponse aux alertes : Acheminez les alertes vers Logic Apps, des e-mails, un SIEM. Créez des playbooks pour le tri, la suspension d’utilisateurs, la révocation de jetons et le renforcement du pare-feu. Raisonnement : une réponse codifiée réduit le temps moyen de confinement (MTTC).

Sécurité d’Azure Cosmos DB

• Clés et jetons : Les clés primaires/secondaires sont hautement privilégiées ; effectuez une rotation régulière. Préférez le RBAC Azure AD pour les opérations du plan de données avec des rôles comme Cosmos DB Built-in Data Contributor/Reader. Raisonnement : accès lié à l’identité avec l’accès conditionnel (CA) et l’audit.
• Contrôles réseau : Liste d’autorisation du pare-feu IP pour les cas d’urgence ; points de terminaison privés (Private Endpoints) comme chemin par défaut ; désactivez l’accès public si possible. Raisonnement : contrôle de chemin garanti et validation du point de terminaison.
• Chiffrement : Au repos par défaut ; activez la CMK pour un contrôle supplémentaire. Raisonnement : répond aux exigences de chiffrement externes et à la séparation des tâches.
• Journaux de diagnostic et métriques : Activez les catégories DataPlaneRequests, ControlPlaneRequests et les catégories spécifiques à l’API (par ex., MongoRequests). Raisonnement : observabilité de bout en bout pour les modèles d’accès, la limitation (throttling) et les requêtes anormales.

Contrôles de Surveillance, de Classification et d’Exfiltration

Secrets et chaînes de connexion adossés à Key Vault

• Utilisez les identités managées pour récupérer les secrets/clés à l’exécution ; ne stockez jamais de secrets dans le code ou les paramètres. Justification : élimine la prolifération des informations d’identification et la rotation des secrets dans les applications.
• Référence Key Vault pour App Service/Functions

ConnectionStrings__Sql=@Microsoft.KeyVault(SecretUri=https://mykv.vault.azure.net/secrets/sql-connstr/)

• Préférez les jetons d’accès Azure AD à SQL plutôt que les chaînes de connexion basées sur des secrets lorsque c’est possible. Justification : politique et révocation plus robustes.

Protection de l’information et classification des données

• Étiquettes de sensibilité Microsoft Purview Information Protection : Appliquez des étiquettes avec chiffrement et droits d’utilisation pour les documents et les e-mails ; intégrez avec l’étiquetage automatique. Justification : protection persistante au-delà des limites du stockage.
• SQL Information Protection (Azure SQL) : Utilisez la découverte et la classification des données intégrées, recommandez des étiquettes sur les colonnes et exportez vers Purview. Justification : gouvernance centrale et politique cohérente sur l’ensemble du patrimoine de données.

Contrôles d’exfiltration de données et modèles d’accès sécurisé

• Private Link en priorité : Pour Storage, SQL et Cosmos DB. Désactivez les points de terminaison publics. Justification : empêche l’accès depuis l’Internet public et impose que l’origine du trafic provienne de VNets approuvés.
• Filtrage de sortie (egress) : Utilisez Azure Firewall avec des balises FQDN et des règles DNAT qui autorisent uniquement les points de terminaison Azure requis ; ajoutez des stratégies de point de terminaison de service là où Private Link n’est pas pratique. Justification : la liste blanche (allow-listing) en sortie bloque la fuite de données vers des points de terminaison contrôlés par des attaquants.
• Règles d’instance de ressource : Pour le pare-feu Storage, autorisez uniquement des instances de ressources de confiance spécifiques (par exemple, un espace de travail Synapse) à y accéder. Justification : lie l’accès à des producteurs/consommateurs connus, et pas seulement à des réseaux.
• Durcissement des SAS : Utilisez des SAS de délégation d’utilisateur lorsque c’est possible, limitez à HTTPS, restreignez les adresses IP, appliquez des permissions minimales et les durées de vie les plus courtes ; liez à des stratégies d’accès stockées pour la révocation. Justification : réduit l’utilisation abusive des jetons et simplifie l’invalidation d’urgence.
• AKS et points de terminaison de service : Si vous vous fiez aux points de terminaison de service, utilisez Azure CNI pour que les pods obtiennent des adresses IP du VNet et héritent de l’accès au point de terminaison. Justification : fait le pont entre le trafic des conteneurs et les contrôles natifs du VNet ; sinon, les points de terminaison ne s’appliquent pas au trafic des pods passant par NAT.
• Journalisation et analytique : Activez les journaux de diagnostic de Storage, SQL et Cosmos DB vers Log Analytics ; créez des alertes pour les volumes de données anormaux, les pics d’émission de SAS et les erreurs 403 fréquentes. Justification : détection précoce des tentatives d’exfiltration.

Scénario de Problème Pratique

Spotify doit empêcher l’exfiltration de données depuis les sous-réseaux des développeurs et les charges de travail AKS vers des points de terminaison Storage et SQL non autorisés, tout en permettant aux pipelines CI/CD d’exécuter des tests d’intégration.

1. Désactivez l’accès au réseau public et créez des Private Endpoints pour tous les comptes Storage et serveurs Azure SQL de production. Justification : Force tous les flux du plan de données à passer par Private Link, éliminant l’entrée/sortie (ingress/egress) publique et permettant une application stricte de l’origine via les VNets et le DNS privé.

2. Configurez des zones DNS privées avec des enregistrements A mappant les FQDN des ressources de stockage et de base de données aux adresses IP des points de terminaison privés ; liez tous les VNets requis. Justification : Empêche la fuite DNS vers des points de terminaison publics et garantit que les clients résolvent les noms vers les ressources privées prévues.

3. Dans les pare-feu Storage, ajoutez des règles d’instance de ressource uniquement pour les identités du cluster AKS de production et de l’ensemble de mise à l’échelle des agents de build ; définissez l’action par défaut sur refuser. Justification : Même au sein du même VNet, seules les identités de ressources approuvées peuvent accéder au compte, déjouant ainsi les mouvements latéraux et l’exfiltration depuis des charges de travail non fiables.

4. Imposez Azure CNI sur AKS et activez les points de terminaison de service avec des stratégies de point de terminaison de service pour permettre aux espaces de noms de développement d’atteindre uniquement un compte de stockage dédié hors production. Justification : Les pods de développement obtiennent des adresses IP du VNet afin que les stratégies réseau s’appliquent ; les stratégies de point de terminaison limitent strictement tout trafic non privé aux comptes autorisés.

5. Remplacez les clés partagées par Azure AD RBAC pour Blob et Queue dans le code de l’application ; lorsque le partage est inévitable pour les tests, émettez des SAS de délégation d’utilisateur avec des stratégies d’accès stockées et une expiration d’une heure. Justification : Les jetons liés à une identité sont auditables et révocables ; les SAS à courte durée de vie minimisent le risque si un jeton est exposé dans les journaux de build.

6. Activez Defender for SQL avec la détection des menaces et l’évaluation des vulnérabilités ; acheminez les alertes et les journaux d’audit SQL vers un espace de travail Log Analytics central avec des Logic Apps automatisées pour le triage (désactiver l’utilisateur, révoquer les sessions, ajouter un refus temporaire au pare-feu). Justification : Les détections managées accélèrent le confinement des injections SQL et des accès anormaux, tandis que les playbooks standardisent et accélèrent la réponse.

7. Utilisez Key Vault pour la CMK protégeant TDE et les étendues de chiffrement de Storage ; activez la suppression réversible (soft delete) et la protection contre la purge ; effectuez une rotation trimestrielle des clés et mettez à jour les références des ressources vers la dernière version de la clé. Justification : Le contrôle cryptographique externalisé avec une rotation sécurisée répond aux exigences de conformité et réduit le risque d’erreur opérationnelle.

8. Classifiez les colonnes sensibles dans Azure SQL avec SQL Information Protection et intégrez-les à Microsoft Purview ; appliquez des étiquettes de sensibilité MIP pour les exportations en aval. Justification : L’étiquetage persistant accompagne les extractions de données, limitant l’utilisation abusive et permettant aux outils DLP d’appliquer des contrôles sur l’ensemble des outils et des appareils.

9. Verrouillez la sortie (egress) avec Azure Firewall pour n’autoriser que les services Azure requis par la compilation/test, en utilisant des balises FQDN pour Storage et SQL et en refusant le trafic HTTP(S) sortant générique (wildcard). Justification : Le modèle de sécurité positif garantit que le trafic ne peut atteindre que les points de terminaison approuvés, empêchant les données de sortir vers des domaines d’attaquants.

Cette séquence empêche l’accès public, restreint qui et quoi peut atteindre les données, lie l’accès à des identités plutôt qu’à des secrets, et opérationnalise la surveillance et la réponse rapide — tout en préservant la vélocité des développeurs grâce à des exceptions ciblées et limitées dans le temps.

← Sécurité du calcul · Tous les domaines · Gestion des clés →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Microsoft →