Sdílet prostřednictvím


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

Je důležité naplánovat řešení vystavování tak, aby kromě vydávání přihlašovacích údajů měli kompletní přehled o architektonickém a obchodním dopadu vašeho řešení. Pokud jste tak ještě neučinili, doporučujeme shlédnout přehled architektury ověřeného ID Microsoft Entra pro základní informace.

Rozsah pokynů

Tento článek popisuje technické aspekty plánování ověřitelného řešení vystavování přihlašovacích údajů (VC). Řešení Microsoftu pro ověřitelné přihlašovací údaje se řídí standardem W3C (World Wide Web Consortium) ověřitelným datovým modelem přihlašovacích údajů 1.0 a decentralizovanými identifikátory (DID) V1.0, aby bylo možné spolupracovat s ne služby Microsoft. Příklady v tomto obsahu však odrážejí zásobník řešení Microsoftu pro ověřitelné přihlašovací údaje.

Mimo rozsah tohoto obsahu jsou články, které pokrývají podpůrné technologie, které nejsou specifické pro řešení vystavování. Weby se například používají v ověřitelném řešení vystavování přihlašovacích údajů, ale plánování nasazení webu se podrobně nezabývá.

Součásti řešení

V rámci plánu řešení pro vystavování musíte navrhnout řešení, které umožňuje interakce mezi vystavitelem, uživatelem a ověřovatelem. Následující diagram znázorňuje komponenty vaší architektury vystavování.

Architektura řešení vystavování Microsoft VC

Diagram znázorňující různé komponenty řešení vystavování

Tenant Microsoft Entra

K hostování ověřeného ID Microsoft Entra potřebujete přístup k tenantovi Microsoft Entra. Tenant Microsoft Entra poskytuje řídicí rovinu správy identit a přístupu (IAM) pro prostředky, které jsou součástí řešení.

Každý tenant používá víceklient Ověřené ID Microsoft Entra službu a má decentralizovaný identifikátor (DID). The DID poskytuje důkaz, že vystavitel vlastní doménu začleněnou do DID. Did se používá subjektem a ověřovatelem k ověření vystavitele.

Služby Microsoft Azure

Diagram znázorňující komponenty řešení vystavování se zaměřením na služby Azure

Služba Azure Key Vault ukládá klíče vystavitele, které se generují při zahájení služby vystavování Ověřené ID Microsoft Entra. Klíče a metadata slouží ke spouštění operací správy přihlašovacích údajů a k zajištění zabezpečení zpráv.

Každý vystavitel má jednu sadu klíčů, která se používá k podepisování, aktualizaci a obnovení. Tato sada klíčů se používá pro každé vystavení všech ověřitelných přihlašovacích údajů, které vytvoříte.

služba Ověřené ID Microsoft Entra slouží k ukládání metadat a definic přihlašovacích údajů, konkrétně pravidel a zobrazení definic vašich přihlašovacích údajů.

  • Definice zobrazení určují, jak se deklarace identity zobrazují v peněžence držitele a zahrnují také branding a další prvky. Definici zobrazení lze lokalizovat do více jazyků. Přečtěte si , jak přizpůsobit ověřitelné přihlašovací údaje.

  • Pravidla jsou model definovaný vystavitelem, který popisuje požadované vstupy ověřitelných přihlašovacích údajů. Pravidla také definovala důvěryhodné vstupní zdroje a mapování vstupních deklarací na výstupní deklarace identity uložené ve VC. V závislosti na typu ověření identity definovaném v definici pravidel můžou vstupní deklarace identity pocházet od různých poskytovatelů. Vstupní deklarace identity můžou pocházet od zprostředkovatele identity OIDC, z id_token_hint nebo z deklarací identity, které se v průběhu vystavování uplatňují prostřednictvím uživatelského vstupu do peněženky.

    • Input – Jedná se o podmnožinu modelu v souboru pravidel pro spotřebu klientů. Podmnožina musí popsat sadu vstupů, kde získat vstupy a koncový bod pro volání za účelem získání ověřitelných přihlašovacích údajů.

služba Ověřené ID Microsoft Entra

Diagram služby Ověřené ID Microsoft Entra

