API saugumo valdysena: ISO 27001 įrodymai 2026 m.

API audito išvada, kuri atsiranda anksčiau nei saugumo pažeidimas

Maria, sparčiai augančios finansinių technologijų SaaS įmonės vyriausioji informacijos saugumo pareigūnė (CISO), likus trims savaitėms iki metinio vertinimo atidaro pagrindinio auditoriaus el. laišką. Žinutė tiesi:

„Atliksime išsamią jūsų IRT trečiųjų šalių rizikos valdymo sistemos ir jos suderinimo su DORA, NIS2 ir GDPR peržiūrą, ypatingą dėmesį skirdami jūsų API ekosistemai. Pateikite produkcinių ir partnerių API inventorių, autentifikavimo modelį, užklausų dažnio ribojimo įrodymus ir žurnalavimo aprėptį.“

Po dviejų dienų vidaus auditas atsiunčia antrą žinutę:

„Radome 47 viešuosius API galinius taškus, kurie nėra įtraukti į turto inventorių. Keturi priima API raktus be jų keitimo įrodymų. Viena partnerio integracija neturi užklausų dažnio ribojimo. Žurnalavimas produkcinėse paslaugose nenuoseklus. Iki penktadienio pateikite ISO 27001, GDPR ir NIS2 įrodymus.“

Nėra pranešimo apie išpirkos reikalaujančią programinę įrangą. Nėra viešai paskelbto pažeidimo. Nėra kliento skundo. Tačiau išvada rimta, nes ji atskleidžia valdysenos spragą, kurią užpuolikai jau išnaudoja. API dabar yra tikrasis perimetras. Jos jungia mokėjimus, klientų įtraukimą, tapatybę, klientų portalus, tiekėjų paslaugas, mobiliąsias programas, debesijos darbo krūvius, analitikos platformas ir išorinius rizikos vertinimo variklius.

Vos neįvykęs incidentas neleidžia šios problemos ignoruoti. Spaudžiamas laiko jaunesnysis kūrėjas atvėrė parengiamosios aplinkos API internetui be jokio autentifikavimo. Joje buvo realistiški, pseudonimizuoti klientų duomenys. Raudonoji komanda ją aptiko pirmoji, tačiau vadovybė uždavė akivaizdų klausimą: kas dar yra pasiekiama?

2026 m. API saugumo valdysena nėra vien kūrėjų kontrolinis sąrašas. CISO, atitikties vadovai, vidaus auditoriai ir valdybos turi įrodyti, kad API yra žinomos, turi savininkus, yra autentifikuojamos, stebimos, ribojamos pagal užklausų dažnį, testuojamos, įvertintos rizikos požiūriu ir įtrauktos į pranešimus apie incidentus. Tie patys įrodymai dažnai turi tenkinti ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 ir su COBIT suderintus patikinimo lūkesčius.

Dauguma organizacijų jau turi technines priemones: API šliuzus, tapatybės teikėjus, SIEM platformas, WAF, debesijos žurnalus, paslaugų tinklus, CI/CD konvejerius ir užklausų valdymo sistemas. Dažnai trūksta kontrolės priemonių naratyvo. Kurios API patenka į taikymo sritį? Kas tvirtina naujas API? Kurie žurnalai įrodo autentifikavimo nesėkmes? Kuris registras rodo priklausomybes nuo trečiųjų šalių API? Kodėl užklausų dažnio ribos skiriasi klientų, administratoriaus ir mašinų tarpusavio API?

Clarysec požiūris — API saugumo valdyseną traktuoti kaip kelių atitikties režimų įrodymų sistemą, o ne kaip vienkartinę inžinerinę veiklą. Jei API gali atskleisti duomenis, pakeisti verslo procesą, autentifikuoti naudotoją, inicijuoti mokėjimą, iškviesti tiekėją ar palaikyti reglamentuojamą paslaugą, ji turi būti įtraukta į ISVS įrodymų modelį.

Kodėl API valdysena dabar yra valdybos klausimas

