Dette indlæg er alene udtryk for skribentens egen holdning.

Apropos Single Signon

4. juni 2008 kl. 22:0514
Artiklen er ældre end 30 dage

Computerworld kørte i weekenden en større artikelserie om lægernes behov for at reducere mængden af logins der foretages i løbet af en arbejdsdag. Artiklerne fokuserede ensidigt på behovet for at introducere single-signon (SSO) for en række applikationer, dvs. log på én gang og få adgang til mange systemer.

Jeg arbejder med denne problematik i relation til sundhedssektoren for tiden og i min optik er SSO kun en lille brik i det store puslespil, der i virkeligheden handler om at give klinikere hurtig og sikker adgang til det sæt af applikationer, der understøtter de sundhedsfaglige arbejdsopgaver (den kliniske it-arbejdsplads) der hvor der er brug for det. Adgangen skal gives under det delte hensyn til patientens rettigheder og lægens behov for information i overensstemmelse med den aktuelle lovgivning (Sundhedsloven, Persondataloven).

Applikationerne spænder fra røntgen systemer over medicinmoduler til parakliniske systemer som blodbank og patologi, men rammer også f.eks. email og delte dokumentdrev, samt nationale systemer som Sundhed.dk. Systemerne kommer fra vidt forskellige leverandører og er som udgangspunkt siloer, designet som om de var det eneste system i denne verden.

Resultatet er til at få øje på: Hvert system har sin egen brugerdatabase, i reglen bygget op omkring en brugernavn / password model og er sat op til at logge brugeren af efter en rum tids inaktivitet ud fra en erkendelse af at denne kan have forladt maskinen og dermed potentielt udsat kliniske data for misbrug. Uden nogen form for indgriben får man med et sådant kompleks hurtigt multiple identiteter i multiple systemer med multiple passwords og andre akkreditiver som f.eks. digitale signaturer. Det er der, de små gule lapper i reglen begynder at indfinde sig på skærmen.

Artiklen fortsætter efter annoncen

Det skal for en god ordens skyld nævnes, at der ikke er noget nyt under solen i alt dette og at der allerede er gjort - og gøres - meget for at forbedre situationen rundt om i landet.

Arbejdet på sygehusene er karakteriseret ved behovet for mobilitet, som når en læge f.eks. går stuegang og lige skal checke fru Hansens aktuelle medicinering. Det er derfor af afgørende betydning, at den kliniske it-arbejdsplads kan tilgås tæt ved patienten, noget der i dag ofte realiseres via PC'er lokaliseret strategisk rundt omkring på hospitalerne. Skal man samtidig kunne tilgå den kliniske it-arbejdsplads fra mange forskellige maskiner og bære tilstanden af åbne applikationer videre for at øge hastigheden fra login til dataadgang bliver det pludselig nødvendigt at introducere remote-access løsninger.

Brikkerne i den klinisk rettede del af puslespillet omfatter altså bla: konsolidering af bruger identiteter, så klinikere ikke skal huske et utal af passwords; infrastruktur til remote-access for at understøtte mobilitet; single-signon mellem applikationer og herunder sømløs adgang til eksterne tjenester for at reducere logintider; optimering af tiden fra login til klinikeren har adgang til it-arbejdspladsen; potentielt alternative autentifikationsmekanismer som smartcards og tokens der kan fjerne behovet for timeouts og meget mere.

Der er imidlertid også et helt andet sæt brikker som er nok så væsentlige, nemlig de administrative. Nye ansatte skal hurtigt kunne gives adgang til netop de applikationer de har brug for og hurtigt fratages de samme rettigheder ved afsked. Det kræver en stærk brugeradministration, der bla. tager højde for sundhedssektorens unikke lovmæssige bindinger om krav til at patienten er i behandling af den aktuelle læge før adgang gives, mm.

Kliniske applikationer kan i nogle tilfælde bringes til at trække på den samme brugerdatabase, f.eks. et directory og i andre tilfælde må en anden del af infrastrukturen tage sig af provisionering af brugere, roller, rettigheder, osv. At lave en sådan kobling for mange it-systemer, der oprindeligt var tænkt som siloer er ikke en lille opgave, der bla. involverer transformationer af en central forståelse for sikkerhedsrelateret information til de lokale systemers behov.

Så ja: Det handler om single-signon, men kun som et middel til at nå et større mål nemlig hurtig og sikker adgang til den for behandlingen nødvendige information.

14 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
1
4. juni 2008 kl. 23:39

Når jeg læser den slags, kan jeg ikke lade være med at tænke på Suns efterhånden 10 år gamle SunRay.

Din session kører på en "server" et eller andet sted i verden (who cares where), og du stikker så et smartcard i en af de mange dumme SunRay terminaler og har straks adgang (evt. efter password) til din session (X11). Hiver du kortet ud, kan du tage det med til næste terminal. Andre fordele: Sunrays bruger ca. ingen strøm, larmer ikke, har ingen lokal disk (læs: installation) og koster en slik - brænder den sammen tager du en ned fra hylden, skifter den og arbejder videre.

