Zero trust jogkivonatok kezelése

A Zero Trust alkalmazásfejlesztés során fontos pontosan meghatározni az alkalmazás szándékát és erőforrás-hozzáférési követelményeit. Az alkalmazásnak csak a kívánt módon való működéshez szükséges hozzáférést kell kérnie. Ez a cikk segítséget nyújt fejlesztőként az alkalmazások biztonságának kialakításában azonosító jogkivonatokkal, hozzáférési jogkivonatokkal és biztonsági jogkivonatokkal, amelyeket az alkalmazás a Microsoft identitásplatformjáról kaphat.

Győződjön meg arról, hogy az alkalmazás betartja a minimális jogosultság zéró megbízhatóság elvét, és megakadályozza a használatot oly módon, hogy az veszélyeztetje a szándékát. Korlátozza a felhasználók hozzáférését a Just-In-Time és a Just-Enough-Access (JIT/JEA), kockázatalapú adaptív irányelvek és az adatok védelme segítségével. Különítse el az alkalmazás bizalmas és hatékony szakaszait. Csak engedéllyel rendelkező felhasználók számára biztosítson hozzáférést ezekhez a területekhez. Korlátozza a felhasználókat, akik használhatják az alkalmazást és az alkalmazásban lévő képességeket.

Építse be az alkalmazásába a minimális jogosultság elvét az azonosító tokenek kezelésében, amelyeket a Microsoft identitásplatformtól kap. Az azonosító jogkivonatokban található információk segítségével ellenőrizheti, hogy egy felhasználó az, akinek állítja magát. A felhasználó vagy szervezete megadhat hitelesítési feltételeket, például MFA-t, felügyelt eszközöket és megfelelő helyeket.

Megkönnyítheti az ügyfelek számára az alkalmazáshoz tartozó engedélyek kezelését. Csökkentse a felhasználólétrehozási és konfigurációs többletterhelést és a manuális folyamatokat. Az automatikus felhasználókiépítés lehetővé teszi, hogy az informatikai rendszergazdák automatizálják a felhasználói identitások létrehozását, karbantartását és eltávolítását a cél identitástárolókban. Az ügyfelek az alkalmazáskiépítéssel vagy a HR-alapú kiépítéssel rendelkező felhasználók és csoportok módosításaira alapozhatják az automatizálást a Microsoft Entra ID-ban.

Token igények használata az alkalmazásokban

Az alkalmazásban a felhasználói élmény javítása érdekében használjon jogcímeket az azonosító jogkivonatokban kulcsként egy adatbázisban. Adjon hozzáférést az ügyfélalkalmazáshoz. Az azonosító jogkivonat az OpenID Connect (OIDC) által az OAuth 2.0-hoz használt alapvető bővítmény. Az alkalmazás a hozzáférési jogkivonatok mellett vagy helyett is fogadhat azonosító jogkivonatokat.

A biztonsági jogkivonatok engedélyezésének szabványos mintájában a kiadott azonosító jogkivonat lehetővé teszi, hogy az alkalmazás információt kapjon a felhasználóról. Ne használja az azonosító jogkivonatot engedélyezési folyamatként az erőforrások eléréséhez. Az engedélyezési kiszolgáló olyan azonosítási tokeneket bocsát ki, amelyek jogcímeket tartalmaznak az alábbi felhasználói adatokkal.

  • A célközönség (aud) jogcím az alkalmazás ügyfélazonosítója. Az API-ügyfélazonosítójához csak tokent fogadjon el.
  • A tid jogcím a jogkivonatot kiállító bérlő azonosítója. A oid jogcím egy nem módosítható érték, amely egyedileg azonosítja a felhasználót. Használja a tid és oid jogcímek egyedi kombinációját kulcsként, ha adatokat kell társítania a felhasználóhoz. Ezekkel a jogcímértékekkel visszakapcsolhatja az adatokat a felhasználó Microsoft Entra-azonosítójában lévő azonosítójához.
  • A sub jogcím egy nem módosítható érték, amely egyedileg azonosítja a felhasználót. A tárgykövetelés az alkalmazásban is egyedi. Ha a sub jogcímet használja arra, hogy adatokat társítson a felhasználóhoz, lehetetlen az adatok alapján összekapcsolni azokat egy Microsoft Entra-azonosítójú felhasználóval.

