OSVauco/docs/RUNBOOK.md

OSVxCC Runbook

Dette dokumentet beskriver operasjonelle prosedyrer for å håndtere varsler og verifisere systemstatus. Målet er å raskt avklare om en hendelse er reell eller en falsk positiv.

---

Innholdsfortegnelse

1. Varsel: "Ukjent bruker" Git Push
2. Hendelse: Eksponert Hemmelighet
3. Hendelse: Høy andel HTTP 401/403 på Cloud Run
4. Hendelse: HTTP 50x (Cloud Run nede)
5. Hendelse: VPC Service Controls blokkerer tilgang
6. Hendelse: Cloud Build / Binary Authorization feiler deploy

---

1. Varsel: "Ukjent bruker" Git Push

Symptom

Chat-applikasjonen (f.eks. Slack, Discord) rapporterer gjentatte Git-pushes fra en "ukjent bruker" eller en generisk app-bruker (f.eks. "CodeOSS-push, App"). Aktiviteten skjer ofte på faste tidspunkter (f.eks. 09:00 og 21:00).

Undersøkelsesprosedyre

Følg disse stegene for å verifisere aktiviteten:

1. Sjekk Git-loggen umiddelbart.

   git log -n 10 --pretty=format:"%h %an <%ae> %ar: %s"
   

   • Se etter: Er de siste comittene fra en kjent og autorisert bidragsyter (f.eks. Chris Christiansen <chris.christiansen@vauco.no>)?

2. Analyser tidspunkt og innhold.

   • Spørsmål: Samsvarer tidspunktene med normalt utviklingsarbeid? Er commit-meldingene og filendringene logiske?

3. Verifiser webhook-konfigurasjon.

   • Undersøk: Sjekk innstillingene for webhooken i Gitea/GitHub og i chat-applikasjonen. Ofte kan webhooks være konfigurert slik at de ikke klarer å mappe den tekniske brukeren til et visningsnavn, og faller tilbake på et generisk navn.

4. Kontroller automatiserte systemer (for å utelukke dem).

   • Sjekk Cloud Build-triggere, cron-jobs på VM-en, og eventuelle lokale Git hooks for uventet aktivitet.

Konklusjon (Mest sannsynlig)

Ingen sikkerhetshendelse. Aktiviteten er høyst sannsynlig legitimt utviklingsarbeid utført av en autorisert bruker via en IDE (som VS Code) sin Git-integrasjon. "Ukjent bruker"-navnet er et resultat av hvordan webhooken tolker og presenterer hendelsen.

Status

✅ Avklart — Falsk positiv. Ingen tiltak er nødvendig med mindre git log viser ukjente forfattere.

---

2. Hendelse: Eksponert Hemmelighet

Symptom

En hemmelighet (API-nøkkel, passord, tjenestenøkkel) er oppdaget på et usikret sted. Eksempler:

• Limt inn i en offentlig chat (Slack, Discord).
• Sjekket inn i Git og pushet til Gitea/GitHub.
• Hardkodet i en offentlig tilgjengelig fil.

Dette er en KRITISK hendelse.

Undersøkelsesprosedyre (PICERL-fasene)

Fase 1: Containment (Innkapsling) - UMIDDELBART

1. Roter hemmeligheten umiddelbart. Dette er det viktigste steget for å stoppe misbruk.
   1. Generer en ny verdi for hemmeligheten.
   2. Opprett en ny versjon i Secret Manager med den nye verdien. Se docs/SECRET_MANAGEMENT.md for detaljerte kommandoer.

      # Eksempel for mcp-server-key
      printf "<NY_HEMMELIG_VERDI>" | gcloud secrets versions add mcp-server-key --data-file=-
      

   3. Oppdater applikasjonen(e) som bruker hemmeligheten til å peke mot den nye versjonen (latest). For Cloud Run, deploy en ny revisjon med den oppdaterte hemmelighetsreferansen.
   4. Deaktiver den gamle versjonen i Secret Manager. Ikke slett den ennå. Dette fungerer som en "kill switch".

      gcloud secrets versions disable <GAMMEL_VERSJON> --secret=<HEMMELIGHETENS_NAVN>
      

Fase 2: Eradication (Utryddelse)

