Innehållsförteckning
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. 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 eDeliuvery (baserad på CEF eDelivery).
För att etablera SDK-förmåga inom en användarorganisation behöver IT-stöd anpassas och en eller flera klienter/verksamhetssystem behöver anslutas.
Accesspunkt:
En Accesspunkt är en standardiserad mjukvara som anpassas enligt DIGGs tekniska specifikationer.
“AP-operatör“ är den part som tillhandahåller Accesspunkt till en användarorganisation i enlighet med DIGGs regelverk och avtal.
En AP-operatör kan vara användarorganisationen själv eller anlita en extern leverantör.
Meddelandetjänst:
En integrationskomponent för att hantera meddelandeflöden mellan accesspunkt och meddelandeklienter/verksamhetssystem
Dekrypterar, krypterar, signerar och validerar signatur på SDK meddelanden
Validera och kvittera meddelanden (meddelande mottaget)
Ansvarar för att leverera meddelandet internt inom användarorganisationen.
Meddelandeklient/Verksamhetssystem:
Representerar ett verksamhetssystem där användaren finns. Meddelandeklienten behöver a
npassas för att kunna hantera SDK-meddelanden och kvittenser
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.
Checklistan är framtagen för att stödja användarorganisationer gällande vägval som behöver göras eller utredas för att etablera lokal SDK-förmåga från meddelandeklient/verksamhetssystem till accesspunkt.
Dokumentet avhandlar den del av it-stöd och lokal infrastruktur som inom eDelivery betecknas som backend, dvs. mellan Meddelandeklient/Meddelandetjänst och accesspunkt
1.1 Målgrupp
Personer som ska genomföra förstudier eller analyser av behov och ta fram lösningsförslag för att etablera lokal IT-förmåga för SDK-anslutning.
Lösningsarkitekter
Projektledare/utredare
1.2 Dokument
Nedan listat ett urval av dokumentation och specifikationer som är relevanta vi anpassning av lokala komponenter för utbyte av SDK meddelanden.
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)
Säker digital kommunikations (SDK) gemensamma regelverk inom informationssäkerhet är framtaget för organisationer som har för avsikt att ansluta till SDK och specificerar de säkerhetskrav som ställs på anslutna aktörer till SDK.
I dess bilagor bilaga beskrivs it-säkerhetskrav, vilka är en integrerad del av regelverket. Därutöver regleras krav på t.ex. användarorganisationers lokala komponenter inklusive tillgänglighet samt anslutningsprocess till SDK i SDKs övriga gemensamma regelverk.
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
Avsnittet beskriver vilka vägval som kan bli aktuella för en användarorganisation. SDKs referensmodell delar upp de förmågor som behöver etableras i tre block. Dessa “block” bör ses, och kunna hanteras, som fristående komponenter.
Oavsett anskaffningsstrategi är Meddelandetjänst/meddelandeväxel en strategisk komponent då den är central för en användarorganisations meddelandeutbyte mellan en/flera meddelandeklient/verksamhetssystem och accesspunkt för vidare distribution inom SDK-federationen.
3.1 Helhetslösning
Helhetslösning innebär att Accesspunkt, Meddelandetjänst/Meddelandeväxel och Meddelandeklient/verksamhetssystem paketeras tillsammans. SDK-förmåga levereras och administreras som en tjänst.
En helhetslösning passar sannolikt organisationer som önskar anskaffa SDK-förmåga snabbt samt bedömer att en separat dedikerad klient passar verksamhetens behov.
Anskaffa lokala komponenter eller köpa som tjänst (Software as a service - SaaS) passar organisationer som önskar enkla paketerad lösning där ingen lokal drift eller förvaltning behövs.
Viktiga vägval:
Fördelar
Snabb anskaffning av SDK-förmåga.
En fristående klient kan användas av alla i organisationen.
Enkel anslutning till SDK-federationen.
Enklare administration då leverantör tar driftansvar för alla komponenter. Alla delar levereras och administreras som en tjänst.
Nackdelar
Separat klient för meddelandeutbyte - “ytterligare ett system för användarna”
Om ytterligare meddelandeklienter/verksamhetssystem behöver integreras kan stöd saknas eller behöva hanteras som ett tillägg. Anslutning till ytterligare meddelandeklienter/verksamhetssystem kan bli kostsam.
Information, t.ex. bilagor(PDF) måste importeras/exporteras mellan systemen.
Hantering av ärendehistorik och beslut om slutlagring eller gallring av dokumentation
3.2 Anskaffa eller utveckla olika delar själv
Att etablera SDK-komponenter separat passar sannolikt organisationer som långsiktigt vill integrera med flera meddelandeklienter/verksamhetssystem.
Organisationen bör ha en strategi för hur olika meddelandeklienter/verksamhetssystem skall integreras och kopplas till olika funktionsadresser.
Anskaffa eller utveckla olika delar själv passar organisationer som önskar installera och konfigurera AP själv, ta fram eller integrera med befintlig integrationslösning(Meddelandetjänst/meddelandeväxel) för meddelandevalidering, meddelandekvittens och informationsutbyte med meddelandeklient/verksamhetssystem.
Rekommendation:
Undersök om lokal kompetens inom integration finns.
Administration, anpassning/utveckling av integrationsflöden
Undersök om lokal infrastruktur t.ex. integrationsmotor (meddelandetjänst/Meddelandeväxel) kan användas för att hantera interna meddelandeflöden.
Undersök vilka förutsättningar som finns för att anpassa befintliga meddelandeklienter/verksamhetssystem.
Undersök om egen förmåga att drifta och förvalta lösning själv finns
Generalisera komponenter för:
Adressbokens apier.
Meddelandetjänstens apier
Accesspunktens apier
Fördelar
Egna komponenter ger anpassningsbarhet – full kontroll över koden.
Integrationsflöden kan skräddarsys för verksamhetens behov
Lätt att koppla på nya klienter (Verksamhetssystem)
Återanvända befintliga komponenter för förvaltning och rättighetsstyrning.
Lätt att byta implementation av accesspunkten
Nackdelar
Utvecklings- och förvaltningskostnader
Kräver ofta egna resurser och kompetens inom utveckling och integration, ev. även applikationsförvaltning, alternativt vana att kravställa leverantörer
Kräver fortsatt vidmakthållande av egna lösningar för att t.ex. löpande följa SDKs livscykel för tekniska specifikationer och dokumenttyper.
Kan bli komplicerad om lösningar om förvaltning fördelas på flera team och plattformar.
4. Säkerhet
SDKs Regelverk för anslutning till Säker digital kommunikation - Informationssäkerhet och IT-säkerhetsbilaga innehåller gemensamma krav som alla användarorganisationer behöver följa (Se ref R6).
4.1 Roller och ansvar - övergripande orientering
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. |
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. |
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
SDK-federationen är framtaget för att stödja informationsutbyte av känsliga personuppgifter. Det är därför viktigt att alla ingående komponenter lever upp till gällande lagar och regelverk för vald informationsklassning.
SDKs Regelverk för anslutning till Säker digital kommunikation - Informationssäkerhet och IT-säkerhetsbilaga innehåller gemensamma krav som alla användarorganisationer behöver följa (Se ref R6).
Lokalt ansvar:
Ansvarsförhållandet för meddelandeinnehåll ligger hos den avsändande parten. Det är upp till varje användarorganisation att själv göra en bedömning av konsekvensnivån i informationsinnehållet innan det skickas.
Rekommendation
Genomför Informationsklassning av information som skall utbytas inom SDK-federationen
Genomför en riskanalys för de informationsflöden som skall integreras med SDK-federationen.
Säkerställ att användarorganisationen följer krav enligt SDKs Regelverk för anslutning - informationssäkerhet och IT-säkerhetsbilaga
4.2 Lokalt ansvar: Inre säkerhet (Inom användarorganisationer)
Med inre säkerhet avses säkerhet mellan användarorganisationens interna komponenter.
SDKs Regelverk för anslutning till Säker digital kommunikation - Informationssäkerhet och IT-säkerhetsbilaga innehåller gemensamma krav som alla användarorganisationer behöver följa (Se ref R6).
Inom området inre säkerhet brukar nedanstående områden lyftas fram som viktiga.
Inloggning (Multifaktorautentisering)
Multifaktorautentisering (multifaktorsinloggning) kan uppnås på olika sätt. Ett vanligt sätt är att en e-legitimation används vid inloggning. E-legitimation kan integreras i användarens dator (operativsystem), alternativt används en intern/extern IdP (Identity Provider) via säkerhetsprotokoll som t.ex. SAMLv2/OAuth/OIDC.
Behörighetshantering (Auktorisation av personal)
Säkerställa att behörighetssystemet endast ger behörig användare tillgång till informationen
Säkerställa att adressering av funktionsbrevlådor motsvara behörighetsmodellen (sekretessgränser)
Behörighetskatalog
Behörighetsstyrning kan med fördel utgå från en för användarorganisationen gemensam katalog. Undersök om en gemensam behörighetskatalog kan användas, t.ex. lokalt Active Directory (AD) eller motsvarande.
Fristående Meddelandeklienter kan innebära att en klientspecifik behörighetskatalog behöver administreras.
Säkerhet mellan interna komponenter
Kommunikation mellan komponenter t.ex. Accesspunkt, meddelandetjänst och meddelandeklient skall vara transportkrypterad och autentisering av systemen skall tillämpas (endast behöriga system skall kunna hantera information).
Rekommendation
Komponenter som hanterar SDK-meddelanden måste vara anpassade för att hantera känsliga personuppgifter
IT-säkerhetsbilagan (R6) innehåller detaljerade krav på säkerhet och säkerhetsprotokoll.
4.3 Yttre säkerhet (mellan användarorganisationer)
Informationsöverföring mellan användarorganisationer hanteras av AP-operatörens Accesspunkt. DIGGs regelverk och specifikationer reglerar säkerhet mellan Accesspunkter I huvudsak är det följande säkerhetsmekanismer som tillämpas (Se ref R20):
Hanteras av AP-operatör - Accesspunkt:
Transportkryptering (TLS)
Tillförlitlig källa för metadata och teknisk adressering. Signering av metadata i Metadatatjänst (SMP) och Certifikatspubliceringstjänst (CertPub, del av SMP)
AS4 meddelandekryptering (WS-Security AP till AP)
Hanteras av användarorganisation - Meddelandetjänst:
Kryptering och signering (Kryptering och signering av nyttolast, SDK meddelandet. Signering av kvittensmeddelande)
Meddelandet krypteras och signeras innan det lämnas till Accesspunkt för meddelandeöverföring.
Läs mer om säkerhet i SDK SAD R5).
Rekommendation
SDK Testbädd (QA) har stödfunktioner som hjälper användarorganisationen att validera följsamhet till tekniska krav.
5. Säkerhet i IT-drift
SDK har inte tagit fram SDK specifika krav på lokal IT-drift. Vid anslutning till SDK regleras ansvarsförhållanden samt förväntningar gällande SLA (Se ref R9).
Anslutande användarorganisation förväntas ha en säker och robust IT-drift eller ha förmåga att kravställa en säker IT-miljö. Användarorganisationen skall säkerställa att lokal IT-miljö är utformad på ett sätt så den kan hantera känsliga personuppgifter.
Rekommendation
Inera har tagit fram bra anvisningar inom området som är tillgängliga för regioner och kommuner (Anvisningar finns tillgängliga via Inera kundservice).
Anvisning för Säkerhet i drift
Anvisning Informationssäkerhet
Anvisning för Loggning i driftsmiljön
6. Övergripande arkitektur
Avsnittet beskriver vilka övergripande frågor som behöver utredas för att kunna välja rätt anpassnings- och anskaffningsstrategi för att etablera lokal SDK-federation.
SDKs övergripande arkitekturbild visar att olika komponenter behöver etableras av användarorganisationen (inom grå ruta). En användarorganisation kan anta rollen AP-operatör och själv tillhandahålla Accesspunkt eller anlita externa part.
6.1 Ansvar för SDKs olika delar
Utifrån SDKs ovanstående övergripande arkitekturskiss fördelas ansvaret för att etablera komponenterna samt kravuppfyllnad enligt tabell nedan. Kolumnen “omfattning” ger en indikation på omfattning i resursbehov (tid eller kostnad) att etablera.
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 har normalt många verksamhetssystem. Meddelandeklient/verksamhetssystem integrerar med SDK-federationen via Accesspunkt samt ansvarar för permanent lagring av information. | L |
Meddelandetjänst/ meddelandeväxel | Användar-organisation | Meddelandeväxel, hanterar integration mellan accesspunkt och meddelandeklienter. En användarorganisation har normalt en meddelandeväxel men kan ha flera. Komponenten ansvarar också för kryptering, dekryptering, signering och validering av signatur samt validering och kvittering av meddelanden. | 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. | 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 ansvisning. | 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 |
Rekommendation:
Analysera vilka verksamhetsprocesser eller verksamhetsfunktion som skall anslutas till SDK-federationen
Analysera vilka verksamhetssystem eller meddelandeklient som kan användas för att stödja verksamhetsprocessen/verksamhetsfunktion
En meddelandeväxel är strategisk lokal SDK-förmåga som bör kunna stödja mer än ett verksamhetssystem/meddelandeklient
Analysera om er organisation har en gemensam behörighetshantering (t.ex AD)som kan användas för behörighetsstyrning av funktionsbrevlådor i meddelandeklient.
Komponenter kan etableras genom upphandling, avrop mot (framtida)ramavtal eller tas fram av egna resurser.
Analysera vilka anpassningsmöjligheter som finns i verksamhetssystem/meddelandeklient
Informationssäkerhetskrav
Krav på multifaktorautentisering (meddelandeklient/verksamhetssystem)
Krav på behörighetsmodell
7. Meddelandeklient, Meddelandetjänst och Accesspunkt
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 | Meddelande | AS4 | |
Standardiserad mjukvara tillgänglig | Anpassning enligt DIGG krävs | ||
Validering och kvittering av meddelande | |||
Loggning | |||
Routing
| |||
Koppling till Adressbok | |||
Koppling till SMP/CertPub |
7.1 Meddelandeklient - Verksamhetssystem
En verksamhetsprocess, t.ex. att skicka / ta emot en orosanmälan, representeras i SDK Adressbok i form av en funktionsadress. Meddelandeklient/verksamhetssystem som ansvarar för lagring av meddelanden (ärendehistorik etc).
Alla funktionsadresser som skapas i SDK Adressbok skall i slutändan levereras till en meddelandeklient eller verksamhetssystem. Hur många Meddelandeklienter eller verksamhetssystem som skall anslutas till SDK flöden avgöras av det lokala IT-landskapets utformning.
Meddelandeklienten/verksamhetssystemet behöver kunna hantera två meddelandetyper (dokumenttyper, xml-meddelanden)
SDK Innehållsspecifikation - Meddelande
DIGGs Meddelandekvittens - Kvittens
En meddelandeklient/verksamhetssystem måste kunna hantera och skapa dokumenttypen “Meddelande“ samt dokumenttypen “Kvittens“.
Sammanfattning:
Rekommendation:
Meddelande
Meddelandeklient/verksamhetssystem måste kunna skapa och hantera meddelande och meddelandekvittenser (enligt specifikation).
Integration
Meddelandeklient/verksamhetssystem integreras med meddelandetjänst/meddelandeväxel.
Observera att SDK endast specificerar meddelanden, inte integrationsgränssnitt.
Integreras (Skicka/ta emot meddelanden, kontrollera meddelandestatus/kvittens) med meddelandetjänst/meddelandeväxel
Integration med SDK Adressbok är nödvändig, alternativt att ha uppdaterad en lokal läskopia av adressboken
7.2 Meddelandeformat
När det gäller meddelandeklient eller verksamhetssystem så kan det vara enklare att initialt välja en dedikerad meddelandeklient då denna kan vara enklare att anpassa efter SDK meddelandeformat.
Meddelandeformatet är “e-post liknande” innehållsmässigt enligt följande övergripande struktur:
Message
MessageHeader
Recipient
Sender
Message
Subject
Text
Attachement
Rekommendation
Några områden som man bör titta närmare på är att meddelandeklienten eller verksamhetssystemet kan:
Den meddelandeklient eller verksamhetssystem som skall anslutas behöver kunna hantera meddelanden (Dokumenttyper)
Innehållsspecifikation Meddelande(se ref R2)
DIGGs Meddeladekvittens (Se ref R12)
Hantera bifogade filer i form av PDF (Observera att endast PDF filer kan utbytes enligt nuvarande version av innehållsspecifikation).
Meddelanden bör kunna sorteras enligt en “meddelandetråd“ (konversations-id)
Statusmeddelanden skall kunna presenteras tillsammans med meddelanden
Transportkvittens - Meddelande har levererats till mottagarens accesspunkt
Meddelandekvittens - Meddelandet är validerat och är tillgängligt för mottagaren
Felhantering - Felmeddelanden
7.3 Meddelandetjänst - Meddelandeväxel
Användarorganisationen behöver ta fram en komponent som kallas Meddelandetjänst/Meddelandeväxel (MT). MT skulle kunna beskrivas som en integrationsmotor som löpande hämtar och lämnar meddelanden mellan accesspunkten och meddelandeklienter/verksamhetssystem (via dess interna t.ex. APIer: SOAP eller REST).
Se även “Bilaga 1: Visuellt stöd vid implementation av lokala SDK-komponenter” som innehåller ett exempel på hur SDK förmåga kan implementeras.
Meddelandetjänsten ansvarar för att
Kryptera, dekryptera, signera och validera signatur av meddelanden
Validera SDK meddelanden. Dvs kontrollera att meddelandet följer schema och regelverk.
Kontrollera att funktionsadressen är korrekt och är aktiv.
Skapa ett kvitteringsmeddelande (inkl felmeddelanden om en funktionsadress har angivits som inte finns aktiv)
Ansvarar för att "routa" meddelanden till det verkssamhetssystem (Meddelandeklient) som ansvarar för funktionsadressen. Man bör ta höjd för att kunna hantera flera meddelandeklienter.
Svarstidsbevaka skickande meddelanden (dvs att ett skickat meddelande kvitteras av mottagaren. En kvittering innebär att meddelandet är utlämnat och har nått mottagaren)
Kommunicera meddelandestatus till Meddelandeklient (Verksamhetssystem)
Ett säkerhetskoncept för att säkra organisationens “inre säkerhet“.
Transportkryptering
Autentisering av systemkomponenter
Behörighetskontroll
Certifikat för signering och kryptering av meddelanden
Externa komponenter
DNS för dynamisk inhämtning av metadata från SMP
CertPub (SMP) register med användarorganisationers publika nycklar (kryptering, validering av signatur).
SDK Adressbok för adressuppslag
Meddelandetjänst/meddelandeväxel en strategisk komponent då den är central för en användarorganisations meddelandeutbyte mellan meddelandeklient/verksamhetssystem och accesspunkt för vidare distribution inom SDK-federationen.
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 (konnektor) En adapter används för att uppnå lös koppling(integration) mellan Accesspunkt och Meddelandetjänst/meddelandeväxel. Denna komponent är inte standardiserat av EU/CEF (byggblock eDelivery).
Ingår endast i Meddelandetjänstens ansvar i de fall användarorganisationen också agerar AP-operatör. Detta kan vara vanligt förekommande i t.ex. helhetslösningar. Kan i en helhetslösning uppfylla ansvar med följsamhet till och hantering av de krav och regelverk som gäller för AP-operatörer inom SDK-federationen. D.v.s. hanterar t.ex. incidenthantering vid fel. 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. | 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”
| 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:
Rekommendation:
Meddelandetjänst/meddelandeväxel är en komponent där utveckling/anpassning är nödvändig.
Alla meddelanden krypteras genom att tillämpa DIGGs specifikationer XHE (Se R14, R18)
Varje meddelande (dokumenttyp) har sin tekniska utformning och valideringsregelverk.
Meddelandeklienter måste integreras via meddelandetjänsten
7.4. Accesspunkt (AP)
Accesspunkten är en integrationskomponent som är baserad på en standardiserad mjukvara. Accesspunkten består av applikationsserver, applikation och databas. Komponenten skall installeras och konfigureras enligt DIGGs anvisningar för att fungera i SDK-federationen (Se R15, R16, R17).
Accesspunkt (beroende på mjukvara) medger anpassade interna integrationsgränssnitt.
En accesspunkt som är integrerad i SDK-federationen kommer automatiskt ta emot och leverera meddelanden till/från användarorganisationer inom federationen.
Accesspunkten hanteras endast transport av meddelanden. Meddelanden skapas och hanteras av Meddelandetjänsten.
Lokalt ansvar:
Anskaffa en Accesspunkt
Alternativ: Via extern AP-operatör
Alternativ: Ansöka om att bli AP-operatör
Välja vilken mjukvara som skalla användas som accesspunkt.
Installera och konfigurera accesspunkt (applikationsserver, applikation, databas)
Konfigurera enligt DIGGs anvisningar
Installera godkänt certifikat i accesspunkt
Konfigurera “trust” till godkända certifikatsutställare
AP-operatör registrera vilka dokumenttyper och användarorganisation (deltagare )som accesspunkten skall kunna skicka och ta emot (hanteras via anslutningsprocess)
Federationsoperatör godkänner registrering i SDK-federation.
Accesspunkt integreras om Meddelandetjänst (MT)
Sammanfattning:
Rekommendation:
Anskaffa godkänd accesspunkt via en AP-operatör eller ansök själv om att bli AP-operatör hos DIGG.
Anpassa lokal driftinfrastruktur för kommunikation mellan accesspunkter. Säkerställ transportkryptering (TLS) t.ex. terminering av TLS.
8. SDK Adressbok
SDK Adressbok är ett gemensamt adressregister för information om SDK-anslutna användarorganisationer och funktioner inom dessa. SDK Adressbok är en komponent i SDK-federatioen.
Syftet med SDK Adressbok är:
Att vara en källa för adressuppgifter, genom att behöriga användare registrerar och underhåller information om en användarorganisation och dess funktioner (funktionsadresser) via adressbokens administrationsgränssnitt.
Att tillhandahålla funktionalitet för att hitta mottagare, genom att SDK-anslutna användarorganisationer kan söka och hitta andra anslutna användarorganisationer och deras funktionsadresser.
Adressboken tillhandahåller ett integrationsgränssnitt ett sk Sök-API som kan användas för direktintegration eller skapa en lokal läskopia.
Användarorganisationen anger behöriga administratörer under anslutningsprocessen och administrera själv sin information.
8.1 Strukturera adressboken - Använda standardiserade sökord
Adressboken ska struktureras för att stödja externa parters behov av att hitta rätt mottagare inom respektive användarorganisation (Strukturera inte utifrån den intern organisationsstrukturen). Funktionsadresser i SDK adressbok behöver beskrivas på ett enhetligt standardiserat sätt för att stödja extern sökning. Detta uppnås genom att tillämpa sökord för funktionsadress enligt de kodverk som finns tillgängliga inom SDK Adressbok.
I SDK finns i huvudsak tre typer av kodverk för att stödja behovet av att hitta rätt mottagare:
Geografisk hemvist: Var tillhandahålls funktionen (kommun, län eller nationellt).
Strukturkodver: Placering av funktion i verksamhetsstrukturen.
Sökkodverk: En sökkod(sökord) för en specifik funktion.
Rekommendation
Undersök om de kodver som finns tillgängliga i SDK Adressbok kan tillämpas eller om nya kodverk (R11) behöver läsas in i eller tas fram.
Strukturera funktionsadresser enligt “R10 SDK Adressbok Användarhandledning” Administratör“
8.2 Integrera med SDK Adressbok: Söka i SDK Adressboken
Användare av Meddelandeklienter/verksamhetssystem behöver kunna söka i SDK adressbok för att adressera ett meddelande. SDK adressbok innehåller alla anslutna användarorganisationers funktionsadresser.
Integration mot SDKs adressbok kan göras via SDKs Sök-API (Ref 11). Sök-API är framtaget för att stödja direktsökning men kan även användas för att skapa en lokal läskopia.
Skapa en lokal läskopia av adressboken
Genom att uppdatera en lokal läskopia kan integration med meddelandeklienter/verksamhetssystem underlättas då befintlig funktionalitet kan återanvändas.
Direktintegration via adressbokens Sök-API.
Funktioner: Fritextsökning, sökning baserat på urval och kodade värden.
Strukturerad sökning
Tillämpa kodverk
Rekommendation:
Lokal läskopia:
Fördelar:
Integration med befintlig kataloglösning kan underlätta integration med Meddelandeklient/verksamhetssystems.
Enklare integration
Mindre påverkan på meddelandeklient/verksamhetssystem
Minskar lokal påverkan vid SLA störningar i central central adressbok
Nackdelar:
“Avancerad“ kodad sökning mot adressboken kan vara svår att realisera
Lokal läskopia måste hållas uppdaterad och säker
Uppdateringar kan ta längre tid innan dessa får genomslag
9. Leverantörsmarknad
Idag finns inget specifikt ramavtal för SDK-komponenter. Det finns ett antal leverantörer som erbjuder SDK-komponenter, det finns ingen officiell lista över godkända mjukvaror från leverantörer (utöver accesspunkt som CEF tillhandahåller).
Etablering kan ske via befintlig avtal eller så kan en direktupphandling göras. SDK tillhandahåller dock inget kravunderlag 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.
Sammanfattning:
Rekommendation:
Bevaka SKL Kommentus kommande ramavtal för SDK komponenter Länk till SKL Kommentus - Säker digital kommunikation
Undersök om befintliga avtal kan användas för att anskaffa och anpassning av nödvändig mjukvara
10. FAQ på vanliga frågor kring anpassning
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? | Ja |
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
Nedanstående flödesscheman är ett visuellt stöd vid implementation av blocken som beskrivs i avsnitt 7.1 och 7.3, dvs. Meddelandeklient, Meddelandetjänst och det lager som definieras som Accesspunktkonnektor (d.v.s. det lager som krävs för AP-operatörers följsamhet till DIGGs regelverk t.ex. XHE-validering innan försändelse skickas till en CEF-godkänd accesspunkt).
De ger exempel på implementation med webbaserad meddelandeklient, dvs. inte integrerat verksamhetssystem, och är delvis baserade på hur SDK-Testbädd (QA) har utformat SDK Testklient.