API-biztonsági irányítás: ISO 27001 bizonyítékok 2026-ra

Az API-auditmegállapítás, amely az adatsértés előtt érkezik

Maria, egy gyorsan növekvő fintech SaaS vállalat információbiztonsági vezetője, három héttel az éves értékelés előtt megnyitja a vezető auditortól érkező e-mailt. Az üzenet egyértelmű:

„Mélyreható felülvizsgálatot végzünk az Önök harmadik felekhez kapcsolódó IKT-kockázatkezelési keretrendszeréről, valamint annak DORA-, NIS2- és GDPR-követelményekkel való összhangjáról, különös tekintettel az API-környezetre. Kérjük, biztosítsák az éles és partner API-k nyilvántartását, hitelesítési modelljét, sebességkorlátozási bizonyítékait és naplózási lefedettségét.”

Két nappal később a belső audit második üzenetet küld:

„47 olyan nyilvános API-végpontot találtunk, amely nem szerepel az eszköznyilvántartásban. Négy API rotációs bizonyítékkal nem alátámasztott API-kulcsokat fogad el. Egy partnerintegráción nincs sebességkorlátozás. A naplózás az éles szolgáltatások között inkonzisztens. Kérjük, péntekig biztosítsák az ISO 27001, GDPR és NIS2 szerinti bizonyítékokat.”

Nincs zsarolóvírus-üzenet. Nincs nyilvános adatsértés. Nincs ügyfélpanasz. A megállapítás mégis súlyos, mert azt az irányítási hiányosságot tárja fel, amelyet a támadók már kihasználnak. Az API-k ma már a tényleges támadási felületet jelentik. Összekapcsolják a fizetéseket, az ügyfélbeléptetést, az identitást, az ügyfélportálokat, a beszállítói szolgáltatásokat, a mobilalkalmazásokat, a felhőben futó munkaterheléseket, az analitikai platformokat és a kiszervezett kockázati motorokat.

Egy majdnem bekövetkezett esemény még nehezebbé teszi a probléma figyelmen kívül hagyását. Egy nyomás alatt dolgozó junior fejlesztő hitelesítés nélkül tette internet felől elérhetővé az előéles API-t. Az API valósághű, álnevesített ügyféladatokat tartalmazott. A red team találta meg először, de a vezetés a kézenfekvő kérdést tette fel: mi van még kint?

2026-ban az API-biztonsági irányítás nem pusztán fejlesztői ellenőrzőlista. Az információbiztonsági vezetőknek, megfelelési vezetőknek, belső auditoroknak és igazgatóságoknak igazolniuk kell, hogy az API-k ismertek, tulajdonoshoz rendeltek, hitelesítettek, felügyeltek, sebességkorlátozottak, teszteltek, kockázatértékeltek és szerepelnek az incidensjelentésben. Ugyanazon bizonyítékoknak gyakran meg kell felelniük az ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 és COBIT-alapú bizonyossági elvárásoknak.

A legtöbb szervezet már rendelkezik technikai eszközökkel: API-átjárókkal, identitásszolgáltatókkal, SIEM-platformokkal, WAF-okkal, felhőnaplókkal, service mesh megoldásokkal, CI/CD-folyamatokkal és jegykezelő rendszerekkel. Ami gyakran hiányzik, az a kontrollnarratíva. Mely API-k tartoznak a hatályba? Ki hagyja jóvá az új API-kat? Mely naplók bizonyítják a hitelesítési hibákat? Melyik nyilvántartás mutatja a harmadik fél API-függőségeket? Miért eltérőek a sebességkorlátozások az ügyfél-, adminisztrátori és gép–gép API-k esetében?

A Clarysec megközelítése szerint az API-biztonsági irányítást több megfelelőségi keretrendszert lefedő bizonyítékrendszerként kell kezelni, nem egyszeri mérnöki tevékenységként. Ha egy API adatokat tehet hozzáférhetővé, üzleti folyamatot módosíthat, felhasználót hitelesíthet, fizetést indíthat, beszállítót hívhat meg vagy szabályozott szolgáltatást támogathat, akkor az IBIR bizonyítékmodelljébe tartozik.

Miért igazgatósági kérdés az API-irányítás?

