Slik bygger vi sikkert: BankID, GDPR og audit fra første tegning

Det vanligste sikkerhets-anti-mønsteret

Et prosjekt løper i flere måneder. Sluttbruker-testing nærmer seg. Noen i prosjektgruppen sier: "Vi må huske å gjøre en sikkerhetsgjennomgang før vi går i prod."

Det er ofte for sent.

Når sikkerhet legges på til slutt, blir det enten en sjekkliste som passer rapporten men ikke virkeligheten, eller en sen oppdagelse av strukturelle problemer som koster mye å fikse. Begge utfall er dårlige.

Sikkerhet bygges inn fra første tegning, eller blir aldri ekte. Her er hvordan vi gjør det konkret.

Datamodellen klassifiseres på dag én

Før vi skriver en eneste linje kode, går vi gjennom alle entiteter i systemet og klassifiserer dem etter hva slags data de inneholder:

• Klasse 1 (offentlig): Kan vises uten autentisering. Bedrifts-info, åpne produktkataloger.
• Klasse 2 (intern): Kun for autentiserte brukere. Bruker-profil, intern dokumentasjon.
• Klasse 3 (sensitiv): Kun for autoriserte roller. Lønn, helsedata, økonomiske transaksjoner.
• Klasse 4 (kritisk): Spesielle krav til kryptering og audit. Helsedata, BankID-signerte dokumenter, identifiserende personopplysninger ved særlig risiko.

Klassifiseringen påvirker hvert teknisk valg videre: hvilken database-kryptering, hvor mye audit-logging, hvilken autentisering, hvilken backup-policy, hvor data kan ligge geografisk.

Dette tar 2–4 timer ekstra på første prosjektuke, og sparer uker senere når sikkerhets-spørsmål kommer opp.

Autentisering: alltid sterkere enn nødvendig

Standardpolicyen vår er at autentisering skal være ett nivå sterkere enn det "akkurat tilstrekkelig" tilsier.

For interne fagverktøy: minimum SSO via virksomhetens egen identitetsleverandør, ikke brukernavn og passord. Hvis systemet håndterer klasse 3+ data: MFA påkrevd, ingen unntak.

For pasient- eller borger-rettet system: BankID eller ID-porten. Aldri "vi sender deg en SMS-kode", aldri "lag en bruker med e-post og passord".

For B2B-portaler der eksterne brukere logger inn: BankID hvis tilgjengelig, ellers OIDC mot deres egen identitetsleverandør. Aldri lokal bruker-database for klasse 2+ data.

For maskinkall mellom systemer: Maskinporten i offentlig sektor, OAuth2 client credentials i private, mTLS for kritiske integrasjoner. Aldri statiske API-nøkler i klartekst.

Det er overkill for noen prosjekter. Det er aldri en sikkerhetsulempe. Og når kravene endres, eller systemet skal håndtere mer sensitiv data senere, er fundamentet allerede der.

Audit-logging på alt som teller

Alt som endrer data, og alt som leser sensitiv data, logges:

• Hvem leste hvilken data, når
• Hvem endret hvilken data, fra hva til hva, når
• Hvem autentiserte seg, hvilken metode, fra hvilken IP
• Hvilke systemer hentet data via API, hvor mye, når

Loggene lagres separat fra applikasjonsdataene, ofte i en append-only-database eller en log-tjeneste med tamper-protection. Det betyr at en angriper som kompromitterer applikasjonen, ikke kan slette spor av angrepet.

For klasse 3+ data oppbevares logger så lenge regelverket og behovet tilsier. Loggene gjennomgås rutinemessig, ikke bare når noe er galt.

Dette er ikke ekstra. Det er minimumsstandard for B2B-systemer som skal tas i bruk i drift.

Minste rettighet er standard, ikke unntak

For hver rolle i systemet stiller vi spørsmålet: hva trenger denne rollen å se og endre for å gjøre jobben? Alt annet skal være utilgjengelig.

Det betyr i praksis:

• En saksbehandler ser kun sine egne saker, eller saker tilhørende kollegaer i samme team
• En leder ser team-statistikk, men ikke detaljer på individuelle saker uten å klikke seg inn
• En admin har full kontroll, men hver admin-handling er ekstra-logget og krever ofte to-faktor
• Eksterne integrasjoner får tilgang til den smalest mulige delen av API-et

