Installation och administration. Lokala Säkerhetstjänster 2.3 (Linux)

Transkript

1 2.3 (Linux)

2 Innehållsförteckning 1 INLEDNING Allmänt Konventioner Begrepp Referenser SYSTEMKRAV Operativsystem Diskyta Delad diskyta för Säkerhetstjänster Diskyta för MySQL Diskyta för MongoDB Tidssynkronisering PLATTFORM OCH TREDJEPARTSPRODUKTER Java JCE, Java Java Cryptography Extension MySQL MongoDB Lastbalanserare Certifikat Ytterligare certifikat CSP - Cryptographic Service Provider Terracotta Beroenden till externa system HSA-WS Revokeringskontroll av certifikat PU-tjänsten* Nationell Spärrtjänst* Tjänsteplattformen* SYSTEMÖVERSIKT Ingående servrar Portöversikt Adressöversikt gränssnitt INSTALLATION AV DATABASSERVER Installationsanvisningar för MySQL Skapa ny användare Skapa upp databaserna Installationsanvisningar för MongoDB Installera MongoDB på tre noder Indexering Skapa nödvändiga databaser Konfigurationsfil...36 Sid 2/85

3 6 INSTALLATION AV APPLIKATIONSSERVER Installera Java och JCE INSTALLATION AV LOKALA SÄKERHETSTJÄNSTER Installera systemet på Linuxmiljö Installation Installation av SingleServer Installation på första noden i en fail-over lösning Installation på andra noden i en fail-over lösning Linux-specifika inställningar på samtliga noder (nod1 och nod2)42 8 UPPSTART AV SERVER Uppstart av Terracotta Uppstart av lokal Säkerhetstjänst på första noden Anslut till webbgränssnittet Uppstart av lokal Säkerhetstjänst på övriga noder SYSTEMKONFIGURATION Webbgränssnittet Koppling till HSA-WS Konfiguration av HSA-WS PU-tjänsten Konfiguration av spärr Block Local Service Block Web Application Block National Webservice Proxy for RIV Block Common Webservice Proxy v Block Common Webservice Proxy for National v Block National Accesscontrol Webservice Proxy Konfiguration av loggtjänsten Log Agent Impl Log WS Proxy Impl Konfiguration av samtycke Consent Webservice Proxy ConsentPDL GWT Application Konfiguration av patientrelation Patientrelation Web Application Patientrelation Webservice Proxy Konfiguration av hämtningstjänsten Ta bort root-certifikat för test vid en produktionssättning Konfiguration av CDC BEHÖRIGHET Behörighetsregler för användare Uppsättning av behörighetsregler för användare Läsa in regler IdP/SP Metadata Behörigheter för konsumentsystem eller för tjänsteplattformen...69 Sid 3/85

4 Anpassa metadata för konsumentsystem eller mot tjänsteplattformen Inläsning av metadata Systemegenskaper Extern Autentiseringstjänst Aktivering av autentiseringsfilter och åtkomstkontroll SYSTEMADMINISTRATION Logga in i lokala Säkerhetstjänster Start och stopp Stoppa lokal Säkerhetstjänster Starta lokal Säkerhetstjänster Stoppa Terracotta Starta Terracotta Hantera aktiviteter i OSGi Aktivering och avaktivering av autentiseringsfilter Systemlogg Sök i systemlogg Felsökning FÖRVALTNING OCH UNDERHÅLL Hämtning av arkivloggar från den nationella Säkerhetstjänster Manuell hämtning Schemaläggare Hämtning av nationella arkiv Periodiskt underhåll Övervakning Uppgradering AVINSTALLATION Avinstallera lokal Säkerhetstjänst Avinstallera Terracotta Upprensning...81 I. APPENDIX A Skapa behörighetsregler och metadata manuellt Manuell hantering av behörighetsregler Manuell hantering av metadata för konsumentsystem...83 Sid 4/85

5 Revisionshistorik Version Författare Kommentar 0.1 Logica Dokument upprättat 0.2 Logica Förtydligande i text 0.3 Logica Uppdaterat portbeskrivning 0.4 Logica Uppdaterat installation, övervakning 0.5 Marcus Tinnsten Uppdaterat installationsguide 0.6 Marcus Tinnsten Uppdaterat portbeskrivning 1.0 Marcus Tinnsten Dokument färdigställt till systemversion Marcus Tinnsten Uppdaterat kapitlet systemkonfiguration 1.11 Marcus Tinnsten Nytt avsnitt i systemkonfiguration 1.2 Marcus Tinnsten Dokumentet justerat för Örjan Olofsson Uppdaterat installationsguide samt kapitlet systemkonfiguration 1.4 Örjan Olofsson Uppdaterat installationsguide (klustrat alternativ) samt kapitlet systemkonfiguration replikering till nationell spärrtjänst 1.5 Örjan Olofsson Uppdaterat 1.6 Stefan Eriksson Uppdaterad efter intern granskning 1.7 Marcus Tinnsten Uppdaterad för systemversion Örjan Olofsson Uppdaterad efter intern granskning 1.9 Magnus Lexhagen, Örjan Olofsson och Marcus Tinnsten 2.0 Magnus Lexhagen, Örjan Olofsson och Marcus Tinnsten Uppdaterad för systemversion 2.3 Dokument färdigställt till systemversion 2.3 Sid 5/85

6 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ärr) som kan installeras separat eller tillsammans som ett komplett paket. Detta dokument beskriver installationen av lokala Säkerhetstjänster på Linux. Dokumentet beskriver i huvudsak: Installation av databasserver (MySQL och 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 install rules schema_wsdl Beskrivning Konfigurationsfiler och databasskript (MySQL). All dokumentation Exempelkod för hur man kan ansluta en SP till IdP:n (lokal autentiseringstjänst) Installationsskript och systemkomponenter. Innehåller behörighetsregler som ska modifieras och läsas in i systemet Tjänstekontrakten för lokala Säkerhetstjänster 1.2 Konventioner I detta dokument finns vissa typografiska markeringar för att klargöra instruktioner. Dessa bör tolkas enligt följande: Konvention Kursiv Kommando [Ref nr] Beskrivning Används vid hänvisning till ett specifikt namn, adress, eller annat värde som inte är löpande text. Används för kommandon till systemet. Referensangivelse Sid 6/85

7 1.3 Begrepp Begrepp Autentiseringstjänst Bundel CDC CRL GFS2 HA HSA IdP Metadata NTP OCSP PDL PU-tjänst REST RIV RIV TA SAMBI Beskrivning Den tjänst som kontrollerar användaren 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. Global File System 2. En delad diskarea för Linux kluster. High Availablity. En tjänst som har hög tillgänglighet. 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. Identity Provider. Tjänst som autentiserar en aktör och utfärdar, i detta fall, en SAML-biljett. Autentiseringstjänsten som levereras med Säkerhetstjänster är en IdP, som även kan installeras som en egen lokal IdP-tjänst. 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 IdP:n och SP:n. 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 aktuellt status för certifikatet som efterfrågas. Patientdatalagen Personuppgiftstjänst Representational State Transfer Regelverk för Interoperabilitet inom Vård och omsorg. 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. SAML-profil för samverkan för Behörighet och Identitet inom hälsa, vård och omsorg. Beskriver hur egenskaper namnsätts i SAML- Sid 7/85

8 SAML SAML biljett SITHS SP Tjänsteplattformen (TP) biljetten. janst/dokument-for-autentiseringstjansten/ Security Assertion Markup Language En standard som beskriver hur egenskaper och dess värden skall beskrivas i XML-format. 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. 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, t ex Samtyckestjänsten. De lokala tjänsterna i Säkerhetstjänsterna 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 Referenser Referensnr Namn Adress Ref 1 Inera AB Ref 2 Inera AB Anvandarhandbok_Sakerhetstjanster.pdf Sid 8/85

9 2 SYSTEMKRAV 2.1 Operativsystem levereras med installationsanvisningar för Linux Redhat 64bit. Denna leverans är kvalitetssäkrat på Linux Redhat bit (x86_64). - Applikationsservrarna bör vara flerkärnig med minst 12 GB RAM. - MySQL-databasservrarna bör vara flerkärnig med minst 8 GB RAM. - MongoDB-servrarna bör vara flerkärnig och hur mycket RAM som krävs är beroende på hur mycket respektive vårdgivare loggar. En riktlinje är att 40 miljoner loggar med dess index tar c:a 20 GB RAM. 2.2 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. arkivloggar och systemets gemensamma konfiguration finns lagrat. Dessa ska sättas upp med GFS2 och mappas upp till en katalog på samtliga noder. Det är viktigt att det är redundant så att man inte får en SinglePointOfFailure, då systemet kräver den delade diskytan för att kunna starta. Default är namnet på katalogen: /share i konfigurationen nedan Delad diskyta för Säkerhetstjänster - Den delade diskytan (/share) för applikationsservrarna bör minst vara på 100 GB Diskyta för MySQL - Diskytan för MySQL (/mysql) bör minst vara på 200 GB Diskyta för MongoDB - Diskytan för MongoDB (/mongodb) är helt beroende av hur mycket som respektive vårdgivare loggar. Riktlinje är att 40 miljoner loggar tar c:a 115 GB diskarea. Sid 9/85

10 2.3 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. För att synkronisera tiden kan t.ex. NTP användas. Sid 10/85

11 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 starta tjänsten krävs Oracle Java SE 6, JDK (senaste update), 64 bitar, som finns att hämta på: Systemet är kvalitetssäkrat med JDK 6 update 35. Observera att man ännu inte kan köra med Java JCE, Java Java Cryptography Extension Det krävs även ett tillägg, download html, som måste installeras för att kunna nyttja 256-bitars kryptering. 3.2 MySQL kräver databasservern MySQL för Linux. Systemet är kvalitetssäkrat med MySQL Community Server och våra rekommendationer är därmed 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 Mongodatabasen (MongoDB) är en lättviktig (NoSQL) databas som används för att hantera uppföljning av verksamhetsloggar (PDL-loggar). MongoDB håller PDL-loggar i ca 18 månader (konfigurerbart) tillbaka i tiden och är den databas 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 en rapport för uppföljning. MongoDB är inget som följer med Säkerhetstjänsters installationspaket, utan är en tredjepartsprodukt som måste hämtas från Internet. Systemet är kvalitetssäkrat mot MongoDB-server Därför rekommenderas att man installerar en version ur 2.4-serien. Hur databasen ska sättas upp på bästa sätt diskuteras i kapitel 5.2 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 ingår inte i detta dokument. Sid 11/85

12 Lastbalansering till applikationsserver kan ske med round-robin då all sessionsdata (SSLsessioner) delas mellan applikationsservrarna. Hur övervakning av applikationsservern kan ske finns beskrivet i kapitel Som ett minimum bör de externa HTTPS-portarna som används TCP-monitoreras innan lastbalansering sker till applikationsservern. 3.5 Certifikat Innan installation av lokala Säkerhetstjänster i produktionsmiljö påbörjas måste ett SITHStjänstecertifikat (funktionscertifikat) för legitimering införskaffas, utfärdade för lokala Säkerhetstjänsters applikationsserver. Certifikat används för att identifiera applikationsservern vid all sorts kommunikation. Certifikaten skall vara utfärdade till det värdnamn som skall användas för applikationsservern. Var god kontakta Inera för information kring SITHScertifikat [Ref 1] Ytterligare certifikat Om lokala Säkerhetstjänster ska nyttjas tillsammans med andra IdP:er i en federation krävs ytterligare ett SITHS-tjänstecertifikat(legitimering) 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 denna IdP ha ett certifikat där också, 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 för att kunna använda hårda certifikat (t.ex SITHS-certifikat). T.ex. kan Net id användas. Var god kontakta Inera för information kring SITHS och Net id [Ref 1]. 3.7 Terracotta Vår rekommendation är att Säkerhetstjänster installeras med en klustrad uppsättning. Till det ändamålet används Terracotta för att koordinera den klustrade uppsättningen. Den ena Terracotta-noden agerar Master och den andra Terracotta-noden agerar Slave. Noderna delar resurser (som exempelvis systemets konfigurationer) på en delad diskyta. Fördelen med klustret är att det bidrar till att systemet får högre prestanda, skalbarhet och tillgänglighet. Om exempelvis en av noderna slutar fungera, går inte hela systemet ner. Kapitel 7 innehåller instruktioner för en klustrad uppsättning med Terracotta på två noder. Installation görs i samband med resterande installation av applikationsservern. Sid 12/85

13 3.8 Beroenden till externa system HSA-WS HSA-WS är en webtjänsteanslutning till underliggande HSA-katalog. Lokala Säkerhetsjänster använder HSA-WS version 2.19 eller senare. Applikationsserverns tjänstecertifikat för legitimering måste också läggas in i HSA-strukturen. Certifikatet behöver ha tillstånd att anropa följande operationer: GetCareUnit GetCareUnitList GetHsaPerson GetHsaUnit GetMiuForPerson Ping använder 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. För att en användare ska kunna autentisera sig krävs det att användaren finns upplagd i HSA. Det finns dock inget krav på att användaren måste ha ett medarbetaruppdrag. Ifall användaren saknar medarbetaruppdrag kommer en tom SAML-biljett att skapas utan egenskaper för användaren och det är upp till konsumenten av SAML-biljetten, SP:n, att avgöra vad som skall ske då (t.ex. visa ett felmeddelande). HSA-WS ingår inte i produkten lokala Säkerhetstjänster. Adresser som kan användas för att nyttja HSA-WS: Test: Produktion: 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 klientcertifikat är spärrat och därmed inte godkänt för autentisering. 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 v Exempel på adresser till crl och ocsp (Test): Sid 13/85

14 Certifikat CRL-adress OSCP-adress SITHS_Type_1_CA_v1 _PP SITHS CA TEST v3 SITHS CA TEST v4 1pp.crl a.com 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 som kan användas för att nyttja PU-tjänsten: Test: Produktion: *PU-tjänsten används enbart ifall man installerar någon av tjänsterna: Samtycke, Patientrelation och Spärr 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 tjänsten samt konfigurera vilka vårdgivare som denna lokala spärrtjä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]. Adresser som kan användas för att nyttja Nationell Spärrtjänst: Test: Produktion: *Nationell Spärrtjänst används enbart om tjänsten Spärr installeras. Sid 14/85

