Revisionshistorik

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).

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(AP):

• En Accesspunkt är en standardiserad mjukvara som anpassas enligt DIGGs tekniska specifikationer.

• “AP-operatör“ är den part som tillhandahåller Accesspunkt till en eller flera användarorganisation i enlighet med DIGGs regelverk och avtal (En Accesspunkt kan delas).

• En AP-operatör kan vara användarorganisationen själv eller anlita en extern leverantör.

• En Accesspunkt ska ha ett öppet tillgängligt API för att kunna integrera med olika Meddelandetjänster.

Meddelandetjänst(MT):

• 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).

• 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.

Meddelandeklient/Verksamhetssystem (MK):

• 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.

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

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.

Alternativ som bör övervägas:

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.

1. Block1: Accesspunkt och konnecktor

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.

Open

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.

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.

Open

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.

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.

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.

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).

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 (mTLS) kan även implementeras i skalskydd

• 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.

• Behörighetshantering mellan Accesspunkt och Meddelandeklienter.

Läs mer om säkerhet i SDK SAD R5).

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.

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

7. Meddelandeklient, Meddelandetjänst och Accesspunkt

Tabellen sammanställer områden som kan underlätta anslutande parts förstudie för införande

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 ska också ha ett behörighetssystem som säkerställer att endast behörig användare har tillgång till information som förmedlas via SDK-federationen.

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:

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

7.3 Meddelandetjänst - Meddelandeväxel

Användarorganisationen behöver etablera 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).

• 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 verksamhetssystemen (Meddelandeklienter) 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)

• Integrationsgränsnitt

  • Öppet integrationsgränssnitt (API)för att integrera med olika meddelandeklienter och accesspunkter

• 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.

Sammanfattning:

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:

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.

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

9. Leverantörsmarknad

Idag finns inget specifikt ramavtal för SDK-komponenter. 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 https://inera.atlassian.net/wiki/spaces/OISDK/pages/2823553290

Etablering kan ske via befintlig avtal eller så kan en direktupphandling göras. SDK tillhandahåller även stöd i form av en kravkatalog för anskaffning, utöver de tekniska specifikationer som finns publicerade. Mer information om kravkatalog för anskaffning finns här: https://inera.atlassian.net/wiki/pages/createpage.action?spaceKey=OISDK&title=Upphandling%20av%20teknisk%20l%C3%B6sning%20via%20Addas%20DIS&linkCreation=true&fromPageId=2716565840

Sammanfattning:

10. FAQ på vanliga frågor kring anpassning

Vanliga frågor som kan accelerera användarorganisationens förstudiearbete.

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.

Utgående meddelande

Inkommande meddelande