4 Beskrivelse og anbefaling av tekniske løsninger

Dette kapitlet beskriver en generell arkitektur for elektroniske skjemaløsninger. Mange kommuner bruker en egen skjemaleverandør for sine skjemaer på nett, slik at skjemaløsningen ligger som en ASP-løsning hos en ekstern leverandør. Dersom kommunen har skjemaløsningen internt i sitt datanettverk, så vil krav beskrevet i dette kapitlet i utgangspunktet også gjelde kommunen sine løsninger.

I beskrivelse av den generelle arkitekturen er det lagt vekt på følgende områder:

• Borgeren skal ha tilgang til å sende inn skjema via Internett
• Skjemaløsningen ligger hos en ekstern ASP-leverandør
• Kommunen skal ta imot data fra skjemaleverandøren
• Borgeren skal tilbakemelding fra kommunen om status på skjemabehandling og informasjon om vedtak

4.1. Generelle sikkerhetsprinsipper

Ved datafangst hos skjemaleverandør og ved datakommunikasjon mellom skjemaleverandør og kommunen er følgende hovedregler de viktigste å tenke på for å ha en trygg og sikker løsning:

1. Datafangst fra borger må skje på en trygg og sikker måte (autentisering/signatur av borger og sikker transport av data)

2. Dataene må håndteres og lagres på sikker måte hos skjemaleverandøren

3. Kommunikasjonen mellom skjemaleverandøren og kommunen må være tilstrekkelig sikret og en må ha god kontroll over datakommunikasjonen mellom skjemaleverandøren og kommunen

4. En må sørge for at løsningene er utformet slik (arkitekturen) at dersom for eksempel ondsinnet kode eller uautoriserte personer/systemer får tilgang til løsningene så blir det minimale konsekvenser (skader) av et slikt sikkerhetsbrudd

De generelle sikkerhetsprinsippene bør planlegges slik at de ivaretar nødvendige krav i henhold til:

- Konfidensialitet: Å sikre at informasjon bare er tilgjengelig for de som skal ha tilgang

- Tilgjengelighet: Å sikre at informasjon er tilgjengelig innenfor de krav som er satt

- Integritet: Å sikre at informasjon er korrekt og fullstendig og at informasjonen ikke er endret av uvedkommende

- Sporbarhet: Å ha nødvendig metoder og mekanismer som skal knytte alle endringer av informasjon til den som har utført endringene

Løsningene som anbefales her gjelder uavhengig av hvilke transportmetoder og teknologier som brukes og hvordan den enkelte skjemaleverandør/kommune velger å motta sine data på. Hvordan sikkerheten rent teknisk kan ivaretas vil avhenge av hvilke metoder som velges og av arkitekturen hos den enkelte kommune/skjemaleverandør.

4.2. Generelt om transportmetoder

Nedenfor beskriver de vanligste metodene som brukes for datatransport mellom to eller flere parter.

4.2.1. FTP/SFTP

FTP (File Transfer Protocol, altså filoverføringsprotokoll) er en standard, operativsystemuavhengig protokoll for overføring av filer i et TCP/IP-basert nettverk. Overføringen skjer mellom en FTP-klient og en FTP-server. Hvilken maskin som har hvilken rolle, kan i utgangspunktet velges fritt, men vil selvsagt være gitt av oppgaven som skal løses.

FTP-serveren lytter på nettverket etter forespørsler. FTP-klienten kobler til serveren og kan lese og skrive til serverens filsystem, som opp- og nedlasting av filer, sletting, navnebytte etc.

Meldingssikkerhet krever ofte PKI-baserte mekanismer både hos avsender og mottaker for å få til gode løsninger i dag. De mest brukte PKI-løsningene i det norske markedet, BankID og Buypass, kan brukes til å oppnå meldingssikkerhet, men de støtter ikke sikker e-post. Det går også an å signere, men ikke kryptere, meldingene, og basere seg på en sikker transportkanal (SSL/TLS) for kryptering.

