Frågor och svar om Säker digital kommunikation (SDK)

Digg ansvarar för tjänsten SDK, och är så kallad federationsägare.

SDK produktionsmiljö är en driftsmiljö som tillhandahålls av Digg som SDK federationsägare. SDK produktionsmiljö stödjer informationsubyte av uppgifter klassade upp till, och innefattande, konsekvensnivån allvarlig enligt Myndigheten för samhällsskydd och beredskaps (MSB) modell för klassificering av information. Testdata får inte förekomma i SDK produktionsmiljö.

eDelivery är ett byggblock framtaget av EU-kommissionens finansieringsprogram Connecting Europe Facility (CEF).

eDelivery syftar till att utgöra ett generellt byggblock för säker och robust överföring av dokument och data över internet mellan offentliga och privata organisationer samt medborgare. Informationsöverföring med eDelivery sker på ett standardiserat, säkert, tillförlitligt och tryggt sätt och följer en s.k. fyrhörningsmodell.

I Sverige ansvarar Myndigheten för digital förvaltning, Digg, för plattform för eDelivery.

Nivån på informationssäkerhet inom SDK är dimensionerad för att tillgodose skyddsnivå allvarlig enligt informationsklassningsmodell som tillhandahålls i Myndigheten för Samhällsskydd och Beredskaps (MSB) metodstöd för systematiskt informationssäkerhetsarbete. Det innebär att SDK uppfyller den säkerhetsnivå som krävs för att utbyta sekretessbelagd information som kan innehålla integritetskänsliga och känsliga personuppgifter.

Ja, det är endast dokument eller information som är klassad med högre känslighetsgrad än konsekvensnivå allvarlig enligt MSB:s modell som inte ska skickas via SDK. Det innebär att information kopplad till rikets säkerhet inte får skickas via SDK.

Exempel på information som SDK är tänkt att användas för regleras t ex i:

OSL – Offentlighets- och sekretesslagen ​

PDL – Patientdatalagen​

GDPR – Dataskyddsförordningen (The General Data Protection Regulation)​

SoLPUL – Lag (2001:454) om behandling av personuppgifter inom socialtjänsten​

SDK ska däremot inte användas för information som lyder under säkerhetsskyddslagen.

Nej, det är upp till varje organisation att kravställa funktionaliteten i respektive meddelandeklient, lära ut användningen av SDK och säkerställa vem som får behörighet till vilka funktionsbrevlådor internt och därmed behörighet att ta del av de meddelanden som kommer in.

SDK:s specifikationer stödjer alla typer av bilagor. Det finns dock en storleksgräns på 30 MB för ett SDK-meddelande inklusive bilagor.

När de gäller storlek på informationsmängderna, kan eDelivery, som SDK bygger på, hantera större filer och Digg kravställer i dagsläget att en Aaccesspunktsoperatör ska kunna hantera 100 MB. Det går alltså att öka storleken på SDK-meddelanden i en framtida utveckling av tjänsten, vilket kan bli aktuellt utifrån deltagarorganisationernas behov och förutsättningar att hantera större meddelanden och bilagor.

Ja, det går att skicka flera dokument, dvs bilagor i samma meddelande. Det beskrivs i teknisk specifikation SDK Innehållsspecifikation - Meddelande.

Storleksbegränsningen om 30 MB gäller hela meddelandet, dvs meddelandet inklusive alla bilagor. Begränsningen är satt för att alla parter ska kunna hantera denna typ av meddelanden.

Namnsättning på filnivå är inte definierat i SDK-meddelande eftersom det handlar om ostrukturerat innehåll i meddelandet. Man kan utbyta SDK-meddelanden inom många olika verksamhetsområden och med många olika bilagor.

Om behov finns kan man komma överens mellan sändare och mottagare om meddelanderubriken i SDK-meddelanden.

För varje dokument som bifogas är det filnamnet som används som identifierare.

Nej, i nuläget finns inget specifikt attribut (fält) för det i meddelandetyp SDK-Meddelande. Sändare kan ange att något är brådskande genom att skriva det i ärenderubriken.

Behov har lyfts av att kunna ange prioritet för meddelande, men man behöver då komma överens om ett gemensamt regelverk för hur prioritet sätts. Det är möjligt att ta fram nya meddelandetyper i SDK som stödjer ytterligare fält.

Ja, alla anslutna organisationer kan använda SDK för att skicka meddelande internt inom organisationen om så önskas. Tänk på att de funktionsadresser som används internt även är synliga för alla andra anslutna organisationer och ska kunna ta emot meddelanden även från externa parter.

Det innebär att man endast kan skapa adresser för och skicka meddelanden till/från funktionsadresser, men referera till ett specifikt ärende eller en individ i ett meddelande.

I specifikationen för meddelandetyp SDK-meddelande finns det ett fält för referens som är ett fritextfält där man kan ange ärendenummer, en specifik individ eller liknande. Det innebär att den tekniska lösningen som organisationen valt för att använda SDK behöver ha stöd för att hantera ett referensfält.

