Planera din Microsoft Entra – verifierat ID utfärdandelösning
Det är viktigt att planera utfärdandelösningen så att du, förutom att utfärda autentiseringsuppgifter, har en fullständig vy över arkitektur- och affärseffekterna av din lösning. Om du inte har gjort det rekommenderar vi att du visar översikten över Microsoft Entra – verifierat ID arkitektur för grundläggande information.
Vägledningens omfattning
Den här artikeln beskriver de tekniska aspekterna av planering för en verifierbar lösning för utfärdande av autentiseringsuppgifter. Microsoft-lösningen för verifierbara autentiseringsuppgifter följer V1.0-standarderna (World Wide Web Consortium) Verifiable Credentials Data Model 1.0 och Decentralized Identifiers (DIDs) V1.0 så att de kan samverka med icke-Microsoft-tjänster. Exemplen i det här innehållet återspeglar dock Microsofts lösningsstack för verifierbara autentiseringsuppgifter.
Omfånget för det här innehållet är artiklar som omfattar stödtekniker som inte är specifika för utfärdandelösningar. Webbplatser används till exempel i en verifierbar lösning för utfärdande av autentiseringsuppgifter, men planeringen av en webbplatsdistribution beskrivs inte i detalj.
Komponenter i lösningen
Som en del av din plan för en utfärdandelösning måste du utforma en lösning som möjliggör interaktioner mellan utfärdaren, användaren och kontrollanten. Följande diagram visar komponenterna i din utfärdandearkitektur.
Microsoft VC-utfärdandelösningsarkitektur
Microsoft Entra-klientorganisation
En förutsättning för att köra Microsoft Entra – verifierat ID-tjänsten är att den finns i en Microsoft Entra-klientorganisation. Microsoft Entra-klientorganisationen tillhandahåller ett kontrollplan för identitets- och åtkomsthantering (IAM) för de Azure-resurser som ingår i lösningen.
Varje klient använder tjänsten Microsoft Entra – verifierat ID multitenant och har en decentraliserad identifierare (DID). DID tillhandahåller bevis på att utfärdaren äger domänen som ingår i DID. DID används av ämnet och kontrollanten för att verifiera utfärdaren.
Microsoft Azure-tjänster
Azure Key Vault-tjänsten lagrar dina utfärdarnycklar, som genereras när du initierar Microsoft Entra – verifierat ID-utfärdandetjänsten. Nycklarna och metadata används för att köra hanteringsåtgärder för autentiseringsuppgifter och tillhandahålla meddelandesäkerhet.
Varje utfärdare har en enda nyckeluppsättning som används för signering, uppdatering och återställning. Den här nyckeluppsättningen används för varje utfärdande av varje verifierbar autentiseringsuppgift som du skapar.
Microsoft Entra – verifierat ID Service används för att lagra metadata och definitioner för autentiseringsuppgifter. Mer specifikt regler och visningsdefinitioner för dina autentiseringsuppgifter.
Visningsdefinitioner avgör hur anspråk visas i innehavarens plånbok och innehåller även varumärkesanpassning och andra element. Visningsdefinitionen kan lokaliseras till flera språk. Se Så här anpassar du dina verifierbara autentiseringsuppgifter.
Regler är en utfärdardefinierad modell som beskriver nödvändiga indata för en verifierbar autentiseringsuppgift. Regler definierade också betrodda indatakällor och mappning av indataanspråk till utdataanspråk som lagras i VC. Beroende på vilken typ av attestering som definieras i regeldefinitionen kan indataanspråken komma från olika leverantörer. Indataanspråk kan komma från en OIDC-identitetsprovider, från en id_token_hint eller från självsäkra anspråk under utfärdandet via användarindata i plånboken.
- Input – Är en delmängd av modellen i regelfilen för klientförbrukning. Delmängden måste beskriva uppsättningen med indata, var du kan hämta indata och slutpunkten som ska anropas för att hämta en verifierbar autentiseringsuppgift.
Microsoft Entra – verifierat ID tjänst
Med tjänsten Microsoft Entra – verifierat ID kan du utfärda och återkalla virtuella datorer baserat på din konfiguration. Tjänsten:
Etablerar den decentraliserade identifieraren (DID). Varje utfärdare har en enda DID per klientorganisation.
Etablerar nyckeluppsättningar till Key Vault.
Lagrar konfigurationsmetadata som används av utfärdandetjänsten och Microsoft Authenticator.
Tillhandahåller REST API:er-gränssnitt för utfärdare och kontrollantwebbklientdelar
Förtroendesystem
Microsoft Entra – verifierat ID stöder för närvarande web som förtroendesystem DID Web, där DID-dokumentet finns på utfärdarens webbserver.
Microsoft Authenticator-program
Microsoft Authenticator är det mobila programmet. Authenticator samordnar interaktionerna mellan användaren, Microsoft Entra – verifierat ID-tjänsten och kontraktet som används för att utfärda virtuella datorer. Det fungerar som en digital plånbok där innehavaren av VC lagrar VC, inklusive den privata nyckeln i ämnet för VC. Authenticator är också den mekanism som används för att presentera virtuella datorer för verifiering.
Utfärdande av affärslogik
Din utfärdandelösning innehåller en webbklientdel där användare begär en VC, ett identitetslager och ett annat attributarkiv för att hämta värden för anspråk om ämnet och andra serverdelstjänster.
En webbklientdel hanterar utfärdandebegäranden till ämnets plånbok genom att generera djupa länkar eller QR-koder. Baserat på konfigurationen av kontraktet kan andra komponenter krävas för att uppfylla kraven för att skapa en VC.
Dessa tjänster tillhandahåller stödroller som inte nödvändigtvis behöver integreras med Microsoft Entra – verifierat ID utfärdandetjänsten. Det här lagret innehåller vanligtvis:
OpenID-Anslut (OIDC)-kompatibla tjänster används för att hämta id_tokens som behövs för att utfärda VC. Befintliga identitetssystem som Microsoft Entra ID eller Azure AD B2C kan tillhandahålla den OIDC-kompatibla tjänsten, liksom anpassade lösningar som Identity Server.
Attributlager – Attributlager kan ligga utanför katalogtjänster och tillhandahålla attribut som behövs för att utfärda en VC. Ett informationssystem för studenter kan till exempel ge anspråk om intjänade examina.
Ytterligare tjänster på mellannivå som innehåller affärsregler för sökningar, validering, fakturering och andra körningskontroller och arbetsflöden som behövs för att utfärda autentiseringsuppgifter.
Mer information om hur du konfigurerar webbklientdelen finns i självstudien Konfigurera ditt Microsoft Entra-ID för att utfärda verifierbara autentiseringsuppgifter.
Designöverväganden för autentiseringsuppgifter
Dina specifika användningsfall avgör din design av autentiseringsuppgifter. Användningsfallet avgör:
kraven på samverkan
hur användarna måste bevisa sin identitet för att få sin VC
de anspråk som behövs i autentiseringsuppgifterna
om autentiseringsuppgifterna måste återkallas
Användningsfall för autentiseringsuppgifter
Med Microsoft Entra – verifierat ID är de vanligaste användningsfallen för autentiseringsuppgifter:
Identitetsverifiering: en autentiseringsuppgift utfärdas baserat på flera kriterier. Flera kriterier kan vara att verifiera äktheten hos myndighetsutfärdade dokument, till exempel ett pass eller körkort, och att ange informationen i dokumentet med annan information, till exempel:
en användares selfie
verifiering av livskraft
Den här typen av autentiseringsuppgifter passar bra för identitetsregistreringsscenarier för nya anställda, partners, tjänsteleverantörer, studenter och andra instanser där identitetsverifiering är viktigt.
Bevis på anställning/medlemskap: en autentiseringsuppgift utfärdas för att bevisa en relation mellan användaren och en institution. Den här typen av autentiseringsuppgifter passar bra för att få tillgång till löst kopplade program från företag till företag, till exempel återförsäljare som erbjuder rabatter till anställda eller studenter. Ett huvudvärde för virtuella datorer är deras portabilitet: När de har utfärdats kan användaren använda VC i många scenarier.
Fler användningsfall finns i Verifierbara användningsfall för autentiseringsuppgifter (w3.org).
Samverkan mellan autentiseringsuppgifter
Som en del av designprocessen undersöker du branschspecifika scheman, namnområden och identifierare som du kan justera för att maximera samverkan och användning. Exempel finns i Schema.org och dif – arbetsgruppen för anspråk och autentiseringsuppgifter.
Vanliga scheman är ett område där standarder fortfarande håller på att växa fram. Ett exempel på en sådan insats är verifierbara autentiseringsuppgifter för utbildningsaktivitetsstyrkan. Vi rekommenderar att du undersöker och bidrar till nya standarder i organisationens bransch.
Typ och attribut för autentiseringsuppgifter
När du har upprättat användningsfallet för en autentiseringsuppgift måste du bestämma typen av autentiseringsuppgifter och vilka attribut som ska ingå i autentiseringsuppgifterna. Kontrollanter kan läsa anspråken i den VC som presenteras av användarna.
Alla verifierbara autentiseringsuppgifter måste deklarera sin typ i regeldefinitionen. Typ av autentiseringsuppgifter skiljer ett schema för verifierbara autentiseringsuppgifter från andra autentiseringsuppgifter och säkerställer samverkan mellan utfärdare och verifierare. Ange en eller flera typer av autentiseringsuppgifter som autentiseringsuppgifterna uppfyller för att ange en typ av autentiseringsuppgifter. Varje typ är en unik sträng. Ofta används en URI för att säkerställa global unikhet. URI:n behöver inte vara adresserbar. Den behandlas som en sträng. Till exempel kan ett examensbevis utfärdat av Contoso University deklarera följande typer:
| Typ | Syfte |
|---|---|
https://schema.org/EducationalCredential |
Deklarerar att diplom som utfärdats av Contoso University innehåller attribut som definierats av objektet schema.org EducationaCredential . |
https://schemas.ed.gov/universityDiploma2020 |
Deklarerar att diplom som utfärdats av Contoso University innehåller attribut som definierats av U.S. Department of Education. |
https://schemas.contoso.edu/diploma2020 |
Intygar att diplom som utfärdats av Contoso University innehåller attribut som definierats av Contoso University. |
Utöver de branschspecifika standarder och scheman som kan vara tillämpliga på dina scenarier bör du tänka på följande aspekter:
Minimera privat information: Uppfylla användningsfallen med den minimala mängd privat information som krävs. Till exempel kan en VC som används för e-handelswebbplatser som erbjuder rabatter till anställda och alumner uppfyllas genom att presentera autentiseringsuppgifterna med bara för- och efternamnsanspråken. Ytterligare information, till exempel anställningsdatum, titel, avdelning, behövs inte.
Favor abstrakta anspråk: Varje anspråk bör uppfylla behovet samtidigt som detaljerna minimeras. Till exempel är ett anspråk med namnet "ageOver" med diskreta värden som 13, 21, 60, mer abstrakt än ett födelsedatumanspråk.
Planera för återkallning: Vi rekommenderar att du definierar ett indexanspråk för att aktivera mekanismer för att hitta och återkalla autentiseringsuppgifter. Du är begränsad till att definiera ett indexanspråk per kontrakt. Det är viktigt att observera att värden för indexerade anspråk inte lagras i serverdelen, bara en hash av anspråksvärdet. Mer information finns i Återkalla en tidigare utfärdad verifierbar autentiseringsuppgift.
Andra överväganden om attribut för autentiseringsuppgifter finns i specifikationen Verifiable Credentials Data Model 1.0 (w3.org).
Planera kvalitetsattribut
Planera för prestanda
Precis som med alla lösningar måste du planera för prestanda. De viktigaste områdena att fokusera på är svarstid och skalbarhet. Under de inledande faserna i en lanseringscykel bör prestanda inte vara ett problem. Men när implementeringen av utfärdandelösningen resulterar i att många verifierbara autentiseringsuppgifter utfärdas kan prestandaplanering bli en viktig del av din lösning.
Följande innehåller områden att tänka på när du planerar för prestanda:
Den Microsoft Entra – verifierat ID utfärdandetjänsten distribueras i Azure-regionerna Europa, västra, Europa, norra, USA, västra 2, USA, västra centrala, Australien och Japan. Om din Microsoft Entra-klientorganisation finns inom EU finns Microsoft Entra – verifierat ID även i EU.
Om du vill begränsa svarstiden distribuerar du din klientdelswebbplats för utfärdande och nyckelvalvet i den region som anges ovan.
Modell baserad på dataflöde:
Utfärdartjänsten omfattas av tjänstbegränsningar för Azure Key Vault.
För Azure Key Vault finns det tre signeringsåtgärder som ingår i varje VC-utfärdande:
En för utfärdandebegäran från webbplatsen
En för den VC som skapats
En för nedladdning av kontraktet
Du kan inte styra begränsningen. Vi rekommenderar dock att du läser vägledningen för Azure Key Vault-begränsning.
Om du planerar en stor distribution och registrering av virtuella datorer bör du överväga att skapa VC för att säkerställa att du inte överskrider gränserna.
Som en del av din plan för prestanda avgör du vad du övervakar för att bättre förstå lösningens prestanda. Utöver övervakning av webbplatser på programnivå bör du överväga följande när du definierar din strategi för övervakning av VC-utfärdande:
För skalbarhet bör du överväga att implementera mått för följande objekt:
Definiera de logiska faserna i utfärdandeprocessen. Till exempel:
Inledande begäran
Underhåll av QR-koden eller djuplänken
Attributsökning
Anrop till Microsoft Entra – verifierat ID utfärdandetjänst
Utfärdade autentiseringsuppgifter
Definiera mått baserat på faserna:
Totalt antal begäranden (volym)
Begäranden per tidsenhet (dataflöde)
Tidsåtgång (svarstid)
Övervaka Azure Key Vault med hjälp av följande länk:
Övervaka de komponenter som används för ditt affärslogiklager.
Planera för tillförlitlighet
För att planera för tillförlitlighet rekommenderar vi:
När du har definierat dina tillgänglighets- och redundansmål använder du följande guider för att förstå hur du uppnår dina mål:
För klientdels- och affärslager kan din lösning visas på ett obegränsat antal olika sätt. Som med alla lösningar ser du till att beroendena är motståndskraftiga och övervakade för de beroenden du identifierar.
Om den sällsynta händelsen som Microsoft Entra – verifierat ID utfärdandetjänsten eller Azure Key Vault-tjänsterna blir otillgänglig blir hela lösningen otillgänglig.
Planera för efterlevnad
Din organisation kan ha specifika efterlevnadsbehov relaterade till din bransch, typ av transaktioner eller verksamhetsland/region.
Datahemvist: Den Microsoft Entra – verifierat ID utfärdandetjänsten distribueras i en delmängd av Azure-regioner. Tjänsten används endast för beräkningsfunktioner. Vi lagrar inte värden för verifierbara autentiseringsuppgifter i Microsoft-system. Men som en del av utfärdandeprocessen skickas och används personuppgifter när virtuella datorer utfärdas. Användning av VC-tjänsten bör inte påverka kraven på datahemvist. Om du lagrar personlig information som en del av identitetsverifieringen bör den lagras på ett sätt och en region som uppfyller dina efterlevnadskrav. Azure-relaterad vägledning finns på webbplatsen för Microsoft Trust Center.
Återkalla autentiseringsuppgifter: Kontrollera om din organisation behöver återkalla autentiseringsuppgifter. En administratör kan till exempel behöva återkalla autentiseringsuppgifter när en anställd lämnar företaget. Mer information finns i Återkalla en tidigare utfärdad verifierbar autentiseringsuppgift.
Autentiseringsuppgifter som upphör att gälla: Avgör hur dina autentiseringsuppgifter upphör att gälla. Om du till exempel utfärdar en VC som bevis på att du har ett körkort kan det upphöra att gälla efter några år. Andra virtuella datorer kan ha kortare giltighet för att se till att användarna kommer tillbaka regelbundet för att uppdatera sin VC.
Planera för åtgärder
När du planerar för åtgärder är det viktigt att du utvecklar ett schema som du kan använda för att felsöka, rapportera och särskilja olika kunder som du stöder. Om driftteamet dessutom ansvarar för att köra VC-återkallning måste den processen definieras. Varje steg i processen bör korreleras så att du kan avgöra vilka loggposter som kan associeras med varje unik utfärdandebegäran. För granskning rekommenderar vi att du samlar in varje försök att utfärda autentiseringsuppgifter individuellt. Specifikt:
Generera unika transaktions-ID:t som kunder och supporttekniker kan referera till efter behov.
Utforma en mekanism för att korrelera loggarna för Azure Key Vault-transaktioner med transaktions-ID:t för utfärdandedelen av lösningen.
Om du är en identitetsverifieringstjänst som utfärdar virtuella datorer för flera kunders räkning övervakar och åtgärdar du kund- eller kontrakts-ID:t för kundriktad rapportering och fakturering.
Om du är en identitetsverifieringstjänst som utfärdar virtuella datorer för flera kunders räkning använder du kund- eller kontrakts-ID:t för kundriktad rapportering och fakturering, övervakning och förmildrande åtgärder.
Planera för säkerhet
Som en del av dina designöverväganden som fokuserar på säkerhet rekommenderar vi följande:
För nyckelhantering:
Skapa ett dedikerat Key Vault för VC-utfärdande. Begränsa Azure Key Vault-behörigheter till den Microsoft Entra – verifierat ID utfärdandetjänsten och tjänstens huvudnamn för klientdelswebbplatsen för utfärdandetjänsten.
Behandla Azure Key Vault som ett mycket privilegierat system – Azure Key Vault utfärdar autentiseringsuppgifter till kunder. Vi rekommenderar att inga mänskliga identiteter har stående behörigheter över Azure Key Vault-tjänsten. Administratörer bör bara ha tidsåtkomst till Key Vault. Mer metodtips för Azure Key Vault-användning finns i Azure Security Baseline för Key Vault.
För tjänstens huvudnamn som representerar klientdelswebbplatsen för utfärdande:
Definiera ett dedikerat tjänsthuvudnamn för att auktorisera åtkomst till Azure Key Vault. Om din webbplats finns i Azure rekommenderar vi att du använder en Hanterad Azure-identitet.
Behandla tjänstens huvudnamn som representerar webbplatsen och användaren som en enda förtroendegräns. Det är möjligt att skapa flera webbplatser, men det finns bara en nyckeluppsättning för utfärdandelösningen.
För säkerhetsloggning och övervakning rekommenderar vi följande:
Aktivera loggning och aviseringar för Azure Key Vault för att spåra utfärdandeåtgärder för autentiseringsuppgifter, försök till extrahering av nycklar, behörighetsändringar och för att övervaka och skicka aviseringar om konfigurationsändringar. Mer information finns i Aktivera Key Vault-loggning.
Arkivera loggar i ett SIEM-system (säkerhetsinformation och händelsehantering), till exempel Microsoft Sentinel för långsiktig kvarhållning.
Minimera förfalskningsrisker med hjälp av följande
DNS-verifiering som hjälper kunder att identifiera varumärkesanpassning för utfärdare.
Domännamn som är meningsfulla för slutanvändare.
Betrodd varumärkesanpassning som slutanvändaren känner igen.
Minska risken för överbelastning av distribuerade överbelastningstester (DDOS) och Key Vault-resurser. Varje begäran som utlöser en VC-utfärdandebegäran genererar key vault-signeringsåtgärder som ackumuleras mot tjänstgränser. Vi rekommenderar att du skyddar trafiken genom att införliva autentisering eller captcha innan du genererar utfärdandebegäranden.
Om du vill ha vägledning om hur du hanterar din Azure-miljö rekommenderar vi att du går igenom Microsofts prestandamått för molnsäkerhet och Skydda Azure-miljöer med Microsoft Entra-ID. De här guiderna innehåller metodtips för att hantera underliggande Azure-resurser, inklusive Azure Key Vault, Azure Storage, webbplatser och andra Azure-relaterade tjänster och funktioner.
Ytterligare överväganden
När du har slutfört din POC samlar du in all information och dokumentation som genereras och överväger att ta bort utfärdarkonfigurationen.
Mer information om implementering och åtgärder för Key Vault finns i Metodtips för att använda Key Vault. Mer information om hur du skyddar Azure-miljöer med Active Directory finns i Skydda Azure-miljöer med Microsoft Entra-ID.
Nästa steg
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för