Sikring af web service snitflader

Transkript

1 Sikring af web service snitflader En operationel vejledning til sikring af nationale web services i sundhedsdomænet Version 1.1 Side 1 af 17

2 Indholdsfortegnelse 1 Introduktion Læsevejledning Målgruppe Oversigt over anvendte forkortelser Betydning af nøgleord Sikkerhedsaspekter Beskyttelse af nationale services Foranstaltninger overblik Sikring af fortrolighed Sikring af integritet (Serviceaftager) (Serviceudbyder) Eksempler på anvendelse af vejledningen Det Fælles MedicinKort en identitetsbaseret service SOSI-GW en infrastrukturservice National klassifikation Appendiks A: Tabel til brug for serviceudbyder Appendiks B: Eksempler på angreb Referencer Dokumenthistorik Side 2 af 17

3 1 Introduktion Nærværende dokument er en vejledning vedrørende sikring af nationale web service snitflader. Med nationale webservices menes her web services udstillet i sundhedssektoren af eksempelvis styrelser, regioner, kompetencecentre osv. der anvendes på tværs af organisatoriske skel, samt web services udstillet i den nationale infrastruktur, f.eks. SOSI-GW på den nationale service platform (NSP). Med sikkerhed menes i denne sammenhæng sikkerhed for påstået identitet af parterne involveret i digital kommunikation (autenticitet), sikkerhed for fortrolighed (konfidentialitet) af de udvekslede informationer, samt sikkerhed for at information udvekslet mellem parterne når frem til modtageren uændret og i sin fulde form (integritet). I andre sammenhænge behandles yderligere sikkerhedsaspekter såsom autorisation, uafviselighed, privacy, tilgængelighed, håndtering af fejlsituationer og afværgelse af angreb osv. I nærværende version af vejledningen behandles disse sikkerhedsaspekter ikke, men vil i fremtidige versioner blive udvidet med disse aspekter. Nationale web services udstillet i sundhedsdomænet kan pt. være sikret både ved foranstaltninger omkring transportlaget (Sundhedsdatanettet, SDN) og gennem anvendelse af formelle protokoller (Den Gode Web Service, DGWS). Vejledningen belyser de forskellige sikkerhedsforanstaltninger en serviceudbyder kan kræve implementeret af serviceaftagere, ved udstilling af en service i en konkret sammenhæng. Motivationen for vejledningen er et støt stigende antal nationale tjenester og et ønske om at drage fordel af nationale og internationale standarder, der formaliserer og kvantificerer sikkerhed. Med denne vejledning til sikkerhedsforanstaltninger etableres et fælles fundament for dialog omkring sikring af nationale services, og kravene til nationale services kvalificeres. Desuden definerer vejledningen en proces, som serviceudbydere kan følge for dels at identificere de relevante aspekter af sikkerhed, der bør findes foranstaltninger for. Med udgangspunkt i [SP800-95] ( Guide to Secure Web Services ) beskrives dimensioner af sikkerhed og tilhørende krav og standarder/specifikationer, og disse holdes op mod typer af nationale services på en form, der gør det muligt at angive, hvilke foranstaltninger en given national service skal implementere og kræve implementeret af serviceaftager i de forskellige sikkerhedsmæssige sammenhænge. 1.1 Læsevejledning Vejledningen er opdelt i en generel introduktion til sikkerhedsaspekter (afsnit 2), en beskrivelse af de sikkerhedsforanstaltninger, der kan kræves for hvert aspekt (afsnit 3), samt udvalgte eksempler på sikkerhedsspecifikationer for nationale services (afsnit 4). Serviceudbydere kan anvende tabellen vedlagt i Appendiks A: Tabel til brug for serviceudbyder til identifikation og dokumentation af sikkerhedsforanstaltninger ved eksponering af nationale services. Side 3 af 17

