Specifikation av validering, felhantering och kvittens

Innehållsförteckning

Revisionshistorik

Version

Datum

Kommentar

Version

Datum

Kommentar

3.0.2 RC2 (2022)

2022-01-31

Revidering av pilotversion inför publicering

  • Avsnitt 3

    • Förtydligat regelverk för omsändningar AP

    • Tagit fram exempel för meddelandestatus för att möjliggöra för sändaren att följa ett meddelande.

  • Avsnitt 4. Sammanfattning av principer och regler för validering och kvittenser

    • Förbättrad dokumentation och förtydliganden

1.0 (2022)

2022-02-28

Beslutad version för Tjänsten Säker digital kommunikation.

1. Inledning

Denna beskrivning är en specifikation av SDKs principer för validering, felhantering och kvittens. Dokumentet är en del av SDKs tekniska specifikationer som i sin tur ingår i regelverk för Säker digital kommunikation. Det innebär att innehållet i dokumentet är styrande för de organisationer som ansluter till Säker digital kommunikation (SDK).

1.1 Referenser

1.1.1. Stödjande externa dokument

Ref

Dokument-id

Dokumentlänk

Ref

Dokument-id

Dokumentlänk

R1

Inera, RIV Tekniska Anvisningar

http://rivta.se/documents

R2

Connecting Europe Facility (CEF)

https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL

R3

CEF eDelivery

https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDeliver

R4

OASIS AS4 transportprotokoll

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/os/AS4-profile-v1.0-os.pdf

R6

CEF eDelivery AS4

https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+AS4

R7

DIGG, Meddelandespecifikation: Meddelandekvittens

DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se

R8

DIGG, “Accesspunktsoperatör - Vägledning - Anslutningsresa för AP-operatör“

DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se

R9

DIGG, Transportmodell - Utökad Bas

DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se

R10

DIGG, Transportprofil AS4

DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se

R11

DIGG, PKI för Accesspunkter Tjänstebeskrivning

DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se

R12

DIGG, Accesspunktsoperatör - Gemensamma Regler och Rutiner

DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se

R13

DIGG, Kuverteringsprofil XHE

DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se

R14

DIGG, Certifikatspublicering - REST-bindning till SMP

DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se

1.1.2. Stödjande SDK-dokument

Ref

Dokument-id

Dokumentlänk

Ref

Dokument-id

Dokumentlänk

B1

Säker digital kommunikation - Software Architecture Documentation (SAD)

Säker digital kommunikation - Software Architecture Documentation (SAD)

B2

SDK Innehållsspecifikation - Meddelande

SDK Innehållsspecifikation Meddelande

Specificerar nyttolast för meddelanden inom Säker digital kommunikation, inklusive meddelandekuvert (metadata) och bilagor.

B3

SLA Tillgänglighet för SDKs gemensamma komponenter

SLA Tillgänglighet för SDK gemensamma komponenter

B4

SDK Adressbok Teknisk guide för Sök-API

Teknisk guide SDK Adressboks Sök-API

B5

IT-säkerhetsbilaga till regelverk för anslutning till Säker digital kommunikation

Informationssäkerhet

B7

SLA Tillgänglighet för användarorganisationens komponenter i SDK-federationen

SLA Tillgänglighet för SDK användarorganisationens komponenter

 

2. Principer för validering och kvittens

En central del i SDKs referensmodell är att skapa en robust meddelandeöverföring, där validering av meddelanden, kvittenser för överförda meddelanden och felhantering är vitala delar.

 

Bilden illustrerar SDKs referensmodell för säker meddelandeöverföring och dess gränsytor.

Läs mer om referensmodellen i SDK - Software Architecture Documentation, avsnitt Identifierare (se Ref. B1). Observera att Accesspunkt ska etableras enligt DIGGs koncept för AP-operatör, se Accesspunktsoperatör - Vägledning - Anslutningsresa för AP-operatör“ (se Ref. R8).

 

Följande avsnitt beskriver principer för validering, kvittens och felhantering i meddelandeöverföringen via SDK.

