Digital Sundhed. Konsekvensnotat for IHE EUA Version 1.0, 10. maj Side 1 af 11

Transkript

1 Digital Sundhed Konsekvensnotat for IHE EUA Version 1.0, 10. maj 2010 Side 1 af 11

2 Indholdsfortegnelse Resumé... 3 Baggrund og formål... 3 Eksempler på SSO-modeller... 4 Den anbefalede SSO-model... 4 Proces ved indførelse af IHE EUA SSO-modellen... 5 Anskaffelse af HL7-CCOW Context Manager komponenten... 7 Udvikling af Client Authentication Agent komponenten... 7 Eventuel opsætning af Active Directory til PKI-autentifikation... 9 Krav til fagsystemer i et EUA SSO-fællesskab Referencer Side 2 af 11

3 Resumé Nærværende notat gennemgår de overordnede konsekvenser forbundet med at introducere IHE EUA og dermed HL7-CCOW til håndtering af SSO og kontekstdeling. Notatet er opdelt i en beskrivelse af de krav, der skal stilles ved anskaffelse af en HL7-CCOW Context Manager, ved anskaffelse af nye fagsystemer eller ved omfattende ændringer af eksisterende fagsystemer, og i en beskrivelse af forholdene omkring implementering af IHE EUA profilen. Baggrund og formål Der foregår pt. en konsolidering af it-systemer i de enkelte regioner, og en vigtig del af konsolideringsarbejdet er indførelse af single sign-on (SSO) imellem udvalgte itsystemer, så brugere undgår frustrerende og tidskrævende rutiner med at afgive, vedligeholde og huske akkreditiver til de forskellige systemer. Da kravene til sikring af brugeres identitet er meget høje i sundhedsvæsenet, stilles der tilsvarende høje krav til de løsningsmodeller, der anvendes til SSO. Ved lokalt single sign-on mellem fagsystemer skal løsningsmodellerne som minimum matche det sikkerhedsniveau der findes i eksisterende sign-on mekanismer i de enkelte fagsystemer. Ved integration mellem lokale fagsystemer og nationale services skal den valgte SSO-model leve op til kravene for nationale services med hensyn til sikkerheden for brugerens identitet. Domænebestyrelsen har fastlagt, at autentificering af brugere af nationale services skal følge internationale standarder [NIST ]. Dette vil i princippet sige et såkaldt Level of Assurance (LoA) på niveau 4 (der er det højeste sikkerhedsniveau i cevil sammenhæng), men niveau 3 vil være tilstrækkeligt 1 hvis den lokale sikkerhedskontekst tilsiger det. Dette niveau kan opnås ved brug af OCES Digital Signatur. I forlængelse af det generelle standardiseringsarbejde i sundhedssektoren har en arbejdsgruppe nedsat af Digital Sundheds infrastrukturprogram anbefalet HL7_CCOW som standard for kontekstdeling [HL7-CCOW-DK]. Kontekstdeling er her defineret bredt som ikke blot klinisk kontekst såsom patient, kontakt, afdeling osv., men også brugerkontekst såsom brugernavn og autorisationsid m.v. HL7- CCOW specificerer en softwarearkitektur og en forståelsesmæssig ramme for kontekstdeling, men berører kun problemstillinger omkring single sign-on overfladisk. Derfor har IHE (Integrating the Health Enterprise) udarbejdet en formel profil for HL7- CCOW, kaldet Enterprise User Authentication (EUA), der specificerer nøje hvordan single sign-on skal implementeres i en HL7-CCOW sammenhæng. Arbejdsgruppen foreslår denne profil som national SSO standard. Sundhedsdomænets arkitekturråd har efterfølgende anbefalet HL7_CCOW og IHE EUA som nationale standarder for Single Sign-on og kontekstdeling i sundhedsdomænet 2. 1 Ifølge ITST er det acceptabelt at anvende et lavere LoA, hvis man indfører passende sikkerhedsforanstaltninger [ITST], og i denne sammenhæng har domænebestyrelsen kompenseret for kravet om LoA-4 under forudsætning af at sundhedsdatanettet anvendes som transportvej. 2 Det bør bemærkes, at IHE-standarden XUA (autentifikation på tværs af domæner) er sat under observation af Digital Sundhed, og at kendskab til denne standard kan være en fordel. Side 3 af 11

