Segregering av miljø

Utviklingsprosjekter benytter flere ulike miljø til ulike formål. Det er viktig å skille på disse slik at en unngår sammenblanding, datalekkasjer eller andre uønskede hendelser.

Når vi bygger løsninger setter vi ofte opp flere miljø, ofte for dev, test og prod slik at vi kan utvikle samtidig som at produkteier tester ny funksjonalitet og sluttbrukere bruker systemet i prod. Det er viktig at vi skiller mellom disse miljøene, slik at vi unngår å komme i situasjoner der endringer i ett miljø påvirker bruken av et annet.

Separate kontoer/abonnement/prosjekter per miljø gir et naturlig sikkerhetsskille fordi miljøene er isolert fra hverandre med mindre du eksplisitt oppretter tilganger mellom dem. Dette medfører noe mer overhead i administrasjon, men gir til gjengjeld sterkere isolasjon enn de andre mønstrene. For de fleste prosjekter av en viss størrelse, eller der det stilles krav til sikkerhet, er dette det anbefalte utgangspunktet. Selv i mindre prosjekter er det verdt å vurdere — kostnaden ved å separere tidlig er langt lavere enn å migrere senere når behovet oppstår.

Vanlige segregeringsmønstre

  • Separate kontoer/abonnement/prosjekter per miljø:
    • Naturlig skille med mindre en eksplisitt definerer tilganger mellom miljøene
    • Mer overhead med administrering, men gir normalt sterkere isolasjon
  • Separate ressursgrupper, namespaces eller tilsvarende logiske enheter:
    • Forenklet administrasjon innen samme toppnivå
    • Deler ofte enkelte begrensninger og tilganger på høyere nivå
  • Separate virtuelle nettverk/VPC-er:
    • Segregering på nettverksnivå
    • Krever bevisst styring av ruting, peering og åpninger for å sikre reell isolasjon
  • Separate identiteter og roller per miljø:
    • Reduserer risikoen for at tilgang i ett miljø gir utilsiktet tilgang i et annet
    • Gjør det enklere å håndheve minste privilegium og spore handlinger per miljø

Azure, AWS og Google Cloud tilbyr ulike mekanismer for dette, men prinsippene er de samme: separer der konsekvensen er høy, åpne kun eksplisitt mellom miljøer, og dokumenter hvilke unntak som finnes.

Det finnes andre tilnærminger på dette også, men uansett hvilken løsning teamet går for er det viktig å se det totale bildet med kost/nytte opp mot kravene en må forholde seg til.

Segregering for AI-systemer

For løsninger som inneholder kunstig intelligens eller maskinlæring, holder det ikke alltid å segregere kun infrastruktur. Teamet må også ha et bevisst forhold til hvordan data, modeller og utrulling holdes adskilt mellom miljøene.

Skille mellom trenings-, evaluerings- og produksjonsdata

Data brukt til trening, evaluering og produksjon bør holdes tydelig adskilt. Dette reduserer risikoen for at modeller valideres på feil grunnlag, eller at test- og utviklingsarbeid påvirker produksjonsnære data.

Skille mellom modellversjoner per miljø

Modeller, vekter og tilhørende konfigurasjon bør versjoneres og knyttes tydelig til riktig miljø. Produksjonsmodellen bør ikke kunne overskrives av eksperimentering i dev eller test.

Gradvis innføring av endringer

Når nye modeller eller større endringer skal innføres, bør teamet vurdere mekanismer som feature flags, kontrollert utrulling eller andre teknikker som gjør det mulig å teste endringer på en avgrenset måte før full produksjonssetting.

Veien videre

Sist endret 13.05.2026: Merge pull request #258 from bouvet/iso-42001-implementation (a1f6421)