API-k védelme

Ha fejlesztőként védi az API-t, a fókusz az engedélyezésen van. Az erőforrás API-jának meghívásához az alkalmazásoknak be kell szereznie az alkalmazásengedélyt. Magának az erőforrásnak kell kikényszerítenie az engedélyezést. Ebben a cikkben megismerheti az API regisztráción, engedélyek és hozzájárulások meghatározásán, valamint a hozzáférés kényszerítésén keresztüli védelmének ajánlott eljárásait a Teljes felügyelet céljai eléréséhez.

A védett API regisztrálása

Ha az API-t Microsoft Entra-azonosítóval (Microsoft Entra ID) szeretné védeni, először regisztrálnia kell az API-t, majd 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 azt, amelyhez egy másik alkalmazás is hozzáférhet. A Microsoft Entra felügyeleti központban a Microsoft Identity Developer Alkalmazásregisztrációk olyan API-k, amelyek a bérlőben üzleti API-kként vagy olyan SaaS-szolgáltatók szolgáltatásaiként találhatók, amelyek a Microsoft Entra ID által védett API-kkal rendelkeznek.

A regisztráció során meghatározhatja, hogy az alkalmazások hogyan hivatkoznak majd 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 azt a forgatókönyvet fogjuk kezelni, amikor 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íti a hívó alkalmazás által bemutatott jogkivonatot. 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 az adott API-kat hívó alkalmazásokból szerzik be a jogkivonataikat, nem a Microsoft Entra-azonosítóval való interakcióval. 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 User.Read az új alkalmazásregisztrációk API-engedélyeit. Ezt az engedélyt a legtöbb webes API-hoz el fogja távolítani. 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 másik API-t, távolítsa el az engedélyt az User.Read API regisztrálásakor.

Szüksége lesz egy egyedi azonosítóra az API-hoz, más néven az alkalmazásazonosító URI-hoz, hogy az API-hoz hozzáférő ügyfélalkalmazások 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álhatja például a https://API.yourdomain.com Microsoft yourdomain.com Entra-bérlőben konfigurált közzétevői tartományt. 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 HTTPS-címét URI-ként használni.

Delegált engedélyek meghatározása minimális jogosultsággal

Ha az API-t felhasználókkal rendelkező alkalmazások fogják meghívni, legalább egy delegált engedélyt meg kell adnia (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 támadók figyelmét, akik hozzá szeretnének férni az adatokhoz. Ahelyett, hogy csak egy delegált engedéllyel rendelkezik, úgy tervezheti meg az engedélyeket, hogy figyelembe vegye a minimális jogosultsági hozzáférés Teljes felügyelet elvét. 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 a "felhasználói megszemélyesítés" (ez egy gyakori kifejezés, bár technikailag pontatlanok) használatával járnak. Az ilyen engedélyek csak teljes körű, kiemelt 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ától és frissítésétől, és fontolja meg az írásvédett engedélyek biztosítását. Az "Írási hozzáférés" magában foglalja a létrehozási, frissítési és törlési műveletekhez szükséges jogosultságokat. Az ügyfélnek soha nem kell írási hozzáférést kérnie csak olvasási adatokhoz.

Fontolja meg a "standard" és a "teljes" hozzáférési engedélyeket, amikor 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.

Felhasználói hozzájárulás és rendszergazdai hozzájárulás meghatározása

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ői rendszergazdák azonban konfigurálhatnak egy bérlőt, hogy minden engedélyhez rendszergazdai hozzájárulás szükséges. 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.

A felhasználói vagy rendszergazdai hozzájárulás kiválasztásakor két elsődleges szempontot kell figyelembe vennie:

1. 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 a felhasználó számára, hogy 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 más felhasználók teljes felhasználói profiljainak megtekintését), akkor ezt az engedélyt rendszergazdai hozzájárulást igénylőként kell meghatározni.

2. 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 meghatározása

Nem felhasználói alkalmazások létrehozásakor 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 az API-t felhasználók nélküli alkalmazások (például számítási feladatok, szolgáltatások és démonok) fogják meghívni, meg kell határoznia az API alkalmazásengedélyeit . Az alkalmazásengedélyek megadásakor hatókörök használata helyett egy alkalmazásszerepkört fog használni.

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ő legkisebb jogosultsági hozzáférést kövessék, és igazodjanak Teljes felügyelet alapelveihez. 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 számítási feladatok ügyfél-hitelesítő adatokkal hitelesítik magukat, és jogkivonatot kérnek az .default alábbi példakódban bemutatott hatókör használatával.

// 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 a HTTPS-kérelem engedélyezési fejlécében érvényesítik és értelmezik azokat a hozzáférési jogkivonatokat, amelyeket a hívó alkalmazás biztosít tulajdonosi jogkivonatként. 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.

Jogkivonatok érvényesítése

Miután az API megkapta a jogkivonatot, érvényesítenie kell a jogkivonatot. Az ellenőrzés biztosítja, hogy a jogkivonat a megfelelő kiállítótól származik, mint nem ellenőrzött és nem módosított. Ellenőrizze az aláírást, mert nem közvetlenül a Microsoft Entra-azonosítóból szerzi be a jogkivonatot, mint az azonosító jogkivonatokkal. 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 webes tokenek aláírásának ellenőrzése körül, használjon egy jól karbantartott és bevált standard jogkivonat-érvényesítési kódtárat. A hitelesítési kódtárak (például a Microsoft.Identity.Web vagy a Passport, ha csomópontot építenek) 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 jogcímekkel szűrheti appid az azp 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ódtárak érvényesítik ezeket a jogkivonatokat, egy jól ismert internetes címről kapják 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 időnként nehezen lettek kódban, hogy 24 óránként frissítsék ezeket a nyilvános aláírási kulcsokat. Vegye figyelembe, hogy a Microsoft Entra-azonosítónak gyorsan el kell forgatnia ezeket a kulcsokat, és a letöltött kulcsok nem tartalmazzák az új 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 kényszerítése

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

A delegált engedélyjogkivonatok esetében az API vizsgálja meg a hatókör (scp) jogcímet, és ellenőrizze, hogy az alkalmazás mit engedélyez. 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 definiált szerepköröket a felhasználókhoz és csoportokhoz való hozzárendeléshez, ellenőrizze az API-nak a jogkivonatban szereplő szerepkör-jogcímeket, és ennek megfelelően viselkedjen. Az alkalmazásengedély-jogkivonatok esetében nem lesz hatóköri (scp) jogcím. Ehelyett a szerepkör-jogcím vizsgálatával állapítsa meg az API-nak, hogy milyen alkalmazásengedélyeket kapott 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

• Példa a Microsoft identitás-jóváhagyási keretrendszer által védett API-ra, amely segít a minimális jogosultsági szintű alkalmazásengedélyezési stratégiák kialakításában a legjobb felhasználói élmény é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.
• 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 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.
• A rendszergazdai hozzájárulást igénylő engedélyek kérése azt az engedély- és hozzájárulási élményt ismerteti, amikor az alkalmazásengedélyek rendszergazdai hozzájárulást igényelnek.
• Ebben a rövid útmutatóban: Webes API védelme a Microsoft Identitásplatform segítségével, megtudhatja, hogyan védheti meg a ASP.NET webes API-t úgy, hogy csak engedélyezett fiókokra korlátozza az erőforrásaihoz való hozzáférést.
• Ebben az oktatóanyagban – Az API átalakítása és védelme az Azure API Managementben, megtudhatja, hogyan konfigurálhat általános szabályzatokat a technológiai veremadatok vagy az EREDETI URL-címek elrejtéséhez az API HTTP-válaszában.