2.17 Installation och administration (Windows)
Dokumenthistorik
Datum Version Namn Förändring
20 Mar
2017 0.1 Lexhagen, Magnus Dokument upprättat i Confluence 16 Oct
2017
0.2 Örjan Olofsson Uppdaterat för 2.17
18 Oct
2017 0.3 Unknown User
(sundbergs)
Uppdaterat instruktioner
30 Oct 2017
1.0 Unknown User (h.
ferm)
Fastställd
09 Nov 2017
1.1 Lexhagen, Magnus Rättat adress till PU-tjänsten via NTjP
09 Nov
2017 1.2 Lexhagen, Magnus Rättat adress för spärreplikering via NTjP 22 Nov
2018
1.3 Lexhagen, Magnus Lagt till info om behovet av nerladdning av de nationella spärrarna.
18 Jul
2019 1.4 Lexhagen, Magnus Ändrad/ny certifikatsinformation då SITHS-certifikat inte längre bör användas i front-end 13 Sep
2019
1.5 Lexhagen, Magnus Tagit bort extern beroende till HSA-kontrakt GetPersonAuthorizedToSystemIncludingProtectedPerson som endast används i den nationella installationen.
Innehållsförteckning 1. Inledning
1.1. Allmänt 1.2. Begrepp 1.3. Referenser 2. Systemkrav
2.1. Diskyta
2.1.1. Delad diskyta för Säkerhetstjänster 2.1.2. Diskyta för MySQL
2.1.3. Diskyta för MongoDB 2.2. Tidssynkronisering
2.3. Lastbalanserare 3. Plattform och tredjepartsprodukter
3.1. Java
3.1.1. JCE - Java Cryptography Extension 3.2. MySQL
3.3. MongoDB 3.4. Lastbalanserare 3.5. Funktionscertifikat
3.5.1. Ytterligare funktionscertifikat 3.6. CSP - Cryptographic Service Provider
3.7. Kluster med Infinispan (Distributed in-memory cache) 3.8. Ciphersuites som används
3.9. Telnet
4. Säkerhetstjänsters beroenden till externa system 4.1. Behörighet externa system
4.2. HSA-WS 4.3. HSA-RIVTA
4.4. Revokeringskontroll av certifikat
4.5. Personuppgiftstjänsten - Personuppgiftstjänsten 4.6. Nationell Spärrtjänst*
4.7. Nationell Loggtjänst*
4.8. Tjänsteplattformen*
5. Systemöversikt
5.1. Ingående servrar
5.2. Exempelinstallation och konfiguration
5.2.1. Lokala Säkerhetstjänster installerade med Spärr och Autentisering 5.2.2. Lokala Säkerhetstjänster installerade med alla tjänster
5.3. Översikt adresser och portar 5.3.1. Applikationsserver 5.3.2. Databasserver 5.4. Adressöversikt gränssnitt
5.4.1. Webbgränssnitt admin-GUI
5.4.2. Webbgränssnitt Autentiseringstjänsten
5.4.3. Webbtjänstegränssnitt för autentisering rika klienter - STS 5.4.4. Webbtjänstegränssnitt WS-port - RIV TA-tjänster och REST-tjänst 6. Installation av databasserver
6.1. Installera MySQL
6.1.1. Specifika MySQL-inställningar 6.1.1.1. Teckenuppsättning
6.1.1.2. Minnestilldelning "innodb_buffer_pool_size"
6.1.1.3. Binary logging "binlog_format"
6.1.1.4. InnoDB Tablespace "innodb_file_per_table"
6.1.2. Skapa användare som applikationsservern ska använda 6.1.3. Skapa upp databasscheman
6.2. Installationsanvisningar för MongoDB
6.2.1. Installera MongoDB på en eller tre noder 6.2.1.1. Installation
6.2.1.2. Konfiguration av ett flernods-system med replikering:
6.2.1.3. Konfiguration för singelnod-system
6.2.2. Skapa databaser, index och användare för Säkerhetstjänster 6.2.3. Konfigurationsfil - Replikaset
6.2.4. Konfigurationsfil - Singelnod 7. Installation av applikationsserver
7.1. Installera Java och JCE
7.2. Installation av lokala Säkerhetstjänster 7.2.1. Val av installationstyp
7.2.2. Installation utan lokala Säkerhetstjänsters Autentiseringstjänst 7.2.3. Installation på övriga noder (nod2, nod3 osv...) i en fail-over lösning 7.3. Installation Infinispan cluster cache över TCP
8. Uppstart av applikationsserver
8.1. Uppstart av lokal säkerhetstjänst på nod 1 8.2. Anslut till webbgränssnitt
8.3. Uppstart av lokal Säkerhetstjänst på övriga noder 9. Systemkonfiguration
9.1. Konfigurera HSA 9.1.1. HSA-WS 9.1.2. HSA-RIVTA
9.2. Konfigurera Personuppgiftstjänsten
9.3. Ta bort rotcertifikat för test vid en produktionssättning 9.4. Lägg till rotcertifikat för front-end-certifikatet
9.5. Konfigurera System, IdP och SP att använda SITHS-certifikat 9.6. Tilldela systemet egenskaper för interna anrop
9.7. Konfiguration av CDC - Common Domain Cookie 9.8. Autentiseringstjänsten - IdP
9.8.1. Exportera Säkerhetstjänsters IdP/SP metadata 9.8.2. Inläsning av metadata
9.8.3. Exportera SAML metadata 9.8.4. Extern Autentiseringstjänst 9.9. Spärrtjänsten
9.9.1. Block Local Service 3.0.4 9.9.2. Block Web Application 3.0.1
9.9.3. Block National Webservice V4 WS ProxyImpl for RIV 2.1 1.0.0 9.10. Konfiguration av PDL-loggning
9.10.1. Log Agent Impl 3.0.0 9.10.2. Log V2 WS Proxy Impl 3.0.0
9.11. Loggtjänsten - hämtning av arkivloggar från den nationella Loggtjänsten 9.11.1. Schemaläggning för automatisk hämtning av arkiv
9.11.2. Manuell hämtning av (äldre) arkiv ifrån den nationella Loggtjänsten 9.12. Arkivsökning
10. Behörighet
10.1. Behörighetsregler för användare
10.1.1. Behörighet för slutanvändare i Säkerhetstjänsters admin-GUI 10.1.2. Skapande av behörighetsregler för användare
10.1.3. SP-metadata 10.1.4. Läs in SP-metadata 10.1.5. Generera WS metadata 10.1.6. Ta reda på HSA-id 11. Aktivera filter och logga in
11.1. Aktivering av filter för autentisering och åtkomstkontroll 11.2. Logga in i Säkerhetstjänster
12. Systemadministration 12.1. Start och stopp
12.1.1. Stoppa lokala Säkerhetstjänster 12.1.2. Starta lokala Säkerhetstjänster 12.2. Logga in i lokala Säkerhetstjänster
12.2.1. Logga in med SITHS-kort 12.3. Hantera aktiviteter i OSGi
12.3.1. Verifiera att systemets alla bundlar är uppstartade 12.3.2. Aktivering av filter för autentisering och åtkomstkontroll 12.4. Systemlogg (audit)
12.4.1. Sök i systemloggen 12.4.2. Status för loggfunktionen
12.5. Felsökning 13. Test
14. Förvaltning och underhåll 14.1. Periodiskt underhåll 14.2. Backup
14.2.1. Applikationsserver 14.2.2. Databasserver Mysql 14.2.3. Databasserver MongoDB 14.3. Uppgradering
15. Avinstallation 16. Appendix
16.1. Appendix A - Exempel på konfiguration av den lokala brandväggen för windows servrarna 16.2. Appendix B - Skapa separat servicekonto
16.2.1. Skapa en användare
16.2.2. Tilldela användaren "Log on as a service" behörighet 16.2.3. Ändra användare på den installerade servicen
16.2.4. Uppdatera behörighet till filer och kataloger som säkerhetstjänster använder 16.2.5. Lägg till behörigheter i registret
16.3. Appendix C - Krav på delad diskyta vid en fail-over installation
1. Inledning
1.1. Allmänt
Säkerhetstjänster är en produkt som är utformad för att hantera patientuppgifter enligt patientdatalagen (PDL) och tillgodose användare av systemet med en säker autentisering. Produkten innehåller olika tjänster (som exempelvis Autentiseringstjänsten och Spärrtjänsten) som kan installeras separat eller tillsammans som ett komplett paket.
Detta dokument beskriver installationen av lokala Säkerhetstjänster. Dokumentet beskriver i huvudsak:
Portval - SSL standardport 443 eller Säkerhetstjänster 8443-8446 portar.
Installation av databasserver MySQL Installation av databasserver MongoDB Installation av applikationsserver
Systemkonfiguration och uppsättning av behörighet Administration, förvaltning och underhåll
Tabellen nedan beskriver vad installationspaketet innehåller.
Sökväg Beskrivning
db Konfigurationsfiler och databasskript (MySQL).
doc All dokumentation
example Exempelkod för hur man kan ansluta en SP (webb) mot IdP:n (lokal Autentiseringstjänst).
Exempelkod i java och .NET för autentisering av rika klienter.
install Installationsskript och systemkomponenter.
license Samlad licenskatalog
rules Behörighetsregler som ska modifieras och läsas in i systemet
NOTERA: Att installera och konfigurera Säkerhetstjänster kräver en viss teknisk IT-kompetens inom nätverk, databaser, operativsystem och eventuell felsökning.
OBS! Från version 2.11 så är installationspaketet detsamma för både Linux och Windows, men med separata installationsförfaranden.
OBS! Från version 2.15 så har installationsprogrammet förbättrats. Installationen går till på samma sätt som tidigare, där man skall ange ett antal konfigurationsvärden för att systemet skall starta upp.
Det ges även möjlighet att när som helst under installationen spara dom konfigurationsvärden man matat in till en fil, för att vid ett senare tillfälle återuppta installationen, utan att behöva mata in alla värden på nytt igen.
SITHS-certifikat
Sedan april 2019 är det inte rekommenderat att använda SITHS-certifikat för Webbsidor (front-end) eftersom SITHS som utgivare har beslutat sig för att lämna Microsofts rotcertifikat-program.
Man vill fortfarande ha ett SITHS-certifikat för t.ex Spärrtjänstens WebService-gränssnitt och för att kunna kommunicera med t.ex NTjP men man bör alltså även beställa ett certifikat till front-end-domänerna från annan utgivare t.ex SSL-certifikat från Telia eller DigiCert.
Notera att till skillnad från SITHS så har övriga utgivare stöd för Subject Alternative Name, SAN, i sina certifikat så det ska räcka med ett certifikat för alla front-end-domäner i en installation (app, idp, secure.idp) och ett SITHS-certifikat för ws-domänen.
För befintliga installationer med SITHS-certifikat i front-end finns en guide skriven: Byta bort SITHS-cert i frontend
NOTERA: Titta igenom Checklistan innan man påbörjar installationen av Lokala Säkerhetstjänster. Den handlar om förberedelser som skall utföras i god tid innan installationen av Säkerhetstjänster påbörjas.
Checklista inför installation
schema_wsdl Tjänstekontrakten för lokala Säkerhetstjänster templates Mall regel och metadatafil
upgrade Uppgraderingspaket med program, skript och instruktioner
1.2. Begrepp
Begrepp Beskrivning Autentiserin
gstjänst
Även kallad för IdP. Den tjänst som kontrollerar användarens kreditiv och utfärdar en SAML-biljett.
Bundel Komponent till ett program
CDC Common Domain Cookie. En webbläsarkaka som lagrar historik från tidigare besökta IdP:er.
CRL Certificate Revocation List
En lista med certifikat och dess status (ex. revokerat den 12 december 2011). Dessa listor uppdateras oftast med jämna intervaller.
HA High Availability. En tjänst som har hög tillgänglighet.
HPTA En HSA-policytillämpning (HPTA) skrivs av varje direktansluten verksamhet och beskriver hur den enskilda organisationen uppfyller kraven i HSA-policy.
HSA Hälso- och sjukvårdens adressregister, HSA, är en elektronisk katalog som innehåller kvalitetssäkrade uppgifter om personer, funktioner och enheter i Sveriges kommuner, landsting och privata vårdgivare.
HSA-WS Webbservicetjänst mot HSA-katalogen som säkerhetstjänster använder sig av.
IdP Identity Provider (Autentiseringstjänst) Tjänst som autentiserar en aktör och utfärdar, i detta fall, en SAML-biljett. Autentiseringstjänsten (IdP) är en tjänst som levereras med Säkerhetstjänster.
Metadata Konfigureringsdata skriven i XML-format. Används för att ge konsumentsystem behörighet till Säkerhetstjänster. SP-metadata importeras in i IdP:n och IdP:ns metadata importeras in i SP:n för att konfigurera/behörighetsstyra IdP:n och SP:n.
http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
Multicast Gruppsändning till en eller flera noder samtidigt Används av applikationsservrarna.
NTP Network Time Protocol. Används för synkronisering servrarnas realtidsklocka.
OCSP Online Certificate Status Protocol
En aktiv tjänst som svarar på certifikatstatusförfrågningar. Till skillnad från CRL tillhandahåller denna tjänst alltid aktuell status för certifikatet som efterfrågas.
PDL Patientdatalagen
http://www.datainspektionen.se/lagar-och-regler/patientdatalagen/
Personuppg iftstjänst
En nationell tjänst som på ett effektivt sätt hanterar personuppgifter från Skatteverket (Navet), för till exempel adressuppgifter som finns i befolkningsregistret.
REST Representational State Transfer. Beskriver hur tjänster för maskin-till-maskin kommunikation kan ske via webbteknologi.
RIV Regelverk för Interoperabilitet inom Vård och omsorg. www.rivta.se
RIV TA RIV Tekniska anvisningar. Syftet med denna anvisning är att beskriva hur man realiserar utbytet av information mellan två parter. RIV Tekniska Anvisningar är en integrerad del i den nationella arkitekturen.
www.rivta.se
SAMBI SAML-profil för samverkan för Behörighet och Identitet inom hälsa, vård och omsorg. Beskriver hur egenskaper namnsätts i SAML- biljetten.
http://www.inera.se/TJANSTER--PROJEKT/Sakerhetstjanster/Dokument/
SAML Security Assertion Markup Language
En standard som beskriver hur egenskaper och dess värden skall beskrivas i XML-format.
http://saml.xml.org/saml-specifications
SAML biljett Ett intyg som Autentiseringstjänsten utfärdar som innehåller en samling med egenskaper enligt SAML. Inom hälsa, vård och omsorg används SAML-profilen SAMBI.
Single installation
En installationsform där endast en nod används.
SITHS SITHS är en nationell lösning för säker IT i hälso- och sjukvården.
SP Service Provider. Den som erbjuder en tjänst, kan vara ett lokalt vårdsystem eller en tjänst i de lokala säkerhetstjänsterna, t ex Samtyckestjänsten. De lokala tjänsterna i Säkerhetstjänsterna, förutom IdP:n, grupperas som en SP.
Tjänsteplattf ormen (TP)
Tjänsteplattformen är en nationell teknisk plattform som förenklar, säkrar och effektiviserar informationsutbytet mellan olika IT-system inom vård och omsorg.
http://www.inera.se/TJANSTER--PROJEKT/ICC-Integration-Competence-Center/
1.3. Referenser
Referensnr Namn Adress Ref 1 Inera AB www.inera.se
Ref 2 Inera AB Användarhandbok (lokal)
2. Systemkrav
Lokala Säkerhetstjänster levereras med installationsanvisningar för Windows Server 64bit. Denna leverans är kvalitetssäkrad på Windows Server 2012 R2 64bit. Lokala Säkerhetstjänster bör driftsättas med minst tre dedikerade maskiner, en applikationsserver och två databasservrar.
Applikationsservern bör vara flerkärniga med minst 12 GB RAM.
MySQL databasservern för bör vara flerkärniga med minst 8 GB RAM dedikerat för MySQL-servern.
MongoDB servern för bör vara flerkärniga och hur mycket RAM som krävs är beuppstart av lokal Säkerhetstjänst på övriga noderroende på hur mycket respektive vårdgivare loggar. Riktlinje är att 40 miljoner loggposter med dess index tar c:a 20 GB RAM dedikerat för MongoDB-servern.
2.1. Diskyta
För att kunna köra systemet med flera servrar i en HA-lösning krävs att samtliga noder har tillgång till en delad diskyta där bl.a. systemets gemensamma konfiguration finns lagrat. Den delade diskytan kan t.ex. sättas upp med hjälp av en samba-share, Microsoft cluster disk eller NFS delning.
Den delade diskytan rekommenderas att vara redundant så att man inte får en Single Point Of Failure, då systemet kräver den delade diskytan för att kunna starta. Default är namnet på katalogen: C:\share i konfigurationen nedan.
2.1.1. Delad diskyta för Säkerhetstjänster
Installationsdisken bör minst vara 20 GB (mer rekommenderas).
Den delade diskytan (<enhet>\share) för applikationsservrarna bör minst vara 100 GB.
2.1.2. Diskyta för MySQL
Diskytan för MySQL bör minst vara 200 GB.
2.1.3. Diskyta för MongoDB
När databaserna för rapporthanteringen skapas vid installation, behövs ungefär 10 GB diskyta. MongoDB allokerar upp disk som senare används när loggar läggs till i databasen. Fyra databaser skapas vid installationen, som använder detta utrymme. Det är för:
PDL-loggar (lagras default i 18 månader)
Arkivsökningar (PDL-loggar läggs till temporärt och raderas när rapporten är klar)
Statistikloggar som loggar händelser vid inloggning och utloggning. (Lagras som default i 3 månader)
Systemloggar (Används inte primärt utan är en backup om annan loggning inte kan köras eller om den konfigureras att användas) Ytterligare diskyta för MongoDB är helt beroende av hur mycket systemet används:
Riktlinje är att 40 miljoner PDL-loggar tar c:a 115 GB diskarea.
Detsamma gäller för statistikloggning och antalet loggar beror på hur många som använder systemet.
Beroende på om MongoDB används för systemloggning kan antalet systemloggar öka dramatiskt om t.ex. loggnivå ändras till TRACE. Det kan generera stora mängder loggar och diskyta kan snabbt konsumeras.
Den delade diskytan måste sättas upp med en symbolisk länk, se Appendix C - Krav på delad diskyta vid en fail-over installation
2.2. Tidssynkronisering
Operativsystemen för lokala Säkerhetstjänster skall vara tidssynkroniserade för att systemet skall fungera korrekt. Felaktigt inställd tid kan få till följd att autentisering av klienter misslyckas samt att systemet lagrar och/eller uppger felaktiga tidpunkter för verksamhetsdata. Detta säkerställs på
operativsystemnivå och är inte en del av produkten. Vi rekommenderar att rådfråga dem som ansvarar för just er serverdrift.
2.3. Lastbalanserare
Från och med version 2.7 av Lokala Säkerhetstjänster går det att använda SSL standardport (443) för alla ingående tjänster istället för att man externt ansluter till tjänsterna mot en unik port. En förutsättning för att detta ska fungera är att en lastbalanserare finns och är konfigurerad att istället lyssna på, för
och som styr trafiken vidare mot applikationsserverns interna portar (som fortfarande måste vara unika för tjänsterna).
tjänsterna, unika ip-adresser
3. Plattform och tredjepartsprodukter
Följande tredjepartsprodukter och infrastruktur måste installeras först och utgör "plattformen" för lokala Säkerhetstjänster.
3.1. Java
För att köra applikationsservern krävs Oracle Java SE 8, JDK, 64 bitar, som finns att hämta på: http://www.oracle.com/technetwork/java/javase/downloads .
/index.html
Notis om licensen för Oracles distribution av Java;
om man inte uttryckligen slå på användning av t ex Java Mission Control eller Flight Recorder triggas inte den kommersiella licensen. Säkerhetstjänster gör inte detta. Se https://docs.google.com/document/d/17OF811wWjjCnmDPJDD6v2c_nMO93e5evjravdCOkXMQ/edit för detaljerna
3.1.1. JCE - Java Cryptography Extension
Det krävs även ett tillägg, http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html, som måste installeras för att kunna nyttja 256-bitars kryptering.
3.2. MySQL
Lokala Säkerhetstjänster kräver databasservern MySQL. Systemet är kvalitetssäkrat med MySQL Community Server 5.6.37 och säkerhetstjänsterna kräver att ni använder en version ur 5.6-serien, dock senare än version 5.6.18. Tidigare 5.6 versioner har problem gällande minneshanteringen.
Databasen bör ha redundant lagring och/eller en backup-rutin vid produktionssättning. Eftersom detta är en driftrelaterad fråga som kan lösas på en mängd olika sätt så beskrivs det inte mer här.
I denna release av Lokala Säkerhetstjänster har vi valt att ligga kvar på MySQL Community Server 5.6.(37), då MySQL Community Server 5.7.
x innehåller ett fel gällande hantering av XA-transaktioner i redundanta replikerings-miljöer (master-slave, master-master). Oracle är medvetna om detta, men kommer inte att hinna släppa någon patch inför denna release av Lokala Säkerhetstjänster 2.17
3.3. MongoDB
MongoDB är en lättviktig (NoSQL) databas som används för att hantera uppföljning av verksamhetsloggar (PDL-loggar). Databasen håller PDL-loggar i 18 månader (konfigurerbart) tillbaka i tiden och är den databas som loggrapporter genereras från. Loggposter som är äldre än 18 månader tas bort från MongoDB och finns arkiverade som zip-filer för långtidslagring.
MongoDB används för att snabbt kunna söka i stora mängder loggposter och generera rapporter för uppföljning. MongoDB är därför ett krav vid installation av lokal Loggtjänst.
Denna databas används även som reservkälla för systemets händelseloggar ifall anslutningen till MySQL-databasen skulle falla ifrån samt för insamlande av statistik runt autentiseringshändelser. Dessa funktioner går dock att inaktivera ifall man skulle behöva en lokal installation utan tillgång till MongoDB (se I nstallation utan databasen MongoDB som beskrivs senare i dokumentet)
Systemet är kvalitetssäkrat mot MongoDB-server 3.4.7. Hur databasen bör sättas upp för Säkerhetstjänster beskrivs i avsnitt nstallationsanvisningar för I MongoDB
3.4. Lastbalanserare
En lastbalanserare som klarar HTTPS krävs för att köra Säkerhetstjänster med skalskydd och trafikdirigering. Det innebär att lastbalanserare krävs för att kunna köra Säkerhetstjänster med standardport 443 för samtliga tjänster. Anvisningar för lastbalanserare beskrivs inte i detta dokument. Lastbalansering till applikationsserver kan ske med round-robin då all sessionsdata (SSL-sessioner) delas mellan applikationsservrarna och de externa HTTPS-portarna som används bör TCP-monitoreras, innan lastbalansering sker till applikationsservern.
3.5. Funktionscertifikat
Innan installation av lokala Säkerhetstjänster påbörjas måste funktionscertifikat för legitimering införskaffas, utfärdat för Lokala Säkerhetstjänsters olika domäner. Funktionscertifikat används för att identifiera applikationsservern vid all sorts kommunikation.
Sedan april 2019 är det inte rekommenderat att använda SITHS-certifikat för Webbsidor (front-end) eftersom SITHS som utgivare har beslutat sig för att lä .
mna Microsofts rotcertifikat-program Man vill dock fortfarande ha ett SITHS-certifikat för t.ex Spärrtjänstens WebService-gränssnitt och för att kunna kommunicera med t.ex NTjP men man bör alltså även beställa ett certifikat till front-end-domänerna från annan utgivare t.ex SSL-certifikat från Teliaeller Di giCert. Notera att till skillnad från SITHS så har övriga utgivare stöd för Subject Alternative Name, SAN, i sina certifikat så det ska räcka med ett certifikat för alla front-end-domäner i en installation (app, idp, secure.idp) och ett SITHS-certifikat för ws-domänen
Funktionscertifikaten skall vara utfärdade till de DNS-namn som skall användas för applikationsservern. Var god kontakta Inera för information kring SITHS funktionscertifikat [Ref 1].
Det kan se ut som i tabellen nedan för de två nationella installationerna av Säkerhetstjänster:
Domän SAN Utgivare Kommentar
CN = sakerhetstjanst.inera.se DNS Name=sakerhetstjanst.inera.se DNS Name=sakerhetstjanst.sjunet.org DNS Name=idp2.sakerhetstjanst.inera.se DNS Name=idp2.sakerhetstjanst.sjunet.org DNS Name=secure.idp2.sakerhetstjanst.inera.se DNS Name=secure.idp2.sakerhetstjanst.sjunet.
org
DigiCert Inc
CN = DigiCert SHA2 High Assurance Server CA
CN = ws.sakerhetstjanst.inera.se SITHS har inget SAN-stöd SITHS
CN = SITHS Type 3 CA v1
För PreProd/testmiljöer är utgivaren
CN = SITHS Type 3 CA v1 PP CN = ws.sakerhetstjanst.sjunet.
org
SITHS har inget SAN-stöd SITHS
CN = SITHS Type 3 CA v1
För PreProd/testmiljöer är utgivaren
CN = SITHS Type 3 CA v1 PP
3.5.1. Ytterligare funktionscertifikat
Om lokala Säkerhetstjänster ska nyttjas tillsammans med andra IdP:er i en federation, krävs ytterligare ett SITHS funktionscertifikat som är utfärdat för IdP:
n på den gemensamma domänen inom federationen. T ex om den gemensamma domänen i federationen är commondomain.example.com, behöver även denna IdP ha ett funktionscertifikat t.ex. idp.commondomain.example.com.
3.6. CSP - Cryptographic Service Provider
Vid autentisering och anslutning till administrationsgränssnittet för lokala Säkerhetstjänster via webbläsare, krävs tillgång till en CSP på användarens dator. Detta för att kunna använda ”hårda certifikat” (t.ex SITHS-kort). T.ex. kan Net iD användas. Vänligen kontakta Inera för information kring SITHS och Net iD [Ref 1].
3.7. Kluster med Infinispan (Distributed in-memory cache)
Vår rekommendation är att Säkerhetstjänster installeras i ett kluster med två noder. Systemet har en inbyggd lösning med Infinispan, som hjälper noderna att dela resurser (som exempelvis systemets konfigurationer) som ska finnas på en delad diskyta. Fördelen med kluster är att det bidrar till att systemet får högre prestanda, tillgänglighet och kan skalas upp ytterligare.
Infinispan kommunicerar mellan noderna i klustret via UDP (multicast) eller TCP. Infinispan rekommenderar UDP för bäst prestanda. Förvalt vid
installationen ges en multicastadress (239.0.10.1) men den lokala driftsorganisationen bör kontaktas för att bestämma vilken adress som ska användas. M . Väljer er information om multicast adresser hittar ni via följande länk: http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml man TCP måste noderna i klustret anges i en statisk lista i konfigurationen (beskrivs närmare nedan).
3.8. Ciphersuites som används
Följande ciphersuties kan användas av en klient för att konsumera säkerhetstjänsters WS- och Webbgränssnitt:
Stöds bara i TLS 1.2
1. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 2. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 3. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 4. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 5. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 6. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 7. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 8. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 9. TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 10. TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 11. TLS_DHE_RSA_WITH_AES_256_CBC_SHA 12. TLS_DHE_RSA_WITH_AES_128_CBC_SHA Stöds i TLS 1.0 och senare
13. TLS_RSA_WITH_AES_256_GCM_SHA384 14. TLS_RSA_WITH_AES_128_GCM_SHA256 15. TLS_RSA_WITH_AES_256_CBC_SHA256 16. TLS_RSA_WITH_AES_128_CBC_SHA256 17. TLS_RSA_WITH_AES_256_CBC_SHA 18. TLS_RSA_WITH_AES_128_CBC_SHA
3.9. Telnet
Installationen av Säkerhetstjänster kräver att man har en telnet-klient installerad på applikationsservrarna.
4. Säkerhetstjänsters beroenden till externa system
4.1. Behörighet externa system
Kommunikation med externa system sker alltid med mutual TLS vilket innebär att även den anropande tjänsten presenterar sig med ett certifikat. I vårdsverige är detta för detta certifikat ofta ett SITHS-certifikat.
Traditionellt har Säkerhetstjänster alltid använt front-end-certifikatet för huvud-domänen för extern kommunikation. När det inte längre är rekommenderat att använda SITHS-certifikat i front-end så går inte detta längre utan det blir WebService-certifikatet som måste användas.
Se alltså till att ange rätt certifikat vid beställning av accesser i NTjP och andra externa system.
HSA
Lokala Säkerhetstjänster har traditionellt använt HSA's äldre gränssnitt kallat HSA-WS. Detta gränssnitt är dock under avveckling och nya anslutningar tillåts därför inte. Som ny anslutning räknas även en befintlig installation som byter certifikat. Det är därför rekommenderat att man som ansvarig för en lokal installation av Säkerhetstjänster planerar en övergång till det nyare gränssnittet HSA-TK. Se nedan vilka av HSA's tjänstekontrakt man via Inera's elektroniska beställningsstöd måste ansöka om access till. Se även 2.17 Release Notes
4.2. HSA-WS
HSA-WS är under avveckling!
HSA-WS är en webbtjänsteanslutning till underliggande HSA-katalog. Lokala Säkerhetsjänster är kompatibelt med HSA-WS version 2.27 eller senare.
Lokala Säkerhetstjänster ansluter sig till HSA-WS för att hämta information om användare, användares medarbetaruppdrag, vilka vårdenheter som tillhör en vårdgivare, namn på vårdenheter m.m. Applikationsserverns funktionscertifikat för legitimering behöver finnas i HSA-katalogen med behörighet att anropa följande operationer:
GetCareUnit GetCareUnitList GetHsaPerson GetHsaUnit GetMiuForPerson Ping
För att en användare ska kunna autentisera sig krävs det att användaren finns upplagd i HSA-katalogen. Det finns dock inget krav på att användaren måste ha ett medarbetaruppdrag. Om användaren saknar medarbetaruppdrag kommer en ”tom” SAML-biljett att skapas, d.v.s utan egenskaper för användaren och det är upp till konsumenten av SAML-biljetten, SP:n, att avgöra vad som som då skall ske (t.ex. visa ett felmeddelande).
Notera: För att få behörigheterna till HSA-WS behöver man dels ha uppdaterat sin HPTA där ovanstående operationer finns med. Därefter får man skicka ett ärende till nationell kundservice med det HSA-id på det certifikat som säkerhetstjänster ska använda för att systemet ska få access till ovanstående operationer. Observera att dessa ärenden måste begäras av den/de som är HSA-ansvarig.
Adresser till HSA-WS:
Miljö Adress
Test https://wstest.hsa.sjunet.org/svr-hsaws2/hsaws Produktion https://ws.hsa.sjunet.org/svr-hsaws2/hsaws
4.3. HSA-RIVTA
Från och med version 2.15 finns möjlighet att använda sig av HSA-RIVTA kontrakt. Kontakta Inera för mer information om ni funderar över anslutning till HSA-RIVTA.
Behörighet att via NTjP anropa HSA-kontrakt via Nationella Tjänsteplattformen:
•GetEmployeeIncludingProtectedPerson
•GetCredentialsForPersonIncludingProtectedPerson
•GetHealthCareUnit
•GetHealthCareUnitList Patch krävs
För att kunna använda HSAs tjänstekontrakt via NTjP krävs en installation av en rättning
4.4. Revokeringskontroll av certifikat
Applikationsservern för lokala Säkerhetstjänster använder i första hand OCSP och i andra hand CRL för att kontrollera om ett certifikat är spärrat och därmed inte godkänt för användning. Adressen till servrarna som används för OCSP och CRL hämtas från certifikaten och kan därför variera beroende på vilka certifikat som används. Dessa servrar måste kunna anropas från applikationsservern över HTTP (default port 80).
Exempel på adresser till crl och ocsp (Produktion):
Certifikat CRL-adress OCSP-adress
SITHS Type 1 CA v1 http://crl1.siths.se/sithsrootcav1.crl http://crl2.siths.sjunet.org/sithsrootcav1.crl
http://ocsp1.siths.se/
http://ocsp2.siths.sjunet.org/
SITHS CA v3 SITHS CA v4
http://www.carelink.se/siths-ca/ca003.crl http://sithsocsp.trust.telia.com/
Exempel på adresser till crl och ocsp (Test):
Certifikat CRL-adress OCSP-adress
SITHS_Type_1_CA_v1_PP http://crl1pp.siths.se/sithsrootcav1pp.crl http://crl2pp.siths.sjunet.org/sithsrootcav1pp.crl
http://ocsp1pp.siths.se/
http://ocsp2pp.siths.sjunet.org/
SITHS CA TEST v3 SITHS CA TEST v4
http://www.carelink.se/siths-ca/test-crl0003.crl http://sithsocsp.preprod.trust.telia.com/
4.5. Personuppgiftstjänsten - Personuppgiftstjänsten
Personuppgiftstjänsten är en tjänst som innehåller personuppgifter. Lokala Säkerhetstjänster använder Personuppgiftstjänsten via NTjP för att hämta patienters namn i användargränssnittet.
Behörighet krävs för att via NTjP anropa följande metod:
GetPersonsForProfile v3
Adresser till Personuppgiftstjänsten via tjänsteplattformen:
Miljö Adress
Test Sjunet https://qa.esb.ntjp.sjunet.org:443/vp/strategicresourcemanagement/persons/person/GetPersonsForProfile/3/rivtabp21 Test Internet https://qa.esb.ntjp.se:443/vp/strategicresourcemanagement/persons/person/GetPersonsForProfile/3/rivtabp21 Produktion Sjunet https://esb.ntjp.sjunet.org:443/vp/strategicresourcemanagement/persons/person/GetPersonsForProfile/3/rivtabp21 Produktion Internet https://esb.ntjp.se:443/vp/strategicresourcemanagement/persons/person/GetPersonsForProfile/3/rivtabp21
Uppgifter som matas in under Generell konfiguration PU - V3 WS Proxy Impl 1.0.0
4.6. Nationell Spärrtjänst*
Den lokala Spärrtjänsten har inbyggd funktionalitet för synkronisering av spärrdata mot den nationella Spärrtjänsten. Innan replikeringen aktiveras måste förvaltningsorganisationen för nationell Spärrtjänst kontaktas för att öppna upp access till den nationella Spärrtjänsten. Kontakta Ineras förvaltning i god tid före driftstart [Ref 1].
Behörighet krävs för att via NTjP anropa följande metoder:
GetBlocks v4 RegisterBlock v4 UnregisterBlock v4
RegisterTemporaryRevoke v4 UnregisterTemporaryRevoke v4
Adresser spärreplikering:
Miljö Adress
Test Sjunet https://qa.esb.ntjp.sjunet.org:443/vp/informationsecurity/authorization/blocking Test Internet https://qa.esb.ntjp.se:443/vp/informationsecurity/authorization/blocking Produktion Sjunet https://esb.ntjp.sjunet.org:443/vp/informationsecurity/authorization/blocking Produktion Internet https://esb.ntjp.se:443/vp/informationsecurity/authorization/blocking
Uppgifter som matas in under Generell konfiguration Block National V4 WS ProxyImpl for RIV 2.1 1.0.0.
Obs! Replikering av spärrar ska ske via tjänsteplattformen. För adresser/portar se kapitel Tjänsteplattformen nedan.Om det finns en existerande lokal installation av säkerhetstjänster och det inte är konfigurerat replikering via tjänsteplattformen, kan nedanstående adresser användas.
4.7. Nationell Loggtjänst*
Den lokala Loggtjänsten har inbyggd funktionalitet för att hämta hem den egna vårdgivarens PDL-loggar från den nationella Loggtjänsten via dess hämtningstjänst. Detta för att man lokalt ska kunna köra och få en loggrapport med loggar, både från de nationella systemen och ens lokala vårdsystem.
Innan hämtningstjänsten aktiveras måste förvaltningsorganisationen för nationell Loggtjänst kontaktas, för att öppna upp access till tjänsten. Kontakta Ineras förvaltning i god tid före driftstart [Ref 1].
Följande adresser används för hämtningstjänsten:
Miljö Adress
Acceptanstest https://ws.acctest.sakerhetstjanst.sjunet.org/
Produktion https://ws.sakerhetstjanst.sjunet.org/
Tjänsterna Spärr och Samtycke behöver logga sina PDL-loggar till en loggtjänst. Detta kan vara en lokal Loggtjänst eller den nationella Loggtjänsten via tjänsteplattformen. För adresser/portar se avsnitt Tjänsteplattformen nedan.
Väljer man att använda den nationella Loggtjänsten, måste förvaltningsorganisationen för nationell Loggtjänst kontaktas för att öppna upp access till tjänsten samt konfigurera vilka vårdgivare som denna lokala Loggtjänst tillåts hantera nationellt. Hur detta görs beskrivs senare i dokumentet.
Kontakta Ineras förvaltning i god tid före driftstart [Ref 1].
*Nationell Loggtjänst kan användas om någon av tjänsterna Spärr, Samtycke eller Logg installeras.
4.8. Tjänsteplattformen*
Installeras Samtyckestjänsten måste den lokala Säkerhetstjänsten registreras som producent i tjänsteplattformen. Detta för att samverkan ska kunna ske med de nationella tjänsterna. T ex en nationell tjänst som vill läsa från den lokala instansen, ifall ett samtycke finns registrerat.
Figuren nedan illustrerar hur en läsande nationell tjänst routas via den nationella tjänsteplattformen, genom en lokal tjänsteplattform (valfri) för att till sist hamna i den lokala Samtyckestjänsten.
Figur: Principer för samverkande tjänster för hantering av samtycke
Installeras någon av tjänsterna Spärr och Samtycke och konfigureras för att logga PDL-loggar till den nationella Loggtjänsten, måste de lokala Säkerhetstjänsterna registreras som konsument i tjänsteplattformen.
Tjänsten Spärr replikerar sina spärrar till den nationella Spärrtjänsten via tjänsteplattformen, vilket gör att den måste registreras som konsument i tjänsteplattformen.
Kontakta Ineras förvaltning i god tid före driftstart för att registrera tjänsterna i tjänsteplattformen [Ref 1].
Adresser till Tjänsteplattformen:
Miljö Hostnamn IP-adress port contextpath
QA-Sjunet qa.esb.ntjp.sjunet.org 82.136.149.53 443 /vp Produktion-Sjunet esb.ntjp.sjunet.org 82.136.149.61 443 /vp
*Tjänsteplattformen kan användas om någon av tjänsterna Spärr, Samtycke och Logg har installerats.
5. Systemöversikt
Detta kapitel beskriver hur systemet sätts upp med maskiner och nätverksstruktur.
5.1. Ingående servrar
Lokala Säkerhetstjänster kan bestå av en eller flera applikationsservrar, en MySQL databasserver och en MongoDB databasserver beroende på vilka tjänster som ska installeras. Databasservrarna kan/bör även sättas upp på flera maskiner i ett kluster med någon typ av 'fail-over' lösning. På applikationsservern installeras en gemensam plattform. På plattformen kan man välja vilka av de fristående tjänsterna Spärr, Samtycke, Autentisering (IdP) och Logg som ska installeras.
Lokala Säkerhetstjänster kan konfigureras på två grundläggande sätt, med en nod eller flera noder i ett kluster. Vår rekommendation är att installera i ett kluster med två maskiner men flera går också bra. Säkerhetstjänsterna installerat i ett kluster ger en typ av active-active 'fail-over' då det ökar
tillgängligheten och kapaciteten på systemet. För att kunna köra i ett kluster av noder krävs att alla noder har tillgång till en delad diskyta.
En lastbalanserare används för att dirigera trafiken till alla applikationsservrar (genom t.ex. round-robin). SSL-sessioner delas mellan
applikationsservrarna, lastbalansering kan därför ske till vilken nod som helst. Om fel uppstår på någon av applikationsservrarna dirigeras trafiken bort från den felaktiga servern till de övriga applikationsservrarna. Alla maskiner i klustret bör vara identiska.
För hanteringen med att dela SSL-sessioner och andra objekt mellan applikationsservrarna är produkten Infinispan integrererat i systemet. Infinispan är en distribuerad cache-lösning som Säkerhetstjänsten använder för att kunna dela data mellan noderna. Det är konfigurerat att kommunicera med UDP och multicast eller TCP för att hitta alla noder i ett kluster.
Singelnodlösningen består av en applikationsserver, en MySQL databasserver och eventuellt en MongoDB databasserver, upp till totalt tre stycken maskiner.
För en installation av ett kluster tillkommer alltså ytterligare maskiner.
Figuren nedan visar ett exempel på en klustrad lösning.
Figur: Systemöversikt av Säkerhetstjänster installerat med en kluster lösning.
5.2. Exempelinstallation och konfiguration
5.2.1. Lokala Säkerhetstjänster installerade med Spärr och Autentisering
Bilden nedan visar en installation av lokal Spärrtjänst och Autentiseringstjänst. Spärreplikeringen till den nationella Spärrtjänsten sker via
tjänsteplattformen, även Spärrtjänstens PDL-loggning går via tjänsteplattformen till den nationella Loggtjänsten. Detta kräver att den lokala Spärrtjänsten registreras som en konsument i tjänsteplattformen. Logguppföljning på händelser i den lokala Spärrtjänsten, måste i detta fall göras i den nationella Loggtjänsten. För att slå upp namn på patienter, använder Spärrtjänsten Personuppgiftstjänsten. HSA och Revokeringskontroll används av alla tjänster i lokala Säkerhetstjänster.
Figur: Lokala Säkerhetstjänster med Spärr och Autentisering installerade.
5.2.2. Lokala Säkerhetstjänster installerade med alla tjänster
Bilden nedan visar en installation där samtliga tjänster (Spärr, Samtycke, Logg och Autentisering) finns installerade lokalt. Spärreplikeringen till den nationella Spärrtjänsten sker via tjänsteplattformen, vilket kräver att den lokala Spärrtjänsten finns registrerad som konsument i tjänsteplattformen.
Samtycke behöver registreras i tjänsteplattformen som producenter för att nationella system, t.ex. NPÖ, ska kunna registrera samtycken i rätt tjänst (via tjänsteplattformen).
Spärr, Samtycke och PDL-loggar till den lokala Loggtjänsten. Den lokala Loggtjänsten hämtar även hem de PDL-loggar som finns i den nationella Loggtjänsten via dess hämtningstjänst. För att slå upp namn på patienter används Personuppgiftstjänsten. HSA och Revokeringskontroll används av samtliga tjänster.
Figur: Lokala Säkerhetstjänster med alla tjänster installerade.
5.3. Översikt adresser och portar
Säkerhetstjänster är uppdelat i flera olika tjänster/delar. I tidigare versioner av Säkerhetstjänster har man anslutit till dessa tjänster via en och samma ip- adress med unika portnummer som identifierade tjänsterna (vi kallar i detta dokument denna konfiguration för 8443 ports). Från version 2.7 av den Lokala Säkerhetstjänsten kan man även använda SSL standardport 443 för samtliga tjänster men då krävs det att varje tjänst tilldelas en egen ip-adress (vi kallar i detta dokument denna konfiguration för 443 ports). För att kunna använda standardport 443 för alla tjänster måste dessa ip-adresser mappas i
lastbalanseraren mot applikationsserverns interna portar som fortfarande måste vara unika för tjänsterna. Skillnaderna beskrivs av tabellen nedan. De interna portarna i tabellen avser föreslagen port men konfigureras manuellt vid installation. Dessa ska vid 443-port-konfiguration inte öppnas för extern åtkomst utan enbart vara åtkomlig från lastbalanseraren.
Det är alltså möjligt att konfigurera Säkerhetstjänster på båda dessa sätt och det är viktigt att vid installationen tänka på att ange samma port för interna och publika portar om man vill konfigurera med 8443-ports och port 443 som publika portar om man vill konfigurera med SSL Standard port 443.
Publik adress (443 ports) Publik adress (8443 ports) Intern adress (internal ports)
https://ws.<Hostnamn-Applikationsserver>:443 https://<Hostnamn-Applikationsserver>:8080 https://<Hostnamn-Applikationsserver>:8080 https://secure.idp.<Hostnamn-Applikationsserver>:443 https://<Hostnamn-Applikationsserver>:8444 https://<Hostnamn-Applikationsserver>:8444 https://idp.<Hostnamn-Applikationsserver>:443 https://<Hostnamn-Applikationsserver>:8445 https://<Hostnamn-Applikationsserver>:8445 https://cd.<Hostnamn-Applikationsserver>:443 https://<Hostnamn-Applikationsserver>:8446 https://<Hostnamn-Applikationsserver>:8446 https://<Hostnamn-Applikationsserver>:443 https://<Hostnamn-Applikationsserver>:8443 https://<Hostnamn-Applikationsserver>:8443
5.3.1. Applikationsserver
Denna tabell visar vilka portöppningar som krävs för att lokala Säkerhetstjänster skall fungera. Portar i tabellen avser föreslagen port, men dessa konfigureras manuellt vid installation. betyder inkommande trafik och In Ut utgående trafik.
Server Port Beskrivning
Applikationss erver
8443 (in)
HTTPS (envägs-SSL, generellt administrationsgränssnitt). Ska ej öppnas för extern åtkomst vid 443 port-konfiguration.
8444 (in)
HTTPS (tvåvägs-SSL, IdP-webbgränssnitt för identifiera användare med certifikat t.ex. SITHS). Ska ej öppnas för extern åtkomst vid 443 port-konfiguration.
*Används endast vid installation av lokal IdP 8445
(in)
HTTPS (envägs-SSL, IdP-webbgränssnitt med bla.val av identifikationsmetod och SSO). Ska ej öppnas för extern åtkomst .
vid 443 port-konfiguration
*Används endast vid installation av lokal IdP 8446
(in)
HTTPS (envägs-SSL, IdP-webbgränssnitt för CDC-hantering). Ska ej öppnas för extern åtkomst vid 443 port-konfiguration.
8080 (in)
HTTPS (tvåvägs-SSL, WebServices, t.ex.CheckBlocks). Ska ej öppnas för extern åtkomst vid 443 port-konfiguration.
8004 (i n)
Java JMX-övervakning, behöver ej öppnas om inte övervakning används. Ska ej öppnas för extern åtkomst.
1111 (i n)
Telnet-port för systemkonsol. Ska ej öppnas för extern åtkomst.
443 (in) HTTPS för samtliga externa tjänster vid 443 port-konfiguration. Ska ej öppnas för extern åtkomst vid 8443 ports-konfiguration.
SSL Standartport 443
Tänk också på att om man väljer en konfiguration med standardport 443 för alla tjänster och därmed flera olika URL:er så krävs det ett unikt certifikat per URL eller ett wildcard certifikat.
Tänk också på att för IdP-adresserna så måste secure.idp-adressen vara en underdomän till idp-adressen.
443 (ut) HTTPS-anrop till HSA, Personuppgiftstjänsten, replikering till nationell hämtningstjänst för loggar samt intern kommunikation med lastbalanseraren för routing.
80 (ut) Porten används av systemet för slagningar mot OCSP- och CRL-kontroll för verifiering av certifikat på exempelvis SITHS- certifikat.
Använder man andra certifikat än SITHS kan andra portar vara aktuella för OCSP/CRL.
3306 ( ut)
Anrop till MySQL-databasservern.
27017 (ut)
Anrop till MongoDB-databasservern
443 (ut)
Anrop till tjänsteplattformen
5.3.2. Databasserver
Databasserver Port Beskrivning
MySQL 3306
(in)
Anslutningsport till MySQL-databas. Används av applikationsservern. Ska ej öppnas för extern åtkomst utan enbart vara åtkomlig ifrån applikationsservrarna.
MongoDB 27017
(in/ut)
Anslutningsport till MongoDB-Används av applikationsservern, samt i MongoDB Replica set. Ska ej öppnas för extern noderna.
åtkomst utan enbart vara åtkomlig ifrån applikationsservrarna samt de andra MongoDB- MongoDB
(Arbiter)
30000 (in/ut)
Används av arbiters i Replica set. Ska ej öppnas för extern åtkomst utan endast vara öppen internt för de andra MongoDB- noderna.
5.4. Adressöversikt gränssnitt
Tabellen nedan visar adresser/URL:er till de webbgränssnitt som Säkerhetstjänsterna erbjuder och som kan användas av användare av den lokala Säkerhetstjänsten. Se respektive tjänstekontraktsbeskrivning för detaljerad beskrivning av tjänsterna och dess användning. Spärr, Samtycke och Logg är RIV TA 2.1 tjänster, se vidare http://www.rivta.se.
5.4.1. Webbgränssnitt admin-GUI
Prefix (443 ports) Prefix (8443 ports) Adress Beskrivning
https://<Hostnamn-Applikationsserver>/ https://<Hostnamn-Applikationsserver>:8443/ block blocklocal
GUI för Spärr
commonarchive GUI för Arkivering consentpdl GUI för Samtycke idpadmin
statistics
GUI för Autentisering
javamelody systemlog job
GUI för Övervakning
logreportarchive GUI för Arkivsökning logreport
logreportnational
GUI för Loggrapport
logstatusservice GUI för Logg
spinfo GUI för Hjälp
sysadmin spadmin accesscontrol
GUI för Administration
general GUI för felmeddelanden
5.4.2. Webbgränssnitt Autentiseringstjänsten
Prefix (443 ports) Prefix (8443 ports) Adress Beskrivning
.<Hostnamn-Applikationsserver>/
https://idp https://<Hostnamn-Applikationsserver>:8445/ idp/saml/sso/{binding} Autentiseringstjänst (IdP) SSO idp/saml/slo/{binding} Autentiseringstjänst (IdP) SLO
idp/saml Metadata IdP
5.4.3. Webbtjänstegränssnitt för autentisering rika klienter - STS
Prefix (443 ports) Prefix (8443 ports) Adress Beskrivning
.<Hostnamn- https://ws
Applikationsserver>/
https://<Hostnamn-Applikationsserver>:
8080/
ws/idp/sts Autentiseringstjänst (STS) 2 vägs-SSL
.<Hostnamn- https://idp
Applikationsserver>/
https://<Hostnamn-Applikationsserver>:
8445/
ws/idp/sts Autentiseringstjänst (STS) 1 vägs-SSL (meddelandesignering)
5.4.4. Webbtjänstegränssnitt WS-port - RIV TA-tjänster och REST-tjänst
Alla adresser för webbtjänstegränssnitt har följande prefix:
Prefix (443 ports) Prefix (8443 ports)
.<Hostnamn-Applikationsserver>/
https://ws https://<Hostnamn-Applikationsserver>:8080/
Spärr version 2.0 RIV TA 2.1
blockingLocalService/DeleteExtendedBlock/2/rivtabp21
blockingLocalService/CancelTemporaryExtendedRevoke/2/rivtabp21 blockingLocalService/RegisterTemporaryExtendedRevoke/2/rivtabp21 blockingLocalService/RevokeExtendedBlock/2/rivtabp21
blockingLocalService/RegisterExtendedBlock/2/rivtabp21 blockingLocalService/GetExtendedBlocksForPatient/2/rivtabp21 blockingLocalService/GetPatientIds/2/rivtabp21
blockingLocalService/GetAllBlocks/2/rivtabp21
blockingLocalService/GetAllBlocksForPatient/2/rivtabp21 blockingLocalService/GetBlocksForPatient/2/rivtabp21 blockingLocalService/GetBlocks/2/rivtabp21
blockingLocalService/CheckBlocks/2/rivtabp21 blockingLocalService/PingForConfiguration/2/rivtabp21
Spärr version 3.0 RIV TA 2.1
blockingLocalService/CheckBlocks/3/rivtabp21 blockingLocalService3/PingForConfiguration/1/rivtabp21
Spärr version 4.0 RIV TA 2.1
blockingLocalService/PingForConfiguration/4/rivtabp21 blockingLocalService/DeleteExtendedBlock/4/rivtabp21
blockingLocalService/CancelTemporaryExtendedRevoke/4/rivtabp21 blockingLocalService/RegisterTemporaryExtendedRevoke/4/rivtabp21 blockingLocalService/RevokeExtendedBlock/4/rivtabp21
blockingLocalService/RegisterExtendedBlock/4/rivtabp21 blockingLocalService/GetExtendedBlocksForPatient/4/rivtabp21 blockingLocalService/GetPatientIds/4/rivtabp21
blockingLocalService/GetBlocks/4/rivtabp21 blockingLocalService/CheckBlocks/4/rivtabp21
Samtycke version 1.0 RIV TA 2.1
consentService/PingForConfiguration/1/rivtabp21 consentService/GetConsentsForCareProvider/1/rivtabp21 consentService/GetConsentsForPatient/1/rivtabp21 consentService/DeleteExtendedConsent/1/rivtabp21 consentService/CancelExtendedConsent/1/rivtabp21 consentService/RegisterExtendedConsent/1/rivtabp21 consentService/GetExtendedConsentsForPatient/1/rivtabp21 consentService/CheckConsent/1/rivtabp21
Samtycke version 2.0 RIV TA 2.1
consentService/PingForConfiguration/2/rivtabp21 consentService/CheckConsent/2/rivtabp21 consentService/DeleteExtendedConsent/2/rivtabp21 consentService/CancelExtendedConsent/2/rivtabp21 consentService/RegisterExtendedConsent/2/rivtabp21 consentService/GetExtendedConsentsForPatient/2/rivtabp21 consentService/GetConsentsForCareProvider/2/rivtabp21 consentService/GetConsentsForPatient/2/rivtabp21
Logg version 1 RIV TA 2.1
logService/PingForConfiguration/1/rivtabp21 logService/StoreLog/1/rivtabp21
logQueryingService/PingForConfiguration/1/rivtabp21 logQueryingService/GetInfoLogsForPatient/1/rivtabp21 logQueryingService/GetInfoLogsForCareProvider/1/rivtabp21 logQueryingService/GetAccessLogsForPatient/1/rivtabp21 logQueryingService/GetLogsForPatient/1/rivtabp21 logQueryingService/GetLogsForUser/1/rivtabp21 logQueryingService/GetLogsForCareProvider/1/rivtabp21
logReportServiceInternal/IsMaintenanceOngoingInternal/1/rivtabp21 logReportServiceInternal/GetLogReportsInfo/1/rivtabp21
logReportServiceInternal/GetAggregatedLogsForPatientInternal/1/rivtabp21 logReportServiceInternal/GetAggregatedLogsForUserInternal/1/rivtabp21 logReportServiceInternal/GetAggregatedLogsForCareProviderInternal/1/rivtabp21 logReportServiceInternal/GetLogsInternal/1/rivtabp21
logReportServiceInternal/GetLogProducersByCareProviderInternal/1/rivtabp21
Logg version 2 RIV TA 2.1
logService/PingForConfiguration/2/rivtabp21 logService/StoreLog/2/rivtabp21
logReportService/PingForConfiguration/2/rivtabp21 logReportService/GetLogs/2/rivtabp21
logReportService/GetInfoLogs/2/rivtabp21
logReportService/GetAccessLogsForPatient/2/rivtabp21
CommissionService version 1 RIV TA 2.1
commissionService/GetCommissionsForPerson/1/rivtabp21 commissionService/SetSelectedCommissionForPerson/1/rivtabp21 commissionService/PingForConfiguration/1/rivtabp21
Adress till REST-tjänst för att söka och ladda ner loggarkiv från Säkerhetstjänster (hämtningstjänst).
Loggarkiv hämtningstjänst logdownload_v2/archives
Dokumentet Hämta loggarkiv 2.0 är en bilaga till tjänstekontraktet för logg. Det beskriver REST-tjänsten och hur hämta arkiv fungerar med parametrar osv.
6. Installation av databasserver
Det är av prestandaskäl rekommenderat att tilldela lokala Säkerhetstjänsters databasservrar egna fysiska maskiner.
6.1. Installera MySQL
: MySQL har officiella installationsanvisningar här http://dev.mysql.com/doc/refman/5.6/en/installing.html
För utökad support och funktionalitet såsom online-backup finns samma version i Enterprise Edition-utförande som dock inte är kostnadsfri. Mer information om detta finns här: http://www.mysql.com/products/enterprise. Rekommenderbart är att nyttja en High Availability lösning.
Mer information om detta finns här: https://dev.mysql.com/doc/refman/5.6/en/ha-overview.html
Den MySQL-användare som används vid installationen kräver behörighet att ändra, uppdatera och lägga till nya tabeller i de scheman som skapas för systemet.
6.1.1. Specifika MySQL-inställningar
6.1.1.1. TeckenuppsättningDefault-installation av MySQL använder teckenuppsättningen latin1. Detta måste ändras till UTF-8för att svenska tecken ska användas korrekt. I katalogen <Lokal_sakerhetstjanst>\db\example\ finns ett exempel på en MySQL-konfigurationsfil (anpassad för Linux) där teckenuppsättningen är ändrad till UTF-8, och även lite generella inställningar man kan använda för att få upp prestandan på MySQL. Dessa generella Inställningar kan man även lägga in i konfigurationsfilen för Windows (observera att det inte finns någon exempel-fil för Windows). Nedan visas dessa inställningar som behöver ändras i filen m
i Linux-installationen och i filen i Windows.
y.cnf my.ini
# Set default character sets to use UTF-8
init_connect='SET collation_connection = utf8_general_ci; SET NAMES utf8;' character-set-server=utf8
character-set-client=utf8 collation-server=utf8_general_ci skip-character-set-client-handshake
6.1.1.2. Minnestilldelning "innodb_buffer_pool_size"
För att minska diskaccess bör denna sättas upp till 4-8 GB RAM-tillgång. Upp till 80% av maskinens minnesstorlek på en dedikerad databasmaskin säger MySQL-dokumentationen.
Sätts i konfigurationsfilen (my.cnf på Linux och my.ini på Windows)
# InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes...
innodb_buffer_pool_size = 6G
6.1.1.3. Binary logging "binlog_format"
Sätts till ROW för Säkerhetstjänster.
Sätts i konfigurationsfilen (my.cnf på Linux och my.ini på Windows)
# binary logging format binlog_format=ROW
6.1.1.4. InnoDB Tablespace "innodb_file_per_table"
Default för senare versioner av MySQL (från 5.6.x) är att tabeller och index skrivs till en fil per schema istället för en enda stor fil.
För detta i tidigare versioner av MySQL, lägg till följande bland övriga innodb-parametrar i konfigurationsfilen (my.cnf på Linux och my.ini på Windows) OBS: Som tidigare nämnts så rekommenderas det att installera den senaste versionen av 5.6-serien (5.6.37).
Vi hänvisar till konfigurationsfilen för MySQL i exemplen nedan, för både Linux och Windows, då både Windows och Linux anvisningarna delar på denna information.
Exempel Linux: /etc/my.cnf
Exempel Windows: C:\ProgramData\MySQL\MySQL Server 5.6\my.ini
Observera: Att man måste aktivera valet "Show hidden files, folders, and drives" under Folder options för att kunna se katalogen C:\ProgramData
1.
2.
3.
4.
# Use one file per table innodb_file_per_table
OBS! Har man ett befintligt system utan denna parameter kan man inte bara ändra utan att först dumpa ut all data och sedan läsa in den igen efter att detta ändrats (beskrivs inte i detta dokument). Denna inställning är dock inte tvingande så man kan i detta läge fortsätta utan denna inställning.
6.1.2. Skapa användare som applikationsservern ska använda
Skapa en användare i MySQL som har behörighet att ändra, uppdatera och lägga till nya tabeller i de scheman som skapas för systemet.
Det behövs två användare:
# sak@localhost : användaren sak kan enbart ansluta från ”localhost”.
# sak@% : användaren sak kan ansluta från ”any hosts”
Användarna behöver inte ha behörighet för att kunna skapa nya scheman.
Starta ett terminal-fönster mot databasservern och skriv följande kommando:
mysql -u root -p
Ange det lösenord som angavs vid installationen.
Skapa ny användare (i detta exempel är användarnamnet sak vilket rekommenderas, samt ett lösenord) genom att skriva följande tre kommandon:
CREATE USER 'sak'@'localhost' IDENTIFIED BY 'password';
GRANT CREATE, DROP, EVENT, DELETE, INDEX, INSERT, SELECT, UPDATE, CREATE TEMPORARY TABLES, LOCK TABLES, TRIGGER, CREATE VIEW, SHOW VIEW, EXECUTE ON *.* TO 'sak'@'localhost';
FLUSH PRIVILEGES;
Skapa ny användare (i detta exempel är användarnamnet sak vilket rekommenderas, samt ett lösenord) genom att skriva följande tre kommandon:
CREATE USER 'sak'@'%' IDENTIFIED BY 'password';
GRANT CREATE, DROP, EVENT, DELETE, INDEX, INSERT, SELECT, UPDATE, CREATE TEMPORARY TABLES, LOCK TABLES, TRIGGER, CREATE VIEW, SHOW VIEW, EXECUTE ON *.* TO 'sak'@'%';
FLUSH PRIVILEGES;
Avsluta MySQL prompten med kommando:
quit
6.1.3. Skapa upp databasscheman
När databasanvändare har skapats, ska databasscheman som lokala Säkerhetstjänster använder skapas upp. I installationspaketet (under strukturen <Lok ) ligger samtliga databasscheman som behöver sättas upp.
al_sakerhetstjanst>\db\mysql\
Tabellen nedan visar vilka skript som tillhör de databasscheman som kommer sättas upp i nästkommande steg.
Schema Skript
accesscontrol accesscontrol.sql accesscontrol_data.sql
OBS! Att tillåta att en användare kan ansluta från "any hosts" bör endast användas i en testmiljö. För en produktionsmiljö bör användningen låsas ytterligare, så att det bara är applikationsserverna som kan ansluta till databasservern.
OBS! För att skapa scheman krävs en användare som har root-rättigheter, vilket skapades upp under installationen av MySQL.
1.
2.
3.
4.
5.
6.
audit audit.sql
blkloc blkloc.sql
commission commission_service.sql
consent consent.sql
idp idp.sql
idp_data.sql
inftyp inftyp.sql
inftyp_data.sql
job quartz.sql
logdb logdb.sql
logreport logreport.sql logreport_data.sql logreportarchive logreportarchive.sql
logreportarchive_data.sql logdlarchive logdlarchive.sql metadata metadata.sql
sinkdb1 sinkdb1.sql
sp sp.sql
sp_data.sql
Skapa upp databaserna:
För över samtliga komponenter som finns i katalogen <Lokal_sakerhetstjanst>\db\mysql\ till en tmp katalog på er MySQL-server.
Öppna ett kommandofönster (cmd.exe - Command prompt).
Gå till katalogen dit filerna kopierats.
Exempel:
cd c:\tmp\mysql
Lista innehållet i katalogen. Utöver de sql-skript som listas i tabellen, finns skript-filen create_databases_windows.bat. Editera create_databases_windows.bat scriptet och ändra sökväg om ni installerat mysql i en annan katalog.
Exempel:
set mysql="C:\Program Files\MySQL\MySQL Server 5.6\bin\mysql.exe"
Skript-filen create_databases_windows.bat ska köras med följande parametrar:
Målmiljö - Den databasserver som skall användas.
Användarnamn – det användarnamn som används till databasmiljön med root-rättigheter.
Prefix – ej obligatoriskt. Ett prefix till tabellnamnet, kan anges om så önskas. I exempelbilden nedan har vi angivit ”exemple_” som prefix.
Om prefix anges kommer namnet på databaserna att få följande utseende som exempel:
example_accesskontrol example_audit osv...
Exempel:
create_databases_windows.bat localhost root example_
När skriptet körs kommer en fråga om ni vill fortsätta att skapa upp databaserna. Ange ”y” för att fortsätta med exekveringen.
Alla databaser kommer att tas bort och skapas igen så all befintlig data kommer att raderas.
OBS!
Exempel:
6.
7.
8.
Exempel:
C:\temp\mysql>create_databases_windows.bat localhost root example_
"C:\Program Files\MySQL\MySQL Server 5.6\bin\mysql.exe"
"C:\Program Files\MySQL\MySQL Server 5.6\bin\mysql_config_editor"
Create MySQL databases for Lokala Sakerhetstjansten.
*NOTE* that by running this script all tables will be recreated and all existing data will be lost!!!
DO YOU WANT TO CONTINUE?(y/n)y Enter password: ******
Do you really want to recreate these databases:
Creating schema "example_accesscontrol"...
...drop and recreate schema example_accesscontrol successful ...reading accesscontrol.sql successful
...database "example_accesscontrol" created Creating schema "example_audit"...
...drop and recreate schema example_audit successful ...reading audit.sql successful
...database "example_audit" created osv...
osv...
osv...
Creating schema "example_sp"...
...drop and recreate schema example_sp successful ...reading sp.sql successful
...reading sp_data.sql successful ...database "example_sp" created
DONE
C:\temp\mysql>
Om inget fel uppstod kommer meddelandet DONE att skrivas ut. Verifiera att databaserna har skapats genom att logga in i mysql-prompten och exekvera följande:
Exempel:
c:\tmp\mysql>"c:\Program Files\MySQL\MySQL Server 5.6\bin\mysql.exe" -uroot -p mysql> show databases;
För att kontrollera om det finns tabeller i ett schema (t.ex. accesscontrol ) ange kommandot:;
Exempel:
mysql> use accesscontrol;
mysql> show tables;
+---+
| Tables_in_accesscontrol | +---+
| action_resource |
| action_resource__attributes |
| attribute |
| data_template | +---+
3 rows in set (0.00 sec)
Lista tabeller
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
6.2. Installationsanvisningar för MongoDB
Här följer ett exempelpå installation av databasen MongoDB för Säkerhetstjänster. MongoDB kan laddas ner som ett MSI-paket. MongoDB har officiella installationsanvisningar här: https://docs.mongodb.com/manual/tutorial/install-mongodb-on-windows/
6.2.1. Installera MongoDB på en eller tre noder
Nedan följer installationsexempel för MongoDB med replikering samt singelnod. I det första fallet innebär det att installationen kommer att använda tre noder kallade Primary, Secondary och Arbiter. Att installera MongoDB på tre noder har två syften:
Prestanda Tillgänglighet
I konfigurationen som följer efter installationen utser man vilka noder som ska ingå i uppsättningen. Vilka noder som ska vara datanoder och vilken av dessa som data ska läsas ifrån. Noden som har rollen Primary är den nod som data skrivs till. Arbitern bedömer vilken av noderna som ska fungera som Pr
och vilken/vilka som ska fungera som .
imary Secondary
kan med fördel installeras på applikationsservern. Säkerhetstjänster kommer att begära att få läsa ifrån en -nod. Detta ökar prestandan
Arbitern Secondary
avsevärt under hanteringen av verksamhetsloggar, då en nod hanterar alla inkommande loggar och läsning kan ske från en annan nod. Med rollen som ” domare” kan Arbitern sedan bestämma om noderna Primary och Secondary ska byta roller vid detekterade problem.
Det går även att sätta upp installationen på en nod, en så kallad singlenodinstallation, men av prestanda- och redundansskäl rekommenderar vi att ovan beskriven trenodsinstallation används.
MongoDB 3.4 kan laddas ner från https://www.mongodb.com/download-center#community
För en installation med replikering ska installationen uföras på samtliga datanoder och Arbiter-noden. Singelnodinstallationen installeras på samma sätt men konfigurationen skiljer sig något mellan nodtyperna.
6.2.1.1. Installation
Hämta MongoDB för Windows.
Kopiera msi-paketet till valfri katalog på alla datanoder samt arbiternoden.
Skapa en datakatalog för MongoDB (alla noder), exempelvis: C:\mongodb\data Skapa en katalog för MongoDBs loggfil (alla noder), exempelvis: C:\mongodb\log
Skapa en nyckelfils katalog för autentisering (gäller enbart i ett replicaset och görs på alla noder), exempelvis: C:\mongodb\keys Skapa en konfigurationsfil genom att först skapa ett temporärt text-dokument med namnet mongod_.cfg C:\mongodb\ i Skapa en cfg-fil. Öppna txt-filen mongod_.cfg och välj därefter att spara ned den tom i mappen C:\mongodb\
Välj "save as" i menyn file. Välj sedan "save as type" och "all" med filnamnet mongod.cfg
(högerklicka sedan på filen och verifiera i properties att filen nu är en cfg-fil. Den temporära txtfilen mongod_.cfg kan tas bort) Editera sedan filen och lägg till dom värden som visas nedan och spara följande information i C:\mongodb\mongod.cfg Kopiera mongod.cfg filen till övriga noder.
I en singelnodinstallation utelämnar man parametrarna och samt och Exemplet nedan gäller för ett
Obs! security keyFile replication replSetName.
replikaset i ett flernodssystem.
10.
11.
12.
1.
2.
3.
4.
5.
6.
systemLog:
destination: file logAppend: false
path: C:\mongodb\mongod.log
# Where and how to store data.
storage:
dbPath: C:\mongodb\data journal:
enabled: true
# network interfaces net:
port: 27017
# Replicaset security:
keyFile: C:\mongodb\keys\keyfile
replication:
replSetName: rs_sak
Kontrollera att sökvägarna är korrekta för ert system.
Lägg till sökvägen C:\Program Files\MongoDB\Server\3.4\bin i Windows PATH-variabel (kontrollera att sökvägen är korrekt för ert system).
Starta en kommandoprompt och installera MongoDB som en service genom att exekvera kommandot:
mongod --config C:\mongodb\mongod.cfg -install
6.2.1.2. Konfiguration av ett flernods-system med replikering:
I exemplet nedan använder vi två servrar för data, mongodb1.example.com och mongodb2.example.com, och en annan server som får agera Arbiter, mon godb0.example.com.
Starta nu MongoDB på datanoderna (ej Arbiter) genom att exekvera kommandot:
net start mongodb
Starta MongoDB-klienten via ett terminalfönster på noden (mongodb1.example.com) som ska vara Master och konfigurera replikeringen:
mongo
Nu ska MongoDB-klienten vara startad och en ny prompt vara synlig, i resten av instruktionen annoterad med >.
Initiera konfiguration av replikering genom att skriva:
> rs.initiate()
Visa replikeringsinformation genom att skriva:
> rs.conf()
Lägg till en slavnod genom att skriva:
> rs.add("mongodb2.example.com")
Logga in på Arbiter-noden och konfigurera den genom att editera C:\mongodb\mongod.cfg: Ändra portnummer:
port=30000
