Ověřování uživatelů pro nulová důvěra (Zero Trust)

Tento článek vám jako vývojář pomůže naučit se osvědčené postupy pro ověřování uživatelů aplikací v nulová důvěra (Zero Trust) vývoji aplikací. Vždy vylepšete zabezpečení aplikace nulová důvěra (Zero Trust) principy nejnižších oprávnění a explicitně ověřte.

Tokeny ID v ověřování uživatelů

Když potřebujete, aby se uživatel ověřil ve vaší aplikaci a neshromažďuje uživatelské jméno a heslo, může vaše aplikace požádat o token identity (ID). Ověřování uživatelů prostřednictvím platformy Microsoft Identity Platform zabraňuje bezpečnostním rizikům, ke kterým dochází, když vaše aplikace uchovává přihlašovací údaje uživatele. Když požádáte o tokeny ID, dojde-li k porušení nebo ohrožení zabezpečení aplikace špatným aktérem, nebudou v aplikaci žádná uživatelská jména a odpovídající hesla.

Token ID platformy Microsoft Identity Platform je součástí standardu OpenID Connect (OIDC), který určuje tokeny ID jako webové tokeny JSON (JWT). Dlouhý řetězec JWT obsahuje tři komponenty:

1. Deklarace identity hlaviček Deklarace identity hlaviček v tokenech ID zahrnují typ (deklarace identity typu), alg (algoritmus pro podpis tokenu) a kid (kryptografický otisk pro veřejný klíč k ověření podpisu tokenu).
2. Deklarace identity datové části Datová část nebo tělo (prostřední část webového tokenu JSON) obsahuje řadu párů atributů názvu. Standard vyžaduje, aby byla deklarace identity s iss (názvem vystavitele), která přejde do aplikace, která token vydala ( auddeklarace identity nebo cílové skupiny).
3. Podpis. Microsoft Entra ID vygeneruje podpis tokenu, který můžou aplikace použít k ověření, že token nenímodifikovaný a že mu můžete důvěřovat.

Následující příklad tokenu ID zobrazuje informace o uživateli a potvrzuje ověření pro použití aplikace.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "1LTMzakihiRla_8z2BEJVXeWMqo"
}.
{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/3338040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "aud": "6cb04018-a3f5-46a7-b995-940c78f5aef3",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "00000000-0000-0000-66f3-3332eca7ea81",
  "tid": "3338040d-6c67-4c5b-b112-36a304b66dad",
}.
.[Signature]

Tokeny ID ve správě přístupu

Pokud chcete získat ID aplikace (klienta), zaregistrujte aplikaci na platformě Microsoft Identity Platform. Když obdržíte token s deklarací identity cílové skupiny (aud), která odpovídá ID klienta vaší aplikace, identifikovaný uživatel v tokenu ověřený pro vaši aplikaci. Správci IT můžou povolit všem uživatelům v tenantovi používat vaši aplikaci. Můžou povolit skupinu, ve které je uživatel členem, aby vaši aplikaci používal.

Pokud obdržíte token, jehož deklarace cílové skupiny se liší od ID klienta vaší aplikace, okamžitě token zamítněte. Uživatel není ve vaší aplikaci ověřený, protože se přihlásil k jiné aplikaci. Vždy se ujistěte, že má uživatel oprávnění k používání vaší aplikace.

Při ověřování uživatelů jsou důležité tyto podrobnosti deklarací identity:

• Webový token JSON je platný, dokud nevyprší platnost. Deklarace exp identity (vypršení platnosti) vás informuje o vypršení platnosti tokenu. Pokud je aktuální čas před časem deklarace exp identity, token je platný.
• Neuvádějte uživatele jako ověřeného před časem určeným v nbf deklaraci identity (nikoli před časem). Časy nbf tokenu exp definují platnou životnost tokenu. Pokud je čas vypršení platnosti bezprostřední, ujistěte se, že získáte nový token ID.
• Deklarace sub identity (subjektu) je jedinečný identifikátor uživatele aplikace. Stejný uživatel má pro jiné aplikace jinou sub deklaraci identity. Pokud chcete uložit data, která chcete přidružit zpět k uživateli a zabránit útočníkovi v tom, aby toto přidružení udělal, použijte deklaraci subjektu. Vzhledem k tomu, že nezpřístupňuje identitu Microsoft Entra uživatele, je to nejsoukromého způsobu přidružování dat k uživateli. Deklarace sub identity je neměnná.
• Pokud chcete sdílet informace mezi více aplikacemi, použijte kombinaci deklarací IDENTITY tenanta (tid) a ID objektu (oid), které jsou pro uživatele jedinečné. Kombinované ID tenanta a ID objektu jsou neměnné.
• Bez ohledu na to, co se stane s identitou jednotlivce, suboidzůstávají neměnné .tid Cokoli o uživateli se může změnit a přesto můžete svá data označit jako identifikátor na základě předmětu nebo kombinovaného tid a oid deklarace identity.

Ověřování pomocí OIDC

