Megosztás a következőn keresztül:

Javaslatok az OWASP API Security Top 10 fenyegetéseinek az API Management használatával történő csökkentésére

  • Cikk

A KÖVETKEZŐRE VONATKOZIK: Minden API Management-szint

Feljegyzés

Ez a cikk az OWASP API Security Top 10 2023-ra vonatkozó legújabb listájának megfelelően lett frissítve.

Az Open Web Application Security Project (OWASP) Foundation a közösség által vezetett nyílt forráskód szoftverprojektekkel, világszerte több száz fejezetben, több tízezer taggal és helyi és globális konferenciák szervezésével igyekszik javítani a szoftverbiztonságot.

Az OWASP API Security Project az API-k egyedi biztonsági réseinek és biztonsági kockázatainak megértésére és enyhítésére szolgáló stratégiákra és megoldásokra összpontosít. Ebben a cikkben az OWASP által a 2023-ban az Azure API Management használatával azonosított 10 API-fenyegetés enyhítésére vonatkozó legújabb javaslatokat ismertetjük.

Annak ellenére, hogy az API Management átfogó vezérlőket biztosít az API-biztonsághoz, más Microsoft-szolgáltatások kiegészítő funkciókat biztosítanak az OWASP API-fenyegetések észleléséhez vagy elleni védelemhez:

Hibás objektumszintű engedélyezés

A nem megfelelő szintű engedélyekkel védett API-objektumok sebezhetők lehetnek az adatszivárgásokkal és a gyenge objektumhozzáférési azonosítókon keresztül végzett jogosulatlan adatkezeléssel szemben. Egy támadó például kihasználhat egy egész szám objektumazonosítót, amely iterálható.

További információ a fenyegetésről: API1:2023 Hibás objektumszintű engedélyezés

Ajánlások

  • Az objektumszintű engedélyezés megvalósításának legjobb helye maga a háttér API. A háttérrendszerben a megfelelő engedélyezési döntéseket a kérelem (vagy objektum) szintjén lehet meghozni, adott esetben a tartományra és az API-ra vonatkozó logikával. Fontolja meg azokat a forgatókönyveket, amelyekben egy adott kérés eltérő részletességi szinteket adhat a válaszban a kérelmező engedélyétől és engedélyétől függően.

  • Ha egy jelenlegi sebezhető API nem módosítható a háttérrendszerben, akkor az API Management tartalékként használható. Példa:

    • Használjon egyéni szabályzatot az objektumszintű engedélyezés implementálásához, ha az nincs implementálva a háttérrendszerben.

    • Egyéni szabályzat implementálása az azonosítók leképezéséhez a kérésből a háttérrendszerbe és a háttérrendszerből az ügyfélbe, hogy a belső azonosítók ne legyennek közzétéve.

      Ezekben az esetekben az egyéni szabályzat lehet egy kereséssel (például szótárral) rendelkező szabályzatkifejezés , vagy integráció egy másik szolgáltatással a küldési kérelem szabályzatán keresztül.

  • GraphQL-forgatókönyvek esetén az elem használatával kényszerítse ki az objektumszintű engedélyezést a validate-graphql-request szabályzaton authorize keresztül.

Hibás hitelesítés

A webhelyek vagy API-k hitelesítési mechanizmusa különösen sebezhető, mert a névtelen felhasználók számára nyitva áll. A felhasználás megakadályozása érdekében védeni kell a hitelesítéshez szükséges eszközöket és végpontokat, beleértve az elfelejtett jelszót vagy a jelszófolyamatok alaphelyzetbe állítását.

További információ a fenyegetésről: API2:2023 Hibás hitelesítés

Ajánlások

Hibás objektumtulajdonság-szintű engedélyezés

A jó API-felület kialakítása megtévesztően kihívást jelent. Gyakran , különösen az örökölt API-k esetében, amelyek idővel fejlődtek, a kérelem- és válaszfelületek több adatmezőt tartalmaznak, mint amennyit a fogyasztó alkalmazások igényelnek, lehetővé téve az adatinjektálási támadásokat. A támadók a nem dokumentált felületeket is felfedezhetik. Ezek a biztonsági rések bizalmas adatokat adhatnak a támadónak.

