Integrationer mellem systemer kører uden en person bag tastaturet. ERP-systemet henter ordrer fra webshoppen, lønsystemet sender filer til banken, og overvågningen spørger netværksudstyret om status. Hver af dem identificerer sig med en nøgle eller en konto, og de nøgler og konti kan dukke op i en penetrationstest. Fundene handler ikke nødvendigvis om, at nøglen er svag. De handler om, at den lever for længe, kan for meget og er kendt af for mange. Svaret på, hvad IT gør, hviler på samme livscyklus, som OWASP beskriver for hemmeligheder generelt: oprettelse, udskiftning, tilbagekaldelse og udløb, med så snævre rettigheder som muligt.
Hvad der er tale om
En API-nøgle er en tekststreng, som et program sender med for at blive genkendt. En integrationskonto er en konto i et system, som et andet system logger ind med. Begge giver adgang uden tofaktor og uden et menneske, der kan stoppe op og undre sig. Hvem der har nøglen, er for systemet det samme som den, nøglen tilhører.
Hemmeligheder i Azure og AWS har deres egne tjenester og regler. → Nøgler og hemmeligheder i cloud Nøgler og konti i de systemer, IT selv drifter og forbinder, følger andre spor: forretningssystemer, integrationsplatforme, webløsninger og udstyr.
Fundtyper, der går igen
En test af API’er og integrationer kan finde en eller flere af disse:
- Nøgler uden udløb · oprettet ved idriftsættelsen for flere år siden og aldrig skiftet.
- For brede rettigheder · en integration, der kun skal læse ordrer, kan også ændre kunder og slette fakturaer.
- Én nøgle til mange formål · samme nøgle bruges af flere integrationer eller flere partnere, så ingen kan se, hvem der gjorde hvad.
- Nøgler, der ligger åbent · i scripts, konfigurationsfiler, delte mapper eller dokumentation. → Adgangskoder i scripts og konfigurationsfiler
- Integrationskonti med menneskelig adgang · kontoen kan også logge ind i brugerfladen, og adgangskoden kendes af flere i IT.
- Personlige konti som integrationskonti · integrationen kører på en medarbejders konto og stopper, når medarbejderen stopper, eller fortsætter med for mange rettigheder.
- Nøgler til partnere, der ikke længere er partnere · samarbejdet er slut, men adgangen er der stadig.
Ingen af dem kræver en avanceret forklaring. Det er fund om styring, og de rettes med styring.
Integrationskonti i Active Directory, som kører tjenester på servere, har deres egne fundtyper og er beskrevet for sig. → Tjenestekonti Grænsen er ikke skarp. Mange integrationer bruger netop en tjenestekonto i kataloget, og så gælder rådene begge steder. Det vigtige er, at hver konto og hver nøgle kan føres tilbage til ét system, én ejer og ét formål.
Hvorfor fundene kan være alvorlige
En integrationskonto kan have adgang til netop de data, der er mest værdifulde: kunder, ordrer, løn eller betalinger. Den har den adgang døgnet rundt, og den bliver måske ikke overvåget, fordi den bruges hele tiden. En nøgle, der kommer i de forkerte hænder, giver derfor adgang til meget, uden at det skiller sig ud i loggen.
Alvoren afhænger af tre ting: hvad nøglen giver adgang til, hvem der kan få fat i den, og om misbrug ville blive opdaget. Testeren vurderer de tre ting for hvert fund. Når I læser rapporten, er det de samme tre spørgsmål, I skal stille for at prioritere. → Fra fund til opgave
Hvad IT forbereder til testen
For at testen kan sige noget om integrationerne, skal testeren vide, hvad der findes:
- Oversigt over integrationer · hvilke systemer der taler sammen, og med hvilken slags login. → Overblik over API’er i driften
- Integrationskonti · en liste over konti, der bruges af systemer, med ejer og formål.
- Partneradgang · hvilke eksterne parter der har nøgler eller konti.
- Aftale om fund · hvem testeren straks kontakter, hvis en nøgle til et kritisk system bliver fundet.
Den sidste aftale skal være på plads, før testen starter. En nøgle, der giver adgang til betalinger eller persondata, skal skiftes nu, ikke når rapporten er skrevet.
Rettelser på begrebsniveau
Rettelserne kan følge samme mønster for fundene:
- Én nøgle pr. integration · så det kan ses, hvem der gør hvad, og så én nøgle kan spærres uden at stoppe resten.
- Mindst mulig adgang · rettigheder, der passer til det, integrationen skal, og intet mere. → Mindst mulig adgang i praksis
- Udløb og udskiftning · nøgler med en levetid og en plan for at skifte dem, helst automatisk, hvor systemet understøtter det.
- Central opbevaring · nøglerne ligger et sted, der er bygget til det, ikke i filer og dokumenter.
- Konti, der kun kan bruges af systemet · uden mulighed for at logge ind i brugerfladen.
- Logning · så det kan ses, hvornår og hvorfra nøglen bruges.
OWASP fremhæver, at ikke alle bør have adgang til alle hemmeligheder, og at adgangen bør styres pr. hemmelighed. For IT-afdelingen betyder det, at den driftsmedarbejder, der vedligeholder en integration, ikke automatisk skal kunne læse nøglerne til alle de andre.
Når en nøgle er fundet
En nøgle, som testeren har kunnet læse, skal betragtes som kendt. OWASP anbefaler, at eksponerede nøgler tilbagekaldes med det samme, skiftes og fjernes fra det sted, hvor de lå, også fra logs og kode. Skift kræver, at I kender alle steder, nøglen bruges. Ellers stopper en integration, og nogen opdager det først, når ordrerne udebliver. Planlæg derfor skiftet sammen med ejeren af integrationen og eventuelt partneren. → Rettelser uden at stoppe driften
Det skal I lade være med
- At give en integration administratorrettigheder, fordi det er nemmest. Det er den rettighed, der gør et fund alvorligt.
- At dele én nøgle mellem partnere. Så kan I ikke lukke for den ene uden at lukke for alle.
- At bruge en medarbejders konto til en integration. Den følger personen og ikke systemet.
- At skifte nøglen uden at kende brugerne. Integrationer stopper uden varsel.
- At lade nøgler til tidligere partnere leve videre. Afslut adgangen sammen med samarbejdet.
Hvad kan og ikke kan konkluderes
Testen viser, hvilke nøgler og integrationskonti testeren fandt eller kunne bruge, og hvad de gav adgang til, inden for de systemer, der var omfattet. Den kan ikke vise, om en fundet nøgle tidligere er brugt af andre, eller om der findes nøgler hos partnere og leverandører, som testen ikke kunne se. Et billede af alle integrationer kræver jeres egen oversigt.
Tjekliste efter fund om nøgler og integrationer
- ☐ Er fundne nøgler tilbagekaldt og skiftet?
- ☐ Har hver integration sin egen nøgle eller konto?
- ☐ Er rettighederne tilpasset det, integrationen skal?
- ☐ Har nøglerne en levetid og en plan for udskiftning?
- ☐ Er adgang for tidligere partnere lukket?
- ☐ Bliver brugen af nøglerne logget?
Kilder
- OWASP Secrets Management Cheat Sheet: livscyklus for hemmeligheder (oprettelse, udskiftning, tilbagekaldelse, udløb), adgang styret pr. hemmelighed, central opbevaring, logning og tilbagekaldelse af eksponerede nøgler.
- OWASP API Security Top 10: OWASP’s oversigt over de største sikkerhedsrisici i API’er.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Overblik over API’er i driften · Filoverførsel og partnerudveksling
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
