Uw Microsoft Entra geverifieerde ID verificatieoplossing plannen

Met de Microsoft Entra geverifieerde ID -service van Microsoft (Microsoft Entra VC) kunt u bewijzen van gebruikersidentiteit vertrouwen zonder uw vertrouwensgrens uit te breiden. Met Microsoft Entra VC maakt u accounts of federatie met een andere id-provider. Wanneer een oplossing een verificatie-uitwisseling implementeert met behulp van verifieerbare referenties, kunnen toepassingen referenties aanvragen die niet zijn gebonden aan een specifiek domein. Deze aanpak maakt het eenvoudiger om referenties op schaal aan te vragen en te verifiëren.

Als u dat nog niet hebt gedaan, raden we u aan het overzicht van Microsoft Entra geverifieerde ID architectuur te bekijken. U wilt ook uw Microsoft Entra geverifieerde ID uitgifteoplossing plannen.

Bereik van richtlijnen

Deze inhoud behandelt de technische aspecten van het plannen van een verifieerbare referentieverificatieoplossing met behulp van Microsoft-producten en -services. De oplossingsinterfaces met een vertrouwenssysteem, waar momenteel DID Web wordt ondersteund. DID Web is een gecentraliseerde infrastructuur voor openbare sleutels.

Ondersteunende technologieën die niet specifiek zijn voor verificatieoplossingen vallen buiten het bereik. Websites worden bijvoorbeeld gebruikt in een verifieerbare referentieverificatieoplossing, maar het plannen van een website-implementatie wordt niet gedetailleerd behandeld.

Wanneer u uw verificatieoplossing plant, moet u overwegen welke bedrijfsfunctionaliteit wordt toegevoegd of gewijzigd. U moet ook overwegen welke IT-mogelijkheden opnieuw kunnen worden gebruikt en welke mogelijkheden moeten worden toegevoegd om de oplossing te maken. Bedenk ook welke training nodig is voor de personen die betrokken zijn bij het bedrijfsproces en de mensen die de eindgebruikers en het personeel van de oplossing ondersteunen. Deze artikelen worden niet behandeld in deze inhoud. We raden u aan het Microsoft Azure Well-Architected Framework te bekijken voor informatie over deze artikelen.

Onderdelen van de oplossing

Als onderdeel van uw plan voor een verificatieoplossing moet u de interacties tussen de verifier, het onderwerp en de verlener inschakelen. In dit artikel worden de termen relying party en verifier door elkaar gebruikt. In het volgende diagram ziet u de onderdelen van uw verificatiearchitectuur.

Microsoft Entra geverifieerde id-service

In de context van een verifier-oplossing is de Microsoft Entra geverifieerde ID-service de interface tussen de Microsoft-onderdelen van de oplossing en het vertrouwenssysteem. De service richt de sleutel in op Key Vault, richt de gedecentraliseerde id (DID) in.

Microsoft Entra-tenant

Voor de service is een Microsoft Entra-tenant vereist die een IAM-besturingsvlak (Identity and Access Management) biedt voor de Azure-resources die deel uitmaken van de oplossing. Elke Microsoft Entra-tenant maakt gebruik van de service voor meerdere tenants Microsoft Entra geverifieerde ID en er wordt één DID-document weergegeven dat de verifier vertegenwoordigt. Als u meerdere relying party's hebt die gebruikmaken van uw verificatieservice, gebruiken ze allemaal dezelfde verifier DID. De verificator DID bevat aanwijzingen voor de openbare sleutel waarmee onderwerpen en verleners berichten kunnen valideren die afkomstig zijn van de relying party.

Azure Key Vault

De Azure Key Vault-service slaat uw verifiersleutels op die worden gegenereerd wanneer u de Microsoft Entra geverifieerde ID uitgifteservice inschakelt. De sleutels worden gebruikt om berichtbeveiliging te bieden. Elke verificator heeft één sleutelset die wordt gebruikt voor het ondertekenen, bijwerken en herstellen van VM's. Deze sleutelset wordt telkens gebruikt wanneer u een verificatieaanvraag servicet. Microsoft-sleutelset maakt momenteel gebruik van Elliptic Curve Cryptography (ECC) SECP256k1. We verkennen andere cryptografische handtekeningschema's die worden gebruikt door de bredere DID-community.