4 1.2 Målgruppe Da formålet med dette notat er at give en konkret vejledning i sikring af nationale web service snitflader, med beskrivelse af hvilke standarder, der skal implementeres i forskellige sammenhænge, er indholdet af ret teknisk karakter og målrettet softwarearkitekter, udviklere og andre med høj teknisk indsigt i web service teknologier og de relaterede standarder for håndtering af sikkerhed. 1.3 Oversigt over anvendte forkortelser Tabel 1 Oversigt over anvendte forkortelser Begreb/Forkortelse Beskrivelse SDN Sundhedsdatanettet; for yderligere information se [SDN_MEDCOM]. SOSI TTP STS WSC WSP CA OCES NIST ServiceOrienteret SystemIntegration; fællesregionalt projekt med sigte på at lave sikker systemintegration i en serviceorienteret arkitektur. Trusted Third Party; en ekstern aktør, der står inde for noget, eksempelvis identitet. Security Token Service; en billetautomat, der veksler digitale identitetsbeviser (tokens) til service tokens, som giver adgang til specifikke services. Web Service Consumer; anden term for serviceaftager. Web Service Provider; anden term for serviceudbyder. Certificate Authority, også kaldet certificeringscenter; en fysisk eller juridisk enhed, der er bemyndiget til at generere, udstede og administrere certifikater. Offentlige Certifikater til Elektronisk Service, en fælles standard for elektronisk kommunikation og autentifikation. OCES er etableret af Videnskabsministeriet. National Institute of Standards and Technology, en offentlig institution under det amerikanske handelsdepartement. 1.4 Betydning af nøgleord I den følgende del af dokumentet skal nøgleordene»skal«,»kræves«,»må IKKE«,»BØR«,»BØR IKKE«,»ANBEFALET«,»KAN«og»VALGFRI«tolkes som beskrevet i [RFC-2119]. Side 4 af 17

5 2 Sikkerhedsaspekter Traditionelt anvendes CIA-modellen (Confidentiality, Integrity, Availability) til at opsummere sikkerhed [WIKI-IS], men over tid er flere aspekter kommet til. De identificerede sikkerhedsaspekter er opsummeret nedenfor: - Identifikation og Kobling mellem en bruger og en digital identitet, baseret på afgivelse af akkreditiver. dækker både metoden hvormed en bruger autentificerer sig, og niveauet af sikkerhed for identitetens ægthed (identifikation). I teorien er kravene til autentifikation af serviceaftager hhv. serviceudbyder symmetriske, men i praksis dækker de eksisterende nationale standarder i sundhedsdomænet ikke udbyder og aftager ensartet, og derfor er der forskellige krav til de to retninger af autentifikationen. 1 - Autorisation Styring og håndtering af brugerens rettigheder til adgang til ressourcer, herunder data og funktionalitet. - Integritet Sikring af kommunikationen, således at serviceudbyder og serviceaftager er garanteret, at beskederne ikke ændres mellem afsender og modtager. Dermed beskyttes mod forskellige angrebstyper, hvor angriberen ændrer eller gentager dele af kommunikationen uden at de øvrige parter opdager det. - Uafviselighed Mulighed for at føre bevis for, at en bruger har udført en given handling på et givet tidspunkt, eksempelvis tilgået personfølsom information eller ordineret medicin. Uafviselighed kan opnås ved at kombinere autentifikation, audit (herunder logning) og integritet. - Fortrolighed Sikring af kommunikationen mellem serviceudbyder og serviceaftager, således at uvedkommende ikke kan opsnappe og læse indholdet af de udvekslede beskeder. Dette gælder i særdeleshed potentielt personhenførbare informationer. - Privacy Beskyttelse af potentielt personhenførbare data mod uautoriseret brug. - Audit Analyse og gennemgang af et system med henblik på sikkerhed og funktionalitet, samt logning af brugerens handlinger og adfærd. Et meget vigtigt resultat af audit og logning er muligheden for at tilvejebringe uafviselighed; eksempelvis at kunne bevise at brugeren har udført en bestemt handling på et bestemt tidspunkt. - Tilgængelighed Sikring af en given tjenestes oppetid, så brugere har adgang til tjenesten indenfor de foruddefinerede rammer. Der henvises til [SP800-95] (tabel 2-1, side 2-13) for yderligere information og eksempler. 1 DGWS beskriver hvorledes en serviceaftager (WSC) skal autentificere sig, men forlader sig på transportlaget til autentifikation af serviceudbyder (WSP) (anvendelse af SSL/TLS). DGWS 1.1 beskriver digital signering af svar som metode til autentifikation af serviceudbyder (WSP), men DGWS 1.1 har ikke opnået status som formelt anbefalet standard. Side 5 af 17

