NemID lagde hele CPR-registret ned

Politi, skat og personalet på landets sygehuse ventede forgæves på data fra CPR-registreret, da tusindvis af forespørgsler efter den nye digitale signatur tvang registret i knæ. Kontorchef afviser, at det kunne være håndteret anderledes.

Myndighederne mistede adgangen til en af Danmarks helt centrale databaser, CPR-registret, da NemID, gik i luften i går, torsdag.

Tusindvis af brugere væltede ind for at bestille en ny, digital signatur. Alle skulle de tjekkes i CPR-registret. Det pres kunne den web-service, som NemID er koblet op til, ikke holde til.

»De andre brugere af systemet, blandt andet politiet, Skat og sygehusene, har alle i en periode på nogle timer været påvirket,« fortæller kontorchef Carsten Grage fra CPR-kontoret.

Han afviser, at kontoret har fået klager fra andre brugere i dag, selv om NemID også har givet fejlmeddelelser fredag.

CPR-systemet kører på en mainframe.

»Den er ikke dimensioneret til, at der er flere hundredtusinder opslag på samme tid. Det er lidt samme problem, som Skat har ved udsendelsen af årsopgørelser,« siger Carsten Grage.

»Under normale omstændigheder fungerer det fint, men i går nåede vi toppen,« tilføjer han.

Carsten Grage har ikke noget bud på, hvor mange transaktioner CPR-registreret kan håndtere i løbet af en time.

»Vi bruger 300-400 MIPS om måneden. Det giver en indikation af, hvilken kapacitet vi har,« oplyser han.

Er der noget, som I set af lyset af problemerne kunne have gjort anderledes op til lanceringen af NemID?

»Nej, det synes jeg ikke«.

»DanID må være i gang med at justere sit eget system nu. De kan lægge forsinkelser ind på opslag i CPR-registret eller sprede belastningen ud over et lidt større tidsrum,« mener kontorchefen.

DanID, som er ejet af PBS og driver NemID, har oplyst til Version2, at der i alt blev oprettet 7.038 digitale signaturer hele torsdag.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (59)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Ole Wolf

Lad os håbe, at ondsindede mennesker ikke har opdaget det her.

For ellers sidder de nemlig og tænker: "Tak til NemID for jeres glimrende demonstration af, at vi kan lægge hele Danmarks CPR-register ned med et par tusinde forsøg på at bestille NemID".

  • 0
  • 0
Stephen Aaskov

Det er dælme godt gået digitale-offentlige-danmark-foretrøje-nr-et-i-verden.

Er det overakademiseringen der slår igennem her? Man burde jo tro, at der efterhånden er blevet opbygget en vis erfaring med store systemer og de faldgruber de præsenterer.

  • 0
  • 0
Carsten Berggreen

Var det ikke en idé om systemarkitekterne i IT-Danmark, snart begyndte at designe efter velkendte principper for "caching"?

Hvis man nu laver så klienterne bliver sorteret og fordelt ud på flere "endestationer" (læs: server-front-ends) og at denne "first access" kun har til formål at redirect til næste ledige "kasse" ganske som på posthuset eller apoteketet... træk et nummer og bliv sendt til næste ledige medarbejder.

Alle "front-ends" (læs: kasser) bør blot have en "local cached" version, dvs. READ ONLY version af CPR-registret.

Dem som skal ændre noget, gemmer deres data i en "kø" og så sendes jobbet ind i en "batch pulje" til senere opdatering og synkronisering.

Det er måske lidt kludret forklaret her, men jeg forstår ikke at dette "pattern" ikke er mere brugt i store danske systemer - og undskyldningerne om at systemerne ikke kan skaleres... jeg forstår det altså ikke... hvem er det som ikke kan se logikken i overnævnte?

  • 0
  • 0
Ole Wolf

Carsten: Der er lige den finte med "cache miss". Indtil en bruger har foretaget en bestilling, hvorved der anmodes om CPR-nummer, kan man ikke cache det. Og så er det jo allerede for sent.

Det kunne løses ved, at DanID fik en komplet kopi af CPR-registret, men det ville til gengæld give problemer med Persondataloven. Man må nemlig kun kopiere personfølsomme data (og her er CPR-nummeret blandt visse jurister indregnet) med brugerens accept. Catch-22 opstår.

  • 0
  • 0
Lars Balker

»Vi bruger 300-400 MIPS om måneden. Det giver en indikation af, hvilken kapacitet vi har,« oplyser han.

Overhovedet ikke. Kun at de bruger forældet teknologi i en online-verden, hvor "et par tusinder" opslag er hvad man skal kunne klare i minuttet.

CPR-opslag er en simpel id der mapper over i en liste af oplysninger - at det overhovedet er et issue i 2010 er overordentligt pinligt, og jo, selvfølgelig "kunne det være håndteret anderledes". Kompetent, for eksempel.

  • 0
  • 0
Allan Ebdrup Blogger