Service-API aanvragen

Api's (Application Programming Interfaces) bieden ontwikkelaars een methode voor abstracte interacties tussen onderdelen van de oplossing om verificatiebewerkingen uit te voeren.

Vertrouwenssysteem

Microsoft Entra geverifieerde ID ondersteunt momenteelDID Web als een vertrouwenssysteem, waar het DID-document wordt gehost op de webserver van de verleners.

Microsoft Authenticator-app

Microsoft Authenticator is de mobiele toepassing. De Authenticator organiseert de interacties tussen de gebruiker, de Microsoft Entra geverifieerde ID-service en het contract dat wordt gebruikt voor het uitgeven van vm's. Het fungeert als een digitale portemonnee waarin de houder van de VC de VC opslaat, met inbegrip van de persoonlijke sleutel van het onderwerp van de VC. Authenticator is ook het mechanisme dat wordt gebruikt voor het presenteren van VM's voor verificatie.

Relying party (RP)

Web-front-end

De relying party-webfront-end maakt gebruik van de Request Service-API om te verifiëren of VCs door deep links of QR-codes te genereren die de portemonnee van het onderwerp verbruikt. Afhankelijk van het scenario kan de front-end een openbaar toegankelijke of interne website zijn om eindgebruikerservaringen in te schakelen waarvoor verificatie is vereist. De eindpunten waartoe de portemonnee toegang heeft, moeten echter openbaar toegankelijk zijn. Het regelt met name omleiding naar de portemonnee met specifieke aanvraagparameters.

Bedrijfslogica

U kunt nieuwe logica maken of bestaande logica gebruiken die specifiek is voor de relying party en die logica verbeteren met de presentatie van vm's.

Scenariospecifieke ontwerpen

Hieronder ziet u voorbeelden van ontwerpen om te voldoen aan specifieke gebruiksvoorbeelden. De eerste is voor het onboarden van accounts, gebruikt om de tijd, kosten en risico's te verminderen die zijn gekoppeld aan het onboarden van nieuwe werknemers. De tweede is voor accountherstel, waarmee een eindgebruiker zijn of haar account kan herstellen of ontgrendelen met behulp van een selfservicemechanisme. De derde is voor toegang tot hoogwaardige toepassingen en resources, met name voor business-to-business-use cases waarbij toegang wordt verleend aan personen die voor andere bedrijven werken.

Onboarding van accounts

Verifieerbare referenties kunnen worden gebruikt om snellere onboarding mogelijk te maken door een aantal menselijke interacties te vervangen. VCs kunnen worden gebruikt om werknemers, studenten, burgers of anderen te onboarden voor toegang tot services. In plaats van bijvoorbeeld een werknemer die naar een centraal kantoor moet gaan om een werknemersbadge te activeren, kan hij een VC gebruiken om zijn identiteit te verifiëren om een badge te activeren die op afstand aan hen wordt geleverd. In plaats van een burger die een code ontvangt die ze moeten inwisselen voor toegang tot overheidsdiensten, kunnen ze een VC gebruiken om hun identiteit te bewijzen en toegang te krijgen.

Andere elementen

Onboarding-portal: een web-front-end die de AANVRAAGservice-API-aanroepen organiseert voor VC-presentatie en -validatie, en de logica voor het onboarden van accounts.

Aangepaste logica/werkstromen: specifieke logica met organisatiespecifieke stappen voor en na het bijwerken van het gebruikersaccount. Voorbeelden hiervan zijn goedkeuringswerkstromen, andere validaties, logboekregistratie, meldingen, enzovoort.

Doelidentiteitssystemen: organisatiespecifieke identiteitsopslagplaatsen waarmee de onboardingportal moet communiceren tijdens het onboarden van onderwerpen. De systemen die moeten worden geïntegreerd, worden bepaald op basis van de soorten identiteiten die u wilt onboarden met VC-validatie. Veelvoorkomende scenario's voor identiteitsverificatie voor onboarding zijn:

• Externe identiteiten die microsoft Entra ID onboardt met behulp van API's voor het uitgeven van B2B-uitnodigingen (Business-to-Business) of toewijzing van rechtenbeheer aan pakketten.

• Identiteiten van werknemers, die in gecentraliseerde identiteitssystemen al worden ge onboardd via HR-systemen (Human Resources). In dit geval kan de identiteitsverificatie worden geïntegreerd als onderdeel van bestaande fasen van HR-werkstromen.

Overwegingen bij het ontwerpen

• Verlener: Onboarding van accounts is geschikt voor een externe identiteitsbewijsservice als verlener van de VM's. Voorbeelden van controles voor onboarding zijn: liveness check, door de overheid uitgegeven documentvalidatie, adres of bevestiging van telefoonnummers, enzovoort.

• VC-kenmerken opslaan: sla waar mogelijk geen kenmerken van VM's op in uw app-specifieke store. Wees vooral voorzichtig met persoonsgegevens. Als voor specifieke stromen in uw toepassingen deze informatie nodig is, kunt u overwegen om de VC te vragen om de claims op aanvraag op te halen.

• VC-kenmerkcorrelatie met back-endsystemen: bij het definiëren van de kenmerken van de VC met de verlener, stelt u een mechanisme in om informatie in het back-endsysteem te correleren nadat de gebruiker de VC heeft gepresenteerd. Het mechanisme gebruikt doorgaans een tijdgebonden, unieke id in de context van uw RP in combinatie met de claims die u ontvangt. Een aantal voorbeelden:

  • Nieuwe werknemer: wanneer de HR-werkstroom het punt bereikt waarop identiteitsbewijs vereist is, kan de RP een koppeling genereren met een unieke id die afhankelijk is van een tijdsgebonden unieke id. De RP stuurt het vervolgens naar het e-mailadres van de kandidaat op het HR-systeem. Deze unieke id moet voldoende zijn om informatie te correleren, zoals firstName, lastName van de VC-verificatieaanvraag naar de HR-record of onderliggende gegevens. De kenmerken in de VC kunnen worden gebruikt om gebruikerskenmerken in het HR-systeem te voltooien of om de nauwkeurigheid van gebruikerskenmerken over de werknemer te valideren.

  • Externe identiteiten - uitnodiging: wanneer een externe gebruiker wordt uitgenodigd voor het doelsysteem, kan de RP een koppeling genereren met een unieke id die de uitnodigingstransactie vertegenwoordigt. Deze koppeling kan worden verzonden naar het e-mailadres van de externe gebruiker. Deze unieke id moet voldoende zijn om de VC-verificatieaanvraag te correleren met de uitnodigingsrecord of onderliggende gegevens en de inrichtingswerkstroom voort te zetten. De kenmerken in de VC kunnen worden gebruikt om de kenmerken van de externe gebruiker te valideren of te voltooien.

  • Externe identiteiten - selfservice: wanneer externe identiteiten zich registreren bij het doelsysteem via selfservice (bijvoorbeeld een B2C-toepassing) kunnen de kenmerken in de VC worden gebruikt om de eerste kenmerken van het gebruikersaccount te vullen. De VC-kenmerken kunnen ook worden gebruikt om erachter te komen of er al een profiel bestaat.

