API védelem

Amikor fejlesztőként védi az API-t, a hitelesítésre összpontosít. Az erőforrás API-jának meghívásához az alkalmazásoknak be kell szereznie az alkalmazásengedélyt. Az erőforrás kikényszeríti az engedélyezést. Ebben a cikkben elsajátíthatja a zéró megbízhatósági célok eléréséhez szükséges ajánlott eljárásokat. Leírja, hogyan védheti meg az API-t regisztrációval, engedély- és hozzájárulásdefinícióval és hozzáférés-kényszerítéssel.

A védett API regisztrálása

Ha az API-t a Microsoft Entra-azonosítóval (Microsoft Entra ID) szeretné védeni, regisztrálja az API-t. Ezután kezelheti a regisztrált API-kat. A Microsoft Entra ID-ban az API olyan alkalmazás, amely meghatározott alkalmazásregisztrációs beállításokkal rendelkezik, amelyek erőforrásként vagy API-ként határozzák meg, amelyhez egy másik alkalmazás hozzáférhet. A Microsoft Entra felügyeleti központjában, a Microsoft Identity Developerben az alkalmazásregisztrációk olyan API-k, amelyek a bérlőben üzleti API-kként vagy a Microsoft Entra ID által védett API-kkal rendelkező Szoftver-mint Servcie (SaaS) szolgáltatók szolgáltatásaiként találhatók.

A regisztráció során meghatározhatja, hogy az alkalmazások hogyan hivatkoznak az API-ra, valamint annak delegált és alkalmazásengedélyeire. Az alkalmazásregisztráció olyan megoldást jelenthet, amely ügyfélalkalmazásokkal és API-kkal is rendelkezik. Ebben a cikkben azonban azzal a forgatókönyvvel foglalkozunk, amelyben egy önálló erőforrás egy API-t tesz elérhetővé.

Az API általában nem végez hitelesítést, és nem kér közvetlenül engedélyezést. Az API érvényesít egy jogkivonatot, amelyet a hívó alkalmazás mutat be. Az API-k nem rendelkeznek interaktív bejelentkezésekkel, így nem kell regisztrálnia az olyan beállításokat, mint az átirányítási URI vagy az alkalmazás típusa. Az API-k a jogkivonataikat az őket meghívó alkalmazásokból szerzik be, nem pedig a Microsoft Entra ID rendszerrel való interakció révén. Webes API-k esetén használja az OAuth2 hozzáférési jogkivonatokat az engedélyezéshez. A webes API-k érvényesítik a tulajdonosi jogkivonatokat a hívók engedélyezéséhez. Ne fogadjon el azonosító jogkivonatokat engedélyigazolásként.

Alapértelmezés szerint a Microsoft Entra ID hozzáadja az új alkalmazásregisztrációk API-engedélyeihez a User.Read elemet. Ezt az engedélyt a legtöbb webes API-hoz eltávolítja. A Microsoft Entra ID csak akkor igényel API-engedélyeket, ha egy API másik API-t hív meg. Ha az API nem hív meg egy másik API-t, távolítsa el az User.Read engedélyt az API regisztrálásakor.

Az API-hoz való hozzáféréshez szükséges ügyfélalkalmazásoknak egyedi azonosítóra van szükségük az API-hoz, más néven az alkalmazásazonosító URI-hoz, és engedélyt kérnek az API meghívásához. Az alkalmazásazonosító URI-jának minden Microsoft Entra-bérlőben egyedinek kell lennie. Használhatja api://<clientId> (az alapértelmezett javaslat a portálon), ahol <clientId> a regisztrált API alkalmazásazonosítója található.

Ha felhasználóbarátabb nevet szeretne adni az API-t hívó fejlesztőknek, használhatja az API-címét az alkalmazásazonosító URI-jaként. Használhat például https://API.yourdomain.com a Microsoft Entra-bérlőben, amennyiben yourdomain.com egy konfigurált közzétevő tartomány. A Microsoft ellenőrzi, hogy Ön rendelkezik-e a tartomány tulajdonjogával, így ön használhatja azt az API egyedi azonosítójaként. Ezen a címen nem kell kóddal rendelkeznie. Az API bárhol lehet, ahol szeretné, de ajánlott az API címét az Alkalmazásazonosító URI-ként használni https.

Delegált engedélyek definiálása minimális jogosultsággal

Ha a felhasználókat használó alkalmazások meghívják az API-t, adjon meg legalább egy delegált engedélyt (lásd: Hatókör hozzáadása az alkalmazásregisztrációhoz API közzététele).

A szervezeti adattárakhoz hozzáférést biztosító API-k felhívhatják a figyelmet a rossz szereplőkre, akik hozzá szeretnének férni az adatokhoz. Ahelyett, hogy csak egy delegált engedéllyel rendelkezik, úgy tervezheti meg az engedélyeket, hogy a minimális jogosultsági hozzáférés nulla megbízhatósági elvét szem előtt tartsa. Később nehéz lehet a legkevésbé kiemelt modellbe bekerülni, ha az összes ügyfélalkalmazás teljes jogosultsági hozzáféréssel kezdődik.

A fejlesztők gyakran egyetlen engedély, például a hozzáférés felhasználóként vagy felhasználói megszemélyesítésként való használatának mintájába esnek (ez egy gyakran technikailag pontatlan kifejezés). Az ilyen engedélyek csak teljes jogosultsági szintű hozzáférést biztosítanak az API-hoz.

Deklarálja a minimális jogosultsági hatóköröket, hogy az alkalmazások ne sérüljenek meg, és ne használják fel olyan feladat végrehajtására, amelyet soha nem tervezett. Definiálja a több hatókört az API-engedélyekben. Különítse el például a hatóköröket az adatok olvasására és frissítésére, és fontolja meg a csak olvasási engedélyek biztosítását. Az írási hozzáférés jogosultságokat tartalmaz a létrehozási, frissítési és törlési műveletekhez. Az ügyfélnek soha nem kell írási hozzáférést kérnie csak olvasási adatokhoz.

Fontolja meg a standard és teljes hozzáférési engedélyeket, ha az API bizalmas adatokkal dolgozik. Korlátozza a bizalmas tulajdonságokat, hogy egy szabványos engedély ne engedélyezze a hozzáférést (például Resource.Read). Ezután implementáljon egy teljes hozzáférési engedélyt (például Resource.ReadFull), amely tulajdonságokat és bizalmas információkat ad vissza.

Mindig értékelje ki a kért engedélyeket, hogy a feladat elvégzéséhez a legkevésbé kiemelt csoportot keresse. Kerülje a magasabb jogosultsági engedélyek kérését. Ehelyett hozzon létre egy egyéni engedélyt az egyes alapvető forgatókönyvekhez. Erre a megközelítésre jó példákért tekintse meg a Microsoft Graph engedélyeinek hivatkozását . Keresse meg és használja a megfelelő számú engedélyt az igényeinek megfelelően.

A hatókördefiníciók részeként döntse el, hogy az adott hatókörrel végrehajtható művelettartományhoz rendszergazdai hozzájárulásra van-e szükség.

API-tervezőként útmutatást adhat arra vonatkozóan, hogy mely hatókörök igényelhetnek biztonságosan csak felhasználói hozzájárulást. A bérlők rendszergazdái azonban úgy is beállíthatják a bérlőt, hogy minden engedély opcionálisan rendszergazdai hozzájárulást igényeljen. Ha rendszergazdai hozzájárulást igénylő hatókört határoz meg, az engedélyhez mindig rendszergazdai hozzájárulás szükséges.