A NIS2 a kiberbiztonsági irányítást a vezető testület felelősségévé teszi. Article 20 előírja, hogy a vezető testületek hagyják jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, felügyeljék a végrehajtást, és képzésben részesüljenek annak érdekében, hogy megértsék a kiberkockázatokat és azok szolgáltatásokra gyakorolt hatását. Article 21 megfelelő és arányos technikai, működési és szervezeti intézkedéseket ír elő, beleértve a kockázatelemzést, a biztonsági szabályzatokat, az incidenskezelést, az üzletmenet-folytonosságot, az ellátási lánc biztonságát, a biztonságos beszerzést és fejlesztést, a sérülékenységkezelést, az eredményesség értékelését, a kiberhigiéniát, a kriptográfiát, a hozzáférés-szabályozást, az eszközkezelést, valamint adott esetben a többtényezős vagy folyamatos hitelesítést.

Az API-irányítás szempontjából ez azt jelenti, hogy a nyilvános API-k, partner API-k, adminisztrátori API-k és belső mikroszolgáltatás-API-k a szabályozott szolgáltatásnyújtás részét képezhetik. A NIS2 az ágazattól, mérettől, kritikalitástól és tagállami besorolástól függően alkalmazható lehet felhőszolgáltatókra, adatközpont-szolgáltatókra, tartalomszolgáltató hálózatokra, bizalmi szolgáltatókra, nyilvános elektronikus hírközlő hálózatokra és szolgáltatásokra, valamint IKT-szolgáltatásmenedzsment-szolgáltatókra, például MSP-kre és MSSP-kre.

A DORA pénzügyi szektorbeli nézőpontot ad hozzá. 2025. január 17-től alkalmazandó, és egységes követelményeket állapít meg az IKT-kockázatkezelésre, az IKT-val kapcsolatos incidensjelentésre, a digitális működési reziliencia tesztelésére, az információmegosztásra és az IKT harmadik fél kockázatkezelésre. Article 5 előírja, hogy a vezető testület határozza meg, hagyja jóvá és felügyelje az IKT-kockázatkezelési keretrendszert, és maradjon felelős érte. Article 8 előírja az IKT által támogatott üzleti funkciók, információs vagyon, IKT-eszközök, függőségek, harmadik felek által támogatott folyamatok, kritikus vagyonelemek, nyilvántartások és örökölt IKT-kockázatok azonosítását, osztályozását és dokumentálását.

API-szempontból egy fizetésindítási API, csaláspontozó API, ügyfélbeléptetési API vagy kiszervezett KYC API nem pusztán végpont. Olyan IKT-eszköz és függőség, amely üzleti funkciót támogat.

A GDPR teszi teljessé a képet. Az azonosítókat, számlaadatokat, eszközazonosítókat, viselkedési telemetriát, biometrikus adatokat, egészségügyi vonatkozású adatokat vagy pénzügyi profilokat továbbító API-k személyes adatokat kezelhetnek. A GDPR elszámoltathatósági elve megköveteli az adatkezelőktől, hogy igazolni tudják a jogszerűség, a célhoz kötöttség, az adattakarékosság, a tárolási korlátozás, a sértetlenség és a bizalmasság követelményeinek való megfelelést. Article 32 az adatkezelés biztonságát írja elő, míg Articles 33 és 34 megbízható bizonyítékoktól függ, amikor személyesadat-sértés történik.

Az igazgatóságnak nincs szüksége csomagrögzítésekre, de biztosnak kell lennie abban, hogy a szervezet tudja, mely API-k fontosak, milyen adatokat kezelnek, mely beszállítóktól függenek, hogyan előzi meg a visszaélést, hogyan észleli az incidenseket, és hogyan igazolja a megfelelést.

Kezdje az API-nyilvántartással

A legtöbb API-hiba nyilvántartási hibaként kezdődik. Egy elavult mobil backend továbbra is éles környezetben fut. Egy ideiglenes partnerintegráció állandóvá válik. Egy felhőfunkció új végpontot tesz hozzáférhetővé. Egy belső API egy terheléselosztó-módosítás után internet felől elérhetővé válik. Mindez nem jelenik meg a CMDB-ben, ezért nem kap hitelesítési felülvizsgálatot, naplózási szabványt, sebességkorlátozási küszöbértéket, beszállítói értékelést vagy megőrzési besorolást.

Az első auditkérdés általában egyszerű: „Megnézhetem az API-nyilvántartásukat?”

A Clarysec az API-nyilvántartást az IBIR eszköznyilvántartás részeként kezeli. A Zenith Blueprint: egy auditor 30 lépéses ütemterve Zenith Blueprint Controls in Action fázisának 22. lépése az ISO/IEC 27002:2022 5.9 kontrolljára vonatkozó útmutatásban így fogalmaz:

