Plánujte řešení ověřování ID od Microsoft Entra

Přehled

Služba Microsoft Entra Verified ID (Microsoft Entra VC) společnosti Microsoft umožňuje důvěřovat ověření identity uživatele bez rozšíření hranice důvěryhodnosti. S Microsoft Entra VC vytvoříte účty nebo federaci s jiným zprostředkovatelem identity. Když řešení implementuje ověřovací výměnu pomocí ověřitelných přihlašovacích údajů, umožní aplikacím požadovat přihlašovací údaje, které nejsou svázané s konkrétní doménou. Tento přístup usnadňuje vyžádání a ověření přihlašovacích údajů ve velkém měřítku.

Pokud jste to ještě neudělali, projděte si přehled architektury Microsoft Entra Verified ID. Zkontrolujte také plánování řešení vystavování ověřených ID pomocí Microsoft Entra.

Rozsah pokynů

Tento obsah se zabývá technickými aspekty plánování ověřitelného řešení ověřování přihlašovacích údajů pomocí produktů a služeb Microsoftu. Řešení se propojuje s systémem důvěryhodnosti, kde se aktuálně podporuje DID Web. DID Web je centralizovaná infrastruktura veřejných klíčů.

Podpora technologií, které nejsou specifické pro řešení ověřování, je mimo rozsah. Weby se například používají v ověřitelném řešení pro ověření přihlašovacích údajů, ale plánování nasazení webu se podrobně nezabývá.

Při plánování řešení ověřování musíte zvážit, jaké obchodní možnosti se přidávají nebo upravují. Musíte také zvážit, jaké možnosti IT je možné znovu použít a jaké možnosti je potřeba přidat k vytvoření řešení. Zvažte také, jaké školení je potřeba pro lidi zapojené do obchodního procesu a lidi, kteří podporují koncové uživatele a zaměstnance řešení. Tato témata nejsou v tomto obsahu popsána. Další informace najdete v rozhraní Microsoft Azure Well-Architected Framework.

Součásti řešení

Jako součást plánu pro ověřovací řešení musíte povolit interakce mezi ověřovatelem, subjektem a vystavitelem. V tomto článku se výrazy předávající strany a ověřovatele používají zaměnitelně. Následující diagram znázorňuje komponenty architektury ověřování.

služba Ověřené ID Microsoft Entra

V kontextu ověřitelného řešení představuje služba Microsoft Entra Verified ID rozhraní mezi komponentami řešení Microsoftu a systémem důvěryhodnosti. Služba zřídí klíč nastavený na Key Vault, zřídí decentralizovaný identifikátor (DID).

Klient Microsoft Entra

Služba vyžaduje tenanta Microsoft Entra, který poskytuje řídicí rovinu správy identit a přístupu (IAM) pro prostředky Azure, které jsou součástí řešení. Každý tenant Microsoft Entra používá multitenantní službu Microsoft Entra Verified ID a vydává jediný dokument DID, který představuje ověřovatele. Pokud máte více stran spoléhajících na vaši ověřovací službu, všechny využívají stejný DID ověřovatele. Ověřovatel DID poskytuje ukazatele na veřejný klíč, který umožňuje subjektům a vystavitelům ověřovat zprávy pocházející od spoléhající strany.

Azure Key Vault

Služba Azure Key Vault ukládá vaše ověřitelní klíče, které se vygenerují, když povolíte službu vystavování ověřených ID microsoftu Entra. Klíče slouží k zajištění zabezpečení zpráv. Každý ověřovatel má jednu sadu klíčů, která se používá k podepisování, aktualizaci a obnovování ověřitelných přihlašovacích údajů. Ověřené ID používá tuto sadu klíčů při každém vyřízení žádosti o ověření. Sada klíčů Microsoftu aktuálně používá elliptic Curve Cryptography (ECC) SECP256k1. Vyhodnocují se také další schémata kryptografických podpisů přijímaná širší komunitou DID.

API pro požadavek služby

Aplikační programovací rozhraní (API) poskytují vývojářům metodu pro abstrakci interakcí mezi komponentami řešení pro provádění ověřovacích operací.

Systém důvěryhodnosti

