Sikkerhetsdokumentasjon og hendelsesrutine for Ordlyd
Tiltak etter personvernforordningen artikkel 32, og rutine ved brudd etter artikkel 33 og 34. Dette dokumentet er vedlegg C til databehandleravtalen. Versjon 1.0 · 6. september 2026 · Ansvarlig: Christoffer Corzani
1. Kort om arkitekturen — hvorfor angrepsflaten er liten
Ordlyd er bygget slik at det meste av behandlingen aldri skjer hos oss:
- Lese- og skrivestøtten kjører lokalt. Talesyntese, ordbok, stavekontroll og ordforslag ligger i selve utvidelsen. Teksten brukeren leser og skriver, sendes aldri noe sted. Et innbrudd hos oss gir derfor ikke tilgang til innhold.
- Bare lisensadministrasjon ligger på server. Det er der tiltakene under gjelder.
- Klientprogramvare inneholder ingen databasenøkkel. Utvidelsen snakker aldri direkte med databasen, bare med lisensserverens eget grensesnitt. Dette er en absolutt regel i prosjektet, og den gjelder også administrasjonspanelet.
2. Tekniske tiltak
2.1 Konfidensialitet
| Tiltak | Hvordan |
|---|---|
| E-postadresser lagres pseudonymisert | Pepret hash. Peppernøkkelen ligger i miljøvariabler hos driftsleverandøren, aldri i databasen — en lekket database alene gir ingen lesbar brukerliste |
| Lisenskoder lagres pseudonymisert | Samme metode. Koden finnes ikke i klartekst noe sted, heller ikke i logger. Mistet kode kan ikke gjenopprettes, bare erstattes |
| All trafikk kryptert | TLS med HSTS på alle tjenester |
| Databasen er ikke eksponert | Bare tjenestens egen tilkobling har tilgang; ingen offentlig databasenøkkel finnes i noe utdelt program |
| Behovsbasert tilgang | Bare de som må ha tilgang for å drifte, har den. Administrasjonspanelet krever eget token |
| Hemmeligheter | Ligger i driftsleverandørens miljøvariabler, aldri i kildekoden. Kildekoden skannes for hemmeligheter før hver innsjekking |
2.2 Integritet
| Tiltak | Hvordan |
|---|---|
| Lisensbeviset er signert | Dobbel digital signatur (Ed25519 og P-256) over samme innhold. Signaturen kontrolleres på brukerens maskin, så en falsk server kan ikke gi seg ut for å være oss |
| Monotont høyvannsmerke | Klienten godtar ikke en eldre kvittering enn den den alt har, slik at et gammelt bevis ikke kan spilles av på nytt |
| Ratebegrensning | Innloggingsforsøk telles per konto og per pseudonymisert nettverk, slik at sjusifrede koder ikke kan gjettes |
| Revisjonsspor | Administrative handlinger loggføres med interne ID-er, ikke e-postadresser |
| Sikkerhetshoder | Streng CSP, frame-ancestors none, nosniff, no-referrer og HSTS på lisensserveren |
2.3 Tilgjengelighet
| Tiltak | Hvordan |
|---|---|
| Fail open | Mister maskinen kontakt med lisensserveren, fortsetter opplesingen å virke i degradert modus. En elev mister aldri hjelpemiddelet fordi et nettverk er nede |
| Offline drift | Norsk språkpakke og talesyntese ligger i selve utvidelsen. Ordlyd virker uten internett |
| Flere adresser til lisensserveren | Klienten har reserveadresser, slik at lisenskontroll ikke stopper om ett domene blir utilgjengelig |
| Sikkerhetskopi av databasen | Automatisk hos databaseleverandøren — [FYLL UT: hyppighet og hvor lenge kopiene beholdes, se Supabase-prosjektets innstillinger] |
2.4 Innebygd personvern
- Dataminimering: ingen navn, alder, klasse, diagnose eller bruksdata samles inn
- Automatisk sletting: en daglig jobb håndhever hver eneste lagringstid i personvernerklæringen. Endres en frist i teksten, må den endres i koden samtidig
- Full IP-adresse lagres aldri; bare en pseudonymisert nettverkskode, slettet etter 30 dager
- Svaret ved selvregistrering er alltid likt, uansett om adressen finnes hos oss — et svar som røpet hvem som er registrert, ville i praksis røpet hvem som har lese- og skrivevansker
3. Organisatoriske tiltak
- Taushetsplikt for alle med tilgang, også etter at oppdraget er avsluttet
- Endringskontroll: all kode gjennomgås og testes automatisk før utrulling. Testene dekker lisenslogikken, signaturkjeden, oppryddingsjobben og skrivestøttemotoren
- Hemmelighetsskann kjøres før hver innsjekking i kildekoden
- Nøkkelhåndtering: signeringsnøkler og pepper ligger i driftsleverandørens hemmeligheter. Peppernøkkelen kan aldri byttes uten at alle lisenser må utstedes på nytt, og det er dokumentert som en bevisst begrensning
- Leverandørstyring: databehandleravtale med hver underdatabehandler, og 30 dagers varsel med protestrett ved endring
4. Test, gjenoppretting og det vi ikke har gjort
Vi skriver dette punktet åpent, fordi en kommune som skal dokumentere egen internkontroll, trenger å vite hva som faktisk er testet.
Dette er gjennomført:
| Kontroll | Status |
|---|---|
| Automatiserte tester av lisenskjernen og serverlogikken | Kjøres ved hver endring |
| Ende-til-ende-test mot produksjon, inkludert lokal signaturverifisering | Gjennomført |
| Test av oppryddingsjobben mot lagringstidene | Kjøres ved hver endring |
| Gjennomgang av sikkerhetshoder på alle tjenester | Gjennomført 5. september 2026 |
| Kontroll av at ingen databasenøkkel finnes i utdelt programvare | Gjennomført |
Dette er IKKE gjennomført per 6. september 2026:
| Mangel | Konsekvens | Plan |
|---|---|---|
| Uavhengig inntrengingstest (pentest) | Ingen ekstern bekreftelse på at tiltakene holder | [FYLL UT: når, og av hvem — eller skriv at det avventer utrulling av et visst omfang] |
| Dokumentert gjenopprettingstest av database | Vi vet at kopier tas, men ikke bevist at gjenoppretting virker | [FYLL UT: dato for første prøvegjenoppretting] |
| Ekstern sikkerhetsrevisjon eller sertifisering (ISO 27001, ISAE 3402) | Ingen tredjepartsattest | Ikke planlagt for et gratistilbud i denne størrelsen |
| Tofaktor for administratorpålogging i panelet | Innlogging med token alene | [FYLL UT: planlagt tidspunkt] |
En leverandør som later som om alt er testet, er farligere enn en som sier hva som gjenstår. Listen over oppdateres når punktene lukkes.
5. Hendelsesrutine ved brudd på personopplysningssikkerheten
5.1 Hva som regnes som et brudd
Ethvert sikkerhetsbrudd som fører til utilsiktet eller ulovlig tilintetgjøring, tap, endring, ulovlig spredning av eller tilgang til personopplysninger. Også tilgjengelighetsbrudd teller: at opplysninger blir utilgjengelige når de skulle vært tilgjengelige.
Eksempler i vår sammenheng: lekket peppernøkkel eller databasetilgang, feil som gir én bruker innsyn i en annens lisens, tapt database uten brukbar sikkerhetskopi, kompromittert administratortilgang, eller en underdatabehandler som varsler brudd hos seg.
5.2 Rollene
| Rolle | Hvem | Ansvar |
|---|---|---|
| Hendelsesansvarlig | Christoffer Corzani | Leder håndteringen, tar varslingsbeslutningen |
| Teknisk ansvarlig | [NAVN ELLER: samme person] | Stanser pågående brudd, sikrer spor, gjenoppretter |
| Kundekontakt | [NAVN ELLER: samme person] | Varsler behandlingsansvarlige kunder |
Er dette samme person, skal det stå — men da må stedfortreder være navngitt, slik at 24-timersfristen også holder i ferier: Stedfortreder: [NAVN].
5.3 Tidslinje
| Tid | Handling |
|---|---|
| 0 timer — bruddet oppdages | Registrer klokkeslett og hvem som oppdaget det. Klokka begynner å gå her |
| Innen 1 time | Stans skaden: steng kompromittert tilgang, roter nøkler, ta tjenesten av nett om nødvendig. Sikre logger før de roteres bort |
| Innen 4 timer | Førstevurdering: hvilke opplysninger, hvor mange, hvilke kunder, sannsynlige følger |
| Innen 24 timer | Varsle hver berørt behandlingsansvarlig med det som er kjent. Er bildet ufullstendig, send likevel, og oppdater fortløpende |
| Innen 72 timer | Der vi selv er behandlingsansvarlig: meld til Datatilsynet etter artikkel 33, eller dokumenter skriftlig hvorfor melding ikke er påkrevd |
| Uten ugrunnet opphold | Ved høy risiko for de registrerte: varsle brukerne direkte, artikkel 34 |
| Innen 30 dager | Sluttrapport til berørte kunder: årsak, omfang, tiltak, og hva som endres for at det ikke skal gjenta seg |
5.4 Innhold i varselet
Hva som skjedde og når det ble oppdaget · hvilke kategorier opplysninger · omtrent hvor mange registrerte og poster · sannsynlige konsekvenser · iverksatte og planlagte tiltak · kontaktpunkt for mer informasjon.
5.5 Protokoll
Alle brudd føres i en intern protokoll, også de som ikke er meldepliktige, med vurderingen av hvorfor. Protokollen legges fram for Datatilsynet eller for en behandlingsansvarlig på forespørsel.
5.6 Øvelse
Rutinen gjennomgås minst én gang i året, og etter enhver reell hendelse. [FYLL UT: dato for siste gjennomgang.]
6. Kontakt
Sikkerhetshenvendelser og varsel om sårbarheter: post@ordlyd.no
Finner du en sårbarhet, tar vi imot meldingen og svarer innen fem virkedager. Vi går ikke rettslig etter noen som melder fra i god tro og som ikke har hentet ut, endret eller delt opplysninger.