Odolnost prostřednictvím osvědčených postupů pro vývojáře

  • Článek

V tomto článku sdílíme některé poznatky založené na našich zkušenostech z práce s velkými zákazníky. Tato doporučení můžete zvážit při návrhu a implementaci služeb.

Image shows developer experience components

Použití knihovny Microsoft Authentication Library (MSAL)

Knihovna MSAL (Microsoft Authentication Library) a knihovna ověřování webu microsoft identity pro ASP.NET zjednodušují získávání, správu, ukládání do mezipaměti a aktualizaci tokenů, které aplikace vyžaduje. Tyto knihovny jsou optimalizované speciálně pro podporu Microsoft Identity včetně funkcí, které zlepšují odolnost aplikací.

Vývojáři by měli přijmout nejnovější verze KNIHOVNY MSAL a zůstat v aktualizovaném stavu. Zjistěte , jak zvýšit odolnost ověřování a autorizace v aplikacích. Pokud je to možné, vyhněte se implementaci vlastního zásobníku ověřování a používejte dobře zavedené knihovny.

Optimalizace čtení a zápisů adresářů

Adresářová služba Azure AD B2C podporuje miliardy ověřování za den. Je určená pro vysokou míru čtení za sekundu. Optimalizujte zápisy, abyste minimalizovali závislosti a zvýšili odolnost.

Optimalizace čtení a zápisů adresářů

  • Vyhněte se funkcím zápisu do adresáře při přihlašování: Ve vlastních zásadách nikdy nespustíte zápis bez předběžné podmínky (klauzule if). Jeden případ použití, který vyžaduje zápis na přihlášení, je migrace uživatelských hesel za běhu. Vyhněte se jakémukoli scénáři, který vyžaduje zápis při každém přihlášení. Předpoklady na cestě uživatele budou vypadat takto:

    <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>

  • Principy omezování: Adresář implementuje pravidla omezování na úrovni aplikace i tenanta. Existují další omezení rychlosti pro operace Čtení,GET, Zápis,POST, Update/PUT a Delete/DELETE a každá operace má jiné limity.

    • Zápis v době přihlášení spadá pod POST pro nové uživatele nebo PUT pro stávající uživatele.
    • Vlastní zásada, která vytvoří nebo aktualizuje uživatele při každém přihlášení, může potenciálně narazit na úroveň aplikace PUT nebo POST limit rychlosti. Stejná omezení platí při aktualizaci objektů adresáře prostřednictvím Microsoft Entra ID nebo Microsoft Graphu. Podobně zkontrolujte čtení, abyste zachovali počet čtení na každém přihlášení na minimum.
    • Odhadněte zatížení ve špičce, abyste předpověděli rychlost zápisů do adresáře a vyhnuli se omezování. Odhady provozu ve špičce by měly zahrnovat odhady akcí, jako je registrace, přihlášení a vícefaktorové ověřování (MFA). Nezapomeňte otestovat systém Azure AD B2C i aplikaci pro špičku provozu. Je možné, že Azure AD B2C dokáže zpracovat zatížení bez omezení, když vaše podřízené aplikace nebo služby nebudou.
    • Seznamte se s časovou osou migrace a naplánujte ji. Při plánování migrace uživatelů do Azure AD B2C pomocí Microsoft Graphu zvažte limity aplikací a tenantů, abyste vypočítali dobu potřebnou k dokončení migrace uživatelů. Pokud rozdělíte úlohu vytvoření uživatele nebo skript pomocí dvou aplikací, můžete použít limit pro každou aplikaci. Stále by bylo potřeba zůstat pod prahovou hodnotou pro jednotlivé tenanty.
    • Seznamte se s účinky úlohy migrace na jiné aplikace. Vezměte v úvahu živý provoz obsluhující ostatní předávající aplikace, abyste se ujistili, že nezpůsobíte omezování na úrovni tenanta a hladovění prostředků pro vaši živou aplikaci. Další informace najdete v doprovodných materiálech k omezování Microsoft Graphu.
    • K simulaci registrace a přihlášení použijte ukázku zátěžového testu.
    • Přečtěte si další informace o omezeních a omezeních služby Azure Active Directory B2C.

