Felhasználók hitelesítése a Zero Trust keretrendszerhez

Ez a cikk fejlesztőként segít elsajátítani az alkalmazásfelhasználók hitelesítésének ajánlott eljárásait a Zero Trust alkalmazásfejlesztésben. Az alkalmazás biztonságát mindig a minimális jogosultság zéró megbízhatósági elveivel fokozza , és explicit módon ellenőrizze.

Azonosító tokenek a felhasználói hitelesítésben

Amikor szükség van arra, hogy a felhasználó hitelesítést végezzen az alkalmazásban, a felhasználónév és jelszó megadása helyett az alkalmazás kérhet egy azonossági (ID) tokent. A felhasználók Microsoft identitásplatformon keresztüli hitelesítése elkerüli azokat a biztonsági kockázatokat, amelyek akkor merülnek fel, amikor az alkalmazás megőrzi a felhasználói hitelesítő adatokat. Ha azonosító jogkivonatokat kér, és egy rosszindulatú szereplő feltöri vagy kompromittálja az alkalmazást, az alkalmazásban nincsenek felhasználónevek és hozzájuk tartozó jelszavak.

A Microsoft identitásplatform azonosító tokenje az OpenID Connect (OIDC) szabvány része, amely az ID tokeneket JSON web tokenek (JWT) formájában határozza meg. A JWT hosszú sztring három összetevőből áll:

1. Fejléc állítások. Az azonosító jogkivonatokban található fejlécjogcímek közé tartozik typ a (típusjogkivonat), alg (a jogkivonat aláírására szolgáló algoritmus) és kid (a nyilvános kulcs ujjlenyomata a jogkivonat aláírásának ellenőrzéséhez).
2. Payload követelések. Az adatállomány vagy törzs (a JSON-webes jogkivonat középső része) névattribútum-párok sorozatát tartalmazza. A szabvány megköveteli, hogy legyen egy igény, amely a iss (kiállító neve) az alkalmazás felé irányul, amelyiknek a token kiadásra került (a aud, vagyis a célközönség igény).
3. Aláírás. A Microsoft Entra ID létrehozza azt a jogkivonat-aláírást, amellyel az alkalmazások ellenőrizhetik, hogy a jogkivonat nincs-e módosítva, és ön megbízhat benne.

Az alábbi példa egy azonosító tokenre a felhasználó adatait mutatja, és igazolja az alkalmazás használatához szükséges hitelesítést.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "1LTMzakihiRla_8z2BEJVXeWMqo"
}.
{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/3338040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
}.
.[Signature]

Azonosító jogkivonatok a hozzáférés-kezelésben

Az alkalmazás (ügyfél) azonosítójának fogadásához regisztrálja az alkalmazást a Microsoft identitásplatformon. Amikor olyan célközönség-jogcímet (aud) kap, amely megfelel az alkalmazás ügyfélazonosítójának, a jogkivonatban szereplő azonosított felhasználó hitelesítette magát az alkalmazás számára. A rendszergazdák engedélyezhetik, hogy a bérlő összes felhasználója használja az alkalmazást. Engedélyezhetik, hogy egy olyan csoport, amelynek a felhasználó tagja, használja az alkalmazást.

Ha olyan tokent kap, amelynek adatalanya eltér az alkalmazás ügyfélazonosítójától, azonnal utasítsa el a tokent. A felhasználót nem hitelesíti az alkalmazás, mert bejelentkezett egy másik alkalmazásba. Mindig győződjön meg arról, hogy a felhasználó rendelkezik engedéllyel az alkalmazás használatára.

Ezek a jogcímadatok fontosak a felhasználói hitelesítésben:

• A JSON web token érvényes, amíg le nem jár. A exp (lejárati) jogcím jelzi, hogy mikor jár le a token. Ha az aktuális idő az exp igényben szereplő idő előtt van, a token érvényes.
• Ne tekintse a felhasználót hitelesítettnek a nbf (nem előtte) jogcímben megadott időpont előtt. A token nbf és exp időpontjai határozzák meg a jogkivonat érvényes élettartamát. Ha a lejárati idő közelgő, győződjön meg arról, hogy új azonosító jogkivonatot kap.
• A sub (tulajdonosi jogcím) egy alkalmazásfelhasználó egyedi azonosítója. Ugyanaz a felhasználó más sub jogcímekkel rendelkezik más alkalmazásokhoz. Ha olyan adatokat szeretne tárolni, amelyek felhasználóhoz rendelhetők, és meg akarja akadályozni, hogy a támadó ezt a társítást létrehozza, használja az alany jogcímet. Mivel nem teszi elérhetővé a felhasználó Microsoft Entra-identitását, ez a legszemélyesebb módja az adatok felhasználóhoz való társításának. A sub jogcím nem módosítható.
• Ha több alkalmazás adatait szeretné megosztani, használja a bérlőazonosító (tid) és az objektumazonosító (oid) jogcímek kombinációját, amelyek egyediek a felhasználó számára. A kombinált bérlőazonosító és objektumazonosító nem módosítható.
• Nem számít, mi történik az egyén identitásával, a sub, oidés tid a jogcímek nem módosíthatók. A felhasználóval kapcsolatos bármi megváltozhat, és továbbra is azonosítani tudja a felhasználót az alany vagy az egyesített tid és oid jogcímek alapján.

Hitelesítés OIDC-vel

A felhasználói hitelesítés bemutatásához tekintsük át azokat az alkalmazásokat, amelyek OIDC-t használnak a felhasználó hitelesítéséhez. Ugyanezek az elvek vonatkoznak a Security Assertion Markup Language (SAML) vagy a WS-Federation nyelvet használó alkalmazásokra is.

Az alkalmazás hitelesíti a felhasználót, amikor a Microsoft Identitásplatformról azonosító tokent kér. Ezt a lépést kihagyják a számítási feladatok (olyan alkalmazások, amelyekben nincsenek felhasználók, hanem inkább szolgáltatásokként, háttérfolyamatokként, démonokként futnak).

Először mindig észrevétlenül kérje ezt a tokent. Ha csendben szeretne jogkivonatot beszerezni a Microsoft Authentication Libraries (MSAL) segítségével, az alkalmazás a metódussal AcquireTokenSilent kezdhet. Ha az alkalmazás anélkül képes hitelesítésre, hogy megzavarná a felhasználót, megkapja a kért azonosító tokent.

Ha a Microsoft Identitásplatform nem tudja befejezni a kérést a felhasználóval való interakció nélkül, akkor az alkalmazásnak vissza kell esnie az MSAL AcquireTokenInteractive metódusra. A token interaktív beszerzéséhez hajtsa végre a kérést úgy, hogy megnyit egy webes felületet a https://login.microsoftonline.com tartomány egy címére.

Ezen a webes felületen a felhasználó privát beszélgetést folytat a Microsoft Identity Platformmal. Az alkalmazás nem tekinti meg ezt a beszélgetést, és nem is rendelkezik a beszélgetés irányításával. A Microsoft Identitásplatform kérhet felhasználói azonosítót és jelszót, többtényezős hitelesítést (MFA), jelszó nélküli hitelesítést vagy más hitelesítési beavatkozást, amelyet a rendszergazda vagy a felhasználó konfigurált.

Az alkalmazás egy azonosítót kap, miután a felhasználó végrehajtotta a szükséges hitelesítési lépéseket. Amikor az alkalmazás megkapja a jogkivonatot, biztos lehet benne, hogy az Microsoft identity platform hitelesítette a felhasználót. Ha az alkalmazás nem kap azonosító tokent, a Microsoft identitásplatform nem hitelesítette a felhasználót. Ne engedélyezze a hitelesítés nélküli felhasználók számára, hogy az alkalmazás biztonságos területeire lépjenek.

Ajánlott, hogy az alkalmazások munkamenetet hozzanak létre egy felhasználó számára, miután megkapják az azonosító jogkivonatot a Microsoft Entra ID-től. Az azonosító jogkivonatban, amelyet az alkalmazás kap, egy lejárati (exp) jogcím található Unix időbélyeggel. Ez az időbélyeg azt a lejárati időt adja meg, amelyre az alkalmazásnak nem szabad elfogadnia a JWT-t feldolgozásra. Használja ezt a token lejárati idejét a felhasználói munkamenetek élettartamának irányításához. A exp jogcím kulcsfontosságú szerepet játszik abban, hogy egy kifejezetten ellenőrzött felhasználó a megfelelő jogosultsággal és a megfelelő ideig maradjon az alkalmazás környezetében.

