Upravljanje sigurnošću API-ja: dokazi za ISO 27001 u 2026.

Revizijski nalaz za API koji stiže prije povrede

Maria, CISO brzorastuće fintech SaaS tvrtke, otvara e-poruku vodećeg revizora tri tjedna prije godišnje procjene. Poruka je izravna:

„Provest ćemo detaljan pregled vašeg okvira za upravljanje IKT rizicima trećih strana i njegove usklađenosti s DORA, NIS2 i GDPR, s posebnim fokusom na vaš API ekosustav. Molimo dostavite popis, model autentifikacije, dokaze o ograničavanju učestalosti zahtjeva i pokrivenost zapisivanjem događaja za produkcijske i partnerske API-je.“

Dva dana poslije interna revizija šalje drugu poruku:

„Pronašli smo 47 javnih krajnjih točaka API-ja koje nisu u popisu imovine. Četiri prihvaćaju API ključeve bez dokaza o periodičnoj promjeni. Jedna partnerska integracija nema ograničavanje učestalosti zahtjeva. Zapisivanje događaja nije dosljedno u produkcijskim uslugama. Molimo dostavite dokaze za ISO 27001, GDPR i NIS2 do petka.“

Nema poruke o ransomwareu. Nema javne povrede. Nema pritužbe klijenta. No nalaz je ozbiljan jer otkriva prazninu u upravljanju koju napadači već iskorištavaju. API-ji su sada stvarni perimetar. Povezuju plaćanja, uvođenje korisnika, identitet, portale za klijente, usluge dobavljača, mobilne aplikacije, radna opterećenja u oblaku, analitičke platforme i eksternalizirane sustave za obradu rizika.

Gotovo ostvareni incident dodatno otežava ignoriranje problema. Mlađi razvojni inženjer, radeći pod pritiskom, izložio je pripremni API internetu bez autentifikacije. Sadržavao je realistične, pseudonimizirane podatke klijenata. Red Team ga je pronašao prvi, ali uprava je postavila očito pitanje: što još postoji vani?

U 2026. upravljanje sigurnošću API-ja nije samo kontrolni popis za razvojne inženjere. CISO-i, voditelji usklađenosti, interni revizori i odbori moraju dokazati da su API-ji poznati, dodijeljeni vlasnicima, autentificirani, praćeni, ograničeni po učestalosti zahtjeva, testirani, procijenjeni prema riziku i uključeni u prijavljivanje incidenata. Isti dokazi često moraju zadovoljiti očekivanja osiguranja za ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 i revizije usklađene s COBIT-om.

Većina organizacija već ima tehničke alate: API pristupnike, pružatelje identiteta, SIEM platforme, WAF-ove, dnevničke zapise u oblaku, servisne mreže, CI/CD cjevovode i sustave za evidentiranje zahtjeva. Ono što im često nedostaje jest kontrolni narativ. Koji su API-ji u opsegu? Tko odobrava nove API-je? Koji dnevnički zapisi dokazuju neuspjele autentifikacije? Koji registar prikazuje ovisnosti o API-jima trećih strana? Zašto su ograničenja učestalosti zahtjeva različita za klijentske, administratorske i M2M API-je?

Clarysecov pristup tretira upravljanje sigurnošću API-ja kao sustav dokaza za višestruku usklađenost, a ne kao jednokratnu inženjersku aktivnost. Ako API može izložiti podatke, promijeniti poslovni proces, autentificirati korisnika, pokrenuti plaćanje, pozvati dobavljača ili podržati reguliranu uslugu, pripada u dokazni model ISMS-a.

Zašto je upravljanje API-jima sada pitanje za upravni odbor

NIS2 čini upravljanje kibernetičkom sigurnošću odgovornošću upravljačkog tijela. Članak 20 zahtijeva da upravljačka tijela odobre mjere upravljanja kibernetičkim rizicima, nadziru provedbu i prođu obuku kako bi razumjela kibernetičke rizike i njihov utjecaj na usluge. Članak 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere, uključujući analizu rizika, sigurnosne politike, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, sigurnu nabavu i razvoj, postupanje s ranjivostima, procjenu djelotvornosti, kibernetičku higijenu, kriptografiju, kontrolu pristupa, upravljanje imovinom i višefaktorsku ili kontinuiranu autentifikaciju gdje je primjenjivo.

