Delegált engedélystratégia fejlesztése

Ez a cikk segítséget nyújt fejlesztőként az alkalmazások engedélyeinek kezeléséhez és az Teljes felügyelet alapelveinek megfelelő fejlesztéshez. Az erőforrásokhoz való hozzáférés engedélyezésének beszerzéséről szóló szakaszban leírtak szerint a delegált engedélyek delegált hozzáféréssel vannak használva, hogy lehetővé tegyék az alkalmazások számára, hogy a felhasználó nevében cselekedjenek, és csak azt érhessék el, amelyhez a felhasználó hozzáférhet. Az alkalmazásengedélyek közvetlen hozzáféréssel vannak használva, hogy az alkalmazás hozzáférhessen minden olyan adathoz, amelyhez az engedély társítva van. Csak a rendszergazdák és a szolgáltatásnevek tulajdonosai járulhatnak hozzá az alkalmazásengedélyekhez .

Az engedély- és hozzájárulási modellek elsősorban egy alkalmazásra vonatkoznak. Az engedély- és hozzájárulási folyamat nem szabályozza, hogy a felhasználó mit tehet. Ez szabályozza, hogy az alkalmazás milyen műveleteket hajthat végre.

Hivatkozzon a következő Venn-diagramra. Delegált engedélyekkel van egy metszet a felhasználó által engedélyezett műveletek és az alkalmazás által engedélyezett műveletek között. Ez a metszet az a tényleges engedély, amellyel az alkalmazás kötött. Ha delegált engedélyt használ, azt a hatályos engedélyek kötik.

"Venn-diagram leírása: Bal oldali körszöveg: Az alkalmazások hozzájárulást kapnak az alkalmazás működési tartományához. Jobb körszöveg: A felhasználók rendelkeznek a szervezet által felügyelt műveletekhez szükséges engedélyekkel. A körök szövegének metszete: Érvényes engedélyek: az alkalmazásengedélyek és a felhasználói képességek metszete."

Ha például az alkalmazás előtt vannak felhasználók, engedélyt kap a bérlő minden felhasználói profiljának frissítésére. Ez nem jelenti azt, hogy az alkalmazást futtató bárki frissítheti bárki más profilját. Ha a rendszergazda úgy dönt, hogy megadja az alkalmazást User.ReadWrite.All, akkor úgy vélik, hogy az alkalmazás helyesen cselekszik a felhasználói profilok frissítésekor. Előfordulhat, hogy az alkalmazás naplózza a módosításokat, és megfelelően védi az információkat. A rendszergazda értékítéletet hoz az alkalmazásról, nem a felhasználóról.

Minimális jogosultsági megközelítés

Az API-k összetettek lehetnek. Előfordulhat, hogy az egyszerű API-k nem sok műveletet hajtanak végre. Az olyan összetett API-k, mint a Microsoft Graph, számos olyan kérést foglalnak össze, amelyeket egy alkalmazás esetleg használni szeretne. Csak azért, mert az alkalmazásnak joga van az olvasáshoz, még nem jelenti azt, hogy joga van a frissítéshez. A Microsoft Graph például több ezer API-t kínál. Csak azért, mert rendelkezik engedéllyel a felhasználói profil olvasására, nincs oka annak, hogy az összes OneDrive-fájl törlésére is jogosult legyen.

Fejlesztőként a következőkre van szükség:

• tudja, hogy az alkalmazás mely API-kat hívja meg.
• megismerheti az API dokumentációját és az API által igényelt engedélyeket.
• a lehető legkisebb engedély használata a feladatok elvégzéséhez.

Az API-k gyakran biztosítanak hozzáférést a szervezeti adattárakhoz, és felhívják a támadók figyelmét, akik hozzá szeretnének férni az adatokhoz.

Értékelje ki a kért engedélyeket, és győződjön meg arról, hogy a feladat elvégzéséhez a legkevésbé kiemelt csoportot keresi. Kerülje a magasabb jogosultsági engedélyek kérését; ehelyett gondosan dolgozza át az API-k, például a Microsoft Graph által biztosított engedélyek nagy számát. Keresse meg és használja az igényeinek megfelelő minimális engedélyeket. Ha nem ír kódot a felhasználó profiljának frissítéséhez, nem fogja azt kérni az alkalmazáshoz. Ha csak felhasználókhoz és csoportokhoz fér hozzá, nem kér hozzáférést a címtárban lévő egyéb információkhoz. Nem kér engedélyt a felhasználói e-mailek kezelésére, ha nem ír olyan kódot, amely hozzáfér a felhasználói e-mailekhez.

Teljes felügyelet alkalmazásfejlesztésben:

• Az alkalmazás szándékának és igényeinek meghatározása.
• Győződjön meg arról, hogy a rossz szereplők nem tudják veszélyeztetni az alkalmazást, és nem kívánt módon használják az alkalmazást.
• Kérjen jóváhagyást, amelyben meghatározza a követelményeket (például olvassa el a felhasználó leveleit).

