

Identitetstjenesten MitID måtte endnu en gang give fortabt i sidste uge i et nedbrud, der varede næsten tre timer.
»Vi har modtaget en foreløbig incident rapport fra Nets som viser, at nedbruddet på MitID d. 5. oktober i tidsrummet 16:18 til 19:03 var forårsaget af en database log, der var løbet fuld. Det medførte, at MitID ikke fungerede i perioden,« skriver Sara Ringgaard Price, som er pressechef i Digitaliseringsstyrelsen i en mail.
Styrelsen henviser yderligere spørgsmål til leverandøren Nets, som ikke ønsker at kommentere nedbruddet overfor Version2.
Tidligere har professor i digitalisering på CBS Jan Damsgaard overfor Version2 advaret mod den sårbare opsætning, der ligger bag MitID.
Han så gerne, at man havde et alternativ til Nets, som kan sikre, at en situation, som den danskerne blev udsat for onsdag aften, ikke gentager sig.
»Jeg har tidligere udtrykt et lille håb om, at det kunne være fedt, hvis der var to operatører. Sådan at vi ikke er afhængige af et enkelt system, men hvis den ene går ned, så har vi stadig den anden,« siger Jan Damsgaard.
Læs også: Alvorligt nedbrud på MitID: Professorer kritiserer sårbar opsætning
Professor ved IT-Universitetet Carsten Schürmann mener også, at de gentagne nedbrud er et problem.
»Efter min ydmyge mening er MitID et tilbageskridt i forhold til en sikker identitetsinfrastruktur. Den er også dårligt implementeret. Der har været så mange udfald med MitID. Jeg forsøgte at logge ind i min bank for at gøre noget, der var tidskritisk, og det kunne jeg ikke,« har han tidligere udtalt til Version2
Carsten Schürmann påpeger, at systemets tilgængelighed er af høj vigtighed for en sikkerhedsinfrastruktur.
Læs også: Eksperter revser MitID: »Det fungerer ikke«
MitID havde også nedbrud i april måned. Forgængeren NemID, der også driftes af Nets, var i juni måned nede i flere dage.
- Borgere kan ikke logge på tjenester: NemLog-in har driftsproblemer
- Igen-igen: MitID ramt af nedbrud
- NemID-nedbrud udløser hård kritik af Nets : »Et monument over inkompetence«
- Denne artikel
- Alvorligt nedbrud på MitID: Professorer kritiserer sårbar opsætning
- NemID-nedbrud fortsætter: »Det er ekstremt alvorligt«
- På dagen, hvor der skal betales regninger: 'MitID er ustabil i øjeblikket. Vi arbejder på en løsning. MitID er ustabil i øjeblikket. Vi arbejder på en løsning'
- emailE-mail
- linkKopier link