Prodloužení životnosti tokenů

V nepravděpodobném případě, když ověřovací služba Azure AD B2C nemůže dokončit nové registrace a přihlášení, můžete přesto poskytnout zmírnění rizik pro uživatele, kteří jsou přihlášení. Díky konfiguraci můžete uživatelům, kteří jsou již přihlášení, povolit, aby mohli aplikaci dál používat bez jakéhokoliv vnímaný přerušení, dokud se uživatel z aplikace neodhlásí nebo nevypne časový limit relace z důvodu nečinnosti.

Vaše obchodní požadavky a požadované prostředí pro koncové uživatele bude diktovat frekvenci aktualizace tokenů pro webové i jednostráňové aplikace (SPA).

Prodloužení životnosti tokenů

  • Webové aplikace: U webových aplikací, u kterých se ověřovací token ověřuje na začátku přihlášení, závisí aplikace na souboru cookie relace, aby platnost relace pokračovala. Povolte uživatelům zůstat přihlášeni implementací doby postupné relace, která bude pokračovat v obnovování relací na základě aktivity uživatele. Pokud dojde k dlouhodobému výpadku vystavování tokenů, můžete tyto časy relací dále zvýšit jako jednorázovou konfiguraci aplikace. Ponechte dobu životnosti relace na maximum povolenou.
  • SpA: Spa může záviset na přístupových tokenech, které budou volat rozhraní API. Spa tradičně používá implicitní tok, který nemá za následek obnovovací token. Spa může použít skrytou iframe k provádění nových žádostí o token vůči autorizačnímu koncovému bodu, pokud má prohlížeč stále aktivní relaci s Azure AD B2C. Pro služby SPA je k dispozici několik možností, které uživateli umožní pokračovat v používání aplikace.
    • Prodloužení doby platnosti přístupového tokenu tak, aby splňovalo vaše obchodní požadavky.
    • Sestavte aplikaci tak, aby jako ověřovací proxy server používala bránu rozhraní API. V této konfiguraci se spa načte bez ověřování a volání rozhraní API se provádí do brány rozhraní API. Brána rozhraní API odešle uživatele prostřednictvím procesu přihlašování pomocí udělení autorizačního kódu na základě zásad a ověří uživatele. Pak se relace ověřování mezi bránou rozhraní API a klientem udržuje pomocí ověřovacího souboru cookie. Brána rozhraní API obsluhuje rozhraní API pomocí tokenu získaného bránou rozhraní API (nebo jiné metody přímého ověřování, jako jsou certifikáty, přihlašovací údaje klienta nebo klíče rozhraní API).
    • Migrujte spa z implicitního udělení na tok udělení autorizačního kódu s podporou proof key for Code Exchange (PKCE) a sdílení prostředků mezi zdroji (CORS). Migrujte aplikaci z MSAL.js 1.x na MSAL.js 2.x, abyste si uvědomili odolnost webových aplikací.
    • U mobilních aplikací se doporučuje prodloužit dobu platnosti obnovovacího i přístupového tokenu.
  • Aplikace back-endu nebo mikroslužeb: Vzhledem k tomu, že aplikace back-endu (démon) nejsou interaktivní a nejsou v kontextu uživatele, potenciální krádež tokenů se výrazně snižuje. Doporučujeme zajistit rovnováhu mezi zabezpečením a životností a nastavit dlouhou životnost tokenu.

Konfigurace jednotného přihlašování

S jednotným přihlašováním se uživatelé přihlašují jednou pomocí jednoho účtu a získají přístup k více aplikacím. Aplikace může být webová, mobilní nebo jednostránkové aplikace (SPA) bez ohledu na platformu nebo název domény. Když se uživatel poprvé přihlásí k aplikaci, Azure AD B2C zachová relaci založenou na souborech cookie.

