SDK system architecture design (SAD)

1. Inledning

1.1 Bakgrund

Tidigare årsarbeten med SDK har visat att behoven går att realisera tekniskt baserat på EU:s ramverk CEF eDelivery, se ref R6, samt kompletterande specifikationer och anvisningar som finns i federationen SDK. Exempel på dokumentation är anslutningsavtal för deltagarorganisationer Länk till annan webbplats. samt regelverk för deltagarorganisationer inom SDK Länk till annan webbplats. inklusive bilagor.

Federationen Säker digital kommunikation (SDK) består bl a av ramverk, regler, rutiner specifikationer och beskrivningar och viss gemensam infrastruktur vid informationsutbyte mellan regioner, kommuner, statliga myndigheter och privata utförare av offentligt uppdrag.

Under 2015 och 2016 har flera behovsanalyser hos kommuner, regioner, privata vårdutförare respektive statliga myndigheter visat på ett stort behov av säker digital kommunikation. Idag sker informationshanteringen mellan aktörerna till stor del manuellt, med fax, brev, telefon och e-post, därför att det saknas alternativ. Det tar tid, driver kostnader och skapar osäkerhet.

Det finns bland annat stora behov inom hälso- och sjukvård, socialtjänst och skola. Behovsbilden har ytterligare konkretiserats i projektets etableringsfas hösten 2017, och aktörerna har konstaterat att behoven bygger på att:

• Informationen är känslig men ej av sådan karaktär att den avser rikets säkerhet.
• Informationen ska kunna gå över öppet nät.
• Informationen ska kunna vara ostrukturerad, för att kunna ersätta dagens fax, fysiska brev och telefonsamtal kan inte krav ställas på innehållets struktur.
• Kommunikationen ska kunna ske mellan funktionsbrevlådor som möjliggör meddelandeutbyte från en handläggare hos sändande part till en annan handläggare hos mottagande part.
• Kommunicerande parter ska kunna hitta säkra adressater, skicka, ta emot, och få kvittens på att ett meddelande överförts.
• Förutsättningarna ska vara samma för offentliga aktörer och privata utförare av offentligt uppdrag.
• Parterna ska kunna ansluta till en federation enligt fastställda regelverk utan att bilaterala överenskommelser ska behövas mellan alla olika parter.

SDK är ett samarbetsprojekt mellan Sveriges kommuner, regioner och myndigheter som har pågått sedan 2017. SDK har tagits fram av Digg och Inera i samarbete med Sveriges Kommuner och Regioner (SKR) samt enskilda kommuner, regioner och andra myndigheter.

1.2 Syfte

Säker digital kommunikation syftar till att skapa förutsättningar för en säker och enhetlig hantering av känslig information vid överföring av digitala meddelanden mellan aktörer i offentlig sektor.

Säker digital kommunikation ger följande vinster för både verksamheter och handläggare:

• ökad trygghet genom att inte personlig eller känslig information sprids till obehöriga
• snabbare handläggning och beslut
• samma spårbarhet oavsett verksamhet

1.3 Dokumentation SAD

SAD utgör dels en övergripande beskrivning av lösningsarkitekturen för federationen Säker digital kommunikation (SDK), dels en grund för lösningar som tas fram som stödjer federationen.

1.4 Om dokumentet

Dokumentet syftar till att beskriva den övergripande lösningsarkitekturen för federationen för Säker digital kommunikation.

Då arkitekturen i grunden är ett ramverk med specifikationer och standarder där samverkande delsystem tillsammans utgör hela systemlösningen, syftar detta dokument främst till att beskriva ramverket, hur samverkan sker mellan delsystemen, samt vilka ytterligare profileringar med tillhörande specifikationer som är framtagna för just syftet Säker digital kommunikation.

För ingående delsystem finns möjligheter att välja olika färdiga programvaror, eller att utveckla/anpassa programvaror, så länge dessa följer ramverksregler, gränssnittsspecifikationer osv. Dokumentet har därför inte fokus på att beskriva intern mjukvarurealisering av delsystem/komponenter.

I dokumentet beskrivs arkitekturen primärt utifrån vyerna:

• Användningsfallsvy - Arkitekturellt drivande användningsfall utifrån den grundläggande funktionalitet som ramverket tillhandahåller, och vilka delsystem som interagerar med varandra i respektive fall (kap. 4).
• Logisk vy - Logisk arkitekturell vy över den tekniska lösningen med ingående delsystem, deras respektive roller och gränsytorna dem emellan. Arkitekturens mål, drivande krav och arkitekturellt speciellt signifikanta delar beskrivs (kap. 2 och3).
• Säkerhetsvy - Säkerhetskrav och säkerhetsmekanismer för den övergripande lösningsarkitekturen (kap. 6).
• Informationsvy - Hantering av information vid användning av federationen Säker digital kommunikation, informationsmodeller och specifikationer för meta- och adressinformation (kap.7).

1.5 Målgrupp

De huvudsakliga målgrupperna för detta dokument är:

• Integratörer
• Leverantörer av meddelandetjänster/applikationer
• Systemägare
• Systemförvaltare
• Systemarkitekter
• Utvecklingsteam
• Arkitekturstödsfunktioner

1.6 Termer och förkortningar

Termer och förkortningar inom SDK finns i SDK-ordlista.

2. Arkitekturell översikt

Figur. Arkitekturell översikt - Säker digital kommunikation. Se bilden i en större version.

Den arkitekturella ansatsen för Säker digital kommunikation är att etablera ett gemensamt ramverk för säkert meddelandeutbyte baserat på standarder i så stor utsträckning som möjligt. Till ramverket ska det vara möjligt att ansluta meddelandetjänster med meddelandeklienter som användarens gränssnitt.

Anslutna meddelandetjänster kan kommunicera med varandra genom standardprotokoll, en överenskommen profilering av dessa protokoll, samt en gemensam innehållsspecifikation för själva meddelandet. Meddelandetjänsterna ansluts via s.k accesspunkter som ansvarar för att göra tekniska vägval och utföra säker robust transport till mottagande organisations accesspunkt.

Mottagarens meddelandetjänst hämtar mottagna meddelande från dess accesspunkt och gör meddelandet tillgängligt till behöriga användare i meddelandeklient. Själva meddelandeöverföringen är asynkron, vilket innebär att meddelandetjänsten kan sända meddelandet utan att behöva vänta på att få ett svar tillbaka från mottagarens system. Meddelandekvittensen skickas som ett separat meddelande tillbaka till avsändande meddelandetjänst, som sedan kan läsa av kvittensen alternativt visa larm om meddelandet inte kvitterades.

Den asynkrona modellen ger stöd för att köa meddelanden hos avsändande respektive mottagande system, för både själva transporten och de valideringssteg som behöver utföras.

Det ingår även viss nödvändig gemensam infrastruktur i lösningen:

• För att etablera tilliten till transportinfrastrukturens AP-operatörer, behövs en betrodd certifikatsutgivare (CA) och en reglerad hantering av denna, se avsnitt 7.4 Säkerhetsmekanismer. Utgivna certifikat används för att realisera säkerhetsmekanismer som transportkryptering, e-stämpling av försändelse, AS4-meddelandekryptering mot mottagande accesspunkt.
• För att etablera tilliten till deltagarorganisationer behövs betrodda certifikatsutgivare (CA) och en reglerad hantering av dessa, se avsnitt 7.4 Säkerhetsmekanismer. Utgivna certifikat används för att realisera säkerhetsmekanismer på meddelandenivå såsom meddelandekryptering och signering. Meddelandekryptering och signering tillämpas mellan deltagarorganisationer.
• En Certifikatpubliceringstjänst (CertPub) som innehåller deltagarorganisationers publika nyckel för att möjliggöra meddelandekryptering och signering, sk. organisation till organisation kryptering/signering (O2O-certifikat).
• En källa till adressuppgifter (SDK adressbok) för de parter som kan kommunicera med varandra. Källan uppdateras av respektive deltagarorganisation, se nedan under Adresseringsmodell.
• En metadatatjänst (SMP) som innehåller tekniska uppgifter om var de olika tjänsterna för meddelandeutbyte finns (teknisk ändpunkt för leverans av meddelande), vad de tekniskt stödjer (meddelandeformat, version etc), samt vilka certifikat som mottagande accesspunkt använder.

I den referensmodell, se figur nedan figur, för meddelandeöverföringen som tagits fram finns följande huvudsakliga logiska komponenter/lager:

• Meddelandeklient (Verksamhetslager): hanterar gränssnittet mot användaren, hanterar koncept som "brevlåda", säker inloggning, behörighetsstyrning, besvara meddelande, konversationer (meddelandetrådning) osv.
• Meddelandeklienten har det primära ansvaret för lagring av inkomna och skickade meddelanden, men ansvaret kan vara delegerat till en annan tjänst för lagring.
  • Representerar en funktionsadress
  • Ansvarar för att adressera meddelandet
  • Ansvarar för att skapa och presenterar meddelanden
  • Presenterar skickade meddelande samt dess meddelandestatus/kvittens meddelande
  • Lagrar meddelanden
• Meddelandetjänst (Meddelandelager/meddelandeväxel): ansvarar för kryptering/dekryptering och signering/validerar signatur samt hanterar själva meddelandeöverföringen, hämta och lämna meddelanden hos accesspunkten (AP-operatör), validering av utgående/inkommande meddelanden, vid behov inom organisationen styra meddelande till rätt meddelandeklient (intern routing), svarstidsbevakning och ge stöd för omsändning av meddelandet om tidigare försök misslyckats. Meddelandetjänst integrerar med accesspunkt via gränsyta C (ej standardiserat tekniskt gränssnitt).
• Accesspunkt (Transportlager): hanterar extern säker kommunikation med andra parter (gränsyta A), validering och säker kvittens på transportnivå samt teknisk adressering för att nå mottagarens accesspunkt. Säkerställer insyns- och integritetsskyddad transport via kryptering, e-stämpling av försändelse och kontroll av certifikat och stämplar.
• Gemensamma komponenter: realiserar tjänster (gränsyta B) för adressering till organisation och funktion inom organisation, certifikatshantering, metadata om var de olika tjänsterna för meddelandeutbyte finns och vad de tekniskt stödjer.

Figur. Referensmodell för säker meddelandeöverföring. Se bilden i en större version.

Uppdelningen i dessa skikt och komponenter ger bl.a. följande möjligheter (där koppling till SDK arkitekturella mål, enligt avsnitt 2.1 nedan, anges inom parentes):

• Gränsytorna A, B, C, D mellan komponenterna kan specificeras för att kunna samverka med olika produkter och lösningar på marknaden (arkitekturellt mål "Öppenhet och standarder"). Läs mer om gränsytor under avsnitt “6. Teknisk lösning”.
• En organisation kan ha flera meddelandeklienter, t.ex. ett ärendesystem som hanterar meddelanden för en del av organisationen, och en meddelandeklient som renodlat hanterar säkra meddelanden (arkitekturellt mål "Eget ansvar för intern arkitektur och val av verktyg").
• Meddelandetjänster kan göras mer generiska och klara flera olika typer av transportlager (arkitekturellt mål "Öppenhet och standarder").
• Byte av realisering av transportlagret kan göras utan att behöva påverka övriga lager (arkitekturellt mål "Öppenhet och standarder").
• Deltagande parter kan nå adressuppgifter om alla andra deltagande parter baserat på den organisation och funktion som parten vill nå (arkitekturellt mål "Gemensamma begrepp, modeller och mönster" och "Använd strukturerad information i processen").
• Deltagande accesspunkter kan få aktuella tekniska uppgifter om mottagarens motsvarande tjänster via metadata och behöver inte uppdateras på annat sätt vid t.ex. byte av tekniska adresser.

I den framtagna lösningen utgörs transportlagret och delar av de Gemensamma komponenterna av eDelivery, ett byggblock framtaget av EU:s organisation Connecting Europe Facility (Se Connecting Europe Facility (CEF)). Dessa byggblock realiseras av Myndigheten för digital förvaltning (Digg). Mer om detta under avsnitt Teknisk lösning.

2.1 Arkitekturella mål

Federationen Säker digital kommunikation utgår utifrån följande arkitekturella mål:

• Följsamhet mot Svenskt ramverk för digital samverkan.
  • Digitala kanaler ska vara det primära alternativet, öka medborgarnas insyn och möjligheter att påverka. Det ska vara lätt att använda det säkra digitala kommunikationsalternativet för att kommunicera säkert med myndigheter och andra inblandade aktörer.
  • Öppenhet och standarder – öppna upp för externa innovatörer genom att använda öppna standarder. Basera en gemensam lösning på öppna specifikationer och gränssnitt, oberoende av specifik leverantör eller produkt. Skapa goda förutsättningar för marknaden att leverera lösningar kompatibla med säker digital kommunikation. Detta ger hög interoperabilitet.

• Rätt nivå på informationssäkerhet och integritet
  • Tillämpa informationssäkerhet riskbaserat för att får en bra balans mellan risk och skydd.
  • Privacy-by-design - bygg in skyddsmekanismer genom hela kedjan från början
  • Skapa god tillit till lösningen genom att via tekniska lösningar och regelverk möta kraven på konfidentialitet, riktighet, spårbarhet och tillgänglighet.
  • Gemensamma begrepp, modeller och mönster. Ta fram en överenskommen och tydlig specifikation för sådant som kommunikationsmönster, organisationsidentiteter, adresseringsinformation, och meddelandets metainformation/struktur.
  • Använd strukturerad information i processen
    • Enligt framtagen behovsbild för SDK ska informationen som överförs kunna vara ostrukturerad; för att kunna ersätta dagens fax, fysiska brev och telefonsamtal kan inte krav ställas på innehållets struktur som sådan. Däremot struktureras metainformation för meddelandet enligt en innehållsspecifikation, såsom avsändare, mottagare, identifierare, interna och externa referenser osv.
      Lösningen baseras på en infrastruktur som klarar av att också överföra strukturerad information, vilket ger möjlighet att utnyttja infrastrukturen även för mer strukturerade informationsutbyten.

• Eget ansvar för intern arkitektur och val av verktyg
  • Införande av säker digital kommunikation ska inte utgå ifrån att organisationerna ska behöva bygga om sin interna IT-arkitektur.
  • Det ska vara möjligt att göra anpassningar i existerande lokala lösningar för att ansluta till säker digital kommunikation.

• Tillgängliggör och återanvänd information och tjänster på ett enhetligt sätt
  • I den för lösningen nödvändiga gemensamma infrastrukturen gäller att gemensamma specifikationer och standarder förvaltas över tid (governance), och stödjande gemensamma IT-förmågor behöver upprätthållas.

2.2 Prioriterade områden

• Definiera en referensmodell för säker meddelandeöverföring inkl de flöden som behövs för en robust hantering av meddelanden.
• Ge verksamheter möjlighet till att registrera och använda säkra och aktuella adressuppgifter till organisationer och funktioner
• Sätta en standard och specifikationer som ger förutsättning för samverkan mellan olika leverantörer/produkter för säker meddelandehantering.
• Sätta en säkerhetsmodell med säkerhetsmekanismer som motsvarar de krav som ställs på informationssäkerheten, och har möjlighet att anpassas till förändrade krav inom IT-säkerhet.

3 Följsamhet till arkitektoniska principer

Denna SAD har inspirerats av “R1 RIV - regelverk för interoperabilitet inom vård och omsorg (Inera)”, inom vilket T-boken är kortnamnet på RIV Teknisk Referensarkitektur. SDK som sådant har ett bredare nationellt perspektiv där alla offentliga aktörer och deras utförare ska kunna ingå, och har därför följt nationella riktlinjer och vägledningar. Nedan har ändå beskrivits följsamhet till delar av T-bokens styrande principer eftersom de flesta av dessa är av generell karaktär.

IT2: Informationssäkerhet

IT4: Lös koppling

IT5: Lokalt driven e-tjänsteförsörjning

IT6: Samverkan i federation

4. Användingsfall

Här beskrivs systemet ur ett funktionellt perspektiv i form av en användningsfallmodell i syfte att lyfta fram de funktionella krav som är drivande för arkitekturen. I detta kapitel förekommer termer och begrepp som beskrivs mer utförligt i senare delar av dokumentet.

4.1 Användningsfall - översikt

Figur. Användningsfallsöversikt. Bilden illustrerar övergripande användningsfall som är drivande för arkitekturen i SDK. Bildens innehåll beskrivs i efterföljande tabell.

Grundläggande användningsfall riktade mot slutanvändare, dvs användare och administratörer framgår av nedanstående tabell.

I tabellen beskrivna användningsfall utgör grundläggande användningsfall riktade mot slutanvändare, dvs användare som skickar och tar emot meddelanden, samt administratörer av gemensamma komponenter. I översikten ingår även bakomliggande stödjande användningsfall, som sker på system-system-nivå. Dessa beskrivs inte som separata användningsfall i detta kapitel.