Ověřené ID Microsoft Entra v současné době podporuje DID Web jako systém důvěry, kde je dokument DID hostovaný na webovém serveru vystavitele.

Aplikace Microsoft Authenticator

Microsoft Authenticator je mobilní aplikace. Authenticator orchestruje interakce mezi uživatelem, službou Microsoft Entra VC a kontraktem používaným k vydávání ověřitelných přihlašovacích údajů. Funguje jako digitální peněženka, ve které držitel VC ukládá VC, včetně soukromého klíče předmětu VC. Ověřovatel je také mechanismus používaný k prezentaci ověřovacích údajů k ověření.

Důvěřující strana (RP)

Webový front-end

Webový front-end strany, která spoléhá, používá Request Service API k ověření ověřitelných přihlašovacích údajů generováním deep linků nebo QR kódů, které zpracovává peněženka subjektu. V závislosti na scénáři může být uživatelské rozhraní veřejně přístupné nebo interní webové stránky, které umožňují prostředí koncového uživatele, jež vyžaduje ověření. Koncové body, ke kterým má peněženka přístup, ale musí být veřejně přístupné. Konkrétně řídí přesměrování na peněženku s konkrétními parametry požadavku.

Obchodní logika

Můžete vytvořit novou logiku nebo použít existující logiku specifickou pro předávající stranu a tuto logiku vylepšit prezentací virtuálních počítačů.

Návrhy specifické pro scénáře

Následují příklady návrhů, které vyhovují konkrétním případům použití. Prvním je onboarding účtu, který se používá ke snížení času, nákladů a rizik spojených s onboardingem nových zaměstnanců. Druhou možností je obnovení účtu, které koncovému uživateli umožňuje obnovit nebo odemknout svůj účet pomocí samoobslužného mechanismu. Třetí možností je přístup k vysoce hodnotovým aplikacím a prostředkům, konkrétně pro případy použití typu business-to-business, kdy je přístup udělen lidem, kteří pracují pro jiné společnosti.

Zavádění účtu

Ověřitelné přihlašovací údaje je možné použít k rychlejšímu onboardingu nahrazením některých lidských interakcí. Virtuální počítače se dají použít k onboardingu zaměstnanců, studentů, občanů nebo jiných uživatelů pro přístup ke službám. Například místo toho, aby zaměstnanec potřeboval přejít do centrální kanceláře, aby si aktivoval odznáček zaměstnance, může pomocí VC ověřit svou identitu a aktivovat odznáček, který se jim doručí vzdáleně. Místo toho, aby občan obdržel kód, který musí uplatnit pro přístup k vládním službám, může pomocí VC prokázat svou identitu a získat přístup.

Další prvky

Portál onboardingu: Webový front-end, který orchestruje volání rozhraní API služby požadavků pro prezentaci a ověřování VC a logiku pro onboarding účtů.

Vlastní logika nebo pracovní postupy: Konkrétní logika s kroky specifickými pro organizaci před a po aktualizaci uživatelského účtu. Mezi příklady patří pracovní postupy schválení, další ověření, protokolování, oznámení atd.

Cílové systémy identit: Úložiště identit specifická pro organizaci, se kterými musí portál onboardingu pracovat při začleňování subjektů. Systémy, které se mají integrovat, se určují na základě typů identit, které chcete připojit k ověřování VC. Mezi běžné scénáře ověřování identit pro onboarding patří:

• Externí identity, které Microsoft Entra ID integruje pomocí rozhraní API pro vydávání B2B (business-to-business) pozvánek nebo pro přiřazení správy nároků k určitým balíčkům.

• Identita zaměstnanců, které jsou v centralizovaných systémech identit již integrovány prostřednictvím systémů personálního oddělení. V tomto případě může být ověření identity integrováno jako součást stávajících fází pracovních postupů personálního oddělení.

Aspekty návrhu

• Vystavitel: Onboarding účtu je vhodný pro externí službu ověřování identity jakožto vystavitel ověřitelných pověření. Mezi příklady kontrol onboardingu patří: kontrola aktivity, ověření dokladu vydané vládou, adresa nebo potvrzení telefonního čísla atd.

• Ukládání atributů VC: Pokud je to možné, neukládejte atributy z VC ve specifickém úložišti aplikace. Buďte obzvláště opatrní s osobními údaji. Pokud konkrétní toky v rámci vašich aplikací vyžadují tyto informace, zvažte požádat VC o načtení nároků na vyžádání.