15 3.8.5 Tjänsteplattformen* Installerar man samtyckestjänsten och/eller patientrelationstjänsten måste man registrera dessa som producenter 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 ifrån den lokala instansen ifall ett samtycke finns registrerat. Figuren nedan illustrerar hur en läsande nationelltjänst routas via den nationella tjänsteplattformen, genom en lokal tjänsteplattform(optionell) för att till sist hamna i den lokala samtyckestjänsten. Figur 1: Principer för samverkande tjänster för hantering av samtycke Kontakta Ineras förvaltning i god tid före driftstart för att registrera tjänsterna i tjänsteplattformen [Ref 1]. *Tjänsteplattformen används enbart om någon av tjänsterna Samtycke eller Patientrelation har installerats. Adresser till Tjänsteplattformen: Miljö Hostnamn IP-adress port contextpath Test (Sjunet) test1.esb.ntjp.sjunet.org /vp Test test1.esb.ntjp.se /vp (Internet) Produktion (Sjunet) esb.ntjp.sjunet.org /vp Sid 15/85

16 Produktion (Internet) esb.ntjp.se /vp Sid 16/85

17 4 SYSTEMÖVERSIKT Detta kapitel beskriver hur systemet sätts upp med maskiner och nätverksstruktur. 4.1 Ingående servrar består av en applikationsserver och två databasservrar. På applikationsservern installeras en gemensam plattform. På plattformen kan man välja vilken/vilka utav de fristående tjänsterna Spärr, Samtycke, Patientrelation, Autentisering (IdP) och Logg som ska installeras. kan konfigureras på två grundläggade sätt, med eller utan så kallad "fail-over". Med fail-over avses en eller flera maskiner/servrar som används tillsammans med den primära servern för att höja tillgängligheten på systemet och öka kapaciteten på systemet. För att kunna köra med en eller flera fail-over servrar krävs att alla noder har en delad diskyta. En lastbalanserare (omnämns inte i detalj här) används för att dirigera trafiken till alla applikationsservrar (genom t.ex. round-robin). SSL-sessioner delas mellan applikationsservrarna, så 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 dom övriga applikationsservrarna. Fail-over-maskinerna bör vara identiska med ordinarie maskiner. Singelserverlösning består av en (1) applikationsserver och två (2) databasservers (1 MySQL och 1 MongoDB), total tre stycken maskiner. För fail-over tillkommer alltså ytterligare tre maskiner. Figur: Systemöversikt nedan visar ett exempel med fail-over. Sid 17/85

18 Användare Nationell spärrtjänst SJUNET HSA NPÖ PU-tjänsten Brandvägg CRL/OCSP Tjänsteplattformen Delad diskyta Lokal säkerhetstjänst Nod 1-x Nod 1 Lokal säkerhetstjänst TC master MongoDB arbiter Nod 2 Lokal säkerhetstjänst TC Slave Nod x Lokal säkerhetstjänst MongoDB 1 & 2 MySQL Master MySQL Slave Figur 2: Systemöversikt Sid 18/85

