Skip to content
Permalink
Browse files

Merge branch 'master' of https://github.com/difi/begrep-SikkerDigital…

  • Loading branch information...
kjorlaug committed Jun 11, 2014
2 parents 4fe1868 + 6727de2 commit 4a0b890f8ef4bc2754929c49138995651edd9c19
@@ -12,6 +12,8 @@ next: Feilhåndtering/Transportfeil

h2. {{page.title}}

Forretningsfeil er feil i meldingsinnhold og format i digitalpost melding, dokumentpakke med innhold. Dette håndteres gjennom egne Feilmeldinger.

Følgende forretningsfeil kan oppstå i Sikker Digital Post.


@@ -13,13 +13,18 @@ next: Feilhåndtering/Teknisk
h2. {{page.title}}

Feil som oppstår i meldingsutvekslingen er transportfeil og ikke forretningsfeil.
Forretningsfeil sendes som egne "StandardBusinessDocument":../forretningslag/StandardBusinessDocument/ og er ikke beskrivet videre her.
Transport feil er feil som både er knyttet til transportprotokoll og meldingsutveksling i tillegg til adresseringsinformasjonen på forretningslaget.
Det vil si at transportfeil er knyttet til følgende deler av meldingen:

* SOAP og WS-Security
* eb:Messaging
* Standard Business Document Header


h3. Feil ved meldingsutveksling

Ved feilsituasjoner vil tjenestene returnere en Soap-fault.
Denne vil både inneholde en ebMS 3.0 SignalMessage som inneholder informasjon om feilen og en feilkode i Soap bodyen.
Ved feilsituasjoner vil tjenestene returnere en SOAP-fault.
Denne vil både inneholde en ebMS 3.0 SignalMessage som inneholder informasjon om feilen og en feilkode i SOAP bodyen.

Feilmeldinger blir returnert som standard SOAP-fault uten noen WS-security-header, og er dermed verken kryptert eller signert slik som andre meldinger er.
Dette er fordi feilmeldingene ikke inneholder informasjon som må integritets- eller konfidensialitetsbeskyttes, samt fordi noen feilsituasjoner gjør det umulig å kryptere og/eller signere feilmeldingen.
@@ -19,12 +19,15 @@ children:

h2. Feilhåndtering

Feil i Sikker digital post deles i Forretningsfeil og Transportfeil. Transportfeil er feil som oppstår i meldingsutvekslingen og håndteres på ebMS laget.
Forretningsfeil er feil som ikke er relatert til transport og utveksling av meldinger, men feil i meldingsinnhold og format på indre melding. Dette håndteres gjennom egne Feilmeldinger.

Dokumentasjonen av feilhåndtering er delt opp i følgende kapitler:

table(table table-striped).
| "Forretningsfeil":Forretningsfeil | Hva er en forretningsfeil og hvordan skal den håndteres? |
| "Transportfeil":Transportfeil | Hvilke tekniske feil kan oppstå og hvordan skal disse håndteres? |
| "En teknisk gjennomgang av meldingen i forhold til feilhåndtering":teknisk | I hvilken del av meldingen skjer feilen? og hvem gjør hva? |
| "Beskrivelse av feiltyper og feilmeldinger":teknisk | I hvilken del av meldingen skjer feilen? og hvem gjør hva? |
| "Prosess for feilhåndtering":feilhandteringsprosess | Hvordan skal Avsendere melde feil? |


@@ -12,9 +12,12 @@ next: Feilhåndtering/Transportfeil

h2. {{page.title}}

Det overordnede prinsippet for sending av en melding, er failfast - det vil si at feil skal detekteres så tidlig som mulig - da dette gir bedre og raskere feedback til avsender. Dette innebærer at Meldingsformidler kan avvise meldinger som ikke overholder XSD skjema, eller har ugyldige verdier for felter den trenger for videreformidling (eksempelvis Receiver/Sender i StandardBusinessDocumentHeader). Alle aktører skal der det er mulig benytte EBMS signalling for å indikere feilen.
Det overordnede prinsippet for sending av en melding, er "fail-fast":http://en.wikipedia.org/wiki/Fail-fast - det vil si at feil skal detekteres så tidlig som mulig - da dette gir bedre og raskere feedback til avsender.
Dette innebærer at Meldingsformidler kan avvise meldinger som ikke overholder XSD skjema, eller har ugyldige verdier for felter den trenger for videreformidling (eksempelvis Receiver/Sender i StandardBusinessDocumentHeader).
Alle aktører skal der det er mulig benytte EBMS signalling for å indikere feilen.

