Sikkerhed i Stamdatamodulet KOMBIT

Sikkerhed i Stamdatamodulet KOMBIT

1 Indholdsfortegnelse 1 Indholdsfortegnelse... 2 2 Historik... 3 3 Oversigt... 4 3.1 Relevante OCES-detaljer... 4 4 Overholdelse af persondatalov mv.... 5 5 Importer... 6 6 Administrator-GUI... 6 6.1 Adgang... 6 6.2 Logning... 6 7 Replikeringstjeneste... 6 7.1 Adgang... 7 7.2 Logning... 7 8 Cpr-opslagskomponent... 7 8.1 Adgang... 7 8.2 Logning... 7 Sikkerhed 2

2 Historik Dato Version Ændring Ansvarlig 3. maj 2011 1.0 Initiel version OFO 19. maj 2011 1.1 Rettelser efter KOMBIT review SEF 9. juni 2011 1.2 Rettelser efter KOMBIT-review OFO 20. juni 2011 1.3 Cpr-opslagskomponent tilføjet FRJ, OFO Sikkerhed 3

3 Oversigt Stamdatamodulet består af følgende komponenter: Importer. Administrator-GUI. Replikeringstjeneste. Cpr-opslagskomponent. Database Administrator-GUI en ligger dog som en del af replikeringstjenesten, og er derfor også deployet i samme webcontainer. Sikkerheden i Stamdatamodulet kan sættes op på følgende måder: Ingen sikkerhed. Bruges kun til test-formål. Den Gode Webservice. Meget sundhedsdatanet-specifik. 2-vejs-SSL, baseret på OCES. Til KOMBIT er der valgt 2-vejs-SSL, så dette dokument vil fokusere på denne opsætning. Sletning af data foregår ved en simpel drop database, sletning af arkivet af dataudtræk samt sletning eller destruering af backup-bånd. Arkitekturen i løsningen sikres mod uautoriseret adgang gennem følgende: 1. Al trafik til applikationen går gennem en loadbalancer. 2. Loadbalanceren tillader kun trafik der er krypteret med SSL 3. Loadbalanceren tillader kun adgang til applikationsserveren for trafik der er baseret på et OCES-certifikat. 4. Applikationen tillader kun adgang til løsningen med et gyldigt klientcertifikat (ej udløbet eller spærret). 5. Applikationen viser kun data til en klient med et certifikat der er whitelistet (CVR, FID) af en administrator. 6. Administrator tillades kun adgang med et gyldigt MOCES-certifikat som er whitelistet (CVR, RID) til løsningen. For et overblik over deployment af løsningen inkl. load-balancer og applikationsserver, se dokumentet Design og Arkitektur. 3.1 Relevante OCES-detaljer OCES findes i følgende varianter: POCES (personlig) VOCES (til virksomheder) MOCES (til medarbejdere i en virksomhed) FOCES (til bestemte funktioner i en virksomhed) Sikkerhed 4

Desuden findes alle certifikattyper i en version I og version II. POCES er irrelevante ifm. Stamdatamodulet. De resterende certifikat-typer indeholder et CVRnummer og en id (kaldet hhv. UID, RID og FID for de tre certifikattyper). Kombinationen af CVR-nummeret og id et kaldes certifikatets subject-serialnumber. For MOCES udpeger subject-serialnumber unikt en medarbejder. For FOCES angiver FID en bestemt funktion inden for virksomheden. Hvor som helst der benyttes certifikater i Stamdatamodulet, checkes der for udløb og spærring samt om certifikatet er udstedt af en OCES CA. Er certifikatet ikke udstedt af en OCES CA, udløbet eller spærret, betragtes certifikatet som ugyldigt, og det giver dermed ikke adgang til den forespurgte funktionalitet. Resultatet af certifikatchecket ift. OCES CA vil fremgå af Loadbalancerens log (kan ikke umiddelbart vises i Splunk). Resultatchecket ift. spærret hhv. udløbet vil fremgå af systemloggen. Stamdatamodulet kan sættes op til at tillade OCES fra enten test- eller produktionsmiljøerne hos DanID. De kan ikke blandes idet man i konfigurationen vælger enten test eller prod. Både OCES-I og OCES-II understøttes. 4 Overholdelse af persondatalov mv. Trifork har gennem mange år udviklet it-løsninger til sundhedssektoren hvor overholdelse af persondataloven mv. Alle medarbejdere er vidende om at dette kræver focus på sikekrhed I dagligdagen. Der er etableret en driftsorganisation under ledelse af firmaets CIO, som samtidig er sikkerhedsleder. CIO har ansvaret for at vurdere risici mv. og iværksætte handlinger så Trifork til stadighed kan opfylde lovens og kundernes krav til sikkerhed. Driftsafdelingen er bla. ansvarlig for indkøb og afslaffelse af al it, backup og adgang til miljøer såvel fysisk som logisk. Server og backup-server er fysisk adskildt på forekellige lokationer. Adgang til udviklingsog,testmiljøer (samt evt. Læseadgang til Produktionslogs) er beskyttet med brugernavn/password. Den fysiske adgang til Triforks udviklingskontorer er beskyttet af sikkerhedsbrik eller fingeraftrykslæser. I forhold til den konkrete løsning til KOMBIT sikres fortrolighed ved at data altid sendes krypteret (SSL) over internettet. Autencitet sikres gennem både afsender og modtager benytter et gyldigt OCES CA certifikat. Løsningen bliver hostet hos Triforks underleverandør Netic A/S. Netic er tidligere i et andet projekt blevet revideret af revisor med henblik på Dansk Standard for Informationssikkerhed (DS-484:2005) i relation til interne processer og metoder. Netic A/S har i en årrække arbejdet med hosting af it-systemer der indeholder personfølsomme oplysninger, herunder et tilsvarende system med cpr-udtræk, der benyttes til en lang række sundhedssystemer. Netic A/S kan behandle personoplysninger i henhold til Sikkerhed 5

