Hver integration mellem to systemer har en identitet: en konto, en nøgle, en hemmelighed eller et certifikat. Kontrollen er at finde dem alle, se, hvad hver enkelt har lov til, og kontrollere, at hemmelighederne har en levetid og ligger et sikkert sted.
Det er sjældent integrationerne selv, der giver fund. Det er de identiteter, der blev oprettet, da integrationen blev sat op, og aldrig blev set på igen.
Målestokkene
I CISA’s SCuBA-baseline for Entra ID står tre punkter om programmers legitimation. Programmers passwords, som Microsoft kalder hemmeligheder, bør højst gælde 180 dage (MS.AAD.5.6v1). Certifikater bør højst gælde 365 dage (MS.AAD.5.7v1). Og muligheden for at tilføje passwords til programmer bør blokeres (MS.AAD.5.5v1). Alle tre er “bør” og ikke “skal” i baselinen. SCuBA binder amerikanske civile myndigheder på føderalt niveau. For alle andre er den til oplysning.
Microsoft skriver, at politikker for betinget adgang, der er rettet mod brugere, ikke blokerer kald fra tjenesteidentiteter. Der findes særskilte politikker for de identiteter, programmer bruger. En opsætning, der ser stram ud for brugerne, siger altså intet om integrationerne.
To punkter i bilaget til forordning (EU) 2024/2690 handler om identiteter og kanaler. Punkt 11.5.2, litra a, kræver unikke identiteter for net- og informationssystemer og deres brugere. Punkt 6.7.2, litra i, kræver, at kommunikation mellem særskilte systemer sker gennem pålidelige kanaler med sikker identifikation af endepunkterne. Bilaget gælder kun de digitale tjenesteudbydere, forordningen nævner. Bruger andre det som målestok, er det vores tolkning.
CISA og NSA anbefaler i AA23-278A ikke at gemme loginoplysninger i Windows’ registreringsdatabase, at forbyde passwords i filer og at gennemgå filer og systemer for loginoplysninger i klartekst. Listen over ti fejlopsætninger, som anbefalingerne hører til, er ikke prioriteret.
Opgørelsen
Opgørelsen er praksis. Ingen af de læste kilder beskriver en metode. Det er almindeligt at bygge den fra systemerne selv frem for fra dokumentation, fordi dokumentationen sjældent er komplet.
Kilderne kan være:
- programregistreringer og tjenesteidentiteter i lejeren,
- servicekonti i kataloget,
- API-nøgler i forretningssystemernes egen administration,
- planlagte opgaver og scripts på serverne, der henter eller sender data,
- firewallregler mellem systemer, der kun bruges af en integration.
Hver integration skrives ind i en liste med fire felter: de to systemer, den identitet, der bruges, hvad identiteten har lov til, og hvem der ejer integrationen. Listen kan få flere felter, fx (udløbsdato for nøglen) og (hvor hemmeligheden ligger).
Hvad hver integration må
Når listen er lavet, er spørgsmålet, om rettighederne passer til opgaven. En integration, der kun skal læse ordrer, bør ikke kunne slette kunder. En integration, der kun skal sende en fil om natten, bør ikke have adgang til hele postsystemet.
Bilagets krav om unikke identiteter betyder i praksis, at to integrationer ikke bør dele samme konto. Deler de, kan ingen sige, hvilken af dem der gjorde hvad, og den ene kan ikke lukkes uden at stoppe den anden.
I lejeren kan programmer med brede rettigheder opgøres for sig. Det kontrolpunkt står i app-registreringer og samtykker i Entra ID.
Hemmelighedernes levetid og opbevaring
For hver hemmelighed er spørgsmålene, hvornår den udløber, hvor den ligger, og hvem der kan læse den. SCuBA’s grænser på 180 og 365 dage er en målestok for programmer i Entra ID. For andre systemer har vi ingen læst grænse.
CISA’s anbefalinger giver kontrolpunktet for opbevaring: Hemmeligheder må ikke ligge i klartekst i filer, scripts eller registreringsdatabasen. En gennemgang kan søge i scripts og opsætningsfiler på de servere, der kører integrationer, og notere de steder, hvor der står en hemmelighed.
Når en medarbejder fratræder
Mange integrationer er sat op med en personlig konto, fordi det var hurtigst. Når personen fratræder, og kontoen lukkes, holder integrationen op med at virke. Eller kontoen holdes åben, fordi integrationen bruger den. Begge dele er fund. En gennemgang kan sammenligne listen over identiteter i integrationer med listen over fratrådte og se, om nogen af dem bruges af et system.
Åbne grænseflader
En grænseflade, der kan kaldes uden at logge på, er det sidste kontrolpunkt. Vi har ikke læst en primærkilde om dem, og afsnittet er praksis. Kontrollen er at gå integrationslisten igennem og spørge, om hver grænseflade kræver autentificering, og om den kan nås fra internettet. En grænseflade, der er åben for alle, fordi den kun var tænkt til brug internt, er et typisk fund.
Udveksling af data mellem myndigheder har ofte sine egne regler, og dem finder I under revision af IT i den offentlige sektor.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at nogen samler listen fra flere systemer og finder en ejer til hver integration. Det tager tid første gang. Derefter kan listen holdes ved lige, når integrationer oprettes og lukkes.
Uden listen findes der identiteter med adgang til data, som ingen ejer. Deres hemmeligheder udløber aldrig, og de bliver ikke ramt af de regler, der beskytter brugerne.
Det skal I lade være med
- At lade flere integrationer dele én konto · giv hver sin identitet.
- At gemme hemmeligheder i scripts og opsætningsfiler · brug et lager til hemmeligheder.
- At regne betinget adgang for brugere som beskyttelse af integrationer · Microsoft skriver, at den ikke gælder tjenesteidentiteter.
Det skal gennemgangen kunne vise
- ☐ En liste over integrationer med systemer, identitet, rettigheder og ejer.
- ☐ Udløbsdato for hver hemmelighed og hvert certifikat.
- ☐ Hvor hemmelighederne ligger, og fund af hemmeligheder i klartekst.
- ☐ Grænseflader, der kan kaldes uden autentificering.
Kilder
- CISA, M365 Secure Configuration Baseline for Microsoft Entra ID (SCuBA), MS.AAD.5.5v1 til 5.7v1, læst 13. november 2026.
- Microsoft Learn, Plan a Conditional Access deployment, læst 13. november 2026.
- Gennemførelsesforordning (EU) 2024/2690, bilaget, punkt 6.7.2 og 11.5.2, læst 13. november 2026.
- CISA og NSA, AA23-278A, Top Ten Cybersecurity Misconfigurations (5. oktober 2023), tabel 9, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Træk listen over programregistreringer og servicekonti, og skriv ved hver, hvilken integration den hører til.
Læs også: Nøgler og hemmeligheder i skyen · Faste forbindelser til kunder, leverandører og søsterselskaber
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