További információ a fenyegetésről: API3:2023 Hibás objektumtulajdonság-szintű engedélyezés

Ajánlások

  • A biztonsági rés csökkentésének legjobb módszere annak biztosítása, hogy a háttér API-n definiált külső interfészek gondosan és ideális esetben az adatmegőrzéstől függetlenül legyenek megtervezve. Csak az API felhasználói által igényelt mezőket kell tartalmazniuk. Az API-kat gyakran felül kell vizsgálni, és az örökölt mezők elavultak, majd el kell távolítani őket.
  • Az API Managementben korrektúrák használatával felügyelheti a nem törhető módosításokat , például egy mező hozzáadását egy felülethez, és verziókkal implementálhatja a kompatibilitástörő módosításokat. A háttérfelületeket is verzióalapúnak kell lennie, amelyek általában eltérő életciklussal rendelkeznek, mint a fogyasztói API-k.
  • A külső API-felületek leválasztása a belső adatmegvalósításról. Kerülje az API-szerződések közvetlen kötését a háttérszolgáltatások adatszerződéseihez.
  • Ha nem lehet módosítani a háttérrendszer felületének kialakítását, és a túlzott adatok aggodalomra adnak okot, használja az API Management átalakítási szabályzatait a válasz hasznos adatainak újraírásához, valamint az adatok maszkolásához vagy szűréséhez. Az API Management tartalomérvényesítése XML- vagy JSON-sémával is használható a nem dokumentált tulajdonságokkal vagy helytelen értékekkel rendelkező válaszok blokkolásához. Távolítsa el például a szükségtelen JSON-tulajdonságokat egy választörzsből. A nem dokumentált tulajdonságokkal rendelkező kérések blokkolása csökkenti a támadásokat, míg a nem dokumentált tulajdonságokkal rendelkező válaszok blokkolása megnehezíti a lehetséges támadási vektorok visszafejtését. A valid-content szabályzat támogatja a megadott méretnél nagyobb válaszok blokkolását is.
  • Az érvényesítési-állapotkód-szabályzattal blokkolhatja az API-sémában nem definiált hibákat tartalmazó válaszokat.
  • Az érvényesítési fejlécszabályzattal letilthatja a sémában nem definiált vagy a séma definíciójának nem megfelelő fejlécekkel érkező válaszokat. Távolítsa el a nem kívánt fejléceket a set-header szabályzattal.
  • GraphQL-forgatókönyvek esetén a validate-graphql-request szabályzattal érvényesítheti a GraphQL-kéréseket, engedélyezheti a hozzáférést adott lekérdezési útvonalakhoz, és korlátozhatja a válasz méretét.

Korlátlan erőforrás-felhasználás

Az API-knak erőforrásokat kell futtatniuk, például memóriát vagy CPU-t, és tartalmazhatnak olyan alsóbb rétegbeli integrációkat, amelyek üzemeltetési költséget jelentenek (például kérelemalapú fizetéses szolgáltatások). A korlátok alkalmazása segíthet megvédeni az API-kat a túlzott erőforrás-használattól.

További információ a fenyegetésről: API4:2023 Korlátlan erőforrás-használat

