Planera din verifieringslösning för Microsoft Entra Verified ID

Microsofts Microsoft Entra-verifierade ID-tjänst (Microsoft Entra VC) gör att du kan lita på bevis på användaridentitet utan att utöka din förtroendegräns. 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 översikt över Microsoft Entra-verifierad ID-arkitektur. Du vill också granska Planera din Microsoft Entra-verifierade 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ösningen gränssnittar med ett förtroendesystem där DID Web för närvarande stöds. 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-verifierad ID-tjänst

I samband med en kontrollantlösning är Microsoft Entra-verifierad 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-tenanten

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-verifierad ID-tjänst för flera klienter 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. Verifikatets DID ger pekare till den offentliga nyckeln som gör att subjekt och utfärdare kan validera meddelanden som kommer från den betrodda parten.

Azure Key Vault

Azure Key Vault-tjänsten lagrar dina verifierarnycklar, som genereras när du aktiverar utfärdandetjänsten för Microsoft Entra-verifierat ID. 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 verifierbara intyg. Verifierat ID använder den här nyckeluppsättningen 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ärvarande DID Web som ett förtroendesystem, där DID-dokumentet finns på utfärdarens webbserver.

Microsoft Authenticator-applikation

Microsoft Authenticator är det mobila programmet. Authenticator samordnar interaktionerna mellan användaren, Microsoft Entra VC-tjänsten och kontraktet som används för att utfärda verifierbara identiteter. Det fungerar som en digital plånbok där innehavaren av VC lagrar VC, inklusive den privata nyckeln för den VC som avses. Authenticator är också den mekanism som används för att presentera virtuella datorer för verifiering.

Förlitande part (RP)

Webbgränssnitt

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 VC:er.

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

Onboardingportal: En webbfrontend som samordnar API-anropen för begärandetjänsten för VC-presentation och validering samt logiken för att anlägga 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 du registrerar ämnen. 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 business-to-business (B2B) inbjudningar eller tilldelning av behörighetshantering 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

• Issuer: Kontoregistrering passar bra för en extern identitetsverifieringstjänst som utfärdare av de verifierbara uppgifterna. Exempel på kontroller för registrering är: kontroll av livstecken, myndighetsutfärdad dokumentverifiering, adress- eller telefonnummerbekräftelse, med mera.

• Lagring av attribut från VCs: Lagra inte, om möjligt, attribut från VCs i din appspecifika butik. Var särskilt försiktig med personuppgifter. Om specifika flöden i dina applikationer kräver denna information kan du be att VC hämtar uppgifterna på begäran.

• VC-attributkorrelation med backend-system: När du definierar attributen för VC med utfärdaren, upprätta en mekanism för att korrelera information i det bakomliggande systemet efter att användaren har presenterat VC. Mekanismen använder vanligtvis en tidsbegränsad, unik identifierare i kontexten för din RP i kombination med de krav 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-begäran om verifiering till HR-registret 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-verifieringsförfrågan till inbjudningsposten eller underliggande data och fortsätta tilldelningsarbetsflö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: Service-to-Service-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. Några exempel är:

  • Om du vill skapa en ny användare i Microsoft Entra-ID kan RP-webbplatsen använda ett huvudnamn för tjänsten som beviljas MS Graph-omfånget för 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 en service principal som medges MS Graph-behörigheten 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 parters webbgränssnitt är webbgränssnittet för applikationen som har förbättrats genom begärandetjänst-API-anrop för presentation och validering av VC, baserat på dina affärskrav.

auktoriseringslogik för användaråtkomst är programmets logiklager som auktoriserar användaråtkomst. Det har förbättrats för att använda användarattributen i VC för att fatta auktoriseringsbeslut.

Andra tjänster på serverdelen och beroenden: Representerar resten av applikationens logik, vilket vanligtvis förblir oförändrat när identitetsverifiering genom verifierbara intyg inkluderas.

Designöverväganden

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

  • Authorization: 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 ombordsteg verkligen är den som försöker komma åt högvärdesapplikationen. En referens från en utfärdare av identitetsverifiering skulle passa bra. Programlogik bör verifiera att attributen från VC överensstämmer med användaren som loggade in i programmet.