Basalt set ville man i denne situation løse en mia. applikations-problemer, blot ved at flytte mobiliteten ned i operativsystemet.

2
5. juni 2008 kl. 00:02

Kåre, du har fat en vigtig problemstilling, som måske kan forekomme mange it-folk at være lidt banal --- men som er dræbende for it-brugere i sundhedsvæsenet: Se fx Lægeforeningens udmeldinger hér --- http://www.laeger.dk/nyhed/download/docs/F31187/LF's%20politik%20for%20sundheds-it.pdf

Og så har du glemt en ting, som også kan få vores pis i kog: Der er nogen, som på et eller andet tidspunkt engang i fortiden, har fået den fikse idé at man kan øge sikkerheden i brugen af sundheds-it ved at tvinge folk til at skifte password hver 3. måned.

De fleste kan måske klare sig uden gule sedler etc. det første år, men så...!

4
5. juni 2008 kl. 08:30

Tak til Kåre for endnu et fint blog-indlæg. En glimrende lejlighed til at nuancere de tilbagevendende SSO-indlæg rettet mod hospitalernes it-systemer - senest som det gennemgående tema i Computerworld og Dagens Medicins tillæg "Digital Sundhed".

Hospitalsklinikerene (læger, sygeplejesker, osv.) ønsker/kræver at slippe for deres mange logins. Og vi er enige - det er indiskutabelt, at mange klinikere har alt for mange logins i løbet af en arbejdsdag. Så lad os dog alle deltage i koret og kræve SSO - nu!

Men hov. Det er vist hverken god skik blandt læger eller it-folk at diktere en løsning uden at afdække behovet. Måske skulle vi lige overveje, om SSO, nu også er, hvad klinikerne efterlyser.

For at vurdere dette er det vigtigt at konstater, at det kliniske personale har en arbejdsdag, som ikke ligner det traditionelle kontorpersonales. Klinkeren bevæger sig meget, har kort tid til at få overblik over patienten, har ind i mellem brug for straks-adgang til data, og så er der jo lige kravet om ekstrem renlighed. Dette er windows og den typiske pc grundlæggende slet ikke egnet til!

Målet er kort sagt en effektiv arbejdsdag og at give patienten den bedst mulige behandling. Dette kan vi udtrykke som: Let og hurtigt adgang til al relevant information om patienten. Mobilitet - system adgang hvor man er. Systemerne skal understøtte sammenhæng i de præsenterede informationer, så der arbejdes med samme patient på hele den kliniske it-arbejdsplads. Dette sikrer behandlingskvaliteten og gøre det let at skifte fra en patient til den næste. Tilgang via it-arbejdspladsen til alle relevante data, lokale såvel som nationale (uden at patientens rettigheder kompromitteres). Hvilket stiller mange krav til både systemernes indhold og hastighed, maskinernes udformning, osv.

I Region Hovedstaden har vi erfaringer med SSO, da det er rullet ud flere steder. Den erfarne it-mand kan selv regne det ud - det er ikke en mirakelkur! Ud erfaringerne vil jeg tillade mig at konkludere, at SSO er en lap på et problem - bestemt en lap det kan betale sig at fokusere på i som kortsigtet løsningselement, men at løse det reelle problem kræver en større indsats - og derfor udarbejder vi en strategi for området.

Mvh. Claus E. Thorsen, It-strategi og -arkitektur, Region Hovedstaden.

5
Indsendt af Anonym (ikke efterprøvet) den tor, 06/05/2008 - 10:21

Vi arbejder på præcis den samme problemstilling, men med den væsentlige forskel at vi ser en lille smule længere frem og arbejder mod holdbare sikkerhedsmodeller i en totalt integreret verden.

Det vi ser i dag - som f.eks. beskrevet med server-side SSO - er kortsigtede handlinger som jeg ville betegne som præget af desparation uden vision.

Behovene er mange og komplekse - både Kåre og Claus har beskrevet nogle af de vigtigste her. Der er betydelige konsekvenser i form af dårligere behandling, spild af tid og penge, komplekse processer etc. Dvs. vi er på ingen måde uenige i at det er vigtige problemer at løse og endda at løse godt.

Men ser man på tilgangen til løsningsmodeller er den bedste test at antage at modellen - både den enkelte del og flere dele - er inficeret af en angriber. Så bør det stå klart for enhver at der ganske enkelt ikke er en sikkerhedsmodel indbygget.

Det er kun et spørgsmål om et minimum af authentikering, men i en model som bedst kan betegnes som et man-in-the-middle angreb. Det er placebo-sikkerhed som kun virker så længe ingen angriber det og alle opfører sig præcis som de burde.

Problemet er at man antager at behandlerne er sikkerhedsproblemet fremfor at foksuere på alle de sekundære interesser - de konkrete behandlere er formentlig de eneste man kan og bør stole på.

At lappe er måske ok - men problemet er hvis de investeringer man foretager IKKE arbejder mod et mål, men tværtimod bringer en LÆNGERE VÆK fra målet.

