Brugere, adgang og drift

Adgangsreview i appen: find glemte konti og for brede rettigheder

En app kan have korrekt login og stadig give for mange mennesker og integrationer adgang. Med et adgangsreview kontrollerer I, hvem og hvad der kan nå appens data og drift, om adgangen stadig har et legitimt formål, og om den er bredere eller mere permanent end nødvendigt.

Udgivet 19. oktober 2026 · Ca. 11 minutters læsetid

Det korte svar

Tag et samlet øjebliksbillede af brugere, grupper, administratorer, gæster, servicekonti, integrationer og personlige tokens. Giv hver adgang en navngiven ejer, et konkret formål, et nødvendigt omfang og en beslutning: behold, begræns, gør tidsbegrænset eller fjern. Udfør ændringer kontrolleret, test både afslag og fortsat drift, og gem kun det bevis, I skal bruge til næste gennemgang.

Et adgangsreview er ikke kun en liste over aktive medarbejdere. En gammel konsulent, en gruppe med arvede rettigheder eller en servicekonto uden ejer kan have større rækkevidde end en almindelig bruger.

Afgræns reviewet efter reel risiko

Begynd dér, hvor en forkert adgang kan gøre størst skade. Det er typisk produktion, persondata, betaling, deployment, database, backup, domæne, identitetsplatform og overvågning. Reviewet må gerne være lille, hvis grænsen er tydelig. Et afgrænset, gennemført review er mere værd end et regneark over hele virksomheden, som ingen træffer beslutninger ud fra.

Mennesker: Medarbejdere, administratorer, gæster, konsulenter, leverandører og kundebrugere.
Grupper og arv: Teamgrupper, tenantroller, projektroller og medlemskaber, der giver indirekte adgang.
Maskinidentiteter: Servicekonti, CI/CD-identiteter, jobs, bots og serverfunktioner med egne rettigheder.
Delegeret adgang: OAuth-apps, API-tokens, deploynøgler, personlige adgangstokens og tredjepartsintegrationer.

Lav én beslutningsklar adgangsoversigt

Eksportér eller registrér adgangen på et fast tidspunkt, så listen ikke ændrer sig midt i reviewet. Saml kun de oplysninger, der gør ejeren i stand til at beslutte. Gem ikke passwords, tokens eller private nøgler i oversigten.

Identitet: Hvem eller hvad har adgang, og er identiteten personlig, delt, ekstern eller maskinel?
Adgangsvej: Kommer rettigheden direkte, via en gruppe, en overordnet ressource, en servicekonto eller en integration?
Omfang: Hvilket miljø, hvilke data og hvilke handlinger kan identiteten nå?
Ejer og formål: Hvem kan forklare det aktuelle behov, og hvilken arbejdsopgave eller systemfunktion kræver adgangen?
Signal om brug: Seneste login, API-aktivitet eller administrativ handling, hvis platformen kan vise det.
Beslutning: Behold, begræns, gør tidsbegrænset, erstat eller fjern – med ansvarlig og dato.

En inaktiv bruger kan stadig være nødvendig som nødadgang, og et sjældent job kan være forretningskritisk. Omvendt beviser hyppig brug ikke, at en bred administratorrolle er nødvendig. Aktivitetsdata er beslutningsstøtte, ikke selve beslutningen.

Lad den rigtige ejer bekræfte behovet

Den tekniske administrator kan vise, hvordan adgang er givet, men bør ikke alene afgøre, hvem der fortsat har et forretningsbehov. Lad den ansvarlige for appen, dataene eller arbejdsprocessen bekræfte behovet. Selvbekræftelse kan være et input, men er et svagt bevis ved administratoradgang og andre højrisikorettigheder.

1. Bekræft identiteten: Find den virkelige person eller tekniske funktion bag kontoen.
2. Bekræft formålet: Beskriv den konkrete opgave, ikke blot “skal stadig bruge systemet”.
3. Sammenlign omfanget: Kræver opgaven læseadgang, ændringer, brugeradministration eller fuld platformkontrol?
4. Undersøg alternativer: Kan en gruppe, smallere rolle eller tidsbegrænset elevation erstatte permanent særadgang?
5. Eskalér uklarhed: Ingen svarfrist bør ikke automatisk betyde fortsat højrisikoadgang.

Gennemgå servicekonti som rigtige identiteter

NCSC anbefaler, at serviceidentiteter jævnligt kontrolleres for både fortsat behov og mindst mulige rettigheder. En maskinkonto forlader ikke virksomheden, men den kan blive glemt, når en funktion, leverandør eller integration udfases. Den kan samtidig have adgang døgnet rundt uden en bruger, der opdager en fejl.

Forbind hver servicekonto med én systemfunktion, et miljø og en navngiven menneskelig ejer.
Find ud af, om den bruges til at køre kode, læse data, ændre data eller udstede andre credentials.
Kontrollér direkte roller, arvede roller og hvem der kan bruge eller efterligne kontoen.
Erstat delte eller standardkonti med afgrænsede identiteter, hvor platformen understøtter det.
Fjern ikke en ukendt servicekonto direkte i produktion. Stop eller begræns den kontrolleret, overvåg konsekvensen og hav en dokumenteret vej tilbage.

Brug platformens fund som spor – ikke som autopilot

Microsoft Entra kan gennemføre tilbagevendende reviews af blandt andet grupper, applikationer og privilegerede roller. Google Cloud og AWS kan vise signaler om overflødige eller ubrugte rettigheder. De funktioner kan spare manuelt arbejde, men dækning, licens og datagrundlag varierer.

Anvend ikke anbefalinger blindt. Google Cloud gør opmærksom på, at IAM-anbefalinger ikke medregner alle andre adgangskontroller. AWS beskriver tilsvarende begrænsninger i sine oplysninger om seneste adgang. Kontrollér derfor kritiske brugerrejser, sjældne jobs og indirekte adgang, før en rettighed fjernes.

Udfør ændringer som små driftsændringer

Et review er først færdigt, når beslutningerne er gennemført og efterprøvet. Prioritér ukendte administratorer, tidligere eksterne brugere, delte konti, offentlige adgange og maskinidentiteter uden ejer. Tag de risikable ændringer én ad gangen, så en afhængighed kan findes uden at blande flere fejl sammen.

Fjern eller nedgrader den konkrete rolle frem for at slette hele identiteten, hvis historik eller anden legitim adgang skal bevares.
Tilbagekald relevante sessioner og credentials, når selve adgangen ikke længere er legitim.
Test at den fjernede adgang giver afslag via både brugerflade, API og direkte ressourcevej.
Test samtidig, at appens vigtigste flow, jobs, deployment, backup og alarmer fortsat virker.
Registrér hvem der godkendte og udførte ændringen, resultatet af kontrollen og en eventuel tidsbegrænset undtagelse.

Vælg en rytme, som følger risiko og ændringer

SikkerDigital anbefaler i sin ISO 27001-vejledning opfølgning på brugerrettigheder mindst to gange årligt. Det er et nyttigt gulv for mange miljøer, men ikke en universel facitliste. Privilegeret adgang, eksterne brugere og kritiske produktionskonti kan kræve hyppigere review. Kør også et afgrænset review ved rolleskift, leverandørskifte, ny integration, sikkerhedshændelse eller større ændring i appens data og funktioner.

Gem scope, øjebliksbillede, beslutninger, undtagelser og gennemførte ændringer. Gem ikke flere personoplysninger end nødvendigt, og sæt en slettefrist på selve reviewmaterialet.

Typiske fejl i et adgangsreview

Kun appens brugerliste gennemgås: Cloudroller, databaser, GitHub, hosting, servicekonti og OAuth-apps bliver overset.
Direkte adgang er hele billedet: Grupper, overordnede ressourcer og delegerede identiteter giver stadig adgang.
Seneste login bliver facit: Sjældne nødopgaver fjernes, mens aktiv, men unødigt bred adgang godkendes.
Alle bekræfter sig selv: Ingen forretnings- eller dataejer vurderer, om adgangens omfang faktisk er nødvendigt.
Servicekonti har ingen ejer: Ingen tør fjerne dem, og rettighederne vokser, hver gang appen får en funktion.
Alt ryddes op på én gang: Kritiske jobs eller deployment stopper, og årsagen bliver svær at isolere.
Undtagelser varer evigt: Midlertidig adminadgang får ingen udløbsdato eller ny vurdering.
Reviewet slutter i et regneark: Beslutninger mangler ejer, frist, efterkontrol og dokumenteret resultat.

Tjekliste til et gennemført adgangsreview

☐ Scope og prioritet tager udgangspunkt i produktion, følsomme data og kritiske driftsfunktioner.
☐ Brugere, administratorer, gæster, grupper, servicekonti, integrationer og tokens indgår.
☐ Direkte, arvet, gruppebaseret og delegeret adgang er synlig.
☐ Hver adgang har en navngiven ejer og et aktuelt, konkret formål.
☐ Rettighedens omfang er sammenholdt med den faktiske arbejdsopgave eller systemfunktion.
☐ Aktivitetsdata bruges som signal og er kontrolleret for platformens begrænsninger.
☐ Højrisikoadgang vurderes af en relevant ressource- eller dataejer frem for alene af brugeren selv.
☐ Uklare, overflødige og for brede adgange har beslutning, ansvarlig og frist.
☐ Kritiske ændringer udføres afgrænset med mulighed for at genskabe nødvendig drift.
☐ Afslag og fortsat drift er testet via relevante indgange, jobs og integrationer.
☐ Undtagelser er begrundede, tidsbegrænsede og har en ny reviewdato.
☐ Reviewets resultat er dokumenteret uden passwords, tokens eller unødige persondata.
☐ Næste review og hændelser, der udløser et tidligere review, er aftalt.

Relaterede guides

Officielle kilder

Principperne og platformseksemplerne er kontrolleret mod aktuelle primærkilder. Brug dokumentationen for den identitets- og cloudplatform, jeres app faktisk anvender, før I ændrer adgang i produktion.