Fire navngitte krav i to mye brukte rammeverk dytter virksomheter mot det samme: strammere kontroll over hvem som har privilegert tilgang, hvordan en tildeling skjer, og hvilket spor den etterlater. Å fjerne faste lokale administratorrettigheter og erstatte dem med policybasert heving av rettigheter er én praktisk måte å gjennomføre det på endepunktene – et mønster, ikke et sitat fra selve kontrollene.
Det skillet er hele poenget med denne artikkelen. Kontrollene overlapper, men de er ikke utskiftbare, og en kobling som behandler dem som ett krav, overlever ikke en samtale med en revisor.
Å vite hvilken kontroll en revisor kommer til å vise til, betyr noe av en praktisk grunn. Det avgjør hvilken dokumentasjon revisoren ber om – og en kobling som er laget på forhånd, gjør den forespørselen til et oppslag i stedet for et prosjekt.
Dette sier hver kontroll faktisk
ISO 27001:2022 vedlegg A 8.2, Privileged Access Rights, sier at en virksomhet bør begrense og styre tildelingen og bruken av privilegerte tilgangsrettigheter. I 2013-revisjonen var den tilsvarende kontrollen A.9.2.3, og det er derfor eldre koblingsdokumenter viser til en annen referanse for den samme ideen.
CIS Critical Security Controls fordeler det samme området på tre kontroller, og hver av dem er bredere enn den delen styring av administratorrettigheter på endepunkter berører.
Safeguard 5.4, under Control 5 (Account Management), begrenser administratorrettigheter til dedikerte administratorkontoer, mens rutinearbeid gjøres fra en konto uten privilegier. Legg merke til hva den foreskriver: separate kontoer. Null faste administratorrettigheter med just-in-time-heving tjener det samme målet – rutineaktivitet forblir uten privilegier – men det er en annen gjennomføring, ikke den safeguarden beskriver.
Control 6 (Access Control Management) dekker prosessene for å gi og tilbakekalle tilgang, flerfaktorautentisering for administrativ tilgang, sentralisert tilgangskontroll og rollebasert tilgang. Policyer for heving av rettigheter på endepunktene adresserer delene om å gi og tilbakekalle tilgang og den rollebaserte avgrensningen. De adresserer ikke resten.
Control 8 (Audit Log Management) dekker et helt loggprogram: innsamling, lagring, tidssynkronisering, sentralisering, lagringstid og gjennomgang. Logger over heving av rettigheter er én kilde til det programmet.
Lest sammen ligger tre operative spørsmål under alle fire referansene: hvem som har rettigheter, hvordan en tildeling skjer, og hvilket spor den etterlater. Et verktøy som besvarer ett av dem og ikke de andre, etterlater et hull som blir synlig i det øyeblikket noen ber om dokumentasjon – men å besvare alle tre er ikke det samme som å oppfylle kontrollene, og den forskjellen er verdt å si rett ut.
For norske virksomheter er NSMs grunnprinsipper for IKT-sikkerhet (versjon 2.1) et naturlig referansepunkt i tillegg. Prinsipp 2.6, «Ha kontroll på identiteter og tilganger», sier at retningslinjene for tilgangskontroll bør følge minste privilegiums prinsipp (tiltak 2.6.1), og tiltak 2.6.4 anbefaler å ikke tildele administratorrettigheter til sluttbrukere. I likhet med CIS 5.4 beskriver 2.6.4 to separate kontoer for spesialbrukere som faktisk trenger forhøyede rettigheter, så forholdet er det samme: samme mål, en annen vei dit. Grunnprinsippene er anbefalinger som NSM sier at hver virksomhet må vurdere og tilpasse, ikke et femte krav.
Slik kobler du kontrollene for minste privilegium til kravene
Begrense tildelingen
CapaOne Privilege Manager, en del av CapaOne-plattformen for endepunktadministrasjon, fjerner faste lokale administratorrettigheter og gir heving av rettigheter etter policy, for et definert omfang og en definert varighet. Det adresserer direkte tildelingsdelen av A.8.2, som ber virksomheter begrense og styre hvordan de tildeler og bruker privilegerte rettigheter. Mot Safeguard 5.4 er forholdet støttende snarere enn én-til-én: Brukernes rutineaktivitet forblir uten privilegier, og det er målet, men 5.4 beskriver uttrykkelig dedikerte administratorkontoer, og dette er en annen vei til samme mål.
Etterprøvbarheten betyr like mye som selve kontrollen. En håndhevet grunnlinje gjelder kontinuerlig, og en revisor kan teste den på stedet – en annen type dokumentasjon enn et dokument som påstår at det samme er sant.
Styre hvordan tilgang gis
Policybasert heving av rettigheter mot Entra ID-grupper betyr at tildelinger følger en regel som finnes før forespørselen, ikke en beslutning tatt under press. Avvisningsregler dekker det motsatte tilfellet – verktøyene ingen skal kunne heve, uansett hvem som spør.
Mot Control 6 støtter dette praksisen for å gi og tilbakekalle tilgang og den rollebaserte avgrensningen, siden policyene retter seg mot grupper du allerede vedlikeholder. Sentralisert tilgangskontroll og flerfaktorautentisering for administrativ tilgang ligger andre steder i IT-miljøet ditt; kontrollen krever også disse.
En break-glass-vei håndterer det ingen policy forutså, og den holdes bevisst smal. Begge rammeverkene forventer at unntak finnes; det de ikke tolererer, er unntak uten spor.
Registrere bruken
Hver heving registrerer brukeren, endepunktet, navnet på den kjørbare filen og programbanen, tidspunktet, varigheten og utfallet, og oppføringene kan eksporteres for gjennomgang. Det gir den sporbarheten A.8.2 forventer, og det bidrar med hendelser om privilegert tilgang til den bredere praksisen for revisjonslogger som Control 8 krever. Det erstatter ikke resten av den praksisen – innsamling fra andre IT-eiendeler, sentralisering, lagringstider og planlagt gjennomgang er fortsatt ditt ansvar. Hvilket felt som besvarer hvilket spørsmål – og hvilket spørsmål policysettet besvarer i stedet for loggen – er temaet i innlegget vårt om revisjonsbevis for privilegert tilgang.
Der koblingen slutter å være ren
Tre forbehold, fordi en kobling som presenteres som komplett, er den typen påstand som faller sammen når noen stiller spørsmål ved den.
Verktøy dekker håndheving og dokumentasjon, ikke prosess. Dokumentert godkjenning og periodisk gjennomgang er fortsatt virksomhetens ansvar, og ingen plattform leverer dem. Om den som gjennomgår, bør være uavhengig av den som gir tilgangen, er et eget styringsspørsmål – et argument om funksjonsdeling snarere enn noe disse fire referansene avgjør.
Omfanget er smalere enn hver av kontrollene som er nevnt her. A.8.2 dekker privilegert tilgang på tvers av infrastruktur, applikasjoner og data. Control 6 dekker tilgangsstyring i hele virksomheten. Control 8 dekker logging på tvers av alle IT-eiendeler. Styring av administratorrettigheter på endepunkter adresserer endepunktet – en betydelig del av hver kontrolls område, men langt fra hele området for noen av dem.
Sertifisering er et resultat virksomheten oppnår, ikke en produktfunksjon. Verktøy hjelper deg å arbeide i tråd med disse kontrollene og produserer dokumentasjonen en revisor ber om. Det kan ikke levere en sertifisering, og en leverandør som antyder noe annet, beskriver noe den ikke har kontroll over.
Dette endrer seg i praksis
Team som kobler privilegiepraksisen sin til navngitte kontroller før en revisjon, opplever ofte at revisjonen blir udramatisk, av en grunn som har lite med koblingsdokumentet å gjøre. Øvelsen tvinger frem en beslutning om hvem som gjennomgår hva, og det er den beslutningen en revisor egentlig tester.
Oversikten vår over styring av administratorrettigheter på endepunkter viser hvordan den samme dokumentasjonen støtter tilgangsstyring i tråd med NIS2, og innlegget vårt om styring av privilegert tilgang tar for seg hvem som eier praksisen når minste privilegium blir standarden. For den operative siden – hva du bør bestemme først, og i hvilken rekkefølge du ruller det ut – se just-in-time-rettigheter i praksis.
CapaOne er utviklet i Danmark og driftet i EU, uten overføring av endepunktdata til amerikansk jurisdiksjon, og det betyr noe når en revisor spør hvor selve dokumentasjonen ligger. Siden vår om sikkerhet og etterlevelse dekker dette sammen med rapportering om patching og konfigurasjon.
Se hvordan loggen passer til ditt eget kontrollsett – book en demo av CapaOne-plattformen for endepunktadministrasjon.
