Drab, drabsforsøg og voldtægt: Region top-sikrer database med mentalerklæringer

På Dansk IT's konference om offentlig it i marts måned, fortalte Morten Juul fra Region Midtjylland om arbejdet med at skabe en sikker database til udfærdigelse af mentalerklæringer. Illustration: Tania Andersen
Mentalerklæringer udfærdiges i forbindelse med retssager og indeholder ekstremt følsomme oplysninger, der aldrig må slettes. Sådan skabte Region Midtjylland en database, der opfylder kravene til datasikkerhed.

I forbindelse med alvorlig kriminalitet, så som drab, drabsforsøg og voldtægt, kan retsvæsenet have behov for en mentalerklæring. Det foregår hos retspsykiatrien på hospitalet i Skejby, der håndterer opgaven for hele landet og Grønland.

Indtil for nylig foregik det med papirjournaler, men det gav problemer.

»Når Trine, der er ledende overlæge, rejser til Grønland, så har hun tidligere fået sendt journaler med post fra Grønland, pakket dem i sin kuffert og rejst til til Grønland, og så tilbage til Danmark igen. Vi har også oplevet, at vi har mistet journalmateriale i vores post, når vi udveksler med andre myndigheder,« fortalte Morten Juul åbenhjertigt på Dansk IT's konference om offentlig it i marts måned.

Han er projekt- og metodeansvarlig ved sundheds-it i Region Midtjylland.

Løsningen er ODA - Observand Database, der skal være journalsystem for de yderst følsomme sager. Grundlaget for systemet et enterprise-cms.

Typisk får hospitalet en anmodning fra en politimyndighed og skal udfærdige erklæringen, inden en dom skal falde. Det er barske sager.

»Derfor kan vi ikke have disse oplysninger i de almindelige systemer, som for eksempel Midt-EPJ. Vores digitale erklæring ligger til grund for domfældelsen.«

Det kan føre til en behandlingsdom, hvor Skejby også står for den opfølgende behandling, der ofte pågår i flere år. Det kan også føre til en anbringelsesdom, som er tidsubegrænset. Afdelingen producerer omkring 350 erklæringer om året, hvor patienterne er fra 15 år og op.

'Privacy by design'

ODA er opbygget ud fra 'privacy by design', mener Morten Juul. Systemet bygger på to-trins-adgang, hvilket vil sige at man skal være oprettet i regionens identitetssystem og derudover have adgang via brugeradministrationen i selve systemet.

Her tildeles de rettigheder man skal have, hvis man for eksempel er psykolog.

»GDPR har været helt grundlæggende i udvikling af systemet. Vi udveksler data mellem flere myndigheder i systemet: Retvæsen, politimyndigheder, kommuner og andre, hvor vi indhenter oplysninger om patienterne.«

Alt i systemet logges. Det er nødvendighed, selvom behandlerne måske føler det som overvågning:

»Hvis der skulle ske et databrud, så kan vi se, hvad der er sket.«

Systemet har også indbygget begrænsning i datavisning, så fagfolk kun kan se de data, der er relevante for netop deres del af arbejdet.

Systemadministrator Lone Poulsen fra Skejby tildeler rettigheder ud fra kategorier, hvor læger, psykologer og socialrådgivere får specifik adgang til en begrænset mængde af oplysninger om patienterne.

Dertil benyttes 'tunnel-mail,' hvor data kan deles på en sikker facon.

Henrik Kirk Larsen fra konsulentfirmaet Magenta, der har medvirket til at udvikle systemet, bemærker:

»Et af de vigtige elementer i privacy by design er retten til at blive glemt. Med denne slags data har man ikke nogen ret til at blive gemt - de gemmes for evigt.«

Ingen tys-tys-kilde-smuthul

Og det er fordi det handler om retsvæsenet.

Morten Kjærsgaard, som er direktør i Magenta, stiller i den efterfølgende spørgetid fokus på regionens andre databaser:

»Der er mange databaser i regioner og kommuner, som er utætte. Har Region Midtjylland en fornemmelse af, hvor mange databaser, der ikke er styr på?«

Det vil Morten Juul dog ikke kommentere, til salens store moro, men man fornemmer, at der er noget at komme efter.

I sagen om ugebladet Se og Hørs ulovlige overvågning af kendte danskere, kunne 'tys-tys-kilden' holde sine spor skjult, i sit arbejde som systemadministrator hos Nets.

På Version2's spørgsmål, om ODA tager højde for dette smuthul, lyder svaret, at administratorernes adfærd logges, samt at der skal to administratorer til at oprette en såkaldt 'kunstig' bruger, som en ondsindet systemadministrator ellers ville kunne gemme sig bag.

