Bilaga för IT säkerhet inom SDK

Figur 1: Fyrhörningsmodellen

Förklaring av hörnen i modellen:

Hörn 1 (C1) / Hörn 4 (C4) är deltagarorganisationers (deltagares) anslutande system, där:

• Hörn 1 är avsändande deltagarorganisations meddelandetjänst och meddelandeklient.
• Hörn 4 är mottagande deltagarorganisations meddelandetjänst och meddelandeklient.

Hörn 2 (C2) / Hörn 3 (C3) är deltagarorganisationers (deltagares) anslutna accesspunkter, där:

• Hörn 2 (C2) är avsändande deltagarorganisations accesspunkt.
• Hörn 3 (C3) är mottagande deltagarorganisations accesspunkt.

2.1 Säkerhetsområden som reglerar skydd vid meddelandeöverföring

Inom fyrhörningsmodellen finns följande säkerhetsområden som reglerar skydd vid meddelandeöverföring:

2.2 O2O-kryptering och signering

SDK tillämpar kryptering och signering för säker meddelandeöverföring mellan deltagarorganisationer genom så kallad Organisation-till-Organisation-kryptering (O2O- kryptering).

Meddelanden som skickas inom SDK ska signeras och krypteras mellan meddelandetjänst hos sändande respektive mottagande deltagarorganisation.

Respektive deltagarorganisations meddelandetjänst ansvarar för att signera, kryptera, validera signatur och dekryptera meddelande.

Detta innebär bland annat att meddelandetjänsten paketerar meddelandet enligt specifikation i bilaga Diggs Kuverteringsprofil XHE Länk till annan webbplats.. Deltagarorganisationens certifikat för kryptering och signering tillgängliggörs genom slagning mot certifikatspubliceringstjänsten.

3. Krav på skydd vid meddelandeöverföring

Dessa krav gäller inom SDK federationen enligt aktuell federationsdeklaration.

3.1 Generella krav på krypteringsalgoritmer, säkerhetsprotokoll och certifikat

För att skydda informationen vid meddelandeöverföring ställs krav på kryptering, signering, autentisering och validering av signatur.

Olika metoder används beroende på säkerhetsområde och vilket hörn i fyrhörningsmodellen som hanterar meddelandet.

Val av algoritmer, nyckellängder och säkerhetsprotokoll ska följa ”best practice guidelines”.

Äldre säkerhetsprotokoll och algoritmer ska INTE användas.

I praktiken innebär detta att för skydd av information vid meddelandeöverföring gäller nedanstående algoritmer, nyckellängder, säkerhetsprotokoll och certifikat.

3.1.1 Krav på krypteringsalgoritmer och nyckellängder

Asymmetriska nycklar

• RSA - Nyckellängd 3072 bitar eller mer (RSA-OAEP).
• ECDSA - För elliptiska kurvor rekommenderar NIST ECDSA Curve P-256 alternativt P-384 dvs. 256 eller 384 bitars kryptografiska elliptiska kurvor.

Symmetriska nycklar och hashfunktioner:

• AES - Nyckellängd 256 bitar eller mer (AES-256-GCM).
• SHA-2 - 256 bitar eller mer (SHA-256).

3.1.2 Tillåtna säkerhetsprotokoll för transportkryptering

• TLS version 1.2 eller nyare.
• TLS-konfigurationen ska vara åtminstone av ”grade A” enligt SSL Labs gradering.

3.1.3 Krav på certifikat

Krav på certifikat är att det ska vara X.509 som är en ITU-standard för digitala certifikat, public key infrastructure (PKI) och privilege management infrastructure (PMI).

3.2 Säkerhet i Plattform för eDelivery transportinfrastruktur – skydd mellan accesspunkter

Säkerställer konfidentialitet och riktighet mellan accesspunkter (säkerhet i eDelivery transportinfrastruktur).

Den som ansvarar för accesspunkten kallas för accesspunktsoperatör och måste genomföra tester och godkännas av Digg för att kunna delta i SDK-federationen.

Både offentliga aktörer och privata tjänsteleverantörer kan bli godkända som accesspunktsoperatörer.

För att ansluta till SDK-federationen ska deltagarorganisationen använda en accesspunktsoperatör som är plattformsgodkänd och federationsgodkänd av Digg.

Utöver Diggs godkännande av accesspunktsoperatör gäller följande anpassningar till de grundregler som specificeras i bilaga Transportprofil AS4 Länk till annan webbplats., avsnitt 2.4.

3.2.1 Godkända certifikatsutgivare för TLS-trafik, A1

TLS ska användas och endast utgivaren SITHS ska användas.

• Rotcertifikat: SITHS e-id Root CA v2 (2019-05-15 till 2049-09-15).
• Certifikatsutgivare: SITHS e-id Function CA v1.

3.2.2 Godkänd autentiseringsmetod, A2

Accesspunktsfunktioner som agerar i eDelivery transportinfrastruktur ska använda:

• “Two-way TLS” baserad på trust till “SITHS e-id Funktion CA v1” (ej enskilda certifikat).

3.3 O2O-kryptering och signering av meddelanden – skydd vid meddelandeöverföring mellan deltagarorganisationer

O2O-kryptering och signering säkerställer konfidentialitet och riktighet mellan deltagarorganisationer. Här gäller följande krav:

• Meddelandekryptering och signering enligt bilaga Diggs Transportmodell Utökad BAS Länk till annan webbplats..

3.3.1 Godkända certifikatsutgivare (CA)

Godkända certifikatsutgivare är tills vidare:

• SITHS e-ID funktionscertifikat (Inera).
• E-identitet för offentlig sektor - Efos (Försäkringskassan).
• ExpiTrust EID CA V4 (tidigare Steria AB e-Tjänstelegitimationer Kort CA v2 hos Expisoft AB).