...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.
Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
Hvad er database loggen? Er det transaktions/archive loggen, der henvises til? På de fleste større systemer, vil det kræve en backup, før den kan trunkeres (eller archive redologs kan slettes). Så ud for beskrivelsen kunne det tyde på at man 1) har haft backup fejl, at man 2) har underdimensioneret transaktions/archive log arealet, så det ikke kan tåle manglende backup særligt længe. Det udstiller så, at et backupsystem faktisk kan gå hen og blive single point of failure! Eller er det databasens fejl/hændelses log, der henvises til? Det er en noget "fluffy" overskrift "fejlbeskrivelse". Just my 5 cents...
jeg undrede mig over at jeg ikke kunne finde driftsinfo - det mangler i løsningen!
I lyset af hvad der ellers er sket med implementeringen af MitId, vil jeg tro at den væsentligste årsag har været tidspres. Så sker der fejl.
Var det (nedbrud) efter Version2's hack af brugernavne?
Hvad er det man ikke har gjort hvis en DB-log løber fuld? Mangler de en commit i deres kode eller har de glemt at tage backup?
Eller er deres kode efterhånden kludret sammen af så mange genbrugsstumper med lidt lim imellem, at ingen mere ejer overblik over, hvad der egentlig foregår - eller ikke foregår... Gruer for næste skridt for telefonløse og udlandsdanskere. Stakkels Borgerservice !
Jeg forsøgte at logge ind i min bank for at gøre noget, der var tidskritisk, og det kunne jeg ikke
Jeg skal ikke gøre reklame, men jeg opdagede, at Nordea har implementeret deres eget login Nordea ID - sjovt nok efter introduktionen af MitID - så som kunde der har man et alternativ når MitID er nede. Med QR-kode scanning er det i øvrigt også lettere end MitID. Jeg formoder, de har lavet det, fordi de er til stede i flere lande og gerne ville have et login-system, de selv har kontrol med. Andre banker har måske også, men i hvert fald Danske Bank har ikke...endnu...
"Databaseloggen var løbet fuld"....
Er jeg den eneste, som synes at det lyder ualmindeligt amatøragtigt? Er der virkelig ikke døgnvagt i operatørrummet på så vigtig kritisk infrastruktur?
Der er vist ikke noget operatørrum og når en standard AWS S3 bucket kan være uendelig stor synes det besynderligt at landets vigtigste og nok mest kristiske IT løsning har en transaktionslog der "løber fuld". Sådan noget skete måske i 90erne da Cloud og serviceorienteret arkitektur var noget Microsoft snakkede om når det skulle være rigtig hype, men i 2022..... jamen harddiske løb tør for plads! Come on...
Transaktionsloggen er ikke som sådan begrænset af diskplads. Når loggen løber fuld er det (som det sådan set er nævnt allerede) et udtryk for andre problemer som skal håndteres. Navnet til trods er det ikke en egentlig log, men en tilbagerulningsliste.
Tingene hedder forskelligt afhængigt af databasen. Et sted skal man have styr på åbne transaktioner, således at de kan rulles tilbage (kasseres), hvis der er nødvendigt. Et andet sted har man alle transaktioner, der er gennemført. Den sidste logfil skal dels kunne dokumentere brugen af databasen, men også (primært) gøre det muligt at genskabe databasen ud fra en backup, hvis databasen af en eller anden grund beskadiges. Endelig kan man have brug for en log, der viser både opdateringer og læsninger knyttet til de enkelte brugere. Hvis nu f.eks. nogen har set på en politikers tidligere spiritus-domme i politiets register uden at have en meget god grund til det, skal man kunne finde disse misdædere og give dem en advarsel.
Hvis en af logfilerne pludselig vokser i størrelse, kan man blive overrumplet. Og hvad foregår der mon egentlig om natten? Hvis den stille og roligt vokser sig for stor, så er der en hel masse driftsovervågning, der har fejlet. I alle tilfælde bør man finde forklaringen og lære af fejlen, ikke starte med at finde en skyldig.
Er jeg den eneste, som synes at det lyder ualmindeligt amatøragtigt?
Nets har da tjent mange penge, så på den måde er det meget professionelt.
En erfaren projektleder fortalte engang, at det var vigtigt at undersøge hvordan de forskellige typer ansatte fordeler sig hos en leverandør. Hvis der er for mange advokater og sælgere i forhold til teknikere, så skal man holde sig væk.
Digitaliseringsstyrelsen burde nok få fat i en erfaren projektleder.
En erfaren projektleder fortalte engang, at det var vigtigt at undersøge hvordan de forskellige typer ansatte fordeler sig hos en leverandør. Hvis der er for mange advokater og sælgere i forhold til teknikere, så skal man holde sig væk.
Det lyder klogt. Måske gælder det også i kommuner? Jeg kommer til at tænke på den kommentar, jeg netop har skrevet til Helsingør-sagen:https://www.version2.dk/artikel/lettet-helsingoer-borgmester-chromebooks-har-i-den-grad-vaeret-savnet#comment-1758760
Den pågældende Politiken-artikel slutter:"Advokatundersøgelsen om anklagerne mod Benedikte Kiær forventes færdig i slutningen af oktober. Det er advokatfirmaet Horten, der laver den, og den forventes at koste omkring en million kroner. "https://politiken.dk/indland/art9026242/Benedikte-Ki%C3%A6r-har-truet-medarbejdere
En million kroner...det kunne man godt nok have fået et par varme hænder for... eller lidt gode, analoge undervisningsmaterialer....
Hvis der er for mange advokater og sælgere i forhold til teknikere, så skal man holde sig væk.
Kan du give guess-timater af disse (dette) forhold?
Kan du give guess-timater af disse (dette) forhold?
Det kommer jo an på hvilken ydelse man skal købe.
Skal man have fat i en tømrer, så er een advokat tilstrækkelig til at kigge andetsteds.
"loggen var løbet fuld" er jo blot den umiddelbare årsag. Når der er incidents at den karakter på kritiske systemer må man også lave en 'root cause analysis': Hvorfor løb loggen fuld?
- Er databasen / serveren dimensioneret forkert?
- Har der været en højere belastning end normalt, så der blev logget mere?
- Hvorfor er det ikke blevet fanget af overvågningen?
- Hvis det blev fanget, hvorfor er der så ikke reageret på det?
Burde være helt standard procedure for driftsnedbrud.
Ja, det forekommer også mig at være en selvfølge, Henrik Juul Størner. Det bliver spændende, om der kommer en forklaring på, hvorfor det ikke har virket i denne situation.
De skal ikke bruge en døgnvagt, en alarm har naturligvis advaret i god tid, så man kunne løse problemet i ro og mag. Jo, det virker amatøragtigt.
Når det kobles med, at MitId er sårbart for et simpelt DOS angreb og at Nets heller ikke havde beskyttet NemID mod DDOS angreb (en teenager lagde NemID ned i timevis over to omgange, med et DDOS angreb bestilt for ca 150 kr.), så giver det mig en begrundet mistillid til, at de er opgaven voksen.
Det ville være glimrende med noget konkurrence på området, så jeg kunne vælge en anden id-udbyder, som jeg stoler mere på og så der er backup når en Netsmedarbejder snubler over strømkablet til serveren næste gang.
De skal ikke bruge en døgnvagt, en alarm har naturligvis advaret i god tid, så man kunne løse problemet i ro og mag.
Ok, det er så nok, at der er en, der faktisk lytter til alarmerne (vel også en slags døgnvagt?). Men hvad i alverden er så gået galt, når ingen i tide har opdaget en log, der var ved at løbe fuld, og som derfor - velsagtens i god tid, eks. en dag i forvejen - har udsendt masser af alarmer?
Må vi ikke konstatere, at den forklaring - "Databaselog løbet fuld" - er en ikke-forklaring? Hvorfor er det ikke blevet opdaget i tide - det er vel det egentlige spørgsmål? Som jeg så håber, at Version2 vil komme efter NETS med.