Az alkalmazások a openid hatókör használatával kérhetnek azonosító jogkivonatot a Microsoft identitásplatformjáról. Az OIDC szabvány szabályozza a openid hatókört az azonosító jogkivonat formátumával és tartalmával együtt. Az OIDC a következő hatóköröket adja meg:

  • A openid hatókör használatával jelentkeztesse be a felhasználót, és adjon hozzá egy sub jogcímet az azonosító jogkivonathoz. Ezek a hatókörök olyan felhasználói azonosítót biztosítanak, amely egyedi az alkalmazás és a felhasználó számára, és meghívja a UserInfo végpontot.
  • A email hatókör hozzáad egy email jogcímet, amely a felhasználó e-mail-címét tartalmazza az azonosító jogkivonatához.
  • A profile hatókör a felhasználó alapvető profilattribútumaival (név, felhasználónév) rendelkező jogcímeket ad hozzá az azonosító jogkivonathoz.
  • A offline_access hatókör lehetővé teszi, hogy az alkalmazás akkor is hozzáférhessen a felhasználói adatokhoz, ha a felhasználó nincs jelen.

A Microsoft Authentication Library (MSAL) mindig hozzáadja az openid, email, és profile specifikus hatóköröket minden jogkivonat-kéréshez. Ennek eredményeképpen az MSAL mindig visszaad egy azonosító tokent és egy hozzáférési tokent minden AcquireTokenSilent híváshoz vagy az AcquireTokenInteractive metódushoz. Az MSAL mindig a hatókört offline_access kéri. A Microsoft identitásplatform mindig akkor is visszaad hatókört offline_access , ha a kérelmező alkalmazás nem adja meg a hatókört offline_access .

A Microsoft az OAuth2 szabványt használja hozzáférési jogkivonatok kiállításához. Az OAuth2 szabvány azt mondja, hogy jogkivonatot kap, de nem adja meg a jogkivonat formátumát, illetve azt, hogy minek kell lennie a jogkivonatban. Amikor az alkalmazásnak hozzá kell férnie egy, a Microsoft Entra ID által védett erőforráshoz, az erőforrás által meghatározott hatókört kell használnia.

A Microsoft Graph például meghatározza azt a User.Read hatókört, amely engedélyezi az alkalmazás számára az aktuális felhasználó teljes felhasználói profiljának és a bérlő nevének elérését. A Microsoft Graph az ADOTT API-ban elérhető funkciók teljes skálájára vonatkozó engedélyeket határoz meg.

Engedélyezés után a Microsoft identitásplatform egy hozzáférési jogkivonatot ad vissza az alkalmazáshoz. Amikor meghívja az erőforrást, az alkalmazás ezt a jogkivonatot a HTTP-kérés engedélyezési fejlécének részeként biztosítja az API-nak.

Jogkivonatok élettartamának kezelése

Az alkalmazások létrehozhatnak egy munkamenetet a felhasználó számára, miután a hitelesítés sikeresen befejeződött a Microsoft Entra-azonosítóval. A felhasználói munkamenet-kezelés azt határozza meg, hogy a felhasználónak milyen gyakran van szüksége ismétlődő hitelesítésre. Az a szerepe, hogy egy kifejezetten ellenőrzött felhasználót a megfelelő jogosultsággal és a megfelelő időtartamig aktívan tartson az alkalmazásban. A munkamenet élettartamának az azonosító jogkivonatban lévő exp igényen kell alapulnia. A exp jogcím az az időpont, amikor az azonosító jogkivonata lejár, és az az idő, amely után már nem használhatja a jogkivonatot a felhasználó hitelesítéséhez.

Mindig tartsa tiszteletben a jogkivonat élettartamát a hozzáférési jogkivonatokra vagy az exp azonosító jogkivonatban található jogcímre adott jogkivonat válaszában megadottak szerint. A jogkivonat élettartamát szabályozó feltételek magukban foglalhatják a vállalat bejelentkezési gyakoriságát. Az alkalmazás nem tudja konfigurálni a jogkivonat élettartamát. A token élettartama nem kérhető.

Általában győződjön meg arról, hogy a tokenek érvényesek és nem jártak le. A célközönség jogcímének (aud) meg kell egyeznie az ügyfél-azonosítójával. Győződjön meg arról, hogy a jogkivonat megbízható kiállítótól származik. Ha több-bérlős API-val rendelkezik, dönthet úgy, hogy szűr, hogy csak bizonyos bérlők hívhassák meg az API-t. Győződjön meg arról, hogy betartatja a token élettartamát. Ellenőrizze a nbf (nem korábbi) és a exp (lejárati) jogcímeket, hogy az aktuális idő a két jogcím értékein belül legyen.