NIS2 kibernetinio saugumo valdyseną paverčia valdymo organo atsakomybe. Article 20 reikalauja, kad valdymo organai patvirtintų kibernetinio saugumo rizikos valdymo priemones, prižiūrėtų jų įgyvendinimą ir gautų mokymus, kad galėtų suprasti kibernetines rizikas ir jų poveikį paslaugoms. Article 21 reikalauja tinkamų ir proporcingų techninių, veiklos ir organizacinių priemonių, įskaitant rizikos analizę, saugumo politikas, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų įsigijimą ir kūrimą, pažeidžiamumų valdymą, veiksmingumo vertinimą, kibernetinę higieną, kriptografiją, prieigos kontrolę, turto valdymą ir, kai tinkama, kelių veiksnių arba tęstinį autentifikavimą.

API valdysenos požiūriu tai reiškia, kad viešosios API, partnerių API, administratoriaus API ir vidinės mikropaslaugų API gali būti reglamentuojamos paslaugos teikimo dalis. NIS2 gali būti taikoma debesijos paslaugų teikėjams, duomenų centrų paslaugų teikėjams, turinio pristatymo tinklams, patikimumo užtikrinimo paslaugų teikėjams, viešiesiems elektroninių ryšių tinklams ir paslaugoms bei IRT paslaugų valdymo teikėjams, pavyzdžiui, MSP ir MSSP, priklausomai nuo sektoriaus, dydžio, kritiškumo ir valstybės narės klasifikavimo.

DORA prideda finansų sektoriaus perspektyvą. Ji taikoma nuo 2025 m. sausio 17 d. ir nustato vienodus reikalavimus IRT rizikos valdymui, pranešimui apie su IRT susijusius incidentus, skaitmeninio operacinio atsparumo testavimui, keitimuisi informacija ir IRT trečiųjų šalių rizikos valdymui. Article 5 reikalauja, kad valdymo organas apibrėžtų, patvirtintų, prižiūrėtų IRT rizikos valdymo sistemą ir liktų už ją atsakingas. Article 8 reikalauja identifikuoti, klasifikuoti ir dokumentuoti IRT palaikomas verslo funkcijas, informacijos išteklius, IRT turtą, priklausomybes, trečiųjų šalių palaikomus procesus, kritinį turtą, inventorius ir senosios IRT riziką.

API požiūriu mokėjimo inicijavimo API, sukčiavimo vertinimo API, klientų įtraukimo API ar išorinis KYC API nėra vien galinis taškas. Tai IRT turtas ir priklausomybė, palaikanti verslo funkciją.

GDPR užbaigia vaizdą. API, kurios perduoda identifikatorius, paskyrų duomenis, įrenginių ID, elgsenos telemetriją, biometrinius duomenis, su sveikata susijusius duomenis ar finansinius profilius, gali tvarkyti asmens duomenis. GDPR atskaitomybės principas reikalauja, kad duomenų valdytojai įrodytų atitiktį teisėtumo, tikslo apribojimo, duomenų kiekio mažinimo, saugojimo trukmės ribojimo, vientisumo ir konfidencialumo principams. Article 32 reikalauja tvarkymo saugumo, o Articles 33 ir 34 priklauso nuo patikimų įrodymų, kai įvyksta asmens duomenų saugumo pažeidimas.

Valdybai nereikia paketų užfiksavimo įrašų, bet jai reikia pasitikėjimo, kad organizacija žino, kurios API svarbios, kokius duomenis jos tvarko, nuo kurių tiekėjų priklauso, kaip užkertamas kelias piktnaudžiavimui, kaip aptinkami incidentai ir kaip galima pagrįsti atitiktį.

Pradėkite nuo API inventoriaus

Dauguma API nesėkmių prasideda nuo inventoriaus spragų. Nebenaudojama mobiliosios sistemos serverinė dalis vis dar veikia produkcinėje aplinkoje. Laikina partnerio integracija tampa nuolatine. Debesijos funkcija atveria naują galinį tašką. Vidinė API po apkrovos balansavimo pakeitimo tampa pasiekiama internetu. Nė viena iš jų neatsiranda CMDB, todėl nė viena negauna autentifikavimo peržiūros, žurnalavimo standartų, užklausų dažnio ribojimo slenksčių, tiekėjo vertinimo ar saugojimo klasifikacijos.

Pirmasis audito klausimas paprastai paprastas: „Ar galiu pamatyti jūsų API inventorių?“

Clarysec API inventorių laiko ISVS turto apskaitos dalimi. Zenith Blueprint: auditoriaus 30 žingsnių veiksmų plane Zenith Blueprint, „Kontrolės priemonės praktikoje“ etape, 22 žingsnyje, ISO/IEC 27002:2022 kontrolės 5.9 gairės paaiškina:

