Planera din Microsoft Entra – verifierat ID verifieringslösning

Med Microsofts tjänst Microsoft Entra – verifierat ID (Microsoft Entra VC) kan du lita på bevis på användaridentitet utan att utöka förtroendegränsen. Med Microsoft Entra VC skapar du konton eller federerar med en annan identitetsprovider. När en lösning implementerar ett verifieringsutbyte med hjälp av verifierbara autentiseringsuppgifter kan program begära autentiseringsuppgifter som inte är bundna till en specifik domän. Den här metoden gör det enklare att begära och verifiera autentiseringsuppgifter i stor skala.

Om du inte redan har gjort det rekommenderar vi att du granskar översikten över Microsoft Entra – verifierat ID arkitektur. Du vill också granska Planera din Microsoft Entra – verifierat ID utfärdandelösning.

Vägledningens omfattning

Det här innehållet beskriver de tekniska aspekterna av planering för en verifierbar verifieringslösning för autentiseringsuppgifter med hjälp av Microsofts produkter och tjänster. Lösningsgränssnitten med ett förtroendesystem, där did-webben stöds för närvarande. DID Web är en centraliserad infrastruktur för offentliga nycklar.

Stödtekniker som inte är specifika för verifieringslösningar ligger utanför omfånget. Webbplatser används till exempel i en verifierbar verifieringslösning för autentiseringsuppgifter, men planeringen av en webbplatsdistribution beskrivs inte i detalj.

När du planerar verifieringslösningen måste du överväga vilken affärskapacitet som läggs till eller ändras. Du måste också tänka på vilka IT-funktioner som kan återanvändas och vilka funktioner som måste läggas till för att skapa lösningen. Tänk också på vilken utbildning som behövs för de personer som är involverade i affärsprocessen och de personer som stöder slutanvändare och personal i lösningen. De här artiklarna beskrivs inte i det här innehållet. Vi rekommenderar att du läser Microsoft Azure Well-Architected Framework för information om dessa artiklar.

Komponenter i lösningen

Som en del av din plan för en verifieringslösning måste du aktivera interaktionerna mellan kontrollanten, ämnet och utfärdaren. I den här artikeln används termerna förlitande part och kontrollant på ett utbytbart sätt. Följande diagram visar komponenterna i verifieringsarkitekturen.

Microsoft Entra – verifierat ID tjänst

I samband med en kontrollantlösning är Microsoft Entra – verifierat ID-tjänsten gränssnittet mellan Microsoft-komponenterna i lösningen och förtroendesystemet. Tjänsten etablerar nyckeluppsättningen till Key Vault, etablerar den decentraliserade identifieraren (DID).

Microsoft Entra-klientorganisation

Tjänsten kräver en Microsoft Entra-klientorganisation som tillhandahåller ett kontrollplan för identitets- och åtkomsthantering (IAM) för de Azure-resurser som ingår i lösningen. Varje Microsoft Entra-klient använder Microsoft Entra – verifierat ID-tjänsten för flera klientorganisationer och utfärdar ett enda DID-dokument som representerar kontrollanten. Om du har flera förlitande parter som använder din verifieringstjänst använder de alla samma verifierare DID. Verifieraren DID ger pekare till den offentliga nyckeln som gör att ämnen och utfärdare kan verifiera meddelanden som kommer från den förlitande parten.

Azure Key Vault

Azure Key Vault-tjänsten lagrar dina kontrollantnycklar, som genereras när du aktiverar Microsoft Entra – verifierat ID utfärdandetjänsten. Nycklarna används för att ge meddelandesäkerhet. Varje kontrollant har en enda nyckeluppsättning som används för signering, uppdatering och återställning av virtuella datorer. Den här nyckeluppsättningen används varje gång du skickar en verifieringsbegäran. Microsofts nyckeluppsättning använder för närvarande Elliptic Curve Cryptography (ECC) SECP256k1. Vi utforskar andra kryptografiska signaturscheman som antas av den bredare DID-communityn.