Anbefalinger: - All overføring av skjemadata anbefales kryptert- Ende-til-ende kryptering skal brukes så langt dette er mulig dersom det kommuniseres sensitive opplysninger- Overføringen skal krypteres dersom skjemaene kan inneholde sensitive opplysninger og/eller fødselsnummer- En må velge mekanismer som også ivaretar nødvendige krav til dataintegritet

4.3.2. Ikke sikret datakommunikasjonen

Dersom man ikke har kryptert datakommunikasjonen hverken med meldingskryptering eller transportkryptering er det begrensning på hvilke skjema man kan tilgjengeliggjøre på Internett. Skjema som er tiltenkt å kunne inneholde sensitive personopplysninger, fødselsnummer eller som har åpne merknadsfelt/kommentarfelt kan da ikke legges ut på Internett.

4.3.3. Typer vedlegg som kan sendes ved

Skjemaleverandørene bør i samarbeid med den enkelte kommune bli enige om hvilke typer vedlegg som innbyggeren skal kunne sende inn.

4.3.4. Teknisk sikring av datafangstløsningen

Datafangstløsningen bør sikres slik at den ikke kan utnyttes til å misbruke datafangsttjenesten på noe vis. Aktuelle sikkerhetstiltak kan for eksempel være:

- Begrensning på hvor mange skjema som kan sendes inn fra samme person/PC slik at dette ikke kan utnyttes av andre til for eksempel å utføre DoS-angrep (Denial-of-Service)

- Tilbakemeldinger til den som fyller ut skjemaet må ikke være av en slik form (må for eksempel ikke oppgi tabellnavn eller feltnavn i databaser) slik at dette kan utnyttes til for eksempel å utføre angrep mot databasene for å få hentet ut informasjon

Det vises også til anbefalinger fra Datatilsynet som er tilgjengelig her.

4.4. Autentisering og bruk av fødselsnummer

Fødselsnummer skal bare brukes når det er saklig behov, og når det er umulig å oppnå tilfredsstillende identifikasjon ved bruk av andre metoder, som for eksempel navn, adresse, fødselsdato, medlems- eller kundenummer.

Å oppgi fødselsnummer er ikke noen form for autentisering, men fødselsnummer inngår for eksempel som brukernavn i dagens løsning av Minid.

Dersom det benyttes for eksempel Minid til pålogging vil fødselsnummer komme gjennom denne påloggingen. I slike tilfeller vil det være unødvendig å be borger fylle ut fødselsnummer i tillegg på skjemaet dersom man har et legitimt behov for fødselsnummeret.

- Fødselsnummer skal bare brukes når det er saklig behov og når det ikke finnes andre mulige løsninger for å oppnå tilfredsstillende identifikasjon

- Overføring av fødselsnummer skal alltid krypteres

4.4.1. Bruk av fødselsnummer i dag

4.5. Datahåndtering når skjemaløsning ligger hos en databehandler

Dersom skjemaløsningen ligger eksternt hos en skjemaleverandør (som en ASP-løsning) vil skjemaleverandøren opptre som en databehandler som innhenter data på vegne av kommunen som er behandlingsansvarlig. Ansvarsforholdene mellom databehandler og behandlingsansvarlig må beskrives gjennom en databehandleravtale (se kapittel 5.4). Databehandleravtalen regulerer hvordan databehandler skal håndtere personopplysninger på vegne av behandlingsansvarlig2].

Hvordan databehandler kan behandle personopplysninger er beskrevet i personopplysningsloven § 15 (Databehandlerens rådighet over personopplysninger). Hvordan databehandlingsansvarlige kan behandle opplysninger er blant annet beskrevet i personopplysningsloven § 11 (Grunnkrav til behandling av personopplysninger).

Figur 5 viser eksempel på en overordnet arkitektur for en skjemaløsning som ligger hos en ASP-leverandør.

4.5.1. Transaksjonslagring og mellomlagring hos skjemaleverandør