Det samme er dog ikke muligt med systemets udviklere, der er nødt til at have dataadgang. De slipper med at underskrive en tavshedserklæring.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Bjarne Nielsen

Kan man tale om "topsikker", hvis der kan gøres mere? Er det ikke lidt lissom at sige at Valby Bakke er det højeste punkt?

Det samme er dog ikke muligt med systemets udviklere, der er nødt til at have dataadgang. De slipper med at underskrive en tavshedserklæring.

Øh, hvad? Er vi enige om, at jeg godt kan udvikle et tekstbehandlingssystem uden at behøve at have adgang til dine dokumenter? Men vi forstår måske ikke det samme ved 'udvikler' og 'administrator'? For vi er vel også enige om, at jeg kan tage en backup af krypterede data uden at kende nøglen, ikk'?

Hvor mange designvalg er truffet med udgangspunkt i behovet for den primære behandling (og jeg ved godt at vi her skal passe på ordet 'behandling', for nogle parter bruger det også om 3. parts behandling af data til eget formål), og hvor meget er sikkerheden svækket af andre grunde, som f.eks. bekvemmelighed (herunder Trines), statistik, forskning m.v.?

Hvorfor er der f.eks. ikke et krav om fysisk adgang? Åh, ja, 'Grønland', ja, og Nord Korea og Fort Meade. Hvad forhindrer krav om lokale systemer med fysisk adgangskontrol? Krav til sagsbehandlingstiden?

Men igen, hvorfor er det et krav at 'udviklere' har fuld adgang til 'databasen'? Og hvordan kan man forlade sig på troskabseder ... se bare hvordan det gik med Balder og misteltenen!

(PS: vi kan godt tage en diskussion om hvorvidt sikkerheden er 'tilstrækkelig', men så vil jeg se et sikkerhedsdesign - og allerede ud fra teksten synes jeg, at der er flere spørgsmål end der er plads til her ... og det også selvom du godt kan overbevise mig om at sikkerheden er mange gange bedre end i de øvrige systemer, for det er godt nok at sætte barren meget lavt ... så "topsikret", nej, den er jeg ikke med på)

  • 10
  • 0
Michael Cederberg

Det lyder som en god start og måske har vi ikke fået alt at vide om det brugte setup.

Men det lyder også som om disse data kun er beskyttet af en enkelt sikkerhedsmur. Hvis der går hul på den - hvadenten det er en fejl i systemerne eller en malicious bruger så er fanden løs. Og det er netop det vi skal forvente ... der er fejl i alle større systemer og der er mennesker med dubiøs karakter alle steder (dvs. også superbrugere, udviklere og database administratorer).

Ydermere så kunne jeg godt ønske en trottle mekanisme, hvor en person kun kan hente X sager i timen, Y sager om dagen og Z sager om måneden og at nogen overvågede dette.

Øh, hvad? Er vi enige om, at jeg godt kan udvikle et tekstbehandlingssystem uden at behøve at have adgang til dine dokumenter?

Faktisk er det ikke altid nemt at bygge større systemer uden at have adgang til repræsentativt data. Når fx. database løsninger nogen gange er langsomme er det bl.a. fordi de ikke er optimeret til den data distribution der findes i det givne produktionssetup. Det samme problem eksisterer for andre teknologier.

  • 2
  • 1
Bjarne Nielsen

Faktisk er det ikke altid nemt at bygge større systemer uden at have adgang til repræsentativt data.

Jeg ved udemærket, hvad du mener, men der er som oftest tale om velstrukken elastik i metermål, hvor andre og ofte tvivlsomme hensyn får lov at trumfe rimelige hensyn til sikkerhed. Hvis der er en, som siger "NEJ!" (med udråbstegn), så finder folk som oftest alligevel en vej.

Så tillad mig lige lidt ordkløveri ; "ikke altid nemt" ... netop: der er ingen som siger, at det altid skal være nemt.

  • 3
  • 0
Mads Hjorth

Det lyder som en rigtig god ide at tage udgangspunkt i noget konkret. Der er temmlig mange gåseøjne, skæg og blå briller her :-)

Et af de helt store problemer, er at vi sjældent er enige om hvad ordet sikkerhedsdesign dækker over. Vi er endda sjældent enige om hvad et design er... Måske fordi den slags ikke lige er til at finde på nettet...

Jeg giver en kold øl i Nyhavn, til den der poster et link til den bedste beskrivelse af et sikkerhedsdesign inden 1. maj!

Det behøves ikke været et godt design (man behøver ikke sidde godt i sofaen), men det skal være godt beskrevet (man skal kunne vurdere om sofaen kan bygges, hvor kompleks den er og hvordan den er sikker :-)

  • 3
  • 0
Bjarne Nielsen