6 I nærværende notat behandles aspekterne, Fortrolighed og Integritet. De resterende aspekter (Autorisation, Audit og Tilgængelighed, samt de afledte aspekter Uafviselighed og Privacy) udestår, da de nuværende krav og anbefalede standarder ikke dækker disse. I takt med at der vedtages, hvilke standarder der skal følges for at opfylde kravene knyttet til de respektive sikkerhedsaspekter, vil notatet blive opdateret. Figur 1 Visuelt overblik over udvalgte web service relaterede standarder, der anvendes i sundhedssektoren. Kilde: [DGWS]. De internationale standarder, der fungerer som ankerpunkt for opfyldelse af kravene til de behandlede sikkerhedsaspekter er WS-Security, kryptering af transportlaget (SSL/TLS), og digitale certifikater (X.509). Den nationale standard, der anvendes i sundhedssektoren til opfyldelse af sikkerhedsaspekterne, er DGWS 1.0.1, som bygger videre på bl.a. WS-Security, som illustreret på Figur 1. Der henvises til [DGWS], [WS-SEC], [SSL-TLS] og [X509] for yderligere information. Side 6 af 17

7 3 Beskyttelse af nationale services Følgende procedure bør følges ved håndtering af sikkerhed i nationale services: 1. Det skal afdækkes præcis hvilke sikkerhedsaspekter, der er relevante for den pågældende service (se Tabel 2 nedenfor) 2. For hver omgivelse, den pågældende service påtænkes udstillet i, tages der stilling til hvilke foranstaltninger, der skal kræves for de relevante sikkerhedsaspekter 3. Resultaterne indføres i tabellen i Appendiks A: Tabel til brug for serviceudbyder 4. Tabellen med eventuelle uddybende kommentarer offentliggøres Sikringen af en given snitflade er afhængig af netværket, hvorfra snitfladen tilgås, samt den nationale services krav til håndtering af de ovennævnte sikkerhedsaspekter. På de følgende sider beskrives de konkrete foranstaltninger, en national service og serviceaftagerne SKAL implementere for at opfylde sikkerhedskravene. Det bør i denne sammenhæng bemærkes, at OWSA-T modellen [OWSA-T] med fordel kan benyttes som referencemodel, idet kravene til anvendelse af eksempelvis SSL-kryptering og XML er nøje beskrevet i OWSA-T. Nærværende vejledning kan i dette perspektiv betragtes som en yderligere konkretisering af foranstaltningerne beskrevet i OWSA-T, og en præcisering af hvilke foranstaltninger der kan anvendes til at opfylde de ønskede sikkerhedsaspekter. 3.1 Foranstaltninger overblik I Tabel 2 er foranstaltningerne til sikring af nationale services opsummeret for hvert af de specificerede sikkerhedsaspekter. I de følgende afsnit er foranstaltningerne beskrevet yderligere. Side 7 af 17

8 Tabel 2 foranstaltninger til sikring af nationale services Sikkerhedsaspekt Krav Godkendte foranstaltninger Fortrolighed Integritet (Aftager) (Udbyder) Kommunikationen skal beskyttes mod uvedkommende adgang til data. Kommunikationen må ikke uopdaget kunne ændres imellem afsender og modtager Aftager skal autentificere sig i tilstrækkeligt omfang Udbyder skal autentificere sig i tilstrækkeligt omfang Lukkede netværk SSL-kryptering af transportlaget Lukkede netværk SSL-kryptering af transportlaget 2 Signerede SOSI-IDkort 3 som beskrevet i [DGWS 1.0.1] Lukkede netværk Inspektion af server-certifikat 3.2 Sikring af fortrolighed Nationale services, der giver adgang til potentielt personfølsomme data eller andre typer data, uvedkommende ikke må få kendskab til, skal stille krav om sikring af fortrolighed for kommunikationen mellem serviceudbyder og serviceaftager. Godkendte foranstaltninger - Anvendelse af lukkede netværk, i form af enten o En direkte forbindelse, hvilket er en tilstrækkelig foranstaltning til sikring af fortrolighed, hvis den anvendte teknologi og den anvendte operatør er godkendt af Datatilsynet. Modemforbindelser og MPLS netværk er eksempler på direkte forbindelser. o Sikrede netværk, hvor der er adgangskontrol og overvågning af både fysisk og digital aktivitet. En afgrænset del af en regions eller en kommunes LAN, hvori fagsystem-servere er placeret, er eksempler på sikrede netværk. - SSL-kryptering af transportlaget 3.3 Sikring af integritet Dette krav sikrer mod at en angriber, uden at parterne opdager det, ændrer dele af kommunikationen mellem serviceudbyderen og serviceaftageren. Godkendte foranstaltninger - Anvendelse af direkte forbindelser o En direkte forbindelse er en tilstrækkelig foranstaltning til sikring af integritet, hvis den anvendte teknologi og den anvendte operatør 2 Anvendelsen af kryptering til sikring af integritet er ikke et udtryk for et behov for sikring af fortrolighed, men afledt af den eksisterende brug af SSL til kryptering af transportlaget, idet SSL også sikrer integritet 3 Disse skal om muligt være STS udstedte tokens. Side 8 af 17