Služba Ověřené ID Microsoft Entra umožňuje vydávat a odvolávat virtuální počítače na základě vaší konfigurace. Služba:

  • Zřídí decentralizovaný identifikátor (DID). Každý vystavitel má jeden DID na tenanta.

  • Zřídí sady klíčů ve službě Key Vault.

  • Ukládá metadata konfigurace používaná službou vystavování a aplikací Microsoft Authenticator.

  • Poskytuje rozhraní REST API pro vystavitele a ověřovatele webových front-endů.

Systém důvěryhodnosti

Snímek obrazovky se zvýrazněním systému důvěryhodnosti v architektuře

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

Aplikace Microsoft Authenticator

Diagram znázorňující Microsoft Authenticator jako peněženku ověřitelného řešení přihlašovacích údajů

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

Obchodní logika vystavování

Diagram znázorňující obchodní logiku vystavování ověřených ID

Vaše řešení vystavování zahrnuje webový front-end, kde uživatelé požadují VC, úložiště identit a jiné úložiště atributů k získání hodnot pro deklarace identity o předmětu a dalších back-endových službách.

Webový front-end obsluhuje požadavky na vystavení peněženky subjektu generováním přímých odkazů nebo kódů QR. Na základě konfigurace kontraktu můžou být k splnění požadavků na vytvoření VC vyžadovány další komponenty.

Tyto služby poskytují podpůrné role, které nemusí nutně integrovat se službou vystavování Ověřené ID Microsoft Entra. Tato vrstva obvykle zahrnuje:

  • Služba nebo služby kompatibilní se standardem OpenID Connect (OIDC) se používají k získání id_tokens potřebné k vydání VC. Stávající systémy identit, jako je Microsoft Entra ID nebo Azure AD B2C, můžou poskytovat službu kompatibilní se standardem OIDC, jako jsou vlastní řešení, jako je například Server identit.

  • Úložiště atributů – Úložiště atributů můžou být mimo adresářové služby a poskytují atributy potřebné k vydání VC. Například informační systém studentů může poskytovat nároky na získané stupně.

  • Další služby střední vrstvy, které obsahují obchodní pravidla pro vyhledávání, ověřování, fakturaci a všechny další kontroly za běhu a pracovní postupy potřebné k vydávání přihlašovacích údajů.

Další informace o nastavení webového front-endu najdete v kurzu Konfigurace VAŠEHO ID Microsoft Entra k vydání ověřitelných přihlašovacích údajů.

Aspekty návrhu přihlašovacích údajů

Konkrétní případy použití určují návrh přihlašovacích údajů. Případ použití určuje:

  • požadavky na interoperabilitu

  • způsob, jakým uživatelé potřebují prokázat svou identitu, aby získali svůj VC

  • deklarací identity, které jsou potřeba v přihlašovacích údajích

  • pokud je potřeba odvolat přihlašovací údaje

Případy použití přihlašovacích údajů

U Ověřené ID Microsoft Entra jsou nejběžnější případy použití přihlašovacích údajů:

Ověření identity: Přihlašovací údaje se vydávají na základě více kritérií. Více kritérií může zahrnovat ověření pravosti státních dokumentů, jako je cestovní pas nebo řidičská licence a korelace informací v tomto dokumentu s dalšími informacemi, jako jsou:

  • selfíčka uživatele

  • ověření živého života

Tento druh přihlašovacích údajů je vhodný pro scénáře onboardingu identit nových zaměstnanců, partnerů, poskytovatelů služeb, studentů a dalších instancí, kde je ověření identity nezbytné.

Diagram znázorňující případ použití ověření identity

Doklad o zaměstnání/členství: Přihlašovací údaje jsou vydány k prokázání vztahu mezi uživatelem a institucí. Tento druh přihlašovacích údajů je vhodný pro přístup k volně propojeným podnikovým aplikacím, jako jsou maloobchodní prodejci nabízející slevy zaměstnancům nebo studentům. Jednou z hlavních hodnot virtuálních počítačů je přenositelnost: Po vydání může uživatel používat VC v mnoha scénářích.

Diagram znázorňující důkaz o případu použití zaměstnání

Další případy použití najdete v tématu Ověřitelné případy použití přihlašovacích údajů (w3.org).

Interoperabilita přihlašovacích údajů

