Sdílet prostřednictvím

Plánování řešení ověřování Ověřené ID Microsoft Entra

  • Článek

Služba Microsoft Ověřené ID Microsoft Entra (Microsoft Entra VC) umožňuje důvěřovat důkazům 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, doporučujeme projít si přehled architektury Ověřené ID Microsoft Entra. Chcete také zkontrolovat řešení pro vystavování Ověřené ID 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. Rozhraní řešení se systémem důvěryhodnosti, kde se aktuálně podporuje WEB DID. DID Web je centralizovaná infrastruktura veřejných klíčů.

Podpora technologií, které nejsou specifické pro řešení ověřování, jsou 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í. Tyto články nejsou v tomto obsahu popsané. Doporučujeme projít si dobře navrženou architekturu Microsoft Azure, kde najdete informace o těchto článcích.

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í.

Diagram součástí ověřovacího řešení

služba Ověřené ID Microsoft Entra

V kontextu ověřovatele řešení představuje služba Ověřené ID Microsoft Entra 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).

Tenant 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á víceklient Ověřené ID Microsoft Entra službu a vydává jeden dokument DID představující ověřovatele. Pokud máte více předávajících stran používajících vaši ověřovací službu, všichni používají stejný ověřovatel DID. Ověřovatel DID poskytuje ukazatele na veřejný klíč, který umožňuje subjektům a vystavitelům ověřovat zprávy, které pocházejí z předávající strany.

Azure Key Vault

Diagram součástí ověřovacího řešení se zvýrazněnou službou Azure Key Vault

Služba Azure Key Vault ukládá vaše ověřitelní klíče, které se generují, když povolíte službu vystavování Ověřené ID Microsoft 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í virtuálních počítačů. Tato sada klíčů se používá při každé službě žádosti o ověření. Sada klíčů Microsoftu aktuálně používá elliptic Curve Cryptography (ECC) SECP256k1. Zkoumáme další schémata kryptografických podpisů, která přijala širší komunita DID.

Rozhraní API služby žádosti

Diagram součástí ověřovacího řešení se zvýrazněným rozhraním API služby požadavku

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

Diagram součástí ověřovacího řešení se zvýrazněným systémem důvěryhodnosti

Ověřené ID Microsoft Entra aktuálně podporuje DID Web jako systém důvěryhodnosti, kde je dokument DID hostovaný na webovém serveru vystavitelů.

Aplikace Microsoft Authenticator

Diagram součástí ověřovacího řešení se zvýrazněnou aplikací Microsoft Authenticator

Microsoft Authenticator je mobilní aplikace. Authenticator orchestruje interakce mezi uživatelem, službou Ověřené ID Microsoft Entra a kontraktem používaným k vydávání virtuálních počítačů. 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ěřovací program je také mechanismus používaný k prezentaci virtuálních počítačů k ověření.

Předávající strana (RP)

Diagram součástí ověřovacího řešení se zvýrazněnými komponentami předávající strany

Webový front-end

Webový front-end předávající strany používá rozhraní API vyžádané služby k ověření virtuálních počítačů generováním přímých odkazů nebo kódů QR, které využívá peněženka subjektu. V závislosti na scénáři může být front-end veřejně přístupný nebo interní web, který umožňuje prostředí koncového uživatele, které vyžadují 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.

Onboarding úč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.

Diagram znázorňující scénář onboardingu účtu

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 onboardingu. 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 onboarduje pomocí rozhraní API k vydávání pozvánek B2B (business-to-business) nebo přiřazení správy nároků k balíčkům.

  • Identity zaměstnanců, které jsou v centralizovaných systémech identit už nasazené prostřednictvím systémů lidských zdrojů. 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í.

Na co dát pozor při navrhování

  • Vystavitel: Onboarding účtu je vhodný pro externí službu kontroly identity jako vystavitel virtuálních počítačů. 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ůch 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 možnost požádat VC o načtení deklarací identity 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 firstName, lastName 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 korelaci žádosti o ověření VC se záznamem pozvánky nebo podkladovými daty a pokračovat v pracovním postupu zřizování. 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 mezi webovým front-endem a cílovými systémy identit musí být zabezpečená 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 některé příklady patří:

    • K vytvoření nového uživatele v Microsoft Entra ID může web RP použít instanční objekt, který má udělen rozsah User.ReadWrite.All MS Graph k vytvoření uživatelů, a rozsah UserAuthenticationMethod.ReadWrite.All pro resetování metody ověřování.

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

    • Pokud je váš poskytovatel prostředků spuštěný v Azure, použijte spravované identity k volání Microsoft Graphu. Použití spravovaných identit odebere rizika správy přihlašovacích údajů instanční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.

Diagram součástí ověřovacího řešení s dalšími prvky

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.

Ostatní 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čů.

Na co dát pozor při navrhování

  • 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. Přihlašovací údaje od vystavitele ověření identity by byly 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í virtuálních počítačů pro přístup k citlivým prostředkům je běžné zkontrolovat stav virtuálního počítače s původním vystavitelem a odepřít přístup pro odvolané virtuální počítače. 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.

    • Podrobné ověřování: 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í. Prezentace VC je vhodná, pokud je povaha celé aplikace vysoká.