4.2 Aktörsinformation

Följande mänskliga huvudaktörer är involverade i ett SDK meddelandeflöde:

4.3 Logisk realisering - användingsfall

Ett urval av användningsfallen i översikten ovan beskrivs mer ingående i detta avsnitt.

4.3.1 AF1 – Registrera deltagarorganisation

4.3.1.1 Textuell beskrivning

Förutsättning:

• AP-operatör och federationsoperatör tillämpar stark autentisering samt är auktoriserad.
• AP-operatör är godkänd av ansvarig för transportinfrastrukturen (Digg).

Aktiviteter:

• AP-operatör registrerar deltagarorganisationens metadata i Metadatatjänst.
• Federationsoperatör godkänner registrerat metadata i Metadatatjänst.
  • Registrerar deltagarorganisationens publika nyckel för Organisation-till-organisation kryptering och signering (O2O). Registrering sker via federationsoperatörens administrativa rutiner och verktyg.
  • Registrerar godkänd deltagarorganisationen i SDK:s gemensamma komponent SDK Adressbok.
  • Tilldelar deltagarorganisationens administratör behörighet till SDK adressbok.

Resultat: Registrerad deltagarorganisation är tekniskt förberedd för att skicka och ta emot meddelanden till/från övriga registrerade deltagarorganisationer.

• Tillhörande metadata för kommunikation, certifikat samt adressuppgifter är registrerade.

Följande systemaktörer är involverade:

4.3.1.2 Sekvens

Figur: Sekvensdiagram - registrering av deltagarorganisation och tillhörande meta- och adressdata.

4.3.2 AF2 – Avregistrera deltagarorganisation

4.3.2.1 Textuell beskrivning

Förutsättning:

• AP-operatör och federationsoperatör tillämpar stark autentisering samt är auktoriserade.

Aktiviteter:

• AP-operatör
  • avregistrerar deltagarorganisationen från metadatatjänst.
  • avregistrerar deltagarorganisationen från accesspunkt.
• Federationsoperatör
  • godkänner avregistrering i metadatatjänst.
  • avregistrerar deltagarorganisation i SDK adressbok.

Resultat: Avregistrering innebär att kommunikation med deltagarorganisationen inte längre blir möjlig.

Följande systemaktörer är involverade:

4.3.2.2. Sekvens

Figur: Sekvensdiagram - avregistrering av deltagarorganisation och tillhörande meta- och adressdata.

4.3.3 AF3 – Uppdatera adressinformation för deltagarorganisation

4.3.3.1 Textuell beskrivning

Förutsättning:

• Deltagarorganisationens administratör tillämpar stark autentisering samt är auktoriserad.
• En deltagarorganisation kan endast administrera sina egna adressuppgifter. Det krävs att deltagarorganisationen som sådan först är registrerad (se AF1).

Aktiviteter:

• Administration av adressuppgifter för deltagarorganisation utförs primärt av deltagarorganisationen själv genom behörig lokal administratör som använder gemensamt administrativt gränssnitt för SDK.

I sekvensdiagrammet nedan visas endast schematiskt en av de möjliga varianterna att administrera uppgifterna. Se vidare avsnitt Teknisk lösning.

Följande systemaktörer är involverade:

4.3.3.2 Sekvens

Figur: Sekvensdiagrammet illustrerar administration av adressuppgifter. Notera att registrering och uppdatering av deltagarorganisations adressuppgifter kan ske via Lokal administratör direkt i administrativt gränssnitt.

4.3.4 AF4 – Uppdatera metadata för deltagarorganisation

4.3.4.1 Textuell beskrivning

Förutsättning:

• Administratör accesspunkt (AP-operatör) och federationsoperatör tillämpar stark autentisering samt är auktoriserade.

Aktiviteter:

• Deltagarorganisationens AP-operatör uppdaterarar metadata via ansvarig för transportinfrastrukturens (Diggs) administrativa rutiner och verktyg.
• Deltagarorganisationen anmäler uppdatering till federationsoperatörens administrativa rutiner och verktyg.
• Federationsägare godkänner uppdateringar innan dessa träder i kraft.

Följande ändringar ska godkännas av federationsoperatören:

• Ändring av metadata som innebär ändring av dokumenttyp.
• Ändring av deltagarorganisationens publika nyckel för organisation-till-organisations kryptering och signering

Följande ändringar hanteras av AP-operatör utan federationsoperatörens godkännande.

• Metadata som berör befintlig anslutning t.ex. AP certifikat och teknisk adress.

Observera att inte alla metadatauppdateringar påverkar lokaliseringstjänst och DNS.

4.3.4.2 Sekvens

Figur: Sekvensdiagrammet illustrerar administration av metadata.

4.3.5 AF5 – Söka adressinformation

4.3.5.1 Textuell beskrivning

En Användare eller lokal komponent (meddelandeklient) i en deltagarorganisation söker/slår upp adressinformation för den/de mottagare som användaren avser skicka säkert meddelande till. Användaren kan använda sök- och filtreringsvillkor för att få fram eftersökta uppgifter.

Följande systemaktörer är involverade:

4.3.52 Sekvens

Figur: Sekvensdiagrammet illustrerar att söka ut adressinformation för önskad mottagare (adressat). Även komponenten meddelandetjänst (MT) kan söka i SDK Adressbok för att t.ex. validera en adress.

4.3.6 AF6 – Skicka meddelande

4.3.6.1 Textuell beskrivning

Förutsättningar:

• Användare tillämpar stark autentisering samt är auktoriserade.
• Användaren har adresserat meddelandet, se AF5.

Aktiviteter:

• En Användare i en deltagarorganisation skapar och skickar ett meddelande via sin Meddelandeklient.
• Meddelandetjänsten krypterar och signerar meddelandet.
• Det krypterade och signerade meddelandet överförs till deltagarorganisationens Accesspunkt och vidare till mottagande organisations Accesspunkt. Vid överföring mellan Accesspunkter krypteras och förseglas meddelandet (AS4).

Mottagande Accesspunkt dekrypterar och verifierar meddelandet varvid mottagarorganisationens Meddelandetjänst hämtar upp meddelandet (förutsatt att allt gått bra). Meddelandetjänsten dekrypterar- och kontrollerar signatur samt validerar meddelandet till struktur och innehåll. Meddelandet förmedlas till den meddelandeklient (Verksamhetssystem) som ansvarar för meddelandets funktionsadress. Meddelandet tillgängliggörs tekniskt för behörig användare.

I flödet ingår även kvittens/felhantering på både transport- och meddelandenivå för att åstadkomma en garanterad leverans.

• Kvittens i transportlagret sker när meddelande tekniskt är korrekt överfört till mottagande accesspunkt.
• Kvittens i meddelandelagret sker när meddelandet är dekrypterat, signatur validerad samt meddelandets struktur och innehåll är validerat.
• Meddelandekvittensen skickas som ett nytt meddelande tillbaka till den ursprungliga avsändande deltagarorganisation.

Att söka ut / ange mottagande organisations adressuppgifter föregår användningsfallet och är inte medtaget i denna beskrivning, se AF5.

Följande systemaktörer är involverade:

4.3.6.2 Sekvens

Figur: Sekvensdiagrammet illustrerar att skicka ett meddelande från organisation A till B.

4.3.7 AF7 och AF8 – Komplettera och besvara meddelande

4.3.7.1 Textuell beskrivning

Att komplettera och besvara ett meddelande sker med samma mekanismer som för användningsfall ”AF6 - Skicka meddelande”. När ett meddelande kompletteras eller besvaras ska dock alltid det tidigare meddelandet som kompletteras/besvaras refereras, vilket bygger upp en tråd av meddelanden och svar på meddelanden. En användare kan i sin meddelandeklient således följa vilka meddelandekonversationer som denne deltagit i. Se SDK Innehållsspecifikation Meddelande Länk till annan webbplats. där beskrivs vilka attribut som skall refereras vid komplettering/besvarande.

4.3.7.2 Sekvens

Se sekvens för användningsfall "AF6 - Skicka meddelande". Meddelandetjänsten kopplar ihop skickade meddelanden med tidigare meddelanden genom kopplingsidentifierare.

Se avsnitt “Stöd för spårbarhet, svar och konversationer SDK Innehållsspecifikation Meddelande Länk till annan webbplats. för detaljerade beskrivningar.

4.3.8 AF10 – Ta del av meddelande

4.3.8.1 Textuell beskrivning

