Flowchart for brugerprovisionering (tiltrædelse, rolleskifte, fratrædelse)

Sådan fungerer det

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.