Megosztás a következőn keresztül:

Rugalmasság fejlesztői ajánlott eljárásokkal

  • Cikk

Ebben a cikkben a nagy ügyfelekkel végzett munka során szerzett tapasztalatunkból profitálhat. Ezeket a javaslatokat megfontolhatja a szolgáltatások tervezéséhez és megvalósításához.

Microsoft Authentication Library

A Microsoft Authentication Library (MSAL) és a Microsoft identity web authentication library ASP.NET leegyszerűsíti az alkalmazások jogkivonatainak beszerzését, kezelését, gyorsítótárazását és frissítését. Ezek a kódtárak a Microsoft Identity támogatására vannak optimalizálva, beleértve az alkalmazás rugalmasságát javító funkciókat is.

A fejlesztők az MSAL legújabb kiadásait fogadhatják el, és naprakészek maradhatnak. Megtudhatja , hogyan növelheti a hitelesítés és az engedélyezés rugalmasságát az alkalmazásokban. Ha lehetséges, kerülje a saját hitelesítési verem implementálását. Ehelyett használjon jól bevált kódtárakat.

Könyvtárolvasások és -írások optimalizálása

Az Azure AD B2C címtárszolgáltatás több milliárd hitelesítést támogat naponta, magas másodpercenkénti olvasási sebességgel. Optimalizálja írásait a függőségek minimalizálása és a rugalmasság növelése érdekében.

Könyvtárolvasások és -írások optimalizálása

  • Kerülje a függvények írását a címtárba a bejelentkezéskor: Ne hajtsa végre az írást a bejelentkezéskor előfeltételek nélkül (ha záradék) az egyéni szabályzatokban. A bejelentkezéshez írást igénylő használati eset a felhasználói jelszavak igény szerint történő áttelepítése. Nincs szükség írásra minden bejelentkezéshez. A felhasználói folyamat előfeltételei a következők:

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

  • A szabályozás ismertetése: A címtár alkalmazás- és bérlőszintű szabályozási szabályokat implementál. Az olvasási/GET,írási/POST-, frissítési/PUT- és törlési/törlési műveletekre további sebességkorlátok vonatkoznak. Minden műveletnek különböző korlátai vannak.

    • A bejelentkezés során történő írás az új felhasználók bejegyzése, az aktuális felhasználók esetében pedig a PUT függvény alá tartozik.
    • Az egyéni szabályzatok, amelyek minden bejelentkezéskor létrehoznak vagy frissítenek egy felhasználót, alkalmazásszintű PUT vagy POST sebességkorlátot érhetnek el. Ugyanezek a korlátozások vonatkoznak a címtárobjektumok Microsoft Entra ID-n vagy Microsoft Graphon keresztüli frissítésére. Hasonlóképpen vizsgálja meg az olvasásokat, hogy az olvasások száma minden bejelentkezésnél a lehető legkisebb legyen.
    • Becsülje meg a maximális terhelést a címtár írási sebességének előrejelzéséhez és a szabályozás elkerüléséhez. A csúcsforgalmi becsléseknek tartalmazniuk kell az olyan műveletek becsléseit, mint a regisztráció, a bejelentkezés és a többtényezős hitelesítés (MFA). Tesztelje az Azure AD B2C-rendszert és az alkalmazást a csúcsforgalom érdekében. Az Azure AD B2C szabályozás nélkül képes kezelni a terhelést, ha az alsóbb rétegbeli alkalmazások vagy szolgáltatások nem.
    • Ismerje meg és tervezze meg a migrálási ütemtervet. Amikor a Felhasználók Azure AD B2C-be való migrálását tervezi a Microsoft Graph használatával, vegye figyelembe az alkalmazás és a bérlő korlátait, hogy kiszámítsa a felhasználói migrálás befejezésének idejét. Ha két alkalmazással osztotta fel a felhasználólétrehozási feladatot vagy a szkriptet, használhatja az alkalmazásonkénti korlátot. Győződjön meg arról, hogy a bérlőnkénti küszöbérték alatt marad.
    • Megismerheti a migrálási feladat más alkalmazásokra gyakorolt hatását. Fontolja meg a más függő alkalmazások által kiszolgált élő forgalmat, hogy az élő alkalmazás bérlői szintjén és erőforrás-éhezésében ne legyen szabályozás. További információkért tekintse meg a Microsoft Graph szabályozási útmutatóját.
    • A regisztráció és a bejelentkezés szimulálásához használjon terhelésteszt-mintát.
    • További információ az Azure AD B2C szolgáltatáskorlátjairól és korlátozásairól.