2.1 Principer för validering

  • Lägg primärt validering och kontroll så tidigt som möjligt i kedjan, där det finns störst möjlighet att åtgärda ev. fel.

  • Gör det lätt för användaren i verksamhetssystemet (meddelandeklienten) att göra rätt från början, t.ex. genom att kontrollera att bifogade filer har rätt typ, att kontrollera format på inmatade värden i meddelandefält osv.

  • Både avsändare och mottagare har ansvar för validering mot gemensamma regler, t.ex. kontroll mot meddelandeformatet, adressering, skanning av skadlig kod, etc.

  • Separera ansvar för transportvalidering till transportlagret (eDelivery) och innehållsvalidering till meddelandelagret (SDK), undantaget kontroll av adressering för att säkerställa säker mottagare och säker avsändare.
    Motiv: Detta gör transportlagret återanvändbart för flera typer av meddelandeöverföringar. Transportlagret ska inte behöva ha mer än nödvändig kunskap om den aktuella nyttolasten.
    Detta medger också att lägga in tillämpningsspecifik validering anpassad för olika meddelandetyper utan att påverka tekniken i transportlagret. T.ex. kan vissa meddelanden kräva tyngre validering, vilket då inte påverkar transportlagrets förmåga att sända och ta emot. Det ger även större möjlighet att testa och verifiera nya valideringsregler i meddelandelagret innan dessa sätts i produktion.

2.2 Principer för kvittens av mottagen leverans

  • Transportkvittenser skickas som signalmeddelanden efter att validering utförts av mottagarens accesspunkt. Detta är en del av eDelivery AS4-specifikationen (Se ref R6) och sker per automatik av en godkänd accesspunkt.

  • Transportkvittens på "överfört meddelande" sker synkront i transportlagret, d.v.s. sändande accesspunkt får direkt en kvittens från mottagande accesspunkt att överföringen lyckats på transportnivå.

  • Meddelandekvittensen för ”meddelande mottaget” sker asynkront i meddelandelagret(MT), vilket medger att hantera meddelandelasten via ett kösystem för bättre skalbarhet i systemet.
    Meddelandekvittenser ska följa Meddelandespecifikation: Meddelandekvittens (se Ref. R7).

  • Kvittenser innehåller alltid ett korrelations-id som sätts till meddelande-id för meddelandet som kvittensen (alt. felmeddelandet) avser. Därmed är varje kvittens unikt spårbar till vilket meddelande som kvitteras. Se vidare Säker digital kommunikation - Software Architecture Documentation (SAD), avsnitt Identifierare (se Ref. B1).

  • Ett meddelande anses levererat när avsändaren erhåller Meddelandekvittens för ”meddelande mottaget”(ACCEPTED) i meddelandelagret.

3. Ansvar för validering, felhantering och kvittens

Robust meddelandeöverföring via SDK bygger på följande ansvarsfördelning mellan meddelande- respektive transportlager:

3.1. Meddelandelagret - Meddelandetjänst (Meddelandeväxel)

Meddelandetjänsterna i meddelandelagret ansvarar för:

  • Validering av meddelande

    • Meddelandets(nyttolast) adressering valideras mot transportlagrets(AS4) adressering. Detta för att kontrollera meddelandets ursprung.

    • Meddelandekuvertets struktur och i förekommande fall innehåll (kodverksregler etc.) valideras.

    • Kontroll mot skadlig kod i nyttolast: Om skadlig kod upptäcks, ska om möjligt ett felmeddelande skickas åter till avsändaren. 
      En incident behöver skapas om skadlig kod upptäcks. Skalskydd i form av antivirussystem bör förhindra vidare hantering genom att t.ex. sätta meddelandet i "karantän".

    • Validering görs både före sändning och efter mottagning i meddelandelagret hos avsändare respektive mottagare.
      I normalfallet stoppas därmed ev. fel tidigt, och vid ev. felkonfiguration hos en avsändande part, kan fel fångas upp hos mottagaren innan det går vidare in till meddelandeklient (verksamhetssystem).

  • Meddelandekvittens/felhantering

    • Skickas asynkront efter validering i mottagande meddelandelager och påvisar att överföringen har accepterats av mottagarens meddelandetjänst (mottaget meddelande - ACCEPTED), alternativt att något fel inträffat hos mottagaren (ej mottaget meddelande - REJECTED).

    • Följande principiella fall finns:

      • Om meddelandet mottagits utan avvikelser, ska meddelandekvittens med status ACCEPTED skickas tillbaka till avsändaren (mottaget meddelande).

      • Om meddelandet mottagits med stoppande avvikelser, ska meddelandekvittens med status REJECTED skickas tillbaka till avsändaren. Felmeddelandet ska även innehålla kodad information om felets art.

  • Svarstidsbevakning på avsändarens meddelandelager

    • Fångar upp uteblivna svar (meddelandekvittens) pga. tekniskt fel, nätverksproblem el. dyl.

    • Gemensamma regler för svarstider tillämpas enligt fastslagen SLA inom federationen. Se ref B7.

  • Spåra och övervaka på meddelandenivå

    • I meddelandelagret realiseras funktioner för att se status för meddelandeöverföringen, t.ex.

      • Meddelande klart för att skickas till Accesspunkt (SCHEDULED)

      • Meddelande skickat till Accesspunkt (SUBMITTED)

      • Meddelandet har transportkvitterats av mottagande Accesspunkt (ACKNOWLEDGED)

      • Meddelandet har inte kunnat levereras till mottagande Accesspunkt, ett problem har uppstått (MESSAGE_EXCHANGE_ERROR)

      • Meddelande kvitterat (ACCEPTED)

      • Meddelande kvitterat med stoppande fel. Meddelandet har ej levererats till avsedd mottagare (REJECTED)