• Interactie met doelidentiteitssystemen: De service-naar-service-communicatie tussen de webfront-end en uw doelidentiteitssystemen moet worden beveiligd als een systeem met hoge bevoegdheden, omdat er accounts kunnen worden gemaakt. Verdeel de webfront-end de minst bevoegde rollen die mogelijk zijn. Enkele voorbeelden:

  • Als u een nieuwe gebruiker in Microsoft Entra ID wilt maken, kan de RP-website een service-principal gebruiken die het MS Graph-bereik heeft gekregen om User.ReadWrite.All gebruikers te maken en het bereik UserAuthenticationMethod.ReadWrite.All om de verificatiemethode opnieuw in te stellen.

  • Als u gebruikers wilt uitnodigen voor Microsoft Entra ID met B2B-samenwerking, kan de RP-website een service-principal gebruiken die het MS Graph-bereik heeft gekregen om User.Invite.All uitnodigingen te maken.

  • Als uw RP wordt uitgevoerd in Azure, gebruikt u Beheerde identiteiten om Microsoft Graph aan te roepen. Als u beheerde identiteiten gebruikt, worden de risico's voor het beheren van referenties van de service-principal in code- of configuratiebestanden verwijderd. Ga naar Beheerde identiteiten voor Azure-resources voor meer informatie over beheerde identiteiten.

Toegang tot hoogwaardige toepassingen binnen organisaties

Verifieerbare referenties kunnen worden gebruikt als ander bewijs voor toegang tot gevoelige toepassingen binnen de organisatie. Vm's kunnen bijvoorbeeld ook worden gebruikt om werknemers toegang te bieden tot Line-Of-Business-toepassingen op basis van het bereiken van specifieke criteria, zoals een certificering.

Andere elementen

Relying party-webfront-end: dit is de webfront-end van de toepassing die is verbeterd via API-aanroepen van aanvraagservice voor VC-presentaties en -validatie, op basis van uw bedrijfsvereisten.

Autorisatielogica voor gebruikerstoegang: logische laag in de toepassing die gebruikerstoegang autoriseert en wordt uitgebreid om de gebruikerskenmerken in de VC te gebruiken om autorisatiebeslissingen te nemen.

Andere back-endservices en afhankelijkheden: vertegenwoordigt de rest van de logica van de toepassing, die doorgaans ongewijzigd blijft door het opnemen van identiteitscontrole via VM's.

Overwegingen bij het ontwerpen

• Doel: Het doel van het scenario bepaalt welk type referentie en verlener nodig is. Typische scenario's zijn:

  • Autorisatie: In dit scenario presenteert de gebruiker de VC om een autorisatiebeslissing te nemen. Vm's die zijn ontworpen voor een bewijs van voltooiing van een training of met een specifieke certificering, zijn geschikt voor dit scenario. De VC-kenmerken moeten gedetailleerde informatie bevatten die kan leiden tot autorisatiebeslissingen en controle. De VC wordt bijvoorbeeld gebruikt om te certificeren dat de persoon is getraind en toegang heeft tot gevoelige financiële apps. De app-logica kan de afdelingsclaim controleren op fijnmazige autorisatie en de werknemer-id gebruiken voor controledoeleinden.

  • Bevestiging van identiteitsverificatie: in dit scenario is het doel om te bevestigen dat dezelfde persoon die in eerste instantie onboarding heeft uitgevoerd, inderdaad de persoon is die probeert toegang te krijgen tot de toepassing met hoge waarde. Een referentie van een verlener van identiteitsverificatie is geschikt. De toepassingslogica moet valideren dat de kenmerken van de VC overeenkomen met de gebruiker die zich in de toepassing heeft aangemeld.

• Intrekking controleren: wanneer u vm's gebruikt voor toegang tot gevoelige resources, is het gebruikelijk om de status van de VC te controleren met de oorspronkelijke verlener en toegang te weigeren voor ingetrokken VM's. Wanneer u met de verleners werkt, moet u ervoor zorgen dat intrekking expliciet wordt besproken als onderdeel van het ontwerp van uw scenario.

• Gebruikerservaring: Wanneer u pc's gebruikt voor toegang tot gevoelige resources, zijn er twee patronen die u kunt overwegen.

  • Stapsgewijze verificatie: gebruikers starten de sessie met de toepassing met bestaande verificatiemechanismen. Gebruikers moeten een VC presenteren voor specifieke hoogwaardige bewerkingen binnen de toepassing, zoals goedkeuringen van zakelijke werkstromen. Dit is geschikt voor scenario's waarbij dergelijke hoogwaardige bewerkingen eenvoudig kunnen worden geïdentificeerd en bijgewerkt binnen de toepassingsstromen.

  • Sessie-instelling: Gebruikers moeten een VC presenteren als onderdeel van het initiëren van de sessie met de toepassing. Het presenteren van een VC is geschikt wanneer de aard van de hele toepassing een hoge waarde heeft.

