API-sikkerhedsstyring: ISO 27001-revisionsbeviser for 2026

API-revisionskonstateringen, der kommer før bruddet

Maria, CISO i en hurtigt voksende fintech-SaaS-virksomhed, åbner en e-mail fra den ledende revisor tre uger før den årlige vurdering. Budskabet er direkte:

“Vi gennemfører en dybdegående gennemgang af jeres ramme for styring af IKT-tredjepartsrisiko og dens tilpasning til DORA, NIS2 og GDPR med særligt fokus på jeres API-økosystem. Fremsend venligst fortegnelsen, autentifikationsmodellen, revisionsbeviser for hastighedsbegrænsning og logningsdækning for produktions- og partner-API’er.”

To dage senere sender intern revision en ny besked:

“Vi har identificeret 47 offentligt eksponerede API-endpoints, som ikke fremgår af aktivfortegnelsen. Fire accepterer API-nøgler uden dokumentation for rotation. Én partnerintegration har ingen hastighedsbegrænsning. Logningen er inkonsistent på tværs af produktionstjenester. Fremsend venligst ISO 27001-, GDPR- og NIS2-revisionsbeviser senest fredag.”

Der er ingen ransomware-besked. Intet offentligt brud. Ingen kundeklage. Men konstateringen er alvorlig, fordi den afdækker det styringshul, som angribere allerede udnytter. API’er er nu den reelle perimeter. De forbinder betalinger, onboarding, identitet, kundeportaler, leverandørtjenester, mobilapps, cloud-workloads, analyseplatforme og outsourcede risikomotorer.

En nærved-hændelse gør problemet sværere at ignorere. En juniorudvikler, der arbejdede under pres, eksponerede et staging-API på internettet uden autentifikation. Det indeholdt realistiske, pseudonymiserede kundedata. Red Team fandt det først, men ledelsen stillede det oplagte spørgsmål: Hvad ellers ligger derude?

I 2026 er API-sikkerhedsstyring ikke kun en tjekliste for udviklere. CISO’er, compliance-ansvarlige, interne revisorer og bestyrelser skal kunne dokumentere, at API’er er kendte, ejet, autentificerede, overvågede, hastighedsbegrænsede, testede, risikovurderede og omfattet af hændelsesrapportering. De samme revisionsbeviser skal ofte opfylde forventninger til assurance efter ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT.

De fleste organisationer har allerede tekniske værktøjer: API-gateways, identitetsudbydere, SIEM-platforme, WAF’er, cloud-logfiler, service meshes, CI/CD-pipelines og helpdesk-systemer. Det, de ofte mangler, er den kontrolmæssige sammenhæng. Hvilke API’er er omfattet? Hvem godkender nye API’er? Hvilke logfiler dokumenterer autentifikationsfejl? Hvilket register viser tredjepartsafhængigheder for API’er? Hvorfor er hastighedsbegrænsninger forskellige for kunde-, administrator- og machine-to-machine-API’er?

Clarysecs tilgang er at behandle API-sikkerhedsstyring som et tværgående system for revisionsbeviser, ikke som en isoleret ingeniøropgave. Hvis et API kan eksponere data, ændre en forretningsproces, autentificere en bruger, udløse en betaling, kalde en leverandør eller understøtte en reguleret tjeneste, hører det hjemme i ISMS-modellen for revisionsbeviser.

Hvorfor API-styring nu er et bestyrelsesanliggende

NIS2 gør cybersikkerhedsstyring til et ansvar for ledelsesorganet. Article 20 kræver, at ledelsesorganer godkender foranstaltninger til styring af cybersikkerhedsrisici, fører tilsyn med implementeringen og modtager uddannelse, så de kan forstå cyberrisici og deres påvirkning af tjenester. Article 21 kræver passende og forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger, herunder risikoanalyse, sikkerhedspolitikker, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse og udvikling, håndtering af sårbarheder, effektivitetsvurdering, cyberhygiejne, kryptografi, adgangsstyring, aktivstyring og multifaktorautentifikation eller løbende autentifikation, hvor det er relevant.

