Správa tokenů pro nulová důvěra (Zero Trust)

  • Článek

Ve nulová důvěra (Zero Trust) vývoji aplikací je důležité konkrétně definovat záměr vaší aplikace a požadavky na přístup k prostředkům. Aplikace by měla požadovat pouze přístup, který vyžaduje, aby fungovala podle očekávání. Tento článek vám jako vývojář pomůže integrovat zabezpečení do vašich aplikací pomocí tokenů ID, přístupových tokenů a tokenů zabezpečení, které vaše aplikace může přijímat z platformy Microsoft Identity Platform.

Ujistěte se, že vaše aplikace dodržuje zásadu nulová důvěra (Zero Trust) nejnižších oprávnění a brání použití způsoby, které by mohly ohrozit váš záměr. Omezte přístup uživatelů pomocí technologie Just-In-Time a Just-Enough-Access (JIT/JEA), adaptivních zásad založených na rizikech a ochrany dat. Oddělte citlivé a výkonné oddíly aplikace, které poskytují přístup pouze autorizovaným uživatelům k těmto oblastem. Omezte uživatele, kteří můžou používat vaši aplikaci, a možnosti, které mají ve vaší aplikaci.

Zabudujte nejnižší oprávnění do způsobu, jakým vaše aplikace spravuje tokeny ID, které přijímá z platformy Microsoft Identity Platform. Informace v tokenech ID umožňují ověřit, že uživatel je tím, za koho se tvrdí. Uživatel nebo jejich organizace může zadat podmínky ověřování, jako je poskytování vícefaktorového ověřování, používání spravovaného zařízení a umístění ve správném umístění.

Usnadněte zákazníkům správu autorizací pro vaši aplikaci. Snižte režijní náklady na zřizování uživatelů a potřebu ručních procesů. Automatické zřizování uživatelů umožňuje správcům IT automatizovat vytváření, údržbu a odebírání identit uživatelů v úložištích cílových identit. Vaši zákazníci můžou založit automatizaci na změnách uživatelů a skupin se zřizováním aplikací nebo zřizováním řízeným personálním oddělením v Microsoft Entra ID.

Použití deklarací identity tokenů v aplikacích

Deklarace identity v tokenech ID pro uživatelské rozhraní uvnitř vaší aplikace, jako klíče v databázi a poskytnutí přístupu k klientské aplikaci. Token ID je základní rozšíření, které OpenID Připojení (OIDC) provádí v OAuth 2.0. Vaše aplikace může přijímat tokeny ID vedle přístupových tokenů nebo místo přístupových tokenů.

Ve standardním vzoru autorizace tokenu zabezpečení umožňuje vystavený token ID aplikaci přijímat informace o uživateli. Nepoužívejte token ID jako autorizační proces pro přístup k prostředkům. Autorizační server vydává tokeny ID, které obsahují deklarace identity s informacemi o uživateli, které obsahují následující informace.

  • Deklarace cílové skupiny (aud) je ID klienta vaší aplikace. Přijměte pouze tokeny pro ID klienta rozhraní API.
  • Deklarace tid identity je ID tenanta, který token vydal. Deklarace oid identity je neměnná hodnota, která jednoznačně identifikuje uživatele. Jedinečnou kombinaci tid deklarací identity a oid deklarací identity použijte v případě, že potřebujete přidružit data k uživateli. Tyto hodnoty deklarací identity můžete použít k připojení dat zpět k ID uživatele v Microsoft Entra ID.
  • Deklarace sub identity je neměnná hodnota, která jednoznačně identifikuje uživatele. Deklarace subjektu je také jedinečná pro vaši aplikaci. Pokud k přidružení dat k uživateli použijete sub deklaraci identity, není možné z dat přejít a propojit je s uživatelem v Microsoft Entra ID.

