Flowchart for brugerprovisionering (tiltrædelse, rolleskifte, fratrædelse)
Flowchart for brugerprovisionering: HR-hændelse, identitet i katalogtjenesten, loginoplysninger og MFA, rollens rettighedspakke, ejergodkendelse af privilegeret adgang, konti i målsystemerne, verificering og recertificering.
Hvad er flowchart for brugerprovisionering (tiltrædelse, rolleskifte, fratrædelse)?
Brugerprovisionering fejler lydløst, og derfor bliver den som regel rettet efter en audit i stedet for før. Tiltrædelsen er den synlige halvdel: en nyansat uden postkasse klager på sin første arbejdsdag, og nogen får det ordnet. Alt det andet er usynligt. Adgangen bliver kopieret fra den, der sad på stolen sidst, så én overprovisioneret konto bliver afdelingens udgangspunkt. Konsulenter kommer ind uden HR-post, uden slutdato og med en sponsor, der siden er stoppet. Halvdelen af systemlandskabet ligger bag single sign-on og tildeles automatisk, mens den anden halvdel (økonomisystemet, værktøjet et team købte på et kort, leverandørportalen) er en manuel kø, ingen måler på. Og et internt rolleskifte lægger til uden nogensinde at trække fra, fordi der intet sted rapporteres adgang, som blot er blevet unødvendig. Ingen af delene giver en hændelse. De giver en langsom ophobning, der dukker op år senere som et fund i en adgangsgennemgang, en fejlet kontroltest eller en tidligere medarbejders konto, der stadig logger på.
Dette diagram er maskineriet bag identiteter og konti, ikke anmodningsformularen og ikke godkendelseskæden. En person, der allerede er i stillingen og beder om én rettighed mere, med godkendelserne og recertificeringen omkring sig, hører til flowchartet for adgangsanmodninger på /da/templates/adgangsanmodning-proces; den samme anmodning udløst af en HR-hændelse ved tiltrædelse eller rolleskifte og afgrænset af en rolleprofil ligger på /da/templates/medarbejder-adgangsanmodning-proces. Adgang til et datasæt, hvor en dataejer træffer beslutningen ud fra klassifikation og formål frem for stillingsrolle, ligger på /da/templates/anmodning-om-dataadgang-proces. Fratrædelsesgrenen her er bevidst kort og overdrager så videre: hele forløbet for deprovisionering, med delte konti og servicekonti, deaktivering kontra sletning og indsamling af dokumentation, ligger på /da/templates/fjernelse-af-brugeradgang-proces. Kontrakter, screening, udstyr og første arbejdsdag hører til /da/templates/medarbejder-onboarding-proces. Tilbage står alt mellem hændelsen og et sæt konti, der virker, er verificeret og er registreret (identiteten, loginoplysningerne, rettighedspakken, målsystemerne), plus den ene gruppe, ingen af de sider dækker: den eksterne, der møder op helt uden HR-post. Kontrolmæssigt er dette identitetshalvdelen af ISO/IEC 27001:2022 Annex A (A.5.16 om identitetsstyring, der dækker en identitets samlede levetid, og A.5.17 om autentifikationsinformation, der dækker de loginoplysninger, som udstedes til den), frem for A.5.15 og A.5.18, der handler om, hvad identiteten derefter må nå frem til.
Tre beslutninger er tegnet eksplicit her, som de fleste provisioneringsprocedurer lader være underforstået. 'Medarbejder eller ekstern?' kommer, før identiteten overhovedet findes, fordi en konsulent har brug for en navngiven sponsor og en udløbsdato, som et HR-feed aldrig leverer, og en identitet oprettet uden dem er netop den forældreløse konto, en adgangsgennemgang finder to år senere. 'Inden for standardpakken?' deler flowet i to: alt i rollens pakke tildeles automatisk uden nogen i vejen, og kun privilegerede rettigheder og rettigheder uden for pakken går til en ejer, og det er dét, der forhindrer godkendelsen i at blive et stempel, man sætter på postkasser. Og 'Svarer den tildelte adgang til anmodningen?' er en port og ikke en afsluttende formalitet, fordi den læser tilbage, hvad målsystemerne rent faktisk giver, og holder det op mod det, der blev bedt om; rettigheder, der er landet uden godkendelse, bliver aldrig meldt af den, som har fået dem. Rolleskiftegrenen tilføjer en fjerde, 'Gamle rettigheder uden for den nye pakke?', og recertificeringen en femte, 'Passer rettighederne stadig til rollen?', og begge svarer ind i det samme inddragelsestrin, så der er én vej ud af en rettighed, uanset hvordan behovet for at fjerne den blev fundet.
Hvad dette flowchart dækker
I denne skabelon
- Seks faser (Udløser, Identitet, Rettigheder, Tildeling, Verificering samt Ændring og review) fordelt på fem swimlanes: HR eller sponsor, Identitetsteam, Nærmeste leder, Rettighedsejer og Sikkerhed
- Ét indgangspunkt for fem hændelser. 'Hvilken identitetshændelse?' sender tiltrædelse, rolleskifte, fratrædelse, en anmodning om nødadgang og en planlagt recertificering ned gennem det samme diagram, så maskineriet deles frem for at blive opfundet forfra i hvert enkelt tilfælde
- Identitetsfasen i fuld længde: 'Medarbejder eller ekstern?' sender konsulenter, vikarer og servicepartnere gennem 'Registrer sponsor og udløbsdato' (det eneste trin, der giver dem en ansvarlig ejer og en slutdato), før begge veje mødes i 'Opret identiteten i katalogtjenesten' og 'Udsted loginoplysninger og tilmeld MFA'
- 'Inden for standardpakken?': standardgrenen løber direkte til 'Tildel standardpakken automatisk' uden en godkender i vejen, mens privilegerede rettigheder og rettigheder uden for pakken går til 'Godkender rettighedsejeren?', hvis afvisningsgren ender i 'Rettighed afvist og lukket'
- Tildeling i den rækkefølge, diagrammet kører den: 'Tildel standardpakken automatisk', derefter 'Opret konti i målsystemerne' på tværs af både det automatiserede og det manuelle systemlandskab, og så 'Svarer den tildelte adgang til anmodningen?', hvis afvigelsesgren går gennem 'Ret over- eller undertildelingen' og tjekker igen frem for at lukke sagen
- Ændringshalvdelen: et rolleskifte får spørgsmålet 'Gamle rettigheder uden for den nye pakke?', og alt, hvad der findes, går til 'Inddrag de afløste rettigheder', før det vender tilbage til 'Inden for standardpakken?'; en fratrædelse ender i 'Overdraget til processen for adgangsfjernelse'; og 'Passer rettighederne stadig til rollen?' sender et afveget svar til nøjagtig det samme inddragelsestrin
Hvornår du skal bruge skabelonen
- I skal skrive afsnittet om identitet og adgang i en it-driftshåndbog og har brug for ét billede af, hvad der sker mellem en HR-hændelse og et sæt konti, der virker
- I står over for at købe eller konfigurere et værktøj til identitetsstyring og vil have grenene afklaret (hvad der tildeles automatisk, hvad der kræver en ejer, hvad der forbliver en manuel kø), før en leverandørs standardworkflow afklarer dem for jer
- Adgangsgennemgange bliver ved med at finde rettigheder fra jobs, folk forlod for år siden, og I har brug for at få fjernelsestrinnet ved rolleskifte tegnet med en ejer og en frist på
- Jeres systemlandskab er fuldt af eksterne (konsulenter, vikarer, revisorer, partnere, servicekonti), og ingen af dem kommer fra det HR-feed, resten af processen bygger på
- En auditor, et sikkerhedsspørgeskema fra en kunde eller en ISO 27001-reviewer har spurgt, hvordan identiteter oprettes, hvordan rettigheder tildeles, og hvordan I ved, at den adgang, der findes, er den adgang, der blev godkendt
Sådan fungerer det
Omdøb banerne, så de passer til jeres egne roller
Erstat HR eller sponsor, Identitetsteam, Nærmeste leder, Rettighedsejer og Sikkerhed med de roller, I reelt har. Hold HR og sponsor i samme bane med vilje: det er den samme opgave løst for hver sin gruppe mennesker, og det er netop ved at dele dem, at eksterne ender uden nogen ansvarlig. Rettighedsejerbanen er den, de fleste organisationer opdager, at de ikke har besat. Kan I ikke i dag sætte navn på en ejer af jeres privilegerede rettigheder, er det hul et fund og ikke et redigeringsproblem, og banen bør blive stående i diagrammet, synligt tom, indtil hullet er lukket.
Fastslå jeres autoritative kilde, og hvad den ikke dækker
Diagrammet forudsætter et autoritativt feed af tiltrædelser, rolleskift og fratrædelser. Skriv ned, hvilket system det er, hvilke felter det bærer (stillingsrolle, leder, startdato, virkningsdato for en ændring, sidste arbejdsdag), og hvor hurtigt en ændring dukker op i det. Skriv derefter ned, hvem der ikke står i det. Konsulenter, bestyrelsesmedlemmer, vikarer, praktikanter og maskinidentiteter gør det som regel ikke, og hver eneste af dem har brug for sit eget register og sin egen sponsor, før resten af processen kan køre.
Skriv rettighedspakkerne, før I udgiver
'Udled rollens rettighedspakke' er tomt, indtil pakkerne findes. Start med de ti roller, I ansætter oftest til, og skriv ned, hvad hver af dem reelt har brug for på første arbejdsdag. Har I data om logins eller seneste anvendelse, så byg ud fra det, de nuværende indehavere faktisk bruger, frem for det, de har liggende; forskellen er som regel stor, og den er hele grunden til, at pakken er værd at skrive. Hold hver pakke som et gulv og ikke et loft, så alt uden for den forbliver synligt nok til at være værd at bede om.
Læg barren for, hvornår en ejer skal godkende
'Inden for standardpakken?' virker kun, hvis kriterierne står ved siden af. Typiske udløsere for godkendelsesgrenen er administrator- og root-rettigheder, adgang til produktion, betalings- og lønsystemer, person- og helbredsoplysninger samt alt, der kan ændre en anden persons adgang. Test listen mod sidste kvartals tildelinger, før I udgiver den: et kriterium, der fanger de fleste af dem, er ikke et kriterium. Sendes alt til en rettighedsejer, kommer godkendelserne hurtigere, end nogen kan nå at læse dem, og kontrollen bliver en kø, folk lærer at klikke sig igennem.
Gør fjernelsen ved rolleskifte til en forpligtelse, der følges op
'Inddrag de afløste rettigheder' er det trin, der afgør, om adgang hober sig op hos jer. Giv det den samme sag, den samme ejer og den samme frist som tildelingen, og luk først rolleskiftet, når begge halvdele er gjort: en sag, der lukkes på tildelingshalvdelen, er selve mekanismen bag, at fjernelsen aldrig sker. Diagrammet lægger med vilje sammenligningen hos nærmeste leder frem for hos identitetsteamet: teamet kan producere listen over forskelle, men kun lederen ved, om en rettighed reelt er afløst eller stadig er nødvendig til en overdragelse.
Gå den igennem med dem, der kører den, og udgiv en version
Afklar de to grene, ingen ejer som udgangspunkt, før I udgiver. Beslut, hvem der må tage nødadgang uden for normal arbejdstid, og hvem der læser sessionsloggen bagefter, og beslut, hvem der handler på et 'Afveget'-svar ved recertificeringen, og hvornår, for et review, der producerer en liste, ingen inddrager noget ud fra, er værre end intet review. Tag derefter diagrammet med til en medarbejder i servicedesken, en leder, der har rekrutteret for nylig, og den, der sidst kørte en adgangsgennemgang, og ret det til det, der faktisk sker. Udgiv den rettede version, hold de tidligere læsbare, og henvis til den fra jeres adgangspolitik.
Ofte stillede spørgsmål
Hvilke trin består brugerprovisionering af?
Tag en hændelse om tiltrædelse, rolleskifte eller fratrædelse fra den autoritative kilde; afgør, om personen er medarbejder eller ekstern, og giv eksterne en sponsor og en udløbsdato; opret eller genfind en identitet i katalogtjenesten med et id, der aldrig genbruges; udsted loginoplysninger og tilmeld multifaktorgodkendelse på den identitet; udled rettighedspakken for stillingsrollen; tildel alt inden for pakken automatisk, og send privilegerede rettigheder og rettigheder uden for pakken til rettighedsejeren for godkendelse; opret konti i målsystemerne, både de automatiserede og den manuelle kø; verificer, at det, systemerne rent faktisk giver, svarer til det, der blev bedt om; lad nærmeste leder bekræfte det; og registrer rettighederne på identiteten. Derefter kører processen videre: et rolleskifte udleder pakken på ny og inddrager det, den gamle rolle ikke længere begrunder, en fratrædelse deaktiveres og overdrages til fjernelse, og recertificeringen kontrollerer med jævne mellemrum, at rettigheder og rolle stadig passer sammen.
Hvad er en standardpakke eller rollebaseret rettighedspakke?
Det er det sæt adgange, et job har brug for på sin første dag, hængt op på rollen frem for på personen: mail og kalender, intranettet, de centrale fagsystemer for den funktion, teamets fællesdrev. Fordi den udledes af stillingsrollen, kan den tildeles uden en godkender i vejen, og det er netop pointen: den fjerner rutinetildelingerne fra godkendelseskøen, så undtagelserne bliver læst ordentligt. To regler holder pakkerne ærlige. Byg dem ud fra, hvad jobbet kræver, aldrig ved at eksportere adgangen fra den, der havde stillingen sidst, for så kopieres alt det ophobede ekstra med over sammen med det nødvendige. Og giv hver pakke en navngiven ejer og en reviewdato, for en pakke uden ejer vokser kun: hver anmodning, man ikke kunne afvise, bliver lagt ind i den, og inden for to år giver den langt mere, end noget enkelt job har brug for.
Hvordan adskiller brugerprovisionering sig fra en proces for adgangsanmodning?
De mødes på midten og ejer hver sin halvdel. Processen for adgangsanmodninger på /da/templates/adgangsanmodning-proces starter med en person, der allerede er i stillingen og mangler ét system mere: personen opretter en anmodning, nærmeste leder og systemejeren godkender den, og adgangen tildeles og recertificeres senere. Processen for medarbejderes adgangsanmodninger på /da/templates/medarbejder-adgangsanmodning-proces dækker den samme anmodning, når en HR-hændelse ved tiltrædelse eller rolleskifte udløser den, og en rolleprofil afgrænser den. Begge handler om at beslutte. Denne side handler om at gøre: oprette identiteten, udstede loginoplysningerne og tilmelde multifaktorgodkendelse, udlede pakken, oprette konti i hvert eneste målsystem og læse rettighederne tilbage ud af systemerne for at kontrollere, at det er dem, der blev godkendt. Skal I designe en anmodningsformular eller en godkendelseskæde, så brug de to. Skal I bygge eller dokumentere maskineriet bag dem, inklusive identiteter for eksterne og fjernelseshalvdelen af et internt rolleskifte, så brug denne. Er spørgsmålet adgang til et datasæt frem for til et system, så se /da/templates/anmodning-om-dataadgang-proces.
Hvor meget af brugerprovisioneringen kan reelt automatiseres?
Mere, end de fleste organisationer har automatiseret, og aldrig det hele. Systemer bag single sign-on kan køre uden en sag: identiteten i katalogtjenesten oprettes ud fra HR-posten, rollens pakke lægges på, gruppemedlemskaber følger med. Det, der spænder ben for fuld dækning, er det systemlandskab, ingen har planlagt for: lønsystemet uden API, laboratorieinstrumentet der har sin egen lokale brugerliste, partnerportalen hvor en konto oprettes ved at svare på en mail. De kræver en kø med en navngiven ejer og en målsat tid, og de skal stå på en liste, for et manuelt system, der ikke er på listen, tildeles for sent ved en tiltrædelse og overses helt ved en fratrædelse. Hold et register over, hvilke systemer der er koblet på, og hvilke der ikke er, se det efter hver gang der købes noget nyt, og betragt det at forkorte den manuelle liste som selve arbejdsprogrammet. At automatisere tildelingen uden at automatisere tilbagelæsningen er en fælde for sig: connectorer fejler lydløst, og det er derfor, verificeringstrinnet læser rettighederne fra målsystemet frem for fra sagen.
Hvordan provisionerer man konsulenter og andre eksterne?
På samme måde som medarbejdere, bortset fra at intet system opstrøms fortæller jer, at de findes. Konsulenter, vikarer, revisorer, partneringeniører, praktikanter og maskinidentiteter står sjældent i HR-systemet, så de to oplysninger, der gør en identitet mulig at administrere, skal registreres bevidst: en navngiven intern sponsor, der står til ansvar for den, og en udløbsdato taget fra kontrakten eller opgaven frem for ladt åben. Gør udløbet automatisk: kontoen deaktiverer sig selv på datoen, og en forlængelse er en udtrykkelig handling fra sponsoren med en ny slutdato. Flyt sponsoratet, når en sponsor stopper, for en sponsoreret identitet, hvis sponsor er væk, er præcis den konto, ingen gennemgår. Eksterne fortjener som regel også strammere pakker og et kortere interval mellem recertificeringer end fastansatte, fordi deres arbejde er smallere, og udskiftningen går hurtigere. De fleste forældreløse konti, en adgangsgennemgang finder, tilhører nogen, organisationen aldrig har haft ansat.
Hvor denne proces passer ind
I de fleste virksomheder følger denne proces efter Flowchart til credentialing af behandlere og sender videre til Flowchart for fjernelse af brugeradgang (deprovisionering).
Den er ét trin i Adgangsstyring.
Trin 1: Flowchart for brugerprovisionering (tiltrædelse, rolleskifte, fratrædelse) Du er her
Flowchart for brugerprovisionering: HR-hændelse, identitet i katalogtjenesten, loginoplysninger og MFA, rollens rettighedspakke, ejergodkendelse af privilegeret adgang, konti i målsystemerne, verificering og recertificering.
Trin 2: Flowchart for adgangsanmodning og tildeling af adgang
Flowchart for adgangsanmodninger: rollebaseret anmodning, godkendelse hos nærmeste leder og systemejer, kontrol af funktionsadskillelse, tildeling efter mindste privilegium og recertificering.
Trin 3: Flowchart for adgangsanmodning ved tiltrædelse og jobskifte
Trin 4: Flowchart for fjernelse af brugeradgang (deprovisionering)