Javaslatok az OWASP API Security Top 10 fenyegetéseinek mérséklése az API Management használatával

  • Cikk

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

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 azOkat a javaslatokat ismertetjük, amelyek az Azure API Management használatával mérsékelik az OWASP által azonosított 10 API-fenyegetést.

Feljegyzés

A cikkben szereplő javaslatok követésén kívül engedélyezheti a Defender for API-kat, amely Felhőhöz készült Microsoft Defender képes az API biztonsági elemzésekhez, javaslatokhoz és fenyegetésészleléshez. További információ a Defender for API-k API Managementtel való használatáról

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:2019 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 egy szótárral) rendelkező szabályzatkifejezés , vagy egy másik szolgáltatással való integráció 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 az érvényesítési GraphQL-kérési szabályzaton authorize keresztül.

Hibás felhasználói hitelesítés

A hitelesítési mechanizmusok gyakran helytelenül vagy hiányoznak, így a támadók kihasználhatják az adatokhoz való hozzáférés végrehajtási hibáit.

További információ a fenyegetésről: API2:2019 – Hibás felhasználói hitelesítés

Ajánlások

Az API Management használata felhasználói hitelesítéshez és engedélyezéshez:

  • Hitelesítés – Az API Management a következő hitelesítési módszereket támogatja:

    • Alapszintű hitelesítési szabályzat – Felhasználónév és jelszó hitelesítő adatai.

    • Előfizetési kulcs – Az előfizetési kulcs ugyanolyan szintű biztonságot nyújt, mint az alapszintű hitelesítés, és lehet, hogy önmagában nem elegendő. Ha az előfizetési kulcs sérült, a támadó korlátlan hozzáférést kaphat a rendszerhez.

    • Ügyféltanúsítvány-szabályzat – Az ügyféltanúsítványok használata biztonságosabb, mint az alapszintű hitelesítő adatok vagy az előfizetési kulcs, de nem teszi lehetővé a jogkivonatalapú engedélyezési protokollok, például az OAuth 2.0 által biztosított rugalmasságot.

  • Engedélyezés – Az API Management támogatja a JWT-szabályzat érvényesítését egy bejövő OAuth 2.0 JWT hozzáférési jogkivonat érvényességének ellenőrzéséhez az OAuth-identitásszolgáltató metaadat-végpontjáról beszerzett információk alapján. Konfigurálja a szabályzatot a vonatkozó jogkivonat-jogcímek, célközönségek és lejárati idő ellenőrzéséhez. További információ az API-k OAuth 2.0-hitelesítéssel és Microsoft Entra-azonosítóval történő védelméről.

További javaslatok:

  • Szabályzatok használata az API Managementben a biztonság növelése érdekében. A hívássebesség-korlátozás például lelassítja a rossz szereplőket, és találgatásos támadásokkal rontja a hitelesítő adatokat.

  • Az API-knak TLS/SSL -t (átviteli biztonságot) kell használniuk a hitelesítő adatok vagy jogkivonatok védelméhez. A hitelesítő adatokat és jogkivonatokat nem lekérdezési paraméterekként, hanem kérelemfejlécekben kell elküldeni.

  • Az API Management fejlesztői portálon konfigurálja a Microsoft Entra-azonosítót vagy az Azure Active Directory B2C-t identitásszolgáltatóként a fiókbiztonság növelése érdekében. A fejlesztői portál a CAPTCHA használatával mérsékli a találgatásos támadásokat.

Túlzott adatexpozíció

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.

Egy rossz szereplő megpróbálhatja közvetlenül elérni az API-t (esetleg egy érvényes kérés ismétlésével), vagy a kiszolgáló és az API közötti forgalmat. Az API-műveletek és a rendelkezésre álló adatok elemzése bizalmas adatokat adhat a támadónak, amelyeket nem az előtérbeli alkalmazás használ fel vagy használ fel.

További információ a fenyegetésről: API3:2019 Túlzott adatexpozíció

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 használja a következőket:

    • Korrektúrák a nem törhető módosítások, például egy mező hozzáadása egy felülethez. A háttérrendszerben változatokat és verziószámozási implementációkat is használhat.

    • A kompatibilitástörő változások verziói, például egy mező eltávolítása egy felületről.

  • 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. Távolítsa el például a szükségtelen JSON-tulajdonságokat egy választörzsből.

  • Az API Management választartalmainak érvényesítése XML- vagy JSON-sémával is használható a nem dokumentált tulajdonságokkal vagy nem megfelelő értékekkel rendelkező válaszok blokkolásához. A szabályzat a megadott méretnél nagyobb válaszok blokkolását is támogatja.

  • Az érvényesítési állapotkód szabályzatával letilthatja az API-sémában nem definiált hibákkal érkező 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 beállított fejlécszabályzattal .

  • GraphQL-forgatókönyvek esetén a GraphQL-kérelmek érvényesítésére szolgáló GráfQL-kérelemszabályzattal érvényesítheti a GraphQL-kérelmeket, engedélyezheti a hozzáférést adott lekérdezési útvonalakhoz, és korlátozhatja a válaszméretet.