Api för begärandetjänst

Programprogrammeringsgränssnitt (API:er) ger utvecklare en metod för att abstrahera interaktioner mellan komponenter i lösningen för att utföra verifieringsåtgärder.

Förtroendesystem

Microsoft Entra – verifierat ID stöder för närvarandeDID Web som ett förtroendesystem, 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.

Förlitande part (RP)

Frontwebb

Den förlitande partens webbklientdel använder API:et för begärandetjänsten för att verifiera virtuella datorer genom att generera djupa länkar eller QR-koder som ämnets plånbok förbrukar. Beroende på scenariot kan klientdelen vara en offentligt tillgänglig eller intern webbplats för att aktivera slutanvändarupplevelser som kräver verifiering. Slutpunkterna som plånboken har åtkomst till måste dock vara offentligt tillgängliga. Mer specifikt styr den omdirigering till plånboken med specifika begärandeparametrar.

Affärslogik

Du kan skapa ny logik eller använda befintlig logik som är specifik för den förlitande parten och förbättra den logiken med presentationen av virtuella datorer.

Scenariospecifika design

Följande är exempel på design för att uppfylla specifika användningsfall. Den första är för kontoregistrering, som används för att minska tid, kostnad och risker som är associerade med registrering av nya anställda. Den andra är för kontoåterställning, som gör det möjligt för en slutanvändare att återställa eller låsa upp sitt konto med hjälp av en självbetjäningsmekanism. Den tredje är för åtkomst till värdefulla program och resurser, särskilt för användning från företag till företag där åtkomst ges till personer som arbetar för andra företag.

Kontoregistrering

Verifierbara autentiseringsuppgifter kan användas för att möjliggöra snabbare registrering genom att ersätta vissa mänskliga interaktioner. Virtuella datorer kan användas för att registrera anställda, studenter, medborgare eller andra för att få åtkomst till tjänster. I stället för att en anställd till exempel behöver gå till ett centralt kontor för att aktivera en anställds märke kan de använda en VC för att verifiera sin identitet för att aktivera ett märke som levereras till dem via fjärranslutning. I stället för att en medborgare som får en kod som de måste lösa in för att få tillgång till statliga tjänster kan de använda en VC för att bevisa sin identitet och få åtkomst.

Andra element

Onboarding-portalen: En webbklientdel som samordnar API:et för begärandetjänsten kräver VC-presentation och validering samt logiken för att registrera konton.

Anpassad logik/arbetsflöden: Specifik logik med organisationsspecifika steg före och efter uppdatering av användarkontot. Exempel kan vara arbetsflöden för godkännande, andra valideringar, loggning, meddelanden och så vidare.

Målidentitetssystem: Organisationsspecifika identitetsdatabaser som onboarding-portalen behöver interagera med när ämnen registreras. De system som ska integreras bestäms baserat på vilka typer av identiteter du vill registrera med VC-validering. Vanliga scenarier för identitetsverifiering för registrering är:

• Externa identiteter som Microsoft Entra ID registrerar med HJÄLP av API:er för att utfärda B2B-inbjudningar (business-to-business) eller tilldelning av berättigandehantering till paket.

• Medarbetarnas identiteter, som i centraliserade identitetssystem redan registreras via HR-system (Human Resources). I det här fallet kan identitetsverifieringen integreras som en del av befintliga steg i HR-arbetsflöden.

Designöverväganden

• Utfärdare: Kontoregistrering passar bra för en extern identitetssäker tjänst som utfärdare av de virtuella datorerna. Exempel på kontroller för registrering är: liveness check, myndighetsutfärdad dokumentverifiering, adress eller telefonnummerbekräftelse och så vidare.

• Lagra VC-attribut: Om möjligt lagrar du inte attribut från virtuella datorer i din appspecifika butik. Var särskilt försiktig med personuppgifter. Om specifika flöden i dina program kräver den här informationen kan du be VC att hämta anspråken på begäran.

