Uw Microsoft Entra geverifieerde id-uitgifteoplossing plannen
Het is belangrijk om uw uitgifteoplossing te plannen, zodat u, naast het uitgeven van referenties, een volledig overzicht hebt van de gevolgen die uw oplossing heeft voor de architectuur en uw bedrijf. Als u dit nog niet hebt gedaan, raden we u aan het overzicht van door Microsoft Entra geverifieerde id-architectuur weer te geven voor basisinformatie.
Bereik van richtlijnen
In dit artikel worden de technische aspecten van het plannen van een uitgifteoplossing voor controleerbare legitimatiebewijzen behandeld. De Microsoft-oplossing voor controleerbare legitimatiebewijzen volgt de W3C-standaarden (World Wide Web Consortium) Verifiable Credentials Data Model 1.0 en Gedecentraliseerde id's (DIDs) V1.0, zodat ze kunnen samenwerken met niet-Microsoft-services. De voorbeelden in deze inhoud weerspiegelen echter de Microsoft-oplossingsstack voor controleerbare legitimatiebewijzen.
Buiten het bereik van deze inhoud vindt u artikelen over ondersteunende technologieën die niet specifiek zijn voor uitgifteoplossingen. Websites worden bijvoorbeeld gebruikt in een uitgifteoplossing voor controleerbare legitimatiebewijzen, maar het plannen van een website-implementatie wordt niet uitgebreid behandeld.
Onderdelen van de oplossing
Als onderdeel van uw plan voor een uitgifteoplossing moet u een oplossing ontwerpen waarmee de interacties tussen de verlener, de gebruiker en de verifier mogelijk zijn. In het volgende diagram ziet u de onderdelen van uw uitgiftearchitectuur.
Architectuur van Microsoft VC-uitgifteoplossing
Microsoft Entra-tenant
Een vereiste voor het uitvoeren van de Microsoft Entra geverifieerde ID-service is dat deze wordt gehost in een Microsoft Entra-tenant. De Microsoft Entra-tenant biedt een IAM-besturingsvlak (Identity and Access Management) voor de Azure-resources die deel uitmaken van de oplossing.
Elke tenant gebruikt de multitenant Microsoft Entra geverifieerde ID-service en heeft een gedecentraliseerde id (DID). De DID geeft bewijs dat de verlener eigenaar is van het domein dat is opgenomen in de DID. De DID wordt door het onderwerp en de verificator gebruikt om de verlener te valideren.
Microsoft Azure-services
De Azure Key Vault-service slaat uw verlenersleutels op die worden gegenereerd wanneer u de Microsoft Entra geverifieerde id-uitgifteservice start. De sleutels en metagegevens worden gebruikt om bewerkingen voor referentiebeheer uit te voeren en berichtbeveiliging te bieden.
Elke verlener heeft één sleutelset die wordt gebruikt voor ondertekening, bijwerken en herstellen. Deze sleutelset wordt gebruikt voor elke uitgifte van elk controleerbaar legitimatiebewijs die u produceert.
Microsoft Entra geverifieerde id-service wordt gebruikt voor het opslaan van metagegevens en definities van referenties, met name de regels en weergavedefinities voor uw referenties.
Weergavedefinities bepalen hoe claims worden weergegeven in de portemonnee van de houder en bevatten ook huisstijl en andere elementen. De weergavedefinitie kan worden gelokaliseerd in meerdere talen. Zie Uw controleerbaar legitimatiebewijs aanpassen.
Regels zijn een door de verlener gedefinieerd model dat de vereiste invoer van een controleerbaar legitimatiebewijs beschrijft. Regels hebben ook vertrouwde invoerbronnen gedefinieerd en de toewijzing van invoerclaims aan uitvoerclaims die zijn opgeslagen in de VC. Afhankelijk van het type attestation dat is gedefinieerd in de definitie van de regels, kunnen de invoerclaims afkomstig zijn van verschillende providers. Invoerclaims kunnen afkomstig zijn van een OIDC Identity Provider, van een id_token_hint of van zelfclaims tijdens uitgifte via gebruikersinvoer in de portemonnee.
- Invoer: zijn een subset van het model in het regelsbestand voor clientverbruik. De subset moet de set invoer beschrijven, waar de invoer moet worden opgehaald en het eindpunt dat moet worden aangeroepen om een controleerbaar legitimatiebewijs te verkrijgen.
Microsoft Entra geverifieerde id-service
Met de Microsoft Entra geverifieerde id-service kunt u VC's uitgeven en intrekken op basis van uw configuratie. De service:
Richt de gedecentraliseerde id (DID) in. Elke verlener heeft één DID per tenant.
Richt sleutelsets in op Key Vault.
Slaat de configuratiemetagegevens op die worden gebruikt door de uitgifteservice en Microsoft Authenticator.
Biedt rest API-interface voor verleners en verifier web-front-ends
Vertrouwenssysteem
Microsoft Entra geverifieerde ID ondersteunt momenteel web als vertrouwenssysteem DID Web, waar het DID-document wordt gehost op de webserver van 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.
Uitgiftebedrijfslogica
Uw uitgifteoplossing bevat een webfront-end waar gebruikers een VC, een identiteitsarchief en een ander kenmerkarchief aanvragen om waarden te verkrijgen voor claims over het onderwerp en andere back-endservices.
Een webfront-end dient uitgifteaanvragen voor de portemonnee van het onderwerp door deep links of QR-codes te genereren. Op basis van de configuratie van het contract kunnen andere onderdelen nodig zijn om te voldoen aan de vereisten voor het maken van een VC.
Deze services bieden ondersteunende rollen die niet per se hoeven te worden geïntegreerd met Microsoft Entra geverifieerde ID uitgifteservice. Deze laag omvat doorgaans:
OpenID Verbinding maken (OIDC)-compatibele service of -services worden gebruikt om id_tokens te verkrijgen die nodig zijn om de VC uit te geven. Bestaande identiteitssystemen zoals Microsoft Entra ID of Azure AD B2C kunnen de OIDC-compatibele service bieden, zoals aangepaste oplossingen zoals Identity Server.
Kenmerkarchieven : kenmerkarchieven bevinden zich mogelijk buiten directoryservices en bieden kenmerken die nodig zijn om een VC uit te geven. Een studentinformatiesysteem kan bijvoorbeeld claims geven over behaalde diploma's.
Aanvullende services in de middelste laag die bedrijfsregels bevatten voor zoekacties, valideren, facturering en andere runtimecontroles en werkstromen die nodig zijn om referenties uit te geven.
Zie de zelfstudie Uw Microsoft Entra-id configureren om verifieerbare referenties te verlenen voor meer informatie over het instellen van uw webfront-end.
Overwegingen voor het ontwerp van referenties
Uw specifieke gebruikscases bepalen het ontwerp van uw referenties. De use-case bepaalt:
de interoperabiliteitsvereisten
de manier waarop gebruikers hun identiteit moeten bewijzen om hun VC te verkrijgen
de claims die nodig zijn in de referenties
als referenties moeten worden ingetrokken
Gebruikscases voor referenties
Bij Microsoft Entra geverifieerde id zijn de meest voorkomende referentiegebruikscases:
Identiteitsverificatie: er wordt een referentie uitgegeven op basis van meerdere criteria. Meerdere criteria kunnen bestaan uit het verifiëren van de echtheid van door de overheid uitgegeven documenten, zoals een paspoort of rijbewijs, en het coreleren van de informatie in dat document met andere informatie, zoals:
selfie van een gebruiker
verificatie van de leeflijkheid
Dit soort referenties is geschikt voor scenario's voor identiteits-onboarding van nieuwe werknemers, partners, serviceproviders, studenten en andere instanties waarbij identiteitsverificatie essentieel is.
Bewijs van werkgelegenheid/lidmaatschap: er wordt een referentie afgegeven om een relatie tussen de gebruiker en een instelling te bewijzen. Dit soort referenties is geschikt voor toegang tot losjes gekoppelde business-to-business-toepassingen, zoals retailers die kortingen bieden aan werknemers of studenten. Een belangrijke waarde van vm's is hun draagbaarheid: zodra deze is uitgegeven, kan de gebruiker de VC in veel scenario's gebruiken.
Zie Verifiable Credential Use Cases (w3.org) voor meer gebruikscases.
Referentie-interoperabiliteit
Onderzoek als onderdeel van het ontwerpproces branchespecifieke schema's, naamruimten en id's waarmee u de interoperabiliteit en het gebruik kunt maximaliseren. Voorbeelden vindt u in Schema.org en de werkgroep claims en referenties.
Algemene schema's zijn een gebied waar nog steeds standaarden ontstaan. Een voorbeeld van een dergelijke inspanning is de Verifiable Credentials for Education Task Force. We raden u aan om opkomende standaarden in de branche van uw organisatie te onderzoeken en bij te dragen.
Referentietype en -kenmerken
Nadat u de gebruikscase voor een referentie hebt vastgesteld, moet u het referentietype bepalen en welke kenmerken u wilt opnemen in de referentie. Verificatoren kunnen de claims lezen in de VC die door de gebruikers worden gepresenteerd.
Alle controleerbare legitimatiebewijzen moeten hun type declareren in de regeldefinitie. Het referentietype onderscheidt een controleerbare legitimatiebewijs van andere referenties en zorgt voor interoperabiliteit tussen verleners en controleprogramma's. Als u een referentietype wilt aangeven, geeft u een of meer referentietypen op waaraan de referentie voldoet. Elk type is een unieke tekenreeks. Vaak wordt een URI gebruikt om wereldwijde uniekheid te garanderen. De URI hoeft niet adresseerbaar te zijn. Het wordt behandeld als een tekenreeks. Als voorbeeld kan een diplomareferentie die is uitgegeven door Contoso University de volgende typen declareren:
| Type | Doel |
|---|---|
https://schema.org/EducationalCredential |
Declareert dat diploma's die zijn uitgegeven door Contoso University kenmerken bevatten die zijn gedefinieerd door het schema.org-object EducationaCredential. |
https://schemas.ed.gov/universityDiploma2020 |
Declareert dat diploma's die zijn uitgegeven door Contoso University kenmerken bevatten die zijn gedefinieerd door het Amerikaanse Ministerie van Onderwijs. |
https://schemas.contoso.edu/diploma2020 |
Declareert dat diploma's die zijn uitgegeven door Contoso University kenmerken bevatten die zijn gedefinieerd door de Contoso University. |
Naast de branchespecifieke standaarden en schema's die mogelijk van toepassing zijn op uw scenario's, moet u rekening houden met de volgende aspecten:
Persoonlijke gegevens minimaliseren: Maak kennis met de gebruikscases met de minimale hoeveelheid persoonlijke gegevens die nodig zijn. Een VC die wordt gebruikt voor e-commercewebsites die kortingen biedt aan werknemers en alumni, kan bijvoorbeeld worden vervuld door de referentie te presenteren met alleen de voor- en achternaamclaims. Aanvullende informatie, zoals aanwervingsdatum, titel, afdeling, zijn niet nodig.
Voorkeur geven aan abstracte claims: elke claim moet voldoen aan de behoefte, terwijl de details worden geminimaliseerd. Een claim met de naam ageOver met discrete waarden zoals 13, 21, 60 is bijvoorbeeld abstracter dan een geboortedatumclaim.
Herroepbaarheid plannen: U wordt aangeraden een indexclaim te definiëren om mechanismen in te schakelen voor het zoeken en intrekken van referenties. U bent beperkt tot het definiëren van één indexclaim per contract. Het is belangrijk te weten dat waarden voor geïndexeerde claims niet worden opgeslagen in de back-end, alleen een hash van de claimwaarde. Zie Een eerder uitgegeven controleerbaar legitimatiebewijs intrekken voor meer informatie.
Raadpleeg de specificatie Verifiable Credentials Data Model 1.0 (w3.org) voor andere overwegingen over kenmerken van legitimatiebewijzen.
Kwaliteitskenmerken plannen
Prestaties plannen
Net als bij elke oplossing moet u plannen voor prestaties. De belangrijkste gebieden waarop u zich moet richten, zijn latentie en schaalbaarheid. Tijdens de eerste fasen van een releasecyclus mogen de prestaties geen probleem zijn. Wanneer de implementatie van uw uitgifteoplossing echter resulteert in een groot aantal controleerbare legitimatiebewijzen, kan de prestatieplanning een essentieel onderdeel van uw oplossing worden.
Hieronder vindt u gebieden waar u rekening mee moet houden bij het plannen van prestaties:
De Microsoft Entra geverifieerde ID uitgifteservice wordt geïmplementeerd in regio's Europa - west, Europa - noord, VS - west-centraal 2, VS - west-centraal, Australië en Japan Azure. Als uw Microsoft Entra-tenant zich in de EU bevindt, bevindt de Microsoft Entra geverifieerde ID service zich ook in de EU.
Als u de latentie wilt beperken, implementeert u de front-endwebsite en sleutelkluis van de uitgifte in de regio die hierboven wordt vermeld.
Model op basis van doorvoer:
De verlenerservice is onderhevig aan Azure Key Vault-servicelimieten.
Voor Azure Key Vault zijn er drie ondertekeningsbewerkingen betrokken bij elke VC-uitgifte:
Een voor uitgifteaanvraag van de website
Een voor de gemaakte VC
Een voor het gedownloade contract
U kunt de beperking niet beheren; u wordt echter aangeraden Azure Key Vault-beperkingsrichtlijnen te lezen.
Als u een grote implementatie en onboarding van VM's plant, kunt u overwegen vc-creatie in batches te maken om ervoor te zorgen dat u de limieten niet overschrijdt.
Bepaal wat u bewaakt als onderdeel van uw plan voor prestaties om de prestaties van de oplossing beter te begrijpen. Naast websitebewaking op toepassingsniveau kunt u het volgende overwegen wanneer u uw VC-uitgiftebewakingsstrategie definieert:
Voor schaalbaarheid kunt u overwegen metrische gegevens voor de volgende items te implementeren:
Definieer de logische fasen van uw uitgifteproces. Voorbeeld:
Eerste aanvraag
Onderhoud van de QR-code of dieptekoppeling
Kenmerken opzoeken
Aanroepen naar Microsoft Entra geverifieerde id-uitgifteservice
Uitgegeven referentie
Metrische gegevens definiëren op basis van de fasen:
Totaal aantal aanvragen (volume)
Aanvragen per tijdseenheid (doorvoer)
Besteedde tijd (latentie)
Bewaak Azure Key Vault met behulp van de volgende koppeling:
Bewaak de onderdelen die worden gebruikt voor uw bedrijfslogicalaag.
Plannen voor betrouwbaarheid
Om betrouwbaarheid te plannen, raden we het volgende aan:
Nadat u uw beschikbaarheids- en redundantiedoelen hebt gedefinieerd, gebruikt u de volgende handleidingen om te begrijpen hoe u uw doelen kunt bereiken:
Voor de front-end- en bedrijfslaag kan uw oplossing op een onbeperkt aantal manieren manifesteren. Net als bij elke oplossing moet u voor de afhankelijkheden die u identificeert, ervoor zorgen dat de afhankelijkheden tolerant en bewaakt zijn.
Als de zeldzame gebeurtenis dat de Microsoft Entra geverifieerde ID uitgifteservice of Azure Key Vault-services niet beschikbaar zijn, is de hele oplossing niet meer beschikbaar.
Plannen voor naleving
Uw organisatie heeft mogelijk specifieke nalevingsbehoeften met betrekking tot uw branche, type transacties of het land/de regio van de bewerking.
Gegevenslocatie: de Microsoft Entra geverifieerde id-uitgifteservice wordt geïmplementeerd in een subset van Azure-regio's. De service wordt alleen gebruikt voor rekenfuncties. We slaan geen waarden op van controleerbare legitimatiebewijzen in Microsoft-systemen. Als onderdeel van het uitgifteproces worden persoonsgegevens echter verzonden en gebruikt bij het uitgeven van virtuele machines. Het gebruik van de VC-service mag geen invloed hebben op de vereisten voor gegevenslocatie. Als u persoonlijke gegevens opslaat als onderdeel van identiteitsverificatie, moet deze worden opgeslagen op een manier en regio die voldoet aan uw nalevingsvereisten. Ga naar de website van het Microsoft Trust Center voor richtlijnen met betrekking tot Azure.
Referenties intrekken: bepaal of uw organisatie referenties moet intrekken. Een beheerder moet bijvoorbeeld referenties intrekken wanneer een werknemer het bedrijf verlaat. Zie Een eerder uitgegeven controleerbaar legitimatiebewijs intrekken voor meer informatie.
Verlopende referenties: bepaal hoe uw referenties verlopen. Als u bijvoorbeeld een VC uitgeeft als bewijs van het hebben van een rijbewijs, kan deze na een paar jaar verlopen. Andere vm's kunnen een kortere geldigheid hebben om ervoor te zorgen dat gebruikers regelmatig terugkomen om hun VC bij te werken.
Plannen voor bewerkingen
Bij het plannen van bewerkingen is het essentieel dat u een schema ontwikkelt voor het oplossen van problemen, rapportage en het onderscheiden van verschillende klanten die u ondersteunt. Als het operations-team verantwoordelijk is voor het uitvoeren van VC-intrekking, moet dat proces bovendien worden gedefinieerd. Elke stap in het proces moet worden gecorreleerd, zodat u kunt bepalen welke logboekvermeldingen kunnen worden gekoppeld aan elke unieke uitgifteaanvraag. Voor controle raden we u aan om elke poging tot het uitgeven van referenties afzonderlijk vast te leggen. Specifiek:
Genereer unieke transactie-id's waarnaar klanten en ondersteuningstechnici naar behoefte kunnen verwijzen.
Maak een mechanisme om de logboeken van Azure Key Vault-transacties te correleren met de transactie-id's van het uitgiftegedeelte van de oplossing.
Als u een service voor identiteitsverificatie bent die namens meerdere klanten VCs uitgeeft, controleert en beperkt u deze door de klant- of contract-id voor klantgerichte rapportage en facturering.
Als u een identiteitsverificatieservice bent die namens meerdere klanten VCs uitgeeft, gebruikt u de klant- of contract-id voor klantgerichte rapportage en facturering, bewaking en beperking.
Beveiliging plannen
Als onderdeel van uw ontwerpoverwegingen die zijn gericht op beveiliging, raden we het volgende aan:
Voor sleutelbeheer:
Maak een toegewezen Key Vault voor VC-uitgifte. Beperk Azure Key Vault-machtigingen voor de Microsoft Entra geverifieerde id-uitgifteservice en de service-principal van de front-endwebsite van de uitgifteservice.
Azure Key Vault behandelen als een systeem met hoge bevoegdheden: Azure Key Vault problemen met referenties voor klanten. Het wordt aangeraden geen menselijke identiteiten te laten bestaan over permanente machtigingen voor de Azure Key Vault-service. Beheerders mogen alleen maar tijd hebben om toegang te krijgen tot Key Vault. Raadpleeg Azure Security Baseline voor Key Vault voor meer aanbevolen procedures voor het gebruik van Azure Key Vault.
Voor service-principal die de front-endwebsite voor uitgifte vertegenwoordigt:
Definieer een toegewezen service-principal om toegang te verlenen tot Azure Key Vault. Als uw website zich in Azure bevindt, raden we u aan een door Azure beheerde identiteit te gebruiken.
Behandel de service-principal die de website en de gebruiker vertegenwoordigt als één vertrouwensgrens. Hoewel het mogelijk is om meerdere websites te maken, is er slechts één sleutel ingesteld voor de uitgifteoplossing.
Voor beveiligingslogboeken en -bewaking raden we de volgende items aan:
Schakel logboekregistratie en waarschuwingen van Azure Key Vault in om bewerkingen voor referentieuitgifte, sleutelextractiepogingen, machtigingswijzigingen bij te houden en waarschuwingen te controleren en te verzenden voor configuratiewijzigingen. Meer informatie vindt u bij Het inschakelen van Key Vault-logboekregistratie.
Archieflogboeken in SIEM-systemen (Security Information and Event Management), zoals Microsoft Sentinel voor langetermijnretentie.
Spoofing-risico's beperken met behulp van het volgende
DNS-verificatie om klanten te helpen bij het identificeren van huisstijlen van verleners.
Domeinnamen die zinvol zijn voor eindgebruikers.
Vertrouwde huisstijl die de eindgebruiker herkent.
Beperk gedistribueerde denial of service (DDOS) en Key Vault-risico's voor resourceuitputting. Elke aanvraag die een VC-uitgifteaanvraag activeert, genereert Key Vault-ondertekeningsbewerkingen die tot servicelimieten leiden. U wordt aangeraden verkeer te beveiligen door verificatie of captcha te integreren voordat u uitgifteaanvragen genereert.
Voor hulp bij het beheren van uw Azure-omgeving raden we u aan de Microsoft-cloudbeveiligingsbenchmark te bekijken en Azure-omgevingen te beveiligen met Microsoft Entra ID. Deze handleidingen bieden aanbevolen procedures voor het beheren van de onderliggende Azure-resources, waaronder Azure Key Vault, Azure Storage, websites en andere Azure-gerelateerde services en mogelijkheden.
Aanvullende overwegingen
Wanneer u uw POC hebt voltooid, verzamelt u alle informatie en documentatie die zijn gegenereerd en kunt u overwegen om de configuratie van de verlener te verwijderen.
Raadpleeg de Aanbevolen procedures voor het gebruik van Key Vault voor meer informatie over Key Vault-implementatie en -werking. Raadpleeg Azure-omgevingen beveiligen met Active Directory voor meer informatie over het beveiligen van Azure-omgevingen met Microsoft Entra-id.
Volgende stappen
Lees het architectuuroverzicht