„Egyetlen szervezet sem tudja megvédeni azt, amiről nem tudja, hogy létezik. Az 5.9 kontroll ezt az alapelvet teszi formálissá, és előírja az IBIR szempontjából releváns valamennyi információ és kapcsolódó vagyonelem naprakész nyilvántartásának létrehozását és fenntartását.”

Ugyanez a lépés logikai eszközöket is tartalmaz, például „felhasználói fiókok, hitelesítő adatok, kulcsok, szoftverlicencek, API-k”, valamint szolgáltatáshoz kapcsolódó eszközöket, például SaaS-platformokat és kiszervezett tárhelyet. A Zenith Blueprint a nyilvántartást „az IBIR központi idegrendszerének” nevezi, mert ez ad alapot a hozzáférés-kiosztáshoz, a titkosításhoz, a biztonsági mentéshez, a naplózáshoz, az osztályozáshoz és a megőrzéshez.

A Clarysec vállalati Eszközkezelési szabályzata Eszközkezelési szabályzat ezt irányítási követelménnyé alakítja:

„Az IT-eszközkezelési vezetőnek átfogó és központi eszköznyilvántartást kell fenntartania a szervezet által használt vagy ahhoz kapcsolódó valamennyi információs vagyonelemről.”

A „A szabályzat végrehajtásának követelményei” szakasz 6.1.1 szabályzati pontjából.

KKV-k esetében a Clarysec Eszközkezelési szabályzat – KKV Eszközkezelési szabályzat – KKV kifejezetten tartalmazza az API-releváns digitális vagyonelemeket:

„Digitális hitelesítő adatok és szolgáltatások: domainnevek, digitális tanúsítványok, API-kulcsok, e-mail fiókok, felhőbejelentkezések”

A „Hatály” szakasz 2.2.4 szabályzati pontjából.

Ez a megfogalmazás fontos. Sok auditban az API-végpont egy átjáróban jelenik meg, a token egy titokkezelő páncélteremben, a tanúsítvány egy felhőfiókban, az adatáramlás pedig egy adatvédelmi nyilvántartásban. Egy igazolható API-nyilvántartás ezeket összekapcsolja.

A Zenith Controls: a több keretrendszert lefedő megfelelési útmutatóban Zenith Controls az ISO/IEC 27002:2022 5.9, Információk és más kapcsolódó vagyonelemek nyilvántartása kontroll megelőző kontrollként szerepel, amely a bizalmasságot, a sértetlenséget és a rendelkezésre állást támogatja. Kiberbiztonsági koncepciója az Identify, operatív képessége az Eszközkezelés, biztonsági tartományai pedig az Irányítás, az Ökoszisztéma és a Védelem. Ez segít az auditoroknak az API-nyilvántartást megelőző irányítási kontrollként, nem adminisztratív nyilvántartási feladatként értelmezni.

Bizonyítsa, hogy minden API-identitás szándékosan került kialakításra

Ha a nyilvántartás rendelkezésre áll, a következő kérdés kiszámítható: ki vagy mi hívhatja meg ezeket az API-kat?

A modern API-k emberi felhasználókat, mobilalkalmazásokat, szolgáltatásfiókokat, CI/CD-feladatokat, partnerrendszereket, munkaterheléseket, botokat, integrációkat, adatpipeline-eket és harmadik fél platformokat hitelesítenek. A gyenge API-kulcsok, hosszú élettartamú bearer tokenek, hiányzó kölcsönös TLS, túlzott jogosultságú OAuth-scope-ok és beégetett titkos adatok mind auditkitettséget hoznak létre.

A Zenith Blueprint Controls in Action fázisának 19. lépése az ISO/IEC 27002:2022 8.5, Biztonságos hitelesítés kontrollt tárgyalja:

„A hitelesítés az első és legkritikusabb védelmi vonal a fenyegető szereplő és az Ön rendszerei, adatai és szolgáltatásai között. Ha a hitelesítés gyenge, minden más — a titkosítás, a megfigyelés, a szegmentálás — megkerülhető.”

Ugyanez a lépés kiemeli a gép–gép hitelesítést. A kulcsokat, tanúsítványokat és tokeneket szigorúan védeni kell, a hitelesítő adatokat nem szabad kódba ágyazni, a biztonságos tároláshoz és rotációhoz pedig titokkezelő megoldásokat vagy páncéltermeket kell használni.