9 er godkendt af Datatilsynet. Modem-forbindelser og MPLS netværk er eksempler på direkte forbindelser. - SSL-kryptering af transportlaget Det bemærkes, at de anvendte standarder ikke giver mulighed for at signere de udvekslede beskeder (eller dele heraf). Det forventes, at fremtidige versioner af DGWS vil understøtte hel eller delvis signering af beskederne, hvilket i givet fald vil blive tilføjet som en godkendt foranstaltning til sikring af integritet. 3.4 (Serviceaftager) Kravet om autentifikation for serviceaftagere af identitetsbaserede services løses gennem anvendelse af [DGWS 1.0.1]. Brugere opretter et DGWS IDkort gennem anvendelse af stærk autentifikation (pt OCES Medarbejdersignatur). Godkendte foranstaltninger - Anvendelse af DGWS IDkort Af hensyn til fagsystemerne er der indført en undtagelse fra den generelle regel, således at det i særligt sikrede systemomgivelser er tilladt at veksle imellem et usigneret niveau 1 IDkort og et DGWS IDkort. 4 Forudsætningen for denne lempelse af kravet er, at brugeren har et gyldigt DGWS IDkort, og at det pågældende fagsystem beskytter det usignerede IDkort mod at blive opsnappet af uvedkommende. 3.5 (Serviceudbyder) I den nuværende systemarkitektur er der kun i begrænset omfang taget stilling til autentifikation af serviceudbyder, idet serviceudbyderen implicit autentificeres gennem inspektion af servercertifikatet og dermed kun når der anvendes kryptering af transportlaget (SSL). Denne sammenblanding af autentifikation på beskedniveau og transportniveau er en nødvendig konsekvens af anvendelsen af DGWS 1.0.1, der ikke foreskriver hvorledes serviceudbyder skal autentificeres 5. I praksis betyder det, at autentifikation af serviceudbyder ikke er krævet i den nuværende systemarkitektur. 4 På sigt kan man forestille sig, at tokens fremkommet i en Kerberos autentifikation vil kunne anvendes (dette er dog i skrivende stund en overvejelse af spekulativ form). 5 I en fremtidig version af en national standard for udveksling af sundhedsinformation via web services, kan det vel tænkes, at autentifikation af serviceudbyder kan baseres på STS tokens udstedt på baggrund af VOCES eller FOCES certifikater. Side 9 af 17

