Jämförda versioner

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.

...

Version

Datum

Kommentar

0.9.3 RC1 (2022)

2022-02-21

Uppdateringar:

  • Generell översyn av innehåll

1.0

2022-02-28

Beslutad version 1.0 för Tjänsten Säker digital kommunikation.

1.0.1

2022-05-03

Uppdateringar:

  • Kap. 2.1 Lagt till checkpunkter för att anskaffa certifikat för transportkryptering mellan accesspunkter

  • Kap. 2.1 Förtydligat punkter som rör anskaffande av O2O-certifikat

  • Steg 2b. Lagt till punkt att prenumerera på driftsstatus (SDK Testbädd)

  • Steg 4 Lagt till en kontroll att AP använder mTLS vid transportkryptering mellan accesspunkter

1.0.2

2022-06-16

Uppdateringar:

  • Kap. 2.1 Justerat DIGGs Testmiljö till DIGGs OPEN-TEST-miljö

1.1

2022-06-29

Uppdateringar:

  • Kap. 2 (diagram, steg 1, 2a) och kap. 3 (diagram, steg 9, 10a) Accesspunktsoperatör administrerar själv användare istället för att skicka in blankett för registrering av deltagare

1.2

2022-09-27

  • Kap. 2.1, Steg 2b Förtydligande kring beställning av O2O-certifikat om SITHS

  • Steg 2b Lösenord skickas inte längre med i granskningsrapporter

1. Inledning

Checklistan syftar till att ge anslutande användarorganisationer en överblick över de moment som krävs för anslutning till Säker digital kommunikation (SDK) enligt SDK Anslutningsprocess (se ref. R1).
En stor del av anslutningsprocessen behandlar förberedelse, genomförande och rapportering av anslutningstester och detta dokument är tänkt att samla länkar till relevant information utifrån anslutningsprocessen.