Za upravljanje API-jima to znači da javni API-ji, partnerski API-ji, administratorski API-ji i interni mikroservisni API-ji mogu biti dio pružanja reguliranih usluga. NIS2 se može primjenjivati na pružatelje usluga računalstva u oblaku, pružatelje usluga podatkovnih centara, mreže za isporuku sadržaja, pružatelje usluga povjerenja, javne elektroničke komunikacijske mreže i usluge te pružatelje upravljanih IKT usluga, kao što su MSP-ovi i MSSP-ovi, ovisno o sektoru, veličini, kritičnosti i klasifikaciji države članice.

DORA dodaje perspektivu financijskog sektora. Primjenjuje se od 17. siječnja 2025. i uspostavlja jedinstvene zahtjeve za upravljanje IKT rizicima, prijavljivanje incidenata povezanih s IKT-om, testiranje digitalne operativne otpornosti, razmjenu informacija i upravljanje IKT rizicima trećih strana. Članak 5 zahtijeva da upravljačko tijelo definira, odobri i nadzire okvir za upravljanje IKT rizicima te ostane odgovorno za njega. Članak 8 zahtijeva identifikaciju, klasifikaciju i dokumentiranje poslovnih funkcija podržanih IKT-om, informacijske imovine, IKT imovine, ovisnosti, procesa koje podržavaju treće strane, kritične imovine, popisa imovine i rizika naslijeđenog IKT-a.

U kontekstu API-ja, API za iniciranje plaćanja, API za ocjenu prijevare, API za uvođenje klijenata ili eksternalizirani KYC API nije samo krajnja točka. To je IKT imovina i ovisnost koja podržava poslovnu funkciju.

GDPR zaokružuje sliku. API-ji koji prenose identifikatore, podatke o računima, identifikatore uređaja, bihevioralnu telemetriju, biometrijske podatke, podatke povezane sa zdravljem ili financijske profile mogu obrađivati osobne podatke. Načelo odgovornosti iz GDPR-a zahtijeva od voditelja obrade da dokažu usklađenost sa zakonitošću, ograničenjem svrhe, smanjenjem količine podataka, ograničenjem pohrane, cjelovitošću i povjerljivošću. Članak 32 zahtijeva sigurnost obrade, dok članci 33 i 34 ovise o pouzdanim dokazima kada dođe do povrede osobnih podataka.

Upravnom odboru ne trebaju snimke paketa, ali treba mu sigurnost da organizacija zna koji su API-ji važni, koje podatke obrađuju, o kojim dobavljačima ovise, kako se sprječava zlouporaba, kako se incidenti otkrivaju i kako se usklađenost može dokazati.

Počnite s popisom API-ja

Većina neuspjeha API-ja počinje kao neuspjeh popisa imovine. Zastarjeli mobilni backend i dalje radi u produkciji. Privremena partnerska integracija postaje trajna. Funkcija u oblaku izlaže novu krajnju točku. Interni API postaje dostupan s interneta nakon promjene balansatora opterećenja. Ništa od toga ne pojavljuje se u CMDB-u, pa ništa od toga ne dobiva pregled autentifikacije, standarde zapisivanja događaja, pragove ograničavanja učestalosti zahtjeva, procjenu dobavljača ili klasifikaciju zadržavanja.

Prvo revizijsko pitanje obično je jednostavno: „Mogu li vidjeti vaš popis API-ja?“

Clarysec tretira popis API-ja kao dio popisa imovine ISMS-a. U Zenith Blueprint: 30-koračni plan za revizore Zenith Blueprint, u fazi Controls in Action, korak 22, smjernica za kontrolu ISO/IEC 27002:2022 5.9 objašnjava:

„Nijedna organizacija ne može zaštititi ono za što ne zna da posjeduje. Kontrola 5.9 formalizira ovo temeljno načelo i zahtijeva uspostavu i održavanje ažurnog popisa svih informacija i povezane imovine relevantne za ISMS.“

Isti korak uključuje logičku imovinu kao što su „korisnički računi, vjerodajnice, ključevi, softverske licence, API-ji“ te imovinu povezanu s uslugama kao što su SaaS platforme i eksternalizirana pohrana. Zenith Blueprint naziva popis „središnjim živčanim sustavom vašeg ISMS-a“ jer informira dodjelu pristupa, šifriranje, sigurnosno kopiranje, zapisivanje događaja, klasifikaciju i zadržavanje.

Clarysecova korporativna Politika upravljanja imovinom Politika upravljanja imovinom pretvara to u upravljački zahtjev:

„Voditelj IT imovine mora održavati sveobuhvatan i centraliziran popis imovine koji obuhvaća svu informacijsku imovinu koju organizacija koristi ili koja je povezana s organizacijom.“

Iz odjeljka „Zahtjevi za provedbu politike“, točka politike 6.1.1.

Za mala i srednja poduzeća, Clarysecova Politika upravljanja imovinom - MSP Politika upravljanja imovinom - MSP izričito uključuje digitalnu imovinu relevantnu za API-je:

„Digitalne vjerodajnice i usluge: nazivi domena, digitalni certifikati, API ključevi, računi e-pošte, prijave u oblak“

Iz odjeljka „Opseg“, točka politike 2.2.4.

Ta je formulacija važna. U mnogim revizijama krajnja točka API-ja nalazi se u pristupniku, token u trezoru tajnih vrijednosti, certifikat na računu u oblaku, a tok podataka u evidenciji privatnosti. Dokaziv popis API-ja povezuje sve te elemente.

U Zenith Controls: Vodič za višestruku usklađenost Zenith Controls, kontrola ISO/IEC 27002:2022 5.9, Popis informacija i druge povezane imovine, klasificirana je kao preventivna kontrola koja podržava povjerljivost, cjelovitost i dostupnost. Njezin koncept kibernetičke sigurnosti je Identify, operativna sposobnost je upravljanje imovinom, a sigurnosne domene su upravljanje, ekosustav i zaštita. To pomaže revizorima sagledati popis API-ja kao preventivnu upravljačku kontrolu, a ne kao administrativno održavanje.

Dokažite da je svaki API identitet namjeran

Nakon što popis postoji, sljedeće je pitanje predvidljivo: tko ili što može pozivati te API-je?

Moderni API-ji autentificiraju ljudske korisnike, mobilne aplikacije, servisne račune, CI/CD poslove, partnerske sustave, radna opterećenja, botove, integracije, podatkovne cjevovode i platforme trećih strana. Slabi API ključevi, dugovječni bearer tokeni, nedostajući uzajamni TLS, preširoki OAuth opsezi i tvrdo kodirane tajne vrijednosti stvaraju revizijsku izloženost.

Zenith Blueprint, u fazi Controls in Action, korak 19, obrađuje kontrolu ISO/IEC 27002:2022 8.5, Sigurna autentifikacija:

„Autentifikacija je prva i najkritičnija linija obrane između aktera prijetnje i vaših sustava, podataka i usluga. Ako je autentifikacija slaba, sve ostalo — šifriranje, praćenje, segmentacija — može se zaobići.“

Isti korak naglašava M2M autentifikaciju. Ključevi, certifikati i tokeni moraju se strogo štititi, vjerodajnice se ne smiju ugrađivati u kod, a za sigurnu pohranu i periodičnu promjenu treba koristiti upravljanje tajnama ili trezore.

Clarysecova korporativna Politika zahtjeva sigurnosti aplikacija Politika zahtjeva sigurnosti aplikacija izravno uvodi ovaj zahtjev u upravljanje API-jima:

„Sva sučelja za programiranje aplikacija (API), mikroservisi i vanjske integracije moraju biti zaštićeni putem:“