10 4 Eksempler på anvendelse af vejledningen Her gennemgås eksempler på anvendelse af vejledningen for nogle relevante servicetyper. Serviceudbyderen gennemgår sikkerhedsaspekterne som beskrevet i nærværende vejledning og indfører egne krav til om der er behov for at håndtere sikkerhedsaspekterne for den pågældende service. I vurderingen af relevansen af de enkelte sikkerhedsaspekter skal serviceudbydere ikke forholde sig til de sammenhænge, hvori servicen udstiller en snitflade, men blot om sikkerhedsaspektet er relevant for den pågældende service. I Appendiks A: Tabel til brug for serviceudbyder ses en tabel-skabelon, hvori serviceudbyderen kan indføre kravene. Dernæst skal serviceudbyderen udfylde en kolonne for hver sammenhæng, hvori servicen udstilles i kolonnen specificeres hvilken foranstaltning der skal anvendes for at opfylde de enkelte sikkerhedsaspekter. For hvert aspekt udvælges én foranstaltning fra listen af godkendte foranstaltninger. Dermed sikres en entydig beskrivelse, som serviceaftagere kan følge. Efter gennemgangen af sikkerhedsaspekterne kan de nødvendige foranstaltninger for en snitflade udstillet i en konkret sammenhæng nu aflæses direkte i tabellen. 4.1 Det Fælles MedicinKort en identitetsbaseret service Identitetsbaserede services er tjenester, hvor der stilles krav til autentifikation og autorisation af den bruger, der ønsker at opnå adgang til informationer og funktionalitet. Som eksempel vælges her det Fælles MedicinKort; en identitetsbaseret national service, der pt. udstiller en snitflade på sundhedsdatanettet (SDN). Derudover vises de foranstaltninger, der ville skulle forlanges af serviceaftager, hvis FMK skulle udstilles over det åbne internet. Samtlige sikkerhedsaspekter viser sig ved gennemgang af kravene fra FMK at være relevante, hvilket indføres i kolonne to i tabellen nedenfor. I den følgende kolonne indføres de foranstaltninger, der kræves ved anvendelse af FMK over sundhedsdatanettet. Som det ses, er de fleste krav opfyldt implicit, idet foranstaltningerne knyttet til sundhedsdatanettet giver både sikkerhed for fortrolighed og integritet, samt (indirekte) autentifikation af FMK som service. 6 For eksemplets skyld er der tilføjet en kolonne yderligere, der beskriver kravene, som man kan forestille sig, at FMK som udbyder vil stille til anvendelse af FMK over internettet. 6 Typisk kommunikationen med FMK foregå med en SOSI-GW og/eller en SOSI-DCC indskudt imellem serviceaftager og FMK-udbyderen, og dermed vil denne del af kommunikationen skulle sikres separat. Dette er beskrevet yderligere i afsnit 4.2. Side 10 af 17

11 Sikkerhedsaspekt Relevans Det Fælles Medicinkort (FMK) krav til sikkerhed Sundhedsdatanettet Fortrolighed Ja Kravet er opfyldt gennem de generelle foranstaltninger implementeret i SDN (sikring af transportlaget ved anvendelse af direkte forbindelser). Integritet Ja Kravet er opfyldt gennem de generelle foranstaltninger implementeret i SDN (sikring af transportlaget ved anvendelse af direkte forbindelser). (Aftager) (Udbyder) Ja Ja Anvendelse af SOSI-IDkort som beskrevet i [DGWS 1.0.1]. Kravet er opfyldt gennem de generelle foranstaltninger implementeret i SDN (aftalebaseret adgang til endpoints). Internet Transportlaget skal være SSLkrypteret. Transportlaget skal være SSLkrypteret. Anvendelse af SOSI-IDkort som beskrevet i [DGWS 1.0.1]. WSC skal inspicere og godkende/afvise servercertifikat (SSL). Foranstaltningerne beskrevet for sundhedsdatanettet er identiske med situationen i dag, og sikkerhedskravene er derfor formelt overholdt for FMK udstillet på sundhedsdatanettet SOSI-GW en infrastrukturservice Infrastrukturservices er tjenester, der assisterer serviceaftagere i brugen af nationale services. Infrastrukturservices fungerer som mellemstationer for kommunikationen mellem serviceaftager og serviceudbyder, idet de udstiller serviceudbyderens snitflade i stort set uændret form. Ansvaret for at sikre den pågældende snitflade overtages dermed af infrastrukturservicen, og dermed skal snitfladen beskyttes som var den udstillet direkte af serviceudbyderen. Pt. vedligeholder Digital Sundhed to nationale infrastrukturservices, nemlig - SOSI-DCC ( afkoblingskomponenten ), der har som formål at give svartidsgaranti til det kaldende system og gøre det muligt at gennemføre asynkrone kald med afleveringsgaranti, og - SOSI-GW (SOSI GateWay), der bl.a. kan "oversætte" usignerede niveau 1 IDkort til DGWS IDkort For ovennævnte infrastrukturservices gælder det særlige, at de er identitetsbaserede, men ikke i forhold til identiteten af den bruger, der er relevant i forhold til den nationale service, der er endemålet i kommunikationen. I stedet er det identiteten af det system, der kommunikerer med den pågældende infrastrukturservice, der er relevant. Denne skelnen mellem identiteten af det 7 Det bør bemærkes, at en eventuel fremtidig anvendelse af FMK i en anden sammenhæng vil medføre, at udbyderen skal tage stilling til hvilke foranstaltninger, der skal anvendes dér. Eksempelvis vil en browserbaseret FMK-snitflade tilgængelig fra internettet fordre at integritet og fortrolighed opfyldes gennem anvendelse af SSL. Side 11 af 17