A jogkivonatok élettartama

Ha az Azure AD B2C hitelesítési szolgáltatás nem tudja elvégezni az új regisztrációkat és bejelentkezéseket, a bejelentkezett felhasználók számára nyújtson kockázatcsökkentést. A konfigurációval a bejelentkezett felhasználók megszakítás nélkül használhatják az alkalmazást, amíg ki nem jelentkeznek az alkalmazásból, vagy a munkamenet túllépi az inaktivitás idejét.

Az üzleti követelmények és a végfelhasználói élmény határozza meg a webes és az egyoldalas alkalmazások (SLA-k) jogkivonat-frissítésének gyakoriságát.

Jogkivonat élettartamának meghosszabbítása

  • Webalkalmazások: Olyan webalkalmazások esetében, amelyeknél a hitelesítési jogkivonatot bejelentkezéskor érvényesítik, az alkalmazás a munkamenet cookie-jától függ, hogy a munkamenet érvényessége tovább nőjön. Engedélyezze a felhasználók számára, hogy továbbra is bejelentkezve maradjanak a felhasználói tevékenység alapján megújított, gördülő munkamenetek végrehajtásával. Ha hosszú távú jogkivonat-kiállítási leállás áll fenn, ezek a munkamenet-idők az alkalmazás egyszeri konfigurációjaként növelhetők. Tartsa a munkamenet élettartamát a maximálisan megengedett értékre.
  • SPA-k: A SPA-k hozzáférési jogkivonatoktól függhetnek, hogy hívásokat kezdeményezhessenek az API-khoz. Az SLA-k esetében azt javasoljuk, hogy használja az engedélyezési kódfolyamatot a Proof Key for Code Exchange (PKCE) folyamattal, hogy a felhasználó továbbra is használni lehessen az alkalmazást. Ha az SPA implicit folyamatot használ, fontolja meg az engedélyezési kódfolyamatba való migrálást a PKCE-vel. Az alkalmazás migrálása az MSAL.js 1.x-ről MSAL.js 2.x-re a webalkalmazások rugalmasságának megvalósításához. Az implicit folyamat nem eredményez frissítési jogkivonatot. Az SPA egy rejtett iframe használatával új jogkivonat-kéréseket hajthat végre az engedélyezési végponton, ha a böngésző aktív munkamenetet végez az Azure AD B2C-vel. Az SLA-k esetében van néhány lehetőség, amelyekkel a felhasználó továbbra is használhatja az alkalmazást.
    • A hozzáférési jogkivonat érvényességi időtartamának meghosszabbítása.
    • Az alkalmazást úgy hozhatja létre, hogy hitelesítési proxyként API-átjárót használjon. Ebben a konfigurációban az SPA hitelesítés nélkül töltődik be, és az API-hívások az API-átjáróra kerülnek. Az API-átjáró egy engedélyezési kód megadását használó bejelentkezési folyamaton keresztül küldi el a felhasználót egy szabályzat alapján, és hitelesíti a felhasználót. Az API-átjáró és az ügyfél közötti hitelesítési munkamenetet egy hitelesítési cookie-val tartjuk karban. Az API-átjáró az API-átjáró által beszerzett jogkivonattal, vagy más közvetlen hitelesítési módszerrel, például tanúsítványokkal, ügyfél-hitelesítő adatokkal vagy API-kulcsokkal szolgáltatásokat nyújt az API-k számára.
    • Váltson az ajánlott beállításra. Migrálja a SPA-t implicit engedélyezésről engedélyezési kód megadására a Proof Key for Code Exchange (PKCE) és a Cross-Origin Resource Sharing (CORS) támogatásával.
    • Mobilalkalmazások esetén meghosszabbíthatja a frissítési és hozzáférési jogkivonat élettartamát.
  • Háttér- vagy mikroszolgáltatás-alkalmazások: A háttéralkalmazások (démonok) nem interaktívak, és nem felhasználói környezetben vannak, ezért csökken a jogkivonat-lopás esélye. Javasoljuk, hogy egyensúlyt teremtsen a biztonság és az élettartam között, és hosszú jogkivonat-élettartamot állítson be.

Egyszeri bejelentkezés

Az egyszeri bejelentkezéssel (SSO) a felhasználók egyszer bejelentkeznek egy fiókkal, és hozzáférést kapnak az alkalmazásokhoz: egy web-, mobil- vagy egyoldalas alkalmazáshoz (SPA), platformtól vagy tartománynévtől függetlenül. Amikor a felhasználó bejelentkezik egy alkalmazásba, az Azure AD B2C egy cookie-alapú munkamenetet őriz meg.

