(-- JanRiis - 20-01-2006)

SOSI designet er i høj grad drevet af kvalitetskrav. I IBMs artikel "Understanding quality of service for Web services" er der en glimrende definition af de aspekter, man bør berøre og/eller håndtere når der tales om Quality of Service (QoS):

• Availability
  "Availability is the quality aspect of whether the Web service is present or ready for immediate use. Availability represents the probability that a service is available. Larger values represent that the service is always ready to use while smaller values indicate unpredictability of whether the service will be available at a particular time. Also associated with availability is time-to-repair (TTR). TTR represents the time it takes to repair a service that has failed. Ideally smaller values of TTR are desirable."
• Accessibility
  "Accessibility is the quality aspect of a service that represents the degree it is capable of serving a Web service request. It may be expressed as a probability measure denoting the success rate or chance of a successful service instantiation at a point in time. There could be situations when a Web service is available but not accessible. High accessibility of Web services can be achieved by building highly scalable systems. Scalability refers to the ability to consistently serve the requests despite variations in the volume of requests."
• Integrity
  Integrity is the quality aspect of how the Web service maintains the correctness of the interaction in respect to the source. Proper execution of Web service transactions will provide the correctness of interaction. A transaction refers to a sequence of activities to be treated as a single unit of work. All the activities have to be completed to make the transaction successful. When a transaction does not complete, all the changes made are rolled back."
• Performance
  "Performance is the quality aspect of Web service, which is measured in terms of throughput and latency. Higher throughput and lower latency values represent good performance of a Web service. Throughput represents the number of Web service requests served at a given time period. Latency is the round-trip time between sending a request and receiving the response."
• Reliability
  "Reliability is the quality aspect of a Web service that represents the degree of being capable of maintaining the service and service quality. The number of failures per month or year represents a measure of reliability of a Web service. In another sense, reliability refers to the assured and ordered delivery for messages being sent and received by service requestors and service providers."
• Regulatory
  "Regulatory is the quality aspect of the Web service in conformance with the rules, the law, compliance with standards, and the established service level agreement. Web services use a lot of standards such as SOAP, UDDI, and WSDL. Strict adherence to correct versions of standards (for example, SOAP version 1.2) by service providers is necessary for proper invocation of Web services by service requestors."
• Security
  "Security is the quality aspect of the Web service of providing confidentiality and non-repudiation by authenticating the parties involved, encrypting messages, and providing access control. Security has added importance because Web service invocation occurs over the public Internet. The service provider can have different approaches and levels of providing security depending on the service requestor."

I de følgende afsnit berøres disse emner i større eller mindre omfang. Da der naturligt nok er meget stor fokus på patientsikkerhed, er sikkerhedsaspektet beskrevet mere dybtgående end de andre, og det er også her vi lægger ud.

4.1. Sikkerhed

I situationer, hvor der skal udveksles følsomme data, stilles generelet flg. krav til sikkerheden i løsningen:

• Hemmeligholdelse
  De afsendte data må ikke kunne læses af en tilfældig lytter på linien.
• Integritet
  Modtageren af en forvansket meddelelse skal kunne afgøre at meddelelsen er blevet ødelagt (tilsigtet eller utilsigtet).
• Autenticitet
  Alle deltagere i kommunikationen skal kunne overbevise sig om, at de øvrige deltagere er dem de udgiver sig for at være - ved alle meddelelser.
• Uafviselighed
  En modtager af en meddelelse, må ikke kunne løbe fra at have fået meddelelsen lige som afsenderen ikke må kunne løbe fra at have sendt den.
• Autorisation
  Der må kun være adgang til de services, som brugeren er autoriseret til at have adgang til (f.eks. jf. jobposition eller lign.)

I WS/SOA sammenhæng er der megen diskussion om, hvilke egenskaber der skal sikres af transportkanalen, og hvilke egenskaber der skal sikres i meddelelsen. I traditionelle punkt-til-punkt løsninger var det tilstrækkeligt at etablere en sikker kanal, hvor begge parter i kommunikationen autentificerer sig over for modparten og al kommunikation er stærkt krypteret (f.eks. bidirectional SSL3.0/TLS1.0). Dette sikrer at en del af ovenstående krav er opfyldt (hemmeligholdelse og integritet). Det sikrer dog ikke brugerautenticitet, uafviselighed og autorisation.

Såfremt der indgår flere parter i kommunikationen (f.eks. en klient -> decentral server -> central server) sikres hemmeligholdelse og integritet kun hvis der er sikre kanaler mellem alle parterne. Hvis blot én af kommunikationskanalerne er "usikker" bryder hele hele systemet sammen (sikkerhedsmæssigt). I WS/SOA sigter man derfor typisk efter "ende-til-ende" sikkerhed frem for (multibel) punkt-til-punkt sikkerhed.

