Microsoft AZ-204: Authentification, autorisation et sécurité Azure — Guide d'étude

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Developer Associate AZ-204 — 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

L’authentification et l’autorisation Azure reposent sur la plateforme d’identités Microsoft, qui émet des jetons (tokens) pour les identités (utilisateurs, applications, workloads) et contrôle l’accès aux API et aux ressources. Les applications s’intègrent via OAuth 2.0 et OpenID Connect, acquièrent des jetons avec MSAL et demandent des permissions déclarées dans les inscriptions d’applications Azure AD. Les workloads s’exécutant sur Azure peuvent éliminer complètement les informations d’identification en utilisant les identités managées et s’appuyer sur Azure RBAC pour accéder à des services comme Key Vault, Storage et Microsoft Graph. La gestion des secrets est centrée sur Azure Key Vault, avec une séparation claire entre l’accès au plan de données (data-plane) du coffre et le contrôle du plan de gestion (management-plane), et avec de solides garanties de récupération grâce à la suppression réversible (soft delete) et à la protection contre la purge. Pour le stockage, les signatures d’accès partagé (SAS) fournissent une délégation d’accès limitée en portée et dans le temps aux clients, sans exposer les clés de compte.

Plateforme d’identités Microsoft, OAuth 2.0, MSAL et inscriptions d’applications

La plateforme d’identités Microsoft prend en charge plusieurs flux OAuth 2.0 optimisés pour différents types d’applications :

• Flux de code d’autorisation (Authorization code flow) : Le standard pour les applications web, les SPA et les applications natives. Les clients publics doivent utiliser PKCE pour protéger le code d’autorisation. Les applications redirigent les utilisateurs vers le point de terminaison d’autorisation (authorize endpoint), reçoivent un code d’autorisation sur l’URI de redirection, puis l’échangent au point de terminaison de jeton (token endpoint) contre un jeton d’accès (et éventuellement un jeton de rafraîchissement). Pour les SPA, le flux de code d’autorisation + PKCE remplace l’ancien flux implicite et atténue les fuites de jetons.
• Flux d’informations d’identification du client (Client credentials flow) : Utilisé par les démons et les services de serveur à serveur sans utilisateur. L’application demande des jetons en utilisant une assertion de client (certificat) ou un secret client. Seules les permissions d’application (rôles d’application) sont disponibles ici, et la plupart d’entre elles nécessitent un consentement de l’administrateur. Ce flux utilise la portée (scope) /.default pour demander l’ensemble des permissions d’application configurées statiquement.
• Flux de code d’appareil (Device code flow) : Conçu pour les appareils ou les environnements sans navigateur intégré. L’application obtient un code utilisateur et une URL de vérification de la part de la plateforme d’identités, l’utilisateur s’authentifie sur un appareil distinct, et l’application interroge (polls) le point de terminaison de jeton. Les permissions déléguées s’appliquent car un utilisateur se connecte.
• Flux d’octroi implicite (Implicit grant flow) : Historiquement utilisé par les SPA pour recevoir des jetons directement depuis le point de terminaison d’autorisation. Il est maintenant déconseillé au profit du flux de code d’autorisation avec PKCE. S’il est utilisé, un URI de redirection est toujours requis lors de l’inscription de l’application.

MSAL (Microsoft Authentication Library) fournit une acquisition de jetons cohérente entre les langages et les plateformes. Les applications clientes publiques (desktop, mobile, SPA) utilisent AcquireTokenInteractive et AcquireTokenSilent pour obtenir et mettre en cache les jetons ; les applications natives utiliseront également AcquireTokenByDeviceCode pour le flux de code d’appareil et AcquireTokenByAuthorizationCode pour l’échange du code d’autorisation dans des contextes de client confidentiel. Les clients confidentiels (applications web/API/démons) acquièrent des jetons avec AcquireTokenForClient lors de l’utilisation d’informations d’identification du client et AcquireTokenOnBehalfOf pour les scénarios OBO (On-Behalf-Of) où une API appelle des API en aval avec le contexte délégué d’un utilisateur.