„Nė viena organizacija negali apsaugoti to, apie ką nežino. Kontrolė 5.9 formalizuoja šį pamatinį principą, reikalaudama sukurti ir palaikyti aktualią visos informacijos ir susijusio turto, reikšmingo ISVS, apskaitą.“

Tas pats žingsnis apima loginius turtus, tokius kaip „naudotojų paskyros, prisijungimo duomenys, raktai, programinės įrangos licencijos, API“, ir su paslaugomis susijusius turtus, pavyzdžiui, SaaS platformas ir išorines saugyklas. Zenith Blueprint turto apskaitą vadina „jūsų ISVS centrine nervų sistema“, nes ji informuoja prieigos suteikimą, šifravimą, atsargines kopijas, žurnalavimą, klasifikavimą ir saugojimą.

Clarysec įmonės Turto valdymo politika Turto valdymo politika tai paverčia valdysenos reikalavimu:

„IT turto valdytojas privalo palaikyti išsamią ir centralizuotą turto apskaitą, apimančią visus informacijos išteklius, kuriuos organizacija naudoja arba kurie yra prie jos prijungti.“

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.1.1.

MVĮ atveju Clarysec Turto valdymo politika - SME Turto valdymo politika - SME aiškiai apima API aktualų skaitmeninį turtą:

„Skaitmeniniai prisijungimo duomenys ir paslaugos: domenų vardai, skaitmeniniai sertifikatai, API raktai, el. pašto paskyros, debesijos prisijungimai“

Iš skyriaus „Taikymo sritis“, politikos punktas 2.2.4.

Ši formuluotė svarbi. Daugelyje auditų API galinis taškas matomas šliuze, prieigos raktas — paslapčių saugykloje, sertifikatas — debesijos paskyroje, o duomenų srautas — privatumo įraše. Pagrindžiamas API inventorius juos sujungia.

Zenith Controls: kelių atitikties režimų vadove Zenith Controls ISO/IEC 27002:2022 kontrolė 5.9, informacijos ir kito susijusio turto inventorius, klasifikuojama kaip prevencinė kontrolė, palaikanti konfidencialumą, vientisumą ir prieinamumą. Jos kibernetinio saugumo koncepcija yra Identify, veiklos pajėgumas — turto valdymas, o saugumo sritys — valdysena, ekosistema ir apsauga. Tai padeda auditoriams API inventorių matyti kaip prevencinę valdysenos kontrolę, o ne administracinę tvarką.

Įrodykite, kad kiekviena API tapatybė nustatyta sąmoningai

Kai inventorius egzistuoja, kitas klausimas nuspėjamas: kas arba kas konkrečiai gali kviesti šias API?

Šiuolaikinės API autentifikuoja žmones naudotojus, mobiliąsias programas, paslaugų paskyras, CI/CD užduotis, partnerių sistemas, darbo krūvius, botus, integracijas, duomenų konvejerius ir trečiųjų šalių platformas. Silpni API raktai, ilgai galiojantys nešlio prieigos raktai, trūkstamas abipusis TLS, perteklinės OAuth aprėptys ir programiškai įrašytos paslaptys sukuria audito riziką.

Zenith Blueprint, „Kontrolės priemonės praktikoje“ etape, 19 žingsnyje, nagrinėja ISO/IEC 27002:2022 kontrolę 8.5, Saugus autentifikavimas:

„Autentifikavimas yra pirmoji ir kritiškiausia gynybos linija tarp grėsmės veikėjo ir jūsų sistemų, duomenų bei paslaugų. Jei autentifikavimas silpnas, visa kita — šifravimas, stebėsena, segmentavimas — gali būti apeita.“

Tas pats žingsnis pabrėžia mašinų tarpusavio autentifikavimą. Raktai, sertifikatai ir prieigos raktai turi būti griežtai apsaugoti, prisijungimo duomenys neturi būti įterpiami į kodą, o saugiam saugojimui ir periodiniam keitimui turi būti naudojamas paslapčių valdymas arba saugyklos.

Clarysec įmonės Taikomųjų programų saugumo reikalavimų politika Taikomųjų programų saugumo reikalavimų politika tai tiesiogiai įtraukia į API valdyseną:

„Visos taikomųjų programų sąsajos (API), mikropaslaugos ir išorinės integracijos turi būti apsaugotos taikant:“

Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.3.

Toliau nurodoma:

„Stipraus autentifikavimo, pavyzdžiui, OAuth 2.0 ir abipusio TLS, taikymas“

Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.3.1.

Mažesnėms organizacijoms Clarysec Taikomųjų programų saugumo reikalavimų politika - SME Taikomųjų programų saugumo reikalavimų politika - SME pateikia bazinį reikalavimą:

„Autentifikavimo kontrolės priemonės: taikomosios programos privalo taikyti stiprų autentifikavimą, įskaitant minimalų slaptažodžio sudėtingumą, paskyros užrakinimą po nesėkmingų bandymų ir sesijų laiko limitus.“

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.1.1.2.

API atveju šiuos reikalavimus paverskite autentifikavimo įrodymų paketu:

1. API inventorius, filtruotas pagal į internetą nukreiptas, partneriams skirtas, administratoriaus ir vidines API.
2. Autentifikavimo matrica, rodanti OAuth 2.0, mTLS, pasirašytas užklausas, šliuzo autorizatorius arba paslaugų tinklo tapatybę.
3. OAuth klientų ir aprėpčių registras su savininku, tikslu, galiojimo pabaiga, patvirtinimu ir paskutinės peržiūros data.
4. Paslapčių valdymo įrodymai, rodantys saugojimą, prieigą, periodinį keitimą ir atšaukimą.
5. Privilegijuotos API prieigos peržiūra administratoriaus galiniams taškams ir produkcinės aplinkos paslaugų paskyroms.
6. Nesėkmingo autentifikavimo žurnalai ir įspėjimo taisyklės.
7. Testavimo rezultatai scenarijams, kai trūksta prieigos rakto, prieigos raktas pasibaigęs, neteisinga auditorija, neteisinga aprėptis ir vykdomos pakartojimo atakos.

Zenith Controls ISO/IEC 27002:2022 kontrolė 8.5, Saugus autentifikavimas, susiejama kaip prevencinė kontrolė, palaikanti konfidencialumą, vientisumą ir prieinamumą. Jos kibernetinio saugumo koncepcija yra Protect, veiklos pajėgumas — tapatybės ir prieigos valdymas, o saugumo sritis — apsauga.

NIS2 Article 21 tai palaiko per prieigos kontrolę, kriptografiją ir, kai tinkama, kelių veiksnių arba tęstinį autentifikavimą. DORA tikisi, kad finansų subjektai palaikys kontrolės priemones, saugančias autentiškumą, vientisumą, prieinamumą ir konfidencialumą. GDPR Article 32 silpną API autentifikavimą paverčia tvarkymo saugumo klausimu, ypač kai atskleidžiami asmens duomenys.

Užklausų dažnio ribojimą traktuokite kaip atsparumo įrodymą

Stiprus autentifikavimas būtinas, bet jo nepakanka. Autentifikuotas klientas vis tiek gali piktnaudžiauti API. Užpuolikai API naudoja prisijungimo duomenų užpildymo atakoms, išvardijimui, duomenų rinkimui, prieigos raktų purškimui, slaptažodžių atkūrimo bombardavimui, operacijų piktnaudžiavimui ir atsisakymo aptarnauti atakoms.

Užklausų dažnio ribojimas anksčiau buvo laikomas našumo funkcija. 2026 m. tai yra saugumo, privatumo ir atsparumo įrodymas.

Clarysec Taikomųjų programų saugumo reikalavimų politika nurodo:

„Užklausų dažnio ribojimas ir piktnaudžiavimo prevencija“

Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.3.2.

Zenith Blueprint, „Kontrolės priemonės praktikoje“ etape, 20 žingsnyje, skirtame ISO/IEC 27002:2022 kontrolei 8.26, Taikomųjų programų saugumo reikalavimai, paaiškina, kad taikomųjų programų saugumo reikalavimai turi būti tikslūs ir įgyvendinami. Jame klausiama, ar taikomoji programa turėtų būti atspari įterpimo atakoms, brutalios jėgos prisijungimo bandymams ar atsisakymo aptarnauti bandymams. Taip pat pateikiamas API specifinis pavyzdys, kad naujoje API turėtų būti prieigos rakto tikrinimas ir įvesties duomenų sanitarinis apdorojimas, ir pažymima, kad viešai prieinamos platformos gali reikalauti griežtesnio tikrinimo, naudotojų elgsenos analitikos ir užklausų dažnio ribojimo.