• VC-attributkorrelation med backend-system: När du definierar attributen för VC med utfärdaren upprättar du en mekanism för att korrelera information i serverdelssystemet efter att användaren har lagt fram VC. Mekanismen använder vanligtvis en tidsbunden, unik identifierare i kontexten för din RP i kombination med de anspråk som du får. Några exempel:

  • Ny medarbetare: När HR-arbetsflödet når den punkt där identitetsbevis krävs kan RP generera en länk med en tidsbunden unik identifierare. RP skickar den sedan till kandidatens e-postadress i HR-systemet. Den här unika identifieraren bör vara tillräcklig för att korrelera information som firstName, lastName från VC-verifieringsbegäran till HR-posten eller underliggande data. Attributen i VC kan användas för att slutföra användarattribut i HR-systemet eller för att verifiera noggrannheten för användarattribut om medarbetaren.

  • Externa identiteter – inbjudan: När en extern användare bjuds in till målsystemet kan RP generera en länk med en unik identifierare som representerar inbjudan. Den här länken kan skickas till den externa användarens e-postadress. Den här unika identifieraren bör vara tillräcklig för att korrelera VC-verifieringsbegäran till inbjudningsposten eller underliggande data och fortsätta etableringsarbetsflödet. Attributen i VC kan användas för att verifiera eller slutföra de externa användarattributen.

  • Externa identiteter – självbetjäning: När externa identiteter registrerar sig för målsystemet via självbetjäning (till exempel ett B2C-program) kan attributen i VC användas för att fylla i användarkontots initiala attribut. VC-attributen kan också användas för att ta reda på om det redan finns en profil.

• Interaktion med målidentitetssystem: Tjänst-till-tjänst-kommunikationen mellan webbklientdelen och målidentitetssystemen måste skyddas som ett mycket privilegierat system, eftersom det kan skapa konton. Ge webbklientdelen de minst privilegierade roller som är möjliga. Vissa exempel inkluderar:

  • Om du vill skapa en ny användare i Microsoft Entra-ID kan RP-webbplatsen använda ett tjänsthuvudnamn som beviljas MS Graph-omfånget User.ReadWrite.All för att skapa användare och omfånget UserAuthenticationMethod.ReadWrite.All för att återställa autentiseringsmetoden.

  • Om du vill bjuda in användare till Microsoft Entra-ID med B2B-samarbete kan RP-webbplatsen använda ett huvudnamn för tjänsten som beviljas MS Graph-omfånget User.Invite.All för att skapa inbjudningar.

  • Om din RP körs i Azure använder du hanterade identiteter för att anropa Microsoft Graph. Om du använder hanterade identiteter tar du bort riskerna med att hantera autentiseringsuppgifter för tjänstens huvudnamn i kod- eller konfigurationsfiler. Mer information om hanterade identiteter finns i Hanterade identiteter för Azure-resurser.

Få åtkomst till värdefulla program i organisationer

Verifierbara autentiseringsuppgifter kan användas som andra bevis för åtkomst till känsliga program i organisationen. Virtuella datorer kan till exempel också användas för att ge anställda åtkomst till verksamhetsspecifika program baserat på att uppnå specifika kriterier, till exempel certifiering.

Andra element

Förlitande parts webbklientdel: Det här är webbklientdelen för programmet som förbättras via API för begärandetjänstanrop för VC-presentation och validering, baserat på dina affärskrav.

Logik för användaråtkomstauktorisering: Logikskiktet i programmet som tillåter användaråtkomst och utökas för att använda användarattributen i VC för att fatta auktoriseringsbeslut.

Andra serverdelstjänster och beroenden: Representerar resten av programmets logik, som vanligtvis inte ändras genom att identitetsbevis inkluderas via virtuella datorer.

Designöverväganden