Præcis det vil være min påstand er tilfældet i den danske sundhedssektor i dag. Man bevæger sig kontinuert LÆNGERE VÆK fra effektiv sundhedsbehandling fordi investeringerne IKKE bygger i en retning men blot addresserer kortsigtede hensyn uden vision eller mål.

For hver krone man investerer i dag skal man investere 2 kroner i morgen og slås med mere ineffektive og mere usikre systemer relativt til det man burde. Det er præcis hvad Gjellerup-rapporten siger om den offentlige sektor - den bliver dyrerere og dårligere år for år. Her har vi et godt eksempel på hvorfor det sker maskeret som "noget godt".

Man bør distribuere sikkerhedsmodellen så den bliver integreret i processerne istedet for noget kunstig perimeterkontrol bygget uden på systemer uden sikkerhed. Samtykke er ikke en registrering i en database, men en delegering etableret i forbindelse med f.eks. en henvisning.

Man bør tænke behovsdrevne processer ind i modellen, dvs. koncentere adgang til data omkring PATIENTENs styring. I dag behandler man borger som inkompetente og gør dem dermed mere inkompetente.

Man bør åbne kundepunkterne istedet for at blokere dem omkring en alt for primitiv model og tvangsstandarder som ikke kan rumme virkeligheden. BÅDE SSO og portaler bliver single-points-of-trust- failure og flaskehalse når de etableres serverside med koncentration af kontrollen over mange processer på en gang.

Man bør se procsser på kryds og tværs af offentlige og private enheder i stedet for den primitive offentlige "firewall" man i dag bygger. I dag er der alæt for megen forældet økonomisk ideologi og falske myter indbygget i systemdesignet uden man stiller spørgsmålstegn ved formålet.

Man bør fokusere på MENNESKER, KUNDER og BEHOV i stedet for systemer, kontrol og nemme "standarder".

Jeg ved ikke hvorfor man tænker så kortsigtet, men det går igen i mange af indlæggene. Måske er systemfolk så bange for brugerne at de glemmer at stille spørgsmålstegn ved de ansvar, de pålægger systemenhederne, uden at have sikkerhedsmodeller eller tilpasningsmodeller herfor?

Problemet er ikke kun sikkerhedsmæssigt teknisk, men også et spørgsmål de økonomiske modeller (behovsdrevet versus i dag stadig mere planøkonomisk), customiserbart (individuelt og formålsbestemt versus i dag stadig mere standardiseret og one-size-fits-all), magt og prestige spørgsmål (fokus på kundernes nytteværdi versus i dag hvor man fokuserer på hvad JEG kan).

Det er sværere at tage ansvar og ofte er problemet at ansvaret ikke følger behovet eller indflydelsen. Det forværres af at man ikke ahr et åbent marked, men en alt for stiv økonomisk styringsproces.

Problemet er ikke så meget at man foretager sig kortsigtede tiltag men at man ikke arbejder frem mod et mål med en vision bag.

Det er fint at tage midlertidige steps hvis man VED hvor man springer over hvor gærdet er for lavt, men her ser jeg den process som gør midlet til målet og glemmer formålet i andet end retorik.

Og der er alt for megen prestige involveret - hvor man istedet for at arbejde mod et mål har travlt med at promovere egne tiltag af egeninteresse.

Single signon er glimrende set fra brugerens synspunkt, men det er en CLIENT-side ting, fordi det er en katastrofe set fra systemsiden - for sikkerhed, effektivitet og brugervenlighed - og det er endda før vi kommer ind på de mere etiske og retssikkerhedsdmæssige aspekter af det umenneskelige systemparadigme.

Selvom man laver server-side løsninger SKAL systemerne forberedes på overgangen til åbne og client-side modeller. Det sker IKKE i dag og det medfører at regningen skal betales flere gange uden nogen er vilige til at erkende det eller tage ansvaret for de milliarder af kroner det vil koste i forsinkelser i sundhedssystemets tilpasning til behov. Man glemmer at der er MASSER af ressource i dag relativ til om 10-15 år og stiller derfor alt for lave krav.

6
5. juni 2008 kl. 22:23

Stephan: Jeg arbejder i et miljø, hvor der er personfølsomme oplysninger en masse. Og jeg er ikke altid helt stolt over, hvordan vi håndterer det. Med andre ord er jeg meget opmærksom på at man skal være varsom med at stole på håndteringen af den slags. Og derfor er jeg altid meget interesseret, når folk kommer med kritik af etablerede eller snart-etablerede modeller for den slags.

Jeg tror jeg har læst alle dine indlæg nøje, inkl. et tidligere indlæg i en meget ældre tråd, hvor jeg - som nu - havde bedt dig forklare nærmere. (Dog har jeg ikke fulgt dine web-links fordi det var uklart, hvilken del af det henviste materiale som indeholdt det essensielle.)

Jeg er muligvis enfoldig ... nej det tror jeg faktisk ikke. Jeg tror man må sige at det er fuldstændig uklart, hvad det er, du konkret (og i korte træk) foreslår som alternativ. Er det et borgerkort med masser af (velbeskyttet) information? Jamen hvad hvis jeg taber det borgerkort i den ulykke som i øvrigt gjorde mig bevidstløs?

