Å fjerne faste lokale administratorrettigheter er ikke én enkelt endring. Just-in-time-tilgang – midlertidig heving av rettigheter – erstatter dem med fire valg, tatt i denne rekkefølgen: hvilke oppgaver som får hevede rettigheter automatisk, hvilke verktøy policyen avviser helt, hvor lenge en heving varer, og hvem som kan gi en heving når ingen policy dekker tilfellet. Team som avklarer alle fire før de rører et eneste endepunkt, bruker den første måneden på å finjustere policyer. Team som avklarer ett og oppdager resten under press, bruker den på å besvare henvendelser.
Mekanikken er godt kjent nå. Å fjerne faste lokale administratorrettigheter stenger en eskaleringsvei en angriper kan bruke etter å ha kompromittert et endepunkt, og det er derfor fjerning av lokal admin stenger åpningen som EDR-killere er avhengige av. Den praktiske siden av overgangen får langt mindre oppmerksomhet: hvilke valg som kommer først, i hvilken rekkefølge utrullingen skjer, og hvilken dokumentasjon du sitter med når den er ferdig.
Fire valg før du slår på just-in-time-tilgang
Hvert av dem har et standardsvar som virker fornuftig, men som skaper arbeid senere.
Heving per prosess eller per økt
CapaOne Privilege Manager, en del av CapaOne-plattformen for endepunktadministrasjon, støtter begge deler, og forskjellen betyr mer enn den først ser ut til. Heving per prosess gir hevede rettigheter til én navngitt kjørbar fil, identifisert med navn og filbane, og fjerner dem i det øyeblikket prosessen lukkes. Heving per økt gir bredere administrativt omfang i en definert periode.
Heving per prosess dekker det aller meste av rutinearbeidet – et bestemt installasjonsprogram, et bestemt konfigurasjonsverktøy, en bestemt driverpakke. Bruk heving per økt bare der oppgaven virkelig spenner over flere verktøy, og gi den den korteste varigheten som lar arbeidet bli ferdig. Den vanlige feilen går motsatt vei: Team gir økter fordi økter gir færre spørsmål, og seks måneder senere har økten i det stille blitt den faste administratorrettigheten de ville fjerne.
Hva som skal avvises som standard
Hevingspolicyen bestemmer hva brukerne kan heve. Avvisningsregler bestemmer hva de ikke kan heve i det hele tatt, uansett hvem som spør. Privilege Manager støtter avvisningsregler for kommandoskall og usignerte installasjonsprogrammer, med eksplisitte unntak i policyen der det finnes et kontrollert behov.
Skriv disse først, før tillatelsesreglene. En avvisningsliste skrevet på dag én er en sikkerhetsbeslutning. Den samme listen skrevet i måned tre, etter en hendelse, er en reaksjon – og den blir vanskeligere å forsvare overfor dem hvis arbeidsflyt den forstyrrer.
Hvor lenge en heving bør vare
Sett en kort varighet med automatisk tilbakekalling, og følg med på hvilke varigheter som løper helt ut. En heving som gang på gang løper til grensen, forteller deg at den underliggende oppgaven burde være en policy og ikke en forespørsel. En heving som gis for en time og brukes i nitti sekunder, forteller deg at grensen er for raus.
Dette er tallet det er verdt å se på igjen hver måned. Det er også det ingen tenker på å se på, fordi ingenting slutter å virke når det er feil.
Hvem som godkjenner det ingen policy dekker
Noen tilfeller passer ikke inn i noen policy, og det fjerde valget er hvem som håndterer dem. Privilege Manager har break-glass-kontroller nettopp for dette, og supportpersonalet kan godkjenne en avgrenset, tidsbegrenset heving uten å eksponere lokale administratorpassord for noen.
Break-glass fungerer når to ting er på plass: Det forblir sjeldent, og noen gjennomgår hver bruk. En break-glass-vei som brukes hver uke, er ikke en unntaksmekanisme. Det er et hull i policyen med et vennligere navn.
De fire fasene i utrullingen
Den første konfigurasjonen går raskt. Utrullingen gjør ikke det, og den skal heller ikke gjøre det – Privilege Manager legger opp til en trinnvis rekkefølge, og avstanden mellom de to tempoene er der de fleste prosjekter mister farten.
Fase én: Fjern de faste administratorrettighetene
Fjern de faste lokale administratorrettighetene først, før det finnes en eneste hevingspolicy. Team som snur rekkefølgen, skriver policyer for et miljø der ingen trenger dem ennå, og oppdager i fase tre hvilke de faktisk trengte.
Fase to: Standardpolicyer på testendepunkter
Bruk grunnpolicyene dine på et lite utvalg endepunkter, og la dem kjøre. Det er her avvisningsreglene viser sin verdi, og her du finner ut om varighetsgrensene stemmer med hvordan folk faktisk jobber.
Kombiner denne fasen med CapaOne Application Manager hvis rutinemessige installasjoner og oppdateringer står for mye av henvendelsene. Programmer som rulles ut stille via policy, utløser aldri en forespørsel om heving, og det fjerner en hel kategori av arbeidet du er i ferd med å legge om.
Fase tre: Skaler avdeling for avdeling
Avdelinger er mer forskjellige enn noen forventer. Økonomiavdelingen og utviklingsavdelingen trenger ikke de samme unntakene, og å finne det ut i én avdeling koster en samtale, mens å finne det ut i hele enhetsparken koster en uke.
Ett tilfelle faller utenfor mønsteret: bærbare PC-er som forlater nettverket. Policyer kan tillate bufrede beslutninger for oppgaver med lav risiko og strenge varigheter, og plattformen legger loggoppføringer i kø for synkronisering når endepunktet er tilkoblet igjen. Bestem bevisst hvilke oppgaver som regnes som lavrisiko, i stedet for å la standardinnstillingen bestemme for deg – en bruker på toget finner denne innstillingen før IT-avdelingen gjør det.
Fase fire: Sett i drift med rapportering
Utrullingen er ferdig når rapporteringen starter. Når du gjennomgår hvilke policyer som slår inn, hvilke varigheter som løper til grensen, og hvor ofte noen tyr til break-glass-veien, blir utrullingen en fast driftsrytme i stedet for et prosjekt med en sluttdato.
Dette kan du vise en revisor etterpå
Hver heving registrerer brukeren, endepunktet, navnet på den kjørbare filen og programbanen, tidspunktet, varigheten og utfallet. Oppføringene kan eksporteres for gjennomgang, og det gjør minste privilegium fra en uttalt intensjon til noe du kan dokumentere på forespørsel.
Dokumentasjonen støtter tilgangsstyring i tråd med NIS2: Den lar deg vise konsekvente kontroller av rettigheter og en sporbar logg over hver eskalering, og det er den koblingen oversikten vår over styring av administratorrettigheter på endepunkter beskriver i sin helhet. Siden vår om sikkerhet og etterlevelse viser hvordan revisjonssporet passer sammen med rapportering om patching og konfigurasjon fra CapaOne Security Monitor.
For virksomheter som bruker Microsoft Entra ID, retter policyene seg direkte mot eksisterende grupper, slik at strukturen du allerede vedlikeholder, blir strukturen som styrer hevingen. CapaOne kjører som en komplett plattform på egen hånd, og for team som har Microsoft Intune på plass, fungerer den side om side med eksisterende policyer for samsvar og konfigurasjon uten å duplisere dem.
Minste privilegium sluttet et sted i løpet av de siste to årene å være en milepæl for modenhet og ble grunnlinjen revisorer måler deg mot – et skifte vi ser nærmere på i innlegget vårt om styring av privilegert tilgang. Virksomhetene som håndterer det godt, er ikke de med de strengeste policyene. Det er de som bestemte hva som skulle avvises, hvor lenge det skulle tillates, og hvem som kan overstyre, før det første endepunktet ble endret.
Se hvordan heving av rettigheter fungerer i et levende miljø – book en demo, eller start en gratis prøveperiode og kjør den første policyen mot dine egne endepunkter.