4 Målet med nærværende konsekvensnotat er at give parterne et solidt udgangspunkt for på kort eller lang sigt at planlægge implementering af standarderne. Eksempler på SSO-modeller Single sign-on kan opnås på forskellig vis. Uanset hvilken model der anvendes, er grundprincippet at en bruger opretter en sikkerhedssession ved at afgive akkreditiver én gang, og efterfølgende har adgang til en række it-systemer indenfor samme sikkerhedssession uden at skulle autentificere sig yderligere. Som eksempler på SSO-modeller kan nævnes - Screen-scraping, hvor ét it-system er en elektronisk nøglering, der rummer akkreditiver for brugerens konti i de relevante it-systemer. Brugeren autentificerer sig overfor nøgleringen, der efterfølgende sørger for på brugerens vegne at afgive de korrekte akkreditiver til de enkelte itsystemer, når systemerne kræver det. De mere avancerede udgaver kan automatisk udskifte brugerens kodeord med et nyt, når de bagvedliggende it-systemer kræver det, så brugeren udelukkende skal huske og eventuelt vedligeholde akkreditiverne til nøgleringen. - Trust-baserede føderationer, hvor de relevante it-systemer indmelder sig i et fællesskab, og hvor brugeren efter sign-on i ét system automatisk har adgang til de andre it-systemer. Denne metode fordrer indbyrdes tillid mellem it-systemerne, samt en mekanisme til at oversætte brugerens identitet, så brugerens identitet i de forskellige it-systemer kobles korrekt. - Single Set of Credentials, hvor de relevante it-systemer har identiske akkreditiver, men ikke nødvendigvis er integrerede derudover. Modellen er en fattigmands-sso, idet brugeren skal autentificere sig overfor hvert enkelt it-system, men kan nøjes med at huske og vedligeholde ét sæt akkreditiver. Den anbefalede SSO-model Modellen, der specificeres i EUA-profilen, er en variant af trust-baserede føderationer, idet EUA introducerer en komponent, Client Authentication Agent (CAA), der som det eneste it-system har rettighed til at autentificere brugeren. De itsystemer, der indgår i SSO-fællesskabet, skal have tillid til CAA-komponenten og autentificeringen foretaget gennem denne. EUA-profilen bygger på HL7-CCOW modellen for kontekstdeling, hvor CAAkomponenten indgår i en kontekstsession sammen med fagsystemerne gennem en HL7-CCOW Context Manager (CM). Fagsystemer og andre it-systemer, der indgår i en kontekstsession, opdaterer og følger konteksten ved at kommunikere med Context Manageren på standardiseret vis. Da kontekst er defineret bredt, dækker begrebet også brugerens identitet, og dermed kan CAA-komponenten gennem CM formidle den autentificerede brugers identitet til de it-systemer, der igennem kontekstsessionen er med i SSO-fællesskabet. Som det ses på Figur 1, fungerer CAA-komponenten som brugerens adgangspunkt til den interne Circle of Trust, dvs. det fællesskab af fagsystemer og andre it- Side 4 af 11