Pagrindžiamas užklausų dažnio ribojimo įrašas turi paaiškinti ne tik tai, kad ribojimas egzistuoja, bet ir kodėl pasirinkti slenksčiai, kas patvirtino išimtis ir kaip stebimi įspėjimai.

NIS2 atveju tai palaiko saugų kūrimą, veiksmingumo vertinimą, veiklos tęstinumą ir incidentų prevenciją. DORA atveju užklausų dažnio ribojimas susijęs su IRT rizikos valdymu, anomalijų aptikimu, atsparumo testavimu ir kritinių ar svarbių funkcijų tęstinumu. GDPR atveju tai palaiko duomenų kiekio mažinimą ir apsaugą nuo perteklinės ar neteisėtos prieigos, ypač kai API duomenų rinkimas galėtų atskleisti asmens duomenis.

Žurnalavimą paverskite įrodymų sluoksniu

Kai įvyksta API incidentas, pirmasis realus klausimas nėra „Ar turite SIEM?“ Jis yra „Ar galite atkurti, kas įvyko?“

API žurnalai turi fiksuoti autentifikavimo nesėkmes, autorizavimo atmetimus, prieigos raktų teiginius, kliento tapatybę, šaltinį, galinį tašką, metodą, užklausos rezultatą, administracinius pakeitimus, didelės rizikos duomenų prieigą, užklausų dažnio ribojimo įvykius, neįprastą apimtį, konfigūracijos pakeitimus ir saugumui reikšmingas klaidas. Jie taip pat neturi žurnaluose fiksuoti paslapčių, nešlio prieigos raktų ar nebūtinų asmens duomenų.

Zenith Blueprint, „Kontrolės priemonės praktikoje“ etape, 19 žingsnyje, skirtame ISO/IEC 27002:2022 kontrolei 8.15, Žurnalavimas, nurodo:

„Žurnalavimas yra bet kurios saugios IT aplinkos gyvybinė kraujotaka. Be jo incidentai lieka nematomi, atskaitomybė išnyksta, o priežasties ir pasekmės ryšiai pradingsta be pėdsako.“

Jame taip pat paaiškinama, kad žurnalavimas yra susijęs su atsekamumu, o naudingi žurnalai turi būti saugiai saugomi, stebimi, peržiūrimi ir apsaugoti nuo klastojimo.

Clarysec Taikomųjų programų saugumo reikalavimų politika - SME reikalauja:

„Registravimas audito žurnale: taikomosios programos privalo žurnaluose fiksuoti autentifikavimo įvykius (prisijungimus, atsijungimus ir nesėkmingus bandymus), duomenų prieigą ir administracinius pakeitimus.“

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.1.1.7.

Clarysec Žurnalų tvarkymo ir stebėsenos politika - SME Žurnalų tvarkymo ir stebėsenos politika - SME nustato žurnalavimo valdysenos kategoriją:

„Privalomi žurnalų tipai“

Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.4.

Debesijoje veikiančioms API Clarysec įmonės Debesijos paslaugų naudojimo politika Debesijos paslaugų naudojimo politika sustiprina reikalavimą:

„Žurnalai turi fiksuoti:“

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.5.2.

Zenith Controls ISO/IEC 27002:2022 kontrolė 8.15, Žurnalavimas, susiejama kaip aptikimo kontrolės priemonė, palaikanti konfidencialumą, vientisumą ir prieinamumą. Jos kibernetinio saugumo koncepcija yra Detect, veiklos pajėgumas — informacijos saugumo įvykių valdymas, o saugumo sritys — apsauga ir gynyba. Tai paverčia žurnalavimą tiltu tarp politikos ir įrodymo.

NIS2 Article 23 reikalauja etapinio pranešimo apie reikšmingus incidentus: ankstyvojo perspėjimo per 24 valandas nuo sužinojimo, pranešimo apie incidentą per 72 valandas, tarpinių ataskaitų, jei jų prašoma, ir galutinės ataskaitos per vieną mėnesį po pranešimo. Patikimumo užtikrinimo paslaugų teikėjams, paveiktiems teikiant patikimumo užtikrinimo paslaugas, pranešimas per 24 valandas nuo sužinojimo yra privalomas.