A későbbi hitelesítési kérések során az Azure AD B2C beolvassa és ellenőrzi a cookie-alapú munkamenetet, és hozzáférési jogkivonatot ad ki anélkül, hogy a felhasználót a bejelentkezésre kéri. Ha az egyszeri bejelentkezés korlátozott hatókörrel van konfigurálva egy szabályzatban vagy alkalmazásban, a többi szabályzathoz és alkalmazáshoz való későbbi hozzáféréshez új hitelesítésre van szükség.

Egyszeri bejelentkezés konfigurálása

Konfigurálja az egyszeri bejelentkezést bérlőszintű (alapértelmezett) értékre, hogy a bérlőben több alkalmazás és felhasználói folyamat is osztozhasson ugyanazon a felhasználói munkameneten. A bérlői szintű konfiguráció biztosítja a legnagyobb rugalmasságot a friss hitelesítéshez.

Biztonságos üzembehelyezési gyakorlatok

A leggyakoribb szolgáltatáskimaradások a kód- és konfigurációmódosítások. A folyamatos integrációs és folyamatos kézbesítési (CICD) folyamatok és eszközök bevezetése lehetővé teszi a nagy léptékű üzembe helyezést, és csökkenti az emberi hibákat a tesztelés és az üzembe helyezés során. Fogadja el a CICD-t a hibacsökkentés, a hatékonyság és a konzisztencia érdekében. Az Azure Pipelines a CICD példája.

Robotok elleni védelem

Az alkalmazások védelme az olyan ismert biztonsági résekkel szemben, mint az elosztott szolgáltatásmegtagadási (DDoS) támadások, az SQL-injektálások, a helyek közötti szkriptelés, a távoli kódvégrehajtás és az OWASP Top-10-ben dokumentált egyéb biztonsági rések. Webalkalmazási tűzfal (WAF) üzembe helyezése a gyakori biztonsági rések és biztonsági rések elleni védelem érdekében.

Titkos kódok

Az Azure AD B2C titkos kódokat használ alkalmazásokhoz, API-khoz, szabályzatokhoz és titkosításhoz. A titkos kulcsok biztonságos hitelesítést, külső interakciókat és tárolást biztosítnak. A Nemzeti Szabványügyi és Technológiai Intézet (NIST) a kulcsengedélyezési időtartományra utal, amelyet a jogos entitások használnak kriptoperiódaként. Válassza ki a kriptoperiódák szükséges hosszát. A lejárat előtt állítsa be a lejáratot, és forgassa el a titkos kulcsokat.

Titkos kulcsok rotálásának implementálása

  • Felügyelt identitások használata a támogatott erőforrásokhoz a Microsoft Entra-hitelesítést támogató bármely szolgáltatásban történő hitelesítéshez. Felügyelt identitások használata esetén az erőforrások automatikusan kezelhetők, beleértve a hitelesítő adatok rotálását is.
  • Leltár készítése az Azure AD B2C-ben konfigurált kulcsokról és tanúsítványokról. Ez a lista tartalmazhat az egyéni szabályzatokban, API-kban, aláíróazonosító-jogkivonatokban és a Security Assertion Markup Language (SAML) tanúsítványaiban használt kulcsokat.
  • A CICD használatával forgassa el azokat a titkos kulcsokat, amelyek a várható csúcsidőszaktól számított két hónapon belül lejárnak. A tanúsítványhoz társított titkos kulcsok ajánlott maximális kriptoperiódiója egy év.
  • Figyelje és forgassa el az API hozzáférési hitelesítő adatait, például a jelszavakat és a tanúsítványokat.

REST API-tesztelés

A rugalmasság érdekében a REST API-k tesztelésének tartalmaznia kell a HTTP-kódok, válasz hasznos adatok, fejlécek és teljesítmény ellenőrzését. Ne csak boldog elérésiút-teszteket használjon, és győződjön meg arról, hogy az API kecsesen kezeli a problémaforgatókönyveket.

Tesztterv

Javasoljuk, hogy a tesztcsomag átfogó API-teszteket tartalmaz. Az előléptetés vagy az ünnepi forgalom miatti túlfeszültségek esetén módosítsa a terheléstesztelést új becslésekkel. Api-terheléstesztelés és Tartalomkézbesítési hálózat (CDN) végrehajtása fejlesztői környezetben, nem éles környezetben.

Következő lépések