Præcisering af transportbaseret sikkerhed i Den Gode Webservice

Transkript

1 Præcisering af transportbaseret sikkerhed i Den Gode Webservice 1. Historik Indledning SSL/TLS baseret netværk Sundhedsdatanettet (VPN) Opsummering Referencer...6 Side 1

2 1. Historik Dato Beskrivelse Person Oprettet KKJ Korrektur KKJ Præcisering af VPN sikkerhed KKJ Side 2

3 2. Indledning Den Gode Webservice (DGWS) version 1.0 definerer bla. retningslinjer for sikkerhed, herunder hvordan oplysninger om bruger og/eller it-system sendes på en sikker måde mellem en webservice klient og en webservice server. En arkitekturmæssig hjørnesten i sikkerhedsmodellen for DGWS er at transportlaget er krypteret helt fra klient til server og tilbage igen, samt at der er etableret et tillidsforhold mellem de to parter. Hvis en af disse præmisser er brudt, øges risikoen for at personfølsomme oplysninger falder i de forkerte hænder markant. Specifikationen tillader to mekanismer til sikring af transportlaget, nemlig VPN og SSL/TLS. Selv om DGWS definerer de overordnede rammer, går specifikationen ikke i detaljer med hvordan det sikres, at der er konfidentialitet helt fra klient til server og tilbage igen. Dette dokument præciserer derfor de forudsætninger der skal være på plads for at opnå den ønskede sikkerhed og angiver samtidig konstruktioner, der ikke er tilladt. 3. SSL/TLS baseret netværk SSL protokollen er defactomekanismen til at sikre konfidentialitet mellem to systemer, der kommunikerer via HTTP over Internettet. Protokollen baserer sig på en public-key infrastructure (PKI) med certifikater til at opnå kryptering af transportlaget typisk mellem en browser og en webserver. I det simple tilfælde er det alene serveren, der identificerer sig overfor klienten og ikke omvendt. For at klienten kan kommunikere skal den udelukkende stole på serverens certifikat. Når klienten er en browser håndteres dette ofte ved at producenten har præinstalleret en række rodcertifikater fra certifikat autoriteter (CA). Kravet til serveren er da blot at dennes certifikat skal være udstedt af en kendt CA, så browseren ikke behøver spørge brugeren om denne stoler på certifikatet. Figur 1: SSL konfiguration med Client Authentication I et DGWS scenario, hvor der kommunikeres personfølsomme oplysninger, er en sådan envejsautentifikation ikke stærk nok. Serveren har også brug for med sikkerhed at vide hvem klienten er, så begge parter må autentificere sig. Dermed skal klienten også have et certifikat. Side 3

4 1: Når der transportlaget beskyttes med SSL skal der anvendes client authentication Den danske certifikatstandard, OCES, benyttes af DGWS til at skabe digitale signaturer på bla. id-kortet, hvori der lagres oplysninger om brugeren. For at sikre sammenhæng er det også nødvendigt at transportlaget krypteres med OCES, helt specifikt virksomhedscertifikater (VOCES). OCES certifikater er imidlertid ikke specifikke for sundhedssektoren, men kan rekvireres af en vilkårlig virksomhed i Danmark. Der opstår derfor et behov fra både klient og server for at validere det anvendte certifikat ifht. organisationer der er tillid til. 2: Når der transportlaget beskyttes med SSL skal certifikaterne være VOCES I det simple punkt-til-punkt tilfælde, hvor klient og server ikke indgår i en single-signon føderation skal parterne enten verificere at CVR-nummeret er på listen over organisationer, der er tillid til eller specifikt verificere at der er tillid til det anvendte certifikat. 3: Ved punkt-til-punkt kommunikation med SSL skal det verificeres at der er tillid til det anvendte certifikat eller at der er tillid til det CVR nummer, som certifikatet er udstedt til. I en føderation af tjenester, hvori der indgår en Identity Provider (IdP) som varetager autentifikationen, er sagen lidt anderledes. Her er præmissen, at IdP en har sagt god for den anvendte medarbejdersignatur (MOCES) eller for virksomhedscertifikatet (VOCES) i SAML kuverten. Kravet er så blot at certifikatet fra denne autentifikation skal være det samme som anvendes til SSL/TLS (VOCES) eller at CVR nummeret i MOCES certifikatet skal være det samme som anvendes i VOCES certifikatet der benyttes til SSL/TLS. 4: Ved single-signon med SSL skal det verificeres at det VOCES certifikat, som anvendes til SSL er det samme som det der blev anvendt til autentifikation mod IdP en eller at dets CVR nummer matcher CVR nummeret i det MOCES certifikat, der blev anvendt til autentifikation mod IdP en. I begge scenarier indskærpes det, at hele certifikatkæden skal checkes ned til OCES rod-certifikatet. IT- og Telestyrelsen har udgivet OWSA-T modellen, der udstikker generelle retningslinjer for transportbaseret sikkerhed for webservices over HTTP. Dette dokument skal opfattes som et tillæg til OWSA-T. I tilfælde af konflikt er dette notats retningslinjer gældende. 5: OWSA-T er gældende for så vidt der ikke er konflikt med retningslinjer i dette dokument. Side 4