A Clarysec vállalati Alkalmazásbiztonsági követelmények szabályzata Alkalmazásbiztonsági követelmények szabályzata ezt közvetlenül beemeli az API-irányításba:

„Valamennyi alkalmazásprogramozási interfészt, mikroszolgáltatást és külső integrációt a következők révén kell védeni:”

Az „Irányítási követelmények” szakasz 5.3 szabályzati pontjából.

Ezt követően előírja:

„Erős hitelesítés alkalmazása, például OAuth 2.0 és kölcsönös TLS”

Az „Irányítási követelmények” szakasz 5.3.1 szabályzati pontjából.

Kisebb szervezetek számára a Clarysec Alkalmazásbiztonsági követelmények szabályzata – KKV Alkalmazásbiztonsági követelmények szabályzata – KKV biztosítja az alapkövetelményt:

„Hitelesítési kontrollok: Az alkalmazásoknak erős hitelesítést kell kikényszeríteniük, beleértve a minimális jelszóerősséget, a sikertelen kísérletek utáni fiókzárolást és a munkamenet-időtúllépést.”

A „A szabályzat végrehajtásának követelményei” szakasz 6.1.1.2 szabályzati pontjából.

API-k esetében ezeket a követelményeket hitelesítési bizonyítékcsomaggá kell alakítani:

1. API-nyilvántartás internet felől elérhető, partneroldali, adminisztrátori és belső API-k szerinti szűréssel.
2. Hitelesítési mátrix, amely bemutatja az OAuth 2.0-t, mTLS-t, aláírt kéréseket, átjáró-autorizátorokat vagy service mesh identitást.
3. OAuth-ügyfél- és scope-nyilvántartás tulajdonossal, céllal, lejárattal, jóváhagyással és utolsó felülvizsgálati dátummal.
4. Titokkezelési bizonyíték a tárolásról, hozzáférésről, rotációról és visszavonásról.
5. Emelt jogosultságú API-hozzáférés felülvizsgálata adminisztrátori végpontokra és éles szolgáltatásfiókokra.
6. Sikertelen hitelesítési naplók és riasztási szabályok.
7. Teszteredmények hiányzó tokenre, lejárt tokenre, hibás audience értékre, hibás scope-ra és visszajátszásos forgatókönyvekre.

A Zenith Controls az ISO/IEC 27002:2022 8.5, Biztonságos hitelesítés kontrollt megelőző kontrollként rendeli hozzá, amely a bizalmasságot, a sértetlenséget és a rendelkezésre állást támogatja. Kiberbiztonsági koncepciója a Protect, operatív képessége az identitás- és hozzáférés-kezelés, biztonsági tartománya pedig a Védelem.

A NIS2 Article 21 ezt hozzáférés-szabályozáson, kriptográfián, valamint adott esetben többtényezős vagy folyamatos hitelesítésen keresztül támogatja. A DORA elvárja, hogy a pénzügyi szervezetek olyan kontrollokat tartsanak fenn, amelyek védik a hitelességet, a sértetlenséget, a rendelkezésre állást és a bizalmasságot. A GDPR Article 32 a gyenge API-hitelesítést az adatkezelés biztonságával kapcsolatos problémává teszi, különösen személyes adatok kitettsége esetén.

Kezelje a sebességkorlátozást rezilienciabizonyítékként

Az erős hitelesítés szükséges, de nem elégséges. Egy hitelesített kliens is visszaélhet egy API-val. A támadók API-kat használnak hitelesítőadat-tömeges próbálgatásra, felsorolásra, scrapingre, token sprayingre, jelszó-visszaállítási bombázásra, tranzakciós visszaélésekre és szolgáltatásmegtagadásra.

A sebességkorlátozást korábban teljesítményfunkciónak tekintették. 2026-ban biztonsági, adatvédelmi és rezilienciabizonyíték.

A Clarysec Alkalmazásbiztonsági követelmények szabályzata kimondja:

„Sebességkorlátozás és visszaélésmegelőzés”

Az „Irányítási követelmények” szakasz 5.3.2 szabályzati pontjából.

A Zenith Blueprint Controls in Action fázisának 20. lépése az ISO/IEC 27002:2022 8.26, Alkalmazásbiztonsági követelmények kontrollhoz kapcsolódóan kifejti, hogy az alkalmazásbiztonsági követelményeknek pontosnak és végrehajthatónak kell lenniük. Felteszi a kérdést, hogy az alkalmazásnak ellenállónak kell-e lennie az injektálási támadásokkal, brute-force bejelentkezésekkel vagy szolgáltatásmegtagadásos kísérletekkel szemben. API-specifikus példaként említi, hogy egy új API-nak tartalmaznia kell hozzáférési token ellenőrzést és bemeneti adatok tisztítását, továbbá megjegyzi, hogy a nyilvánosan elérhető platformok szigorúbb ellenőrzést, felhasználói viselkedéselemzést és sebességkorlátozást igényelhetnek.