Po následných žádostech o ověření Azure AD B2C přečte a ověří relaci založenou na souborech cookie a vydá přístupový token bez výzvy, aby se uživatel znovu přihlásil. Pokud je jednotné přihlašování nakonfigurované s omezeným oborem v zásadách nebo aplikaci, bude pozdější přístup k jiným zásadám a aplikacím vyžadovat nové ověření.

Konfigurace jednotného přihlašování

Nakonfigurujte jednotné přihlašování tak, aby bylo v rámci celého tenanta (výchozí) povoleno více aplikací a toků uživatelů ve vašem tenantovi sdílet stejnou uživatelskou relaci. Konfigurace v rámci celého tenanta zajišťuje největší odolnost vůči čerstvému ověřování.

Postupy bezpečného nasazení

Nejběžnějšími narušeními služby jsou změny kódu a konfigurace. Přijetí procesů a nástrojů CICD (Continuous Integration and Continuous Delivery) pomáhá s rychlým nasazením ve velkém měřítku a snižuje lidské chyby během testování a nasazování do produkčního prostředí. Osvojte si CICD pro snížení, efektivitu a konzistenci chyb. Příkladem CICD je Azure Pipelines .

Ochrana před roboty

Chraňte své aplikace před známými ohroženími zabezpečení, jako jsou útoky DDoS (Distributed Denial of Service), injektáže SQL, skriptování mezi weby, vzdálené spuštění kódu a mnoho dalších, jak je uvedeno v OWASP Top 10. Nasazení firewallu webových aplikací (WAF) může bránit před běžným zneužitím a ohrožením zabezpečení.

Rotace tajných kódů

Azure AD B2C používá tajné kódy pro aplikace, rozhraní API, zásady a šifrování. Tajné kódy jsou zabezpečené ověřování, externí interakce a úložiště. National Institute of Standards and Technology (NIST) volá časové období, během kterého je určitý klíč autorizovaný pro použití legitimními entitami kryptografickým kódem. Zvolte správnou délku cryptoperiodu, aby vyhovovala vašim obchodním potřebám. Vývojáři musí ručně nastavit vypršení platnosti a obměňovat tajné kódy před vypršením jejich platnosti.

Postup implementace obměně tajných kódů

  • Použití spravovaných identit pro podporované prostředky k ověření u jakékoli služby, která podporuje ověřování Microsoft Entra. Když používáte spravované identity, můžete spravovat prostředky automaticky, včetně obměně přihlašovacích údajů.
  • Proveďte inventarizaci všech klíčů a certifikátů nakonfigurovaných v Azure AD B2C. Tento seznam bude pravděpodobně obsahovat klíče používané ve vlastních zásadách, rozhraních API, tokenu podpisového ID a certifikátech pro SAML.
  • Pomocí CICD obměňujte tajné kódy, jejichž platnost brzy vyprší do dvou měsíců od očekávané špičky sezóny. Doporučený maximální cryptoperiod privátních klíčů přidružených k certifikátu je jeden rok.
  • Proaktivně monitorujte a obměňujte přihlašovací údaje pro přístup k rozhraní API, jako jsou hesla a certifikáty.

Testování rozhraní REST API

V kontextu odolnosti musí testování rozhraní REST API zahrnovat ověření – kódy HTTP, datovou část odpovědi, hlavičky a výkon. Testování by nemělo zahrnovat pouze šťastné testy cest, ale také zkontrolovat, jestli rozhraní API řádně zpracovává problémové scénáře.

Testování rozhraní API

Doporučujeme, aby váš testovací plán zahrnoval komplexní testy rozhraní API. Pokud plánujete nadcházející nárůst z důvodu povýšení nebo dovolené, je potřeba upravit zátěžové testování pomocí nových odhadů. Proveďte zátěžové testování vašich rozhraní API a sítě pro doručování obsahu (CDN) ve vývojářském prostředí a ne v produkčním prostředí.

Další kroky