Ajánlások

  • A sebességkorlátozás kulcsonkénti vagy sebességkorlátozási szabályzatok használatával rövidebb időkereteken is alkalmazhat szabályozást. Szigorúbb sebességkorlátozó szabályzatokat alkalmazhat a bizalmas végpontokra, például a jelszó-visszaállításra, a bejelentkezésre vagy a regisztrációs műveletekre, illetve a jelentős erőforrásokat használó végpontokra.
  • Kvótaalapú vagy kvótakorlátozó szabályzatokkal szabályozhatja az API-hívások vagy sávszélességek engedélyezett számát hosszabb időkeretek esetén.
  • Optimalizálja a teljesítményt a beépített gyorsítótárazással, ezáltal csökkentve a processzor, a memória és a hálózati erőforrások használatát bizonyos műveletekhez.
  • Érvényesítési szabályzatok alkalmazása.
    • max-size A kérések és válaszok maximális méretének kikényszerítéséhez használja az attribútumot a tartalomérvényesítési szabályzatban
    • Az API-specifikációban definiálhat sémákat és tulajdonságokat, például sztringhosszt vagy maximális tömbméretet. A kérések és válaszok sémáinak érvényesítéséhez használjon érvényesítési tartalmakat, érvényesítési paramétereket és érvényesítési fejléceket .
    • Használja a validate-graphql-request szabályzatot a GraphQL API-khoz, valamint konfiguráljon max-depth és max-size paramétereket.
    • Riasztások konfigurálása az Azure Monitorban az adatok felhasználók általi túlzott felhasználásához.
  • Generatív AI API-k esetén:
  • A háttérszolgáltatás válaszidejének minimalizálása. Minél tovább tart a háttérszolgáltatás megválaszolása, annál hosszabb ideig van használatban a kapcsolat az API Managementben, így csökken az adott időkeretben kiszolgálható kérelmek száma.
  • CORS-szabályzatot alkalmazva szabályozhatja azokat a webhelyeket, amelyek betöltik az API-val kiszolgált erőforrásokat. A túlzottan megengedő konfigurációk elkerülése érdekében ne használjon helyettesítő értékeket (*) a CORS-házirendben.
  • Bár az Azure platformszintű védelemmel és fokozott védelemmel rendelkezik az elosztott szolgáltatásmegtagadási (DDoS) támadások ellen, az API-k alkalmazásvédelmi (7. réteg) védelme továbbfejleszthető egy robotvédelmi szolgáltatás API Management előtti üzembe helyezésével – például Azure-alkalmazás Gateway, Azure Front Door vagy Azure DDoS Protection. Ha webalkalmazási tűzfalszabályzatot (WAF) használ az Azure-alkalmazás Gateway vagy az Azure Front Door használatával, fontolja meg a Microsoft_BotManagerRuleSet_1.0 használatát.

Hibás függvényszintű engedélyezés

A különböző hierarchiákkal, csoportokkal és szerepkörökkel rendelkező, összetett hozzáférés-vezérlési szabályzatok, valamint a felügyeleti és a reguláris függvények nem egyértelmű elkülönítése engedélyezési hibákhoz vezetnek. A problémák kihasználásával a támadók hozzáférést kapnak más felhasználók erőforrásaihoz vagy felügyeleti funkcióihoz.

További információ a fenyegetésről: API5:2023 Hibás függvényszintű engedélyezés

Ajánlások

  • Alapértelmezés szerint az API Managementben az összes API-végpontot előfizetési kulcsokkal vagy teljes API-szintű engedélyezési szabályzattal kell védeni. Szükség esetén adjon meg más engedélyezési szabályzatokat adott API-khoz vagy API-műveletekhez.
  • OAuth-jogkivonatok ellenőrzése szabályzatokkal.
    • A Microsoft Entra-jogkivonatok érvényesítéséhez használja az validate-azure-ad-token szabályzatot. Adja meg az összes szükséges jogcímet, és adott esetben adja meg az engedélyezett alkalmazásokat.
    • A Nem a Microsoft Entra által kibocsátott jogkivonatok érvényesítéséhez adjon meg egy validálási-jwt szabályzatot , és kényszerítse ki a szükséges jogkivonat-jogcímeket. Ha lehetséges, elévülési időt igényel.
    • Ha lehetséges, használjon titkosított jogkivonatokat, vagy listázz meghatározott alkalmazásokat a hozzáféréshez.
    • Az engedélyezés hiánya miatt elutasított kérelmek figyelése és áttekintése.
  • Az API-végpontok internetről való elrejtéséhez használjon Azure-beli virtuális hálózatot vagy Private Linket. További információ a virtuális hálózati lehetőségekről az API Management használatával.
  • Ne definiáljon helyettesítő API-műveleteket (azaz "catch-all" API-kat * elérési útként). Győződjön meg arról, hogy az API Management csak explicit módon definiált végpontokra irányuló kérelmeket szolgál ki, és a nem definiált végpontokra irányuló kéréseket a rendszer elutasítja.
  • Ne tegye közzé az előfizetést nem igénylő nyitott termékekkel rendelkező API-kat.
  • Ha az ügyfél IP-címei ismertek, ip-szűrési szabályzattal csak engedélyezett IP-címekről engedélyezze a forgalmat.
  • A validate-client-certificate szabályzat használatával kényszerítse ki, hogy az ügyfél által egy API Management-példánynak bemutatott tanúsítvány egyezik-e a megadott érvényesítési szabályokkal és jogcímekkel.