5 systemer, der deltager i en kontekstsession styret af HL7-CCOW Context Manageren (illustreret i midten af cirklen til venstre). Figur 1 Illustration af de to Circles of Trust, som brugeren får adgang til ved sign-on. FS = Fagsystem, NS = National Service. Den eksterne Circle of Trust (illustreret til højre) er centreret omkring en national Security Token Service (STS), der genererer digitale IDkort baseret på brugernes digitale signatur. Adgang til de nationale services er baseret på disse IDkort samt eventuel yderligere autorisation af brugerne, hvis dette kræves af de enkelte nationale services. CAA en kommunikerer med STS en som en del af sign-on forløbet for at få dannet et digital IDkort. Denne model rummer en række fordele for brugerne, idet de ved sign-on igennem en CAA kan få adgang både til de fagsystemer, der er tilknyttet den regionale SSO Circle of Trust, og til de nationale services. Proces ved indførelse af IHE EUA SSO-modellen SSO gennem anvendelse af HL7-CCOW og præciseringerne angivet i IHE EUA profilen giver et kendt, højt niveau af sikkerhed for brugerens identitet. Komponenterne, der gør dette muligt, er HL7-CCOW Context Manager (CM) og Client Authentication Agent (CAA). Som udgangspunkt vil en CM være en standardkomponent, idet funktionaliteten i en CM er generel og eventuelle regionale eller lokale krav til en CM typisk vil kunne opfyldes gennem konfiguration af komponenten. Det forholder sig anderledes med CAA, da denne komponent udgør den visuelle grænseflade, hvorigennem brugere skal autentificere sig (og afslutte sikkerhedssessioner). Da det er det mest krævende it-system i et SSO-fællesskab, der afgør det nødvendige sikkerhedsniveau i autentifikation, og da de nationale services pt. fordrer Digital Signatur, skal brugeren anvende sin digitale signatur som akkreditiv ved signon, hvis SSO-fællesskabet skal indeholde både lokale it-systemer og nationale Side 5 af 11

6 services 3. Hvis der anvendes Active Directory (AD) lokalt/regionalt, kan disse opsættes til at acceptere Digital Signatur som adgangsgivende akkreditiv [PKINIT][MS-PKCA]. De it-systemer, der skal tilknyttes den lokale/regionale Circle of Trust, skal overholde HL7-CCOW standarden mht. deling af bruger kontekst, dvs. de skal opfylde et sæt af formelle krav omkring kommunikation med en HL7-CCOW Context Manager og håndtering af ændringer i konteksten (eksempelvis skift af patient eller nyt sign-on). Figur 2 Opgaverne i forbindelse med indførelse af et SSO-fællesskab er illustreret med grønne ovaler på figuren. Den overordnede proces, der skal igangsættes ved indførelse af IHE EUA SSOmodellen, indeholder en række opgaver som illustreret på Figur 2 og kort beskrevet i tabellen nedenfor. I de følgende afsnit beskrives processen mere detaljeret. Opgave Anskaffelse af HL7-CCOW Context Manager komponenten Udvikling af IHE EUA Client Authentication Agent komponenten Beskrivelse Der skal anskaffes en CM til etablering af HL7-CCOW arkitekturen til kontekstdeling. Opgaven omfatter også analyse af klientmaskiner (hardware og software) med henblik på at sikre kompatibilitet. Der skal udvikles en CAA, der kan forestå autentifikation af brugere som beskrevet i IHE EUA profilen. 3 Det er muligt at indføre modellen trinvist, idet SSO-fællesskabet i en indledende fase kan begrænses til alene at omfatte den interne Circle of Trust, således at SSO for lokale systemer kan opnås uafhængigt af en komplet udrulning af digital signatur til brugerne. I en efterfølgende fase kan CAA komponenten justeres, således at sign-on foretages med digital signatur, og SSO-fællesskabet dermed udvides til at omfatte både den interne Circle of Trust og de nationale services. Side 6 af 11