Amikor felhasználó vagy rendszergazdai hozzájárulás mellett dönt, az alábbi elsődleges szempontokat kell figyelembe vennie:

  • Azt, hogy az engedély mögötti műveletek tartománya több felhasználót is érint-e. Ha az engedély lehetővé teszi, hogy a felhasználó eldöntse, melyik alkalmazás férhet hozzá csak a saját adataihoz, akkor a felhasználói hozzájárulás megfelelő lehet. A felhasználó például beleegyezhet az előnyben részesített alkalmazás kiválasztásába e-mailben. Ha azonban az engedély mögötti műveletek több felhasználót is érintenek (például a többi felhasználó teljes felhasználói profiljának megtekintését), akkor ezt az engedélyt rendszergazdai hozzájárulást igénylőként kell meghatározni.

  • Az engedély mögötti műveletek köre széles hatókörrel rendelkezik-e. A széles hatókör például az, amikor egy engedély lehetővé teszi az alkalmazások számára, hogy egy bérlőben mindent megváltoztassanak, vagy olyan műveleteket hajtsanak végre, amelyek visszafordíthatatlanok lehetnek. A széles hatókör azt jelzi, hogy a felhasználói hozzájárulás helyett rendszergazdai hozzájárulásra van szükség.

Err a konzervatív oldalon, és megköveteli a rendszergazdai hozzájárulást, ha kétségei vannak. Világosan és tömören írja le a hozzájárulás következményeit a jogosultsági sztringekben. Tegyük fel, hogy a leírási sztringeket olvasó személy nem ismeri az API-kat vagy a terméket.

Kerülje az API-k meglévő engedélyekhez való hozzáadását oly módon, hogy az megváltoztatja az engedély szemantikáját. A meglévő engedélyek túlterhelése felhígítja azt az érvelést, amelyre az ügyfelek korábban engedélyt adtak.

Alkalmazásengedélyek definiálása

Ha nem használt alkalmazásokat hoz létre, nincs olyan felhasználója, akitől felhasználónevet és jelszót vagy többtényezős hitelesítést (MFA) kérhet. Ha a felhasználók nélküli alkalmazások (például számítási feladatok, szolgáltatások és démonok) meghívják az API-t, adja meg az API alkalmazásengedélyeit . Alkalmazásengedély megadásakor hatókörök használata helyett használjon alkalmazásszerepkört .

A delegált engedélyekhez hasonlóan részletes alkalmazásengedélyeket is biztosít, hogy az API-t meghívó számítási feladatok a lehető legkevesebb jogosultsági hozzáférést kövessék, és igazodjanak a nulla megbízhatósági alapelvekhez. Ne tegyen közzé csak egy alkalmazásszerepkört (alkalmazásengedélyt) és egy hatókört (delegált engedélyt), vagy tegye közzé az összes műveletet az egyes ügyfelek számára.

A munkaterhelések ügyfél-hitelesítő adatokkal hitelesítik magukat, és ezzel a .default hatókörrel kérnek jogkivonatot, ahogyan a következő példakód is bemutatja.

// With client credentials flows the scopes is ALWAYS of the shape "resource/.default", as the 
// application permissions need to be set statically (in the portal or by PowerShell), 
// and then granted by a tenant administrator
string[] scopes = new string[] { "https://kkaad.onmicrosoft.com/webapi/.default" };
 
AuthenticationResult result = null;
try
{
  result = await app.AcquireTokenForClient(scopes)
    .ExecuteAsync();
  Console.WriteLine("Token acquired \n");
}
catch (MsalServiceException ex) when (ex.Message.Contains("AADSTS70011"))
{
  // Invalid scope. The scope has to be of the form "https://resourceurl/.default"
  // Mitigation: change the scope to be as expected
  Console.WriteLine("Scope provided is not supported");
}

Az engedélyek rendszergazdai hozzájárulást igényelnek, ha nincs felhasználó az alkalmazás előtt, és ha az alkalmazásengedély széles körű műveleteket tesz lehetővé.

Hozzáférés kényszerítése

Győződjön meg arról, hogy az API-k érvényesítik és értelmezik a hozzáférési jogkivonatokat, amelyeket az alkalmazások mint viselői jogkivonatokat biztosítanak a https kérés autorizációs fejlécében. A jogkivonatok érvényesítésével, a metaadatok frissítésének kezelésével, valamint a hatókörök és szerepkörök kényszerítésével kényszerítheti ki a hozzáférést a következő szakaszokban leírtak szerint.

Tokenek érvényesítése

