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
52 lines
3.5 KiB
Markdown
52 lines
3.5 KiB
Markdown
# OSVxCC Access Control Policy
|
|
|
|
> Dette dokumentet definerer policyen for tilgangsstyring til alle ressurser i OSVxCC-arkitekturen. Målet er å sikre at kun autoriserte prinsipaler (brukere, service accounts) har tilgang, og kun med de rettighetene som er absolutt nødvendige (prinsippet om minimalt privilegium).
|
|
|
|
---
|
|
|
|
## Kjerne-prinsipper
|
|
|
|
1. **Minimalt Privilegium (Least Privilege):** Alle prinsipaler skal kun ha det absolutte minimum av rettigheter som kreves for å utføre sin definerte funksjon.
|
|
2. **Service Accounts for Tjenester:** All kode og alle tjenester (f.eks. Cloud Run, Compute Engine) **skal** kjøre med en dedikert service account med et snevert sett med rettigheter. Standard service accounts skal herdes.
|
|
3. **Menneskelig Tilgang via IAP:** All interaktiv menneskelig tilgang til interne ressurser (som SSH til VM-er) **skal** gå gjennom Identity-Aware Proxy (IAP). Direkte eksponering av porter til internett er forbudt.
|
|
4. **Nekt Alt som Standard (Default Deny):** Implisitt eller eksplisitt skal tilgang nektes med mindre det er gitt en spesifikk tillatelse.
|
|
|
|
---
|
|
|
|
## IAM-Policy og Praksis
|
|
|
|
### Forbud mot Primitive Roller
|
|
|
|
Bruk av primitive roller er strengt regulert:
|
|
|
|
- **`roles/owner`:** Forbudt for alle ressurser unntatt på prosjektnivå for et begrenset antall prosjekteiere.
|
|
- **`roles/editor`:** Forbudt. Denne rollen er for bred og gir for mange rettigheter. Den har blitt fjernet fra standard service accounts (se `SECURITY.md`).
|
|
- **`roles/viewer`:** Skal kun brukes for roller som krever bred, men passiv, innsikt.
|
|
|
|
Predefinerte roller (f.eks. `roles/run.invoker`, `roles/secretmanager.secretAccessor`) skal alltid foretrekkes.
|
|
|
|
### Viktige Service Accounts
|
|
|
|
Dette er kjernen i den usynlige arkitekturen. Hver konto har et begrenset og veldefinert formål.
|
|
|
|
| Service Account | Formål | Kritiske Roller |
|
|
|-----------------|--------|-----------------|
|
|
| `osvxcc-sa@...` | Kjerneidentitet for OSVxCC. Brukes av agenter og verktøy. | `run.invoker`, `secretmanager.secretAccessor` |
|
|
| `jason-vauger@...` | Runtime-identitet for MCP-serveren (Cloud Run). *(Historisk navn. Bør vurderes omdøpt til f.eks. `opax-mcp-runtime-sa` ved en senere anledning)*. | `secretmanager.secretAccessor` |
|
|
| `osvauco-agent-sa@...` | Identitet for OSVauco-agenten. | `secretmanager.secretAccessor` |
|
|
| `...-compute@...` | GCE default service account. **Herdet** ved fjerning av `editor`-rollen. | Begrensede rettigheter for VM-drift. |
|
|
|
|
### Menneskelig Tilgang
|
|
|
|
- **SSH-tilgang:** Gis ved å legge til en brukers Google-konto i IAM med rollene `roles/iap.tunnelResourceAccessor` og `roles/oslogin.user`. Brannmur-regler skal kun tillate SSH-trafikk fra IAPs verifiserte IP-range (`35.235.240.0/20`).
|
|
- **Konsolltilgang:** Gis via medlemskap i Google Grupper, som igjen tildeles spesifikke, forhåndsdefinerte IAM-roller.
|
|
|
|
---
|
|
|
|
## Prosedyre for Tildeling av Tilgang
|
|
|
|
1. **Forespørsel:** En forespørsel om tilgang sendes med en klar begrunnelse for *hvorfor* tilgangen er nødvendig og *hva* den skal brukes til.
|
|
2. **Vurdering:** Forespørselen vurderes for å identifisere det minimale settet med rettigheter som trengs. Alternativer som midlertidig tilgang vurderes.
|
|
3. **Tildeling:** Rettigheter tildeles, helst ved å legge prinsipalen til i en eksisterende gruppe eller ved å tildele en predefinert rolle for et spesifikt ressurs.
|
|
4. **Revisjon:** Tildelingen logges, og alle IAM-policyer revideres jevnlig (mål: hver 90. dag) for å fjerne utdaterte eller unødvendige rettigheter.
|