Iz odjeljka „Upravljački zahtjevi“, točka politike 5.3.

Zatim propisuje:

„Primjena snažne autentifikacije, kao što su OAuth 2.0 i uzajamni TLS“

Iz odjeljka „Upravljački zahtjevi“, točka politike 5.3.1.

Za manje organizacije, Clarysecova Politika zahtjeva sigurnosti aplikacija - MSP Politika zahtjeva sigurnosti aplikacija - MSP pruža polaznu osnovu:

„Kontrole autentifikacije: aplikacije moraju provoditi snažnu autentifikaciju, uključujući minimalnu složenost lozinke, zaključavanje računa nakon neuspjelih pokušaja i vremenska ograničenja sesije.“

Iz odjeljka „Zahtjevi za provedbu politike“, točka politike 6.1.1.2.

Za API-je pretvorite te zahtjeve u paket dokaza o autentifikaciji:

1. Popis API-ja filtriran prema API-jima izloženima internetu, partnerima, administratorskim API-jima i internim API-jima.
2. Matrica autentifikacije koja prikazuje OAuth 2.0, mTLS, potpisane zahtjeve, autorizatore pristupnika ili identitet servisne mreže.
3. Registar OAuth klijenata i opsega s vlasnikom, svrhom, istekom, odobrenjem i datumom posljednjeg pregleda.
4. Dokazi o upravljanju tajnama koji prikazuju pohranu, pristup, periodičnu promjenu i opoziv.
5. Pregled privilegiranog API pristupa za administratorske krajnje točke i produkcijske servisne račune.
6. Dnevnički zapisi neuspjele autentifikacije i pravila upozoravanja.
7. Rezultati testiranja za scenarije nedostajućeg tokena, isteklog tokena, pogrešne publike, pogrešnog opsega i ponovljenog zahtjeva.

U Zenith Controls, kontrola ISO/IEC 27002:2022 8.5, Sigurna autentifikacija, mapirana je kao preventivna kontrola koja podržava povjerljivost, cjelovitost i dostupnost. Njezin koncept kibernetičke sigurnosti je Protect, operativna sposobnost je upravljanje identitetom i pristupom, a sigurnosna domena je zaštita.

NIS2 Članak 21 to podržava kroz kontrolu pristupa, kriptografiju i višefaktorsku ili kontinuiranu autentifikaciju gdje je primjenjivo. DORA očekuje od financijskih subjekata održavanje kontrola koje štite autentičnost, cjelovitost, dostupnost i povjerljivost. GDPR Članak 32 pretvara slabu autentifikaciju API-ja u pitanje sigurnosti obrade, osobito kada su osobni podaci izloženi.

Tretirajte ograničavanje učestalosti zahtjeva kao dokaz otpornosti

Snažna autentifikacija je nužna, ali nije dovoljna. Autentificirani klijent i dalje može zloupotrijebiti API. Napadači koriste API-je za credential stuffing, enumeraciju, scraping, token spraying, bombardiranje zahtjevima za resetiranje lozinke, zlouporabu transakcija i uskraćivanje usluge.

Ograničavanje učestalosti zahtjeva nekada se smatralo značajkom performansi. U 2026. ono je dokaz sigurnosti, privatnosti i otpornosti.

Clarysecova Politika zahtjeva sigurnosti aplikacija navodi:

„Ograničavanje brzine zahtjeva i sprječavanje zlouporabe“

Iz odjeljka „Upravljački zahtjevi“, točka politike 5.3.2.

Zenith Blueprint, u fazi Controls in Action, korak 20, za kontrolu ISO/IEC 27002:2022 8.26, Zahtjevi sigurnosti aplikacija, objašnjava da zahtjevi sigurnosti aplikacija moraju biti precizni i provedivi. Postavlja pitanje treba li aplikacija biti otporna na napade ubacivanjem, brute-force prijave ili pokušaje uskraćivanja usluge. Navodi i API-specifičan primjer prema kojem novi API treba uključivati provjeru pristupnog tokena i sanitizaciju unosa te napominje da javno dostupne platforme mogu zahtijevati strožu provjeru, analitiku ponašanja korisnika i ograničavanje učestalosti zahtjeva.