Abychom si ukázali ověřování uživatelů, podívejme se na aplikace, které k ověření uživatele používají OIDC. Stejné principy platí pro aplikace, které používají SAML (Security Assertion Markup Language) nebo WS-Federation.

Aplikace ověří uživatele, když aplikace požádá o token ID z platformy Microsoft Identity Platform. Tento krok přeskočí úlohy (aplikace, které nemají uživatele, ale spíše běží jako služby, procesy na pozadí, procesy démonů).

Jako první byste měli vždy bezobslužně požádat o tento token. Pokud chcete token v knihovnách MICROSOFT Authentication Library (MSAL) získat bezobslužně, může vaše aplikace začít metodou AcquireTokenSilent . Pokud se vaše aplikace může ověřit bez narušení uživatele, obdrží požadovaný token ID.

Pokud Microsoft Identity Platform nemůže dokončit požadavek bez interakce s uživatelem, musí se vaše aplikace vrátit k metodě MSAL AcquireTokenInteractive . Pokud chcete interaktivně získat token, proveďte požadavek tak, že otevřete webovou plochu na adresu v doméně https://login.microsoftonline.com .

Na tomto webovém povrchu má uživatel soukromou konverzaci s platformou Microsoft Identity Platform. Vaše aplikace nemá žádné zobrazení této konverzace ani nemá žádnou kontrolu nad konverzací. Platforma Microsoft Identity Platform může požádat o ID uživatele a heslo, vícefaktorové ověřování (MFA), ověřování bez hesla nebo jinou interakci s ověřováním, kterou nakonfiguroval správce IT nebo uživatel.

Vaše aplikace obdrží token ID po provedení požadovaných kroků ověřování uživatelem. Když vaše aplikace obdrží token, můžete mít jistotu, že platforma Microsoft Identity Platform uživatele ověřila. Pokud vaše aplikace neobdrží token ID, platforma Microsoft Identity Platform uživatele neověřila. Nepovolujte neověřeným uživatelům pokračovat v zabezpečených oblastech vaší aplikace.

Osvědčeným postupem je, aby aplikace vytvořily relaci pro uživatele poté, co obdrží token ID z Microsoft Entra ID. V tokenu ID, který aplikace obdrží, deklarace platnosti (exp) s časovým razítkem unixu. Toto časové razítko určuje dobu vypršení platnosti, pro kterou aplikace nesmí přijmout JWT ke zpracování. Tuto dobu vypršení platnosti tokenu použijte k řízení životnosti uživatelských relací. Deklarace exp identity hraje zásadní roli při zachování explicitně ověřeného uživatele před aplikací se správnými oprávněními a po správnou dobu.

podpora Jednotné přihlašování

Ověřování jednotného přihlašování umožňuje uživatelům přihlásit se pomocí jedné sady přihlašovacích údajů k více nezávislým softwarovým systémům. Jednotné přihlašování umožňuje vývojářům aplikací nepožadovat, aby se uživatel přihlásil ke každé aplikaci samostatně a opakovaně. Vývojáři v jádru jednotného přihlašování zajišťují, aby všechny aplikace na zařízení uživatele sdílely webovou plochu, která uživatele ověřuje. Artefakty na webovém povrchu (například stav relace a soubory cookie) po úspěšném ověření jednotného přihlašování k jednotce ověřování

Jak je znázorněno v následujícím diagramu, nejjednodušším případem použití sdíleného webového povrchu je aplikace spuštěná ve webovém prohlížeči (například Microsoft Edge, Google Chrome, Firefox, Safari). Karty prohlížeče sdílejí stav jednotného přihlašování.

Název diagramu: Webový prohlížeč – nejjednodušší případ. V horní části diagramu se zobrazuje cloudový obrazec obsahující ikonu ID Microsoft Entra. Pod tvarem cloudu je pole. Propojením cloudového obrazce a rámečku je čára se šipkou na každém konci. Popisek pole je "Zůstat přihlášeni, ukládá soubory cookie stavu jednotného přihlašování napříč vyvoláním". Uvnitř pole na levé straně je ikona, která vypadá jako soubor cookie. Pod souborem cookie je titulek Soukromá konverzace s uživatelem. Pod titulkem je ikona, která představuje uživatele. Nalevo od těchto tří součástí je uvnitř krabice další krabice. Vnitřní popisek pole je "Tabulátory". Pod popiskem jsou čtyři čtverečky, které představují okna prohlížeče na kartách.

Platforma Microsoft Identity Platform spravuje stav jednotného přihlašování v jakémkoli konkrétním prohlížeči, pokud uživatel nemá na stejném zařízení otevřené jiné prohlížeče. Ve Windows 10 a novějším podporuje platforma Microsoft Identity Platform nativně jednotné přihlašování v prohlížeči Microsoft Edge. Když se uživatel přihlásí k Windows, umožní ubytování v Prohlížeči Google Chrome (prostřednictvím rozšíření účtů Windows 10) a v Mozilla Firefoxu v91+ (prostřednictvím nastavení prohlížeče) každému prohlížeči sdílet stav jednotného přihlašování samotných Windows.