1. Fjern hemmeligheten fra eksponeringsstedet.
   • Git: Bruk et verktøy som git-filter-repo eller BFG Repo-Cleaner for å fjerne hemmeligheten fra hele Git-historikken. En vanlig git commit er ikke nok.
     • Referanse: Den tidligere hendelsen med mcp-server-key (se docs/SECURITY_AUDITS.md).
   • Slack/Chat: Slett meldingen.
   • Filer: Fjern hemmeligheten fra filen og deploy på nytt.

Fase 3: Recovery & Lessons Learned

1. Analyser logger. Sjekk Secret Manager audit logs for å se om den eksponerte hemmeligheten ble aksessert av uautoriserte IP-adresser eller tjenestekontoer.
   • Naviger til Logging > Log Explorer i Cloud Console.
   • Query:

     resource.type="gcp_secret"
     protoPayload.methodName="AccessSecretVersion"
     protoPayload.resourceName="projects/.../secrets/<HEMMELIGHETENS_NAVN>/versions/<GAMMEL_VERSJON>"
     

2. Verifiser at alle systemer fungerer med den nye hemmeligheten.
3. Destruer den gamle versjonen i Secret Manager etter en verifikasjonsperiode (f.eks. 24-48 timer).
4. Dokumenter hendelsen og diskuter hvordan det skjedde for å forhindre gjentakelse.

Status

🔴 KRITISK TIL AVKLART. Følg prosedyren til alle steg er fullført.

---

3. Hendelse: Høy andel HTTP 401/403 på Cloud Run

Symptom

Cloud Monitoring-varsler rapporterer en unormalt høy andel av HTTP-responser med statuskode 401 (Unauthorized) eller 403 (Forbidden) fra MCP-serveren (opax-mcp).

Undersøkelsesprosedyre

1. Analyser kildene.
   • Gå til Logging > Log Explorer i Cloud Console.
   • Kjør en spørring for å gruppere 401/403-feil etter kilde-IP.

     resource.type="cloud_run_revision"
     resource.labels.service_name="opax-mcp"
     httpRequest.status IN (401, 403)
     

   • Se i loggene etter jsonPayload.remoteIp.
2. Skill mellom angrep og feilkonfigurasjon.
   • Brute-force/Scanning: Ser du mange forespørsler fra én eller få IP-adresser som ikke er gjenkjennelige? Dette kan tyde på et angrepsforsøk. Vurder å blokkere IP-en midlertidig med Cloud Armor.
   • Feilkonfigurert klient: Ser du forespørsler fra kjente IP-adresser (f.eks. andre VM-er i prosjektet)? Dette tyder på at en legitim klient bruker en utdatert eller feilaktig hemmelighet (X-MCP-Secret).
   • Mønster: Er feilene sporadiske eller konstante? Konstante feil fra en kjent klient indikerer nesten alltid en konfigurasjonsfeil hos klienten.

Konklusjon (Mest sannsynlig)

• Scenario A (Ukjent IP): Potensielt sikkerhetsproblem (scanning). Overvåk og vurder blokkering.
• Scenario B (Kjent IP): Operasjonell feil. Informer eieren av klienten om å oppdatere sin hemmelighet.

Status

🟡 MODERAT TIL AVKLART.

---

4. Hendelse: HTTP 50x (Cloud Run nede)

Symptom

Cloud Monitoring varsler om en høy andel HTTP 5xx-feil, eller tjenesten svarer ikke. Dette indikerer at containeren krasjer eller ikke starter.

Undersøkelsesprosedyre

1. Sjekk container-logger for krasj.
   • Gå til Cloud Run > opax-mcp > Logs.
   • Se etter meldinger som indikerer at prosessen stoppet uventet, f.eks. panic, out of memory, eller andre unntak ved oppstart.
2. Verifiser IAM-tilganger (spesielt til Secret Manager).
   • Gå til Cloud Run > opax-mcp > Revisions.
   • Sjekk hvilken Service Account som brukes (skal være jason-vauger@...).
   • Gå til IAM & Admin > IAM.
   • Verifiser at jason-vauger@... har rollen roles/secretmanager.secretAccessor.
   • Vanlig feil: Hvis applikasjonen ikke får hentet mcp-server-key ved oppstart på grunn av manglende IAM-tilgang, vil den ofte krasje med en 5xx-feil.