Toegang tot toepassingen buiten organisatiegrenzen

Verifieerbare referenties kunnen ook worden gebruikt door relying party's die toegang of voordelen willen verlenen op basis van lidmaatschap of arbeidsrelatie van een andere organisatie. Een e-commerceportal kan bijvoorbeeld voordelen bieden, zoals kortingen voor werknemers van een bepaald bedrijf, studenten van een bepaalde instelling, enzovoort.

De gedecentraliseerd karakter van verifieerbare referenties maakt dit scenario mogelijk zonder federatierelaties tot stand te brengen.

Andere elementen

Relying party-webfront-end: dit is de webfront-end van de toepassing die is verbeterd via API-aanroepen van aanvraagservice voor VC-presentaties en -validatie, op basis van uw bedrijfsvereisten.

Autorisatielogica voor gebruikerstoegang: logische laag in de toepassing die gebruikerstoegang autoriseert en wordt uitgebreid om de gebruikerskenmerken in de VC te gebruiken om autorisatiebeslissingen te nemen.

Andere back-endservices en afhankelijkheden: vertegenwoordigt de rest van de logica van de toepassing, die doorgaans ongewijzigd blijft door het opnemen van identiteitscontrole via VM's.

Overwegingen bij het ontwerpen

• Doel: Het doel van het scenario bepaalt welk type referentie en verlener nodig is. Typische scenario's zijn:

  • Verificatie: In dit scenario moet een gebruiker vc hebben om een dienstverband of relatie met een bepaalde organisatie(en) te bewijzen. In dit geval moet de RP worden geconfigureerd voor het accepteren van vm's die zijn uitgegeven door de doelorganisaties.

  • Autorisatie: Op basis van de toepassingsvereisten kunnen de toepassingen de VC-kenmerken gebruiken voor gedetailleerde autorisatiebeslissingen en controle. Als een e-commercewebsite bijvoorbeeld kortingen biedt aan werknemers van de organisaties op een bepaalde locatie, kunnen ze de geschiktheid van korting valideren op basis van de claim land/regio in de VC (indien aanwezig).

• Intrekking controleren: wanneer u vm's gebruikt voor toegang tot gevoelige resources, is het gebruikelijk om de status van de VC te controleren met de oorspronkelijke verlener en toegang te weigeren voor ingetrokken VM's. Wanneer u met de verleners werkt, moet u ervoor zorgen dat intrekking expliciet wordt besproken als onderdeel van het ontwerp van uw scenario.

• Gebruikerservaring: Gebruikers kunnen een VC presenteren als onderdeel van het initiëren van de sessie met de toepassing. Toepassingen bieden doorgaans ook een alternatieve methode om de sessie te starten voor gevallen waarin gebruikers geen vm's hebben.

Accountherstel

Verifieerbare referenties kunnen worden gebruikt als een methode voor accountherstel. Wanneer een gebruiker bijvoorbeeld zijn account moet herstellen, heeft hij of zij mogelijk toegang tot een website waarvoor ze een VC moeten presenteren en een Microsoft Entra-referentie opnieuw moeten instellen door MS Graph API's aan te roepen, zoals wordt weergegeven in het volgende diagram.

Notitie

Hoewel het scenario dat we in deze sectie beschrijven specifiek is voor het herstellen van Microsoft Entra-accounts, kan deze benadering ook worden gebruikt om accounts in andere systemen te herstellen.

Andere elementen

Accountportal: webfront-end waarmee de API-aanroepen voor VC-presentatie en -validatie worden ingedeeld. Deze indeling kan Microsoft Graph-aanroepen bevatten om accounts in Microsoft Entra-id te herstellen.

Aangepaste logica of werkstromen: logica met organisatiespecifieke stappen vóór en na het bijwerken van het gebruikersaccount. Aangepaste logica kan goedkeuringswerkstromen, andere validaties, logboekregistratie, meldingen, enzovoort bevatten.

Microsoft Graph: Maakt representational state transfer (REST) API's en clientbibliotheken beschikbaar voor toegang tot Microsoft Entra-gegevens die worden gebruikt om accountherstel uit te voeren.

Microsoft Entra Enterprise-directory: de Microsoft Entra-tenant die de accounts bevat die worden gemaakt of bijgewerkt via de accountportal.

Ontwerpoverwegingen

VC-kenmerkcorrelatie met Microsoft Entra-id: Bij het definiëren van de kenmerken van de VC in samenwerking met de verlener, moet u ervoor zorgen dat u akkoord gaat met claims die de gebruiker identificeren. Als idV bijvoorbeeld de identiteit verifieert vóór onboarding van werknemers, moet u ervoor zorgen dat de uitgegeven VC claims bevat die kunnen worden vergeleken met interne systemen. Dergelijke claims kunnen een telefoonnummer, adres of geboortedatum zijn. De RP kan vragen om informatie die niet in de VC is gevonden als onderdeel van dit proces, zoals de laatste vier cijfers van hun burgerservicenummer (SSN).

De rol van vm's met bestaande mogelijkheden voor het opnieuw instellen van referenties van Microsoft Entra: Microsoft Entra ID heeft een ingebouwde selfservice voor wachtwoordherstel (SSPR). Verifieerbare referenties kunnen worden gebruikt om een andere manier te bieden om te herstellen in gevallen waarin gebruikers geen toegang hebben tot of verloren controle over de SSPR-methode. In scenario's waarin de gebruiker zowel computer als mobiel verloren is gegaan, kan de gebruiker een VC opnieuw insluiten bij een verlener van identiteitsbewijs en deze presenteren om hun account op afstand te herstellen.

Op dezelfde manier kunt u een VC gebruiken om een tijdelijke toegangspas te genereren waarmee gebruikers hun MFA-verificatiemethoden opnieuw kunnen instellen zonder een wachtwoord.

Autorisatie: Maak een autorisatiemechanisme, zoals een beveiligingsgroep die door de RP wordt gecontroleerd voordat u doorgaat met het herstel van referenties. Zo kunnen alleen gebruikers in specifieke groepen in aanmerking komen voor het herstellen van een account met een VC.

Interactie met Microsoft Entra-id: De service-naar-service-communicatie tussen de webfront-end en Microsoft Entra-id moet worden beveiligd als een systeem met hoge bevoegdheden omdat de referenties van werknemers opnieuw kunnen worden ingesteld. Verdeel de webfront-end de minst bevoegde rollen die mogelijk zijn. Enkele voorbeelden:

• Verdeel de RP-website de mogelijkheid om een service-principal te gebruiken die het MS Graph-bereik UserAuthenticationMethod.ReadWrite.All heeft verleend om verificatiemethoden opnieuw in te stellen. Niet verlenen User.ReadWrite.All, waardoor gebruikers kunnen worden gemaakt en verwijderd.

• Als uw RP wordt uitgevoerd in Azure, gebruikt u Beheerde identiteiten om Microsoft Graph aan te roepen. Beheerde identiteiten verwijderen de risico's voor het beheren van referenties van de service-principal in code- of configuratiebestanden. Zie Beheerde identiteiten voor Azure-resources voor meer informatie.

Identiteitsbeheer plannen

Hier volgen IAM-overwegingen bij het opnemen van VM's aan relying party's. Relying party's zijn doorgaans toepassingen.

Verificatie

• Het onderwerp van een VC moet een mens zijn.

• Een mens heeft de VC in hun portemonnee en moet de VC interactief presenteren. Niet-interactieve stromen, zoals namens-of, worden niet ondersteund.

Autorisatie

• Een succesvolle presentatie van de VC kan worden beschouwd als een grofkorrelige autorisatiepoort op zichzelf. De VC-kenmerken kunnen ook worden gebruikt voor fijnmazige autorisatiebeslissingen.

