# 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:** ```bash gcloud secrets create --replication-policy="automatic" ``` 2. **Legg til den første versjonen:** ```bash printf "" | gcloud secrets versions add --data-file=- ``` 3. **Gi en service account tilgang:** ```bash gcloud secrets add-iam-policy-binding \ --member="serviceAccount:" \ --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`. ```bash printf "" | gcloud secrets versions add --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. ```bash gcloud secrets versions disable --secret= ``` 5. **Monitorer systemet** i en verifikasjonsperiode (f.eks. 7 dager). 6. **Destruer den gamle versjonen.** ```bash gcloud secrets versions destroy --secret= ``` #### 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:** ```bash #!/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 ```