Flowchart for adgangsanmodning og tildeling af adgang

Sådan fungerer det

1. Sæt navn på jeres rigtige godkendere

   Omdøb de fem baner til de roller, I har. I mindre organisationer er systemejeren og sikkerhedsrevieweren ofte den samme person; læg de baner sammen frem for at tegne en godkendelse, der aldrig sker. Hold én bane pr. beslutningstager — ikke pr. person — så diagrammet overlever, at nogen skifter job.

2. Definer, hvad der tæller som privilegeret eller følsomt

   Beslutningen 'Privilegeret eller følsom adgang?' virker kun, hvis kriterierne står skrevet ved siden af den. De typiske triggere er administrator- og root-konti, servicekonti, adgang til person- eller økonomidata og alt, der kan ændre produktionen. Læg barren, så sikkerhedsgrenen udløses på et mindretal af anmodningerne — ellers bliver den et gummistempel.

3. Skriv jeres regler for funktionsadskillelse ned

   Lav listen over de kombinationer, ingen enkeltperson må have — for eksempel at oprette en leverandør og godkende betalingen, eller at skrive kode og sætte den i produktion. Uden den matrix er konflikttjekket ren teater. Beslut også, hvem der godkender en kompenserende kontrol, når konflikten ikke kan undgås, og notér den på rettigheden.

4. Beslut, hvor adgangsregistret ligger

   Peg registreringstrinnet mod det system, I reelt vil vedligeholde — et identity governance-værktøj, jeres ITSM-platform eller et kontrolleret regneark. Sørg for, at grenen, der fjerner adgang, opdaterer den samme række; ellers bliver registret langsomt en liste over adgang, der er blevet givet, frem for adgang, der findes.

5. Fastlæg kadencen for recertificering og dens ejer

   Erstat det generiske planlagte review med jeres egen frekvens og trigger — for eksempel privilegerede konti kvartalsvis og standardroller årligt, plus et review uden for turnus ved rolleskift. Angiv, hvem der rykker reviewerne, og hvad der sker, når en frist overskrides; et review uden ejer er netop det trin, der stille og roligt holder op med at køre.

6. Få kortet godkendt, og hold én gældende version

   Del diagrammet med de godkendere, der er nævnt i det, indhent deres godkendelse, og link til den godkendte version fra jeres politik for adgangsstyring. Når diagrammet er versionsstyret med en registreret godkendelse, er den proces, folk følger, og den proces, I viser en auditor, den samme.

Ofte stillede spørgsmål

Hvad er en proces for adgangsanmodninger?

Det er den definerede vej, en anmodning om systemadgang tager fra det øjeblik, nogen beder om den, til den er tildelt, registreret og senere gennemgået. En komplet proces har fire dele: en anmodning, der nævner en defineret rolle og en forretningsmæssig begrundelse, godkendelse hos en, der er ansvarlig for personen, og en, der er ansvarlig for systemet, teknisk tildeling af den, der har administratorrettighederne, og en registrering af rettigheden med en reviewdato. At anmode og at tildele er bevidst adskilte trin udført af forskellige personer, så ingen giver sig selv adgang.

Hvem skal godkende en adgangsanmodning?

To godkendere dækker de fleste situationer. Nærmeste leder bekræfter, at personen har brug for adgangen til sit arbejde — det er et spørgsmål om ansøgeren. System- eller dataejeren bekræfter, hvad rollen reelt giver, og om netop denne person skal have den — det er et spørgsmål om systemet. En tredje godkendelse fra sikkerhed er kun besværet værd ved privilegeret eller følsom adgang, og det er præcis sådan, denne skabelon dirigerer den. Flere godkendere forbedrer sjældent beslutningen, men forlænger pålideligt ventetiden — og det er ventetiden, der skaber uformelle smutveje som delte adgangskoder.

Hvad er en kontrol af funktionsadskillelse i adgangsstyring?

Den tester, om den ønskede rolle kombineret med de adgange, personen allerede har, ville lade én enkelt person gennemføre en følsom transaktion fra ende til anden uden et uafhængigt led. Klassiske eksempler er at oprette en leverandør og godkende dens betalinger, eller at skrive kode og sætte den i produktion. Kontrollen kræver en aftalt liste over konfliktende kombinationer at teste imod. Når en konflikt ikke kan undgås — for eksempel i et lille team — er det sædvanlige svar en dokumenteret kompenserende kontrol, typisk en efterfølgende gennemgang udført af en anden, noteret på rettigheden.

Hvor ofte skal brugeradgange recertificeres?

Risikoen skal sætte frekvensen. Et udbredt mønster er kvartalsvis for privilegerede konti og administratorkonti, årligt for almindelige forretningsroller og et øjeblikkeligt review uden for turnus, hver gang nogen skifter rolle eller team. ISO/IEC 27001:2022 kontrol A.5.18 kræver, at adgangsrettigheder gennemgås regelmæssigt, men foreskriver ikke et interval — frekvensen er jeres at begrunde. Bemærk, at et flowchart dokumenterer hensigt, ikke efterlevelse: den dokumentation, en auditor beder om, er godkendelserne og registret, processen producerer.