Vaše aplikace můžou obor použít openid k vyžádání tokenu ID z platformy Microsoft Identity Platform. Standard OIDC řídí openid obor spolu s formátem a obsahem tokenu ID. OIDC určuje tyto obory:

  • openid Pomocí oboru se přihlaste uživatele a přidejte sub deklaraci identity do tokenu ID. Tyto obory poskytují ID uživatele, které je jedinečné pro aplikaci a uživatele a volá koncový bod UserInfo.
  • Obor email přidá email deklaraci identity obsahující e-mailovou adresu uživatele do tokenu ID.
  • Obor profile přidá deklarace identity se základními atributy profilu uživatele (jméno, uživatelské jméno) do tokenu ID.
  • Obor offline_access umožňuje aplikaci přistupovat k uživatelským datům i v případě, že uživatel není k dispozici.

Knihovna MSAL (Microsoft Authentication Library ) vždy přidává do každého požadavku na token openid, e-mail a profile obory. V důsledku toho msAL vždy vrátí token ID a přístupový token při každém volání AcquireTokenSilent nebo AcquireTokenInteractive. MSAL vždy požaduje offline_access obor. Platforma Microsoft Identity Platform vždy vrací offline_access obor, i když požadovaná aplikace nezadá offline_access obor.

Microsoft používá standard OAuth2 k vydávání přístupových tokenů. Standard OAuth2 říká, že obdržíte token, ale nezadá formát tokenu nebo to, co musí být v tokenu. Když vaše aplikace potřebuje získat přístup k prostředku, který chrání Microsoft Entra ID, měl by použít obor definovaný prostředkem.

Microsoft Graph například definuje User.Read obor, který aplikaci autorizuje pro přístup k úplnému profilu uživatele aktuálního uživatele a názvu tenanta. Microsoft Graph definuje oprávnění v celé řadě funkcí dostupných v daném rozhraní API.

Po autorizaci vrátí platforma Microsoft Identity Platform přístupový token pro vaši aplikaci. Když prostředek zavoláte, vaše aplikace tento token poskytne jako součást autorizační hlavičky požadavku HTTP do rozhraní API.

Správa životností tokenů

Aplikace můžou po úspěšném dokončení ověřování vytvořit relaci pro uživatele s ID Microsoft Entra. Správa uživatelských relací určuje, jak často uživatel potřebuje opětovné ověření. Jeho role při zachování explicitně ověřeného uživatele před aplikací se správnými oprávněními a pro správnou dobu je zásadní. Životnost relace musí být založená exp na deklaraci identity v tokenu ID. Deklarace exp identity je čas, kdy vyprší platnost tokenu ID, a čas, po kterém už token nemůžete použít k ověření uživatele.

Vždy respektujte životnost tokenu, jak je uvedeno v odpovědi tokenu exp pro přístupové tokeny nebo deklaraci identity v tokenu ID. Podmínky, které řídí životnost tokenu, můžou zahrnovat frekvenci přihlašování pro podnik. Vaše aplikace nemůže nakonfigurovat životnost tokenu. Nemůžete požádat o životnost tokenu.

Obecně platí, že tokeny musí být platné a nevylučené. Deklarace identity cílové skupiny (aud) musí odpovídat VAŠEMu ID klienta. Ujistěte se, že token pochází od důvěryhodného vystavitele. Pokud máte víceklientské rozhraní API, můžete se rozhodnout filtrovat, aby vaše rozhraní API mohlo volat jenom konkrétní tenanty. Ujistěte se, že vynucujete životnost tokenu. nbf Zkontrolujte deklarace identity (ne dříve) a exp (vypršení platnosti) a ujistěte se, že aktuální čas spadá do hodnot těchto dvou deklarací identity.

Nezaměřujte se na mimořádně dlouhé nebo krátké životnosti relací. Nechte toto rozhodnutí řídit životnost uděleného tokenu ID. Udržování relací vaší aplikace aktivní nad rámec platnosti tokenů porušuje pravidla, zásady a obavy, které správce IT řídil nastavit dobu platnosti tokenu, aby zabránil neoprávněnému přístupu. Krátké relace snižují uživatelské prostředí a nemusí nutně zvýšit stav zabezpečení. Oblíbené architektury, jako je ASP.NET umožňují nastavit časové limity relací a souborů cookie z doby vypršení platnosti tokenu ID Microsoft Entra. Po uplynutí doby vypršení platnosti tokenu zprostředkovatele identity zajistíte, že relace uživatele nebudou delší než zásady, které zprostředkovatel identity určuje.