• Check Revocation: När du använder VC för att komma åt sekretessbelagda resurser är det vanligt att kontrollera statusen för VC med den ursprungliga utfärdaren och neka åtkomst för återkallade VC. 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.

  • Step-up authentication: 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 ett riskkapitalbolag passar bra när hela ansökans natur är av 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

Tillitsparters webbgränssnitt: Det här är programvarans webbgränssnitt, som har förbättrats genom API-anrop från begärandetjänsten för presentation och validering av VC, baserat på dina affärskrav.

Logik för användaråtkomstauktorisering: Logiklager i programmet som auktoriserar 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 applikationens logik, som vanligtvis är oförändrad av tillägget av identitetsverifiering genom VCs.

Designöverväganden

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

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

  • Authorization: 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).

• Check Revocation: När du använder verifierbara bevis för att komma åt känsliga resurser är det vanligt att kontrollera statusen för dessa med den ursprungliga utfärdaren och neka åtkomst för återkallade verifierbara bevis. 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.

Notera

Ä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

kontoportalen: 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.

Designöverväganden

VC-attributkorrelation med Microsoft Entra-ID: När du definierar attributen för VC i samarbete med utfärdaren, se till att ni enas om påståenden 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.

Authorization: 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: Service-to-Service-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. Några exempel är:

• 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 inte User.ReadWrite.All, 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 integrerar verifierbara referenser till betrodda parter. Betrodda parter är vanligtvis program.

Autentisering

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

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

Tillstånd

• En lyckad presentation av riskkapital kan betraktas som en övergripande auktoriseringsgräns i sig själv. VC-attributen kan också användas för detaljerade auktoriseringsbeslut.

• Kontrollera om en förfallen VC har betydelse i din applikation; om så är fallet, kontrollera värdet av exp-kravet (förfallotiden) för VC som en del av kontroll av behörighet. 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 ett VC utfärdas innehåller det en ögonblicksbild av attributen vid utfärdandet. Verifierbara intyg kan ha långa giltighetsperioder och du måste fastställa attributens ålder som du accepterar som tillräckligt aktuella 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, spara bara de anspråk som applikationen 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 ogenomskinligt unikt attribut som är konstant för ett specifikt ämne/RP-par.

  • Definiera en mekanism för att ta bort användarprofilen från applikationen. På grund av den decentraliserade karaktären hos Microsoft Entra-verifierat ID-system 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:

• Microsoft Entra Verified ID-utfärdandetjänsten distribueras i Västeuropa, Nordeuropa, Västra USA 2 och Västra Centrala USA Azure-regionerna. Om du vill begränsa svarstiden distribuerar du din verifieringsklientdel (webbplats) och nyckelvalv i den närmaste regionen.

• Modell baserad på genomströmning

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

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

  • Du kan inte kontrollera begränsning; vi rekommenderar dock att du läser Azure Key Vault-begränsningsvägledning 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 Verified ID-tjänst är distribuerad i Azure-regionerna West Europe, North Europe, West US 2, West Central US, 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 Azure Key Vaults tillgänglighet och redundans när du designar med dina tillgänglighets- och redundansmål i åtanke.

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 Verified ID-tjänst och webbplatstjänstens huvudprincipaler 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 for Key Vault.

• Läs Skydda Azure-miljöer med Microsoft Entra-ID för bästa praxis för hantering av supporttjänster för din lösning.

• Minimera förfalskningsrisker genom att:

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

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

• Minska risken för distribuerade överbelastningsattacker (DDOS) och begränsningar av Key Vault-resurser. Varje VC-presentationsbegäran genererar Key Vault-signeringsåtgärder som räknas mot gränserna för tjänsten. 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 heltäckande säkerhetsindikatorer för applikationer.

  • Ö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 Azure Key Vault-övervakning samt aviseringar.

• 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 Så här aktiverar du 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-översikt över verifierade ID:n

• Planera din Microsoft Entra-verifierade ID-utfärdandelösning

Implementera verifierbara autentiseringsuppgifter

• Introduktion till Verifierat ID i Microsoft Entra

• Kom igång med verifierbara autentiseringsuppgifter

vanliga frågor och svar