Bizalmas üzleti folyamatokhoz való korlátlan hozzáférés

Az API-k számos funkciót elérhetővé tehetnek a fogyasztó alkalmazás számára. Fontos, hogy az API-szerzők megértsék az API által biztosított üzleti folyamatokat és a kapcsolódó érzékenységet. Nagyobb a kockázata az üzletnek, ha a bizalmas folyamatokat feltáró API-k nem implementálnak megfelelő védelmet.

További információ a fenyegetésről: API6:2023 A bizalmas üzleti folyamatokhoz való korlátlan hozzáférés

Ajánlások

  • Az ügyfél ujjlenyomatai alapján csökkentheti vagy letilthatja a hozzáférést. Használja például a válasz-válasz szabályzatot a kiválasztási szabályzattal a fej nélküli böngészők forgalmának letiltásához a Felhasználó-Ügynök fejléc vagy más fejlécek konzisztenciája alapján.
  • Érvényesítési paraméterekkel kényszerítse ki, hogy a kérésfejlécek megfeleljenek az API-specifikációnak.
  • Ip-szűrőszabályzat használatával csak ismert IP-címekről érkező kéréseket engedélyezhet, vagy megtagadhatja a hozzáférést adott IP-címekről.
  • A belső API-k külső kapcsolatának korlátozásához használjon privát hálózati funkciókat.
  • A sebességkorlátozási kulcsonkénti szabályzattal korlátozhatja az API-használat kiugró értékeit a felhasználói identitás, az IP-cím vagy más érték alapján.
  • Front API Management Azure-alkalmazás Gateway vagy Azure DDoS Protection szolgáltatással a robotforgalom észleléséhez és letiltásához.

Kiszolgálóoldali kérelemhamisítás

A kiszolgálóoldali kérések hamisítási biztonsági rése akkor fordulhat elő, ha az API egy olyan URL-cím értéke alapján lekéri az alsóbb rétegbeli erőforrást, amelyet az API-hívó megfelelő ellenőrzési ellenőrzés nélkül átadott.

További információ a fenyegetésről: API7:2023 Kiszolgálóoldali kérelemhamisítás

Ajánlások

  • Ha lehetséges, ne használjon az ügyfél hasznos adataiban megadott URL-címeket, például a háttérbeli URL-címek, a küldési kérelem szabályzata vagy az újraírási URL-szabályzat paramétereiként.
  • Ha az API Management vagy a háttérszolgáltatások a kérelem hasznos adataiban megadott URL-címeket használják az üzleti logikához, definiálja és kényszerítse ki a gazdagépnevek, portok, médiatípusok vagy egyéb attribútumok korlátozott listáját az API Management szabályzataival, például a kiválasztott szabályzatokkal és szabályzatkifejezésekkel.
  • Adja meg az timeout attribútumot a továbbítási és küldési kérelmek szabályzataiban.
  • A kérés- és válaszadatok érvényesítése és tisztítása érvényesítési szabályzatokkal. Ha szükséges, a válasz feldolgozásához és a nyers adatok visszaadásának elkerüléséhez használja a set-body szabályzatot.
  • A kapcsolat korlátozásához használjon privát hálózatkezelést. Ha például az API-nak nem kell nyilvánosnak lennie, korlátozza az internetkapcsolatot a támadási felület csökkentése érdekében.