Přístup k aplikacím mimo hranice organizace

Ověřitelné přihlašovací údaje můžou používat také předávající strany, které chtějí udělit přístup nebo výhody na základě členství nebo pracovního poměru jiné organizace. 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.

Diagram součástí ověřovacího řešení znázorňující, že přístup probíhá mimo hranici důvěryhodnosti

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.

Ostatní 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čů.

Na co dát pozor při navrhování

  • 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 pracovní poměr nebo vztah k určité organizaci. V takovém případě by měl být poskytovatel prostředků nakonfigurovaný tak, aby přijímal virtuální počítače 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í virtuálních počítačů pro přístup k citlivým prostředkům je běžné zkontrolovat stav virtuálního počítače s původním vystavitelem a odepřít přístup pro odvolané virtuální počítače. 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í: 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í virtuální počítače.

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ář, který popisujeme 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.

Diagram součástí ověřovacího řešení znázorňující scénář obnovení účtu

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 atributu VC s ID Microsoft Entra: 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 onboardingem zaměstnanců, ujistěte se, že vystavený virtuální počítač obsahuje deklarace identity, které se dají spárovat 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é nebyly nalezeny ve VC, například poslední čtyři číslice čísla sociálního pojištění (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 uživatel obnovit virtuální počítač od vystavitele kontroly identity a předložit ho k 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 některé příklady patří:

  • Udělte webu rp možnost používat instanční objekt udělený oboru UserAuthenticationMethod.ReadWrite.All MS Graph k resetování metod ověřování. Neudělujte User.ReadWrite.All, což umožňuje vytvářet a odstraňovat uživatele.

  • Pokud je váš poskytovatel prostředků spuštěný v Azure, použijte spravované identity k volání Microsoft Graphu. Spravované identity odeberou rizika související se správou přihlašovacích údajů instančního objektu 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.

Ověřování

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

  • Člověk má VC v peněžence a musí interaktivně prezentovat VC. 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ě odstupňovanou autorizační bránu. Atributy VC je také možné využívat k jemně odstupňovaným rozhodnutím o autorizaci.

  • Zjistěte, jestli platnost VC s vypršenou platností má ve vaší aplikaci význam; pokud ano, zkontrolujte hodnotu exp deklarace identity (čas vypršení platnosti) virtuálního počítače jako součást kontrol autorizace. 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 deklarace identity 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 rámci vystavení. Virtuální počítače můžou mít dlouhou dobu platnosti a musíte určit věk atributů, které budete přijímat jako dostatečně čerstvé, abyste je mohli použít jako součást profilu.

  • Pokud je potřeba předložit virtuální počítač pokaždé, když předmět zahájí relaci s rp, zvažte použití výstupu prezentace VC k vytvoření profilu uživatele, který není trvalý s 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 deklarace identity, 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ůhlený jedinečný atribut, který je konstantní pro danou dvojici předmětu nebo rp.

    • Definujte mechanismus pro zrušení zřízení profilu uživatele z aplikace. Vzhledem k decentralizované povaze systému Ověřené ID Microsoft Entra neexistuje žádný životní cyklus zřizování uživatelů aplikace.

    • Neukládejte deklarace identity osobních údajů vrácené v tokenu VC.

    • Ukládejte pouze deklarace identity potřebné pro logiku předávající strany.

Plánování výkonu

Stejně jako u jakéhokoli řešení musíte naplánovat výkon. 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é ID Microsoft Entra se nasadí v oblastech Azure Usa – západ, Severní Evropa, USA – západ 2 a USA – středozápad. 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í; Doporučujeme ale přečíst si pokyny k omezování služby Azure Key Vault, abyste pochopili, 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, doporučujeme následující položky:

  • služba Ověřené ID Microsoft Entra se nasazuje 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í cílů dostupnosti a redundance ve službě Azure Key Vault si projděte a začleňte osvědčené postupy.

Plánování zabezpečení

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

  • Všechny předávající strany (RPS) v jednom tenantovi mají stejnou hranici důvěryhodnosti, protože sdílejí stejnou sadu DID.

  • Definujte vyhrazený instanční objekt pro web, který přistupuje ke službě Key Vault.

  • K podepisování zpráv pomocí privátního klíče by měla mít oprávnění pouze služba Ověřené ID Microsoft Entra a instanční objekty webu.

  • 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á zákazníkům pomůže identifikovat branding vystavitele

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

  • Zmírnění rizik omezování prostředků služby Key Vault s distribuovaným odepřením služeb (DDOS) a omezováním 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 vystavení doporučujeme chránit provoz zahrnutím alternativního ověřování nebo captcha.

Plánování provozu

Při plánování operací doporučujeme v rámci auditování zaznamenat každý pokus o ověření přihlašovacích údajů. 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.

    • Archivace protokolů v systémech zabezpečení a správy událostí (SIEM), jako je Microsoft Sentinel pro dlouhodobé uchovávání.

Další kroky

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

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

Nejčastější dotazy