Når skjemaløsningen ligger som en ASP-løsning hos en leverandør er utgangspunktet at leverandøren opptrer som en databehandler som innhenter data (”datainnsamler”) på vegne av kommunen (behandlingsansvarlig). Dersom databehandleren skal ha en rolle utover enn en ren ”datainnsamler” må dette være i samsvar med blant annet personopplysningsloven § 11 (Grunnkrav til behandling av personopplysninger) og § 15 (Databehandlerens rådighet over personopplysninger). Hva databehandleren skal kunne gjøre av databehandling må også være beskrevet i databehandleravtalen.

Skjemaleverandør kan foreta transaksjonslagring av de opplysninger som sendes inn fra innbyggeren ved endt datafangst. Slik transaksjonslagring kan gjøres slik at skjemaleverandøren lagrer skjemadataene borgeren sender inn inntil kommunen kan bekrefte at dataene er korrekt mottatt fra skjemaleverandøren. Skjemaleverandøren kan lagre skjemadataene i maks 72 timer etter at en søknad er sendt (72 timer ansees som forvaltningspraksis) slik at det skal være rimelig tid til å oppdage eventuelle (tekniske) feil ved forsendelsen.

Skjemaleverandøren (som opptrer som ren datainnsamler og databehandler på vegne av kommunen) har i utgangspunktet ikke grunnlag for å lagre eller behandle personopplysninger på annen måte enn det som er beskrevet ovenfor. Et slikt grunnlag må eventuelt være begrunnet i personopplysningsloven § 11 (grunnkrav til behandling av personopplysninger). Dette betyr for eksempel at mellomlagring av et delvis utfylt skjema ikke kan gjøres så lenge dette ikke kan gjøres med grunnlag i personopplysningsloven § 11 og § 15.

4.5.2. Datahåndtering med og uten autentisering av borger

Skjemaleverandøren og den enkelte kommunen må bli enige om krav til autentisering av innbyggeren. Se mer i kapittel 3.3.5.

4.5.2.1. Retningslinjer vedrørende datafangst

Vi anbefaler følgende retningslinjer for datahåndtering (uavhengig om borgeren er autentisert eller ikke):

- Skjemaleverandøren kan lagre skjemadata i maks 72 timer etter at en søknad er sendt slik at det skal være rimelig tid til å oppdage eventuelle feil ved forsendelsen

- Data skal slettes hos skjemaleverandør når de er bekreftet korrekt mottatt hos kommunen (for eksempel ved hjelp av applikasjonskvitteringer mellom systemene som kommuniserer)

- Eventuelle vedlegg skal slettes etter at vedlegget er bekreftet korrekt mottatt av kommunen

- Borgeren må få kvittering fra skjemaleverandør ”vist på skjerm” når skjemaet sendes inn fra borgeren

- Skjemaleverandøren kan lagre metadata (”logger”) om skjemaene som er sendt, dette kan for eksempel være id (ikke fødselsnummer), type søknad, tidspunkt.

4.5.2.2. Med autentisering av borger

Dersom borger blir autentisert og samtykker til det kan en ved skjemautfylling tilby ”ekstratjenester” som for eksempel preutfylling av visse typer opplysninger.

Dersom innbyggeren er autentisert og har gitt sitt samtykke kan skjemaleverandøren tilby følgende til borgeren:

- Preutfylling av visse typer veldefinerte opplysninger (for eksempel adresseinformasjon) som hentes fra databehandlingsansvarliges (kommunen) registre

- Hvilke typer opplysninger som innhentes må presenteres for innbyggeren på forhånd og innbyggeren må gi sitt samtykke til dette før slik innhenting kan skje

- Vise logg over ”metadata”, for eksempel tidligere innsendte søknader

4.5.2.3. Uten autentisering av borger

Dersom borgeren ikke er autentisert skal alle data slettes etter at data er bekreftet korrekt mottatt av kommunen. Logg over metadata (id, type søknad, tidspunkt etc.) kan imidlertid lagres.

4.5.2.4. Teknisk lagring hos skjemaleverandør