Jak je znázorněno na následujícím diagramu, případ použití nativní aplikace je složitější.

Název diagramu: Nativní aplikace – vložené prohlížeče – bez jednotného přihlašování V horní části diagramu se zobrazuje cloudový obrazec obsahující ikonu ID Microsoft Entra. V dolní části diagramu jsou čtyři pole rozložená vodorovně. V pravém dolním rohu každého pole je ikona, která představuje uživatele. Uvnitř každého pole je znázornění oken prohlížeče, včetně ikony cookie a ikony zeměkoule. Spojením všech čtyř polí s obrazcem cloudu je čára se šipkou na každém konci.

Přístup zprostředkovatele ověřování

Běžným vzorem je, aby každá nativní aplikace měla vlastní vložené webové zobrazení, které brání jeho účasti v jednotném přihlašování. K vyřešení tohoto scénáře používá Microsoft Entra ID přístup zprostředkovatele ověřování (zprostředkovatel ověřování) pro nativní aplikace, jak je znázorněno v následujícím diagramu.

Název diagramu: Přístup zprostředkovatele ověřování V horní části diagramu se zobrazuje cloudový obrazec obsahující ikonu ID Microsoft Entra. Pod cloudovým obrazcem je obdélníkový obrazec s popiskem Auth Broker. Obdélníkový obrazec obsahuje ikonu cookie a ikonu zeměkoule. Propojení cloudového obrazce a obdélníkového obrazce je čára se šipkou na každém konci. V dolní části diagramu jsou čtyři pole rozložená vodorovně. V pravém dolním rohu každého pole je ikona, která představuje uživatele. Ikony v každém poli představují okna prohlížeče. Každé ze čtyř polí s obrazcem obdélníku je čára se šipkou na každém konci.

Když je zprostředkovatel ověřování zavedený, aplikace odesílají žádosti o ověření do zprostředkovatele místo přímo na platformu Microsoft Identity Platform. Tímto způsobem se zprostředkovatel stane sdílenou plochou pro veškeré ověřování na zařízení.

Kromě poskytování sdíleného povrchu poskytuje zprostředkovatel ověřování další výhody. Při přijímání nulová důvěra (Zero Trust) můžou podniky chtít, aby aplikace běžely jenom z podnikových spravovaných zařízení. Příklady správy podnikových zařízení zahrnují úplné mobilní Správa zařízení (MDM) a scénáře, ve kterých uživatelé přinesou svá vlastní zařízení, která se účastní správy mobilních aplikací (MAM).

Základní operační systémy (OS) záměrně izolují prohlížeče. Vývojáři potřebují bližší připojení k operačnímu systému, aby měli úplný přístup k podrobnostem o zařízení. Ve Windows je zprostředkovatel ověřování správcem webových účtů systému Windows (WAM). Na jiných zařízeních je zprostředkovatel ověřování buď aplikací Microsoft Authenticator (pro zařízení s iOSem nebo Androidem), nebo Portál společnosti aplikací (pro zařízení s Androidem). Aplikace přistupuje ke zprostředkovateli ověřování pomocí knihovny MSAL. Ve Windows má aplikace přístup k WAM bez MSAL. MsAL je ale nejjednodušší způsob, jak aplikace získat přístup ke zprostředkovateli ověřování (zejména aplikacím, které nejsou Univerzální platforma Windows aplikace).

Zprostředkovatelé ověřování pracují v kombinaci s ID Microsoft Entra a využívají primární obnovovací tokeny (PRT), které snižují potřebu uživatelů ověřovat vícekrát. Žádosti o přijetí změn můžou určit, jestli je uživatel na spravovaném zařízení. Microsoft Entra ID vyžaduje zprostředkovatele ověřování, protože představuje důkaz o vlastnictví tokenů, což je bezpečnější možnost než nosné tokeny, které jsou dnes rozšířeny.

Další kroky

• Řešení potíží s přístupovými tokeny Microsoft Entra: Ověření přístupového tokenu popisuje, jak, když máte přístupový token Microsoft Entra, ověříte, že určitá pole odpovídají záznamu.
• Zvýšení odolnosti ověřovacích a autorizačních aplikací, které vyvíjíte , řeší aplikace, které používají platformu Microsoft Identity Platform a Microsoft Entra ID. Obsahují pokyny pro klientské a servisní aplikace, které pracují jménem přihlášených uživatelů a aplikací démonů, které pracují vlastním jménem. Obsahují osvědčené postupy pro používání tokenů a volání prostředků.
• Přizpůsobení tokenů popisuje informace, které můžete přijímat v tokenech Microsoft Entra a jak můžete přizpůsobit tokeny.
• Konfigurace deklarací identity skupin a rolí aplikací v tokenech ukazuje, jak nakonfigurovat aplikace s definicemi rolí aplikace a přiřadit skupiny zabezpečení k rolím aplikací.
• Vytváření aplikací, které zabezpečují identitu prostřednictvím oprávnění a souhlasu , poskytuje přehled oprávnění a osvědčených postupů přístupu.