chris/OSVauco
1
0
Fork 0
Code Issues 1 Pull Requests Actions 2 Packages Projects Releases Wiki Activity
0b40d556cd
OSVauco/docs/ACCESS_CONTROL.md
Chris Christiansen 79b100caff
Some checks are pending
Check Python Version Consistency / Check Python Version (push) Waiting to run
Details
docs(security): komplett sikkerhetsdokumentasjon med 7 manifestfiler 
- 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
2026-09-04 08:25:57 +00:00

3.5 KiB
Raw Blame History

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.