Hvis man skal relatere dette til typiske EPJ systemer i sundhedssektoren i dag, er de ofte opbygget som "rige klienter", der kommunikerer med nogle servere på et lukket net. Når der er behov for "ekstern integration" til centrale systemer (f.eks. systemer hos Lægemiddelstyrelsen eller Sundhedsstyrelsen), foregår det typisk over SundhedsDataNettet, som fungerer som en sikker kanal, hvor man på netværksniveau kender alle servere på dette net.

System-til-system integration i sundhedssektoren er derfor lidt "atypisk", idet der findes dette sikre net, som tager sig af hemmeligholdelse og integritet af al kommunikation. Disse egenskaber behøver vi således ikke adressere i SOSI, men fokuserer vores arbejde på de resterende sikkerhedsegenskaber: brugerautenticitet, systemautenticitet, uafviselighed af beskeder og svar samt autorisation.

4.1.1 Risikovurdering

Hidtil har kommunikation over internettet udgjort den største sikkerhedsrisiko i system-til-system kommunikation. Der findes dog mange anerkendte teknikker og værktøjer, der imødegår denne risiko (f.eks. VPN, bidirectional SSL3.0/TLS1.0 og HTTPS), og hvis man benytter disse, viser det sig, at den største risiko nu findes i "enderne" af kommunikationen.

I SOSI forholder vi os ikke til risikoen på serviceudbyder og serviceaftagers side. Vi antager, at kommunikationen er sikret med SSL3.0/TLS1.0 og dermed sikret mod "Man in the Middle (MITM)", "replay" og andre kendte angreb.

Med disse forudsætninger er de væsentligste tekniske sikkerhedsaspekter på plads, mens de mere patientsikkerhedsrelaterede aspekter stadig mangler at blive behandlet. Det gør vi nedenfor.

4.1.2 Brugerautenticitet

Da en serviceudbyder i SOSI kan have forskellige krav til sikring af brugerautenticitet (niveau 1-4) kan vi ikke sætte én bestemt løsning.

På niveau 3-4 sikres autenticitet ved, at at påføre "udsted ID-kort" forespørgslen brugerens digitale signatur. IdP'en verificerer denne signatur i forbindelse med udstedelse af ID-kortet, og kan dermed overbevise sig om, at brugeren har adgang til den private nøgle.

På niveau 1-2 kan IdP'en ikke verificere autenticiteten af brugeren, da der ikke sendes bevis for akkreditiver med til IdP'en. IdP'en må derfor udelegere autenticitetskontrollen af en evt. bruger til enten serviceaftagersystemet selv, til serviceudbyderen, eller til en helt tredje ekstern autenticeringsautoritet, og stole på at dette er korrekt udført. Der er dog en problemstilling her. Hvordan kan IdP'en stole på, at den pågældende forespørgsel reelt kommer fra det serviceaftagersystem, der er påtrykt forespørgslen i forbindelse med ID-kort udstedelse? Uden nogen form for digital signatur kan dette kun sandsynliggøres. Anvendelse af SundhedsDataNettet, indskrænker naturligvis antallet af mulige systemer betragteligt, men da det ikke er muligt for en serviceudbyder på netværksniveau at afgøre, hvilken serviceaftager en forespørgsel kommer fra, har man kun ringe sikkerhed for serviceaftagers autenticitet. I takt med at der kommer flere og flere aktører på SundhedsDataNettet og at endepunkterne (f.eks. regionsnettene) bliver større og risikoen for kompromittering dermed større, vælger vi derfor altid at kræve en systemsignatur i baseret på et OCES virksomhedscertifikat på niveau 1 og 2.
Bemærk: Dette gælder kun "udsted ID-kort" kaldet. I efterfølgende kald til serviceudbydere er det optionelt for serviceudbyderen, om systemsignatur kræves ved servicekald.

4.1.3 Autorisation

I SOSI overlader vi autorisationen til de parter der ved noget om hhv. servicen og brugeren. Serviceudbyderen skal derfor sikre, at kun passende autenticerede brugere og brugere med en passende rolle (samt evt. andre attributter) får adgang til servicen. Omvendt overlader vi det til serviceaftagersystemet at medsende passende udsagn om brugeren hhv. i forbindelse med udstedelse af ID-kort (f.eks. rolle og den afdeling brugeren er "logget ind på") og i forbindelse med et servicekald (f.eks. samtykke).