• Bepaal of een verlopen VC betekenis heeft in uw toepassing; als dat het zo is, controleert u de waarde van de exp claim (de verlooptijd) van de VC als onderdeel van de autorisatiecontroles. Een voorbeeld waarbij vervaldatum niet relevant is, is het vereisen van een door de overheid uitgegeven document, zoals een rijbewijs om te valideren of het onderwerp ouder is dan 18. De geboortedatum is geldig, zelfs als de VC is verlopen.

• Bepaal of een ingetrokken VC betekenis heeft voor uw autorisatiebeslissing.

  • Als dit niet relevant is, slaat u de aanroep over om de status-API te controleren (die standaard is ingeschakeld).

  • Als dit relevant is, voegt u de juiste verwerking van uitzonderingen in uw toepassing toe.

Gebruikersprofielen

U kunt informatie in gepresenteerde VM's gebruiken om een gebruikersprofiel te maken. Als u kenmerken wilt gebruiken om een profiel te maken, moet u rekening houden met de volgende items.

• Wanneer de VC wordt uitgegeven, bevat deze een momentopname van kenmerken vanaf uitgifte. Vm's hebben mogelijk lange geldigheidsperioden en u moet de leeftijd bepalen van kenmerken die u als onderdeel van het profiel wilt gebruiken als voldoende nieuw om te gebruiken.

• Als een VC elke keer moet worden weergegeven wanneer het onderwerp een sessie met de RP start, kunt u overwegen de uitvoer van de VC-presentatie te gebruiken om een niet-permanent gebruikersprofiel met de kenmerken te maken. Een niet-permanent gebruikersprofiel helpt bij het verminderen van privacyrisico's met betrekking tot het opslaan van gebruikerseigenschappen in rust. Mogelijk moet uw toepassing de kenmerken van het onderwerp lokaal opslaan. Zo ja, sla dan alleen de claims op die uw toepassing nodig heeft. Sla de hele VC niet op.

• Als voor de toepassing een permanent gebruikersprofielarchief is vereist:

  • Overweeg het gebruik van de sub claim als onveranderbare id van de gebruiker. Dit is een ondoorzichtig uniek kenmerk dat constant is voor een bepaald onderwerp/RP-paar.

  • Definieer een mechanisme voor het ongedaan maken van de inrichting van het gebruikersprofiel uit de toepassing. Vanwege de gedecentraliseerd karakter van het Microsoft Entra geverifieerde ID systeem, is er geen levenscyclus voor het inrichten van gebruikers van toepassingen.

  • Sla geen claims voor persoonlijke gegevens op die worden geretourneerd in het VC-token.

  • Sla alleen claims op die nodig zijn voor de logica van de relying party.

Prestaties plannen

Net als bij elke oplossing moet u plannen voor prestaties. Focusgebieden omvatten latentie, doorvoer en schaalbaarheid. Tijdens de eerste fasen van een releasecyclus mogen de prestaties geen probleem zijn. Wanneer de implementatie van uw oplossing echter resulteert in een groot aantal verifieerbare referenties, kan de prestatieplanning een essentieel onderdeel van uw oplossing worden.

De volgende items bieden gebieden waar u rekening mee moet houden bij het plannen van prestaties:

• De Microsoft Entra geverifieerde id-uitgifteservice wordt geïmplementeerd in de Azure-regio's Europa - west, Europa - noord, VS -west 2 en VS - west-centraal. Als u de latentie wilt beperken, implementeert u uw verificatie-front-end (website) en sleutelkluis in de dichtstbijzijnde regio.

• Model op basis van doorvoer:

  • Vc-verificatiecapaciteit is onderhevig aan servicelimieten van Azure Key Vault.

  • Voor elke verificatie van een VC is één Key Vault-handtekeningbewerking vereist.

  • U kunt geen beperking beheren; We raden u echter aan om beperkingsrichtlijnen voor Azure Key Vault te lezen, zodat u begrijpt hoe beperking van invloed kan zijn op de prestaties.