• Korelace atributů VC s back-endovými systémy: Při definování atributů VC s vystavitelem vytvořte mechanismus pro korelaci informací v back-endovém systému poté, co uživatel zobrazí VC. Mechanismus obvykle používá časově vázané jedinečné identifikátory v kontextu vašeho poskytovatele prostředků v kombinaci s deklaracemi, které obdržíte. Některé příklady:

  • Nový zaměstnanec: Když pracovní postup personálního oddělení dosáhne bodu, kde je vyžadováno ověření identity, může rp vygenerovat odkaz s jedinečným identifikátorem vázaném na čas. Poskytovatel prostředků ji pak pošle na e-mailovou adresu kandidáta v systému lidských zdrojů. Tento jedinečný identifikátor by měl stačit ke korelaci informací, jako je křestní jméno a příjmení z žádosti o ověření VC na záznam HR nebo podkladová data. Atributy v jazyce VC lze použít k dokončení atributů uživatele v systému personálního oddělení nebo k ověření přesnosti atributů uživatele o zaměstnanci.

  • Externí identity – pozvánka: Když je externí uživatel pozván do cílového systému, může rp vygenerovat odkaz s jedinečným identifikátorem, který představuje transakci pozvánky. Tento odkaz lze odeslat na e-mailovou adresu externího uživatele. Tento jedinečný identifikátor by měl stačit ke spojení žádosti o ověření VC se záznamem pozvánky nebo podkladovými daty a v postupu zřizování pokračovat. Atributy ve VC lze použít k ověření nebo dokončení atributů externího uživatele.

  • Externí identity – samoobslužné: Když se externí identity zaregistrují do cílového systému prostřednictvím samoobslužné služby (například aplikace B2C), dají se atributy ve VC použít k naplnění počátečních atributů uživatelského účtu. Atributy VC je také možné použít ke zjištění, jestli profil již existuje.

• Interakce s cílovými systémy identit: Komunikace služeb webového front-endu s cílovými systémy identit musí být zabezpečena jako vysoce privilegovaný systém, protože může vytvářet účty. Udělte webovému front-endu co nejmenší možné privilegované role. Mezi příklady patří:

  • K vytvoření nového uživatele v Microsoft Entra ID může web RP použít služební principál, kterému byl udělen rozsah User.ReadWrite.All MS Graph pro vytváření uživatelů a rozsah UserAuthenticationMethod.ReadWrite.All pro resetování jejich metody ověřování.

  • Pokud chcete pozvat uživatele do Microsoft Entra ID pomocí spolupráce B2B, může web RP použít objekt služby, kterému je udělen rozsah MS Graph User.Invite.All k vytváření pozvánek.

  • Pokud je váš RP spuštěný v Azure, použijte Spravované identity k volání Microsoft Graph. Použití spravovaných identit eliminuje rizika spojená se správou přihlašovacích údajů služebního objektu v kódu nebo konfiguračních souborech. Další informace o spravovaných identitách najdete v tématu Spravované identity pro prostředky Azure.

Přístup k vysoce hodnotovým aplikacím v organizacích

Ověřitelné přihlašovací údaje je možné použít jako další důkaz pro přístup k citlivým aplikacím v organizaci. Například virtuální počítače lze použít také k poskytování přístupu zaměstnanců k podnikovým aplikacím na základě splnění konkrétních kritérií, jako je certifikace.

Další prvky

Webový frontend spoléhající se strany je webový frontend aplikace, který je vylepšený pomocí volání rozhraní API služby požadavků pro prezentaci a ověřování VC na základě vašich obchodních požadavků.

Autorizační logika přístupu uživatele je aplikační vrstva logiky, která autorizuje přístup uživatelů. Je vylepšena tak, aby při rozhodování o autorizaci spotřebovala atributy uživatelů ve VC.

Další back-endové služby a závislosti: Představuje zbytek logiky aplikace, která se obvykle nemění zahrnutím kontroly identity prostřednictvím virtuálních počítačů.

Aspekty návrhu

