3 Anbefalinger til autentisering av borger

Kapitlets innhold:

3. Anbefalinger til autentisering av borger. 11

3.1. Aktuelle autentiseringsmekanismer 11

3.1.1. Kort om Minid. 11

3.1.2. Kort om PKI. 12

3.2. Problemstillinger rundt datafangst og autentisering. 12

3.2.1. Datafangst, skjemautfylling. 12

3.2.2. Innsyn i egen sak hos kommunen. 14

3.3. Krav til autentisering av borger 14

3.3.1. Mulige trusler ved datafangst 14

3.3.2. Mulige trusler ved innsyn. 16

3.3.3. Konsekvenser dersom sensitive opplysninger skal håndteres. 16

3.3.4. Hva omfatter datafangsten. 17

3.3.5. Anbefalinger til autentisering av innbyggeren. 17

3.4. Skjema som har krav til utfylling fra flere enn en part 20

3.5. Krav til elektronisk signatur fra borger 21

3.6. Risikovurdering av skjemaløsningene. 22

Autentisering av innbyggeren er en viktig del av informasjonssikkerheten for "skjema på nett". Dette kapitlet vil beskrive problemstillinger og komme med anbefalinger til autentiseringskrav både ved datafangst og innsyn.

3.1. Aktuelle autentiseringsmekanismer

Det er flere autentiseringsmekanismer som kan brukes for å verifisere at innbyggeren er den han utgir seg for å være. I dette dokumentet er det to ulike mekanismer som vurderes:

1. Borgeren blir autentisert på sikkerhetsnivå 3 vha. Minid eller tilsvarende

2. Borgeren blir autentisert på sikkerhetsnivå 4 vha. en PKI-løsning eller tilsvarende

Autentiseringsløsninger med bare selvvalgte brukernavn/passord og lignende er ikke omhandlet i dette dokumentet da de generelt sett ansees å gi for lav sikkerhet til at faggruppen for sikkerhet ønsker anbefale dem for utbredelse til noen anvendelser rundt skjemaløsninger på nett.

3.1.1. Kort om Minid

Minid er en autentiseringsmekanisme utviklet for offentlig nettsteder. Minid muliggjør at innbyggerne kan logge seg på ett nettsted med Minid og sikkert bevege seg mellom offentlig nettsteder (tjenesteleverandører) uten å måtte gjenta pålogging.

Minid kan også benyttes som autentiseringsløsning på egen portal. Dvs. en kommune eller en etat kan bruke Minid som autentiseringsløsning for sitt eget nettsted. Den eneste forutsetning er at alle relevante tjenester også tilbys i Minside.

Minid består i dag av følgende faktorer:

- Fødselsnummer (brukernavn)

- Selvvalgt passord

- Engangs PIN-kode (enten engangskode fra tilsendt skattekort eller engangskode tilsendt vis SMS)

Styrker ved Minid:

- En nasjonal løsning som er utbredt til alle borgere som får tilsendt skattekort

- En felles løsning som for eksempel alle kommuner kan ta i bruk for autentisering

Svakheter ved Minid:

- Masseutsendelse av engangskoder i form av PIN-koder på skattekortet kan føre til at uvedkommende får tilgang til engangskoder

- PIN-koder distribueres sammen med fødselsnummeret (som fungerer som brukernavn ved bruk av Minid)

- Er kun på sikkerhetsnivå 3 og kan kun brukes for tilgang til ikke-sensitiv informasjon

- Er kun en autentiseringsløsning, har ikke funksjoner for eksempel for elektronisk signering

3.1.2. Kort om PKI

PKI står for Public Key Infrastructure og omfatter infrastruktur og tjenester for sikring av informasjonsutveksling og tilgang til systemer:

- elektronisk signering av dokumenter

- autentisering (sikker identifisering) av kommunikasjonsparter eller brukere av systemer

- sikring av integritet og konfidensialitet ved overføring/utveksling av informasjon(kryptering)

- Ikke-benekting (innholdet knyttes bindende til avsender, som regel i forbindelse med personlig elektronisk signatur)

