Správa a řízení zabezpečení API: důkazní podklady pro ISO 27001 v roce 2026

Auditní zjištění k API, které přijde dříve než bezpečnostní incident

Maria, CISO rychle rostoucí fintech SaaS společnosti, otevírá tři týdny před každoročním posouzením e-mail od vedoucího auditora. Zpráva je přímá:

„Provedeme hloubkový přezkum vašeho rámce řízení rizik třetích stran v oblasti ICT a jeho souladu s DORA, NIS2 a GDPR, se zvláštním zaměřením na váš ekosystém API. Poskytněte prosím evidenci, model autentizace, důkazní podklady k omezování četnosti požadavků a pokrytí protokolováním pro produkční a partnerská API.“

O dva dny později posílá interní audit druhou zprávu:

„Našli jsme 47 veřejně dostupných koncových bodů API, které nejsou v evidenci aktiv. Čtyři přijímají API klíče bez důkazních podkladů o rotaci. Jedna partnerská integrace nemá nastavené omezování četnosti požadavků. Protokolování je napříč produkčními službami nekonzistentní. Poskytněte prosím důkazní podklady pro ISO 27001, GDPR a NIS2 do pátku.“

Neexistuje žádná zpráva od ransomwaru. Žádný veřejně oznámený bezpečnostní incident. Žádná stížnost zákazníka. Zjištění je však závažné, protože odhaluje mezeru ve správě a řízení, kterou útočníci již zneužívají. API jsou dnes skutečným perimetrem. Propojují platby, onboarding, identitu, zákaznické portály, dodavatelské služby, mobilní aplikace, cloudové pracovní zátěže, analytické platformy a outsourcované rizikové enginy.

Těsně odvrácený incident zvyšuje naléhavost problému. Juniorní vývojář pracující pod tlakem vystavil do internetu API ve stagingovém prostředí bez autentizace. Obsahovalo realistická, pseudonymizovaná zákaznická data. Red team je našel jako první, ale vedení položilo zřejmou otázku: co dalšího je ještě dostupné?

V roce 2026 není správa a řízení zabezpečení API jen kontrolní seznam pro vývojáře. CISO, manažeři souladu, interní auditoři a vedoucí orgány musí doložit, že API jsou známá, mají vlastníka, jsou autentizovaná, monitorovaná, chráněná omezováním četnosti požadavků, testovaná, posouzená z hlediska rizik a zahrnutá do hlášení incidentů. Stejné důkazní podklady musí často obstát vůči očekáváním zajištění podle ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 a auditů sladěných s COBIT.

Většina organizací již má technické nástroje: API brány, poskytovatele identit, platformy SIEM, WAF, cloudové logy, service mesh, CI/CD pipeline a ticketovací systém. Často však chybí kontrolní narativ. Která API jsou v rozsahu? Kdo schvaluje nová API? Které logy dokládají selhání autentizace? Který registr ukazuje závislosti API na třetích stranách? Proč se limity četnosti požadavků liší pro zákaznická, administrátorská a machine-to-machine API?

Přístup Clarysec spočívá v tom, že správa a řízení zabezpečení API se chápe jako systém důkazních podkladů pro více rámců souladu, nikoli jako jednorázová inženýrská aktivita. Pokud API může zpřístupnit data, změnit obchodní proces, autentizovat uživatele, spustit platbu, zavolat dodavatele nebo podporovat regulovanou službu, patří do důkazního modelu ISMS.

Proč je správa a řízení API tématem pro vedoucí orgány

NIS2 činí ze správy a řízení kybernetické bezpečnosti odpovědnost vedoucích orgánů. Article 20 vyžaduje, aby vedoucí orgány schvalovaly opatření k řízení kybernetických rizik, dohlížely na jejich provádění a absolvovaly školení, aby rozuměly kybernetickým rizikům a jejich dopadu na služby. Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření, včetně analýzy rizik, bezpečnostních politik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného pořizování a vývoje, zvládání zranitelností, hodnocení účinnosti, kybernetické hygieny, kryptografie, řízení přístupu, správy aktiv a vícefaktorové nebo průběžné autentizace tam, kde je to vhodné.

Pro správu a řízení API to znamená, že veřejná API, partnerská API, administrátorská API i interní mikroslužbová API mohou být součástí poskytování regulovaných služeb. NIS2 se může vztahovat na poskytovatele služeb cloud computingu, poskytovatele služeb datových center, sítě pro doručování obsahu, poskytovatele služeb vytvářejících důvěru, veřejné sítě a služby elektronických komunikací a poskytovatele správy služeb ICT, například MSP a MSSP, v závislosti na odvětví, velikosti, kritičnosti a klasifikaci členského státu.

DORA přidává pohled finančního sektoru. Uplatňuje se od 17. ledna 2025 a stanovuje jednotné požadavky na řízení rizik v oblasti ICT, hlášení incidentů souvisejících s ICT, testování digitální provozní odolnosti, sdílení informací a řízení rizik třetích stran v oblasti ICT. Article 5 vyžaduje, aby vedoucí orgán definoval, schvaloval, dohlížel na rámec řízení rizik v oblasti ICT a nesl za něj odpovědnost. Article 8 vyžaduje identifikaci, klasifikaci a dokumentaci podnikových funkcí podporovaných ICT, informačních aktiv, aktiv ICT, závislostí, procesů podporovaných třetími stranami, kritických aktiv, evidencí a rizik spojených se zastaralými ICT.

V terminologii API není API pro iniciaci platby, API pro hodnocení podvodů, API pro onboarding zákazníků ani outsourcované KYC API pouhým koncovým bodem. Je to aktivum ICT a závislost podporující podnikovou funkci.

GDPR obraz doplňuje. API, která přenášejí identifikátory, údaje o účtech, ID zařízení, behaviorální telemetrii, biometrické údaje, údaje týkající se zdraví nebo finanční profily, mohou zpracovávat osobní údaje. Princip odpovědnosti podle GDPR vyžaduje, aby správci dokázali doložit soulad se zákonností, omezením účelu, minimalizací údajů, omezením uložení, integritou a důvěrností. Article 32 vyžaduje zabezpečení zpracování, zatímco Articles 33 a 34 závisí na spolehlivých důkazních podkladech při porušení zabezpečení osobních údajů.

Vedoucí orgány nepotřebují záznamy paketů, ale potřebují jistotu, že organizace ví, která API jsou důležitá, s jakými daty nakládají, na kterých dodavatelích závisí, jak je bráněno jejich zneužití, jak jsou incidenty detekovány a jak lze doložit soulad.

Začněte evidencí API

Většina selhání API začíná selháním evidence. Zastaralý mobilní backend stále běží v produkčním prostředí. Dočasná partnerská integrace se stane trvalou. Cloudová funkce vystaví nový koncový bod. Interní API se po změně load balanceru stane dostupným z internetu. Nic z toho se neobjeví v CMDB, takže se na nic z toho nevztahuje přezkum autentizace, standardy protokolování, prahové hodnoty omezování četnosti požadavků, posouzení dodavatele ani klasifikace uchovávání.

První auditní otázka bývá obvykle jednoduchá: „Mohu vidět vaši evidenci API?“

Clarysec chápe evidenci API jako součást evidence aktiv ISMS. V dokumentu Zenith Blueprint: 30krokový plán auditora Zenith Blueprint, ve fázi Kontroly v praxi, krok 22, pokyny k opatření ISO/IEC 27002:2022 5.9 vysvětlují:

„Žádná organizace nemůže chránit to, o čem neví, že má. Opatření 5.9 formalizuje tento základní princip a vyžaduje zavedení a udržování aktuální evidence všech informací a souvisejících aktiv relevantních pro ISMS.“

Tentýž krok zahrnuje logická aktiva, například „uživatelské účty, přihlašovací údaje, klíče, softwarové licence, API“, a aktiva související se službami, například platformy SaaS a outsourcovaná úložiště. Zenith Blueprint nazývá evidenci „centrálním nervovým systémem vašeho ISMS“, protože ovlivňuje zřizování přístupu, šifrování, zálohování, protokolování, klasifikaci a uchovávání.

Podniková Politika správy aktiv společnosti Clarysec Politika správy aktiv převádí tento princip na požadavek správy a řízení:

„IT manažer aktiv musí udržovat komplexní a centralizovanou evidenci aktiv pokrývající všechna informační aktiva používaná organizací nebo připojená k organizaci.“

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.1.1.

Pro SME Politika správy aktiv – SME společnosti Clarysec Politika správy aktiv – SME výslovně zahrnuje digitální aktiva relevantní pro API:

„Digitální přihlašovací údaje a služby: názvy domén, digitální certifikáty, API klíče, e-mailové účty, cloudová přihlášení“

Ze sekce „Rozsah“, ustanovení politiky 2.2.4.

Tato formulace je důležitá. V mnoha auditech se koncový bod API objeví v bráně, token v trezoru tajemství, certifikát v cloudovém účtu a datový tok v záznamu o ochraně soukromí. Obhajitelná evidence API je propojí.

V dokumentu Zenith Controls: průvodce napříč rámci souladu Zenith Controls je opatření ISO/IEC 27002:2022 5.9, Evidence informací a dalších souvisejících aktiv, klasifikováno jako preventivní opatření podporující důvěrnost, integritu a dostupnost. Jeho koncept kybernetické bezpečnosti je Identifikovat, provozní schopnost je správa aktiv a bezpečnostní domény jsou správa a řízení, ekosystém a ochrana. To auditorům pomáhá chápat evidenci API jako preventivní opatření správy a řízení, nikoli jako administrativní údržbu.

Doložte, že každá identita API je záměrná

Jakmile evidence existuje, další otázka je předvídatelná: kdo nebo co může tato API volat?

Moderní API autentizují lidské uživatele, mobilní aplikace, servisní účty, CI/CD úlohy, partnerské systémy, pracovní zátěže, boty, integrace, datové pipeline a platformy třetích stran. Slabé API klíče, dlouhodobé bearer tokeny, chybějící vzájemné TLS, nadměrně oprávněné rozsahy OAuth a pevně zakódované tajné údaje vytvářejí auditní expozici.

Zenith Blueprint, fáze Kontroly v praxi, krok 19, se věnuje opatření ISO/IEC 27002:2022 8.5, Bezpečná autentizace:

„Autentizace je první a nejkritičtější obrannou linií mezi aktérem hrozby a vašimi systémy, daty a službami. Pokud je autentizace slabá, vše ostatní – šifrování, monitorování, segmentace – lze obejít.“

Tentýž krok zdůrazňuje autentizaci mezi systémy. Klíče, certifikáty a tokeny musí být důsledně chráněny, přihlašovací údaje nesmí být vloženy v kódu a pro bezpečné ukládání a rotaci se mají používat nástroje pro správu tajemství nebo trezory.

Podniková Politika požadavků na zabezpečení aplikací společnosti Clarysec Politika požadavků na zabezpečení aplikací přenáší tento požadavek přímo do správy a řízení API:

„Všechna rozhraní API, mikroslužby a externí integrace musí být zabezpečeny prostřednictvím:“

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.

Dále stanovuje:

„Vynucování silné autentizace, například OAuth 2.0 a vzájemného TLS“

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.1.

Pro menší organizace poskytuje Politika požadavků na zabezpečení aplikací – SME společnosti Clarysec Politika požadavků na zabezpečení aplikací – SME základní úroveň:

„Opatření autentizace: Aplikace musí vynucovat silnou autentizaci, včetně minimální složitosti hesla, zablokování účtu po neúspěšných pokusech a časových limitů relací.“

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.1.1.2.

Pro API převeďte tyto požadavky do balíčku důkazních podkladů k autentizaci:

1. Evidence API filtrovaná podle API dostupných z internetu, partnerských API, administrátorských API a interních API.
2. Matice autentizace zobrazující OAuth 2.0, mTLS, podepsané požadavky, autorizační mechanismy brány nebo identitu service mesh.
3. Registr klientů a rozsahů OAuth s vlastníkem, účelem, expirací, schválením a datem posledního přezkumu.
4. Důkazní podklady ke správě tajemství zobrazující ukládání, přístup, rotaci a revokaci.
5. Přezkum privilegovaného přístupu k API pro administrátorské koncové body a produkční servisní účty.
6. Logy neúspěšné autentizace a pravidla upozornění.
7. Výsledky testů pro chybějící token, expirovaný token, nesprávného příjemce, nesprávný rozsah a scénáře opakovaného přehrání.

V Zenith Controls je opatření ISO/IEC 27002:2022 8.5, Bezpečná autentizace, mapováno jako preventivní opatření podporující důvěrnost, integritu a dostupnost. Jeho koncept kybernetické bezpečnosti je Chránit, provozní schopnost je řízení identit a přístupů a bezpečnostní doména je ochrana.

NIS2 Article 21 to podporuje prostřednictvím řízení přístupu, kryptografie a vícefaktorové nebo průběžné autentizace tam, kde je to vhodné. DORA očekává, že finanční subjekty budou udržovat opatření chránící autenticitu, integritu, dostupnost a důvěrnost. GDPR Article 32 mění slabou autentizaci API na problém zabezpečení zpracování, zejména tam, kde jsou vystaveny osobní údaje.

Chápejte omezování četnosti požadavků jako důkaz odolnosti

Silná autentizace je nezbytná, ale nestačí. Autentizovaný klient může API stále zneužít. Útočníci používají API ke credential stuffingu, enumeraci, scrapingu, rozstřikování tokenů, zahlcování resetu hesel, zneužití transakcí a odepření služby.

Omezování četnosti požadavků bývalo vnímáno jako výkonnostní funkce. V roce 2026 je to důkazní podklad k bezpečnosti, ochraně osobních údajů a odolnosti.

Politika požadavků na zabezpečení aplikací společnosti Clarysec uvádí:

„Omezení četnosti požadavků a prevence zneužití“

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.2.

Zenith Blueprint, fáze Kontroly v praxi, krok 20, k opatření ISO/IEC 27002:2022 8.26, Požadavky na zabezpečení aplikací, vysvětluje, že požadavky na zabezpečení aplikací musí být přesné a proveditelné. Klade otázku, zda má být aplikace odolná vůči injekčním útokům, přihlašování hrubou silou nebo pokusům o odepření služby. Uvádí také příklad specifický pro API, podle něhož má nové API zahrnovat ověření přístupového tokenu a sanitizaci vstupů, a poznamenává, že veřejně dostupné platformy mohou vyžadovat přísnější ověřování, analytiku chování uživatelů a omezování četnosti požadavků.

Obhajitelný záznam o omezování četnosti požadavků má vysvětlit nejen to, že throttling existuje, ale také proč byly vybrány konkrétní prahové hodnoty, kdo schválil výjimky a jak jsou monitorována upozornění.

Pro NIS2 to podporuje bezpečný vývoj, hodnocení účinnosti, kontinuitu činností a prevenci incidentů. Pro DORA se omezování četnosti požadavků váže na řízení rizik v oblasti ICT, detekci anomálií, testování odolnosti a kontinuitu kritických nebo důležitých funkcí. Pro GDPR podporuje minimalizaci údajů a ochranu proti nadměrnému nebo nezákonnému přístupu, zejména tam, kde by scraping API mohl zpřístupnit osobní údaje.

Udělejte z protokolování důkazní vrstvu

Když dojde k incidentu API, první skutečná otázka nezní „Máte SIEM?“. Zní: „Dokážete rekonstruovat, co se stalo?“

Logy API mají zachycovat selhání autentizace, zamítnutí autorizace, tvrzení tokenů, identitu klienta, zdroj, koncový bod, metodu, výsledek požadavku, administrativní změny, vysoce rizikový přístup k datům, události omezování četnosti požadavků, abnormální objem, změny konfigurace a bezpečnostně relevantní chyby. Zároveň se musí vyhnout protokolování tajemství, bearer tokenů nebo zbytečných osobních údajů.

Zenith Blueprint, fáze Kontroly v praxi, krok 19, k opatření ISO/IEC 27002:2022 8.15, Protokolování, uvádí:

„Protokolování je životní krev každého bezpečného IT prostředí. Bez něj zůstávají incidenty neviditelné, odpovědnost se vytrácí a vztahy příčiny a následku mizí beze stopy.“

Dále vysvětluje, že protokolování je o dohledatelnosti a že užitečné logy musí být bezpečně uloženy, monitorovány, přezkoumávány a chráněny proti manipulaci.

Politika požadavků na zabezpečení aplikací – SME společnosti Clarysec vyžaduje:

„Auditní protokolování: Aplikace musí protokolovat autentizační události (přihlášení, odhlášení a neúspěšné pokusy), přístup k datům a administrativní změny.“

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.1.1.7.

Politika protokolování a monitorování – SME společnosti Clarysec Politika protokolování a monitorování – SME stanovuje kategorii správy a řízení protokolování:

„Požadované typy logů“

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.4.

Pro API hostovaná v cloudu podniková Politika používání cloudových služeb společnosti Clarysec Politika používání cloudových služeb požadavek posiluje:

„Logy musí zachycovat:“

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.5.2.

V Zenith Controls je opatření ISO/IEC 27002:2022 8.15, Protokolování, mapováno jako detekční kontrola podporující důvěrnost, integritu a dostupnost. Jeho koncept kybernetické bezpečnosti je Detekovat, provozní schopnost je řízení událostí informační bezpečnosti a bezpečnostní domény jsou ochrana a obrana. To z protokolování činí most mezi politikou a důkazy.

NIS2 Article 23 vyžaduje postupné hlášení významných incidentů: včasné varování do 24 hodin od zjištění, oznámení incidentu do 72 hodin, průběžné zprávy na vyžádání a závěrečnou zprávu do jednoho měsíce po oznámení. U poskytovatelů služeb vytvářejících důvěru dotčených při poskytování těchto služeb je vyžadováno oznámení do 24 hodin od zjištění.

DORA Articles 17 to 19 vyžadují řízení incidentů souvisejících s ICT s ukazateli včasného varování, klasifikací závažnosti a kritičnosti, eskalací, protokolováním, následnou analýzou kořenové příčiny a hlášením významných incidentů souvisejících s ICT prostřednictvím úvodních, průběžných a závěrečných zpráv. Posouzení porušení zabezpečení podle GDPR také závisí na logách, aby bylo možné určit, zda došlo k přístupu k osobním údajům, které osoby byly dotčeny a zda vznikají oznamovací povinnosti.

Vytvořte balíček důkazních podkladů k API za pět pracovních dnů

Cílem rychlého sprintu není opravit veškeré zabezpečení API během jednoho týdne. Cílem je vytvořit obhajitelný výchozí stav, identifikovat mezery a zahájit ošetření rizik.

Den 1: zaveďte registr API

Exportujte trasy z API bran, service mesh, cloudových load balancerů, serverless funkcí, repozitářů OpenAPI a manifestů nasazení CI/CD. Normalizujte je do jednoho registru API s koncovým bodem, prostředím, vlastníkem, obchodním procesem, klasifikací dat, indikátorem osobních údajů, metodou autentizace, limitem četnosti požadavků, stavem protokolování, závislostí na dodavateli, kritičností a datem posledního přezkumu.

Použijte ustanovení 6.1.1 Politiky správy aktiv a krok 22 Zenith Blueprint jako oporu správy a řízení.

Den 2: klasifikujte mezery v autentizaci

Vytvořte matici autentizace. Označte API používající statické API klíče, dlouhodobé tokeny, chybějící ověření příjemce, chybějící ověření rozsahu, chybějící mTLS pro partnerské integrace, sdílené servisní účty nebo chybějící důkazní podklady k rotaci.

Namapujte zjištění na ustanovení 5.3.1 Politiky požadavků na zabezpečení aplikací a krok 19 Zenith Blueprint. Každou mezeru zaznamenejte jako riziko s vlastníkem, způsobem ošetření a cílovým datem.

Den 3: doložte omezování četnosti požadavků a opatření proti zneužití

U veřejných, partnerských a administrátorských API zachyťte politiky brány, pravidla WAF, opatření proti botům, nastavení kvót a prahové hodnoty upozornění. Kde opatření chybí, zaznamenejte kompenzační opatření nebo otevřené ošetření rizika.

Použijte ustanovení 5.3.2 Politiky požadavků na zabezpečení aplikací jako autoritativní požadavek politiky. U kritických API propojte prahové hodnoty s dopadem na službu, újmou zákazníka a očekáváními odolnosti podle DORA nebo NIS2.

Den 4: ověřte pokrytí protokolováním

Odeberte vzorek logů pro vysoce riziková API. Potvrďte, že logy zachycují úspěšnou autentizaci, neúspěšnou autentizaci, zamítnutí autorizace, přístup k datům, administrátorskou změnu, událost omezování četnosti požadavků, zdrojovou identitu a korelační ID. Ověřte synchronizaci času, uchovávání, řízení přístupu a ochranu proti manipulaci.

Pokud logy obsahují tokeny, tajemství nebo nadměrné osobní údaje, založte položky nápravných opatření pro ochranu soukromí a bezpečnost.

Den 5: předejte balíček odpovědi pro audit

Předejte stručný soubor důkazních podkladů:

• Export evidence API a souhrn vlastnictví.
• Registr rizik API s plánem ošetření rizik.
• Matici autentizace a důkazní podklady k přezkumu tokenů.
• Důkazní podklady k omezování četnosti požadavků a schválené výjimky.
• Zprávu o pokrytí protokolováním a snímky řídicích panelů SIEM.
• Postup klasifikace incidentů pro zneužití API.
• Mapování napříč rámci souladu na pohledy auditů podle ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 a auditů sladěných s COBIT.

Důležitý posun spočívá v tom, že každý artefakt má příběh opatření. Registr API podporuje správu aktiv. Autentizace podporuje řízení přístupu. Limity četnosti požadavků podporují zabezpečení aplikací a odolnost. Logy podporují detekci, reakci na incidenty a odpovědnost.

Mapování správy a řízení API napříč rámci souladu

Největší chybou je vytvářet samostatné sady důkazních podkladů pro každý rámec. Správa a řízení API funguje lépe jako jeden model opatření s více regulačními pohledy.

ISO/IEC 27001:2022 poskytuje systém řízení, který drží důkazní podklady pohromadě. Clauses 4.1 až 4.4 vyžadují, aby organizace definovala kontext a rozsah ISMS, včetně zainteresovaných stran, právních, regulačních a smluvních povinností a rozhraní nebo závislostí na jiných organizacích. Clauses 5.1 až 5.3 ukládají odpovědnost vrcholovému vedení. Clauses 6.1.1 až 6.1.3 vytvářejí proces posouzení rizik, ošetření rizik a Prohlášení o použitelnosti. Clause 8.1 vyžaduje operativní plánování a řízení, včetně řízení externě poskytovaných procesů, produktů nebo služeb relevantních pro ISMS.

Pro správu a řízení API to znamená, že API třetí strany pro platby, cloudové API identit nebo outsourcované API detekce podvodů není mimo oblast souladu jen proto, že je externí. Je to rozhraní a závislost, které musí být zahrnuty do rozsahu, posouzeny z hlediska rizik a řízeny.

NIST CSF 2.0 přidává užitečný pohled pro vedení. Jeho funkce GOVERN pomáhá organizacím definovat očekávání zainteresovaných stran, právní povinnosti, ochotu podstupovat riziko a rizika dodavatelského řetězce. Přístup Profiles podporuje aktuální profil, cílový profil, prioritizovaný plán mezer a cyklus neustálého zlepšování. Přesně tak má fungovat sprint správy a řízení API.

COBIT 2019 může podpořit manažerský pohled tím, že propojí opatření API s cíli správy a řízení, vlastnictvím opatření, kontinuitou služeb, monitorováním bezpečnosti, vykazováním rizik a sledováním problémů. Klíčem není vtlačit API do jediného rámce, ale ukázat, že jeden důkazní model odpovídá na více otázek zajištění.

Jak auditoři testují správu a řízení API

Silný program předvídá auditorský pohled. Stejné důkazní podklady budou testovány odlišně podle rámce.

Clarysec doporučuje triangulaci důkazních podkladů. Neukazujte pouze politiku. Ukažte politiku, důkazní podklady k implementaci a důkazní podklady k provozu.

Například:

• Politika: API musí používat OAuth 2.0 nebo mTLS tam, kde je to vhodné.
• Konfigurace: trasa API brány ukazuje validaci JWT a povoleného příjemce.
• Provozní důkazní podklady: neúspěšné pokusy s tokenem jsou protokolovány a upozorňování je aktivní.
• Důkazní podklady z přezkumu: přezkum klienta OAuth byl dokončen se schválením vlastníka.
• Důkazní podklady k riziku: výjimka pro zastaralé API má kompenzační opatření a lhůtu ošetření.

To je mnohem silnější než odpověď založená pouze na snímcích obrazovky.

Časté chyby ve správě a řízení API

Nejčastějším problémem není to, že by API byla zcela nezabezpečená. Problémem je nekonzistentní zabezpečení.

Jeden tým používá rozsahy OAuth správně, jiný používá sdílený API klíč. Jedna služba protokoluje přístup k datům, jiná pouze chyby serveru. Jedna partnerská integrace má mTLS, jiná spoléhá na dlouhodobý bearer token. Limity četnosti požadavků existují pro veřejné koncové body, ale ne pro autentizovaná zákaznická API, kde může docházet ke scrapingu. CMDB uvádí aplikaci, ale ne její API, tokeny, certifikáty, kategorie dat ani dodavatele.

Opakující se chyby zahrnují:

• Shadow API nasazená prostřednictvím serverless funkcí nebo dočasných testovacích tras.
• API klíče uložené v proměnných CI/CD bez dokumentované rotace.
• Protokolování, které zachycuje tokeny, tajemství nebo zbytečné osobní údaje.
• Chybějící korelační ID napříč logy brány, aplikace a databáze.
• Výjimky z limitů četnosti požadavků udělené neformálně pro velké zákazníky.
• Partnerská API bez smluvního oznámení incidentu nebo práv na audit.
• Chybějící klasifikace incidentů specifická pro API pro enumeraci, scraping nebo zneužití tokenů.
• Chybějící mapování mezi datovými toky API a záznamy o zpracování podle GDPR.
• Bezpečnostní testování zaměřené na webové uživatelské rozhraní, zatímco API zůstávají netestovaná.
• Reporty vedoucím orgánům uvádějící „zabezpečení aplikací“ bez metrik rizik specifických pro API.

Jde o řešitelné problémy, ale pouze tehdy, pokud organizace chápe správu a řízení API jako řízenou doménu opatření.

Přeměňte zabezpečení API na správu a řízení připravené na audit

Pokud se vás příští audit zeptá na důkazní podklady k zabezpečení API, nezačínejte sběrem náhodných snímků obrazovky. Začněte příběhem opatření.

Clarysec vám jej pomůže vybudovat prostřednictvím:

• Zenith Blueprint Zenith Blueprint, který strukturuje implementaci napříč evidencí aktiv, bezpečnou autentizací, požadavky na zabezpečení aplikací a protokolováním.
• Zenith Controls Zenith Controls, který mapuje opatření ISO/IEC 27002:2022, například 5.9, 8.5, 8.15 a 8.26, na očekávání napříč rámci souladu a auditorské pohledy.
• Politik Clarysec včetně Politiky správy aktiv Politika správy aktiv, Politiky požadavků na zabezpečení aplikací Politika požadavků na zabezpečení aplikací, Politiky používání cloudových služeb Politika používání cloudových služeb, Politiky správy aktiv – SME Politika správy aktiv – SME, Politiky požadavků na zabezpečení aplikací – SME Politika požadavků na zabezpečení aplikací – SME a Politiky protokolování a monitorování – SME Politika protokolování a monitorování – SME.

Praktickým dalším krokem je spustit Clarysec API Governance Evidence Sprint: zaevidovat vaše API, klasifikovat autentizaci, ověřit omezování četnosti požadavků, validovat protokolování, zmapovat závislosti na třetích stranách a vytvořit balíček důkazních podkladů připravený pro ISO 27001 s pohledy auditů sladěnými s NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT.

API jsou místem, kde se potkává obchodní logika, zákaznická data a závislosti na třetích stranách. V roce 2026 si zaslouží víc než technickou ochranu. Potřebují správu a řízení, které obstojí při auditu, podpoří reakci vůči regulačnímu orgánu a pomůže vašim týmům odhalit zneužití dříve než zákazníci.