Når en bruker ber om mer tilgang, er det en eksplisitt beslutning, ikke en automatisk utvidelse. Det er kjedelig for brukerne på kort sikt. Det er forsikring mot at en kompromittert konto ikke gir tilgang til alt.

Kryptering: i hvile, i transport, alltid

All data krypteres i hvile (storage-nivå), i transport (TLS 1.3 minimum), og for klasse 3+ også i applikasjons-laget (kolonne-nivå kryptering for sensitive felter som personnummer eller bankkontoer).

Krypteringsnøkler oppbevares i dedikerte key management-tjenester, ikke i applikasjonskoden eller miljøvariablene.

Rotering av nøkler skjer automatisk på en fast plan. Backup er kryptert med separate nøkler, ikke produksjonsnøklene.

Dette er standard for alle våre systemer som håndterer klasse 2+ data, ikke noe vi gjør "hvis kunden ber om det".

GDPR i grunnmuren

For systemer som behandler personopplysninger gjør vi følgende rutinemessig:

Datakart ved oppstart: hvilke personopplysninger samles inn, hvor lagres de, hvor lenge oppbevares de, hvem har tilgang, hvem deles de med. Dette holdes oppdatert gjennom hele prosjektet.

Konsekvensvurdering for personvern der behandlingen tilsier det, for eksempel ved klasse 3+ data eller bred behandling av personopplysninger. Vi er vant til å gjøre slike vurderinger i samarbeid med kunden.

Behandlingsgrunnlag fastsatt for hver type behandling. Ikke "vi gjør det fordi vi gjør det", men et tydelig grunnlag der behandlingen er proporsjonal.

Innebygd personvern (privacy by design): brukeren ser hvilke data om dem som finnes, kan eksportere dem, kan rette feil, kan be om sletting. Disse funksjonene bygges inn fra start, ikke som ettertanke.

Databehandleravtaler med alle underleverandører. Norsk eller EU/EØS-basert drift for alt som inneholder norske personopplysninger.

Penetrasjonstest, men ikke som første sikkerhetstiltak

Vi gjør penetrasjonstest på alle systemer som håndterer klasse 3+ data før produksjonssetting. Vi gjør det med eksterne sikkerhetsmiljøer, ikke oss selv, fordi vi er for nær koden til å se den med friske øyne.

Men penetrasjonstest er den siste sjekken, ikke den første. Hvis testen finner kritiske hull, er det ikke fordi testen var god. Det er fordi vi gjorde for dårlig arbeid før den.

På et velbygget system finner penetrasjonstesten typisk: små feilmeldinger som leker for mye informasjon, mindre konfigurasjonsfeil, et par edge cases vi ikke hadde tenkt på. Ikke strukturelle problemer.

Bygget for å overleve oppdagelser

Sikkerhet er ikke en tilstand, det er en kontinuerlig prosess. Vi setter opp:

• Automatisk overvåking av kjente sårbarheter i avhengigheter (Snyk, Dependabot, GitHub Security)
• Logging av uvanlige autentiserings-mønstre (mange feil-innlogginger, innlogging fra uvanlig geografi)
• Periodisk reviews av rolle- og tilgangsstruktur
• Klare runbooks for sikkerhetshendelser: hva gjør vi hvis vi oppdager en lekkasje?

Et godt system overlever den dagen noe blir oppdaget, ikke fordi ingenting feiler, men fordi vi har strukturer for å fange det opp og handle.

Hva dere bør kreve av enhver utviklingspartner

Når dere snakker med potensielle partnere, still disse spørsmålene:

1. Hvordan klassifiserer dere data i et nytt prosjekt?
2. Hvilken minimum-autentisering bruker dere på systemer med personopplysninger?
3. Hvordan logger dere endringer på sensitive data, og hvor lagres loggene?
4. Hvordan håndterer dere personvern og GDPR fra prosjektstart?
5. Når gjør dere penetrasjonstest, og av hvem?
6. Hva er deres protokoll hvis dere oppdager et sikkerhetshull i produksjon hos en kunde?

En partner som svarer strukturert og konsistent: god kandidat. En partner som svarer vagt eller henviser til en "policy" uten å forklare hvordan den praktiseres: vær forsiktig.

Sikkerhet er ikke kompliserte ord, det er konkrete vaner. Snakk med oss om hvordan dette ser ut i et reelt prosjekt, eller les mer om systemutvikling hos STUDIO X.