DORA Articles 17 to 19 reikalauja su IRT susijusių incidentų valdymo su ankstyvojo perspėjimo indikatoriais, sunkumo ir kritiškumo klasifikavimu, eskalavimu, žurnalavimu, pagrindinės priežasties tolesniu nagrinėjimu ir pranešimu apie reikšmingus su IRT susijusius incidentus per pradines, tarpines ir galutines ataskaitas. GDPR pažeidimo vertinimas taip pat priklauso nuo žurnalų, leidžiančių nustatyti, ar buvo pasiekti asmens duomenys, kurie asmenys paveikti ir ar kyla pranešimo pareigos.

Sukurkite API įrodymų paketą per penkias darbo dienas

Greito sprinto tikslas nėra per savaitę ištaisyti visą API saugumą. Tikslas — sukurti pagrindžiamą bazinį lygį, nustatyti spragas ir pradėti rizikos tvarkymą.

1 diena: sukurkite API registrą

Eksportuokite maršrutus iš API šliuzų, paslaugų tinklų, debesijos apkrovos balansavimo priemonių, funkcijų be serverio architektūros, OpenAPI saugyklų ir CI/CD diegimo manifestų. Normalizuokite juos į vieną API registrą su galiniu tašku, aplinka, savininku, verslo procesu, duomenų klasifikavimu, asmens duomenų indikatoriumi, autentifikavimo metodu, užklausų dažnio riba, žurnalavimo būsena, priklausomybe nuo tiekėjo, kritiškumu ir paskutinės peržiūros data.

Naudokite Turto valdymo politikos punktą 6.1.1 ir Zenith Blueprint 22 žingsnį kaip valdysenos pagrindą.

2 diena: klasifikuokite autentifikavimo spragas

Sukurkite autentifikavimo matricą. Pažymėkite API, naudojančias statinius API raktus, ilgai galiojančius prieigos raktus, neturinčias auditorijos tikrinimo, neturinčias aprėpties tikrinimo, neturinčias mTLS partnerių integracijoms, naudojančias bendras paslaugų paskyras arba neturinčias periodinio keitimo įrodymų.

Susiekite išvadas su Taikomųjų programų saugumo reikalavimų politikos punktu 5.3.1 ir Zenith Blueprint 19 žingsniu. Kiekvieną spragą įrašykite kaip riziką su savininku, tvarkymo keliu ir tiksline data.

3 diena: įrodykite užklausų dažnio ribojimą ir piktnaudžiavimo kontrolės priemones

Viešosioms, partnerių ir administratoriaus API užfiksuokite šliuzo politikas, WAF taisykles, botų kontrolės priemones, kvotų nustatymus ir įspėjimų slenksčius. Jei kontrolės priemonių nėra, įrašykite kompensuojančias kontrolės priemones arba atvirą rizikos tvarkymą.

Naudokite Taikomųjų programų saugumo reikalavimų politikos punktą 5.3.2 kaip politikos pagrindą. Kritinėms API susiekite slenksčius su poveikiu paslaugai, žala klientui ir DORA arba NIS2 atsparumo lūkesčiais.

4 diena: patikrinkite žurnalavimo aprėptį

Atrinkite didelės rizikos API žurnalų pavyzdžius. Patvirtinkite, kad žurnalai fiksuoja sėkmingą autentifikavimą, nesėkmingą autentifikavimą, autorizavimo atmetimą, duomenų prieigą, administratoriaus pakeitimą, užklausų dažnio ribojimo įvykį, šaltinio tapatybę ir koreliacijos ID. Patikrinkite laiko sinchronizavimą, saugojimą, prieigos kontrolę ir apsaugą nuo klastojimo.

Jei žurnaluose yra prieigos raktų, paslapčių ar perteklinių asmens duomenų, inicijuokite privatumo ir saugumo taisomuosius veiksmus.

5 diena: pateikite audito atsako paketą

Pateikite glaustą įrodymų rinkinį:

• API inventoriaus eksportas ir savininkystės santrauka.
• API rizikų registras su rizikos tvarkymo planu.
• Autentifikavimo matrica ir prieigos raktų peržiūros įrodymai.
• Užklausų dažnio ribojimo įrodymai ir patvirtintos išimtys.
• Žurnalavimo aprėpties ataskaita ir SIEM valdymo skydų ekrano kopijos.
• API piktnaudžiavimo incidentų klasifikavimo veiksmų planas.
• Kelių atitikties režimų susiejimas su ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 ir su COBIT suderintais audito pjūviais.

Svarbus pokytis yra tai, kad kiekvienas artefaktas turi kontrolės istoriją. API registras palaiko turto valdymą. Autentifikavimas palaiko prieigos kontrolę. Užklausų dažnio ribos palaiko taikomųjų programų saugumą ir atsparumą. Žurnalai palaiko aptikimą, reagavimą į incidentus ir atskaitomybę.

Kelių atitikties režimų susiejimas API valdysenai

Didžiausia klaida — kurti atskirus įrodymų rinkinius kiekvienai sistemai. API valdysena veikia geriau kaip vienas kontrolės modelis su keliais reglamentavimo pjūviais.

ISO/IEC 27001:2022 suteikia valdymo sistemą, kuri sujungia įrodymus. Clauses 4.1 to 4.4 reikalauja, kad organizacija apibrėžtų ISVS kontekstą ir taikymo sritį, įskaitant suinteresuotąsias šalis, teisines, reglamentavimo ir sutartines pareigas, taip pat sąsajas ar priklausomybes su kitomis organizacijomis. Clauses 5.1 to 5.3 atskaitomybę priskiria aukščiausiajai vadovybei. Clauses 6.1.1 to 6.1.3 sukuria rizikos vertinimo, rizikos tvarkymo ir Taikytinumo pareiškimo procesą. Clause 8.1 reikalauja veiklos planavimo ir kontrolės, įskaitant išorėje teikiamų procesų, produktų ar paslaugų, reikšmingų ISVS, kontrolę.

API valdysenos požiūriu tai reiškia, kad trečiosios šalies mokėjimo API, debesijos tapatybės API ar išorinis sukčiavimo aptikimo API nėra už atitikties ribų vien todėl, kad yra išorinis. Tai sąsaja ir priklausomybė, kuri turi būti įtraukta į taikymo sritį, įvertinta rizikos požiūriu ir kontroliuojama.

NIST CSF 2.0 prideda naudingą vadovybės pjūvį. Jo GOVERN funkcija padeda organizacijoms apibrėžti suinteresuotųjų šalių lūkesčius, teisines pareigas, rizikos apetitą ir tiekimo grandinės riziką. Jo profilių metodas palaiko esamą profilį, tikslinį profilį, prioritetizuotą spragų planą ir nuolatinio tobulinimo ciklą. Būtent taip turėtų veikti API valdysenos sprintas.

COBIT 2019 gali palaikyti valdymo perspektyvą susiedamas API kontrolės priemones su valdysenos tikslais, kontrolės priemonių savininkyste, paslaugų tęstinumu, saugumo stebėsena, rizikos ataskaitų teikimu ir problemų sekimu. Esmė nėra priverstinai įsprausti API į vieną sistemą, bet parodyti, kad vienas įrodymų modelis atsako į kelis patikinimo klausimus.

Kaip auditoriai testuoja API valdyseną

Stipri programa iš anksto numato auditoriaus perspektyvą. Tie patys įrodymai bus testuojami skirtingai, priklausomai nuo sistemos.

Clarysec rekomenduoja įrodymų trianguliaciją. Nerodykite vien tik politikos. Parodykite politiką, įgyvendinimo įrodymus ir veikimo įrodymus.

Pavyzdžiui:

• Politika: API turi naudoti OAuth 2.0 arba mTLS, kai tinkama.
• Konfigūracija: API šliuzo maršrutas rodo JWT tikrinimą ir leidžiamą auditoriją.
• Veikimo įrodymai: nesėkmingi prieigos raktų bandymai registruojami žurnaluose ir įspėjimai aktyvūs.
• Peržiūros įrodymai: OAuth kliento peržiūra baigta savininko patvirtinimu.
• Rizikos įrodymai: senosios API išimtis turi kompensuojančias kontrolės priemones ir tvarkymo terminą.

Tai daug stipriau nei atsakymas, paremtas vien ekrano kopijomis.

Dažnos API valdysenos klaidos