Egy igazolható sebességkorlátozási nyilvántartásnak nemcsak azt kell bemutatnia, hogy létezik throttling, hanem azt is, miért ezeket a küszöbértékeket választották, ki hagyta jóvá a kivételeket, és hogyan történik a riasztások nyomon követése.

A NIS2 esetében ez támogatja a biztonságos fejlesztést, az eredményesség értékelését, az üzletmenet-folytonosságot és az incidensmegelőzést. A DORA esetében a sebességkorlátozás az IKT-kockázatkezeléshez, az anomáliadetektáláshoz, a rezilienciateszteléshez és a kritikus vagy fontos funkciók folytonosságához kapcsolódik. A GDPR esetében támogatja az adattakarékosságot, valamint a túlzott vagy jogellenes hozzáféréssel szembeni védelmet, különösen akkor, ha az API-scraping személyes adatokat tehet hozzáférhetővé.

Tegye a naplózást a bizonyítékréteggé

Amikor API-incidens történik, az első valódi kérdés nem az, hogy „Van SIEM-jük?”. Hanem az: „Rekonstruálható, mi történt?”

Az API-naplóknak rögzíteniük kell a hitelesítési hibákat, az engedélyezési elutasításokat, a token claimjeit, a kliensidentitást, a forrást, a végpontot, a metódust, a kérés eredményét, az adminisztratív módosításokat, a magas kockázatú adathozzáférést, a sebességkorlátozási eseményeket, a rendellenes volument, a konfigurációváltozásokat és a biztonsági szempontból releváns hibákat. Kerülniük kell ugyanakkor a titkos adatok, bearer tokenek vagy szükségtelen személyes adatok naplózását.

A Zenith Blueprint Controls in Action fázisának 19. lépése az ISO/IEC 27002:2022 8.15, Naplózás kontrollhoz kapcsolódóan kimondja:

„A naplózás minden biztonságos IT-környezet éltető eleme. Nélküle az incidensek láthatatlanok maradnak, az elszámoltathatóság elhalványul, az ok-okozati összefüggések pedig nyomtalanul eltűnnek.”

Azt is kifejti, hogy a naplózás a visszakövethetőségről szól, és hogy a hasznos naplókat biztonságosan kell tárolni, figyelni kell, felül kell vizsgálni, és védeni kell a manipulációval szemben.

A Clarysec Alkalmazásbiztonsági követelmények szabályzata – KKV előírja:

„Auditnaplózás: Az alkalmazásoknak naplózniuk kell a hitelesítési eseményeket (bejelentkezések, kijelentkezések és sikertelen kísérletek), az adathozzáférést és az adminisztratív módosításokat.”

A „A szabályzat végrehajtásának követelményei” szakasz 6.1.1.7 szabályzati pontjából.

A Clarysec Naplózási és felügyeleti szabályzat – KKV Naplózási és felügyeleti szabályzat – KKV meghatározza a naplózás irányítási kategóriáját:

„Kötelező naplótípusok”

Az „Irányítási követelmények” szakasz 5.4 szabályzati pontjából.

Felhőben üzemeltetett API-k esetében a Clarysec vállalati Felhőszolgáltatások használatára vonatkozó szabályzata Felhőszolgáltatások használatára vonatkozó szabályzat megerősíti a követelményt:

„A naplóknak rögzíteniük kell:”

A „A szabályzat végrehajtásának követelményei” szakasz 6.5.2 szabályzati pontjából.

A Zenith Controls az ISO/IEC 27002:2022 8.15, Naplózás kontrollt észlelő kontrollként rendeli hozzá, amely a bizalmasságot, a sértetlenséget és a rendelkezésre állást támogatja. Kiberbiztonsági koncepciója a Detect, operatív képessége az információbiztonsági eseménykezelés, biztonsági tartományai pedig a Védelem és a Védelmi működés. Ez teszi a naplózást a szabályzat és a bizonyíték közötti híddá.