4.1.4 Uafviselighed

Der er flere typer af uafviselighed:

• Bruger-uafviselighed: I forespørgsler/indberetniger medsendes data, som serviceudbyder kan gemme og efterfølgende bruge som bevis for, at den pågældende bruger afsendte en given besked på et givet tidspunkt.
• Serviceudbyder-uafviselighed: En serviceudbyder medsender data i svaret, der gør det muligt for en serviceaftager at bevise at det pågældende svar blev behandlet af netop denne serviceudbyder på det angivne tidspunkt.
• Serviceaftagersystem-uafviselighed: Et alternativ til brugeruafviselighed, men hvor det er afsendersystemets virksomhedscertifikat, der lægger til grund for uafviselighedsdata.

I SOSI har vi valgt at lade uafviselighed være en egenskab, der er ortogonal på autenticitetsniveauerne, og som serviceudbyder og -aftager dermed optionelt kan kræve, hvis situationen byder det. Da uafviselighed kræver en digital signatur, er det ikke på alle autenticitetsniveauer, det giver mening at kræve alle typer af uafviselighed. Flg. skema ridser mulighederne op:

(M=Mandatory/Obligatorisk, O=Optionel, N/A=ikke tilladt)
*) Afgivelse af digital signatur er "mandatory" (M) i forbindelse med udstedelse af ID-kort, men kan optionelt kræves af serviceudbyderen ved andre services.

Request for comment:

• Skal uafviselighed (på brugeren) være obligatorisk på niveau 4?
• Skal systemuafviselighed være M/O eller N/A på niveau 4?

4.1.5 Opsummering af sikkerhedskrav og løsninger i SOSI

Sikkerhedsforudsætninger:

• Serviceaftager (EPJ serveren) og Serviceudbyderen er forbundet via SundhedsDataNettet
• EPJ serveren og EPJ klienten er forbundet via bidirektionel SSL3.0/TLS1.0 forbindelse eller med et på anden vis lukket og/eller sikkert net.

S1 - Brugerautenticitet

Om nødvendigt skal det være muligt for en serviceudbyder entydigt at identificere en bruger, og overbevise sig om brugerens autenticitet.

Løsning:
Det personlige ID kort gør det muligt for en serviceudbyder at identificere og verificere autenticiteten af en bruger. Hvis en serviceudbyder har tillid til IdP'ens troværdighed, kan serviceudbyderen have lige så stor tillid til ID kortets ægthed og dermed brugerens identitet.

S2 - Systemautenticitet

Det skal være muligt for en serviceudbyder at identificere, hvilket system (server/proces) en given forespørgsel/indberetning kommer fra.

Løsning:
I "udsted ID kort" use casen påtrykker afsender systemet (f.eks. EPJ systemet) sit unikke System-ID på "kuverten". IdP'en kan ved modtagelse af kuverten aflæse System-ID'et fra kuverten, og påtrykke dette på brugerens ID kort inden IdP'en fører disse data under digital signatur.

Senere kan en serviceudbyder aflæse hvilket system, et givet personligt ID kort var udstedt til, og bruge dette til logning og evt. i første trin i en autorisationsproces.

Request for comment: På niveau 3+4 er det således brugeren, der står inde for, at udstedelses-requestet kommer fra det rette system. Kan der være ekstra værdi i også at lade serviceaftagersystemet signere requestet (niveau 3+4)?

S3 - Brugerautorisation

Det skal være muligt for en serviceudbyder at kunne nægte en bruger adgang til en given service, såfremt denne (type) bruger ikke må få adgang til servicen.

Løsning:
På det personlige ID kort, er der angivet hvilken sundhedsfaglig rolle brugeren optræder i, med dette ID kort (f.eks. "ordinerende læge" eller "tilsynsførende læge"). På baggrund af disse informationer, kan serviceudbyderen autorisere brugeren til en delmængde af de udstillede services.

MedCom definerer i øvrigt adskillige attributter i kuverten, der kan hjælpe serviceudbyderen i autorisationsprocessen, f.eks. samtykke, organisatorisk enhed mfl.

S4 - Resistens mod typiske sikkerhedsangreb

Designet skal være resistent mod de typiske sikkerhedsangreb, f.eks. MITM, replay, session hi-jacking etc.

Løsning:
Dette sikres af forudsætningen om SSL3.0/TLS1.0

S5 - "Ende-til-Ende" Integritet

Forespørgsler må ikke kunne ændres, uden at serviceudbyderen opdager det.

Løsning:
Dette sikres af forudsætningen om SSL3.0/TLS1.0

