Sdílet prostřednictvím

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

  • Článek

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ěra (Zero Trust) ve vašich aplikacích, které získávají autorizaci pro přístup k prostředkům, když z Microsoft Entra ID získávají přístupové tokeny.

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 exp, která identifikuje dobu vypršení platnosti, kterou nesmíte přijmout token JWT ke zpracování. Ve výchozím nastavení vyprší platnost tokenů Microsoft Entra 60 až 90 minut po problému. Vaše aplikace musí v tomto období ukládat do mezipaměti a používat přístupové tokeny, během kterých id Microsoft Entra nevyhodnocuje podmínky autorizace.

Vyhodnocení podmínek mimo vystavení tokenu

Zákazníci Microsoftu se zajímají o prodlevy mezi změnami podmínek uživatele a vynucení změn zásad, když Microsoft Entra ID vydává tokeny. Tento přístup s omezenou životností tokenů může snížit uživatelské prostředí a spolehlivost, aniž by se eliminovali rizika.

Jedním z řešení je vyhodnocení podmínek při každém volání chráněného prostředku. Nejběžnější způsob 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 prostředků 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 do každého volání rozhraní API přidává další webový požadavek na odezvu.

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, jestli přijal události z ID Microsoft Entra o 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áva istrator 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

Bezpečnější a odolné aplikace založené na videu Microsoft Entra Continuous Access Evaluation ukazují vytvoření klientské aplikace s podporou CAE.

V předchozí prezentaci se dozvíte, jak aplikace fungují při používání moderního ověřování pomocí těchto kroků:

  • Jak aplikace fungují při používání moderního ověřování
  • Aplikace žádá identitu Microsoftu o tokeny.
  • Aplikace obdrží přístupový token.
  • Rozhraní API pro volání aplikací / autorizace pomocí JWT
  • Introspekce
  • Sdílené signály a události
  • Vyhodnocení kritické události
  • Vyhodnocení zásad podmíněného přístupu
  • Vyhodnocení průběžného přístupu rozhraní API
  • Výzva deklarace identity

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á čas aktualizace jako součást odpovědi tokenu, která obsahuje přístupový token. Knihovny MICROSOFT Authentication Library (MSAL) používají tuto dobu aktualizace k proaktivní aktualizaci tokenu. Čas aktualizace je zlomek (obvykle polovina) času vypršení platnosti tokenu. Pokud msAL dokáž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 MSAL pokusí aktualizovat přístupový token selžou, protože původní přístupový token je stále platný po dobu 12 hodin, je aplikace 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 povoleným průběžným vyhodnocováním přístupu ve vašich aplikacích, musí být aplikace i rozhraní API prostředků, ke které přistupuje, povolená funkce CAE. Příprava kódu na použití prostředku s povoleným caE vám ale nebrání v používání rozhraní API, která nejsou povolená službou CAE. Aplikace, které nepoužívají knihovnu MSAL, můžou přidat podporu pro výzvy deklarací identity, žádosti o deklarace identity a možnosti klienta pro použití caE.

Další kroky