Plannen voor betrouwbaarheid

Om het beste te plannen voor hoge beschikbaarheid en herstel na noodgevallen, raden we de volgende items aan:

• Microsoft Entra geverifieerde ID service wordt geïmplementeerd in de regio's Europa - west, Europa - noord, VS - west 2 en VS - west-centraal, Australië en Japan Azure. Overweeg om uw ondersteunende webservers en ondersteunende toepassingen in een van deze regio's te implementeren, met name in de regio's waarvan u verwacht dat het meeste validatieverkeer afkomstig is.

• Bekijk en integreer best practices van azure Key Vault-beschikbaarheid en redundantie tijdens het ontwerpen voor uw beschikbaarheids- en redundantiedoelen.

Beveiliging plannen

Houd rekening met het volgende bij het ontwerpen voor beveiliging:

• Alle relying party's (RPs) in één tenant hebben dezelfde vertrouwensgrens omdat ze dezelfde DID delen.

• Definieer een speciale service-principal voor een website die toegang heeft tot de Key Vault.

• Alleen de Microsoft Entra geverifieerde ID-service en de service-principals van de website moeten gemachtigd zijn om Key Vault te gebruiken om berichten met de persoonlijke sleutel te ondertekenen.

• Wijs geen beheerdersmachtigingen voor menselijke identiteiten toe aan de Key Vault. Zie Azure Security Baseline for Key Vault voor meer informatie over best practices voor Key Vault.

• Bekijk Het beveiligen van Azure-omgevingen met Microsoft Entra ID voor aanbevolen procedures voor het beheren van de ondersteunende services voor uw oplossing.

• Spoofing-risico's beperken door:

  • Het implementeren van DNS-verificatie om klanten te helpen de huisstijl van verleners te identificeren.

  • Gebruik domeinen die zinvol zijn voor eindgebruikers.

• Beperk gedistribueerde Denial of Service (DDOS) en Key Vault-resourcebeperkingsrisico's. Elke VC-presentatieaanvraag genereert ondertekeningsbewerkingen van Key Vault die zijn opgebouwd voor servicelimieten. U wordt aangeraden verkeer te beveiligen door alternatieve verificatie of captcha in te voegen voordat u uitgifteaanvragen genereert.

Plannen voor bewerkingen

Bij het plannen van bewerkingen wordt u aangeraden elke poging tot referentievalidatie vast te leggen als onderdeel van uw controle. Gebruik deze informatie voor controle en probleemoplossing. Daarnaast kunt u overwegen om unieke transactie-id's (ID's) te genereren waarnaar klanten en ondersteuningstechnici zo nodig kunnen verwijzen.

Overweeg het volgende te controleren als onderdeel van uw operationele planning:

• Voor schaalbaarheid:

  • Controleren van mislukte VC-validatie als onderdeel van end-to-end beveiligingsgegevens van toepassingen.

  • Controleer de end-to-end latentie van verificatie van referenties.

• Voor betrouwbaarheid en afhankelijkheden:

  • Controleer onderliggende afhankelijkheden die worden gebruikt door de verificatieoplossing.

  • Volg bewaking en waarschuwingen van Azure Key Vault.

• Voor beveiliging:

  • Schakel logboekregistratie voor Key Vault in om ondertekeningsbewerkingen bij te houden en om configuratiewijzigingen te bewaken en te waarschuwen. Raadpleeg Key Vault-logboekregistratie inschakelen voor meer informatie.

  • Archieflogboeken in SIEM-systemen (Security Information and Event Management), zoals Microsoft Sentinel voor langetermijnretentie.

Volgende stappen

Meer informatie over het ontwerpen van VC-oplossingen

• overzicht van Microsoft Entra geverifieerde ID

• Uw Microsoft Entra geverifieerde ID uitgifteoplossing plannen

Verifieerbare referenties implementeren

• Inleiding tot Microsoft Entra geverifieerde ID

• Aan de slag met verifieerbare referenties

Veelgestelde vragen