12 kaldende system og identiteten af slutbrugeren er nødvendig, da SOSI-GW netop fungerer som identitets-vekselautomat, hvor et fagsystem uden kendskab til brugerens akkreditiver kan foretage kald på vegne af brugeren Beskyttelse af eksisterende snitflade I skrivende stund udstilles SOSI-GWs web services udelukkende på interne netværk, hvor der er stram adgangskontrol, og sikkerhedsaspekterne derfor anses for værende opfyldt gennem tillid til parterne på netværket. I anvendelsen af Sign-On biblioteket bliver der behov for at tilgå identitetsoperationen på SOSI-GW fra andre interne netværk, hvor der er knap så stram styring af aktørerne på netværkene, og derfor er der behov for at angive eksplicitte foranstaltninger til beskyttelse af snitfladen i denne sammenhæng. Tabel 3 Krav til SOSI-GW (eksisterende snitflade) SOSI-GW Sikkerhedsaspekt Relevans krav til sikkerhed Stærkt beskyttede netværk Fortrolighed Ja Opfyldt gennem foranstaltningerne i netværket (stram adgangskontrol og tillid til aktørerne) Integritet Ja Opfyldt gennem foranstaltningerne i netværket (stram adgangskontrol og tillid til aktørerne) (Aftager) (Udbyder) Intranet Transportlaget skal være SSL-krypteret. Transportlaget skal være SSL-krypteret. Ja IP-white list Anvendelse af SOSI-IDkort Ja Opfyldt gennem foranstaltningerne i netværket (stram adgangskontrol og tillid til aktørerne) WSC skal inspicere og godkende/afvise servercertifikat (SSL). Aspektet dækkende autentifikation af serviceaftager er markeret med Ja i anførselstegn, idet den nuværende SOSI-GW giver mulighed for at anvende en liste af godkendte IP-numre, hvilket giver en rudimentær sikring af snitfladen. Det forventes, at SOSI-GW indenfor en overskuelig fremtid vil implementere og kræve en standardiseret sikkerhedsforanstaltning til autentifikation af serviceaftageren. 4.3 National klassifikation Der eksisterer i dag et antal nationale klassifikationer, der er til rådighed enten på sundhedsdatanettet eller frit tilgængeligt på internettet. Fælles for disse services er, at de ikke er identitetsbaserede, og at informationerne ikke er direkte personfølsomme 8. Principielt bør opslag i en national klassifikation behandles 8 Klassifikationerne kan dog indeholde persondata, eksempelvis SOR, hvor kontaktinformationer kan slås op for organisatoriske enheder. Side 12 af 17

13 fortroligt, idet en potentiel angriber kan aflede information ud fra opslagsmønstre; i praksis vil dette sikkerhedsaspekt nok ikke vurderes relevant. Uanset type af klassifikation vil det være nødvendigt at kræve sikkerhed for integriteten af kommunikationen, idet serviceaftager skal kunne være helt sikker på at få de korrekte informationer fra en forespørgsel. En potentiel angriber må ikke uopdaget kunne ændre hverken forespørgsel eller svar, idet information fra en klassifikation kan fungere som beslutningsgrundlag for en kritisk klinisk beslutning. Anonyme klassifikationer fordrer i sagens natur ikke autentifikation af serviceaftager, og i den eksisterende sikkerhedsforståelse fordres der ej heller autentifikation af serviceudbyderen 9. National klassifikation X krav til sikkerhed Sikkerhedsaspekt Relevans Sundhedsdatanettet Internet Fortrolighed Nej Integritet Ja Kravet er opfyldt gennem de generelle foranstaltninger implementeret i SDN (sikring af transportlaget ved anvendelse af direkte forbindelser). Transportlaget skal være SSL-krypteret. (Aftager) (Udbyder) Nej Nej 9 Det må rimeligvis kunne forventes, at der på et tidspunkt vil komme krav til autentifikation af serviceudbyderen, så serviceaftager er garanteret sikkerhed for at kommunikationen ikke er dirigeret hen til en potentiel angriber. Side 13 af 17

