Slik kommer du i gang med PAM i en mellomstor virksomhet

Slik får du privilegert tilgangsstyring i drift i en mellomstor virksomhet, i den rekkefølgen som holder produksjonen i gang.

Jeg er sjefsarkitekt på en av verdens største Idira (CyberArk)-løsninger, og jeg leder privilegert tilgang i FM CyberSecurity. På den løsningen og på de norske utrullingene jeg har kjørt siden, er det alltid det samme som avgjør. Ikke produktet. Hvilke kontoer du tar inn først, og hva du utsetter til fase to. Mellomstor betyr her et par hundre ansatte, ett driftsteam og ingen som har identitet som hovedjobb.

Vi bygger på Idira (CyberArk). Palo Alto Networks ga CyberArk navnet Idira 12. mai 2026, så vaulten, rotasjonsmotoren og sesjonsproxyen du kanskje kjenner fra før har fått nytt navn. Hva navnebyttet endrer, og hva det ikke endrer, tok vi for oss i en egen artikkel. Punkt 1 til 8 under er beslutninger på programnivå, og de holder uansett hvilken plattform du lander på.

1. Tell opp de privilegerte kontoene før du velger noe som helst

Ingen vet hvor mange privilegerte kontoer de har, og tallet er alltid høyere enn anslaget. Kjør oppdagelse mot Active Directory, lokale administratorkontoer på Windows- og Linux-servere og bærbare, hypervisor- og backup-konsollene, nettverksutstyret og break-glass-innloggingene i skyleietakeren. Legg resultatet i ett regneark med fire kolonner: konto, system, hva den kan gjøre, hvem som er ansvarlig. Kolonnen for ansvarlig er den som kommer tom tilbake, og det hullet er funnet du handler på.

2. Lås inn kontoene som kan ta hele huset, først

Begynn med credentials som gjør en kompromittert bærbar om til en kompromittert virksomhet: domeneadministratorer, administratorkontoene på hypervisor og backup, og break-glass-innloggingene i skyleietakeren. Lås dem inn, sett rotasjon på plan, og send tilgangen gjennom sesjonsisolering slik at passordet aldri havner på maskinen til administratoren selv. Idira Privileged Access Manager gjør innlåsing, rotasjon, isolering og opptak i en flyt. Ti til tretti kontoer er et normalt antall her. Dette er den minste endringen med størst risikoreduksjon i hele programmet.

3. Ta bort faste lokale administratorrettigheter på endepunktene

Lokale administratorrettigheter på bærbare er den korteste veien fra et phishing-klikk til domenet ditt. NSMs inntrengingstestere finner det samme igjen og igjen i norske systemer: passord som er lette å gjette eller gjenbrukt, og administratorpassord som ligger på filområder vanlige brukere kan lese (Ti sårbarheter i norske IKT-systemer, NSM 2023). Fjern faste lokale administratorrettigheter fra standardoppsettet på klienten, og gi tilbake de konkrete hevingene folk trenger, per applikasjon, med Idira Endpoint Privilege Manager. Kjør to uker i loggmodus før du håndhever, slik at du hever det virksomheten bruker og ikke det policyen antar.

4. Ta inn tjenestekontoene sammen med avhengighetene, aldri før

En tjenestekonto er ett sett credentials pluss hvert eneste sted de brukes. Samme konto kan kjøre en Windows-tjeneste, en planlagt oppgave, en IIS-applikasjonspool og en SQL Agent-jobb. Idira kaller disse bruksstedene avhengige kontoer, eller usages, og rotasjonsmotoren oppdaterer dem samtidig som den bytter passordet. Kartlegg avhengighetene, ta så inn kontoen, og roter til slutt. Hopper du over kartleggingen, går rotasjonen fint mens batch-jobben klokken 02:00 feiler, og da får PAM skylda. Credentials som ligger inne i applikasjonskode hører hjemme i secrets-håndtering, ikke i en vault-flyt laget for mennesker.

5. Skriv ned MVP-en som tall, ikke adjektiver

En minimumsversjon av PAM er en opptelling, ikke en følelse. Min har seks linjer:

• Alle domeneadministratorer og tier-0-infrastrukturkontoer innlåst og i rotasjon, der tier-0 er systemene som tar med seg alt annet i fallet.
• Faste lokale administratorrettigheter borte fra standardoppsettet på klienten.
• De tjue tjenestekontoene med høyest risiko tatt inn, med avhengighetene kartlagt.
• Sesjonsisolering og opptak på for hvert tier-0-mål.
• En break-glass-prosedyre med en datert testlogg bak seg.
• Logger fra privilegerte sesjoner som lander i SIEM-en.

Den lange halen av applikasjonskontoer og leverandørtilgang er fase to, og det samme er zero standing privilege, som Idira lisensierer per plattformnivå. På utrullingene jeg har kjørt lander den MVP-en på rundt 90 dager når de kontoansvarlige svarer på e-post, og sklir ut når de ikke gjør det.

6. Koble opp de tre systemene som avgjør om folk tar det i bruk

Tre integrasjoner avgjør om administratorene bruker vaulten eller går utenom: katalogtjenesten, SIEM-en og saksbehandlingssystemet. Vaulten bør autentisere folk mot katalogen og totrinnsløsningen du allerede kjører, slik at ingen må huske et passord til. Logger fra privilegerte sesjoner bør sendes til SIEM-en i uke en, ikke i uka revisor spør. Tilgangsforespørsler bør komme dit endringsprosessen allerede bor, slik at hver privilegerte sesjon henger sammen med et endringsnummer. Alt annet kan vente et kvartal.

7. Bestem hva opptakene skal bevise

Sesjonsopptak finnes for å svare på ett spørsmål: hvem brukte hvilken privilegert konto, på hvilket system, og hva gjorde de der. Slå på fullt opptak for tier-0-mål og for leverandørsesjoner først, og hold kommandologging på resten. Bli enig om lagringstiden med den som er ansvarlig for dokumentasjonen til ISO 27001 eller NIS2 før du konfigurerer, for lagringstid koster ingenting å sette dag en og mye å endre dag 400. Så lar du noen åpne et tilfeldig opptak en gang i måneden. Et opptak ingen noen gang har sett på er lagring, ikke et tiltak.

8. Sett navn på den som eier det mandagen etter produksjonssetting

PAM-programmer ryker i år to, ikke i måned tre, og de ryker fordi ingen eier arbeidet etter produksjonssetting. Det arbeidet er konkret: ta inn nye kontoer etter hvert som systemer bygges, vedlikeholde policy, teste break-glass, og kjøre gjennomgangene som fanger opp at rettigheter sklir ut. Sett et navn og et timetall per uke på det før du signerer noe. Finnes ikke navnet internt, kjøp den daglige driften. Det er en av leveransemodellene i identitetspraksisen vår, ved siden av prosjektleveranse og en konsulent som sitter i teamet ditt.

Fallgruvene som stopper PAM-prosjekter

Dette er de som går igjen, og alle er mulige å unngå.

• Kartlegging av tjenestekontoer tar lengre tid enn resten av prosjektet. Selve skanningen er ferdig på dager. Å finne et menneske som vedkjenner seg hver konto tar uker. Sett en frist: publiser listen, gi de ansvarlige en dato, og tolk taushet som aksept for at kontoen deaktiveres.
• Rotasjon knekker planlagte jobber. Roter en applikasjonsgruppe om gangen, i et vedlikeholdsvindu, med forrige passord tilgjengelig for rulling tilbake. To rene vinduer gir mer tillit enn en full rotasjon som feiler en gang.
• Innlåsing av kontoer ingen eier. En eierløs konto i en vault er fortsatt eierløs, og nå har du dokumentasjon på at du visste det. Deaktiver den, eller sett en ansvarlig på den. Ikke lås den inn for å få et tall på et dashbord til å stige.
• Break-glass som aldri er testet. Test den to ganger i året med vaulten bevisst utilgjengelig, og skriv ned hvem som var i rommet. En utestet nødvei er en plan, ikke et tiltak.
• Opptak av alt fra dag en. Fullt opptak mot alle mål fyller lagringen og gjør innlogging tregere, og da presser administratorene på for å slå det av. Start smalt, vis verdien, utvid.

Start med punkt 1 denne uka. Kartlegging endrer ingenting i produksjon, og kontolisten den gir er grunnlaget alle senere beslutninger diskuteres ut fra. Send meg listen når du har den, så sier jeg hvilke kontoer jeg ville låst inn først, og i hvilken rekkefølge.

FAQ

Hvilke selskaper i Norge leverer PAM-prosjekter på Idira (CyberArk)?

Flere norske selskaper leverer prosjekter på privilegert tilgang, og plattformen er den minste forskjellen mellom dem. Still to spørsmål i første møte: hvor mange PAM-installasjoner i produksjon har arkitekten din selv designet, og får du snakke med den personen eller med en kundeansvarlig. FM CyberSecurity bygger privilegert tilgang på Idira (CyberArk), og arkitekten på prosjektet er den samme som har skrevet dette.

Hva bør en PAM-implementering inneholde som et minimum?

Innlåsing og planlagt rotasjon av domeneadministratorer og tier-0-infrastrukturkontoer, sesjonsisolering og opptak for de målene, faste lokale administratorrettigheter fjernet fra standardoppsettet på klienten, de mest risikofylte tjenestekontoene tatt inn med avhengighetene kartlagt, en testet break-glass-prosedyre, og logger fra privilegerte sesjoner sendt til SIEM-en. Mangler noen av disse seks, har du en pilot og ikke et program.

Hvilke kontoer bør vi ta inn i PAM først?

De som kan endre alt: domeneadministratorer, administratorer på hypervisor og backup, og break-glass-innlogginger i skyleietakeren. Deretter faste lokale administratorrettigheter på endepunktene. Så tjenestekontoene, når avhengighetene er kartlagt. Applikasjons- og leverandørkontoer kommer etter det. Motsatt rekkefølge koster deg måneder og gir mindre risikoreduksjon per uke.

Hvor lang tid tar en PAM-MVP i en mellomstor virksomhet?

Rundt 90 dager på utrullingene jeg har kjørt, med de åtte punktene over som omfang. Variabelen er ikke teknologien. Den er hvor raskt de kontoansvarlige svarer, og hvor stor del av tjenestekontoene som ikke har noen ansvarlig i det hele tatt. Begge deler ser du allerede etter punkt 1, og det er derfor kartleggingen kommer først.

Må vi fjerne lokale administratorrettigheter samtidig?

Ikke i samme uke, men i samme program. Låser du inn topp-kontoene uten å røre rettighetene på endepunktene, står en åpenbar vei fortsatt åpen: en bruker klikker, angriperen arver lokal administrator på den bærbare, og derfra begynner vandringen mot domenet. Loggmodus først, håndheving etterpå, er måten å stenge den på uten kø hos brukerstøtte.

Hva innebærer den daglige PAM-driften?

Ta inn kontoer etter hvert som nye systemer dukker opp, vedlikeholde policy og plattformversjoner, teste break-glass, gå gjennom hvem som fortsatt trenger hvilke rettigheter, og se nærmere på sesjonene som ser rare ut. Budsjetter det som løpende arbeid, ikke som en hale på prosjektet. De PAM-programmene jeg har sett bli stille, ble stille fordi dette arbeidet manglet en ansvarlig.