Planifier votre solution de vérification Vérification d’identité Microsoft Entra

Le service Microsoft Entra Verified ID (Microsoft Entra VC) de Microsoft vous permet de faire confiance aux preuves d'identité des utilisateurs sans étendre votre limite de confiance. Avec Microsoft Entra VC, vous créez des comptes ou vous fédérez avec un autre fournisseur d'identité. Lorsqu’une solution implémente un échange de vérification à l’aide d’informations d’identification vérifiables, elle permet aux applications de demander des informations d’identification qui ne sont pas liées à un domaine spécifique. Cette approche rend plus facile la démarche de demander et de vérifier des informations d’identification à grande échelle.

Si vous ne l’avez pas encore fait, nous vous suggérons de passer en revue la Présentation de l’architecture Vérification d’identité Microsoft Entra. Vous pouvez également consulter Planifier votre solution d’émission Vérification d’identité Microsoft Entra.

Étendue des recommandations

Ce contenu couvre les aspects techniques de la planification d’une solution de vérification des justificatifs vérifiables à l’aide de produits et services Microsoft. Les interfaces de solution avec un système d’approbation, où actuellement DID Web est pris en charge. DID Web est une infrastructure à clé publique centralisée.

Les technologies connexes qui ne sont pas spécifiques aux solutions de vérification sont hors du champ d’application. Par exemple, les sites web sont utilisés dans une solution de vérification de justificatifs vérifiables mais la planification du déploiement d’un site web n’est pas traitée en détail.

Lorsque vous planifiez votre solution de vérification, vous devez prendre en compte la capacité d’entreprise ajoutée ou modifiée. Vous devez également prendre en compte quelles fonctionnalités informatiques peuvent être réutilisées et les fonctionnalités qui doivent être ajoutées pour créer la solution. Vous devez également tenir compte de la formation nécessaire pour les personnes impliquées dans le processus commercial et les personnes qui assistent les utilisateurs finaux et le personnel de la solution. Ces articles ne sont pas abordés ici. Nous vous recommandons de consulter l’infrastructure Microsoft Azure Well-Architected Framework pour obtenir des informations sur ces articles.

Composants de la solution

Dans le cadre de votre plan pour une solution de vérification, vous devez activer les interactions entre le vérificateur, le sujet et l’émetteur. Dans cet article, les termes « partie de confiance » et « vérificateur » sont utilisés de manière interchangeable. Le diagramme suivant montre les composants de votre architecture de vérification.

Service Vérification d’identité Microsoft Entra

Dans le contexte d’une solution de vérification, le service Vérification d’identité Microsoft Entra est l’interface entre les composants Microsoft de la solution et le système d’approbation. Le service provisionne l’ensemble de clés dans Key Vault et provisionne l’identifiant décentralisé (DID).

Locataire Microsoft Entra

Le service nécessite un locataire Microsoft Entra qui 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 Microsoft Entra utilise le service Microsoft Entra Verified ID multi-tenant et émet un seul document DID représentant le vérificateur. Si plusieurs parties de confiance utilisent votre service de vérification, elles utilisent toutes le même DID de vérificateur. Le DID du vérificateur fournit des pointeurs vers la clé publique qui permet aux sujets et aux émetteurs de valider les messages provenant de la partie de confiance.

Azure Key Vault

Le service Azure Key Vault stocke vos clés de vérificateur, qui sont générées lorsque vous activez le service d’émission Vérification d’identité Microsoft Entra. Les clés sont utilisées pour assurer la sécurité des messages. Chaque vérificateur dispose d’un jeu de clés unique utilisé pour la signature, la mise à jour et la récupération des justificatifs vérifiables. Ce jeu de clés est utilisé chaque fois que vous répondez à une demande de vérification. Le jeu de clés de Microsoft utilise actuellement la cryptographie à courbe elliptique (ECC) SECP256k1. Nous explorons d’autres schémas de signature de chiffrement qui seront adoptés par l’ensemble de la communauté DID.

API du service de requête

Des interfaces de programmation d’applications (API) fournissent aux développeurs une méthode pour extraire les interactions entre les composants de la solution pour exécuter des opérations de vérification.

Système d’approbation

La 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.

Partie de confiance

Web frontal

Le front-end web de partie de confiance utilise l’API service de requête pour vérifier les machines virtuelles en générant des liens profonds ou des codes QR que le portefeuille du sujet consomme. Selon le scénario, le serveur frontal peut être un site web interne ou accessible publiquement pour permettre aux utilisateurs finaux d’effectuer des vérifications. Toutefois, les points de terminaison auxquels le portefeuille accède doivent être accessibles publiquement. Plus précisément, il contrôle la redirection vers le portefeuille avec des paramètres de demande spécifiques.

Logique métier

Vous pouvez créer une nouvelle logique ou utiliser une logique existante qui est spécifique à la partie de confiance et améliorer cette logique avec la présentation de justificatifs vérifiables.

Conceptions spécifiques aux scénarios

Voici des exemples de conceptions visant à satisfaire des cas d’usage spécifiques. Le premier concerne l’intégration de comptes, qui permet de réduire le temps, les coûts et les risques associés à l’intégration de nouveaux employés. Le deuxième concerne la récupération du compte, qui permet à un utilisateur final de récupérer ou de déverrouiller son compte à l’aide d’un mécanisme en libre-service. Le troisième est destiné à l’accès aux applications et aux ressources de grande valeur, notamment dans les cas d’usage interentreprises où l’accès est accordé à des personnes travaillant pour d’autres sociétés.

Intégration de comptes

Les informations d’identification vérifiables peuvent être utilisées pour accélérer l’intégration en remplaçant certaines interactions humaines. Les justificatifs vérifiables peuvent être utilisés pour permettre aux employés, étudiants, citoyens ou autres d’accéder à des services. Par exemple, au lieu qu’un employé doive se rendre dans un bureau central pour activer son badge, il peut utiliser un justificatif vérifiable attestant de son identité pour activer un badge qui lui est remis à distance. Au lieu qu’un citoyen reçoive un code qu’il doit accepter pour accéder aux services gouvernementaux, il peut utiliser des justificatifs vérifiables pour prouver son identité et obtenir l’accès.

Autres éléments

Portail d’intégration : Il s’agit d’un serveur web front-end qui orchestre les appels à l’API du service de requête pour la présentation et la validation des informations d’identification vérifiables, ainsi que la logique d’intégration des comptes.

Logique/flux de travail personnalisés : Logique spécifique avec des étapes propres à l’organisation avant et après la mise à jour du compte d’utilisateur. Des exemples peuvent inclure des flux de travail d’approbation, d’autres validations, la journalisation, les notifications, etc.

Systèmes d’identité cibles: Référentiels d’identité propres à l’organisation avec lesquels le portail d’intégration doit interagir lors de l’intégration des sujets. Les systèmes à intégrer sont déterminés en fonction des types d’identité que vous souhaitez intégrer à la validation des justificatifs vérifiables. Voici quelques scénarios courants de vérification d’identité pour l’intégration :

• Identités externes intégrées à Microsoft Entra ID en utilisant des API pour émettre des invitations B2B ou une affectation de gestion des droits d’utilisation aux packages.

• Les identités des employés, qui, dans les systèmes d’identité centralisés, sont déjà intégrées à Azure AD par le biais des systèmes de ressources humaines (RH). Dans ce cas, la vérification d’identité peut être intégrée dans le cadre des étapes existantes des flux de travail des RH.

Remarques sur la conception

• Émetteur : L’intégration de compte est un bon choix pour un service de vérification de l’identité externe comme émetteur de justificatifs vérifiables. Voici quelques exemples de vérifications de l’intégration : vérification de liveness, validation de documents délivrés par un gouvernement, confirmation de l’adresse ou du numéro de téléphone, etc.

• Stockage des attributs de justificatifs vérifiables : Dans la mesure du possible, ne stockez pas les attributs des justificatifs vérifiables dans le magasin spécifique à votre application. Soyez particulièrement vigilant avec les données personnelles. Si des flux spécifiques au sein de vos applications nécessitent ces informations, envisagez de demander au VC de récupérer les revendications à la demande.

• Corrélation entre les attributs de justificatifs vérifiables et les systèmes principaux : Lorsque vous définissez les attributs des justificatifs vérifiables avec l’émetteur, établissez un mécanisme de mise en corrélation des informations dans le système principal une fois que l’utilisateur a présenté les justificatifs vérifiables. Ce mécanisme utilise généralement un identificateur unique, limité dans le temps, dans le contexte de votre partie de confiance en association avec les revendications que vous recevez. Exemples :

  • Nouvel employé : Lorsque le flux de travail des RH atteint le point où la preuve d’identité est requise, la partie de confiance peut générer un lien avec un identificateur unique limité dans le temps. La partie de confiance l’envoie ensuite à l’adresse de messagerie du candidat sur le système RH. Cet identificateur unique doit être suffisant pour mettre en corrélation des informations telles que firstName et lastName provenant de la demande de vérification des justificatifs vérifiables avec l’enregistrement des RH ou les données sous-jacentes. Les attributs des justificatifs vérifiables peuvent être utilisés pour compléter les attributs utilisateur dans le système RH ou pour valider l’exactitude des attributs utilisateur concernant l’employé.

  • Identités externes : invitation : lorsqu’un utilisateur externe est invité au système cible, le fournisseur de ressources peut générer un lien avec un identificateur unique qui représente la transaction d’invitation. Ce lien peut être envoyé à l’adresse e-mail de l’utilisateur externe. Cet identificateur unique devrait être suffisant pour corréler la demande de vérification des justificatifs vérifiables avec l’enregistrement de l’invitation ou les données sous-jacentes et poursuivre le flux de travail de configuration. Les attributs des justificatifs vérifiables peuvent être utilisés pour valider ou compléter ceux de l’utilisateur externe.

  • Identités externes, libre-service : Lorsque des identités externes s’inscrivent auprès du système cible en libre-service (par exemple, une application B2C), les attributs des justificatifs vérifiables peuvent être utilisés pour renseigner les attributs initiaux du compte d’utilisateur. Les attributs des justificatifs vérifiables peuvent également être utilisés pour déterminer si un profil existe déjà.

• Interaction avec les systèmes d’identité cibles : La communication de service à service entre le serveur web frontal et vos systèmes d’identité cibles doit être sécurisée comme un système à privilèges élevés, car elle peut créer des comptes. Accordez au serveur web frontal des rôles avec le moins de privilèges possibles. Voici quelques exemples :

  • Pour créer un nouvel utilisateur dans Microsoft Entra ID, le site Web RP peut utiliser un principal de service disposant de la portée MS Graph User.ReadWrite.All pour créer des utilisateurs et de la portée UserAuthenticationMethod.ReadWrite.All pour réinitialiser leur méthode d'authentification.

  • Pour inviter des utilisateurs à Microsoft Entra ID à l'aide de la collaboration B2B, le site Web RP peut utiliser un principal de service bénéficiant de la portée MS Graph User.Invite.All pour créer des invitations.

  • Si votre partie de confiance s’exécute dans Azure, utilisez des identités managées pour appeler Microsoft Graph. L’utilisation d’identités managées élimine les risques liés à la gestion des informations d’identification du principal de service dans le code ou les fichiers config. Pour plus d’informations sur les identités managées, consultez Identités managées pour les ressources Azure.

Accès aux applications à haute valeur ajoutée au sein des organisations

Les justificatifs vérifiables peuvent servir de preuve pour accéder à des applications sensibles au sein de l’organisation. Par exemple, les justificatifs vérifiables peuvent également être utilisés pour permettre aux employés d’accéder aux applications métier sur la base de critères spécifiques, tels qu’une certification.

Autres éléments

Serveur web front-end de la partie de confiance : Il s’agit du serveur web front-end de l’application qui est amélioré par le biais d’appels à l’API du service de requête pour la présentation et la validation des informations d’identification vérifiables, en fonction de vos exigences métier.

Logique d’autorisation de l’accès utilisateur : Couche logique de l’application qui autorise l’accès utilisateur et qui est améliorée pour consommer les attributs utilisateur dans les justificatifs vérifiables afin de prendre des décisions en matière d’autorisation.

Autres services principaux et dépendances : Représente le reste de la logique de l’application, qui est généralement laissé inchangé par l’inclusion de la preuve de l’identité via les justificatifs vérifiables.

Remarques sur la conception

• Objectif : L’objectif du scénario détermine le type d’informations d’identification et d’émetteur requis. Voici quelques exemples de scénarios courants :

  • Autorisation : Dans ce scénario, l’utilisateur présente les justificatifs vérifiables pour prendre une décision en matière d’autorisation. Les justificatifs vérifiables destinés à prouver l’achèvement d’une formation ou la détention d’une certification spécifique conviennent bien à ce scénario. Les attributs des justificatifs vérifiables doivent contenir des informations précises permettant de prendre des décisions en matière d’autorisation et de procéder à des audits. Par exemple, le VC est utilisé pour certifier l’individu est formé et peut accéder à des applications financières sensibles. La logique de l’application peut vérifier la revendication du service pour obtenir une autorisation affinée et utiliser l’ID d’employé à des fins d’audit.

  • Confirmation de la vérification de l’identité : Dans ce scénario, l’objectif est de confirmer que la personne qui a été intégrée au départ est bien celle qui tente d’accéder à l’application à forte valeur ajoutée. Les informations d’identification d’un émetteur de vérification d’identité seraient adaptées. La logique d’application doit vérifier que les attributs de la VC s’alignent sur l’utilisateur qui s’est connecté à l’application.

• Vérification de la révocation : lors de l’utilisation de justificatifs vérifiables pour accéder à des ressources sensibles, il est courant de vérifier l’état des justificatifs vérifiables auprès de l’émetteur d’origine et de refuser l’accès aux justificatifs vérifiables révoqués. Lorsque vous travaillez avec les émetteurs, assurez-vous que la révocation est explicitement discutée dans le cadre de la conception de votre scénario.

• Expérience de l’utilisateur : Lorsque vous utilisez des justificatifs vérifiables pour accéder à des ressources sensibles, vous pouvez envisager deux modèles.

  • Authentification par étapes : Les utilisateurs démarrent la session avec l’application à l’aide des mécanismes d’authentification existants. Les utilisateurs doivent présenter des justificatifs vérifiable pour des opérations spécifiques à forte valeur ajoutée au sein de l’application, telles que les approbations de flux de travail d’entreprise. Cette solution convient bien aux scénarios où ces opérations à forte valeur ajoutée sont faciles à identifier et à mettre à jour dans les flux d’application.

  • Établissement de la session : Les utilisateurs doivent présenter des justificatifs vérifiables lors de l’ouverture de la session avec l’application. La présentation d’un VC est un bon ajustement lorsque la nature de l’application entière est à valeur élevée.

Accès aux applications en dehors des limites de l’organisation

Les justificatifs vérifiables peuvent également être utilisés par les parties de confiance qui souhaitent accorder un accès ou des avantages en fonction de l’appartenance ou de la relation de travail d’une autre organisation. Par exemple, un portail d’e-commerce peut offrir des avantages tels que des réductions aux employés d’une entreprise particulière, aux élèves d’une institution donnée, etc.

La nature décentralisée des justificatifs vérifiables permet ce scénario sans établir de relations de fédération.

Autres éléments

Serveur web front-end de la partie de confiance : Il s’agit du serveur web front-end de l’application qui est amélioré par le biais d’appels à l’API du service de requête pour la présentation et la validation des informations d’identification vérifiables, en fonction de vos exigences métier.

Logique d’autorisation de l’accès utilisateur : Couche logique de l’application qui autorise l’accès utilisateur et qui est améliorée pour consommer les attributs utilisateur dans les justificatifs vérifiables afin de prendre des décisions en matière d’autorisation.

Autres services principaux et dépendances : Représente le reste de la logique de l’application, qui est généralement laissé inchangé par l’inclusion de la preuve de l’identité via les justificatifs vérifiables.

Remarques sur la conception

• Objectif : L’objectif du scénario détermine le type d’informations d’identification et d’émetteur requis. Voici quelques exemples de scénarios courants :

  • Authentification : Dans ce scénario, un utilisateur doit être en possession de justificatifs vérifiables pour prouver son emploi ou sa relation avec une ou plusieurs organisations particulières. Dans ce cas, la partie de confiance doit être configurée pour accepter les justificatifs vérifiables émis par les organisations cibles.

  • Autorisation : En fonction des exigences relatives à l’application, les applications peuvent utiliser les justificatifs vérifiables pour prendre des décisions en matière d’autorisation et effectuer des audits de granularité fine. Par exemple, si un site web de commerce électronique offre des remises aux employés des organisations dans un emplacement particulier, ils peuvent valider l’éligibilité à la remise en fonction de la revendication pays/région dans la VC (le cas échéant).

• Vérification de la révocation : lors de l’utilisation de justificatifs vérifiables pour accéder à des ressources sensibles, il est courant de vérifier l’état des justificatifs vérifiables auprès de l’émetteur d’origine et de refuser l’accès aux justificatifs vérifiables révoqués. Lorsque vous travaillez avec les émetteurs, assurez-vous que la révocation est explicitement discutée dans le cadre de la conception de votre scénario.

• Expérience de l’utilisateur : Les utilisateurs peuvent présenter des justificatifs vérifiables lors de l’ouverture de la session avec l’application. En général, les applications proposent également une autre méthode pour démarrer la session afin de tenir compte des cas où les utilisateurs n’ont pas de justificatifs vérifiables.

Récupération de compte

Les justificatifs vérifiables peuvent être utilisés comme une approche de la récupération de compte. Par exemple, lorsqu'un utilisateur a besoin de récupérer son compte, il peut accéder à un site Web qui lui demande de présenter un VC et de lancer une réinitialisation des informations d'identification Microsoft Entra en appelant les API MS Graph, comme indiqué dans le diagramme suivant.

Autres éléments

Portail de compte: front-end web qui orchestre les appels d’API pour la présentation et la validation VC. Cette orchestration peut inclure des appels Microsoft Graph pour récupérer des comptes dans Microsoft Entra ID.

Logique ou flux de travail personnalisés : Logique avec des étapes propres à l’organisation avant et après la mise à jour du compte d’utilisateur. Cela peut inclure des flux de travail d’approbation, d’autres validations, la journalisation, les notifications, etc.

Microsoft Graph : expose les API REST et les bibliothèques clientes pour accéder aux données Microsoft Entra utilisées pour effectuer la récupération de compte.

Annuaire d'entreprise Microsoft Entra : il s'agit du locataire Microsoft Entra qui contient les comptes en cours de création ou de mise à jour via le portail de comptes.

Remarques relatives à la conception

Corrélation d’attribut VC avec Microsoft Entra ID : lors de la définition des attributs du VC en collaboration avec l’émetteur, veillez à accepter les revendications qui identifient l’utilisateur. Par exemple, si le fournisseur de vérification d’identité (IDV) vérifie l’identité avant l’intégration des employés, assurez-vous que le VC émis inclut des revendications pouvant être mises en correspondance avec les systèmes internes. Ces revendications peuvent être un numéro de téléphone, une adresse ou une date de naissance. Le RP peut demander des informations introuvables dans la VC dans le cadre de ce processus, comme les quatre derniers chiffres de leur numéro de sécurité sociale (SSN).

Rôle des VC avec des capacités existantes de réinitialisation des informations d'identification Microsoft Entra : Microsoft Entra ID dispose d'une capacité intégrée de réinitialisation de mot de passe en libre-service (SSPR). Les justificatifs vérifiables peuvent être utilisés pour fournir un autre moyen de récupérer dans les cas où les utilisateurs n’ont pas accès à la méthode SSPR ni perdu le contrôle de la méthode SSPR. Dans les scénarios où l’utilisateur a perdu à la fois l’ordinateur et le mobile, l’utilisateur peut obtenir à nouveau un VC à partir d’un émetteur de preuve d’identité et le présenter pour récupérer son compte à distance.

De même, vous pouvez utiliser un VC pour générer une passe d’accès temporaire qui permet aux utilisateurs de réinitialiser leurs méthodes d’authentification MFA sans mot de passe.

Autorisation : Créez un mécanisme d’autorisation tel qu’un groupe de sécurité que la partie de confiance vérifie avant de procéder à la récupération des informations d’identification. Par exemple, seuls les utilisateurs de groupes spécifiques sont qualifiés pour récupérer un compte avec des justificatifs vérifiables.

Interaction avec Microsoft Entra ID : La communication de service à service entre le frontal Web et Microsoft Entra ID doit être sécurisée en tant que système hautement privilégié car elle peut réinitialiser les informations d'identification des employés. Accordez au serveur web frontal des rôles avec le moins de privilèges possibles. Voici quelques exemples :

• Accordez au site web de la partie de confiance la possibilité d’utiliser un principal de service auquel est accordée l’étendue MS Graph UserAuthenticationMethod.ReadWrite.All pour réinitialiser les méthodes d’authentification. N’accordez pas l’étendue User.ReadWrite.All, qui permet de créer et de supprimer des utilisateurs.

• Si votre partie de confiance s’exécute dans Azure, utilisez des identités managées pour appeler Microsoft Graph. Les identités managées suppriment les risques liés à la gestion des informations d’identification du principal de service dans le code ou les fichiers de configuration. Pour plus d’informations, consultez Identités managées pour les ressources Azure.

Plan de gestion des identités

Voici les considérations IAM lors de l’incorporation de machines virtuelles à des parties de confiance. Les parties de confiance sont généralement des applications.

Authentication

• Le sujet de justificatifs vérifiables doit être un être humain.

• Un humain a le VC dans son portefeuille et doit présenter de manière interactive le VC. Les flux non interactifs tels que les flux non interactifs ne sont pas pris en charge.

Autorisation

• Une présentation réussie des justificatifs vérifiables peut être considérée comme une porte d’autorisation grossière. Les attributs des justificatifs vérifiables peuvent également être utilisés pour des décisions affinées en matière d’autorisation.

• Déterminez si des justificatifs vérifiables expirés ont une signification dans votre application ; si c’est le cas, vérifiez la valeur de la revendication exp (l’heure d’expiration) des justificatifs vérifiables dans le cadre des contrôles d’autorisation. L’un des exemples où l’expiration n’est pas pertinente nécessite un document émis par le gouvernement, tel qu’un permis de conduire, pour valider si le sujet est antérieur à 18 ans. La revendication de la date de naissance est valide, même si les justificatifs vérifiables sont expirés.

• Déterminez si des justificatifs vérifiables révoqués ont une signification pour votre décision d’autorisation.

  • Si ce n’est pas le cas, ignorez l’appel à l’API de vérification de l’état (qui est activé par défaut).

  • Si c’est le cas, ajoutez la gestion appropriée des exceptions dans votre application.

Profils utilisateur

Vous pouvez utiliser les informations contenues dans les justificatifs vérifiables présentés pour établir un profil utilisateur. Si vous souhaitez utiliser des attributs pour générer un profil, tenez compte des éléments suivants.

• Lorsque les justificatifs vérifiables sont émis, ils contiennent un instantané des attributs au moment de l’émission. Les VC peuvent avoir de longues périodes de validité, et vous devez déterminer l’âge des attributs que vous accepterez comme suffisamment récents pour être utilisés dans le cadre du profil.

• Si des justificatifs vérifiables doivent être présentés chaque fois que le sujet démarre une session avec la partie de confiance, envisagez d’utiliser la sortie de la présentation des justificatifs pour créer un profil utilisateur non persistant avec les attributs. Un profil utilisateur non persistant permet de réduire les risques de confidentialité associés au stockage des propriétés utilisateur au repos. Votre application peut avoir besoin d’enregistrer les attributs de l’objet localement. Si c’est le cas, enregistrez uniquement les revendications dont votre application a besoin. N’enregistrez pas l’intégralité du VC.

• Si l’application nécessite un stockage persistant du profil utilisateur :

  • Envisagez d’utiliser la revendication sub comme identificateur immuable de l’utilisateur. Il s’agit d’un attribut unique opaque qui est constant pour une paire objet/RP donnée.

  • Définissez un mécanisme pour supprimer les privilèges d’accès du profil utilisateur de l’application. En raison de la nature décentralisée du système Vérification d’identité Microsoft Entra, il n’existe aucun cycle de vie d’approvisionnement des utilisateurs d’application.

  • Ne stockez pas les revendications de données personnelles retournées dans le jeton VC.

  • Stockez uniquement les revendications nécessaires à la logique de la partie de confiance.

Planifier les performances

Comme pour n’importe quelle solution, vous devez planifier les performances. Les domaines à privilégier sont la latence, le débit 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 entraîne la vérification de nombreux justificatifs vérifiables, la planification des performances peut devenir un élément essentiel de votre solution.

Les éléments suivants fournissent des 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 Europe Ouest, Europe Nord, USA Ouest 2 et USA Centre-Ouest. Pour limiter la latence, déployez votre serveur frontal de vérification (site web) et votre coffre de clés dans la région la plus proche.