Egyszeri bejelentkezés támogatás

Az egyszeri bejelentkezési (SSO) hitelesítés lehetővé teszi a felhasználók számára, hogy egy hitelesítő adatokkal jelentkezzenek be több független szoftverrendszerbe. Az egyszeri bejelentkezés lehetővé teszi, hogy az alkalmazásfejlesztők ne követelik meg, hogy egy felhasználó külön-külön és ismétlődően jelentkezzen be minden alkalmazásba. Az egyszeri bejelentkezés lényege, hogy a fejlesztők biztosítják, hogy a felhasználó eszközén található összes alkalmazás megossza a felhasználót hitelesíteni hivatott webes felületet. Az olyan webes felületen található összetevők, mint a munkamenet-állapot és a cookie-k, a sikeres hitelesítés után az egyszeri bejelentkezést irányítják.

Az alábbi ábrán látható módon a megosztott webes felületek legegyszerűbb használati esete egy webböngészőben futó alkalmazás (például Microsoft Edge, Google Chrome, Firefox, Safari). A böngészőlapok megosztják az egyszeri bejelentkezés (SSO) állapotát.

Diagram címe: Webböngésző – a legegyszerűbb eset. A diagram tetején egy Microsoft Entra ID ikont tartalmazó felhőalakzat jelenik meg. A felhőalakzat alatt egy doboz látható. A felhőalakzat és a doboz összekapcsolása egy vonal, amelynek mindkét végén nyíl látható. A mezőfelirat a következő: "Bejelentkezés megtartása, SSO-állapot cookie-k mentése a meghívások között". A dobozon belül, a bal oldalon, egy ikon, amely úgy néz ki, mint egy cookie. A cookie alatt a "felhasználóval folytatott privát beszélgetés" felirat látható. A felirat alatt egy ikon látható, amely a felhasználót jelöli. A három összetevő bal oldalán, a dobozon belül egy másik doboz található. A belső doboz címkéje a "Tabs". A címke alatt négy négyzetes mező látható, amelyek a böngészőablakokat jelölik a lapokban.

A Microsoft Identitásplatform egy adott böngészőben kezeli az egyszeri bejelentkezés állapotát, kivéve, ha a felhasználó különböző böngészőket nyit meg ugyanazon az eszközön. Windows 10 és újabb rendszereken a Microsoft Identitásplatform natív módon támogatja a microsoft edge böngészős egyszeri bejelentkezést. Amikor a felhasználó bejelentkezett a Windowsba, a Google Chrome-ban (a Windows 10-fiókbővítményen keresztül) és a Mozilla Firefox v91+ böngészőben (böngészőbeállításon keresztül) lévő szállások lehetővé teszik, hogy minden böngésző megossza a Windows SSO-állapotát.

Az alábbi ábrán látható módon a natív alkalmazáshasználati eset bonyolultabb.

Diagram címe: Natív alkalmazások – beágyazott böngészők – nincs egyszeri bejelentkezés. A diagram tetején egy Microsoft Entra ID ikont tartalmazó felhőalakzat jelenik meg. A diagram alján négy vízszintesen elterülő doboz látható. Az egyes dobozok jobb alsó sarkában egy felhasználót jelképező ikon látható. Az egyes mezőkben a böngészőablakok ábrázolása látható, beleértve a cookie ikont és a földgömb ikont. Mindegyik négy dobozt egy vonal köti össze a felhő alakzattal, amelynek mindkét végén nyíl van.

Hitelesítési közvetítő megközelítése

Gyakori példa, hogy minden natív alkalmazásnak saját beágyazott WebView-jával kell rendelkeznie, amely megakadályozza, hogy részt vegyen az egyszeri bejelentkezésben. Ennek a forgatókönyvnek a megoldásához a Microsoft Entra ID hitelesítési közvetítőt (hitelesítésközvetítőt) használ natív alkalmazásokhoz az alábbi ábrán látható módon.