V rámci procesu návrhu prozkoumejte oborová schémata, obory názvů a identifikátory, ke kterým můžete zajistit soulad s maximalizací interoperability a využití. Příklady najdete v Schema.org a pracovní skupině DIF – Deklarace identity a přihlašovací údaje.

Běžná schémata jsou oblastí, ve které se stále objevují standardy. Jedním z příkladů takového úsilí je ověřitelné přihlašovací údaje pro vzdělávací úlohu. Doporučujeme, abyste prozkoumali nově vznikající standardy v oboru vaší organizace a přispěli k jejich přispívání.

Typ a atributy přihlašovacích údajů

Po vytvoření případu použití přihlašovacích údajů musíte rozhodnout o typu přihlašovacích údajů a o atributech, které se mají zahrnout do přihlašovacích údajů. Ověřovatelé mohou číst deklarace identity ve VC prezentovaných uživateli.

Všechny ověřitelné přihlašovací údaje musí deklarovat jejich typ v definici pravidel. Typ přihlašovacích údajů rozlišuje ověřitelné schéma přihlašovacích údajů od jiných přihlašovacích údajů a zajišťuje interoperabilitu mezi vystaviteli a ověřovateli. Pokud chcete označit typ přihlašovacích údajů, zadejte jeden nebo více typů přihlašovacích údajů, které přihlašovací údaje splňují. Každý typ je jedinečný řetězec. Identifikátor URI se často používá k zajištění globální jedinečnosti. Identifikátor URI nemusí být adresovatelný. Považuje se za řetězec. Například diplomové přihlašovací údaje vydané univerzitou Contoso mohou deklarovat následující typy:

Typ Účel
https://schema.org/EducationalCredential Deklaruje, že diplomy vydané univerzitou Contoso obsahují atributy definované objektem schema.org EducationaCredential .
https://schemas.ed.gov/universityDiploma2020 Deklaruje, že diplomy vydané univerzitou Contoso obsahují atributy definované ministerstvem školství USA.
https://schemas.contoso.edu/diploma2020 Deklaruje, že diplomy vydané univerzitou Contoso obsahují atributy definované univerzitou Contoso.

Kromě oborových standardů a schémat, které mohou být použitelné pro vaše scénáře, zvažte následující aspekty:

  • Minimalizovat soukromé informace: Splňovat případy použití s minimálním množstvím soukromých informací nezbytných. Například virtuální počítač používaný pro weby elektronického obchodování, který nabízí slevy zaměstnancům alumnim, může být splněna tak, že přihlašovací údaje zobrazíte pouze s deklaracemi jména a příjmení. Další informace, jako je například datum přijetí, titul, oddělení, nejsou potřeba.

  • Upřednostňování abstraktních deklarací: Každá deklarace identity by měla vyhovět potřebě a zároveň minimalizovat podrobnosti. Například deklarace identity s názvem ageOver s diskrétními hodnotami, jako jsou 13, 21, 60, je abstraktnější než datum narození.

  • Plánování odvolání: Doporučujeme definovat deklaraci identity indexu, která umožňuje mechanismy vyhledání a odvolání přihlašovacích údajů. Jste omezeni na definování jedné deklarace indexu pro každou smlouvu. Je důležité si uvědomit, že hodnoty indexovaných deklarací identity nejsou uložené v back-endu, pouze hodnota hash hodnoty deklarace identity. Další informace najdete v tématu Odvolání dříve vydaných ověřitelných přihlašovacích údajů.

Další aspekty atributů přihlašovacích údajů najdete ve specifikaci ověřitelného datového modelu přihlašovacích údajů 1.0 (w3.org).

Plánování atributů kvality

Plánování výkonu

Stejně jako u jakéhokoli řešení musíte naplánovat výkon. Klíčové oblasti, na které se zaměřit, jsou latence 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. Když ale přijetí řešení pro vystavování způsobí vydání 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í část popisuje 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 Západní Evropa, Severní Evropa, USA – západ 2, USA – západní střed, Austrálie a Japonsko. Pokud se váš tenant Microsoft Entra nachází v RÁMCI EU, Ověřené ID Microsoft Entra služba je také v EU.

  • Pokud chcete omezit latenci, nasaďte váš frontendový web pro vydávání a trezor klíčů v oblasti, kterou jste vybrali dříve.

