2.5 Installation och administration (Windows)

2.5 Installation och administration (Windows) Publik Information Informationen på denna sida är publik. Dokumenthistorik Datum Version Namn Förändring 2014-04-10 0.1 Roger Öberg Dokument upprättat i confluence 2014-05-20 0.2 Olof Edström Uppdateringar, tagit bort terracotta. 2014-05-20 0.3 Anne-Charlotte Nordqvist Granskning och justeringar 2014-06-03 0.4 Olof Edström Uppdaterat 2014-06-17 1.0 Örjan Olofsson Lokala Säkerhetstjänster 2.5 2015-01-08 1.1 Magnus Lexhagen Uppdaterat med info om specifika MySQL-inställningar 2015-02-04 1.2 Magnus Lexhagen Uppdaterat "Uppstart av lokal Säkerhetstjänst på övriga noder" 2015-12-22 1.3 Örjan Olofsson Uppdaterat med nya adresser gällande PU-tjänsten 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 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. SITHS funktionscertifikat 3.5.1. Ytterligare funktionscertifikat 3.6. CSP - Cryptographic Service Provider 3.7. Kluster med Infinispan (Distributed in-memory cache) 4. Säkerhetstjänsters beroenden till externa system 4.1. HSA-WS 4.2. Revokeringskontroll av certifikat 4.3. Personuppgiftstjänsten - PU-tjänsten* 4.4. Nationell Spärrtjänst* 4.5. Nationell loggtjänst* 4.6. 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. Portöversikt 5.3.1. Applikationsserver 5.3.2. Databasserver