19 4.2 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). Server Standardport Beskrivning Applikationsserver 8443 (in) Extern HTTPS (envägs-ssl, generellt administrationsgränssnitt) 8444 (in) Extern HTTPS (tvåvägs-ssl, IdP-webbgrä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, IdP-webbgränssnitt med bla.val av identifikationsmetod och SSO) *Används endast vid installation av lokal IdP 8446 (in) Extern HTTPS (envägs-ssl, IdP-webbgrä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. Bör ej vara extern utanför DMZ (in) Telnet-port för systemkonsol. Bör ej öppnas externt (in/ut) Interna portar som används av Terracotta-tjänsten 9520 (in/ut) då man använder fail-over. Ska ej öppnas externt 9530 (in/ut) utan endast vara öppen internt för de andra noderna. 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-kort. Använder man andra certifikat än SITHS kan andra portar vara aktuella för OCSP/CRL (ut) Replikering till nationell spärrtjänst *Används endast vid installation av lokal spärrtjänst och för bakåtkompatibilitet (ut) Replikering till nationell spärrtjänst *Används endast vid installation av lokal spärrtjänst (ut) Anrop till databasservern (ut) Anrop till MongoDb-servern Databasserver Standarport Beskrivning MySQL 3306 (in) Anslutningsport till MySQL-databas. Används av applikationsservern. Bör ej vara extern utanför DMZ. Sid 19/85

20 MongoDB (in/ut) Anslutningsport till MongoDB-Används av applikationsservern, samt i MongoDB Replica set. Ska ej öppnas externt utan endast vara öppen internt för de andra noderna. MongoDB (Arbiter) (in/ut) Används av Arbiters i Replica set. Ska ej öppnas externt utan endast vara öppen internt för de andra noderna. En användare som nyttjar lokala Säkerhetstjänster kommer att behöva nyttja portar Externa system som ska använda tjänsten ansluter på port Adressöversikt gränssnitt Denna tabell 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änstekontraktsbeskrivningen 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 Alla adresser för webbgränssnitt har följande prefix: Adress Beskrivning Blockservice Consentpdlservice patientrelationservice logservice logqueryingservice Spadmin Monitor com.logica.se.bif.externalpages.web sp/saml Administrations-GUI för lokala Säkerhetstjänster. Där sidor för bl.a. spärr, samtycke, patientrelation, logg och loggrapport finns. Webbsida för administration Webbsida för att övervaka systemet. Samtyckes-dialog som externa tjänster kan nyttja Metadata SP Alla adresser för webbgränssnitt för idp har följande prefix: Adress Beskrivning idp/saml/sso/{binding} Autentiseringstjänst (IdP) SSO idp/saml/slo/{binding} Autentiseringstjänst (IdP) SLO Idp/saml Metadata IdP Sid 20/85

21 Adresser för webbgränssnitt för STS har följande prefix: Adress Beskrivning :8080/ws/idp/sts Autentiseringstjänst (STS) 2 vägs-ssl :8445/ws/idp/sts Autentiseringstjänst (STS) 1 vägs-ssl (meddelandesignering) Alla adresser för webbtjänstegränssnitt har följande prefix: 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/rivtab21 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 Sid 21/85

22 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/rivtab21 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 Sid 22/85

23 Adress till REST tjänst för att söka och ladda ner loggarkiv från Säkerhetstjänster. Log Archive download REST service logdownload/archives Dokumentet Hämta loggarkiv är en bilaga till tjänstekontraktet för logg och finns bifogat i leveransen. Det beskriver REST-tjänsten för hur hämta arkiv fungerar med parametrar osv. Dokumentet som beskriver tjänsten ligger under mappstrukturen: <Lokal_sakerhetstjanst_linux>/doc/Hämta loggarkiv.pdf Sid 23/85

24 5 INSTALLATION AV DATABASSERVER Det är av prestandaskäl rekommenderat att tilldela lokala Säkerhetstjänsters databasserver en egen fysisk maskin. Servern bör vara flerkärnig med minst 8 GB RAM. För utökad support och funktionalitet såsom online-backup så finns samma version i Enterprise Edition-utförande som dock inte är kostnadsfri. Mer information om detta finns här: För att nyttja automatisk fail-over samt databasreplikering med MySQL så rekommenderas DRBD. Mer information om detta finns här: Den MySQL-användare som används kräver behörighet att kunna ändra, uppdatera och lägga till nya tabeller i de scheman som skapas för systemet, användaren behöver dock inte ha behörighet att kunna skapa nya scheman. Vid skapandet av scheman krävs en inloggning med en användare som har root-rättigheter. Konfigurationen av MySQL ska vara satt att använda UTF-8. UTF-8 används för att t.ex. svenska tecken ska skrivas korrekt. Öppna konfigurationsfilen my.cnf. Om ni inte vet vart ni hittar den, sök den med kommando: locate my.cnf. Öppna filen och säkerställ att det är UTF-8 som används. Se bilden nedan för hur det ska se ut. Figur 3: MySQL-konfiguration för UTF Installationsanvisningar för MySQL MySQL har officiella installationsanvisningar för Linux här: Skapa ny användare 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. Man behöver skapa två användare: # sak@localhost : användaren sak kan enbart ansluta från localhost. # sak@% : användaren sak kan ansluta från any hosts Användarna behöver inte ha behörighet att kunna skapa nya scheman. Skapandet av scheman krävs en inloggning med en användare som har root-rättigheter, vilket skapas under installationen av MySQL. Sid 24/85

25 1. Logga in i MySQL-prompten med exempelvis putty mot databasservern och skriv följande kommando: mysql u root p (Ange det lösenord som angetts) 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 Skapa upp databaserna När databasanvändare har skapats, ska databas scheman som lokala Säkerhetstjänster använder skapas upp. I installationspaketet (under strukturen <Lokal_sakerhetstjanst_linux>/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 inftyp logdb logreport Skript accesscontrol.sql audit.sql blkloc.sql commission_service.sql consent.sql idp.sql idp_data.sql inftyp.sql inftyp_data.sql logdb.sql logreport.sql logreport_data.sql Sid 25/85

26 logreportarchive logdlarchive metadata patientrelation sinkdb1 sp logreportarchive.sql logreportarchive_data.sql logdlarchive.sql metadata.sql patientrelation.sql sinkdb1.sql sp.sql Skapa upp databaserna: 1. För över samtliga komponenter som finns i katalogen <Lokal_sakerhetstjanst_linux>/db/mysql/ till er dedikerade MySQL-server. Om inte databashanteraren MySQL har installerats på servern ska det göras först. 2. Ställ er i katalogen ni i föregående steg förde över. Exempel: cd /tmp/mysql/ 3. Lista innehållet och stäm av att alla skripten som tabellen ovan refererar till finns i katalogen. Utöver de skript som listas i tabellen, ska skriptet create_databases_linux.sh listas. 4. Ändra behörigheter på skriptet create_databases_linux.sh. Skriptet kommer att sätta upp databaserna automatiskt. Exempel: chmod a+x create_databases_linux.sh 5. Lista innehållet i katalogen och säkerställ att create_databases_linux.sh har fått exekveringsbehörigheter. Se exempelbilden nedan. Sid 26/85

27 Figur 4: Samtliga databasscheman som ska skapas upp 6. Skriptet ska köras med följande parametrar: Användarnamn det användarnamn som används till databasmiljön. Lösenord det lösenord som används till databasmiljön. Prefix ej obligatoriskt. Ett prefix kan anges om så önskas. I exempelbilden nedan har vi angivit exempel_ som prefix. Exempel:./create_databases_linux.sh root password example_ Figur 5: Exekvering av create_databases_linux.sh 7. När skriptet körs kommer det fråga om ni önskar att skapa upp databaserna. 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å. Sid 27/85

28 Figur 6: Recreate databases 8. Skriptet kan även användas om databaserna redan existerar, men ska skapas om. Om inte databaserna finns uppsatta redan kommer följande felmeddelande visas: error: 'Can't drop database 'example_database ; database doesn't exist'. Detta kan ignoreras. Se utskriften i exempelbilden nedan. Figur 7: Meddelande som visas om inte databaserna finns sedan tidigare 9. Om databaserna fanns sedan tidigare visas istället följande meddelande: Database "example_accesscontrol" dropped. Se utskriften i exempelbilden nedan. Figur 8: Meddelande som visas om databaserna fanns sedan tidigare 10. Inget meddelande visas om att det gick bra att skapa databasen. Verifiera sedan att databaserna har skapats genom att logga in i mysql-prompten och exekvera kommandot: show databases; 11. För att kolla om det finns tabeller i ett schema kan man gå in i schemat (t.ex. use accesscontrol;) och ange kommando show tables; Sid 28/85

29 Figur 9: Lista tabeller 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. 5.2 Installationsanvisningar för MongoDB MongoDB har officiella installationsanvisningar för Linux här: Installera MongoDB på tre noder Nedan följer installationsanvisningar för MongoDB med replikering. Det innebär att installationen kommer att använda tre noder kallade Primary, Secondary och Arbiter. Att installera MongoDB på tre noder har två syften: Prestanda Fail-over I konfigurationen 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. Arbiterns roll i uppsättningen är att bedöma 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änsten 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 tar 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 single installation, men vi rekommenderar starkt att ovan beskriven trenodsinstallation används. Att installera MongoDB gör man enklast genom att installera med yum (se punkt 2.a). Detta kräver dock att man har Internet-access till dess repository, enligt baseurl ( i punkt 1 nedan. Sid 29/85

30 Har man inte tillgång till Internet från mongodb-noderna (p.g.a restriktioner i brandväggar), så får man ladda hem RPM-paket och kopiera dessa till respektive nod. Paketen som krävs är: mongo-10gen mongodb_1.x86_64.rpm mongo-10gen-server mongodb_1.x86_64.rpm ( Installera paketen med hjälp av RPM, genom att ställa sig i den mapp som paketen ligger i, se punkt 2. b). I din Linuxmiljö (i resten av instruktionen annoterat med #): 1. Skapa en ny fil (10gen.repo) /etc/yum.repos.d/10gen.repo Lägg till följande text: [10gen] name=10gen Repository baseurl= gpgcheck=0 enabled=1 2. a) Installera mongodb med kommandot yum. # yum install mongo-10gen mongo-10gen-server b) Installera mongodb med rpm. # rpm ivh mongo-10gen mongodb_1.x86_64.rpm # rpm ivh mongo-10gen-server mongodb_1.x86_64.rpm 3. Skapa en katalog för databasen på data-noder (ej Arbiter-noden) och sätt rättigheter: # mkdir -p /mongodb/data # chown mongod /mongodb/data # chgrp mongod /mongodb/data 4. Konfigurera data-noder (ej Arbiter-noden) genom att editera: /etc/mongod.conf Ändra dbpath: dbpath=/mongodb/data Lägg till replset: replset = rs_sak 5. Starta MongoDB-server på datanoderna # service mongod start Starta MongoDB-klienten via ett terminalfönster på noden (mongo1.exempel.com)som ska vara Master och konfigurera replikeringen. Sid 30/85

31 Starta MongoDB-klienten: # mongo Nu ska MongoDB-klienten vara startad och en ny prompt vara synlig (i resten av instruktionen annoterad med >). Initiera konfiguration av replikering genom att skriva: > rs.initiate() Visa replikeringsinformation genom att skriva: > rs.conf() Lägg till en slavnod genom att skriva: > rs.add( mongo2.exempel.com ) 6. Logga in på Arbiter-noden och skapa en katalog för konfiguration: I Linux-miljön: # mkdir /mongodb/data/arb # chown mongod /mongodb/data/arb # chgrp mongod /mongodb/data/arb 7. Konfigurera Arbiter-noden genom att editera: /etc/mongod.conf Ändra dbpath: dbpath=/mongodb/data/arb Lägg till replset: replset = rs_sak Ange portnummer: port= Starta MongoDB-server: # service mongod start 9. Gå tillbaka till Masternoden och dess MongoDB-klient och lägg till Arbiter-noden genom att i MongoDB-klienten skriva: > rs.addarb( mongo0.exempel.com:30000 ) 10. Nu ska rs.status()visa att replikering är konfigurerat med en MASTER, en SEOCONDARY och en ARBITER. Sid 31/85

32 Figur 10: Exempel på "rs.status()" Sid 32/85

33 11. Skapa ett Admin-konto i MongoDB-klienten: > db = db.getsiblingdb("admin") > db.adduser( { user: "admin", 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 för en användare se Mongos egen dokumentation. 12. Generera keyfile (som används för autentisering mellan noderna): I Linux-miljön: # mkdir -p /mongodb/srv/mongodb/keyfile # cd /mongodb/srv/mongodb/keyfile # openssl rand -base > keyfile Notera: Samma keyfile måste finnas på alla medlemsnoder (PRIMARY, ARBITER och alla SECONDARYs) så generera denna endast på första noden och kopiera till de andra. # scp keyfile root@mongo2.exempel.com:/mongodb/srv/mongodb/keyfile Filen får inte ha några grupp eller world rättigheter och ska ägas av mongod: # cd /mongodb/srv/ # chown mongod -R mongodb # chgrp mongod R mongodb # cd mongodb # chmod 600 keyfile 13. Aktivera autentisering och peka ut keyfile i alla noders konfigurationsfil: # vim /etc/mongod.conf auth = true keyfile = /mongodb/srv/mongodb/keyfile 14. Starta nu om ARBITER, SECONDARY och slutligen PRIMARY: # service mongod restart 15. Skapa ett Användarkonto: Detta kan uteslutas ifall man använder skriptet för skapandet av nödvändiga databaser som följer med installationen (se nedan). I mongo-klinten: > db = db.getsiblingdb("pdllog") > db.adduser( { user: "USER", pwd: "PASSWORD", roles: [ "readwrite" ] } ) Sid 33/85

34 5.2.2 Indexering Att rätt index är inlagda i databasen är helt avgörande för prestanda. Logga in med en användare som har skrivrättigheter i databasen för PDL-loggar och använd metoden ensureindex: Detta kan uteslutas ifall man använder skriptet för skapandet av nödvändiga databaser som följer med installationen (se nedan). Starta MongoDB-klienten: [root@db ~]# mongo MongoDB shell version: connecting to: TEST I MongoDB-klienten: > use admin switched to db admin > db.auth("_user_", "_PASSWORD_") 1 rs_sak:primary> use pdllog switched to db pdllog rs_sak:primary> show collections system.indexes system.users 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> db.log.stats() rs_sak:primary> show collections log system.indexes system.users Sid 34/85

35 5.2.3 Skapa nödvändiga databaser Med installationen medföljer ett konfigurationsskript för att skapa nödvändiga databaser, index och användare för Säkerhetstjänsten. Det ligger i installationskatalogen under <Lokal_sakerhetstjanst_linux>/db/mongodb/ med namnet mongo_db_setup.sh. För att kunna köra detta behöver MongoDB med klient vara installerat enligt ovan. Du måste ha skapat ett användarkonto med administratörsrättigheter och det ska i en replikerad miljö exekveras på noden som för tillfället kör som PRIMARY. Skriptet kräver användarnamn och lösenord för administratören, användarnamn och lösenord för Säkerhetstjänsten samt eventuellt ett prefix för tabellerna (collections) för den specifika installationen. Man kan också välja ifall man vill ta bort eventuellt existerande databas eller bara tabellen (collection). Argumentet dropdb kommer att radera databasen och frigöra diskutrymme medan utelämnande av detta argument bara kommer att ta bort eventuell tabell (collection) vilket inte resulterar i frigörande av diskutrymme. Skriptet måste ges exekveringsrättigheter i Linux-miljön t.ex. genom kommandot chmod. # chmod +x mongo_db_setup.sh Med växeln -h kan man få mer information om användingen av skriptet # mongo_db_setup.sh -h Usage: #mongo_db_setup.sh root <root-pw> <sak-user> <sak-pw> [prefix][dropdb] Exempel 1: # mongo_db_setup.sh 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.sh 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.sh 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.sh 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. Sid 35/85

36 5.2.4 Konfigurationsfil Följande är ett exempel på hur en MongoDB-konfiguration kan se ut. Denna fil hittar ni under: /etc/mongod.conf pidfilepath = /var/run/mongodb/mongod.pid logpath=/var/log/mongo/mongod.log logappend=true fork = true port = #Arbiter port #port = dbpath=/mongodb/data #Arbiter db path #dbpath=/mongodb/data/arb replset = rs_sak # Uncomment when User and Keyfile has been created #auth = true #keyfile = /mongodb/srv/mongodb/keyfile Notera plats för loggfilen (logpath) för eventuell felsökning av databasservern. Sid 36/85

37 6 INSTALLATION AV APPLIKATIONSSERVER Det är av prestandaskäl rekommenderat att tilldela lokala Säkerhetstjänsters applikationsserver en egen fysisk maskin. Servern bör vara multikärnig med minst 12 GB RAM. 6.1 Installera Java och JCE Installera java och tillägget JCE Java Cryptography Extension, enligt kapitel INSTALLATION AV LOKALA SÄKERHETSTJÄNSTER När databasserver och applikationsserver är förberedda kan programvaran för lokala Säkerhetstjänster installeras. Detta görs på applikationsservern. 7.1 Installera systemet på Linuxmiljö Installation NOTERA: Vid installationen krävs att användaren har root-privilegier, t.ex. root-användaren. Under installationen kommer det att skapas en användare ( sak ) som sedan används för att köra systemets processer. Det är även möjligt att använda en redan befintlig användare. 1. Kopiera över installationsmediat till en katalog på servern (nod1). 2. Gå in i installationskatalogen. Detta är viktigt för att installationsskriptet ska hitta tillhörande installationsfiler, dist.target. Dessa kommer beskrivas i större detalj i kommande steg. cd /<Lokal_sakerhetstjanst_linux>/install/ 3. Ändra rättigheten med hjälp av följande kommando på installationsfilen: chmod a+x install.sh 4. När installationen har startat ska man välja ett installations target. Detta är en inställningsfil med de parametrar som ska anges vid en installation. I installationspaketet finns endast en inställningsfil; dist.target. Denna ska väljas om man inte har förpreparerat ett specifikt target. Inställningsfilens parametrar ska då sättas manuellt under installationens gång. Dessa parametrar beskrivs i Tabell: Konfigurationsvärden lite längre ned. Notera: Info kolumnen i tabellen nedan som beskriver lite mer i detalj vad som efterfrågas. Sid 37/85

38 Det går att förpreparera ett dist.target. Detta kan vara lämpligt ifall man har en testmiljö som kommer installeras fler än en gång. För att utföra en sådan preparering, kopiera det target som följer med i installationspaketet och ge det ett lämpligt namn: cp -r /<Lokal_sakerhetstjanst_linux>/install/ resource/dist.target/ /<Lokal_sakerhetstjanst_linux>/install/ resource/test.target Öppna katalogen ni nyss kopierade. Filen dist.properties ska uppdateras med era adresser, portar och certifikat m.m. Se Tabell: Konfigurationsvärden för vägledning omkring de olika parametrarna. När detta är gjort kan installationen startas. Ni kommer nu få välja mellan dist.target och det nya target (exempelvis test.target) ni skapade. Starta installationen med följande kommando:./install.sh För installation av en singleserver gå till kapitel Installation av SingleServer. För installation av en fail-over lösning gå till kapitel Installation på första noden i en fail-over lösning Installation av SingleServer 1. Välj alternativ 2 (single instance Linux) och tryck enter. 2. Därefter görs de konfigureringar som behövs (för att använda defaultvärdet trycker man enter), se Tabell: Konfigurationsvärden. NOTERA: Parameteravsnittet för Terracotta-server utgår vid single instance. 3. Vänta på att installationsscriptet körs klart och att meddelandet Installation Completed! visas. Observera att det kan ta upp till 5 minuter att kopiera filerna. Installationsloggen 4. Ändra rättigheten på installationsfilen lokal Säkerhetstjänst med hjälp av kommandot: chmod a+x /share/sakerhetstjanst<version>/local/bin/sak_server 5. Installera lokal Säkerhetstjänst på första noden genom att exekvera kommandot: /share/sakerhetstjanst<version>/local/bin/sak_server setup_first 6. Sedan är det dags att starta upp systemet och installera de komponenter som skall användas. Gå till kapitel 8.2 Uppstart av lokal Säkerhetstjänst på första noden Installation på första noden i en fail-over lösning 1. Välj alternativ 1 (dist.target) och tryck enter. Sid 38/85

39 2. Välj alternativ 1 (complete with terracotta (two instances)) och tryck enter. 3. Därefter görs de konfigureringar som behövs (för att använda defaultvärdet trycker man enter), se Tabell: Konfigurationsvärden. Parameter Defaultvärde Info (Core setup) Java home directory --- Katalog där java finns installerat t.ex. /usr/java/jdk1.6_35 Shared path /share Säkerhetstjänstens delade diskarea (som används av alla noder). Här läggs t.ex. konfigurationsfiler och binärer. Install path /share/ Sakerhetstjanst<version>/local Säkerhetstjänstens delade filer läggs här (som används av alla noder). Här läggs t.ex. konfigurationsfiler och binärer. Working path /sakerhetstjansten/ Sakerhetstjanst<version>/local Säkerhetstjänstens arbetsyta, här sparas loggar och övriga filer för respektive nod. OSGi console port 1111 Konsol-porten för att ansluta till osgi. Service user sak Systemanvändare som Säkerhetstjänstens process kommer att köras som. Service usergroup sakgroup Användargruppen till systemanvändaren. (Http(s) setup) Host adress -- Säkerhetstjänstens publika adress (host.example.com). Path to server Identity PKCS#12 certificate Identity PKCS#12 certificate password Path to server common domain Identity PKCS#12 certificate -- Sökväg till där man sparat ned legitimeringscertifkatet(certificate.p12- fil) för Säkerhetstjänsten. -- Lösenord till legitimeringscertifikatet. -- Sökväg till där man sparat ned legitimeringscertifikatet för common domain (cd-certificate.p12-fil) för Säkerhetstjänsten. -- Lösenord till legitimeringscertifikatet. Identity PKCS#12 certificate password Ws port 8080 Port som Säkerhetstjänsten kommer att publiceras på. Sid 39/85

40 Https port, One-way SSL 8443 Https port för Säkerhetstjänstens administrationsgränssnitt. (Database setup) 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. (Common Domain http(s) setup) Https port, One-way SSL Host address on Common Domain Common Domain address 8446 Https port för Säkerhetstjänstens IdP webgränssnitt för CommonDomainCookie hantering -- Säkerhetstjänsten publika Common Domain adress (host.cd.example.com). -- Säkerhetstjänstens Common Domain adress (cd.example.com). (Terracotta server setup) Server #1 host address -- Serveradress till terracotta-mastern (nod1.example.com). Server #1 name -- Hostnamn till terracotta-mastern (nod1.example.com). -- Serveradress till terracotta-slaven (nod2.example.com). Server #2 host address Server #2 name -- Hostnamn till terracottaslaven(nod2.example.com). Install path /share/terracotta-<version> Terracotta-serverns delade filer sparas här(som används av mastern och slaven). Här sparas t.ex. konfigurationsfiler och binärer. Work directory /terracotta/terracotta-<version> Terracotta- servrarnas respektive arbetsyta, här sparas loggar och övriga filer för master/slave. DSO port 9510 JMX port 9520 L2 group port 9530 Java home directory --- Katalog där java finns installerat t.ex. /usr/java/jre1.6_35 Terracotta service user tc Systemanvändare som terracotta processen kommer att köras som. Terracotta service sakgroup Användargruppen till Sid 40/85

41 usergroup terracottaprocessens användare. (IdP http(s) setup) Host address -- IdPtjänstens publika adress (host.example.com). Path to IdP Identity PKCS#12 certificate -- Sökväg till där man sparat ned legitimeringscertifkatet(certificate.p12- IdP Identity PKCS#12 certificate password Https port,two-way SSL fil) för IdPtjänsten. -- Lösenord till legitimeringscertifikatet IdP webbgränssnitt för identifiera/autentisers certifikats användare (SITHS). Https port,one-way SSL 8445 IdP Web gränssnitt som används av SSO-service. (HSA-WS setup) Host name ws.hsa.sjunet.org Address 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 /svr-hsaws2/hsaws Context path för HSA-WS. (Mongo Database setup) Address replica server 1 Address replica server 2 -- Adress till MongoDB Primary server (server1.example.com) -- Adress till MongoDB Secondary server (server2.example.com) (Vid singelnodinstallation ange samma adress som server 1). Port Port för MongoDB. Username sak Användare för MongoDB. Password -- Lösenord MongoDB. Database name PDL log Database name archive search Database name audit log Log setup Log archive shared path Logreport setup Log reports online shared path pdllog archivesearch auditlog /share/archive MongoDB databas för PDL-loggar MongoDB databas för arkivsökning MongoDB databas för systemloggar Sökväg till den delade area där komprimerade arkiv av olika slag sparas. /share/logreports/online Sökväg till den delade area där komprimerade loggarkiv sparas. Log reports archive /share/logreports/archive Sökväg till den delade area där Sid 41/85

42 shared path Tabell: Konfigurationsvärden temporära arkiv lagras vid arkivsök. 4. Vänta på att installationsscriptet körs klart och att meddelandet Installation Completed! visas. Observera att det kan upp till 5 minuter kopiera filerna. 5. Ändra rättigheten på installationsfilen för Terracotta med kommandot: chmod a+x /share/terracotta-3.5.3/bin/terracotta_server 6. Installera Terracotta på första noden att exekvera kommandot: /share/terracotta-3.5.3/bin/terracotta_server setup_first 7. Ändra rättigheten på installationsfilen för lokal Säkerhetstjänst med hjälp av kommandot: chmod a+x /share/sakerhetstjanst<version>/local/bin/sak_server 8. Installera lokal säkerhetstjänst på första noden genom att exekvera kommandot: /share/sakerhetstjanst<version>/local/bin/sak_server setup_first Installation på andra noden i en fail-over lösning 1. Installera lokal Säkerhetstjänst på andra noden genom att exekvera kommandot: /share/sakerhetstjanst<version>/local/bin/sak_server setup_other 2. Installera Terracotta på andra noden genom att exekvera kommandot: /share/terracotta-3.5.3/bin/terracotta_server setup_other Linux-specifika inställningar på samtliga noder (nod1 och nod2) 1. Lägg till i /etc/security/limits.conf så att antalet max öppna filer för användarna sak utökas: sak - nofile Se till att ovanstående begränsningar läses in vid inloggning genom att lägga till följande rad i /etc/pam.d/login: session required /lib/security/pam_limits.so Sid 42/85

43 3. Eftersom saktjänsten använder en gemensam disk är det viktigt att användargruppen och sakanvändaren (sakgroup respektive sak) har samma UID på samtliga noder för att man inte ska få problem med åtkomst till vissa resurser. Verifiera därför att användaren och gruppen har samma UID på samtliga noder i filerna /etc/passwd och /etc/group. Vid behov så använd kommandona usermod respektive groupmod för att sätta ett nytt likadant UID. Sid 43/85

44 8 UPPSTART AV SERVER NOTERA: Om installation av singleserver utan Terracotta (alternativ 2) valdes, fortsätt till kapitel 8.2. Vid uppstart kommer först Terracotta-servrarna att startas och därefter startas den första noden för lokala Säkerhetstjänsterna. Den första noden kommer att ansluta sig till Terracotta-klustret som i det här läget inte innehåller något data (bundle states, om bundlarna är startade, stoppade, installerade, etc). Installera sedan de valda komponenterna för Säkerhetstjänsterna i Terracotta-klustret och starta dessa. När sedan de övriga servrarna startas och ansluter sig till klustret, t.ex. när nod 2 startas, så hämtar de all information om bundle states etc, dvs. övriga servrar kommer att bli en spegling av den första servern i klustret. 8.1 Uppstart av Terracotta Nod1: 1. Starta Terracotta-servern på första noden genom att exekvera: /etc/init.d/terracotta_server start Nod2: 2. Starta igång Terracotta-servern på andra noden genom att exekvera: /etc/init.d/terracotta_server start 3. Terracotta-servrarna har startat när den ena noden har statusen ACTIVE och den andra PASSIVE-STANDBY. Verifiera att Terracotta-servrarna har startat genom att exekvera: /etc/init.d/terracotta_server status Exempelutsskrift: nod1.example.se.health: OK nod1.example.se.role: ACTIVE nod1.example.se.state: ACTIVE-COORDINATOR nod1.example.se.jmxport: 9520 nod2.example.se.health: OK nod2.example.se.role: PASSIVE nod2.example.se.state: PASSIVE-STANDBY nod2.example.se.jmxport: 9520 Sid 44/85

45 8.2 Uppstart av lokal Säkerhetstjänst på första noden Nod1: 1. Starta igång lokal Säkerhetstjänst på första noden genom att exekvera: /etc/init.d/sak_server start 2. 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. 3. I systemkonsolen verifiera att systembundeln med id 0 har startat, dvs. har status ACTIVE, genom att exekvera kommandot: osgi> ss Utskriftsexempel: 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 finns installerad i systemet men är ej startad. STARTED Bundeln är startad men ännu ej aktiv. ACTIVE Bundeln är startad och aktiv. RESOLVED Bundeln är stoppad efter start. 4. Lista de komponenter som kan installeras med följande kommando: osgi> pkg list Id Name Description 1 Local server Includes all below services Sid 45/85

46 2 IDP component Bundles for IDP 3 Patient/Consent dialog Bundles for Patient/Consent dialog 4 Block local component Bundles for local block installation 5 Patientrelation component Bundles for patientrelation installation 6 Consent component Bundles for consent installation 7 Log local component Bundles for local log installation osgi> 5. Välj de komponenter som skall installeras; en eller flera. Alla lokala tjänster, välj alternativ Local server. Autentiseringstjänst, alternativ IdP component Patient/samtyckes dialog, alternativ Patient/Consent dialog Spärr, alternativ Block component. Patientrelation, alternativ Patientrelation component Samtycke, alternativ Consent component. Loggtjänst, alternativ Log local component. 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 autentiseringstjänst för att en användare ska kunna logga in och komma åt webbtjänsterna. Det kan t.ex. vara en annan befintlig lokal autentiseringstjänst (IdP) eller den nationella autentiseringstjänsten (IdP:n) eller så installeras den lokala autentiseringstjänsten tillsammans med den/de övriga lokala tjänsterna som skall installeras. Exempel: För att installera alla tjänster (komponent 1 i exemplet ovan): pkg install package 1 För att installera lokal spärrtjänst (komponent 4 i exemplet ovan): pkg install package 4 För att installera lokal loggtjänst med autentisering: pkg install package 3,7 Observera att de paket-id som anges i exemplet ovan kan variera. Hämta aktuellt paketid från kommandot pkg list. 6. Starta det installerade paketet med kommando: osgi> pkg start Vänta ett tag på att bundlarna startar upp, ca 2 min. 7. Verifiera att samtliga bundlar är uppstartade med kommandot dep. Kommandot listar alla bundlar som ännu ej startat. Exekvera kommandot: osgi> dep Sid 46/85

47 Utskriftsexempel: id Bundle State Unsatisfied dependencies Förklaring: 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. Ifall någon bundel ej startar igång, kan man testa att starta om säkerhetstjänster, kvarstår problemet får man starta felsökning. 8. Verifiera att alla beroenden är uppfyllda med kommandot: osgi> context state Utskriftsexempel: id Context State State Information Förklaring: 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. 9. Om enbart Spärrtjänsten eller enbart Loggtjänsten installerades i föregående steg visas följande fel : Figur 11Utskriftsexempel 1, Context state, Unresolved dependencies Block och logmodulen saknar beroenden i detta fall saknar en lokalt installerad loggtjänst och behöver konfigureras manuellt med adressen till en extern loggtjänst. För att göra detta editera konfigurationsfilen <installationskatalog>/sakerhetstjanst<version>/local/config/com.logica.se.bif.log.agent.impl xml. Ändra värdet för logstoreservice från Service till Proxy. Editera sedan konfigurationsfilen com.logica.se.bif.log.ws.proxyimpl xml i samma katalog. Ange adress (hostname) och portnummer (portnumber) till den externa loggtjänsten. Uppdatera nu com.logica.se.bif.log.agent.impl i systemkonsolen med kommando: osgi> update 305 (siffran till vänster om com.logica.se.bif.log.agent.impl i bilden ovan). Nu ska bara modulen com.logica.se.bif.ping.ws.factory sakna beroenden. Sid 47/85

48 Figur 12Utskriftsexempel 2, Context state, Unresolved dependencies Modulen com.logica.se.bif.ping.ws.factory väntar på en Loggtjänster Samtyckestjänst och en Patientrelationstjänst. Eftersom dessa tjänster inte installerades måste konfigurationen uppdateras. För att få bort felet så får man gå in i konfigurationskatalogen för com.logica.se.bif.ping.ws.factory och ta bort filerna som heter samtycke och patientrelation. Om man enbart installerat Samtycke så får man ta bort filerna för spärr och patientrelation osv. Gå till katalogen: <installationskatalog>/sakerhetstjanst<version>/local/config/com.logica.se.bif.ping.ws.factory.1.0.0/ Ta bort xml-filerna för de saknade tjänsterna. I fallet ovan consent.xml, log.xml, logreport.xml och patientrelation.xml. Uppdatera com.logica.se.bif.ping.ws.factory i systemkonsolen med kommando: osgi> update 63 (siffran till vänster om com.logica.se.bif.ping.ws.factory i bilden ovan). Efter uppdateringen skall felen ovan försvinna. Kontrollera med kommandot osgi> context state. Figur 13 Beroenden upplösta 10. Avsluta systemkonsolen med kommandot: osgi> disconnect 8.3 Anslut till webbgränssnittet Kontrollera att det går att ansluta till webbgränssnittet m.h.a en webbläsare på den första noden. Sid 48/85

49 1. 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 2. Anslut med SITHS-kort. 3. Verifiera att det går att ansluta till webbgränssnittet via en webbläsare ex När frågan om att servern inte har ett giligt certifikat visas, välj continue to this website. 8.4 Uppstart av lokal Säkerhetstjänst på övriga noder 1. Starta Säkerhetstjänstem på de övriga noderna (nod2) genom att exekvera: /etc/init.d/sak_server start 2. Vänta en stund, ca 5 min, på att systemet startar upp. 3. Logga in till systemkonsolen: telnet localhost Verifiera att samtliga bundlar är uppstartade med kommandot dep. Kommandot listar alla bundlar som ännu ej startat. Exekvera kommandot: osgi> dep Utskriftsexempel: id Bundle State Unsatisfied dependencies Förklaring: Listas inte någon bundel här så är samtliga bundlar startade, i annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel. 5. Verifiera att alla beroenden är uppfyllda med kommandot: osgi> context state Utskriftsexempel: id Context State State Information Förklaring: Listas inte någon bundel här så är samtliga bundlar startade, i annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel. 5. Avsluta systemkonsolen med kommandot: osgi> disconnect Sid 49/85

50 6. Verifiera att det går att ansluta till webbgränssnittet via en webbläsare ex. Sid 50/85

51 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. För att slå av/på filtren utför följande: 1. Gå in i systemkonsolen med: telnet localhost Inaktivera/aktivera autentiseringsfiltret med kommando: osgi> sys spfilter off osgi> sys spfilter -on 3. Inaktivera/aktivera behörighetsfiltret med kommando: osgi> sys authz off osgi> sys authz -on När konfigurationen av systemet är genomförd ska autentiseringsfiltret och behörighetsfiltret aktiveras. 9.1 Webbgränssnittet Anslut till Säkerhetstjänsters webbgränssnitt med den host-adress som ni angav i installationsskedet: Koppling till HSA-WS För att slutanvändare skall få tillgång till administrationssidan krävs minst ett medarbetaruppdrag för de SITHS-kort som används. Var god kontakta Inera för mer information kring anslutning och dokumentation [Ref 1]. Användaren och medarbetaruppdraget måste innehålla minst följande: Namn HSA Systemroll HSA -id för medarbetaren Beskrivning Användarens systemroll(er). För åtkomst till spärrar krävs rollen: BIF;Spärradministratör Användarens personliga HSA-id. Sid 51/85

52 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 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. Exempel: Om användaren innehar systemrollen BIF;Spärradministratör så ges tillgång till all funktionalitet rörande spärrar. Läs användarhandboken [Ref 2] för mer detaljerad information om åtkomst och regler i spärradministrationen Konfiguration av 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 i undermenyn Egenskapskä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 14: HSA-WS Egenskapkälla Sid 52/85

53 9.3 PU-tjänsten PU-tjänsten behöver endast konfigureras ifall någon av följande tjänster är installerade: samtycke, patientrelation eller spärr. Konfiguration för PU-tjänsten ligger i menyn Administration i undermenyn Generell Konfiguration. Välj sedan konfiguration Resident Information Lookup Service Impl Se exempelbilden nedan. Figur 15: Konfiguration av PU-tjänsten 9.4 Konfiguration av spärr Spärr kan konfigureras upp att antingen gå mot tjänsteplattformen eller för att köras lokalt. Exempelbilderna nedan visar hur konfigurationen ser ut mot tjänsteplattformen. Hänvisade hostnamn och portar för konfigurationerna som beskrivs nedan ska konfigureras mot tjänsteplattformen. Konfigurationer behöver endast göras om tjänsten Spärr är installerad. Samtliga konfigurationer av tjänsten ligger i menyn Administration i undermenyn 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. Sid 53/85

54 9.4.1 Block Local Service Se exempelbilden nedan för konfigurationen. 1. Öppna konfigurationen Block Local Service National block interface ska vara satt till Proxy (Den nationella Spärrtjänsten stödjer replikering via RIV TA 2.0 och RIV TA 2.1. Det är rekommenderat att konsultera med Inera om vilken version som skall användas för replikeringen men i dagsläget ska National RIVTA version ska vara satt till Riv 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 bör 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. Sid 54/85

55 Figur 16: Block Local Service Block Web Application Se exempelbilden nedan för konfigurationen. 1. Öppna konfigurationen för Block Web Application 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. Sid 55/85

56 Figur 17: Block Web Application Block National Webservice Proxy for RIV Se exempelbilden nedan för konfigurationen. 1. Öppna konfigurationen Block National Webservice Proxy for RIV 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 18: Block National Webservice Proxy for RIV Block Common Webservice Proxy v Se exempelbilden nedan för konfigurationen. 1. Öppna konfigurationen Block Common Webservice Proxy v Ange Context path, Host name och Port number. Sid 56/85

57 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur 19: Block Common Webservice Proxy Block Common Webservice Proxy for National v Se exempelbilden nedan för konfigurationen. 1. Öppna konfigurationen Block Common Webservice Proxy for National v 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 20: Block Common Webservice Proxy for National Sid 57/85

58 9.4.6 Block National Accesscontrol Webservice Proxy Se exempelbilden nedan för konfigurationen. 1. Öppna konfigurationen Block National Accesscontrol Webservice Proxy 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 21: Block National Accesscontrol Webservice Proxy 9.5 Konfiguration av loggtjänsten PDL-loggar kan styras att antingen gå mot lokalt installerad loggtjänst eller så kan man för tjänsterna lokal spärr, samtycke och patientrelation välja att logga dessa händelser till den nationella loggtjänsten. Detta görs genom att konfigurera 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. Exempelbilderna nedan visar hur konfigurationen styr PDL-loggar att lagras på en hotelltjänst. Samtliga konfigurationer av tjänsten Logg ligger i menyn Administration i undermenyn Generell Konfiguration. För att anslutningen till den externa loggtjänsten ska fungera måste förvaltningsorganisationen för nationella tjänster kontaktas för att öppna upp access till tjänsten. Kontakta Ineras förvaltning i god tid före driftstart [Ref 1] Log Agent Impl Öppna konfigurationen Log Agent Impl Logstore service ska vara satt till Proxy. Sid 58/85

59 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur 22 Log Agent Impl Log WS Proxy Impl Öppna konfigurationen Log WS Proxy Impl Ange Host name och Port number för loggtjänsten som ska användas. 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur 23 Log WS Proxy Impl Sid 59/85

60 9.6 Konfiguration av samtycke Tjänsten samtycke kan konfigureras upp att antingen gå mot tjänsteplattformen eller för att köras lokalt. Exempelbilderna nedan visar hur konfigurationen ser ut mot tjänsteplattformen. Dessa konfigurationer behöver endast göras om tjänsten är installerad. Samtliga konfigurationer av tjänsten samtycke ligger i menyn Administration i undermenyn Generell Konfiguration. Hänvisade host-namn och portar för konfigurationerna som beskrivs nedan ska konfigureras mot tjänsteplattformen Consent Webservice Proxy Öppna konfigurationen Consent Webservice Proxy Ange Context path, Host name och portnummer. 6. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur 24: Consent Webservice Proxy ConsentPDL GWT Application Öppna konfigurationen ConsentPDL GWT Application Consent service ska vara satt till Proxy. 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Sid 60/85

61 Figur 25: ConsentPDL GWT Application 9.7 Konfiguration av patientrelation Tjänsten patientrelation kan konfigureras upp att antingen gå mot tjänsteplattformen eller för att köras lokalt. Exempelbilderna nedan visar hur konfigurationen ser ut mot tjänsteplattformen. Dessa konfigurationer behöver endast göras om tjänsten är installerad. Samtliga konfigurationer av tjänsten patientrelation ligger i menyn Administration i undermenyn Generell Konfiguration. Hänvisade host-namn och portar för konfigurationerna som beskrivs nedan ska konfigureras mot tjänsteplattformen Patientrelation Web Application Öppna konfigurationen Patientrelation Web Application Patientrelation service ska vara satt till Proxy. 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur 26: Patientrelation Web Application Patientrelation Webservice Proxy Öppna konfigurationen Patientrelation Webservice Proxy 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. Sid 61/85

62 Figur 27: Patientrelation Webservice Proxy 9.8 Konfiguration av hämtningstjänsten Klicka på menyn Generell Konfiguration under huvudmenyn Administration. I tabellen som visas, klicka på den blå pilen för konfigurationen Log Download Archive. I tabellen nedan så måste man konfigurera följande: 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. Context Path Sökväg till tjänsten för att hämta loggarkiv. (Default: /logdownload/archives/) Host name Domännamn till nationella tjänsten Port Portnummer till nationella tjänsten Protocol https eller http (Default: https) Om man vill aktivera schemaläggaren så den hämtar gårdagens (eller från när den hämtade senast) arkiv per automatik så bockar man i Scheduler enabled. Man behöver även konfigurera när schemaläggaren ska starta, det görs med formatet HH:mm (00:00 23:59) Default: 02:00. Sid 62/85

63 Figur 28: Log Download Archive 9.9 Ta bort root-certifikat för test vid en produktionssättning I och med produktionssättning av systemet bör alla CA rotcertifikat som använts för test tas bort ur listan med konfigurerade certifikatsutfärdare. Detta görs i syfte att utesluta att certifikat för testsyften kan ges någon form av åtkomst till systemet. Säkerställ att inga tester skall genomföras i systemet innan certifikaten tas bort. En eller flera förtroendekällor kan ha certifikatutfärdaren under användning. För att ta bort en certifikatutfärdare måste därför först den webbserver som kopplingen går mot avmarkeras i Webbserveradministrationen. Observera att när en webbserver skall tas bort så måste först de konnektorer som är kopplade till denna att tas bort. Kontrollera att inga förtroendekällor använder certifikatutfärdaren ni vill ta bort, genom följande anvisningar: 1. Klicka på soptunnan som tillhör den certifikatutfärdaren ni vill ta bort. Se bilden nedan ( Sid 63/85

64 Figur 29: Borttagning av certifikatsutfärdare 2. Navigera till menyvalet Webbserver om meddelandet En eller flera förtroendekällor använder denna certifikatsutfärdare. För att kunna ta bort denna certifikatsutfärdare måste den avmarkeras i Webbserveradministrationen visas. Figur 30: Vy över Webbserver Börja med att ta bort den konnektor som är kopplad till webbservern. Gör så här: 1. Identifiera under tabellen Konnektorer vilken konnektor som skall tas bort. 2. Klicka på soptunnan längst till höger på den valda raden. Bilden ovan illustrerar vyn. Fortsätt sedan med att ta bort den berörda webbservern: 1. Klicka på soptunnan under menyn Webbservrar. Sid 64/85

65 Notera att det inte går att ta bort en webbserver om en konnektor är kopplad till denna. Följande felmeddelande visas i ett sådant scenario: [Webbserverns namn] har en eller flera konnektorer kopplad. 2. Bekräfta borttagningen genom att klicka på Ja eller avbryt genom att klicka på Tillbaka. Återgå till menyn för Certifikatutfärdare. Efter att kopplingarna är borttagna kan certifikatutfärdarna dedikerade för testsyften tas bort. Upprepa stegen ovan tills alla certifikatutfärdare för testsyften är borttagna från systemet Konfiguration av CDC CDC är en typ av webbkaka. För att hålla rätt på vilken IdP som medarbetaren använde senast, för att på så vis få SingleSignOn när man har flera IdP:er, används CDC. Kortfattat kan man beskriva detta att SP:ar läser ifrån den gemensamma kakan, medan IdP:er skriver till den. Konfigurering av CDC sker i menyerna SP SAML (under huvudmenyn Administration) och i IdP SAML (under huvudmenyn Autentisering). 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. CDC - SP SAML Bocka i kryssrutan om SP ska läsa från CDC. Se bilden nedan. Figur 31: Konfiguration för CDC i SP SAML CDC - IdP SAML Bocka i kryssrutan om IdP ska skriva till CDC. Se bilden nedan. Figur 32: Konfiguration för CDC i IdP SAML Sid 65/85

66 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 finns det mer information om systemets behörighetskriterier [Ref 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 dennes SAML-intyg. Användare som autentiserar sig till systemet med ett SITHS-kort får sina egenskaper från HSA. En egenskap kan exempelvis vara BIF;Spärradministratör som innebär att användaren har behörighet att hantera spärrar. Samtliga vårdgivare som ska använda sig av någon av tjänsterna som har installerats måste specificera detta i de interna reglerna som läses in. En användare hämtar sina egenskaper från HSA-katalogen och sedan valideras dessa egenskaper mot de inlästa reglerna för att kontrollera att användaren har behörighet till någon installerad tjänst i systemet. Uppsättning av lokala behörighetsregler kan antingen göras med ett medföljande verktyg (som beskrivs i följande avsnitt) eller manuellt. Se Sid 66/85

67 APPENDIX A Skapa behörighetsregler och metadata manuellt för manuell uppsättning av lokala behörighetsregler Uppsättning 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_linux>/rules/regler_default_lokal.xml. Reglerna skapas med en applikation som följer med i installationspaketet tillsammans med mallen som beskrevs ovan. Applikationen ligger under mappstrukturen: <Lokal_sakerhetstjanst_linux>/rules/RuleConfigGenerator/RuleConfigGenerator.exe. Starta applikationen RuleConfigGenerator.exe. Applikationen består av två huvudfunktioner: Generering av behörighetsregler. 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 33: Generering av behörighetsregler för användare I samma katalog där ni hittar regelapplikationen, finns textfilen CareProviders.txt som ska modifieras med era vårdgivare. För att sätta upp behörighetsregler för er lokala installation: Sid 67/85

68 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 textfil med knappen Browse i fältet Care provider file path. Se förtydligande bild nedan. Applikationen hittar filen själv om ni sparade den med samma namn i den katalog som ni modifierade den i. Figur 34: Ange sökvägar till nödvändiga filer 4. Välj fliken Generate rules i applikationen. 5. Läs in regelmallen med knappen Browse i fältet Rule template file path. Ni hittar mallen i installationspaketet under mappstrukturen <Lokal_sakerhetstjanst_linux>/rules/regler_default_lokal.xml. 6. Klicka på knappen Generate Rules. Spara era regler på ett lämpligt ställe. Reglerna som ni skapat kommer att läsas in i systemet. Se kapitel Läsa in regler Läsa in regler 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. Läs in regler: 1. Öppna Säkerhetstjänsters OSGi-konsol. Ange den adress och port till konsolen som valdes i installationsskedet. Exempelvis: Telnet localhost Ange kommando: sys acc import file:///<sökväg till er anpassade regel-fil> 3. Tryck på Enter för att exekvera kommandot. Reglerna har nu lästs in i systemet. Sid 68/85

69 10.2 IdP/SP Metadata Metadata är en viktig beståndsdel av SAML och innehåller information som IdP:n och SP:n kommunicerar med varandra för att bestämma om ett system har den behörighet som krävs för att bli tilldelad åtkomst. Om en lokal autentiseringstjänst är installerad måste metadata-filer för IdP:en och SP:n exporteras och importeras i menyn SAML Metadata. Metadata-filer anpassade för konsumentsystem till Säkerhetstjänster importeras till systemet på samma sätt som beskrivs nedan för Säkerhetstjänsters IdP/SP metadata. Exportera Säkerhetstjänsters IdP/SP metadata: 1. Gå in i webbgränssnittet. Öppna menyn Autentisering och sedan undermenyn IdP SAML. 2. Fyll i formuläret IdP Metadata med era valda kontaktuppgifter. Dessa kommer att specificeras på metadata-filen. 3. Uppdatera informationen genom att klicka på knappen Spara (längst ner på sidan). 4. Exportera IdP metadata med knappen Exportera. Filen kommer läsas in i ett senare skede, så spara den på ett lämpligt ställe. 5. Öppna nu menyn Administration och sedan undermenyn SP SAML. 6. Utför motsvarande procedur som tidigare (steg 2-4) för SP metadata Behörigheter för konsumentsystem eller för tjänsteplattformen Metadata är till för dels att IdP ska lita på olika SP:er. Det är också till för att ge externa vårdsystem och tjänsteplattformen tillgång att använda Säkerhetstjänster. Till skillnad från användaren som får sina egenskaper från HSA-WS, hämtar systemen sina egenskaper från inläst metadata. 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. Tjänsteplattformen beskrivs i kapitel Tjänsteplattformen*. System som skall ges behörighet till Säkerhetstjänster måste beskrivas i en metadata-fil där dess egenskaper anges. I leveransen ingår det en mall för metadata. Metadata-filen måste anpassas efter följande kriterier: Systemets HSA-id (entityid). HSA-id för de vårdgivare som ingår i konsumentsystemet (endast för uppsättning av metadata mot vårdsystem). Sid 69/85

70 Mallen ligger under mappstrukturen: <Lokal_sakerhetstjanst_linux>/example/metadata/example-system-metadata.xml. Metadatafilen skapas med en applikation som följer med i installationspaketet tillsammans med mallen som beskrevs ovan. Starta applikationen RuleConfigGenerator.exe. Applikationen består av två huvudfunktioner: Generering av behörighetsregler. Generering av metadata för externa system (exempelvis vårdsystem eller tjänsteplattformen). Funktionerna är uppdelat under två flikar. Bilden nedan visar fliken Generate metadata, som används vid skapandet av metadata för externa system. För uppsättning av metadata till era vårdsystem ska textfilen CareProviders.txt modifieras med era vårdgivare. Filen hittar ni i regelgeneratorns katalog. Figur 35: Generering av behörigheter för konsumentsystem Anpassa metadata för konsumentsystem eller mot 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. Sid 70/85

71 Figur 36: Beskrivningar av samtliga knappar och fält i fliken Öppna konsumentsystemets eller tjänsteplattformens klientcertifikat för att ta reda på vilket HSA-id systemet har och som ska specificeras i metadata-filen. 1. Öppna certifikatets leg.cer fil och klicka på Details. 2. Bläddra i listan som visas. Klicka på informationsfältet Subject. 3. En informationsruta visas. Det Serialnumber som visas i rutan är certifikatets serienummer, dvs. det HSA-id som ni ska specificera i metadata-filen som ni anpassar till systemet. 4. Observera: steg 4-6 behöver endast göras vid uppsättning av metadata för vårdsystem. Öppna textfilen CareProviders.txt och ange era vårdgivare (en per rad). Följ instruktionerna som ges i filen. 5. 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. 6. Läs in er modifierade textfil med knappen Browse i fältet Care provider file path. Se förtydligande bild nedan. Applikationen hittar filen själv om ni sparade den med samma namn i den katalog som ni modifierade den i. 7. Välj fliken Generate metadata i applikationen. 8. Ange det HSA-Id för konsumentsystemet som ni hämtade i steg 3 i fältet Entity id (Serial No). Se bilden ovan. 9. Läs in regelmallen med knappen Browse i fältet Meta template file path. Ni hittar mallen i installationspaketet under mappstrukturen <Lokal_sakerhetstjanst_linux>/example/metadata/example-system-metadata.xml. 10. Bocka endast i kryssrutan Generera för Tjänsteplattformen om metadata-filen ska sättas upp mot tjänsteplattformen. I annat fall, fortsätt till steg Klicka på knappen Generate Metadata. Spara metadata-filen på ett lämpligt ställe. Metadata-filen ni skapat ska läsas in i systemet. Se kapitel 10.4 Inläsning av metadata. Sid 71/85

72 10.4 Inläsning av metadata IdP/SP metadata, samt eventuellt övriga metadata-filer anpassade för externa system till Säkerhetstjänster måste läsas in i systemet. Denna import av metadata sker i Säkerhetstjänster webbgränssnitt. Importera metadata till Säkerhetstjänster: 1. Öppna menyn Administration och sedan undermenyn SAML Metadata. 2. Klicka på knappen Välj fil. Välj en av era metadata-filer (dvs. IdP/SP metadata, samt eventuell metadata skapad för externa system). 3. Klicka på Importera. 4. Den importerade metadata-filen ska nu visas i tabellen Importerade IdP Metadata Entiteter (IdP metadata) och/eller i tabellen Importerade SP Metadata Entiteter (SP metadata) Systemegenskaper Interna tjänster får egenskaper från de inlagda systemegenskaperna. För att de interna tjänsterna ska få anropa andra interna tjänster så måste systemegenskapen systemrole bli tilldelad värdet Internal. En intern tjänst kan exempelvis kräva att ett anrop som kommer från en annan intern tjänst ska innehålla en viss vårdgivare. De vårdgivarna måste då läggas till i systemegenskaperna för att anropet ska beviljas behörighet till tjänsten. Lägg till systemegenskapen Internal: 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. 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. 5. Upprepa steg 1-4 för samtliga vårdgivare som ska läggas till. Se exempelbilden nedan för hur det kan se ut. Vårdgivarna i bilden är fiktiva. Sid 72/85

73 Figur 37: Systemegenskaper 10.6 Extern Autentiseringstjänst Om ingen lokal autentiseringstjänst installerades, måste systemet ansluta sig till en extern autentiseringstjänst/idp för att upprätthålla PDL. Detta görs genom att exportera SP metadata för det lokala system och skicka denna XML-fil till organisationen som tillhandahåller autentiseringstjänsten. Metadata-filen måste importeras i deras system samt att dess (autentiseringstjänstens) metadata-fil måste importeras i det lokala systemet (korsvis exportering och inläsning) Aktivering av autentiseringsfilter och åtkomstkontroll Avsluta konfigurationsavsnittet och aktivera autentiserings- och behörighetsfiltret från systemkonsolen. För att slå på filtren utför följande: 1. Gå in i systemkonsolen med: telnet localhost Aktivera autentiseringsfiltret med kommando: osgi> sys spfilter on 3. Aktivera behörighetsfiltret med kommando: osgi> sys authz -on Kontrollera därefter att webbgränssnittet nu kräver SITHS-kort inloggning genom att gå till webbgränssnittet för lokala Säkerhetstjänster via en webbläsare: Sid 73/85

74 11 SYSTEMADMINISTRATION 11.1 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: Där testas inloggningsförfarandet med val av certifikat och val av medarbetaruppdragsval Start och stopp Stoppa lokal Säkerhetstjänster Om en nod i klustret behöver stoppas, exekvera kommandot: /etc/init.d/sak_server stop Starta lokal Säkerhetstjänster Om en nod i klustret behöver startas, exekvera kommandot: /etc/init.d/sak_server start Stoppa Terracotta Om en Terracotta-nod behöver stoppas, exekvera kommandot: /etc/init.d/terracotta_server stop Starta Terracotta Om en Terracotta-nod behöver startas, exekvera kommandot: /etc/init.d/terracotta_server start 11.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. Verifiera att samtliga bundlar är uppstartade med kommandot context state. Det kommandot listar alla bundlar som inte startat ännu. Exekvera kommandot: osgi> context state Se Figur: OSGi context state exempel, nedan av kommandot context state: Sid 74/85

75 Figur 38: Exempelutskrift av OSGi context state Förklaring: Listas inte någon bundel här så är samtliga bundlar startade, i annat fall upprepa kommandot i intervallet tills kommandot inte listar någon bundel. Kommandot context state används för att verifiera att alla beroenden är uppfyllda. Avsluta systemkonsolen med kommandot: osgi> disconnect Aktivering och avaktivering av autentiseringsfilter Autentiseringsfiltret kontrollerar om en aktör måste logga in med SITHS-kort eller tjänstecertifikat. Observera att en aktiverad behörighetskontroll kräver att autentiseringsfiltret är aktiverat. För att slå av/på filtren utför följande: 1. Gå in i systemkonsolen med: telnet localhost Inaktivera/aktivera autentiseringsfiltret med kommando: osgi> sys spfilter off osgi> sys spfilter -on 3. Inaktivera behörighetsfiltret med kommando: osgi> sys authz off osgi> sys authz -on 11.4 Systemlogg för Linux producerar en logg som avser teknisk förvaltning och felsökning som lagras på filsystemet under uppstartsfasen. Systemlog lagras i följande katalog (enligt standardinstallationen för Linux): <sökväg till installerad säkerhetstjänst>/sakerhetstjanst<version>/local/log/ Systemet lagrar loggarna i databasen (schemat audit) och kan nås genom kommandot audit från systemkonsollen, se kapitel Sök i systemlogg. Om inte databasen är uppsatt för att kunna hantera systemloggar (som sker i installationsskedet av Säkerhetstjänster) skriver Säkerhetstjänster backup av systemloggar till fil. Sid 75/85

76 Sök i systemlogg Logga in i systemkonsollen och exekvera något av följande kommandon: audit search level error audit search level error time 1h audit search time 1h audit search time 5m (Alla error loggar) (Alla error loggar senaste timmen) (Alla loggar senaste timmen) (Alla loggar från de senaste 5 minuterna) 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 så fort som loggfunktionen är startad 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 Java-processen på applikationsserver och kontrollera att "monitor"-sidan svarar ( 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. Sid 76/85

77 12 FÖRVALTNING OCH UNDERHÅLL 12.1 Hämtning av arkivloggar från den nationella Säkerhetstjänster Vid en ny installation så kan man vilja hämta loggarkiv för den egna vårdgivaren/vårdgivarna från nationella Säkerhetstjänster. Det kan göras manuellt och via en schemaläggare. För konfiguration av hämtningstjänsten, se kapitel 9.8 Konfiguration av hämtningstjänsten Manuell hämtning Följande kommandon finns att tillgå i OSGi-konsolen: archive dl <parametrar> archive status <parametrar> Figur 39: Kommandon för manuell hämtning av arkivloggar Exempel 1 - Hämta alla arkivloggar från 1:a januari 2013 archive dl -from Exempel 2 - Hämta alla arkivloggar från 1:a januari 2013 till 1:a augusti 2013 archive dl -from to Exempel 3 Visa status på alla hanterade arkivloggar från 1:a januari 2013 archive status -from Exempel 4 Visa status på alla hanterade arkivloggar som har gått fel archive status code Error Exempel 5 Testa anslutningen mot nationella säkerhetstjänsten archive status test Sid 77/85

78 Schemaläggare För att slippa hämta arkivloggar manuellt så finns det möjlighet att aktivera en schemaläggare som hämtar arkivloggar automatiskt. 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 Hämtning av nationella arkiv För att den lokala installationen av Säkerhetstjänster ska kunna hämta arkiv från nationella Säkerhetstjänster så behöver nationella Säkerhetstjänster innehålla den lokala installationens metadata. För att skapa upp metadata till nationella Säkerhetstjänster, se kapitel Anpassa metadata för konsumentsystem konsumentsystem. Notera att den lokala installationen är ett konsumentsystem till nationella Säkerhetstjänster. Kontakta en behörig administratör av nationella Säkerhetstjänster för att sedan läsa in den lokala installationens metadata Periodiskt underhåll Läs kapitel 11.4 för information angående hur systemloggar lagras och hur de loggas med hjälp av Loggtjänsten. Kapitel 11.3 beskriver hur systemet kan hanteras och kontrolleras i systemkonsolen (OSGi) Övervakning Applikationsservern publicerar en mängd systemmoduler som kan övervakas över JMXprotokollet som är Javas teknik för generell övervakning. Med valfritt JMX-verktyg kan applikationsserverns webbtjänster övervakas, se kapitel 4.2 för gällande port. Observera att JMX-porten inte får tillgängliggöras för någon annan part annat än den maskin som skall sköta övervakningen. Standardinställningarna för JMX kan ändras i <installationskatalog>\localsakerhetstjanstconfig.xml Alla systemkomponenter publiceras som monitorerbara JMX-bönor. Nedan visas en exempelbild från programmet JConsole som medföljer Java SE. Sid 78/85

79 Figur 40: 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 delta.size name total.exceptions total.maxtime total.meantime total.mintime total.packets 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. Antal paket/anrop som ingår i delta-beräkningarna, t.ex. "de 50 senaste". 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. Sid 79/85

80 12.4 Uppgradering kan mjukvaruuppgraderas då nyare versioner av produkten görs tillgängliga. Mer information om detta ges för respektive uppgradering. Var god kontakta Inera för information kring aktuella versioner [Ref 1]. Sid 80/85

81 13 AVINSTALLATION Avsnittet innehåller anvisningar för avinstallation av lokala Säkerhetstjänster. Avinstallationen tar bort processerna för lokal Säkerhetstjänst samt Terracotta Avinstallera lokal Säkerhetstjänst Börja med att stoppa tjänsten, exekvera kommandot: /etc/init.d/sak_server stop Därefter avinstallera tjänsten, exekvera kommandot: /etc/init.d/sak_server removedaemon Tjänsten ska tas bort på samtliga noder som Säkerhetstjänster är installerad på. Upprepa samma procedur beskriven ovan på samtliga noder Avinstallera Terracotta Det är alltid rekommenderat att stoppa slave-noden för terracottan först. För att veta vilken nod det gäller, exekvera kommandot: /etc/init.d/terracotta_status Börja med att stoppa tjänsten (slave-noden först), exekvera kommandot: /etc/init.d/terracotta_server stop Därefter avinstallera tjänsten, exekvera kommandot: /etc/init.d/terracotta_server removedaemon Upprepa proceduren ovan för samtliga terracotta-noder Upprensning När systemet är avinstallerat kan man genomföra en upprensning av resterande Säkerhetstjänster-relaterad data. De kataloger då som ska tömmas är följande: /terracotta (på samtliga noder) /sakerhetstjansten (på samtliga noder) /share (behövs endast rensas på en nod, då detta är en delad diskarea). /share2 (även denna behövs endast rensas på en nod). Sid 81/85

82 I. APPENDIX A Skapa behörighetsregler och metadata manuellt Regler och metadata kan skapas upp manuellt utan att använda applikationen som beskrevs tidigare. Det är lämpligt att använda texteditorn Notepad++ för att skapa regler/metadata enligt instruktionerna nedan Manuell hantering av behörighetsregler I leveransen 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_linux>/rules/regler_default_lokal.xml. Reglerna är uppdelade för respektive tjänst. Om exempelvis endast autentiseringstjänsten och spärr är installerade, är det endast dessa tjänster som måste anpassas för vårdgivarna som ska använda dem. Om en full installation har valts så ska samtliga tjänster anpassas. Bilden nedan visar ett exempel på tjänsten spärr i reglerna. Figur 41: Regler för tjänsten Spärr utan vårdgivare Observera det rödmarkerade värdet i bilden. Detta värde, ${replace_this_careprovider}, är det som ska bytas ut till det specifika HSA-id:t för er vårdgivare. Kopiera raden för varje vårdgivare ni har och som ska ges behörighet. Bilden nedan visar ett exempel på hur det kan se ut när fyra fiktiva vårdgivare har blivit specificerade. Sid 82/85

83 Figur 42: Regler för tjänsten Spärr med vårdgivare När reglerna är skapade ska de läsas in i systemet. Se beskrivning för detta i kapitel Läsa in regler Manuell hantering av metadata för konsumentsystem Vårdsystem som skall ges behörighet till systemet måste beskrivas i en metadata-fil där dess egenskaper anges. I leveransen ingår det en mall för metadata. Metadata-filen måste anpassas efter följande kriterier: HAS-id för de vårdgivare som ingår i konsumentsystemet. Konsumentsystemets HAS-id (entityid). Mallen ligger under mappstrukturen: <Lokal_sakerhetstjanst_linux>/example/metadata/example-system-metadata.xml. Bilden nedan visar ett exempel på hur en metadata-fil som hanterar den fiktiva vårdgivaren ExampleCareProvider_1 ser ut. Värdet i entityid är konsumentsystemets HSA-id. Sid 83/85

84 Figur 43: Anpassning av metadata för konsumentsystem Öppna konsumentsystemets klientcertifikat för att ta reda på vilket HSA-id konsumentsystemet har som ska specificeras i metadata-filen. 1. Öppna certifikatets leg.cer fil och klicka på Details. 2. Bläddra i listan som visas. Klicka på informationsfältet Subject. 3. En informationsruta visas. Det Serialnumber som visas i rutan är certifikatets serienummer, dvs. det HSA-id som ni ska specificera i metadata-filen som ni anpassar till systemet. 4. Öppna mallen för metadata-filen. <Lokal_sakerhetstjanst_linux>/example/metadata/example-system-metadata.xml 5. Ange konsumentsystemets HSA-id för värdet i entityid. 6. Kontrollera att värdet för urn:sambi:names:attribute:systemrole är satt till System. 7. Byt ut värdet ExampleCareProvider_1 till HSA-id:et för den vårdgivare ni vill lägga till. 8. Kopiera raden för varje vårdgivare som ska ingå i filen och följ sedan instruktionen som gavs i föregående steg. Bilden nedan exemplifierar hur en metadata-fil kan se ut med flera vårdgivare. Observera att vårdgivarna är fiktiva och ska ersättas med korrekt HSA-id för respektive vårdgivare. Sid 84/85

85 Figur 44: Exempel på en metadata-fil anpassat för ett konsumentsystem Läs in metadata-filen enligt beskrivningarna i kapitel 10.4 Inläsning av metadata. Sid 85/85