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í ve vývoji aplikací s nulovou důvěryhodností. Vždy vylepšete zabezpečení aplikace principy nulové důvěry principem nejnižšího oprávnění a explicitně ověřujte.

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

Když potřebujete, aby se uživatel ověřil ve vaší aplikaci, místo aby shromažďovala 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. Nároky hlavičky Deklarace v hlavičkách tokenů ID zahrnují typ (deklarace typu), alg (algoritmus pro podpis tokenu) a kid (otisk palcem pro veřejný klíč k ověření podpisu tokenu).
2. Nároky na obsah Datová část nebo tělo (prostřední část webového tokenu JSON) obsahuje řadu párů atributů názvu. Standard vyžaduje, aby existoval nárok s iss (názvem vystavitele), který přejde do aplikace, jíž byl token vydán (nárok příjemce nebo aud).
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": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
}.
.[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í cílové skupiny (aud), která odpovídá ID klienta vaší aplikace, uživatel identifikovaný v tokenu se ověřil vůči vaší 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 (vypršení platnosti) vás informuje, kdy vyprší platnost tokenu. Pokud je aktuální čas před časem v deklaraci exp, token je platný.
• Nepovažujte uživatele za ověřeného před časem určeným v deklaraci nbf (not before time). Doby nbf a exp určují platnou dobu životnosti tokenu. Pokud je čas vypršení platnosti bezprostřední, ujistěte se, že získáte nový token ID.
• sub (nárok 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ější způsob přiřazení dat k uživateli. Deklarace sub 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, sub, oid a tid zůstávají neměnné. Cokoli o uživateli se může změnit a přesto můžete svá data propojit s identifikací uživatele na základě subjektu nebo kombinované deklarace identity tid a oid.

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. Úlohy (aplikace, které nemají uživatele, ale běží jako služby, procesy běžící na pozadí, démony) tento krok přeskočí.

Jako první byste měli vždy bezobslužně požádat o tento token. Pokud chcete token v Microsoft Authentication Libraries (MSAL) získat tiše, 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 po obdržení ID tokenu z Microsoft Entra ID vytvořily relaci pro uživatele. V ID tokenu, který aplikace obdrží, je deklarace vypršení platnosti s Unix časovým razítkem. Toto časové razítko určuje čas vypršení nebo po něm, pro který 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ého 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 ve webovém prostředí (například stav relace a soubory cookie) po úspěšném ověření umožňují jednotné přihlášení.

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 SSO (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 krabice. 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 "Karty". Pod popiskem jsou čtyři čtverečky, které představují okna prohlížeče na záložká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ších platforma Microsoft identity nativně podporuje jednotné přihlašování v prohlížeči Microsoft Edge. Když se uživatel přihlásí k Windows, nastavení 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) umožňují každému prohlížeči sdílet stav jednotného přihlašování samotného 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. Každou ze čtyř krabic spojuje s obrazcem cloudu čára s šipkou na obou jejích koncích.

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

Běžným vzorem je, aby každá nativní aplikace měla vlastní vložený WebView, který brání její účasti v SSO. 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. Ke každé ze čtyř krabic je připojena čára, která spojuje obdélníkový tvar a je zakončena šipkou na každém konci.

S nasazeným zprostředkovatelem ověřování aplikace odesílají ověřovací žádosti zprostředkovateli místo přímo na Platformu Microsoft Identity. Tímto způsobem se broker stane sdílenou platformou 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 zavádění konceptu nulové důvěry (Zero Trust) mohou podniky chtít, aby aplikace běžely jenom na podnikových spravovaných zařízeních. Příklady správy podnikových zařízení zahrnují úplnou správu mobilních zařízení (MDM) a scénáře, ve kterých uživatelé používají svá vlastní zařízení a účastní se 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ředkovatelem ověřování buď aplikace Microsoft Authenticator (pro zařízení s iOSem nebo Androidem), nebo aplikace Portál společnosti (pro zařízení s Androidem). Aplikace přistupují 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ískají přístup ke zprostředkovateli ověřování (zejména pro aplikace, které nejsou aplikacemi Univerzální platformy Windows).

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. PRT mohou 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.
• Zvyšování odolnosti ověřovacích a autorizačních aplikací, které vyvíjíte, se zabývá aplikacemi, 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.