Identitets- og adgangsstyring: samlet IAM-model i virksomheden

Identitets- og adgangsstyring som ledelsesansvar

IAM er den samlede måde, en virksomhed forbinder en identitet med de rettigheder, identiteten må bruge. Identiteten kan være en medarbejder, en ekstern konsulent, en leverandørs systembruger eller en maskine, der kalder et API. Modellen dækker hele kæden: Hvem er du? Hvordan beviser du det? Hvad må du bruge? Og hvordan dokumenterer vi bagefter, at adgangen var berettiget?

Med et IAM-system kan organisationen ved hvert adgangsforsøg bekræfte en persons identitet og de nødvendige tilladelser til den anmodede ressource. Målet er, at de rigtige personer kan udføre deres arbejde, og at uvedkommende nægtes adgang. Det gælder også, når medarbejdere fjernarbejder eller arbejder fra egne maskiner.

Fordi IAM binder mennesker, data, applikationer og fysiske lokaliteter sammen i én styringsmodel, kan området ikke reduceres til IT-drift. Adgange opstår på tværs af forretningsenheder, systemer og leverandører. Fejl i tildelingen rammer langt ud over den enkelte afdeling. Derfor kræver identitets- og adgangsstyring ledelsesmæssig prioritering, ejerskab og opfølgning.

Hybridarbejde har flyttet adgangen ud af kontoret. Medarbejderne skal have sikker adgang til apps, filer og data, uanset om de møder på et kontor eller fjernarbejder. Det gælder også underleverandører, leverandører og forretningspartnere, der arbejder fra egne maskiner. Kravet er, at hver person har det rette adgangsniveau på det rette tidspunkt på den rette maskine.

For IAM er det vigtigt at skelne mellem adgangskontroller og de øvrige forpligtelser til cybersikkerhedsrisikostyring. Adgangskontrol er ét af flere områder, og modellen bør derfor ses i sammenhæng med den øvrige risikostyring.

Ledelsen bør fastlægge en ejer for hver del af modellen: forretningsbehov, godkendelse, teknisk håndhævelse og kontrol. Når ansvaret er fordelt, kan afvigelser følges op uden at forveksle systemdrift med beslutningen om, hvem der skal have adgang.

NIS2-loven trådte i kraft i Danmark den 1. juli 2025 og stiller krav til medlemmer af ledelsesorganer i omfattede enheder. Ledelsen skal tage ejerskab for cybersikkerheden. Styrelsen for Samfundssikkerhed har udgivet vejledninger om bl.a. ledelsens rolle og opgaver, foranstaltninger og hændelsesunderretning.

IAM-modellens byggesten: identitet og adgangsstyring

En identitet er den entitet, der skal have adgang – en person, en rolle, en tjeneste eller en enhed. Brugergodkendelse verificerer, hvem brugeren er, mens adgangsgodkendelse afgør, hvad brugeren må foretage sig. RBAC (role-based access control) tildeler adgang ud fra roller, mens ABAC (attribute-based access control) baserer beslutningen på attributter for brugeren, ressourcen eller miljøet.

Gør adgangsbeslutninger til en del af modellens styring. Angiv, hvem der ejer en rolle eller et system, hvem der må godkende en adgang, og hvordan en undtagelse begrundes og dokumenteres. På den måde bliver ansvar og beslutningsvej tydelige, før teknologien håndhæver rettighederne.

Et tredje begrebspar er fortrolighed, integritet og tilgængelighed. Formålet med niveauer og adgangsbegrænsninger er at minimere risikoen for uautoriseret adgang og samtidig styre fortroligheden, integriteten og tilgængeligheden af informationen. Den samme trekant går igen, når I vurderer, om en kontrol er den rigtige for et givet aktiv.

I praksis kan byggestenene være et identitetsregister over brugere og tjenester, et rolle- og rettighedskatalog samt en rettighedsmatrix mellem roller og systemer. Modellen bør også beskrive oprettelse, ændringer ved skift af opgave og fjernelse af adgang ved fratrædelse. Automatiseret on- og offboarding kan indgå i identitetsstyringen.

I mange organisationer er Active Directory stadig det autoritative brugerkatalog, hvor brugere, adgangskoder og gruppemedlemskaber ligger. Moderne applikationer – SaaS-platforme og kundeportaler – forventer typisk føderationsprotokoller som OIDC (OpenID Connect) og SAML 2.0 samt tokens og claims.

Teknisk bør I skelne mellem kataloget og identitetslaget. Applikationer bør ikke forbindes direkte til Active Directory eller LDAP, men til et identitetslag, der håndterer føderationsprotokol, tokens og claims. Modellen bør beskrive, hvordan kataloget forbindes til applikationerne, og hvor MFA og step-up autentifikation sættes ind.

Vælg kontroller efter risikoen ved den konkrete adgang. MFA og step-up-autentifikation kan bruges foran følsomme systemer, mens roller og claims formidler de rettigheder, applikationen skal håndhæve. Beskriv også, hvem der ejer kontrollen, og hvordan man opdager, hvis den ikke virker efter hensigten.

FoxIDs er et eksempel på et identitetslag foran Active Directory. Active Directory forbliver autoritativ for brugere, adgangskoder og gruppemedlemskaber, mens FoxIDs håndterer OpenID Connect, SAML 2.0, tokens og claims til applikationerne.

Til identity governance og administration findes Microsoft Entra ID, Microsoft Entra ID Governance, Okta, SailPoint og Omada. SailPoint er en fuld IGA-platform; Okta er en identitetsudbyder med IGA-funktioner gennem opkøb; Entra ID Governance er Microsofts IGA-tilbud.

Omada kan automatisere provisioning og de-provisioning af Microsoft Entra ID-brugere, grupper og medlemskaber. eADM fra Identum henter data fra HRM og opretter og opdaterer brugerkonti i Microsoft Entra ID og andre målsystemer.

Sammenligning af IAM-platforme til identity governance

Start med risikovurdering og forretningsbehov

En IAM-model bør begynde med et kort over, hvad der overhovedet skal beskyttes. Første skridt er at definere formålet med adgangen til bestemte data eller systemer. En risikovurdering identificerer potentielle trusler, sårbarheder og konsekvenser ved en hændelse. Den er grundlaget for, hvilke niveauer og beskyttelsestiltag der er nødvendige, og hvordan værdierne beskyttes bedst.

I praksis gennemgår I data, systemer og fysiske områder én for én og spørger: Hvad ville det betyde, hvis oplysningerne blev læst af uvedkommende, ændret uden at nogen opdagede det, eller gjort utilgængelige i en periode? Konsekvenserne – for kunder, medarbejdere, drift, økonomi og omdømme – er med til at bestemme, hvor stramme kravene til brugergodkendelse og adgangsstyring skal være.

Før rettigheder tildeles, bør I vide, hvilke data virksomheden behandler, og hvor data lagres og bevæger sig hen. Det overblik er både et risikobillede og et dokumentationsgrundlag, og det gør det lettere at svare på, hvem der reelt har behov for adgang.

Forretningsbehovet skal kobles direkte på. Hvem har reelt behov for at se eller ændre oplysningerne for at løse deres opgaver? Hvilke opgaver kræver skriveadgang, og hvilke kan klares med læseadgang? Er der perioder – for eksempel et projekt eller en midlertidig opgave – hvor adgangen kun skal gælde i en afgrænset periode? Svarene bliver input til senere konkrete rettigheder.

Risikovurderingen bør også omfatte de identiteter, der ikke er mennesker: tjenestekonti, integrationsbrugere og systemer, der taler sammen. De har ofte vide rettigheder og skiftes sjældent. Derfor er de afgørende at få med, hvis modellen skal være reel og ikke kun et papirprodukt.

NIS2-loven trådte i kraft 1. juli 2025 og stiller krav til risikostyring og sikkerhedsforanstaltninger for omfattede virksomheder. Enheder kan være væsentlige (særlig kritiske) eller vigtige (kritiske). IAM-modellen bør derfor kobles til den samlede cybersikkerhedsrisikostyring.

Klassificér information og aktiver før rettigheder tildeles

Klassificering oversætter risikovurderingen til kategorier, som organisationen kan bruge til at styre adgang og beskyttelse. Afgør først, om I har brug for en intern klassifikation af information og aktiver, eller om I håndterer officielt klassificerede oplysninger. Det gør det tydeligt, hvilke regler og kontroller der hører til den enkelte kategori.

I praksis kan niveauerne for sikkerhedsgodkendelse være afgrænset som fortrolig niveau (konfidentiel), hemmeligt niveau (hemmelig) og yderst hemmeligt niveau. Betegnelserne kan variere fra land til land og fra sektor til sektor (Retsinformation, sikkerhedscirkulæret).

Det afgørende er ikke antallet af niveauer, men at hvert niveau er koblet til et krav. For hvert niveau bør der være svar på: Hvem må se oplysningerne? Kræves der stærkere brugergodkendelse? Må oplysningerne ligge i cloud, på mobile enheder eller uden for EU? Hvor længe må de opbevares, og hvordan slettes eller arkiveres de? Uden den kobling bliver klassificeringen en etiket uden effekt.

Lav en oversigt, der forbinder hver kategori med konkrete beslutninger: hvem må få adgang, hvem godkender den, og hvilke beskyttelsestiltag gælder. Medtag også krav til brugergodkendelse, opbevaring og håndtering, hvor det er relevant. Oversigten skal kunne bruges af både systemejere og dem, der kontrollerer adgangen.

Klassificeringen bør dække både information og aktiver. Et dokument, en database og et fysisk serverrum kan have forskellige niveauer, men de hænger sammen: Adgangen til et system giver ofte adgang til de data, der ligger i det. Derfor bør klassificering af data og af systemer og lokaliteter ses i sammenhæng, inden rettigheder tildeles.

Fra adgangsbehov til konkrete adgangsprincipper

Grundprincipperne bag adgangsstyring bygger ofte på en sammenkædning af behov for adgang, tillid til den enkelte og tilgængelige sikkerhedsforanstaltninger. Adgangsbehovet er udgangspunktet: En bruger skal kun have de rettigheder, der er nødvendige for at løse opgaven. Tilliden til den enkelte er den anden side, fordi mange adgangsbeslutninger træffes af en leder eller systemejer, der kender opgaven. Sikkerhedsforanstaltningerne er den tredje, fordi tillid alene ikke er en kontrol.

En rettighed skal kunne begrundes: Hvem har bedt om den, hvilken opgave understøtter den, og hvilken rolle hører den til? Indfør adgangsrecertificering som en tilbagevendende kontrol, og fastlæg en passende kadence ud fra risiko og ændringer i organisationen. Adgangsrecertificering kan indgå i en IAM-driftsmodel.

Hold standardadgang adskilt fra undtagelser. Hvis en medarbejder har brug for en rettighed ud over sin rolle, bør behovet, godkendelsen og den forventede varighed fremgå. Det gør det lettere at finde adgang, der kan fjernes, når opgaven eller projektet er afsluttet.

Modellen består af organisatoriske principper, tekniske kontroller og processer for medarbejdere. Principperne fastlægger, hvem der godkender adgange, og kontrollerne håndhæver dem gennem login, rettighedstildeling og logning. For særligt følsomme konti kan privileged access management (PAM) lægge ekstra kontrol på administratoradgange og kritiske systemroller.

Teknisk udmøntes principperne ofte som single sign-on. Brugeren logger ind én gang og får adgang til flere applikationer via OIDC eller SAML 2.0; applikationen modtager tokens og claims med roller og gruppemedlemskaber. MFA og step-up autentifikation kan lægges foran følsomme systemer, så adgangen kontrolleres uden delte adgangskoder, og rettigheden bindes til en identitet, der kan verificeres.

Beskriv også håndteringen af adgangskoder, nøgler, certifikater og tokens. Angiv, hvor de opbevares, hvem der må bruge dem, og hvordan adgangen ændres, når en medarbejder eller leverandør skifter opgave. Så bliver håndteringen af hemmeligheder en del af modellen frem for en løsrevet teknisk praksis.

IGA-platforme som SailPoint, Okta og Microsoft Entra ID Governance kan understøtte adgangsrecertificering og governance. SailPoint er en fuld IGA-platform, men kræver typisk et løbende team eller specialister og kan være dyr at drive.

Dokumentation, GDPR og compliance i IAM-arbejdet

IAM og databeskyttelse hænger tæt sammen, fordi begge områder handler om, hvem der kan tilgå oplysninger om personer, og hvorfor. GDPR står for General Data Protection Regulation og kaldes på dansk også databeskyttelsesforordningen. Datatilsynet er den danske tilsynsmyndighed og vejleder virksomheder om reglerne.

Reglerne gælder, når private virksomheder behandler personoplysninger. Behandling omfatter både at indsamle, registrere, videregive og slette oplysninger om for eksempel kunder eller ansatte.

Virksomheder bør kunne dokumentere, hvordan de behandler personoplysninger, og hvem der har adgang til systemerne, hvor oplysningerne findes. Virksomheder skal kunne dokumentere, at de behandler persondata i overensstemmelse med reglerne, og i værste fald kan manglende dokumentation føre til bøder (danskindustri.dk). En IAM-model kan understøtte dokumentationen ved at vise adgange og godkendelser.

Gør dokumentationen operationel ved at forbinde personoplysninger med de systemer og roller, der giver adgang til dem. Det skal være muligt at finde oplysninger om, hvor data lagres, hvem der kan tilgå dem, og hvorfor adgangen er givet. Dermed kan rettighedsoversigten bruges i arbejdet med databeskyttelse og ikke kun som teknisk bilag.

Start med at holde en oversigt over de personoplysninger, virksomheden behandler, og de systemer, hvor de findes. Knyt derefter relevante roller til oplysningerne, og gør det synligt, hvem der ejer adgangen. Når data eller arbejdsgange ændres, bør oversigten og adgangene gennemgås sammen.

Dokumentation får praktisk værdi, når den viser sammenhængen mellem formål, data og adgang. En leder eller systemejer skal kunne forklare, hvorfor en rolle giver adgang til bestemte oplysninger, og hvordan adgangen kontrolleres. Det skaber et tydeligere grundlag for intern opfølgning og dialog med samarbejdspartnere.

Registrér beslutningerne i IAM-processen samme sted, så godkendelser, roller og begrundelser kan findes igen. Beskriv også, hvem der vedligeholder oplysningerne, og hvordan rettelser kommunikeres til de systemer, der håndhæver adgangen. Det mindsker risikoen for, at dokumentationen og den faktiske adgang udvikler sig hver sin vej.

En brugbar adgangslog bør gøre det muligt at følge rettigheden fra beslutning til kontrol. Registrér, hvilken rolle eller gruppe der giver adgangen, hvem der har godkendt den, og hvad der sker, når behovet ophører. Knyt logningen til en tydelig ejer, så afvigelser kan undersøges og håndteres.

En praktisk tilgang er at knytte hver adgang til et formål og en behandlingsaktivitet. Når en medarbejder får en rolle, bør det fremgå, hvilke personoplysninger rollen giver adgang til, og hvorfor adgangen er nødvendig. Så bliver loggen og rettighedsoversigten et aktivt dokumentationsværktøj i stedet for et bilag, der først findes frem, når nogen spørger.

Databeskyttelsesforordningen fik virkning den 25. maj 2018. DI har reduceret forordningens 261 sider og 99 artikler til operationelle værktøjer. Medlemmer kan hente skabeloner og vejledning om databehandleraftaler, procesafdækning og dokumentation af databehandlingsaktiviteter.

Sikkerhedsgodkendelse og klassificerede oplysninger

Sikkerhedsgodkendelse gælder adgang til klassificeret information og er ikke det samme som virksomhedens almindelige rolle- og rettighedsstyring. Sikkerhedsgodkendelsesniveauer bliver centrale, når virksomheder og offentlige organisationer håndterer kritiske data, fortrolige oplysninger eller følsomme projekter (Retsinformation, sikkerhedscirkulæret). Hold derfor klassificering, godkendelse og de tekniske adgangsrettigheder tydeligt forbundet i modellen.

Når klassificerede oplysninger indgår, skal modellen vise, hvilke oplysninger og systemer der er omfattet, hvem der har ansvar for klassificeringen, og hvordan adgangen håndhæves. Beskriv også, hvordan sikkerhedsgodkendelsen kontrolleres, før adgang gives. Så kan organisationen skelne mellem krav til personen og de tekniske rettigheder i systemet.

Fastlæg, hvem der vurderer, om en person må arbejde med de pågældende oplysninger, og hvem der godkender de tilhørende systemrettigheder. Beskriv, hvordan brugergodkendelsen kontrolleres, og hvordan adgang ændres, hvis personen skifter opgave eller forlader organisationen. Hold beslutningen om godkendelse adskilt fra den tekniske tildeling, men sørg for, at de hænger sammen.

Knyt klassificeringen til de beskyttelsestiltag, der gælder for oplysningerne. Kataloget bør samtidig vise, hvilke gruppemedlemskaber der giver adgang, og hvem der har godkendt dem. Det gør forbindelsen mellem klassifikation, godkendelse og faktisk adgang synlig.

Audit binder det hele sammen. Uden løbende kontrol af, hvem der er tildelt hvilke adgange, og uden spor af, hvad der er blevet tilgået, kan organisationen ikke svare på, om niveauet blev overholdt. Audit bør derfor designes sammen med godkendelsesprocessen og ikke bagefter som et selvstændigt projekt.

Kontrolliste for sikkerhedsgodkendelse og klassificerede oplysninger

Sådan bygger du en samlet IAM-model i virksomheden

Implementeringen bør følge en struktureret tilgang, der kombinerer politikker, processer og teknologi. Første trin er at fastlægge behov og gennemføre en risikovurdering: Formålet med adgangen til bestemte data eller systemer defineres, og vurderingen identificerer potentielle trusler, sårbarheder og konsekvenser ved en hændelse. Den danner grundlag for, hvilke niveauer der er nødvendige, og hvordan værdierne bedst beskyttes.

Andet trin er klassificering af information og aktiver. Her sætter I navn på kategorierne, beslutter hvordan de bruges i praksis, og gennemgår datasæt, applikationer og fysiske steder systematisk. Resultatet bør være en oversigt, hvor hvert aktiv har et niveau og dermed et sæt krav til brugergodkendelse, adgangsstyring og beskyttelse.

Tredje trin er at tildele adgange ud fra roller og behov. I stedet for at give rettigheder enkeltvis til hver person, beskriver I de roller, virksomheden faktisk har, og kobler rettigheder til rollen. Derefter tildeler I roller til personer og kontrollerer, at tildelingen sker efter en godkendt proces. Roller gør det også lettere at svare på, hvad en medarbejder har haft adgang til i en given periode.

Fjerde trin er at etablere de tekniske forbindelser. Applikationer forbindes til identitetslaget med OIDC eller SAML 2.0, så brugeren får single sign-on og applikationen modtager de nødvendige tokens og claims. Adgangskoder kan fortsat valideres i Active Directory, mens multi-factor authentication og step-up autentifikation lægges foran de følsomme systemer.

En referencearkitektur kan bestå af Active Directory som autoritativt katalog, et identitetslag som FoxIDs og applikationer, der forbindes via OpenID Connect eller SAML 2.0. FoxIDs forbinder til Active Directory via en Directory Connector i Windows-miljøet og holder AD autoritativ for brugere, adgangskoder og gruppemedlemskaber. Applikationer bør ikke forbindes direkte til Active Directory eller LDAP.

Vælg identitetslag ud fra kataloger, applikationer og krav til login, ikke ud fra produktnavnet. Microsoft Entra ID er Microsofts cloudbaserede IAM-platform og fungerer som identitetsudbyder for Microsoft 365, Azure og tusindvis af tredjepartsapplikationer. Entra-familien omfatter Entra ID, Entra External ID, Entra ID Governance, Entra ID Protection og Entra Verified ID.

eADM fra Identum importerer data fra HRM og opretter brugerkonti i Microsoft Entra ID og andre applikationer. eADM automatiserer licens- og adgangsstyring og on/offboarding og giver ledere mulighed for selvbetjening. Omada kan automatisere provisioning og de-provisioning af Microsoft Entra ID-brugere, grupper og medlemskaber.

Planlæg identiteternes livscyklus sammen med integrationerne. Ved onboarding oprettes relevante identiteter og adgange; ved skift af opgave ændres rettighederne; ved fratrædelse fjernes de. Automatiseret on- og offboarding og adgang, der følger medarbejderen, når roller skifter, kan indgå i modellen.

Test hvert integrationsforløb fra login til logout, herunder hvad der sker, hvis en bruger ikke har de nødvendige rettigheder. Kontrollér, at applikationen kun modtager de oplysninger, den skal bruge for at håndhæve adgang. Afprøv ændringer og fejlscenarier, før forbindelsen sættes i drift.

Indfør integrationerne trinvist, begyndende med systemer, hvor adgangen er vigtigst for forretningen eller indebærer størst risiko. Kontrollér efter hver tilslutning, at katalog, identitetslag og applikation viser de samme relevante rettigheder. Brug erfaringerne til at rette roller og processer, før næste system kobles på.

Femte trin er dokumentation og opfølgning. Adgange, godkendelser, klassificeringer og hændelser bør registreres et sted, hvor de kan findes igen – både til intern brug, til revision og til de dokumentationskrav, der følger af databeskyttelsesreglerne. Sjette trin er audit: En planlagt gennemgang af udvalgte systemer og roller, hvor I holder den faktiske adgang op mod det beskrevne behov. Trinnene gentages, når organisationen ændrer sig.

NIS2-loven trådte i kraft 1. juli 2025. Styrelsen for Samfundssikkerhed har udgivet vejledninger om anvendelsesområdet, ledelsens rolle og opgaver, foranstaltninger og hændelsesunderretning. Loven stiller krav til sikkerhed i forsyningskæder, sikkerhedsforanstaltninger og hændelsesrapportering.

Danske leverandører som TDC Erhverv tilbyder driftede forløb inden for endpoint-, identitets- og adgangsstyring med Microsoft 365, Entra og Intune.

Hold IAM-modellen levende med audit og opfølgning

Den største risiko ved en IAM-model er ikke, at den er forkert designet, men at den ikke holdes ved lige. Organisationer ændrer sig, medarbejdere skifter opgaver, leverandører udskiftes, og nye systemer kommer til. Hvis rettigheder kun tildeles og aldrig revurderes, vokser mængden af unødvendig adgang stille og roligt, og modellen beskriver ikke længere virkeligheden.

Gør audit til en fast del af driften frem for et engangsprojekt. En gennemgang af udvalgte roller og systemer viser, om adgangen stadig svarer til behovet, om klassificeringen er opdateret, og om dokumentationen er i orden. Adgangsrecertificering og dens kadence kan indgå i en IAM-driftsmodel.

Fordi gruppemedlemskaber i kataloget ofte styrer adgangen i applikationerne, bør opfølgningen omfatte både kataloget og de claims, applikationerne modtager. Skifter en medarbejder opgave, skal grupperne og dermed adgangen opdateres samme sted.

Opfølgningen bør have tydeligt ejerskab. Nogen skal kunne svare på, hvem der kan tilgå hvad, og hvorfor. Det gælder både de daglige tildelinger og de periodiske revurderinger, og i særlig grad sikre nøgler og certifikater, hvor en glemt eller delt nøgle kan undergrave hele adgangsstyringen.

Vedligehold forbindelserne mellem identitetslag og katalog. Overvåg, om brugeroplysninger og adgangsbeslutninger overføres korrekt, og undersøg fejl, før de påvirker login eller rettigheder. Hvis en integration ikke længere fungerer som forventet, skal det kunne opdages og håndteres som en del af den løbende drift.

Endelig bør ændringer i omverdenen føre tilbage til modellen. Nye regulatoriske krav, et ændret trusselsbillede eller en ny forretningsaktivitet kan betyde, at klassificeringen, godkendelsesprocessen eller adgangskontrollen skal justeres. Ved at koble audit, dokumentation og ledelsesrapportering sammen bliver IAM-modellen et levende styringsværktøj frem for et stykke dokumentation, der samler støv.