3.3.2 Krav på certifikatshantering

Anskaffande och förnyelsehantering:

• Deltagarorganisationen ansvarar för att vid var tid ha ett giltigt certifikat.
• Deltagarorganisationen ansvarar för att leverera certifikatets publika nyckel till SDK federationsägare.
• Deltagarorganisationen ansvarar för att vid uppdatering och byte av certifikat eller nyckel utan dröjsmål meddela SDK federationsägare.

Kontroll av certifikatens giltighet vid meddelandeutbyte:

• Deltagarorganisationen ansvarar för att kontrollera certifikatens giltighet vid kryptering och dekryptering av meddelanden samt validering av signatur.
• Certifikatens giltighet ska kontrolleras mot Diggs certifikatspubliceringstjänst enligt ’Certifikatspublicering – REST-bindning till SMP’.
• Spärrhantering/revokeringskontroll ska göras enligt ’Kuverteringsprofil XHE’.

3.3.3 Konfigurering av tillit till godkända certifikatsutgivare (CA)

Giltigt signerat metadata i certifikatspubliceringstjänsten (SMP) utgör grund för tillit till deltagarorganisationens O2O certifikat. Giltig certifikatsutgivare för signering av metadata i SMP se SDK Anslutningsinformation certifikat.

3.4 Inre säkerhet

Säkerställer konfidentialitet och riktighet i deltagarorganisations inre säkerhet, dvs. inom anslutande system (meddelandetjänst och meddelandeklient) och mellan anslutande system och accesspunkt.

Här gäller följande krav:

• Transportkryptering och flerfaktorsautentisering av anslutande system.
• Information kan hanteras och transporteras okrypterat och konsumerande anslutna system behöver inte autentiseras i följande fall:
  • Inom en för deltagarorganisationen isolerad serverhall eller låst serverutrymme där ingen server eller nätverkskomponent delas med någon annan part.
  • Inom dedikerade switchar i en väl skyddad miljö.

3.4.1 Tillåtna säkerhetsprotokoll för transportkryptering

Utöver TLS, enligt avsnitt 3.1.2 ovan, tillåts även följande protokoll:

• IPsec, ESP i Tunnel mode, med IKEv2 (Internet Key Exchange) med RSA/DSS.

4. Krav på skydd vid kommunikation med gemensamma komponenter

Krav på skydd vid kommunikation med gemensamma komponenter säkerställer konfidentialitet och riktighet vid administration och sökning av deltagande organisationer och metadata i gemensamma komponenter.

Figur 3 - Säkerhet vid administration och sökning av deltagande organisationer och metadata

4.1 Plattformens gemensamma komponenter

Plattformens gemensamma komponenter säkerställer konfidentialitet och riktighet vid administration och sökning av deltagande organisationer och metadata i gemensamma komponenter hos Digg. Det omfattar:

• Skydd mellan administratör och SMP-tjänsten.
• Skydd mellan accesspunkt och SMP-tjänsten.
• Skydd mellan SMP- och SML-tjänsten.
• Skydd mellan administratör och certifikatspubliceringstjänsten.
• Skydd mellan anslutet system och certifikatspubliceringstjänsten.

För närmare beskrivning av krav, se tjänstebeskrivningar för respektive komponent.

4.2 SDK-federationens gemensamma komponenter

SDK-federationens gemensamma komponenter säkerställer konfidentialitet och riktighet vid administration och sökning av deltagande organisationer och metadata i gemensamma komponenter. Det omfattar:

• Skydd mellan administratör och SDK adressbok, som regleras i Regelverk för deltagarorganisationer inom SDK.
• Skydd mellan anslutande system och SDK adressbok, se avsnitt 4.2.1.

4.2.1 Skydd mellan anslutande system och SDK adressbok

Skydd mellan anslutande system och SDK adressbok säkerställer konfidentialitet och riktighet mellan anslutande system och SDK adressbok. Här gäller följande krav:

• Transportkryptering tillämpas enligt generella krav på protokoll och krypteringsalgoritmer

Om anslutande system skapar en lokal läskopia av SDK adressbok gäller även:

• För att vidmakthålla hög aktualitet i lokal läskopia behöver denna uppdateras flera gånger per dygn. Det innebär att lokal läskopia ska uppdateras minst var 12:e timme men inte oftare än var 4:e timme.

5. Teknisk säkerhet

Det här kapitlet beskriver den säkerhet som krävs avseende loggning för felsökning samt tidssynkronisering i lokala komponenter.

5.1 Felsökning och spårbarhet

Kraven på loggning är för att underlätta felsökning genom spårbarhet när det är flera aktörer inblandade. Kraven på loggning i eDelivery transportinfrastruktur, både i avsändande respektive mottagande AP-funktioner, framgår av bilaga Accesspunkt – Komponentspecifikation. Länk till annan webbplats.

Därutöver ska loggar för meddelandeöverföring via SDK innehålla:

• SDK dokumenttyp.
• Accesspunkternas nätverksadresser.
• Meddelandets identitet (meddelande-id).
• Meddelande-ID i eDelivery transportinfrastruktur (AS4 Message ID).
• Vilken AP-operatör/accesspunkt som används.
• Tidpunkt när meddelande lämnas respektive hämtas i accesspunkt.

Observera att loggar inte ska omfatta meddelandeinnehåll.

Vid adressering via SDK ska loggar innefatta:

Vilken SDK adressbok som används (gemensam alternativt lokal läskopia).

5.2 Tid

Samtliga datorklockor ska synkroniseras mot tillförlitliga källor, spårbara till världstiden UTC(SP) men minimum UTC. Tidssynkroniseringen ska övervakas kontinuerligt.