Dažniausia problema nėra ta, kad API visiškai neapsaugotos. Problema ta, kad saugumas nenuoseklus.

Viena komanda tinkamai naudoja OAuth aprėptis, kita naudoja bendrą API raktą. Viena paslauga žurnaluose fiksuoja duomenų prieigą, kita — tik serverio klaidas. Viena partnerio integracija turi mTLS, kita remiasi ilgai galiojančiu nešlio prieigos raktu. Užklausų dažnio ribos egzistuoja viešiesiems galiniams taškams, bet ne autentifikuotoms klientų API, kuriose gali vykti duomenų rinkimas. CMDB nurodo taikomąją programą, bet ne jos API, prieigos raktus, sertifikatus, duomenų kategorijas ar tiekėjus.

Pasikartojančios klaidos apima:

• Shadow API, įdiegtos per funkcijas be serverio architektūros arba laikinus testavimo maršrutus.
• API raktai, saugomi CI/CD kintamuosiuose be dokumentuoto periodinio keitimo.
• Žurnalavimas, fiksuojantis prieigos raktus, paslaptis ar nebūtinus asmens duomenis.
• Nėra koreliacijos ID tarp šliuzo, taikomosios programos ir duomenų bazės žurnalų.
• Užklausų dažnio ribojimo išimtys dideliems klientams suteikiamos neformaliai.
• Partnerių API trūksta sutartinio pranešimo apie incidentus arba audito teisių.
• Nėra API specifinio incidentų klasifikavimo išvardijimui, duomenų rinkimui ar prieigos raktų piktnaudžiavimui.
• Nėra susiejimo tarp API duomenų srautų ir GDPR tvarkymo įrašų.
• Saugumo testavimas sutelktas į žiniatinklio naudotojo sąsają, o API lieka netestuotos.
• Valdybos ataskaitose rodoma „taikomųjų programų sauga“ be API specifinių rizikos rodiklių.

Šias problemas galima išspręsti, bet tik jei organizacija API valdyseną traktuoja kaip valdomą kontrolės sritį.

Paverskite API saugumą auditui parengta valdysena

Jei kitas jūsų auditas paprašys API saugumo įrodymų, nepradėkite nuo atsitiktinių ekrano kopijų rinkimo. Pradėkite nuo kontrolės istorijos.

Clarysec gali padėti ją sukurti naudojant:

• Zenith Blueprint Zenith Blueprint, kad struktūruotumėte įgyvendinimą per turto apskaitą, saugų autentifikavimą, taikomųjų programų saugumo reikalavimus ir žurnalavimą.
• Zenith Controls Zenith Controls, kad susietumėte ISO/IEC 27002:2022 kontrolės priemones, tokias kaip 5.9, 8.5, 8.15 ir 8.26, su kelių atitikties režimų lūkesčiais ir audito perspektyvomis.
• Clarysec politikas, įskaitant Turto valdymo politiką Turto valdymo politika, Taikomųjų programų saugumo reikalavimų politiką Taikomųjų programų saugumo reikalavimų politika, Debesijos paslaugų naudojimo politiką Debesijos paslaugų naudojimo politika, Turto valdymo politiką - SME Turto valdymo politika - SME, Taikomųjų programų saugumo reikalavimų politiką - SME Taikomųjų programų saugumo reikalavimų politika - SME ir Žurnalų tvarkymo ir stebėsenos politiką - SME Žurnalų tvarkymo ir stebėsenos politika - SME.

Praktinis kitas žingsnis — vykdyti Clarysec API valdysenos įrodymų sprintą: inventorizuoti API, klasifikuoti autentifikavimą, patikrinti užklausų dažnio ribojimą, validuoti žurnalavimą, susieti priklausomybes nuo trečiųjų šalių ir parengti ISO 27001 tinkamą įrodymų paketą su NIS2, DORA, GDPR, NIST CSF 2.0 ir su COBIT suderintais audito pjūviais.

API yra vieta, kur susitinka verslo logika, klientų duomenys ir priklausomybės nuo trečiųjų šalių. 2026 m. joms reikia daugiau nei techninės apsaugos. Joms reikia valdysenos, kuri atlaikytų auditą, palaikytų atsaką reguliuotojui ir padėtų jūsų komandoms aptikti piktnaudžiavimą anksčiau nei klientai.