PKI er ikke en teknologi i seg selv i form av programvare eller maskinvare. PKI er en beskrivelse av en infrastruktur der private og offentlige nøkler benyttes for å muliggjøre sikker elektronisk kommunikasjon mellom flere aktører. Hvordan selve infrastrukturen i en PKI er sammensatt, dvs. hvilke aktører som er med i infrastrukturen, er ikke entydig bestemt, men kan variere fra sted til sted (f.eks. fra land til land), og over tid.

Styrker ved PKI:

- Kan gi autentisering på sikkerhetsnivå 4 og kan brukes for tilgang til sensitiv informasjon

- En PKI-løsning kan også gi støtte for elektronisk signering

Svakheter ved PKI:

- Er pr. i dag en lite utbredt løsning hos borgere (men får større utbredelse blant via BankID og BuyPass)

- Krever en fysisk gjenstand (for eksempel smartkort) dersom det skal være en sterk PKI-løsning

3.2. Problemstillinger rundt datafangst og autentisering

Dette dreier seg om to delvis separate problemstilinger:

1) Utfylling og innsending av skjema til kommune ved hjelp av skjemaløsning hos ASP, og der skjema (eller vedlegg) kan inneholde sensitiv personinformasjon.

2) Innsyn i egen sak hos kommunen, der saksdokumentene kan inneholde sensitiv personinformasjon. Innsyn skjer gjennom Minside eller kommunal portal.

Disse to diskuteres hver for seg nedenfor.

3.2.1. Datafangst, skjemautfylling

Dagens portalløsninger for utfylling av skjema har tilgang i klartekst til all informasjon som legges inn tilknyttet et skjema. (Løsninger som tilbyr ende-til-ende kryptering fra brukeren til kommunen, er mulig, men finnes ikke tilgjengelig i dag.)

Sensitiv informasjon kan være knyttet til:

- Informasjon som fylles ut i et søknadsskjema (for eksempel sosialstøtte).

- Det at en person i det hele tatt fyller ut et skjema (igjen for eksempel sosialstøtte).

- Vedlegg til en søknad - dette kan være hvilken som helst søknad (for eksempel er søknad om barnehageplass normalt ikke sensitiv, men dersom barnets helsetilstand brukes som grunn til prioritert plass, kan et vedlegg som dokumenterer dette, gjerne ha sensitive personopplysninger).

Dersom personopplysninger (også sensitive opplysninger av en eller annen grad) skal kunne gis inn i skjema eller som vedlegg til skjema, er det en del ting å merke seg:

- Kommunen er behandlingsansvarlig for opplysningene.

- Siden ASP har tilgang til opplysningene, må det inngås en databehandleravtale med kommunen før sensitive personopplysninger kan legges inn via skjemaløsningen.

- Søkeren må identifiseres med fødselsnummer - enten ved at personen oppgir dette selv eller ved at det skaffes på annen måte (for eksempel basert på en eID som personen bruker). Merk at fødselsnummer er et brukernavn for personen, ikke et passord som kan brukes for a autorisere tilgang.

- Normalt gjør en i dag ikke autentisering av personen som del av søknadsprosessen. En antar at den som er identifisert i søknaden, er korrekt person. Dersom noe er feil her (noen har sendt inn søknad i en annens navn), vil det bli avdekket i saksbehandlingen eller når vedtak skal meddeles. Dette bygger på at risikoen for «falsk søknad» er liten.

- Dersom en søknad inneholder sensitive personopplysninger krever dette kryptering av enten informasjonen eller transportkanalen. I tillegg kan det hende at kommunen ønsker en sterkere verifisering, gjerne på et tidlig tidspunkt, av at søkeren er den han/hun gir seg ut for å være. Dette kan gjøres gjennom at autentisering (det vil si elektronisk signatur i en utvidet betydning av det begrepet) kreves, eller ved at saksbehandlingsprosedyrene inneholder rutiner for å verifisere en søknad manuelt som del av prosessen.

- Dersom en skal kreve autentisering, må en ha en autentiseringsmetode. Administrasjon av egne brukernavn og passord er neppe regningssvarende, og statiske passord vil gjerne bli regnet som for svak mekanisme for sensitive personopplysninger. Bruk av engangspassord (dagens Minid) eller en PKI-basert eID er mulig dersom dette er integrert hos ASP-en. Disse autentiseringsmetodene vil også gi fødselsnummer for personen.