5.4. Adressöversikt gränssnitt 5.4.1. Webbgränssnitt port 8443 - admin-gui 5.4.2. Webbgränssnitt port 8445 - Autentiseringstjänsten 5.4.3. Webbtjänstegränssnitt för autentisering rika klienter - STS 5.4.4. Webbtjänstegränssnitt port 8080 - 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 databaserna 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.1.4. Skapa konto för Säkerhetstjänster 6.2.2. Indexering 6.2.3. Skapa databaser, index och användare för Säkerhetstjänster 6.2.4. Konfigurationsfil 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 av SingelServer 7.2.3. Installation på första noden i en fail-over lösning 7.2.4. Installation på andra noden i en fail-over lösning 7.2.5. Installation på övriga noder (nod3 osv...) i en fail-over lösning 7.3. Installation utan databasen MongoDB 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-WS 9.2. Konfigurera Personuppgiftstjänsten (PU-tjänsten) 9.3. Ta bort rootcertifikat för test vid en produktionssättning 9.4. Tilldela systemet de vårdgivare som ska hanteras 9.5. Konfiguration av CDC - Common Domain Cookie 9.6. Autentiseringstjänsten - IdP 9.6.1. Exportera Säkerhetstjänsters IdP/SP metadata 9.6.2. Inläsning av metadata 9.6.3. Extern Autentiseringstjänst 9.7. Spärrtjänsten 9.7.1. Block Local Service 2.0.4 9.7.2. Block Web Application 1.0.1 9.7.3. Block National Webservice Proxy for RIV 2.1 1.0.0 9.7.4. Block Common Webservice Proxy v.3 3.0.0 9.7.5. Block Common Webservice Proxy for National v.3 3.0.0 9.8. Konfiguration av PDL-loggning 9.8.1. Log Agent Impl 1.0.0 9.8.2. Log WS Proxy Impl 1.0.0 9.9. Loggtjänsten - hämtning av arkivloggar från den nationella loggtjänsten 9.9.1. Schemaläggning för automatisk hämtning av arkiv 9.9.2. Manuell hämtning av (äldre) arkiv ifrån den nationella loggtjänsten 9.10. Arkivsökning 10. Behörighet 10.1. RuleConfigGenerator 10.2. Behörighetsregler för användare 10.2.1. Behörighet för slutanvändare i Säkerhetstjänsters admin-gui 10.2.2. Skapa av behörighetsregler för användare 10.2.3. Läsa in behörighetsregler för användare 10.3. Behörigheter för vårdsystem eller tjänsteplattformen 10.3.1. Anpassa metadata för vårdsystem eller tjänsteplattformen 10.3.2. Ta reda på HSA-id 10.3.3. Skapa metadata för vårdsystem/tjänsteplattform 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.5. Felsökning 13. Test 14. Förvaltning och underhåll 14.1. Periodiskt underhåll 14.2. Övervakning 14.3. Uppgradering 15. Avinstallation 15.1. Avregistrera tjänster 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: 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 db doc example Beskrivning Konfigurationsfiler och databasskript (MySQL). All dokumentation Exempelkod för hur man kan ansluta en SP(webb) mot IdP:n (lokal autentiseringstjänst). Exempelkod i java och.net för autentisering utav rika klienter. install rules schema_wsdl Installationsskript och systemkomponenter. Behörighetsregler som ska modifieras och läsas in i systemet Tjänstekontrakten för lokala Säkerhetstjänster 1.2. Begrepp Begrepp Autentiseringstjänst Bundel CDC CRL Beskrivning Även kallad för IdP. Den tjänst som kontrollerar användarens kreditiv och utfärdar en SAML-biljett. Komponent till ett program Common Domain Cookie. En webbläsarkaka som lagrar historik från tidigare besökta IdP:er. 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 HPTA HSA High Availability. En tjänst som har hög tillgänglighet. En HSA-policytillämpning (HPTA) skrivs av varje direktansluten verksamhet och beskriver hur den enskilda organisationen uppfyller kraven i HSA-policy. 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 IdP Metadata Multicast NTP OCSP Webbservicetjänst mot HSA-katalogen som säkerhetstjänster använder sig av. 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. 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 Skickar kommunikation till en adress som en eller flera lyssnar på. Används av applikationsservrarna. Net Time Protocol. Används för synkronisering av tid mellan servrarna. 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/ PU-tjänst REST RIV RIV TA SAMBI SAML Personuppgiftstjänst Representational State Transfer Regelverk för Interoperabilitet inom Vård och omsorg. www.rivta.se 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. http://code.google.com/p/rivta/ SAML-profil för samverkan för Behörighet och Identitet inom hälsa, vård och omsorg. Beskriver hur egenskaper namnsätts i SAMLbiljetten. http://www.inera.se/infrastrukturtjanster/sakerhetstjanster /Autentiseringstjanst/Dokument-for-Autentiseringstjansten/ 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 Single installation SITHS SP Tjänsteplattformen (TP) 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. En installationsform där endast en nod används. SITHS är en nationell lösning för säker IT i hälso- och sjukvården. 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ä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/infrastrukturtjanster/tjansteplattform/

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 2008 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. MongoDB servern för bör vara flerkärniga och hur mycket RAM som krävs är beroende på hur mycket respektive vårdgivare loggar. Riktlinje är att 40 miljoner loggposter med dess index tar c:a 20 GB RAM. 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. 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.1.1. Delad diskyta för Säkerhetstjänster Den delade diskytan ( C:\share) för applikationsservrarna bör minst vara 100 GB. 2.1.2. Diskyta för MySQL Diskytan för MySQL ( <enhet>\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 (<enhet>\mongodb). 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 (<enhet>\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. 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.

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 7, JDK, 64 bitar, som finns att hämta på: http://www.oracle.com/technetwork/java/javase /downloads/index.html. Systemet är kvalitetssäkrat med JDK 7 update 55. 3.1.1. JCE - Java Cryptography Extension Det krävs även ett tillägg, http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.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.5.30 och säkerhetstjänsterna kräver att ni använder en version ur 5.5-serien. 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. 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 PDLloggar 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 två funktioner går dock att inaktivera ifall man skulle behöva en lokal installation utan tillgång till MongoDB (se Installationsanvisningar för MongoDB) Systemet är kvalitetssäkrat mot MongoDB-server 2.4.6. Därför rekommenderas att man installerar en version ur 2.4-serien. Hur databasen bör sättas upp för Säkerhetstjänster beskrivs i avsnitt Installationsanvisningar för MongoDB 3.4. Lastbalanserare En lastbalanserare som klarar HTTPS krävs för att köra lokala Säkerhetstjänster med skalskydd och/eller trafikdirigering. Anvisningar för lastbalanserare beskrivs inte i detta dokument. Lastbalansering till applikationsserver kan ske med round-robin då all sessionsdata (SSLsessioner) delas mellan applikationsservrarna. Hur övervakning av applikationsservern kan ske finns beskrivet i avsnitt Övervakning. Som ett minimum bör de externa HTTPS-portarna som används TCP-monitoreras, innan lastbalansering sker till applikationsservern. 3.5. SITHS funktionscertifikat Innan installation av lokala Säkerhetstjänster påbörjas måste ett SITHS funktionscertifikat för legitimering införskaffas, utfärdat för lokala Säkerhetstjänsters applikationsserver. Funktionscertifikatet används för att identifiera applikationsservern vid all sorts kommunikation. Funktionscertifikaten skall vara utfärdade till det värdnamn som skall användas för applikationsservern. Var god kontakta Inera för information kring SITHS funktionscertifikat [ Ref 1]. 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. Var god 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 är konfigurerat att använda multicast för att noderna ska kommunicera med varandra. Förvalt anges en multicastadress (239.0.10.1) men den lokala driftsorganisationen bör kontaktas för att bestämma vilken adress som ska användas.

4. Säkerhetstjänsters beroenden till externa system 4.1. HSA-WS 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 HSAkatalogen 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 bägge ärendena måste begäras av den/de som är HSA-ansvarig. Adresser till HSA-WS: Miljö Test Produktion Adress https://wstest.hsa.sjunet.org/svr-hsaws2/hsaws https://ws.hsa.sjunet.org/svr-hsaws2/hsaws 4.2. 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 SITHS CA v3 SITHS CA v4 http://crl1.siths.se/sithsrootcav1.crl http://crl2.siths.sjunet.org/sithsrootcav1.crl http://www.carelink.se/siths-ca/ca003.crl http://ocsp1.siths.se/ http://ocsp2.siths.sjunet.org/ http://sithsocsp.trust.telia.com/ Exempel på adresser till crl och ocsp (Test): Certifikat CRL-adress OCSP-adress SITHS_Type_1_CA_v1_PP SITHS CA TEST v3 SITHS CA TEST v4 http://crl1pp.siths.se/sithsrootcav1pp.crl http://crl2pp.siths.sjunet.org/sithsrootcav1pp. crl http://www.carelink.se/siths-ca/test-crl0003. crl http://ocsp1pp.siths.se/ http://ocsp2pp.siths.sjunet.org/ http://sithsocsp.preprod.trust.telia.com/

4.3. Personuppgiftstjänsten - PU-tjänsten* Personuppgiftstjänsten (PU-tjänsten) är en tjänst som innehåller personuppgifter. Lokala Säkerhetstjänster använder PU-tjänsten för att hämta patientens namn i användargränssnittet. Adresser till PU-tjänsten: Miljö Test Produktion Adress https://qa.esb.ntjp.sjunet.org/vp/lookupresidentforfullprofile/1 /rivtabp21 https://esb.ntjp.sjunet.org/vp/lookupresidentforfullprofile/1 /rivtabp21 *PU-tjänsten används enbart då någon av tjänsterna Samtycke, Patientrelation, Logg eller Spärr har installerats. 4.4. 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]. Obs! Replikering av spärrar ska fr.o.m. denna release 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. Adresser enbart för direktanslutning till Nationell spärrtjänst: (tjänsteplattformen ska användas fr.o.m. Lokala säkerhetsjänster 2.3) Miljö Adress Acceptanstest https://ws.acctest.sakerhetstjanst.sjunet.org/ Utvecklingstest https://ws.utvtest.sakerhetstjanst.sjunet.org/ Produktion https://ws.sakerhetstjanst.sjunet.org/ *Nationell Spärrtjänst används enbart om tjänsten Spärr installeras. 4.5. 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ö Acceptanstest Utvecklingstest Produktion Adress https://ws.acctest.sakerhetstjanst.sjunet.org/ https://ws.utvtest.sakerhetstjanst.sjunet.org/ https://ws.sakerhetstjanst.sjunet.org/ Tjänsterna Spärr, Samtycke och Patientrelation behöver logga sina PDL-loggar till en loggtjänst. Detta kan göras antingen till en lokal loggtjänst eller till 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, Patientrelation eller Logg installeras. 4.6. Tjänsteplattformen* Installeras Samtyckestjänsten och/eller Patientrelationstjä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, Samtycke och Patientrelation 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, Patientrelation 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 eventuellt 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 'failover' lösning. På applikationsservern installeras en gemensam plattform. På plattformen kan man välja vilka av de fristående tjänsterna Spärr, Samtycke, Patientrelation, 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å rekomendation ä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 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ärrreplikeringen 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 PU-tjänsten. HSA-WS 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, Patientrelation, 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 och Patientrelation 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 Patientrelation 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 PU-tjänsten. HSA-WS och Revokeringskontroll används av samtliga tjänster. Figur: Lokala Säkerhetstjänster med alla tjänster installerade. 5.3. Portöversikt

Denna tabell visar vilka portöppningar som krävs för att lokala Säkerhetstjänster skall fungera. Standardport avser föreslagen port, men dessa konfigureras manuellt vid installation. In betyder inkommande trafik och Ut utgående trafik. En användare som nyttjar lokala Säkerhetstjänster kommer att behöva nyttja portar 8443-8446 på applikationsservern. Externa system som ska använda tjänsten ansluter på port 8080. 5.3.1. Applikationsserver Server Standardport Beskrivning Applikationsserver 8443 (in) Extern HTTPS (envägs-ssl, generellt administrationsgränssnitt) 8444 (in) Extern HTTPS (tvåvägs-ssl, IdPwebbgränssnitt för identifiera användare med certifikat t.ex. SITHS) Används endast vid installation av lokal IdP 8445 (in) Extern HTTPS (envägs-ssl, IdPwebbgränssnitt med bla.val av identifikationsmetod och SSO) Används endast vid installation av lokal IdP 8446 (in) Extern HTTPS (envägs-ssl, IdPwebbgränssnitt för CDC-hantering) 8080 (in) Extern HTTPS (tvåvägs-ssl, WebServices, t.ex.checkblocks) 8004 (in) Java JMX-övervakning, behöver ej öppnas om inte övervakning används. Ska ej öppnas för extern åtkomst. 1111 (in) Telnet-port för systemkonsol. Ska ej öppnas för extern åtkomst. 443 (ut) HTTPS-anrop till HSA-WS. PU-tjänsten 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. 7080 (ut) Replikering till nationell spärrtjänst samt nationell hämtningstjänst för loggar. Används endast vid installation av lokal spärrtjänst och/eller lokal logg. 3306 (ut) Anrop till databasservern. 20000 (ut) Anrop till tjänsteplattformen 27017 (ut) Anrop till MongoDB-servern 5.3.2. Databasserver Databasserver Standarport 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 åtkomst utan enbart vara åtkomlig ifrån applikationsservrarna samt de andra MongoDB-noderna. 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 MongoDBnoderna. 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, Patientrelation och Logg är RIV TA 2.1 tjänster, se vidare http://www.rivta.se. 5.4.1. Webbgränssnitt port 8443 - admin-gui Alla adresser för webbgränssnitt har följande prefix: https://<hostnamn-applikationsserver>:8443/ Adress block blocklocal Beskrivning GUI för Spärr consentpdl patientrelation logstatusservice logreport logreportnational logreportarchive sysadmin spadmin accesscontrol idpadmin statistics commonarchive javamelody systemlog spinfo com.logica.se.bif.externalpages.web GUI för Samtycke GUI för Patientrelation GUI för Logg GUI för Loggrapport GUI för Arkivsökning GUI för Administration GUI för Autentisering GUI för Arkivering GUI för Övervakning GUI för Hjälp Samtyckes-dialog som externa tjänster kan nyttja. 5.4.2. Webbgränssnitt port 8445 - Autentiseringstjänsten Alla adresser för webbgränssnitt för IdP har följande prefix: https://<hostnamn-applikationsserver>:8445/ Adress Beskrivning

idp/saml/sso/{binding} idp/saml/slo/{binding} idp/saml Autentiseringstjänst (IdP) SSO Autentiseringstjänst (IdP) SLO Metadata IdP 5.4.3. Webbtjänstegränssnitt för autentisering rika klienter - STS Adresser för webbgränssnitt för STS har följande prefix: https://<hostnamn-applikationsserver> Adress :8080/ws/idp/sts :8445/ws/idp/sts Beskrivning Autentiseringstjänst (STS) 2 vägs-ssl Autentiseringstjänst (STS) 1 vägs-ssl (meddelandesignering) 5.4.4. Webbtjänstegränssnitt port 8080 - RIV TA-tjänster och REST-tjänst Alla adresser för webbtjänstegränssnitt har följande prefix: https://<hostnamn-applikationsserver>:8080/ Spärr version 1.0 RIV TA 2.0 services/canceltemporaryextendedrevokeresponderservice services/checkblocksresponderservice services/deleteextendedblockresponderservice services/getallblocksresponderservice services/getblocksforpatientresponderservice services/getextendedblocksforpatientresponderservice services/registerextendedblockresponderservice services/registertemporaryextendedrevokeresponderservice services/revokeextendedblockresponderservice Spärr version 2.0 RIV TA 2.1 blockinglocalservice/canceltemporaryextendedrevoke/2/rivtabp21 blockinglocalservice/checkblocks/2/rivtabp21 blockinglocalservice/deleteextendedblock/2/rivtabp21 blockinglocalservice/getblocks/2/rivtabp21 blockinglocalservice/getblocksforpatient/2/rivtabp21 blockinglocalservice/getextendedblocksforpatient/2/rivtabp21 blockinglocalservice/getpatientids/2/rivtabp21 blockinglocalservice/pingforconfiguration/1/rivtabp21 blockinglocalservice/registerextendedblock/2/rivtabp21 blockinglocalservice/registertemporaryextendedrevoke/2/rivtabp21 blockinglocalservice/revokeextendedblock/2/rivtabp21

blockinglocalservice/countblocks/2/rivtabp21 blockinglocalservice/getallblocksforcareproviderpage/2/rivtabp21 blockinglocalservice/copyblock/2/rivtabp21 blockinglocalservice/getcopiedblocks/2/rivtabp21 Spärr version 3.0 RIV TA 2.1 blockinglocalservice/checkblocks/3/rivtabp21 blockinglocalservice3/pingforconfiguration/1/rivtabp21 Samtycke version 1.0 RIV TA 2.1 consentservice/cancelextendedconsent/1/rivtabp21 consentservice/checkconsent/1/rivtabp21 consentservice/deleteextendedconsent/1/rivtabp21 consentservice/getconsentsforcareprovider/1/rivtabp21 consentservice/getconsentsforpatient/1/rivtabp21 consentservice/getextendedconsentsforpatient/1/rivtabp21 consentservice/pingforconfiguration/1/rivtabp21 consentservice/registerextendedconsent/1/rivtabp21 Patientrelation version 1 RIV TA 2.1 patientrelationservice/getpatientrelationsforcareprovider/1/rivtabp21 patientrelationservice/getpatientrelationsforpatient/1/rivtabp21 patientrelationservice/deleteextendedpatientrelation/1/rivtabp21 patientrelationservice/cancelextendedpatientrelation/1/rivtabp21 patientrelationservice/registerextendedpatientrelation/1/rivtabp21 patientrelationservice/getextendedpatientrelationsforpatient/1/rivtabp21 patientrelationservice/checkpatientrelation/1/rivtabp21 patientrelationservice/pingforconfiguration/1/rivtabp21 Logg version 1 RIV TA 2.1 logservice/storelog/1/rivtabp21 logservice/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 logqueryingservice/getlogreportsinfo/1/rivtabp21 logqueryingservice/pingforconfiguration/1/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/archives Dokumentet Hämta loggarkiv ä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.5/en/installing.html För utökad support och funktionalitet såsom online-backup finns samma version i Enterprise Edition-utförandinformation om detta finns här: http://www.mysql.com/products/enterprise. För att nyttja automatisk fail-over samt databasreplikering med MySQL som dock inte är kostnadsfri. Mer rekommenderas DRBD. Mer information om detta finns här: http://downloads.mysql.com/docs/mysql-ha-drbd-en.a4.pdf 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ättning Default-installation av MySQL använder teckenuppsättningen latin1. Detta måste ändras till UTF-8 för att svenska tecken ska användas korrekt. I katalogen <Lokal_sakerhetstjanst_<operativsystem>>/db/example finns ett exempel på en MySQL-konfigurationsfil 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. Bilden nedan visar de inställningar för UTF-8 som behöver ändras i filen my.cnf ( my.ini för Windows). Figur: Exempel på MySQL-konfiguration för UTF-8 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.6) ä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) # 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 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. Användarna behöver inte ha behörighet för att kunna skapa nya scheman. För att skapa scheman krävs en användare som har root-rättigheter, vilket skapas under installationen av MySQL. 1. Starta ett terminal-fönster mot databasservern och skriv följande kommando: mysql -u root -p Ange det lösenord som angavs vid installationen. 2. Skapa ny användare (i detta exempel är användarnamnet sak vilket rekommenderas, samt ett lösenord) genom att skriva följande rader, varje rad avslutas med Enter. 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; 3. Skapa ny användare (i detta exempel är användarnamnet sak vilket rekommenderas, samt ett lösenord) genom att skriva följande rader, varje rad avslutas med Enter. 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; 4. Avsluta MySQL prompten med kommando: quit 6.1.3. Skapa upp databaserna

När databasanvändare har skapats, ska databasscheman som lokala Säkerhetstjänster använder skapas upp. I installationspaketet (under strukturen Lokal_sakerhetstjanst_<version>/db/mysql/ ) ligger samtliga databasscheman som behöver sättas upp. Tabellen nedan visar vilka skript som tillhör de databasscheman som kommer sättas upp i nästkommande steg. Schema accesscontrol audit blkloc commission_service consent idp Skript accesscontrol.sql audit.sql blkloc.sql commission_service.sql consent.sql idp.sql idp_data.sql inftyp inftyp.sql inftyp_data.sql job logdb logreport quartz.sql logdb.sql logreport.sql logreport_data.sql logreportarchive logreportarchive.sql logreportarchive_data.sql logdlarchive metadata patientrelation sinkdb1 sp logdlarchive.sql metadata.sql patientrelation.sql sinkdb1.sql sp.sql Skapa upp databaserna: 1. 2. För över samtliga komponenter som finns i katalogen <Lokal_sakerhetstjanst_win>/db/mysql/ till er MySQL-server. Gå till katalogen dit filerna kopierats. Exempel: cd c:\tmp\mysql 3. Lista innehållet i katalogen. Utöver de sql-skript som listas i tabellen, ska skript-filen create_databases_windows.bat finnas. Editera create_databases_windows.bat scriptet och ändra alla sökvägar om ni installerat i en annan katalog. Exempel: "C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqladmin" -u% username% -p%password% -f DROP %prefix%%accesscontrol% 4. Skript-filen create_databases_windows.bat ska köras med följande parametrar: Användarnamn det användarnamn som används till databasmiljön med root-rättigheter. Lösenord det lösenord som används till databasmiljön.

Prefix ej obligatoriskt. Ett prefix till tabellnamnet, kan anges om så önskas. I exempelbilden nedan har vi angivit exemple_ som prefix. Exempel: create_databases_windows.bat root password example_ 5. När skriptet körs kommer en fråga, om databaserna ska skapas upp. Ange y för att fortsätta med exekveringen. Exempelbilden nedan visar hur det ser ut. Observera att det prefix vi angav (example_) står före respektive databasschema. Detta är det namn som databasschemat kommer att få. Figur: Skapa upp databaserna 6. Skriptet kan användas även om databaserna redan existerar, men ska skapas om. OBS! allt innehåll i databaserna kommer att försvinna. Om databaserna inte är skapade tidigare, kommer följande felmeddelande visas: 'DROP DATABASE 'example_database ; failed; '. Detta kan ignoreras. Se utskriften i exempelbilden nedan. Figur: Meddelande som visas om databaserna inte finns sedan tidigare. Om databaserna fanns sedan tidigare, visas istället följande meddelande: Database "example_accesscontrol" dropped. Figur: Meddelande som visas om databaserna fanns sedan tidigare.

7. Inget meddelande visas om att det gick bra att skapa databasen. Verifiera att databaserna har skapats, genom att logga in i mysqlprompten och exekvera kommandot: Exempel: show databases; 8. För att kontrollera om det finns tabeller i ett schema (t.ex. accesscontrol ;) ange kommandot: Exempel: use accesscontrol; show tables; Figur: Lista tabeller 9. En rekommendation av hur man sätter upp konfigureringen av MySQL:s konfigurationsfil my.cnf finns i installationspaketet under katalogen /db/example/my.cnf.example. 6.2. Installationsanvisningar för MongoDB Här följer ett exempel på installation av databasen MongoDB för Säkerhetstjänster 2.5. MongoDB har officiella installationsanvisningar här: http://docs.mongodb.org/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 Failover 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 Primary och vilken/vilka som ska fungera som Secondary. Arbitern kan med fördel installeras på applikationsservern. Säkerhetstjänster kommer att begära att få läsa ifrån en Secondary-nod. Detta ökar prestandan 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 laddas ner från http://www.mongodb.org/downloads som ett zip-arkiv. Det uppackade arkivet innehåller ingen installer utan bara filer som kan exekveras fristående från vilken katalog som helst utan beroenden till systemfiler. För en installation med replikering ska installationen gö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: 1. Hämta MongoDB för Windows-versionen. 2. Packa upp zip-filen till C:\.

3. Döp om den uppackade katalogen till mongodb så att vi nu har en MongoDB-installation i C:\mongodb 4. Skapa en datakatalog för MongoDB. Som standard är denna i Windows satt till C:\data\db. 5. Skapa en katalog för MongoDBs loggfil: C:\mongodb\log. 6. Skapa en konfigurationsfil genom att skapa ett text-dokument med namn mongod.cfg i C:\mongodb. 7. Lägg till och spara följande information i C:\mongodb\mongod.cfg. Obs! I en singelnodinstallation utelämnar man parametrarna replset och keyfile. dbpath= C:\data\db replset = rs_sak logpath= C:\mongodb\log\mongod.log port = 27017 # Uncomment when User and Keyfile has been created #auth = true #keyfile = C:\mongodb\keys\sak.key 8. Lägg till sökvägen C:\mongodb\bin i Windows PATH-variabel. 9. 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: 1. Starta nu MongoDB på datanoderna (ej Arbiter) genom att exekvera kommandot: net start mongodb 2. Starta MongoDB-klienten på en av datanoderna: mongo Nu ska MongoDB-klienten vara startad och en ny prompt vara synlig, i resten av instruktionen annoterad med >. 3. Initiera konfiguration av replikering genom att skriva: > rs.initiate() 4. Visa replikeringsinformation genom att skriva: > rs.conf() 5. Lägg till en slavnod genom att skriva: > rs.add("mongodb2.exempel.com") 6. Logga in på Arbiter-noden och konfigurera den genom att editera C:\mongodb\mongod.cfg: Ändra portnummer: port=30000

Begränsa storleken på den lokala databasen (oplog): oplogsize=1 7. Starta nu MongoDB på Arbiter-noden: net start mongodb 8. Gå tillbaka till Masternoden (Primary) och dess MongoDB-klient. Lägg till Arbiter-noden genom att i MongoDB-klienten skriva: > rs.addarb("mongodb0.exempel.com:30000")

9. Nu ska rs.status() visa att replikering är konfigurerat med en primary, en secondary och en arbiter. Figur: Exempel på rs.status() 10. Skapa ett Admin-konto i MongoDB-klienten: > db = db.getsiblingdb("admin") > db.adduser({ user: "root", pwd : "PASSWORD", roles: [ "useradminanydatabase", "readwriteanydatabase", "dbadminanydatabase"," clusteradmin" ] } )

Detta skapar en superanvändare med rätt att hantera alla databaser, användare och replikering. För beskrivning av de olika behörighetsrollerna se MongoDBs egen dokumentation. 11. Generera en keyfile (som används för autentisering mellan noderna). Det rekommenderas att OpenSSL ( http://www.openssl.org/ ) används för att skapa en keyfile med slumpmässig data: cd C:\mongodb\keys\ openssl rand -base64 753 > sak.key 12. 13. Aktivera autentisering och peka ut keyfile i alla noders konfigurationsfil. Editera filen C:\mongodb\mongod.cfg Ta bort # ( avkommentera) framför auth = true Ta bort # (avkommentera) framför keyfile = C:\mongodb\keys\sak.key Starta nu om ARBITER-, SECONDARY- och slutligen PRIMARY-noden: net stop mongodb net start mongodb 6.2.1.3. Konfiguration för singelnod-system 1. Starta nu MongoDB net start mongodb 2. Starta MongoDB-klienten i kommandoprompten: mongo Nu ska MongoDB-klienten vara startad och en ny prompt vara synlig, i resten av instruktionen annoterad med >. 3. Skapa ett Admin-konto i MongoDB-klienten: > db = db.getsiblingdb("admin") > db.adduser({ user: "root", pwd : "PASSWORD", roles: [ "useradminanydatabase", "readwriteanydatabase", "dbadminanydatabase"," clusteradmin" ] } ) 4. Aktivera autentisering genom att editera filen C:\mongodb\mongod.cfg Ta bort # (avkommentera) framför auth = true 5. Starta om MongoDB-servern net stop mongodb net start mongodb 6.2.1.4. Skapa konto för Säkerhetstjänster 1. Skapa ett Användarkonto. OBS! Detta kan uteslutas, om man använder skriptet, för att skapa de nödvändiga databaserna, som följer med installationen (se Skapa databaser, index och användare för Säkerhetstjänster).

6.3. I mongo-klienten > db = db.getsiblingdb("pdllog") > db.adduser({ user: "USER", pwd:"password",roles:[ "readwrite" ] } ) > db = db.getsiblingdb("auditlog") > db.adduser({ user: "USER", pwd:"password",roles:[ "readwrite" ] } ) > db = db.getsiblingdb("statistics") > db.adduser({ user: "USER", pwd:"password",roles:[ "readwrite" ] } ) > db = db.getsiblingdb("archivesearch") > db.adduser({ user: "USER", pwd:"password",roles:[ "readwrite" ] } ) 6.3.1. Indexering Att rätt index är inlagda i databasen är helt avgörande för prestandan. Logga in med en användare som har skrivrättigheter i databasen för PDLloggar och använd metoden ensureindex: Detta kan uteslutas ifall man använder skriptet för att skapa nödvändiga databaser, som följer med installationen (se Skapa databaser, index och användare för Säkerhetstjänster). 6.4. Indexering 1. Starta MongoDB-klienten mongo 2. I MongoDB-klienten, logga in med admin-kontot > use admin > db.auth("root", "PASSWORD") Notera prompten ändras nu till rs_sak:primary> i ett system med replikering och root-användaren har rättigheter att ändra i klustret. 3. Lägg till index:

rs_sak:primary> use pdllog rs_sak:primary> db.log.ensureindex({"cpid": 1,"act_date" : 1}) rs_sak:primary> db.log.ensureindex({"resources.pid": 1, "act_date" : 1}) rs_sak:primary> db.log.ensureindex({"cpid": 1, "resources.pid": 1, "act_date" : 1}) rs_sak:primary> db.log.ensureindex({"cpid": 1, "cuid": 1, "act_date" : 1}) rs_sak:primary> db.log.ensureindex({"cpid": 1, "uid": 1, "act_date" : 1}) rs_sak:primary> use statistics rs_sak:primary> db.log.ensureindex({ 'timestamp': 1 }) rs_sak:primary> db.log.ensureindex({ 'expireat': 1 }, { expireafterseconds: 0 }) rs_sak:primary> db.log.ensureindex({ 'consumerid': 1, 'eventtype': 1,'eventstatus': 1, 'timestamp': 1 }) 4. Verifiera att indexen finns: rs_sak_utv:primary> db.log.stats() Exempelutskrift: { "ns" : "pdllog.log", "count" : 13, "size" : 9344, "avgobjsize" : 718.7692307692307, "storagesize" : 57344, "numextents" : 2, "nindexes" : 6, "lastextentsize" : 49152, "paddingfactor" : 1, "systemflags" : 1, "userflags" : 0, "totalindexsize" : 49056, "indexsizes" : { "_id_" : 8176, "cpid_1_act_date_1" : 8176, "resources.pid_1_act_date_1" : 8176, "cpid_1_resources.pid_1_act_date_1" : 8176, "cpid_1_cuid_1_act_date_1" : 8176, "cpid_1_uid_1_act_date_1" : 8176 }, "ok" : 1 }

6.4.1. Skapa databaser, index och användare för Säkerhetstjänster Med installationen medföljer ett konfigurationsskript för att skapa nödvändiga databaser, index och användare för Säkerhetstjänster. Skriptet igger i installationskatalogen under <Lokal_sakerhetstjanst_windows>\db\mongodb\ med namnet mongo_db_setup.bat. För att kunna köra detta skript behöver MongoDB med klient, vara installerat enligt ovan. Det måste finnas ett användarkonto med administratörsrättigheter. I en replikerad miljö exekveras skriptet på noden som för tillfället är PRIMARY. Skriptet kräver användarnamn och lösenord för administratören. Användarnamn och lösenord för Säkerhetstjänster samt eventuellt ett prefix för tabellerna ( collections) för den specifika installationen. Det går också att välja att ta bort existerande databas eller bara tabellen ( collection). Argumentet dropdb raderar databasen och frigör diskutrymme. Utelämnande av detta argument kommer endast att ta bort eventuell tabell ( collection) vilket inte resulterar i frigörande av diskutrymme. Med växeln -h fås mer information om användningen av skriptet. mongo_db_setup.bat -h Användning: mongo_db_setup.bat root <root-pw> <sak-user> <sak-pw> [prefix][dropdb] Exempel 1: mongo_db_setup.bat root <root-pw> <sak-user> <sak-pw> Skapar (om) collections med index men utan tabellprefix. Skapar databaser och sak-användare om dessa inte redan existerar. Frigör inte något diskutrymme. Exempel 2: mongo_db_setup.bat root <root-pw> <sak-user> <sak-pw> proxy Skapar (om) collections med index och tabellprefix proxy_ Skapar databaser och sak-användare om de inte redan existerar. Frigör inte något diskutrymme. Exempel 3: mongo_db_setup.bat root <root-pw> <sak-user> <sak-pw> dropdb Skapar databaser, sak-användare och collections med index men utan tabellprefix OBS! Raderar all data i databaserna och frigör diskutrymme. Exempel 4: mongo_db_setup.bat root <root-pw> <sak-user> <sak-pw> proxy dropdb

Skapar databaser, sak-användare och collections med tabellprefix proxy_ OBS! Raderar all data i databaserna och frigör diskutrymme. 6.4.2. Konfigurationsfil Följande är ett exempel på hur en MongoDB-konfiguration kan se ut för datanoderna i ett replikeringskluster. Denna fil skapar vi ovan i mappen: C:\mongodb\mongod.cfg dbpath = C:\data\db replset = rs_sak logpath= C:\mongodb\log\mongod.log port = 27017 auth = true keyfile = C:\mongodb\keys\sak.key Notera att parametrarna replset och keyfile är specifika för en uppsättning med replikering i ett MongoDB-kluster. Parameter Defaultvärde Beskrivning dbpath C:\data\db Sökväg til MongoDBs datakatalog. Det är detta diskutrymme som måste möta utrymmeskraven för MongoDB. replset <none> Använd för att konfigurera replikering i ett kluster av MongoDB-noder. Ange ett namn på "replikeringsuppsättningen". Observera att alla noder måste ha samma värde på detta namn. logpath <none> Vill man att MongoDB ska skriva sina egna händelseloggar till fil anger man vilken fil med denna parameter. port 27017 Portnummer som MongoDB-server lyssnar efter anslutningar på. För Arbiter-noden sätter vi denna till 30000 i vårt exempel. auth false Måste sättas till true innan produktionssättning men efter det att man har skapat en superanvändare som har rätt att administrera databasen. keyfile <none> Sökväg till en fil med den autentiseringsnyckel som används för autentisering mellan de noder som ingår i ett replikeringskluster. Denna nyckel/fil måste vara identisk på alla noder. För en komplett lista med beskrivningar över konfiguration av MongoDB gå till MongoDBs hemsida.

7. Installation av applikationsserver Det är av prestandaskäl rekommenderat att tilldela lokala Säkerhetstjänsters applikationsserver en egen fysisk maskin. 7.1. Installera Java och JCE Installera Java och tillägget JCE Java Cryptography Extension, enligt avsnitt Java. 7.2. Installation av lokala säkerhetstjänster Innan installationen av lokala Säkerhetstjänster påbörjas, finns några operativspecifika uppgifter som måste utföras: Konfiguration av den lokala brandväggen på applikationsservern, se Appendix A - Exempel på konfiguration av den lokala brandväggen för windows servrarna. Delad diskyta för en fail-over lösning, se Appendix C - Krav på delad diskyta vid en fail-over installation När databasserver och applikationsserver är förberedda, kan lokala Säkerhetstjänster installeras på applikationsservern. Att installera lokala Säkerhetstjänster kan göras på två sätt: Singleserver lösning utan fail-over. Fail-over lösning, som vi rekommenderar för en produktionsmiljö. 7.2.1. Val av installationstyp Kopiera < Lokal säkerhetstjänst win> till valfri katalog på applikationsservern. Installationsprogrammet ligger under katalogen < Lokal säkerhetstjänst win>/install/. För installation av en singelserver gå till avsnitt Installation av SingelServer. Installation på första noden i en fail-over lösning gå till avsnitt Installation på första noden i en fail-over lösning. Installation på andra noden i en fail-over lösning gå till avsnitt Installation på andra noden i en fail-over lösning. Installation på övriga noder i en fail-over lösning gå till avsnitt Installation på övriga noder (nod3 osv...) i en fail-over lösning. 7.2.2. Installation av SingelServer Installationen kommer att kopiera in de filer som behövs för applikationsservern, samt registrera en service Lokal Säkerhetstjänst 2.5. Efter installationen är det rekommenderat att byta servicekonto, se Appendix B - Skapa separat servicekonto. Vid installation av en SingelServer används valet " First node installation". 1. Exekvera setup.exe, under katalogstrukturen \Sakerhetstjanst2.5\Lokal_sakerhetstjanst_win\install\ Klicka på knappen Next>. Välj var lokala Säkerhetsjänster ska installeras och klicka på knappen Next>. Klicka på knappen Next> (Confirm Installation) 2. Välj First node installation.

Figur: SingleServer Installation 3. Ange sökvägen till valfri katalog på servern genom att klicka på knappen Browse. Denna behöver i Singleserver-installationen inte vara delad. Parameter Defaultvärde Exempel Beskrivning Path to shared disk space -- c:\share Säkerhetstjänstens delade diskarea (som används av alla noder). Här läggs t.ex. konfigurationsfiler och binärer.

4. Ange sökvägen till Java JDK:n genom att klicka på knappen Browse. Det är möjligt att ändra de defaultportar som används för OSGi-konsolen och JMX. Se bilden nedan. Parameter Defaultvärde Exempel Beskrivning Path to Java JDK -- C:\Program Files\Java\jdk1.7.0_55 Katalog där java JDK finns installerat. OSGi console port 1111 Konsol-porten för att ansluta till OSGi. JMX Port 8004 Port för JMX (Java Management Extension) som bl.a. används för övervakning av systemet. T.ex. kan JConsole kan användas mot denna port för att se Säkerhetstjänsters övervakningsparametrar. 5. Fortsätt till Configuration. Figur: Configuration. 6. Klicka på pilen Log setup och fyll i fälten: Figur: Configuration - Log Setup Parameter Defaultvärde Exempel Beskrivning Log archive shared path C:\share\xlog_archive Sökväg till den delade area där komprimerade PDL-logg arkiv sparas. Kommer ej att användas om Loggtjänsten inte installeras. Log store proxy address -- sakerhetstjanster.inera.se Säkerhetstjänstens publika adress. Anges om lokal Loggtjänst inte installeras för att skicka PDL-loggar till Nationella Loggtjänsten.

7. Klicka på pilen Logreport setup och fyll i fälten: Figur: Configuration - Logreport Setup Parameter Defaultvärde Exempel Beskrivning Log Reports shared path C:\share\logreports Sökväg till en delad filarea där färdiga rapporter sparas. 8. Klicka på pilen Http(s) setup och fyll i fälten: De funktionscertifikat som ska användas beskrivs i avsnitt SITHS funktionscertifikat. Systemets portar beskrivs i avsnitt Portöversikt. Figur: Configuration Http(s) setup Parameter Defaultvärde Exempel Beskrivning Host address -- host.example.com Säkerhetstjänstens publika adress. Path to server Identity PKCS#12 certificate Identity PKCS#12 certificate password Path to server common domain Identity PKCS#12 certificate -- Sökvägen till där funktionscertifikat et för legitimering (certificate.p12- fil) för Säkerhetstjänsten är sparat. -- Lösenord till ovan funktionscertifikat. -- Sökväg till där funktionscertifikatet (legitimering) för common domain (cd-certificate.p12-fil) för Säkerhetstjänsten är sparat. (Om common domain inte används, dvs systemet ingår inte i en

federation, ange samma funktionscertifikat som ovan.) Identity PKCS#12 certificate password -- Lösenord till ovan funktionscertifikat. Ws port 8080 Port som Säkerhetstjänsten webbtjänster kommer att publiceras på. Https port, One-way SSL 8443 Https port för Säkerhetstjänstens Admin-GUI. Infinispan multicast address 239.0.10.1 Multicastadress för kommunikation mellan klusternoder. 9. Klicka på pilen Idp http(s) setup och fyll i fälten: Systemets portar beskrivs i avsnitt Portöversikt. De certifikat som ska användas finns i avs Figur: Configuration - Idp http(s) setup Parameter Defaultvärde Exempel Beskrivning Host address -- host.example.com IdP tjänstens publika adress. (vid behov kan man ha olika adresser till IdP-tjänsten och de övriga tjänsterna, vilket visas i bilden ovan. Men man kan även använda samma adress/certifikat som användes i steget innan.) Path to IdP Identity PKCS#12 certificate IdP Identity PKCS#12 certificate password -- Sökväg till där man sparat funktionscertifikatet,legitimering, (certificate.p12-fil) för IdPtjänsten. (vid behov kan man ha olika certifikat till IdP-tjänsten och de övriga tjänsterna, vilket visas i bilden ovan. Men man kan även använda samma adress/certifikat som användes i steget innan.) -- Lösenord till ovan funktionscertifikat.

Https port,two-way SSL 8444 IdP webbgränssnitt för identifiera /autentisera användare med SITHS-kort Https port,one-way SSL 8445 IdP Web gränssnitt som används av SSO-service. 10. Klicka på pilen Common Domain http(s) setup och fyll i fälten: Systemets portar beskrivs i avsnitt Portöversikt. Figur: Configuration Common Domain http(s) setup Parameter Defaultvärde Exempel Beskrivning Https port, One-way SSL 8446 Https port för Säkerhetstjänstens Webgränssnitt för CommonDomainCookie hantering Host address on Common Domain -- host.cd.example.com Säkerhetstjänsten publika Common Domain adress. (Om common domain inte används, dvs systemet ingår inte i en federation, ange "host.cd. example.com") Common Domain address -- cd.example.com Säkerhetstjänstens Common Domain adress. (Om common domain inte används, dvs systemet ingår inte i en federation, ange "cd.example. com") 11. Klicka på pilen HSA-WS setup och fyll i fälten: Se adresser som kan användas för test respektive produktion i avsnitt HSA-WS. Figur: Configuration HSA-WS Parameter Defaultvärde Exempel Beskrivning

Host address ws.hsa.sjunet.org Adress till HSA-WS tjänsten. Port 443 Port för HSA-WS tjänsten. Search base c=se Sökbas för HSA-WS. Context path /svr-hsaws2/hsaws Context path för HSA-WS. 12. Klicka på pilen MySQL Database setup och fyll i fälten: Host Address Port - till databas (mysql)-servern. User name - den användare som Säkerhetstjänster skall använda för att koppla upp sig mot databasen. Password - databasanvändarens lösenord. Se bilden nedan. Database name prefix - Namnen på databaserna kan ges ett prefix ifall så önskas. I annat fall lämnas detta fält tomt. (Vill man ha ett und erscore mellan prefix och namn så måste detta ingå) Figur: Configuration MySQL Parameter Defaultvärde Exempel Beskrivning Host address -- Adress till databas(mysql)- servern (db.example.com). Port 3306 Port till MySQL. User name sak Den användare som Säkerhetstjänstens skall använda för att koppla upp sig mot databasen. Password -- Lösenord för databasanvändaren. Database name prefix example_ Namnen på databaserna kan ges ett prefix ifall så önskas. I annat fall lämnas detta fält tomt. (Vill man ha ett underscore mellan prefix och namn så måste detta ingå). 13. Klicka på pilen Mongo Database setup och fyll i fälten:

Figur : Configuration MongoDB Parameter Defaultvärde Exempel Beskrivning Address replica server 1 -- mongo1.example.com Adress till MongoDB Primary server Address replica server 2 -- mongo2.example.com Adress till MongoDB Secondary server. (Vid singelnodinstallation ange samma adress som server 1). Port 27017 Port för MongoDB. Username sak Användare för MongoDB. Password -- Lösenord MongoDB. Database name PDL log pdllog MongoDB databas för PDL-loggar Database name archive search archivesearch MongoDB databas för arkivsökning Database name audit log auditlog MongoDB databas för systemloggar Database name statistics statistics MongoDB databas för statistikloggar Collection name prefix example_ I databaserna skapas Collections s om kan ges ett prefix ifall så

14. Klicka på knappen Continue för att starta installationen. önskas. I annat fall lämnas detta fält tomt. (Vill man ha ett underscore mellan prefix och namn så måste detta ingå). Days to keep data in database 92 Antal dagar som statistikloggarna sparas innan de automatiskt tas bort. Figur: Continue - First node installation 15. Systemet installeras och meddelar användaren med en bekräftelsedialog hur installationen gick. Klicka på knappen Close för att avsluta. 16. För uppstart av systemet, gå till avsnitt Uppstart av applikationsserver. 7.2.3. Installation på första noden i en fail-over lösning Denna installation kopierar in de filer som behövs för applikationsservern och kopierar de gemensamma filerna som används till den delade diskytan samt registrerar en tjänst: Lokal Säkerhetstjänst 2.5.

Efter installationen är det rekommenderat att byta servicekonto, se Appendix B - Skapa separat servicekonto. En förutsättning att man ska kunna installera en fail-over lösning är att det finns en delad diskyta, se Appendix C - Krav på delad diskyta vid en fail-over installation, som kan nås från samtliga noder. 1. Exekvera setup.exe under katalogstrukturen \Sakerhetstjanst2.5\Lokal_sakerhetstjanst_win\install\ Klicka på knappen Next>. Välj var lokala Säkerhetsjänster ska installeras och klicka på knappen Next>. Klicka på knappen Next>. (Confirm Installation) 2. Välj First node installation. 3. Peka ut sökväg till den delade diskytan Path to shared disk space. Notera: Viktigt att uppmärksamma är att Windows kan göra om den symboliska-länken till en UNC-sökväg, vilket man då manuellt får ändra i textfältet till den korrekta sökvägen, se figurerna nedan. Figur: Share-katalogen Resulterar i: Figur: Sökväg till delad diskyta Ändra manuellt till: Figur: Korrekt sökväg till delad diskyta 4. Ange sökvägen till Java JDK:n genom att klicka på knappen Browse. Det är möjligt att även ändra de defaultportar som används för OSGi-konsolen och JMX. Se bilden nedan.

5. 6. 7. 8. Figur: Sökväg till Java. Genomför konfigurationen enligt punkt 5-13 i avsnitt Installation av SingelServer Klicka på knappen Continue. Systemet installeras och meddelar användaren med en bekräftelsedialog hur installationen gick. Klicka på knappen Close för att avsluta installationen. 9. Därefter skall installationen göras på nod 2, se avsnitt Installation på andra noden i en fail-over lösning. 7.2.4. Installation på andra noden i en fail-over lösning Denna installation görs på den andra noden och kommer att registrera en tjänst: Lokal Säkerhetstjänst 2.5. Efter installationen är det rekommenderat att byta servicekonto, se Appendix B - Skapa separat servicekonto. 1. Exekvera setup.exe under katalogstrukturen \Sakerhetstjanst2.5\Lokal_sakerhetstjanst_win\install\ Klicka på knappen Next>. Välj var lokala Säkerhetsjänster ska installeras och klicka på knappen Next>. Klicka på knappen Next>. (Confirm Installation) 2. Välj Other node installation.

3. Ange sökväg till konfigirationsfilen Node1InstallationProperties.xml som skapades vid installationen på den första noden och ligger på den delade diskytan. (ex. C:\share\Sakerhetstjanst<version>\Node1InstallationProperties.xml). 4. 5. Notera: Viktigt att uppmärksamma är att Windows kan göra om den symboliska-länken till en UNC-sökväg, vilket man då manuellt får ändra i textfältet till den korrekta sökvägen, se nedan. Klicka på knappen OK. Klicka på knappen Continue i GUI-fönstret. Systemet installeras och meddelar användaren med en bekräftelsedialog hur installationen gick. 6. Klicka på knappen Close för att avsluta installationen. Notera: För installation på övriga noder, se avsnitt Installation på övriga noder (nod3 osv...) i en fail-over lösning. 7.2.5. Installation på övriga noder (nod3 osv...) i en fail-over lösning Denna installation görs på övriga noder och kommer att registrera en tjänst: Lokal Säkerhetstjänst 2.5. Efter installationen är det rekommenderat att byta servicekonto, se Appendix B - Skapa separat servicekonto. 1. Följ anvisningarna i Installation på andra noden i en fail-over lösning. 7.3. Installation utan databasen MongoDB

NOTERA: MongoDB är ett krav för lokal loggtjänst. Följande konfiguration kommer att inaktivera insamlandet av statistik för autentiseringshändelser samt ta bort MongoDB som reservkälla för loggning av systemhändelser. Öppna filen com.logica.se.iac.statistics.db.mongo.impl.xml för editering i ett program lämpligt för xml. Ändra värdet på attributet med nyckelnamn enabled till false. C:\share\Sakerhetstjanst2.5\local\config\com.logica.se.iac.statistics.db.mongo.impl.xml Gör likadant med filen com.logica.se.iac.logging.mongo.xml C:\share\Sakerhetstjanst2.5\local\config\com.logica.se.iac.logging.mongo.xml

8. Uppstart av applikationsserver NOTERA: Om installation av singelserver valdes, fortsätt till avsnitt Uppstart av lokal säkerhetstjänst på nod 1. När man startar Säkerhetstjänster första gången efter installation måste man, på varje nod, installera de komponenter man har behov av. Det görs genom OSGi-konsolen som med standardkonfiguration nås genom telnet på port 1111. Det finns en uppstartslogg < enhet\program Files\Inera\Lokal Sakerhetstjanst<version>\sakerhetstjansten\log\outputlog_service.txt>. Där loggas det som sker under uppstarten av systemet. En telnet-klient behövs under installationen för att koppla upp sig mot Säkerhetstjänsters OSGI-konsol där Säkerhetstjänster konfigureras. 8.1. Uppstart av lokal säkerhetstjänst på nod 1 För att starta systemet, gå in i verktyget Server Manager och Services och gå till lokala Säkerhetstjänsters tjänst (Lokal Säkerhetstjänst 2.5) och klicka på Start. 1. Logga in till systemkonsolen: telnet localhost 1111 NOTERA: Det kan ta ca en minut innan servern har startat och att det går att logga in till systemkonsolen. NOTERA: Om en annan port än defaultport 1111 har angivits i installationen, anger man denna istället. 2. Verifiera i systemkonsolen att systembundeln med id 0 har startat, dvs. har status ACTIVE, genom att exekvera kommandot: osgi> ss Exempel: Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_1.0.3 Förklaring av fältet State i ovan utskrift: INSTALLED - Bundeln är installerad i systemet men är inte startad. STARTED - Bundeln är startad men ännu inte aktiv. ACTIVE - Bundeln är startad och aktiv. RESOLVED - Bundeln är stoppad. 3. Lista de komponenter som kan installeras med kommandot: osgi> pkg list Exempel: Id Name Description 1 Local server Includes all below services 2 IDP local component Bundles for IDP 3 Patientrelation local component Bundles for patientrelation installation 4 Consent local component Bundles for consent installation 5 Block local component Bundles for local block installation

6 Patient/Consent dialog Bundles for Patient/Consent dialog 7 Log local component Bundles for local log installation 4. Välj de komponenter som skall installeras: Local server - Alla lokala tjänster. IDP local component - Autentiseringstjänst. Patientrelation local component - Patientrelation. Consent local component - Samtycke. Block local component - Spärr. Patient/Consent dialog - Patient/samtyckesdialog. Log local component - Loggtjänst. Det är möjligt att installera enbart en av tjänsterna, t.ex. Spärr. Dock kräver tjänsterna Spärr, Samtycke och Patientrelation tillgång till en intern/extern autentiseringstjänst (IdP) för att en användare ska kunna logga in och komma åt webbtjänsterna. Exempel: För att installera alla tjänster (komponent 1 i exemplet ovan): osgi> pkg install -package 1 För att installera lokal spärrtjänst (komponent 4 i exemplet ovan): osgi> pkg install -package 4 För att installera lokal loggtjänst med IdP: osgi> pkg install -package 2,7 Observera att de paket-id som anges i exemplet ovan kan variera. Hämta aktuellt paket-id med kommandot: pkg list. 5. Starta det installerade komponenterna med kommandot: osgi> pkg start Vänta ett tag på att bundlarna startar upp, ca 2 min. 6. Verifiera att samtliga bundlar är uppstartade med kommandot dep. (Kommandot listar alla bundlar som ännu inte är startade.) Exekvera kommandot: osgi> dep Utskriftsexempel: osgi> dep id Bundle State Unsatisfied dependencies

Spring dependencies osgi> Listas inte någon bundel här, är samtliga bundlar startade. I annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel. Om någon bundel inte startar igång, testa att starta om säkerhetstjänster. Kvarstår problemet måste felsökning påbörjas: 1. Kontrollera systemloggen efter fel. osgi> audit search -level error 2. Kontrollera även systemloggen efter fel. Systemloggen skapas i den lokala katalogen där Säkerhetstjänster körs och dit skrivs loggar innan systemet är helt startat och senare i vissa fall om det är loggning till System.out.../log/outputlog_service.txt 7. Verifiera att alla beroenden är uppfyllda med kommandot: osgi> context state Exempel: osgi> context state Id Context State osgi> State Information Listas inte någon bundel här, är alla beroenden mellan bundlarna uppfyllda. I annat fall upprepa kommandot i intervaller, tills kommandot inte listar någon bundel. Kan ta ett antal minuter vid uppstart. Om context state visar någon eller några bundlar så kan det bero på följande: 1. Om någon av tjänsterna Samtycke, Patientrelation eller Spärr installeras, men inte lokal loggtjänst, behöver tjänsterna konfigureras för att använda en extern loggtjänst. Följande fel visas vid installation av enbart Spärr och IdP. Figur: Utskriftsexempel 1, Context state, Unresolved dependencies. 2. Spärr (Block) saknar beroenden, i detta fall saknas en lokalt installerad loggtjänst som behöver konfigureras manuellt med adressen till en extern loggtjänst. För att göra detta, editera konfigurationsfilen i installationskatalogen (/share för standardkatalogen i Linux, c:\share för standardkatalogen i Windows) <share>/sakerhetstjanst<version>/local/config/com.logica. se.bif.log.agent.impl.1.0.0.xml. Ändra värdet för logstoreservice från Service till Proxy. Editera sedan konfigurationsfilen com.logica.se.bif.log.ws.proxyimpl.1.0.0.xml i samma katalog. Ange adress ( hostname) och portnummer ( portnumber) till den externa loggtjänsten. 3. Uppdatera bundlen: com.logica.se.bif.log.agent.impl.1.0.0 i systemkonsolen med kommandot:

osgi> update 305 (siffran till vänster om com.logica.se.bif.log.agent.impl.1.0.0 i bilden ovan). 4. Verifiera beroenden igen med kommandot: osgi> context state Figur: Utskriftsexempel 2, Context state, Unresolved dependencies 5. Bundeln com.logica.se.bif.ping.ws.factory publicerar ping-tjänsten för alla tjänster, varav Logg, Samtycke (consent) och Patientrelationtjänsten visas ovan. Eftersom dessa tjänster inte installerades måste konfigurationen uppdateras. Gå till installationskatalogen (/share för standardkatalogen i Linux, c:\share för standardkatalogen i Windows) <share>/sakerhetst janst<version>/local/config/com.logica.se.bif.ping.ws.factory.1.0.0/ och ta bort konfigurationsfilerna för de tjänster som inte installerats: Tjänst Spärr Patientrelation Logg (Loggrapport) Samtycke Idp Konfigurationsfil blocklocal.xml blocklocalv3.xml patientrelation.xml log.xml logreport.xml consent.xml commissionservice.xml Om enbart Samtycke installeras, ta då bort filerna för Spärr och Patientrelation osv. 6. Verifiera att alla beroenden är uppfyllda med kommandot: osgi> context state Exempel: osgi> context state Id Context State osgi> State Information 8. Avsluta systemkonsolen med kommandot: osgi> disconnect

8.2. Anslut till webbgränssnitt Kontrollera att det går att ansluta till webbgränssnittet m.h.a en webbläsare på den första noden. 1. 2. 3. Om serverns adress inte finns i DNS-servern måste den lokala host-filen temporärt uppdateras på den klientdator som används för att ansluta till webbgränssnittet. Lägg till följande i lokala host-filen: <server ip-adress nod1> nod1 Verifiera att det går att ansluta till webbgränssnittet via en webbläsare ex. https://[servernamn]:[8443]/spadmin Om frågan, att servern inte har ett giligt certifikat visas, välj continue to this website. Figur: Säkerhetstjänsters admin-gui 8.3. Uppstart av lokal Säkerhetstjänst på övriga noder För att starta systemet, gå in i verktyget Server Manager och Services och gå till lokala Säkerhetstjänsters tjänst (Lokal Säkerhetstjänst 2.5) och klicka på Start. 1. 2. Vänta en stund på att systemet startar. Logga in till OSGi-konsolen: telnet localhost 1111 3. Installera samma komponenter som på första noden (-package 1 i exemplet nedan) osgi> pkg install -package 1 4. Starta det installerade komponenterna med kommandot pkg start. osgi> pkg start

5. Verifiera efter ett tag att samtliga bundlar är uppstartade med kommandot dep. (Kommandot listar alla bundlar som inte har startat). osgi> dep Exempel: osgi> dep id Bundle State Unsatisfied dependencies Spring dependencies osgi> Listas inte någon bundel här är samtliga bundlar startade. I annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel. Om någon bundel inte startar, testa att starta om Säkerhetstjänster. Kvarstår problemet måste felsökning påbörjas. 6. Verifiera att alla beroenden är uppfyllda med kommandot: osgi> context state Exempel: osgi> context state Id Context State osgi> State Information Listas inte någon bundel här, är samtliga bundlar startade. I annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel. 7. När nu alla noder är installerade och uppstartade kan det vara bra att kontrollera att de har anslutit till infinispan-klustret. Man kan kontrollera att samtliga noder ingår i infinispan-klustret med ett kommando i OSGi-konsolen. Detta kommando bör verifieras på varje nod för att säkerställa att noderna känner till varandra i klustret. Utför på varje installerad nod i klustret: 1. Gå in i systemkonsolen med: telnet localhost 1111 2. Slå kommando: sys mon filter infinispan 3. Konsolen kommer nu lista vilka noder som ingår i klustret. Se exempelbilden nedan: Figur: bilden ger exempel på hur utskriften kan se ut när man ser över klustret i OSGi-konsolen. De noder här som ingår i

klustret är "perfnod1-33209, perfnod2-4270, perfnod3-14979". 4. Om samtliga noder listas, har klustret satts upp som det ska. I annat fall: 1. Stoppa Säkerhetstjänster på den nod som inte var listad i konsolen. /etc/init.d/sak_server stop 2. Öppna sak_server med en lämplig text-editor. vim /etc/init.d/sak_server 3. Sök er fram till # Common java arguments. Kontrollera att infinispan multicast ip-adressen finns sparad. Se exempelbilden nedan för hur det kan se ut: Figur: sak_server med infinispan multicast adressen tillagd Kom ihåg att samma infinispan multicast ip-adress ska användas för samtliga noder som ingår i klustret. Default är 239.0.10.1 4. Efter verifieringen: starta sak_server igen. /etc/init.d/sak_server start 5. Uppstarten kan ta en stund. Utför steg 1-4 efter ni har väntat i ca 5 minuter. 8. Avsluta systemkonsolen med kommandot: osgi> disconnect 9. Verifiera att det går att ansluta till webbgränssnittet via en webbläsare ex: https://[servernamn]:[8443]/spadmin

9. Systemkonfiguration Efter att den lokala Säkerhetstjänsten har installerats och startats, ska en systemkonfiguration genomföras. Säkerhetstjänster använder sig av två filter: Autentiseringsfilter - Filtret kräver att användaren ska autentisera sig för att få åtkomst till Säkerhetstjänster. Behörighetsfilter - Filtret styr vilken behörighet användaren har i Säkerhetstjänster. Det kan exempelvis innebära att en användare som har rollen som spärradministratör endast får hantera spärrar i systemet. Filtren ska vara avstängda under pågående systemkonfiguration. Verifiera att de är avslagna enligt: 1. Logga in till systemkonsolen med: telnet localhost 1111 2. Inaktivera autentiseringsfiltret med kommando: osgi> sys spfilter -off 3. Inaktivera behörighetsfiltret med kommando: osgi> sys authz -off 4. Avsluta systemkonsolen med kommando: osgi> disconnect När konfigurationen av systemet är genomförd ska autentiseringsfiltret och behörighetsfiltret aktiveras. Anslut till Säkerhetstjänsters webbgränssnitt med den host-adress som ni angav i installationsskedet: https://[servernamn]:[8443]/spadmin och genomför konfiguration enligt nedan: 9.1. Konfigurera HSA-WS Vid installationen anges adressen till HSA-WS. Om fel adress angavs eller om adressen måste ändras går det att göra i menyn Autentisering -> E genskapskälla. Ange adress och/eller ny sökbas och klicka på knappen Spara. Timeout och cachetimeout ska normal inte ändras. Timeout anger hur länge tjänsten skall vänta på svar från HSA-tjänsten. Cachetimeout anger hur länge i millisekunder ett hämtat värde kan återanvändas, utan att åter fråga HSA-tjänsten.

Figur: Konfiguration av HSA-WS 9.2. Konfigurera Personuppgiftstjänsten (PU-tjänsten) PU-tjänsten behöver endast konfigureras om någon av följande tjänster är installerade: Samtycke, Patientrelation eller Spärr. Konfiguration för PU-tjänsten görs i menyn Administration -> Generell Konfiguration. Välj sedan konfiguration Resident Information Lookup Service Impl 1.0.1. Se exempelbilden nedan. Figur: Konfiguration av PU-tjänsten 9.3. Ta bort rootcertifikat för test vid en produktionssättning I och med produktionssättning av systemet bör alla rootcertifikat som använts för test, tas bort ur listan med konfigurerade certifikatsutfärdare. Säkerställ först att inga ytterligare tester skall genomföras i systemet innan certifikaten tas bort. Detta görs i två steg, först avmarkerar man i förtroendekällan att rootcertifikaten används, därefter tas rootcertifkaten bort. 1. 2. Klicka på menyn Administration -> Webbserver. Klicka på knappen Ändra för förtroendekällan "Logica No Check Trust Service".

3. Figur: Ändra rootcertifikat för förtroendekälla Avmarkera de rootcerfikat som ska tas bort och klicka på knappen Spara. Figur: Ändra förtroendekälla 4. Gör motsvarande (punkt 2-3) för förtroendekällan " Logica Trust Service". 5. Klicka på menyn Administration -> Webbserver. 6. Klicka på soptunnan som tillhör den certifikatutfärdaren ni vill ta bort. Se bilden nedan: Figur: Ta bort certifikatsutfärdare Om man får felmeddelandet En eller flera förtroendekällor använder denna certifikatsutfärdare...", används rootcertifikarten av någon webbserver. Upprepa punkt 2-4 för berörda förtroendekällor för att ta bort användningen innan rootcertifikatet kan tas bort. 9.4. Tilldela systemet de vårdgivare som ska hanteras För att lokala säkerhetstjänster ska veta vilken/vilka vårdgivare som får hanteras av systemet, måste dessa konfigureras in. Detta görs genom att ange systemegenskaper. 1. Klicka på menyn Administration -> SP SAML. 2. Lägg till systemegenskaper för vårdgivare: 1. Bläddra i listan Egenskap. 2. Välj urn:sambi:names:attribute:careproviderhsaid. 3. Skriv in HSA-id för vårdgivaren i fältet Värde. 4. Klicka på knappen Lägg till. Upprepa steg a-d för samtliga vårdgivare som ska läggas till. 3. Dessutom behöver systemet tilldelas systemerollen Internal för att interna tjänster ska vara behörig att göra anrop: 1. Bläddra i listan Egenskap. 2. Välj urn:sambi:names:attribute:systemrole. 3. Skriv in Internal i fältet Värde. 4. Klicka på knappen Lägg till. Figur: Exempel på konfiguration av systemegenskaper. (Vårdgivarid i bilden är fiktiva) 9.5. Konfiguration av CDC - Common Domain Cookie CDC är en typ av webbkaka som används för hålla rätt på vilken IdP som medarbetaren använde senast, för att på så vis få SingleSignOn då det finns flera IdP:er. Finns det bara en IdP ska nedanstående inställningar vara avaktiverade. Konfiguration av CDC görs under menyerna Administration -> SP SAML och Autentisering -> IdP SAML.

Det går att aktivera/inaktivera att CDC används. Detta görs genom att bocka i eller ur kryssrutorna för SP och IdP CDC. Se bilderna nedan. 1. Bocka i kryssrutan om SP ska läsa från CDC. Se bilden nedan. Figur: SP CDC inställningar 2. Bocka i kryssrutan om IdP ska skriva till CDC. Se bilden nedan. Figur: IdP CDC inställningar 9.6. Autentiseringstjänsten - IdP Säkerhetstjänster består av två huvuddelar, de tjänster SP:ar (såsom Spärr och Logg) som installeras och Autentiseringstjänsten (IdP). Installeras IdP:n behöver man i där konfigurera upp vilka SP:ar som får använda IdP:n. På motsvarande sätt måste man i SP-delen konfigurera upp vilka IdP:er som denna kan använda. Denna konfiguration görs med hjälp av SAML-metadatafiler: SP-metadata beskriver hur SP:n fungerar och läses in i IdP:n. IdP-metadata beskriver hur IdP:n kan användas och denna läser man in i SP:n. Om lokal autentiseringstjänst och en av de lokala tjänsterna (såsom t ex Spärr) installerats, behöver man göra följande: 9.6.1. Exportera Säkerhetstjänsters IdP/SP metadata 1. 2. 3. 4. 5. 6. Öppna menyn Autentisering -> IdP SAML. Fyll i formuläret IdP Metadata med aktuella kontaktuppgifter. Dessa kommer att specificeras i metadatafilen. Uppdatera informationen genom att klicka på knappen Spara. Exportera IdP metadata med knappen Exportera. Filen kommer läsas in i ett senare skede, spara den på ett lämpligt ställe. Öppna nu menyn Administration -> SP SAML. Utför motsvarande procedur som tidigare (steg 2-4) för SP metadata. 9.6.2. Inläsning av metadata IdP och SP-metadata måste läsas in till Säkerhetstjänster. Denna import av metadata sker i Säkerhetstjänsters webbgränssnitt. Importera metadata till Säkerhetstjänster: 1. 2. 3. Öppna menyn Administration -> SAML Metadata. Klicka på Välj fil. Välj en av era metadata-filer (dvs. IdP/SP metadata). Klicka på Importera.

4. Den importerade metadata-filen ska nu visas i tabellen Importerade IdP Metadata Entiteter och/eller i tabellen Importerade SP Metadata Entiteter. Figur: Exempel på sidan SAML Metadata 9.6.3. Extern Autentiseringstjänst Om ingen lokal autentiseringstjänst installerades, måste systemet ansluta sig till en extern autentiseringstjänst (IdP) för att användare ska kunna logga in i systemet. Detta görs genom att exportera SP metadata, enligt ovan, skicka denna XML-fil till organisationen som tillhandahåller autentiseringstjänsten. Metadata-filen måste importeras i deras system samt att dess (autentiseringstjänstens) IdP-metadata-fil måste importeras i det lokala systemet (korsvis exportering och inläsning). 9.7. Spärrtjänsten Spärr kan konfigureras upp att antingen gå mot tjänsteplattformen eller köras lokalt. Exempelbilderna nedan visar hur konfigurationen ser ut mot tjänsteplattformen. Hänvisade host-namn och portar för konfigurationerna som beskrivs nedan ska konfigureras mot tjänsteplattformen. Samtliga konfigurationer av tjänsten ligger i menyn Administration -> Generell Konfiguration. En lokal uppsättning av Spärr skall normalt replikera sina lokala spärrar till den nationella Spärrtjänsten för att nationella e-tjänster, såsom t.ex. Nationell Patientöversikt (NPÖ), skall få ett så komplett spärrunderlag som möjligt. 9.7.1. Block Local Service 2.0.4 Se exempelbilden nedan för konfigurationen. 1. Öppna konfigurationen Block Local Service 2.0.4.

2. National block interface ska vara satt till Proxy. 3. Synkronisering till nationell Spärrtjänst aktiveras om Replicate to/from national node är ikryssat. Även valen för Download blocks from national node och Send local blocks to national node ska vara ikryssade. Det går att välja vilken typ av replikering som skall ske med dessa val, men rekommenderat är att båda skall vara ikryssade. 4. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur: Block Local Service 9.7.2. Block Web Application 1.0.1 Se exempelbilden nedan för konfigurationen. 1. Öppna konfigurationen för Block Web Application 1.0.1. 2. Konfigurationen ska vara inställd efter bilden nedan, för att gå mot tjänsteplattformen. 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur: Block Web Application 9.7.3. Block National Webservice Proxy for RIV 2.1 1.0.0 Se exempelbilden nedan för konfigurationen. 1. Öppna konfigurationen Block National Webservice Proxy for RIV 2.1 1.0.0. 2. Ange Context path for National Webservice, Host name och Port number. 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka.

Figur: Block National Webservice Proxy for RIV 2.1 9.7.4. Block Common Webservice Proxy v.3 3.0.0 Se exempelbilden nedan för konfigurationen. 1. 2. 3. Öppna konfigurationen Block Common Webservice Proxy v.3 3.0.0. Ange Context path for Local Webservice, Host name och Port number. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur: Block Common Webservice Proxy 9.7.5. Block Common Webservice Proxy for National v.3 3.0.0 Se exempelbilden nedan för konfigurationen. 1. 2. 3. Öppna konfigurationen Block Common Webservice Proxy for National v.3 3.0.0. Ange Context path for National Webservice, Host name och Port number. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka.

Figur: Block Common Webservice Proxy for National 9.8. Konfiguration av PDL-loggning PDL-loggar kan styras att antingen gå mot lokalt installerad loggtjänst eller så kan tjänsterna Lokal spärr, Samtycke och Patientrelation logga dessa händelser till den nationella loggtjänsten. För att använda en extern loggtjänst konfigureras modulen Log Agent Impl till att använda en Proxy samt ange adress och portnummer till den externa loggtjänsten i modulen Log WS Proxy Impl. För att använda den lokala loggtjänsten konfigureras modulen Log Agent Impl till att använda Service och ingen konfiguration behöver göras i modulen Log WS Proxy Impl. Exempelbilderna nedan visar hur konfigurationen styr PDL-loggar att lagras på en den nationella loggtjänsten. Samtliga konfigurationer av tjänsten Logg ligger i menyn Administration -> Generell Konfiguration. För att anslutningen till den nationella loggtjänsten ska fungera måste förvaltningsorganisationen för nationella säkerhetstjänster kontaktas för att öppna upp access till tjänsten. Kontakta Ineras förvaltning i god tid före driftstart [Ref 1]. 9.8.1. Log Agent Impl 1.0.0 1. Öppna konfigurationen Log Agent Impl 1.0.0. 1. Om en extern loggtjänst ska användas, sätt Log store service till Proxy. 2. Om den lokala loggtjänsten ska användas, sätt Log store service till Service. 2. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur: Log Agent Impl

9.8.2. Log WS Proxy Impl 1.0.0 OBS! Denna konfiguration behöver endast göras ifall man använder en extern loggtjänst. 1. Öppna konfigurationen Log WS Proxy Impl 1.0.0. 2. Ange Context Path, Host name och Port number. 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur: Log WS Proxy Impl 9.9. Loggtjänsten - hämtning av arkivloggar från den nationella loggtjänsten Om lokala loggtjänsten installerats, kan den egna vårdgivarens loggar hämtas från den nationella loggtjänsten via dess hämtningstjänst. För att den lokala installationen av Säkerhetstjänster ska kunna hämta arkiv från nationella Säkerhetstjänster måste förvaltningsorganisationen för nationella säkerhetstjänster kontaktas för att öppna upp access till tjänsten. Kontakta Ineras förvaltning i god tid före driftstart [ Ref 1]. För att rätt behörighet ska ges, krävs det att det lokala säkerhetstjänsters SP-metadata bifogas. Se avsnitt Exportera Säkerhetstjänsters IdP/SP metadata 9.9.1. Schemaläggning för automatisk hämtning av arkiv När schemaläggaren är aktiv och ingen information om föregående arkivnedladdningar existerar, hämtar den gårdagens arkivloggar. Om tidigare nerladdningar av arkivloggar har lyckats (dvs. har status Done ) så utgår schemaläggaren från den senaste arkivhämtningen nästkommande dag. Nedan följer två möjliga scenarion över hur detta kan se ut. Scenario 1 - Ny installation och inga loggarkiv har hämtats tidigare. Resultat: Schemaläggaren hämtar gårdagens arkivloggar. Scenario 2 Loggarkiv har hämtats tidigare och lokala Säkerhetstjänster har legat nere 3 dagar innan den har gått upp igen. Resultat: Schemaläggaren hämtar arkivloggar för 3 dagar tillbaka. 1. Klicka på menyn Administration -> Generell Konfiguration. 2. Öppna konfigurationen Log Download Archive 3. I tabellen nedan, konfigurera följande: 1. Careproviders that s supported Vilka vårdgivare den lokala säkerhetstjänsten ska ladda ner arkiv för. Lägg till flera med hjälp av + -tecknet.. 2. Context Path Sökväg till tjänsten för att hämta loggarkiv. (Default: /logdownload/archives/). 3. Host name Domännamn till nationella tjänsten. 4. Port Portnummer till nationella tjänsten. 5. Protocol https eller http (Default: https). 4. Aktivera därefter schemaläggaren så att den hämtar gårdagens (eller från när den hämtade senast) arkiv per automatik genom att bocka i Scheduler enabled. 5. Konfigurera när schemaläggaren ska starta, Scheduler start time, det görs i formatet HH:mm (00:00 23:59) Default: 02:00 på natten. Figur: Log Download Archive 9.9.2. Manuell hämtning av (äldre) arkiv ifrån den nationella loggtjänsten

När den automatiska hämtningen startar, hämtas bara gårdagens arkiv (eller från den tidpunkt när arkiven hämtade senast). Om behov finns, av att hämta äldre arkiv, måste detta göras manuellt. Logga in till systemkonsolen med: telnet localhost 1111 Följande kommandon finns att tillgå i systemkonsolen: archive dl <parametrar> archive status <parametrar> Figur: Kommandon för manuell hämtning av arkivloggar Exempel 1 - Hämta alla arkivloggar från 1:a januari 2013 osgi> archive dl -from 2013-01-01 Exempel 2 - Hämta alla arkivloggar från 1:a januari 2013 till 1:a augusti 2013 osgi> archive dl -from 2013-01-01 -to 2013-08-01 Exempel 4 Visa status på alla hanterade arkivloggar som har gått fel osgi> archive status -code Error Exempel 5 Testa anslutningen mot nationella säkerhetstjänsten osgi> archive status -test 9.10. Arkivsökning

Syftet med arkivsökningstjänsten är att söka fram arkiverade loggrapporter som är äldre än 18 månader och innefattar sökning i komprimerade arkiv. Här kan man vilja se över de tider på dygnet som den processintensiva genereringen av denna rapport tillåts. Se då framförallt fälten Report execute start interval och Report execute stop interval som beskriver det intervall som dessa jobb inte tillåts exekvera (08-17 i fallet nedan). Notera att Arkivsökningen kommer att skapa en katalog på den delade diskytan för att lagra den komprimerade xml-filen som sökningen resulterar i.

10. Behörighet Ansvaret på vilka vårdgivare en lokal installation skall hantera, ligger på varje huvudmans vårdorganisation. Det är av största vikt att de behörighetsregler som används kontrollerar åtkomsten till den eller de vårdgivare och konsumentsystem som avses innan åtkomst till systemet ges. I Användarhandboken för Säkerhetstjänster [ Ref 2] finns det mer information om systemets behörighetskriterier. 10.1. RuleConfigGenerator I lokala Säkerhetstjänster ingår det en Windows-applikation som används för att skapa behörighetsregler och metadata för konsumentsystem. Applikationen ligger under mappstrukturen: <Lokal_sakerhetstjanst_<operativsystem>>/rules/RuleConfigGenerator/ Starta applikationen med RuleConfigGenerator.exe. Applikationen består av två huvudfunktioner: Generate rules - Generering av behörighetsregler. Generate metadata - Generering av metadata för konsumentsystem. Funktionerna är uppdelat under två flikar. Bilden nedan visar fliken Generate rules, som används vid skapandet av lokala behörighetsregler. Figur: Generering av behörighetsregler för användare Bilden nedan visar fliken Generate metadata, som används vid skapandet av metadata för externa system.

Figur: Generering av behörigheter för konsumentsystem 10.2. Behörighetsregler för användare Säkerhetstjänster validerar vad en användare har behörighet att göra i systemet, utifrån de egenskaperna som finns i användarens SAML-intyg. Användare som autentiserar sig till systemet med ett SITHS-kort får sina egenskaper från HSA-katalogen. En egenskap kan exempelvis vara BIF; Spärradministratör som innebär att användaren har behörighet att hantera spärrar. Dessutom måste man i den lokala säkerhetstjänsten konfigurera in vilken/vilka vårdgivare denna instans representerar, denna information jämförs sedan med innehållet i användarens SAML-biljett för att på så vis avgöra om användaren är behörig eller ej. Uppsättning av lokala behörighetsregler görs med det medföljande verktyget som beskrivs i följande avsnitt. 10.2.1. Behörighet för slutanvändare i Säkerhetstjänsters admin-gui För att slutanvändare skall få tillgång till administrationssidan krävs minst ett medarbetaruppdrag i HSA, för de SITHS-kort som används. Var god kontakta Inera [ Ref 1] för mer information kring anslutning och dokumentation. Användaren och medarbetaruppdraget måste innehålla minst följande: Namn HSA Systemroll Beskrivning Användarens systemroll(er). T ex För åtkomst till spärrar krävs rollen: BIF;Spärradministratör HSA-id för medarbetaren HSA-id för medarbetaruppdrag Namn på medarbetaruppdrag HSA-id för vårdgivare Namn på vårdgivare HSA-id för vårdenhet Namn på vårdenhet Användarens personliga HSA-id. Det valda medarbetaruppdragets HSA-id. Det valda medarbetaruppdragets namn. HSA-id för vårdgivaren som medarbetaruppdraget gäller inom. Namn på vårdgivaren som medarbetaruppdraget gäller inom. HSA-id för vårdenheten som medarbetaruppdraget gäller inom. Namn på vårdenheten som medarbetaruppdraget gäller inom. Se Användarhandboken [Ref 2] för mer detaljerad information om åtkomst och regler i behörighetsadministrationen. 10.2.2. Skapa av behörighetsregler för användare

I installationspaketet ingår det en mall för de behörighetsregler som en lokal installation behöver. Reglerna måste anpassas efter era vårdgivare och vad dessa ska få behörighet att göra i systemet. Mallen ligger under mappstrukturen: <Lokal_sakerhetstjanst_<operativsystem>>/rules/regler_default_lokal.xml. Reglerna skapas med en applikation som följer med i installationspaketet tillsammans med mallen ovan. I samma katalog finns textfilen CareProviders.txt som ska modifieras med era vårdgivare. För att sätta upp behörighetsregler för er lokala installation: 1. Öppna textfilen CareProviders.txt och ange era vårdgivare (en per rad). Följ instruktionerna som ges i filen. 2. Spara filen och kör applikationen RuleConfigGenerator.exe. Det är rekommenderat att ni sparar filen i samma katalog så applikationen kan välja den automatiskt till kommande steg. 3. Läs in er modifierade CareProviders.txt med knappen Browse i fältet Care provider file path. Se bild nedan. Applikationen hittar filen själv om ni sparade den med samma namn i den katalog som ni modifierade den i. Figur: Ange sökvägar till nödvändiga filer 4. Välj fliken Generate rules i applikationen. 5. Rule template file path ska normalt inte behöva anges, utan applikationen hittar den själv under förutsättning att filen finns i samma katalog. <Lokal_sakerhetstjanst_<operativsystem>>/rules/regler_default_lokal.xml. 6. Klicka på knappen Generate Rules. Spara era regler på ett lämpligt ställe. Reglerna som ni skapat ska läsas in i systemet. Se Läsa in behörighetsregler för användare. 10.2.3. Läsa in behörighetsregler för användare När samtliga vårdgivare (som ska ha behörighet att hantera de installerade tjänsterna) är inlagda i de lokala behörighetsreglerna, ska de läsas in i Säkerhetstjänsters OSGi-konsol (systemkonsol). Läs in regler: 1. Logga in till systemkonsolen. Ange den adress och port till konsolen som valdes i installationsskedet: telnet localhost 1111 2. Läs in reglerna med kommandot: osgi> sys acc -import file:///<sökväg till er anpassade regel-fil> 3. Reglerna är nu inlästa, Avsluta systemkonsolen med kommandot: osgi> disconnect

10.3. Behörigheter för vårdsystem eller tjänsteplattformen Förutom att ge andra system (SP) rätt att autentisera sig mot IdP:n används även SP-metadata för att ge externa vårdsystem och tjänsteplattformen behörighet att använda lokala Säkerhetstjänster. Det som menas med vårdsystem är ett externt system som ska ha behörighet att anropa någon av de installerade tjänsterna i lokala Säkerhetstjänster (dvs. Samtycke, Patientrelation och Spärr) som är definierade i tjänstekontrakten. I leveransen ingår det en mall för SP-metadata. Metadata-filen måste anpassas efter följande kriterier: Systemets HSA-id (entityid). HSA-id för de vårdgivare som som systemet ska vara behörig till 10.3.1. Anpassa metadata för vårdsystem eller tjänsteplattformen Nedan följer en beskrivning för hur regelgeneratorn ska användas vid generering av metadata till ett vårdsystem eller mot tjänsteplattformen. Följande bild visar beskrivningar för samtliga funktioner under fliken Generate metadata som används vid genereringen av metadata. Figur: Beskrivningar av samtliga knappar och fält i fliken 10.3.2. Ta reda på HSA-id Det går att ta reda på HSA-id:et för vårdsystemet eller tjänsteplattformens funktionscertifkat om man har tillgång till certifikatfilen. 1. 2. 3. 4. Har man tillgång till certifikatfilen kan man öppna denna och ta reda på id:et genom: Öppna certifikatets leg.cer fil och klicka på Details. Bläddra i listan som visas. Klicka på informationsfältet Subject. En informationsruta visas. Det Serial number som visas i rutan är certifikatets serienummer, dvs. det HSA-id som ni ska specificera i metadata-filen som ni anpassar till systemet. 10.3.3. Skapa metadata för vårdsystem/tjänsteplattform 1. Öppna textfilen CareProviders.txt och ange era akutella vårdgivare (en per rad). Följ instruktionerna som ges i filen. 2. Spara filen och kör applikationen RuleConfigGenerator.exe. Det är rekommenderat att ni sparar filen i samma katalog så applikationen kan välja den automatiskt till kommande steg. 3. Välj fliken Generate metadata i applikationen 4. Läs in er modifierade textfil med knappen Browse i fältet Care provider file path. (Applikationen hittar filen själv om den sparades med samma namn). 5. Ange HSA-Id för konsumentsystemet i fältet Entity id (Serial No). Se bilden ovan. 6. Meta template file path ska normalt inte behöva anges, utan applikationen hittar den själv under förutsättning att filen finns i samma katalog. <Lokal_sakerhetstjanst>/rules/metadata_default.xml 7. Bocka i kryssrutan Generera för Tjänsteplattformen om metadata-filen ska sättas upp mot tjänsteplattformen annars fortsätt till nästa steg. 8. Klicka på knappen Generate Metadata. Spara metadata-filen på ett lämpligt ställe. 9. Metadata-filens som skapats ska läsas in i systemet. Se avsnitt Inläsning av metadata. När metadata är inläst, kommer det att listas med konsumentsystemets HSA-id i listan under Importerade SP metadata.

11. Aktivera filter och logga in 11.1. Aktivering av filter för autentisering och åtkomstkontroll Säkerhetstjänster använder sig av två filter: Autentiseringsfilter - Filtret kräver att användaren ska autentisera sig för att få åtkomst till Säkerhetstjänster. Behörighetsfilter - Filtret styr vilken behörighet användaren har i Säkerhetstjänster. Det kan t ex innebära att en användare som har rollen som spärradministratör endast får hantera spärrar i systemet. Efter att systemet installerats och konfigurerats ska filtren aktiveras: 1. Logga in i systemkonsolen med: telnet localhost 1111 2. Aktivera autentiseringsfiltret med kommandot: osgi> sys spfilter -on 3. Aktivera behörighetsfiltret med kommandot: osgi> sys authz -on 4. Avsluta systemkonsolen med kommandot: osgi> disconnect 11.2. Logga in i Säkerhetstjänster När ni har installerat och konfigurerat upp systemet, starta webbgränssnittet för lokala Säkerhetstjänster: https://[servernamn]:[8443]/spadmin Kontrollera därefter att webbgrässnittet nu kräver SITHS-kort inloggning och att ett medarbetaruppdragsval måste göras (om användaren har fler än ett medarbetaruppdrag i HSA-katalogen).

12. Systemadministration 12.1. Start och stopp 12.1.1. Stoppa lokala Säkerhetstjänster För att stoppa systemet, gå in i verktyget Server Manager och Services och gå till lokala Säkerhetstjänsters tjänst (Lokal Säkerhetstjänst 2.5) och klicka på Stop. 12.1.2. Starta lokala Säkerhetstjänster För att starta systemet, gå in i verktyget Server Manager och Services och gå till lokala Säkerhetstjänsters tjänst (Lokal Säkerhetstjänst 2.5) och klicka på Start. Man bör alltid säkerställa att systemet startat korrekt genom att kontrollera att systemloggen inte innehåller några fel ( Exceptions). Avvakta upp till en minut så att lokala Säkerhetstjänster har givits tid att starta upp och kontrollera därefter den senaste loggfilen (läs mer om loggning och felsökning i avsnitt Systemlogg (audit) 12.2. Logga in i lokala Säkerhetstjänster När ni har installerat servern kan ni gå till det grafiska webbgränssnittet för lokala Säkerhetstjänster: https://[servernamn]:[8443]/spadmin Där testas inloggningsförfarandet med val av SITHS-kort och val av medarbetaruppdragsval. 12.2.1. Logga in med SITHS-kort 1. 2. Sätt in SITHS-kortet i kortläsaren. Öppna webbläsaren och ange adressen till webbgränssnittet. Ange PIN-koden för SITHS-kortet i autentiseringsrutan. Klicka därefter på knappen Jag identifierar mig. Fönstret Val av uppdrag visas. 3. Klicka på ett presenterat uppdrag för att fortsätta. a. Här presenteras enbart aktiva medarbetaruppdrag, alltså uppdrag på vårdenheter som är aktiva. b. Om vyn Val av uppdrag inte visas, beror det på att: : i. Medarbetaren har bara ett uppdrag vilket då väljs automatiskt. ii. Medarbetaren är redan inloggad och har en aktiv session (t.ex. om medarbetaren först loggar in i NPÖ och därefter i samma webbläsare startar Säkerhetstjänster s webbgränssnitt). Det uppdragsval som gjordes vid första inloggningen används automatiskt vid efterföljande inloggning (SSO). 4. Inloggningen till webbgränssnittet är klart. I webbgränssnittet gäller generellt att endast de knappar eller funktioner som medarbetaren har behörighet till visas och de övriga funktionerna döljs.vid osäkerhet på vilket uppdrag som ger rättighet till vad, prova att först logga ut och därefter logga in igen i webbgränssnittet med något annat tänkbart uppdrag. Behörigheten styrs med hjälp av de uppdrag som är kopplade till SITHS-kortet och dessa hämtar systemet från HSA. Om behörighet till någon funktion saknas, kontakta HSA-support eller motsvarande för att lägga till de uppdrag och behörigheter som behövs. 12.3. Hantera aktiviteter i OSGi Systemet har en inbyggd systemkonsol (OSGi-konsol) som är åtkomlig via Telnet på port 1111 (om inget annat angavs under installationen). Systemkonsolen används endast vid produktsupport eller felsökning, samt av- och påslag av autentiseringsfiltret.

12.3.1. Verifiera att systemets alla bundlar är uppstartade 1. Logga in till systemkonsolen: telnet localhost 1111 2. Verifiera att samtliga bundlar är uppstartade med kommandot dep. (Kommandot listar alla bundlar som ännu inte har startat.) osgi> dep Utskriftsexempel: osgi> dep id Bundle State Unsatisfied dependencies Spring dependencies osgi> Listas inte någon bundel här är samtliga bundlar startade. I annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel. Om någon bundel ej startar igång, testa att starta om säkerhetstjänster. Kvarstår problemet måste felsökning påbörjas. 3. Verifiera att alla beroenden är uppfyllda med kommandot: osgi> context state Utskriftsexempel: osgi> context state Id Context State osgi> State Information Listas inte någon bundel här är samtliga bundlar startade. I annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel. 12.3.2. Aktivering av filter för autentisering och åtkomstkontroll 1. Gå in i systemkonsolen med: telnet localhost 1111 2. Aktivera/Inaktivera autentiseringsfiltret med kommandot: osgi> sys spfilter -on osgi> sys spfilter -off

3. Aktivera/Inaktivera behörighetsfiltret med kommandot: osgi> sys authz -on osgi> sys authz -off 4. Avsluta systemkonsolen med kommandot: osgi> disconnect 12.4. Systemlogg (audit) Lokala Säkerhetstjänster producerar en systemlogg för teknisk förvaltning och felsökning, som lagras på filsystemet under uppstartsfasen. Systemloggen lagras i följande katalog (enligt standardinstallationen): /sakerhetstjansten/sakerhetstjanst<version>/local/log/ Systemet lagrar systemloggarna i första hand i databasen (schemat audit) och kan nås genom kommandot audit från systemkonsollen, se avsnitt Sök i systemloggen. Om inte databasen är uppsatt för att kunna hantera systemloggar (som sker i installationsskedet av Säkerhetstjänster) skrivs systemloggarna till filen ovan istället. Vid uppstart av systemet kan systemloggningen temporärt ske till fil (för att få uppstartsloggar), men den övergår snabbt till att logga till databas när loggfunktionen är startad. 12.4.1. Sök i systemloggen 1. Logga in till systemkonsolen med: telnet localhost 1111 2. Sök i loggen enligt: (Alla error loggar den senaste timmen) osgi> audit search -level error -time 1h (Alla loggar den senaste timmen) osgi> audit search -time 1h (Alla loggar de senaste 5 minuterna) osgi> audit search -time 5m 3. Avsluta systemkonsolen med kommandot: osgi> disconnect 12.5. Felsökning Om problem uppstår där lokala Säkerhetstjänster misstänks vara orsaken bör följande saker undersökas: Monitorera MySQL-processen och kontrollera att databasen svarar på enkla förfrågningar. Monitorera MongoBD-processen och kontrollera att databasen svarar på enkla förfrågningar. Monitorera Java-processen på applikationsserver och kontrollera att "monitor"-sidan svarar ( https://[servernamn]:[8443]/spadmin). Vid akuta problem, starta om applikations- och/eller databasservern och kontrollera systemloggen.

Om produktfelanmälan skall göras måste alla systemloggar kring felet samt ett beskrivande scenario kring vad som föranledde felet, bifogas felanmälan.

13. Test För att verifiera systemet kan följande anvisning användas: Test av installation eller uppgradering 2.11

14. Förvaltning och underhåll 14.1. Periodiskt underhåll Läs Systemlogg (audit) för information angående hur systemloggar lagras och söks i. Hantera aktiviteter i OSGi beskriver hur systemet kan hanteras och kontrolleras i systemkonsolen (OSGi). 14.2. Övervakning Applikationsservern publicerar en mängd systemmoduler som kan övervakas över JMX-protokollet som är Javas teknik för generell övervakning. Med valfritt JMX-verktyg kan applikationsserverns webbtjänster övervakas, se avsnitt Portöversikt gällande port. Observera att JMX-porten inte får tillgängliggöras för någon annan part än den maskin som skall sköta övervakningen. Standardinställningarna för JMX kan ändras i filen: Windows: <installationskatalog>\localsakerhetstjanstconfig.xml Linux: /etc/init.d/sak_server Alla systemkomponenter publiceras som monitorerbara JMX-bönor. Nedan visas en exempelbild från programmet JConsole som medföljer Java SE. Figur: Exempelbild från programmet Jconsole Alla bönor med namn com.logica.se.iac.performance.impl.inbound respektive. outbound är övervakade webbtjänster som vid behov kan övervakas för att samla in statistik. Inbound avser alla för servern inkommande anrop och outbound de utgående. Övriga bönor är interna systemkomponenter och innehåller ingen övervakningsbar information. Varje webbtjänst har en uppsättning attribut med värden enligt följande lista: Attribut delta.maxtime delta.meantime delta.mintime Beskrivning Det anrop som tagit längst tid att exekvera (ms) inom aktuellt mätfönster/delta. Snittid för alla anrop (ms) inom aktuellt mätfönster/delta. Det anrop som tagit kortast tid att exekvera (ms) inom aktuellt mätfönster/delta.

delta.size Antal paket/anrop som ingår i delta-beräkningarna, t.ex. "de 50 senaste". name total.exceptions total.maxtime total.meantime total.mintime total.packets Namn på webbtjänsten. Totalt antal exceptions/fel som inträffat för webbtjänsten sedan systemet startades. Det anrop som tagit längst tid att exekvera (ms) sedan systemet startades. Snittid för alla anrop (ms) sedan systemet startades. Det anrop som tagit kortast tid att exekvera (ms) sedan systemet startades. Totalt antal paket/anrop som behandlats sedan systemet startades. 14.3. Uppgradering Lokala Säkerhetstjänster kan mjukvaruuppgraderas då nyare versioner av produkten finns tillgängliga. Mer information om detta ges för respektive uppgradering. Var god kontakta Inera för information kring aktuella versioner [ Ref 1].

15. Avinstallation Avinstallationen tar bort de flesta filer och kataloger som skapats. Dock får man manuellt ta bort installationskatalogen i efterhand om så önskas, samt manuellt avregistrera tjänster (services). Det görs med hjälp av SC.exe och beskrivs lite längre ner. Om installationen var en fail-over installation med flera noder, så skapades även en katalogstruktur på den delade diskytan. Innehållet på diskytan måste också tas bort manuellt. Obs! Det kan vara bra att ta en backup på den delade diskytan, om man behöver återställa systemet. För att avinstallera: 1. Stoppa först tjänsten Lokal Säkerhetstjänst 2.5. Se bilden nedan. 2. 3. 4. Figur: Exempelbild från services under verktyget Server Manager Avinstallera sedan systemet enligt standardiserat sätt via Windows kontrollpanel -> Avinstallera och ändra program. Se bilden nedan. Välj Uninstall a program under menyn Programs. Dubbelklicka på Lokal Sakerhetstjanst 2.5. 5. Figur: Avinstallation av tjänsten Lokala Säkerhetstjänster avinstalleras. 15.1. Avregistrera tjänster Avregistrera tjänster och ta bort registervärden med hjälp av programmet sc.exe. För att avregistrera tjänst: 1. 2. Öppna kommando-prompten. Avregistrera tjänsten Lokal säkerhetsjänst 2.5. sc delete "Lokal Säkerhetstjänst <version>" Notera: ersätt <version> med den version som är installerad

16. Appendix 16.1. Appendix A - Exempel på konfiguration av den lokala brandväggen för windows servrarna Konfigurera inställningarna för brandväggen genom att starta verktyget Adminstrative Tools -> Windows Firewall with Advanced Security, Skapa en ny regel under Inbound rules, se tabellen nedan. Steg Val Beskrivning Rule Type Port Regel som kontrollerar anslutningar för TCP eller UDP port Protocol and Ports TCP Specific local ports Ange dom portar som beskrivs i tabellen under avsnitt Portöversikt Action Allow the connection Inkluderar anslutningar som vare sig är skyddade eller ej utav IPsec Profile Domain, Private, Public Ange om regeln ska gälla för Domain/Private /Public Name Lokala säkerhetsjänster Namn och beskrivning för regeln, 16.2. Appendix B - Skapa separat servicekonto Vid installation av service Lokal Säkerhetstjänst installeras den och körs default som Local System. Det är rekommenderat att skapa ett separat servicekonto som servicen använder. Nedan visar på ett exempel hur detta skapas. 16.2.1. Skapa en användare För att skapa ett nytt servicekonto: 1. 2. Klicka på Start och sedan Run. Starta Local Users and Groups med kommandot: lusrmgr.msc 3. Högerklicka på gruppen Users och välj New user Figur: Lägg till ny användare 4. Ett fönster öppnas med ett formulär som ska fyllas i. Välj namn på användaren, beskrivning och lösenord med specifika inställningar. 1. 2. Avaktivera "User must change password at next logon" Klicka i "Password never exipires"

Figur: exempel på skapande av användare 5. Klicka på knappen Create och därefter på knappen Close. En ny användare är nu skapad. 16.2.2. Tilldela användaren "Log on as a service" behörighet För att användaren ska få behörighet att köra en service, behöver den tilldelas en policy för detta. Gör så här: 1. Starta Local Security Policy som återfinns under Control Panel->System and Security->Administrative Tools.

Figur :Administrative Tools vyn. 2. Expandera Local Policies och klicka på User Rights Assignment i menyn. 3. Lokalisera policyn Log on as a service i listan till höger och dubbelklicka på den. Figur: Local Polices vyn. 4. Klicka på knappen Add User or Group och peka ut den användare du vill servicen ska köras som. I exemplet är det den lokala användaren SakUser som vi skapade i tidigare steg.

Figur: Add User or Group. 5. Klicka på knappen OK och verifiera att användaren SakUser finns med i listan (i bilden ovan). 6. Klicka på knappen OK. 16.2.3. Ändra användare på den installerade servicen För att ändra användare på servicen:

1. Starta Services som återfinns under Control Panel->System and Security->Administrative Tools. 2. Figur: Administrative tools vyn. Leta rätt på servicen Lokal Säkerhetstjänst 2.5 i listan och dubbelklicka på den. 3. Figur: Services vyn. Klicka på Log On fliken i dialogen.

Förvalt är värdet satt till Local System Account, men sök istället fram och välj den användare som skapades innan, genom att klicka på knappen Browse. 4. Figur: Service egenskaper. Klicka på knappen OK. 16.2.4. Uppdatera behörighet till filer och kataloger som säkerhetstjänster använder 1. Starta utforskaren och bläddra fram dig till den katalog systemet är installerat på. (I exemplet ligger systemet installerat under C:\Program Files\Inera\Lokal Sakerhetstjanst 2.5)

Figur: Lokala Säkerhetstjänsters installationskatalog. 2. Högerklicka på katalogen Lokal Sakerhetstjanst 2.5 eller motsvarande katalog i er miljö. Välj Properties samt Security-fliken.

Figur: Security vyn. 3. Klicka på knappen Edit och knappen Add och peka ut användaren som service körs som (som skapades innan). Tilldela användaren Full Control och klicka på knappen OK.

Figur: Security - Add. 16.2.5. Lägg till behörigheter i registret Användaren behöver även behörighet att läsa och skriva i registret. 1. 2. Klicka på Start-knappen i Windows och skriv in regedit. Kör Regedit.exe.

3. Sök fram till katalogstrukturen (under HKEY_LOCAL_MACHINE ) där Säkerhetstjänster är installerad. Se bild nedan. Figur: Registry editor. 4. Högerklicka på motsvarande huvudkatalog till Säkerhetstjänster och välj Permissions...

Figur: Permissions 5. Välj serviceanvändaren som skapades tidigare och lägg till följande behörigheter (permissions) för användaren: Full Control och Read. Dessa behörigheter sätts med kryssrutorna som bilden nedan visar. Klicka på knappen OK. Figur: Behörigheter för användare 16.3. Appendix C - Krav på delad diskyta vid en fail-over installation Samtliga noder i fail-overlösningen skall använda samma sökväg till den delade diskytan. UNC-sökvägar (Nätverkssökväg, t.ex. \\my.share. domain.se\share) stöds inte. För att uppnå det kan en symbolisk länk skapas på respektive nod, genom att använda kommandot mklink. Den delade diskytan kan t.ex. sättas upp med hjälp av en samba-share, Microsoft cluster disk eller NFS delning. Exempel Sökväg som valts till delad diskyta på nod #1, nod #2, och övriga noder: C:\share Sökväg till nätverksresurs: \\my.share.domain.se\share På samtliga noder, skapa en symbolisk länk C:\Share till den delade resursen "\\my.share.domain.se\share" med hjälp av kommandot: mklink /D C:\Share "\\my.share.domain.se\share"

Figur: mklink exempel Använd därefter sökvägen till den delade diskytan (symboliska länken C:\share) under installationsförfarandet.