7 (Gradvis) omlægning af fagsystemer til HL7-CCOW Eventuel opsætning af AD til PKIautentifikation Omlægningen af fagsystemer og evt. andre it-systemer til SSO-fællesskabet gennem HL7-CCOW. Dette kan evt. ske gradvist i takt med planlagte nyerhvervelser eller ændringer i eksisterende it-systemer. Hvor det er relevant, kan eksisterende AD-løsninger eventuelt opsættes til at acceptere Digital Signatur som adgangsgivende akkreditiver (ved anvendelse af standardmetoden PKINIT). Anskaffelse af HL7-CCOW Context Manager komponenten HL7-CCOW Context Manager komponenten er centeret, de tilknyttede fagsystemer kommunikerer igennem. Princippet i HL7-CCOW er, at fagsystemer ikke kommunikerer direkte med hinanden, men i stedet bruger standardfunktionalitet i CM til at ændre i konteksten og følge ændringerne foretaget af andre fagsystemer. CM er således en komponent, der typisk installeres på de enkelte klientmaskiner, og ved anskaffelse af en CM er det nødvendigt at kortlægge den maskinpark, brugerne anvender, herunder operativsystemer, hardwarebegrænsninger og eventuelle sessionsfastholdelsesløsninger. Funktionalitet i en CM og krav til implementeringen af en sådan komponent er beskrevet udførligt i HL7-CCOW standarden. Som nævnt ovenfor er en CM en standardkomponent, og i anskaffelsen af en CM bør det derfor indgå som parameter i overvejelserne, om eventuel egenudvikling af en CM er rentabel, eller om det eksisterende marked for kommercielle eller Open Source CM komponenter er tilstrækkeligt (se bl.a. arkitekturprincip A1 i [SDSD-ARK]). Udvikling af Client Authentication Agent komponenten Client Authentication Agenten skal opsamle brugerens akkreditiver og gennemføre en autentificering på passende vis. Komponenten er brugerens visuelle adgangspunkt til SSO-fællesskabet, og denne komponent er derfor placeret på klientmaskinen, hvor den også kommunikerer med HL7-CCOW CM. Da de nationale services kræver anvendelse af stærke akkreditiver (pt. OCES Digital Signatur), er det nødvendigt at denne indgår som del af autentifikationen, hvis SSO-fællesskabet også skal omfatte de nationale services. Side 7 af 11

8 Figur 3 CAA arkitekturen med OCES autentifikation (PKI Authentication Server). Den overordnede arkitektur for en CAA implementering er illustreret på Figur 3. CAA komponenten verificerer brugerens akkreditiver hos en passende autentifikationsservice, eksempelvis et Active Directory (AD). IHE EUA stiller krav om anvendelse af Kerberosprotokollen i verifikationen af brugerens akkreditiver. Autentifikation ved hjælp af Digital Signatur som akkreditiv overfor et Active Directory kan opnås ved anvendelse af RFC4556 (også kaldet PKINIT), som er en særlig opsætning af Kerberos [KERBEROS-PKI]. Det digitale IDkort til brug for adgang til de nationale services opnås på standardiseret vis i en web service dialog med STS-komponenten. Denne arbejdsgang er ikke triviel, og Digital Sundhed stiller derfor et Open Source sign-on bibliotek og tilhørende plugins til rådighed 4, der i samspil med en SOSI-GW komponent giver den nødvendige funktionalitet så resultatet af brugerens sign-on er bl.a. et digitalt IDkort til de nationale services. Ved anvendelse af en SOSI-GW skal det besluttes, om denne komponent skal installeres på en NSP (standardkonfiguration), eller om den skal placeres lokalt i infrastrukturen. 4 Sign-on biblioteket og de tilhørende plugins forudsætter Windows-klienter, da denne platform er de facto standard i regionerne pt. Side 8 af 11

9 Ved implementering af en CAA skal følgende inkluderes i processen: Passende mekanisme til opsamling af brugerens akkreditiver skal implementeres, og den relevante autentifikationsmekanisme skal kaldes Overholdelse af IHE krav, herunder o Kerberos kommunikation med den udvalgte autentifikationsmekanisme o o o Håndtering af den opnåede Kerberos-sikkerhedssession kommunikation med CM konfiguration af CM til kun at acceptere sign-on fra CAA Overholdelse af nationale krav (reference til national subprofil HL7-CCOW- DK 0.9) Eventuel konfiguration af lokale autentifikationsmekanismer (se førstkommende afsnit nedenfor) Beslutning om anvendelse af plugins og sign-on bibliotek samt SOSI-GW stillet til rådighed af Digital Sundhed, herunder beslutning om placering af SOSI-GW lokalt i infrastrukturen eller på en NSP En CAA implementering kan tage mange former, idet brugeren kan afgive akkreditiver i forskellige sammenhænge og på forskellige tidspunkter i en arbejdsdag 5. Kommunikationen af brugerens identitet til en CM er essentiel (ellers opnås der ikke SSO), og under forudsætning af at denne binding overholdes, kan en CAA eksempelvis opsamle akkreditiver: I en udvidelse af Windows sign-on I en udvidelse af et portal sign-on I en udvidelse af en eksisterende sessionsbevarelsesløsning (klient virtualisering) Som en selvstændig komponent Uanset valg af implementering og eventuel sammenkobling af ovenstående eksempler skal det være tydeligt for brugeren, hvilken digital identitet der er logget på en klient, og det skal være let og hurtigt at logge af og eventuelt skifte til en ny bruger. Eventuel opsætning af Active Directory til PKI-autentifikation Hvor det er relevant, kan eksisterende Active Directory løsninger opsættes til at acceptere Digital Signatur som adgangsgivende akkreditiver. Dette kan ske ved anvendelse af standarden PKINIT og den AD-specifikke udgave af PKINIT: MS- PKCA [MS-PKCA]. Til AD-integrationen vil det være muligt at anvende sign-on biblioteket og udvikle en plugin til formålet (eventuelt i fællesskab med andre aktører så lavere udviklingsomkostninger opnås). Anvendelse af sign-on biblioteket til denne 5 Sign-on biblioteket afprøves pt. i fagsystem-sammenhæng, hvor en eksisterende sign-on grænseflade er modificeret til at anvende sign-on biblioteket og de tilhørende plugins samt SOSI-GW. Side 9 af 11

