| name | security-review |
| description | Sikkerhetsgjennomgang for Nav-applikasjoner — PII, FNR, helseopplysninger, secrets, logging, auditlogg, accessPolicy, eksterne integrasjoner, DPIA og sikkerhetschampion. Brukes via /security-review ved sikkerhetsreview. |
Sikkerhetsgjennomgang — Nav
Nav-spesifikk sikkerhetssjekk før commit, push og PR. Generiske OWASP-mønstre (SQLi, XSS, CSRF, injection) forutsettes kjent — dette dokumentet fokuserer på Nav-konteksten: PII-klassifisering, accessPolicy som sikkerhetsmekanisme, og eskalering til sikkerhetschampion.
PII-klassifisering i Nav
Nav behandler personopplysninger med fire beskyttelsesnivåer. Feil klassifisering er den vanligste rotårsaken til alvorlige avvik.
| Nivå | Typiske data | Behandling |
|---|
| Strengt fortrolig | Helseopplysninger, diagnoser, sykemeldinger, voldsutsatte/kode 6, barnevernsdata | Kryptering i ro og transit, streng tilgangsstyring, CEF-auditlogg ved visning (WARN), dedikert DPIA |
| Fortrolig | Fødselsnummer (fnr), D-nummer, kode 7, sensitive ytelsesdata | Aldri i standardlogger, CEF-auditlogg ved visning, tilgangsstyring per sak/bruker |
| Intern | Navn, adresse, telefon, e-post, ikke-sensitiv ytelsesstatus | Dataminimering, tilgang per tjenstlig behov, retention dokumentert |
| Åpen | Offentlig statistikk, anonymiserte aggregater | Normal tilgang; verifiser at anonymiseringen tåler koblingsangrep |
Klassifisering av ytelsesdata: Faktumet "en bruker mottar ytelse X" kan være fortrolig eller strengt fortrolig avhengig av ytelsen (f.eks. AAP/uføretrygd implisitt helseinformasjon). Spør sikkerhetschampion ved tvil.
Placeholder i kode og dokumentasjon: Bruk aldri ekte fnr. I eksempler og tester: 00000000000 eller Skatteetatens offisielle testserie (markert eksplisitt som syntetisk). Se references/nav-threat-model.md for DPIA-prosess og audit-krav.
PII i logger
log.info("Behandler sak", kv("sakId", sak.id), kv("tema", sak.tema))
log.info("Behandler sak for ${bruker.fnr}")
Visning av personopplysninger til Nav-ansatte skal logges i CEF-format til auditlog (ikke standardlogg). Se references/nav-threat-model.md for format og hva som skal logges når.
accessPolicy som first-line defense
accessPolicy i Nais-manifestet er første forsvarslinje — ikke en tilleggsmekanisme. Default deny på Nais-plattformen betyr at glemt regel = brutt tilgang, ikke åpen tilgang. Men feil regel = eksponert tjeneste.
spec:
accessPolicy:
inbound:
rules:
- application: min-frontend
outbound:
rules:
- application: pdl-api
namespace: pdl
cluster: prod-gcp
external:
- host: api.ekstern-tjeneste.no
Kritiske vurderinger ved gjennomgang:
- Ingen åpen inbound:
inbound.rules må være eksplisitt liste. Fravær av rules = ingen tilgang (OK for intern batch/job), men åpne wildcards eller mange generelle rules krever begrunnelse.
- Inbound vs. auth-kode speiler hverandre: Hver app i
inbound.rules skal være validert i auth-koden (f.eks. azp-sjekk mot AZURE_APP_PRE_AUTHORIZED_APPS). Diff avvik — enten død kode eller manglende nettverksregel.
- Outbound er et sikkerhetstiltak, ikke bare ruting: Begrenset outbound = begrenset blast radius hvis appen kompromitteres. Outbound
external må ha tydelig formål og eier.
- Cluster/namespace stemmer med miljøet:
prod-gcp vs dev-gcp — feil cluster i outbound = tjeneste fungerer ikke i prod, men blir ofte oppdaget sent.
Sikkerhetschampion-rolle og eskalering
Hvert team har en sikkerhetschampion (eller kan eskalere til plattformens sikkerhetsfunksjon). Denne rollen eies av teamet, ikke av security-review-skillen.
Når skillen håndterer det (ingen eskalering):
- Parameteriserte spørringer, input-validering, standard OWASP-mønstre.
- CEF-auditlogg ved visning av personopplysninger (mønster er etablert).
- accessPolicy-oppsett for standard inbound/outbound.
- Trivy/zizmor-funn med kjente fixes.
Når du eskalerer til sikkerhetschampion (eller #appsec):
- Ny klasse data: Første gang teamet behandler helseopplysninger, barnevernsdata eller kode 6/7.
- DPIA-behov: Ny behandling med personopplysninger eller vesentlig endring i eksisterende behandling. Se
references/nav-threat-model.md.
- Ny integrasjon med eksternt domene:
outbound.external mot leverandør/tredjepart.
- Endring i autentiseringsmekanisme: Bytte mellom Azure AD/TokenX/ID-porten/Maskinporten, eller ny RBAC-modell.
- Mistanke om hendelse: Lekket secret, uautorisert tilgang, avvikende bruksmønster — ikke vent, eskaler umiddelbart.
- Compliance-vurdering utenfor standardmønster: Tilsynssaker, Datatilsynet-henvendelser, svar på revisjon.
Hastegrad:
- Akutt (ring/ping umiddelbart): Aktiv hendelse, eksponert secret i git-historikk, mistanke om databehandlingsbrudd.
- Samme dag: Ny ekstern integrasjon i prod, endret autentiseringsflyt, nye datakategorier.
- Planlagt (Slack/issue): DPIA-forberedelse, arkitekturgjennomgang, trusselmodellering.
Kontaktkanaler (prosess, ikke personer): Teamets interne sikkerhetschampion-kanal; Navs #appsec for generelle spørsmål; #auditlogging-arcsight for auditlogg; plattformens sikkerhetsfunksjon for hendelser.
Automatiserte skanninger
trivy repo .
trivy image <image-name> --severity HIGH,CRITICAL
zizmor .github/workflows/
git log -p --all -S 'password' -- '*.kt' '*.ts' | head -100
git log -p --all -S 'secret' -- '*.kt' '*.ts' | head -100
Hemmeligheter
val dbPassword = System.getenv("DB_PASSWORD")
?: error("DB_PASSWORD mangler")
val dbPassword = "supersecret123"
Secrets opprettes i Nais Console og injiseres via envFrom/filesFrom. Kopier aldri prod-secrets lokalt.
Sjekkliste (Nav-fokus)
Referanser
| Ressurs | Bruksområde |
|---|
| sikkerhet.nav.no | Navs Golden Path for sikkerhet |
| auth-overview skill | JWT-validering, TokenX, ID-porten, Maskinporten |
references/nav-threat-model.md | Dyp trusselmodellering (STRIDE i Nav-kontekst), DPIA-prosess, audit-logging-krav, Datatilsynet-varsling |
references/gdpr-privacy.md | Nav-spesifikk PII-kategorisering og pekere til DPIA/CEF/retention |
references/api-security.md | Nav-signal: Nav-Call-Id, Nav-Consumer-Id, accessPolicy som primærmekanisme |