Biztonsági helytelen konfiguráció

A támadók megpróbálhatják kihasználni a biztonsági helytelen konfigurációs biztonsági réseket, például:

  • Hiányzó biztonsági megkeményedés
  • Szükségtelenül engedélyezett funkciók
  • A hálózati kapcsolatok szükségtelenül nyílnak meg az interneten
  • Gyenge protokollok vagy titkosítások használata

További információ a fenyegetésről: API8:2023 Biztonsági helytelen konfiguráció

Ajánlások

  • Az átjáró TLS-ének helyes konfigurálása. Ne használjon sebezhető protokollokat (például TLS 1.0, 1.1) vagy rejtjeleket.
  • Konfigurálja az API-kat úgy, hogy csak titkosított forgalmat fogadjanak el, például HTTPS- vagy WSS-protokollokkal. Ezt a beállítást az Azure Policy használatával naplózhatja és kényszerítheti.
  • Fontolja meg az API Management magánvégpont mögötti vagy belső módban üzembe helyezett virtuális hálózathoz való csatlakoztatását. A belső hálózatokban a hozzáférés szabályozható a magánhálózaton belül (tűzfalon vagy hálózati biztonsági csoportokon keresztül) és az internetről (fordított proxyn keresztül).
  • Azure API Management-szabályzatok használata:
    • Mindig örökölje a szülőszabályzatokat a <base> címkén keresztül.
    • Az OAuth 2.0 használatakor konfigurálja és tesztelje a validate-jwt szabályzatot a jogkivonat meglétének és érvényességének ellenőrzéséhez, mielőtt az elérené a háttérrendszert. Automatikusan ellenőrizze a jogkivonat lejárati idejét, a jogkivonat aláírását és a kiállítót. Jogcímek, célközönségek, jogkivonatok lejárata és jogkivonat-aláírás kényszerítése a szabályzatbeállításokon keresztül. A Microsoft Entra használata esetén az validate-azure-ad-token szabályzat átfogóbb és egyszerűbb módot kínál a biztonsági jogkivonatok érvényesítésére.
    • Konfigurálja a CORS-szabályzatot , és ne használjon helyettesítő karaktereket * semmilyen konfigurációs beállításhoz. Ehelyett explicit módon listázhatja az engedélyezett értékeket.
    • Állítsa be az érvényesítési szabályzatokat éles környezetben a JSON- és XML-sémák, fejlécek, lekérdezési paraméterek és állapotkódok ellenőrzéséhez, valamint a kérések vagy válaszok maximális méretének kikényszerítéséhez.
    • Ha az API Management kívül esik a hálózat határain, az ügyfél IP-jének érvényesítése továbbra is lehetséges a hívó IP-címeinek korlátozására vonatkozó szabályzat használatával. Győződjön meg arról, hogy engedélyezési listát használ, nem blokklistát.
    • Ha ügyféltanúsítványokat használ a hívó és az API Management között, használja az validate-client-certificate szabályzatot . Győződjön meg arról , hogy a validate-revocation, validate-trust, validate-not-beforeés validate-not-after attribútumok mind be vannak állítva true.
  • Az ügyféltanúsítványok (kölcsönös TLS) az API Management és a háttérrendszer között is alkalmazhatók. A háttérrendszernek a következőnek kell lennie:
    • Hitelesítési hitelesítő adatok konfigurálása
    • Szükség esetén ellenőrizze a tanúsítványláncot
    • A tanúsítvány nevének ellenőrzése adott esetben
    • GraphQL-forgatókönyvek esetén használja a validate-graphQL-request szabályzatot. Győződjön meg arról, hogy az elem és max-size max-depth az authorization attribútumok be vannak állítva.
  • Ne tárolja a titkos kulcsokat a szabályzatfájlokban vagy a forráskontrollban. Mindig használjon api Management által elnevezett értékeket , vagy kérje le a titkos kulcsokat futtatókörnyezetben egyéni szabályzatkifejezések használatával. Az elnevezett értékeket integrálják az Azure Key Vaultba , vagy titkosítják az API Managementben a "titkos" megjelöléssel. Soha ne tároljon titkos kulcsokat egyszerű szöveges elnevezett értékekben.
  • Api-k közzététele termékeken keresztül, amelyek előfizetést igényelnek. Ne használjon olyan nyitott termékeket , amelyekhez nincs szükség előfizetésre.
  • Győződjön meg arról, hogy az API-khoz előfizetési kulcsok szükségesek, még akkor is, ha az összes termék előfizetési kulcsok megkövetelésére van konfigurálva. További információ
  • Kérjen előfizetés-jóváhagyást az összes termékhez, és gondosan tekintse át az összes előfizetési kérelmet.
  • A Key Vault-integrációval kezelheti az összes tanúsítványt. Ez központosítja a tanúsítványkezelést, és megkönnyíti az olyan üzemeltetési felügyeleti feladatokat, mint a tanúsítványok megújítása vagy visszavonása. Felügyelt identitás használata a kulcstartók hitelesítéséhez.
  • A saját üzemeltetésű átjáró használatakor győződjön meg arról, hogy a rendszerkép rendszeres frissítése folyamatban van a legújabb verzióra.
  • Háttérszolgáltatásokat jelöl háttérbeli entitásként. Szükség esetén konfigurálja az engedélyezési hitelesítő adatokat, a tanúsítványlánc-ellenőrzést és a tanúsítványnév-ellenőrzést.
  • Ha lehetséges, használjon hitelesítőadat-kezelőt vagy felügyelt identitást a háttérszolgáltatásokon való hitelesítéshez.
  • A fejlesztői portál használatakor:
    • Ha úgy dönt, hogy önkiszolgálóként üzemelteti a fejlesztői portált, győződjön meg arról, hogy folyamatban van egy folyamat, amely rendszeresen frissíti a saját üzemeltetésű portált a legújabb verzióra. Az alapértelmezett felügyelt verzió frissítései automatikusak.
    • Használja a Microsoft Entra ID-t vagy az Azure Active Directory B2C-t a felhasználói regisztrációhoz és a bejelentkezéshez. Tiltsa le az alapértelmezett felhasználónév- és jelszóhitelesítést, ami kevésbé biztonságos.
    • Felhasználói csoportok hozzárendelése termékekhez az API-k láthatóságának szabályozásához a portálon.
  • Az Azure Policy használatával kényszerítheti ki az API Management erőforrásszintű konfigurációs és szerepköralapú hozzáférés-vezérlési (RBAC) engedélyeit az erőforrás-hozzáférés szabályozásához. A minimálisan szükséges jogosultságok megadása minden felhasználónak.
  • Az API Management-tartalom és a konfiguráció változásainak konzisztenciájának biztosításához és az emberi hibák minimalizálásához használjon devOps-folyamat- és infrastruktúra-kódalapú megközelítést a fejlesztési környezeten kívül.
  • Ne használjon elavult funkciókat.