Skjemaleverandøren må lagre skjemadataene på en sikker måte. Dette betyr blant annet at:

- Det skal være logiske skiller på data tilhørende ulike databehandlingsansvarlige (som i praksis som regel være en kommune).

o For eksempel i egne databaser for hver databehandlingsansvarlige

- Sensitiv informasjon skal krypteres ved lagring hos skjemaleverandør.

- Sensitiv informasjon skal lagres i en sikker sone hos skjemaleverandøren

4.5.3. Kvittering på innsendt skjema

Kvittering ”vist på skjerm” for innsendt skjema kan vises til innbyggeren når skjemaet er sendt inn. Kommunen bør sende også bekreftelse til innbyggeren via e-post når søknad er kommet frem til kommunen. Det bør også være mulig å få slik bekreftelse tilsendt på SMS for den som ønsker det. Kvitteringen må ikke inneholde noen opplysninger fra selve søknaden, men kan for eksempel inneholde et referansenummer til det innsendte skjemaet.

4.6. Datahåndtering når skjemaløsning ligger hos behandlingsansvarlig

Dersom skjemaløsingen ligger lokalt hos kommunen (dvs. i kommunens nettverk slik at kommunen har full kontroll over datafangsten) vil ikke skjemaleverandøren opptre som noen databehandler på vegne av kommunen. Kommunen vil da både ha rollen som databehandler og databehandlingsansvarlig.

4.6.1. Transaksjonslagring og mellomlagring hos kommunen

Kommunen kan foreta transaksjonslagring av de opplysninger som innhentes fra innbyggeren gjennom datafangsten. Slik transaksjonslagring kan gjøres slik at kommunen kan lagre skjemadataene i skjemaløsningen inntil de er korrekt overført til aktuelle system. Når data er overført til aktuelle systemer skal de slettes i skjemaløsningen[3].

Mellomlagring, for eksempel lagring av et delvis utfylt skjema, kan foretas av kommunen i rollen som behandlingsansvarlig så lenge dette kan gjøres blant annet begrunnet i basiskravene i personopplysningsloven § 11 (grunnkrav til behandling av personopplysninger).

4.6.2. Med autentisering av borger

Dersom borger blir autentisert kan en ved skjemautfylling tilby ”ekstratjenester” som for eksempel preutfylling av visse typer informasjon i et skjema.

Dersom innbyggeren er autentisert og har gitt samtykke til kan følgende tilbys innbyggeren:

- Kommunen kan mellomlagre data slik at innbyggeren kan fylle ut et skjema i flere sesjoner (med flere inn- og utlogginger)

o Krever autentisering på sikkerhetsnivå 3 eller 4 avhengig av type skjema (se anbefalinger i kapittel 3.3.5)

- Preutfylling av visse typer opplysninger (for eksempel adresseinformasjon) fra kommunens registre

o Hvilke typer opplysninger som kan innhentes må presenteres for innbyggeren på forhånd og innbyggeren må gi sitt samtykke til dette.

- Gjenbruke og vise data fra tidligere innsendte skjema dersom innbyggeren samtykker til at kommunen kan beholde kopi av innsendte skjema

o Krever at innbyggeren samtykker til at kommunen kan lagre kopi av innsendte skjema til senere gjenbruk i skjemaløsningen

o Det må være kjent hvor lenge kommunen kan beholde kopi av innsendte skjema, for eksempel 3 måneder. Kopi av innsendte skjemadata skal da slettes etter angitt tidsrom.

o Dersom gjenbruk av data omfatter sensitive opplysninger må borger autentiseres med en sikkerhetsløsning på sikkerhetsnivå 4. Dvs. at Minid ikke kan benyttes som autentiseringsløsning, men en må benytte for eksempel en PKI-løsning som tilfredsstiller kravene til sikkerhetsnivå 4.

4.6.3. Uten autentisering av borger

Uten innlogging fra innbyggeren skal skjemadata slettes etter at data er mottatt korrekt i kommunens fagsystemer.

4.7. Sikring av datakommunikasjon

For selve transportoverføringen av data mellom skjemaleverandør og kommunen er det flere forhold som bør ivaretas gjennom valgt metode. De viktigste mekanismene beskrives nedenfor.

4.7.1. Sikker datakommunikasjon

Overføringen av data mellom skjemaleverandør og kommune må krypteres for å ivareta krav til konfidensialitet. Kryptering kan i hovedsak skje på to måter:

Kryptert transportkanal innebærer at det etableres en sikker overføringslinje mellom skjemaleverandør og kommunen som brukes for å overføre data. Det er viktig å merke seg at data i en slik løsning vil være ubeskyttet når dataene kommer ut av den krypterte transportkanalen. Dersom man for eksempel har en kryptert transportkanal inn til en server i DMZ, så vil dataene ligge ukryptert når det overføres til serveren.

Kryptering av selve informasjonen innebærer at informasjonen som sendes over blir kryptert for eksempel vha. av virksomhetssertifikater i en PKI-løsning. Med slik meldingskryptering vil informasjonen ligge kryptert til man velger å dekryptere dataene.

4.7.2. Dataintegritet

Dataintegritet er den egenskapen at data ikke er blitt ødelagt eller endret på en ikke-autorisert måte. Ved datakommunikasjon bør mottageren være i stand til å oppdage om meldinger er blitt endret ved at aktivt inngrep eller ved et uhell. På et stadium må informasjonen forsegles slik at enhver påfølgende endring vil oppdages. Når vi verifiserer dataintegritet forsikrer vi oss om at det ikke har skjedd endringer i informasjonen etter at denne ble forseglet.

Digitale signaturer i en PKI-løsning kan for eksempel brukes til å verifisere at dataintegriteten er intakt.

4.7.3. Kvitteringsmekanismer

Kvitteringsmekanismer skal sørge for at avsender for kvittering for at en melding er kommet korrekt frem til mottaker, eller at det gis feilmeldinger dersom noe har feilet i forsendelsen.

4.7.4. Anbefalte transportmetoder

Vi anbefaler alle kommuner å velge en transportmetode som sørger for sikker og pålitelig overføring av data mellom skjemaleverandør og kommunen:

- E-post bør ikke velges som overføringsmetode pga. manglende kvitteringsmekanismer og dårlig sporbarhet

- FTP, http ebXML, eller webservices anbefales som overføringsmetode fremfor e-post fordi disse regnes som mer sikrere og mer pålitelige enn vanlig e-post. ebXML er en kanskje den beste metoden fordi den blant annet har innebygde funksjoner for kvitteringsmekanismer.

Uansett overføringsmetode må denne sikres vha. kryptering, autentisering av systemet etc.

4.7.5. Autentisering av systemene

Ved kommunikasjon mellom to systemer må en være sikker på at det er de riktige systemene som kommuniserer med hverandre. Noen anbefalinger er:

- Det må være autentisering av begge ender som sikrer at det kun er autoriserte systemer som kommuniserer med hverandre

- Autentisering skal skje med sikrere metoder enn bare passord, for eksempel med bruk av sertifikater hos begge parter

- Hos skjemaleverandøren må en sørge for at den enkelte kommune kun får lov til å hente data som tilhører kommunen (dersom dette er aktuelt for valgt overføringsmetode)

- Skjemaleverandøren må også sørge for at data skrives til riktig kommune (dersom dette er aktuelt for valgt overføringsmetode)

- Hos kommunen må en sørge for at kun skjemaleverandøren får til lov til å overføre data inn til kommunens nettverk (dersom dette er aktuelt for valgt overføringsmetode)

4.8. Datahåndtering hos kommunen

Datatilsynet har retningslinjer og anbefalinger for hvordan en kommune bør utforme sitt nettverk med tanke på sikker informasjonsbehandling [4]. Datatilsynet beskriver blant annet hvordan en kommune bør dele opp sitt nettverk i interne og sikre soner (gjerne kjent som ”tosone-modellen”). Figur 7 nedenfor viser et eksempel på hvordan en kommune kan utforme sitt nettverk med tanke på å få til en sikker nettverksarkitektur.

Figur 7: Mulig teknisk nettverksarkitektur for skjemaløsning på nett

Hovedregelen er at sensitiv informasjon skal behandles på et system som ligger i sikker sone, mens ikke-sensitiv informasjon kan behandles på system i intern sone.

I tillegg til soneinndelingen med tekniske sperrer mellom sonene er det også viktig med å sikre tilgangen til tjenestene som ligger på de ulike sonene. Dette kan for eksempel være tilgang til fagsystemer, filområder eller webservicestjenester.

4.8.1. Mottak av data i kommunen

Mottaket av skjemadata må sikres slik at kommunen ikke blir eksponert for unødige trusler knyttet mot datakommunikasjon mot skjemaleverandør:

- Det bør brukes en egen dedikert server som er konfigurert til å ta imot skjemadata fra skjemaleverandøren, jfr. Figur 7.

o Det bør vurderes å sikre tilgangen til en slik dedikert server for eksempel ved kun å tillate datakommunikasjon fra IP-adresser hos aktuell skjemaleverandør. I tillegg må det være autentisering av systemene.

o Det bør også vurderes å sette mottaket av skjemadata i en egen dedikert DMZ-sone slik tilgang til ”mottaksserveren” ikke kan misbrukes til å få tilgang til andre systemer

- Data må aldri lagres usikret i DMZ. DMZ må kun brukes som en ”mellomstasjon” hvor data kontrolleres og hentes videre inn til intern/sensitiv sone og aktuelle systemer

o Data skal krypteres så lenge de er i DMZ

o Dekryptering av data skal først skje når data skal hentes videre inn til intern sone, eventuelt at dekryptering skjer når data er kommet på innsiden av DMZ

o For sensitiv informasjon som skal til sikker sone er hovedregelen at disse dekrypteres først når data er i sikker sone (jfr. Kommuneveilederen fra Datatilsynet, kapittel 18.3.2 [4])

- Sjekk mot ondsinnet programvare

o All innkommende data må kontrolleres for ondsinnet programvare

o Skanning bør også skje hos avsender (skjemaleverandør)

o Skanning må gjøres etter at en data er dekrypteres for å kunne oppdage eventuell ondsinnet kode

o Vedlegg må også skannes

- Kommunen bør som generell regel alltid initiere datatrafikken inn til kommunens nettverk. Dette kan løses på flere måter

o Kommunen kan hente data fra skjemaleverandør (for eksempel vha. ftp eller webservices)

o Kommunen kan tillate trafikk (for eksempel filoverføring) inn til en dedikert server i DMZ hvor så kommunen henter data videre inn til aktuelle systemer

- Bør ha kvitteringsmekanismer som sendes fra kommunen til skjemaleverandør når skjemaet er mottatt i kommunen

o Og e-post til innbyggeren med bekreftelse fra kommunen om mottatt skjema + ev. referansenummer.

4.8.2. Eksempel på teknisk løsning

Eksempel på hvordan trafikken kan settes opp internt fra DMZ og videre innover i kommunens nettverk:

- En setter opp det interne nettverket med to DMZ-soner.

- På det første DMZ nettet setter man inn en reverse proxy. Denne vil da terminere all HTTPS trafikk fra eksterne brukere. Fordelen med dette er at man kun trenger et sertifikat uavhengig av hvor mange web servere på baksiden man ønsker å komme i kontakt med.

- Reverse proxy serveren setter så opp en HTTP forbindelse fra seg selv og videre inn mot webserveren på det andre DMZ nettet. Ved at denne trafikken går i klartekst (HTTP) kan man så benytte Web Security på brannmuren for å sikre seg mot uønsket tilgang.

- Fordelen med å gjøre det på denne måten er at oppsettet på webserveren kan være helt standard HTTP, uten kryptering, som igjen gjør at systemet vil bli enklere å administrere for Kommunen. På den andre siden kan Reverse Proxy'en benyttes som terminering når neste tjeneste skal på luften uten å installere/kjøpe nye sertifikater siden dette allerede finnes.

Se også Figur 7 for mulig nettverksarkitektur.

4.9. Tilgang og innsyn i data hos kommunen

Dersom kommunen tillater at data hentes ut fra egne systemer for tilgjengeliggjøring enten i egen innsynsløsning eller via Minside gjelder i utgangspunktet de samme sikkerhetsprinsippene som er beskrevet i kapittel 4.1.

Det blir enda viktigere å ha god kontroll og styring på hvem som får lov til å hente ut data i en slik setting. Dersom en for eksempel har en webservice som henter ut data fra et fagsystem bør en da blant annet sette krav til sterk autentisering vha. sertifikater/PKI-løsning fra den parten som skal benytter webservicen for å hente ut data. En slik webservices må også kjøres i et sikret miljø og være utviklet slik at den som benytter webservicen ikke kan utnytte svakheter i tjenesten til å hente ut mer eller andre data enn det som er tiltenkt.

Figur 8: Eksempel på nettverksarkitektur for innsynsløsning

En innsynsløsning må utformes slik at den på en sikker måte henter ut riktige data til autentisert borger (eller et autentisert system):

- Borgeren logger for eksempel på en portalløsning og får innsyn i ”sine saker” i henhold til sikkerheten på påloggingen (for eksempel Minid på nivå 3 eller en PKI-løsning på nivå 4)

o Informasjonen kan for eksempel være status på behandling av et skjema eller det vedtaket som er fattet

o Bruk av autentiseringsløsning på nivå 4 hos borgeren vil kunne gi innsyn til sensitiv informasjon, mens en autentiseringsløsning på nivå 3 hos borgeren vil bare gi tilgang til ikke-sensitiv informasjonen

- Kun den borgeren som er autentisert som avsender kan få elektronisk innsyn i ettertid til samme skjema/sak

- Kommunen må ha god kontroll på hvordan dataene hentes ut

o For eksempel at dette skjer gjennom en egen DMZ-sone for innsynsløsningen hvor det er streng kontroll på trafikken inn og ut, jfr. Figur 8.

o Kommunen må ved en innsynsløsning ikke unødig eksponere andre interne systemer som eventuelt kan utnyttes av ondsinnede angrep via innsynsløsningen

o Innsynsløsningen bør ikke ha muligheter til kommunikasjon mot andre systemer enn det som er nødvendig for å få hentet ut data fra kommuneno Innsynsløsningen bør være så ”isolert” så mulig slik at eventuelle ondsinnede angrep får minst mulige konsekvenser

Anbefalinger:
- Kommunen må sørge for sikker autentisering og løsninger som sørger for at data kan hentes ut fra kommunen på en trygg og sikker måte
- Innsynsløsningen må være utformet slik at den ikke unødig eksponerer andre systemer eller annen informasjon enn det som er nødvendig for selve innsynsløsningen

Figur 9: Eksempel på skjemaflyt for innsyn

Videre problemstillinger rundt tilgang og innsyn

En aktuell problemstilling som dukker opp vedrørende innsyn er hvem som skal få innsyn for eksempel til et vedtak. Slike problemstillinger kan for eksempel være:- Far har elektronisk søkt barnehageplass for et barn, skal mor også få elektronisk tilgang til statusopplysninger og vedtak etc. om søknaden? Hvordan slike problemstillinger kan løses har både tekniske (hvordan) og juridiske (hva er lovlig) problemstillinger som må vurderes og avklares før slike løsninger kan etableres. Sikkerhetsgruppen har ikke vurdert slike problemstillinger i prosjektet, men påpeker at dette er et område for videre arbeid.

4.10.Tilbakemelding fra kommune til borger

Informasjon fra kommunen tilbake til borger vedrørende et innsendt skjema kan skje på følgende måter (her kan det være flere løsninger som ikke beskrevet):

Tabell 3: Oversikt over tilbakemeldinger til borgeren