...

  •  Ta del av krav enligt regelverk inklusive tekniska specifikationer för tjänsten SDK
  •  Val av accesspunkt (AP), samt om organisationen själv etablerar accesspunkt eller anlitar tjänsteleverantör, respektive ska ta rollen som accesspunktsoperatör gentemot DIGGs plattform för eDelivery eller anlita annan accesspunktsoperatör
    •  Dokumenterat testbevis behöver finnas som redovisar tester av accesspunkten. Det kan t.ex. vara ett testprotokoll från manuella tester i DIGGs OPEN-TEST-miljö (se ‘Accesspunktsoperatör - Anslutningsresa för AP-operatör’, kontakta info@digg.se)
  •  Anskaffa/utveckla egen SDK-förmåga
  •  Anskaffa ett SITHS funktionscertifikat att användas för transportkryptering mellan accesspunkter (se Tillåtna säkerhetsprotokoll för transportkryptering - Tillämpning av TLS)
    •  Bestäm hur användarorganisationens AP-operatör anskaffar SITHS funktionscertifikat, i första hand via ombud (tredjepartsanslutning eller själv (direktanslutning) (https://www.inera.se/tjanster/alla-tjanster-a-o/siths-identifieringstjanst/#section-1907)
      •  Anskaffa ett SITHS testfunktionscertifikat för SDK Testbädd (QA)
        •  Säkerställ att det finns beredskap för hur användarorganisationen beställer SITHS testfunktionscertifikat.
      •  Anskaffa ett skarpt SITHS funktionscertifikat för SDK PROD
        •  Säkerställ att det finns beredskap för hur användarorganisationen beställer skarpa SITHS funktionscertifikat.
        •  Första gången ett skarpt SITHS funktionscertifikat utfärdas för en ny domän (ej subdomän), behöver en domänvalidering genomföras vilket är mer ledtidskrävande (Beställ och ändra)
  •  Anskaffa ett O2O-certifikat att användas för organisation till organisations signering/kryptering enligt DIGGs tekniska specifikation “Transportmodell - Utökad Bas”
    •  Bestäm vilken certifikatsutgivare som ska utfärda O2O-certifikatet (för godkända certifikatutfärdare, se /wiki/spaces/OISDK/pages/2710896795)
    •  Om SITHS: Bestäm hur användarorganisationen anskaffar ett SITHS funktionscertifikat, i första hand via ombud (tredjepartsanslutning) eller själv (direktanslutning) (

Stöd:

...

  •  Lämna in digitala formuläret ‘SDK Anslutningsblankett - Testbädd (QA)’ till Inera (Blanketter i SDK Anslutningsprocess )
    •  Hämta certifikatsuppgifter från användarorganisationens AP-operatör för det certifikat som används för accesspunkten (AP-operatörens organisationsidentitet ‘O', samt accesspunktsidentitet 'CN’)
    •  Hämta deltagaridentitet från användarorganisationens AP-operatör (motsvarar 'participantIdentifier’ som angetts vid registrering av deltagare i DIGGs SDK-QA-miljö)
    •  Inkludera ett Hantering av användarorganisationens O2O-certifikat (publikt certifikat som representerar användarorganisationen att användas för O2O-kryptering och signering)
      •  Metod 1: Användarorganisationen anskaffar och bifogar tidigare anskaffat O2O-certifikatet med anslutningsblankettenett godkänt O2O-certifikat (för godkända certifikatsutfärdare, se /wiki/spaces/OISDK/pages/2710896795)
      •  Metod 2: Användarorganisationen bifogar en certifikatsigneringsbegäran (CSR), SDK-federationsoperatör skapar ett SITHS testfunktionscertifikat utifrån begäran
    •  Vid godkänd anslutning, säkerställ att granskningsrapporten från Inera sparas då den innehåller tilldelade inloggningsuppgifter (användarnamn
    och lösenord
    • ) till SDK Testklient och SDK Adressbok.
  •  Säkerställ att upplagda användare kan logga in i SDK Testklient med användarnamn och lösenord (url till SDK Testklient /wiki/spaces/OISDK/pages/2710012582 )
  •  Säkerställ att upplagda administratörer kan logga in i SDK Adressbok med användarnamn och lösenord (url till SDK Adressbok /wiki/spaces/OISDK/pages/2710012582 )
  •  Säkerställ att driftstatus för SDK Testbädd (QA) fångas upp genom att prenumerera på information om driftstatus (https://www.inera.se/driftstatus/) och servicefönster (https://www.inera.se/driftstatus/kommande-atgarder/) för tjänsten Säker digital kommunikation (se https://customers.anpdm.com/inera/1610_form/driftstatus/subscribe/)
    •  Säkerställ att det finns rutiner som säkerställer att användarorganisationen över tid bevakar (prenumererar) på driftstatus för tjänsten

...

  •  Säkerställ att endast testdata kommer användas i meddelanden. Detta gäller både för kommande integrationstester och systemtester som ska genomföras i SDK Testbädd (QA).
  •  Säkerställ att accesspunkten (AP) använder mTLS vid transportkryptering mellan accesspunkter (/wiki/spaces/OISDK/pages/2793865227 )
  •  Säkerställ grundläggande funktionalitet med hjälp av SDK Testklient och integrationstester i testinstruktionen (SDK Testinstruktioner för anslutningstester)
    •  Meddelandetjänsten tar emot meddelande från SDK Testklient (TF 2.0.1). För användarorganisationen kan det här testet vara ett bra sätt för att förstå SDKs meddelandeformat genom att se och analysera meddelandestrukturen på mottagna meddelanden
      •  Användarorganisationens testare skapar och skickar meddelanden från SDK Testklients grafiska gränssnitt
      •  Användarorganisationens meddelandetjänst (via accesspunkten) tar emot meddelandet och skickar tillbaka en meddelandekvittens till SDK Testklient där meddelandekvittensen valideras (schema- och schematron-validering)
      •  Användarorganisationens testare kan i SDK Testklients grafiska gränssnitt se att meddelandet blivit kvitterat
    •  Meddelandetjänsten skickar meddelande till SDK Testklient (TF 2.0.2). För användarorganisationen kan det här testet vara ett bra sätt för att förstå SDKs meddelandeformat genom att se och analysera meddelandestrukturen på mottagna kvittenser
      •  Användarorganisationens testare skapar och skickar meddelande via egen meddelandetjänst (och accesspunkt).
      •  SDK Testklient tar emot meddelandet, validerar (schema- och schematron-validering) och skickar tillbaka en meddelandekvittens till användarorganisationens meddelandetjänst (via accesspunkten)
      •  Användarorganisationens testare kontrollerar meddelandekvittensen
    •  Meddelandeklienten tar emot meddelande från SDK Testklient (TF 3.0.1). För användarorganisationen kan det här testet vara ett bra sätt för att säkerställa standardflödet för en användare att ta emot meddelanden i det anslutande systemet
      •  Användarorganisationens testare skapar och skickar meddelanden från SDK Testklients grafiska gränssnitt.
      •  Användarorganisationens testare kontrollerar mottaget meddelande i meddelandeklient
    •  Meddelandeklienten skickar meddelande till SDK Testklient (TF 3.0.2). För användarorganisationen kan det här testet vara ett bra sätt för att säkerställa standardflödet för en användare att skicka meddelanden i det anslutande systemet där användare använder SDK Adressbok för att adressera meddelanden, samt kontrollera meddelandestatus
      •  Användarorganisationens testare skapar och skickar meddelande via egen meddelandeklient (SDK Testklient tar emot meddelandet och skickar automatiskt tillbaka en meddelandekvittens)
      •  Användarorganisationens testare att meddelandestatus på skickat meddelandet är korrekt

...

STEG 5: Systemtester i SDK Testbädd (QA)

...

  •  Säkerställ mer ingående att systemlösningen är följsam till SDKs tekniska specifikationer med hjälp av framtagna systemtester (SDK Testinstruktioner för anslutningstester)
    •  Systemtest MT: Genomför systemtest för Meddelandetjänst enligt SDK Testinstruktion för anslutningstester
      •  Meddelandetjänsten tar emot meddelande (TF-2.1.x)
      •  Felhantering - Okontaktbar organisation (TF-2.5.1)
    •  Systemtest MK: Genomför systemtest för Meddelandeklient enligt SDK Testinstruktion för anslutningstester
      •  Meddelandeklienten tar emot meddelande (TF-3.1.x)
      •  Konversationer - Besvara (TF-3.2.x)
      •  Konversationer - Komplettera (TF-3.3.x)
    •  Representanter för berörd verksamhet godkänner informationsöverföringen (Blanketter i SDK Anslutningsprocess , kap. 3.4.2 ‘Verksamhetens godkännande av informationsöverföring’)
      •  Information som matas in av verksamheten via meddelandeklienten och skickas till SDK Testklient, presenteras korrekt i SDK Testklient
      •  Information som matas in via SDK Testklient och skickas till användarorganisationen, presenteras korrekt i meddelandeklienten

...

...

...