Felles infrastruktur for elektronisk ID i offentlig sektor

Transkript

1 Felles infrastruktur for elektronisk ID i offentlig sektor Forelesning, FINF4001, 2. november 2010 Disposisjon Kort om teknologien etc. hva er alt dette? Medaljens forside ; ID-porten (og dens forgjengere) Regelverket og de sentrale dokumentene Aktørene Anvendelsesområder Medaljens bakside ; noen kritiske betraktninger Sikkerhetsnivåenes utvikling: har man egentlig senket lista? Forholdet mellom risikohåndtering og fastlagte sikkerhetsnivåer Trøbbelet med å autentisere virksomheter Kobling til organisasjonsnummer eller til en installasjon? Fullmaktsforhold innen en virksomhet 1

2 Litteratur Pensum stoff som belyser eid-problemstillinger EFN, kap. 12 (DeBrisis, Elektronisk ID ) Høringsrapport, Strategi for eid og e-signatur i offentlig sektor Autoritative dokumenter status quo for de infrastrukturvalg som gjelder (for hjemmelskjedens skyld: fvl 15a, esignl. 5 og 16a) eforvaltningsforskriften ( nr 988) Forskrift om selvdeklarasjonsordninger ( nr 1296) Kravspesifikasjon for PKI i offentlig sektor (v. 2.0, juni 2010, gyldig fra 23. september 2010) henvist til i forskrift FAD retningslinje: Rammeverk for autentisering og uavviselighet i elektronisk kommunikasjon med og i offentlig sektor (En kort intro i en liten parentes; tre forskjellige typer kryptering) Symmetrisk Samme nøkkel for å kryptere og å dekryptere Basert på en delt hemmelighet, løser ikke problemene med å kommunisere med ukjente En-veis kryptering, hash-funksjon Ikke meningen å kunne dekryptere innholdet! Velegnet for å vurdere meldingens integritet, men du får ikke vite hva avsenderen egentlig sier PKI, assymetrisk kryptering/dekryptering Nøkkelpar, offentlig og privat nøkkel umulig å finne ut hvilken privat nøkkel som kan dekryptere innhold som ble kryptert med den offentlige nøkkelen 2

3 Hva er elektronisk ID? Grunnproblemet: Kommunikasjon mellom ukjente Hvem er vedkommende, og hvordan kan jeg vite det? Hvilken handlingsevne/fullmakter har vedkommende? Kan avsender nekte for å ha sendt dette? Er det jeg mottar = det vedkommende sendte? Er begge parter sikre på at konfidensialiteten kan ivaretas? Hvor sikker må jeg være? Elektronisk ID kan ses som en slags samlebetegnelse på et knippe teknologier, og tilhørende regelverk og organisering rundt dette Begrepet elektronisk signatur Definisjon, i esignaturloven 3 nr. 1: elektronisk signatur: data i elektronisk form som er knyttet til andre elektroniske data og som brukes som autentiseringsmetode personen Signaturverifisering Kommunikasjons- Part Fødselsnr. F.reg. identitetsforvalter Brreg Org.nr. 3

4 Elektronisk ID Autentisere: Selve ID-en (jf. esignl. elektronisk signatur ) Sertifikat som ikke er identisk med fødselsnummer, men som kan knyttes til et fødselsnummer Utstederen kvalitetssikrer denne koblingen Signere: Sertifikater for angitt handlingsevne Content commitment, styrken på koblingen eid handling Ikke-benekting som betegnelse på sterk content commitment Kryptere: PKI-basert nøkkelforvaltning Tillitskjede Dine sertifikater viser til utstederens sertifikater, begge må være gyldige osv. Krav til utstedere; robust organisering, driftskontinuitet, sikkerhet Problemene med å eid-er på lufta Beskjeden utvikling av sektorvise anvendelser Eks. innrapportering fra leger til Rikstrygdeverket Mange etater la opp til enklere løsninger Fødselsnummer som kvasi-autentisering Selvvalgte brukernavn og passord Fødselsnummer som brukernavn, tildelte passord/engangskoder Alle ventet på alle Kritisk masse, nok brukere og tjenester til et selvgående marked Krav om eid som felles infrastruktur men skal myndighetene være fødselshjelp eller curling-foreldre? Forretningsmodell maks eller regulert bruk? 4

5 Ikke alle offentlige tjenester har like høyt beskyttelsesbehov For eksempel innen trygdeetaten, ca : Elektroniske sykemeldinger/legeerklæringer: PKI/smartkort Innmelding av opplysninger til AA-registeret: Enkelt passord Skifte av fastlege: Kvasi-autentisering med fødselsnummer Mer systematisk grep om ulike beskyttelsesbehov: Først introdusert i Altinn, fra 2003, fire forskjellige nivåer (enkelt passord, passord + engangskode, software-sertifikater, smart-kort) Målet var å samle mange ulike etaters rapporteringskrav Ulike terskler for akseptabel risiko for hvert autentiseringsnivå Prinsippet med forskjellige autentiseringsnivåer er videreført i arbeidet med felles eid To (tre?) forskjellige nivåer SEID-prosjektet Står for Samarbeid om eid og esignatur Delvis leverandørstyrt Forankret i forskjellige sertifikat-policier fra ETSI (The European Telecommunications Standards Institute) To hovednivåer, som tilsvarte Altinns nivå 3 og 4: Person høyt (kvalifiserte sertifikater, ETSI-policy QCP) Person standard (ikke-kvalifiserte, ETSI-policy NCP) Og et tredje begrep: Virksomhet (også basert på NCP, grunnleggende sett samme sikkerhet som person standard ) Nåværende rammeverk (retningslinje 2008): 4 sikkerhetsnivåer, definisjonene noe mer åpne enn i Altinn 5

6 MinID Arbeidet for felles eid infrastruktur startet med sikkerhetsløsning til minside.no Store forsinkelser og betydelig skepsis blant leverandørene førte til at prosjektet gikk i stå MinID ble iverksatt som en kompromissløsning Basert på skatteetatens ordning med tildelte pin-koder Skal brukes bare for tjenester som krever et moderat sikkerhetsnivå ( person standard nivå 3) Endelig suksess! Over 2 millioner brukere i 2010 Over 700 forskjellige statlige og kommunale tjenester De neste stegene, ID-porten Utviklingen styres av DIFI eid-er på nivå 4 skal leveres av flere leverandører Hver tjeneste som krever autentisering melder inn sitt krav til sikkerhetsnivå Egne veiledninger for hvordan en tjeneste skal kobles til Basert på SAML (W3C-standard) ID-porten ber brukeren logge seg på, med angitt eller høyere sikkerhetsnivå Første steg: konvertere eksisterende MinID (nivå 3) Neste: Pilot-anvendelse på nivå 4 (mineresepter.no) Fremtid: eid over landegrensene ( STORK ) 6

7 DIFIs prinsipper for bruk av eid i ID-porten Kostnadsfritt for sluttbruker Sluttbruker skal fritt velge blant tilknyttede eid-er eid på ett sikkerhetsnivå skal kunne brukes på tjenester med lavere sikkerhetsnivå ID-porten skal tilby ett brukergrensesnitt Alle tjenesteeiere må akseptere alle tilknyttede eid-er Alle eid-er må ha et felles og tilfredsstillende risikonivå Alle tilknyttede eid-er skal tilby tjenester for autentisering, signering og meldingskryptering Regelverk som hjemler dette Regelverket er eldre enn ID-porten, men i utvikling eforvaltningsforskriften 27, Koef Koef kan koordinere forvaltningens bruk av sikkerhetstjenester Forskrift om selvdeklarasjonsordninger Liste over selvdeklarerte eid-leverandører hos Post- og teletilsynet Ikke forhåndsgodkjenning, men løpende (etterfølgende) kontroll Forskriftens 3-5 kravene til de ulike sertifikatklassene, henholdsvis person høyt, person standard og virksomhet Henvisning til Kravspesifikasjon for PKI i offentlig sektor Rammeverket, retningslinje fra FAD Gir tjenesteeierne (ulike etater), anvisning om hvordan de skal knytte egen risikovurdering til forhåndsdefinerte sikkerhetsnivåer 7

8 Aktørene (har egentlig vært innom dem ) Bruker skal selv kunne velge eid-leverandør Tjenesteeier (etat) bestemmer sikkerhetsnivå, men skal godta ulike leverandører på samme nivå Sertifikatutstedere Leverandører som i en eller annen form skal ha betalt for tjenestene Underlagt strenge krav til robusthet og sikkerhet osv., både i esignaturloven og ETSI-sertifikatpolicyene Gjør i stor grad den egentlige jobben, sikrer koblingen eid person DIFI utvikler og styrer ID-porten På sikt en mer strategisk og mindre operativ rolle (?) ID-porten som rammeverk/metode må også forvaltes/videreutvikles Anvendelser De viktigste tjenestene så langt har vært pålogging til tjenester hos ulike forvaltningsorganer En del innslag av signering ( content commitment ) av borgerens meldinger til forvaltningen Etter hvert også ulike typer signert kommunikasjon fra organet Virksomhet forvaltningsorgan, (eks. helserefusjon) Lang historie: Disketter og EDI ( helse/trygd-postkassen ) Lett anonymiserte oppgjørsdata Ca. 2001: Legeerklæringer og sykemeldinger, høye sikkerhetskrav Nasjonalt helsenett, egen infrastruktur for elektronisk utveksling Altinn: Egentlig bare personer som autentiseres Koblingen person/virksomhet ikke basert på virksomhetssertifikat! 8

