--- title: "Sådan sikrer du API'er med følsomme eller regulerede data" description: "Konkrete kontroller for API'er med bank-, energi- og forsyningsdata: trusselsmodel, autorisation, mindste privilegium, dataminimering, hemmeligheder, auditlogs." canonical: https://sdk.enterprises/da/insights/securing-regulated-data-apis language: da --- # Sådan sikrer du API'er med følsomme eller regulerede data Opdateret: 2026-09-25 > Sikr et API med regulerede data ved at modellere, hvem der kan misbruge det, tjekke autorisation på hvert objekt og hvert felt, indsamle og returnere så få data som muligt og holde hemmeligheder og auditlogs under streng kontrol. De svagheder, der betyder mest i praksis, er huller i autorisationen og svar, der afslører for mange data, ikke brudt kryptering. ## Start med en trusselsmodel for dataene, ikke for frameworket Før du vælger værktøjer, så skriv ned, hvad API'et eksponerer, og hvem der kan misbruge det. For en bank betyder det konto- og transaktionsdata; for en energi- eller forsyningsvirksomhed kan det betyde måledata, kundekontrakter og driftsmålinger fra nettet. En nyttig trusselsmodel er kort. Den oplister de følsomme data, alle kaldere, der kan nå dem, de handlinger, hver kalder skal kunne udføre, og hvad der sker, hvis en af dem bliver kompromitteret. Det dokument styrer derefter alle kontrollerne nedenfor og fortæller reviewerne, hvad de skal teste. - Hvilke data der er personlige, fortrolige eller regulerede, og hvor de er gemt. - Alle, der bruger API'et: interne tjenester, partnere, mobilapps og administratorer. - Hvad hver bruger af API'et må læse, ændre eller udløse. - Konsekvensen af et lækket token, en ondsindet insider eller et kompromitteret partnersystem. ## Autentificér hver kalder, og autorisér derefter hvert objekt Brug en standardprotokol som OAuth 2.0 med OpenID Connect for brugere og kortlivede tokens eller gensidig TLS for kald mellem tjenester. Undgå langlivede, delte API-nøgler, fordi ingen kan se, hvilket system der har brugt dem, eller tilbagekalde dem uden at ødelægge noget for andre. Autentificering beviser kun, hvem der kalder. Det første punkt i OWASP API Security Top 10 er broken object level authorization: en gyldig bruger ændrer et id i forespørgslen og læser en andens post. Tjek ejerskab eller tenant på serveren for hvert objekt, hver funktion og hvert følsomt felt, og stol aldrig på et id eller en rolle, som klienten sender. ## Giv hver klient og tjeneste de mindst mulige rettigheder Mindste privilegium begrænser skaden, når noget går galt. Udsted separate adgangsoplysninger pr. bruger af API'et, afgræns tokens til bestemte operationer, og hold administrative endpoints på en separat sti med skrappere kontroller. Anvend den samme regel under API'et. Den servicekonto, der læser måledata, bør ikke kunne slette dem, og et rapporteringsjob bør forbinde med en databaserolle med kun læseadgang. Gennemgå rettigheder efter en fast plan, fordi adgang, der er givet til en engangsopgave, har det med at blive for evigt. ## Indsaml mindre, returnér mindre, og opbevar det kortere Dataminimering er både et princip i GDPR og en stærk sikkerhedskontrol: data, du aldrig gemmer, kan ikke lække. Spørg for hvert felt, om tjenesten virkelig har brug for det, og fjern eller pseudonymisér det, den ikke har brug for. Anvend den samme disciplin på svarene. Definér eksplicitte svarskemaer i stedet for at serialisere hele databaseobjekter, maskér id'er som kontonumre, hvor den fulde værdi ikke er nødvendig, og fastsæt opbevaringsperioder, så gamle poster slettes. Dokumentér retsgrundlaget for hvert behandlingsformål, og indgå databehandleraftaler med alle leverandører, der håndterer dataene. Dette er god udviklingspraksis, ikke juridisk rådgivning, så inddrag din databeskyttelsesrådgiver (DPO) eller din advokat i den juridiske vurdering. ## Validér hvert input, og begræns, hvad én kalder kan forbruge Behandl hver forespørgsel som fjendtlig, indtil den er valideret. Håndhæv et skema for hvert endpoint, afvis ukendte felter, og brug parametriserede forespørgsler, så input aldrig bliver en del af en databasekommando. Flere af OWASP's API-risici skyldes manglende grænser snarere end dårlig kode. Indfør rate limiting pr. klient, sæt loft over sidestørrelser og payloadstørrelser, og beskyt følsomme forretningsforløb som betalinger eller kontraktændringer mod automatiseret misbrug. Hvis API'et henter eksterne URL'er på vegne af kaldere, så begræns destinationerne for at forhindre server-side request forgery. ## Hold hemmeligheder ude af kode, images og logs Databaseadgangskoder, signeringsnøgler og partneres adgangsoplysninger hører hjemme i en dedikeret secrets manager, hvorfra de indsættes ved kørsel og roteres efter en fast plan. Scan repositories og container-images for hemmeligheder i build-pipelinen, og betragt enhver hemmelighed, der når versionsstyringen, som kompromitteret. Adskil hemmeligheder pr. miljø, så en lækket testadgang aldrig åbner produktion. Begræns, hvem der kan læse hemmeligheder i produktion, og log hver adgang til dem. ## Log til revision, og design efter færre hændelser Regulerede miljøer skal bagefter kunne svare på et enkelt spørgsmål: hvem tilgik hvilke data, hvornår og gennem hvilken klient. Registrér det for hver følsom læsning og skrivning, gem logs, hvor applikationens driftsfolk ikke kan ændre dem, og hold persondata ude af logbeskederne. Kombinér logning med alarmer ved usædvanlige mønstre, for eksempel en klient, der læser langt flere poster end normalt, og en testet beredskabsplan for hændelser. Gennem Sopra Steria byggede vores udviklere sikre API'er til følsomme forsyningsdata under regulatoriske krav og ledede et værktøj til driftsovervågning, hvor håndhævede sikkerhedsstandarder gik hånd i hånd med færre produktionshændelser. SDK Enterprises anvender i dag den samme praksis på kundeprojekter. ## Det vigtigste - En kort, skriftlig trusselsmodel for dataene bør styre hver sikkerhedskontrol i API'et. - Tjek autorisation på serveren for hvert objekt, hver funktion og hvert følsomt felt, ikke kun ved login. - Mindste privilegium gælder både for tokens, servicekonti og databaseroller. - Dataminimering mindsker både eksponeringen efter GDPR og konsekvensen af et eventuelt brud. - Auditlogs skal vise, hvem der tilgik hvad og hvornår, uden selv at lække persondata. ## FAQ ### Er HTTPS nok til at sikre et API? Nej. TLS beskytter data under overførsel, men mange brud på API'er handler om autentificerede kaldere, der når data, de ikke burde se. Kontrol af autorisation, validering af input, rate limits og auditlogning er stadig nødvendige. ### Hvad er broken object level authorization? Det er en fejl, hvor API'et tjekker, at en kalder er logget ind, men ikke, at den forespurgte post tilhører vedkommende. Når man ændrer et id i URL'en eller i forespørgslens indhold, bliver andre brugeres data så eksponeret. Løsningen er et tjek af ejerskab eller tenant på serveren for hvert objekt. ### Foreskriver GDPR bestemte sikkerhedskontroller for API'er? GDPR kræver passende tekniske og organisatoriske foranstaltninger i forhold til risikoen uden at pålægge bestemte værktøjer. Kontroller som adgangsbegrænsning, minimering, pseudonymisering og logning er almindelige måder at opfylde kravet på, og dine juridiske rådgivere bør bekræfte, hvad der gælder i dit tilfælde. ## Relaterede ydelser - [Applikationssikkerhed](https://sdk.enterprises/da/services/secure-systems)