10 opgave vil give en række fordele, eksempelvis afkobling af selve CAA implementeringen fra implementeringen af integrationen med AD og mulighed for fællesudvikling på tværs af regionerne. I overgangsfasen, hvor ikke alle brugere har en digital signatur, vil det være muligt at opsætte CAA og AD et til at give lokalt SSO med AD-akkreditiver, samt lokalt og nationalt SSO med Digital Signatur. Krav til fagsystemer i et EUA SSO-fællesskab Overgangen til anvendelse af et EUA SSO-fællesskab kan ske løbende, så de relevante it-systemer kan tilpasses i takt med forretningsbehovene. Ved nyanskaffelser skal der stilles krav til leverandøren om at de relevante it-systemer kan indgå i et EUA SSO-fællesskab. De formelle krav til leverandører af it-systemer er beskrevet i [STD-KRAV-EUA]. Kort opsummeret består processen ved indrullering af et fagsystem i EUA SSOfællesskabet først og fremmest i at sikre, at det givne system overholder standardkravene beskrevet i HL7-CCOW version 1.5. Overholdelse af kravene dokumenteres af leverandøren med et Declaration of Conformance -dokument, der angiver it-systemets HL7-CCOW funktionalitet og hvilke kontekst-emner, der understøttes af it-systemet. I praksis skal et fagsystem som minimum være i stand til at deltage i og følge en kontekstsession, herunder den del af standardkonteksten, der eksplicit har med brugeren at gøre (kaldet User Subject). Leverandøren skal dokumentere, at det pågældende fagsystem gør brug af relevante kontekst-termer som specificeret i den nationale subprofil [HL7-CCOW-DK]. Det bør bemærkes, at IHE gennemfører Connectathons, der er årlige arrangementer, hvor leverandører kan afprøve integrationen mellem egne og andres systemer [IHE- CONNECT]. Et vel gennemført connectathon 6 er ikke et ufravigeligt krav til leverandøren, men bør tages med i overvejelserne ved valg af nye fagsystemer. 6 Dokumenteret gennem IHE s online resultat side, se [IHE-CONNECT] for yderligere info. Side 10 af 11

11 Referencer IHE-EUA-DK STD-KRAV-EUA HL7-CCOW-DK HL7-CCOW-1.5 HL7-CCOW-1.5-DRAFT NIST ITST KERBEROS-PKI Reference til anbefaling Under udarbejdelse Reference til anbefaling Den officielle HL7-CCOW version 1.5, kan købes her: Gratis draft version af HL7-CCOW version 1.5 kan hentes her: NIST Electronic Authentication Guideline, v April 2006: Vejledning vedrørende niveauer af autenticitetssikring: Horing.B.st.niv.autenticitetssikring.v5.pdf MIT Kerberos Consortium Whitepaper, beskriver bl.a. Kerberos, AD og PKI: MS-PKCA [MS-PKCA]: Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol Specification : SDSD-ARK M-OCES IHE-CONNECT ~/media/files/arkitektur/arkitekturprincipper_21_6_2009. ashx ertifikatpolitik%20version%205%20signeret.pdf Side 11 af 11