Jeg ser faktisk frem til den dag, hvor jeg forstår, hvad det er, du foreslår som alternativ til den centralisering, som du så kraftigt (og ordrigt) opponerer imod.

7
Indsendt af Anonym (ikke efterprøvet) den fre, 06/06/2008 - 09:21

Troels,

Jeg er fuldstændigt opmærksom på at det vender sig i mange som er låst i det forældede 60er-paradigme fra før-internet alderen. Ikke kun teknisk, men også fordi man bilder sig ind at det er mere "effektivt", "convenient" eller "sikkert" blot at stole på server-systemerne - det er faktuelt forkert, men mange er fastlåst af nogle meget stive myter.

Jeg taler ganske enkelt om at indbygge sikkerheden på id-niveauet ved at virtualisere alle personreferencer og nøgler formålsbestemt, dvs. FJERNE cpr-nummer fra alle server-side tabeller bortet set fra CPR-systemet selv og erstatte dem med AKTIVE pseudonymer, dvs. et virtuelt interface til brugeren/borgeren for er låst til det specifikke formål.

Det bygger på en ganske simpel erkendelse at den eneste måde at beskytte persondata i en digitalt integreret verden er at indbygge revokability i bunden, dvs. gøre selve personhenførbarheden tilbageførbar EFTER data er opsamlet.

Data slettes ikke (det sker stort set aldrig med de aktuelle priser på storage og ingen tør slette), men du styrer sikkerheden via kontrollen med henførbarheden.

Et AIDS-register er ikke følsomme data hvis du ikke kan henføre den enkelte observation til en specifik borger, men i modsætning til forskningsdatabaser som er passive døde data, er dette levende data fordi man faktisk kan interagere med personen bag.

Sundhedssektoren er specielt kritisk og fuldstændigt ude af trit med behovene, men det er til gengæld også svært fordi der er så ekstremt mange og livsvigtige hensyn. Har du f.eks. ikke en model til at håndtere Akut, så er du nødt til at arbejde med generelle bagdøre og så ryger sikkerheden samme vej.

Afhængig af formål vil dine server-side systemer fungere som de plejer med den betydelige forskel at en hacker (eller anden misbrug) ikke vil have noget ud af at hacke databasen. Som sådan behøver du heller ikke alle de bureaukratiske "samtykke"-mekanismer fordi det ganske enkelt er indbygget konkret.

Hele systemet vil dermed være indrettet på deling, fordi deling af data ikke skalerer risici.

Men du har selvfølgelig ikke muligheden for at kunne misbruge data uden for kontekst, fordi så kan kriminelle også.

Afhængig af den konkrete applikation må du så TILFØRE eller OVERFØRE specifik viden til de personer som skal vide mere. Det er præcis her hvor systemet bliver behovsdrevent - hvis KUNDEN (f.eks. den gravide) ønsker at du skal agere på opdaterede data, så får du dem smækket lige i hovedet og tvinges til at agere på basis af opdaterede data - hvis du oeprerer en service som er betinget af bettemt viden, så skal du ikke slå den op, men AFKRÆVE certificerede data som betingelse for at gå videre.

Til gengæld slipper du for hele det ineffektiviserende og eksproprierende registersamkøringssystem som man pt. arbejder med.

F.eks. kan du som borger altid koble en identificerende information direkte end-to-end krypteret til din læge uden at Sundhed.dk KAN henføre en given transaktion til dig.

Men det applikationsspecifikke kan man ikke sige noget generelt om udover at der er pattern-modeller til at håndtere forskellige typer af behov.

Der er stor forskel på hvad der skal til for at sikre en SKAT-validering mod hæleri i betalingstransaktionerne, håndtering af akut situationer i sundhedssektoren og sikre ansvarlighed hvis en aftale ikke overholdes eller en rettighed overtrædes.

Og du har helt ret - det borgerkort som indeholder din styring af dine MANGE formålsbestemte nøgler SKAL kunne lukkes ned og du selv overgå til dine backup modeller uden at det skaber sikkerheds- eller availability problemer.

Men vi skal derhen hvor en recept ikke udstedes på cpr-nummer (selvom din læge kender cpr-nummere), men på en ticket som du via dit borgerkorts biometriske match on card kan bevise vedrører den samme krop uden at udlevere cpr-nummer noget sted i transaktionen.

Det nuværende setup i Digital Forvaltning larmer i sit fravær af sikkerhedsmodel og effektiviseringsforståelse - der er ingen vision, intention eller mulighed for at indbygge sikkerhed eller behovs-dreven styring som man tilgår det i øjeblikket.

server-side SSO er placebo-sikkerhed og værre end ingenting.

8
Indsendt af Anonym (ikke efterprøvet) den fre, 06/06/2008 - 10:32

Troels.

En vigtig problemstilling er jo at du som applikationsudvikler eller systemdesigner ikke kan gøre meget selv, hvis andre ikke passer deres arbejde.

Når ingen i Digital Forvaltning tager hensyn til at klæde borgerne på til at være digitale kunder i systemet, så kan du ikke sikre dine systemer fordi du er afhængig af at de eksterne parter kan håndtere deres nøgler og kommunikere blot nogenlunde intelligent.

Problemstillingen er parallel i den private sektor, hvor Staten svigter på samme måde.

Hvorfor indførte man ikke Digital Cash, da man tvang chip på dankortet? Fordi ministerierne vil have ikke-legitim adgang til at detailovervåge borgernes finansielle transaktioner.

Hvorfor indførte man ikke sikkerhed, da man tog fat på Digital Signatur? Fordi ministerierne vil have bagdøre til alting. Se f.eks. grundlaget for OCES - ikke blot er der ingen sikkerhed i modellen, men offentligt ansatte har også magt som en dommer til at overrule en PID-nøgle som ikke er upfront identificerende.

Hvorfor indfører man ikke sikkerhed med næste fase af Digital Signatur i udbud? Fordi man simpelthen ikke har en business case for Digital Signatur eftersom den ikke skaber værdi. Istedet sælger man kontrollen over borgerne på auktion til et kartel mod at de finansiere overvågningsapparatet.

Hvorfor tænker man ikkeopå innovation, effektivisering og sikkerhed i Digital Forvaltningsstrategi? Jeg ved det ikke - man misbrugte Gjelleruprapporten som dokumenterede at den planøkonomiske model IKKE virker til at agierer for en ekstrem planøkonomisk model - meningsløst.

Jeg prøver ikke at dæmonisere - men siger ligeud at man er i færd med at begå enorme fejl og de fleste tiltag faktisk forværrer situationen.

9
6. juni 2008 kl. 14:54

Der findes i øjeblikket en lille menneskeskabt dyt på Mars, som futter lidt rundt og leder efter vand i nabolaget.

Når det kan lade sig gøre at få sådan et projekt i luften, så kan jeg ikke begribe, at der tilsyneladende findes nogle helt uovervindelige forhindringer for etablering af SSO.

Stephan: Jeg har sandt at sige svært ved at forstå hvad du skriver.

10
6. juni 2008 kl. 16:16

Hej Ulrik,

Den lille dyt på Mars er bestemt teknologisk set mange gange mere kompleks at få i luften (og ned igen) end det er at give hurtig adgang til relevante kliniske data. NASA havde bare den fordel, at kunne starte med et rent skrivebord da de gik i gang og at der kun var ét system i én enkelt (omend nok så kompleks) installation.

En sådan luksus har man ikke i sundhedssektoren, hvor der gerne er i omegnen af 600-900 it-systemer bare for en enkelt region, hvor systemerne er designet og udviklet over lang tid af mange forskellige leverandører og med forskellige måder at designe bla. sikkerhedsaspekter ind på. Gang det tal med 5 og læg dertil kommunale systemer, herunder hjemmeplejen, samt nationale systemer og vi kommer højt op.

Systemerne antager som jeg skrev, ofte, at de selv er de vigtigste eller eneste, klinikere nogensinde får brug for og bygger derfor egne brugerdatabaser, egen autentifikationsmekanisme, etc. ind. Nogle systemer er bygget, så de kan omkonfigureres til at trække på en fælles brugerdatabase f.eks. baseret på LDAP og det hjælper lidt på situationen: En kliniker kan på den måde nøjes med at have én identitet overfor disse systemer, dvs. ét brugernavn og password. Andre er ikke, og her skal man være anderledes kreativ for at få én identitet - hvis man da ikke lige punger ud og får leverandøren til at udvide sit system, noget der ikke altid er muligt i øvrigt.

Én identitet er bedre end flere, men det løser stadig ikke problemet med for mange logins per dag. Hvis man bygger videre på de systemer der findes i dag er der reelt et par muligheder:

  1. Man kan ændre i hvert eneste system, så det trækker på en - for det omliggende miljø - fælles brugerkontekst. En sådan kontekst får man f.eks. med sit operativsystemslogon, og programmer der startes op af den specifikke bruger kan så trække på brugeridentiteten. Windows muliggør f.eks. en sådan SSO med Kerberos/NTLM. Det er de færreste sundheds-it systemer jeg har set, der i dag understøtter dette og en sådan SSO kræver altså at man skal have fat i leverandøren.

  2. Hvis det ikke er muligt af økonomiske hensyn eller fordi producenten ikke ønsker/kan at hjælpe, men systemet skal bestå fordi der ikke er anvendelige alternativer eller penge til udskiftning, er man reelt ude i at skulle overføre identiteten vha. klient-baseret enterprise SSO. Denne mekanisme overfører f.eks. brugernavn og password bag om ryggen på brugeren fra et centralt lager til den enkelte applikation ved "at taste det ind i login dialogen" for brugeren. Denne model kræver også konfiguration for hvert eneste system, men kræver ikke producentens involvering.

Så summa summarum er det mængden af heterogene systemer, mængden af leverandører og mængden af installationer koblet med behovet for ændringer / konfiguration for hvert eneste system, der som jeg ser det er den største sten i skoen for et hurtigt fix.

11
Indsendt af Anonym (ikke efterprøvet) den lør, 06/07/2008 - 12:32

For mig er det ret tydeligt at debatten kun ser problemet med at nedbryde de fysiske siloer - men slet ikke nødvendigheden af at designe for en verden, hvor alle fysiske barrierer er væk. Man har ryggen til både fremtiden og nutiden.

Det er som en dårlig kopi af Mao "Store Spring". Alle skal lave SSO fokuseret på identifikation og overvågning, så bliver alt godt - at det fjerner fokus fra det vigtige og logins er af inferiør kvalitet som ingen kan bruge til noget bekymrer ikke.

Ja, der er kaos pt. i Sundhedssektoren. Og det er kritisk at gøre noget ved. Men at gøre noget er ikke det samme som at løse problemerne og SLET ikke det samme som at åbne for at behovene kan trække effektviisering og innovation igennem systemet.

Når man nu har fjernet al sikkerhed og kørt det hele sammen i et system hvor alle knudepunkterne er uden fallbacks eller sikkerhedsmekanismer - hvad så?

Når alle kontaktpunkter er inficeret og ingen kan røre sig fordi man har et stift SSO-koncept hvor nogle få magtinteresser sider på adgangskontrollen til alt - hvad så?

Hvordan vil man effektivisere et system hvor behovene isoleres af de centrale knudepunkters mangel på nuancer? Og systemet kontinuert bliver mere ineffektivt fordi det styres planøkonomisk og rent udbudsdrevet?

Hvem skal betale for de manglende visioner i denne digitale variant af Maos "Det Store Spring"?

Når vi har smeltet al støbejernet om til ubrugeligt stål og markerne ligger upløjet hen, mens hungersnøden hærger, hvem skal så betale for fejlene når der mangler hænder i sundehdssektoren og økonoien strammer i modsætning til i dag hvor det bare skyldes planøkonomisk ineffektivitet og spild.

Det er begrebsforvirring når bruger-id i forskellige fysiske siloer (besværligt) med den samme identitet forveksles med flere logiske identiter (formålsspecifikke nøgler) som hver især kan fungere på tværs af systemer (nødvendigt).

12
Indsendt af Anonym (ikke efterprøvet) den søn, 06/08/2008 - 06:16

Stephan: Hvis jeg har forstået det korrekt, så mener du, at det er et problem, at data i sundhedssektoren er knyttet til CPR-nummeret. I stedet burde man knytte data til pseudonymer, fx kunne alle mine undersøgelser på Rigshospitalet blive registreret under: Jens Jensen, #id: qwert1234. Jeg ville derfor ikke have noget problem med, at alt personalet på Rigshospitalet havde adgang til data knyttet til Jens Jensen med #id: qwert1234, da jeg i virkeligheden hedder Morten Thomsen. Fordelen ville så være, at vi ikke behøvede at have adgangskontrol til dataene og derfor ikke behøvede at fokusere på SSO.

Et par kommentarer til ”pseudonym-modellen”:

  1. Jeg kunne blive genkendt af medarbejdere på hospitalet – fx af min nabo som er sygeplejerske. Så ville hun måske kunne opspore mit pseudonym, da hun kender min alder og tidspunktet jeg var på hospitalet. Herefter vil der ikke være nogen forhindringer for, at hun kan finde alt hvad Rigshospitalet har om mig. Nu er sandsynligheden for, at jeg bliver genkendt nok ikke så stor…men for fx en statsminister er sandsynligheden ret stor…

  2. Hvis hospitalet har min hjemadresse (i det tilfælde de ønsker at sende noget til mig), kan man benytte krak.dk til at finde mit rigtige navn, eller i tilfælde af statsministeren – søg på hans adresse i systemet og få adgang til hans pseudonym.

  3. Det kan vel blive en lidt besværlig proces når hospitalet skal indhente data om mig fra et andet hospital, hvor jeg er registreret under et andet pseudonym.

  4. Kan man droppe adgangskontrollen i forhold til at ikke alle må ændre på data.

  5. Hvad med ”folkesundheden”, hvorledes kan forskerne lave de store tværgående studier hvis de ikke har en entydig nøgle?

vh/Morten

13
Indsendt af Anonym (ikke efterprøvet) den man, 06/09/2008 - 13:12

@ Morten

Siden du tager dig tiden til at spørge vil jeg tage mig tiden til at svare. Lidt langt for at komme godt rundt om de fleste aspekter uden at gå i detaljer med teknikken.

Korrekt - virtualisering er den eneste kendte måde hvorpå vi kan få fordelene ved digitalisering uden at sikkerheden bryder sammen. Ikke bare i sundhedssektoren hvor behovet er åbenlyst, men overalt i det digitale samfund.

Man fokuserer på at beskytte det som gør data til trusler, nemlig henførbarheden til en specifik person / entitet. Data skal istedet henføres til det specifikke FORMÅL (f.eks. røntgenbehandling nr xxy), hvorfra nogen kan have mere viden om hvordan disse kan kobles sammen til en EPJ afhængige af deres relation til den specifikke behandling.