Hvis der endvidere er valgt digital signatur på niveau 3+4, er der integritetssikkerhed på både kanal-niveau og på besked-niveau.

S6 - "Ende-til-Ende" Hemmeligholdelse

Det må ikke være muligt for en tilfældig lytter på linien, at se patientfølsomme data.

Løsning:
Dette sikres af forudsætningen om SSL3.0/TLS1.0

S7 - Optionel brugeruafviselighed

Det skal være muligt for en serviceudbyder optionelt at bede om data i forespørgsler/indberetninger, der kan _bevise, at en bruger har sendt en given forespørgsel/indberetning på et givent tidspunkt. Med optionelt menes, at nogle services er af en karakter, der altid kræver brugeruafviselighed, mens andre ikke gør det._

Løsning:
Dette kan kun lade sig gøre på niveau 3+4. Alle forespørgsler/indberetninger påføres brugerens digitale signatur. Da signaturen er uløseligt forbundet med brugerens private nøgle og den pågældende forespørgsel/indberetning, kan bruger-uafviselighed opnås ved at lade serviceudbyderen gemme forespørgslen og underskriften sammen med en reference til ID-kortet, hvori den ofentlige nøgle er placeret. Hvis en service kræver uafviselighed, og serviceaftagersystemet ikke medsender en signatur genereret af certifikatholderen, skal forespørgslen/indberetningen afvises.

- Bemærk at dette krav tilsigter, at serviceudbyderen optionelt kan bede om en "uafviselighedsforsikring". Det bør fremgå af metadata for en service hos en serviceudbyder, om denne service kræver uafviselighedsdata på niveau 3.

S8 - Optionel systemuafviselighed af serviceaftagersystemet

Det skal optionelt være muligt for et serviceudbyder at rekvirere bevis for, at et givet serviceaftagersytem har foretaget en bestemt forespørgsel/indberetning på et givet tidspunkt. Dette er et alternativ til S7 og specielt anvendeligt på autenticeringsniveau 1 og 2.

Løsning:
I stedet for at lade brugeren (certifikatholderen) generere den digitale signatur som beskrevet i S7, kan man lade serviceaftagersystemet underskrive forespørgslen/indberetningen ved hjælp af systemets OCES virksomhedscertifikat. For at undgå at medsende X.509 certifikater i forespørgsler og kræve at serviceudbydere skal verificere disse, lader vi serviceudbydersystemet trække et system ID-kort hos IdP'en, og medsender dette til serviceudbyderen.

- Bemærk at dette krav tilsigter, at serviceudbyderen optionelt kan bede om en "uafviselighedsforsikring" fra afsendersystemet. Det bør fremgå af metadata for en service hos en serviceudbyder, om denne service kræver system-uafviselighedsdata på niveau 1+2.

S9 - Optionel systemuafviselighed for serviceudbyder

Det skal optionelt være muligt for et brugersystem (en serviceaftager) at bede om bevis for, at en serviceudbyder har behandlet en given forespørgsel/indberetning på et givet tidspunkt, sammen med svaret.

Løsning:
Ved at lade serviceudbyderen returnere et digitalt underskrevet svar, og lade serviceaftageren logge svaret og den tilhørende digitale signatur, sikres dels, at serviceaftageren kan bevise at serviceudbyderen har håndteret en forespørgsel/indberetning, men forhindrer samtidig at en uhæderlig serviceaftager kan foregive at have fået et andet svar end det faktiske.

For at undgå at alle serviceaftagere skal kende certifikater fra alle serviceudbydere, "vender" vi her ID-kort skemaet om, og lader serviceudbydere trække et ID-kort hos IdP'en (baseret på OCES virksomhedscertifikater). Serviceaftageren kan således nemt og effektivt kontrollere en serviceudbyders svar og logge signaturen sammen med en reference til ID-kortet.

- Bemærk at dette krav tilsigter, at serviceaftageren optionelt kan bede om en "uafviselighedsforsikring". Anmodningen om dette er indbygget i forespørgslen. Det bør fremgå af metadata for en service hos en serviceudbyder, om denne service kan levere uafviselighedsdata sammen med svaret.

4.2. De andre QoS egenskaber

4.2.1 Availability og Accessability

Hvis man skal oversætte disse egenskaber til Dansk, er de mest dækkende termer hhv. "Rådighed" og "Tilgængelighed". Rådighedsegenskaben kendetegner serviceudbyderens og IdP'ens evne til at holde systemerne kørende ("oppetid"), mens tilgængelighedsegenskaben fortæller noget om muligheden for at få adgang til en service når den er til rådighed. Selv om en service er til rådighed, kan systemerne nemlig være så belastede, at servicen ikke er tilgængelig, eller der kan være lang ventetid til en service.