Helytelen készletkezelés

A nem megfelelő eszközök kezelésével kapcsolatos biztonsági rések a következők:

  • Az API megfelelő dokumentációjának vagy tulajdonosi adatainak hiánya
  • Túl sok régebbi API-verzió, amelyek esetleg hiányoznak a biztonsági javítások közül

További információ a fenyegetésről: API9:2023 Helytelen készletkezelés

Ajánlások

  • Használjon egy jól definiált OpenAPI-specifikációt a REST API-k importálásának forrásaként. A specifikáció lehetővé teszi az API-definíció beágyazását, beleértve az önaláírási metaadatokat is.
  • API-felületeket használjon pontos elérési utakkal, adatsémákkal, fejlécekkel, lekérdezési paraméterekkel és állapotkódokkal. Kerülje a helyettesítő karaktereket. Adja meg az egyes API-k és műveletek leírását, és adja meg a kapcsolattartási és licencinformációkat.
  • Kerülje azokat a végpontokat, amelyek nem járulnak hozzá közvetlenül az üzleti célkitűzéshez. Szükségtelenül növelik a támadási felületet, és megnehezítik az API fejlődését.
  • Az API-módosítások kezeléséhez használja az API Management változatait és verzióit . Erős háttérverzió-verziókövetési stratégiával rendelkezik, és a támogatott API-verziók maximális száma (például 2 vagy 3 korábbi verzió) mellett kötelezi el magát. Tervezze meg, hogy gyorsan elavult, és végül eltávolítja a régebbi, gyakran kevésbé biztonságos API-verziókat. Győződjön meg arról, hogy a biztonsági vezérlők minden elérhető API-verzióban implementálva vannak.
  • Külön környezetek (például fejlesztés, tesztelés és éles környezetek) különböző API Management-szolgáltatásokkal. Győződjön meg arról, hogy minden API Management-szolgáltatás ugyanabban a környezetben csatlakozik a függőségeihez. A tesztkörnyezetben például a teszt API Management-erőforrásnak csatlakoznia kell egy teszt Azure Key Vault-erőforráshoz és a háttérszolgáltatások tesztverzióihoz. A DevOps automatizálási és az infrastruktúra kódkénti eljárásainak használatával fenntarthatja a környezetek közötti konzisztenciát és pontosságot, és csökkentheti az emberi hibákat.
  • Elkülönítheti az API-kra és a kapcsolódó erőforrásokra vonatkozó felügyeleti engedélyeket munkaterületek használatával.
  • Címkék használatával rendszerezheti az API-kat és a termékeket, és csoportosíthatja őket közzétételre.
  • Api-k közzététele használat céljából egy fejlesztői portálon keresztül. Győződjön meg arról, hogy az API dokumentációja naprakész.
  • Fedezze fel a nem dokumentált vagy nem felügyelt API-kat, és tegye elérhetővé őket az API Managementen keresztül a jobb felügyelet érdekében.
  • Az Azure API Center használatával az API-k, verziók és üzemelő példányok átfogó, központosított leltárát tarthatja karban, még akkor is, ha az API-kat nem az Azure API Management kezeli.