Felhasználói és bérlői rendszergazdai szerepkörök engedélyben és hozzájárulásban

Kapcsolatok, akik jóváhagyhatják a kéréseket, két kategóriába sorolhatók: azok a rendszergazdák, akik bármikor jóváhagyhatják az engedélykérelmeket, és azok a rendszeres felhasználók, akik nem rendszergazdák. A bérlői rendszergazdáknak azonban megvan a végső beleszólásuk a bérlőjükbe arról, hogy mely engedélyekhez van szükség rendszergazdai hozzájárulásra, és hogy a felhasználó milyen engedélyekhez járulhat hozzá.

Ha egy API-tervező rendszergazdai hozzájárulást igényel egy engedélyhez, az engedélyhez mindig rendszergazdai hozzájárulásra lesz szükség; a bérlői rendszergazda ezt nem tudja felülírni, és csak felhasználói hozzájárulást igényel.

Ha egy API-tervező felhasználói hozzájárulást igénylő engedélyeket határoz meg, az API-tervező felhasználói hozzájárulási javaslatait a bérlői rendszergazda felülírhatja. A bérlői rendszergazdák ezt megtehetik egy "nagy kapcsolóval" a bérlőben: mindenhez rendszergazdai hozzájárulásra van szükség. A felhasználói hozzájárulást részletesebben is felülírhatják az engedély- és hozzájáruláskezeléssel. Engedélyezhetik például, hogy a felhasználók hozzájáruljanak az ellenőrzött közzétevőktől érkező felhasználói hozzájárulási kérelmekhez, más közzétevőktől azonban nem. Egy másik példában engedélyezhetik User.Read , hogy bejelentkezhessenek a felhasználóba, és elolvashassák a profiljukat, de rendszergazdai hozzájárulást igényelhetnek azokhoz az alkalmazásokhoz, amelyek engedélyt kérnek a levelezéshez vagy a fájlokhoz.

Az API-tervezők javaslatokat tesznek, de a bérlői rendszergazdák rendelkeznek a végső mondanivalóval. Ezért fejlesztőként nem mindig fogja tudni, hogy az alkalmazás mikor igényel rendszergazdai hozzájárulást. Jó ezt megtervezni és megtervezni, de ne feledje, hogy jogkivonat-kérés esetén bármilyen okból megtagadható. A kódban türelmesen kell kezelnie, hogy nem kap-e jogkivonatot, mert azok a bérlői rendszergazdák, amelyekben az ügyfelek vagy a felhasználók futtatják az alkalmazást, eldöntik, hogy mikor igényelnek rendszergazdai hozzájárulást az engedélyek.

Példa JavaScript MSAL használatával

A példában szereplő hitelesítéshez a JavaScript Microsoft Authentication Library (MSAL) használatával kell bejelentkeznie a felhasználóba egy egyetlenoldalas alkalmazásban (SPA), ahol az alkalmazáslogika a böngészőből fut.

A kapcsolódó rövid útmutatóból letölthet és futtathat egy kódmintát. Bemutatja, hogy egy JavaScript egyoldalas alkalmazás (SPA) hogyan tud bejelentkezni a felhasználókba, és hogyan hívhatja meg a Microsoft Graphot az engedélyezési kódfolyamattal a Code Exchange-hez készült Proof Key (PKCE) használatával. A kódminta bemutatja, hogyan kérhet le hozzáférési jogkivonatot a Microsoft Graph API vagy bármely webes API meghívásához.

Ahogy az alábbi példakódban látható, nyilvános ügyfelet fog példányosítani, mert egy teljes mértékben a böngészőben futó alkalmazásnak nyilvános ügyfélnek kell lennie. Ha a kód a böngészőben van, a felhasználó az alkalmazás belső elemeire is ráteheti a kezét.

// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication(msalConfig);

Ezután az MSAL-kódtárat fogja használni. Az MSAL JavaScriptben van egy adott API, a bejelentkezéshez. A böngészőben két API van, amelyek bizonyos képességeket használnak. Az egyik, hogy előugró felülettel jelentkezzen be; A másik az, hogy böngészőátirányítási felülettel jelentkezik be.

Az alábbi kódpéldában látható módon a bejelentkezési előugró ablak kezeli a felhasználó által a függvény meghívásával végrehajtandó hitelesítést signIn .

function signIn() {

    /**
     * You can pass a custom request object below. This will override the initial configuration. For more information, visit:
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/request-response-object.md#request
     */

    myMSALObj.loginPopup(loginRequest)
        .then(handleResponse)
        .catch(error => {
            console.error(error);
        });
}

Az alkalmazás információkat kaphat a felhasználóról, például megjelenítendő nevét vagy felhasználói azonosítóját. Ezután az alkalmazásnak engedélyt kell adnia a felhasználó teljes profiljának a Microsoft Graphból való olvasásához egy olyan minta követésével, amelyet az MSAL-kódtárakban fog használni.