Nu er omregning fra Mainframe-enhede MIPS ikke en eksakt videnskab. Men 300-400 MIPS det svarer sådan cirka til een Wintel server med en eller måske to chips med 4 cores.
1) Det er ikke meget kapacitet.
2) Den burde alligevel snildt kunne klare tusindvis af requests i minuttet, der er noget arkitektur der skal have en overhaling. Caching lyder som en oplagt idé.

  • 0
  • 0
Ole Wolf

Allan, MIPS giver faktisk en vis mening i Mainframe-systemer.

Og det siger jeg, selv om jeg har holdt flere forelæsninger, hvor jeg har påpeget, at MIPS, MOPS, MFLOPS osv. ikke giver mening. Pointen er, at så længe arkitekturen er nogenlunde statisk, KAN man godt angive performance i MIPS m.m. Det er kun på tværs af arkiktekturer, at det ikke giver mening. I det aktuelle tilfælde fra Carsten Grage er det en acceptabel måleenhed.

Det er straks mere korrekt at bringe Lars' kritik på banen. Mainframes er meget batchjob-orienterede, og on-demand opgaver som webforespørgsler ligger ikke lige for.

  • 0
  • 0
Jacob Larsen

Jeg undrer mig også lidt. Det hjælper selvfølgelig lidt at den MIPS enhed der opereres med her er af en anden størrelse end jeg normalt opererer med. I min verden kan de fleste smartphones levere mere end det, hvilket selvfølgelig understreger hvor lidt man kan bruge MIPS tal til.

Men alt det til side (vi ignorerer lige at MIPS om måneden ikke giver mening), så er jeg enig i at det er alt for lidt kapacitet. Eller måske en ringe implementation? Vi skal op i adskillige sekunder pr request før tallene passer. Enten kører der noget tungt behandling af data (hvorfor?) eller også kører det på PC-klasse hardware fra sidste årtusinde.
Er det virkelig det centrale register som diverse services i Danmark bruger?

  • 0
  • 0
Poul-Henning Kamp Blogger

Men 300-400 MIPS det svarer sådan cirka til een Wintel server med en eller måske to chips med 4 cores.

Nej, det gør det bestemt ikke.

IBM's mainframes er CISC maskiner og nogle af deres instruktioner er hjernevridende potente i databaseapplikationer.

Deres I/O båndbredde skal man heller ikke overse.

Ikke dermed sagt at jeg mener de ikke er forældede, men man er en stor idiot hvis man tror man kan erstatte dem med 2U til 10.000 kr.

Poul-Henning

  • 0
  • 0
Bjarne Nielsen

Nu er der givetvist ikke tale om en jævn belastning (og situationen er nok forværret af at mange har prøvet forgæves flere gange), men jeg kan ikke lade være med at tænke på, hvor lang tid det vil tage at nå målet om 3 mio. nemme id'er, hvis man kan lægge det mest centrale i hele det officielle Danmarks infrastruktur ned i forbindelse med oprettelsen af sølle syv tusinde nemme id'er?

  • 0
  • 0
Allan Ebdrup Blogger

Nej, det gør det bestemt ikke.

IBM's mainframes er CISC maskiner og nogle af deres instruktioner er hjernevridende potente i databaseapplikationer.

Deres I/O båndbredde skal man heller ikke overse.

Ikke dermed sagt at jeg mener de ikke er forældede, men man er en stor idiot hvis man tror man kan erstatte dem med 2U til 10.000 kr.

Som jeg skrev er omregning fra Mainframe-enheden MIPS ikke en eksakt videnskab.
Om man kan erstatte 300-400 MIPS med en 2U til 10.0000 afhænger vel af hvor flaskehalsene i systemet er. Hvis det ikke er I/O båndbredde og "de hjernevridende potente instruktioner" som du skriver, kan man. Og efter hvad min nære ven i moderniseringsbranchen med praktisk erfaring og andre i den branche fortæller om konkrete projekter, kan man ofte det (jeg skrev ikke altid). Men de er måske idioter, selv når de har gjort det i praksis?

Jeg mener stadig at 300-400 MIPS ikke er det store til CPR-registret.

  • 0
  • 0
Ole Wolf

Allan: Nej. MIPS i betydningen "millioner operationer per sekund" afhænger af, hvad man lægger i betydningen af "operation".

Hvis en Mainframe-instruktion foretager 100 atomare læse/skrive-operationer, så er 400 MIPS af den slags mere i forhold til f.eks. en RISC processor, der kan lave 30000 ditto.

MIPS giver kun mening i identiske arkitekturer, hvor definitionen af en "operation" er identiske.

  • 0
  • 0
Allan Ebdrup Blogger

Allan: Nej. MIPS i betydningen "millioner operationer per sekund" afhænger af, hvad man lægger i betydningen af "operation".