API-k nem biztonságos felhasználása

Az alsóbb rétegbeli integrációkon keresztül beszerzett erőforrások általában megbízhatóbbak, mint a hívó vagy a végfelhasználó API-bemenetei. Ha nem alkalmazzák a megfelelő higiéniai és biztonsági szabványokat, az API sebezhető lehet, még akkor is, ha az integráció megbízható szolgáltatáson keresztül történik.

További információ a fenyegetésről: API10:2023 Az API-k nem biztonságos felhasználása

Ajánlások

  • Fontolja meg az API Management használatát a háttér API-k által integrálható alsóbb rétegbeli függőségek homlokzataként.
  • Ha az alsóbb rétegbeli függőségeket az API Management kezeli, vagy ha az alsóbb rétegbeli függőségeket egy küldési kérési szabályzattal használják fel az API Managementben, használja a dokumentáció más szakaszainak ajánlásait a biztonságos és szabályozott felhasználás biztosítására, beleértve a következőket:
    • Győződjön meg arról, hogy a biztonságos átvitel engedélyezve van, és kényszerítse ki a TLS/SSL-konfigurációt
    • Ha lehetséges, hitelesítés hitelesítőadat-kezelővel vagy felügyelt identitással
    • A felhasználás szabályozása kulcs szerint és kvótakorlát-kulcsonkénti szabályzatokkal
    • Olyan válaszok naplózása vagy letiltása, amelyek nem összhangban vannak az API-specifikációval a validálási tartalommal és az érvényesítési fejléc szabályzataival
    • A válaszok átalakítása a törzsszabályzattal, például a szükségtelen vagy bizalmas információk eltávolításához
    • Időtúllépések konfigurálása és egyidejűség korlátozása

Kapcsolódó tartalom

További információk: