-svg.png){kind=small}
Denna blogg kommer fokusera på strategiska områden för eDeliverys säkerhetsmekanismer. Bloggen kommer inte gå in på de faktiska säkerhetsprotokollen (WS-Security 1.1 med XML Signature, WS-Security 1.1 med XML Encryption) som används mellan accesspunkter inom eDelivery.
Vill du lära dig mer om eDelivery rekommenderar jag följande länkar:
CEF introduktion:
Hur tror vi SKR/Inera kommer använda eDelivery (2018-09-22)
Övergripande jämförelser mellan eDelivery och andra infrastrukturer (2019-07-30)
eDeliverys fyrhörning (four-corner)
eDelivery är ett sk byggblock framtaget av Connecting Europe Facility (CEF) och är en paketering av OASIS standard ebMS3 och AS4 specifikationen. Lite förenklat kan man säga att eDelivery används för att skapa ett säkert ”peer-to-peer” närverk för asynkron kommunikation mellan anslutna organisationer/deltagare.
Ett eDelivery-nätverk kan implementeras som en generisk transportinfrastruktur eller vara avgränsat för ett specifikt tillämpningsområde som t.ex. PEPPOL. Läs mer om PEPPOL här https://peppol.eu/what-is-peppol/
Bilden illusterar eDelivery 4-corner model. Ett eDelivery-nätverk kan implementeras med en eller SMP. eDelivery består av följande komponenter:
Domain Name System (DNS)
Domain Name System (DNS). Standardiserad komponent.
Service Metadata Locator (SML)
Komponenten ansvarar för att uppdatera information om deltagare i DNS, vilken SMP som deltagaren använder. Standardiserad komponent. Läs mer: Länk
Service Metadata Publishing (SMP)
Komponenten innehåller metadata om deltagaren. Standardiserad komponent. Läs mer: Länk
Accesspunkt
Komponenten ansvarar för att skicka och ta emot meddelanden inom eDelivery-nätverket. Standardiserad komponent. Läs mer: Länk
Backend
Komponenten representerar deltagarens verksamhetssystem som utbyter meddelanden inom nätverket.
eDelivery tillämpar en sk fyrhörningsmodell vilket innebär att systemen som utbyter meddelanden inte har direktkontakt med varandra. Meddelanden utbytes via accesspunkter(C2/C3).
Observera att eDelivery endast specificerar meddelandeutbyte mellan accesspunkter. Integration med bakomliggande system är out-of-scope för eDelivery. Detta innebär att accesspunktsmjukvaran kan erbjuda olika typer av APIer för att stödja meddelandeöverföring. Detta måste beaktas när säkerhetsarkitekturen inom ett nätverk designas. T.ex. Önskas en standardisering för att säkerställa lös koppling. Hur uppnås spårbarhet om känsliga uppgifter hanteras. Behöver säkerheten kunna garanteras hela vägen (terminering). Kvittering vid asynkront meddelandeflöde.
Hörn eller parter i eDelivery
Hörn 1: Organisation A (C1)
Organisationen som vill utbyta meddelanden
Är avsändare eller mottagare i nätverket
Ett eller flera system kan anslutas
Slutlig hantering och lagring av meddelande
Hörn 2: Accesspunkt (C2)
Organisation A (C1) utpekade accesspunkt.
Kan vara en delad eller dedikerad komponent
Mellanlagrar meddelanden under transport
Hörn 3: Accesspunkt (C3)
Organisation B (C4) accesspunkt.
Kan vara en delad eller dedikerad komponent
Mellanlagrar meddelanden under transport
Hörn 4: Organisation B (C4)
Organisationen som vill utbyta meddelanden
Är avsändare eller mottagare i nätverket
Ett eller flera system kan anslutas
Slutlig hantering och lagring av meddelande
Registrering av deltagare/parter inom eDelivery nätverket (SMP)
Är man flera deltagare i eDelivery-nätverket bör ”dynamic discovery” användas. Vid ”dynamic discovery” etableras ett register över deltagare i komponenten Service Metadata Publishing – SMP.
SMP är i sin tur kopplad till komponenten kallad SML. SML uppdaterar DNS. Accesspunkter använder DNS för att hitta den SMP som används för deltagaren inom, eDelivery-nätverket.
Detaljerad information om SMP och SML fungerar samt hur det påverkar utformning av eDelivery kommer beskrivas i kommande bloggar.
Registrets (SMP) hanterar metadata för deltagare (ej uttömmande lista):
ParticipantIdentifier: En unik identifierare för organisationen (t.ex. organisationsnummer).
DocumentIdentifier: Vilken dokumenttyp och version som organisationen kan hantera/utbyta (detta ger stöd för livscykelhantering av meddelanden)
Certificate: Vilket certifikat som skall användas vid kryptering av meddelandet mellan accesspunkter.
Vilken teknisk adress URL(https/https) som skall användas.
Metadata i SMP signeras för att säkerställa riktighet. Accesspunkter kontrollerar automatiskt att signaturen är giltig(samt sk "trust").
I de eDelivery nätverk som sätts upp av projektet Säker digital kommunikation (SDK) har man för närvarande en(1st) SMP för eDelivery nätverket. Standarden möjliggör dock att flera SMP sätts upp.
Bilden illustrerar metadata som registreras för en deltagare i eDelivery nätverket. SMP komponenten är som standard öppen och tillgänglig via REST APIer. Källa: https://dev.diggsmp.com/iso6523-actorid-upis%3A%3A0203%3Atestbed.inera.se/services/busdox-docid-qns%3A%3Aurn%3Ariv%3Ainfrastructure%3Amessaging%3Amessagewithattachments%3A2
En registrering i SMP innebär att deltagare följer gemensamma specifikationer och regelverk för meddelandeutbyte inom nätverket.
Exempel på regler som kan tillämpas vid anslutning till ett eDelivery nätverk.
Tillämpa en anslutningsprocess där anslutande parts identitet kontrolleras.
Kräva att ett sk OV-certifikat (Organisation Validation) används av accesspunkten.
Utöver en generisk anslutningsprocess för tillträde till eDelivery-nätverket kan olika/utökade regelverk kopplade till vilka dokumenttyper som deltagande part registrerar kan tillämpas. T.ex. Dokumenttypen ”Konsultationsremiss” förutsätter att deltagaren följer funktionella och icke funktionella krav kopplade till informationsflöden kopplade till remisshantering.
Läsa mer om hur Säker digital kommunikation (SDK-projektet) använd SMP:
SMP specifikationen:
eDeliverys säkerhetsmekanismer
eDelivery lutar sig mot modern kryptografi så som signering och kryptering för att säkra meddelandeutbytet mellan accesspunkter dvs C2-C3. eDelivery tillhandahåller ingen lösning för att säkra kommunikationen hela vägen sk end-to-end C1-C4, detta illustreras i ”scenarios” i kommande avsnittet implementering.
Följande grundläggande mekanismer tillämpas mellan accesspunkter(C2-C3).
Transportkryptering (infrastruktur):
TLS-kryptering av kommunikation mellan accesspunkter
Meddelandekryptering vid överföring mellan accesspunkter (WS-Security)
Meddelanden krypteras med mottagande accesspunkts registrerade certifikat (Certifikat hämtas från SMP.)
Hantering av certifikat (PKI) och hantering av tillit till certifikatsutställare är grundläggande för att uppnå hög säkerhet inom ett eDelivery nätverk. Beroende på vilken information som skall hanteras inom nätverket så kan olika lösningar vara lämpliga:
Dedikerad PKI:
En specifik PKI används för meddelandekryptering inom eDelivery nätverket.
Möjliggör att endast godkända accesspunkter kan delta i kommunikationen.
En delad PKI:
En PKI som kan användas för olika ändamål används. T.ex. Efos.
Flera PKI:
Flera PKIer används. Varje part måste ”lita” (trust) till flera PKIer.
Trusted lists:
Tillit skapas utifrån en lista av certifikat som kan komma från olika PKIer
Implementering av eDelivery säkerhetsmekanismer
eDelivery har ett utmärkt stöd för att garantera att endast avsedd mottagare (Accesspunkt) kan ta del av meddelandet. SMP-komponenten används för detta. Mekanismer för att identifiera avsändaren är däremot svagare (avsändaren valideras helt enkelt inte). Här måste nätverket utformas specifikt för att lösa detta alternativt utöka med en säkerhetslösning på dokumenttyp/payload (t.ex. signering).
CEF (Connecting Europe Facility) har tagit fram tre scenarion för hur eDelivery säkerhetsmekanismer kan implementeras för att belysa detta på ett bra sätt.
Delegationscenario – Organisation och accesspunkt är samma part
Part C1 och C2 ses som samma aktör. Säkerhetshantering delegeras till C2. C2 autentiserar C1. C2 signerar meddelande med sitt certifikat och sätter C1 som avsändare (identitet).
Meddelandet hanteras inte av tredje part då C2 är under C1s kontroll(t.ex. är en komponent inom deltagarens IT-drift).
Detta är eDeliverys standardkonfiguration.
Egenskaper:
C1 skapar meddelande och ”stämplar” sin identitet som avsändare (en sträng som ej valideras av C2/C3 vid överföring). Se bilaga AS4 meddelande: ”originalSender”.
C1 "skickar" meddelandet till C2 (Accesspunkt).
C2 levererar meddelandet till mottagarens accesspunkt C3. C2 certifikat representerar C1. Certifikatet som används av C2 måste kunna verifieras mot C1s identitet för att inte öppna upp för falska avsändare (t.ex. CN i certifikat mappas mot C1 identitet). I praktiken innebär detta en C2 instans per C1.
Bilden illustrerar eDelivery ”Delegation scenario” vilket innebär att en instans accesspunkt per part behövs för att uppnå hög säkerhet. Att eDelivery nätverkets struktur följs kontrolleras vid anslutning till SMP.
Extended delegation scenario – Separering med signering av meddelande (payload)
I detta scenario ses C1 och C2 som samma aktör, men C2 signerar/krypterar meddelandet med C1s certifikat/privata nyckel. C1 skall ha fullständig kontroll över C2.
Mottagaren kan därmed kryptografiskt verifiera vem som är avsändare. Meddelanden är under C1 organisationens kontroll tills dess det är levererat till slutlig mottagare.
Detta scenario kräver inte att C1 eller C4 behöver hantera signering/kryptering (verifiera signatur, dekryptera meddelande). Denna komplexitet kan läggas på C2/C3.
Egenskaper:
C1 skapar meddelande och ”stämplar” sin identitet som avsändare (en sträng som ej valideras av C2/C3 vid överföring). Se bilaga AS4 meddelande: ”originalSender”.
C1 "skickar" meddelandet till C2 (Accesspunkt).
C2 signerar/krypterar meddelandet med C1s certifikat. En C2 instans per C1 bör används för att uppnå hög säkerhet. C2 behöver ha tillgång till C1s privata nyckel
C2 levererar meddelandet till mottagarens accesspunkt C3.
C4 kan kontrollera meddelandets avsändare via C1s signatur (payload)
Signering och kryptering av meddelande (payload) ingår inte i eDelivery standard/paketering. Detta innebär att: Standard för signering och kryptering(verifiera signatur, dekryptera meddelande) behöver beslutas av parter. Register (BCP alt PKI) med certifikat eller PKI för ”end-to-end” behöver beslutas av parter
Bilden illustrerar ”extended delegation scenaria”. Mycket av säkerhetshanteringen delegeras till C2/C3 vilket innebär att dessa måste stå under C1/C4s kontroll.
Extended security scenario – Fullständig separering av parter med signering och kryptering av meddelande (payload)
I detta scenario ses C1 och C2 som två separata parter. C1 tar fullständigt ansvar för säkerheten genom att kryptera meddelandet så att endast mottagaren C4 kan dekryptera meddelandet. Meddelanden är under C1 organisationens kontroll tills dess det är levererat till slutlig mottagare (uppnås genom kryptering).
Detta scenario förutsätter på samma sätt som ovanstående Extended delegation scenario att:
Standard för signering och kryptering (verifiera signatur, dekryptera meddelande) behöver beslutas av parter.
Ett register med certifikat eller PKI för ”end-to-end” behöver etableras.
Egenskaper:
C1 skapar meddelande och ”stämplar” med sin identitet som avsändare (en sträng som ej valideras vid överföring).
C1 signerar/krypterar meddelandet (payload)
C1 "skickar" meddelandet till C2 (Accesspunkt).
C2 levererar meddelandet till mottagarens accesspunkt C3.
C4 kan kontrollera C1s identitet mot signatur (payload)
C1 kan ta ansvar för end-to-end säkerheten genom att använda signering och kryptering. C1 är ”löst kopplad” mot C2. Detta innebär att C2 kan hanteras av tredje part.
Sk. end-to-end signering och kryptering är möjlig
Signering och kryptering av meddelande (payload) ingår inte i eDelivery. Detta innebär att: Standard för signering och kryptering(verifiera signatur, dekryptera meddelande) behöver beslutas av parter. Ett Register (BCP alt PKI) med certifikat eller PKI för ”end-to-end” behöver etableras.
Sammanfattning:
eDelivery är en robust paketering för asynkron meddelandeöverföring. Komponenten SMP ger bra stöd för livscykelhantering av de dokumenttyper som respektive ansluten part/organisation stödjer.
Det finns ett utbud av mjukvara för accesspunkten som ansvarar för meddelandeutbytet. Se https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+AS4+conformant+solutions
eDelivery är sedan 2020 en ISO standard (oklart vilka fördelar detta medger). Se https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/2020/07/24/ISO+approves+eDelivery+message+exchange+protocol+as+International+Standard
Tidigare begränsningar på meddelandes storlek (2GB) har nu tagits bort. Med eDelivery AS4 1.15 finns nu ingen över gräns för hur stora meddelanden kan vara. Detta kan öppna upp för informationsflöden där stora datamängder behöver utbytas t.ex. inom bildhantering röntgen.
Ett eDelivery-nätverk kan beroende på behov implementeras på olika sätt.
Öppen eller stängd PKI
Olika scenarios kan tillämpas beroende på informationsklassning
Anlita tredje part. Skall hörn C2 eller C3 kunna tillhandahållas av fristående parter eller vara en del av respektive organisation/part. Detta påverkar säkerhetslösning för meddelanden (dokumenttyper) då asynkrona meddelandeflöden innebär mellanlagring t.ex. i meddelande kö.
Ett eDelivery-nätverk som skall kunna hantera t.ex. journalinformation har i princip två sk scenarion att välja på:
Använda ”delegation scenario” där respektive organisation/part har full kontroll över C2/C3.
Använda ”extended security scenario” vilket kräver säkerhetslösningar (kryptering av payload) som inte ingår i eDelivery.
Sammanfattning: Vilka mekanismer som stödjer respektive område.
Konfidentialitet
eDelivery:
TLS kryptering mellan accesspunkter C2-C3
AS4 Meddelandekryptering mellan C2-C3
Utformning av nätverk (part som tillhandahåller infrastruktur C2/C3)
Val av PKI för TLS och AS4 Meddelandekryptering
Tillägg:
End-to-end: Signering/kryptering av payload
Riktighet
eDelivery:
Deltagarregister (SMP)
Tillägg:
PKI eller register för ”end-to-end” signering/kryptering
Tillgänglighet
eDelivery:
Asynkron överföring
Omsändningsmekanismer
Kvittenser C2/C3
Tillägg:
Kvittenser C1/C4
Bilaga: AS4 meddelande
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Header>
<ns5:Messaging
xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
xmlns:ns5="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/"
xmlns:ns4="http://org.ecodex.backend/1_1/" mustUnderstand="false">
<ns5:UserMessage>
<ns5:MessageInfo>
<ns5:Timestamp>2019-06-03T13:48:31.366</ns5:Timestamp>
<ns5:MessageId>9367829b-77d8-4c10-8212-402cccec2078@domibus
</ns5:MessageId>
</ns5:MessageInfo>
<ns5:PartyInfo>
<ns5:From>
<!-- Same as CN of remote AP eDelivery cert (i.e. the cert of the receiving
party - part of the service metadata in SMP). Note! The AP eDelivery cert
*may* be the same as AP TLS server cert but does not have to be. I.e. the
AP may have a dedicated TLS server cert under another domain (ok as long
as it is issued by an approved CA). -->
<ns5:PartyId type="actorid">Accesspunkt cert CN
</ns5:PartyId>
<ns5:Role>http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/initiator
</ns5:Role>
</ns5:From>
<ns5:To>
<ns5:PartyId type="actorid">Accesspunkt cert CN</ns5:PartyId><!-- Same
as CN of local AP Certificate -->
<ns5:Role>http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/responder
</ns5:Role>
</ns5:To>
</ns5:PartyInfo>
<ns5:CollaborationInfo>
<ns5:Service type="procid">process-id
</ns5:Service>
<ns5:Action>documenttyp
</ns5:Action>
<ns5:ConversationId>960db3cf-896b-492b-84cd-12e19efeb048@domibus.sdk
</ns5:ConversationId>
</ns5:CollaborationInfo>
<ns5:MessageProperties>
<ns5:Property name="originalSender"
type="actorid">Avsändare C1</ns5:Property><!-- Maps to Participant Identifier
in SMP -->
<ns5:Property name="finalRecipient"
type="actorid">Mottagare C4</ns5:Property><!-- Maps to Participant Identifier
in SMP -->
</ns5:MessageProperties>
<ns5:PayloadInfo>
<ns5:PartInfo href="cid:message">
<ns5:PartProperties>
<ns5:Property name="MimeType">text/xml</ns5:Property>
</ns5:PartProperties>
</ns5:PartInfo>
</ns5:PayloadInfo>
</ns5:UserMessage>
</ns5:Messaging>
</soap:Header>
<soap:Body>
<ns4:retrieveMessageResponse
xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
xmlns:ns5="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/"
xmlns:ns4="http://org.ecodex.backend/1_1/">
<payload payloadId="cid:message">
<value>Base64 encoded payload </value>
</payload>
</ns4:retrieveMessageResponse>
</soap:Body>
</soap:Envelope>
Comments