Mezipaměti a obnovovací tokeny

Nezapomeňte správně ukládat tokeny do mezipaměti. MsAL automaticky ukládá tokeny do mezipaměti, ale tokeny mají životnost. Tokeny používejte v plné délce jejich životnosti a odpovídajícím způsobem je ukážíte do mezipaměti. Pokud opakovaně požádáte o stejný token, omezování způsobí, že aplikace přestane reagovat. Pokud vaše aplikace zneužije vystavování tokenů, doba potřebná k vystavování nových tokenů pro prodloužení aplikace.

Knihovny MSAL spravují podrobnosti protokolu OAuth2, včetně mechaniky aktualizace tokenů. Pokud nepoužíváte knihovnu MSAL, ujistěte se, že vaše knihovna efektivně využívá obnovovací tokeny.

Když váš klient získá přístupový token pro přístup k chráněnému prostředku, obdrží obnovovací token. Obnovovací token použijte k získání nových párů přístupových/obnovovacích tokenů po vypršení platnosti aktuálního přístupového tokenu. Obnovovací tokeny slouží k získání dodatečných přístupových tokenů pro jiné prostředky. Obnovovací tokeny jsou vázané na kombinaci uživatele a klienta (ne k prostředku nebo tenantovi). Obnovovací token můžete použít k získání přístupových tokenů v libovolné kombinaci prostředků a tenanta, kde má vaše aplikace oprávnění.

Správa chyb a chyb tokenů

Aplikace by se nikdy neměla pokoušet ověřovat, dekódovat, kontrolovat, interpretovat ani zkoumat obsah přístupového tokenu. Tyto operace jsou výhradně odpovědností za rozhraní API prostředků. Pokud se vaše aplikace pokusí prozkoumat obsah přístupového tokenu, je vysoce pravděpodobné, že se vaše aplikace přeruší, když platforma Microsoft Identity Platform vydá šifrované tokeny.

Zřídka může volání načíst token selhat kvůli problémům, jako jsou selhání sítě, infrastruktury nebo selhání ověřovací služby nebo výpadek. Pokud dojde k selhání získání tokenu, zvyšte odolnost prostředí ověřování ve vaší aplikaci podle těchto osvědčených postupů:

  • Místně ukládat tokeny do mezipaměti a zabezpečit je pomocí šifrování.
  • Nepředávejte artefakty zabezpečení, jako jsou tokeny v nezabezpečených kanálech.
  • Seznamte se s výjimkami a odpověďmi služeb od zprostředkovatele identity a zareagujte na ně.

Vývojáři často mají dotazy týkající se hledání uvnitř tokenů kvůli ladění problémů, jako je například chyba 401 při volání prostředku. Vzhledem k tomu, že více šifrovaných tokenů vám brání v prohlížení přístupového tokenu, musíte najít alternativy pro hledání uvnitř přístupových tokenů. Pro ladění poskytuje odpověď tokenu, která obsahuje přístupový token, informace, které potřebujete.

V kódu zkontrolujte třídy chyb místo jednotlivých případů chyb. Pokud například systém neuděluje oprávnění, nezpracujte jednotlivé chyby, ale vyžaduje se interakce uživatelů. Vzhledem k tomu, že byste mohli tyto jednotlivé případy vynechat, je lepší zkontrolovat klasifikátor, jako je interakce uživatele, místo toho, abyste se podívali na jednotlivé kódy chyb.

Možná se budete muset vrátit zpět a AcquireTokenInteractive poskytnout výzvy k nárokům AcquireTokenSilent , které volání vyžaduje. Tím zajistíte efektivní správu interaktivní žádosti.

Další kroky