LAKESIDE Sårjurnalen Løsningsbeskrivelse til ændring af sikkerhedsarkitekturen Versin 0.8 8. maj 2015 LAKESIDE A/S Marselisbrg Havnevej 32, 1. sal DK-8000 Århus C Denmark tlf. +45 21607252 www.lakeside.dk inf@lakeside.dk
1 Indledning Nærværende dkument beskriver etablering af en sikkerhedsarkitektur fr Sårjurnalen. Med afsæt i Sårjurnalens nuværende løsning fr autentifikatin g autrisatin af brugere belyses, hvilke gevinster der gennem etablering af sikkerhedsarkitekturen kan høstes hs de invlverede parter. Løsningens tekniske elementer frklares, g der pstilles et radmap til en trinvis realisering g afprøvning af sikkerhedsarkitekturen. Denne løsningsbeskrivelse er således en kntekstualisering g knkretisering af de af NSI beskrevne sikkerhedsmdeller fr Sårjurnalen [SIKKERHED-SÅRJ. Dkumentet henvender sig til arkitekter, prjektledere g interesserede parter, sm indgår i piltafprøvningen af sikkerhedsarkitekturen. Der frventes, at læseren har et basalt kendskab til Sårjurnal løsningen. 1.1 Metde Udarbejdelsen af denne løsningsbeskrivelse er inspireret af TOGAF Architecture Develpment Methd (ADM), se [TOGAF]. I ADM gennemgår arkitekturprcessen en række faser startende med en fastlæggelse af rammerne (svarende til afsnit 1.2 - Rammer g principper), hvrefter der frmuleres en arkitekturvisin (afsnit 1.3 - Anvendelsesscenarier), frretningsarkitekturen beskrives (afsnit 2 - Frretningsmæssige gevinster), en lgisk infrmatinssystemarkitektur defineres (afsnit 3 - Infrmatinsarkitektur), løsningens tekniske systemlandskab beskrives (afsnit 4 - Løsningens tekniske elementer) g mdel fr en trinvis etablering præsenteres (afsnit 5 - Radmap fr etablering). 1.2 Rammer g principper Løsningen bygger på de i [SIKKERHED-SÅRJ] identificerede rammer g principper, sm her krt plistes: 1. Udnyt så vidt muligt eksisterende løsninger 2. Brugeradministratin fretages i egne systemer 3. Samme autentifikatinssikkerhed sm ved Fælles Medicinkrt 4. Skab bedre sammenhæng mellem systemer 5. Tænk fremad så kmmende løsninger får gavn af indsatsen 6. Løsningen må ikke være unødigt svær at administrere 7. Følg referencearkitekturer g øvrige analyser 1.3 Anvendelsesscenarier Det er visinen, at sikkerhedsarkitekturen sm minimum understøtter de verrdnede frventede anvendelsesscenarier fr adgangen til Sårjurnalen med den frnødne sikkerhed: A) Sundhedspersner tilgår Sårjurnalen fra et fagsystem igennem en knap løsning, hvr en allerede etableret sikkerheds- g behandlingskntekst verføres til brwseren (sikker brwser-pstart) B) Sundhedspersner g brgere tilgår Sårjurnalen direkte i en brwser (gså fra mbile enheder) C) Sundhedspersner udveksler links til ressurcer i Sårjurnalen i gennem Med- Cm EDI/XML krrespndancemeddelelser LAKESIDE side 2 / 19
1.4 Definitin af termer g frkrtelser Frkrtelse / Term Akkreditiver Autentifikatin Autrisatin CA Føderatin IdP TOGAF Frklaring I it-sammenhæng er akkreditiver bevis fr en brugers identitet. En bruger afgiver akkreditiver til et itsystem, g systemet kan på baggrund af disse infrmatiner verificere brugerens identitet. Den mest udbredte frm fr akkreditiver er brugernavn + kderd. Et andet eksempel er digital signatur, der udvider sikkerheden fra alene at mfatte nget, brugeren har kendskab til (et kderd) til gså at mfatte nget, brugeren er i besiddelse af (f.eks. en nøglefil, et kdekrt eller lignende). Kbling mellem en bruger g en digital identitet, baseret på afgivelse af akkreditive der verificerer, at burgeren er den hævdede digitale identitet. Styring g håndtering af brugerens rettigheder til adgang til ressurcer, herunder data, tjenester g funktinalitet. Certificate Authrity. Myndighed, der har ansvaret fr certifikater g udstedelse af disse. Opgaverne g ansvarsmråderne tilhørende en CA er pdelt i Identity Prfing Service (IPS) g Credential Management Service (CMS). En række rganisatiner, der har indbyrdes tillid til hinanden mkring autentificering af brugere. Indenfr en føderatin kan en bruger autentificere sig verfr en lkal autritet g derefter anvende sin identitet i tjenester udbudt af de andre rganisatiner uden at skulle autentificere sig igen. En natinal føderatin på sundhedsmrådet vil bestå af blandt andre reginerne g et antal natinale tjenester, én eller flere CA'er samt et antal parter på lige fd med reginerne (eksempelvis lægepraksis, kmmuner, apteker, sv.). Identity Prvider. En it-tjeneste der ved hjælp af ittekniske hjælpemidler g akkreditiver, kan kntrllere m en bruger er den, vedkmmende udgiver sig fr at være. En IdP prethlder lgin sessiner på tværs af web applikatiner. Dermed kan der pnås Single Sign On, dvs. brugeren behøver kun lgge på én gang fr at få adgang til alle web applikatinerne, der er med i IdP sammenslutningen. Ngle IdP implementeringer understøtter gså Single Lg-ut, så brugeren autmatisk lgges af i alle tilsluttede web applikatiner. TOGAF står fr The Open Grup Architecture Framewrk g er et rammeværk fr Enterprise Arkitektur. LAKESIDE side 3 / 19
2 Frretningsmæssige gevinster I dette afsnit sammenhldes sikkerhedsaspekterne fr det nuværende løsning i Sårjurnalen med den kmmende sikkerhedsarkitektur. Desuden beskrives de frretningsmæssige gevinster, der kan realiseres gennem etablering af en ny sikkerhedsarkitektur. 2.1 Nuværende løsning (AS-IS) Den etablerede Sårjurnalsløsning kan i frhld til sikkerhed g kntekstverførsel karakteriseres igennem følgende egenskaber: A) Brugerstyring i Sårjurnalen Sundhedspersners adgang g rettigheder administreres direkte i Sårjurnalen. B) Særskilt brugernavn/passwrd Sundhedspersner tildeles et unikt brugernavn/passwrd til Sårjurnalen. Brgere kan til gengæld benytte deres NemID akkreditiver. C) Svag autentifikatin Sårjurnalens brugerautentifikatin lever i sin nuværende frm ikke p til sikkerhedsanbefalingerne til håndtering af persnfølsmme data, se Appendiks: Sikkerhedsanalyse. D) Kan ikke indgå i Single-Sign-On (SSO) Sårjurnalens brugerautentifikatin kan hverken fr sundhedspersner eller brgere indgå i et SSO setup, sm eksempelvis Sundhedsjurnalen eller FMKnline er del af. E) Ingen sikkerhedssessinsverførsel fra fagsystem Sundhedspersner, sm allerede er autentificeret i et lkalt fagsystem, skal på ny autentificere sig, når de tilgår Sårjurnalen. F) Ingen kntekstverførsel fra fagsystem Selvm en sundhedspersn arbejder med en bestemt patients data i sit lkale fagsystem, kan denne behandlingskntekst ikke verføres til Sårjurnalen sundhedspersnen må i stedet fremfinde patienten på ny i Sårjurnalen. 2.2 Kmmende sikkerhedsarkitektur (TO-BE) Den kmmende Sårjurnalsløsning kan i frhld til sikkerhed g kntekstverførsel karakteriseres igennem følgende egenskaber: A) Lkal brugerstyring Sundhedspersners adgang g rettigheder administreres i sundhedspersnens egen rganisatin på lige fd med adgang g rettigheder til andre it-systemer. B) Single-set-f-Credentials Brugerne kan anvende de samme akkreditiver, sm de benytter til andre itsystemer. LAKESIDE side 4 / 19
C) Frnøden stærk autentifikatin Sundhedspersners adgang til persnfølsmme data sikres gennem frnøden stærk autentifikatin, se Appendiks: Sikkerhedsanalyse. D) Kan indgå i Single-Sign-On (SSO) Brugere kan pnå SSO mellem Sårjurnalen g natinale webløsninger sm eksempelvis FMK-nline g Sundhedsjurnalen. E) Sikkerhedssessinsverførsel fra fagsystem Ved pstart af Sårjurnalen fra et fagsystem kan tilstrækkelig stærk autentificerede sundhedspersner verføre deres allerede etablerede sikkerhedskntekst til Sårjurnalen. F) Kntekstverførsel fra fagsystem Sundhedspersner kan ligeledes verføre den knkrete patientkntekst fra deres fagsystem til Sårjurnalen. 2.3 Gevinster Med etableringen af sikkerhedsarkitekturen er der en række gevinster at høste, såvel fr de berørte brugere g patienter, sm fr sundhedspersners rganisatiner. A) Fra Brugerstyring i Sårjurnalen til Lkal brugerstyring Brugerstyring til Sårjurnalen kan integreres i sundhedspersnens lkale brugerstyringssystem, så det dermed håndteres på lige fd med adgangsstyring til andre it-systemer. Dette gør rettighedsadministratinen enklere g mere effektiv fr de lkale brugeradministratrer. B) Fra Særskilt brugernavn/passwrd til Single-set-f-Credentials At skulle huske frskellige akkreditiver er en udfrdringer fr mange brugere. Passwrds bliver glemt eller nteres på papir, med risik fr at blive set g misbrugt af uvedkmmende persner. Ved at genbruge, de samme akkreditiver sm brugerne gså benytter til deres lkale systemer, mindskes risiken fr misbrug. Desuden frsvinder det administrative verhead, sm ligger i vedligehldelse af separate akkreditiver. C) Fra Svag autentifikatin til Frnøden stærk autentifikatin Gennem frnøden stærk autentifikatin frmindskes risiken fr sikkerhedsbrud, hvr uvedkmmende persner skaffer sig adgang til persnfølsmme data. D) Fra Kan ikke indgå i Single-Sign-On til Kan indgå i Single-Sign-On Gennem indgåelse i et Single-Sign-On setup på tværs af it-systemer kan unødvendige arbejdsgange hs brugerne fjernes g dermed tid spares. E) Fra Ingen sikkerhedssessinsverførsel fra fagsystem til Sikkerhedssessinsverførsel fra fagsystem Sm i Single-Sign-On scenariet undgås re-autentifikatin af brugerne, sm derved sparer tid. LAKESIDE side 5 / 19
F) Fra Ingen kntekstverførsel fra fagsystem til Kntekstverførsel fra fagsystem Ved at verføre behandlingsknteksten fra fagsystemet til Sårjurnalen undgår brugeren at skulle fremfinde den pågældende patient på ny. Derved spares tid g risiken fr fejl mindskes. 3 Infrmatinsarkitektur I det følgende præsenteres den kmmende sikkerhedsarkitektur fr Sårjurnalen sm pfylder de i afsnit 2.2 (Kmmende sikkerhedsarkitektur (TO-BE)) beskrevne egenskaber. Dette afsnit mhandler infrmatinsarkitekturen fr sikkerhedsløsningen. Overrdnet g teknlgineutralt anskueliggøres infrmatinsflwet mellem de enkelte dele, der udgør den samlede sikkerhedsløsning. Hvrdan de enkelte parter knkret interagerer med hinanden g hvrdan data knkret udveksles, behandles i afsnit 4 (Løsningens tekniske elementer). Beskrivelsen er delt p efter de tre verrdnede anvendelsesscenarier sm skitseret i [PROJEKT-SÅRJ]. 3.1 Passiv scenarie Det passive scenarie dækker ver anvendelsesscenariet, hvr en sundhedsfaglig persn tilgår Sårjurnalen direkte fra en brwser, sm illustreret i nedenstående figur. Hængelåsen på de enkelte data-elementer indikerer at infrmatinen er krypteret under mdtagerens nøgle. Natinal Sundhedsføderatin Fællesffentlig føderatin Lkalt sikkerhedsdmæne Security Tken Service (SOSI STS) Rlle/Rettigheder (attributter) Tken 7 IDkrt Autentifikatin + IdP / STS (f.eks. ADFS) 5 Rettigheder IdP/STS 6 Tken NemLgin IdP 1 4 8 NyTken IDkrt 2 Brwser 3 Sårjurnalen Bruger I det passive scenarie indgår følgende trin: 1. Brugeren autentificerer sig i sit lkale sikkerhedsdmæne (eksempelvis ved lgge på sit Windws Active Directry (AD) dmæne). 2. Brugeren åbner en brwser. 3. Brugeren tilgår Sårjurnalen. 4. Sårjurnalen knstaterer, at brugeren ikke har ngen gyldig sikkerhedskntekst, g viderestiller brugeren til sundhedsføderatinens IdP. 5. IdP en indhenter en liste ver brugerens Rettigheder i frhld til natinale tjenester hs brugerens hjemmerganisatin. LAKESIDE side 6 / 19
6. Brugeren viderestilles til autentificering hs NemLgin IdP en. NemLgin returner et Tken sm bevis fr, at brugeren nu er stærk autentificeret. 7. IdP en veksler nu NemLgin tkenet til et SOSI IDkrt hs SOSI-STS en. 8. IdP en danner et NyTken indehldende attributter fra NemLgin tkenet, rettighederne hentet fra brugerrganisatinen sm er relevante fr Sårjurnalen, samt IDkrtet fra STS en. IdP en sender NyTken et til Sårjurnalen. Sårjurnalen giver brugeren adgang svarende til de rettigheder, der fremgår af tkenet. Sårjurnalen kan anvende det verførte SOSI-IDkrt til at kalde andre tjenester indenfr sundhedsmrådet fr brugeren. Det er værd at bemærke, at scenariet frløber lidt anderledes, når Sårjurnalen tilgås fra en mbil enhed. Eksempelvis en ipad, hvr brugeren i trin 1 typisk ikke lgger på et sikkerhedsdmæne, men alene autentificerer sig direkte md den mbile enhed. I dette tilfælde skal brugeren i trin 5 autentificere sig md sit lkale sikkerhedsdmæne. Brugere med flere sundhedsfaglige autrisatiner prmptes fr at vælge den autrisatin, sm de arbejder under. Dette sker hs sundhedsføderatinens IdP i trin 7 (se gså afsnit 8.2 - Lgin-sessin). 3.2 Aktiv scenarie / Sikker brwser-pstart I det aktive scenarie tilgår brugeren Sårjurnalen fra sit lkale fagsystem g verfører en allerede etableret sikkerheds- g behandlingskntekst fra fagsystemet til Sårjurnalen, når denne pstartes fra en brwser. Lkalt sikkerhedsdmæne Natinal sundhedsføderatin Autentifikatin (f.eks. AD / Kerbers) Rlle/Rettigheder (f.eks. AD / LDAP) 1 3 Rettigheder 2 2 4 Bruger 2 Fagsystem 6 5 IDkrt Tken IDkrt IDkrt Security Tken Service (SOSI STS) trust Brwser 7 Tken IDkrt Sårjurnalen Rettigheder Behandlings kntekst I det aktive scenarie indgår følgende trin: 1. Brugeren autentificerer sig i sin lkale sikkerhedsdmæne. 2. Brugeren tilgår fagsystemet. 3. Fagsystemet indhenter Rettigheder fra det lkale brugerstyringssystem. 4. I gennem fagsystemet autentificerer brugeren sig med sin digital signatur hs SOSI-STS en g får udstedt et IDkrt. 5. Fagsystemet veksler IDkrtet til et Tken med indlejret IDkrt hs SOSI-STS en. (Tkenets frm g indhld er magen til NemLgin tkenet i det passive scenarie.) 6. Brugeren starter nu brwseren fra fagsystemet. 7. Fra brwseren verføres tkenet, rettighederne g Behandlingsknteksten til Sårjurnalen. Sårjurnalen giver brugeren adgang svarende til de rettigheder, LAKESIDE side 7 / 19
der fremgår af tkenet. Patientdata vises i verensstemmelse med den verførte behandlingskntekst. Bemærk at piltprjektet i trin 7 ikke verfører brugerrettighederne indlejret i tkenet. Se afsnit 8.3 (Overførsel af rettigheder) fr en begrundelse af denne beslutningen. Udgangspunktet fr scenariet illustreret via venstående figur er, at fagsystemet integrerer til den lkale IdP, SOSI-STS en g sikker brwser-pstart. Der kan være psætninger, hvr fagsystemet ikke har adgang til en lkal IdP (idet fagsystemet ikke driftes lkalt) eller der kan være ønskeligt at afkble lgikken mkring sikker brwser-pstart fra fagsystemet. I afsnit 9 (Appendiks: Alternativ psætning til sikker brwser-pstart) illustreres en mdel, hvr integratinen til lkal IdP, SOSI-STS g Sårjurnalen håndteres af en separat lkal sikkerhedskmpnent. 3.3 Passiv scenarie med SOSI I det passive scenarie med SOSI er den stærke autentifikatin af brugeren hs NemLgin erstattet med en videreførelse af en allerede etableret stærk sikkerhedskntekst i sundhedsføderatinen. Natinal sundhedsføderatin Lkalt sikkerhedsdmæne Rlle/Rettigheder (attributter) 8 Tken Tken IDkrt Rettigheder Natinal IdP/STS Autentifikatin + IdP / STS (f.eks. ADFS) 6 5 trust 4 9 1 IDkrt cache (fx. SOSI-GW) Tken IDkrt 7 IDkrt SOSI STS NyTken IDkrt 2 Brwser 3 Sårjurnalen Bruger I det passive scenarie med SOSI indgår følgende trin: 1. Brugeren autentificerer sig i sit lkale sikkerhedsdmæne. 2. Brugeren åbner en brwser. 3. Brugeren tilgår Sårjurnalen. 4. Sårjurnalen knstaterer, at brugeren ikke har ngen gyldig sikkerhedskntekst g viderestiller brugeren til sundhedsføderatinens IdP. 5. IdP en kalder videre til brugerens hjemmerganisatin. 6. I brugerens lkale IdP afgøres, m brugeren har et gyldigt IDkrt, dvs. en gyldig stærk sikkerhedskntekst. 7. Brugerens lkale IdP veksler brugerens IDkrt til et Tken med indlejret IDkrt hs SOSI-STS en. 8. Den lkale IdP returner et samlet tken, sm indehlder det SOSI-STS udstedte tken g brugerens Rettigheder i frhld til natinale tjenester. 9. IdP en danner nu et NyTken indehldende attributter fra SOSI-STS tkenet, rettighederne hentet fra brugerrganisatinen sm er relevante fr Sårjurnalen g IDkrtet (præcist sm i det simple passive scenarie). IdP en sender NyTken et LAKESIDE side 8 / 19
til Sårjurnalen, sm giver brugeren adgang svarende til de rettigheder, der fremgår af tkenet. 3.4 Udveksling af links til patientdata Sundhedsfaglig persner kan udveksle links til patientdata i Sårjurnalen med hinanden, eksempelvis via MedCms Krrespndancemeddelelse. En pstart af Sårjurnalen fra et tilsendt link svarer til et passiv scenarie, hvr behandlingsknteksten (i frm en af reference til patienten g eventuel et knkrete sår) medsendes, men hvr autentifikatins- g autrisatins-trinene er uændret. Dette er illustreret fr det simple passive scenarie i nedenstående figur, hvr brugeren i trin 2 åbner det tilsendte link i brwseren, g hvr behandlingsknteksten verføres til Sårjurnalen i trin 3. Natinal Sundhedsføderatin Fællesffentlig føderatin Lkalt sikkerhedsdmæne Security Tken Service (SOSI STS) Rlle/Rettigheder (attributter) Tken 7 IDkrt Autentifikatin + IdP / STS (f.eks. ADFS) 5 Rettigheder IdP/STS 6 Tken NemLgin IdP 1 4 8 NyTken IDkrt Bruger 2 Brwser 3 Behandlings kntekst Sårjurnalen 4 Løsningens tekniske elementer I det følgende beskrives de anvendte prfiler g teknlgier, der udgør den samlede sikkerhedsløsning fr Sårjurnalen. Afsnittet henvender sig primært til læsere med en frhldsvis teknisk baggrund. Fr hvert af de tre scenarier beskrives, hvrdan hver enkel integratin realiseres. I dette afsnit dykkes således lidt dybere ned i teknlgien. Sikkerhedsarkitekturen bygger på etableret infrastruktur g eksisterende prfiler, herunder specielt OIOSAML WebSSO prfilen [OIO-WEBSSO]. Fr at gøre løsningen rbust ver fr en kmprmittering af transprtlaget g brugerens klient, så fregår al internettransprt med SSL/TLS kryptering, g alle internetverførte SAML tkens krypteres under aftagerens nøgle. LAKESIDE side 9 / 19
4.1 Passiv scenarie Natinal Sundhedsføderatin Fællesffentlig føderatin Lkalt sikkerhedsdmæne Security Tken Service (SOSI STS) Rlle/Rettigheder (attributter) 9 10 Autentifikatin + IdP / STS (f.eks. ADFS) 7 6 IdP/STS 8 5 NemLgin IdP 1 4 11 2 Brwser 3 Sårjurnalen Bruger De enkelte trin i det passive scenarie, hvr brugeren tilgår Sårjurnalen direkte i en brwser, realiseres på følgende måde. 1. Brugeren autentificerer sig i frhld til den lkale IdP (AD/Kerbers) 2. Brugeren starter en brwser 3. Brugeren fretager et HTTP Get kald til Sårjurnalens lgin-side fr sundhedsfaglige persner 4. Sårjurnalen afgør, hvrvidt brugeren har en eksisterende sessin (med Sårjurnalen). Hvis ikke det er tilfældet, sendes et signeret SAML <AuthnRequest> via HTTP Redirect til sundhedsføderatinens IdP. 5. Sundhedsføderatinens IdP afgør, hvrvidt brugeren har en eksisterende sessin (med sundhedsføderatinens IdP). Hvis ikke det er tilfældet, så prmptes brugeren til at vælge lkal rganisatin (g dermed hans lkale IdP). IdP en gemmer valget i en persistent ckie således, at brugeren kun skal bekræfte hans rganisatin, næste gang IdP en tilgås. IdP en sender nu et signeret SAML <AuthnRequest> via HTTP Redirect til brugerens lkale IdP. 6. Via brugerens lkale sikkerheds-sessin udtrækker den lkale IdP de rettigheder/attributter, sm er relevant i en natinal kntekst (herunder rettigheder ift. Sårjurnalen g rganisatinens CVR nummer). En SAML assertin pbygges, krypteres g sendes sm SAML <Respnse> via Pst til sundhedsføderatinens IdP. Attributterne i SAML assertinen navngives g frmateres sm specificeret i [OIOSAML-H]. 7. Sundhedsføderatinens IdP sender et SAML <AuthnRequest> til NemLgin IdP en via HTTP Redirect (sundhedsføderatinens IdP ptræder her sm serviceprvider (SP)). Hvis brugeren ikke allerede har en aktiv NemLgin-sessin skal vedkmmende autentificere sig med digital signatur. 8. NemLgin IdP en udsteder g sender et OIOSAML tken til sundhedsføderatinens IdP via Pst. Sundhedsføderatinens IdP validerer, at CVR nummeret i OIO- SAML tkenet matcher CVR nummeret i tkenet fra den lkale IdP. Dette sikrer, at attributter fra en rganisatin ikke anvendes i en anden rganisatins kntekst. 9. Sundhedsføderatinens IdP laver et WS-trust kald til SOSI-STS ens OIO- SAML2SOSI snitflade med NemLgin OIOSAML tkenet sm input. Hvis brugeren har flere sundhedsfaglige autrisatiner, så returnerer SOSI- STS en et fejlsvar indehldende brugerens mulige autrisatiner. Sundhedsføderatins IdP en prmpter i givet fald brugeren til at vælge den autrisatin, sm vedkmmende arbejder under. WS-trust kaldet gentages efterfølgende med autrisatinen sm yderlig inputparameter. LAKESIDE side 10 / 19
10. SOSI-STS en udsteder et SOSI IDkrt fr brugeren, sm returneres i WS-trust respnsen til sundhedsføderatinens IdP. 11. Sundhedsføderatinens IdP udsteder nu et SAML tken med indlejret SOSI IDkrt, sm følger subprfilen beskrevet i [OIOSAML-H]. SAML tkenet sendes i en SAML <Respnse> via Pst til Sårjurnalen. Sårjurnalen validerer tkenet g lgger brugeren ind med de rettigheder, der fremgår af tkenet. Bemærk at trin 3 8 g 11 fregår igennem brugerens brwser, hhv. sm HTTP Get, Redirect eller Pst kald. 4.2 Aktiv scenarie / Sikker brwser-pstart Lkalt sikkerhedsdmæne Natinal sundhedsføderatin Autentifikatin (f.eks. AD / Kerbers) Rlle/Rettigheder (f.eks. AD / LDAP) 1 3 Bruger 2 2 2 Fagsystem 8 9 4 5 6 7 Security Tken Service (SOSI STS) trust Brwser 10 Sårjurnalen Fr enkeltheds skyld tager den tekniske beskrivelse udgangspunkt i, at det er fagsystemet, sm integrerer direkte med såvel den lkale IdP, SOSI-STS en g Sårjurnalen. Fr en alternativ realisering se Appendiks: Alternativ psætning til sikker brwser-pstart. I det aktive sikker brwser-pstart scenarie, hvr der ikke etableres en sessin i Sundhedsføderatins IdP, indgår følgende trin: 1. Brugeren autentificerer sig i frhld til den lkale IdP (AD/Kerbers) 2. Brugeren tilgår fagsystemet. 3. Fagsystemet indhenter brugerens rettigheder til Sårjurnalen fra den lkale IdP via en lkal prtkl. 4. Fagsystemet udfrmer et SOSI IDkrt fr brugeren, sm brugeren underskriver med digital signatur. Fagsystemet fretager et WS-Trust kald md SOSI-STS en med det bruger-underskrevne IDkrt sm input. 5. SOSI-STS en validerer det bruger-underskrevne IDkrt g udsteder et nyt beriget IDkrt. IDkrtet signeres g sendes til fagsystemet i en WS-Trust respnse. 6. Fagsystemet laver et WS-Trust Issue kald til SOSI-STS ens SOSI2OIOSAML snitflade. Sm input sendes det STS-signerede SOSI IDkrt g en angivelse af Sundhedsføderatinens IdP sm audience parameter. 7. SOSI-STS en udsteder et OIOSAML tken med indlejret SOSI IDkrt. Tkenet krypteres med sundhedsføderatins IdP s ffentlig nøgle g returneres via WS- Trust respnse. 8. Fagsystemet klargør input parametrene til sikker brwser-pstart af Sårjurnalen, dvs. OIOSAML tkenet, rettighederne g behandlingsknteksten (angivet i henhld til [AP-HCE]). Derefter genererer fagsystemet en en-gangs-nøgle med krt levertid g knytter de tre input parametre til Sårjurnalen til den. Slutteligt dannes en URL sm peger tilbage på fagsystemet g sm indehlder en-gangsnøglen sm URL parameter, hvrefter brwseren startes med denne URL. LAKESIDE side 11 / 19
9. Fagsystemet mdtager HTTP GET kaldet med en-gangs-nøglen g danner ud fra den mdtagne en-gangs-nøgle en HTML side med et POST kald til Sårjurnalen sm indehlder OIOSAML tkenet i en SAML <Respnse> g rettighederne g behandlingsknteksten sm yderlige parametre. 10. Sårjurnalen validerer tkenet, lgger brugeren ind med de medsendte rettigheder g viser de patientdata der hører til den medsendte behandlingskntekst. Bemærk at trin 8 g 9 er nødvendige til at generere POST kaldet, idet en brwser kun kan startes med en (GET) URL. POST kald genereres typisk ved at returnere en HTML side med et nlad script sm submitter en FORM via POST med de relevante parametre. 4.3 Passiv scenarie med SOSI Natinal sundhedsføderatin Lkalt sikkerhedsdmæne Rlle/Rettigheder (attributter) 10 Natinal IdP/STS Autentifikatin + IdP / STS (f.eks. ADFS) 9 6 5 trust 4 11 1 IDkrt cache (fx. SOSI-GW) 7 8 SOSI STS 2 Brwser 3 Sårjurnalen Bruger De enkelte trin i det passive scenarie med SOSI, hvr brugeren tilgår Sårjurnalen direkte i en brwser g viderefører den i SOSI føderatinen etablerede sikkerhedskntekst, realiseres på følgende måde. Det passive scenarie med SOSI minder m det almindelige passive scenarie. Fr gd rdens skyld er alle trinene her gengivet i deres helhed, men bemærk at kun trin 6 10 er frskellig fra det almindelige passive scenarie. 1. Brugeren autentificerer sig i frhld til den lkale IdP (AD/Kerbers) 2. Brugeren starter en brwser 3. Brugeren fretager et HTTP Get kald til Sårjurnalens lgin-side fr sundhedsfaglige persner 4. Sårjurnalen afgør, hvrvidt brugeren har en eksisterende sessin (med Sårjurnalen). Hvis ikke det er tilfældet, sendes et signeret SAML <AuthnRequest> via HTTP Redirect til sundhedsføderatinens IdP. 5. Sundhedsføderatinens IdP afgør, hvrvidt brugeren har en eksisterende sessin (med sundhedsføderatinens IdP). Hvis ikke det er tilfældet, så prmptes brugeren til at vælge lkal rganisatin (g dermed hans lkale IdP). IdP en gemmer valget i en persistent ckie således, at brugeren kun skal bekræfte den lkale rganisatin næste gang IdP en tilgås. IdP en sender nu et signeret SAML <AuthnRequest> via HTTP Redirect til brugerens lkale IdP. LAKESIDE side 12 / 19
6. Den lkale IdP afgør, hvrvidt brugeren har en etableret sikkerhedskntekst i SOSI føderatinen, dvs. har et gyldigt SOSI IDkrt, eksempelvis i SOSI-GW. 7. Den lkale IdP laver et WS-Trust Issue kald til SOSI-STS ens SOSI2OIOSAML snitflade. Sm input sendes SOSI IDkrt g en angivelse af Sundhedsføderatinens IdP sm audience parameter. 8. SOSI-STS en udsteder et OIOSAML tken med indlejret SOSI IDkrt. Tkenet krypteres med sundhedsføderatins IdP s ffentlig nøgle, g det returneres i et WS-Trust respnse. 9. Fra en eventuel IDkrt cache sendes det SOSI-STS-udstedte OIOSAML tken videre til den lkale IdP. 10. Via brugerens lkale sikkerheds-sessin udtrækker den lkale IdP rettigheder/attributter, sm er relevant i en natinal kntekst (herunder rettigheder ift. Sårjurnalen g rganisatinens CVR nummer). En SAML assertin pbygges (med det SOSI-STS-udstedet OIOSAML tken indlejret), krypteres g sendes i en SAML <Respnse> via Pst til sundhedsføderatinens IdP. Attributterne i SAML assertinen navngives g frmateres sm specificeret i [OIOSAML-H]. 11. Sundhedsføderatinens IdP dekrypterer det mdtagne SAML tken g udsteder et nyt SAML tken med indlejret SOSI IDkrt, sm følger subprfilen beskrevet i [OIOSAML-H], g sender denne i en SAML <Respnse> via Pst til Sårjurnalen. Sårjurnalen validerer tkenet g lgger brugeren ind med de rettigheder, der fremgår af tkenet. Bemærk at trin 3 5 g 10 11 fregår i gennem brugerens brwser, hhv. sm HTTP Get, Redirect eller Pst kald. 4.4 Anvendte prfiler I nedenstående tabel sammenfattes anvendte prtkller, bindings g tkenprfiler. Prtkl Bindings Tkenprfiler SAML Authenticatin Request HTTP Redirect Binding HTTP Pst Binding WS-Trust Issuance Binding SOSI IDkrt HTTP GET POST OIOSAML OCES Attribute Prfile OIOSAML OCES Attribute Prfile fr Healthcare Lkale IdP-specifikke SAML attribut prfiler OIOSAML OCES Attribute Prfile OIOSAML OCES Attribute Prfile Cntent Prfile fr Healthcare Cntext Exchange I frhld til de anvendte bindings gælder der fr SAML Authenticatin Request prtkllen, at requests sendes sm HTTP Redirect med parametrene i URL en g at der til respnses benyttes HTTP Pst bindingen præcis sm i OIOSAML WebSSO. Med hensyn til de anvendte tkenprfiler så er frmat g indhld af SOSI IDkrt g OIOSAML tken specificeret i henhldsvis [DGWS] g [OIO-WEBSSO]. SAML tkens sm udstedes af Sundhedsføderatinens IdP er prfileret i [OIOSAML-H] g behandlingsknteksten defineres i [AP-HCE]. Hvrdan SAML tkens sm lkale IdP er verfører til Sundhedsføderatinens IdP udfrmes, underlægges ikke ngen specifik prfil, dg bør navngivning af rettighed attributterne følge prfileringen i [OIOSAML-H] fr at undgå mapninger i Sundhedsføderatinens IdP. LAKESIDE side 13 / 19
5 Radmap fr etablering Sikkerhedsarkitekturen anbefales etableret trinvist med tre milepæle, hvr hvert milepæl består af en afprøvning af et af de beskrevne scenarier. Fr hvert milepæl angives i det følgende krt, hvilke aktiviteter der skal gennemføres fr at nå til en afprøvning af scenarieret. Ngle af aktiviteterne kan fregå parallelt, aktiviteterne er derfr listet i ikke-nummereret frm. Bemærk, at det første milepæl er uafhængigt af etableringen af Sundhedsføderatinens IdP. Aktiviteter i milepæl 1: Afprøvning af det aktiv scenarie Etablering af en SAML snitflade i Sårjurnalen, sm kan mdtage et unslicited SAML respnse, hvr rettigheder g behandlingskntekst medsendes sm separate parametre. Etablering af trust til SOSI-Føderatinen i Sårjurnalens SAML snitflade. Typisk etableres trust ved at knfigurere en SAML snitflade med IdP ens certifikat. SOSIføderatinen pererer derimd ikke med faste føderatinscertifikater, men anvender en familie af føderatinscertifikater (sm er defineret i gennem et sæt simple regler). Knfigurering af SOSI-STS en med Sårjurnalen sm aftager af SAML tkens. Etablering af sikker-brwser-pstarts løsning hs piltdeltageren. Piltafprøvning af det aktive scenarie. Aktiviteter i milepæl 2: Afprøvning af det passive scenarie Etablering af Sundhedsføderatinens IdP. Integratin af Sundhedsføderatinens IdP med NemLgin IdP en. Integratin af Sundhedsføderatinens IdP med SOSI-STS en, herunder håndtering af flere sundhedsfaglige autrisatiner i Sundhedsføderatinens IdP. Integratin af Sundhedsføderatinens IdP med piltdeltagerens lkale IdP, herunder etablering af funktinalitet i Sundhedsføderatinens IdP til, at brugeren kan vælge egen rganisatin. Etablering af funktinalitet til udstedelse af OIOSAML-H tken i Sundhedsføderatinens IdP, herunder validering af m CVR nummeret i tkens fra den lkale IdP g NemLgin er ens. Integratin af Sårjurnalen med Sundhedsføderatinens IdP, herunder metadata udveksling g etablering af trust. Piltafprøvning hs piltrganisatinen. Afprøvning af link udveksling via krrespndancemeddelelse. Aktiviteter i milepæl 3: Passiv scenarie med SOSI Integratin af piltdeltagerens lkale IdP med SOSI-STS en. Knfigurering af SOSI-STS en med Sundhedsføderatinens IdP sm aftager af SAML tkens. Integratin af piltdeltagerens lkale IdP med Sundhedsføderatinens IdP, herunder udstedelse af SAML tken med indlejret krypteret OIOSAML tken i piltdeltagerens lkale IdP. Udstedelse af OIOSAML-H tken i Sundhedsføderatins IdP på baggrund af SAML tkenet fra piltdeltagerens lkale IdP. Piltafprøvning hs piltrganisatinen. Under piltafprøvningen af sikkerhedsarkitekturen fr Sårjurnalen må der ikke ændres på SOSI-STS en, hvilket medfører, at der i det aktive scenarie verføres brugerrettigheder uden fr tkenet, se gså appendiks 8.3 - Overførsel af rettigheder. I en senere fase bør de frnødne udvidelser i SOSI-STS en etableres således, at rettighederne kan blive en del at det SOSI-STS-udstedte tken (sm dermed gså kmmer til at verhlde tkenprfilen i [OIOSAML-H]). LAKESIDE side 14 / 19
På længere sigt kunne sikkerhedsarkitekturen desuden udvides med et passivt scenarie med decentral stærk autentifikatin. Baseret på en lkal stærk autentifikatinsmekanisme, der lever p til kravene til NIST niveau 3, frem fr NemLgin eller SOSI-STS en - se gså Appendiks: Sikkerhedsanalyse. 6 Referencer [AUTHN-SIK] [AP-HCE] Vejledning vedrørende niveauer af autenticitetssikring http://www.digst.dk/~/media/files/arkitektur-g-standarder/servicerienteret-infrastruktur/hringbstnivautenticitetssikringv5.pdf Attribute Prfile fr Healthcare Cntext Exchange (Arbejdstitel) Under udarbejdelse [DGWS] Den Gde Webservice, versin 1.0.1 [FIBS] [NIST] [OIOSAML-H] [OIO-WEBSSO] [PROJEKT-SÅRJ] [SIKKERHED-SÅRJ] [TOGAF] http://www.medcm.dk/wm110731 Federal Infrmatin Prcessing Standards Publicatin 140-2 Security Requirements fr Cryptgraphic Mdules http://csrc.nist.gv/publicatins/fips/fips140-2/fips1402.pdf NIST Special Publicatin 800-63-2 Electrnic Authenticatin Guideline http://nvlpubs.nist.gv/nistpubs/specialpublicatins/nist.sp.800-63- 2.pdf OIOSAML OCES Attribute Prfile fr Healthcare (Arbejdstitel) Under udarbejdelse OIO Web SSO Prfile V2.0.9 https://digitaliser.dk/resurce/2377872/artefact/oio+web+sso+prfile +V2+09.pdf Prjektdkument: Sårjurnalen - Ændring af sikkerhedsarkitekturen, Versin 1.1, MedCm, 10. Marts 2015 Fås ved henvendelse til MedCm. Føderative sikkerhedsmdeller til Sårjurnalen - Overrdnet arkitektur, v.0.95, NSI, 17. nvember 2014 Fås ved henvendelse til NSI. TOGAF - Architecture Develpment Methd (ADM) http://pubs.pengrup.rg/architecture/tgaf9-dc/arch/chap05.html LAKESIDE side 15 / 19
7 Appendiks: Sikkerhedsanalyse I [NIST] defineres der fire niveauer fr tillid til autentifikatinsløsninger fr brugere, hvr niveau 1 er det laveste g niveau 4 det højeste. I det daværende IT- g Telestyrelsens regi blev der udfrmet en natinal vejledning vedrørende niveauer af autentifikatinssikring, sm bygger på NIST s pdeling i fire niveauer [AUTHN-SIK]. I vejledningen anbefales det at benytte nedenstående tabel til at vurdere en tjenestes behv fr niveau af sikkerhed ved brugerautentifikatin. Sm der fremgår af tabellen, bør der allerede ved lille risik fr fysisk persnskade fretages brugerautentifikatin på NIST niveau 3. NIST niveau 3 frudsætter blandt andet multifaktr-autentifikatin. Brugernavn/passwrd løsninger er dermed ikke på NIST niveau 3. I g med, at der i Sårjurnalen er risik fr persnskade, bør brugerautentifikatin fregå på NIST niveau 3. Der anbefales at basere autentifikatinsløsning til Sårjurnalen på OCES medarbejdersignatur, der på nuværende tidspunkt er den eneste bredt etablerede autentifikatinsløsning i Danmark, sm lever p til NIST niveau 3. LAKESIDE side 16 / 19
8 Appendiks: Arkitekturbeslutninger Under udfrmning af denne løsningsbeskrivelse blev der sammen med de invlverede parter truffet en række arkitekturbeslutninger, sm fasthldes her. 8.1 SOSI IDkrt Prblem Alternativer Analyse Beslutning Bør SOSI IDkrtet altid indlejres i de tkens sundhedsføderatinens IdP udsteder? A) Ja, SOSI IDkrtet indlejres altid B) Nej, SOSI IDkrtet kan udlades De etablerede sikkerhedsplitikker mkring udstedelse, pbevaring g anvendelse af de kryptgrafiske nøgler, sm benyttes til at udstede SOSI IDkrt (g NemLgin tkens), lever p til FIBS niveau 2 [FIBS], herunder pbevaring af nøgler på et tamper-prf hardware sikkerhedsmdul. Nøglerne til den natinale føderatin er ikke beskyttet på sammen niveau, hvilket medfører, at risiken fr kmprmittering af sundhedsføderatinens IdP er større. Indlejring af SOSI IDkrtet i alle tkens, sm sundhedsføderatinens IdP udsteder, imødegår denne risik, idet der dermed ikke kan udstedes tkens alene ud fra sundhedsføderatinens IdP s (kmprmitterede) nøgler. Indlejringen har desuden den frdel, at aftageren (her Sårjurnalen), på brugerens vegne, kan fretage webservice kald til andre natinale tjenester, eksempelvis til det Fælles Medicinkrt (FMK). A) SOSI IDkrtet indlejres altid i de udstedte tkens 8.2 Lgin-sessin Prblem Alternativer Analyse Ngle sundhedsfaglige brugere ptræder i frskellige rller i løbet af en arbejdsdag såvel lkale rller (arbejdsfunktiner) sm natinale rller (sundhedsfaglig autrisatiner). Hvrdan kan brugere med flere sundhedsfaglige autrisatiner understøttes i frbindelse med lgin til den natinale føderatin i det passive scenarie? A) Lad brugeren vælge rlle (sundhedsfaglig autrisatin) ved lgin til den natinale føderatin. Dermed bliver lgin-sessinen i den natinale føderatin på rlle-niveau. B) Lad lgin-sessinen til den natinale føderatin alene være på identitets-niveau, g lad brugeren vælge rlle i de enkelte applikatinerne (her Sårjurnalen), hvis applikatiner har behv fr at kende rllen. Medarbejdere med én sundhedsfaglig autrisatin vil af SOSI-STS en få angivet autrisatinen i det udstedte SOSI IDkrt. Medarbejdere med flere autrisatiner skal på udstedelsestidspunktet angive, hvilken autrisatin de arbejder under, så denne kan angives i SOSI IDkrtet. I g med at SOSI IDkrtet indlejres i det natinale tken, g kan benyttes LAKESIDE side 17 / 19
Beslutning Bemærkning til at fretage webservice kald på brugerens vegne, så bør der være verensstemmelse mellem autrisatinen i SOSI IDkrtet g lgin-sessinen i den natinale føderatin. Fr brugere med flere autrisatiner er en lgin-sessin på identitetsniveau dermed ikke muligt uden, at der laves ændringer i SOSI-STS. Eksempelvis ved at tillade udstedelse af IDkrt med flere autrisatiner. En ændring af SOSI-STS en ligger uden fr rammen fr etableringen af sikkerhedsarkitekturen fr Sårjurnalen. Samtidigt bør brugere med flere autrisatiner ikke udelukkes fra at benytte Sårjurnalen i det passive scenarie. A) Lad brugeren i det passive scenarie vælge rlle (sundhedsfaglig autrisatin) i frbindelse med etablering af sessinen i sundhedsføderatinens IdP. Ovenstående beslutning vedrører alene afprøvningen af sikkerhedsarkitekturen fr Sårjurnalen. Der udestår en afklaring af hvilken type natinal føderatin, der ønskes skabt inden fr sundhedsvæsnet. Fx hvrvidt der perereres på rlle- eller identitetsniveau. Denne afklaring ligger uden fr rammen fr etableringen af sikkerhedsarkitekturen fr Sårjurnalen 8.3 Overførsel af rettigheder Prblem Alternativer Analyse Beslutning Skal lkalt administrerede rettigheder i det aktive scenarie verføres sm en del af tkenet? A) Ja, rettigheder er en del af tkenet. B) Nej, rettigheder verføres separat. Ved at lade rettigheder indgå i det krypterede tken sikres disse md mdikatin i en kmprmitteret brwserklient. Derved vil gså indhldet af tkenet blive ens i det aktive g det passive scenarie. Indlejring i tkenet kræver en ændring i vekslingssnitflade hs SOSI- STS en. B) Overfør rettigheder separat, idet sikkerhedsarkitekturen fr Sårjurnalen i første mgang ønskes etableret uden ændringer i SOSI-STS. Risik fr kmprmittering af brwseren accepteres under afprøvningen. LAKESIDE side 18 / 19
9 Appendiks: Alternativ psætning til sikker brwser-pstart I nedenstående figur illustreres et alternativt setup fr det aktive scenarie, hvr integratin til lkal IdP, SOSI-STS en g Sårjurnalen varetages af en særskilt sikkerhedskmpnent. Lkalt sikkerhedsdmæne Natinal sundhedsføderatin Autentifikatin (f.eks. AD / Kerbers) Rlle/Rettigheder (f.eks. AD / LDAP) 1 5 Rettigheder 6 Bruger 2 Fagsystem 3 Sikkerheds Kmpnent 7 IDkrt Tken IDkrt IDkrt Security Tken Service (SOSI STS) trust Brwser 4 8 Behandlings kntekst Tken IDkrt Rettigheder Sårjurnalen Behandlings kntekst I det alternative aktive scenarie indgår følgende trin: 1. Brugeren autentificerer sig i sit lkale sikkerhedsdmæne. 2. Brugeren tilgår fagsystemet. 3. Brugeren starter brwseren fra fagsystemet. 4. Fra brwseren verføres Behandlingsknteksten til en lkal Sikkerhedskmpnent 5. Sikkerhedskmpnenten indhenter Rettigheder fra det lkale brugerstyringssystem. 6. I sikkerhedskmpnenten autentificerer brugeren sig med sin digital signatur hs SOSI-STS en g får udstedt et IDkrt. 7. Sikkerhedskmpnenten veksler IDkrtet til et Tken med indlejret IDkrt hs SOSI-STS en. 8. Fra sikkerhedskmpnenten verføres tkenet, rettighederne g behandlingsknteksten til Sårjurnalen. Sårjurnalen giver brugeren adgang på baggrund af de medsendte rettigheder g viser de patientdata, der hører til den verførte behandlingskntekst. Bemærk at fagsystemet i denne psætning kan være driftet uden fr den lkale sikkerhedsdmæne. LAKESIDE side 19 / 19