Postkassene bør gi en EBMS-feil og/eller SOAP Fault dersom det er transport (SOAP/EBMS) eller routing problematikk (SBDH). Ellers bør "Feil":../meldinger/FeilMelding. Dette sikrer at feilene i flyter tilbake til avsender i de tilfeller avsender har gjort feil.
Postkassene skal gi en EBMS-feil og/eller SOAP Fault dersom det er transport (SOAP/EBMS) eller routing problematikk (SBDH).
Ellers sendes feil som egne forretningmeldinger av typen "FeilMelding":../meldinger/FeilMelding. Dette sikrer at feilene i flyter tilbake til avsender i de tilfeller avsender har gjort feil.

table(table table-striped).
|_. Feiltype? |_. Hva gjør Avsender? |_. Hva gjør Meldingsformidler(MF)? |_. Hva gjør Postkasseleverandør(PK)? |_. Hva gjør MF hvis PK svarer med soap fault? |
@@ -24,8 +27,8 @@ table(table table-striped).
| Skjemavalidering | Manuell håndtering | SOAP-fault + EBMS-signal | SOAP-fault + EBMS-signal | Manuell håndtering |
| Feil i SBD-signatur | Manuell håndtering | SOAP-fault + EBMS-signal | SOAP-fault + EBMS-signal | Manuell håndtering |
| Feil i SBDH | Manuell håndtering | SOAP-fault + EBMS-signal | SOAP-fault + EBMS-signal | Manuell håndtering |
| Feil i SBD | Manuell håndtering | SOAP-fault + EBMS-signal | "Feil":../meldinger/FeilMelding | Manuell håndtering |
| Feil i ASIC (signering/kryptering) | Manuell håndtering | N/A | "Feil":../meldinger/FeilMelding | Manuell håndtering |
| Feil i SBD | Manuell håndtering | SOAP-fault + EBMS-signal | "Feil":../meldinger/FeilMelding | N/A |
| Feil i ASIC (signering/kryptering) | Manuell håndtering | N/A | "Feil":../meldinger/FeilMelding | N/A |
| Intern feil i system | Prøver på ny senere | SOAP-fault + EBMS-signal (Other) | SOAP-fault + EBMS-signal (Other) | Prøver på ny senere |

h3. Feilmeldinger / kvitteringer
@@ -39,8 +39,6 @@ Feilen må utbedres og ny "Digitalpostmelding":DigitalPostMelding må sendes.
h4. Håndtering av server feil

Feil kategorisert som serverfeil vil oppstå dersom postkasseleverandør har interne feil som stopper behandlingen av den digitale postmeldingen.



h3. Attributer

@@ -28,8 +28,13 @@ Dersom Postkasseleverandør opplever problemer med å utføre varslingen som avt
* Innbygger mottok ikke e-post varselet eller sms-meldingen og feilmelding om dette ble gitt til Postkasseleverandør.
** Det er begrensninger i forhold til om Postkasseleverandør får slike feilmeldinger tilbake eller ikke. Dette er avhengig av oppsett på e-post serveren Innbyggeren bruker og mobiloperatøren Innbygger er tilknyttet. Postkasseleverandør vil etter beste evne tolke de "Non-Delivery Reports":http://en.wikipedia.org/wiki/Bounce_message som mottas og gi en Varslingfeiletkvittering i de tilfeller det er helt sikker at varselet ikke ble levert.


Ved mottak av VarslingfeiletKvittering må avsender vurdere om og hvordan dette skal følges opp avhengig av hvor viktig posten. Posten vil være tilgjengelig i postkassen uavhengig av om varselet feilet eller ikke.

Mer informasjon om hvordan varsler bestilles kan du lese "her":../begrep/Varsler.



h3. Attributer

table(table table-striped).
@@ -4,6 +4,44 @@ title: Sikkerhet
headtitle: Sikker digital post

id: Sikkerhet


---

h2. Content to come

h2. Kryptografisk beskyttelse av digital post

Sikker digital post skal etablere tillit mellom avsender og mottaker, slik at avsender med rimelig sikkerhet kan stole på at posten som sendes havner i riktig postkasse, og innbygger kan vite hvem som har sendt posten, og stole på at den er autentisk. Begge parter ønsker å vite at ingen uvedkommende har lest eller endret den digitale posten som formidles mellom dem. Her beskrives overordnet løsning for å sikre integritet og konfidensialitet i overføringen av digital post fra avsendervirksomhetene til innbyggernes digitale postkasser.

Formatet på digitalt post er detaljert på "http://begrep.difi.no/SikkerDigitalPost":http://begrep.difi.no/SikkerDigitalPost. Løsningen legger opp til at all post sikres på samme nivå, og er tiltenkt å kunne beskytte informasjon av særlig følsomme taushetsbelagte opplysninger, herunder de fleste sensitive personopplysninger, stigmatiserende opplysninger m.v. Eksempelvis opplysninger om sykdom. Det er hver enkelt avsendervirksomhet som må vurdere om løsningen er dekkende for deres informasjon, men det vil utarbeides risiko- og sårbarhetsanalyser som vil hjelpe avsendervirksomhetene i denne vurderingen.