9 Sikkerhetsnivåenes utvikling Utviklingen fra Altinn 2003 til rammeverket 2008: Altinns opprinnelige fire nivåer var en konkret angivelse av ulike typer sikkerhetstjenester For eksempel ville BankID være på nivå 3 i Altinn, fordi bankene sitter med kontrollen over sertifikatet (lagret på server) På den annen side er ikke lokale software-sertifikater særlig bedre; sløve brukere har neppe kontroll over dem likevel MinID antakelig på nivå 2 (i opprinnelig versjon en rullerende liste pin-koder tilsendt i brev, som det er enkelt å kopiere) I en viss forstand stiller nåværende rammeverk noe lavere krav til hver sikkerhetsnivå enn tidligere På den annen side: Siste versjon av PKI-kravspesifikasjonen krever på noen områder strengerer varianter av ETSI-policyene Tilpasninger for å kunne bruke de aktuelle nivå 4 -leverandørene i ID-porten Buypass; kjent som tippekortet Dette har ikke vært ansett som problematisk i helsenettet Prosjektet e-valg 2011 har ansett det som uheldig Koblingen valg/tipping kan oppleves useriøs I enkelte tippelag brukes felles kort, dvs. svak praktisk respekt for kortet som personlig eid ID-porten aksepterer Buypass, men vil ikke ha det merket som tippekort BankID; sterkt desentralisert Overlater kundestøtte og tilbaketrekking osv. til tjenesteeier (dvs. den enkelte bank): Neppe holdbart for mylderet av statlige og kommunale organer og tjenester Har så langt bare hatt pålogging, ikke signering av kommunikasjon 9

10 Er koordinering av sikkerhetstjenester og produkter i tråd med pol 13/pof kap. 2? Kravet etter pol 13 er tilstrekkelig sikkerhet Pol 13/pof kapittel 2 forutsetter at hver virksomhet tar stilling til risiko, og beslutter og iverksetter egnede tiltak Rammeverket forutsetter også at hver virksomhet tar stilling til risiko ved sin behandling av opplysninger, men angir også en slags nøkkel til å vurdere hvilke typer risiko som skal mappes til et relativ smalt spekter av forhåndsdefinerte tiltak (= de 4 nivåene) Antakelig fornuftig, men likevel et tankevekkende brudd med ledelsesansvarsprinsippet i pol/pof eid for virksomheter? Sertifikatklassen virksomhetssertifikat når ikke opp til samme nivå som person høyt Derfor er det fristende å autentisere personene, og ikke virksomheten Fullmakt til en ansatt, som signerer på vegne av virksomheten virker rimelig, det likner på situasjonen i en ikke-elektronisk verden (bare fysiske personer kan holde en kulepenn) Problem: Fullmaktene som en person har internt i virksomheten er flyktige, og kan i praksis ha liten verdi for etaten, hvis det etaten egentlig trenger å vite er at virksomheten er forpliktet Er det uproblematisk å bruke virksomhetssertifikat? Nei: Hvis ikke signerende person dokumenteres hos mottaker, vil etterprøvbarhet kreve mye av virksomhetens tilgangsstyring 10

11 Trøbbelet med eid for virksomheter En litt subtil, men svært viktig forskjell: Å handle på vegne av en virksomhet (en ansatts fullmakt) Å handle på oppdrag fra en virksomhet (eks. regnskapsfører) Litt forskjellige bruksscenarier Ansatte med fullmakt, bruker virksomhetens eget system til å samhandle med en etat. Etaten trenger (antakelig) ikke å vite med sikkerhet hvem den konkrete personen er, så lenge virksomheten går god for handlingen. Krav til sertifikatklasse virksomhet : Virksomheten må selv holde styr på bruken og sine interne fullmaktsforhold En oppdragstaker (person eller firma), som samhandler med en etat på vegne av en annen virksomhet. Vil ikke kunne signere for kunden, ved å bruke kundens eid (bryter med alt som er av sertifikatpolicyer) Mer trøbbel med virksomhetene En like brysom, og ikke fullt så subtil forskjell: Ofte litt tvetydig hva som menes med virksomhet i de ulike tekniske rammeverkene Kravspesifikasjon for PKI i offentlig sektor: Legger til grunn en selskapsrettslig forståelse, en virksomhet skal i utgangspunktet kunne knyttes til organisasjonsnummer I enkelte rammeverk er virksomhet knyttet til en konkret installasjon (autentiserer en server), slik at det er vanskelig å skille mellom forskjellige org.nr. som deler utstyr (kontorfellesskap) Virksomhetsbegrepet forstås også ulikt i ulike land Peppol (EU-prosjekt, offentlig e-handel over landegrensene) peker på ulike tolkninger av virksomhetsbegrepet 11

12 Anvendelser, eid for virksomheter Altinn: Håndterer ikke egentlig virksomhetssertifikater Alle autentiseres som, og signerer som, personlige eid-er Tildeling av fullmakter, styres av virksomheten, kan tildeles både til egne ansatte og til eksterne oppdragstakere Helsenettet: Bruker både personsertifikater og virksomhetssertifikater Virksomhetssertifikat normalt enklest Enkelte fastlegekontorer mangler org.nr: Kan tilpasses med en ad hoc-løsning, der slike fastlegekontorer registreres som avdeling under kommunen de har avtale med ID-porten? Ambisjonsnivå for virksomheters eid foreløpig noe uklart 12