Ahogy az alábbi példakódban látható, az alkalmazás megkísérli lekérni az engedélyezést hívással AcquireTokenSilent. Ha a Microsoft Entra-azonosító anélkül tudja kiadni a jogkivonatot, hogy nem lép kapcsolatba a felhasználóval, akkor AcquireTokenSilent azt a jogkivonatot adja vissza, amelyet az alkalmazásnak a felhasználó nevében el kell érnie a Microsoft Graph-hoz.

function getTokenPopup(request) {

    /**
     * See here for more info on account retrieval: 
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-common/docs/Accounts.md
     */
    request.account = myMSALObj.getAccountByUsername(username);
    
    return myMSALObj.`AcquireTokenSilent`(request)
        .catch(error => {
            console.warn("silent token acquisition fails. acquiring token using popup");
            if (error instanceof msal.InteractionRequiredAuthError) {
                // fallback to interaction when silent call fails
                return myMSALObj.`AcquireTokenPopup`(request)
                    .then(tokenResponse => {
                        console.log(tokenResponse);
                        return tokenResponse;
                    }).catch(error => {
                        console.error(error);
                    });
            } else {
                console.warn(error);
            }
    });
}

A Microsoft Entra-azonosító azonban gyakran nem tudja kiadni a jogkivonatot a felhasználóval való interakció nélkül (például a felhasználó módosította a jelszavát, vagy nem adott hozzájárulást). Ezért hibaüzenetet küld vissza az alkalmazásnak, AcquireTokenSilent amelyhez felhasználói beavatkozás szükséges. Amikor az alkalmazás megkapja a hibát, vissza fog esni a híváshoz AcquireTokenPopup.

Ezen a ponton a Microsoft Entra-azonosító beszélgetésbe fog lépni a felhasználóval, hogy hitelesíthessék a felhasználót, és engedélyezhessék az alkalmazás számára, hogy a felhasználó nevében járjon el (például MFA-t hajtson végre, adja meg a jelszavát, adja meg a hozzájárulást). Ezután az alkalmazás megkapja a továbblépéshez szükséges jogkivonatot.

A vállalat Teljes felügyelet felé vezető útjának elsődleges lépése, hogy a felhasználói azonosító és jelszó helyett erősebb hitelesítési módszereket vezessen be. A fent ismertetett példakód teljes mértékben lehetővé teszi a vállalat számára, hogy a vállalat által választott erősebb hitelesítési módszerre váltson. Például többtényezős hitelesítés, teljes jelszó nélküli, FIDO2 kulccsal, a Microsoft Authenticator használatával.

Következő lépések

• Az erőforrások elérésére vonatkozó engedélyek beszerzése segít megérteni, hogyan biztosíthatja a legjobban Teljes felügyelet az alkalmazás erőforrás-hozzáférési engedélyeinek beszerzésekor.
• Az alkalmazásengedélyezési stratégia fejlesztése segít eldönteni, hogy az alkalmazásengedélyek milyen megközelítést alkalmaznak a hitelesítő adatok kezelésére.
• A jogkivonatok testreszabása ismerteti a Microsoft Entra-jogkivonatokban kapott információkat, valamint azt, hogy hogyan szabhatja testre a jogkivonatokat a rugalmasság és a szabályozás javítása érdekében, miközben a minimális jogosultsággal rendelkező, az alkalmazás zéró megbízhatósági biztonságát növeli.
• A csoportjogcímek és alkalmazásszerepkörök jogkivonatokban való konfigurálása bemutatja, hogyan konfigurálhatja alkalmazásait alkalmazásszerepkör-definíciókkal, és hogyan rendelhet hozzá biztonsági csoportokat az alkalmazásszerepkörökhöz a rugalmasság és az ellenőrzés javítása érdekében, miközben a minimális jogosultsággal rendelkező alkalmazásmegbízhatóság nélküli biztonság növelése érdekében.
• Az API Protection ismerteti az API regisztrációval, engedélyek és hozzájárulások meghatározásával, valamint a hozzáférés kényszerítésével kapcsolatos ajánlott eljárásokat a Teljes felügyelet célok elérése érdekében.
• Ha egy API-t egy másik API-ból hív meg, azzal biztosíthatja, hogy Teljes felügyelet, ha egy olyan API-val rendelkezik, amelyet egy másik API-nak kell meghívnia, és biztonságosan fejlesztenie kell az alkalmazást, amikor egy felhasználó nevében dolgozik.
• Az ajánlott engedélyezési eljárások segítségével implementálhatja a legjobb engedélyezési, engedély- és hozzájárulási modelleket az alkalmazásokhoz.
• Használjon Teljes felügyelet identitás- és hozzáférés-kezelési fejlesztési ajánlott eljárásokat az alkalmazásfejlesztési életciklusban a biztonságos alkalmazások létrehozásához.