Jeg bruger netop ikke MIPS som "millioner operationer per sekund". MIPS på mainframe er en speciel enhed som forbruget på mainframe afregnes efter, hvordan den beregnes ved jeg intet om. Som en anden skrev giver det ikke menig at tale om MIPS pr måned. Jeg baserer min udtalelse på folk jeg kenders praktiske erfaring med at flytte fra mainframe til WIntel, hvad skal der til for at overtage 300-400 MIPS på WIntel? Det tror jeg giver folk en bedre idé om hvad 300-400 MIPS er.

Min pointe er stadig at 300-400 mainframe MIPS er meget lidt til hele danmarks CPR-register.

  • 0
  • 0
Ole Wolf

Allan: Hvis ikke du tager stilling til, hvad MIPS er en mål for, så kan jeg oprigtigt ikke se, hvordan du kan sammenligne det med andre computerarkitekturer.

MIPS er en forkortelse for "Millions of Instructions Per Second". Hvis ikke du mener, at det er relevant, hvad "instruction" dækker over, så forstår jeg ikke rigtigt, hvad du bidrager med i diskussionen.

  • 0
  • 0
Allan Ebdrup Blogger

Allan: Hvis ikke du tager stilling til, hvad MIPS er en mål for, så kan jeg oprigtigt ikke se, hvordan du kan sammenligne det med andre computerarkitekturer.

Jeg bidrager med folk jeg kenders praktiske erfaring med at flytte fra mainframe til WIntel, hvad skal der til for at overtage 300-400 MIPS på WIntel?

Det mener jeg er meget mere relevant end en teoretisk diskussion af hvad en instruktion er på den ene eller den anden arkitektur. Men jeg kan heller ikke rigtigt se hvad du bidrager med til diskussionen, så måske skulle vi bare stoppe den der. Du forholder dig fx ikke til at MIPS pr måned ikke giver nogen mening, medmindre vi taler om en accelration af instruktionsforbruget.

  • 0
  • 0
Ole Wolf

Allan: Gider du lige? Hvis du anklager 300-400 MIPS for at være for lidt, uden at forholde dig til, hvad tallet dækker over, så ER det da lidt svært at forstå, hvad du mener, eller hvad det er, du kritiserer. For ikke at sige, at det er svært at forstå, hvordan du kan skalere, uden at kende målestokken for skaleringen.

  • 0
  • 0
Allan Ebdrup Blogger

Ole, jeg mener skal også at jeg forholder mig til hvad 300-400 MIPS dækker over, jeg stiller det op i termer der er til at forstå når vi taler om kald af webservices, hvad svarer 300-400 MIPS til på en af de arkitekture de fleste laver den slags på: Intel. Jeg kan ikke se hvad det bidrager til forståelsen af 300-400 MIPS noget som helst af det du har skrevet, du siger bare at man ikke kan sammenligne forskellige arkitekture. Jeg gør i det mindste et forsøg, udfra hvad folk har af praktisk erfaring med at flytte et workload fra den ene arkitektur til den anden.
Som jeg startede med at skrive er det ikke en eksakt videnskab, og nogle gange rammer man ved siden af.
Jeg køber heller ikke dit argument om at Mainframe er batch-orienteret og ikke skulle kunne bruges til on-demand opgaver. Selvfølgelig kan den det.
Den største reele grund til ikke at benytte Mainframe til on-demand opgaver er driftsomkostningerne, ellers kunne man sagtens gøre det. Og det hele hænger så sammen, for lur mig om det ikke er pga af driftsomkostningerne, at CPR-registret KUN er dimensioneret med 300-400 MIPS, det er jo tydeligvis ikke dimensioneret efter det load der kan komme på systemet.

  • 0
  • 0
Jesper Kildebogaard

Som DanID har forklaret i en anden artikel på V2 fredag, så er planen, at bankerne vil stå for udstedelsen af langt de fleste NemID.

De kan oprette folk uden at tilgå CPR-registeret, fordi de i forvejen har nok oplysninger på folk og står inde for, at det er de rigtige mennesker, der får signaturen.

vh.

Jesper
Version2

  • 0
  • 0
Carsten Berggreen

Jeg ved ikke hvor flaskehalsen præcis er, men jeg er dybt forundret over at vi gang på gang høre om store dyre systemer i Danmark (specielt offentlige løsninger) som ikke kan skaleres når de rent faktisk går i luften.

Vi er et lille bitte land med 5-6 millioner brugere og alligevel laver man så meget GED i den når man implementere noget som involverer nogle tusinde brugere.

Det med cache-planen, var tænkt som noget der var hos CPR-registret, som åbenbart ikke kan håndtere så mange samtidige forespørgsler eller også kunne det måske være deres båndbredde ud.

Jeg er med på at cache handler om at lave gentagende opslag i "kendt data", men jeg tænker mere på en "pre-cache" løsning, hvor man centralt replikere READ-ONLY data ud på "front ends", om disse så er webservices eller andet hos f.eks. CPR, har jeg ikke kendskab til, da jeg ikke kender arkitekturen bag den nuværende løsning.

