API drošības pārvaldība: ISO 27001 pierādījumi 2026. gadam

API audita konstatējums, kas pienāk pirms pārkāpuma

Marija, strauji augoša finanšu tehnoloģiju SaaS uzņēmuma informācijas drošības vadītāja (CISO), trīs nedēļas pirms ikgadējās izvērtēšanas atver e-pastu no vadošā auditora. Ziņojums ir tiešs:

“Mēs veiksim padziļinātu pārskatu par jūsu IKT trešo pušu risku pārvaldības ietvaru un tā saskaņotību ar DORA, NIS2 un GDPR, īpaši koncentrējoties uz jūsu API ekosistēmu. Lūdzu, iesniedziet produkcijas un partneru API uzskaiti, autentifikācijas modeli, pierādījumus par pieprasījumu biežuma ierobežošanu un žurnalēšanas pārklājumu.”

Divas dienas vēlāk iekšējais audits nosūta otru ziņojumu:

“Mēs konstatējām 47 publiskus API galapunktus, kas nav iekļauti aktīvu uzskaitē. Četri pieņem API atslēgas bez rotācijas pierādījumiem. Vienai partnera integrācijai nav pieprasījumu biežuma ierobežošanas. Produkcijas pakalpojumos žurnalēšana ir nekonsekventa. Lūdzu, līdz piektdienai iesniedziet ISO 27001, GDPR un NIS2 pierādījumus.”

Nav paziņojuma par izspiedējprogrammatūru. Nav publiska pārkāpuma. Nav klienta sūdzības. Tomēr konstatējums ir nopietns, jo tas atklāj pārvaldības trūkumu, ko uzbrucēji jau izmanto. API tagad ir faktiskais perimetrs. Tie savieno maksājumus, klientu uzņemšanas procesus, identitāti, klientu portālus, piegādātāju pakalpojumus, mobilās lietotnes, mākoņa darbslodzes, analītikas platformas un ārpakalpojumā nodotus riska izvērtēšanas dzinējus.

Gandrīz noticis incidents padara šo problēmu grūtāk ignorējamu. Jaunākais izstrādātājs, strādājot laika spiedienā, publicēja pirmsprodukcijas vides API internetā bez autentifikācijas. Tajā bija reālistiski, pseidonimizēti klientu dati. Sarkanā komanda to atrada pirmā, bet vadība uzdeva acīmredzamo jautājumu: kas vēl ir ārpusē?

2026. gadā API drošības pārvaldība nav tikai izstrādātāju kontrolsaraksts. Informācijas drošības vadītājiem, atbilstības vadītājiem, iekšējiem auditoriem un valdēm jāspēj pierādīt, ka API ir zināmi, tiem ir īpašnieki, tie ir autentificēti, uzraudzīti, ar piemērotu pieprasījumu biežuma ierobežošanu, testēti, risku ziņā izvērtēti un iekļauti incidentu ziņošanā. Tie paši pierādījumi bieži ir nepieciešami, lai izpildītu ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 un ar COBIT saskaņotas apliecinājuma prasības.

Lielākajai daļai organizāciju jau ir tehniskie rīki: API vārtejas, identitātes nodrošinātāji, SIEM platformas, WAF, mākoņa žurnāli, pakalpojumu režģi, CI/CD konveijeri un pieteikumu sistēmas. Bieži trūkst kontroles pasākumu naratīva. Kuri API ietilpst darbības jomā? Kas apstiprina jaunus API? Kuri žurnāli pierāda autentifikācijas atteices? Kurš reģistrs parāda trešo pušu API atkarības? Kāpēc pieprasījumu biežuma ierobežojumi klientu, administratoru un mašīna–mašīna (M2M) API atšķiras?

Clarysec pieeja API drošības pārvaldību aplūko kā starpatbilstības pierādījumu sistēmu, nevis kā vienreizēju inženiertehnisku aktivitāti. Ja API var eksponēt datus, mainīt biznesa procesu, autentificēt lietotāju, ierosināt maksājumu, izsaukt piegādātāju vai atbalstīt regulētu pakalpojumu, tam jābūt ISMS pierādījumu modelī.

Kāpēc API pārvaldība tagad ir valdes jautājums

NIS2 padara kiberdrošības pārvaldību par vadības struktūras atbildību. Article 20 prasa vadības struktūrām apstiprināt kiberdrošības risku pārvaldības pasākumus, pārraudzīt to ieviešanu un saņemt apmācību, lai tās saprastu kiberriskus un to ietekmi uz pakalpojumiem. Article 21 prasa atbilstošus un samērīgus tehniskus, operacionālus un organizatoriskus pasākumus, tostarp riska analīzi, drošības politikas, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, drošu iegādi un izstrādi, ievainojamību apstrādi, efektivitātes izvērtēšanu, kiberdrošības higiēnu, kriptogrāfiju, piekļuves kontroli, aktīvu pārvaldību un daudzfaktoru autentifikāciju vai nepārtrauktu autentifikāciju, ja tas ir piemēroti.

API pārvaldībā tas nozīmē, ka publiskie API, partneru API, administratoru API un iekšējie mikroservisu API var būt daļa no regulēta pakalpojuma sniegšanas. NIS2 var attiekties uz mākoņdatošanas pakalpojumu sniedzējiem, datu centru pakalpojumu sniedzējiem, satura piegādes tīkliem, uzticamības pakalpojumu sniedzējiem, publiskiem elektronisko sakaru tīkliem un pakalpojumiem, kā arī IKT pakalpojumu pārvaldības sniedzējiem, piemēram, MSP un MSSP, atkarībā no nozares, lieluma, kritiskuma un dalībvalsts klasifikācijas.

DORA pievieno finanšu sektora skatījumu. Tā ir piemērojama no 2025. gada 17. janvāra un nosaka vienotas prasības IKT risku pārvaldībai, ar IKT saistītu incidentu ziņošanai, digitālās darbības noturības testēšanai, informācijas apmaiņai un IKT trešo pušu risku pārvaldībai. Article 5 prasa vadības struktūrai definēt, apstiprināt, pārraudzīt IKT risku pārvaldības ietvaru un saglabāt atbildību par to. Article 8 prasa identificēt, klasificēt un dokumentēt ar IKT atbalstītas biznesa funkcijas, informācijas aktīvus, IKT aktīvus, atkarības, trešo pušu atbalstītus procesus, kritiskos aktīvus, uzskaites un mantoto IKT risku.

API kontekstā maksājuma iniciēšanas API, krāpšanas novērtēšanas API, klientu uzņemšanas API vai ārpakalpojumā nodots KYC API nav tikai galapunkts. Tas ir IKT aktīvs un atkarība, kas atbalsta biznesa funkciju.

GDPR papildina kopainu. API, kas pārsūta identifikatorus, konta datus, ierīču ID, uzvedības telemetriju, biometriskos datus, ar veselību saistītus datus vai finanšu profilus, var apstrādāt personas datus. GDPR pārskatatbildības princips prasa pārziņiem pierādīt atbilstību likumīgumam, nolūka ierobežojumam, datu minimizēšanai, glabāšanas ierobežojumam, integritātei un konfidencialitātei. Article 32 prasa apstrādes drošību, savukārt Articles 33 and 34 balstās uz uzticamiem pierādījumiem, ja notiek personas datu aizsardzības pārkāpums.

Valdei nav vajadzīgi pakešu tvērumi, bet tai ir nepieciešama pārliecība, ka organizācija zina, kuri API ir būtiski, kādus datus tie apstrādā, no kuriem piegādātājiem tie ir atkarīgi, kā tiek novērsta ļaunprātīga izmantošana, kā tiek atklāti incidenti un kā var pierādīt atbilstību.

Sāciet ar API uzskaiti

Lielākā daļa API kļūmju sākas kā uzskaites kļūmes. Novecojis mobilais backend joprojām darbojas produkcijas vidē. Pagaidu partnera integrācija kļūst pastāvīga. Mākoņfunkcija eksponē jaunu galapunktu. Iekšējs API kļūst pieejams internetā pēc slodzes balansētāja izmaiņām. Nekas no tā neparādās CMDB, tāpēc nekam no tā netiek veikta autentifikācijas pārskatīšana, netiek piemēroti žurnalēšanas standarti, pieprasījumu biežuma ierobežošanas sliekšņi, piegādātāju izvērtēšana vai glabāšanas klasifikācija.

Pirmais audita jautājums parasti ir vienkāršs: “Vai varu redzēt jūsu API uzskaiti?”

Clarysec API uzskati uzskata par daļu no ISMS aktīvu uzskaites. Zenith Blueprint: auditora 30 soļu ceļvedī Zenith Blueprint, Controls in Action fāzē, Step 22, ISO/IEC 27002:2022 kontroles pasākuma 5.9 vadlīnijas skaidro:

“Neviena organizācija nevar aizsargāt to, par ko tā nezina, ka tai tas ir. 5.9 kontroles pasākums formalizē šo pamatprincipu, pieprasot izveidot un uzturēt aktuālu visu ISMS būtisko informācijas un saistīto aktīvu uzskaiti.”

Tas pats solis ietver loģiskos aktīvus, piemēram, “lietotāju kontus, autentifikācijas datus, atslēgas, programmatūras licences, API”, un ar pakalpojumiem saistītus aktīvus, piemēram, SaaS platformas un ārpakalpojuma krātuves. Zenith Blueprint aktīvu uzskaiti sauc par “jūsu ISMS centrālo nervu sistēmu”, jo tā nodrošina informāciju piekļuves piešķiršanai, šifrēšanai, rezerves kopiju veidošanai, žurnalēšanai, klasifikācijai un glabāšanai.

Clarysec uzņēmuma Aktīvu pārvaldības politika Aktīvu pārvaldības politika to pārvērš pārvaldības prasībā:

“IT aktīvu pārvaldniekam ir jāuztur visaptveroša un centralizēta aktīvu uzskaite, kas aptver visus informācijas aktīvus, kurus organizācija izmanto vai kuri ir savienoti ar organizāciju.”

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.1.

SME vajadzībām Clarysec Aktīvu pārvaldības politika - SME Aktīvu pārvaldības politika - SME skaidri ietver API būtiskus digitālos aktīvus:

“Digitālie autentifikācijas dati un pakalpojumi: domēna vārdi, digitālie sertifikāti, API atslēgas, e-pasta konti, mākoņa pieteikšanās dati”

No sadaļas “Piemērošanas joma”, politikas punkts 2.2.4.

Šai frāzei ir nozīme. Daudzos auditos API galapunkts parādās vārtejā, marķieris — noslēpumu krātuvē, sertifikāts — mākoņpakalpojumu kontā, bet datu plūsma — privātuma ierakstā. Auditā aizstāvama API uzskaite tos savieno.

Zenith Controls: starpatbilstības ceļvedī Zenith Controls ISO/IEC 27002:2022 kontroles pasākums 5.9, informācijas un citu saistīto aktīvu uzskaite, ir klasificēts kā preventīvs kontroles pasākums, kas atbalsta konfidencialitāti, integritāti un pieejamību. Tā kiberdrošības koncepts ir Identify, operacionālā spēja ir aktīvu pārvaldība, un drošības jomas ir pārvaldība, ekosistēma un aizsardzība. Tas palīdz auditoriem API uzskaiti uztvert kā preventīvu pārvaldības kontroli, nevis administratīvu kārtības uzturēšanu.

Pierādiet, ka katra API identitāte ir apzināta

Kad uzskaite ir izveidota, nākamais jautājums ir paredzams: kas vai kas drīkst izsaukt šos API?

Mūsdienu API autentificē cilvēkus lietotājus, mobilās lietotnes, pakalpojumu kontus, CI/CD uzdevumus, partneru sistēmas, darbslodzes, botus, integrācijas, datu konveijerus un trešo pušu platformas. Vājas API atslēgas, ilgdzīvojoši nesēja marķieri, trūkstošs savstarpējs TLS, pārmērīgi plašas OAuth darbības jomas un kodā iestrādāti noslēpumi rada audita risku.

Zenith Blueprint, Controls in Action fāze, Step 19, aplūko ISO/IEC 27002:2022 kontroles pasākumu 8.5, droša autentifikācija:

“Autentifikācija ir pirmā un kritiskākā aizsardzības līnija starp apdraudējuma izraisītāju un jūsu sistēmām, datiem un pakalpojumiem. Ja autentifikācija ir vāja, visu pārējo — šifrēšanu, uzraudzību, segmentēšanu — var apiet.”

Tas pats solis izceļ mašīna–mašīna (M2M) autentifikāciju. Atslēgas, sertifikāti un marķieri ir stingri jāaizsargā, autentifikācijas datus nedrīkst iestrādāt kodā, un drošai glabāšanai un rotācijai jāizmanto noslēpumu pārvaldība vai seifi.

Clarysec uzņēmuma Lietojumprogrammu drošības prasību politika Lietojumprogrammu drošības prasību politika to tieši ievieš API pārvaldībā:

“Visas lietojumprogrammu saskarnes (API), mikroservisi un ārējās integrācijas ir jāaizsargā, izmantojot:”

No sadaļas “Pārvaldības prasības”, politikas punkts 5.3.

Pēc tam tā nosaka:

“Stipras autentifikācijas piemērošana, piemēram, OAuth 2.0 un savstarpējs TLS”

No sadaļas “Pārvaldības prasības”, politikas punkts 5.3.1.

Mazākām organizācijām Clarysec Lietojumprogrammu drošības prasību politika - SME Lietojumprogrammu drošības prasību politika - SME nodrošina pamatprasības:

“Autentifikācijas kontroles pasākumi: lietojumprogrammām ir jāpiemēro stipra autentifikācija, tostarp minimālais paroles stiprums, konta bloķēšana pēc neveiksmīgiem mēģinājumiem un sesiju taimauti.”

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.1.2.

API vajadzībām pārvērtiet šīs prasības autentifikācijas pierādījumu kopā:

1. API uzskaite, filtrēta pēc internetam pieejamiem, partneriem pieejamiem, administratoru un iekšējiem API.
2. Autentifikācijas matrica, kas parāda OAuth 2.0, mTLS, parakstītus pieprasījumus, vārtejas autorizatorus vai pakalpojumu režģa identitāti.
3. OAuth klientu un darbības jomu reģistrs ar īpašnieku, nolūku, derīguma termiņu, apstiprinājumu un pēdējās pārskatīšanas datumu.
4. Noslēpumu pārvaldības pierādījumi, kas parāda glabāšanu, piekļuvi, rotāciju un atsaukšanu.
5. Priviliģētas API piekļuves pārskatīšana administratoru galapunktiem un produkcijas pakalpojumu kontiem.
6. Neveiksmīgas autentifikācijas žurnāli un brīdinājumu noteikumi.
7. Testēšanas rezultāti scenārijiem ar trūkstošu marķieri, marķieri ar beigušos derīguma termiņu, nepareizu auditoriju, nepareizu darbības jomu un atkārtojuma uzbrukumu.

Zenith Controls ietvaros ISO/IEC 27002:2022 kontroles pasākums 8.5, droša autentifikācija, ir kartēts kā preventīvs kontroles pasākums, kas atbalsta konfidencialitāti, integritāti un pieejamību. Tā kiberdrošības koncepts ir Protect, operacionālā spēja ir identitātes un piekļuves pārvaldība, un drošības joma ir aizsardzība.

NIS2 Article 21 to atbalsta caur piekļuves kontroli, kriptogrāfiju un daudzfaktoru autentifikāciju vai nepārtrauktu autentifikāciju, ja tas ir piemēroti. DORA sagaida, ka finanšu subjekti uzturēs kontroles pasākumus, kas aizsargā autentiskumu, integritāti, pieejamību un konfidencialitāti. GDPR Article 32 pārvērš vāju API autentifikāciju par apstrādes drošības jautājumu, īpaši gadījumos, kad tiek eksponēti personas dati.

Uztveriet pieprasījumu biežuma ierobežošanu kā noturības pierādījumu

Stipra autentifikācija ir nepieciešama, bet ar to nepietiek. Autentificēts klients joprojām var ļaunprātīgi izmantot API. Uzbrucēji izmanto API akreditācijas datu pārbaudei ar nopludinātām parolēm, uzskaitīšanai, datu skrāpēšanai, marķieru izsmidzināšanai, paroles atiestatīšanas bombardēšanai, darījumu ļaunprātīgai izmantošanai un pakalpojuma atteicei.

Pieprasījumu biežuma ierobežošana agrāk tika uzskatīta par veiktspējas funkciju. 2026. gadā tā ir drošības, privātuma un noturības pierādījums.

Clarysec Lietojumprogrammu drošības prasību politika nosaka:

“Pieprasījumu biežuma ierobežošana un ļaunprātīgas izmantošanas novēršana”

No sadaļas “Pārvaldības prasības”, politikas punkts 5.3.2.

Zenith Blueprint, Controls in Action fāze, Step 20, attiecībā uz ISO/IEC 27002:2022 kontroles pasākumu 8.26, lietojumprogrammu drošības prasības, skaidro, ka lietojumprogrammu drošības prasībām jābūt precīzām un praktiski piemērojamām. Tas jautā, vai lietojumprogrammai jābūt noturīgai pret injekcijas uzbrukumiem, brutāla spēka pieteikšanās mēģinājumiem vai pakalpojuma atteices mēģinājumiem. Tas sniedz arī API specifisku piemēru, ka jaunam API jāietver piekļuves marķiera validācija un ievades sanitizācija, un norāda, ka publiski pieejamas platformas var prasīt stingrāku validāciju, lietotāju uzvedības analītiku un pieprasījumu biežuma ierobežošanu.

Auditā aizstāvamam pieprasījumu biežuma ierobežošanas ierakstam jāpaskaidro ne tikai tas, ka ierobežošana pastāv, bet arī kāpēc izvēlēti konkrētie sliekšņi, kas apstiprinājis izņēmumus un kā tiek uzraudzīti brīdinājumi.

NIS2 vajadzībām tas atbalsta drošu izstrādi, efektivitātes izvērtēšanu, darbības nepārtrauktību un incidentu novēršanu. DORA ietvaros pieprasījumu biežuma ierobežošana sasaistās ar IKT risku pārvaldību, anomāliju noteikšanu, noturības testēšanu un kritisku vai svarīgu funkciju nepārtrauktību. GDPR vajadzībām tā atbalsta datu minimizēšanu un aizsardzību pret pārmērīgu vai nelikumīgu piekļuvi, īpaši gadījumos, kad API skrāpēšana var eksponēt personas datus.

Padariet žurnalēšanu par pierādījumu slāni

Kad notiek API incidents, pirmais reālais jautājums nav “Vai jums ir SIEM?” Tas ir “Vai varat rekonstruēt notikušo?”

API žurnāliem jāfiksē autentifikācijas atteices, autorizācijas atteikumi, marķiera prasības, klienta identitāte, avots, galapunkts, metode, pieprasījuma iznākums, administratīvas izmaiņas, augsta riska datu piekļuve, pieprasījumu biežuma ierobežojuma notikumi, neparasts apjoms, konfigurācijas izmaiņas un drošībai būtiskas kļūdas. Tiem arī jāizvairās reģistrēt noslēpumus, nesēja marķierus vai nevajadzīgus personas datus.

Zenith Blueprint, Controls in Action fāze, Step 19, attiecībā uz ISO/IEC 27002:2022 kontroles pasākumu 8.15, žurnalēšana, nosaka:

“Žurnalēšana ir jebkuras drošas IT vides dzīvības artērija. Bez tās incidenti paliek neredzami, pārskatatbildība izzūd, un cēloņu un seku saites pazūd gaisā.”

Tas arī skaidro, ka žurnalēšana ir saistīta ar izsekojamību un ka noderīgi žurnāli ir droši jāglabā, jāuzrauga, jāpārskata un jāaizsargā pret manipulācijām.

Clarysec Lietojumprogrammu drošības prasību politika - SME prasa:

“Audita žurnālu veidošana: lietojumprogrammām jāreģistrē autentifikācijas notikumi (pieteikšanās, atteikšanās un neveiksmīgi mēģinājumi), datu piekļuve un administratīvās izmaiņas.”

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.1.7.

Clarysec Žurnalēšanas un uzraudzības politika - SME Žurnalēšanas un uzraudzības politika - SME nosaka žurnalēšanas pārvaldības kategoriju:

“Obligātie žurnālu veidi”

No sadaļas “Pārvaldības prasības”, politikas punkts 5.4.

Mākoņvidē izvietotiem API Clarysec uzņēmuma Mākoņpakalpojumu izmantošanas politika Mākoņpakalpojumu izmantošanas politika pastiprina prasību:

“Žurnāliem jāfiksē:”

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.5.2.

Zenith Controls ietvaros ISO/IEC 27002:2022 kontroles pasākums 8.15, žurnalēšana, ir kartēts kā atklājošs kontroles pasākums, kas atbalsta konfidencialitāti, integritāti un pieejamību. Tā kiberdrošības koncepts ir Detect, operacionālā spēja ir informācijas drošības notikumu pārvaldība, un drošības jomas ir aizsardzība un aizsardzības pasākumi. Tas padara žurnalēšanu par tiltu starp politiku un pierādījumu.

NIS2 Article 23 prasa pakāpenisku ziņošanu par būtiskiem incidentiem: agrīnu brīdinājumu 24 stundu laikā pēc informētības, incidenta paziņojumu 72 stundu laikā, starpziņojumus pēc pieprasījuma un galīgo ziņojumu viena mēneša laikā pēc paziņojuma. Uzticamības pakalpojumu sniedzējiem, kurus ietekmē uzticamības pakalpojuma sniegšana, paziņojums 24 stundu laikā pēc informētības ir obligāts.

DORA Articles 17 to 19 prasa ar IKT saistītu incidentu pārvaldību ar agrīna brīdinājuma indikatoriem, smaguma pakāpes un kritiskuma klasifikāciju, eskalāciju, žurnalēšanu, pamatcēloņa turpmāku novēršanu un nozīmīgu ar IKT saistītu incidentu ziņošanu sākotnējos, starpposma un galīgajos ziņojumos. GDPR pārkāpuma izvērtēšana arī balstās uz žurnāliem, lai noteiktu, vai personas datiem tika piekļūts, kuras personas tika ietekmētas un vai tiek iedarbināti paziņošanas pienākumi.

Izveidojiet API pierādījumu kopu piecās darba dienās

Ātrā sprinta mērķis nav vienas nedēļas laikā salabot visu API drošību. Mērķis ir izveidot aizstāvamu bāzlīniju, identificēt trūkumus un sākt risku apstrādi.

1. diena: izveidojiet API reģistru

Eksportējiet maršrutus no API vārtejām, pakalpojumu režģiem, mākoņa slodzes balansētājiem, serverless funkcijām, OpenAPI repozitorijiem un CI/CD ieviešanas manifestiem. Normalizējiet tos vienotā API reģistrā ar galapunktu, vidi, īpašnieku, biznesa procesu, datu klasifikāciju, personas datu indikatoru, autentifikācijas metodi, pieprasījumu biežuma ierobežojumu, žurnalēšanas statusu, piegādātāja atkarību, kritiskumu un pēdējās pārskatīšanas datumu.

Izmantojiet Aktīvu pārvaldības politika punktu 6.1.1 un Zenith Blueprint Step 22 kā pārvaldības pamatu.

2. diena: klasificējiet autentifikācijas trūkumus

Izveidojiet autentifikācijas matricu. Atzīmējiet API, kas izmanto statiskas API atslēgas, ilgdzīvojošus marķierus, neveic auditorijas validāciju, neveic darbības jomas validāciju, kam trūkst mTLS partneru integrācijām, kas izmanto koplietotus pakalpojumu kontus vai kam trūkst rotācijas pierādījumu.

Kartējiet konstatējumus uz Lietojumprogrammu drošības prasību politika punktu 5.3.1 un Zenith Blueprint Step 19. Reģistrējiet katru trūkumu kā risku ar īpašnieku, apstrādes ceļu un mērķa datumu.

3. diena: pierādiet pieprasījumu biežuma ierobežošanu un ļaunprātīgas izmantošanas kontroles

Publiskajiem, partneru un administratoru API fiksējiet vārtejas politikas, WAF noteikumus, botu kontroles, kvotu iestatījumus un brīdinājumu sliekšņus. Ja kontroles nav, reģistrējiet kompensējošos kontroles pasākumus vai atvērtu riska apstrādi.

Izmantojiet Lietojumprogrammu drošības prasību politika punktu 5.3.2 kā politikas mandātu. Kritiskajiem API sasaistiet sliekšņus ar ietekmi uz pakalpojumu, kaitējumu klientam un DORA vai NIS2 noturības gaidām.

4. diena: validējiet žurnalēšanas pārklājumu

Izvēlieties augsta riska API žurnālu izlasi. Apstipriniet, ka žurnāli fiksē veiksmīgu autentifikāciju, neveiksmīgu autentifikāciju, autorizācijas atteikumu, datu piekļuvi, administratora izmaiņu, pieprasījumu biežuma ierobežojuma notikumu, avota identitāti un korelācijas ID. Pārbaudiet laika sinhronizāciju, glabāšanu, piekļuves kontroli un aizsardzību pret manipulācijām.

Ja žurnāli satur marķierus, noslēpumus vai pārmērīgus personas datus, izveidojiet privātuma un drošības trūkumu novēršanas uzdevumus.

5. diena: iesniedziet audita atbildes pakotni

Iesniedziet kodolīgu pierādījumu kopu:

• API uzskaites eksports un īpašumtiesību kopsavilkums.
• API risku reģistrs ar risku apstrādes plānu.
• Autentifikācijas matrica un marķieru pārskatīšanas pierādījumi.
• Pieprasījumu biežuma ierobežošanas pierādījumi un apstiprinātie izņēmumi.
• Žurnalēšanas pārklājuma pārskats un SIEM informācijas paneļu ekrānuzņēmumi.
• Incidentu klasifikācijas rokasgrāmata API ļaunprātīgai izmantošanai.
• Starpatbilstības kartējums uz ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 un ar COBIT saskaņotiem audita skatījumiem.

Svarīgā pāreja ir tā, ka katram artefaktam ir kontroles stāsts. API reģistrs atbalsta aktīvu pārvaldību. Autentifikācija atbalsta piekļuves kontroli. Pieprasījumu biežuma ierobežojumi atbalsta lietojumprogrammu drošību un noturību. Žurnāli atbalsta atklāšanu, reaģēšanu uz incidentiem un pārskatatbildību.

Starpatbilstības kartējums API pārvaldībai

Lielākā kļūda ir veidot atsevišķas pierādījumu kopas katram ietvaram. API pārvaldība labāk darbojas kā viens kontroles modelis ar vairākiem regulatīvajiem skatījumiem.

ISO/IEC 27001:2022 nodrošina pārvaldības sistēmu, kas satur pierādījumus kopā. Clauses 4.1 to 4.4 prasa organizācijai definēt ISMS kontekstu un darbības jomu, tostarp ieinteresētās puses, tiesiskos, regulatīvos un līgumiskos pienākumus, kā arī saskarnes vai atkarības ar citām organizācijām. Clauses 5.1 to 5.3 piešķir pārskatatbildību augstākajai vadībai. Clauses 6.1.1 to 6.1.3 izveido riska novērtēšanas metodoloģiju, risku apstrādi un piemērojamības deklarācijas (SoA) procesu. Clause 8.1 prasa darbības plānošanu un kontroli, tostarp kontroli pār ārēji nodrošinātiem procesiem, produktiem vai pakalpojumiem, kas ir būtiski ISMS.

API pārvaldībā tas nozīmē, ka trešās puses maksājumu API, mākoņa identitātes API vai ārpakalpojumā nodots krāpšanas atklāšanas API nav ārpus atbilstības tikai tāpēc, ka tas ir ārējs. Tā ir saskarne un atkarība, kas jāiekļauj darbības jomā, jāizvērtē pēc riska un jākontrolē.

NIST CSF 2.0 pievieno noderīgu vadības skatījumu. Tā GOVERN funkcija palīdz organizācijām definēt iesaistīto pušu gaidas, juridiskos pienākumus, riska apetīti un piegādes ķēdes risku. Tā Profiles pieeja atbalsta Current Profile, Target Profile, prioritizētu trūkumu plānu un nepārtrauktas uzlabošanas ciklu. Tieši tā jādarbojas API pārvaldības sprintam.

COBIT 2019 var atbalstīt pārvaldības skatījumu, sasaistot API kontroles ar pārvaldības mērķiem, kontroles pasākumu īpašniekiem, pakalpojumu nepārtrauktību, drošības uzraudzību, riska ziņošanu un problēmu izsekošanu. Galvenais nav piespiest API vienā ietvarā, bet parādīt, ka viens pierādījumu modelis atbild uz vairākiem apliecinājuma jautājumiem.

Kā auditori testē API pārvaldību

Spēcīga programma paredz auditora skatījumu. Tie paši pierādījumi tiks testēti atšķirīgi atkarībā no ietvara.

Clarysec iesaka pierādījumu triangulāciju. Nerādiet tikai politiku. Rādiet politiku, ieviešanas pierādījumus un darbības pierādījumus.

Piemēram:

• Politika: API jāizmanto OAuth 2.0 vai mTLS, ja tas ir piemēroti.
• Konfigurācija: API vārtejas maršruts parāda JWT validāciju un atļauto auditoriju.
• Darbības pierādījumi: neveiksmīgi marķiera mēģinājumi tiek reģistrēti žurnālos un brīdināšana ir aktīva.
• Pārskatīšanas pierādījumi: OAuth klienta pārskatīšana pabeigta ar īpašnieka apstiprinājumu.
• Riska pierādījumi: mantota API izņēmumam ir kompensējošie kontroles pasākumi un apstrādes termiņš.

Tas ir daudz spēcīgāk nekā atbilde tikai ar ekrānuzņēmumiem.

Biežākās API pārvaldības nepilnības

Visbiežākā problēma nav tā, ka API ir pilnībā neaizsargāti. Problēma ir tā, ka drošība ir nekonsekventa.

Viena komanda labi izmanto OAuth darbības jomas, cita izmanto koplietotu API atslēgu. Viens pakalpojums reģistrē datu piekļuvi, cits reģistrē tikai servera kļūdas. Vienai partnera integrācijai ir mTLS, cita paļaujas uz ilgdzīvojošu nesēja marķieri. Pieprasījumu biežuma ierobežojumi pastāv publiskiem galapunktiem, bet ne autentificētiem klientu API, kur var notikt datu skrāpēšana. CMDB uzskaita lietojumprogrammu, bet ne tās API, marķierus, sertifikātus, datu kategorijas vai piegādātājus.

Atkārtotas nepilnības ietver:

• Ēnu IT API, kas izvietoti ar serverless funkcijām vai pagaidu testa maršrutiem.
• API atslēgas, kas glabātas CI/CD mainīgajos bez dokumentētas rotācijas.
• Žurnalēšana, kas fiksē marķierus, noslēpumus vai nevajadzīgus personas datus.
• Nav korelācijas ID starp vārtejas, lietojumprogrammas un datubāzes žurnāliem.
• Pieprasījumu biežuma ierobežojumu izņēmumi lieliem klientiem piešķirti neformāli.
• Partneru API trūkst līgumisku prasību par paziņošanu par pārkāpumu vai audita tiesībām.
• Nav API specifiskas incidentu klasifikācijas uzskaitīšanai, skrāpēšanai vai marķieru ļaunprātīgai izmantošanai.
• Nav kartējuma starp API datu plūsmām un GDPR apstrādes ierakstiem.
• Drošības testēšana koncentrējas uz tīmekļa UI, kamēr API paliek netestēti.
• Valdes ziņojumi rāda “lietojumprogrammu drošību” bez API specifiskiem riska rādītājiem.

Šīs problēmas ir risināmas, bet tikai tad, ja organizācija API pārvaldību uztver kā pārvaldītu kontroles jomu.

Pārvērtiet API drošību par auditam gatavu pārvaldību

Ja nākamais audits pieprasa API drošības pierādījumus, nesāciet ar nejaušu ekrānuzņēmumu vākšanu. Sāciet ar kontroles stāstu.

Clarysec var palīdzēt to izveidot ar:

• Zenith Blueprint Zenith Blueprint, lai strukturētu ieviešanu aktīvu uzskaites, drošas autentifikācijas, lietojumprogrammu drošības prasību un žurnalēšanas jomās.
• Zenith Controls Zenith Controls, lai kartētu ISO/IEC 27002:2022 kontroles pasākumus, piemēram, 5.9, 8.5, 8.15 un 8.26, uz starpatbilstības gaidām un audita skatījumiem.
• Clarysec politikas, tostarp Aktīvu pārvaldības politika Aktīvu pārvaldības politika, Lietojumprogrammu drošības prasību politika Lietojumprogrammu drošības prasību politika, Mākoņpakalpojumu izmantošanas politika Mākoņpakalpojumu izmantošanas politika, Aktīvu pārvaldības politika - SME Aktīvu pārvaldības politika - SME, Lietojumprogrammu drošības prasību politika - SME Lietojumprogrammu drošības prasību politika - SME un Žurnalēšanas un uzraudzības politika - SME Žurnalēšanas un uzraudzības politika - SME.

Praktisks nākamais solis ir īstenot Clarysec API pārvaldības pierādījumu sprintu: uzskaitīt API, klasificēt autentifikāciju, pārbaudīt pieprasījumu biežuma ierobežošanu, validēt žurnalēšanu, kartēt trešo pušu atkarības un sagatavot ISO 27001 gatavu pierādījumu kopu ar NIS2, DORA, GDPR, NIST CSF 2.0 un ar COBIT saskaņotiem audita skatījumiem.

API ir vieta, kur satiekas biznesa loģika, klientu dati un trešo pušu atkarības. 2026. gadā tiem pienākas vairāk nekā tehniska aizsardzība. Tiem vajadzīga pārvaldība, kas iztur auditu, atbalsta atbildi regulatoram un palīdz komandām atklāt ļaunprātīgu izmantošanu pirms klientiem.