Det store spørsmålet knyttet til bruk av ASP og håndtering av sensitive personopplysninger er hvor stor grad av separasjon som vil kreves hos ASP for løsningen for denne kommunen, i forhold til løsninger for andre kunder hos ASP-en. Det er et viktig prinsipp at sensitive personopplysninger bare skal kunne være tilgjengelig for de som er autorisert for det, og at det skal være separasjon både i forhold til andre systemer i egen organisasjon (dvs. i kommunen) og spesielt i forhold til andre organisasjoner.

Dette kan komme i konflikt med en effektiv implementering av en skjemaløsning, der samme skjema brukes for en hel rekke kommuner, og identifikasjon av kommunen er det som skiller når en søknad skal rutes videre. I en del tilfeller har det vært ønske om fysisk separate løsninger for forskjellige organisasjoner, men det er klart lite hensiktsmessig med en fysisk installasjon av skjemaportal for hver kommune.

Spørsmålet er da i hvor stor grad ASPen kan sørge for logisk skille mellom informasjon tilhørende forskjellige kommuner? Dette er et element som må beskrives i databehandleravtalen mellom kommunen og ASP og som bør være risikovurdert.

Det neste, store spørsmålet er hvordan kommunen mottar søknadene fra ASP. Igjen skal sensitive personopplysninger holdes separat fra annen informasjon og være tilgjengelig bare for dem som er autorisert for det. Det er mulig at en kommune bør sørge for at alle sensitive søknader og alle søknader med vedlegg (siden vedleggene potensielt kan holde sensitiv informasjon) bør sorteres ut og rutes separat til egne systemer og personer som er klarert for dette, heller enn at alle søknader mottas på samme sted. Dette må også håndteres korrekt hos ASP.

Autentisering av ASP og kommunens systemer og beskyttelse av trafikken mellom dem anses ikke for å være noen stor utfordring.

3.2.2. Innsyn i egen sak hos kommunen

Tilgang her antas skjer gjennom kommuneportal eller Minside. Det antas også at dagens versjon av Minside redirigerer brukeren direkte til den linken informasjon skal hentes fra, slik at det ikke passerer sensitiv informasjon gjennom Minside. Dette bør også gjelde for eventuelle andre portalløsninger som formidler tilgang til saksinformasjon, slik at de redirigere heller enn å videreformidle informasjonen (så lenge løsninger for ende-til-ende kryptering ikke er i bruk). I dette tilfellet bør det ikke være nødvendig med noen spesiell avtale med portalen.

I dette tilfellet trengs helt klart en autentiseringsløsning. Minid (engangspassord) holder for de fleste typer personopplysninger, mens "person-høy" PKI-basert eID vil som hovedregel være påkrevd for tilgang til sensitiv informasjon.

Igjen er det viktig at sensitive personopplysninger holdes separat og bare med tilgang for autoriserte personer. Dette er helt klart en utfordring når det gjelder tilgang gjennom en innsynsløsning hos kommunen.

3.3. Krav til autentisering av borger

Ser man isolert bare på autentiseringen av innbyggeren er det i hovedsak to risikoområder:

1. At innbyggeren oppgir falske opplysninger ved innsending (datafangst) av en søknad

2. At en borger får innsyn i informasjon tilhørende en annen borger

Disse to risikoområdene er beskrevet nedenfor.

1.3.1. Mulige trusler ved datafangst

Borger oppgir falske avsenderopplysninger ("ID-tyveri")
Det kan tenkes situasjoner der en borger har interesse eller motivasjon av å sende i en søknad eller et skjema i en annen innbyggers navn, selv om det ikke vises til konkrete eksempler på dette i dette dokumentet. Sannsynligheten for at dette skjer er nok lav pr. i dag og dette oppleves ikke som et problem i kommunene i dag.

Samtidig er ID-tyveri er generelt økende problem og det må nok erfaringsmessig regnes med at også misbruk for elektronisk kommuneskjema vil forekomme når slike skjemaer gjøres elektronsk tilgjengelige for innsending i økende grad. På denne bakgrunn kan det være fornuftig for den enkelte kommune å kreve autentisering av borgeren ved innsending av skjema. Dette vil redusere risikoen for misbruk både for kommunen og for den enkelte borger.

