Ta med ingeniørene dine, ikke kontoene

En revisjonsspors-gjennomgang, tre måneder etter igangkjøring. Anleggseierens security-operations-team rekonstruerer en serie konfigurasjonsendringer gjort på en turbinkontroller i løpet av forrige uke. Endringene var autorisert — de vises i endringshåndterings-systemet, godkjent, med klar ingeniør-rettferdiggjørelse. Sesjonen ble registrert av den sikre fjerntilgangs-megleren; skjermopptaket viser hva som ble gjort.

Det teamet ikke kan rekonstruere er hvem som gjorde det.

Sesjonen ble logget inn ved hjelp av en konto kalt svc_oem_eng. Kontoen deles på tvers av produsentens service-organisasjon — kanskje åtte navngitte ingeniører har tilgang til passordet, distribuert via produsentens egen interne legitimasjons-håndtering. Sesjonsopptaket viser skjermene, men viser ikke hvilken av de åtte ingeniørene som var ved tastaturet. Endringshåndterings-ticket-en lister «produsentens service-team» som aktøren. Revisjonssporet, i den strenge forstanden anleggseierens samsvars-funksjon trenger, eksisterer ikke.

Dette er identitets-modellen produsenten brakte til prosjektet. Perfekt normal i deres egen interne drift, perfekt kompatibel med måten service-organisasjonen alltid har jobbet på, perfekt utilstrekkelig for et EU-finansiert prosjekt under NIS2 .

Anleggseierens forventning er enkel. Hver handling mot et OT-aktivum må kunne tilskrives en navngitt individuell person, autentisert gjennom anleggseierens identitets-infrastruktur, autorisert gjennom anleggseierens privileged access management-prosess, revidert under anleggseierens loggings-disiplin. Produsentens ingeniører tar ikke med sine egne identiteter inn i prosjektet; de mottar identiteter fra anleggseieren. Tjeneste-kontoer for applikasjon-til-applikasjon-kommunikasjon eksisterer, men de håndteres og roteres av anleggseierens secret store, ikke holdes som statisk legitimasjon i produsentens verktøy. Hardkodede passord i firmware er ikke konfigurasjons-valg; de er leverings-defekter.

Prinsippet er navngitt-person-tilgang, tidsbegrenset, revidert per person, med separasjon mellom det menneskelige identitets-overflaten og maskin-til-maskin-identitets-overflaten. Snarveien sikkerhets-fellesskapet iblant bruker er zero trust; det underliggende ingeniørarbeidet går forut for etiketten med et tiår og er nå mainstream i seriøse anleggseier-organisasjoner.

Hva anleggseieren leverer

Identitets-infrastrukturen produsentens ingeniører vil integreres inn i er en definert stakk.

Anleggseieren driver en bedrifts-identitets- og tilgangshåndterings-plattform — typisk bygd rundt Microsoft Entra ID (plattformen tidligere kjent som Azure Active Directory), Okta, Ping Identity, eller en lignende bedrifts-leverandør — og en privileged access management-plattform — typisk CyberArk, BeyondTrust, Delinea, eller HashiCorp Vault avhengig av anleggseierens preferanse. Disse plattformene håndterer bruker-identiteter, gruppe-medlemskap, autentiserings-faktorer, sesjons-megling for privilegert tilgang, og revisjons-logger for alle autentiserings- og autoriserings-hendelser.

Produsentens ingeniører mottar identiteter i denne infrastrukturen. Hver ingeniør har en navngitt konto: ikke svc_oem_eng, men en personlig identifikator — Wei Chen, Maria Andersson, Hiroshi Tanaka. Kontoen klargjøres gjennom en dokumentert onboarding-prosess som inkluderer bakgrunnssjekks-fullføring, opplæring på anleggseierens prosedyrer, og bekreftelse av anleggseierens akseptabel-bruk-policy. Multi-faktor-autentisering konfigureres gjennom anleggseierens MFA-infrastruktur — telefon-app, maskinvare-token, FIDO2-nøkkel — ikke gjennom produsentens.

Kontoen har en definert gyldighets-periode. Den eksisterer ikke i det uendelige. Standard-utløp er slutten av ingeniørens sertifisering på utstyret, eller slutten av deres ansettelse hos produsenten, eller en spesifikk kalenderdato — den som kommer først. Fornyelse er en bevisst handling, som krever bekreftelse på at ingeniøren fortsatt er sertifisert og fortsatt krever tilgang.

For privilegert tilgang — tilgangen som tillater faktiske endringer på kontrollerne og SCADA-en, snarere enn bare-lese-observasjon — autentiserer ingeniøren gjennom privileged access management-plattformen, som megler sesjons-tilgang til spesifikke mål for spesifikke varigheter under spesifikke autoriteter. Stående privilegerte kontoer på mål-systemene eksisterer ikke; ingeniørens privilegerte tilgang etableres når den trengs og tilbakekalles når den er ferdig, med den formidlede sesjons-modellen beskrevet tidligere i serien .

IEC 62443-3-3 organiserer kravene for identifikasjon og autentisering under foundational requirement 1 (identification and authentication control), med de komponentnivå-kravene som vises i 62443-4-2 under samme nummerering. Anleggseierens infrastruktur er designet for å møte disse kravene ved SL-T 3 eller over; produsentens utstyr er forventet å være i stand til å integreres med den infrastrukturen snarere enn å erstatte den.

Hvorfor federering ikke løser dette

Et vanlig produsent-forslag på dette punktet i diskusjonen er federering — at ingeniørene fortsetter å autentisere mot produsentens eget Active Directory eller identitets-leverandør, med tillit etablert mellom produsentens IDP og anleggseierens IAM gjennom SAML eller OpenID Connect. Dette er operasjonelt enklere for produsenten; deres ingeniører fortsetter å bruke kjent legitimasjon, MFA-en deres fortsetter å fungere som utrullet, identitets-livssyklusen deres fortsetter å flyte gjennom produsentens HR-system.

For et EU-finansiert prosjekt aksepteres federering generelt ikke ved OT-grensen. Tre grunner.

For det første kan anleggseieren ikke validere produsentens identitets-praksis. De vet ikke hvordan produsenten autentiserer en ny ansatt, hvordan de håndterer en avgang, hvordan de beskytter mot legitimasjons-tyveri, hvordan MFA-en deres er konfigurert, hvordan kompromittering oppdages og responderes på. Å stole på en federert identitet er å stole på hele identitets-infrastrukturen til den federerende parten. Anleggseieren har ingen kontraktuell stilling til å revidere den infrastrukturen dypt, ingen synlighet inn i den daglige driften, ingen evne til å oppdage kompromittering i tide til å respondere.

For det andre bryter revisjonssporet ved federerings-grensen. Anleggseieren kan registrere at «en identitet fra produsentens IDP, som hevder å være Wei Chen, autentiserte og aksesserte kontrolleren». De kan ikke uavhengig verifisere at identiteten faktisk var Wei Chen, snarere enn noen som hadde kompromittert Wei Chens legitimasjon hos produsenten. Under NIS2 hendelses-rapporterings-forpliktelsene trenger anleggseieren et revisjonsspor de kan stå inne for uten avhengighet av en tredjeparts identitets-praksis.

For det tredje blir avgangs-prosessen asynkron. Når Wei Chen forlater produsenten, behandler produsentens HR-system avgangen, IDP-en fjerner etter hvert kontoen, federeringen reflekterer etter hvert fjerningen i anleggseierens IAM. Vinduet mellom Wei Chens siste dag og tilgangs-fjerning ved anleggseierens ende er operasjonelt vesentlig for enhver privilegert rolle. Federering forsterker dette vinduet; direkte klargjøring krymper det.

Det aksepterte mønsteret er direkte klargjøring: ingeniøren har en navngitt konto i anleggseierens IAM, klargjort gjennom anleggseierens onboarding, deklargjort gjennom anleggseierens avgangs-prosess, autentisert gjennom anleggseierens MFA, revidert gjennom anleggseierens logger. Produsentens egen identitets-infrastruktur er irrelevant for prosjektets tilgangs-arkitektur.

Federering kan fortsatt være akseptabelt for ikke-OT-systemer — selskaps-samarbeids-verktøy, ticket-plattformer, dokument-repositorier — der sikkerhets-grensen er mindre sensitiv og revisjons-forpliktelsene er forskjellige. OT-grensen spesifikt er der federering når sin grense.

Tjeneste-kontoer og maskin-til-maskin-identitet

Mønsteret som gjelder menneskelige ingeniører, gjelder også, i en annen form, for tjeneste-kontoer — identitetene brukt av applikasjoner, skript og maskin-til-maskin-integrasjoner.

En turbin-produsents tilstandsovervåknings-system trekker telemetri gjennom en spesifikk konto på historian-en. Et oppdaterings-utrullings-skript logger inn på kontrollerne ved hjelp av en tjeneste-konto. Et diagnose-verktøy autentiserer til SCADA-ens API. Hver av disse er en ikke-menneskelig identitet, med legitimasjon som må håndteres på en eller annen måte.

Den historiske praksisen — legitimasjon hardkodet i konfigurasjonsfiler, skript eller firmware — er ikke akseptabel. Hardkodet legitimasjon kan ikke roteres uten å redistribuere det kallende systemet, kan ikke tilbakekalles uten å bryte integrasjonen, kan ikke revideres per bruk, og ender ofte i kildekode-repositorier eller backup-arkiver ingen hadde til hensikt å beskytte. En enhet som leveres med hardkodet legitimasjon i firmwaren leverer en legitimasjon inn i anleggseierens miljø uten anleggseierens kontroll.

Forventningen er at tjeneste-kontoer håndteres av anleggseierens secret store — HashiCorp Vault, CyberArk Conjur eller lignende — med rotasjon håndtert av store-en, henting av autoriserte konsumenter ved kjøretid, og revisjon av hver henting. Applikasjoner henter legitimasjonen sin ved oppstart eller på en definert kadens, roterer den på timeplan, og persisterer den aldri utenfor store-ens beskyttede stier.

For maskin-til-maskin-tilkoblinger der høyere forsikring kreves, erstatter sertifikat-basert autentisering passord-baserte tjeneste-kontoer helt. Hver applikasjon eller enhet har et sertifikat utstedt av anleggseierens PKI (temaet for den forrige artikkelen i denne serien ), med den private nøkkelen holdt i en maskinvare-sikkerhets-modul eller ekvivalent. Autentisering er mutual TLS; sertifikatets identitet er den autoritative. Rotasjon av sertifikater erstatter rotasjon av passord. Revisjon av sertifikat-utstedelse og -bruk er en del av PKI-infrastrukturen snarere enn en separat loggings-øvelse.

Moderne maskin-identitets-rammeverk — SPIFFE og SPIRE , i økende grad sett i seriøse utrullinger — formaliserer denne tilnærmingen ved å utstede kort-levede kryptografiske identiteter til workloads og tjenester gjennom en workload identity attestation-prosess. Rammeverkene er ennå ikke universelt utrullet i OT, men retningen er klar: sertifikat-baserte maskin-identiteter, kort-levede, automatisk roterte, revidert per bruk.

En enhet som bare støtter passord-autentisering for sine tjeneste-grensesnitt er en enhet med en arkitektonisk begrensning som vil bli reist ved design-gjennomgang. Enheter som støtter sertifikat-basert autentisering, med sertifikat-enrollment-protokollene fra den kryptografiske grunnlinje-artikkelen, integreres rent inn i moderne identitets-infrastruktur.

Hva dette betyr for produsentens organisasjon

Skiftet fra team-pool-tilgang til direkte navngitt-person-tilgang har organisatoriske konsekvenser produsenten bør forutse.

De navngitte ingeniørene må avsløres på forhånd. Produsenten kan ikke operere en modell der «hvilken ingeniør som er tilgjengelig» håndterer en service-samtale; spesifikke ingeniører må identifiseres, klareres, onboardes og trenes på anleggseierens prosedyrer før de kan aksessere prosjektets systemer. For en stor service-organisasjon betyr dette typisk en utpekt pool av sertifiserte ingeniører for prosjektet — kanskje et dusin mennesker, kanskje færre — snarere enn en åpen roster.

Pool-en må vedlikeholdes. Når en ingeniør forlater produsenten, må anleggseieren varsles raskt. Når en ny ingeniør legges til pool-en, kjører onboarding-prosessen igjen. Når en ingeniørs sertifisering på et stykke utstyr utløper, suspenderes tilgangen deres til re-sertifisering. Produsentens HR- og sertifiserings-systemer må grensesnitte med anleggseierens identitets-livssyklus — enten gjennom formell integrasjon eller gjennom pålitelig manuell varsling — og ansvaret for å holde pool-en aktuell hviler på produsenten, ikke anleggseieren.

Produsentens interne praksis med å bruke delte tjeneste-kontoer for internt verktøy overfører ikke til anleggseierens miljø. Inne i produsentens egne systemer kan delte kontoer være effektive og operasjonelt akseptable. Inne i anleggseierens OT-miljø er de det ikke. Produsentens ingeniører vil i praksis ha to identitets-overflater: deres interne produsent-identitet for deres egne verktøy og systemer, og deres prosjekt-spesifikke navngitte identitet for enhver tilgang til de utrullete aktivene. Å opprettholde separasjonen mellom disse to overflatene er en del av service-organisasjonens disiplin snarere enn en engangs-oppsett-oppgave.

Denne dualiteten er ikke unik for EU-finansierte prosjekter; det er retningen industriell identitets-håndtering har beveget seg på tvers av global industri det siste tiåret. EU-regulering har akselerert og kodifisert praksisen, men det underliggende ingeniørarbeidet — navngitt-person-tilgang, tidsbegrenset legitimasjon, sertifikat-basert maskin-til-maskin-autentisering — er mainstream snarere enn eksotisk.

På forslagsstadiet

Et produsents bud som adresserer identitet og tilgang — som foreslår en navngitt pool av sertifiserte ingeniører for prosjektet, beskriver hvordan deres legitimasjon vil bli onboardet inn i anleggseierens IAM, forplikter seg til sertifikat-basert autentisering for utstyrets tjeneste-grensesnitt, og demonstrerer at ingen hardkodet legitimasjon er til stede i levert firmware — er et bud som har forutsett samtalen. Samtalen som følger er operasjonell: hvordan onboarding-arbeidsflyten integreres med produsentens service-rotasjon, hva re-sertifiserings-kadensen vil være, hvordan avgangsmenn vil bli kommunisert.

Et produsents bud som foreslår «sikker VPN-tilgang for service-organisasjonen vår ved hjelp av selskaps-legitimasjonen vår», signaliserer at teamet opererer fra det forrige tiårets identitets-modell. Modellen er ikke uoverkommelig — de samme ingeniørene kan bli onboardet inn i anleggseierens IAM, det samme utstyret kan rekonfigureres for sertifikat-basert autentisering, de samme tjeneste-kontoene kan migreres til et håndtert secret store — men arbeidet med å lukke gapet må starte før kontrakts-signatur.

Den dypere observasjonen, lik den som ble gjort i den kryptografiske grunnlinje-artikkelen, er at denne disiplinen betaler seg på tvers av produsentens hele marked. Navngitt-person-tilgang, tidsbegrenset legitimasjon, sertifikat-basert autentisering, og håndterte tjeneste-kontoer er ikke EU-spesifikke krav; de er retningen hver seriøs anleggseiers identitets-infrastruktur beveger seg. En produsent som har tilpasset seg å levere inn i ett EU-finansiert prosjekt har tilpasset seg å levere inn i det neste, og inn i den øvre enden av det globale markedet mer bredt.

Den neste artikkelen plukker opp temaet identitet støtter, men ikke alene adresserer: oppdaterings-leverings-kontrakten mellom produsenten og anleggseieren, der den historiske praksisen med leverandør-pushede automatiske oppdateringer møter operatørens forventning om kontrollerte, planlagte, signerte distribusjoner som ankommer gjennom en dokumentert utgivelsesprosess.

Denne artikkelen reflekterer identitets- og tilgangshåndterings-landskapet ved publisering. Referanser til kommersielle IAM-, PAM- og secret-store-plattformer er illustrative snarere enn anbefalinger; de underliggende ingeniør-prinsippene gjelder på tvers av leverandør-valg. Hvis et sitat har råtnet eller en klausul har flyttet seg, er LinkedIn veien å flagge det på.