• Cíl: Cíl scénáře určuje, jaký druh přihlašovacích údajů a vystavitele je potřeba. Mezi obvyklé scénáře patří:

  • Autorizace: V tomto scénáři uživatel předloží VC k rozhodnutí o autorizaci. Pro tento scénář jsou vhodné virtuální počítače navržené pro doklad o dokončení školení nebo s konkrétní certifikací. Atributy VC by měly obsahovat jemně odstupňované informace, které jsou příznivé pro rozhodnutí o autorizaci a auditování. Například virtuální počítač slouží k certifikaci jednotlivce, který je vytrénovaný a má přístup k citlivým finančním aplikacím. Logika aplikace může zkontrolovat žádost oddělení o jemně odstupňovanou autorizaci a použít ID zaměstnance pro účely auditu.

  • Potvrzení ověření identity: V tomto scénáři je cílem potvrdit, že stejná osoba, která byla původně nasazena, je skutečně ta, která se pokouší o přístup k aplikaci s vysokou hodnotou. Doklad od poskytovatele ověřování identity by byl vhodný. Logika aplikace by měla ověřit, že atributy z VC odpovídají uživateli, který se přihlásil k aplikaci.

• Kontrola odvolání: Při použití věrohodných certifikátů pro přístup k citlivým prostředkům je běžné zkontrolovat stav certifikátu s původním vystavitelem a odepřít přístup pro odvolané certifikáty. Při práci s vystaviteli se ujistěte, že je odvolání výslovně popsáno jako součást návrhu vašeho scénáře.

• Uživatelské prostředí: Při používání virtuálních počítačů pro přístup k citlivým prostředkům můžete zvážit dva vzory.

  • Vyšší úroveň ověření: Uživatelé spustí relaci s aplikací s existujícími mechanismy ověřování. Uživatelé musí předložit VC pro konkrétní vysoce hodnotné operace v rámci aplikace, jako jsou schválení obchodních pracovních postupů. To je vhodné pro scénáře, ve kterých jsou takové vysoce hodnotné operace snadno identifikovat a aktualizovat v rámci toků aplikací.

  • Zřízení relace: Uživatelé musí předložit VC jako součást zahájení relace s aplikací. Představení VC je vhodným řešením, pokud je povaha celé aplikace vysoké hodnoty.

Přístup k aplikacím mimo hranice organizace

Ověřitelné přihlašovací údaje můžou používat také důvěřující strany, které chtějí udělit přístup nebo výhody na základě členství nebo pracovního poměru v jiné organizaci. Portál elektronického obchodování může například nabízet výhody, jako jsou slevy zaměstnancům konkrétní společnosti, studentům dané instituce atd.

Decentralizovaná povaha ověřitelných přihlašovacích údajů umožňuje tento scénář bez navázání vztahů federace.

Další prvky

Webový front-end předávající strany: Jedná se o webový front-end aplikace, který se vylepšuje prostřednictvím volání rozhraní API služby požadavků na prezentaci a ověřování VC na základě vašich obchodních požadavků.

Logika autorizace přístupu uživatele: Vrstva logiky v aplikaci, která autorizuje přístup uživatelů a je vylepšena tak, aby spotřebovával atributy uživatele v rámci VC k rozhodování o autorizaci.

Další back-endové služby a závislosti: Představuje zbytek logiky aplikace, která se obvykle nemění zahrnutím kontroly identity prostřednictvím virtuálních počítačů.

Aspekty návrhu

• Cíl: Cíl scénáře určuje, jaký druh přihlašovacích údajů a vystavitele je potřeba. Mezi obvyklé scénáře patří:

  • Ověřování: V tomto scénáři musí mít uživatel vlastnictví VC, aby prokázal zaměstnání nebo svůj vztah k určitým organizacím. V takovém případě by měla být strana spoléhající se nakonfigurována tak, aby přijímala ověřitelné údaje vydané cílovými organizacemi.

  • Autorizace: Na základě požadavků aplikace můžou aplikace využívat atributy VC pro jemně odstupňovaná rozhodnutí o autorizaci a auditování. Pokud například web elektronického obchodování nabízí slevy zaměstnancům organizací v určitém umístění, můžou ověřit nárok na slevy na základě žádosti o zemi nebo oblast ve VC (pokud je k dispozici).