At kunne koble et cpr-nummer til data bør være forbeholdt de få som er direkte involveret i behandlingen af den specifikke patient. Resten - inkl. sikkerhedsadministratorer, servere, forskere etc. - kan ikke få adgang til cpr fordi man ikke se forskel på dem og angribere med kriminelle eller andre ikke-legitime hensigter.

Dine spørgsmål afspejler at du ikke har tænkt over disse problemers løsning. De tager udgangspunkt i en alt for simpel og umoden sikkerhedsmodel. Der skal væsentligt flere nuancer på.

For det første kan man ikke bare udskifte cpr-nummeret med et andet nummer "#id: qwert1234" uden kobling til navn og så bare sammenkøre alt. Risikoen er jo latent hvis koblingen til personen kan etableres på anden vis.

Desuden vil alene koblingen af data gør det nemmere at identificere på basis af data alene - f.eks. er kombinationen af køn, fødselsdato og postnummer reelt identificerende (86% af amerikanere). På basis af tidspunkt og sted kan man koble en aftale med andre databaser til helt andre formål.

For det andet - selvom ikke-personhenførbare data principielt er ufarlige - er der andre årsager end datasikkerhed til - at man skal bruge adgangskontol overfor sekundær adgange, dvs. processunderstøttelse, autorisationer etc.

Desuden er der interessenter som har interesser at beskytte af andre årsager end hensynet til borgeren. Data er penge.

(Endelig skal vi ikke glemme den paranoide frygtretoriske "hovedundskyldning" til adgangskontrol/authentikering - det kunne være en terrorist (pædofil, rocker - udskift selv), der kommunikerer med de andre terroristsygeplejesker.)

En af pointerne er at du ikke kan bruge adgangskontrol til at beskytte data - det holder ikke i længden.

Adgangskontrol beskytter stakeholders mod kriminalitet ved at sikre at sikkerhedsmekanismerne er i overenstemmele med den risikoprofil der specifikt er gældende. Dvs. at en sygeplejeske som skal have adgang til administrativ information kommer reltivt let igennem, mens en læge som skal have adgang til at ordinere f.eks. morfinpræparater skal lidt mere og en som skal kunne oprette ny læger eller certificere nøgler skal have stærk beskyttelse mod angribere.

Men server-side (vi skal have client-side identitity management hvilket ogås er en slags SSO) SSO og rollebaseret adgang er nærmest en slags roadkille, hverken godt nok til at sikre patienten, lægen eller systemet - det kan bruges lokalt som addon til Clienht-side i en lille gruppe med adgang i stærkt dynamiske miljøer eller globalt til adgang til i forvejen grundsikrede data via virtualisering - men ellers kan det ikke bruges til meget.

Omkring dine spørgsmål

Man kan man tænke sig løsninger implementeret på forskellig måde - endda i parallel. Dvs. CPR 2.0 som jeg/Priway arbejder for er blot vores bud en konsistent id-model til opretholdelse af de helt fundamentale principper som trampes under fode i den offentlige sektor i dag. Omvendt må du ikke tage evt. problemstillinger du tror at finde i vores arbejde som udtryk for et problem ved virtualisering generelt - der er ganske enkelt ikke alternativer i horisonten.

  1. "Jeg ville derfor ikke have noget problem med, at alt personalet på Rigshospitalet havde adgang til data knyttet til Jens Jensen med #id: qwert1234"

a) Du skal ikke tænke på det som en "falsk" identitet. Du hedder ikke Jens Jensen. Dit simple identitets eksempel "#id: qwert1234" er blot et ægte subset af Morten Thomsen.

b) Vi taler her om ALLE sekundære adgange - ikke kun på hospitalet, men overalt. Data kan jo ikke antages beskyttet når først de ligger i en database.

Jeg synes vi skal holde op med at dæmonisere de ansatte i primærbehandlingen. De primære trusler er helt andre steder.

c) Dem som er direkte involveret i din behandlig behøver ikke mærke forskel fordi de vil skulle have adgang til MERE information om "#id: qwert1234" - alle som læser dette ved f.eks. at det i virkeligheden vedrører Morten Thomsen ;-)

d) Du kan ikke nøjes med et enkelt pseudonym - i praksis skal det være mere granulart. Men lad os springe ud fra den bro, når vi når til den.

  1. "Fordelen ville så være, at vi ikke behøvede at have adgangskontrol til dataene og derfor ikke behøvede at fokusere på SSO."

Du kan være ligeglad om der er adgangskontrol fordi data alligevel er uden for din kontrol. Men som ovenfor beskrevet er det ikke så simpelt.

  1. Jeg kunne blive genkendt af medarbejdere på hospitalet

Hvis hun er så tæt på at hun deltager i din behandling ændrer det ikke på noget. Selvfølgelig vil der være et lille antal MENNESKER som kan koble noget så intimt som din EPJ - det er i systemerne truslerne eskalerer ud af kontrol.

Hvis hun ikke er, så er det ikke værre end før. Men her skal du holde fast i pointen fra oven - selvfølgelig ligger alt ikke på kun et pseudonym, fordi så skal der kun et brud til.

