OSVauco/docs/SECRET_MANAGEMENT.md

OSVxCC Secret Management Policy

Dette dokumentet definerer policy og prosedyrer for livssyklusen til hemmeligheter (API-nøkler, passord, sertifikater) i OSVxCC-arkitekturen. Målet er å sikre at hemmeligheter er beskyttet mot uautorisert tilgang og avsløring.

---

Kjerne-prinsipper

1. Sannhetens Kilde: Google Cloud Secret Manager er det eneste godkjente systemet for lagring og administrasjon av hemmeligheter.
2. Minimalt Privilegium: Prinsipaler (brukere, service accounts) skal kun ha tilgang til de spesifikke hemmelighetene de trenger for å utføre sin funksjon.
3. Aldri i Kode: Hemmeligheter skal aldri hardkodes i kildekode, konfigurasjonsfiler eller sjekkes inn i Git.
4. Kryptert i Transitt og Hvile: Hemmeligheter håndteres alltid kryptert.

---

Policy

Regel	Beskrivelse
Lagring	Alle hemmeligheter skal lagres i Google Cloud Secret Manager.
Tilgang	Tilgang skal kun gis via IAM-roller (primært roles/secretmanager.secretAccessor) til spesifikke service accounts.
Logging	Tilgang til hemmeligheter skal logges (Data Access audit logs).
Rotasjon	Alle kritiske hemmeligheter skal ha en rotasjonspolicy.

---

Prosedyrer

Opprette en ny hemmelighet

1. Opprett hemmeligheten i Secret Manager:

   gcloud secrets create <SECRET_NAME> --replication-policy="automatic"
   

2. Legg til den første versjonen:

   printf "<SECRET_VALUE>" | gcloud secrets versions add <SECRET_NAME> --data-file=-
   

3. Gi en service account tilgang:

   gcloud secrets add-iam-policy-binding <SECRET_NAME> \
     --member="serviceAccount:<SA_EMAIL>" \
     --role="roles/secretmanager.secretAccessor"
   

Hente en hemmelighet i en applikasjon

Applikasjoner (f.eks. i Cloud Run) skal bruke Google Cloud-klientbiblioteker for å hente hemmeligheter ved oppstart eller ved behov. Service accounten som applikasjonen kjører som må ha fått tilgang.

Rotere en hemmelighet

Rotasjon er kritisk for å redusere risikoen ved en kompromittert hemmelighet.

Manuell Rotasjon (Gjeldende prosedyre)

1. Generer en ny hemmelighetsverdi.
2. Legg til den nye verdien som en ny versjon i Secret Manager. Merk den som ENABLED.

   printf "<NEW_SECRET_VALUE>" | gcloud secrets versions add <SECRET_NAME> --data-file=-
   

3. Oppdater applikasjoner til å peke mot den nye versjonen (f.eks. latest).
4. Deaktiver den gamle versjonen etter at applikasjonen er bekreftet å fungere.

   gcloud secrets versions disable <OLD_VERSION_NUMBER> --secret=<SECRET_NAME>
   

5. Monitorer systemet i en verifikasjonsperiode (f.eks. 7 dager).
6. Destruer den gamle versjonen.

   gcloud secrets versions destroy <OLD_VERSION_NUMBER> --secret=<SECRET_NAME>
   

Automatisert Rotasjon (Anbefaling)

• Status: ⚠️ Ikke implementert.
• Anbefaling: For kritiske hemmeligheter som mcp-server-key, konfigurer en automatisk rotasjonspolicy direkte i Secret Manager.
  • Mål: Roter hver 90. dag.
  • Implementasjon: Dette kan gjøres via Cloud Console eller gcloud og krever ofte en Cloud Function for å håndtere selve rotasjonslogikken (generere ny verdi og oppdatere der den brukes).
  • Prioritet: Høy. Dette adresserer et kjent forbedringspunkt fra SECURITY.md.

---

Lokal Utvikling

For å unngå at hemmeligheter lekkes ved et uhell under lokal testing og utvikling, gjelder følgende regler:

1. Bruk av .env-filer:

   • Filer som inneholder hemmeligheter for et lokalt miljø (f.eks. .env, .env.local) skal legges til i prosjektets .gitignore-fil for å forhindre at de blir sjekket inn i kildekontroll.

2. Anbefalt Praksis: Dynamisk Henting

   • I stedet for å kopiere hemmeligheter manuelt til lokale filer, er det sterkt anbefalt å hente dem dynamisk ved behov.
   • Dette kan gjøres i et oppstartsskript som injiserer hemmelighetene som miljøvariabler. Dette minimerer tiden en hemmelighet ligger lagret på disk.
   • Eksempel på skript:

     #!/bin/bash
     
     # Hent hemmeligheten fra Secret Manager
     export MCP_SECRET=$(gcloud secrets versions access latest --secret=mcp-server-key)
     
     # Start applikasjonen med hemmeligheten som miljøvariabel
     python3 main.py