Dokaziv zapis o ograničavanju učestalosti zahtjeva mora objasniti ne samo da ograničavanje postoji, nego i zašto su pragovi odabrani, tko je odobrio iznimke i kako se upozorenja prate.

Za NIS2 to podržava siguran razvoj, procjenu djelotvornosti, neprekidnost poslovanja i sprječavanje incidenata. Za DORA ograničavanje učestalosti zahtjeva povezuje se s upravljanjem IKT rizicima, otkrivanjem anomalija, testiranjem otpornosti i neprekidnošću kritičnih ili važnih funkcija. Za GDPR podržava minimizaciju podataka i zaštitu od prekomjernog ili nezakonitog pristupa, osobito kada scraping API-ja može izložiti osobne podatke.

Učinite zapisivanje događaja slojem dokaza

Kada se dogodi API incident, prvo stvarno pitanje nije „Imate li SIEM?“ nego „Možete li rekonstruirati što se dogodilo?“

Dnevnički zapisi API-ja trebaju obuhvatiti neuspjele autentifikacije, odbijanja autorizacije, tvrdnje tokena, identitet klijenta, izvor, krajnju točku, metodu, ishod zahtjeva, administrativne promjene, pristup podacima visokog rizika, događaje ograničavanja učestalosti zahtjeva, abnormalan volumen, promjene konfiguracije i sigurnosno relevantne pogreške. Istodobno moraju izbjegavati zapisivanje tajnih vrijednosti, bearer tokena ili nepotrebnih osobnih podataka.

Zenith Blueprint, u fazi Controls in Action, korak 19, za kontrolu ISO/IEC 27002:2022 8.15, Zapisivanje događaja, navodi:

„Zapisivanje događaja krvotok je svakog sigurnog IT okruženja. Bez njega incidenti ostaju nevidljivi, odgovornost blijedi, a uzročno-posljedične veze nestaju.“

Također objašnjava da se zapisivanje događaja odnosi na sljedivost te da korisni dnevnički zapisi moraju biti sigurno pohranjeni, praćeni, pregledavani i zaštićeni od neovlaštene izmjene.

Clarysecova Politika zahtjeva sigurnosti aplikacija - MSP zahtijeva:

„Revizijsko bilježenje: aplikacije moraju bilježiti događaje autentifikacije (prijave, odjave i neuspjele pokušaje), pristup podacima i administrativne promjene.“

Iz odjeljka „Zahtjevi za provedbu politike“, točka politike 6.1.1.7.

Clarysecova Politika zapisivanja događaja i praćenja - MSP Politika zapisivanja događaja i praćenja - MSP uspostavlja kategoriju upravljanja zapisivanjem događaja:

„Obvezne vrste dnevničkih zapisa“

Iz odjeljka „Upravljački zahtjevi“, točka politike 5.4.

Za API-je hostirane u oblaku, Clarysecova korporativna Politika korištenja usluga u oblaku Politika korištenja usluga u oblaku dodatno potvrđuje zahtjev:

„Dnevnički zapisi moraju obuhvatiti:“

Iz odjeljka „Zahtjevi za provedbu politike“, točka politike 6.5.2.

U Zenith Controls, kontrola ISO/IEC 27002:2022 8.15, Zapisivanje događaja, mapirana je kao detektivna kontrola koja podržava povjerljivost, cjelovitost i dostupnost. Njezin koncept kibernetičke sigurnosti je Detect, operativna sposobnost je upravljanje događajima informacijske sigurnosti, a sigurnosne domene su zaštita i obrana. To zapisivanje događaja čini mostom između politike i dokaza.

NIS2 Članak 23 zahtijeva fazno prijavljivanje značajnih incidenata: rano upozorenje u roku od 24 sata od saznanja, obavijest o incidentu u roku od 72 sata, privremena izvješća ako se zatraže i završno izvješće u roku od jednog mjeseca nakon obavijesti. Za pružatelje usluga povjerenja pogođene u pružanju usluga povjerenja, obavijest je potrebna u roku od 24 sata od saznanja.