A NIS2 Article 23 lépcsőzetes jelentéstételt ír elő jelentős incidensek esetén: korai figyelmeztetés a tudomásszerzéstől számított 24 órán belül, incidensbejelentés 72 órán belül, kérés esetén közbenső jelentések, valamint zárójelentés a bejelentést követő egy hónapon belül. A bizalmi szolgáltatás nyújtását érintő bizalmi szolgáltatók esetében a tudomásszerzéstől számított 24 órán belüli értesítés szükséges.

A DORA Articles 17 to 19 IKT-val kapcsolatos incidenskezelést ír elő korai figyelmeztető indikátorokkal, súlyossági és kritikalitási besorolással, eszkalációval, naplózással, gyökérok-követéssel és a jelentős IKT-val kapcsolatos incidensek kezdeti, közbenső és zárójelentéseivel. A GDPR szerinti adatsértésértékelés is a naplóktól függ annak megállapításához, hogy történt-e személyes adathozzáférés, mely érintettek érintettek, és keletkezik-e bejelentési kötelezettség.

Építsen API-bizonyítékcsomagot öt munkanap alatt

Egy gyors sprint célja nem az összes API-biztonsági probléma egy hét alatti megoldása. A cél egy igazolható alapállapot létrehozása, a hiányosságok azonosítása és a kockázatkezelés megkezdése.

1. nap: az API-nyilvántartás létrehozása

Exportálja az útvonalakat az API-átjárókból, service mesh megoldásokból, felhőalapú terheléselosztókból, serverless függvényekből, OpenAPI-adattárakból és CI/CD telepítési manifestekből. Normalizálja ezeket egyetlen API-nyilvántartásba, amely tartalmazza a végpontot, környezetet, tulajdonost, üzleti folyamatot, adatosztályozást, személyesadat-jelölőt, hitelesítési módszert, sebességkorlátozást, naplózási státuszt, beszállítói függőséget, kritikalitást és utolsó felülvizsgálati dátumot.

Irányítási horgonyként használja az Eszközkezelési szabályzat 6.1.1 pontját és a Zenith Blueprint 22. lépését.

2. nap: a hitelesítési hiányosságok osztályozása

Hozzon létre hitelesítési mátrixot. Jelölje meg azokat az API-kat, amelyek statikus API-kulcsokat vagy hosszú élettartamú tokeneket használnak, nem végeznek audience-ellenőrzést, nem végeznek scope-ellenőrzést, hiányzik náluk a partnerintegrációkhoz szükséges mTLS, megosztott szolgáltatásfiókokat használnak, vagy nincs rotációs bizonyítékuk.

A megállapításokat rendelje hozzá az Alkalmazásbiztonsági követelmények szabályzata 5.3.1 pontjához és a Zenith Blueprint 19. lépéséhez. Minden hiányosságot kockázatként rögzítsen tulajdonossal, kezelési úttal és tervezett határidővel.

3. nap: a sebességkorlátozás és a visszaélés elleni kontrollok bizonyítása

Nyilvános, partner- és adminisztrátori API-k esetében rögzítse az átjárószabályokat, WAF-szabályokat, botkontrollokat, kvótabeállításokat és riasztási küszöbértékeket. Ahol nincsenek kontrollok, rögzítsen kompenzáló kontrollokat vagy nyitott kockázatkezelési feladatot.

Szabályzati felhatalmazásként használja az Alkalmazásbiztonsági követelmények szabályzata 5.3.2 pontját. Kritikus API-k esetében kapcsolja össze a küszöbértékeket a szolgáltatási hatással, az ügyfélkárral és a DORA vagy NIS2 szerinti rezilienciaelvárásokkal.

4. nap: a naplózási lefedettség ellenőrzése

Mintavételezzen naplókat magas kockázatú API-kból. Erősítse meg, hogy a naplók rögzítik a sikeres hitelesítést, a sikertelen hitelesítést, az engedélyezési elutasítást, az adathozzáférést, az adminisztrátori módosítást, a sebességkorlátozási eseményt, a forrásidentitást és a korrelációs azonosítót. Ellenőrizze az időszinkronizálást, a megőrzést, a hozzáférés-szabályozást és a manipuláció elleni védelmet.

Ha a naplók tokeneket, titkos adatokat vagy túlzott mennyiségű személyes adatot tartalmaznak, adatvédelmi és biztonsági helyesbítő intézkedéseket kell indítani.

5. nap: az auditválasz-csomag átadása

Adjon át tömör bizonyítékkészletet:

• API-nyilvántartás exportja és tulajdonosi összefoglaló.
• API-kockázati nyilvántartás kockázatkezelési tervvel.
• Hitelesítési mátrix és token-felülvizsgálati bizonyíték.
• Sebességkorlátozási bizonyíték és jóváhagyott kivételek.
• Naplózási lefedettségi jelentés és SIEM-irányítópult-képernyőképek.
• Incidensosztályozási forgatókönyv API-visszaélésekhez.
• Több keretrendszert lefedő megfeleltetés ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 és COBIT-alapú auditnézetekhez.

A fontos szemléletváltás az, hogy minden artefaktumnak kontrolltörténete van. Az API-nyilvántartás az eszközkezelést támogatja. A hitelesítés a hozzáférés-szabályozást támogatja. A sebességkorlátozások az alkalmazásbiztonságot és a rezilienciát támogatják. A naplók az észlelést, az incidensreagálást és az elszámoltathatóságot támogatják.

Több keretrendszert lefedő megfeleltetés API-irányításhoz

A legnagyobb hiba külön bizonyítékkészleteket építeni minden keretrendszerhez. Az API-irányítás hatékonyabb egyetlen kontrollmodellként, több szabályozói nézettel.

Az ISO/IEC 27001:2022 biztosítja azt az irányítási rendszert, amely összefogja a bizonyítékokat. A 4.1–4.4 pontok előírják, hogy a szervezet határozza meg az IBIR környezetét és alkalmazási területét, beleértve az érdekelt feleket, a jogi, szabályozási és szerződéses kötelezettségeket, valamint a más szervezetekkel fennálló interfészeket vagy függőségeket. Az 5.1–5.3 pontok az elszámoltathatóságot a felső vezetéshez rendelik. A 6.1.1–6.1.3 pontok létrehozzák a kockázatértékelési, kockázatkezelési és alkalmazhatósági nyilatkozati folyamatot. A 8.1 pont operatív tervezést és szabályozást ír elő, beleértve az IBIR szempontjából releváns, külsőleg biztosított folyamatok, termékek vagy szolgáltatások kontrollját.

Az API-irányítás szempontjából ez azt jelenti, hogy egy harmadik fél fizetési API-ja, felhőidentitás-API-ja vagy kiszervezett csalásészlelési API-ja nem kerül ki a megfelelés köréből pusztán azért, mert külső. Olyan interfész és függőség, amelyet hatályba kell vonni, kockázatértékelni és kontrollálni kell.

A NIST CSF 2.0 hasznos vezetői nézetet ad hozzá. GOVERN funkciója segíti a szervezeteket az érdekelt felek elvárásainak, jogi kötelezettségeinek, kockázatvállalási hajlandóságának és ellátásilánc-kockázatainak meghatározásában. Profilmegközelítése támogatja a Current Profile, Target Profile, priorizált hiányossági terv és folyamatos fejlesztési ciklus kialakítását. Pontosan így kell működnie egy API-irányítási sprintnek is.

A COBIT 2019 a menedzsmentnézetet támogathatja azzal, hogy az API-kontrollokat irányítási célokhoz, kontrolltulajdonláshoz, szolgáltatás-folytonossághoz, biztonsági felügyelethez, kockázatjelentéshez és problémakövetéshez kapcsolja. A lényeg nem az, hogy az API-kat egyetlen keretrendszerbe kényszerítsük, hanem annak bemutatása, hogy egy bizonyítékmodell több bizonyossági kérdésre is választ ad.

Hogyan tesztelik az auditorok az API-irányítást?

Egy erős program előre számol az auditor nézőpontjával. Ugyanazokat a bizonyítékokat a keretrendszertől függően eltérően fogják tesztelni.

A Clarysec bizonyítéktriangulációt javasol. Ne csak a szabályzatot mutassa be. Mutassa be a szabályzatot, a végrehajtási bizonyítékot és a működési bizonyítékot is.

Például:

• Szabályzat: az API-knak adott esetben OAuth 2.0-t vagy mTLS-t kell használniuk.
• Konfiguráció: az API-átjáró útvonala JWT-ellenőrzést és engedélyezett audience értéket mutat.
• Működési bizonyíték: a sikertelen tokenkísérleteket naplózzák, és a riasztás aktív.
• Felülvizsgálati bizonyíték: az OAuth-ügyfél felülvizsgálata tulajdonosi jóváhagyással lezárult.
• Kockázati bizonyíték: egy örökölt API-kivételhez kompenzáló kontrollok és kezelési határidő tartozik.

