NemID stadig i knæ: Umuligt at løsne op for CPR-flaskehals

Det er stadig umuligt for de fleste at oprette en NemID, fordi et datatræk til CPR-registret er overbelastet. Men DanID kan ikke skrue op for blusset og afviser, at det vil give problemer for den store udrulningsplan.

Danskere, som vil have den nye digitale signatur NemID, må væbne sig med tålmodighed. Der er stadig mere tryk på NemID's servere, end den nødvendige arbejdsgang for at oprette en NemID kan håndtere.

Problemerne opstod i går, kort efter at NemID blev lanceret til danskerne.

Der var nemlig ikke kapacitet nok til at trække CPR-oplysninger fra CPR-registret, og så får borgerne blot en fejlmeddelelse og besked om at ringe til supporten, når de forsøger at få en NemID.

Og kapacitetsproblemerne er ikke sådan lige til at løse, for det er ikke muligt at 'skrue op' for CPR-tjenesten fra CSC, forklarer DanID.

»CPR-registret er en online-tjeneste, man kan abonnere på sammen med rigtig mange andre. Vi har ikke vores eget hjørne. Så vi er i konkurrence med sundhedspersonalet i landet, og når de fleste af dem går hjem ved fire-fem-tiden, bliver der mere kapacitet til os,« siger kommunikationschef Jette Knudsen fra DanID, som står bag NemID.

I går klokken 15.45 var der oprettet 5.073 NemID via websiden NemID.nu, men hvor mange det blev til i løbet af hele dagen og natten, vil Jette Knudsen ikke gætte på, før hun har fået mere præcise tal fra teknikerne.

Men der er på ingen måde fare for, at den store udrulningsplan for millioner af danskere er i fare. De fleste vil nemlig få NemID gennem deres bank, og her er det ikke nødvendigt at trække oplysninger fra CPR-registret undervejs.

»Ved en bankmigrering tager man en kendt identitet, som bankerne står inde for. De skal kunne stå inde for folks identiet ifølge hvidvaskningsloven. Så her er der ikke noget opslag til CPR-registret. Det er kun på NemID.nu og i kommunernes borgercentre at proppen opstår,« siger Jette Knudsen.

Hun forklarer, at det ikke var muligt at lave belastningstest af CPR-opslaget, fordi det er en delt tjeneste.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (19)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Brian Matzon

Nu er jeg ikke bekendt med hvordan systemet fejlede ... men man kan da tage den begrænsede adgang til cpr registreret ind i sine overvejelser og lave en kø adgang. Det er uheldig at der er den flaske hals, men systemet skal jo stadigvæk ikke gå ned - men bare informere om at der er "nedsat fremkommelighed".

  • 0
  • 0
#5 Stephen Aaskov

Hun forklarer, at det ikke var muligt at lave belastningstest af CPR-opslaget, fordi det er en delt tjeneste.

Rystende forkert, en valid testplan for et sådant system vil indeholde en test af det element, da det er kritisk for systemets ydelse.

I mangel af test mod det rigtige CPR register, skulle man have brugt stub´s eller en simuleret dublet af CPR. På den måde vil man også kunne trække NemID systemet ud i undtagelsessituationer.

  • 0
  • 0
#10 Stephen Aaskov

Og hvad vil man kunne konkludere ud fra det? -At du kan lave en stub/simulator der kan performe?

Hun siger det ikke var muligt at teste, det siger jeg det var.

Hvis CPR opslaget er så kritisk en delfunktionalitet, burde systemet være designet så der kompenseres for forsinkelsen ved hjælp af f.eks en kø.

Med en stub, der ville kunne simulere forskellige belastningsgrader på CPR systemet, ville man under en systemtest opleve effekten af CPR opslags problematikken.

  • 0
  • 0
#11 Martin Westergaard Lassen

Hun siger det ikke var muligt at teste, det siger jeg det var.

Du har ret i at man sagtens kan lave en simulator der giver x svartid, og så kan man justere på denne for at finde ud af ved hvilken værdi at systemet bliver ubrugeligt. Men den værdi skal stadig holdes op mod virkeligheden, og da men ikke kender den virkelige værdi, så bliver x pludselig ubrugelig

Hvis CPR opslaget er så kritisk en delfunktionalitet, burde systemet være designet så der kompenseres for forsinkelsen ved hjælp af f.eks en kø.

Alt efter hvor høj du tror værdien for x bliver, skal du vælge at putte penge i en løsning og samtidig vurdere hvor meget værdi denne tilfører.

Med en stub, der ville kunne simulere forskellige belastningsgrader på CPR systemet, ville man under en systemtest opleve effekten af CPR opslags problematikken.

Du kan stadig kun dokumentere noget med en stub som du godt ved i forvejen. Eller i værste fald det du vil se.

  • 0
  • 0
#12 Stephen Aaskov

Du kan stadig kun dokumentere noget med en stub som du godt ved i forvejen. Eller i værste fald det du vil se.

Det vil jeg nu ikke give dig ret i, med en stub kan man synliggøre designfejl under en system og/eller verifikationstest. Du kan se om designet er robust overfor ydre faktorer gennem interaktionen med stub'en. Du kan dermed verificere om antagelserne om det eksterne systems opførsel er korrekte.

  • 0
  • 0
#13 Lasse Lindgård

De projekter jeg har set der bruger CPR-integration fungerer på følgende måde:

1) Man slår op i sin lokale cache for at se om man har CPR-nummeret 2) Hvis ikke man har det laver man et online kald og får CPR-oplysningerne. Samtidigt med opslaget opretter man et abonnement på oplysningerne. 3) Hver nat kommer et delta fra CPR-registeret, som man ligger ind over sin lokale cache af oplysningerne.

Med andre ord. Hvis NemID på forhånd havde oprettet abonnementer på f.eks. alle dem som i forvejen har en digital signatur, så ville problemerne sandsynligvis kunne være undgået.

Nu gætter jeg, men der hvor filmen er knækket er sikkert at abonnementet mod CPR-registeret koster kr. på CPR-nummer, hvorfor man har valgt en strategi med at først oprette abonnementerne efterhånden.

  • 0
  • 0
#15 Jesper Louis Andersen

som er et par år siden - da var det noget hø at få til at virke. Opgaven virker forholdsvist simpel og overkommelig: Etabler en SSL-forbindelse, authentifikation, send en forespørgsel, modtag svar og parse svar. Med andre ord hvad stort set alle services på nettet gør.

Hvis jeg husker rigtigt var servicen søbet ind i XML-indpakning til det niveau hvor intet normalt menneske kan hacke en løsning sammen på en eftermiddag. Jeg kan ikke huske om det var en fuld XML-SOAP-WSDL stak, men det er også ligemeget. Sådan en stak er dyr når man får mange kald.

Det er naturligvis nødvendigt at lege "hvem flaskehalsen peger på" med koden. 5000-8000 oprettelser over en periode på en 12-24 timer er ikke just imponerende. Man kan kun gisne om hvad der er galt.

Hans Schous pointe fra en anden tråd er også god: Med 8000 oprettelser om dagen skal vi ind i 2011 før alle 3 millioner borgere har NemID.

  • 0
  • 0
#16 Martin Westergaard Lassen

Det vil jeg nu ikke give dig ret i, med en stub kan man synliggøre designfejl under en system og/eller verifikationstest. Du kan se om designet er robust overfor ydre faktorer gennem interaktionen med stub'en. Du kan dermed verificere om antagelserne om det eksterne systems opførsel er korrekte.

Men virkelighedsbegrebet forholder du dig stadig ikke til. Et robust design er nødvendigvis heller ikke nok, hvis der ikke er tilstrækkeligt jern.

  • 0
  • 0
#17 Deleted User

@Jesper Louis Andersen

Som der står i artiklen, bliver langt de fleste danskere efter planen oprettet med NemID via deres bank. Det kræver ikke noget CPR-opslag, så der er ikke problemer med gennemsnitsbelastningen.

Der blev i øvrigt oprettet 7038 NemID i løbet af hele døgnet 1. juli, oplyser DanID nu.

vh.

Jesper Version2

  • 0
  • 0
#18 Stephen Aaskov

Men virkelighedsbegrebet forholder du dig stadig ikke til. Et robust design er nødvendigvis heller ikke nok, hvis der ikke er tilstrækkeligt jern.

Du mener altså, at når man ikke ved hvor lang forsinkelse fra CPR man kan opleve, er der ingen grund til at teste systemet i en tilstand hvor der er forsinkelse?

Et robust design vil sørge for at manglen på jern håndteres på en måde, så både systemintegritet og brugeroplevelse bevares.

  • 0
  • 0
#19 Sune Højfeldt

De fleste vil nemlig få NemID gennem deres bank, og her er det ikke nødvendigt at trække oplysninger fra CPR-registret undervejs.

(Jette Knudsen)

Med andre ord, bankerne kan direkte iværkssætte generering af NemID. Fantastisk. Jeg bliver mere og mere overbevist om at NemID er bombesikkert og ikke på nogen måde kan give ondsindede personer adgang til personfølsomme data.

Med de fadæser der i tidens løb har været med offentlige computersystemer (Amanda som vanvittigt eksempel og nu Polsag som er årevis forsinket og langt over dobbelt så dyrt som aftalt), sidder jeg med en fornemmelse af at det er et spørgsmål om alt for kort tid før NemID er kompromitteret og følsomme oplysninger blevet tilgængelige for uønskede. Folketinget har jo allerede hjulpet godt til ved at sørge for at alle de oplysninger der skal til for at være mig, dig, videnskabsministeren, Jette Knudsen, Palle Sørensen (altså ikke politimorderen, men ham spindoktoren fra NemID) osv., er deponeret hos DanID.

"2. juli. Sikke en dag. Det var næsten for nemt til at være sandt. Og nu sidder jeg sgu med det hele! Master of the universe! Og hold kæft hvor har politikerne dummet sig. Pengene kommer jo til at rulle ind. Vi bruger bare den sædvanlige med 'nejda! Vi tjener ikke noget, for det er dyrt --faktisk helt vildt dyrt -- at vedligeholde systemerne, som er meget komplicerede, mere end I nogensinde kommer til at forstå'

Nemlig.

PS: Palle og Jette, det har ikke været for smart med jer to undervejs, men nu står vi her og skidtet kører (håber ikke der kommer flere brølere før i morgen...knock on wood!). Så vi sætter en streg over det.

Ih, hvor er jeg altså glad."

(uddrag fra PBS' dagbog)

Har I set at DanID søger erfarne systemtestere til deres nyoprettede afdeling for implementering af sikkerhed i NemID???

Just kidding :-)

  • 0
  • 0
Log ind eller Opret konto for at kommentere