Zabezpečení aplikací s využitím průběžného vyhodnocování přístupu

Tento článek vám jako vývojář pomůže zlepšit zabezpečení aplikací pomocí průběžného vyhodnocování přístupu. Dozvíte se, jak zajistit podporu nulové důvěryhodnosti ve vašich aplikacích, které přijímají autorizaci pro přístup k prostředkům při získávání přístupových tokenů z Microsoft Entra ID.

Když Microsoft Entra ID vydá tyto přístupové tokeny, plně vyhodnotí podmínky pro danou autorizaci. Microsoft Entra ID provádí standardní autorizační akce, jako je například zajištění souhlasu, pokaždé, když vydává tokeny pro počáteční žádosti o tokeny a při aktualizaci tokenů.

Id Microsoft Entra primárně pro přístupové tokeny používá webové tokeny JSON (JWT). Rozhraní API prostředků může dekódovat, ověřovat a interpretovat JWT, aniž by při každém volání rozhraní API prostředku bylo nutné volat zpět na ID Microsoft Entra. Standard JWT definuje deklaraci identity exp, která identifikuje čas vypršení platnosti, nejdříve po kterém nesmíte přijmout token JWT ke zpracování. Ve výchozím nastavení vyprší tokeny Microsoft Entra 60 až 90 minut po vydání. Ujistěte se, že vaše aplikace ukládají do mezipaměti a používají přístupové tokeny po dobu, během které ID Microsoft Entra nevyhodnocuje podmínky autorizace.

Vyhodnocení podmínek mimo vystavení tokenu

Prodlevy můžou nastat mezi změnami podmínek uživatele a vynucení změn zásad, když Microsoft Entra ID vydává tokeny. Přístup s omezenou životností tokenů může snížit uživatelské prostředí a spolehlivost, aniž by se eliminovali rizika.

Jedno z řešení je vyhodnocovat podmínky při každém volání chráněného prostředku. Nejběžnějším způsobem implementace tohoto vynucení je introspekce tokenu. Introspekce tokenu nepoužívá pro token formát JWT. Místo toho introspekce tokenu používá neprůzraký řetězec, který rozhraní API prostředků nedokáže interpretovat. Rozhraní API pro prostředky odešle token zprostředkovateli identity při každém volání. Zprostředkovatel identity pak zkontroluje všechny podmínky a vrátí data, která může rozhraní API prostředků použít k dokončení operace. Tento proces může být nákladný, protože každé volání rozhraní API přidává další webový požadavek pro úplný cyklus zpracování.

Pokud chcete tyto výdaje napravit pomocí funkce CAE (Continuous Access Evaluation ), může rozhraní API prostředků naslouchat událostem, které Microsoft Entra ID odesílá o tokenech, které Microsoft Entra ID vydává pro rozhraní API prostředků. Například když vaše aplikace volá rozhraní Microsoft Graph API, může Microsoft Graph zkontrolovat, zda obdržel události od Microsoft Entra ID týkající se tokenu. Pokud se podmínky původního ověřování liší a uživatel musí znovu ověřit, Vrátí Microsoft Graph volající aplikaci chybu.

Microsoft Entra ID odešle událost do prostředků Microsoftu s podporou CAE, pokud dojde k některé z těchto událostí:

  • Zakázaný nebo odstraněný uživatelský účet
  • Změna nebo resetování uživatelského hesla
  • Povolené vícefaktorové ověřování uživatelů
  • Správce explicitně odvolá všechny obnovovací tokeny pro uživatele.
  • Microsoft Entra ID Protection detekuje zvýšené riziko uživatele.

Kromě toho můžou prostředky CAE s podporou Microsoftu vynutit zásady podmíněného přístupu založené na umístění.

Vylepšení zabezpečení a odolnosti aplikací pomocí CAE

Následující video Bezpečnější a odolnější aplikace postavené na Microsoft Entra Continuous Access Evaluation ukazuje, jak vytvořit klientskou aplikaci s podporou CAE.

Videoprezentace popisuje, jak aplikace fungují s moderním ověřováním, a tento postup:

  1. Aplikace žádá systém identit Microsoft o tokeny.
  2. Aplikace obdrží přístupový token.
  3. Rozhraní API pro volání aplikací / autorizace pomocí JWT
  4. Introspekce
  5. Sdílené signály a události
  6. Vyhodnocení kritické události
  7. Vyhodnocení zásad podmíněného přístupu
  8. Průběžné vyhodnocení přístupu API
  9. Výzva pohledávek

Průběžné vyhodnocování přístupu umožňuje autorizaci aplikace pro přístup k prostředku, který byl odvolán mimo dobu životnosti přístupového tokenu. Například aplikace má token, který je platný po dobu 75 minut. Uživatel má vysoce rizikový stav z důvodu porušení přihlašovacích údajů. CaE blokuje přístup aplikace k prostředku, což vyžaduje, aby se uživatel před pokračováním znovu ověřil. CaE tak dosahuje svého primárního cíle ke zlepšení zabezpečení aplikací.

Vzhledem k tomu, že přístup k prostředku je možné odvolat mimo životnost tokenu, může ID Microsoft Entra vydávat tokeny po delší dobu životnosti. U aplikací, které podporují CAE, může ID Microsoft Entra vydávat tokeny platné až po dobu 28 hodin. I když tato delší životnost tokenu nezlepší odolnost aplikace, snižuje náklady na aplikace, protože aplikace potřebuje o tokeny mnohem méně často.

CAE zlepšuje odolnost aplikace vůči problémům, se kterými se aplikace může setkat při získávání přístupového tokenu z ID Microsoft Entra. Kdykoli je to možné, Microsoft Entra ID vydá obnovovací čas v rámci odpovědi na token, která obsahuje přístupový token. Knihovny Microsoft Authentication Libraries (MSAL) používají tuto dobu aktualizace k automatickému obnovení tokenu. Čas aktualizace je zlomek (obvykle polovina) času vypršení platnosti tokenu. Pokud msAL může aktualizovat přístupový token před vypršením platnosti tokenu, je aplikace odolná vůči problémům s aktualizací tokenu.

Například když aplikace podporuje CAE, Microsoft Entra ID vydá token, který autorizuje aplikaci tak, aby volala Microsoft Graph, která je platná po dobu 24 hodin. Microsoft Entra ID pak informuje MSAL, aby proaktivně aktualizoval token po 12 hodinách. Pokud se pokusy MSAL o obnovení přístupového tokenu nezdaří, protože původní přístupový token je stále platný ještě 12 hodin, aplikace je odolnější vůči problémům při získávání tokenů z Microsoft Entra ID.

Implementace průběžného vyhodnocování přístupu v aplikaci

Jak je popsáno v tématu Použití rozhraní API s průběžným vyhodnocováním přístupu ve vašich aplikacích, musí být vaše aplikace i API prostředků, ke kterému přistupuje, mít povolené CAE. Příprava vašeho kódu na použití prostředku s povoleným CAE vám ale nebrání v používání rozhraní API, která nejsou CAE-povolena. Aplikace, které nepoužívají knihovnu MSAL, mohou přidat podporu pro výzvy k deklaracím, žádosti o deklarace a schopnosti klienta kvůli použití CAE.

Další kroky

  • Last updated on