Jeg må bare konkludere at det ikke er første gang at offentlige planer fejler voldsomt.

Tror vi burde kigge lidt på andre lande i f.eks. EU og lære af hvordan man bygger store systemer, fordi det går ikke super godt herhjemme.

  • 0
  • 0
Morten Andersen

Jeg undrer mig over "Vi bruger 300-400 MIPS om måneden."

Så vidt jeg ved så er MIPS "Million Instructions per Second" og burde dermed være en hastighed - i.e. lidt det samme som en klokfrekvens. Men hvad bidrager "om måneden" så med? De bruger vel også 300-400 MIPS om året? Jeg har imidlertid hørt MIPS brugt som en form for mål for CPU-forbrug, men jeg vil mene dette er helt forkert. Måske MIPSS (i.e. MIPS * sekund) kunne være dette, så det kan være det er en stavefejl?

  • 0
  • 0
Ole Wolf

Morten m.fl.: MIPS er ganske rigtigt et udtryk for hastighed, og betyder "millions of instructions per second". Men en instruktion på én computerarkitektur er slet ikke det samme som en instruktion på en anden computerarkitektur. Ligesom en højere clockfrekvens på én processor ikke automatisk betyder, at processoren er hurtigere end en anden slags processor med en lavere clockfrekvens, så kan man kun sammenligne på MIPS-tal, hvis arkitekturerne er ens.

Hvis ikke man er enige om, hvad en "instruktion" er, så kan man kun give samme svar, som når min (dengang) treårige søn spurgte: "Er 100 mange?", nemlig: "Det kommer helt an på, hvad det er, du tæller".

(Jeg har i en treårig periode beskæftiget mig udelukkende med analyse af processorers hastigheder, så jeg vil tillade mig at sige, at jeg ved en del om det her.)

  • 0
  • 0
Allan Ebdrup Blogger

Har du overvejet at der nok er en smule adgangskontrol og eventuelt krypto involveret i den applikation ?

Hvorfor er det vigtigt om jeg har overvejet det? Du må gerne uddybe hvad du mener Poul-Henning.
Men ja, og det gør jo bare at man har brug for endnu mere kraft.

  • 0
  • 0
Anonym

Man kan kun blive lidt rystet over at endnu et stort system fejler.
De sidste par år har budt på den ene it skandale efter den anden.
Jeg så også et andet sted at der åbenbart også er problemer med sikkerheden.
Sig mig tester de kun tingene på 100 brugere eller sådan noget.

  • 0
  • 0
Morten Andersen

Jeg forstår stadigvæk ikke ""Vi bruger 300-400 MIPS om måneden."

De bruger MIPS som om det var et antal instruktioner snarere end en hastighed? Ellers giver "om måneden" ingen mening!

400 millioner instruktioner lyder ikke af meget, og selvom der kan være forskel platformene imellem, så lyder det heller ikke af meget selv hvis man ganger med en faktor 100 og der er vel grænser for hvor effektive de instruktioner er.

Noget helt andet: Nogen der ved hvem der har kodet NemID?

  • 0
  • 0
Allan Ebdrup Blogger

Ole. Når man taler om MIPS på mainframe, er det det forbruget af ressourcer afregnes efter, det forbrug inkluderer alt, også det forbrug som operativsystem og alt det andet bruger. Det kan ikke direkte oversættes til "millioner instruktioner per sekund", fx måles det ofte som et rullende gennemsnit af forbruget, og der er vidst også forskel på om man betaler for peak eller fx gennemsnittet over de tre mest aktive timer på døgnet. Det er derfor de taler om MIPS om måneden.
Du kan fx se her http://www.watsonwalker.com/PR060818.pdf
Der er et eksempel på en der prøver at forklare hvordan man omregner mainframe MIPS til serviceunits (cpu tid)

  • 0
  • 0
Allan Ebdrup Blogger

Allan, d.s. betegnelsen MIPS bliver brugt fuldstændigt forkert i mainframe sammnehæng?

Hvis du kigge på linket vil du se at der er forskel på hvor mange MIPS der leveres med Lav I/O og høj I/O op til 12%, hvordan dine LAPRS er konfigureret op til 28% forskel. Dertil kommer forskellige versioner af det software der ligge på. Og sidst men ikke mindst udregnes de MIPS man betaler for forskelligt.
Der er andre forskelle mellem Intel og IBM end bare processorarkitektur (Også I/O båndbredde osv. hvor er de i MIPS?).

Så det jeg siger er at:

1) For at vurdere hvad 300-400 MIPS svarer til i en on-demand applikation må vi forsøge at sammenligne med Intel hvor den slags bliver lavet på.

2) Jeg ved fra folk med praktisk erfaring at når man flytter 300-400 MIPS fra mainframe til Intel kan det ofte klares med ca. en eller måske to 4 core chips (der skal selvfølgelig være et godt disksystem osv også)