Ez sokkal erősebb, mint egy kizárólag képernyőképekre épülő válasz.

Gyakori API-irányítási buktatók

A leggyakoribb probléma nem az, hogy az API-k teljesen védtelenek. Hanem az, hogy a biztonság inkonzisztens.

Az egyik csapat jól használja az OAuth-scope-okat, egy másik megosztott API-kulcsot használ. Az egyik szolgáltatás naplózza az adathozzáférést, egy másik csak a szerverhibákat. Az egyik partnerintegráció mTLS-t használ, egy másik hosszú élettartamú bearer tokenre támaszkodik. A nyilvános végpontokon van sebességkorlátozás, de nincs a hitelesített ügyfél-API-kon, ahol scraping történhet. A CMDB tartalmazza az alkalmazást, de nem tartalmazza annak API-jait, tokenjeit, tanúsítványait, adatkategóriáit vagy beszállítóit.

Visszatérő buktatók:

• Shadow API-k bevezetése serverless függvényeken vagy ideiglenes tesztútvonalakon keresztül.
• API-kulcsok tárolása CI/CD-változókban dokumentált rotáció nélkül.
• Olyan naplózás, amely tokeneket, titkos adatokat vagy szükségtelen személyes adatokat rögzít.
• Korrelációs azonosító hiánya az átjáró-, alkalmazás- és adatbázisnaplók között.
• Nagy ügyfelek számára informálisan jóváhagyott sebességkorlátozási kivételek.
• Szerződéses incidensbejelentési vagy auditálási jogok nélküli partner API-k.
• API-specifikus incidensbesorolás hiánya felsorolásra, scrapingre vagy tokenvisszaélésre.
• Kapcsolat hiánya az API-adatáramlások és a GDPR szerinti adatkezelési nyilvántartások között.
• Webes felületre fókuszáló biztonsági tesztelés, miközben az API-k teszteletlenek maradnak.
• Olyan igazgatósági jelentések, amelyek „alkalmazásbiztonságot” mutatnak API-specifikus kockázati mutatók nélkül.

Ezek megoldható problémák, de csak akkor, ha a szervezet az API-irányítást menedzselt kontrollterületként kezeli.

Alakítsa az API-biztonságot auditra felkészített irányítássá

Ha a következő audit API-biztonsági bizonyítékokat kér, ne véletlenszerű képernyőképek gyűjtésével kezdje. Kezdje a kontrolltörténettel.

A Clarysec ebben a következőkkel segít:

• Zenith Blueprint Zenith Blueprint az eszköznyilvántartáson, biztonságos hitelesítésen, alkalmazásbiztonsági követelményeken és naplózáson átívelő bevezetés strukturálásához.
• Zenith Controls Zenith Controls az ISO/IEC 27002:2022 kontrollok, például 5.9, 8.5, 8.15 és 8.26 több megfelelőségi keretrendszert lefedő elvárásokhoz és auditori nézőpontokhoz történő megfeleltetéséhez.
• Clarysec szabályzatok, köztük az Eszközkezelési szabályzat Eszközkezelési szabályzat, az Alkalmazásbiztonsági követelmények szabályzata Alkalmazásbiztonsági követelmények szabályzata, a Felhőszolgáltatások használatára vonatkozó szabályzat Felhőszolgáltatások használatára vonatkozó szabályzat, az Eszközkezelési szabályzat – KKV Eszközkezelési szabályzat – KKV, az Alkalmazásbiztonsági követelmények szabályzata – KKV Alkalmazásbiztonsági követelmények szabályzata – KKV és a Naplózási és felügyeleti szabályzat – KKV Naplózási és felügyeleti szabályzat – KKV.

Gyakorlati következő lépésként indítson Clarysec API Governance Evidence Sprintet: készítsen API-nyilvántartást, osztályozza a hitelesítést, ellenőrizze a sebességkorlátozást, erősítse meg a naplózást, térképezze fel a harmadik fél függőségeket, és állítson elő ISO 27001-re felkészített bizonyítékcsomagot NIS2, DORA, GDPR, NIST CSF 2.0 és COBIT-alapú auditnézetekkel.

Az API-k ott helyezkednek el, ahol az üzleti logika, az ügyféladatok és a harmadik felektől való függőségek találkoznak. 2026-ban többet érdemelnek puszta technikai védelemnél. Olyan irányításra van szükségük, amely kiállja az auditot, támogatja a hatósági választ, és segíti a csapatokat abban, hogy az ügyfelek előtt észleljék a visszaélést.