Policy for infrastruktur-kode

 

Form?let med denne policyen er ? sikre en strukturert, trygg og sporbar h?ndtering av all kode og konfigurasjon relatert til IT-infrastruktur. Ved ? f?lge denne policyen legger vi til rette for:

  • Sporbarhet: Muligheten til ? f?lge alle endringer i kode og konfigurasjon, inkludert hvem som har gjort hva og n?r.
  • Avviksdeteksjon: Muligheten til ? oppdage avvik mellom kj?rende konfigurasjon og versjonskontrollert kode.
  • Reproduserbarhet: Evnen til ? gjenskape milj?er p? en konsistent m?te ved bruk av versjonskontrollert kode.
  • Sikkerhet: Reduksjon av risiko for utilsiktede eller ondsinnede endringer, samt sikring av hemmeligheter og sensitiv informasjon.
  • Transparens: Legge til rette for deling p? tvers, og bidra til lettere ? kunne avdekke feil og svakheter.

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.
  • Endringer i policyen skal fremlegges for IT-sikkerhetssjef for godkjenning 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.
Publisert 25. mars 2025 12:20 - Sist endret 1. apr. 2025 21:34
Del p? e-post