• Mål: Målet med scenariot avgör vilken typ av autentiseringsuppgifter och utfärdare som behövs. Vanliga scenarier är:

  • Auktorisering: I det här scenariot presenterar användaren VC för att fatta ett auktoriseringsbeslut. Virtuella datorer som är utformade för att bevisa att en utbildning har slutförts eller som har en specifik certifiering passar bra för det här scenariot. VC-attributen bör innehålla detaljerad information som främjar auktoriseringsbeslut och granskning. Till exempel används VC för att certifiera att individen är utbildad och kan komma åt känsliga finansiella appar. Applogik kan kontrollera avdelningsanspråket för detaljerad auktorisering och använda medarbetar-ID:t i granskningssyfte.

  • Bekräftelse av identitetsverifiering: I det här scenariot är målet att bekräfta att samma person som ursprungligen registrerades verkligen är den som försöker komma åt programmet med högt värde. En autentiseringsuppgift från en utfärdare av identitetsverifiering passar bra. Programlogik bör verifiera att attributen från VC överensstämmer med användaren som loggade in i programmet.

• Kontrollera återkallande: När du använder virtuella datorer för åtkomst till känsliga resurser är det vanligt att kontrollera statusen för VC med den ursprungliga utfärdaren och neka åtkomst för återkallade virtuella datorer. När du arbetar med utfärdarna ska du se till att återkallandet uttryckligen diskuteras som en del av utformningen av ditt scenario.

• Användarupplevelse: När du använder virtuella datorer för att komma åt känsliga resurser finns det två mönster som du kan överväga.

  • Steg-upp-autentisering: Användare startar sessionen med programmet med befintliga autentiseringsmekanismer. Användare måste presentera en VC för specifika åtgärder med högt värde i programmet, till exempel godkännanden av affärsarbetsflöden. Detta passar bra för scenarier där sådana högvärdesåtgärder är enkla att identifiera och uppdatera i programflödena.

  • Sessionsetablering: Användare måste presentera en VC som en del av att initiera sessionen med programmet. Att presentera en VC passar bra när hela programmets natur är högt värde.

Åtkomst till program utanför organisationens gränser

Verifierbara autentiseringsuppgifter kan också användas av förlitande parter som vill bevilja åtkomst eller förmåner baserat på medlemskap eller anställningsrelation i en annan organisation. Till exempel kan en e-handelsportal erbjuda förmåner som rabatter till anställda i ett visst företag, studenter vid en viss institution osv.

Den decentraliserade typen av verifierbara autentiseringsuppgifter möjliggör det här scenariot utan att upprätta federationsrelationer.

Andra element

Förlitande parts webbklientdel: Det här är webbklientdelen för programmet som förbättras via API för begärandetjänstanrop för VC-presentation och validering, baserat på dina affärskrav.

Logik för användaråtkomstauktorisering: Logikskiktet i programmet som tillåter användaråtkomst och utökas för att använda användarattributen i VC för att fatta auktoriseringsbeslut.

Andra serverdelstjänster och beroenden: Representerar resten av programmets logik, som vanligtvis inte ändras genom att identitetsbevis inkluderas via virtuella datorer.

Designöverväganden

• Mål: Målet med scenariot avgör vilken typ av autentiseringsuppgifter och utfärdare som behövs. Vanliga scenarier är:

  • Autentisering: I det här scenariot måste en användare ha tillgång till VC för att bevisa anställning eller relation till en viss organisation. I det här fallet bör RP konfigureras för att acceptera virtuella datorer som utfärdats av målorganisationerna.

  • Auktorisering: Baserat på programkraven kan programmen använda VC-attributen för detaljerade auktoriseringsbeslut och granskning. Om en e-handelswebbplats till exempel erbjuder rabatter till anställda i organisationerna på en viss plats kan de verifiera rabattberättigande baserat på land/region-anspråket i VC (om det finns).

