Revisionshistorik
Version | Datum | Författare | Kommentar |
|---|---|---|---|
0.9 | 2020-12-01 | Marco de Luca |
|
0.9 (2022) | 2022-02-14 | Marco de Luca | Revidering 2022
|
1.0 (2022) | 2022-02-28 | Marco de Luca | Beslutad version för Tjänsten Säker digital kommunikation. |
1.1 (2022) | 2023-09-12 | Marco de Luca | Uppdatering för att tydliggöra att komponenter bör kravställas att vara “öppna” för att minska risk för leverantörs inlåsning. |
1.2 (2023) | 2023-10-25 | Marco de Luca | Förtydligande att SDK Adressbok används för att söka fram och validera avsändare/mottagare. Uppdaterad information under sektion “Leverantörsmarknad” |
1. Inledning
Syfte: SDK är en säker transportinfrastruktur för asynkron punkt-till-punkt (meddelande levereras direkt till mottagarens Accesspunkt) arkitektur som bygger på DIGGs Transportinfrastruktur för eDelivery (baserad på CEF eDelivery).
...
En integrationskomponent för att hantera meddelandeflöden mellan accesspunkt och meddelandeklienter/verksamhetssystem. En användarorganisation kan ha en(1) meddelandetjänst.
Dekrypterar, krypterar, signerar och validerar signatur på SDK meddelanden.
Validera och kvittera meddelanden (meddelande mottaget).
Ansvarar för Validerar giltig avsändare och mottagare mot SDK Adressbok.
Ansvarar för att leverera meddelandet internt inom användarorganisationen.
En meddelandetjänst ska ha ett öppet tillgängligt API för att kunna integrera med olika Accesspunkter och Meddelandeklienter.
...
Representerar ett verksamhetssystem där användaren finns.
Meddelandeklienten behöver anpassas för att kunna hantera SDK-meddelanden och kvittenser.
Meddelandeklienten ska ha ett öppet tillgängligt API för att kunna integrera med olika Meddelandetjänster.
Söker mottagare i SDK Adressbok
Mål: Stödja en användarorganisation som skall etablera SDK-förmåga. Dokumentet lyfter fram områden som behöver utredas och vägval som behöver göras.
...
Läsaren rekommenderas även att besöka SDKs publiceringsplats https://inera.atlassian.net/wiki/spaces/OISDK/pages/2644705403
Ref | Dokument-id | Dokument länk |
|---|---|---|
R1 | Specifikation av validering, felhantering och kvittens | |
R2 | SDK Innehållsspecifikation - Meddelande | |
R4 | SDKs Testinstruktioner för anslutningstester | |
R5 | Säker digital kommunikation SAD | |
R6 | Regelverk för anslutning till Säker digital kommunikation - Informationssäkerhet och IT-säkerhetsbilaga | |
R9 | SLA Tillgänglighet | |
R10 | SDK Adressbok Användarhandledning Administratör | |
R11 | SDK Adressbok | Informationsmodell, kodverk och Sök-API. |
R12 | Meddelandespecifikation: Meddelandekvittens | DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se |
R14 | Transportmodell - Utökad Bas | DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se |
R15 | Transportprofil AS4 | DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se |
R16 | PKI för Accesspunkter Tjänstebeskrivning | DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se |
R17 | Accesspunktsoperatör - Gemensamma Regler och Rutiner | DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se |
R18 | Kuverteringsprofil XHE | DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se |
R19 | Certifikatspublicering - REST-bindning till SMP | DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se |
R20 | Plattform - Informationssäkerhet och tillitsmodell | DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se |
2. Sourcingstrategi SDK förmåga (Vägval för etablering)
...
Vid tillämpning av regelverk och specifikationer finns det frihet hur krav skall implementeras. Det finns en hel del vägval som anslutande användarorganisationer behöver överväga.
Vägval | |||
|---|---|---|---|
Accesspunkt vi AP-operatör | Meddelandetjänst | Meddelandeklient | |
Användarorganisation |
|
|
|
Alternativ som bör övervägas:
Alternativ | Kommentar |
|---|---|
Ta fram själv/Egen utveckling/Anpassa befintliga lösningar
|
|
Anskaffa komponenter
|
|
Gå samman/gör tillsammans med andra
|
|
Köpa som tjänst
|
|
3. Anskaffa helhetslösning eller anskaffa/utveckla olika delar
...
Inom SDK-federationen fördelas ansvar enligt följande.
...
Ansvarig för eDelivery transportinfrastruktur | I Sverige ansvarar Myndigheten för digital förvaltning, DIGG, för eDelivery transportinfrastruktur. |
SDK-federationsägare | SDK-federationsägare ansvarar för federationen gentemot ansvarig för eDelivery transportinfrastruktur. SDK-federationsägare kan utse SDK-federationsoperatör. För närvarande är Inera både SDK-federationsägare- och operatör. |
SDK-federationsoperatör | SDK-federationsoperatör är den organisation som förvaltar SDK och tillhandahåller SDKs gemensamma komponenter, miljöer och regelverk. För närvarande är Inera både SDK-federationsägare- och operatör. |
Accesspunktsoperatör (AP-operatör) | Accesspunktsoperatör avser den roll som ansluter användarorganisationen till eDelivery transportinfrastruktur via en accesspunkt. En AP-operatör kan hantera många användarorganisationer. |
Accesspunkt | Accesspunkten utgör respektive användarorganisations anslutningspunkt till eDelivery transportinfrastruktur. Accesspunkten är den anslutningspunkt som en användarorganisation använder för att överföra meddelanden till andra användarorganisationer i SDK via eDelivery transportinfrastruktur. En Accesspunkt kan delas av användarorganisationer. |
Användarorganisation | Användarorganisation avser den organisation som har anslutit eller har för avsikt att ansluta till SDK i syfte att överföra digitala meddelanden till andra användarorganisationer. Användarorganisation i SDK motsvarar deltagare i eDelivery transportinfrastruktur. |
4.1 Informationsklassning
...
S: Small
M: Medium
L: Large
Komponent | Ansvar | Beskrivning | Omfatt-ning |
|---|---|---|---|
Meddelandeklient/Verksamhetssystem | Användar-organisation | Meddelandeklienten eller verksamhetssystem är den komponent där verksamhetsprocessen och användarna finns. En användarorganisation kan ha många verksamhetssystem/meddelandeklienter. En funktionsadress slutdestination är Meddelandeklienten. Meddelandeklient/verksamhetssystem ansvarar för permanent lagring av information samt integrerar med SDK-federationen via dess Meddelandetjänst (MT). Meddelandeklient behöver kunna söka I SDK Adressbok. Komponenten bör ha ett öppet tillgängligt API som möjliggör integration med olika Meddelandetjänster. | L |
Meddelandetjänst/ meddelandeväxel | Användar-organisation | Meddelandetjänst/Meddelandeväxel, hanterar integration mellan accesspunkt och meddelandeklienter. En användarorganisation har normalt en meddelandetjänst/meddelandeväxel men kan ha flera. Komponenten ansvarar också för kryptering, dekryptering, signering och validering av signatur samt validering och kvittering av meddelanden. Validerar avsändare mottagare mot SDK Adressbok. Komponenten bör ha ett öppet tillgängligt API som möjliggör integration med olika Accesspunkter och Meddelandeklienter. | L |
Accesspunkt | AP-operatör | En användarorganisation har normalt en (1st) accesspunkt som hanterar alla dess meddelandeutbyten inom SDK-federationen. En Accesspunkt måste tillhandahållas av en rollen AP-operatör som regleras av DIGG. En användarorganisation kan vara AP-operatör. Komponenten bör ha ett öppet tillgängligt API som möjliggör integration med olika Meddelandetjänster. | S |
Accesspunkt validering | AP-operatör | En AP-operatörs Accesspunkt skall konfigureras enligt DIGGs ansvisningar och valideringsprocess | M |
Adressbok (gemensam komponent) | SDK-federationsoperatör | ||
Adressbok (Innehåll) | Användar-organisation | Behörig administratör underhåller funktionsadresser. Funktionsadressens tekniska adress behöver samordnas med meddelandetjänsten/meddelandeväxelns “routing”- funktion. Denna hanterar leverans av meddelande till funktionsadressens meddelandeklient/verksamhetssystem. Funktionsadresser bör också kodas(kodverk) för att öka sökbarhet och möjliggöra strukturerad sökning av funktionsadresser. Se avsnitt SDK Adressbok för mer information. | M |
SMP (gemensam Komponent) | DIGG Federationsoperatör (DIGG) | ||
SMP/CertPub (AP metadata) | AP-operatör | Behörig användare underhåller metadata(Certifikat, URL till AP etc) för användarorganisationens AP. Hanteras av AP-operatör via DIGGs anvisning. | S |
O2O-certifikat
| Användar-organisation | Certifikat för O2O-kryptering (Organisation till organisation) anskaffas från godkända certifikatsutgivare (Se Regelverk för anslutning R6.) | M |
Uppfyllande av informationssäkerhetskrav och SLA | Användar-organisation (via självdeklaration) | Krav på användarorganisationen gällande informationssäkerhet och it-säkerhet.
| M |
| Tips |
|---|
Rekommendation:
|
...
Tabellen sammanställer områden som kan underlätta anslutande parts förstudie för införande
Meddelandeklient | Meddelandetjänst | Accesspunkt | |
|---|---|---|---|
Informationslagring
|
|
| |
Informationslagring
|
| ||
Multifaktorsautentisering av personal |
| ||
Behörighetsstyrning av personal |
| ||
Autentisering integration |
|
|
|
Transportkryptering (TLS) |
|
|
|
Meddelandekryptering |
|
| |
Standardiserad mjukvara tillgänglig |
| ||
Validering och kvittering av meddelande |
|
| |
Integrerar direkt eller indirekt mot mot SDK Adressbok |
|
| |
Loggning |
|
|
|
Routing
|
| ||
Koppling till Adressbok |
|
| |
Koppling till SMP/CertPub |
|
|
7.1 Meddelandeklient - Verksamhetssystem
...
Bilden illustrerar på en övergripande nivå förmågor som meddelandetjänsten utför i SDK meddelandeflöde. Flödet kan appliceras för både inkommande och utgående meddelanden.
Meddelandetjänsten utgör en meddelandeväxel som transporterar meddelanden mellan meddelandeklienter (t.ex. verksamhetssystem) och användarorganisationens accesspunkt. Nedanstående tabell lista övergripande funktioner/förmågor som komponenten behöver stödja.
Se SDKs Testinstruktioner för anslutningstester (ref R4) för testfall som verifieras vid anlutning till SDK-federation.
Övergripande funktion/förmågor | Vilket stöd tillhandahållas av SDK federationen.(Testbädd - QA, Öppen Testmiljö för tjänsteleverantörer) |
|---|---|
Adapter (Connector) En adapter används för att uppnå koppling (integration) mellan Accesspunkt och Meddelandetjänst som inte är produktspecifik. Denna komponent är inte standardiserad av CEF. Adaptern bör ha ett öppet tillgängligt API för att möjliggöra integration av olika leverantörers lösningar.
| Verifieras vid DIGGs anslutningstester för AP-operatör. Verifieras även indirekt via SDK Testbädd (QA) genom att meddelanden skickas, valideras och kvitteras med t.ex. Testklient. Rekommenderade specifikationer:
|
Hämta(lämna) Komponent som löpande hämtar/lämnar meddelanden från accesspunkten. Det kan vara en meddelandekö, pollning eller hämtning baserat på notifiering. Funktionalitet:
| Verifieras i SDK anslutningstester indirekt genom att meddelanden skickas, valideras och kvitteras. Rekommenderade specifikationer:
|
Dekryptera, Validera Komponenten dekrypterar, validerar signatur, validerar meddelandets struktur dvs kontrollera att meddelandet följer schema och regelverk(schematron).
| Verifieras genom att meddelanden skickas, valideras och kvitteras med Testklient. Rekommenderade specifikationer:
|
Status Komponenten skapar ett sk kvitteringsmeddelande eller ett felmeddelande.
Persistens/lagring av meddelandet och meddelandets status under pågående transaktion.
| Verifieras genom att meddelanden skickas, valideras och kvitteras med Testklient. Rekommenderade specifikationer:
|
Vägval/”routing”
Vägval/routing funktion bör stödja olika verksamhetssystem/Meddelandeklienter. | Verifieras EJ av Testklient (lokal hantering) |
Skicka
| Verifieras indirekt genom att Testklient skickar ett kvitteringsmeddelande. Rekommenderade specifikationer:
|
| Verifieras EJ av Testklient (lokal hantering) Krav specificerade i Inre säkerhet i dokumentet: IT-säkerhetsbilaga till regelverk för anslutning till Säker digital kommunikation - Informationssäkerhet (Se ref R6). |
Komponent | Beskrivning |
|---|---|
Katalog | Katalogfunktion som innehåller funktioners tekniska adress etc. En funktionsadress behöver en teknisk adress för att kunna levereras till rätt meddelandeklient. I de fall det endast finns en Meddelandeklient kan denna komponent vara överflödig. |
Meddelandestatus | Persistens/lagring av meddelandet under pågående transaktion.
|
Dekrypter, Validera | Applikation som validerar meddelanden.
|
Vägval | Komponenten hämtar teknisk adress till den Meddelandeapplikation/verksamhetssystem som hanterar funktionsadress.
|
Router/Skicka | Komponenten levererar meddelandet till Meddelandeklient/verksamhetssystem.
|
Adapter/konnektor | Anpassningskomponent mellan meddelandetjänst och komponenter som Accesspunkt eller Meddelandeklient/verksamhetssystem.
|
Sammanfattning:
| Tips |
|---|
Rekommendation: Meddelandetjänst/meddelandeväxel är en komponent där utveckling/anpassning är nödvändig.
|
...
Idag finns inget specifikt ramavtal för SDK-komponenter. Det finns ett antal leverantörer som erbjuder SDK-komponenter. SDK publicerar en lista Adda inköpscentral kommer framöver att kunna erbjuda stöd i form av ett dynamiskt inköpssystem för Säker digital kommunikation. Mer information om det stöd som erbjuds via Adda finns att läsa här: https://www.adda.se/upphandling-och-ramavtal/planerade-och-pagaende-upphandlingar/saker-digital-kommunikation-DIS
Det finns även ett antal leverantörer som erbjuder SDK-komponenter. SDK publicerar en lista med godkända mjukvaror från leverantörer (utöver accesspunkt som CEF tillhandahåller). Se Anslutna leverantörer i SDK Öppen testmiljö (ÖTM) och leverantörer med godkänd mjukvara för MT/MK
Etablering kan ske via befintlig avtal eller så kan en direktupphandling göras. SDK tillhandahåller dock inget kravunderlag även stöd i form av en kravkatalog för anskaffning, utöver de tekniska specifikationer som finns publicerade.
Genom att använda ett ramavtal får användarorganisationen stöd med kravställan och etablering av nödvändiga SDK komponenter.
Mer information om kravkatalog för anskaffning finns här: Kravkatalog för anskaffning
Sammanfattning:
| Tips |
|---|
Rekommendation:
|
...
Vanliga frågor som kan accelerera användarorganisationens förstudiearbete.
Fråga | Svar |
|---|---|
Meddelandeklient (verksamhetssystem) | |
Kravställer SDK i detalj hur en klient skall fungera?
| Nej |
Finns stöd för klientsignering (person signera meddelandet som skickas) | Nej |
Finns funktionalitet för att se om mottagaren har läst meddelandet? | Nej |
Finns det funktionalitet för att se om meddelandet har levererats till mottagaren (användarorganisation)? | Ja |
Får avsändaren ett felmeddelande om t.ex. mottagarens anslutning ligger nere? | Ja |
Är det bara PDF som får bifogas i SDK meddelanden? | Nej |
Adressboken | |
Finns personer eller personal Adressboken? | Nej |
Är det användarorganisationen som ansvarar för att underhålla adressuppgifter i adressboken | Ja |
Kan man synkronisera adressboken med t.ex. HSA eller lokal katalog. | Nej |
Hur hittar man rätt i adressboken? Finns det färdiga regler och kodverk för kodning av funktionsadresser? | Ja |
Är all information i SDK adressbok öppet tillgänglig på internet? | Ja |
Finns det ett öppet sök API till adressboken? | Ja |
Kan man använda e-post i SDK? | Nej |
Tekniska gränssnitt | |
Är APIer mellan Accesspunkt, meddelandetjänst och meddelandeklient standardiserade? | Nej |
SDKs källkod | |
Delar Inera källkod för Testbäddens komponenter (Testklient, auktorisation) | Nej |
Bilaga 1: Visuellt stöd vid implementation av lokala SDK-komponenter
...