Model založený na propustnosti:

  • Služba Vystavitel podléhá omezením služby Azure Key Vault.

  • Ve službě Azure Key Vault existují tři operace podepisování, které se týkají každé vystavování VC:

    • Jedna pro žádost o vystavení z webu

    • Jeden pro vytvořený VC

    • Jeden pro stažení smlouvy

  • Nemůžete řídit omezování; Doporučujeme ale přečíst si pokyny k omezování služby Azure Key Vault.

  • Pokud plánujete velké zavedení a onboarding virtuálních počítačů, zvažte dávkování vytváření VC, abyste zajistili, že nepřekročíte limity.

V rámci plánu výkonu určete, co monitorujete, abyste lépe porozuměli výkonu řešení. Kromě monitorování webů na úrovni aplikací zvažte při definování strategie monitorování vystavování VC následující:

Pro zajištění škálovatelnosti zvažte implementaci metrik pro následující položky:

  • Definujte logické fáze procesu vystavování. Příklad:

  • Počáteční požadavek

  • Údržba kódu QR nebo hloubkového odkazu

  • Vyhledávání atributů

  • Volání služby pro vystavování Ověřené ID Microsoft Entra

  • Vystavené přihlašovací údaje

  • Definujte metriky na základě fází:

    • Celkový počet požadavků (objem)

    • Požadavky za jednotku času (propustnost)

    • Čas strávený (latence)

  • Monitorování služby Azure Key Vault pomocí následujícího odkazu:

  • Monitorujte komponenty používané pro vrstvu obchodní logiky.

Plánování spolehlivosti

Pokud chcete naplánovat spolehlivost, doporučujeme:

  • Po definování cílů dostupnosti a redundance využijte následující příručky, abyste pochopili, jak dosáhnout vašich cílů:

  • V případě front-endové a obchodní vrstvy se vaše řešení může projevit neomezeným počtem způsobů. Stejně jako u jakéhokoli řešení se u závislostí, které identifikujete, ujistěte se, že jsou závislosti odolné a monitorované.

Pokud se vzácná událost, že služba pro vystavování Ověřené ID Microsoft Entra nebo služby Azure Key Vault přestanou být k dispozici, celé řešení se stane nedostupným.

Plánování dodržování předpisů

Vaše organizace může mít specifické požadavky na dodržování předpisů související s vaším odvětvím, typem transakcí nebo zemí nebo oblastí provozu.

Rezidence dat: Služba vystavování Ověřené ID Microsoft Entra se nasadí v podmnožině oblastí Azure. Služba se používá jenom pro výpočetní funkce. V systémech Microsoftu neukládáme hodnoty ověřitelných přihlašovacích údajů. V rámci procesu vystavování se ale odesílají a používají osobní údaje při vydávání virtuálních počítačů. Použití služby VC by nemělo mít vliv na požadavky na rezidenci dat. Pokud ukládáte jakékoli osobní údaje jako součást ověření identity, ujistěte se, že je ukládáte způsobem a oblastí, které splňují vaše požadavky na dodržování předpisů. Pokyny související s Azure najdete v centru zabezpečení Microsoftu.

Odvolání přihlašovacích údajů: Určete, jestli vaše organizace potřebuje odvolat přihlašovací údaje. Správce může například potřebovat odvolat přihlašovací údaje, když zaměstnanec odejde ze společnosti. Další informace najdete v tématu Odvolání dříve vydaných ověřitelných přihlašovacích údajů.

Vypršení platnosti přihlašovacích údajů: Určete, jak vyprší platnost vašich přihlašovacích údajů. Pokud například vydáte VC jako doklad o tom, že máte řidičskou licenci, může vypršet po několika letech. Jiné virtuální počítače můžou mít kratší platnost, aby se uživatelé pravidelně vraceli, aby aktualizovali svůj virtuální počítač.

Plánování provozu