Diagram címe: Hitelesítési közvetítő megközelítés. A diagram tetején egy Microsoft Entra ID ikont tartalmazó felhőalakzat jelenik meg. A felhőalakzat alatt egy téglalap alakzat látható, amelynek a címkéje Auth Broker. A téglalap alakzat egy cookie ikont és egy földgömb ikont tartalmaz. A felhő alakzatot és a téglalap alakzatot egy vonal kapcsolja össze, mindkét végén nyíllal. A diagram alján négy vízszintesen elterülő doboz látható. Az egyes dobozok jobb alsó sarkában egy felhasználót jelképező ikon látható. Az egyes dobozok ikonjai a böngészőablakokat jelölik. A négy doboz mindegyike egy vonallal van összekötve a téglalap alakzattal, amelynek mindkét végén nyíl található.

Ha egy hitelesítési bróker van érvényben, az alkalmazások hitelesítési kéréseket küldenek a brókernek, nem pedig közvetlenül a Microsoft Identitásplatformra. Ily módon a közvetítő lesz az eszköz összes hitelesítésének megosztott felülete.

A megosztott felület biztosítása mellett a hitelesítési közvetítő más előnyöket is biztosít. A Zero Trust megközelítés bevezetésekor előfordulhat, hogy a vállalatok csak vállalati felügyelt eszközökről szeretnének alkalmazásokat futtatni. A nagyvállalati eszközök felügyeletére példa a teljes mobil Eszközkezelés (MDM) és az olyan forgatókönyvek, amelyekben a felhasználók a mobilalkalmazás-kezelésben (MAM) részt vevő saját eszközeiket használják.

A mögöttes operációs rendszerek (OS) kialakításuk szerint elkülönítik a böngészőket. A fejlesztőknek szorosabb kapcsolatra van szükségük az operációs rendszerrel az eszköz részleteihez való teljes hozzáféréshez. A Windowsban a hitelesítési közvetítő a Windows Web Account Manager (WAM). Más eszközökön a hitelesítési közvetítő a Microsoft Authenticator alkalmazás (iOS vagy Android rendszerű eszközök esetén) vagy a Céges portál alkalmazás (Android rendszerű eszközök esetén). Az alkalmazások az MSAL használatával férnek hozzá a hitelesítési közvetítőhöz. Windows rendszerben az alkalmazások MSAL nélkül is hozzáférhetnek a WAM-hez. Az MSAL azonban a legegyszerűbb módja annak, hogy az alkalmazások elérhessék a hitelesítési közvetítőt (különösen azokat az alkalmazásokat, amelyek nem Univerzális Windows-platform alkalmazásokat).

A hitelesítésszervezők a Microsoft Entra-azonosítóval kombinálva használják az elsődleges frissítési jogkivonatokat (PRT), amelyek csökkentik a felhasználók számára a többszöri hitelesítés szükségességét. A PRT-k meg tudják állapítani, hogy a felhasználó felügyelt eszközön van-e. A Microsoft Entra ID számára hitelesítési közvetítőkre van szükség, mivel bevezeti a birtoklás igazolási tokeneket, amelyek biztonságosabbak, mint a ma általánosan használt hordozó tokenek.

Következő lépések

• A Microsoft Entra hozzáférési jogkivonatok hibaelhárítása: A hozzáférési jogkivonat ellenőrzése azt írja le, hogy a Microsoft Entra hozzáférési jogkivonat használatakor hogyan ellenőrizheti, hogy bizonyos mezők megfelelnek-e a rekordnak.
• Az alkalmazások hitelesítésének és engedélyezésének rugalmasságának növelése sorozat azokat az alkalmazásokat tárgyalja, amelyek a Microsoft identitásplatformot és a Microsoft Entra ID-t használják. Útmutatást tartalmaznak azokhoz az ügyfél- és szolgáltatásalkalmazásokhoz, amelyek a saját nevükben működő bejelentkezett felhasználói és démonalkalmazások nevében dolgoznak. A tokenek és az erőforrások hívásához szükséges ajánlott eljárásokat tartalmazzák.
• A jogkivonatok testreszabása a Microsoft Entra-jogkivonatokban kapott információkat és a jogkivonatok testreszabásának módját ismerteti.
• A csoportjogcímek és alkalmazásszerepkörök tokenekben való konfigurálása bemutatja, hogyan konfigurálhatja alkalmazásait alkalmazásszerepkör-definíciókkal, és hogyan rendelhet biztonsági csoportokat alkalmazásszerepkörökhöz.
• Az engedélyek és hozzájárulások révén identitást biztonságossá tevő alkalmazások létrehozása áttekintést nyújt az engedélyekről és az ajánlott eljárásokhoz való hozzáférésről.