• Kontrola odvolání: Při použití věrohodných certifikátů pro přístup k citlivým prostředkům je běžné zkontrolovat stav certifikátu s původním vystavitelem a odepřít přístup pro odvolané certifikáty. Při práci s vystaviteli se ujistěte, že je odvolání výslovně popsáno jako součást návrhu vašeho scénáře.

• Uživatelský zážitek: Uživatelé mohou prezentovat VC jako součást zahájení relace s aplikací. Aplikace obvykle také poskytují alternativní metodu spuštění relace, aby vyhovovaly případům, kdy uživatelé nemají VC.

Obnovení účtu

Ověřitelné přihlašovací údaje je možné použít jako přístup k obnovení účtu. Když například uživatel potřebuje obnovit svůj účet, může získat přístup k webu, který vyžaduje, aby představil VC a zahájil resetování přihlašovacích údajů Microsoft Entra voláním rozhraní MS Graph API, jak je znázorněno v následujícím diagramu.

Poznámka:

Scénář popsaný v této části je specifický pro obnovení účtů Microsoft Entra, tento přístup lze použít také k obnovení účtů v jiných systémech.

Další prvky

Portál účtů: Webový front-end, který orchestruje volání rozhraní API pro prezentaci a ověřování VC. Tato orchestrace může zahrnovat volání Microsoft Graphu pro obnovení účtů v Microsoft Entra ID.

Vlastní logika nebo pracovní postupy: Logika s kroky specifickými pro organizaci před a po aktualizaci uživatelského účtu. Vlastní logika může zahrnovat pracovní postupy schválení, další ověření, protokolování, oznámení atd.

Microsoft Graph: Zveřejňuje rozhraní REST (Representational State Transfer) API a klientské knihovny pro přístup k datům Microsoft Entra, která se používají k obnovení účtu.

Podnikový adresář Microsoft Entra: Tenant Microsoft Entra, který obsahuje účty, které se vytvářejí nebo aktualizují prostřednictvím portálu účtů.

Aspekty návrhu

Korelace atributů VC s Microsoft Entra ID: Při definování atributů VC ve spolupráci s vystavitelem se ujistěte, že souhlasíte s deklaracemi identity, které identifikují uživatele. Pokud například zprostředkovatel ověření identity (IDV) ověřuje identitu před nástupem zaměstnanců, ujistěte se, že vydaný ověřovací věrohodný údaj (VC) obsahuje tvrzení, která lze porovnat s interními systémy. Takové deklarace identity můžou být telefonní číslo, adresa nebo datum narození. RP může v rámci tohoto procesu požádat o informace, které nejsou uvedeny ve VC, například poslední čtyři číslice čísla sociálního zabezpečení (SSN).

Role virtuálních počítačů se stávajícími možnostmi resetování přihlašovacích údajů Microsoft Entra: ID Microsoft Entra má integrovanou funkci samoobslužného resetování hesla (SSPR). Ověřitelné přihlašovací údaje je možné použít k zajištění dalšího způsobu obnovení v případech, kdy uživatelé nemají přístup k metodě SSPR nebo o ně ztratí kontrolu. Ve scénářích, kdy uživatel ztratil počítač i mobilní zařízení, může získat zpět VC od vystavitele průkazu totožnosti a předložit ho ke vzdálenému obnovení účtu.

Podobně můžete použít VC k vygenerování dočasného přístupového passu, který uživatelům umožňuje resetovat metody ověřování vícefaktorového ověřování bez hesla.

Autorizace: Vytvořte mechanismus autorizace, například skupinu zabezpečení, kterou poskytovatel prostředků zkontroluje před pokračováním v obnovení přihlašovacích údajů. K obnovení účtu pomocí VC můžou mít například nárok jenom uživatelé v konkrétních skupinách.

Interakce s ID Microsoft Entra: Komunikace mezi webovým front-endem a ID Microsoft Entra musí být zabezpečena jako vysoce privilegovaný systém, protože může resetovat přihlašovací údaje zaměstnanců. Udělte webovému front-endu co nejmenší možné privilegované role. Mezi příklady patří:

• Udělete webu RP možnost používat služební objekt, kterému je udělen obor MS Graph UserAuthenticationMethod.ReadWrite.All, pro resetování metod ověřování. Neudělujte User.ReadWrite.All, což umožňuje vytvářet a odstraňovat uživatele.

• Pokud je váš RP spuštěný v Azure, použijte Spravované identity k volání Microsoft Graph. Spravované identity odstraňují rizika související se správou přihlašovacích údajů služební identity v kódu nebo konfiguračních souborech. Další informace najdete v tématu Spravované identity pro prostředky Azure.

Plánování správy identit

Při začlenění virtuálních počítačů do předávajících stran je potřeba vzít v úvahu následující aspekty IAM. Předávající strany jsou obvykle aplikace.

Autentizace

• Předmět VC musí být člověk.

• Člověk má VC v peněžence a musí ji interaktivně prezentovat. Neinteraktivní toky, jako je on-behalf-of, nejsou podporované.

Autorizace

• Úspěšná prezentace VC může být sama o sobě považována za hrubě definovanou autorizační bránu. Atributy VC je také možné využívat k jemně odstupňovaným rozhodnutím o autorizaci.

• Zjistěte, jestli má vypršela platnost VC ve vaší aplikaci význam; pokud ano, zkontrolujte hodnotu exp nároku (čas vypršení platnosti) VC jako součást autoritativních kontrol. Jedním z příkladů, kdy vypršení platnosti není relevantní, je vyžadování dokladu vydaného vládou, například licence řidiče k ověření, jestli je předmět starší než 18. Datum narození je platné, i když platnost VC vypršela.

• Určete, jestli odvolání VC má význam pro vaše rozhodnutí o autorizaci.

  • Pokud to není relevantní, přeskočte volání pro kontrolu stavového rozhraní API (které je ve výchozím nastavení zapnuté).

  • Pokud je relevantní, přidejte do aplikace správné zpracování výjimek.

Profily uživatelů

K vytvoření profilu uživatele můžete použít informace v zobrazených virtuálních počítačích. Pokud chcete k vytvoření profilu využívat atributy, zvažte následující položky.

• Když se VC vydá, obsahuje snímek atributů v době vydání. Ověřitelné údaje můžou mít dlouhou dobu platnosti a musíte určit věk atributů, které budete přijímat jako dostatečně aktuální k použití jako součást profilu.

• Pokud je potřeba předložit ověřitelný certifikát pokaždé, když subjekt zahájí relaci s RP, zvažte použití výstupu z prezentace VC k vytvoření dočasného uživatelského profilu s uvedenými atributy. Profil uživatele, který není trvalý, pomáhá snížit rizika ochrany osobních údajů spojená s ukládáním neaktivních uložených vlastností uživatele. Vaše aplikace může potřebovat uložit atributy předmětu místně. Pokud ano, uložte pouze nároky, které vaše aplikace potřebuje. Neuložte celý VC.

• Pokud aplikace vyžaduje trvalé úložiště profilů uživatelů:

  • Zvažte použití sub deklarace identity jako neměnného identifikátoru uživatele. Jedná se o neprůhledný jedinečný atribut, který je konstantní pro danou dvojici předmětu/RP.

  • Definujte mechanismus pro odebrání uživatelského profilu v aplikaci. Vzhledem k decentralizované povaze systému Microsoft Entra Verified ID neexistuje žádný životní cyklus zřizování uživatelů aplikace.

  • Neukládejte osobní údaje o nárocích vrácených v tokenu VC.

  • Ukládejte pouze tvrzení potřebná pro logiku spoléhající se strany.

Plánování výkonu

Stejně jako u jakéhokoli řešení musíte plánovat zajištění výkonnosti. Mezi oblasti zaměření patří latence, propustnost a škálovatelnost. Během počátečních fází cyklu vydávání verzí by výkon neměl být problém. Pokud ale přijetí vašeho řešení vede k ověření mnoha ověřitelných přihlašovacích údajů, může se plánování výkonu stát důležitou součástí vašeho řešení.

Následující položky poskytují oblasti, které je potřeba vzít v úvahu při plánování výkonu:

• Služba vystavování ověřených ID Microsoft Entra je nasazena v oblastech Azure Západní Evropa, Severní Evropa, Západ USA 2 a Západ Střední USA. Pokud chcete omezit latenci, nasaďte ověřovací front-end (web) a trezor klíčů v nejbližší oblasti.