Az erőforrások hiánya és a sebességkorlátozás

A sebességkorlátozás hiánya adatkiszivárgáshoz vagy sikeres DDoS-támadásokhoz vezethet a háttérszolgáltatások ellen, ami minden fogyasztónál kimaradáshoz vezethet.

További információ a fenyegetésről: API4:2019 Erőforrások hiánya és sebességkorlátozás

Ajánlások

  • A sebességkorlát (rövid távú) és a kvótakorlát (hosszú távú) szabályzatok használatával szabályozhatja az API-hívások engedélyezett számát vagy a felhasználónkénti sávszélességet.

  • Szigorú kérelemobjektum-definíciókat és azok tulajdonságait definiálja az OpenAPI-definícióban. Definiálja például a sztringek lapszámozási egész számainak, a maxLength és a regex kifejezésének (regex) maximális értékét. Kényszerítse ki ezeket a sémákat a tartalom érvényesítése és a paraméterszabályzatok érvényesítése az API Managementben.

  • A kérelem maximális méretének kényszerítése a tartalomérvényesítési szabályzattal.

  • 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.

  • Hitelesítés kényszerítése API-hívásokhoz (lásd: Hibás felhasználói hitelesítés). A visszaélést használók hozzáférésének visszavonása. Inaktiválhatja például az előfizetési kulcsot, letilthatja az IP-címet a hívó IP-címeinek korlátozására vonatkozó házirenddel, vagy elutasíthatja egy bizonyos felhasználói jogcímre vonatkozó kéréseket egy JWT-jogkivonatból.

  • 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.

  • A háttérszolgáltatás válaszidejének minimalizálása. Minél tovább tart a háttérszolgáltatás válasza, annál hosszabb ideig van használatban a kapcsolat az API Managementben, így csökken az adott időkeretben kiszolgálható kérések száma.

    • Definiálja timeout a továbbítási kérelem szabályzatában.

    • Használja a GraphQL-kérelmek érvényesítési szabályzatát a GraphQL API-khoz, valamint konfiguráljon max-depth és max-size paramétereket.

    • Korlátozza a párhuzamos háttérkapcsolatok számát a korlát egyidejűségi szabályzattal.

  • Bár az API Management képes megvédeni a háttérszolgáltatásokat a DDoS-támadásoktól, sebezhető lehet magára a támadásokra. A DDoS-támadások elleni hatékonyabb védelem érdekében helyezzen üzembe egy robotvédelmi szolgáltatást az API Management (például Azure-alkalmazás Gateway, Azure Front Door vagy Azure DDoS Protection) előtt. Ha WAF-et használ Azure-alkalmazás Gateway vagy 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 rendszeres függvények nem egyértelmű elkülönítése engedélyezési hibákhoz vezet. 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:2019 Hibás függvényszintű engedélyezés

Ajánlások

  • Alapértelmezés szerint az API Management összes API-végpontját előfizetési kulcsokkal védi.

  • JWT-szabályzat meghatározása és a szükséges jogkivonat-jogcímek kikényszerítése. Ha bizonyos műveletek szigorúbb jogcímérvényesítést igényelnek, csak ezekhez a műveletekhez adjon meg további validate-jwt szabályzatokat.

  • 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.

Tömeges hozzárendelés

Ha egy API több mezőt kínál, mint amennyit az ügyfél igényel egy adott művelethez, a támadó túlzott tulajdonságokat szúrhat be az adatok jogosulatlan műveleteinek végrehajtásához. A támadók a kérések és válaszok vagy más API-k formátumának vizsgálatával vagy találgatásukkal felderíthetik a nem dokumentált tulajdonságokat. Ez a biztonsági rés különösen akkor alkalmazható, ha nem használ erősen gépelt programozási nyelveket.

További információ a fenyegetésről: API6:2019 Tömeges hozzárendelés