For API-styring betyder det, at offentlige API’er, partner-API’er, administrator-API’er og interne mikroservice-API’er kan indgå i reguleret levering af tjenester. NIS2 kan gælde for udbydere af cloud computing-tjenester, datacentertjenester, content delivery-netværk, tillidstjenester, offentlige elektroniske kommunikationsnet og -tjenester samt udbydere af IKT-servicestyring såsom MSP’er og MSSP’er, afhængigt af sektor, størrelse, kritikalitet og medlemsstatens klassificering.

DORA tilføjer et finanssektorperspektiv. Den finder anvendelse fra 17. januar 2025 og fastsætter ensartede krav til styring af IKT-risiko, rapportering af IKT-relaterede hændelser, test af digital operationel robusthed, informationsdeling og styring af IKT-tredjepartsrisiko. Article 5 kræver, at ledelsesorganet definerer, godkender, fører tilsyn med og fortsat er ansvarligt for rammeværket for styring af IKT-risici. Article 8 kræver identifikation, klassificering og dokumentation af IKT-understøttede forretningsfunktioner, informationsaktiver, IKT-aktiver, afhængigheder, tredjepartsunderstøttede processer, kritiske aktiver, fortegnelser og legacy-IKT-risiko.

I API-termer er et API til betalingsinitiering, et API til svigscore, et API til kundeonboarding eller et outsourcet KYC-API ikke blot et endpoint. Det er et IKT-aktiv og en afhængighed, der understøtter en forretningsfunktion.

GDPR fuldender billedet. API’er, der transmitterer identifikatorer, kontodata, enheds-id’er, adfærdstelemetri, biometriske data, helbredsrelaterede data eller finansielle profiler, kan behandle personoplysninger. GDPR’s ansvarlighedsprincip kræver, at dataansvarlige kan dokumentere overholdelse af lovlighed, formålsbegrænsning, dataminimering, opbevaringsbegrænsning, integritet og fortrolighed. Article 32 kræver behandlingssikkerhed, mens Articles 33 og 34 afhænger af pålidelige revisionsbeviser, når der sker et brud på persondatasikkerheden.

Bestyrelsen har ikke brug for packet captures, men den har brug for tillid til, at organisationen ved, hvilke API’er der er vigtige, hvilke data de håndterer, hvilke leverandører de afhænger af, hvordan misbrug forebygges, hvordan hændelser detekteres, og hvordan compliance kan dokumenteres.

Begynd med API-fortegnelsen

De fleste API-fejl begynder som mangler i aktivfortegnelsen. En udfaset mobilbackend kører stadig i produktionsmiljøet. En midlertidig partnerintegration bliver permanent. En cloudfunktion eksponerer et nyt endpoint. Et internt API bliver internettilgængeligt efter en ændring i en load balancer. Intet af det fremgår af CMDB’en, og derfor bliver intet af det omfattet af gennemgang af autentifikation, logningsstandarder, tærskler for hastighedsbegrænsning, leverandørvurdering eller klassificering af opbevaring.

Det første revisionsspørgsmål er ofte enkelt: “Må jeg se jeres fortegnelse over API’er?”

Clarysec behandler API-fortegnelsen som en del af ISMS-aktivfortegnelsen. I Zenith Blueprint: En revisors 30-trins køreplan Zenith Blueprint, fasen Kontroller i praksis, trin 22, forklarer vejledningen til ISO/IEC 27002:2022-kontrol 5.9:

“Ingen organisation kan beskytte det, den ikke ved, at den har. Control 5.9 formaliserer dette grundlæggende princip og kræver etablering og vedligeholdelse af en ajourført fortegnelse over alle informationsaktiver og tilknyttede aktiver, der er relevante for ISMS.”

Det samme trin omfatter logiske aktiver såsom “brugerkonti, legitimationsoplysninger, nøgler, softwarelicenser, API’er” og servicerelaterede aktiver såsom SaaS-platforme og outsourcet lagring. Zenith Blueprint kalder fortegnelsen “centralnervesystemet i dit ISMS”, fordi den informerer adgangstildeling, kryptering, backup, logning, klassificering og opbevaring.

Clarysecs enterprise-Politik for styring af aktiver Politik for styring af aktiver omsætter dette til et styringskrav:

“IT Asset Manager skal vedligeholde en omfattende og centraliseret aktivfortegnelse, der dækker alle informationsaktiver, som organisationen anvender, eller som er forbundet til organisationen.”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.

For SMV’er omfatter Clarysecs Politik for styring af aktiver - SMV Politik for styring af aktiver - SMV eksplicit API-relevante digitale aktiver:

“Digitale legitimationsoplysninger og tjenester: domænenavne, digitale certifikater, API-nøgler, e-mailkonti, cloud-login”

Fra afsnittet “Omfang”, politikklausul 2.2.4.

Den formulering er vigtig. I mange revisioner fremgår API-endpointet af en gateway, tokenet fremgår af en secrets vault, certifikatet fremgår af en cloud-konto, og dataflowet fremgår af en privatlivsregistrering. En revisionsmæssigt holdbar API-fortegnelse forbinder dem.

I Zenith Controls: Tværgående compliance-guide Zenith Controls klassificeres ISO/IEC 27002:2022-kontrol 5.9, Fortegnelse over information og andre tilknyttede aktiver, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. Dens cybersikkerhedskoncept er Identify, dens operationelle kapacitet er Asset Management, og dens sikkerhedsdomæner er Governance, Ecosystem og Protection. Det hjælper revisorer med at se API-fortegnelsen som en forebyggende styringskontrol, ikke som administrativ oprydning.

Dokumentér, at hver API-identitet er tilsigtet

Når fortegnelsen findes, er det næste spørgsmål forudsigeligt: Hvem eller hvad kan kalde disse API’er?

Moderne API’er autentificerer menneskelige brugere, mobilapps, servicekonti, CI/CD-job, partnersystemer, workloads, bots, integrationer, datapipelines og tredjepartsplatforme. Svage API-nøgler, langlivede bearer tokens, manglende mutual TLS, OAuth-scopes med for brede rettigheder og hårdkodede hemmeligheder skaber alle revisionsmæssig eksponering.

Zenith Blueprint, fasen Kontroller i praksis, trin 19, behandler ISO/IEC 27002:2022-kontrol 8.5, Sikker autentifikation:

“Autentifikation er den første og mest kritiske forsvarslinje mellem en trusselsaktør og jeres systemer, data og tjenester. Hvis autentifikationen er svag, kan alt andet — kryptering, overvågning, segmentering — omgås.”

Det samme trin fremhæver machine-to-machine-autentifikation. Nøgler, certifikater og tokens skal beskyttes stringent, legitimationsoplysninger bør ikke indlejres i kode, og håndtering af hemmeligheder eller bokse med kontrolleret adgang bør anvendes til sikker lagring og rotation.

Clarysecs enterprise-Politik for krav til applikationssikkerhed Politik for krav til applikationssikkerhed bringer dette direkte ind i API-styringen:

“Alle application programming interfaces (API’er), mikroservices og eksterne integrationer skal sikres gennem:”

Fra afsnittet “Styringskrav”, politikklausul 5.3.

Den specificerer derefter:

“Håndhævelse af stærk autentifikation, såsom OAuth 2.0 og mutual TLS”

Fra afsnittet “Styringskrav”, politikklausul 5.3.1.

For mindre organisationer fastsætter Clarysecs Politik for krav til applikationssikkerhed - SMV Politik for krav til applikationssikkerhed - SMV baselinekravet:

“Autentifikationskontroller: Applikationer skal håndhæve stærk autentifikation, herunder mindste adgangskodestyrke, kontolåsning efter mislykkede forsøg og sessionstimeout.”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.2.

For API’er skal disse krav omsættes til en dokumentationspakke for autentifikation:

1. API-fortegnelse filtreret efter internetvendte, partnervendte, administrator- og interne API’er.
2. Autentifikationsmatrix, der viser OAuth 2.0, mTLS, signerede requests, gateway authorizers eller service mesh-identitet.
3. OAuth-klient- og scoperegister med ejer, formål, udløb, godkendelse og seneste gennemgangsdato.
4. Dokumentation for håndtering af hemmeligheder, der viser lagring, adgang, rotation og tilbagekaldelse.
5. Gennemgang af privilegeret API-adgang for administratorendpoints og servicekonti i produktionsmiljøet.
6. Logfiler for mislykket autentifikation og alarmregler.
7. Testresultater for manglende token, udløbet token, forkert audience, forkert scope og replay-scenarier.

I Zenith Controls mappes ISO/IEC 27002:2022-kontrol 8.5, Sikker autentifikation, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. Dens cybersikkerhedskoncept er Protect, dens operationelle kapacitet er Identity and access management, og dens sikkerhedsdomæne er Protection.

NIS2 Article 21 understøtter dette gennem adgangsstyring, kryptografi og multifaktorgodkendelse eller løbende autentifikation, hvor det er relevant. DORA forventer, at finansielle enheder opretholder kontroller, der beskytter autenticitet, integritet, tilgængelighed og fortrolighed. GDPR Article 32 gør svag API-autentifikation til et spørgsmål om behandlingssikkerhed, især hvor personoplysninger eksponeres.

Behandl hastighedsbegrænsning som robusthedsbevis

Stærk autentifikation er nødvendig, men ikke tilstrækkelig. En autentificeret klient kan stadig misbruge et API. Angribere bruger API’er til credential stuffing, enumeration, scraping, token spraying, password reset bombing, transaktionsmisbrug og denial of service.

Hastighedsbegrænsning blev tidligere betragtet som en performancefunktion. I 2026 er det revisionsbevis for sikkerhed, privatliv og robusthed.

Clarysecs Politik for krav til applikationssikkerhed fastslår:

“Hastighedsbegrænsning og forebyggelse af misbrug”

Fra afsnittet “Styringskrav”, politikklausul 5.3.2.

Zenith Blueprint, fasen Kontroller i praksis, trin 20, for ISO/IEC 27002:2022-kontrol 8.26, Krav til applikationssikkerhed, forklarer, at krav til applikationssikkerhed skal være præcise og handlingsorienterede. Den spørger, om en applikation skal være robust over for injektionsangreb, brute-force-login eller denial-of-service-forsøg. Den giver også det API-specifikke eksempel, at et nyt API bør omfatte validering af adgangstoken og inputvalidering, og bemærker, at offentligt tilgængelige platforme kan kræve strengere validering, analyse af brugeradfærd og hastighedsbegrænsning.

En revisionsmæssigt holdbar registrering af hastighedsbegrænsning skal ikke kun forklare, at throttling findes, men også hvorfor tærsklerne blev valgt, hvem der godkendte undtagelser, og hvordan alarmer overvåges.

For NIS2 understøtter dette sikker udvikling, effektivitetsvurdering, forretningskontinuitet og forebyggelse af hændelser. For DORA kobler hastighedsbegrænsning sig til styring af IKT-risiko, anomalidetektion, robusthedstest og kontinuitet for kritiske eller vigtige funktioner. For GDPR understøtter det dataminimering og beskyttelse mod overdreven eller ulovlig adgang, især hvor API-scraping kan eksponere personoplysninger.

Gør logning til bevislaget

Når der opstår en API-hændelse, er det første reelle spørgsmål ikke “Har I et SIEM?” Det er “Kan I rekonstruere, hvad der skete?”

API-logfiler bør registrere autentifikationsfejl, afviste autorisationer, token claims, klientidentitet, kilde, endpoint, metode, request-resultat, administrative ændringer, adgang til højrisikodata, hændelser ved hastighedsbegrænsning, unormalt volumen, konfigurationsændringer og sikkerhedsrelevante fejl. De skal samtidig undgå at logge hemmeligheder, bearer tokens eller unødvendige personoplysninger.

Zenith Blueprint, fasen Kontroller i praksis, trin 19, for ISO/IEC 27002:2022-kontrol 8.15, Logning, fastslår:

“Logning er livsnerven i ethvert sikkert IT-miljø. Uden den forbliver hændelser usynlige, ansvarlighed udviskes, og årsags- og virkningssammenhænge forsvinder i den blå luft.”

Den forklarer også, at logning handler om sporbarhed, og at brugbare logfiler skal lagres sikkert, overvåges, gennemgås og beskyttes mod manipulation.

Clarysecs Politik for krav til applikationssikkerhed - SMV kræver:

“Revisionslogning: Applikationer skal logge autentifikationshændelser (login, logud og mislykkede forsøg), dataadgang og administrative ændringer.”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.7.

Clarysecs Lognings- og overvågningspolitik - SMV Lognings- og overvågningspolitik - SMV fastlægger styringskategorien for logning:

“Påkrævede logtyper”

Fra afsnittet “Styringskrav”, politikklausul 5.4.

For API’er i cloudmiljøer forstærker Clarysecs enterprise-Politik for brug af cloudtjenester Politik for brug af cloudtjenester kravet:

“Logfiler skal registrere:”

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.5.2.

I Zenith Controls mappes ISO/IEC 27002:2022-kontrol 8.15, Logning, som en opdagende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. Dens cybersikkerhedskoncept er Detect, dens operationelle kapacitet er Information security event management, og dens sikkerhedsdomæner er Protection og Defense. Det gør logning til broen mellem politik og dokumentation.

NIS2 Article 23 kræver trinvis rapportering af væsentlige hændelser: tidlig advarsel inden for 24 timer efter kendskab, hændelsesunderretning inden for 72 timer, mellemliggende rapporter, hvis de anmodes om, og en endelig rapport inden for én måned efter underretningen. For tillidstjenesteudbydere, der påvirkes i leveringen af tillidstjenester, kræves underretning inden for 24 timer efter kendskab.

DORA Articles 17 to 19 kræver styring af IKT-relaterede hændelser med indikatorer for tidlig advarsel, klassificering af alvorlighed og kritikalitet, eskalering, logning, opfølgning på rodårsag og rapportering af større IKT-relaterede hændelser gennem indledende, mellemliggende og endelige rapporter. GDPR-vurdering af brud afhænger også af logfiler for at afgøre, om personoplysninger er blevet tilgået, hvilke personer der er berørt, og om underretningspligter udløses.

Opbyg en API-dokumentationspakke på fem arbejdsdage

Målet med et hurtigt sprint er ikke at rette al API-sikkerhed på én uge. Målet er at skabe en revisionsmæssigt holdbar baseline, identificere huller og påbegynde risikobehandling.

Dag 1: etabler API-registeret

Eksportér ruter fra API-gateways, service meshes, cloud-load balancers, serverless functions, OpenAPI-repositories og CI/CD-udrulningsmanifester. Normalisér dem til ét samlet API-register med endpoint, miljø, ejer, forretningsproces, dataklassificering, indikator for personoplysninger, autentifikationsmetode, hastighedsbegrænsning, logningsstatus, leverandørafhængighed, kritikalitet og seneste gennemgangsdato.

Brug Politik for styring af aktiver klausul 6.1.1 og Zenith Blueprint trin 22 som styringsmæssigt anker.

Dag 2: klassificér autentifikationshuller

Opret en autentifikationsmatrix. Markér API’er, der bruger statiske API-nøgler, langlivede tokens, manglende audience-validering, manglende scope-validering, manglende mTLS for partnerintegrationer, delte servicekonti eller manglende dokumentation for rotation.

Map konstateringer til Politik for krav til applikationssikkerhed klausul 5.3.1 og Zenith Blueprint trin 19. Registrér hvert hul som en risiko med ejer, behandlingsspor og måldato.

Dag 3: dokumentér hastighedsbegrænsning og misbrugskontroller

For offentlige, partner- og administrator-API’er indsamles gateway-politikker, WAF-regler, botkontroller, kvoteindstillinger og alarmtærskler. Hvor kontroller mangler, registreres kompenserende kontroller eller åben risikobehandling.

Brug Politik for krav til applikationssikkerhed klausul 5.3.2 som politisk grundlag. For kritiske API’er kobles tærskler til tjenestepåvirkning, kundeskade og robusthedsforventninger efter DORA eller NIS2.

Dag 4: validér logningsdækning

Udtag prøver af logfiler for højrisiko-API’er. Bekræft, at logfiler registrerer vellykket autentifikation, mislykket autentifikation, afvist autorisation, dataadgang, administratorændring, hændelse ved hastighedsbegrænsning, kildeidentitet og korrelations-id. Verificér tidssynkronisering, opbevaring, adgangsstyring og manipulationsbeskyttelse.

Hvis logfiler indeholder tokens, hemmeligheder eller overdrevne personoplysninger, skal der oprettes afhjælpningspunkter for privatliv og sikkerhed.

Dag 5: lever revisionssvarpakken

Lever et kortfattet sæt revisionsbeviser:

• Eksport af API-fortegnelse og ejerskabsresumé.
• API-risikoregister med behandlingsplan.
• Autentifikationsmatrix og dokumentation for tokengennemgang.
• Dokumentation for hastighedsbegrænsning og godkendte undtagelser.
• Rapport om logningsdækning og skærmbilleder fra SIEM-dashboard.
• Playbook for hændelsesklassificering ved API-misbrug.
• Tværgående compliance-mapping til revisionsperspektiver tilpasset ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT.

Det vigtige skifte er, at hvert artefakt har en kontrolsammenhæng. API-registeret understøtter aktivstyring. Autentifikation understøtter adgangsstyring. Hastighedsbegrænsninger understøtter applikationssikkerhed og robusthed. Logfiler understøtter detektion, hændelseshåndtering og ansvarlighed.

Tværgående compliance-mapping for API-styring

Den største fejl er at opbygge separate sæt revisionsbeviser for hvert framework. API-styring fungerer bedre som én kontrolmodel med flere regulatoriske perspektiver.

ISO/IEC 27001:2022 leverer det ledelsessystem, der holder revisionsbeviserne samlet. Clauses 4.1 to 4.4 kræver, at organisationen definerer ISMS-kontekst og -omfang, herunder interessenter, retlige, regulatoriske og kontraktlige forpligtelser samt grænseflader eller afhængigheder til andre organisationer. Clauses 5.1 to 5.3 placerer ansvarlighed hos øverste ledelse. Clauses 6.1.1 to 6.1.3 etablerer processen for risikovurdering, risikobehandling og Anvendelseserklæring. Clause 8.1 kræver operationel planlægning og styring, herunder kontrol med eksternt leverede processer, produkter eller tjenester, der er relevante for ISMS.

For API-styring betyder det, at et tredjepartsbetalings-API, et cloud-identitets-API eller et outsourcet API til svigdetektion ikke falder uden for compliance, fordi det er eksternt. Det er en grænseflade og en afhængighed, der skal afgrænses, risikovurderes og kontrolleres.

NIST CSF 2.0 tilføjer et nyttigt ledelsesperspektiv. GOVERN-funktionen hjælper organisationer med at definere interessentforventninger, retlige forpligtelser, risikovillighed og risiko i forsyningskæden. Dens Profiles-tilgang understøtter en Current Profile, Target Profile, prioriteret plan for huller og en løbende forbedringscyklus. Det er præcis sådan et sprint for API-styring bør fungere.

COBIT 2019 kan understøtte ledelsesperspektivet ved at koble API-kontroller til styringsmål, kontrolejerskab, servicekontinuitet, sikkerhedsovervågning, risikorapportering og issue tracking. Nøglen er ikke at tvinge API’er ind i ét framework, men at vise, at én bevismodel besvarer flere assurance-spørgsmål.

Hvordan revisorer tester API-styring

Et stærkt program forudser revisors perspektiv. De samme revisionsbeviser testes forskelligt afhængigt af frameworket.

Clarysec anbefaler triangulering af revisionsbeviser. Vis ikke kun politikken. Vis politikken, implementeringsbeviset og driftsbeviset.

For eksempel:

• Politik: API’er skal anvende OAuth 2.0 eller mTLS, hvor det er relevant.
• Konfiguration: API-gateway-ruten viser JWT-validering og tilladt audience.
• Driftsbevis: Mislykkede tokenforsøg logges, og alarmering er aktiv.
• Gennemgangsbevis: OAuth-klientgennemgang er gennemført med ejerens godkendelse.
• Risikobevis: En undtagelse for et legacy-API har kompenserende kontroller og en behandlingsfrist.

Det er langt stærkere end et svar, der kun består af skærmbilleder.

Almindelige faldgruber i API-styring

Det mest almindelige problem er ikke, at API’er er helt usikrede. Det er, at sikkerheden er inkonsistent.

Ét team bruger OAuth-scopes godt, et andet bruger en delt API-nøgle. Én tjeneste logger dataadgang, en anden logger kun serverfejl. Én partnerintegration har mTLS, en anden baserer sig på et langlivet bearer token. Hastighedsbegrænsninger findes for offentlige endpoints, men ikke for autentificerede kunde-API’er, hvor scraping kan forekomme. CMDB’en angiver applikationen, men ikke dens API’er, tokens, certifikater, datakategorier eller leverandører.

Tilbagevendende faldgruber omfatter:

• Shadow APIs udrullet via serverless functions eller midlertidige testruter.
• API-nøgler lagret i CI/CD-variabler uden dokumenteret rotation.
• Logning, der registrerer tokens, hemmeligheder eller unødvendige personoplysninger.
• Manglende korrelations-id på tværs af gateway-, applikations- og databaselogfiler.
• Undtagelser fra hastighedsbegrænsning givet uformelt til store kunder.
• Partner-API’er uden kontraktlig hændelsesunderretning eller revisionsrettigheder.
• Manglende API-specifik hændelsesklassificering for enumeration, scraping eller tokenmisbrug.
• Manglende mapping mellem API-dataflows og GDPR-behandlingsregistreringer.
• Sikkerhedstest fokuseret på web-UI’et, mens API’er forbliver utestede.
• Bestyrelsesrapporter, der viser “applikationssikkerhed” uden API-specifikke risikomålinger.

Det er problemer, der kan løses, men kun hvis organisationen behandler API-styring som et styret kontroldomæne.

Gør API-sikkerhed til revisionsklar styring

Hvis din næste revision efterspørger revisionsbeviser for API-sikkerhed, skal du ikke starte med at indsamle tilfældige skærmbilleder. Start med kontrolsammenhængen.

Clarysec kan hjælpe dig med at opbygge den med:

• Zenith Blueprint Zenith Blueprint til at strukturere implementering på tværs af aktivfortegnelse, sikker autentifikation, krav til applikationssikkerhed og logning.
• Zenith Controls Zenith Controls til at mappe ISO/IEC 27002:2022-kontroller såsom 5.9, 8.5, 8.15 og 8.26 til tværgående compliance-forventninger og revisionsperspektiver.
• Clarysec-politikker, herunder Politik for styring af aktiver Politik for styring af aktiver, Politik for krav til applikationssikkerhed Politik for krav til applikationssikkerhed, Politik for brug af cloudtjenester Politik for brug af cloudtjenester, Politik for styring af aktiver - SMV Politik for styring af aktiver - SMV, Politik for krav til applikationssikkerhed - SMV Politik for krav til applikationssikkerhed - SMV og Lognings- og overvågningspolitik - SMV Lognings- og overvågningspolitik - SMV.

Et praktisk næste skridt er at gennemføre et Clarysec API Governance Evidence Sprint: registrér jeres API’er, klassificér autentifikation, verificér hastighedsbegrænsning, validér logning, map tredjepartsafhængigheder, og producer en ISO 27001-klar dokumentationspakke med revisionsperspektiver tilpasset NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT.

API’er er der, hvor forretningslogik, kundedata og tredjepartsafhængigheder mødes. I 2026 fortjener de mere end teknisk beskyttelse. De har brug for styring, der kan bestå en revision, understøtte et svar til en tilsynsmyndighed og hjælpe jeres teams med at opdage misbrug, før kunderne gør det.