Borger oppgir falske opplysninger i skjema

Det kan tenkes at en borger oppgir falske eller uriktige opplysninger i en søknad eller et skjema for å få tilgang til en viss type tjeneste, støtte eller lignende fra kommunen. Uten autentisering av innbyggeren har en i utgangspunktet liten reell mulighet til å kunne sjekke hvem som var den faktiske innsenderen av en søknad eller et skjema. Dersom en borger blir mistenkt for å ha oppgitt falske eller uriktige opplysninger, kan dermed innbyggeren nekte for at det var han som sendte inn de aktuelle opplysningene.

Dersom innbyggeren var autentisert med for eksempel Minid er det langt vanskeligere for innbyggeren å nekte for eller motbevise at det ikke var han som sendte inn opplysningene i et skjema eller en søknad. Å kreve autentisering ved innsending av opplysninger vil sannsynligvis også føre til at det er færre som "tar sjansen" på å sende inn falske/uriktige opplysninger med viten og vilje.

For søknader/skjema som krever store behandlingsressurser fra kommunen og/eller hvor innbyggeren kan ha motiv/motivasjon til å sende inn uriktige opplysninger, så ønsker kanskje en kommune å være mest mulig trygg på at opplysningene er korrekte. I slike tilfeller kan autentisering av innbyggeren også ved innsending være en metode for kommunen å sikre at det er rimelig stor grad av sikkerhet for at opplysningene er korrekte.

Vurderinger av den enkelte kommune

Det er opptil den enkelte kommune å avgjøre hvorvidt den ønsker å kreve autentisering eller ikke ved innsending av skjema eller søknader. Det er i hovedsak kommunen som har risikoen ved mottak av søknader og skjema fra innbyggeren, så den enkelte kommune må vurdere hvor trygg den ønsker å være på at den mottar korrekte opplysninger fra riktig borger.

3.3.2. Mulige trusler ved innsyn

Uautorisert tilgang til informasjon

At opplysninger om en borger skal komme på avveie og bli tilgjengeliggjort for uvedkommende er den store trusselen når en snakker om innsynsløsninger for innbyggerne. Den enkelte kommune må derfor ha gode løsninger på dette området før den enkelte borger kan gis innsyn i egne opplysninger.

Vurderinger av den enkelte kommune

Mens truslene ved datafangst/innsending i hovedsak rammer kommunen, så rammer truslene ved innsyn også den enkelte borger blant annet fordi at egne opplysninger kan komme på avveie. Hensynet til den enkelte borger bør veie tyngst her slik at ingen kommuner må legge til rette for innsynsløsninger før hensynet til innbyggerne er godt nok ivaretatt.

I praksis betyr det at kommunene må ha autentiseringsløsninger på nivå med Minid eller bedre før innbyggerne kan gis innsyn til egne opplysninger.

3.3.3. Konsekvenser dersom sensitive opplysninger skal håndteres

Enkelte skjema/søknader er lagt opp til å kunne inneholde sensitive opplysninger, mens andre skjema/søknader i utgangspunktet ikke skal inneholde sensitive opplysninger.

3.3.3.1. Ved datafangst

Ved ren datafangst og innsending av opplysninger fra innbyggeren vil ikke innhold av sensitive opplysninger eller ikke gi noen automatisk føringer for kravet til autentisering av innbyggeren. Så lenge transportsikkerhet, datahåndtering hos skjemaleverandør, mottak av data i kommunen etc. er godt nok ivaretatt, så vil ikke sensitive opplysninger automatisk legge føringer for høyere krav til autentisering. Transportsikkerhet, mottak av data i kommunen etc. er uansett forhold som må være ivaretatt fordi det er vanskelig å hindre at en borger for eksempel oppgir sensitive data i et fritekstfelt.

Det kan være at skjema som skal kunne inneholde sensitive opplysninger generelt krever en mer omfattende behandlingsprosess hos kommunen, og at kommunen av slike årsaker ønsker å vite med stor grad av sikkerhet hvem som er avsender. En kommune vil derfor kunne sette krav til autentisering av innbyggeren ved innsending av skjema/søknader som skal kunne inneholde sensitive opplysninger.