Hold fast i at den fysiske genkendelse er ret ufarlig så længe den ikke kommer ind i det digitiale system, dvs. registreres eller "sælges".

Herefter vil der ikke være nogen forhindringer for, at hun kan finde alt hvad Rigshospitalet har om mig.

Dermed har du selv leveret et argument for at hospitalet nok vil have en simpel ansvarliggørende access control selv til sekundære data. Rollebaseret access control er rimeligt til dette formål, man kan ikke bruges til meget andet.

  1. Hvis hospitalet har min hjemadresse (i det tilfælde de ønsker at sende noget til mig), kan man benytte krak.dk til at finde mit rigtige navn,

En virtuel identitet uden virtuelle kommunikationskanaler kan ikke bruges til meget. Alle kommunikationskanaler kan virtualiseres og vil blive det - c/o addresser er mere fleksible ligesom SIP vil gøre det indenfor telekommunikaton og Digital Cash for betalinger.

  1. Det kan vel blive en lidt besværlig proces når > hospitalet skal indhente data om mig fra et andet > hospital, hvor jeg er registreret under et andet pseudonym.

Hospitalet hverken kan eller skal gøre noget sådan, fordi det er selve kilden til problemet. Hvis du åbner systemerne mod BORGEREN, kan du bare spørge selv som dataejer - du kan selvfølgelig selv (nemt) hente data. Det er sådan alle dataudveksling om mennesker skal fungere hvis det ikke lige er tæt integreret i en konkret process.

Når EPJ er fuldt oppe at køre vil du kun behøve delegere en adgang til lægen - ikke koordinere data. Og selvfølgelig skal man mulighed for delegering for dem som ikke kan eller vil selv.

  1. Kan man droppe adgangskontrollen i forhold til at ikke alle må ændre på data.

Men et svar afhænger af sammenhæng og applikation. Det er uafhængigt af de spørgsmål vi taler om. Du kan godt sikre datas integritet via checksom modeller, dvs. validere at de er uændrede og komplette.

Selvfølgelig kan personale som ikke er involveret i den direkte behandling ikke ændre på en EPJ og slet ikke unden ansvarspådragelse - det ville være livsfarligt.

  1. Hvad med ”folkesundheden”, hvorledes kan forskerne lave de store tværgående studier hvis de ikke har en entydig nøgle?

Typisk kortsigt suboptimeringsspørgsmål som kun addresser hvad en eller anden planøkonom lige synes han har brug for - selvfølelig "enormt" vigtigt.

For det første er det et argument uden ende og groft ude af proportioner med de overgreb de medfører. Hvis "forskerne" kan sammenstille, kan hvem som helst principielt gøre det og hvilket som helst formål.

For det andet skal du se spørgsmålet i flere niveauer fordi det afhænger af de sammenhænge man vil undersøge.

  1. Data må bruges som de skabes, dvs. klarer langt hovedparten af "statestikspørgsmål" om f.eks. kvalitet i behandlingen.

  2. Data kan beriges af lægen til specifikke spørgsmål på tværs af de koblinger som kan ses af EPJ-databaserne. Dækker typisk sammenstilling af detailanalyser over lang tid på tværs af sygdomsområder.

  3. Derudover - SPØRG borgeren - for fanatsien kender ingen grænser for disse spørgsmål som vi bruger uanede mængder af resourcer på uden nogen klar værdiskabelse. Der er jo sundhed i alt.

Med stærk virtualisering og aktiv identity-support behøver du jo ikke at antage at data er anonymiseret og dermed DØDE for berigelse.

a) Ikke-registrerede data kan besvares manuelt - e.g. finde forklaringer omkring en gruppe som ikke passede med antagelserne. b) Borgeren kan i hans datastyring godkende at simpel overførsel af data kan ske automatisk til forskningsformål indenfor visse rammer, dvs. regelbaseret uden det behøver at forstyrre borgeren. c) Borgeren kan modtage en forespørgsel som han kan køre mod ALLE borgerens data på tværs og sende resultatet tilbage uden detaljerne.

Morten - som dit sidste spørgmsål afspejlede - er den digitale verden ET stort integreret system hvor ALT kan kobles hvis der er logiske forbindelser, dvs. det ikke er sikret ved kilden. Vores øvelse er at kombinere værdiskabelsen ved at fjerne de fysiske silo-grænser og ersttte disse med logiske sikkerhedsmodeller.

Det er på tide at sundhedssektoren begynder at indstille sig på en digital verden.

Det eneste, jeg gør, er at erstatte MÅ med KAN. Resten følger logisk deraf. Selvom EPJ-sikkerhed med SSO etc. er nærmest ikke-eksisterende og ignoreres groft er den legale hensigt jo ikke så ringe.http://www.sst.dk/Nyheder/Seneste_nyheder/Informationssikkerhed_vejledning2008.aspx?

Dvs. VÆK med alle bagdøre - vi har ikke brug for dem og de misbruges. I Norge sker 40% af alle adgang til EPJ via Emergency override, så er sikkerhed blevet til placebo.

14
11. juni 2008 kl. 11:29

Tak Stephan for gode konstruktive svar på mine spørgsmål.