• Kontrollera återkallande: När du använder virtuella datorer för åtkomst till känsliga resurser är det vanligt att kontrollera statusen för VC med den ursprungliga utfärdaren och neka åtkomst för återkallade virtuella datorer. När du arbetar med utfärdarna ska du se till att återkallandet uttryckligen diskuteras som en del av utformningen av ditt scenario.

• Användarupplevelse: Användare kan presentera en VC som en del av att initiera sessionen med programmet. Vanligtvis tillhandahåller program också en alternativ metod för att starta sessionen för att hantera fall där användare inte har virtuella datorer.

Kontoåterställning

Verifierbara autentiseringsuppgifter kan användas som en metod för kontoåterställning. När en användare till exempel behöver återställa sitt konto kan de komma åt en webbplats som kräver att de presenterar en VC och initierar en återställning av Microsoft Entra-autentiseringsuppgifter genom att anropa MS Graph-API:er enligt följande diagram.

Kommentar

Även om scenariot som vi beskriver i det här avsnittet är specifikt för att återställa Microsoft Entra-konton, kan den här metoden också användas för att återställa konton i andra system.

Andra element

Kontoportal: Webbklientdel som samordnar API-anropen för VC-presentation och validering. Den här orkestreringen kan innehålla Microsoft Graph-anrop för att återställa konton i Microsoft Entra-ID.

Anpassad logik eller arbetsflöden: Logik med organisationsspecifika steg före och efter uppdatering av användarkontot. Anpassad logik kan omfatta arbetsflöden för godkännande, andra valideringar, loggning, meddelanden osv.

Microsoft Graph: Exponerar REST-API:er (representationstillståndsöverföring) och klientbibliotek för åtkomst till Microsoft Entra-data som används för att utföra kontoåterställning.

Microsoft Entra Enterprise-katalog: Microsoft Entra-klientorganisationen som innehåller de konton som skapas eller uppdateras via kontoportalen.

Utformningsbeaktanden

VC-attributkorrelation med Microsoft Entra-ID: När du definierar attributen för VC i samarbete med utfärdaren måste du komma överens om anspråk som identifierar användaren. Om identitetsverifieringsprovidern (IDV) till exempel verifierar identiteten innan du registrerar anställda ska du se till att den utfärdade VC:en innehåller anspråk som kan matchas mot interna system. Sådana anspråk kan vara ett telefonnummer, en adress eller ett födelsedatum. RP kan be om information som inte hittas i VC som en del av den här processen, till exempel de sista fyra siffrorna i deras socialförsäkringsnummer (SSN).

Roll för virtuella datorer med befintliga funktioner för återställning av Microsoft Entra-autentiseringsuppgifter: Microsoft Entra ID har en inbyggd SSPR-funktion (självbetjäning av lösenordsåterställning). Verifierbara autentiseringsuppgifter kan användas för att tillhandahålla ett annat sätt att återställa i fall där användare inte har åtkomst till eller förlorat kontrollen över SSPR-metoden. I scenarier där användaren har förlorat både datorn och mobilen kan användaren återkalla en VC från en identitetssäker utfärdare och presentera den för att återställa sitt konto via fjärranslutning.

På samma sätt kan du använda en VC för att generera ett tillfälligt åtkomstpass som gör det möjligt för användare att återställa sina MFA-autentiseringsmetoder utan lösenord.

Auktorisering: Skapa en auktoriseringsmekanism, till exempel en säkerhetsgrupp som RP kontrollerar innan du fortsätter med återställningen av autentiseringsuppgifter. Till exempel kan endast användare i specifika grupper vara berättigade att återställa ett konto med en VC.

Interaktion med Microsoft Entra-ID: Tjänst-till-tjänst-kommunikationen mellan webbklientdelen och Microsoft Entra-ID måste skyddas som ett mycket privilegierat system eftersom det kan återställa anställdas autentiseringsuppgifter. Ge webbklientdelen de minst privilegierade roller som är möjliga. Vissa exempel inkluderar:

• Ge RP-webbplatsen möjlighet att använda ett tjänsthuvudnamn som beviljats MS Graph-omfånget UserAuthenticationMethod.ReadWrite.All för att återställa autentiseringsmetoder. Bevilja User.ReadWrite.Allinte , vilket gör det möjligt att skapa och ta bort användare.

• Om din RP körs i Azure använder du hanterade identiteter för att anropa Microsoft Graph. Hanterade identiteter tar bort riskerna med att hantera autentiseringsuppgifter för tjänstens huvudnamn i kod- eller konfigurationsfiler. Mer information finns i Hanterade identiteter för Azure-resurser.

Planera för identitetshantering

Följande är IAM-överväganden när du införlivar virtuella datorer till förlitande parter. Förlitande parter är vanligtvis program.

Autentisering

• Ämnet för en VC måste vara en människa.

• En människa har VC i plånboken och måste interaktivt presentera VC. Icke-interaktiva flöden, till exempel å vägnar, stöds inte.

Auktorisering

• En lyckad presentation av VC kan betraktas som en grovkornig auktoriseringsport av sig själv. VC-attributen kan också användas för detaljerade auktoriseringsbeslut.

• Kontrollera om en utgången VC har betydelse i ditt program. Om så är fallet kontrollerar du värdet för anspråket exp (förfallotiden) för VC som en del av auktoriseringskontrollerna. Ett exempel där förfallodatum inte är relevant är att kräva att ett myndighetsutfärdande dokument, till exempel ett körkort, verifierar om ämnet är äldre än 18 år. Födelsedatumsanspråket är giltigt, även om VC har upphört att gälla.

• Kontrollera om en återkallad VC har betydelse för ditt auktoriseringsbeslut.

  • Om det inte är relevant hoppar du över anropet för att kontrollera status-API :et (som är aktiverat som standard).

  • Om det är relevant lägger du till rätt hantering av undantag i ditt program.

Användarprofiler

Du kan använda information i presenterade virtuella datorer för att skapa en användarprofil. Om du vill använda attribut för att skapa en profil bör du överväga följande objekt.

• När VC utfärdas innehåller den en ögonblicksbild av attribut från och med utfärdandet. Virtuella datorer kan ha långa giltighetsperioder och du måste fastställa ålder på attribut som du accepterar som tillräckligt färska för att kunna användas som en del av profilen.

• Om en VC måste visas varje gång ämnet startar en session med RP kan du överväga att använda utdata från VC-presentationen för att skapa en icke-beständig användarprofil med attributen. En icke-beständig användarprofil bidrar till att minska sekretessriskerna i samband med lagring av användaregenskaper i vila. Programmet kan behöva spara ämnets attribut lokalt. I så fall sparar du bara de anspråk som programmet behöver. Spara inte hela VC.

• Om programmet kräver ett beständigt användarprofilarkiv:

  • Överväg att använda anspråket sub som en oföränderlig identifierare för användaren. Det här är ett täckande unikt attribut som är konstant för ett visst ämne/RP-par.

  • Definiera en mekanism för att avetablera användarprofilen från programmet. På grund av Microsoft Entra – verifierat ID systemets decentraliserade karaktär finns det ingen livscykel för programanvändaretablering.

  • Lagra inte personliga dataanspråk som returneras i VC-token.

  • Lagra endast anspråk som behövs för logiken hos den förlitande parten.

Planera för prestanda

Precis som med alla lösningar måste du planera för prestanda. Fokusområden omfattar svarstid, dataflöde och skalbarhet. Under de inledande faserna i en lanseringscykel bör prestanda inte vara ett problem. Men när implementeringen av lösningen resulterar i att många verifierbara autentiseringsuppgifter verifieras kan prestandaplanering bli en viktig del av din lösning.