3) Når jeg ved 2, så synes jeg at 300-400 MIPS er meget lidt til hele danmarks CPR-register. Når jeg tænker på den kapacitet der skal til at drive de on-demand services jeg har praktisk erfaring med.

  • 0
  • 0
Ole Wolf

Allan: Det er jeg klar over. Det er sådan set også det, der gør, at jeg ikke mener, at man kan sammenligne et MIPS-tal med en Wintel-maskines performance.

Det var dermed dit punkt 2, jeg efterlyste, men nu fremgik dine "x MIPS på én arkitektur svarer til y performance på en anden"-oplysninger jo ikke af dine tidligere indlæg.

  • 0
  • 0
Morten Andersen

Allan, OK.

Men undrer mig nu stadigvæk det kan gå ned med 7.000 brugere. Hvor mange opslag i CPR registret må der ikke være fra alle landets offentlige myndigheder - evt. caching til trods? Jeg ville tro det var mange gange flere.

Det er sikkert en hel elendig protokol med flere levels af ineffektivitet. En simpel protokol over en SSL forbindelse ell.lign. som holdes åbent burde være fuldt tilstrækkeligt, og jeg vil vædde med at min skrabede dual-core CPU snildt ville kunne håndtere en load på 7000/dagen (og periodisk 10/sek) med en MySQL database med 3 mio. rekords, mange samtidige forbindelser og inkl. kryptering af såvel database som SSL forbindelser.
Den ville snildt kunne klare den 10-dobbelte kapacitet.

  • 0
  • 0
Ole Wolf

Morten: Firmaerne, der checker CPR-numre, kan evt. have en lokal kopi. Ikke at det nødvendigvis er lovligt i forhold til Persondataloven, men man må jo give sig lidt for mulighedernes kunst. :)

  • 0
  • 0
Baldur Norddahl

Hvis man har et system med en kendt kapacitetsbegrænsning, så indbygger man naturligvis fornuftige begrænsninger så en enkelt kunde ikke lægger de andre ned.

Det fremgår af artiklen at det åbenbart sker årligt for SKAT. Det er ikke acceptabelt at SKAT skal have lov til at forhindre andre kunder i at tilgå systemet.

Det kan gøres ret enkelt ved at sælge X opslag/tid til SKAT, NemID, etc.

NemID kan så sætte brugerne i kø hvis NemID systemet har overskredet kapacitetsgrænsen tildelt NemID.

  • 0
  • 0
Poul-Henning Kamp Blogger

Jeg forstår stadigvæk ikke ""Vi bruger 300-400 MIPS om måneden."

MIPS i mainframe sammenhæng har helt specielle betydninger, ikke mindst mht leje/betaling af hardware.

F.eks kan du købe en maskine med en given ydelse, målt i MIPS og betale efter regning for at bruge mere i kortere eller længere perioder.

"300-400 MIPS om måneden" er den slags ting folk der betaler efter regning kan find på at sige.

Poul-Henning

  • 0
  • 0
Baldur Norddahl

Prøv at forestille dig din ældste server. Nu installerer vi Apache+Varnish på den. I /var/www/ dumper vi ca. 5 millioner filer med filnavn cprnummer (evt. optimeret til elendige filsystemer ved at gemme dem som dd/mm/åå/ssss).

Nu kan NemID, SKAT, etc, lave opslag ved at lave GET http://cpr.dk/cprnummer.

Ok vi mangler adgangskontrol. Da de har fuld adgang til at lave ubegrænsede opslag kan vi klare den opgave med IPSEC.

På en computer med et par GB hukommelse vil det hele automatisk blive cachet i RAM.

  • 0
  • 0
Peter Lind

Hvem har sagt noget om at cache? Tankeeksperimentet omhandler hvordan CPR registeret kan implementeres.

Jeg tillader mig at rette for dig:

Hvem har sagt noget om at cache? Tankeeksperimentet omhandler hvordan CPR registeret kan implementeres pivåbent og uden nogen form for sikkerhed eller nem mulighed for at ændre i data efter behov.

Sådan, det er vist lidt mere korrekt.

  • 0
  • 0
Ole Wolf

Mon ikke det er muligt at svare Baldur lidt mere diplomatisk, end det foreløbigt er gjort? F.eks.:

Det er klart, at hvis problemet alene handler om antal dataopslag, så er sølle 5 millioner records med tilhørende oplysninger om adresser m.v. ikke nogen væsentlig byrde for et tidssvarende computersystem.

Men ligesom der gælder, at software hurtigt kan gøre, hvad det skal, hvorpå de sidste 90% går ud på at dække bagdel for mere eller mindre oplagt situationer, handler store dele af problematikken om, hvad løsningen IKKE skal. Der er væsentlige sikkerhedsmæssige udfordringer, der skal løses, og man skal sikre interoperabilitet med alle de mange systemer, der har behov for de informationer - og KUN de informationer - som de har krav på.

Sådanne elementer vil kræve enorme mængder af computerkraft, og med disse overvejelser taget med i ligningen er det nok svært at reducere problemet til antallet af MySQL-opslag i sekundet.

  • 0
  • 0
Morten Andersen

Vrøvl, selv en computer i Føtex til 3000 kr. kan følge med når vi snakker 8000 transer om dagen (eller 10 per sekund) mod en 'rigtig' database og med SSL kryptering og hele pivtøjet. Til besvarelse af simple queries kunne man have et sådant separat system der blev synkroniseret én gang om dagen med hovedsystemet. Man behøver ikke engang en DB - en simpel Java-server med en hashtabel kunne klare det. Det hele kan sikkert endda være i RAM. Det kan kodes på et par timer, inkl. koden til SSL-delen. Og så sparer man også en masse betaling for MIPS!

  • 0
  • 0
Poul-Henning Kamp Blogger

Hvad mener du egentlig om NemID løsningen?

Tjae, hvad skal jeg mene ?

Jeg har ikke i de sidste 25+ år mødt noget privat firma der anså en single-signon løsning med passwords på papirlapper som et seriøst bud på sikkerhed og jeg leder stadig efter nogen der kan forklare mig hvorledes (behovet for) NemID adskiller sig derfra.

Min eneste forklaring er at der efterhånden har dannet sig det almene indtryk at offentlig EDB skal være absurd og generelt undtaget for sund fornuft, et standpunkt jeg bestemt ikke deler.

Havde jeg været minister, havde alle danskere fået udleveret en eller anden form for elektronisk token med display/keyboard til opbevaring af deres personlige certifikat og en dertil passende lovgivning for hvornår og hvorledes man dermed kan bruge og delegere sin underskrift til andre.

Jeg er sikker på at Politiet og PET ville forlange mit hoved på et fad derfor, men de må lære at følge med tiden: forbrydere har allerede krypto, det er på tide at lovlydige borgere også får det.

Poul-Henning

  • 0
  • 0
Baldur Norddahl

Det bliver ikke de herrer jeg ansætter for at løse et kapacitetsproblem. Det er klart at de bagvedliggende systemer er meget komplekse. Men en simpel trigger på den rigtige SQL tabel kan opdatere kopien i filsystemet (et filsystem er forresten også en database).

Tankeeksperimentet er kun det - et tankeeksperiment. Det er ikke et forslag til hvordan de faktisk skal implementere CPR registeret. Men det er en illustration af hvor enkelt det er, at lave optimering der kan håndtere en næsten vilkårlig belastning af opslag på primær nøgle.

Uden nogen former for sikkerhed? Sidst jeg checkede, tilbyder IPSEC alle relevante sikkerhedsmodeller.

  • 0
  • 0
Kristian Poulsen

Nu ved jeg absolut intet om mainframes, og derfor så siger 300-400 MIPS om måneden mig heller ikke noget om hvilken kapacitet CPR har.

Det der undrer mig er, at det ikke af artiklen fremgår hvilke forventninger der har været til antallet af borgere der vil oprette en NemID i en given periode, og hvilke mål man dermed har arbejdet ud fra.

Når Carsten Grage ikke ved hvor mange transaktioner systemet kan håndtere, så kan man frygte at det er fordi det aldrig har været nævnt i kravspecifikationen.

Et velbegrundet og fyldestgørende svar ville efter min mening have været noget i stil med

"DanID forventede at der i peak-hour mellem 11 og 13 vil være X brugere pr time der anmoder om en NemID. Vi er derfor blevet pålagt at lave en service der kan håndtere X+Y forespørgelser mod CPR, således at vores Web Service ikke udgør nogen flaskehals i det samlede system. Derudover kan jeg fortælle, at vores stresstest har vist at vi kan håndtere X+Y+Z opslag i timen, uden at belaste de eksisterende systemer og vi dermed mere end rigeligt lever op til de oprindelige forventninger."

Nu ved jeg ikke hvor meget der er gjort for at teste systemet, men hvis arkitekturen er fornuftig, så burde det være rimelig simpelt at implementere en test, hvor man opretter 10.000 eller 100.000 NemID sekventielt eller evt parallelt for at 'bevise' hvad back-end systemet kan præstere. Da disse transaktioner gennemføres programmatisk, burde resultatet af en sådan test gerne ligge væsentlig (nærmest urealistisk højt) over målet, således at backend aldrig vil udgøre en flaskehals (medmindre målet er alt for lavt sat).

@Nicolai Rasmussen: Det er korrekt at man kan være kunde i flere banker, men det er den bank hvor du har din NemKonto, som giver dig din NemID.

@Henrik Pedersen: Jeg stemmer også for PHK som vores nye minister!

PS: Pressemeddelelser og avisannoncer er i den grad ubekendte som sjældent medtages i kravspecifikationen. Jeg har selv prøvet implementere et politisk drevet website (mastedatabasen.dk) fordi Helge Sander i et interview kom til at nævne noget om, at borgerne selvfølgelig skulle kunne se hvor telemaster står, så de kan forholde sig til strålingsrisiko.
På lanceringsdagen fløj der en pressemeddelelse ud (http://vtu.dk/nyheder/pressemeddelelser/2004/ny-mastedatabase/ ), hvilket 20-doblede antallet af brugere i forhold til det forventede. Til alt held var serveren virtuel, og 2 timer efter at problemet var opstået, så havde den fået tilført ekstra kræfter og kunne modstå belastningen. Godt gået af IT-afdelingen.

  • 0
  • 0
Per Gøtterup

Hvad vil folk med det skidt?

Specielt i netbank-sammenhæng er det et kæmpe skridt baglæns rent sikkerhedsmæssigt; alt hvad man behøver for at kunne rippe millioner af konti samlet et eneste sted.

Og det tåbelige papkort... det skal man huske overalt hvor man kunne finde på at tilgå sin netbank, og så lægger man det i tegnebogen, der så bliver stjålet mens man står i den anden ende af verden. Hvordan er det så lige at man blokerer kreditkort og alt det der? - Så er det med at huske telefonnumrene på spærretjenesterne for de forskellige kort... har du dem i din mobiltelefon? - Jeg har ihvertfald ikke... endnu. Men havde jeg adgang til min netbank så kunne jeg spærre kortene med et klik... men det har jeg ikke, selv om jeg måske stadig har min laptop, for der skal jeg bruge papkortet som ligger i den forsvundne tegnebog. Så er der sikkert smarte folk som scanner papkortet og lægger billedet på laptoppen, men hvad så hvis det er den som bliver stjålet?

Nej, det hæderkronede sikkerheds-mantra med mindst to ud af noget man har (nøglefil), noget man ved (kode) og noget man er (biometrik), er stadig bedst. Sådan fungerede Nordeas netbank og det er NemID klart overlegen på alle måder.

  • 0
  • 0
Henrik Schmidt

Jeg synes også en tokenbaseret løsning ville være bedre - om ikke andet så for min sjælefreds skyld.

Når det så er sagt, så er der ingen grund til ligefrem at opfinde problemer. Et token skal du også have med overalt, hvor du skal bruge din netbank. Ja, jeg har tlf nummeret på PBS, når jeg tager på ferie, og ellers kan man jo slå det op - især hvis man har internet ved hånden, som du antager.

Hvis man scanner sit papkort og lægger det på sin laptop, så er man bestemt ikke særlig smart.

  • 0
  • 0
Peter Larsen

Det var da utroligt som man altid skal læse at IBM's mainframeteknologi er forældet og kan erstattes af en mindre Linux/Windows æske for ganske få tusinde kroner - helt uden problemer!!
Hvis det var tilfældet var der ikke noget der hed mainframes. Os der arbejder med dem ved hvor meget de kan præstere - og det er altså imponerende og klippe stabilt året rundt, alle timer.
7.000 opslag i et register som CPR kan en mainframe udfører på 2 minutter, så det er altså ikke her der er et problem. Måske er det fordi NemID går via en webservice på en Windoze kasse og derfra videre med en eller anden kommunikation til MF, måske MQ.
Det vil alt i alt være forsinkende, om end at det kan løses ved en vis parallelisme - som andre også har anført. DanID ville uden problemer kunne få et udtræk fra CPR, ligesom mange andre offentlige systemer får, så en lokal kopi ville da være oplagt.

  • 0
  • 0
Kim Rasmussen

Det ville da være dejligt hvis du havde ret, men der er et par punkter der er forkerte i dine antagelser.

  1. CPR kan ikke klare 120 opslag på 2 minutter uden fejl via deres webservice interface - sandsynligvis pga. CPU overheadet ved WS-Security, og pga. den lave mængde MIPS de har allokeret.
  2. Der er ikke en eneste windows box mellem DanID og CPR.
  3. DanID er et privat firma og ikke en offentlig virksomhed, og må således ikke få en lokal kopi af CPR registeret.
  • 0
  • 0
Klavs Klavsen

Siden al access går igennem en webservice - og hver "kunde" kommer fra en bestemt IP (eller bestemte ranges) - så har del selvfølgelig sat lidt simpel ressource-styring ind i webservicen - så de kun tillader X antal samtidige forbindelser - og dermed undgår at en enkelt "aktiv" kunde, kan tage ressourcerne fra alle de andre CPR-kunder?

Og iøvrigt lyder optimeringen til statiske filer som en ganske god idé - evt. med en backend dæmon der opdaterer dem fra den nuværende DB - når der sker en ændring - det burde man snildt kunne lave trigger-baseret - det er jo en pænt simpel database :)

  • 0
  • 0
Anonym

Ja, vil jeg bare sige tsk....
Når man prissætter 'det store jern', sker det ud fra en betragtning om TPS, hvor ingen af de nævnte pilleæsker kan følge med.

Hvis en kværn bliver prissat til eks. 5 mio, kan i være evigt forvisset om, at sådan en kværn kan behandle langt flere TPS end 100 pilleæsker til 5000 pr. stk.