Miután az API megkapta a jogkivonatot, győződjön meg arról, hogy érvényesíti a jogkivonatot. Az ellenőrzés biztosítja, hogy a jogkivonat a megfelelő kiállítótól származik, és érintetlen, valamint módosítatlan. Ellenőrizze az aláírást, mert nem közvetlenül a Microsoft Entra ID-tól kapja meg a tokent, mint az azonosító tokenek esetében. Ellenőrizze az aláírást, miután az API jogkivonatot kapott egy nem megbízható forrástól a hálózaton.

Mivel ismert biztonsági rések vannak a JSON web tokenek aláírásának ellenőrzése körül, használjon egy jól karbantartott és bevált JSON web token érvényesítési kódtárat. A hitelesítési kódtárak (például a Microsoft.Identity.Web) a megfelelő lépéseket követik, és elhárítják az ismert biztonsági réseket.

Igény szerint bővítse a jogkivonat érvényesítését. A bérlőazonosító (tid) jogcím használatával korlátozhatja azokat a bérlőket, amelyekben az API jogkivonatot szerezhet be. A azp és appid jogcímeket használva szűrheti az API-t meghívni képes alkalmazásokat. Az objektumazonosító (oid) jogcím használatával szűkítse tovább az egyes felhasználók hozzáférését.

Metaadatok frissítésének kezelése

Mindig győződjön meg arról, hogy a jogkivonat-érvényesítési kódtár hatékonyan kezeli a szükséges metaadatokat. Ebben az esetben a metaadatok a nyilvános kulcsok, a titkos kulcsok párja, amelyeket a Microsoft a Microsoft Entra-jogkivonatok aláírására használ. Amikor a könyvtárak ellenőrzik ezeket a jogkivonatokat, egy ismert internetes címről szerzik meg a nyilvános aláíró kulcsok közzétett listáját. Győződjön meg arról, hogy az üzemeltetési környezet megfelelő időzítéssel rendelkezik a kulcsok beszerzéséhez.

A régebbi kódtárak például gyakran be voltak égetve a kódba, hogy ezeket a nyilvános aláírási kulcsokat 24 óránként frissítsék. Vegye figyelembe, amikor a Microsoft Entra ID-nek gyorsan el kell forgatnia ezeket a kulcsokat, és a letöltött kulcsok nem tartalmazzák az újonnan elforgatott kulcsokat. Előfordulhat, hogy az API egy napig offline állapotban van, amíg a metaadatok frissítési ciklusára vár. Hivatkozzon adott metaadatok frissítési útmutatóira annak biztosítása érdekében, hogy megfelelően szerezze be a metaadatokat. Ha tárat használ, győződjön meg arról, hogy ésszerű időn belül kezeli a metaadatokat.

Hatókörök és szerepkörök érvényesítése

A jogkivonat érvényesítése után az API megvizsgálja a jogkivonatban lévő jogcímeket, hogy megállapítsa, hogyan kell működnie.

A delegált engedélyjogkivonatok esetén az API vizsgálja meg a hatókör (scp) jogcímet, hogy ellenőrizze, mire adtak engedélyt az alkalmazásnak. Vizsgálja meg az objektumazonosító (oid) vagy a tárgykulcs (sub) jogcímeket, hogy láthassa azt a felhasználót, akinek a nevében az alkalmazás működik.

Ezután ellenőrizze az API-t, hogy a felhasználó is hozzáfér-e a kért művelethez. Ha az API szerepköröket határoz meg a felhasználókhoz és csoportokhoz való hozzárendeléshez, az API ellenőrizze a jogkivonatban található szerepkör-jogcímeket, és ennek megfelelően működjön. Az alkalmazásengedély-jogkivonatok nem rendelkeznek hatóköri (scp) jogcímekkel. Ehelyett kérje meg az API-t, hogy vizsgálja meg a szerepkör-jogcímet, és állapítsa meg, hogy melyik alkalmazásengedélyeket kapta meg a számítási feladat.

Miután az API érvényesítette a jogkivonatot és a hatóköröket, és feldolgozta az objektumazonosítót (oid), a tulajdonoskulcsot (sub) és a szerepkör-jogcímeket, az API visszaadhatja az eredményeket.

Következő lépések

  • Last updated on