5 4. Sundhedsdatanettet (VPN) MedCom driver i dag det VPN-baserede Sundhedsdatanet (SDN), til hvilket der er knyttet en lang række sundhedsfaglige aktører. Netværket udmærker sig ved at være aftalebaseret således at det kræver en fysisk underskrevet kontrakt mellem to parter før de bliver i stand til at kommunikere via SDN. DGWS udpeger da også SDN som en oplagt VPN-baseret kandidat til at sikre transportlaget. Når netværkssikkerheden bygges op omkring SDN, håndteres krypteringen af netværksenheder. I dette scenarium overlades verifikationen af de enkelte parter derfor til netværket. En aktør på SDN udstyres med sin egen specifikke IP-adresse og for så vidt denne adresse udelukkende benyttes af én webserviceklient eller -server, der har forpligtet sig til at beskytte eget netværk i henhold til forskrifterne for SDN [SDNSIK] er sikkerheden umiddelbart ækvivalent med SSL/TLS scenariet. 6: Aktører der benytter Sundhedsdatanettet til webservice kommunikation skal overholde sikkerhedsforskrifterne [SDNSIK] Hvis forbindelsen til SDN benyttes af et antal forskellige systemer eller virksomheder er det pludselig ikke længere så gennemskueligt om konfidentialiteten er sikret helt fra klient til server, samt hvilke it-systemer der er koblet på. Dette er f.eks. tilfældet når en lægepraksissystemleverandør foretager opkoblingen til Sundhedsdatanettet på vegne af et antal decentrale installationer lokalt hos praktiserende læger eller når en region installerer en gateway til at håndtere digital signatur med DGWS og opkobling til SDN f.eks. på vegne af et antal Elektroniske Patient Journal (EPJ) systemer. Modellen er skitseret nedenfor: Figur 2: SDN konfiguration med mange klienter Side 5

6 Denne situation beskrives i [SDNLÆ] afsnit 3.2, hvor det angives at forbindelsen mellem porten til SDN og det decentrale it-system bør etableres via VPN. Dette krav skærpes i det følgende: 7: Forbindelsen mellem det system der varetager adgangen til SDN og det decentrale itsystem skal etableres via hardwarebaseret VPN En række konkrete sikkerhedstiltag og overvejelser til sikring af netværk og it-systemer hos lægepraksissystemleverandører, samt i regionerne findes i [SDNLÆ] og [SDNREG]. Ved opkobling til SDN følges forskrifterne heri for at mindske risikoen for misbrug. 8: Retningslinjerne i [SDNLÆ] og [SDNREG] skal følges for at sikre netværk hos parter der enten direkte eller indirekte er koblet på SDN 5. Opsummering Den Gode Webservice anvender et krypteret transportlag til at sikre konfidentialiteten af data enten med SSL/TLS eller med VPN (SDN). Ved brug af SSL/TLS anvendes ITSTs OWSA-T model med client authentication via VOCES certifikater. Ved brug af SDN er det et krav at hver aktør overholder sikkerhedsforskrifterne for SDN. Modellerne anses med disse præciseringer for at være sikkerhedsmæssigt ækvivalente. 6. Referencer [OWSA-T] OWSA-model T, IT- og Telestyrelsen (23/ ), [DGWS10] Den Gode Webservice 1.0, MedCom ( ), [SDNLÆ] Sikkerhed i lægepraksis. Praktisk vejledning.version 1.0, UNI-C (2003), [SDNREG] Best practice ved opkobling til Sundhedsdatanettet, Fyns Amt (24/4 2003), [SDNSIK] Sundhedsdatanettet: Sikkerhed og ansvar, UNI-C (2003), Side 6