Søg lidt indsigt i den transaktionsbaserede verden!

At man tilsyneladende har centraliseret opslag til CPR er at pisse ved siden af alle potter, og indføre en flaskehals, og ikke mindst SPOF.
(kender ikke systemet, men det lugter lidt af mangel på situationsfornemmelse).

  • 0
  • 0
Kim Rasmussen

Jeg er ikke helt sikker på at google vil være enig med dig, man kan vel godt sige at de har bygget deres success på masser af små billige maskiner - se f.eks.: http://news.cnet.com/8301-1001_3-10209580-92.html

Det kan godt være at en kværn til 5 mill kan klare mere en 100 maskiner af 5k, MEN afregningen på MIPS stikker en kæp i hjulet på dette da det er for dyrt at køre med mere end absolut minimum af CPU kraft til rådighed. De 3-400 MIPS som CPR kører med svarer til 3/4 til 1 CPU på en z9 som sandsynligvis er hvad de kører på. Den billigste bærbare kan i ren CPU outperforme dette med en faktor 2-3 stykker mindst. Måler man på IO er det selvfølgelig en helt anden historie og kværnen vinder suverent, men bruger man CPU på at lave f.eks. signering/kryptering uden hardware acceleration, eller vil man blot starte en WebSphere server på sådan en kværn, så kan 1 z9 CPU slet ikke følge med selv den billigste bærbare.

Men som alt andet, er det afhængig af applikationen hvilken platform der er den bedste, derfor er det ikke altid mange små maskiner der er bedst, eller få store - det kommer an på brugen.

  • 0
  • 0
Martin Kofoed

Søg lidt indsigt i den transaktionsbaserede verden!

Verden har overhalet transaktioner.

Ok, naturligvis sat på spidsen, men der er altså en grund til, at hverken Google, Facebook eller endda visse ekstreme real-time dealersystemer ikke anvender en transaktionsbaseret backend. Det er simpelthen for langsomt og dyrt! For real-time dealersystemerne er ventetid altafgørende for, om man vinder eller taber. Et netværkshop for meget, og man har tabt. Det er ikke fordi, huslejen er billig, at de store handelscentre klumper sig sammen i det centrale London, Frankfurt, New York etc. Ti milisekunder betyder ALT. For Google og Facebooks vedkommende, drejer det sig naturligvis om omkostningsminimering ved real-time søgning i astronomiske datasets.

I de scenarier har man tabt, hvis man drister sig til at TÆNKE på two-phase commit henover en kø og en database.

Hvorfor ikke tage ved lære af den slags systemer, i stedet for at klynge sig til en transaktionsbaseret, MIPS-faktureret verden, hvis det i virkeligheden ikke er nødvendigt? Grundstenene til Google og Facebooks web-infrastruktur er veldokumenteret og frit tilgængeligt.

Men det kræver naturligvis et paradigmeskift i en ultra-konservativ branche (det gør faktisk lidt ondt at skulle hæfte den betegnelse på IT-branchen, men det er i høj grad tilfældet).

  • 0
  • 0
Ditlev Petersen

CPR + NemID er ikke gået i brædderne efter 7000 opslag. Tallet 7000 er de transaktioner, der faktisk kom igennem. Tallet for de samlede forsøg, har jeg ikke hørt/læst. Det er forhåbentligt væsentligt højere. Men løsningen burde da kunne trække mindst 200.000 opslag om dagen uden ligefrem at dåne.

  • 0
  • 0
Ole Wolf

Jeg har netop oplevet et eksempel på manglende sikkerhed, sådan som det er defineret af bl.a. Dansk Standard norm 484:2005 ("DS484").

Som i mange andre standarder defineres "Tilgængelighed" som et af en lille håndfuld nøgleord, herunder autencitet og integritet. Begrebet "tilgængelighed" henviser til, at man skal være sikker på, at systemet kan levere det ønskede. Hvis ikke man kan logge og tilgå systemet som forventet, er det således et eksempel på et sikkerhedsbrud.

I det aktuelle tilfælde havde jeg fået modtaget min midlertidige kode til NemID, idet jeg har bestilt NemID. Da jeg forsøgte at logge ind med mit CPR-nummer og denne kode, meldte NemID fejl, idet mit CPR-nummer og min midlertidige kode ikke blev accepteret. DanIDs support kunne ikke hjælpe mig, men anbefalede mig at vente, til jeg modtog et velkomstbrev og et nøglekort - som jeg i følge vejledningen til brugen af den midlertidige kode allerede skulle have fået.

I min situation var "impact" ikke så slem, men i en situation, hvor jeg måske skulle kunne underskrive et skøde eller foretage en vigtig banktransaktion (f.eks. husleje, så jeg ikke blev sat på gaden), ville det være meget alvorligt, hvis ikke det var muligt at logge på via NemID. Det er derfor, at DS484 og andre standarder definerer "tilgængelighed" som en del af sikkerheden af et system.

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