DORA Članci 17 do 19 zahtijevaju upravljanje incidentima povezanima s IKT-om uz pokazatelje ranog upozorenja, klasifikaciju ozbiljnosti i kritičnosti, eskalaciju, zapisivanje događaja, praćenje temeljnog uzroka i prijavljivanje većih incidenata povezanih s IKT-om putem početnih, privremenih i završnih izvješća. Procjena povrede prema GDPR-u također ovisi o dnevničkim zapisima kako bi se utvrdilo jesu li osobni podaci bili pristupljeni, koje su osobe pogođene i pokreću li se obveze obavješćivanja.

Izgradite paket dokaza za API u pet radnih dana

Cilj brzog sprinta nije riješiti svu sigurnost API-ja u jednom tjednu. Cilj je uspostaviti dokazivu polaznu osnovu, identificirati praznine i pokrenuti obradu rizika.

1. dan: uspostavite registar API-ja

Izvezite rute iz API pristupnika, servisne mreže, balansatora opterećenja u oblaku, bezposlužiteljskih funkcija, OpenAPI repozitorija i CI/CD manifesta implementacije. Normalizirajte ih u jedinstveni registar API-ja s krajnjom točkom, okruženjem, vlasnikom, poslovnim procesom, klasifikacijom podataka, pokazateljem osobnih podataka, metodom autentifikacije, ograničenjem učestalosti zahtjeva, statusom zapisivanja događaja, ovisnošću o dobavljaču, kritičnošću i datumom posljednjeg pregleda.

Koristite točku 6.1.1 Politike upravljanja imovinom i korak 22 iz Zenith Blueprint kao upravljačko uporište.

2. dan: klasificirajte praznine u autentifikaciji

Izradite matricu autentifikacije. Označite API-je koji koriste statične API ključeve, dugovječne tokene, nemaju provjeru publike, nemaju provjeru opsega, nemaju mTLS za partnerske integracije, koriste dijeljene servisne račune ili nemaju dokaze o periodičnoj promjeni.

Mapirajte nalaze na točku 5.3.1 Politike zahtjeva sigurnosti aplikacija i korak 19 iz Zenith Blueprint. Zabilježite svaku prazninu kao rizik s vlasnikom, putem obrade rizika i ciljnim datumom.

3. dan: dokažite ograničavanje učestalosti zahtjeva i kontrole zlouporabe

Za javne, partnerske i administratorske API-je prikupite politike pristupnika, WAF pravila, kontrole botova, postavke kvota i pragove upozoravanja. Ako kontrole ne postoje, evidentirajte kompenzacijske kontrole ili otvorenu obradu rizika.

Koristite točku 5.3.2 Politike zahtjeva sigurnosti aplikacija kao ovlašteni izvor politike. Za kritične API-je povežite pragove s utjecajem na uslugu, štetom za klijente i očekivanjima otpornosti prema DORA ili NIS2.

4. dan: provjerite pokrivenost zapisivanjem događaja

Uzorkujte dnevničke zapise za API-je visokog rizika. Potvrdite da dnevnički zapisi obuhvaćaju uspješnu autentifikaciju, neuspjelu autentifikaciju, odbijanje autorizacije, pristup podacima, administratorsku promjenu, događaj ograničavanja učestalosti zahtjeva, identitet izvora i korelacijski ID. Provjerite sinkronizaciju vremena, zadržavanje, kontrolu pristupa i zaštitu od neovlaštene izmjene.

Ako dnevnički zapisi sadrže tokene, tajne vrijednosti ili prekomjerne osobne podatke, otvorite stavke za korektivne radnje u području privatnosti i sigurnosti.

5. dan: isporučite paket odgovora za reviziju

Isporučite sažet skup dokaza:

• Izvoz popisa API-ja i sažetak vlasništva.
• Registar rizika API-ja s planom obrade rizika.
• Matrica autentifikacije i dokazi pregleda tokena.
• Dokazi o ograničavanju učestalosti zahtjeva i odobrene iznimke.
• Izvješće o pokrivenosti zapisivanjem događaja i snimke zaslona SIEM nadzornih ploča.
• Operativne upute za klasifikaciju incidenata zlouporabe API-ja.
• Mapiranje višestruke usklađenosti na revizijske prikaze za ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT.

Važan pomak je u tome da svaki artefakt ima priču o kontroli. Registar API-ja podržava upravljanje imovinom. Autentifikacija podržava kontrolu pristupa. Ograničenja učestalosti zahtjeva podržavaju sigurnost aplikacija i otpornost. Dnevnički zapisi podržavaju otkrivanje, odgovor na incidente i odgovornost.

Mapiranje višestruke usklađenosti za upravljanje API-jima

Najveća pogreška jest izgradnja zasebnih skupova dokaza za svaki okvir. Upravljanje API-jima bolje funkcionira kao jedan model kontrola s više regulatornih prikaza.

ISO/IEC 27001:2022 pruža sustav upravljanja koji drži dokaze zajedno. Točke 4.1 do 4.4 zahtijevaju da organizacija definira kontekst i opseg ISMS-a, uključujući zainteresirane strane, pravne, regulatorne i ugovorne obveze te sučelja ili ovisnosti s drugim organizacijama. Točke 5.1 do 5.3 stavljaju odgovornost na najviše rukovodstvo. Točke 6.1.1 do 6.1.3 uspostavljaju proces procjene rizika, obrade rizika i Izjave o primjenjivosti. Točka 8.1 zahtijeva operativno planiranje i kontrolu, uključujući kontrolu nad vanjski pruženim procesima, proizvodima ili uslugama relevantnima za ISMS.

Za upravljanje API-jima to znači da API za plaćanja treće strane, API identiteta u oblaku ili eksternalizirani API za otkrivanje prijevara nije izvan usklađenosti zato što je vanjski. To je sučelje i ovisnost koja mora biti obuhvaćena opsegom, procijenjena prema riziku i kontrolirana.

NIST CSF 2.0 dodaje koristan prikaz za izvršno rukovodstvo. Njegova funkcija GOVERN pomaže organizacijama definirati očekivanja dionika, pravne obveze, apetit za rizik i rizik opskrbnog lanca. Njegov pristup profilima podržava trenutačni profil, ciljni profil, prioritizirani plan praznina i ciklus kontinuiranog poboljšanja. Upravo tako treba funkcionirati sprint upravljanja API-jima.

COBIT 2019 može podržati upravljačku perspektivu povezivanjem API kontrola s ciljevima upravljanja, vlasništvom nad kontrolama, neprekidnošću usluge, praćenjem sigurnosti, izvješćivanjem o rizicima i praćenjem otvorenih pitanja. Ključno nije prisilno smjestiti API-je u jedan okvir, nego pokazati da jedan model dokaza odgovara na više pitanja osiguranja.

Kako revizori testiraju upravljanje API-jima

Snažan program anticipira revizorsku perspektivu. Isti dokazi testirat će se različito ovisno o okviru.

Clarysec preporučuje triangulaciju dokaza. Nemojte pokazati samo politiku. Pokažite politiku, dokaze o provedbi i operativne dokaze.

Na primjer:

• Politika: API-ji moraju koristiti OAuth 2.0 ili mTLS gdje je primjenjivo.
• Konfiguracija: ruta API pristupnika prikazuje JWT provjeru i dopuštenu publiku.
• Operativni dokaz: neuspjeli pokušaji s tokenom bilježe se i upozoravanje je aktivno.
• Dokaz pregleda: pregled OAuth klijenta dovršen je uz odobrenje vlasnika.
• Dokaz rizika: iznimka za naslijeđeni API ima kompenzacijske kontrole i rok obrade rizika.

To je znatno snažnije od odgovora temeljenog samo na snimkama zaslona.

Uobičajene zamke u upravljanju API-jima