Meddelandeklienten (MK) hämtar meddelande meddelandetjänst (MT). Meddelanden kan hämtas genom att tillämpa Rekommendation API MT/MK för SDK Länk till annan webbplats.. .

Förutsättning:

• Användare tillämpar stark autentisering samt är auktoriserade.

Aktiviteter:

• Deltagarorganisationen Meddelandetjänst hämtar löpande meddelanden från dess AP-operatörs accesspunkt.
  • Alla meddelande dekrypteras och valideras.
  • Meddelanden kan överföras till meddelandetjänsten med olika tekniska lösningar(push/pull).
  • Meddelanden kan överföras till Meddelandeklienten (Verksamhetssystem) som hantera funktionsadressen (funktionsbrevlådan) genom att tillämpa rekommendationen Rekommendation SDK API MT/MK.
• En Användare använder meddelandeklienten för att ta del av meddelanden.

Följande systemaktörer är involverade:

4.3.8.2 Sekvens

Figur: Sekvensdiagrammet (steg 9) illustrerar hur ett meddelande hämtas till Meddelandeklienten. Sekvensen föregåas av ”Hämta meddelande från AP”

5. Teknisk lösning

5.1 Beskrivning av arkitekturellt signifikanta delar av lösningen

5.1.1 Referensmodell för säker meddelandeöverföring och dess gränsytor

Figur: Referensmodell för säker meddelandeöverföring. Se bilden i en större version.

Referensmodellen för säker meddelandeöverföring syftar bland annat till att definiera ett antal gränsytor mellan olika delkomponenter i lösningen, fördela ansvar mellan olika lager och komponenter samt möjliggöra att olika produkter och lösningar för säker meddelandehantering lättare kan samverka. Gränsytorna underlättar också utbyte av viss produkt, t ex i transportlagret, genom att en annan produkt realiserar motsvarande transportprotokoll och gränssnitt mot meddelandetjänst.

5.1.1.1 Gränsyta A

Gränsyta A motsvarar transportprotokollet för att säkert överföra meddelanden mellan parter (organisationer). Gränsyta A måste vara standardiserad så att alla accesspunkter som realiserar gränssnittet blir interoperabla med varandra och säkert kan utbyta meddelanden.

Det är tekniskt möjligt att stödja flera olika transportprotokoll parallellt, vald teknisk lösning har stöd för att konfigurera vilket transportprotokoll och version som gäller för den aktuella överföringstypen (dokumenttypen). Förutom att det ger en större flexibilitet, generalitet och framtidssäkring av det tekniska ramverket ger det även visst stöd för att hantera nya versioner av transportprotokollet.

Gränsyta A realiseras genom protokollet OASIS ebMS 3.0 AS4, eller kort "AS4", som är en av OASIS-profilerad standard baserad på WebService-protokoll för kommunikation och säkerhet. Se vidare hur eDelivery realiserar transportlagret, https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery Länk till annan webbplats.

• Anslutna Accesspunkter inom SDK-federationens realiserar Diggs Transportprofil AS4.

5.1.1.2 Gränsyta B

Gränsyta B är en samlingsbeteckning för de gränssnitt som behövs mot gemensamma komponenter. Gränssnitten kan delas in i:

• Gränssnitt för adressuppgifter till organisation och funktion (verksamheter). Se bilaga SDK adressbok API-dokumenationSDK Adressbok Informationsspecifikation för mer information om gränssnitten.
• Gränssnitt för uppslag av var de tekniska tjänsterna finns (lokaliseringstjänster se Ref. R12 SML Komponentspecifikation).
• Gränssnitt för uppslag av metadata och säkerhetscertifikat för mottagares tekniska tjänster (se Ref. R13 SMP Komponentspecifikation).
• Gränssnitt för kontroll av säkerhetscertifikat (CRL/OCSP, se Ref. R14 Digg, eDelivery - PKI för Accesspunkter Tjänstebeskrivning).
• Gränssnitt för kontroll av deltagarorganisationens certifikat, se Ref. R18 Digg, eDelivery - Certifikatspublicering - REST-bindning till SMP Länk till annan webbplats.

5.1.1.3 Gränsyta C

Gränsyta C består av de systemgränssnitt (API:er) som accesspunkten erbjuder meddelandetjänster.

Accesspunkter kan erbjuda flera olika tekniska "smaker" på gränssnitten, t ex WebService/SOAP, HTTP/REST, JMS, S-FTP.

Gränssnitten tillhandahåller dock samma grundfunktionalitet till meddelandetjänsten: skicka meddelande, kontrollera status för meddelanden, hämta nya inkomna meddelanden, hämta logginformation osv.

En komponent som realiserar ett visst gränssnitt mot accesspunkten kallas även för en Konnektor.

En accesspunktsprodukt kan erbjuda ett ramverk för att utveckla nya konnektorer inom ramen för en accesspunkt, för att på så sätt kunna erbjuda nya tekniska gränssnitt mot accesspunkten. T.ex. har produkten Domibus (CEF:s referensimplementation för accesspunkt) ett ramverk för att utveckla konnektorer som plug-ins till Domibus.

Om den aktuella accesspunktsprogramvaran saknar ett sådant ramverk, och behov finns att lägga till ett tekniskt gränssnitt i ytan C, kan man behöva ta fram en fristående programvarukomponent som agerar adapter framför accesspunkten, dock inom skalskyddet för denna.

5.1.1.4 Gränsyta D

Gränsyta D består av de systemgränssnitt (Rekommendation SDK API MT/MK Länk till annan webbplats.) som meddelandetjänst (API producent) erbjuder meddelandeklienter (API konsument).

Meddelandeklient kan t ex vara ett anpassat verksamhetssystem eller paketerade slutanvändarprodukter särskilt utformade för säker meddelandehantering.

Rekommendation SDK API MT/MK (REST API) stödjer följande operationer:

• Skicka meddelande
• Hämta meddelande
• Radera meddelande

Rekommendation SDK API MT/MK Länk till annan webbplats. (REST API) är beskrivet (kontrakt) enligt specifikationen openAPI, version 3.1.x, och är utformat enligt/inspirerat av JSON:API, se Rekommendation SDK API MT/MK Länk till annan webbplats..

5.2 Asynkront meddelandeflöde

Figur: Meddelandeflödet är asynkront med stöd för köhantering i både meddelandelagret och transportlagret. Se bilden i en större version.

I bilden representerar "S" en kö för sändning (Sender) och "R" en kö för mottagning (Receiver). Meddelandeflödet enligt referensmodellen är asynkront, vilket t.ex. betyder att ett meddelande kan läggas på kö för sändning och producenten av meddelandet kan direkt gå vidare till nästa meddelande eller andra aktiviteter. Köhantering realiseras i både meddelandelagret och transportlagret. På så sätt skapas lös koppling mellan de olika lagren och mellan komponenter i en viss realisering av modellen. I meddelandelagret (meddelandetjänst) kan det dessutom förekomma separata köer för respektive meddelandeklient.

Det kan även vid behov förekomma köhantering i respektive meddelandeklient beroende på hur meddelandeklient och meddelandetjänst realiseras i organisationen. Om t ex verksamhetssystem med egen lagring ansluts till en separat meddelandetjänst är det lämpligt att ha köhantering även i verksamhetssystemet. Notera att ett enskilt anrop, t.ex. anropet mellan sändande och mottagande accesspunkt, har ett synkront svar som kvittens på själva anropet.

Den asynkrona överföringsmodellen och köhanteringen ger följande kvalitativa fördelar:

• Ett mer robust system för meddelandeöverföring, där enskilda noder kan vara nere kortare tider utan att meddelandeöverföringen som sådan bryts. Detta kan öka den för användare upplevda tillgängligheten i systemet markant. Jämför ekosystemet för SMTP-baserad e-post.
• Inbyggda möjligheter att sända om meddelanden som inte kunnat levererats t.ex. p.g.a. att någon del av tekniken tillfälligt är otillgänglig.
• Bättre skalbarhet, större potential att kunna hantera större laster (meddelandeflöden), eftersom mottagande system kan validera och processa inkomna meddelanden i separata processer, och inte kopplat i realtid vid mottagandet av meddelandet.

5.2.1 Validering, felhantering och kvittens

Deltagarorganisationer ansvarar för att korrekta meddelanden överförs inom SDK-federationen. För att säkerställa detta finns ett gemensamt regelverk för “Validering, felhantering och kvittens”. Enligt detta ska deltagarorganisationer validera och kontrollera meddelanden vid såväl sändande som mottagande av meddelanden. Meddelandetjänsten är normalt den komponent som behöver ha förmåga att tillämpa regelverket.

Regelverket innehåller kontroller såsom:

• Följsamhet mot regler i specifikation
• Meddelandevalidering (schema och schematron)
• Skydd mot skadlig kod (skanning)
• Kontrollera avsändare och mottagare

Se Specifikation av validering, felhantering och kvittens Länk till annan webbplats..

5.2.2 eDelivery realiserar transportlagret

I den framtagna lösningen utgörs transportlagret och delar av de gemensamma komponenterna av eDelivery (Se Ref. R6 CEF eDelivery), ett byggblock framtaget av EU:s organisation Connecting Europe Facility (CEF).

Figur: Byggblocket eDelivery för säkert utbyte av dokument och data mellan parter. Källa: CEF.

eDelivery syftar till att utgöra ett generellt byggblock för säker robust överföring av dokument och data mellan parter över internet, eller annat privat nätverk, och följer en s k fyrhörningsmodell där sändande system via sin accesspunkt skickar till mottagande system via dess accesspunkt. Kommunikationen behöver alltså inte gå över en central hub som i 3/5-hörningsmodeller.

Egenskaper:

• Alla till alla – ”peer-to-peer”
• Generisk transportinfrastruktur - Olika meddelanden och dokumenttyper kan överföras
• Överföring sker asynkront
• Varje ansluten deltagarorganisation (party) registrerar vilka dokumenttyper som kan utbytas

Figur: eDeliverys 4-hörningsmodell för säker robust transport. Källa: CEF. C1/C4 – deltagande parters anslutna system (backend), t.ex. anpassat verksamhetssystem eller en renodlad meddelandeklient, som användare använder för att skicka och ta emot. C2 – sändarens accesspunkt. C3 – mottagarens accesspunkt.

Om man placerar in eDeliverys begrepp, Access point, Connector, Backend och Corner 1 - 4, i referensmodellen för säker meddelandeöverföring ovan, får vi följande bild.

Figur: eDeliverys 4-hörningsmodell mappad mot referensmodellen för säker meddelandeöverföring. Se bilden i en större version.

5.2.2.1 Transportprotokollet AS4

eDelivery-ramverket ger stöd för att i princip använda flera olika transportlager för olika typer av överföringar, men det transportprotokoll som är det primärt stödda av CEF är AS4 (Se OASIS AS4 transportprotokoll).

AS4-protokollet har bl.a. följande egenskaper:

• Transporten är baserad på WebService-stacken över HTTP.
• Transporten är oberoende av formatet på nyttolasten (payload agnostic). AS4 kan utväxla olika typer av nyttolast, t.ex. XML, JSON, HL7, PDF, binära format osv.
• Inbyggt stöd för komprimering av nyttolast (payload compression)
• Konfidentialitet för meddelandet genom stöd för både transport- och meddelandekryptering mellan accesspunkter
• Dataintegritet dvs. skydd mot förvanskning eller förlust av meddelande under transport, bl.a. genom e-stämpel (e-seals)
• Säker signerad kvittens av överfört meddelande (transport receipt / evidence of delivery) levereras synkront.
• Stöd för duplikateliminering för att säkerställa att ett meddelande levereras en och endast en gång.

Figur. AS4 översikt. Källa CEF.

5.2.2.2 Profilen eDelivery AS4

I SDK har AS4 tillämpats utifrån den rekommenderade profilering för eDelivery som CEF tillhandahåller, eDelivery AS4, samt Diggs profilering av AS4-protokollet. Se Transportprofil AS4.

Figur. Kommunikationsmönster enligt eDelivery AS4. Källa CEF.

Profilen eDelivery AS4 preciserar bl.a.:

• Att kommunikationsmönstret är envägs/PUSH (one-way PUSH), vilket innebär att meddelandet tekniskt överförs från avsändande system till mottagande system. En meddelandekvittens (meddelande mottagen), skickas som ett eget anrop i den andra riktningen. AS4-protokollet stödjer även PULL, dvs. att mottagande system först får ett anropsmeddelande från avsändaren innehållande en länk där mottagande system hämtar meddelandet.
  Det senare mönstret (PULL) utvärderades i en förstudie för SDK, en nackdel som lyftes var problematiken för avsändaren att ansvara för att tillgängliggöra meddelanden för andra parter över tid.
  AS4 stödjer även tvåvägskommunikation där primära syftet är att leverera svar med innehåll på en begäran (request/response).
• Hur AS4 ska tillämpas i eDeliverys 4-hörningsmodell, t.ex. hur avsändande system (original sender - corner 1) respektive mottagande system (final recipient - corner 2) hanteras.
• Vilka säkerhetsmekanismer som är obligatoriska, t.ex. e-stämpling och meddelandekryptering.
• Hur nyttolasten paketeras (i separata MIME-delar).

Profilen Transportprofil AS4 beskriver avvikelser från underliggande eDelivery AS4 profil:

• Vilken version av eDelivery AS4 profil som skall tillämpas
• Meddelanden skall kuverteras enligt XHE. Se R17, eDelivery - Kuverteringsprofil XHE Länk till annan webbplats.
• Konfigureringar av Processing mode (P-mode)
• Tillämpning av PKI för AS4 meddelandekryptering av signering
• Tillämpning av TLS
• Valideringstillägg av meddelanden, funktionalitet som inte ingår i en standard mjukvara enligt CEF eDelivery Conformance Testing.

5.2.2.3 Profilering och specifikationer för Säker digital kommunikation

SDK-federationen tillämpar Diggs AS4 profilering med precisering enligt SDK federationens tekniska anpassningar mot plattform för eDelivery Länk till annan webbplats..

Transportprotokollet kapslar sedan in själva meddelandet (nyttolasten) som går mellan avsändande och mottagande parter (organisationer). Nyttolastens struktur återfinns i SDK Innehållsspecifikation Länk till annan webbplats.

För sammanställning av använda integrationsprofiler för meddelandeöverföringen se avsnitt 5.4.1, Nyttjade integrationsprofiler.

5.3.3 Lokaliseringstjänst och metadatatjänst

eDelivery realiserar även två gemensamma komponenter i lösningen som hanterar uppslag av mottagande parter och deras accesspunkter, för att avsändande part dynamiskt ska hitta fram till mottagande parts accesspunkt enbart med kännedom om vilken organisation man vill skicka till.

5.3.3.1 Lokaliseringstjänst - eDelivery Service Metadata Locator (SML)

Lokaliseringstjänsten SML är en central komponent som möjliggör att accesspunkterna dynamiskt kan hitta mottagande organisations Metadatatjänst enbart baserat på mottagande parts organisationsidentitet, samt vetskap om vilket typ av meddelandeutbyte som ska göras, i detta fall SDK meddelandeutbyte.

SML kan ses som ett försystem som hjälper till att registrera organisationer som ska deltaga i ett meddelandeutbyte. Registreringen av en organisation resulterar i en speciell post i nätverkstjänsten DNS (Domain Name System). När ett meddelandeutbyte ska ske slår avsändande accesspunkt upp mottagande parts post i DNS och får tillbaka adressen (URL) till aktuell Metadatatjänst. Notera att posterna i DNS är av typen Name Authority Pointer - NAPTR, se vidare Dynamic Delegation Discovery System (DDDS) Part Four. En NAPTR post skapa i DNS enligt Hash (Participant ID) + Participant ID Scheme + SML Domain.

5.3.3.2 Metadatatjänst - eDelivery Service Metadata Publisher (SMP)

Metadatatjänsten SMP håller mottagarens tekniska kommunikationsmöjligheter (kapabiliteter) i ett eDelivery-nätverk (t.ex. SDK federation). I SMP registreras en deltagande organisation och dess tekniska tjänster, dvs. tekniska adresser till accesspunkter, vilket transportprotokoll som stöds, och vilken typ av meddelandeutbyte och version dessa kan hantera. Även säkerhetscertifikat till accesspunkterna registreras i och hämtas från SMP.En avsändande accesspunkt slår mot SMP och kan med uppgifterna säkerställa att mottagaren kan hantera den typ av meddelandeutbyte som avses. På så sätt underlättas interoperabiliteten i eDelivery-nätverket (t.ex. SDK federation) över tid.

I eDelivery kan det finnas flera SMP-tjänster, t.ex. olika SMP för olika typer av meddelandeutbyten som e-faktura, säkra meddelanden (SDK), socialförsäkringsuppgifter osv, men SMP-tjänsten kan även konsolideras till en nationellt gemensam SMP. I Sverige hanteras en gemensam SMP-tjänst av Myndigheten för digital förvaltning, Digg (https://www.digg.se ), och SDK har registrerats som en underdomän inom den tjänsten.

Figur: Registrering av en deltagarorganisation inkl. metadata för deltagande i meddelandeutbyte. Källa CEF.

Uppgifterna registreras först i SMP och går sedan automatiskt vidare till SML och DNS.

Notera att all administration av SML/DNS sker via behörigt SMP-system som först har tilldelas ett säkerhetscertifikat.

Figur: Dynamiskt uppslag av en mottagande organisation (Party B) via DNS i ett visst meddelandeutbyte. Accesspunkten får adress till mottagarens SMP-tjänst (steg 2), från vilken hämtas de tekniska uppgifterna om vilken typ av meddelandeutbyte som mottagaren stödjer (steg 3). Se bilden i en större version.

5.3.4 Certifikatspubliceringstjänst (CertPub)

För att stödja insynsskydd (i form av meddelandekryptering och signering) mellan kommunicerande deltagarorganisationer (C1/C4) realiserar Digg tjänsten CertPub (Se . Tjänsten är en utökning av SMP där information om respektive deltagarorganisations certifikats publika nyckel publiceras.

Tjänsten möjliggör tillämpning av “Transportmodell - Utökad Bas”, se som stärker säkerheten då själva meddelandet krypteras och signeras. Meddelande krypteras innan det hanteras av Diggs transportinfrastruktur, dvs mellan accesspunkter via AP-operatörer. Detta innebär att endast avsedd mottagande deltagarorganisation (C4) kan ta del av (dekryptera) meddelandet.

Certifikatspubliceringstjänst tillämpar samma tekniska lösning för dynamiskt uppslag (dynamic discovery) som metadatatjänst - eDelivery Service Metadata Publisher (SMP).

5.3.5 Adresseringsmodell

En avgörande faktor för att verksamheter ska kunna använda SDK-federationen som ett fullvärdigt alternativ för säker digital kommunikation är:

• förmågan att hitta säkra adressater för de mottagare verksamheten behöver nå, och att kunna lita på korrektheten i dessa adresser.
• förmågan att säkerställa vem avsändaren av ett meddelande är.

En utmaning i detta är hur en verksamhet får tillgång till adressuppgifter till övriga parter och att upprätthålla kvalitet i dessa uppgifter.

Funktionellt kan verksamhetskraven något förenklat sammanfattas i:

1. att det ska gå att skicka meddelande till (adressera) en viss organisation
2. att det ska gå att skicka meddelande till (adressera) en funktion inom en viss organisation, liknande en funktionsbrevlåda.
3. att det ska gå att referera till medarbetare i respektive organisation.
4. att det ska gå att referera till interna referenser, t ex ärendenummer, hos respektive part.

OBS! Verksamheterna behöver i praktiken kunna adressera ett meddelande till flera funktioner/organisationer samtidigt (sändlista). Dock är en specifik meddelandeöverföring i SDK tekniskt sett alltid adresserad till endast en mottagare, alltså en kombination av organisation och funktion, t.ex. socialkontoret i Storkommun. Däremot finns inga hinder att en meddelandeklient stödjer att ange en sändlista. I SDK Innehållsspecifikation Meddelande Länk till annan webbplats., beskrivs vilka attribut som skall refereras vid sändlista.

Figur: Adressera och ange referenser för ett SDK-meddelande (konceptuellt). Se bilden i en större version.

De två första kraven, adressera organisation och funktion, ingår i SDK adresseringsmodell. De senare kraven ingår i SDK Innehållsspecifikation Länk till annan webbplats., dvs. hanteras som märkning av ett meddelande som adresseras till en funktion i en organisation, där märkningen hanteras vidare inom organisationens meddelandetjänst/applikation.

eDelivery ger ett grundläggande stöd att adressera säkert till en organisation via stödtjänsterna SMP och SML. Funktionaliteten är dock ganska begränsad när det gäller att söka och beskriva organisationer, även om det teknisk skulle vara möjligt att utöka strukturerna.

Det saknas direkt stöd i eDelivery för att hantera den inre nivån med funktioner inom respektive organisation. Det finns exempel på tillämpningar av eDelivery som har lagt till en katalogfunktionalitet där det ges bättre möjligheter att beskriva organisationer, söka på organisationer osv.

Av ovanstående skäl har det i SDK-federationen lagts till en gemensam tjänst för att hantera och söka på adressater, SDK adressbok, vilken beskrivs mer nedan.

5.3.6 Principer för adressering

Följande principer har definierats för hantering av adressinformation i SDK:

• Varje organisation ansvarar för sin egen adressinformation, distribuerad administration ska vara möjlig.
• Det ska gå att administrera adressinformation
  • via ett gemensamt administrativt gränssnitt för behöriga användare inom organisationen
  • alternativt ansluta ett eget system med befintlig adresskälla (typiskt en katalogtjänst).
• Gemensamma integrationsprofiler (api:er) tas fram
  • för att från meddelandeklienter kunna söka adressuppgifter för mottagare
  • för att från eget system med befintlig adresskälla kunna publicera/uppdatera adressuppgifter för mottagare (API för uppdatering saknas)
• Dynamisk adressering baserat på organisation och efterfrågad typ av meddelandeutbyte (för SDK är detta "säkert meddelande", men kan vara t.ex. e-faktura eller dylikt i andra sammanhang).

Principerna syftar bl a till att:

• Möjliggöra hög datakvalitet genom att hålla uppdatering av uppgifterna så nära källan (organisationen själv) som möjligt.
• Undvika onödig dubbelregistrering av uppgifter.
• Möjliggöra att snabbt komma igång med säker meddelandeöverföring för organisationer med en eller ett fåtal funktionsbrevlådor.
• Undvika att exponera organisationens interna organisationsstruktur i adressboken, genom att exponerade funktioner inte direkt behöver motsvara den interna strukturen.
• Göra det enklare att hantera att organisationer gör tekniska ändringar IT-systemen, t.ex. byter den tekniska adressen för accesspunkten, genom den dynamiska adresseringen baserat på organisation.

5.3.6.1 Underhålla adressinformation

Figur: Underhåll av adressinformation för SDK meddelandeutbyte. Se bilden i en större version.

Bilden ovan beskriver de komponenter som behövs för att realisera funktioner för att registrera och underhålla adressinformation för SDK meddelandeutbyte.

För att administrera adressuppgifter för en organisation behöver organisationen först läggas upp i SMP-tjänsten tillsammans med annan metadata.

Adressboken är ett register med utökade adressuppgifter för respektive deltagande organisation. Organisationsidentifieraren i SMP-tjänsten återfinns även i adressboken och används för att koppla organisationens metadata till adressuppgifterna.

5.3.6.2 Använda adressinformation

Figur: Hur adressinformation används när ett meddelande skickas, exempelflöde.

Bilden ovan beskriver ett exempelflöde för hur adressuppgifter, och i viss mån även referenser, används när ett meddelande adresseras och skickas. I exemplet ovan ska en sändare skicka ett meddelande till socialkontoret i Sundbybergs Stad.

Förutsättning: Lars använder en meddelandetjänst för att i detta exempel skicka till Sundbybergs Stad. Flödet består i huvudsak av följande steg:

1. Lars söker på "sundbyberg.." och systemet slår i SDK adressbok och hittar Sundbybergs Stad samt de funktioner som kommunen lagt upp som mottagare.
2. Lars väljer funktionen "Socialkontor" i kommunen och skickar sedan meddelandet.
   1. Meddelandetjänsten skapar ett NAPTR uppslag utifrån hash av identifieraren "0203:sundbyberg.se” samt SML zon, vilken används för att göra ett DNS-uppslag. Tillbaka kommer adressen till den SMP-tjänst som hanterar Sundbybergs Stad.
   2. Meddelandetjänsten hämtar “Sundbybergs Stads” publika nyckel från Certifikatpubliceringstjänsten (CertPub). Adresserar och skapar meddelandet som krypteras och signeras.
3. Meddelandetjänsten skickar meddelandet vidare till accesspunkten.
4. När meddelandet ska skickas av accesspunkten, skapas ett NAPTR uppslag utifrån hash av identifieraren "0203:sundbyberg.se" samt SML zon, vilken används för att göra ett DNS-uppslag. Tillbaka kommer adressen till den SMP-tjänst som hanterar Sundbybergs Stad.
   1. Accesspunkten gör uppslag mot SMP-tjänsten och får tillbaka nödvändig metadata för att kunna skicka meddelandet till Sundbybergs Stad accesspunkt (AP2).
5. Accesspunkten (AP1) skickar meddelandet till mottagande accesspunkt (AP2) baserat på uppgifterna från SMP.
6. Sundbybergs Stad meddelandetjänst fångar upp inkommit meddelande, kontrollerar avsändare mot SDK Adressbok och tillgängliggör det för den funktionsbrevlåda som adresserats. Här kan behöriga medarbetare logga in och få tillgång till meddelandet.
   1. Eventuella referenser som angivits för meddelande, t.ex. specifik handläggare eller ärendenummer, hanteras av mottagande organisation, t.ex. för att knyta meddelandet till ett internt ärende.

5.3.7 Stöd för spårbarhet, svar och konversationer

I ramverket för SDK finns produktoberoende stöd för att:

• unikt spåra ett meddelande på meddelande- och transportnivå (AS4.MessageId).
• koppla svar till det meddelande som svaret avser (M.refToMessageId).
• koppla kvittens till det meddelande som kvittensen avser (M.MessageId)
• koppla samman ett meddelandeflöde i en konversation (meddelandetråd) (M.conversationId).

Stödet är realiserat genom att det finns ett antal identifierare dels i transportlagret (transportkuvert) och dels i meddelandelagret (meddelandekuvert).

Figur: Identifierare som stöd för spårbarhet, korrelation och konversationer i meddelandeöverföring. Observera att bilden inte illustrerar XHE-paketering som krypterar och signerar meddelandekuvert.

5.3.7.1 Identifierare i transportlagret

5.3.7.1 Identifierare i meddelandelagret (nyttolast header)

5.3.7.2 Spårbarhet till visst meddelande

För att kunna spåra hur ett visst meddelande flödar hela vägen från avsändaren till mottagaren behöver ett meddelande kunna identifieras i alla lager från verksamhet, meddelande till transport.

• MessageId i meddelandelagret sätts av sändande meddelandetjänst som unik identifierare av verksamhetsmeddelandet.
• XHE.ID sätts av sändande meddelandetjänst till samma som id som M.MessageId.
• MessageId i transportlagret sätts som en separat unik identifierare för denna specifika överföring av meddelandet. En ev. omsändning av ett meddelande mellan två accesspunkter har samma T.MessageId.
• Meddelandelagret erhåller T.MessageId från transportlagret när meddelandet överförs för att skickas.

Medelandelagret har krav på att logga både M.MessageId och T.MessageId för meddelandet för att få spårbarhet genom hela meddelandeflödet.

OBS! Meddelande-id i resp. lager hålls isär för att få en renare skiktad modell där det blir lättare att sända om meddelanden vid fel (exakt samma meddelande kan skickas om), samt underlättar att vid behov nyttja olika transportlager för meddelandeöverföring.

5.3.7.4 Transportkvittens

Mottagarens accesspunkt skickar automatiskt och synkront, efter validering av transportkuvertet, ett ”signalmeddelande” innehållande transportkvittens (SignalReceipt) tillbaka till avsändarens accesspunkt.

T.RefToMessageId på transportnivån används för att koppla samman meddelande och transportkvittens.

5.3.7.5 Meddelandekvittens

• Mottagarens Meddelandetjänst skickar automatiskt, efter dekryptering och validering av meddelandet struktur och innehållen en meddelandekvittens tillbaka till avsändaren.
• RefToMessageId på meddelandenivå används för att koppla samman meddelanden och meddelandekvittens.
• Id sätt till XHE.Id (M.MessageId) för det meddelande som kvitteras.
• Meddelanden kvitteras med “ACCEPTED“ (Accepteras) eller “REJECTED“ (Accepteras ej) .

5.3.7.6 Besvara meddelande och konversationer

När en användare väljer att svara på ett tidigare erhållet meddelande, skapas en koppling mellan det nya meddelandet och det meddelande som besvaras. Samtidigt kopplas meddelandena samman i en meddelandekonversation (tråd).

• Avsändarens Meddelandeklient använder ConversationId för att gruppera meddelanden i konversationer (trådar).
• När ett meddelande besvaras, sätts RefToMessageId för det meddelande som besvaras.
• Inom respektive konversation (tråd) visar RefToMessageId sekvensen av meddelanden i tråden - vilket meddelande som besvarar vilket.
• Användarens Meddelandeklient kan använda RefToMessageId för att sortera meddelanden i en logisk ordningsföljd inom en konversation/tråd.

5.3.7.7 Komplettera meddelande

• Att komplettera ett meddelande innebär att två meddelanden kopplas till samma meddelande (messageId) via RefToMessageId.
• När ett meddelande kompletteras, sätts meddelandeId från det första meddelandet till RefToMessageId .
• Ett meddelande kan kompletteras flera gångar (begränsande regel saknas).
• Samma “ConversationId” från det första meddelandet återanvänds. Detta för att gruppera meddelanden i konversationer (trådar).

5.3.7.8 Skicka meddelande till flera mottagare

Att skicka ett meddelande till flera mottagare innebär att varje mottagare får ett nytt meddelande. Mottagaren kan inte se att samma meddelande har skickats till flera mottagare.

• Varje meddelande får ett nytt meddelande med ett nytt “messageId“
• Befintlig konversation kan återanvändas eller en ny konversation kan skapas.

5.4 Integration med omvärlden

Meddelandeklienter (klienter) integrerar med:

1. Gemensamt adressregister - SDK adressbok.
2. Identifieringstjänst (Identity Provider, IdP) för att hantera stark autentisering för inloggade användare i meddelandeklienten, och som även kan stödja en effektiv behörighetshantering i applikationerna.
3. En katalogtjänst för medarbetare och organisation som kan ge stöd för funktioner som
   1. att knyta behörighet och funktionalitet till funktionsbrevlådor,
   2. att välja medarbetare som egna referenser för meddelanden,
   3. att skicka notifiering t.ex. via e-post eller sms vid inkomna meddelanden som berör en eller flera medarbetare.

Det är ett lokalt ansvar exakt hur organisationen realiserar identitet och åtkomst i sin organisation, se bilaga för IT-säkerhet inom SDK Länk till annan webbplats..

För rekommenderade mönster för hur realisera identitet- och åtkomsthantering i meddelandeklienten, se “R3 Referensarkitektur - Identitet och åtkomst”. Det rekommenderas även att följa Referensarkitektur för Kataloginformation för utformning av kataloglösningar.

Meddelandetjänst integrerar med:

1. Gemensamt adressregister (SDK adressbok).
   1. Meddelandetjänsten validerar meddelandets utgående och inkommande funktionsadress.
2. DNS för dynamiskt uppslag av Certifikatspubliceringstjänst-tjänst.
3. Certifikatspubliceringstjänst (CertPub - Se )
   1. Gemensamt register innehållande anslutna deltagarorganisationers publika nyckel.
      1. Meddelandetjänst hämtar mottagarens publika nyckel för meddelandekyptering (Se Transportmodell - Utökad Bas)
      2. Meddelandetjänsten hämtar avsändarens publika nyckel för att validera meddelandets signatur (Se Transportmodell - Utökad Bas)
   2. Certifikatstjänster (Certifikatsutgivare - CA) för att skapa tillit till och kontroll av giltighet för O2O-certifikat (spärrtjänster).

Accesspunkter integrerar med:

• DNS för dynamiskt uppslag av SMP-tjänst.
• Metadatatjänst (SMP) för uppslag av metadata för mottagarens tekniska förmågor avseende säkert meddelandeutbyte.
• Certifikatstjänster (Certifikatsutgivare - CA) för att skapa tillit till och kontroll av giltighet för säkerhetscertifikat (spärrtjänster). Se PKI för Accesspunkter Tjänstebeskrivning.

5.4.1 Nyttjade integrationsprofiler

5.4.2 Nyttjade plattformsfunktioner

Se sammanställning av använda gemensamma och lokala komponenter under avsnitt Integration med omvärlden ovan.

5.5 Felhantering

För principer och ansvarsfördelning kring felhantering se specifikation av validering, felhantering och kvittens samt Stöd för spårbarhet, svar och konversationer ovan.

Felhantering och kvittenser hanteras både på transportnivå och meddelandenivå. På transportnivå specificeras hanteringen av transportprotokollet, se avsnitt 5.1.4 eDelivery realiserar transportlagret. På meddelandenivå styrs detta av specifikation av validering, felhantering och kvittens, där Meddelandespecifikation Meddelandekvittens Länk till annan webbplats. används för att kvittera meddelanden eller signalera fel.

• Respektive produkt som realiserar en accesspunkt ansvarar för att dokumentera de felmeddelanden, fel- och statuskoder som accesspunkten tillhandahåller till meddelandetjänster.
• Respektive produkt som realiserar en meddelandetjänst ansvarar för att dokumentera de felmeddelanden, fel- och statuskoder som meddelandetjänsten tillhandahåller till meddelandeklienter.

5.6 Realisering av användargränssnitt

Respektive produkt som realiserar en meddelandeklient ansvarar för att realisera gränssnittet mot slutanvändaren. Användargränssnitten ska kräva stark autentisering och uppfylla kraven enligt Regelverk för deltagarorganisation inom SDK Länk till annan webbplats..

Webbaserat användargränssnitt finns framtaget för underhåll av metadata och adressuppgifter i de gemensamma komponenter (SMP, CertPub och SDK adressbok). Det har utformats så att moderna webbläsare kan användas och med standard HTML i största möjliga utsträckning. Användargränssnittet ska kräva stark autentisering och uppfylla kraven enligt Regelverk för deltagarorganisationer inom SDK Länk till annan webbplats..

6. Säkerhet

6.1 Säkerhetsklassificering av information

En kartläggning av externa krav vid kommunikation via Säker digital kommunikation har gjorts, vilken även innefattar lagkrav, se Regelverk för deltagarorganisation Länk till annan webbplats..

Riskanalys avseende informationssäkerhet utförs löpande för lösningskonceptet där både SDK-federationen (Digg) och transportinfrastruktur (Digg) ingår. För att vidta lämpliga skyddsåtgärder krävs att analyser görs av de risker som finns i gemensamt lösningskoncept. Riskminimering i den tekniska lösningen

Nedan följer ett urval av åtgärder för att minimera risk i lösningen:

• Datakvalitet för adressuppgifter
  • Huvudprincipen är att varje deltagande organisation administrerar sina egna uppgifter för att undvika "mellanhänder" där så möjligt. Administration sker via behöriga starkt autentiserad administratör.
  • Spårbarhet via loggning.

• Skydd mot skadlig kod
  • Federationen har tagit fram och principer för validering och felhantering som varje anslutande meddelandetjänst har att förhålla sig till. Principerna ingår i det gemensamma regelverket för meddelandeutbyte inom SDK, som varje part behöver följa. Principerna innebär att en anslutande meddelandetjänst ansvarar för innehållsvalidering inkl. scanning av skadlig kod, både innan ett meddelande skickas och efter att ett meddelande mottagits av meddelandetjänsten. Se vidare avsnitt Validering och felhantering.

• Tillgänglighet
  • Meddelandeöverföringen bygger på en s.k. 4-hörningsmodell, där meddelandeöverföringen inte behöver passera centrala noder, utan kan gå direkt mellan deltagarorganisationers AP-operatörer som tillhandahåller accesspunkter, och vidare till verksamhetssystemen. Överföringen är asynkron med köhantering och omsändning vid tillfälliga fel i infrastrukturen, vilket skapar goda förutsättningar för en för användaren upplevd god tillgänglighet för systemet. Se Asynkront meddelandeflöde.
  • Viktiga komponenter ska sättas upp i enlighet med de SLA-krav som ställs av SDK-federationen (Digg) respektive ansvarig för Plattform för eDelivery (Digg). Detta innebär att flera kluster per tjänst (redundans), t.ex. accesspunkter och metadatatjänst behöver sättas upp.
  • Transportinfrastruktur (Digg)
  • Lokaliseringstjänst (SML): ej nödvändig för att sända/mottaga meddelanden; komponenter vid administration av uppgifterna (när ny organisation ska registreras, tas bort eller om uppgiften skulle vara fel i SML).
  • Domännamnsystem (DNS): kritisk gemensam komponent; har en distribuerad arkitektur där EU:s instans är dubblerad.
  • Metadatatjänst (SMP): kritisk gemensam komponent för att sända/mottaga meddelanden. Flera instanser (kluster) kan skapa redundans.
  • Certifikatpubliceringstjänst (SMP): kritisk gemensam komponent för att möjliggöra kryptering/signering och validering av signaturer för meddelanden. Flera instanser (kluster) kan skapa redundans.

• Accesspunktsoperatör (AP-operatör).
  • Varje accesspunkt är kritisk för att sända/mottaga meddelanden för den organisation som är ansluten till accesspunkten i fråga. Vid tillfälliga avbrott ska accesspunkt och meddelandetjänster köa meddelanden för omsändning.
  • SDK-federationen (Digg)
    • Adressbok (SDK adressbok): kritisk gemensam stödtjänst för att möjliggöra adressering av meddelanden. Flera instanser (kluster) kan skapa redundans.

• Konfidentialitet
  • I lösningen ingår både transport- och meddelandekryptering för att minimera risken för att obehöriga kan läsa information som skickas över SDK.
    • Transportkryptering (TLS)
      • Kravställs för intern och extern trafik (C1-C2-C3-C4)
      • AS4 meddelandekryptering (WS-Security AP till AP)
        1. Kravställs mellan deltagarorganisationers AP-operatörer som tillhandahåller Accesspunkt (C2-C3).
        2. EU-organisationen CEF har ett certifieringsprogram (CEF eDelivery Conformance Testing) med tillhörande testsviter som syftar till att bedöma om programvara och implementering för accesspunkter möter kraven som är specificerade för eDelivery.
      • Payloadkryptering (kryptering och signering av nyttolast, SDK meddelandet)
        1. Kravställs innan meddelandet sänds till AP-operatörer för leverans (C1-C4).

För ytterligare beskrivning av de säkerhetsmekanismer som ingår i lösningskonceptet för SDK, se Säkerhetsmekanismer nedan.

6.2 Säkerhetsmekanismer

6.2.1 Tillitsmodell och ansvar

Att ansluta en deltagarorganisation för meddelandeöverföring inom SDK federationen omfattar efter godkännande bland annat att tillit behöver skapas till aktörer inom SDK federationen och dess transportinfrastruktur.

I praktiken skapas tillitskedjor till godkända certifikatsutgivare samt signerat metadata i gemensamma komponenter (SMP, CertPub).

Figur: Illustrerad tillitsmodell och ansvar.

6.2.2 Säkerhetsarkitektur för meddelandeöverföring

Basen för säkerhetsarkitekturen för SDK bygger på CEF eDeliverys säkerhetsmodell, som i sin tur består av säkerhetsmekanismer som möter krav i eIDAS-förordningen, se “ eIDAS-förordningen“ för en s k Electronic Registered Delivery Service.

Figur: Säkerhetsmekanismer (CTRL1-5) vid överföring av meddelanden mappade mot eDelivery 4-hörningsmodell samt mot krav (REQ1-6) i eIDAS-förordningen.

Modellen delar in arkitekturen i säkerhetsområden kopplade till eDeliverys 4-hörningsmodell enligt följande tabell:

Den organisationsöverskridande säkerheten hanteras primärt mellan meddelandetjänster(C1/C4) som tillämpar meddelandekryptering och signering (tillämpar R19 eDelivery - Transportmodell - Utökad Bas) innan meddelanden distribueras deltagarorganisationens AP-operatörens accesspunkter och understöds av AS4-protokollets säkerhetsmekanismer.

Den inre säkerheten regleras av krav på IT-säkerhetsfunktioner genom regelverk för anslutning för SDK informationsutbyte och tillhörande IT-säkerhetskrav. Även accesspunkten måste stödja dessa säkerhetsmekanismer.

Nedanstående tabell beskriver säkerhetsmekanismer (CTR1-5) vid överföring av SDK-meddelanden mer i detalj.

För en detaljerad beskrivning hur säkerhetsmekanismerna mappar mot reglering i eIDAS (eIDAS-förordningen), se “R9 eDelivery Security Controls Guidelines”.

6.2.3 Säkerhetscertifikat för meddelandeöverföring

För att åstadkomma de beskrivna säkerhetsmekanismerna krävs ett antal säkerhetscertifikat för kommunicerande IT-system och en tillit till dessa certifikat (trust).

• Transport kryptering (TLS)
• Signering av metadata i Metadatatjänst (SMP) och Certifikatspubliceringstjänst (CertPub, del av SMP)
• AS4 meddelande kryptering (WS-Security AP till AP)
• Payload kryptering och signering (Kryptering och signering av nyttolast, SDK meddelandet)