Planifier votre solution d’émission Vérification d’identité Microsoft Entra
Il est important de planifier votre solution d’émission afin qu’en plus d’émettre des informations d’identification, vous disposiez d’une vue complète de l’impact sur l’architecture et l’activité de votre solution. Si vous ne l’avez pas encore fait, nous vous recommandons de consulter la présentation de l’architecture Vérification d’identité Microsoft Entra pour obtenir des informations de base.
Étendue des recommandations
Cet article aborde les aspects techniques de la planification d’une solution d’émission d’informations d’identification vérifiables. La solution Microsoft pour les justificatifs d’identité vérifiables suit les normes Verifiable Credentials Data Model 1.0 et Decentralized Identifiers (DIDs) V1.0 du World Wide Web Consortium (W3C), de sorte à être interopérable avec des services non Microsoft. Toutefois, les exemples de ce contenu reflètent la pile de solutions Microsoft pour les justificatifs vérifiables.
Les articles relatifs aux technologies de prise en charge qui ne sont pas propres aux solutions d’émission ne sont pas traités dans ce contenu. Par exemple, des sites web sont utilisés dans une solution d’émission de justificatifs vérifiables, mais la planification d’un déploiement de site web n’est pas traitée en détail.
Composants de la solution
Dans le cadre de votre plan pour une solution d’émission, vous devez concevoir une solution qui permet les interactions entre l’émetteur, l’utilisateur et le vérificateur. Le diagramme suivant montre les composants de votre architecture d’émission.
Architecture de la solution d’émission de justificatifs vérifiables Microsoft
Locataire Microsoft Entra
Un prérequis à l’exécution du service Vérification d’identité Microsoft Entra est le fait qu’il soit hébergé dans un locataire Microsoft Entra. Le locataire Microsoft Entra fournit un plan de contrôle de gestion des identités et des accès (IAM) pour les ressources Azure qui font partie de la solution.
Chaque locataire utilise le service Vérification d’identité Microsoft Entra multilocataire et possède un identificateur décentralisé (DID). Le DID fournit une preuve que l’émetteur possède le domaine incorporé dans le DID. Le DID est utilisé par le sujet et le vérificateur pour valider l’émetteur.
Services Microsoft Azure
Le service Azure Key Vault stocke vos clés d’émetteur, qui sont générées lorsque vous lancez le service d’émission Vérification d’identité Microsoft Entra. Les clés et métadonnées sont utilisées pour exécuter des opérations de gestion des informations d’identification et assurer la sécurité des messages.
Chaque émetteur possède un ensemble de clés unique utilisé pour la signature, la mise à jour et la récupération. Ce jeu de clés est utilisé pour chaque émission de tous les justificatifs vérifiables que vous produisez.
Le service Vérification d’identité Microsoft Entra est utilisé pour stocker les métadonnées et les définitions des informations d’identification, plus précisément les définitions d’affichage et de règles pour vos informations d’identification.
Les définitions d’affichage déterminent la façon dont les revendications sont affichées dans le portefeuille du détenteur, et incluent également la personnalisation et d’autres éléments. La définition d’affichage peut être localisée en plusieurs langues. Consultez Comment personnaliser vos justificatifs vérifiables.
Les règles sont un modèle défini par l’émetteur qui décrit les entrées requises des informations d’identification vérifiables. Les règles définissent également des sources d’entrée approuvées et le mappage des revendications d’entrée aux revendications de sortie stockées dans les informations d’identification vérifiables. En fonction du type d’attestation défini dans la définition de règles, les revendications d’entrée peuvent provenir de différents fournisseurs. Les revendications d’entrée peuvent provenir d’un fournisseur d’identité OIDC, d’un id_token_hint ou de revendications autodéclarées lors de l’émission par une entrée utilisateur dans le portefeuille.
- Entrée - Un sous-ensemble du modèle dans le fichier de règles pour la consommation du client. Le sous-ensemble doit décrire le jeu d’entrées, où obtenir les entrées et le point de terminaison à appeler pour obtenir des justificatifs vérifiables.
Service Vérification d’identité Microsoft Entra
Le service Vérification d’identité Microsoft Entra vous permet d’émettre et de révoquer des informations d’identification vérifiables en fonction de votre configuration. Le service :
Provisionne l’identificateur décentralisé (DID). Chaque émetteur a un seul DID par locataire.
Approvisionne les jeux de clés pour Key Vault.
Stocke les métadonnées de configuration utilisées par le service d’émission et Microsoft Authenticator.
Fournit une interface API REST pour les front-ends web de l’émetteur et du vérificateur
Système d’approbation
Vérification d’identité Microsoft Entra prend actuellement en charge DID Web en tant que système d’approbation, où le document DID est hébergé sur le serveur web des émetteurs.
Application Microsoft Authenticator
Microsoft Authenticator est l’application mobile. Authenticator orchestre les interactions entre l’utilisateur, le service Vérification d’identité Microsoft Entra et le contrat utilisé pour émettre des justificatifs vérifiables. Il agit comme un portefeuille numérique dans lequel le détenteur des justificatifs vérifiables stocke les justificatifs vérifiables, y compris la clé privée de l’objet des justificatifs vérifiables. Authenticator est également le mécanisme utilisé pour présenter les justificatifs vérifiables à des fins de vérification.
Logique métier d’émission
Votre solution d’émission comprend un serveur web frontal dans lequel les utilisateurs demandent des justificatifs vérifiables, un magasin d’identités et ou un autre magasin d’attributs pour obtenir des valeurs pour les revendications relatives au sujet et d’autres services principaux.
Un serveur web frontal sert les requêtes d’émission au portefeuille du sujet en générant des liens profonds ou des codes QR. En fonction de la configuration du contrat, d’autres composants peuvent être requis pour répondre aux conditions requises pour créer un circuit virtuel.
Ces services fournissent des rôles de soutien qui n’ont pas nécessairement besoin d’être intégrés au service d’émission Vérification d’identité Microsoft Entra. Cette couche comprend généralement les éléments suivants :
Un ou des services conformes OpenID Connect (OIDC) sont utilisés pour obtenir les id_tokens nécessaires pour émettre les justificatifs vérifiables. Les systèmes d’identité existants comme Microsoft Entra ID ou Azure AD B2C peuvent fournir le service conforme à OIDC, tout comme les solutions personnalisées comme le serveur d’identités.
Magasins d’attributs – Les magasins d’attributs peuvent se trouver en dehors des services d’annuaire et fournir les attributs nécessaires pour émettre des justificatifs vérifiables. Par exemple, un système d’informations sur les étudiants peut fournir des revendications sur les diplômes obtenus.
Des services de niveau intermédiaire supplémentaires qui contiennent des règles d’entreprise pour les recherches, la validation, la facturation et tout autre contrôle et workflow nécessaire à l’émission d’informations d’identification.
Pour plus d’informations sur la configuration de votre serveur web frontal, consultez le tutoriel Configurer Microsoft Entra ID pour émettre des justificatifs vérifiables.
Considérations relatives à la conception des informations d’identification
Vos cas d’utilisation spécifiques déterminent la conception de vos informations d’identification. Le cas d’usage détermine :
Les exigences relatives à l’interopérabilité
La façon dont les utilisateurs doivent prouver leur identité pour accéder à leurs justificatifs vérifiables
Les revendications nécessaires dans les informations d’identification
Si les informations d’identification doivent être révoquées
Cas d’utilisation des justificatifs
Avec Vérification d’identité Microsoft Entra, les cas d’usage des informations d’identification les plus courants sont les suivants :
Vérification de l’identité : Des informations d’identification sont émises en fonction de plusieurs critères. Ces critères multiples peuvent inclure la vérification de l’authenticité des documents émis par le gouvernement, comme un passeport ou un permis de conduire, et la corrélation des informations contenues dans ce document avec d’autres informations comme :
Un selfie de l’utilisateur
Une vérification de l’activité
Ce type d’informations d’identification est adapté aux scénarios d’intégration d’identité de nouveaux employés, partenaires, fournisseurs de services, étudiants et autres instances où la vérification d’identité est essentielle.
Preuve d’emploi/appartenance : Des informations d’identification sont émises pour prouver une relation entre l’utilisateur et une institution. Ce type d’informations d’identification est un bon choix pour accéder aux applications interentreprises faiblement couplées, comme les détaillants proposant des remises aux employés ou étudiants. L’une des principales valeurs des justificatifs vérifiables est leur portabilité : une fois émis, l’utilisateur peut utiliser les justificatifs vérifiables dans de nombreux scénarios.
Pour plus de cas d’utilisation, consultez Cas d’utilisation des justificatifs vérifiables (w3.org).
Interopérabilité des informations d’identification
Dans le cadre du processus de conception, recherchez des schémas, des espaces de noms et des identificateurs spécifiques au secteur que vous pouvez aligner pour optimiser l’interopérabilité et l’utilisation. Vous trouverez des exemples sur Schema.org et DIF - Claims and Credentials Working Group.
Les schémas courants sont un domaine dont les normes restent émergentes. Un exemple d’un tel effort est Verifiable Credentials for Education Task Force. Nous vous encourageons à étudier et à contribuer aux normes émergentes dans le secteur de votre organisation.
Type d’informations d’identification et attributs
Après avoir établi le cas d’usage pour les informations d’identification, vous devez déterminer le type des informations d’identification et les attributs à inclure dedans. Les vérificateurs peuvent lire les revendications dans les justificatifs vérifiables présentés par les utilisateurs.
Tous les informations d’identification vérifiables doivent déclarer leur type dans leur définition de règles. Le type d’informations d’identification distingue un schéma d’informations d’identification vérifiables d’autres informations d’identification, et il garantit l’interopérabilité entre les émetteurs et les vérificateurs. Pour indiquer un type d’informations d’identification, fournissez un ou plusieurs types d’informations d’identification auxquels les informations d’identification satisfont. Chaque type est une chaîne unique. Souvent, un URI est utilisé pour garantir l’unicité globale. Il n’est pas nécessaire que l’URI soit adressable. Elle est traitée comme une chaîne. Par exemple, les justificatifs de diplôme émis par Contoso University peuvent déclarer les types suivants :
| Type | Objectif |
|---|---|
https://schema.org/EducationalCredential |
Déclare que les diplômes émis par Contoso University contiennent des attributs définis par l’objet EducationaCredential de schema.org. |
https://schemas.ed.gov/universityDiploma2020 |
Déclare que les diplômes émis par Contoso University contiennent des attributs définis par le Ministère de l’Éducation américain. |
https://schemas.contoso.edu/diploma2020 |
Déclare que les diplômes émis par Contoso University contiennent des attributs définis par Contoso University. |
Outre les normes et schémas spécifiques au secteur qui peuvent s’appliquer à vos scénarios, tenez compte des aspects suivants :
Minimiser les informations privées : Répondez aux cas d’usage avec le minimum d’informations privées nécessaires. Par exemple, des justificatifs vérifiables utilisés pour des sites web d’e-commerce qui offrent des remises aux employés et étudiants peuvent être remplis en présentant les justificatifs avec uniquement les revendications de prénom et nom de famille. Des informations supplémentaires comme la date d’embauche, le titre et le service ne sont pas nécessaires.
Privilégier les revendications abstraites : Chaque revendication doit répondre au besoin tout en minimisant les détails. Par exemple, une revendication nommée « ageOver » avec des valeurs discrètes comme 13, 21, 60 est plus abstraite qu’une revendication de date de naissance.
Planifier la révocabilité : Nous vous recommandons de définir une revendication d’index pour permettre aux mécanismes de trouver et de révoquer les informations d’identification. Vous ne pouvez définir qu’une seule revendication d’index par contrat. Il est important de noter que les valeurs des revendications indexées ne sont pas stockées dans le back-end : seul un hachage de la valeur de la revendication l’est. Pour plus d’informations, consultez Révoquer un des justificatifs vérifiables précédemment émis.
Pour d’autres considérations sur les attributs des informations d’identification, consultez la spécification Verifiable Credentials Data Model 1.0 (w3.org).
Attributs de qualité du plan
Planifier les performances
Comme pour n’importe quelle solution, vous devez planifier les performances. Les points clés à prendre en compte sont la latence et la scalabilité. Pendant les phases initiales d’un cycle de mise en production, les performances ne doivent pas être un problème. Toutefois, lorsque l’adoption de votre solution d’émission entraîne l’émission de nombreux justificatifs vérifiables, la planification des performances peut devenir un élément essentiel de votre solution.
Vous trouverez ci-dessous les points à prendre en compte lors de la planification des performances :
Le service d’émission Vérification d’identité Microsoft Entra est déployé dans les régions Azure suivantes : Europe Ouest, Europe Nord, USA Ouest 2, USA Centre-Ouest, Australie et Japon. Si votre locataire Microsoft Entra réside dans l’UE, le service Vérification d’identité Microsoft Entra est également dans l’UE.
Pour limiter la latence, déployez votre site web front-end d’émission et le coffre de clés dans la région listée ci-dessus.
Modèle basé sur le débit :
Le service Émetteur est soumis aux limites du service Azure Key Vault.
Pour Azure Key Vault, il existe trois opérations de signature impliquées dans chaque émission de justificatifs vérifiables :
Une pour la requête d’émission à partir du site web
Une pour les justificatifs vérifiables créés
Une pour le téléchargement du contrat
Vous ne pouvez pas contrôler la limitation. Cependant, nous vous recommandons de lire nos Conseils sur la limitation d’Azure Key Vault.
Si vous planifiez un déploiement et une intégration de justificatifs vérifiables à grande échelle, songez à traiter par lots la création des justificatifs pour vous assurer de ne pas dépasser les limites.
Dans le cadre de votre plan de performances, déterminez ce que vous surveillez pour mieux comprendre les performances de la solution. En plus de la surveillance des sites web au niveau de l’application, tenez compte des éléments suivants lorsque vous définissez votre stratégie d’analyse des émissions de justificatifs vérifiables :
À des fins de scalabilité, envisagez d’implémenter des métriques pour les éléments suivants :
Définissez les phases logiques de votre processus d’émission. Par exemple :
Demande initiale
Remise du code QR ou lien profond
Recherche d’attribut
Appels au service d’émission Vérification d’identité Microsoft Entra
Justificatifs émis
Définissez les métriques en fonction des phases :
Nombre total de requêtes (volume)
Requêtes par unité de temps (débit)
Temps passé (latence)
Surveillez Azure Key Vault à l’aide du lien suivant :
Surveillez les composants utilisés pour votre couche de logique métier.
Planifier pour la fiabilité
Pour planifier la fiabilité, nous vous recommandons ceci :
Une fois que vous avez défini vos objectifs de disponibilité et de redondance, utilisez les guides suivants pour comprendre comment atteindre vos objectifs :
Pour les couches frontale et métier, votre solution peut se manifester de façons illimitées. Comme pour toute solution, pour les dépendances que vous identifiez, assurez-vous qu’elles sont résilientes et surveillées.
Dans les rares cas où le service d’émission Vérification d’identité Microsoft Entra ou les services Azure Key Vault deviendraient indisponibles, la solution entière devient indisponible.
Planifier pour la conformité
Il se peut que votre organisation ait des besoins spécifiques en matière de conformité par rapport à votre secteur d’activité, au type de transactions ou au pays/à la région d’exploitation.
Résidence des données : le service d’émission Vérification d’identité Microsoft Entra est déployé dans un sous-ensemble de régions Azure. Le service est utilisé uniquement pour les fonctions de calcul. Nous ne stockons pas les valeurs des informations d’identification vérifiables dans des systèmes Microsoft. Toutefois, dans le cadre du processus d’émission, les données personnelles sont envoyées et utilisées lors de l’émission des justificatifs vérifiables. L’utilisation du service d’informations d’identification vérifiables ne doit pas avoir d’incidence sur la résidence des données. Si vous stockez des informations personnelles dans le cadre de la vérification d’identité, vous devez les stocker d’une façon et dans une région qui répondent à vos exigences en matière de conformité. Pour obtenir des instructions relatives à Azure, visitez le site web du Centre de gestion de la confidentialité Microsoft.
Révoquer les informations d’identification : déterminez si votre organisation doit révoquer les informations d’identification. Par exemple, un administrateur peut avoir besoin de révoquer les informations d’identification lorsqu’un employé quitte l’entreprise. Pour plus d’informations, consultez Révoquer un des justificatifs vérifiables précédemment émis.
Informations d’identification arrivant à expiration : déterminez la façon dont vos informations d’identification expirent. Par exemple, si vous émettez des justificatifs vérifiables comme preuve de permis, ce dernier peut expirer au bout de quelques années. D’autres justificatifs vérifiables peuvent avoir une durée de validité plus courte afin que les utilisateurs les mettent régulièrement à jour.
Planifier les opérations
Lors de la planification des opérations, il est essentiel de développer un schéma à utiliser pour la résolution des problèmes, la création de rapports et la distinction entre les différents clients que vous prenez en charge. En outre, si l’équipe d’exploitation est responsable de l’exécution de la révocation des justificatifs vérifiables, ce processus doit être défini. Chaque étape du processus doit être corrélée afin que vous puissiez déterminer les entrées de journal qui peuvent être associées à chaque requête d’émission unique. Pour l’audit, nous vous recommandons de capturer chaque tentative d’émission d’informations d’identification individuellement. En particulier :
Générez des ID de transaction uniques auxquels les clients et ingénieurs du support peuvent faire référence en fonction des besoins.
Élaborez un mécanisme permettant de corréler les journaux des transactions d’Azure Key Vault aux ID de transaction de la partie émission de la solution.
Si vous êtes un service de vérification des identités émettant des justificatifs vérifiables pour le compte de plusieurs clients, surveillez et atténuez la création de rapports et la facturation côté client par ID de client ou de contrat.
Si vous êtes un service de vérification des identités émettant des justificatifs vérifiables pour le compte de plusieurs clients, utilisez l’ID de client ou de contrat pour la création de rapports et la facturation côté client, la surveillance et l’atténuation.
Planifier la sécurié
Dans le cadre de vos considérations de conception axées sur la sécurité, nous recommandons ce qui suit :
Pour la gestion des clés :
Créez une instance Key Vault dédiée pour l’émission de justificatifs vérifiables. Limitez les autorisations Azure Key Vault au service d’émission Vérification d’identité Microsoft Entra et au principal de service du site web front-end d’émission.
Traitez Azure Key Vault comme un système à privilèges élevés - Azure Key Vault émet des informations d’identification pour les clients. Nous vous recommandons de ne pas avoir d’autorisations permanentes sur le service Azure Key Vault. Les administrateurs ne doivent avoir que l’accès juste-à-temps à Key Vault. Pour plus de bonnes pratiques concernant l’utilisation d’Azure Key Vault, consultez Ligne de base de sécurité Azure pour Key Vault.
Pour le principal du service qui représente le site web frontal d’émission :
Définissez un principal de service dédié pour autoriser l’accès à Azure Key Vault. Si votre site web est sur Azure, nous vous recommandons d’utiliser une Identité managée Azure.
Traitez le principal de service qui représente le site web et l’utilisateur comme une limite d’approbation unique. Bien qu’il soit possible de créer plusieurs sites web, il n’y a qu’un seul jeu de clés pour la solution d’émission.
Pour la journalisation et la surveillance de la sécurité, nous recommandons ce qui suit :
Activez la journalisation et les alertes d’Azure Key Vault pour suivre les opérations d’émission d’informations d’identification, les tentatives d’extraction de clé, les modifications d’autorisation, et pour surveiller et envoyer une alerte pour les modifications de configuration. Plus d’informations peuvent être trouvées dans Comment activer la journalisation Key Vault.
Archivez des journaux dans un système de gestion des informations et des événements de sécurité (SIEM), comme Microsoft Sentinel pour une conservation à long terme.
Atténuez les risques d’usurpation d’identité à l’aide des éléments suivants
Vérification DNS pour aider les clients à identifier la personnalisation de l’émetteur.
Noms de domaine significatifs pour les utilisateurs finaux.
La personnalisation de confiance que l’utilisateur final reconnaît.
Atténuez les risques d’épuisement de ressources Key Vault et de déni de service distribué (DDOS). Chaque requête qui déclenche une requête d’émission de justificatifs vérifiables génère des opérations de signature Key Vault qui s’accumulent sur les limites du service. Nous vous recommandons de protéger le trafic en incorporant l’authentification ou un captcha avant de générer des requêtes d’émission.
Pour obtenir des conseils sur la gestion de votre environnement Azure, nous vous recommandons de consulter point de référence de sécurité Microsoft Cloud et Sécuriser les environnements Azure avec Microsoft Entra ID. Ces guides fournissent les meilleures pratiques pour la gestion des ressources Azure sous-jacentes, y compris Azure Key Vault, Stockage Azure, les sites web et d’autres services et fonctionnalités liés à Azure.
Considérations supplémentaires
Lorsque vous avez terminé votre preuve de concept, rassemblez toutes les informations et la documentation générées, puis envisagez de détruire la configuration de l’émetteur.
Pour plus d’informations sur la mise en œuvre et le fonctionnement de Key Vault, reportez-vous aux Meilleures pratiques pour utiliser Key Vault. Pour plus d’informations sur la sécurisation des environnements Azure avec Active Directory, reportez-vous à Sécurisation des environnements Azure avec Microsoft Entra ID.
Étapes suivantes
Lire la présentation de l’architecture