La mise en cache des jetons est intégrale à MSAL : elle stocke les jetons d’accès et de rafraîchissement indexés par compte, client et portée (scope), permettant à AcquireTokenSilent d’éviter les invites interactives inutiles. Les applications web et les API s’exécutant sur plusieurs instances doivent persister et protéger le cache de jetons en utilisant un stockage partagé et chiffré (par ex., un cache distribué avec un chiffrement approprié au repos et en transit). Les hooks de sérialisation du cache dans MSAL permettent une persistance sécurisée. Les portées (scopes) identifient les permissions qu’une application demande. Pour les permissions déléguées, demandez les portées minimales et spécifiques à la ressource (par ex., https://graph.microsoft.com/User.Read). Pour les informations d’identification du client, demandez la portée /.default basée sur la ressource, qui correspond aux permissions d’application accordées statiquement à l’application (par ex., scope = https://graph.microsoft.com/.default). Utilisez le consentement incrémentiel pour demander des portées progressivement et réduire les frictions.

Les inscriptions d’applications Azure AD définissent l’identité de l’application, ses informations d’identification, ses URI de redirection et ses permissions. Les permissions déléguées nécessitent un utilisateur connecté et peuvent souvent être consenties par les utilisateurs eux-mêmes pour leurs propres données ; les permissions d’application sont accordées à l’application elle-même et nécessitent presque toujours le consentement d’un administrateur car elles s’appliquent à l’échelle du tenant ou de manière large. Les applications qui exposent des API déclarent des portées (scopes) (pour les permissions déléguées) et des rôles d’application (app roles) (pour les permissions d’application) sous la section « Exposer une API ». Configurez l’accès en mode single-tenant ou multi-tenant en fonction des limites de confiance, et utilisez des certificats plutôt que des secrets clients pour des informations d’identification plus robustes et une rotation plus facile.

Microsoft Graph utilise la même émission de jetons. Authentifiez-vous avec MSAL en ciblant la ressource Graph et demandez les portées du moindre privilège. Les points de terminaison courants incluent :

• GET https://graph.microsoft.com/v1.0/me pour le profil utilisateur avec des jetons délégués (par ex., User.Read)
• GET https://graph.microsoft.com/v1.0/users et /groups pour les objets de l’annuaire (nécessite des permissions déléguées ou d’application appropriées telles que User.Read.All ou Group.Read.All)
• GET https://graph.microsoft.com/v1.0/sites ou /drives pour les opérations SharePoint/OneDrive Lorsque vous utilisez des informations d’identification du client, demandez la portée /.default et assurez-vous que le consentement de l’administrateur existe pour les permissions d’application requises. Choisissez la bonne autorité (spécifique au tenant par rapport à common/organizations) pour contrôler où les utilisateurs peuvent se connecter et où les jetons peuvent être émis.

Identités managées et accès sécurisé aux ressources Azure, plus les références Key Vault

Les identités managées pour les ressources Azure éliminent les secrets en permettant à Azure de gérer les informations d’identification des principaux de service. Les identités managées affectées par le système sont liées 1:1 à une ressource (App Service, Function App, VM, VMSS, Logic App, etc.) et partagent son cycle de vie ; lorsque la ressource est supprimée, l’identité l’est également. Les identités managées affectées par l’utilisateur sont créées en tant que ressources Azure autonomes qui peuvent être attachées à plusieurs ressources de calcul et existent indépendamment du cycle de vie d’une charge de travail unique. Ce modèle prend en charge la réutilisation des identités et la séparation des tâches.

Pour accéder aux ressources Azure avec une identité managée, accordez-lui le rôle Azure RBAC approprié à la bonne portée :

• Pour le plan de données Azure Storage avec Azure AD, assignez des rôles comme Lecteur/Contributeur aux données Blob de stockage (Storage Blob Data Reader/Contributor) au niveau d’un compte de stockage, d’un conteneur, ou à la portée d’un groupe de ressources/abonnement.
• Pour Key Vault (modèle de plan de données RBAC), assignez des rôles tels que Utilisateur des secrets Key Vault (Key Vault Secrets User) ou Agent de chiffrement Key Vault (Key Vault Crypto Officer).
• Pour Microsoft Graph via les autorisations d’application, les identités managées ne peuvent appeler les API en aval qu’après l’association d’une inscription d’application. Utilisez la fédération d’identité de charge de travail ou configurez les autorisations de l’application d’entreprise et le consentement de l’administrateur selon les besoins.

Au moment de l’exécution, utilisez le service de métadonnées d’instance (IMDS) sur les VM ou le point de terminaison géré par App Service pour obtenir des jetons ; les SDK comme DefaultAzureCredential d’Azure Identity utiliseront automatiquement le point de terminaison de l’identité managée lorsqu’il est disponible. Cela élimine le besoin de stocker des secrets et prend en charge la rotation par la plateforme.

Les références Key Vault dans App Service et Azure Functions permettent de récupérer en toute sécurité des secrets dans les paramètres d’application sans modification du code. Dans la valeur d’un paramètre d’application, utilisez la syntaxe de référence @Microsoft.KeyVault(SecretUri=https://{vault-name}.vault.azure.net/secrets/{name}/{version}). La plateforme résout la référence en utilisant l’identité managée de l’application au démarrage et la rafraîchit périodiquement. Assurez-vous que l’identité managée dispose de l’autorisation Get pour les secrets via les stratégies d’accès Key Vault ou le rôle Utilisateur des secrets Key Vault (Key Vault Secrets User) lors de l’utilisation du modèle de plan de données RBAC. Les références Key Vault sont idéales pour les valeurs de configuration qui ne devraient jamais être stockées en texte clair dans le magasin de configuration de l’application et suppriment la logique de gestion des secrets du code de l’application.

Azure Key Vault : Secrets, Clés, Certificats et Contrôle d’accès

Azure Key Vault stocke trois types d’objets :

• Secrets : Chaînes opaques telles que des mots de passe, des chaînes de connexion ou des clés d’API. Versionnés ; les clients effectuent généralement des opérations Get et Set.
• Clés : Clés cryptographiques (RSA, EC) utilisées pour les opérations de signature/vérification, de chiffrement/déchiffrement et d’encapsulation/désencapsulation (wrap/unwrap). Le matériel de clé est protégé par le service soutenu par des HSM ; les clients appellent les opérations de chiffrement via le service plutôt que d’exporter le matériel de la clé privée.
• Certificats : Objets X.509 avec gestion du cycle de vie, éventuellement intégrés avec des autorités de certification (CA) partenaires. Les certificats se matérialisent sous la forme d’un certificat plus un secret correspondant (PFX) et, en option, une clé managée.

La suppression réversible (soft delete) est activée par défaut, préservant les objets supprimés pendant une fenêtre de rétention. Activez la protection contre le vidage (purge protection) pour empêcher la suppression irréversible pendant la période de rétention et pour appliquer des garanties de récupération (souvent une exigence de rétention de 90 jours). Combinez la suppression réversible et la protection contre le vidage pour répondre à des politiques de récupération strictes. De plus, sécurisez l’accès réseau au coffre avec des points de terminaison privés et désactivez l’accès réseau public lorsque c’est possible.

Le contrôle d’accès peut utiliser les anciennes stratégies d’accès au coffre (vault access policies) ou Azure RBAC pour le plan de données. Les stratégies d’accès sont configurées par coffre et accordent explicitement des autorisations (Get, List, Set, Sign, Wrap) aux principaux ; elles ne sont pas héritées et peuvent devenir lourdes à gérer à grande échelle. Le modèle de plan de données RBAC utilise des rôles Azure (par ex., Administrateur Key Vault, Agent des secrets Key Vault, Utilisateur des secrets Key Vault, Agent de chiffrement Key Vault) et prend en charge la portée au niveau de l’abonnement, du groupe de ressources ou du coffre avec un audit intégré à Azure RBAC. Choisissez un modèle ; si RBAC est activé pour le plan de données, les stratégies d’accès sont ignorées. Les opérations du plan de gestion (création/mise à jour du coffre) utilisent toujours Azure RBAC.

Intégrez Key Vault avec les applications en utilisant les SDK Azure (par ex., SecretClient, KeyClient, CertificateClient) et DefaultAzureCredential. Préférez les identités managées pour l’authentification, évitez d’intégrer des informations d’identification en dur et mettez en œuvre des politiques de nouvelle tentative (retry) et de limitation (throttling) lors de l’appel des API du coffre.

SAS Azure Storage et stratégies d’accès stockées

Les signatures d’accès partagé (SAS) délèguent un accès précis et limité dans le temps à Azure Storage sans révéler les clés de compte :

• SAS de délégation d’utilisateur (Blob uniquement) : Adossée à Azure AD. L’application obtient une clé de délégation d’utilisateur auprès du service Blob en utilisant des informations d’identification Azure AD, puis crée des jetons SAS pour les clients. C’est l’approche la plus sécurisée pour les scénarios centrés sur l’utilisateur car elle évite l’utilisation des clés de compte et s’aligne sur l’autorisation basée sur les rôles.
• SAS de service : Limitée à une ressource spécifique (blob, conteneur, message de file d’attente, entité de table, fichier). Signée avec une clé de compte. Prend en charge des autorisations telles que la lecture, l’écriture, l’ajout, la création, la suppression, la liste, la définition de l’immuabilité et les balises en fonction du service.
• SAS de compte : Portée la plus large sur plusieurs services (Blob, Queue, Table, File) et types de ressources. À utiliser avec parcimonie en raison du large rayon d’impact.

Les jetons SAS incluent des contraintes telles que l’heure d’expiration (se), l’heure de début (st), les autorisations (sp), les plages d’adresses IP (sip), les protocoles autorisés (spr), la ressource signée (sr) et, lorsqu’ils sont liés à une stratégie d’accès stockée, un identifiant signé (si). Suivez le principe du moindre privilège en n’accordant que les autorisations nécessaires, en gardant des expirations courtes et en imposant HTTPS (spr=https). Préférez la SAS de délégation d’utilisateur lorsque c’est possible ; sinon, utilisez une SAS de service avec une stratégie d’accès stockée pour la révocation.

Les stratégies d’accès stockées résident sur les conteneurs, les partages de fichiers, les files d’attente ou les tables et définissent un ensemble réutilisable de contraintes (autorisations, début, expiration). Lors de la création d’une SAS, référencez la stratégie par son identifiant. Cela permet une révocation centralisée ou un resserrement de la portée sans avoir à réémettre tous les jetons SAS ; la mise à jour ou la suppression de la stratégie affecte immédiatement tous les jetons SAS qui y sont liés. Effectuez une rotation régulière des clés de compte si des SAS de service ou de compte sont utilisées, et surveillez l’utilisation via les paramètres de diagnostic et les journaux Azure Monitor.

Scénario de problème pratique

Adobe déploie un portail de traitement multimédia multi-locataire sur Azure. Les clients se connectent avec leurs propres tenants Microsoft Entra ID, téléversent de gros fichiers multimédias directement dans le stockage Blob et suivent l’état du traitement. La solution doit éviter de stocker des secrets, centraliser les autorisations et garantir la récupérabilité des secrets pendant au moins 90 jours.

1. Inscrire les applications dans Microsoft Entra ID :

   • Créer une SPA pour l’interface utilisateur du portail et un client confidentiel pour l’API backend. Exposer des portées d’API pour l’accès délégué et définir des rôles d’application pour les tâches en arrière-plan. Configurer la SPA pour utiliser le flux de code d’autorisation + PKCE avec des URI de redirection exacts. Cela aligne chaque client sur le flux OAuth correct et impose des limites de consentement basées sur le moindre privilège.

2. Implémenter MSAL dans la SPA et le backend :

   • La SPA acquiert des jetons pour l’API backend en utilisant AcquireTokenInteractive/AcquireTokenSilent avec un consentement incrémentiel. Le backend utilise AcquireTokenOnBehalfOf pour appeler Microsoft Graph afin de lire le profil de base de l’utilisateur connecté. Cela préserve le contexte utilisateur de bout en bout et minimise les invites grâce à la mise en cache des jetons.

3. Activer les identités managées affectées par le système sur App Service (API) et Azure Functions (processeurs multimédias) :

   • Attribuer le rôle Contributeur aux données Blob du stockage sur le conteneur multimédia et Utilisateur des secrets Key Vault sur le coffre. Les identités managées éliminent la prolifération des secrets et permettent à la plateforme d’effectuer une rotation automatique des informations d’identification tout en permettant un accès sécurisé à Storage et Key Vault via Azure RBAC.

4. Configurer Azure Key Vault avec le plan de données RBAC, la suppression réversible (soft delete) et la protection contre la purge :

   • Stocker les certificats de signature pour l’assertion du backend, les clés d’API tierces et tout secret de connexion ne pouvant être remplacé par AAD. Imposer la protection contre la purge en plus de la suppression réversible pour garantir la récupération pendant 90 jours. Le RBAC simplifie l’audit et s’adapte à plusieurs environnements par rapport aux stratégies d’accès par coffre.

5. Utiliser les références Key Vault pour la configuration :

   • Référencer les secrets dans les paramètres d’application d’App Service et de Functions en utilisant @Microsoft.KeyVault(SecretUri=…). La plateforme résout et actualise les valeurs avec l’identité managée, éliminant les modifications de code et empêchant le stockage des secrets en texte clair dans la configuration.

6. Déléguer les téléversements directs depuis le navigateur avec des SAS :

   • Le backend émet des jetons SAS de délégation d’utilisateur pour un accès de courte durée en écriture seule à un chemin de blob spécifique, limité par IP et HTTPS. Pour les outils de traitement par lots opérationnels, créer des SAS de service liées à une stratégie d’accès stockée sur le conteneur afin que les jetons puissent être révoqués de manière centralisée en mettant à jour ou en supprimant la stratégie. Cela permet des téléversements clients à haut débit sans exposer les clés de compte et prend en charge la révocation d’urgence.

7. Intégrer Microsoft Graph de manière minimale :

   • Demander https://graph.microsoft.com/User.Read dans la SPA pour l’affichage du profil et utiliser https://graph.microsoft.com/.default dans le backend si des autorisations d’application sont requises (avec le consentement préalable de l’administrateur). L’utilisation de /.default garantit que le backend respecte les autorisations d’application accordées de manière centralisée et évite de demander des portées excessives à l’exécution.

Cette conception utilise le flux de code d’autorisation + PKCE pour sécuriser la SPA, OBO pour préserver le contexte utilisateur en aval, les identités managées et le RBAC pour éliminer les secrets, Key Vault avec de solides garanties de récupération, les références Key Vault pour l’hygiène de la configuration, Graph avec des portées de moindre privilège, et les SAS avec des stratégies d’accès stockées pour des téléversements clients sécurisés et révocables.

← Solutions de conteneurs Azure · Tous les domaines · Gestion des API Azure →

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

Parcourir Microsoft →