persondataloven, herunder Sikkerhedsbekendtgørelsen, Datatilsynets praksis vedrørende behandling af personoplysninger og i overensstemmelse med god databehandlingsskik. Sikkerheden er yderligere beskrevet i Netics sikkerhedspolitik som kan rekvireres af KOMBIT. 5 Importer Importeren eksponerer kun overvågningskomponenter via en web-gui. Overvågningskomponenterne er ikke beskyttede, da de ikke indeholder personfølsomme oplysninger, men kun oplysninger om systemets status. 6 Administrator-GUI 6.1 Adgang Administrator-GUI en tilgås via 2-vejs-SSL. Serveren præsenterer et SSL-certifikat (Self signed af Netic ifm. POC), og klienten præsenterer et MOCES. Præsenterer klienten andet end et MOCES, afvises den. Som klient benyttes en browser. Brugerens MOCES skal derfor indlæses i browseren for at få adgang til administrator-gui en. I Stamdatamodulets database ligger en liste over brugere der kan tilgå administrator-gui en, herefter kaldet administratorer. En administrator er defineret ud fra CVR og RID, der som tidligere nævnt unikt udpeger en medarbejder i en virksomhed. På baggrund af CVR og RID i administratorens MOCES kan administrator-gui en tillade adgang eller ej. Den første administrator skal oprettes direkte i databasen. Se brugervejledningen til administrator-gui en. Oprettelse af nye administratorer sker i administrator-gui en, simpelthen ved at angive et navn, en organisation samt en RID. Navnet er valgfrit for administratoren og har ingen betydning for adgangen til administrator-gui en, men benyttes i Revisionsloggen. Organisationen udpeger entydigt et CVR-nummer. De organisationer der kan udpeges, angives vha. en konfigurationsfil på serveren. 6.2 Logning Enhver adgang til administrator-gui en logges i auditloggen for at sikre sporbarhed. Ligeledes logges fejlede forsøg på adgang. Den tilgåede side, IP-adressen samt CVR+id fra OCES logges. Alle handlinger foretaget af administratorer i administrator-gui en logges, ud over i auditloggen, desuden i databasen, så det er synligt fra selve administrator-gui en hvad der er ændret af hvem hvornår. 7 Replikeringstjeneste Sikkerhed 6

7.1 Adgang I Stamdatamodulets database ligger en liste over klienter til replikeringstjenesten, herefter kaldet serviceaftagere, samt en liste over de views de hver især kan tilgå. I administrator- GUI en oprettes nye serviceaftagere ved blot at angive et navn og certifikatets subjectserialnumber. Navnet er valgfrit for administratoren og har ingen betydning for adgangen til replikeringstjenesten, men benyttes i Revisionsloggen. Serviceaftageren identificeres ud fra subject-serialnumber i det FOCES certifikat den præsenterer. Replikeringstjenesten tilgås via 2-vejs-SSL. Serveren præsenterer et SSL-certifikat (self signed af Netic ifm. POC), og serviceaftageren præsenterer et FOCES. Den SSL-krypterede forbindelse termineres i en Loadbalancer, som sender trafikken ukrypteret videre til KOMBIT-serveren hvis serviceaftagerens certifikat er gyldigt jf. afsnit 3.1. Det checkes programmatisk inden fremsøgning af data at serviceaftageren har adgang til det forespurgte view. Hvis ikke det er tilfældet, gives en UNAUTHORIZED-HTTP-statuskode (401) og ingen data. 7.2 Logning Enhver adgang til replikeringstjenesten logges i auditloggen for at sikre sporbarhed. Ligeledes logges fejlede forsøg på adgang. Det tilgåede view, IP-adressen samt CVR+id fra OCES logges. 8 Cpr-opslagskomponent 8.1 Adgang Cpr-opslagskomponenten tilgås ligesom replikeringstjenesten via 2-vejs-SSL. Serveren præsenterer et SSL-certifikat (self signed af Netic ifm. POC), og serviceaftageren præsenterer et OCES. Den SSL-krypterede forbindelse termineres i en Loadbalancer, som sender trafikken ukrypteret videre til KOMBIT-serveren hvis serviceaftagerens certifikat er gyldigt jf. afsnit 3.1. Serviceaftageren identificeres ud fra subject-serialnumber i det OCES-certifikat den præsenterer. Adgangen til cpr-opslagskomponenten styres via opslagskomponentens konfigurationsfil, hvor en kommasepareret liste af subject-serialnumbers på klienter der skal have adgang. Via et HTTP-filter checkes at serviceaftageren har adgang til opslagskomponenten. Hvis ikke det er tilfældet, gives en UNAUTHORIZED-HTTP-statuskode (401) og ingen data. 8.2 Logning Enhver adgang til opslagskomponenten logges i auditloggen for at sikre sporbarhed. Ligeledes logges fejlede forsøg på adgang. Det tilgåede view, IP-adressen samt CVR+id fra OCES logges. Sikkerhed 7