Sdílet prostřednictvím

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

  • Článek

V tomto článku můžete využít naše zkušenosti s prací s velkými zákazníky. Tato doporučení můžete zvážit při návrhu a implementaci služeb.

Identity a ověřování Microsoftu

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

Vývojáři můžou využívat 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í. Místo toho 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 s vysokou mírou č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í: Vyhněte se provádění zápisu při přihlašování bez předběžné podmínky (klauzule if) ve vlastních zásadách. Jeden případ použití, který vyžaduje zápis na přihlášení, je migrace uživatelských hesel za běhu. Při každém přihlášení nevyžaduje zápis. Předpoklady na cestě uživatele jsou:

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

  • Principy omezování: Adresář implementuje pravidla omezování na úrovni aplikace a tenanta. Pro operace Read/GET, Write/POST, Update/PUT a Delete/DELETE platí více omezení rychlosti. Každá operace má různá omezení.

    • Zápis během přihlašování spadá pod POST pro nové uživatele nebo PUT pro aktuální uživatele.
    • Vlastní zásada, která vytvoří nebo aktualizuje uživatele při každém přihlášení, může na úrovni aplikace dosažení limitu rychlosti PUT nebo POST. 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). Otestujte systém Azure AD B2C a vaši aplikaci pro špičku provozu. Azure AD B2C dokáže zpracovat zatížení bez omezení, pokud 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 dokončení migrace uživatelů. Pokud rozdělíte úlohu nebo skript vytvoření uživatele pomocí dvou aplikací, můžete použít limit pro jednotlivé aplikace. Ujistěte se, že zůstane 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 zajistili, že nedojde k 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 AD B2C.

Životnost tokenů

Pokud ověřovací služba Azure AD B2C nemůže dokončit nové registrace a přihlášení, poskytněte omezení rizik pro uživatele, kteří jsou přihlášení. S konfigurací můžou uživatelé, kteří jsou přihlášení, používat aplikaci bez přerušení, dokud se neodhlásí z aplikace, nebo že relace vyprší z nečinnosti.

Vaše obchodní požadavky a činnost koncových uživatelů určují frekvenci aktualizace tokenů pro webové a jednostráňové aplikace (SPA).

Prodloužení životnosti tokenů

  • Webové aplikace: U webových aplikací, ve kterých se ověřovací token ověřuje při 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é se prodlužují na základě aktivity uživatele. Pokud dojde k dlouhodobému výpadku vystavování tokenů, můžete tyto časy relací 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, aby bylo možné volat rozhraní API. U spA doporučujeme použít tok autorizačního kódu s tokem proof key for Code Exchange (PKCE) jako možnost, která uživateli umožní pokračovat v používání aplikace. Pokud vaše spa používá implicitní tok, zvažte migraci na tok autorizačního kódu pomocí infrastruktury veřejných klíčů. Migrujte aplikaci z MSAL.js 1.x na MSAL.js 2.x, abyste si uvědomili odolnost webových aplikací. Implicitní tok nemá za následek obnovovací token. Spa může použít skryté iframe k provádění nových žádostí o token vůči autorizačnímu koncovému bodu, pokud má prohlížeč aktivní relaci s Azure AD B2C. Pro služby SPA existuje několik možností, které uživateli umožní pokračovat v používání aplikace.
    • Prodloužení doby platnosti přístupového tokenu
    • 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. Ověřovací relace mezi bránou rozhraní API a klientem se 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 jinou metodou přímého ověřování, jako jsou certifikáty, přihlašovací údaje klienta nebo klíče rozhraní API.
    • Přepněte na doporučenou možnost. 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).
    • U mobilních aplikací rozšiřte dobu platnosti obnovovacího a přístupového tokenu.
  • Back-endové aplikace nebo aplikace mikroslužeb: Back-endové aplikace (démon) nejsou interaktivní a nejsou v kontextu uživatele, a proto se snižuje potenciální krádež tokenů. Naším doporučením je zajistit rovnováhu mezi zabezpečením a životností a nastavit dlouhou životnost tokenu.

Jednotné přihlášení

S jednotným přihlašováním se uživatelé přihlašují jednou pomocí účtu a získají přístup k aplikacím: web, mobilní nebo jednostránkové aplikace (SPA), bez ohledu na platformu nebo název domény. Když se uživatel 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 k přihlášení uživatele. Pokud je jednotné přihlašování nakonfigurované s omezeným oborem v zásadách nebo aplikaci, pozdější přístup k jiným zásadám a aplikacím vyžaduje nové ověřování.

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 poskytuje největší odolnost proti čerstvému ověřování.

Postupy bezpečného nasazení

Nejběžnějšími přerušeními služeb jsou změny kódu a konfigurace. Přijetí procesů a nástrojů CICD (Continuous Integration and Continuous Delivery) umožňuje nasazení ve velkém měřítku a snižuje lidské chyby během testování a nasazování. 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 další zdokumentované v OWASP Top-10. Nasaďte firewall webových aplikací (WAF) pro ochranu před běžným zneužitím a ohrožením zabezpečení.

Tajné kódy

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) označuje časový rozsah autorizace klíčů používaný legitimními entitami jako cryptoperiod. Zvolte požadovanou délku cryptoperiodů. Nastavte vypršení platnosti a obměňte tajné kódy před vypršením jejich platnosti.

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 klíčů a certifikátů nakonfigurovaných v Azure AD B2C. Tento seznam může zahrnovat klíče používané ve vlastních zásadách, rozhraních API, tokenu podpisového ID a certifikátech pro jazyk SAML (Security Assertion Markup Language).
  • Pomocí CICD obměňte tajné kódy, jejichž platnost vyprší do dvou měsíců od očekávané špičky. Doporučený maximální cryptoperiod privátních klíčů přidružených k certifikátu je jeden rok.
  • 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

Kvůli odolnosti musí testování rozhraní REST API zahrnovat ověření kódů HTTP, datové části odpovědi, hlaviček a výkonu. Nepoužívejte pouze šťastné testy cest a ověřte, že rozhraní API zpracovává problémové scénáře elegantně.

Testovací plán

Doporučujeme, aby váš testovací plán zahrnoval komplexní testy rozhraní API. Pokud jde o nárůsty kvůli povýšení nebo dovolené provozu, upravte zátěžové testování pomocí nových odhadů. Proveďte zátěžové testování rozhraní API a síť pro doručování obsahu (CDN) v vývojářském prostředí, ne v produkčním prostředí.

Další kroky