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.

Deltagarorganisationen ska säkerställa att meddelandetjänsten följer kraven på signering, kryptering, validering av signatur och dekryptering av meddelande enligt Regelverk för meddelandesystem.

Detta innebär bland annat att meddelandetjänsten paketerar meddelandet enligt specifikation i bilaga Diggs Kuverteringsprofil XHE. 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 aktuellt anpassningsdokument SDK federationens tekniska anpassningar mot plattform för eDelivery.

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

För att skydda informationen vid meddelandeöverföring inom SDK ska deltagarorganisationer för sin egen anslutning ansvara för att krav på kryptering, signering, autentisering och validering av signatur uppfylls.

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

Kryptografiskt nyckelmaterial som används för skydd av överföring av meddelanden via SDK ska skapas på ett säkert och trovärdigt sätt med slumptalsgenerator, samt skyddas vid förvaring och användning så att det inte röjs till obehöriga.

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

Anpassning A1 enligt B1.4.4 - Federationens tekniska anpassningar mot plattform för eDelivery

• 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

Anpassning A2 enligt B1.4.4 - Federationens tekniska anpassningar mot plattform för eDelivery

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.

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 ha en skriftlig rutin för hur certifikatsunderlaget skapas (CSR).
• Deltagarorganisationen ansvarar för att vid var tid ha ett giltigt 020-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.
• 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’.
• Certifikatens giltighet ska kontrolleras genom spärrkontroll/revokeringskontroll (CRL/OSCP)
  • Om spärr/revokeringskontroll ej kan utföras anses certifikatet ej tillförlitligt.
    

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

Deltagarorganisationen ska ha skydd mot intrång, skydd mot inkommande skadlig kod samt skydd mot spridning av skadlig kod för att undvika att påverka mottagande deltagarorganisation eller andra aktörer i SDK. 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.

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.

Tekniska säkerhetsåtgärder och rutiner för felsökning, loggning och tid ska hanteras mellan deltagarorganisation och ansvariga för 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 Accesspunktsoperatör - Gemensamma Regler och Rutiner.

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

• Meddelandetyp (dokumenttyp)
• Identifierare för accesspunkt
• Avsändningstidpunkt/ Mottagandetidpunkt
• Identifierare för avsändande och mottagande deltagare
• AS4 Message ID
• AS4 Conversation ID
  

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.