Det innebär att man endast kan skapa adresser för och skicka meddelanden till/från funktionsadresser, men referera till ett specifikt ärende eller en individ i ett meddelande.

I specifikationen för meddelandetyp SDK-meddelande finns det ett fält för referens som är ett fritextfält där man kan ange ärendenummer, en specifik individ eller liknande. Det innebär att den tekniska lösningen som organisationen valt för att använda SDK behöver ha stöd för att hantera ett referensfält.

Funktionsadresserna hanteras på samma sätt som andra funktionsbrevlådor, d v s att man lokalt tilldelar behörighet till de som har rätt att ta del av meddelanden som inkommer till just den adressen.

Endast de personer som har behörighet till respektive funktionsadress kan ta del av meddelanden som inkommer. Detta är oavsett vilken eventuell referensperson som sändaren skrivit in i referensfältet.

Man kan ange bådas referens. Det finns fält för detta i SDK-meddelandet. Om en part anger sitt referensid, måste mottagande part skicka tillbaka det till sändaren. Mottagaren kan också skicka sitt referensid och ursprunglig sändare måste då visa det för sina användare. Det är frivilligt att använda fältet i befintliga SDK-meddelanden.

Varje meddelande har även ett unikt tekniskt meddelande-id, som parterna i sina SDK-lösningar kan välja att använda i sina interna system för att ha kontroll över meddelandeutbytet. Det beskrivs i specifikation för meddelandetypen, se bilaga SDK Innehållsspecifikation - Meddelande.

Man kan ange bådas referens. Det finns fält för detta i SDK-meddelandet. Om en part anger sitt referensid, måste mottagande part skicka tillbaka det till sändaren. Mottagaren kan också skicka sitt referensid och ursprunglig sändare måste då visa det för sina användare. Det är frivilligt att använda fältet i befintliga SDK-meddelanden.

Varje meddelande har även ett unikt tekniskt meddelande-id, som parterna i sina SDK-lösningar kan välja att använda i sina interna system för att ha kontroll över meddelandeutbytet. Det beskrivs i specifikation för meddelandetypen, se bilaga SDK Innehållsspecifikation - Meddelande.

Ja, men deltagarorganisationen behöver själv se till att den tekniska lösning man använder för att skicka och ta emot meddelanden loggar vem, av de användare som har behörighet till funktionsbrevlådan, som hanterar meddelanden.

Nej, meddelanden som skickas och tas emot via SDK kan endast skickas och tas emot via de funktionsadresser som finns registrerade i SDK Adressbok. Eftersom SDK-meddelanden endast skickas och tas emot via funktionsadresser kan man inte skicka ett svar till en enskild person.

Det finns två olika tekniska kvittenser i SDK:

• När mottagande organisations accesspunkt har tagit emot sändande organisations meddelande.
• När mottagande organisations meddelandetjänst har dekrypterat meddelandet.

I båda fallen anses meddelandet expedierat och inkommen hos mottagande deltagarorganisation.

Läs gärna mer om allmän handling och SDK

SDK-meddelandet och dess innehåll (“datan”) som överförs stannar inte hos Digg eftersom överföringen sker direkt från avsändande organisations accesspunkt till mottagande organisations accesspunkt.

Däremot behöver gemensamma tjänster hos Digg finnas för att sändaren och mottagaren ska kunna hitta och adressera varandra i SDK-federationen:

SDK Adressbok (hos Digg) för att kunna hitta mottagande organisations funktionsadress

SMP och SML (hos Digg) för att lokalisera mottagande organisations accesspunkt.

SKR/Inera och Digg beslutade tidigt att inte ta fram lösningar eller produkter där det redan finns en leverantörsmarknad, vilket är fallet när det gäller meddelandeklienter. Dessa kan vara både i form av fristående produkter/lösningar eller integrerade i olika verksamhetssystem.

SDK är en transportinfrastruktur för meddelandekommunikation. De gemensamma delar som ingår i SDK-konceptet är SDK Testklient som finns i OPEN-TEST och SDK QA. Testklienten simulerar en meddelandeklient som ett testverktyg för att verifiera din organisations anslutning.

eDelivery och SDK bygger på att det finns både kommersiella lösningar och organisationer som själva vill utveckla egna lösningar, vilket SDK projektets tidigare pilotorganisationer, regioner och kommuner, har visat exempel på. En del av de tidigare pilotorganisationerna valde att anskaffa/köpa en färdig klient och andra pilotorganisationer (framförallt större organisationer) valde att utveckla en egen klient.

Nej, SDK är en federation vilket innebär att endast de organisationer som är anslutna till SDK kan skicka meddelanden till och från varandra. De meddelanden som skickas via SDK adresseras till och från funktionsbrevlådor som är registrerade i SDK:s Adressbok.

SDK är en federation som ska kunna användas av många olika organisationer och som bygger på ett gemensamt regelverk, gemensamma specifikationer och en gemensam adresskälla i SDK Adressbok.
Respektive organisation kan använda befintliga eller nya lösningar för t. ex. säker e-post om dessa är anpassade till SDK och organisationen är ansluten till SDK-federationen hos Digg.