API-turbe juhtimine: ISO 27001 tõendusmaterjal 2026. aastaks

API auditi leid, mis saabub enne rikkumist

Maria, kiiresti kasvava fintech SaaS ettevõtte infoturbejuht, avab kolm nädalat enne iga-aastast hindamist juhtivaudiitori e-kirja. Sõnum on otsekohene:

„Viime läbi teie IKT kolmandate osapoolte riskijuhtimise raamistiku ja selle DORA, NIS2 ning GDPR-iga vastavuse põhjaliku ülevaatuse, keskendudes eelkõige teie API ökosüsteemile. Palun esitage tootmis- ja partner-API-de register, autentimismudel, päringusageduse piiramise tõendusmaterjal ja logimise katvus.“

Kaks päeva hiljem saadab siseaudit teise sõnumi:

„Leidsime 47 avalikku API otspunkti, mida ei ole varade registris. Neli neist aktsepteerivad API-võtmeid ilma rotatsiooni tõendusmaterjalita. Ühel partnerintegratsioonil puudub päringusageduse piiramine. Logimine on tootmisteenustes ebaühtlane. Palun esitage ISO 27001, GDPR ja NIS2 tõendusmaterjal reedeks.“

Lunavaranõuet ei ole. Avalikku rikkumist ei ole. Kliendikaebust ei ole. Kuid leid on tõsine, sest see toob nähtavale juhtimislünga, mida ründajad juba ära kasutavad. API-d on nüüd tegelik perimeeter. Need ühendavad makseid, kasutajate liitumist, identiteeti, kliendiportaale, tarnijateenuseid, mobiilirakendusi, pilve töökoormusi, analüütikaplatvorme ja allhanke korras kasutatavaid riskimootoreid.

Peaaegu juhtunud intsident muudab probleemi eiramise veel raskemaks. Surve all töötanud nooremarendaja avaldas vahekeskkonna API internetti ilma autentimiseta. See sisaldas realistlikke pseudonüümitud kliendiandmeid. Punane meeskond leidis selle esimesena, kuid juhtkond esitas ilmse küsimuse: mis veel on väljas?

2026. aastal ei ole API-turbe juhtimine üksnes arendaja kontrollnimekiri. Infoturbejuhid, vastavusjuhid, siseaudiitorid ja juhatused peavad tõendama, et API-d on teada, omanikega seotud, autenditud, seiratud, päringusageduse piirangutega kaetud, testitud, riskihinnatud ja hõlmatud intsidentidest teavitamise protsessidega. Sama tõendusmaterjal peab sageli katma ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 ja COBIT-i kindlustandmise ootused.

Enamikul organisatsioonidel on tehnilised tööriistad juba olemas: API-lüüsid, identiteedipakkujad, SIEM-platvormid, WAF-id, pilvelogid, teenusevõrgud, CI/CD torustikud ja piletihaldussüsteemid. Sageli puudub aga kontrollimeetmete tõenduslugu. Millised API-d kuuluvad kohaldamisalasse? Kes kinnitab uued API-d? Millised logid tõendavad autentimistõrkeid? Milline register näitab kolmandate osapoolte API-sõltuvusi? Miks erinevad päringusageduse piirangud kliendi-, administraatori- ja masinalt masinale API-de vahel?

Claryseci lähenemine käsitleb API-turbe juhtimist vastavusraamistike ülese tõendusmaterjali süsteemina, mitte ühekordse inseneritegevusena. Kui API võib avaldada andmeid, muuta äriprotsessi, autentida kasutajat, käivitada makse, kutsuda tarnijat või toetada reguleeritud teenust, kuulub see ISMS-i tõendusmudelisse.

Miks API-juhtimine on nüüd juhatuse teema

NIS2 muudab küberturbe juhtimise juhtorgani vastutuseks. Article 20 nõuab, et juhtorganid kiidaksid heaks küberturbe riskijuhtimismeetmed, teeksid nende rakendamise üle järelevalvet ja läbiksid koolituse, et mõista küberriske ja nende mõju teenustele. Article 21 nõuab asjakohaseid ja proportsionaalseid tehnilisi, operatiivseid ja organisatsioonilisi meetmeid, sealhulgas riskianalüüsi, turbepoliitikaid, intsidentide käsitlemist, talitluspidevust, tarneahela turvet, turvalist hankimist ja arendust, haavatavuste käsitlemist, tõhususe hindamist, küberhügieeni, krüptograafiat, juurdepääsukontrolli, varahaldust ning vajaduse korral mitmefaktorilist või pidevat autentimist.

API-juhtimise puhul tähendab see, et avalikud API-d, partner-API-d, administraatori API-d ja sisemised mikroteenuste API-d võivad olla osa reguleeritud teenuse osutamisest. NIS2 võib kohalduda pilveteenuse pakkujatele, andmekeskuse teenusepakkujatele, sisuedastusvõrkudele, usaldusteenuse pakkujatele, avalikele elektroonilise side võrkudele ja teenustele ning IKT-teenuste halduse pakkujatele, näiteks MSP-dele ja MSSP-dele, sõltuvalt sektorist, suurusest, kriitilisusest ja liikmesriigi klassifikatsioonist.

DORA lisab finantssektori vaate. Seda kohaldatakse alates 17. jaanuarist 2025 ning see kehtestab ühtsed nõuded IKT-riski juhtimisele, IKT-ga seotud intsidentidest teatamisele, digitaalse operatsioonilise toimepidevuse testimisele, teabe jagamisele ja IKT kolmandate osapoolte riskijuhtimisele. Article 5 nõuab, et juhtorgan määratleks, kiidaks heaks, jälgiks ja vastutaks jätkuvalt IKT-riski juhtimise raamistiku eest. Article 8 nõuab IKT-toega ärifunktsioonide, teabevarade, IKT-varade, sõltuvuste, kolmandate osapoolte toetatud protsesside, kriitiliste varade, registrite ja pärand-IKT riskide tuvastamist, klassifitseerimist ja dokumenteerimist.

API mõistes ei ole makse algatamise API, pettuseskoorimise API, kliendi kaasamise API või allhanke korras kasutatav KYC API pelgalt otspunkt. See on IKT-vara ja sõltuvus, mis toetab ärifunktsiooni.

GDPR täiendab tervikpilti. API-d, mis edastavad identifikaatoreid, kontoandmeid, seadme identifikaatoreid, käitumuslikku telemeetriat, biomeetriat, terviseandmeid või finantsprofiile, võivad töödelda isikuandmeid. GDPR-i vastutuse põhimõte nõuab, et vastutavad töötlejad tõendaksid vastavust seaduslikkuse, eesmärgipiirangu, võimalikult väheste andmete kogumise, säilitamise piirangu, tervikluse ja konfidentsiaalsuse nõuetele. Article 32 nõuab töötlemise turvalisust, samas kui Articles 33 ja 34 sõltuvad isikuandmetega seotud rikkumise korral usaldusväärsest tõendusmaterjalist.

Juhatus ei vaja paketihõiveid, kuid vajab kindlust, et organisatsioon teab, millised API-d on olulised, milliseid andmeid need käitlevad, millistest tarnijatest need sõltuvad, kuidas kuritarvitust ennetatakse, kuidas intsidente tuvastatakse ja kuidas vastavust tõendatakse.

Alusta API registrist

Enamik API tõrkeid algab registripuudustest. Aegunud mobiilirakenduse taustateenus töötab endiselt tootmiskeskkonnas. Ajutine partnerintegratsioon muutub püsivaks. Pilvefunktsioon avaldab uue otspunkti. Sisemine API muutub pärast koormusjaoturi muudatust internetist kättesaadavaks. Ükski neist ei ilmu CMDB-sse, mistõttu ei saa ükski neist autentimise läbivaatamist, logimisstandardeid, päringusageduse lävendeid, tarnija hindamist ega säilitamise klassifikatsiooni.

Esimene auditi küsimus on tavaliselt lihtne: „Kas ma näen teie API-de registrit?“

Clarysec käsitleb API registrit ISMS-i varade registri osana. Zenith Blueprint: audiitori 30-sammuline teekaart Zenith Blueprint, Controls in Action faasis, 22. sammus, selgitab ISO/IEC 27002:2022 kontrollimeetme 5.9 juhis:

„Ükski organisatsioon ei saa kaitsta seda, mille olemasolust ta ei tea. Kontrollimeede 5.9 formaliseerib selle aluspõhimõtte, nõudes ajakohase registri loomist ja pidamist kõigi ISMS-i seisukohalt asjakohaste teabe- ja seotud varade kohta.“

Sama samm hõlmab loogilisi varasid, nagu „kasutajakontod, autentimisandmed, võtmed, tarkvaralitsentsid, API-d“, ning teenustega seotud varasid, nagu SaaS-platvormid ja allhanke korras kasutatav salvestus. Zenith Blueprint nimetab registrit „teie ISMS-i kesknärvisüsteemiks“, sest see toetab juurdepääsuõiguste andmist, krüptimist, varundamist, logimist, klassifitseerimist ja säilitamist.

Claryseci ettevõtte Varahalduse poliitika Varahalduse poliitika muudab selle juhtimisnõudeks:

„IT-varahaldur peab pidama terviklikku ja tsentraliseeritud varade registrit, mis hõlmab kõiki organisatsiooni kasutatavaid või organisatsiooniga ühendatud teabevarasid.“

Jaotisest „Poliitika rakendamise nõuded“, poliitikapunkt 6.1.1.

VKE-de jaoks hõlmab Claryseci Varahalduse poliitika - VKE Varahalduse poliitika - VKE otseselt API-dega seotud digitaalseid varasid:

„Digitaalsed autentimisandmed ja teenused: domeeninimed, digitaalsed sertifikaadid, API-võtmed, e-posti kontod, pilveteenuste sisselogimised“

Jaotisest „Kohaldamisala“, poliitikapunkt 2.2.4.

See sõnastus on oluline. Paljudes auditites asub API otspunkt lüüsis, token saladuste hoidlas, sertifikaat pilvekontos ja andmevoog privaatsuskirjes. Kaitstav API register seob need omavahel.

Zenith Controls: vastavusraamistike ülene juhend Zenith Controls liigitab ISO/IEC 27002:2022 kontrollimeetme 5.9, teabe ja muu seotud vara register, ennetavaks kontrollimeetmeks, mis toetab konfidentsiaalsust, terviklust ja käideldavust. Selle küberturbe kontseptsioon on Identify, operatiivne võimekus on varahaldus ning turbevaldkonnad on juhtimine, ökosüsteem ja kaitse. See aitab audiitoritel näha API registrit ennetava juhtimiskontrollina, mitte haldusliku korrastustööna.

Tõenda, et iga API identiteet on tahtlik

Kui register on olemas, on järgmine küsimus etteaimatav: kes või mis võib neid API-sid kutsuda?

Tänapäevased API-d autendivad inimkasutajaid, mobiilirakendusi, teenusekontosid, CI/CD töid, partnerisüsteeme, töökoormusi, roboteid, integratsioone, andmetorustikke ja kolmandate osapoolte platvorme. Nõrgad API-võtmed, pikaealised bearer-tokenid, puuduv vastastikune TLS, ülemääraste õigustega OAuthi ulatused ja koodi sisse kirjutatud saladused tekitavad kõik auditi kokkupuute.

Zenith Blueprint, Controls in Action faasis, 19. samm käsitleb ISO/IEC 27002:2022 kontrollimeedet 8.5, turvaline autentimine:

„Autentimine on esimene ja kõige kriitilisem kaitseliin ohutegija ning teie süsteemide, andmete ja teenuste vahel. Kui autentimine on nõrk, saab kõigest muust — krüptimisest, seirest, segmenteerimisest — mööda minna.“

Sama samm rõhutab masinalt masinale autentimist. Võtmeid, sertifikaate ja tokeneid tuleb kaitsta rangelt, autentimisandmeid ei tohi koodi manustada ning turvaliseks hoiustamiseks ja rotatsiooniks tuleb kasutada saladuste haldust või hoidlaid.

Claryseci ettevõtte Rakendusturbe nõuete poliitika Rakendusturbe nõuete poliitika toob selle otse API-juhtimisse:

„Kõik rakendusliidesed (API-d), mikroteenused ja välised integratsioonid tuleb kaitsta järgmiste meetmete abil:“

Jaotisest „Juhtimisnõuded“, poliitikapunkt 5.3.

Seejärel täpsustab see:

„Tugeva autentimise rakendamine, näiteks OAuth 2.0 ja vastastikune TLS“

Jaotisest „Juhtimisnõuded“, poliitikapunkt 5.3.1.

Väiksemate organisatsioonide jaoks annab Claryseci Rakendusturbe nõuete poliitika - VKE Rakendusturbe nõuete poliitika - VKE baastaseme:

„Autentimiskontrollid: rakendused peavad rakendama tugevat autentimist, sealhulgas parooli minimaalset tugevust, konto lukustamist ebaõnnestunud katsete järel ja seansi ajalõppe.“

Jaotisest „Poliitika rakendamise nõuded“, poliitikapunkt 6.1.1.2.

API-de puhul teisenda need nõuded autentimise tõenduspaketiks:

1. API register, filtreerituna internetile avatud, partneritele suunatud, administraatori ja sisemiste API-de järgi.
2. Autentimismaatriks, mis näitab OAuth 2.0, mTLS-i, allkirjastatud päringuid, lüüsi autoriseerijaid või teenusevõrgu identiteeti.
3. OAuthi klientide ja ulatuste register koos omaniku, eesmärgi, aegumistähtaja, kinnituse ja viimase läbivaatamise kuupäevaga.
4. Saladuste halduse tõendusmaterjal, mis näitab hoiustamist, juurdepääsu, rotatsiooni ja tühistamist.
5. Administraatori otspunktide ja tootmiskeskkonna teenusekontode privilegeeritud API-juurdepääsu läbivaatamine.
6. Ebaõnnestunud autentimise logid ja teavitusreeglid.
7. Testitulemused puuduva tokeni, aegunud tokeni, vale auditooriumi, vale ulatuse ja kordusründe stsenaariumide kohta.

Zenith Controls seob ISO/IEC 27002:2022 kontrollimeetme 8.5, turvaline autentimine, ennetava kontrollimeetmena, mis toetab konfidentsiaalsust, terviklust ja käideldavust. Selle küberturbe kontseptsioon on Protect, operatiivne võimekus on identiteedi- ja juurdepääsuhaldus ning turbevaldkond on kaitse.

NIS2 Article 21 toetab seda juurdepääsukontrolli, krüptograafia ning vajaduse korral mitmefaktorilise või pideva autentimise kaudu. DORA eeldab, et finantsüksused hoiavad kontrollimeetmeid, mis kaitsevad autentsust, terviklust, käideldavust ja konfidentsiaalsust. GDPR Article 32 muudab nõrga API autentimise töötlemise turvalisuse küsimuseks, eriti kui isikuandmed on avatud.

Käsitle päringusageduse piiramist toimepidevuse tõendusmaterjalina

Tugev autentimine on vajalik, kuid sellest ei piisa. Autenditud klient võib API-d siiski kuritarvitada. Ründajad kasutavad API-sid autentimisandmete täitmise rünneteks, loendamiseks, kraapimiseks, tokenite pihustamiseks, parooli lähtestamise pommitamiseks, tehingute kuritarvituseks ja teenusetõkestuseks.

Päringusageduse piiramist peeti varem jõudlusfunktsiooniks. 2026. aastal on see turbe, privaatsuse ja toimepidevuse tõendusmaterjal.

Claryseci Rakendusturbe nõuete poliitika sätestab:

„Päringumahu piiramine ja kuritarvituse ennetamine“

Jaotisest „Juhtimisnõuded“, poliitikapunkt 5.3.2.

Zenith Blueprint, Controls in Action faasis, 20. samm ISO/IEC 27002:2022 kontrollimeetme 8.26, rakendusturbe nõuded, kohta selgitab, et rakendusturbe nõuded peavad olema täpsed ja tegevusteks teisendatavad. See küsib, kas rakendus peaks olema vastupidav sisestusrünnetele, jõurünnaku sisselogimistele või teenusetõkestuse katsetele. Samuti toob see API-põhise näite, et uus API peaks sisaldama juurdepääsutokeni valideerimist ja sisendite puhastamist, ning märgib, et avalikkusele suunatud platvormid võivad vajada rangemat valideerimist, kasutajakäitumise analüütikat ja päringusageduse piiramist.

Kaitstav päringusageduse piiramise kirje peab selgitama mitte ainult seda, et piiramine on olemas, vaid ka seda, miks lävendid valiti, kes erandid kinnitas ja kuidas teavitusi seiratakse.

NIS2 puhul toetab see turvalist arendust, tõhususe hindamist, talitluspidevust ja intsidentide ennetamist. DORA puhul seostub päringusageduse piiramine IKT-riski juhtimise, anomaaliatuvastuse, toimepidevuse testimise ning kriitiliste või oluliste funktsioonide järjepidevusega. GDPR-i puhul toetab see võimalikult väheste andmete kogumist ning kaitset ülemäärase või õigusvastase juurdepääsu eest, eriti kui API kraapimine võib avaldada isikuandmeid.

Muuda logimine tõenduskihiks

Kui API intsident toimub, ei ole esimene tegelik küsimus „Kas teil on SIEM?“. Küsimus on: „Kas saate toimunu rekonstrueerida?“

API logid peaksid jäädvustama autentimistõrked, autoriseerimise keeldumised, tokeniväited, kliendiidentiteedi, allika, otspunkti, meetodi, päringu tulemuse, haldusmuudatused, kõrge riskiga andmejuurdepääsu, päringusageduse piirangu sündmused, ebatavalise mahu, konfiguratsioonimuudatused ja turbe seisukohalt olulised vead. Samuti tuleb vältida saladuste, bearer-tokenite või ebavajalike isikuandmete logimist.

Zenith Blueprint, Controls in Action faasis, 19. samm ISO/IEC 27002:2022 kontrollimeetme 8.15, logimine, kohta sätestab:

„Logimine on iga turvalise IT-keskkonna vereringe. Ilma selleta jäävad intsidendid nähtamatuks, vastutus hajub ning põhjus-tagajärg seosed kaovad õhku.“

Samuti selgitab see, et logimine on seotud jälgitavusega ning kasulikud logid peavad olema turvaliselt säilitatud, seiratud, läbi vaadatud ja kaitstud rikkumise eest.

Claryseci Rakendusturbe nõuete poliitika - VKE nõuab:

„Auditilogimine: rakendused peavad logima autentimissündmused (sisselogimised, väljalogimised ja ebaõnnestunud katsed), andmetele juurdepääsu ja haldusmuudatused.“

Jaotisest „Poliitika rakendamise nõuded“, poliitikapunkt 6.1.1.7.

Claryseci Logimis- ja seirepoliitika - VKE Logimis- ja seirepoliitika - VKE kehtestab logimise juhtimiskategooria:

„Nõutavad logitüübid“

Jaotisest „Juhtimisnõuded“, poliitikapunkt 5.4.

Pilvekeskkonnas majutatud API-de puhul tugevdab Claryseci ettevõtte Pilveteenuste kasutamise poliitika Pilveteenuste kasutamise poliitika nõuet:

„Logid peavad jäädvustama:“

Jaotisest „Poliitika rakendamise nõuded“, poliitikapunkt 6.5.2.

Zenith Controls seob ISO/IEC 27002:2022 kontrollimeetme 8.15, logimine, tuvastava kontrollimeetmena, mis toetab konfidentsiaalsust, terviklust ja käideldavust. Selle küberturbe kontseptsioon on Detect, operatiivne võimekus on infoturbe sündmuste haldus ning turbevaldkonnad on kaitse ja kaitsetegevus. See muudab logimise sillaks poliitika ja tõenduse vahel.

NIS2 Article 23 nõuab olulistest intsidentidest etapiviisilist teatamist: varajane hoiatus 24 tunni jooksul teadlikuks saamisest, intsidenditeade 72 tunni jooksul, vahearuanded nõudmisel ja lõpparuanne ühe kuu jooksul pärast teatamist. Usaldusteenuse pakkujate puhul, keda intsident mõjutab usaldusteenuse osutamisel, on nõutav teavitamine 24 tunni jooksul teadlikuks saamisest.

DORA Articles 17 to 19 nõuavad IKT-ga seotud intsidendihaldust koos varajaste hoiatusindikaatorite, tõsiduse ja kriitilisuse klassifitseerimise, eskaleerimise, logimise, algpõhjuse järeltegevuste ning suurtest IKT-ga seotud intsidentidest esialgsete, vahe- ja lõpparuannete kaudu teatamisega. GDPR-i rikkumise hindamine sõltub samuti logidest, et teha kindlaks, kas isikuandmetele pääseti ligi, millised isikud olid mõjutatud ja kas teavitamiskohustused rakenduvad.

Koosta API tõenduspakett viie tööpäevaga

Kiire sprindi eesmärk ei ole parandada kogu API-turvet ühe nädalaga. Eesmärk on luua kaitstav lähtealus, tuvastada lüngad ja alustada riskikäsitlust.

1. päev: loo API register

Ekspordi marsruudid API-lüüsidest, teenusevõrkudest, pilve koormusjaoturitest, serverless-funktsioonidest, OpenAPI repositooriumidest ja CI/CD juurutusmanifestidest. Ühtlusta need üheks API registriks koos otspunkti, keskkonna, omaniku, äriprotsessi, andmete klassifikatsiooni, isikuandmete tunnuse, autentimismeetodi, päringusageduse piirangu, logimise staatuse, tarnijasõltuvuse, kriitilisuse ja viimase läbivaatamise kuupäevaga.

Kasuta juhtimisankruna Varahalduse poliitika punkti 6.1.1 ja Zenith Blueprinti 22. sammu.

2. päev: klassifitseeri autentimislüngad

Koosta autentimismaatriks. Märgista API-d, mis kasutavad staatilisi API-võtmeid, pikaealisi tokeneid, puuduvat auditooriumi valideerimist, puuduvat ulatuse valideerimist, partnerintegratsioonide puhul puuduvat mTLS-i, ühiseid teenusekontosid või puuduvat rotatsiooni tõendusmaterjali.

Seo leiud Rakendusturbe nõuete poliitika punktiga 5.3.1 ja Zenith Blueprinti 19. sammuga. Registreeri iga lünk riskina koos omaniku, käsitlustee ja sihtkuupäevaga.

3. päev: tõenda päringusageduse piirangud ja kuritarvituse kontrollid

Avalike, partner- ja administraatori API-de puhul kogu lüüsi poliitikad, WAF-i reeglid, robotitõrje kontrollid, kvoodiseaded ja teavitamislävendid. Kui kontrollimeetmed puuduvad, registreeri kompenseerivad kontrollimeetmed või avatud riskikäsitlus.

Kasuta poliitikaautoriteedina Rakendusturbe nõuete poliitika punkti 5.3.2. Kriitiliste API-de puhul seo lävendid teenusemõju, kliendikahju ning DORA või NIS2 toimepidevuse ootustega.

4. päev: valideeri logimise katvus

Võta kõrge riskiga API-de logidest valimid. Kinnita, et logid jäädvustavad eduka autentimise, ebaõnnestunud autentimise, autoriseerimise keeldumise, andmetele juurdepääsu, haldusmuudatuse, päringusageduse piirangu sündmuse, allikaidentiteedi ja korrelatsiooni-ID. Kontrolli aja sünkroniseerimist, säilitamist, juurdepääsukontrolli ja rikkumiskaitset.

Kui logid sisaldavad tokeneid, saladusi või ülemääraseid isikuandmeid, algata privaatsuse ja turbe parandusmeetmed.

5. päev: esita auditi vastuspakett

Esita kompaktne tõendusmaterjali kogum:

• API registri eksport ja omandivastutuse kokkuvõte.
• API riskiregister koos käsitlusplaaniga.
• Autentimismaatriks ja tokenite läbivaatamise tõendusmaterjal.
• Päringusageduse piiramise tõendusmaterjal ja kinnitatud erandid.
• Logimise katvuse aruanne ja SIEM-i juhtpaneeli ekraanitõmmised.
• API kuritarvituse intsidendi klassifitseerimise tööjuhis.
• Vastavusraamistike ülene kaardistus ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 ja COBIT-i auditivaadetele.

Oluline nihe seisneb selles, et igal artefaktil on kontrollimeetme tõenduslugu. API register toetab varahaldust. Autentimine toetab juurdepääsukontrolli. Päringusageduse piirangud toetavad rakendusturvet ja toimepidevust. Logid toetavad tuvastamist, intsidentidele reageerimist ja vastutust.

API-juhtimise vastavusraamistike ülene kaardistus

Suurim viga on eraldi tõenduskomplektide loomine iga raamistiku jaoks. API-juhtimine toimib paremini ühe kontrollimudelina, millel on mitu regulatiivset vaadet.

ISO/IEC 27001:2022 annab juhtimissüsteemi, mis hoiab tõendusmaterjali koos. Clauses 4.1 to 4.4 nõuavad, et organisatsioon määratleks ISMS-i konteksti ja kohaldamisala, sealhulgas huvitatud osapooled, õiguslikud, regulatiivsed ja lepingulised kohustused ning liidesed või sõltuvused teiste organisatsioonidega. Clauses 5.1 to 5.3 seavad vastutuse tippjuhtkonnale. Clauses 6.1.1 to 6.1.3 loovad riskihindamise, riskikäsitluse ja kohaldatavusavalduse protsessi. Clause 8.1 nõuab tegevuse planeerimist ja ohjet, sealhulgas kontrolli ISMS-i seisukohalt asjakohaste väliselt osutatavate protsesside, toodete või teenuste üle.

API-juhtimise puhul tähendab see, et kolmanda osapoole makse-API, pilveidentiteedi API või allhanke korras kasutatav pettusetuvastuse API ei ole vastavusest väljas pelgalt seetõttu, et see on väline. See on liides ja sõltuvus, mis tuleb kohaldamisalasse hõlmata, riskihinnata ja kontrollida.

NIST CSF 2.0 lisab kasuliku juhtkonna vaate. Selle GOVERN-funktsioon aitab organisatsioonidel määratleda sidusrühmade ootusi, õiguslikke kohustusi, riskivalmidust ja tarneahela riski. Selle profiilide lähenemine toetab praegust profiili, sihtprofiili, prioriseeritud lünkade plaani ja pideva täiustamise tsüklit. Täpselt nii peaks toimima API-juhtimise sprint.

COBIT 2019 saab toetada juhtimisvaadet, sidudes API kontrollimeetmed juhtimiseesmärkide, kontrollimeetmete omamise, teenuse järjepidevuse, turbeseire, riskiraportluse ja probleemide jälgimisega. Võti ei ole API-de surumine ühte raamistikku, vaid näitamine, et üks tõendusmudel vastab mitmele kindlustandmise küsimusele.

Kuidas audiitorid API-juhtimist testivad

Tugev programm arvestab audiitori vaatenurgaga ette. Sama tõendusmaterjali testitakse sõltuvalt raamistikust erinevalt.

Clarysec soovitab tõendusmaterjali triangulatsiooni. Ära näita ainult poliitikat. Näita poliitikat, rakendamise tõendusmaterjali ja toimimise tõendusmaterjali.

Näiteks:

• Poliitika: API-d peavad vajaduse korral kasutama OAuth 2.0 või mTLS-i.
• Konfiguratsioon: API-lüüsi marsruut näitab JWT valideerimist ja lubatud auditooriumi.
• Toimimise tõendusmaterjal: ebaõnnestunud tokenikatsed logitakse ja teavitamine on aktiivne.
• Läbivaatamise tõendusmaterjal: OAuthi kliendi läbivaatamine on lõpule viidud koos omaniku kinnitusega.
• Riskitõendusmaterjal: pärand-API erandil on kompenseerivad kontrollimeetmed ja käsitluse tähtaeg.

See on palju tugevam kui ainult ekraanitõmmistel põhinev vastus.

Levinud API-juhtimise puudused

Kõige levinum probleem ei ole see, et API-d on täiesti kaitsmata. Probleem on selles, et turve on ebaühtlane.

Üks meeskond kasutab OAuthi ulatusi hästi, teine kasutab jagatud API-võtit. Üks teenus logib andmetele juurdepääsu, teine logib ainult serverivead. Ühel partnerintegratsioonil on mTLS, teine tugineb pikaealisele bearer-tokenile. Päringusageduse piirangud on olemas avalike otspunktide jaoks, kuid mitte autenditud kliendi-API-de jaoks, kus kraapimine võib toimuda. CMDB loetleb rakenduse, kuid mitte selle API-sid, tokeneid, sertifikaate, andmekategooriaid ega tarnijaid.

Korduvad puudused hõlmavad järgmist:

• Varjatud API-d, mis on juurutatud serverless-funktsioonide või ajutiste testmarsruutide kaudu.
• API-võtmed, mida hoitakse CI/CD muutujates ilma dokumenteeritud rotatsioonita.
• Logimine, mis jäädvustab tokeneid, saladusi või ebavajalikke isikuandmeid.
• Korrelatsiooni-ID puudumine lüüsi, rakenduse ja andmebaasi logides.
• Päringusageduse piirangu erandid, mida antakse suurklientidele mitteametlikult.
• Partner-API-del puuduvad lepingulised intsidendist teavitamise või auditeerimisõigused.
• Puudub API-spetsiifiline intsidendi klassifikatsioon loendamise, kraapimise või tokeni kuritarvituse jaoks.
• API andmevoogude ja GDPR-i töötlemiskirjete vahel puudub kaardistus.
• Turbetestimine keskendub veebiliidesele, samas kui API-d jäävad testimata.
• Juhatuse aruanded näitavad „rakendusturvet“ ilma API-spetsiifiliste riskimõõdikuteta.

Need probleemid on lahendatavad, kuid ainult siis, kui organisatsioon käsitleb API-juhtimist hallatava kontrollivaldkonnana.

Muuda API-turve auditivalmiks juhtimiseks

Kui järgmine audit küsib API-turbe tõendusmaterjali, ära alusta juhuslike ekraanitõmmiste kogumisest. Alusta kontrollimeetmete tõendusloost.

Clarysec aitab seda üles ehitada järgmiste vahenditega:

• Zenith Blueprint Zenith Blueprint, et struktureerida rakendamist varade registri, turvalise autentimise, rakendusturbe nõuete ja logimise lõikes.
• Zenith Controls Zenith Controls, et kaardistada ISO/IEC 27002:2022 kontrollimeetmed, nagu 5.9, 8.5, 8.15 ja 8.26, vastavusraamistike üleste ootuste ja auditivaadetega.
• Claryseci poliitikad, sealhulgas Varahalduse poliitika Varahalduse poliitika, Rakendusturbe nõuete poliitika Rakendusturbe nõuete poliitika, Pilveteenuste kasutamise poliitika Pilveteenuste kasutamise poliitika, Varahalduse poliitika - VKE Varahalduse poliitika - VKE, Rakendusturbe nõuete poliitika - VKE Rakendusturbe nõuete poliitika - VKE ja Logimis- ja seirepoliitika - VKE Logimis- ja seirepoliitika - VKE.

Praktiline järgmine samm on viia läbi Claryseci API-juhtimise tõendusmaterjali sprint: kanda API-d registrisse, klassifitseerida autentimine, kontrollida päringusageduse piiramist, valideerida logimine, kaardistada kolmandate osapoolte sõltuvused ning koostada ISO 27001 jaoks valmis tõenduspakett koos NIS2, DORA, GDPR, NIST CSF 2.0 ja COBIT-i auditivaadetega.

API-d on koht, kus kohtuvad äriloogika, kliendiandmed ja kolmandate osapoolte sõltuvused. 2026. aastal väärivad need enamat kui tehnilist kaitset. Need vajavad juhtimist, mis peab vastu auditile, toetab vastust regulaatorile ja aitab meeskondadel tuvastada kuritarvitust enne kliente.