Et af de helt store problemer, er at vi sjældent er enige om hvad ordet sikkerhedsdesign dækker over.

Godt set. Jeg har også min egen lokale definition, og det er der næppe plads til at definere i regi af denne debat.

Men kan kommer nu ikke helt galt afsted ved at tage udgangpunkt i det, som tit kaldes for "Threat modelling":

  • identificer, hvad der er værd at beskytte
  • identificer, hvad det skal beskyttes imod
  • overvej hvordan det kan gøres
  • 0
  • 0
Michael Cederberg

Jeg ved udemærket, hvad du mener, men der er som oftest tale om velstrukken elastik i metermål, hvor andre og ofte tvivlsomme hensyn får lov at trumfe rimelige hensyn til sikkerhed. Hvis der er en, som siger "NEJ!" (med udråbstegn), så finder folk som oftest alligevel en vej.

Så tillad mig lige lidt ordkløveri ; "ikke altid nemt" ... netop: der er ingen som siger, at det altid skal være nemt.

Jeg har sjældent hørt noget så dumt. Blot fordi folk finder en vej så er det ikke det samme som at det var en fornuftig beslutning. For din "finder en vej" kan fx. betyde:

  • At der debugges eller testes i direkte produktionsmiljøet
  • At fejl findes for sent
  • At projekter bliver meget dyrere
  • At performance problemer ikke løses eller løses meget sent
  • At der fifles med roller, adgang, etc.
  • . . .

Hvis man er ansvarlig for sikkerhed i en organisation, så har man et ansvar for at afveje sikkerhed mod alle de andre parametre. Og blot sige nej og så håbe at folk finder en løsning er uansvarligt.

  • 1
  • 0
Bjarne Nielsen

Hvis man er ansvarlig for sikkerhed i en organisation, så har man et ansvar for at afveje sikkerhed mod alle de andre parametre. Og blot sige nej og så håbe at folk finder en løsning er uansvarligt.

Det var så ikke det, som jeg sagde.

Hvis vi lige frasorterer de punkter, hvor du beskriver selvtægt, så er der i alle tilfælde netop tale om at sikkerhed skal afvejes imod andre parametre. Og når der er sket, og der er sagt nej, så er det ikke lovligt at lave selvtægt.

Jeg har alt for tit mødt "det kan ikke lade sig gøre", og når man så siger, "lad os se på det sammen", så går der sjældent ret lang tid, før de selv tager den derfra.

  • 0
  • 0
Mogens Lysemose

Helt enig, ud fra det beskrevne har de muligvis gjort det "nødvendige" men jeg har ikke læst noget der nærmer sig "topsikring":
1. Har man f.eks. segregeret systemet på sit eget netværk hvortil der kun er adgang med en VPN-forbindelse og firewall forhindrer al anden kommunikation med omverden?
2. "Enterprise CMS" - skulle det nu være en sikkerhedsgaranti? Mange systemer i den kategori har masser af kendte alvorlige sikkerhedsproblemer i bagagen og sikkert mange der ikke er offentligt kendt.
3. Man beskriver stolt adgangskontrolmekanismen og antager at hackere osv. tvinges til at overholde den; Men tænk hvis hackere el lign. fandt et password eller kunne give sig selv rettigheder ved at injecte SQL eller hvad ved jeg. Det er set mange gange i sikkerhedshistorien.
4. Dygtige Psykologer og Psykiatere er ikke altid samtidig de skarpeste IT-eksperter, så hvordan sikrer de sig mod de utilsigtet kompromiterer sikkerheden - som f.eks. ved at skrive deres password ned eller kopiere ting ud osv.?

  • 1
  • 0
Michael Zedeler

Nu har jeg læst artiklen to gange og jeg kan ikke finde noget, der kan begrunde brugen af begrebet "privacy by design". At man f. eks. har givet udviklerne adgang til produktionsdata er i mine øjne en falliterklæring og i øvrigt højst usædvanligt i miljøer hvor man arbejder med følsomme oplysninger.

  • 6
  • 0
Morten Ulrik Sørensen

Jeg havde håbet at se noget konkret a la
- hver registrering krypteres med sin egen nøgle
- adgangen til nøglerne er implementeret på følgende vis... (der som minimum sikrer logning, og med tiltag som gør det svært at omgå)
- kodeændringer skal gennem følgende proces... (fx review i en anden afdeling)

så det fremgik, hvordan man ikke vil kunne læse noget man ikke skal, bare fordi man har adgang til databasen eller koden.

En sådan opskrift findes forhåbentlig, men jeg giver også gerne øl i Nyhavn til både de første par stykker, der peger på den, og til det første offentlige projekt, der bruger den (op til et two-pizza team).

  • 1
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize