Chris Christiansen
79b100caff
Some checks are pending
Check Python Version Consistency / Check Python Version (push) Waiting to run
- SECURITY.md: Overordnet visjon med lenker til alle manifestfiler - SECURITY_AUDITS.md: Historikk og To-Do liste - RUNBOOK.md: 6 operasjonelle scenarier (ukjent bruker, eksponert secret, 401/403, 50x, VPC-SC, BinAuthz) - INCIDENT_RESPONSE.md: PICERL-modell med eskaleringsmatrise - SECRET_MANAGEMENT.md: Policy + lokal utvikling - ACCESS_CONTROL.md: IAM-policy med service account-oversikt - COMPLIANCE.md: TYR, Binary Auth, KMS-attestasjon Opprydding: - Slettet sensitive filer (test_secret.txt, final-secret-test.txt, tyr/certs/ca_password.txt) - Slettet engangsskript og midlertidige filer - Oppdatert .gitignore med *.txt
103 lines
4.4 KiB
Markdown
103 lines
4.4 KiB
Markdown
# 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 <SECRET_NAME> --replication-policy="automatic"
|
|
```
|
|
2. **Legg til den første versjonen:**
|
|
```bash
|
|
printf "<SECRET_VALUE>" | gcloud secrets versions add <SECRET_NAME> --data-file=-
|
|
```
|
|
3. **Gi en service account tilgang:**
|
|
```bash
|
|
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`.
|
|
```bash
|
|
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.
|
|
```bash
|
|
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.**
|
|
```bash
|
|
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:**
|
|
```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
|
|
```
|
|
|