Följande objekt 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 och USA, västra centrala. Om du vill begränsa svarstiden distribuerar du din verifieringsklientdel (webbplats) och nyckelvalv i den närmaste regionen.

• Modell baserad på dataflöde:

  • VC-verifieringskapaciteten omfattas av tjänstbegränsningar för Azure Key Vault.

  • Varje verifiering av en VC kräver en nyckelvalvssignaturåtgärd.

  • Du kan inte styra begränsningen. Vi rekommenderar dock att du läser vägledningen för Azure Key Vault-begränsning så att du förstår hur begränsning kan påverka prestanda.

Planera för tillförlitlighet

Vi rekommenderar följande för att planera för hög tillgänglighet och haveriberedskap:

• Microsoft Entra – verifierat ID tjänsten distribueras i Azure-regionerna Europa, västra, Europa, norra, USA, västra 2 och USA, västra centrala, Australien och Japan. Överväg att distribuera dina stödwebbservrar och stödprogram i en av dessa regioner, särskilt i de som du förväntar dig att merparten av valideringstrafiken kommer från.

• Granska och införliva metodtips från Tillgänglighet och redundans i Azure Key Vault när du utformar för dina tillgänglighets- och redundansmål.

Planera för säkerhet

När du utformar för säkerhet bör du tänka på följande:

• Alla förlitande parter (RPs) i en enda klientorganisation har samma förtroendegräns eftersom de delar samma DID.

• Definiera ett dedikerat tjänsthuvudnamn för en webbplats som har åtkomst till Key Vault.

• Endast Microsoft Entra – verifierat ID-tjänsten och webbplatstjänstens huvudnamn ska ha behörighet att använda Key Vault för att signera meddelanden med den privata nyckeln.

• Tilldela inte någon administrativ behörighet för mänsklig identitet till Key Vault. Mer information om metodtips för Key Vault finns i Azure Security Baseline för Key Vault.

• Se Skydda Azure-miljöer med Microsoft Entra-ID för bästa praxis för att hantera de tjänster som stöds för din lösning.

• Minimera förfalskningsrisker genom att:

  • Implementera DNS-verifiering för att hjälpa kunder att identifiera varumärkesanpassning för utfärdare.

  • Använd domäner som är meningsfulla för slutanvändare.

• Minska risken för distribuerad denial of service (DDOS) och key vault-resursbegränsning. Varje VC-presentationsbegäran genererar key vault-signeringsåtgärder som ackumuleras mot tjänstbegränsningar. Vi rekommenderar att du skyddar trafiken genom att använda alternativ autentisering eller captcha innan du genererar utfärdandebegäranden.

Planera för åtgärder

När du planerar för åtgärder rekommenderar vi att du registrerar varje försök till validering av autentiseringsuppgifter som en del av din granskning. Använd den informationen för granskning och felsökning. Överväg också att generera unika transaktionsidentifierare (ID:er) som kunder och supporttekniker kan referera till om det behövs.

Som en del av din operativa planering bör du överväga att övervaka följande:

• För skalbarhet:

  • Övervaka misslyckad VC-validering som en del av slutpunkt till slutpunkt-säkerhetsmått för program.

  • Övervaka svarstiden från slutpunkt till slutpunkt för verifiering av autentiseringsuppgifter.

• För tillförlitlighet och beroenden:

  • Övervaka underliggande beroenden som används av verifieringslösningen.

  • Följ Övervakning och aviseringar för Azure Key Vault.

• För säkerhet:

  • Aktivera loggning för Key Vault för att spåra signeringsåtgärder och övervaka och varna 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.

Nästa steg

Läs mer om att utforma VC-lösningar

• Microsoft Entra – verifierat ID översikt

• Planera din Microsoft Entra – verifierat ID utfärdandelösning

Implementera verifierbara autentiseringsuppgifter

• Introduktion till Microsoft Entra – verifierat ID

• Kom igång med verifierbara autentiseringsuppgifter

Vanliga frågor och svar