• Model založený na propustnosti:

  • Kapacita ověřování VC podléhá omezením služby Azure Key Vault.

  • Každé ověření virtuálního počítače vyžaduje jednu operaci podpisu služby Key Vault.

  • Nemůžete řídit omezování; Projděte si ale pokyny k omezování služby Azure Key Vault a zjistěte, jak může omezování ovlivnit výkon.

Plánování spolehlivosti

Pokud chcete co nejlépe naplánovat vysokou dostupnost a zotavení po havárii, zvažte následující položky:

• Služba Microsoft Entra Verified ID je nasazená v oblastech Azure v oblasti Západní Evropa, Severní Evropa, USA – západ 2 a USA – středozápad, Austrálie a Japonsko. Zvažte nasazení podpůrných webových serverů a podpůrných aplikací v jedné z těchto oblastí, konkrétně v těch, ze kterých očekáváte, že většina ověřovacího provozu pochází.

• Při navrhování s ohledem na cíle dostupnosti a redundance si projděte a začleňte osvědčené postupy ze sekce dostupnost a redundance ve službě Azure Key Vault.

Plánování zabezpečení

Při navrhování zabezpečení zvažte následující:

• Všechny spoléhající strany (RP) v jednom tenantovi mají stejnou hranici důvěry, protože sdílejí stejné DID.

• Definujte vyhrazenou služební identitu pro web, který přistupuje k trezoru klíčů.

• Pouze služba Microsoft Entra Verified ID a hlavní objekty služby webových stránek by měly mít oprávnění použít Key Vault k podepisování zpráv pomocí privátního klíče.

• Nepřiřazujte ke službě Key Vault žádná oprávnění správce lidských identit. Další informace o osvědčených postupech služby Key Vault najdete v tématu Standardní hodnoty zabezpečení pro Službu Key Vault.

• Projděte si zabezpečení prostředí Azure pomocí Microsoft Entra ID , kde najdete osvědčené postupy pro správu podpůrných služeb pro vaše řešení.

• Zmírnění rizik falšování identity:

  • Implementace ověření DNS, které pomůže zákazníkům identifikovat značku vystavitele.

  • Používejte domény, které mají smysl pro koncové uživatele.

• Zmírněte rizika distribuovaného odepření služeb (DDOS) a omezování prostředků služby Key Vault. Každá žádost o prezentaci VC generuje operace podepisování služby Key Vault, které nabíhají směrem k limitům služeb. Před generováním požadavků na vystavování můžete chránit provoz zahrnutím alternativního ověřování nebo captcha.

Plánování provozu

Při plánování operací zachyťte každý pokus o ověření přihlašovacích údajů jako součást auditování. Tyto informace použijte k auditování a řešení potíží. Kromě toho zvažte generování jedinečných identifikátorů transakcí (ID), na které můžou zákazníci a technici podpory odkazovat v případě potřeby.

V rámci plánování provozu zvažte monitorování následujících možností:

• Škálovatelnost:

  • Monitorování neúspěšného ověření VC v rámci komplexních metrik zabezpečení aplikací

  • Monitorujte kompletní latenci ověřování přihlašovacích údajů.

• Spolehlivost a závislosti:

  • Monitorujte základní závislosti používané ověřovacím řešením.

  • Postupujte podle monitorování a upozorňování ve službě Azure Key Vault.

• Zabezpečení:

  • Povolte protokolování pro Službu Key Vault, abyste mohli sledovat operace podepisování a monitorovat změny konfigurace a upozorňovat na je. Další informace najdete v tématu Povolení protokolování služby Key Vault .

  • Archivujte protokoly v systémech pro správu informací a událostí o zabezpečení (SIEM), například Microsoft Sentinel, pro dlouhodobé uchovávání.

Další kroky

Další informace o navrhování řešení VC

• Přehled ověřeného ID Microsoft Entra

• Plánujte řešení pro vydávání ověřených ID od Microsoftu

Implementace ověřitelných přihlašovacích údajů

• Úvod do ověřeného ID Microsoft Entra

• Začínáme s ověřitelnými přihlašovacími údaji

Nejčastější dotazy