Med single sign-on logger medarbejderne ind ét sted og får derfra adgang til mange systemer. Det gør det fælles login til en central del af sikkerheden, og en test af det bør derfor spørge til hele kæden: hvilke systemer der hænger på det, hvordan rettigheder føres videre, hvilke systemer der stadig har deres eget login ved siden af, og hvordan en adgang lukkes igen.
Fordelen ved et fælles login er, at virksomheden kan styre adgangen ét sted. Ulempen er, at fejl samme sted får betydning for alt, der er tilsluttet. Testen skal hjælpe med at se, om fordelen faktisk er opnået.
Én nøgle til mange døre
Det fælles login består typisk af en identitetstjeneste, der kender brugerne, og en række systemer, der stoler på den. Når en medarbejder har logget ind, bekræfter identitetstjenesten over for ERP-systemet, fildelingen og kundeportalens administration, hvem brugeren er.
Det betyder, at spørgsmålet til testen ikke kun handler om selve loginsiden. Det handler også om forholdet mellem identitetstjenesten og de systemer, der stoler på den. Et system, der tager imod bekræftelsen uden at kontrollere den ordentligt, kan give adgang, selv om loginsiden er i orden. Selve login og adgangskoder er behandlet i → Login og adgangskoder.
OWASP’s testguide for webapplikationer behandler identitetsstyring, autentifikation og sessioner som særskilte områder. Det kan bruges som en påmindelse om, at det fælles login berører flere af dem på én gang, ikke som en opskrift på testen.
Kortlæg, hvad der hænger på det fælles login
Begynd med en liste over de systemer, der er tilsluttet. Oversigten er nyttig i sig selv, fordi den ofte viser systemer, som ingen huskede. Den bør også nævne, hvem der ejer hvert system, så fund kan sendes direkte til den rette, når rapporten foreligger.
- Interne systemer · ERP-systemet, intranettet, lønsystemet og fildelingen.
- Tjenester i skyen · kontorpakker, kundesystemer og andre abonnementer, der bruger samme login.
- Administrative adgange · konsoller og portaler, hvor systemerne styres.
- Eksterne brugere · leverandører, konsulenter eller kunder, der også logger ind via det fælles login.
Vælg derefter, hvilke systemer testen skal omfatte. Det er sjældent muligt eller nødvendigt at teste dem alle. Udvælgelsen kan bygge på, hvor følsomme data systemerne rummer, og hvor mange der bruger dem.
Eksterne brugere fortjener særlig opmærksomhed. Hvis leverandører eller kunder logger ind via virksomhedens fælles login, er de en del af den samme kæde, men deres konti oprettes og lukkes ofte efter andre rutiner end medarbejdernes. Bestillingen kan spørge, om eksterne brugere kun når de systemer, de er tiltænkt, og om de forsvinder, når samarbejdet ophører.
Fra gruppe i kataloget til rettighed i systemet
I mange opsætninger bestemmes rettigheder i de enkelte systemer ud fra de grupper, brugeren er medlem af i identitetstjenesten. En medarbejder i økonomigruppen får adgang til økonomifunktionerne i ERP-systemet, og så videre.
Spørgsmålet til testen er, om den kobling virker efter hensigten. Får en bruger kun de rettigheder, gruppen skal give? Bliver rettigheder fjernet i systemet, når brugeren fjernes fra gruppen? Kan en bruger påvirke sine egne gruppemedlemskaber? For at undersøge det skal testeren have testbrugere i de relevante grupper. → Testkonti og testdata
Virksomhedens egen beskrivelse af, hvilke grupper der giver hvilke rettigheder, er det, testens resultat sammenholdes med. Hvis beskrivelsen ikke findes, er den et godt sted at begynde, også før testen bestilles.
Systemer med deres eget login ved siden af
Et fælles login giver kun den forventede beskyttelse, hvis det faktisk er den eneste vej ind. Mange systemer har stadig et lokalt login, der blev brugt før det fælles login kom til, eller som leverandøren beholder til support og nødsituationer.
Sådanne lokale adgange kan omgå de krav, der er sat op centralt, eksempelvis tofaktorlogin. Bestillingen bør derfor spørge, om de tilsluttede systemer kan nås uden om det fælles login, og om undtagelserne er kendte og begrundede. Hvor tofaktor gælder, og hvor den ikke gør, er behandlet i → Tofaktorlogin i testen.
Når en bruger stopper eller logger ud
Et af de stærkeste argumenter for et fælles login er, at en fratrådt medarbejder kan lukkes ude ét sted. Testen kan undersøge, om det holder. Ophører adgangen til alle tilsluttede systemer, når brugeren spærres? Eller kan en igangværende session fortsætte i et system, indtil den udløber af sig selv?
Det samme gælder, når en bruger logger ud. Bliver brugeren logget ud af alle systemer eller kun af det ene? Svaret har betydning på delte computere og for medarbejdere, der arbejder fra flere enheder. Rapporten bør oplyse, hvilke systemer der blev kontrolleret, så det er tydeligt, hvor resultatet gælder. En aftalt test kan spærre en testbruger undervejs og konstatere, hvad der sker i de tilsluttede systemer.
Systemerne er forbundet med det fælles login på samme måde som med andre integrationer, og forbindelserne kan have deres egne konti og rettigheder. → Integrationer mellem systemer
Hvem må give lov?
Identitetstjenesten ligger ofte hos en udbyder i skyen, og mange af de tilsluttede systemer drives af andre. Testen kræver derfor tilladelse fra flere parter, og udbydernes vilkår for sikkerhedstest skal læses, før noget planlægges.
Hvis identitetstjenesten er en del af en større kontorpakke, hører den tekniske gennemgang af den til et særskilt emne, men de spørgsmål, virksomheden vil have svar på, kan nævnes kort. → Microsoft 365 og testen · → Er en penetrationstest lovlig?
Det skal I lade være med
- At teste loginsiden alene · kæden omfatter også de systemer, der stoler på det fælles login.
- At bestille uden en oversigt · kortlæg de tilsluttede systemer, før scope skrives.
- At overse lokale login · de kan omgå de centrale krav.
- At teste med en bruger uden de rigtige grupper · rettighederne følger grupperne.
- At glemme lukningen · spærring og log ud skal virke i alle tilsluttede systemer.
- At springe udbydernes vilkår over · identitetstjenesten og systemerne kan have hver sin ejer.
Hvad kan og ikke kan konkluderes
En test kan vise, hvordan det fælles login og de udvalgte systemer opførte sig med de testbrugere, der indgik. Den kan pege på undtagelser, rettigheder og lukninger, der ikke virker som forventet.
Den kan ikke vise, hvordan systemer uden for udvælgelsen opfører sig, eller hvordan opsætningen ser ud efter næste ændring. Tilføjes et nyt system, skal koblingen vurderes for sig.
Tjekliste til det fælles login
- ☐ Findes der en oversigt over tilsluttede systemer?
- ☐ Er det valgt, hvilke systemer testen omfatter?
- ☐ Er det beskrevet, hvilke grupper der giver hvilke rettigheder?
- ☐ Er lokale login og andre undtagelser kortlagt?
- ☐ Er testbrugere oprettet i de relevante grupper?
- ☐ Er spærring og log ud med som spørgsmål?
- ☐ Har udbydere og systemejere givet tilladelse?
Kilder
- OWASP Web Security Testing Guide: identitetsstyring, autentifikation og sessioner som testområder.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: Integrationer mellem systemer · Testkonti og testdata
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