Ajánlások

  • A külső API-interfészeket el kell választani a belső adatmegvalósítástól. Kerülje az API-szerződések közvetlen kötését a háttérszolgáltatások adatszerződéseihez. Tekintse át gyakran az API-kialakítást, és törölje és távolítsa el az örökölt tulajdonságokat az API Management verziószámozásával.

  • Az API-sémában pontosan definiálhat XML- és JSON-szerződéseket, és érvényesítheti a tartalom- és paraméterszabályzatokat a kérelmek és válaszok dokumentálatlan tulajdonságokkal való blokkolásához. 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.

  • Ha a háttérfelület nem módosítható, átalakítási szabályzatok használatával írja át a kérések és válaszok hasznos adatait, és leválasztsa az API-szerződéseket a háttérszerződésekről. Például maszkolhatja vagy szűrheti az adatokat, vagy eltávolíthatja a szükségtelen JSON-tulajdonságokat.

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
  • Egyéb beállítások vagy végpontok, amelyek jogosulatlan hozzáférést tehetnek lehetővé a rendszerhez

További információ a fenyegetésről: API7:2019 Biztonsági 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.

  • 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 az érvényesítési JWT-szabályzatot a JWT-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.

    • 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 prevent é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érelmek 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 ügyféltanúsítvány-szabályzat érvényesítését. 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 az érvényesített GraphQL-kérési szabályzatot. Győződjön meg arról, hogy az elem és max-sizemax-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 a Key Vaultba , vagy titkosítják az API Managementen belül 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.

  • 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 műveletek kezelését, mint a tanúsítványok megújítása vagy visszavonása.

  • 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.

  • 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. Frissítések alapértelmezett felügyelt verzió automatikus.

    • 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.

Injekció

A felhasználói adatokat elfogadó végpontok potenciálisan sebezhetők az injektálási biztonsági rések miatt. Ilyenek például a következők:

  • Parancsinjektálás, amely során egy rossz szereplő megpróbálja módosítani az API-kérést, hogy parancsokat hajtson végre az API-t futtató operációs rendszeren

  • SQL-injektálás, ahol egy hibás szereplő megpróbálja módosítani az API-kérést a parancsok és lekérdezések adatbázison való végrehajtásához, az API függ

További információ a fenyegetésről: API8:2019 Injection

Ajánlások

  • A modern webalkalmazási tűzfal (WAF) szabályzatok számos gyakori injektálási biztonsági rést fednek le. Bár az API Management nem rendelkezik beépített WAF-összetevővel, az API Management-példány egy WAF-példányának üzembe helyezése erősen ajánlott. Használjon például Azure-alkalmazás Átjárót vagy Az Azure Front Doort.

    Fontos

    Győződjön meg arról, hogy egy rossz szereplő nem tudja megkerülni a WAF-ot üzemeltető átjárót, és közvetlenül az API Management-átjáróhoz vagy magához a háttér API-hoz csatlakozik. A lehetséges kockázatcsökkentések közé tartoznak a hálózati ACL-ek, az API Management-házirend használata a bejövő forgalom ügyfél IP-cím szerinti korlátozásához, a nyilvános hozzáférés eltávolításához, ahol nincs szükség rá, és az ügyféltanúsítvány-hitelesítés (más néven kölcsönös TLS vagy mTLS).

  • Szükség esetén séma- és paraméterérvényesítési szabályzatokkal korlátozhatja és érvényesítheti a kérést, mielőtt elérené a háttér API-szolgáltatást.

    Az API-definícióhoz megadott sémának regex mintakorlátozást kell alkalmaznia a sebezhető mezőkre. Minden regexet tesztelni kell annak biztosítása érdekében, hogy az elegendő mértékben korlátozza a mezőt a gyakori injektálási kísérletek mérsékléséhez.

Nem megfelelő eszközök kezelése

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:2019 Helytelen eszközök kezelése

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-végpontok szabályozásához és szabályozásához használjon változatokat és verziókat az API Managementben. 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.

  • Használjon környezetenként egy API Management-példányt (például fejlesztés, tesztelés és éles környezet). Győződjön meg arról, hogy minden API Management-példány 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.

  • 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 a beépített 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.

Nem megfelelő naplózás és monitorozás

Az elégtelen naplózás és monitorozás, valamint az incidensválaszokkal való hiányzó vagy hatástalan integráció lehetővé teszi a támadók számára, hogy további támadási rendszereket támadjanak, fenntartsák az adatmegőrzést, több rendszer felé forgjanak, hogy illetéktelenek módosítsák az adatokat, és kinyerjenek vagy megsemmisítsék az adatokat. A legtöbb szabálysértési vizsgálat azt mutatja, hogy a jogsértés észlelésének ideje több mint 200 nap, amelyet általában külső felek észlelnek a belső folyamatok vagy monitorozás helyett.

További információ a fenyegetésről: API10:2019 Nem megfelelő naplózás és monitorozás

Ajánlások

Következő lépések

További információk: