Planifiez votre solution de vérification d'identifiant vérifié Microsoft Entra

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

Si vous ne l'avez pas encore fait, nous vous recommandons de consulter la Vue d'ensemble de l'architecture de Microsoft Entra Verified ID . Vous pouvez également consulter Planifier votre solution d’émission Vérification d’identité Microsoft Entra.

Étendue des conseils

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. La solution s'interface avec un système de confiance, où actuellement le DID Web est pris en charge. DID Web est une infrastructure à clé publique centralisée.

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

Lorsque vous planifiez votre solution de vérification, vous devez prendre en compte la fonctionnalité métier en cours d’ajout ou de modification. Vous devez également prendre en compte les fonctionnalités informatiques qui peuvent être réutilisées et quelles fonctionnalités doivent être ajoutées pour créer la solution. Considérez également quelle formation est nécessaire pour les personnes impliquées dans le processus métier et les personnes qui prennent en charge les utilisateurs finaux et le personnel de la solution. Ces articles ne sont pas abordés dans ce contenu. Nous vous recommandons de consulter les Microsoft Azure Well-Architected Framework pour plus d’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 de partie de confiance et de vérificateur sont utilisés de façon 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érificateur, le service Microsoft Entra Verified ID est l’interface entre les composants Microsoft de la solution et le système d’approbation. Le service provisionne la clé définie sur Key Vault, approvisionne l’identificateur décentralisé (DID).

Locataire Microsoft Entra

Le service nécessite un locataire Microsoft Entra qui fournit un plan de contrôle Identity and Access Management (IAM) pour les ressources Azure qui font partie de la solution. Chaque locataire Microsoft Entra utilise le service d’ID vérifié Microsoft Entra mutualisé et émet un document DID unique représentant le vérificateur. Si vous avez plusieurs parties prenantes utilisant votre service de vérification, elles utilisent toutes le même vérificateur DID. Le vérificateur DID fournit des pointeurs vers la clé publique permettant aux sujets et aux émetteurs de valider les messages provenant du tiers 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 d’ID vérifié 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 CV. L’ID vérifié utilise cette clé définie chaque fois que vous effectuez une demande de vérification. Le jeu de clés Microsoft utilise actuellement la cryptographie à courbe elliptique (ECC) SECP256k1. Nous explorons d’autres schémas de signature de chiffrement qui sont adoptés par la communauté DID plus large.

API pour la gestion des demandes de service

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

Système de confiance

Microsoft Entra Verified ID 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 Microsoft Entra VC et le contrat utilisé pour émettre des certificats 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 (RP)

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 accessible publiquement ou interne pour activer les expériences des utilisateurs finaux qui nécessitent une vérification. 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 requête 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 qui répondent à des cas d’usage spécifiques. La première concerne l’intégration de comptes, utilisée pour réduire le temps, le coût et le risque associés à l’intégration de nouveaux employés. La deuxième est la récupération de 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 d’accéder à des applications et ressources à valeur élevée, en particulier pour les cas d’usage métier à entreprise où l’accès est donné aux personnes qui travaillent pour d’autres entreprises.

Intégration de compte

Les justificatifs vérifiables peuvent être utilisés pour permettre une intégration plus rapide 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, plutôt que d'aller dans un bureau central pour activer un badge d'employé, un employé peut utiliser une VC pour vérifier son identité afin d'activer un badge envoyé à distance. Plutôt qu’un citoyen recevant un code qu’il doit utiliser pour accéder aux services gouvernementaux, il peut utiliser un VC 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 personnalisée/flux de travail: logique spécifique avec des étapes spécifiques à l’organisation avant et après la mise à jour du compte d’utilisateur. Les exemples peuvent inclure des flux de travail d’approbation, d’autres validations, la journalisation, les notifications, et ainsi de suite.

systèmes d’identité cible: référentiels d’identité spécifiques à 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és que vous souhaitez intégrer à la validation VC. Les scénarios courants de vérification d’identité pour l’intégration sont les suivants :

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

Considérations relatives à 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 VC: si possible, ne stockez pas d’attributs à partir de machines virtuelles dans votre magasin spécifique à l’application. Soyez particulièrement prudent 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 des attributs du VC avec les systèmes de back-end: Lors de la définition des attributs du VC avec l'émetteur, établissez un mécanisme permettant de mettre en corrélation les informations dans le système de back-end une fois que l'utilisateur présente le VC. Le mécanisme utilise généralement un identificateur unique temporellement limité dans le cadre de votre RP en combinaison avec les revendications que vous recevez. Voici quelques exemples :

  • Nouvel employé: lorsque le flux de travail RH atteint le point où la vérification de l'identité est requise, le fournisseur de services peut générer un lien avec un identificateur unique à durée déterminée. Le rp l’envoie ensuite à l’adresse e-mail du candidat sur le système RH. Cet identificateur unique doit être suffisant pour mettre en corrélation des informations telles que firstName, lastName de la demande de vérification VC à l’enregistrement RH ou aux données sous-jacentes. Les attributs de la VC peuvent être utilisés pour compléter les attributs utilisateur dans le système RH ou pour valider la précision des attributs utilisateur concernant l’employé.

  • Identités externes - Invitation : Lorsqu’un utilisateur externe est invité au système cible, le RP 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 doit être suffisant pour mettre en corrélation la demande de vérification VC à l’enregistrement d’invitation ou aux données sous-jacentes et poursuivre le flux de travail d’approvisionnement. Les attributs de la VC peuvent être utilisés pour valider ou compléter les attributs utilisateur externes.

  • Identités externes - libre-service : lorsque des identités externes s’inscrivent au système cible via un libre-service (par exemple, une application B2C), les attributs dans le VC peuvent être utilisés pour remplir les attributs initiaux du compte d'utilisateur. Les attributs VC peuvent également être utilisés pour déterminer si un profil existe déjà.

• Interaction avec les systèmes d’identité cible: la communication de service à service entre le serveur frontal web et vos systèmes d’identité cible doit être sécurisée en tant que système hautement privilégié, car il peut créer des comptes. Accordez au serveur frontal web les rôles les moins privilégiés possibles. Voici quelques exemples :

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

  • Pour inviter des utilisateurs à Microsoft Entra ID à l'aide de la collaboration inter-entreprises B2B, le site Web RP peut utiliser un principal de service disposant du périmètre MS Graph de User.Invite.All pour créer des invitations.

  • Si votre RP s'exécute dans Azure, utilisez des identités gérées pour appeler Microsoft Graph. L’utilisation d’identités managées supprime les risques de gestion des informations d’identification du principal de service dans le code ou les fichiers de configuration. Pour en savoir plus sur les identités managées, accédez à identités managées pour les ressources Azure.

Accès à des applications à valeur élevée au sein d’organisations

Les justificatifs vérifiables peuvent être utilisés comme autre preuve d’accès aux applications sensibles au sein de l’organisation. Par exemple, les machines virtuelles peuvent également être utilisées pour fournir aux employés un accès aux applications métier en fonction de critères spécifiques, tels qu’une certification.

Autres éléments

Le front-end Web de la partie de confiance est le front-end Web de l'application qui est amélioré par le biais d'appels d'API de service de requête pour la présentation et la validation VC, en fonction de vos besoins métier.

logique d’autorisation d’accès utilisateur est la couche logique de l’application qui autorise l’accès utilisateur. Il est amélioré pour consommer les attributs utilisateur à l’intérieur du VC pour prendre des décisions d’autorisation.

Autres services principaux et dépendances: représente le reste de la logique de l’application, qui est généralement inchangée par l’inclusion de la vérification des identités par le biais de machines virtuelles.

Considérations relatives à la conception

• Objectif: l’objectif du scénario détermine le type d’informations d’identification et l’émetteur nécessaires. Les scénarios classiques sont les suivants :

  • 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 VC doivent contenir des informations affinées propices aux décisions d’autorisation et à l’audit. Par exemple, le VC est utilisé pour certifier que 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 même personne initialement intégrée est en effet celle qui tente d’accéder à l’application à valeur élevée. Un justificatif d'un fournisseur de vérification d'identité conviendrait. La logique d'application doit vérifier que les attributs de la VC correspondent à 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 abordée dans le cadre de la conception de votre scénario.

• expérience utilisateur: lorsque vous utilisez des machines virtuelles pour accéder aux ressources sensibles, vous pouvez envisager deux modèles.

  • Authentification renforcée: les utilisateurs démarrent la session avec l’application en utilisant des mécanismes d’authentification existants. Les utilisateurs doivent présenter une VC pour des opérations spécifiques à forte valeur au sein de l'application, telles que les approbations des flux de travail d'entreprise. Il s’agit d’un bon ajustement pour les scénarios où de telles opérations à valeur élevée sont faciles à identifier et à mettre à jour dans les flux d’application.

  • Établissement de session: les utilisateurs doivent présenter une VC pour lancer 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 des parties de confiance qui souhaitent accorder l’accès ou les avantages en fonction de l’appartenance ou de la relation d’emploi d’une autre organisation. Par exemple, un portail de commerce électronique peut offrir des avantages tels que des remises aux employés d’une entreprise particulière, des étudiants d’un établissement donné, 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 d’accès des utilisateurs: couche logique dans l’application qui autorise l’accès des utilisateurs et est améliorée pour utiliser les attributs des utilisateurs dans le VC pour prendre des décisions d’autorisation.

Autres services principaux et dépendances: représente le reste de la logique de l’application, qui est généralement inchangée par l’inclusion de la vérification des identités par le biais de machines virtuelles.

Considérations relatives à la conception

• Objectif: l’objectif du scénario détermine le type d’informations d’identification et l’émetteur nécessaires. Les scénarios classiques sont les suivants :

  • Authentification : dans ce scénario, un utilisateur doit être en possession d’un VC pour prouver son emploi ou sa relation avec une organisation particulière. 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 abordée dans le cadre de la conception de votre scénario.

• expérience utilisateur: les utilisateurs peuvent présenter une VC lors du démarrage de la session avec l'application. En règle générale, les applications fournissent également une autre méthode pour démarrer la session afin de prendre en charge les cas où les utilisateurs n’ont pas de machines virtuelles.

Récupération de compte

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

Remarque

Bien que le scénario que nous décrivons dans cette section soit spécifique à la récupération des comptes Microsoft Entra, cette approche peut également être utilisée pour récupérer des comptes dans d’autres systèmes.

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 l’ID Microsoft Entra.

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

Microsoft Graph : expose les API rest (representational state transfer) 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.

Considérations relatives à la conception

Corrélation d’attributs VC avec l’ID Microsoft Entra: Lors de la définition des attributs du VC en collaboration avec l’émetteur, veillez à vous mettre d’accord sur les déclarations 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 déclarations qui peuvent être comparées aux 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 VCs avec les fonctionnalités de réinitialisation des identifiants Microsoft Entra existantes: Microsoft Entra ID possède une fonctionnalité 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 reobtener 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 certains groupes spécifiques peuvent être éligibles pour récupérer un compte avec un VC.

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

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

• Si votre RP s'exécute dans Azure, utilisez des identités géré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.

Planifier la 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.

Authentification

• 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 une vc expirée a une signification dans votre application ; si c’est le cas, vérifiez la valeur de la revendication exp (heure d’expiration) de la vc dans le cadre des vérifications d’autorisation. L’un des exemples où l’expiration n’est pas pertinente exige qu’un document émis par le gouvernement, tel qu’un permis de conduire, vérifie si le sujet est âgé de plus de 18 ans. L'affirmation concernant la date de naissance est valide, même si le VC est expiré.

• Déterminez si une vc révoquée a une signification à votre décision d’autorisation.

  • S’il n’est pas pertinent, ignorez l’appel pour vérifier l’API d’état (qui est activée par défaut).

  • S’il est pertinent, ajoutez la gestion appropriée des exceptions dans votre application.

Profils utilisateur

Vous pouvez utiliser des informations dans les machines virtuelles présentées pour créer 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 magasin de profils utilisateur persistant :

  • 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 déprovisionner le profil utilisateur à partir de l’application. En raison de la nature décentralisée du système Microsoft Entra Verified ID, il n’existe aucun cycle de vie d’approvisionnement des utilisateurs d’application.

  • Ne stockez pas les réclamations de données personnelles renvoyé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 de focus incluent la latence, le débit et l’extensibilité. 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 une partie essentielle de votre solution.

Les éléments suivants fournissent des points à prendre en compte lors de la planification des performances :

• Le service d’émission d’ID vérifié Microsoft Entra est déployé dans les régions 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 d’un VC nécessite une opération de signature Key Vault.

  • Vous ne pouvez pas contrôler le throttling ; toutefois, nous vous recommandons de lire les consignes de gestion du throttling pour Azure Key Vault afin de comprendre comment le throttling peut avoir un impact sur les performances.

Plan 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 Microsoft Entra Verified ID est déployé dans les régions Europe Ouest, Europe Nord, USA Ouest 2 et USA Centre Ouest, Australie et Japon Azure. Envisagez de déployer vos serveurs web de prise en charge et les applications de prise en charge dans l’une de ces régions, en particulier dans celles dont vous attendez que la plupart de votre trafic de validation provient.

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

• Seul le service Microsoft Entra Verified ID et les principaux du service de site web doivent disposer des autorisations nécessaires pour utiliser Key Vault pour signer des messages avec la clé privée.

• N’attribuez aucune autorisation d’administration d’identité utilisateur au coffre de clés. Pour plus d’informations sur les meilleures pratiques de Key Vault, consultez base de référence de sécurité Azure pour Key Vault.

• Consultez sécurisation des environnements Azure à l'aide de Microsoft Entra ID pour connaître les meilleures pratiques de gestion des services de support de votre solution.

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

  • Implémentation de la vérification DNS pour aider les clients à identifier la marque de l'émetteur.

  • Utilisez des domaines significatifs pour les utilisateurs finaux.

• Atténuer les risques de déni de service distribué (DDoS) et de limitation des ressources de Key Vault. 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 captcha avant de générer des demandes 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 du support peuvent faire référence si nécessaire.

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

• Pour l’extensibilité:

  • Surveiller l’échec de la validation VC 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 la surveillance et les alertes d’Azure Key Vault .

• Pour la sécurité:

  • Activez la journalisation pour Key Vault afin de suivre les opérations de signature et de surveiller et d’alerter sur les modifications de configuration. Référez-vous à Comment activer la journalisation Key Vault pour plus d’informations.

  • Archivez les journaux d’activité dans des systèmes SIEM (Security Information and Event Management), tels que Microsoft Sentinel pour la rétention à long terme.

Étapes suivantes

En savoir plus sur l’architecture de solutions VC

• 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

• Introduction à l'identité vérifiée Microsoft Entra

• Prise en main des justificatifs vérifiables

FAQ