• Modèle basé sur le débit :

  • La capacité de vérification des justificatifs vérifiables est soumise aux limites du service Azure Key Vault.

  • Chaque vérification de justificatifs vérifiables nécessite une opération de signature Key Vault.

  • Vous ne pouvez pas contrôler la limitation ; cependant, nous vous recommandons de lire Aide sur la limitation de requêtes Azure Key Vault afin de comprendre l’impact de la limitation sur les performances.

Planifier pour la fiabilité

Pour mieux planifier la haute disponibilité et la récupération d’urgence, nous vous suggérons les éléments suivants :

• Le service Vérification d’identité Microsoft Entra est déployé dans les régions Azure : Europe Ouest, Europe Nord, USA Ouest 2 et USA Centre-Ouest. Envisagez de déployer vos serveurs web et vos applications connexes dans l’une de ces régions, en particulier celles à partir desquelles vous vous attendez à ce que la plupart de votre trafic de validation provienne.

• Passez en revue et intégrez les meilleures pratiques décrites dans Disponibilité et redondance d’Azure Key Vault lors de la conception de vos objectifs de disponibilité et de redondance.

Planifier la sécurité

À mesure que vous concevez pour la sécurité, tenez compte des éléments suivants :

• Toutes les parties de confiance d’un même locataire ont la même limite de confiance puisqu’elles partagent le même DID.

• Définissez un principal de service dédié pour un site web accédant au coffre de clés.

• Seuls le service Vérification d’identité Microsoft Entra et les principaux de service du site web doivent avoir l’autorisation d’utiliser Key Vault pour signer des messages avec la clé privée.

• N’attribuez pas d’autorisations d’administration d’identité humaine au Key Vault. Pour plus d’informations sur les meilleures pratiques de Key Vault, consultez Ligne de base de sécurité Azure pour Key Vault.

• Consultez Sécurisation des environnements Azure avec Microsoft Entra ID pour connaître les meilleures pratiques de gestion des services de prise en charge de votre solution.

• Atténuez les risques d’usurpation d’identité en :

  • implémentant une vérification DNS pour aider les clients à identifier la personnalisation de l’émetteur ;

  • utilisant des domaines significatifs pour les utilisateurs finaux.

• Atténuez les risques de limitation de ressources Key Vault et de déni de service distribué (DDOS). Chaque demande de présentation de justificatifs vérifiables génère des opérations de signature Key Vault qui s’ajoutent aux limites de service. Nous vous recommandons de protéger le trafic en incorporant une autre authentification ou un captcha avant de générer des requêtes d’émission.

Planifier les opérations

Lorsque vous planifiez des opérations, nous vous recommandons de capturer chaque tentative de validation des informations d’identification dans le cadre de votre audit. Utilisez ces informations pour l’audit et la résolution des problèmes. En outre, envisagez de générer des identificateurs de transaction uniques (ID) auxquels les clients et les ingénieurs su support peuvent se référer en cas de besoin.

Dans le cadre de votre planification opérationnelle, pensez à surveiller les éléments suivants :

• Pour la scalabilité :

  • Surveillez les échecs de validation des justificatifs vérifiables dans le cadre des métriques de sécurité de bout en bout des applications.

  • Surveillez la latence de bout en bout de la vérification des informations d’identification.

• Pour la fiabilité et les dépendances :

  • Surveillez les dépendances sous-jacentes utilisées par la solution de vérification.

  • Suivez Surveillance et alertes pour Azure Key Vault.

• Pour la sécurité :

  • Activez la journalisation pour Key Vault afin de suivre les opérations de signature, ainsi que pour surveiller les changements de configuration et déclencher des alertes à leur sujet. Référez-vous à Comment activer la journalisation Key Vault pour plus d’informations.

  • 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.

Étapes suivantes

En savoir plus sur l’architecture de solutions justificatives vérifiables

• Présentation de Vérification d’identité Microsoft Entra

• Planifier votre solution d’émission Vérification d’identité Microsoft Entra

Implémenter des justificatifs vérifiables

• Présentation de l’ID vérifié Microsoft Entra

• Prise en main des justificatifs vérifiables

Questions fréquentes (FAQ)