Innehållsförteckning
...
Expandera | |||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
1. Inledning
Denna beskrivning är en specifikation av SDKs principer för validering, felhantering och kvittens. Dokumentet är en del av SDKs tekniska specifikationer som i sin tur ingår i regelverk för Säker digital kommunikation. Det innebär att innehållet i dokumentet är styrande för de organisationer som ansluter till Säker digital kommunikation (SDK).
...
Ref | Dokument-id | Dokumentlänk | ||||||
---|---|---|---|---|---|---|---|---|
B1 | Säker digital kommunikation - Software Architecture Documentation (SAD) | Säker digital kommunikation - Software Architecture Documentation (SAD) | ||||||
B2 | SDK Innehållsspecifikation - Meddelande
| SDK Innehållsspecifikation Meddelande Specificerar nyttolast för meddelanden inom Säker digital kommunikation, inklusive meddelandekuvert (metadata) och bilagor. | ||||||
B3 | SLA Tillgänglighet för SDKs gemensamma komponenter | |||||||
B4 | SDK Adressbok Teknisk guide för Sök-API | |||||||
B5 | IT-säkerhetsbilaga till regelverk för anslutning till Säker digital kommunikation | |||||||
B7 | SLA Tillgänglighet för användarorganisationens komponenter i SDK-federationen |
2. Principer för validering och kvittens
...
Lägg primärt validering och kontroll så tidigt som möjligt i kedjan, där det finns störst möjlighet att åtgärda ev. fel.
Gör det lätt för användaren i verksamhetssystemet (meddelandeklienten) att göra rätt från början, t.ex. genom att kontrollera att bifogade filer har rätt typ, att kontrollera format på inmatade värden i meddelandefält osv.
Det skall finnas skydd mot skadlig kod i nyttolast. Skyddet kan implementeras i Meddelandeklient(MK), Meddelandetjänst(MT) eller motsvarande. Om skadlig kod upptäcks, ska om möjligt ett felmeddelande skickas åter till avsändaren.
En incident behöver skapas om skadlig kod upptäcks. Skalskydd i form av antivirussystem bör förhindra vidare hantering genom att t.ex. sätta meddelandet i "karantän".Både avsändare och mottagare har ansvar för validering mot gemensamma regler, t.ex. kontroll mot meddelandeformatet, adressering, skanning av skadlig kod, etc.
Separera ansvar för transportvalidering till transportlagret (eDelivery) och innehållsvalideringtill meddelandelagret (SDK), undantaget kontroll av adressering för att säkerställa säker mottagare och säker avsändare.
Motiv: Detta gör transportlagret återanvändbart för flera typer av meddelandeöverföringar. Transportlagret ska inte behöva ha mer än nödvändig kunskap om den aktuella nyttolasten.
Detta medger också att lägga in tillämpningsspecifik validering anpassad för olika meddelandetyper utan att påverka tekniken i transportlagret. T.ex. kan vissa meddelanden kräva tyngre validering, vilket då inte påverkar transportlagrets förmåga att sända och ta emot. Det ger även större möjlighet att testa och verifiera nya valideringsregler i meddelandelagret innan dessa sätts i produktion.
...
Steg | Aktör | Aktivitet |
---|---|---|
Sändare (C1) | ||
Initiera meddelandeöverföring | Verksamhetslager - Meddelandeklient/Verksamhetssystem | Observera regelverk för:
|
1.Skapa meddelande | Meddelandelager - Meddelandetjänst | Meddelande SKA skapas enligt specifikation SDK Innehållsspecifikation Meddelande (se Ref. B2). Meddelandet paketeras (kuverteras) enligt specifikation eDelivery - Kuverteringsprofil XHE (se Ref. R13). Observera regelverk för:
Se även specifikation:
|
2.Schemavalidering | Meddelandelager - Meddelandetjänst | Meddelandepaketering (kuvert) SKA valideras enligt eDelivery - Kuverteringsprofil XHE (se Ref. R13). Meddelandet(nyttolast) SKA valideras enligt specifikation SDK Innehållsspecifikation - Meddelande (se Ref. B2).
Observera regelverk för:
|
3.Innehållsvalidering | Meddelandelager - Meddelandetjänst | Meddelandet kontrolleras:
Observera regelverk för:
Se specifikation:
|
Kryptera och signera meddelande | Meddelandelager - Meddelandetjänst | Meddelandet SKA krypteras och signeras. Mottagande användarorganisations publika nyckel SKA hämtas från Certifikatspublicering (se Ref. R14)
Se specifikation:
|
Sänd meddelande | Meddelandelager - Meddelandetjänst | Meddelandet överför meddelandet till Accesspunkt för distribution till mottagaren. Meddelandetjänst:
|
AP-operatör (C2) | ||
Accesspunkt | AP-operatör SKA validera meddelandet enligt DIGGs specifikationer för AP-operatörer. Observera:
Se specifikation:
Observera att ytterligare valideringskrav kan tillkomma. Kontakta DIGG för senaste information. | |
AP-operatör (C3) | ||
Accesspunkt | AP-operatör SKA validera meddelandet enligt DIGGs specifikationer för AP-operatörer. Se specifikation:
Observera att ytterligare valideringskrav kan tillkomma. Kontakta DIGG för senaste information. | |
Mottagaren (C4) | ||
4.Schemavalidering | ||
Validera signatur och dekryptera meddelande | Meddelandelager - Meddelandetjänst | Meddelandetjänst: Meddelandets signatur SKA valideras. Sändande (C1) användarorganisations publika nyckel hämtas från Certifikatspublicering (se Ref. R14).
Se specifikation:
|
Schemavalidering | Meddelandelager - Meddelandetjänst | Tillämpar validering enligt 2.Schemavalidering |
5.Innehållsvalidering | Meddelandelager - Meddelandetjänst | Tillämpar validering enligt 3.Innehållsvalidering Ursprungskontroll
Se specifikation:
|
Sänd meddelandekvittens | Meddelandelager - Meddelandetjänst | Efter genomför validering och kontroller SKA meddelandetjänst skicka meddelandekvittens alternativt felmeddelande.
Se specifikation:
|
Initiera intern behandling av meddelande | Verksamhetslager - Meddelandeklient/Verksamhetssystem | Meddelandeklient/Verksamhetssystem
Se specifikation:
|
...