h3. Integritet

Det er flere forhold som ivaretas ved integritetsbeskyttelse. Meldingsformidler og postkasseleverandør vil kontrollere og verifisere identiteten til avsender for å hindre uautoriserte avsendere, og for å etablere et trygt sporings- og fakturaregime. Videre kan innbygger være trygg på at posten faktisk er fra den som har utgitt seg for å sende den.

God integritetssikring hindrer at postens innhold eller metadata endres underveis i transporten mellom avsender og mottaker, og sørger for at posten kommer frem til riktig postkasse.

Virksomhetssertifikater er den løsningen som har størst utbredelse og sikrer integritet på best måte, spesielt for autentisering av avsendervirksomheter.

Associated Signature Container er et pakkeformat som er designet for å ivareta integritet til innholdet over lang tid. Kort fortalt definerer standarden hvordan man skal sette sammen en zip-fil med en filstruktur der man lager en digital signatur over innholdet.

Avsendervirksomheten pakker dokumentene til mottakeren i en dokumentpakke og signerer den med sitt eget virksomhetssertifikat. (En avsendervirksomhet kan også benytte sertifikatet til en Databehandler etter nærmere avtale.)

I tillegg er det en signatur på formidlingen som dekker både ukryptert metadata som skal være tilgjengelig under formidlingen, inkludert avsenders virksomhetssertifikat, varslingsinformasjon og dokumentpakken som er kryptert.

Det vil være behov for å endre algoritmer og protokoller over tid, men i første versjon vil signaturen i dokumentpakken være http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 (PKCS #1 v1.5) i henhold til XAdES-standarden.

For å sende digital post må en avsendervirksomhet være registrert med organisasjonsnummer hos sentralforvalteren av sikker digital post, og må inneha et virksomhetssertifikat som benyttes for å signere all digital post. Meldingsformidler og postkasseleverandører vil validere signaturen, og undersøke om avsendervirksomheten er registrert for utsending av digital post.

Innbyggere kan ha behov for å gjenbruke dokumenter utenfor postkassen, der en tredjepart ønsker å validere ektheten av dokumentet. Signaturen i dokumentpakken kan valideres av en tredjepart, eller avsender kan signerer dokumentene som legges i dokumentpakken helt uavhengig av Sikker digital post.

h3. Konfidensialitet

Avsendervirksomheten benytter oppslagstjenesten for digital kontaktinformasjon for å få levert innbyggerens digitale postkasseadresse og tilhørende X.509 sertifikat. Postkasseleverandøren må gjøre sertifikatet tilgjengelig for oppslagstjenesten, og det kan enten være et unikt sertifikat tilhørende innbyggeren eller innbyggerens postkasse, eller det kan være postkasseleverandørens virksomhetssertifikat. Løsningen er valgt med tanke på fleksibilitet, der postkasseleverandørene kan konkurrere på sikkerhet, uten at avsendervirksomhetene må endre sine systemer for utsendelse av digital post. Postkasseleverandøren kan tilby beskyttelse under samme virksomhetssertifikat for alle sine kunder, eller de kan tilby unike sertifikater per innbygger, enten i egen kontroll, eller hvor innbyggeren selv sitter på den private nøkkelen som er nødvendig for å se innholdet. Sertifikatene postkasseleverandøren gjør tilgjengelig kan kostnadsfritt valideres opp mot en sertifikatutsteder. I første omgang har begge postkasseleverandørene valgt å beskytte posten med eget virksomhetssertifikat.

Avsendervirksomheten validerer sertifikatet og benytter dette for å kryptere den symmetriske nøkkelen som benyttes for å kryptere selve innholdet i den digitale posten. Krypteringen er i henhold til Cryptographic Message Syntax (CMS). Det vil være behov for å endre algoritmer og protokoller over tid, men i første versjon krypteres dokumentpakken med AES-CBC-PKCS5Padding og den symmetriske nøkkelen krypters med PKCS #1 v2.1.

Det sensitive innholdet i en digital forsendelse krypteres med symmetriske nøkler. Disse nøklene genereres tilfeldig og gjenbrukes ikke.

Noe metadata må være tilgjengelig under flytting av digital post fra avsender til mottaker, og denne kan ikke være innenfor det som er kryptert. Selv om denne informasjonen er utenfor det krypterte innholdet, så er den beskyttet under overføringen, fordi i tillegg til innholdskryptering er det også kanalkryptering i form av TLS mellom avsendervirksomheten og meldingsformidleren, og mellom meldingsformidleren og postkasseleverandøren.

0 comments on commit 4a0b890

Please sign in to comment.
You can’t perform that action at this time.