Při plánování operací je velmi důležité vytvořit schéma pro řešení potíží, vytváření sestav a rozlišování různých zákazníků, které podporujete. Pokud je navíc provozní tým zodpovědný za provádění odvolání VC, musí být tento proces definován. Každý krok v procesu by měl být korelován, abyste mohli určit, které položky protokolu je možné přidružit ke každému jedinečnému požadavku na vystavení. Pro auditování doporučujeme zachytit každý pokus o vydání přihlašovacích údajů jednotlivě. Konkrétně:

  • Vygenerujte jedinečná ID transakcí, na která můžou zákazníci a technici podpory odkazovat podle potřeby.

  • Vytvořte mechanismus pro korelaci protokolů transakcí služby Azure Key Vault s ID transakcí části řešení vystavení.

  • Pokud jste služba ověřování identit, která vydává virtuální počítače jménem několika zákazníků, monitorujte a zmírňovali id zákazníka nebo smlouvy pro generování sestav a fakturaci, které jsou určené pro zákazníky.

  • Pokud jste služba ověřování identit, která vydává virtuální počítače jménem několika zákazníků, použijte ID zákazníka nebo smlouvy pro generování sestav a fakturaci, monitorování a zmírnění rizik.

Plánování zabezpečení

V rámci aspektů návrhu, které se zaměřují na zabezpečení, doporučujeme následující položky:

  • Pro správu klíčů:

    • Vytvořte vyhrazenou službu Key Vault pro vystavování VC. Omezte oprávnění služby Azure Key Vault na službu vystavování Ověřené ID Microsoft Entra a instanční objekt webu front-endové služby pro vystavování.

    • Zacházet se službou Azure Key Vault jako s vysoce privilegovaným systémem – Azure Key Vault vydává pro zákazníky přihlašovací údaje. Doporučujeme, aby žádné lidské identity neměly oprávnění ke službě Azure Key Vault. Správci by měli mít přístup ke službě Key Vault jenom v čase. Další osvědčené postupy pro použití služby Azure Key Vault najdete ve standardních hodnotách zabezpečení Azure pro Službu Key Vault.

  • Pro instanční objekt, který představuje front-endový web pro vystavování:

    • Definujte vyhrazený instanční objekt pro autorizaci přístupu ke službě Azure Key Vault. Pokud je váš web v Azure, doporučujeme použít spravovanou identitu Azure.

    • Zacházejte s instančním objektem, který představuje web a uživatele jako jednu hranici důvěryhodnosti. I když je možné vytvořit více webů, existuje pro řešení vystavování jenom jedna sada klíčů.

Pro protokolování a monitorování zabezpečení doporučujeme následující položky:

  • Povolte protokolování a upozorňování služby Azure Key Vault, abyste mohli sledovat operace vystavování přihlašovacích údajů, pokusy o extrakci klíčů, změny oprávnění a monitorování a odesílání výstrah pro změny konfigurace. Další informace najdete v tématu Jak povolit 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í.

  • Zmírnění rizik falšování identity pomocí následujícího:

    • Ověření DNS, které zákazníkům pomáhá identifikovat branding vystavitele

    • Názvy domén, které jsou pro koncové uživatele smysluplné.

    • Důvěryhodný branding, který koncový uživatel rozpozná.

  • Zmírnění rizik vyčerpání prostředků služby DDOS (Distributed Denial of Service) a služby Key Vault Každý požadavek, který aktivuje žádost o vystavení VC, vygeneruje 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í doporučujeme chránit provoz zahrnutím ověřování nebo captcha.

Pokyny ke správě prostředí Azure doporučujeme zkontrolovat srovnávací test zabezpečení cloudu Microsoftu a zabezpečení prostředí Azure pomocí Microsoft Entra ID. Tyto příručky poskytují osvědčené postupy pro správu základních prostředků Azure, včetně služby Azure Key Vault, Azure Storage, webů a dalších služeb a možností souvisejících s Azure.

Další aspekty

Po dokončení poc shromážděte všechny informace a vygenerovanou dokumentaci a zvažte vyřazení konfigurace vystavitele.

Další informace o implementaci a provozu služby Key Vault najdete v osvědčených postupech pro použití služby Key Vault. Další informace o zabezpečení tenantů Microsoft Entra pomocí Microsoft Entra ID najdete v tématu Úvod k delegované správě a izolovaným prostředím.

Další kroky

Přečtěte si přehled architektury.

Plánování řešení pro ověření

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