3. Analyser nylige endringer.
   • Har det vært en nylig deployering? Rull tilbake til en tidligere, fungerende revisjon via Cloud Run > opax-mcp > Manage Revisions for å se om problemet vedvarer.

Konklusjon (Mest sannsynlig)

• Oftest er dette enten en bug i koden (som fører til krasj) eller en IAM/Secret Manager-konfigurasjonsfeil.

Status

🔴 KRITISK TIL AVKLART.

---

5. Hendelse: VPC Service Controls blokkerer tilgang

Symptom

En applikasjon, et skript eller en utvikler mottar en 403 Request Prohibited by organization's policy feil ved kall mot en GCP API (f.eks. BigQuery, Storage) som er beskyttet av en VPC-SC perimeter.

Undersøkelsesprosedyre

1. Finn VPC-SC brudd-loggen.
   • Gå til Logging > Log Explorer.
   • Bruk følgende spørring for å finne de relevante loggene:

     log_id("cloudaudit.googleapis.com/activity")
     protoPayload.metadata.violationReason = "SERVICE_NOT_ALLOWED_FROM_VPC" OR "NO_MATCHING_ACCESS_LEVEL"
     

2. Analyser logg-detaljene.
   • resource.labels.project_id: Hvilket prosjekt skjedde bruddet i?
   • protoPayload.authenticationInfo.principalEmail: Hvem eller hva ble blokkert?
   • protoPayload.requestMetadata.callerIp: Hvor kom kallet fra (hvis relevant)?
   • protoPayload.resourceName: Hvilken beskyttet ressurs var målet?

Konklusjon (Mest sannsynlig)

• Scenario A (Legitimt kall blokkert): En ny tjeneste eller utvikler-VM er satt opp utenfor perimeteren og trenger tilgang. Tiltak: Vurder å inkludere ressursen i perimeteren, eller opprett et tilgangsnivå (Access Level).
• Scenario B (Uventet kall blokkert): Et uautorisert skript eller en ekstern tjeneste prøver å nå en beskyttet ressurs. Konklusjon: Perimeteren har fungert som designet og forhindret et potensielt datainnbrudd.

Status

🟡 MODERAT TIL AVKLART. Krever analyse for å skille mellom feilkonfigurasjon og reell beskyttelse.

---

6. Hendelse: Cloud Build / Binary Authorization feiler deploy

Symptom

En Cloud Build-pipeline feiler på det siste "deploy to Cloud Run"-steget. Feilmeldingen nevner Binary Authorization eller attestation.

Undersøkelsesprosedyre

1. Sjekk bygge-loggen for TYR-feil.
   • Åpne loggen for den feilede builden i Cloud Build.
   • Scroll opp til steget som kjører TYR Compliance Scan.
   • Hvis dette steget feilet (rødt ikon), vil loggen inneholde detaljer om nøyaktig hvilken compliance-regel som ble brutt.
2. Verifiser at attestering finnes.
   • Hvis TYR-steget var vellykket, men deploy likevel feiler, kan selve attesteringen mangle.
   • Finn "digest" for ditt image i loggen (en lang sha256:... streng).
   • Kjør denne kommandoen i Cloud Shell:

     gcloud container binauthz attestations list --artifact-url="[REGION]-docker.pkg.dev/[PROJECT_ID]/[REPO]/[IMAGE_NAME]@[IMAGE_DIGEST]"
     

Konklusjon (Mest sannsynlig)

• TYR-feil: Den vanligste årsaken. En endring i koden eller infrastrukturen bryter med en definert sikkerhetsregel. Tiltak: Rett feilen som TYR rapporterer.
• Manglende attestering: Output fra gcloud er tomt. Dette kan skyldes en midlertidig feil med KMS eller at IAM-rettighetene til Cloud Build sin service account er feil. Tiltak: Prøv å kjøre builden på nytt. Hvis feilen vedvarer, sjekk IAM for cloud-build-private-pool@....

Status

🟡 MODERAT TIL AVKLART. Vanligvis en operasjonell feil forårsaket av en compliance-endring.