Ne törekedjenek a kivételesen hosszú vagy rövid munkamenetek élettartamára. Hagyja, hogy a megadott azonosítójogkivonat élettartama határozza meg ezt a döntést. Ha az alkalmazás munkamenetei a jogkivonat érvényességi idején túl is aktívak maradnak, azzal megsértik azokat a szabályokat, előírásokat és megfontolásokat, amelyek alapján a rendszergazda meghatározta a jogkivonatok érvényességi időtartamát a jogosulatlan hozzáférés megakadályozása érdekében. A rövid munkamenetek rontják a felhasználói élményt, és nem feltétlenül növelik a biztonsági helyzetet. Az olyan népszerű keretrendszerek, mint a ASP.NET lehetővé teszik a munkamenetek és a cookie-k időtúllépésének beállítását a Microsoft Entra ID-jogkivonat lejárati idejéből. Kövesse az identitásszolgáltató jogkivonatának lejárati idejét, hogy a felhasználó munkamenetei soha ne legyenek hosszabbak az identitásszolgáltató által diktált szabályzatoknál.

Tokenek gyorsítótárazása és frissítése

Ne felejtse el megfelelően gyorsítótárba helyezni a tokeneket. Az MSAL automatikusan gyorsítótárazza a tokeneket, de ezeknek élettartamuk van. Használjon tokeneket az élettartamuk teljes hosszán keresztül, és megfelelően cache-elje őket. Ha ismételten ugyanazt a tokent kéri, a korlátozás miatt az alkalmazás válaszkészsége csökken. Ha az alkalmazás visszaél a jogkivonat kiállításával, az új jogkivonatok kiadásának ideje meghosszúl.

Az MSAL-kódtárak kezelik az OAuth2 protokoll részleteit, beleértve a frissítési jogkivonatok mechanikáját is. Ha nem MSAL-t használ, győződjön meg arról, hogy a választott kódtár hatékonyan használja a frissítési jogkivonatokat.

Amikor az ügyfél hozzáférési jogkivonatot szerez be egy védett erőforrás eléréséhez, egy frissítési jogkivonatot kap. A frissítési jogkivonat használatával új hozzáférési/frissítési jogkivonatpárokat szerezhet be az aktuális hozzáférési jogkivonat lejárata után. A frissítési jogkivonatokkal további hozzáférési jogkivonatokat szerezhet be más erőforrásokhoz. A frissítési jogkivonatok a felhasználó és az ügyfél kombinációjához vannak kötve (nem erőforráshoz vagy bérlőhöz). A frissítési jogkivonatokkal hozzáférési jogkivonatokat szerezhet be az erőforrások és bérlők bármely kombinációjában, ahol az alkalmazás rendelkezik engedélyekkel.

Tokenhibák és más hibák kezelése

Az alkalmazás soha nem kísérelheti meg ellenőrizni, dekódolni, megvizsgálni, értelmezni vagy megvizsgálni a hozzáférési jogkivonat tartalmát. Ezek a műveletek szigorúan az erőforrás API felelősségi körébe tartoznak. Ha az alkalmazás megkísérli megvizsgálni egy hozzáférési jogkivonat tartalmát, nagy valószínűséggel megszakad az alkalmazás, amikor a Microsoft identitásplatform titkosított jogkivonatokat ad ki.

A jogkivonat lekérésére irányuló hívások ritkán meghiúsulnak olyan problémák miatt, mint a hálózat, az infrastruktúra vagy a hitelesítési szolgáltatás hibája vagy leállása. A következő ajánlott eljárások követésével növelheti a hitelesítési élmény rugalmasságát az alkalmazásban, ha jogkivonat-beszerzés meghiúsul:

  • Helyben cache-elt és titkosítással védett tokek.
  • Ne adjon át biztonsági összetevőket, például jogkivonatokat a nem biztonságos csatornákon.
  • Az identitásszolgáltatótól érkező kivételek és szolgáltatásválaszok megismerése és kezelése.

A fejlesztőknek gyakran merülnek fel kérdések a jogkivonatok belsejébe nézés kapcsán, hogy hibákat derítsenek fel, például ha 401-es hibát kapnak az erőforrás meghívása során. Mivel a titkosítottabb jogkivonatok megakadályozzák a hozzáférési jogkivonatok keresését, alternatív megoldásokat kell találnia a hozzáférési jogkivonatokban való kereséshez. A hibakereséshez a válasz, amely tartalmazza a hozzáférési jogkivonatot, megadja a szükséges információkat.

A kódban az egyes hibaesetek helyett ellenőrizze a hibaosztályokat. Például kezelje a szükséges felhasználói beavatkozást az egyéni hibák helyett, ha a rendszer nem ad engedélyt. Mivel előfordulhat, hogy hiányoznak ezek az egyedi esetek, jobb, ha a felhasználói interakcióhoz hasonló osztályozót keres, nem pedig egyéni hibakódokat.

Előfordulhat, hogy vissza kell térnie AcquireTokenInteractive-hez, és meg kell adnia a AcquireTokenSilent hívás által igényelt igényérvényesítési kihívásokat. Ez biztosítja az interaktív kérés hatékony kezelését.

Következő lépések

  • Last updated on