3.2. Transportlagret - Accesspunkt

Accesspunkterna i transportlagret utför validering enligt DIGGs krav på AP-operatörer (Se DIGGs specifikationer, Ref. R7-R14).

Omsändning definieras genom en total omsändningsperiod och antal försök som genomförs under den perioden.

Omsändning:

  • En Accesspunkt ska göra omsändningar enligt fastslagen SLA inom federationen. Se ref B7.

4. Detaljering av validering, felhantering och kvittens

Figur. Modell för robust meddelandeöverföring. Validering, felhantering och kvittens.

 

Steg

Aktör

Aktivitet

Steg

Aktör

Aktivitet

Sändare (C1)

 

 

Initiera meddelandeöverföring

 

Verksamhetslager -

Meddelandeklient/Verksamhetssystem

Observera regelverk för:

  • SKA hantera meddelandestatus

    • Transportkvittens (Från mottagande Accesspunkt)

    • Meddelandekvittens (Från mottagande Meddelandetjänst)

1.Skapa meddelande

Meddelandelager - Meddelandetjänst

Meddelande SKA skapas enligt specifikation SDK Innehållsspecifikation Meddelande (se Ref. B2). Meddelandet paketeras (kuverteras) enligt specifikation eDelivery - Kuverteringsprofil XHE (se Ref. R13).

Observera regelverk för:

  • SKA använda tillförlitlig källa för adressering. Mottagande användarorganisation och dess funktionsadress SKA hämtas från

    • SDK Adressbok (direktintegration via Sök-API)

    • Kvalitetssäkrad läskopia

  • Tillåtna filtyper är (PDF)

  • Max storlek för bifogade filer är 30 MB

  • Hantering av meddelande-id och konversations-id

Se även specifikation:

  • SDK Adressbok (se Ref. B4)

2.Schemavalidering

Meddelandelager - Meddelandetjänst

Meddelandepaketering (kuvert) SKA valideras enligt eDelivery - Kuverteringsprofil XHE (se Ref. R13).

Meddelandet(nyttolast) SKA valideras enligt specifikation SDK Innehållsspecifikation - Meddelande (se Ref. B2).

  • Meddelandet schemavalideras programmatiskt (xsd)

  • Meddelandets regelverk valideras programmatiskt med fastslagna valideringsskript (schematronvalidering).

Observera regelverk för:

  • SKA endast skicka meddelanden som passerat validering

3.Innehållsvalidering

Meddelandelager - Meddelandetjänst

Meddelandet kontrolleras:

  • SKA utföra skanning mot skadlig kod.

Observera regelverk för:

  • SKA kontrollera meddelandets storlek

Se specifikation:

  • SDK Innehållsspecifikation - Meddelande (se Ref. B2)

Kryptera och signera meddelande

Meddelandelager - Meddelandetjänst

Meddelandet SKA krypteras och signeras.

Mottagande användarorganisations publika nyckel SKA hämtas från Certifikatspublicering (se Ref. R14)

  • Kontrollera att metadata där publik nyckel ingår är signerad av betrodd part.

  • Spärrkontroll av mottagarens publika nyckel

Se specifikation:

  • Transportmodell - Utökad Bas (se Ref. R9)

  • Kuverteringsprofil XHE (se Ref. R13)

  • Certifikatspublicering - REST-bindning till SMP (se Ref. R14)

  • IT-säkerhetsbilaga till regelverk för anslutning till Säker digital kommunikation - Informationssäkerhet (se avsnitt “Certifikat för O2O-kryptering och signering av meddelanden – skydd vid meddelandeöverföring mellan användarorganisationer“ Ref. B5)

Sänd meddelande

Meddelandelager - Meddelandetjänst

Meddelandet överför meddelandet till Accesspunkt för distribution till mottagaren.

Meddelandetjänst:

  • SKA hantera meddelandestatus

    • Transportkvittens (från mottagande Accesspunkt) dvs meddelandet är levererat till mottagarens Accesspunkt.

    • Svarstidsbevakning (enligt definierad SLA. Se Ref. B7) sker till dess meddelandekvittens mottagits.

    • Vid uteblivna kvittenser skall felmeddelande returneras till meddelandeklient.

AP-operatör (C2)

 

 

 

Accesspunkt

AP-operatör SKA validera meddelandet enligt DIGGs specifikationer för AP-operatörer.

Observera:

  • Regelverk för omsändning (Avsnitt 3)

Se specifikation:

  • Transportprofil AS4 (se Ref. R10)

  • Accesspunktsoperatör - Gemensamma Regler och Rutiner (se Ref. R12)

Observera att ytterligare valideringskrav kan tillkomma. Kontakta DIGG för senaste information.

AP-operatör (C3)

 

 

 

Accesspunkt

AP-operatör SKA validera meddelandet enligt DIGGs specifikationer för AP-operatörer.

Se specifikation:

  • Transportprofil AS4 (se Ref. R10)

  • Accesspunktsoperatör - Gemensamma Regler och Rutiner (se Ref. R12)

Observera att ytterligare valideringskrav kan tillkomma. Kontakta DIGG för senaste information.

Mottagaren (C4)

 

 

4.Schemavalidering

 

 

Validera signatur och dekryptera meddelande

Meddelandelager - Meddelandetjänst

Meddelandetjänst:

Meddelandets signatur SKA valideras. Sändande (C1) användarorganisations publika nyckel hämtas från Certifikatspublicering (se Ref. R14).

  • Kontrollera att metadata där publik nyckel ingår är signerad av betrodd part.

  • Spärrkontroll av sändarens (C1) publika nyckel

  • Validering av signatur är också en del av SDKs ursprungskontroll (Se 5.Innehållsvalidering).

 

Se specifikation:

  • Transportmodell - Utökad Bas (se Ref. R9)

  • Kuverteringsprofil XHE (se Ref. R13)

  • Certifikatspublicering - REST-bindning till SMP (se Ref. R14)

Schemavalidering

Meddelandelager - Meddelandetjänst

Tillämpar validering enligt 2.Schemavalidering

5.Innehållsvalidering

Meddelandelager - Meddelandetjänst

Tillämpar validering enligt 3.Innehållsvalidering

Ursprungskontroll

  • Sändarens(C1) organisations-id verifieras genom kontroll av meddelandets signatur.

    • Signatur kontrolleras mot publik nyckel registrerad i Certifikatspubliceringstjänst.

  • Verifiera att sändande organisations-id är korrekt i kuvert och nyttolast (AS4, XHE och SDK Meddelande).

Se specifikation:

  • SDK Innehållsspecifikation - Meddelande (se Ref. B2)

  • Transportmodell - Utökad Bas (se Ref. R9)

  • Kuverteringsprofil XHE (se Ref. R13)

Sänd meddelandekvittens

Meddelandelager - Meddelandetjänst

Efter genomför validering och kontroller SKA meddelandetjänst skicka meddelandekvittens alternativt felmeddelande.

  • Om meddelandet mottagits utan avvikelser, ska meddelandekvittens med status ACCEPTED skickas tillbaka till avsändaren.(mottaget meddelande).

  • Om meddelandet mottagits med stoppande avvikelser, ska meddelandekvittens med status REJECTED skickas tillbaka till avsändaren. Felmeddelandet ska även innehålla kodad information om felets art.

Se specifikation:

  • Meddelandespecifikation: Meddelandekvittens (se Ref. R7)

Initiera intern behandling av meddelande

Verksamhetslager - Meddelandeklient/Verksamhetssystem

Meddelandeklient/Verksamhetssystem

  • SKA hantera meddelande enligt specifikation SDK Meddelande.

 

Se specifikation:

  • Meddelandespecifikation: Meddelandekvittens (se Ref. R7)

  • SDK Innehållsspecifikation - Meddelande (se Ref. B2)

 

.