Flowchart for fjernelse af brugeradgang (deprovisionering)

Hvad er flowchart for fjernelse af brugeradgang (deprovisionering)?

Fjernelse af brugeradgang (også kaldet deprovisionering eller inddragelse) er processen med at tage adgange fra en person, der ikke længere har brug for dem, og at kunne dokumentere, at de rent faktisk blev taget. Den løber fra en udløser, som kan være en fratrædelse, et rolleskifte, en kontrakt eller opgave, der slutter, eller en rettighedsgennemgang, der har fundet en adgang, ingen kan begrunde, og frem til en registrering, der viser, at hver eneste konto og rettighed er håndteret. Den er tidskritisk på en måde, de fleste administrative processer ikke er: risikovinduet åbner i det øjeblik, udløseren indtræffer, og står åbent, indtil den sidste session er lukket.

Det er ikke hele fratrædelsesprocessen. Overlevering, fratrædelsessamtale, aflevering af udstyr og sidste løn hører hjemme i offboarding af medarbejdere, som er en bredere koordineringsopgave ejet af HR. Denne proces er adgangshalvdelen af den, og den kører også for folk, der slet ikke er på vej ud, derfor er udløserbanen opkaldt efter kilden frem for efter en fratrædelse. Det er heller ikke tildelingssiden: hvordan adgang anmodes, begrundes, godkendes og tildeles, hører til i processen for adgangsanmodning. Fjernelsen begynder, hvor de to slipper, og ét flow dækker alle fire udløsere i stedet for at være skrevet ordentligt til fratrædelser og improviseret til alt andet.

Skabelonen tegner flowet på tværs af fem baner, Udløsende kilde (HR eller leder), IT-servicedesk, Systemejer, Sikkerhed og Audit, over seks faser fra udløser til dokumentation og lukning. Den indeholder grenen, der afgør, om inddragelsen sker øjeblikkeligt eller på virkningsdatoen, håndteringen af delte konti, servicekonti og privilegerede konti, som ikke bare kan slukkes, beslutningen om at deaktivere kontra slette, og et afstemningstjek til sidst, der holder det faktisk fjernede op mod den liste, der blev lavet i starten. Formen følger fjernelseshalvdelen af det adgangsforløb, ISO/IEC 27001:2022 Annex A-kontrol A.5.18 beskriver, og som kræver, at adgangsrettigheder fjernes eller justeres, når en ansættelse eller et samarbejde ophører eller ændrer sig.

Hvad dette flowchart dækker

I denne skabelon

• Fire veje ind, ét flow: beslutningen 'Type af udløser?' i banen Udløsende kilde sender en fratrædelse eller kontraktophør, et rolleskifte og et fund i en gennemgang ned ad den samme fjernelsesvej, så intet afhænger af, om det tilfældigvis var HR, der oprettede sagen
• Beslutningen 'Kræves øjeblikkelig inddragelse?' i IT-servicedeskens bane, med en øjeblikkelig gren, der lukker alle adgange inden for en time ved bortvisninger og privilegerede konti, og en planlagt gren, der sætter fjernelsen til virkningsdatoen, begge mødes igen i det samme kortlægningstrin
• Ét kortlægningstrin, der samler den fulde liste over konti og rettigheder, før noget som helst bliver lukket, med en kommentar på noden, der navngiver de kilder, folk overser: lokale konti, service- og delte konti, VPN og fjernadgang, cloud- og databasekonsoller, tredjeparts-SaaS købt på et kort samt fysisk adgang til bygninger
• Beslutningen 'Delt eller privilegeret konto?' ejet af systemejeren, som sender delte konti, servicekonti og privilegerede konti videre til Sikkerhed for at skifte adgangskoder og nøgler: de konti kan ikke deaktiveres uden at ødelægge noget, der afhænger af dem
• Beslutningen 'Deaktivér eller slet kontoen?' i inddragelseskolonnen, hvor begge grene mødes igen i systemejerens inddragelse af rettighederne i hvert enkelt system
• Data og licenser i den rækkefølge, der undgår forældreløse filer: postkasse og filejerskab overdrages, før licenser frigives og registret opdateres, hvorefter Sikkerhed dokumenterer inddragelserne, og afstemningen 'Er der stadig aktive adgange?' i Audit-banen sender eventuelle huller tilbage til kortlægningen inden den endelige godkendelse

