IT/OT-grensen: hva identitetsstyring i Entra ID kan og ikke kan gjøre for driftskontrollsystemet

Enhver leverandør som forteller deg at deres identitetsprodukt «sikrer OT-miljøet», selger noe de ikke har. Et driftskontrollsystem eller et prosesskontrollsystem har sin egen brukerdatabase, sine egne lokale kontoer, sin egen autentiseringsmekanisme — ofte flere, ofte leverandørspesifikke, ofte uten kobling til noen katalogtjeneste i det hele tatt. Kraftberedskapsforskriften § 7-6 forbyr til og med personlig eid utstyr i driftskontrollsystemet og krever trådbundet datakommunikasjon i driftssentral og datarom. Dette er bevisst isolerte miljøer.

Entra Logic styrer Microsoft Entra ID. Det er alt. Det har ingen funksjon inne i et SCADA-system, ingen agent på en PLS, ingen rolle i et sikkerhetssystem.

Så hvorfor er identitetsstyring i IT-domenet likevel en av de mest kostnadseffektive tiltakene et energiselskap kan gjøre for OT-sikkerheten sin?

Fordi ingen angriper OT-miljøet direkte. De angriper veien inn.

Veien inn er alltid en identitet i IT-domenet

Se på hvordan et kompromiss av OT faktisk forløper i praksis, ikke i trusselmodeller.

En ingeniør har en arbeidsstasjon i kontordomenet, autentisert mot Entra ID. Fra den arbeidsstasjonen logger vedkommende inn på en jump host eller et hoppsteg i DMZ mellom IT og OT. Derfra åpnes en økt mot ingeniørarbeidsstasjonen i prosesskontrollnettet. Leverandøren av turbinstyringen har fjernaksess gjennom samme sti, ofte via en VPN- eller ZTNA-løsning som autentiserer mot — igjen — Entra ID, eller mot en identitetsleverandør som føderer med den.

Hver eneste av disse overgangene starter med en identitet som lever i IT-domenet. Colonial Pipeline i mai 2021 er lærebokeksempelet: en gammel VPN-profil med et passord fra en lekket liste, uten multifaktorautentisering. Angriperne rørte ikke OT-systemene — selskapet stengte selv ned rørledningen fordi det ikke kunne fastslå hvor langt kompromitteringen gikk. Konsekvensen for driften var total, og inngangen var én konto ingen hadde ryddet opp i.

Norsk Hydro i mars 2019 følger samme mønster på et annet nivå: inngangen var et e-postvedlegg, men det som gjorde angrepet katastrofalt, var eskaleringen til administrative rettigheter og kontrollen over domenekontrollerne. Kostnaden er anslått til om lag 800 millioner kroner.

Poenget er ikke at IT-identitetsstyring beskytter OT direkte. Poenget er at kvaliteten på IT-identitetsstyringen bestemmer hvor lett det er å nå fram til den sonen der OT-tilgangen gis.

Hva standardene faktisk sier om identitet i OT

IEC 62443-3-3 definerer sju foundational requirements for systemsikkerhet i industrielle automatiserings- og kontrollsystemer. De to første handler om identitet:

• FR 1 – Identification and Authentication Control (IAC): «Control access to the IACS by identifying and authenticating all users (humans, processes, and devices).»
• FR 2 – Use Control (UC): «Enforce the privileges of authenticated users to perform actions on the IACS.»

Legg merke til at FR 1 omfatter mennesker, prosesser og enheter. Det er tre populasjoner som i praksis håndteres av tre helt ulike mekanismer, og der de to siste sjelden har noen eier i organisasjonen.

IEC 62443-2-1:2024 dekker sikkerhetsprogramkrav for anleggseiere — altså styringssystemsiden. For norsk petroleumsvirksomhet er bransjeforankringen Offshore Norge-retningslinje 104, tidligere kjent som NOG 104, nå ON 104, som i revisjon 7 (2026) bærer tittelen Recommended guidelines on cyber security baseline requirements for Operational Technology systems. Innretningsforskriften § 34a om kontroll- og overvåkingssystem viser i veiledningen til nettopp denne retningslinjen.

Ingen av disse standardene sier at OT-identiteter skal ligge i en skykatalog. De sier at det skal finnes kontroll på hvem som autentiseres og hva de har lov til. Det er en styringsutfordring før det er en teknologiutfordring.

De fire koblingene mellom Entra ID og OT-risiko

Konkret er det fire steder der tilstanden i Entra ID direkte påvirker OT-risikoen:

1. Kontoen til personen som har OT-tilgang. Alle som har brukertilgang i driftskontrollsystemet har også en vanlig ansattidentitet. Kompromitteres den, kompromitteres utgangspunktet for lateral bevegelse mot OT. Kraftberedskapsforskriften § 7-4 krever kontrollordninger for tildeling, endring og sletting av brukertilgang til driftskontrollsystemet — men signalet om at en person har sluttet eller byttet rolle, oppstår i HR og materialiserer seg først i IT-identitetsplattformen.

2. Gruppemedlemskapet som gir fjerntilgang. I moderne arkitekturer er tilgang til hoppsteget eller til ZTNA-tjenesten styrt av en sikkerhetsgruppe i Entra ID og en betinget tilgangspolicy. Hvem som er medlem av den gruppen, er dermed hvem som kan nå OT-sonen. Feil i gruppemedlemskap er ikke et administrativt slurv — det er en barrieresvikt i styringsforskriftens forstand.

3. Leverandøridentiteten. Utstyrsleverandøren som skal feilsøke på en omformer klokken to om natten, får som regel en gjestekonto eller en kontraktørkonto. Kraftberedskapsforskriften § 7-10 krever en oppdatert liste over godkjente brukere for ekstern tilkobling. Den listen og den faktiske gjestepopulasjonen i Entra ID er i de fleste virksomheter to ulike ting.

4. Enheten. Ingeniørarbeidsstasjonen og den bærbare maskinen som brukes til å nå OT-sonen, er som regel administrert gjennom Intune og registrert i Entra ID. En foreldreløs enhet uten eier, eller en Autopilot-registrering ingen kan redegjøre for, er en enhet som fortsatt kan oppfylle en betinget tilgangspolicy som krever «compliant device».

Hva som faktisk lar seg gjøre — og hva som ikke gjør det

Lar seg gjøre med Entra Logic:

• Ha en kontinuerlig oppdatert, søkbar oversikt over hvilke identiteter, grupper og enheter som eksisterer, på tvers av tenanter — og dermed kunne svare presist på hvem som per nå er medlem av gruppene som styrer OT-fjerntilgang.
• Sørge for at endringer i disse gruppene bare kan skje gjennom en godkjent, logget ordre, slik at ingen kan legge seg selv eller andre inn i en OT-tilgangsgruppe uten at det er en beslutning med navn på.
• Fjerne stående administratorrettigheter fra menneskene i IT-organisasjonen, slik at en kompromittert IT-konto ikke er en snarvei til å manipulere tilgangsgrunnlaget.
• Fange opp foreldreløse enheter og ueide registreringer kontinuerlig i stedet for som en kvartalsvis opprydningsjobb.
• Levere det strukturerte, tidsstemplede datagrunnlaget som en årlig gjennomgang etter § 7-4 og en barrierevurdering etter styringsforskriften § 5 faktisk trenger.

Lar seg ikke gjøre — verken med Entra Logic eller noe annet identitetsprodukt i IT-domenet:

• Styre lokale kontoer i SCADA, DCS eller sikkerhetssystemer.
• Erstatte segmentering, soner og conduits etter IEC 62443.
• Håndtere maskin- eller prosessidentiteter i OT-nettet.
• Gi noen form for kontroll over utstyr eller systemer som ikke er representert i Entra ID.

En leverandør som ikke er tydelig på den andre listen, har heller ikke tenkt gjennom den første.

Den praktiske anbefalingen

Behandle IT-identitetsplattformen som en barriere i styringsforskriftens forstand — altså som noe som skal identifiseres, tilordnes en ytelse og etterprøves — snarere enn som en administrativ tjeneste. Konkret:

1. Kartlegg hvilke Entra-grupper og betingede tilgangspolicyer som faktisk kontrollerer stier inn mot OT-sonen. I de fleste virksomheter er dette mellom tre og ti objekter, og de er sjelden dokumentert som kritiske.

2. Sørg for at endringer i nettopp disse objektene aldri kan skje uten godkjenning og logg.

3. Etabler en prosess der en avsluttet ansettelse eller et rolleskifte i IT-identitetsplattformen genererer et sporbart signal til dem som forvalter OT-tilgangene — og der signalet kan etterprøves.

4. Slutt å oppgi «vi har MFA» som svar på spørsmålet om OT-tilgangskontroll. Spørsmålet er hvem som står i gruppen.

Kilder

• Kraftberedskapsforskriften (FOR-2012-12-07-1157), §§ 7-4, 7-6, 7-10 — https://lovdata.no/dokument/SF/forskrift/2012-12-07-1157
• Havtil, innretningsforskriften § 34a (kontroll- og overvåkingssystem) — https://www.havtil.no/en/regulations/all-acts/the-facilities-regulations3/V/34a/
• Havtil, styringsforskriften (§ 5 barrierer, § 6 styring) — https://www.havtil.no/globalassets/regelverk/gjeldende-regelverk-2022/styringsforskriften_n.pdf
• Offshore Norge, retningslinjeoversikt (ON 104) — https://www.offshorenorge.no/en/faginnhold/guidelines/guidelines/
• IEC 62443-2-1:2024, Security program requirements for IACS asset owners — https://webstore.iec.ch/en/publication/62883
• Bloomberg om Colonial Pipeline — https://www.bloomberg.com/news/articles/2021-06-04/hackers-breached-colonial-pipeline-using-compromised-password
• Norsk Hydro om cyberangrepet — https://www.hydro.com/en/global/media/on-the-agenda/cyber-attack/