Tilgængelighed kan vi ikke designe os ud af i SOSI, da dette primært er en egenskab, som de enkelte serviceudbydere skal sikre. Tilgængelighed sikres typisk ved at udarbejde nogle passende skalerings- og testkrav til leverandører af serviceudbydersystemer.

Rådighedsegenskaben er til gengæld en egenskab ved det samlede design i SOSI. Har man "flaskehalse" eller et "single point of failure" i det samlede system, er der større risiko for at det samlede system bryder sammen. For at imødegå disse risici har vi i SOSI valgt at system-til-system kommunikation i videst mulig omfang skal foregå direkte mellem serviceaftager og -udbyder (dvs. uden "relays") og minimere afhængigheden mellem de enkelte elementer i designet.

Hvis IdP'en skulle være nede, kan alle brugere, der allerede har et ID kort, fortsætte med at kommunikere med serviceudbydere. Kun brugere, der endnu ikke har et gyldigt ID kort, vil blive ramt af nedbrudet.

4.2.2 Service Integrity (Transaktionalitet)

Denne QoS egenskab har vi valgt ikke behandlet i første version af SOSI. Behovet for transaktionssikre services opstår først, når der i en "use case service" indgår flere servicekald hvori der indgår skriveoperationer. Når dette behov opstår, vil der blive behov for at introducere globalt unikke transaktions-ID'er i alle forespørgsler/indberetninger og definere kompenserende services (roll-back services) for alle indberetningsservices.

4.2.3 Performance og Reliability

Disse egenskaber kan vi kun i begrænset omfang designe os ud af i SOSI, da dette primært er egenskaber, som de enkelte serviceudbydere skal sikre. Vi har dog lagt vægt på, at de enkelte procestrin hos en serviceudbyder ikke bliver alt for performancekrævende. Det er netop argumentet for at indføre et ID kort, der er meget mere lempeligt at verificere end certifikater. Endvidere har vi forsøgt at sikre, at de enkelte servicemeddelelser ikke bliver enorme, samt at minimere antallet af kald i alle procestrin, specielt "eksterne kald", dvs. kald på tværs af aktører. SOSI lægger op til direkte kommunikation mellem service udbyder og -aftager, med sporadisk kommunikation med tredjepart.

4.2.4 Regulatory (Overholdelse af retningslinier og standarder)

SOSI forholder sig i videst mulig omfang til både internationale standarder (XML, SOAP, WS-SEC, SAML), nationale standarder (OIO, OCES) og domænerelaterede standarder (MedCom standarder).

4.3 Sammenligning med password-beskyttede systemer

I traditionelle systemer har serviceudbydere typisk "beskyttet" services med brugernavn og password. I mange tilfælde har serviceudbydere endda udstillet services gennem interfaces, der kunne anvendes med "tekniske brugere" og kun medsendt data om den kaldende bruger, og forudsat at denne bruger var passende autenticeret og autoriseret af det kaldende system. Det er klart, at hvis brugerens brugernavn og password, eller, endnu værre, den tekniske brugers brugernavn og password bliver kompromitteret, bryder hele sikkerhedssystemet i dise situationer sammen.

Anvendelse af digitale certifikater forbedrer reelt ikke denne sikkerhed, idet den private del af certifikatet stadig kun er beskyttet af et password med mindre man indfører biometriske metoder (f.eks. fingeraftryk). Derimod kan digitale certifikater, eller som i SOSI virtuelle ID-kort baseret på certifikater, forbedre andre sikkerhedsmæssige aspekter. Foruden at gøre det muligt at bevise en brugers identitet hos en serviceudbyder, er det primært uafviselighedsaspekterne der nyder gavn af de digitale certifikater. Ved korrekt anvendelse kan hverken en bruger, et brugersystem eller en serviceudbyder løbe fra at have hhv. foretaget en forespørgsel eller afgivet et svar. Signerer man også de tilknyttede data (f.eks. tidspunkt for afsendelse af en service), er både meddelelsesindholdet og -tidspunktet uafviseligt af aktørerne.

I SOSI lader vi alle muligheder være åbne og tillader autenticitetssikring baseret på både certifikater og brugernavn/password. Hvorvidt det er tilstrækkeligt at være autenticeret vha. password lader vi være op til serviceudbyderen, ligesom det er op til aktørerne at specificere hvorvidt der kræves digital signatur for at sikre uafviselighed.