Hvornår du skal bruge skabelonen

• I skriver eller gennemgår en procedure for deprovisionering og har brug for at få adgangstrinnene skilt ud fra den bredere offboarding-tjekliste, med en ansvarlig på hvert enkelt trin
• Rettighedsgennemgange bliver ved med at finde aktive konti for folk, der er fratrådt, har skiftet team eller har afsluttet en kontrakt, og I skal kunne vise, hvor i processen fjernelsen sker, og hvem der bekræfter den
• I er ved at sætte automatik op for tiltrædelse, jobskifte og fratrædelse i en identitetsplatform eller et servicedeskværktøj og vil have processen aftalt, før den bliver kodet ind i workflow-regler
• I har mange konsulenter og eksterne, så det er kontrakternes slutdatoer og ikke et HR-feed, der er den primære udløser, og der findes ingen fratrædelsesregistrering at arbejde ud fra
• I skal svare en auditor eller et sikkerhedsspørgeskema fra en kunde på, hvordan adgange fjernes ved ophør, og hvilken dokumentation der findes for, at det skete

Sådan fungerer det

1. Navngiv jeres reelle udløsere

   Diagrammet arbejder med fire udløsere: fratrædelse, kontraktophør, rolleskifte og fund i en rettighedsgennemgang. Skriv ned, hvilket system eller hvilken person der er den autoritative kilde for hver enkelt, for eksempel HR-systemet for medarbejdere, kontraktregistret for leverandører og konsulenter og resultatet af gennemgangen for fund. Er der en udløser uden ejer i dag, er det det hul, der er værd at lukke først: en proces, ingen starter, kan ikke måles.

2. Skriv reglen for øjeblikkelig inddragelse ned

   Beslutningen 'Kræves øjeblikkelig inddragelse?' virker kun, hvis kriterierne står ved siden af den. Typiske udløsere er bortvisning, mistanke om misbrug og enhver, der har administrator-, produktions- eller betalingsgodkendelsesrettigheder. Tilføj jeres egen målsatte tid, og angiv, hvem der kan udløse den uden for arbejdstid. Ved en bortvisning tidsfæstes inddragelsen normalt til selve samtalen, så grenen handler lige så meget om rækkefølge som om hastighed.

3. Hæft jeres systemoversigt på kortlægningstrinnet

   Erstat den generiske kontoliste med den oversigt, I faktisk vedligeholder, og markér, hvilke systemer der ligger bag single sign-on, og hvilke der ikke gør. Alt uden for identitetsplatformen er der, hvor de oversete adgange bor: lokale administratorkonti, databaselogins, SSH-nøgler, API-tokens og værktøjer, et team har købt på et kort. Bed den fratrædendes leder om at navngive alt det, IT ikke administrerer.

4. Beslut deaktivering kontra sletning, før I får brug for det

   Sæt deaktivering som standard, og definer, hvornår sletning er tilladt, for eksempel efter en fastsat opbevaringsperiode eller ved kontraktophør, hvor en aftale kræver det. Notér, hvem der træffer den beslutning. Sletter I for tidligt, ødelægger I maildata, filejerskab og den historik, som afstemningstrinnet og enhver senere undersøgelse er afhængig af.

5. Hold rækkefølgen på data- og licenstrinnene

   Overdrag postkasse og filejerskab først, og frigiv derefter licenserne. Bytter I om på de to, bliver delte filer og postkasser forældreløse, og det er langsomt at få dem tilbage bagefter. Opretter I en videresendelse eller en fuldmagt, så giv den en navngiven ejer og en slutdato i det samme trin, ellers bliver den midlertidige løsning stille og roligt permanent.

6. Aftal, hvad der tæller som dokumentation, og hvem der afstemmer

   Beslut, hvad registreringen af en inddragelse skal indeholde (typisk system, handling, tidsstempel og hvem der udførte den), og hvor den opbevares. Udpeg derefter, hvem der kører tjekket 'Er der stadig aktive adgange?', og hvad der afstemmes imod: kun ved at afstemme mod den oprindelige kontoliste frem for mod hukommelsen fanger I en udeladelse. Udgiv det godkendte diagram sammen med jeres adgangspolitik, så den proces, folk følger, og den proces, I viser en auditor, er den samme.

Ofte stillede spørgsmål

Hvad er processen for fjernelse af brugeradgang?

Det er den definerede vej, en fjernelse af en persons adgange tager, fra udløseren til en bekræftet og dokumenteret lukning. En komplet proces har fem dele: en udløser med en navngiven kilde, en beslutning om, hvor hurtigt adgangen skal væk, en kortlægning af hver eneste konto og rettighed, personen har, en inddragelse i hvert system hvor konsekvenserne for data og licenser er håndteret, og en afstemning, der viser, at intet blev efterladt aktivt. Udløserne er bredere, end de fleste teams antager. Ud over fratrædelser bør processen køre ved rolle- og teamskift, ved kontrakters ophør og ved ethvert fund i en rettighedsgennemgang: det er netop de veje, der skaber de adgange, ingen bagefter kan forklare.

Hvor hurtigt skal adgange fjernes, når nogen fratræder?

Standarderne fastsætter kravet, ikke uret. ISO/IEC 27001:2022-kontrol A.5.18 kræver, at adgangsrettigheder fjernes eller justeres ved ophør eller ændring af ansættelsen, men foreskriver ikke et interval: målet er jeres eget at sætte og begrunde. Et almindeligt mønster er fjernelse ved udgangen af den sidste arbejdsdag ved en planlagt fratrædelse og øjeblikkelig fjernelse tidsfæstet til samtalen ved en bortvisning eller for enhver med privilegeret adgang. Uanset hvad I vælger, så skriv det ind i processen, mål den faktiske tid fra udløser til sidste inddragelse, og betragt afstanden mellem de to som det tal, der er værd at rapportere.

Skal vi deaktivere eller slette kontoen?

Deaktivering er det sikre udgangspunkt, og det er, hvad de fleste organisationer gør først. Det lukker kontoen, afslutter aktive sessioner og blokerer login, samtidig med at postkassens indhold, filejerskab, gruppemedlemskaber og den historik, en undersøgelse eller en senere rettighedsgennemgang kan få brug for, bevares. Sletning hører hjemme ved udløbet af en fastsat opbevaringsperiode eller ved kontraktophør, hvor en aftale eller et databeskyttelsestilsagn kræver det. Uanset hvad I vælger, betyder det lige så meget at afslutte aktive sessioner og tilbagekalde tokens som selve kontotilstanden: en deaktiveret konto med en levende session eller et gyldigt refresh-token har stadig adgang, indtil sessionen udløber.

Hvordan fjerner man adgang til delte konti, servicekonti og privilegerede konti?

Man kan ikke deprovisionere en delt konto eller en servicekonto ved at deaktivere den, for andre mennesker og systemer afhænger af den. Handlingen er i stedet at skifte adgangsmidlet: skift adgangskoden eller nøglen, fjern personen fra den boks eller gruppe, der opbevarer den, tilbagekald de API-tokens, SSH-nøgler og personlige adgangstokens, vedkommende har oprettet, og afslut alle aktive sessioner. Privilegerede personlige konti skal have den samme session- og token-håndtering oven i den almindelige deaktivering. Skabelonen lægger dette på sin egen gren, ejet af Sikkerhed, fordi det er det tilfælde, der oftest bliver overset, og det med de bredeste konsekvenser, hvis det bliver det.

Hvilken dokumentation skal processen frembringe?

Som minimum en sag eller en registrering pr. fjernelse, der viser udløseren og dens dato, den liste over konti og rettigheder, der blev samlet, den handling der blev udført i hvert system med tidsstempel og navnet på den, der udførte den, samt resultatet af afstemningstjekket. Det er den registrering, en auditor stikprøver, og den, der gør, at I kan svare på et sikkerhedsspørgeskema med en dato frem for en beskrivelse. Det er værd at være tydelig om, hvad et flowchart gør her: det dokumenterer den tilsigtede proces og hvem der ejer hvert trin, men beviset for efterlevelse er de registreringer, processen frembringer, når den kører.