14 5 Appendiks A: Tabel til brug for serviceudbyder Nedenstående tabel skal udfyldes af serviceudbyderen, så det klart fremgår præcis hvilke foranstaltninger, der kræves af udbyder og aftager ved brug af den udstillede service. For hver sammenhæng, servicen udstilles i, tilføjes en kolonne med angivelse af påkrævede foranstaltninger. Tabel 4 Tabel til brug for serviceudbyder [Service] Sikkerhedsaspekt Relevans krav til sikkerhed Sammenhæng (f.eks. SDN, internettet, osv. ) Fortrolighed Ja/Nej [Angivelse af påkrævet foranstaltning skal vælges fra listen af godkendte foranstaltninger beskrevet i afsnit 0] Sammenhæng (f.eks. SDN, internettet, osv. ) [Angivelse af påkrævet foranstaltning skal vælges fra listen af godkendte foranstaltninger beskrevet i afsnit 0] Integritet Ja/Nej [Se afsnit 3.3] [Se afsnit 3.3] (Serviceaftager) (Serviceudbyder) Ja/Nej [Se afsnit 3.4] [Se afsnit 3.4] Ja/Nej [Se afsnit 3.5 [Se afsnit 3.5 Side 14 af 17

15 6 Appendiks B: Eksempler på angreb De vigtigste trusler som web services skal beskytte sig mod, samt de teknologier/standarder, der bedst afværger truslerne. Kilde: [Security-Challenges] og [SP800-95] (TABLE 2-1). Tabel 5 Eksempler på angreb Trussel Message alteration Loss of confidentiality Falsified messages Man in the middle Principal spoofing Forged claims Replay of message Replay of message parts Denial of service Beskrivelse En angriber indsætter, fjerner eller ændrer information i en besked med det formål at snyde modtageren. Information i en besked læses af en uautoriseret aktør. En angriber opbygger en besked med det formål at narre modtageren til at tro at beskeden er fra en gyldig afsender. En angriber placerer sig mellem udbyder og aftager som mellemstation for beskeder, uden at parterne opdager dette. Beskeder kan dermed læses og ændres af angriberen. En angriber konstruerer og sender beskeder med akkreditiver udformet således at de fremstår som værende fra en anden, autoriseret principal. En angriber konstruerer en besked med falske akkreditiver så de fremstår for modtageren som værende gyldige. En angriber opsnapper og gensender en tidligere fremsendt besked. En angriber gensender udvalgte dele af en eller flere beskeder som del af en ny besked. En angriber forårsager uforholdsmæssig ressourceforbrug hos en udbyder med det resultat, at udbyderen i kortere eller længere tid er ude af stand til at servicere sine brugere. Tabel 6 Trusler som de håndteres af de gængse web service standarder Message Alteration Loss of Confidentiality Falsified Message Man in the Midle Principal Spoofing Forged Claims Replay of Message Parts Replay of Message Denial of Service XML Encryption X X X X X XML Signature X X X X X X WS-Security Tokens X X X WS-Addressing X SSL/TLS X X X* X X* X* X SSL/TLS with client certificates X X X X X X X HTTP Authentication X X X *-markeringerne i tabellen indikerer, at truslen er afværget den ene retning i kommunikationen, nemlig i svaret fra udbyderen, men ikke i forespørgslen. Side 15 af 17

16 7 Referencer MS-WASF WS-SEC SSL-TLS X509 DGWS SP SP Security- Challenges WS-FEDERATION SST-AUT CISCO SDN_MEDCOM OWSA-T RFC-2119 Security-Taxonomy WIKI-IS Microsoft om Web Application Security Fundamentals: Den Gode Webservice 1.0.1: Electronic Authentication Guideline Guide to Secure Web Services Security Challenges, Threats and Countermeasures at Sundhedsstyrelsens autorisationsregister: Lovgrundlag for registeret: OWSA Model T sikker direkte transport: Link direkte til standarden: IETF RFC 2119: Key words for use in RFCs to indicate Requirements Levels : A State of the Art Security Taxonomy of Internet Security: Threats and Countermeasures : ad&gid=42&itemid=36 Side 16 af 17

17 8 Dokumenthistorik Version Dato Ansvarlig Bemærkninger / CHE Første version til indstilling i arkitekturrådet efter review af arkitekturfunktionen / CHE Opfølgning efter arkitekturrådsmøde, JRI review / CHE Opfølgning efter JSK review / JSK Ændringer accepteret. Side 17 af 17