Virksomheter utformer administratorrettighetene på endepunktene rundt dagen noen begynner. Sjekklisten for onboarding dekker kontoer, grupper, programmer og policyen for heving av rettigheter som hører til jobben. Livssyklusen for administratorrettigheter på endepunktene får reell oppmerksomhet i nøyaktig ett øyeblikk – og så stopper det.
Dagen noen bytter rolle, finnes det ingen tilsvarende sjekkliste. En utvikler går over til økonomi. En servicedesktekniker begynner i nettverksteamet. En prosjektleder overtar en avdeling. Tilgangen deres til filer og programmer følger en prosess, fordi noen merker det når noe slutter å virke. Muligheten deres til å heve rettigheter på endepunktet følger ingenting, fordi ingenting slutter å virke. Brukeren fortsetter å jobbe. De gamle rettighetene blir liggende.
Over tid fører dette til privilege creep: Brukere samler opp rettigheter fra tidligere roller og beholder dem lenge etter at arbeidet som begrunnet dem, er avsluttet. Hver enkelt tildeling virket rimelig den dagen noen gjorde den. Opphopningen gjorde det aldri.
Der tilgangsstyringen svikter ved rollebytte
Et rollebytte gir ingen feilmelding. Det er hele problemet.
Ingen bestrider styringsprinsippet, og artikkelen vår om innsidetrusler viser hva det koster når en virksomhet ignorerer det: Når en rolle endres, skal tilgangen endres med den. Dette innlegget tar for seg neste spørsmål. Prinsippet håndhever ikke seg selv, og å vite at tilgangen bør flyttes, sier ingenting om hva som faktisk får den til å flytte seg.
Når noen mister tilgang de fortsatt trenger, oppretter de en sak innen en time. Når noen beholder tilgang de ikke lenger trenger, nevner de det aldri – ofte merker de det ikke engang. Gapet lukkes bare når noen leter etter det, og de fleste IT-team har ingen utløser som forteller dem at de bør lete.
Faste lokale administratorrettigheter gjør opphopningen permanent. Rettigheter som aldri utløper, overlever hver omorganisering, hver intern flytting og hver forfremmelse i virksomheten. Ti år med rollebytter etterlater et sett med rettigheter som ikke passer til noens nåværende jobb. Revisorer finner slike opphopninger lett, fordi mønsteret ser likt ut hver gang: Ansatte med lang fartstid har de bredeste rettighetene, og ingen dokumenter forklarer hvorfor.
Fra identitetsstyring til endepunktet
Standardiseringsorganene behandler rollebytte som en egen utløser, ikke som en fotnote til offboarding. CIS Safeguard 6.2 ber virksomheter trekke tilbake tilgang ved rollebytte, ikke bare når et arbeidsforhold avsluttes, og begrunnelsen bak CIS Control 6 peker direkte på to årsaker: tilgang som blir liggende når folk flytter mellom roller, og lokale administratorrettigheter på brukernes bærbare PC-er.
Den innrammingen trekker en tydelig grense. Identitetsstyringen setter regelen – tilgangen følger rollen. Styringen av administratorrettigheter på endepunktene må føre den samme regelen helt ned til enheten, der retten til å heve rettigheter ligger, og der ingen merker det når den slutter å passe til jobben. De fleste virksomheter håndhever den første halvdelen gjennom katalogtjenesten og overlater den andre halvdelen til hukommelsen.
Å fjerne faste administratorrettigheter gjør problemet mindre. Det løser det ikke. Tidsbegrenset heving av rettigheter hindrer at rettighetene varer evig, men en policy med feil omfang gir fortsatt feil omfang hver gang noen utløser den.
Gruppemedlemskap som kontrollpunkt
Den praktiske løsningen er strukturell. Knytt policyene for heving av rettigheter til grupper i stedet for til personer, så blir rollebyttet øyeblikket da rettighetsmodellen din oppdateres.
CapaOne Privilege Manager, en del av CapaOne-plattformen for endepunktadministrasjon, definerer hvem som kan heve rettighetene for hva, hvor og under hvilke begrensninger – per bruker, gruppe, enhet eller program. Policyene retter seg direkte mot Entra ID-grupper og respekterer gruppestrukturen du allerede vedlikeholder, slik at identitetssystemet som allerede gjenspeiler jobben til en person, også kan styre hva vedkommende kan heve rettighetene for på endepunktet.
Når policyene for heving av rettigheter peker på grupper, endrer et nytt gruppemedlemskap hvilke policyer som gjelder for personen. Katalogtjenesten bærer beslutningen, så ingen trenger å skrive om en rettighetsregel ved hver interne flytting. Bekreft hvordan dette fungerer mot din egen gruppestruktur før du stoler på det, og planlegg for de to tilfellene nedenfor, som følger andre regler.
Å fjerne faste administratorrettigheter er utgangspunktet, ikke målet – løsningssiden vår om styring av administratorrettigheter på endepunktene tar for seg det steget.
Unntak per bruker
Hvert unntak du lager for en enkeltperson, er knyttet til den personen og lever lenger enn jobben. Slike unntak hoper seg opp raskere enn teamene regner med, fordi hvert av dem løser et reelt problem den dagen det skrives. Noter begrunnelsen ved hvert unntak, og se på et unntak uten begrunnelse som et signal om å fjerne det.
Forhåndsgodkjente programmer
Med Privilege Manager kan du forhåndsgodkjenne programmer etter navnet på den kjørbare filen eller programbanen. Mekanismen fjerner friksjon i rutinearbeidet, og den beskriver en oppgave, ikke en person. En forhåndsgodkjenning som var fornuftig for ett team, kan være meningsløs når personen som utløser den, jobber et annet sted – så kontroller forhåndsgodkjenningene mot rollene som faktisk bruker dem, ikke mot rollene som ba om dem.
Sjekkliste for gjennomgang ved rollebytte
Gå gjennom denne når noen bytter rolle, og gå gjennom den for de berørte teamene etter en omorganisering.
- Bekreft det nye gruppemedlemskapet. Kontroller at personen er med i gruppene den nye rollen krever, og at disse gruppene har de policyene for heving av rettigheter du forventer.
- Fjern de gamle gruppemedlemskapene. Å legge til de nye gruppene uten å fjerne de gamle er den aller vanligste årsaken til privilege creep.
- Finn unntakene per bruker som nevner personen. Disse overlever hver gruppeendring. Les begrunnelsen du noterte, og slett unntaket hvis begrunnelsen ikke lenger gjelder.
- Gå gjennom de forhåndsgodkjente programmene som de nye policyene tillater. Spør om den nye rollen virkelig trenger hvert av dem.
- Kontroller varigheten på hevede rettigheter. En oppgave som tok tjue minutter i den gamle rollen, kan ta to i den nye. Forkort tidsvinduet der arbeidet har endret seg.
- Les den siste måneden med aktivitet for heving av rettigheter. Hevinger som passer til den gamle jobben og ikke den nye, forteller deg hvilken policy du bør se på først.
- Eksporter dokumentasjonen. Privilege Manager registrerer bruker, endepunkt, navnet på den kjørbare filen og programbanen, tidspunkt, varighet og utfall for hver heving av rettigheter, og eksporterer loggen til CSV. Ta vare på eksporten fra før og etter flyttingen.
- Sett opp en oppfølging. Avtal en ny gjennomgang tretti dager senere. Nye roller avdekker behov som den første gjennomgangen ikke fanger opp, og udokumenterte omveier dukker opp i det tidsrommet.
Steg 6 og 7 krever dokumentasjon, ikke hukommelse. Filtrer CSV-eksporten på personene som har byttet rolle, sorter etter kjørbar fil, og les den side om side med en liste over gruppene de er med i nå. Alt som er utløst av et program den nye rollen ikke bruker, peker på en policy som har overlevd formålet sitt.
Måltall det er verdt å følge
Overskriften betyr mer enn det kan se ut som. Argumenter om styring taper mot budsjettargumenter fordi de kommer uten tall, og hvert tall nedenfor kommer fra data teamet ditt allerede har.
- Faste lokale administratorkontoer i hele enhetsparken. Hovedtallet, og det et styre forstår uten videre forklaring.
- Unntak per bruker for heving av rettigheter. Et økende antall forteller deg at gruppemodellen trenger arbeid, ikke flere unntak.
- Alderen på det eldste unntaket per bruker. Et unntak skal dekke et midlertidig behov. Dette tallet viser om dine gjør det.
- Andelen policyer for heving av rettigheter som er knyttet til grupper i stedet for enkeltpersoner. Den beste enkeltindikatoren på om rettighetene følger organisasjonen.
- Gjennomsnittlig varighet på hevede rettigheter. Kortere tidsvinduer betyr strammere omfang, og trenden betyr mer enn det absolutte tallet.
- Hevinger av rettigheter som faller utenfor brukerens nåværende rolle. Det direkte målet på privilege creep, og det som krever CSV-eksporten.
- Rollebytter som er gjennomgått innen tretti dager. Gjør sjekklisten ovenfor til noe du kan rapportere på.
Følg disse kvartalsvis, ikke kontinuerlig. Poenget er trendlinjen, ikke dagstallet, og et kvartalsvis intervall tåler møtet med et travelt team.
Privilege Manager er en del av en komplett plattform som fungerer helt på egen hånd, og den retter seg mot Entra ID-grupper enten du bruker Microsoft Intune ved siden av eller ikke.
Hvor du bør begynne
Velg den siste omorganiseringen virksomheten din gjennomførte, og bruk den som testcase. Hent ut loggen over heving av rettigheter for de berørte personene, les den side om side med gruppene de er med i nå, og tell avvikene. Det tallet forteller deg om rettighetsmodellen din følger organisasjonen eller henger etter.
En moden modell for minste privilegium slutter ikke med å fjerne lokale administratorrettigheter. Den holder når retten til å heve rettigheter fortsetter å samsvare med det folk faktisk gjør, gjennom hver interne flytting virksomheten gjør. Å få den første delen riktig krever et prosjekt. Å holde den andre delen riktig krever en struktur.
Book en demo av CapaOne-plattformen for endepunktadministrasjon, så går vi gjennom utformingen av policyer for heving av rettigheter mot din egen gruppestruktur.