Najčešći problem nije da su API-ji potpuno nezaštićeni. Problem je u tome što je sigurnost nedosljedna.

Jedan tim dobro koristi OAuth opsege, drugi koristi dijeljeni API ključ. Jedna usluga zapisuje pristup podacima, druga zapisuje samo pogreške poslužitelja. Jedna partnerska integracija ima mTLS, druga se oslanja na dugovječni bearer token. Ograničenja učestalosti zahtjeva postoje za javne krajnje točke, ali ne i za autentificirane klijentske API-je gdje se može dogoditi scraping. CMDB navodi aplikaciju, ali ne i njezine API-je, tokene, certifikate, kategorije podataka ili dobavljače.

Ponavljajuće zamke uključuju:

• Shadow API-je implementirane putem bezposlužiteljskih funkcija ili privremenih testnih ruta.
• API ključeve pohranjene u CI/CD varijablama bez dokumentirane periodične promjene.
• Zapisivanje događaja koje obuhvaća tokene, tajne vrijednosti ili nepotrebne osobne podatke.
• Nepostojanje korelacijskog ID-a kroz dnevničke zapise pristupnika, aplikacije i baze podataka.
• Neformalno odobrene iznimke od ograničenja učestalosti zahtjeva za velike klijente.
• Partnerske API-je bez ugovorne obveze prijave incidenta ili prava na reviziju.
• Nepostojanje API-specifične klasifikacije incidenata za enumeraciju, scraping ili zlouporabu tokena.
• Nepostojanje mapiranja između tokova podataka API-ja i evidencija obrade prema GDPR-u.
• Sigurnosno testiranje usmjereno na web UI, dok API-ji ostaju netestirani.
• Izvješća odboru koja prikazuju „sigurnost aplikacija“ bez API-specifičnih metrika rizika.

To su rješivi problemi, ali samo ako organizacija tretira upravljanje API-jima kao upravljanu domenu kontrola.

Pretvorite sigurnost API-ja u upravljanje spremno za reviziju

Ako vaša sljedeća revizija zatraži dokaze o sigurnosti API-ja, nemojte početi prikupljanjem nasumičnih snimki zaslona. Počnite s pričom o kontroli.

Clarysec vam može pomoći izgraditi je uz:

• Zenith Blueprint Zenith Blueprint za strukturiranje provedbe kroz popis imovine, sigurnu autentifikaciju, zahtjeve sigurnosti aplikacija i zapisivanje događaja.
• Zenith Controls Zenith Controls za mapiranje kontrola ISO/IEC 27002:2022 kao što su 5.9, 8.5, 8.15 i 8.26 prema očekivanjima višestruke usklađenosti i revizijskim perspektivama.
• Clarysecove politike uključujući Politiku upravljanja imovinom Politika upravljanja imovinom, Politiku zahtjeva sigurnosti aplikacija Politika zahtjeva sigurnosti aplikacija, Politiku korištenja usluga u oblaku Politika korištenja usluga u oblaku, Politiku upravljanja imovinom - MSP Politika upravljanja imovinom - MSP, Politiku zahtjeva sigurnosti aplikacija - MSP Politika zahtjeva sigurnosti aplikacija - MSP i Politiku zapisivanja događaja i praćenja - MSP Politika zapisivanja događaja i praćenja - MSP.

Praktičan sljedeći korak je provesti Clarysec API Governance Evidence Sprint: popisati API-je, klasificirati autentifikaciju, provjeriti ograničavanje učestalosti zahtjeva, provjeriti zapisivanje događaja, mapirati ovisnosti o trećim stranama i izraditi paket dokaza spreman za ISO 27001 s revizijskim prikazima usklađenima s NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT-om.

API-ji su mjesto susreta poslovne logike, podataka klijenata i ovisnosti o trećim stranama. U 2026. zaslužuju više od tehničke zaštite. Potrebno im je upravljanje koje može izdržati reviziju, podržati odgovor regulatoru i pomoći vašim timovima da otkriju zlouporabu prije klijenata.