3.3.3.2. Ved innsyn

Ved innsyn til egen informasjon vil innsyn til sensitive opplysninger kreve et høyere sikkerhetsnivå med tanke på autentisering av innbyggeren. Ved tilgang til sensitive opplysninger anbefales det autentiseringsløsninger som PKI eller med tilsvarende på sikkerhetsnivå 4.

3.3.4. Hva omfatter datafangsten

Krav til autentisering ved datafangt må sees i sammenheng med den totale informasjon en får tilgang til ved utfylling av et skjema. Eksempelvis kan tilgang til karttjenester med detaljert informasjon gjøre at kravet til autentisering øker i forhold til bare tilgang til et "tomt" skjema.

Den enkelte kommune må derfor selv vurdere krav til autentisering ved datafangst basert på den informasjonen som skjemautfylleren får tilgang til.

3.3.5. Anbefalinger til autentisering av innbyggeren

Kravet til autentisering må sees i sammenheng med hvordan den totale saksbehandlingen i kommunen foregår. En "heldigitalisert" saksbehandling hvor all kommunikasjon mellom borger og kommune foregår elektronisk vil sannsynligvis ha større krav til autentisering enn en "halvdigitalisert" saksbehandling. Dersom for eksempel bare innsendingen skjer elektronisk og videre kommunikasjon med borgeren skjer på vanlig post og/eller fysisk oppmøte vil dette kunne redusere behovet for autentisering i datafangsten.

Det sentrale er at kommunen i løpet av saksbehandlingen må autentisere borgeren slik at kommunen vet med nødvendig grad av sikkerhet hvem den snakker med. Og en slik autentisering kan skje elektronisk allerede ved datafangst eller senere i saksbehandlingen gjennom vanlig post sendt til borger eller krav om fysisk oppmøte.

Skjemaene er i denne sammenhengen delt inn i to grupper hvor skillet er om skjemaene er tenkt å kunne inneholde sensitiv informasjon eller ikke. Anbefalingene er gjort for 15 skjema som har vært prioriterte i prosjektet "Tjenester på nett".

3.3.5.1. Gruppe 1 - skjema som ikke skal inneholde sensitiv informasjon

Skjema som det ikke er lagt opp til skal inneholde sensitive opplysninger:

- Rekvisisjon av kartforretning

- Søknad Kulturskole

- Melding om tiltak[1]

- Gravemelding

- Svar offentlig høring

- Tilskudd til kulturformål

- Bestilling av avfallsbeholder

- Skjenkebevilling

3.3.5.2. Gruppe 2 - skjema som kan inneholde sensitiv informasjon

Skjema som potensielt kan inneholde sensitive opplysninger (dvs. at skjemaet har fritekstfelter for "Andre opplysninger" eller lignende):

- Søknad barnehageplass

- Søknad SFO

- Lærerstilling/ ledig stilling

Skjema hvor det konkret etterspørres etter sensitive opplysninger:

- Ledsagerbevis

- Søknad Pleie- og omsorgs­tjenester

- Parkeringstil­latelse med legeattest

- Søknad om sosialstøtte

NB: Det er viktig å merke seg at her kan det være lokale variasjoner/forskjeller mellom skjemaene som kan gjøre at inndelingen ovenfor ikke stemmer. Hver enkelt må derfor ha kontroll på hvilke opplysninger som en kan forvente å motta i det enkelte skjema.

3.3.5.3. Metode for å vurdere krav til autentisering

Det er benyttet et rammeverk fra FAD [1] for å vurdere krav til autentisering av innbyggeren. Med bakgrunn i rammeverket har det blir utarbeidet en egen mal som har vært benyttet for å vurdere kravene til autentisering av innbyggeren. Malen finnes i "Vedlegg C - Mal for vurdering av krav til autentisering".

3.3.5.4. Autentisering ved datafangst

Tabell 1 nedenfor viser en oversikt over anbefalinger til autentisering av borger ved datafangst. Det er i tabellen også tatt med om det enkelte skjema kan ha vedlegg og om det har felt for fødselsnummer.

Det anbefales her i utgangspunktet at borgeren blir autentisert for en del av skjemaene som sendes inn. Dette gir:

1) Trygghet for kommunen om hvem avsender er

2) Trygget for borgeren og kommunen ved at det er mindre risiko for misbruk av skjemaløsningen (falske søknader etc.)

Den enkelte kommune må selv velge om en ønsker å følge anbefalingene i dette dokumentet eller om man velger andre krav til autentisering for de ulike skjemaene. Ved innsending kan det også være aktuelt å bruke et lavere sikkerhetsnivå for autentiseringen enn nivå 3 dersom kommunen/skjemaleverandøren har tilrettelagt for dette. Slike valg må da eventuelt være gjennomtenkte valg fra kommunens side og begrunnet i gjennomførte risikovurderinger.

Det kan også være andre skjema som ikke er vurdert i dette dokumentet hvor det ikke er behov for samme grad av autentisering ved innsending.

Tabell 1: Oversikt over krav til autentisering ved datafangst

3.3.5.5. Autentisering ved innsyn

Tabell 2 nedenfor viser en oversikt over anbefalinger til minstekrav til autentisering av borger ved skjemainnsyn. Det tas her utgangspunkt i at innsyn omfatter innsyn til alle data som potensielt kan registreres for et skjema.

Hovedregelen for innsyn er vurdert til at innsyn til kun ikke-sensitive opplysninger krever sikkerhetsnivå 3 (Minid), mens innsyn til data som kan omfatte sensitive opplysninger krever sikkerhetsnivå 4 (for eksempel PKI-løsning).

Tabell 2: Oversikt over krav til autentisering ved innsyn

3.4. Skjema som har krav til utfylling fra flere enn en part

Dersom et skjema krever utfylling fra flere enn en part er dette en ekstra utfordring å få til elektronisk. Eksempel på slike skjema er for eksempel ByggSøk og gravemelding. Mulige løsninger kan være både elektroniske/manuelle eller elektroniske:

Mulig elektronisk løsning:

- Den elektroniske løsningen må utformes slik at flere enn den parten som sender inn skjemaet kan gå inn på aktuell del av skjema og fylle ut "sin del".

- Det bør da være logiske sjekker slik at for eksempel et skjema ikke kan sendes inn før alle parter har fylt ut sine deler obligatoriske deler.

Mulig manuell løsning:

- Part nr 2 sender inn sin del av skjemaet på papir med referanse til elektronisk skjema som er innsendt av part nr 1 (krever at kommunen manuelt må koble sammen elektronisk søknad med papirsøknad).

For mer informasjon om utfordringer rundt problemstillingene skissert ovenfor så har Statskonsult utredet disse problemstillingene rundt ByggSøk [7].

3.5. Krav til elektronisk signatur fra borger

Det er ikke vurdert detaljert i hvilke situasjoner det stilles krav til elektronisk signatur fra borger i henhold til lov- og regelverk. Når det er behov for en elektronisk signatur fra borgeren er i stor grad en juridisk vurdering og dette området har ikke prosjektgruppen hatt ressurser til å behandle i noen særlig grad.

En har i dag i hovedsak tre nivåer av elektroniske signaturer [8]:

- Elektroniske signaturer: Alle metoder som knytter en aktør til en handling eller spesifikk informasjon

o Aktør (vanligvis person) må være autentisert

o Handling (for eksempel innsending) bør være eksplisitt og valgt av aktøren

o Logger sørger for sporbarhet

o Minid og FEIDE er to løsninger som kan brukes til elektronisk signatur

- Avanserte elektronisk signaturer: Sikker knytning mellom signatur og informasjon slik at endringer kan oppdages. Bare signerer skal kunne ha tilgang til signeringsmetode.

o Eneste teknologi i dag er digital signatur med PKI-basert eID

o Buypass, BankID, Commfides, ZebSign er eID-løsninger i markedet som kan brukes til avansert signatur

- Kvalifiserte elektronisk signaturer: Avansert signatur med tilleggskrav til utsteder av eID(kvalifisert eID) og til signeringsutstyr.

o Gir Garantert rettsvirkning som håndskrevet signatur etter Esignaturloven

o Kvalifisert signatur finnes ikke i det norske markedet i dag, det er ingen godkjente signeringsverktøy. Dvs. i teorien finnes det ikke noe som gir garantert rettsvirkning

Det er i utgangspunktet få formkrav[6] i regelverket til elektronisk signatur. Det er i stor grad opptil den ansvarlige å vurdere bevisbehovet i forholdet til kravet om elektronisk signatur. Det handler i stor grad om hvor sikker man vil kunne påvise at en bestemt borger har sendt inn en bestemt informasjonsmengde på et gitt tidspunkt (krav til "ikke-benekting"). Eksempelvis hvor sterke bevis en kommune ønsker å ha dersom det skulle ble en tvist mellom kommunen og innbyggeren (og i verste fall dersom det skulle bli en rettsak).

Elektroniske signaturer er generelt lite utbredt pr. i dag, men innen helsesektoren kreves det bruk av avansert elektronisk signatur for innsending av elektronisk sykmelding blant annet fordi en slik sykmelding utløser et økonomisk ansvar.

På sin enkleste form kan en se for seg at en elektronisk signatur kan være prosessen hvor en borger blir autentisert og sender inn data:

"autentisering à utfylling à bekreftelse à innsending"

Vha. av logger og lignende vil en i ettertid med en slik signaturløsning i hvert fall til en viss grad av sikkerhet kunne legge frem "bevis" for at en bestemt borger utførte en gitt handling (innsending) og hvilken informasjon som ble sendt inn. For enkle tjenester som for eksempel barnehagesøknad og lignende bør dette være godt nok pr. i dag, men hver enkelt kommune må vurdere hvor sterke bevis de ønsker å legge til grunn for sin saksbehandling. Dersom en kommune ønsker større grad av sikkerhet for hva en borger har sendt inn så vil det kunne kreve bruk av avanserte elektroniske signaturer eller kvalifiserte elektroniske signaturer.

For mer informasjon rundt elektroniske signaturer og elektroniske søknader vises det til rapport fra Statskonsult som har vurdert dette i forhold til elektroniske byggesøknader[7]. Se også Sikkerhetsrammeverk fra faggruppen for sikkerhet for mer informasjon [2].

Anbefalinger for bruk av elektronisk signatur:

- Den ansvarlige må i stor grad selv vurdere bevisbehov og andre relevante faktorer og avgjøre når det er behov for elektroniske signaturer og nivået til selve signaturen (jfr. de tre nivåene presentert ovenfor).

- Som en generell regel kan det sies at "Der offentlig myndighet utøver en handling ovenfor en borger, for eksempel at det foretas inngrep i borgers rettigheter eller plikter, og hvor ikke-benekting er av betydning, bør elektroniske signaturer (basert på kvalifiserte sertifikater) benyttes".

3.6. Risikovurdering av skjemaløsningene

Når det gjelder risikovurdering av selve skjemaløsningene bør dette gjøres i samarbeid av den enkelte kommune og skjemaleverandøren. Et eksempel på en mal for slik risikovurdering finnes i Vedlegg D - Eksempel på risikovurdering av skjemaløsning hvor det også er vist eksempler på noen aktuelle trusler.

For gjennomføring av risikovurderinger henvises det til Datatilsynet sin veileder for risikovurderinger [3].

[1] Dette skjemaet kan krever samtykke/bekreftelse fra E-verket og/eller Televerket

[2] Dette feltet angir om et "standardskjema" slik det ser ut pr. i dag er lagt opp til å kunne ha vedlegg knyttet til seg

[3] Dette feltet angir om et "standardskjema" slik det ser ut pr. i dag krever fødselsnummer

[4] Dette feltet angir om et "standardskjema" slik det ser ut pr. i dag er lagt opp til å kunne ha vedlegg knyttet til seg

[5] Dette feltet angir om et "standardskjema" slik det ser ut pr. i dag krever fødselsnummer

[6] Nærings- og handelsdepartementet har i eRegelprosjektet fra 2001 oppsummerert en del om kravene som står i regelverket (VederRe-prosjektet / eRegelprosjektet)