Policy for infrastruktur-kode

1. Omfang

Infrastruktur-kode inkluderer all kode, skript og konfigurasjonsfiler som brukes til å sette opp, administrere og vedlikeholde IT-systemer, nettverk, applikasjoner og tjenester. Dette omfatter, men er ikke begrenset til:

• Konfigurasjonsstyring (Ansible, Terraform, Puppet)
• CI/CD-pipelines
• Applikasjonsoppsett og driftsautomatisering
• Infrastruktur som kode (IaC)

2. Lagring og versjonskontroll

• All kode og konfigurasjon for IT-avdelingens systemer, programvare og infrastruktur skal lagres i github.uio.no.
• github.uio.no skal ikke brukes til å lagre personopplysinger (annet enn informasjon om brukere av systemet).
• github.uio.no skal være primærkilde (master) for all kode og konfigurasjon. Eksterne repositorier kan brukes som speil når det er nødvendig.
• Om ROS eller kontinuitetsplan tilsier det så skal en sikre at jevnlige kopier av viktige repositories finnes i UiO Driftsmiljø, på jumphoster eller andre egnede maskiner.
• Ved utsjekk av lokale kopier så skal disse lagres på maskiner godkjent for disse data. F.eks. røde data kun på maskiner godkjent for røde data osv.
• Repository-struktur skal følge godkjente retningslinjer, og hvert repository skal ha definerte ansvarlige eiere.
• Endringer i kode og konfigurasjon skal som hovedregel gjøres via pull requests og godkjennes av minst én reviewer før merging.
• Hovedbranch skal inneholde produksjonsklar kode, og produksjonssettinger skal merkes med versjonstags.
• github.uio.no  er klassifisert for å kunne håndtere røde data.

3. Håndtering av hemmeligheter

• Hemmeligheter, API-nøkler, sertifikater og passord skal ikke lagres i github.uio.no, disse skal lagres i Vault eller andre godkjente løsninger.
• Hemmeligheter kan etter dokumentert vurdering lagres kryptert i github.uio.no, ansible-vault eller tilsvarende verktøy dersom det er teknisk nødvendig.
• Hemmeligheter skal flettes inn med kode og konfigurasjon ved produksjonssetting på en sikker måte, slik at de aldri lagres i klartekst i repositoriet.

4. Kodesignering og sikring av prodsetting

• All kode som prodsettes skal signeres digitalt eller på annen måte sikres mot uautoriserte endringer.
• GitHub-repositories skal ikke være eneste sikring mot utilsiktet eller ondsinnet produksjonssetting.
• Automatisk produksjonssetting skal skje via godkjente CI/CD-pipelines som sikrer at kun verifisert og signert kode settes i produksjon.
• Ved manuell produksjonsetting skal det være rutiner som sikrer at kun riktig versjon, og riktige endringer produksjonssettes.

5. Dokumentasjon og sporbarhet

• Alle endringer i kode og konfigurasjon skal dokumenteres i repositoryets endringshistorikk, inkludert hvem som gjorde endringen og hvorfor.
• Dersom det refereres til eksterne systemer (f.eks. RT), skal det sikres at nødvendig informasjon er tilgjengelig i repositoryet, også dersom eksterne systemer har begrenset lagringstid.
• Ved feil i produksjon relatert til kode eller konfigurasjon, skal en rotårsaksanalyse utføres og dokumenteres.

6. Produksjonssetting

• Alle produksjonsendringer skal skje fra versjonskontrollert kode.
• Automatiserte tester og validering skal kjøre som en del av CI/CD-pipelinen før produksjonssetting.
• Logging av automatiserte prodsettingsprosesser skal inkludere tidspunkt, versjon og ansvarlig bruker (eller servicekonto).

7. Unntak

• Unntak fra denne policyen kan bare innvilges etter skriftlig godkjenning fra IT-direktøren.
• Alle unntak skal være tidsbegrenset, og det skal dokumenteres hvorfor unntaket er nødvendig samt hvilke kompenserende tiltak som er iverksatt.

8. Forvaltning av policy

• Denne policyen forvaltes av arkitekturrådet og er vedtatt av IT-direktøren 25.03 2025
• Endringer i policyen skal fremlegges for IT-sikkerhetssjef for godkjenning og vedtas av IT-direktøren før de trer i kraft.
• Policyen skal gjennomgås og revideres minst én gang per år for å sikre at den til enhver tid er oppdatert i henhold til gjeldende praksis og krav.