georg strøm bloghoved

NemID og to store problemer med IT-systemer

I går – første september – var NemID nede i tre timer og 17 minutter. Nu er der ikke mange gode tidspunkter for sådan et nedbrud. Her ramte det dem som gerne ville på netbanken eller lave andet privat administration før de mødte på arbejde.

Det fik mig til at tænke over noget, der burde være paratviden for alle som designer IT-systemer. Det går tilbage til Charles Perrow som i 1999 udgav en bog med den beroligende titel: Natural Accidents.

Han inddelte systemer i løst og tæt koblede. I et løst koblet system vil en hændelse typisk kun påvirke en lille del af systemet, og den vil brede sig så langsomt, at der er tid til at gribe ind og stoppe den.

Problemet er, at ny IT næsten uden undtagelse fører til at et system bliver mere tæt koblet. Det skyldes at målet med det nye system er at gøre arbejdet hurtigere eller mere effektivt, og det fører nærmest uundgåeligt til et tættere koblet system.

Det er endda ikke det værste. De konsekvenser vi – hele samfundet – oplever fra et uheld er alt andet lige langt mere alvorlige fra et enkelt stort uheld end fra en række små. Hvis vi for eksempel samler driften fra 10 små centre i et stort, er det derfor ikke nok at gøre det 10 gange så pålideligt.

Det skal nok være mindst 10**2 eller 100 gange så pålideligt, for at konsekvenserne af uheld eller nedbrud ikke opleves som mere alvorlige. Det er svært, da den tættere kobling samtidig kan mindske chancen for at gribe ind og begrænse et uheld, eller forhindre et nedbrud.

Det bliver endnu sværere på grund af et andet problem. Perrow skriver om lineære og komplekse systemer. I et lineært system går forbindelserne i en enkelt retning – typisk fra venstre mod højre på en tegning af det – mens der i et komplekst system er forbindelser på kryds og tværs, så det kan være umuligt at forudse konsekvenserne af et indgreb i det.

Når vi indfører et nyt IT-system, eller lægger et ekstra lag af IT på et eksisterende system, er resultatet som regel at det nye system bliver mere komplekst. Der kommer nogle nye forbindelser på kryds og tværs som gør det sværere for designerne og operatørerne at forudse konsekvenserne af en ændring.

Det bliver altså sværere at finde ud af hvad der skal gøres, samtidig med at det er nødvendigt at gribe hurtigere ind for at forhindre et uheld eller et nedbrud, hvor konsekvenserne alt andet lige er langt mere alvorlige. Sådan en situation får Perrow til at konkludere at nogle former for teknologi er umulige at styre, og simpelthen for farlige til at vi kan have med dem at gøre.

Du er velkommen til at panikke, ellers kan du læse videre.

Jeg kan se to muligheder for at begrænse problemerne. Den ene er bevidst at lave opdelinger som begrænser kompleksiteten og konsekvenserne af et uheld.

Den anden er at have et styresystem som er relativt enkelt så det kan overskues, og som er i stand til at reagere langt hurtigere end resten af systemet. Hvis du omvendt har et IT-system som kan reagere langt hurtigere end de mennesker som skal styre det, så sørg for at det er en anden som skal tage skraldet, når uheldet sker.

Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Allan Ebdrup Blogger

Jeg var til et foredrag på en konference, hvor en IT-arkitekt fortalte om at ledelsen krævede 99,999% oppetid på et system. Hvortil han svarede "Det kan vi godt, her er prisen" og så blev der valgt 99,99% oppetid i stedet.

Det virker som sort magi på mig at forudsige en oppetid på 99,99% eller 99,999%. Så vidt jeg kan se bliver det en masse sandsynligheder der skal ganges samme. Findes der en "sådan beregner du et systems oppetid"-bog? er "Natural Accidents" sådan en bog. Jeg har forsøgt at google mig til mere info om hvordan man gør, men har ikke kunnet finde noget - synes det er spændende.

  • 0
  • 0
Andreas Bjørn Hassing Nielsen

Den lovede oppetids-procent er knap så interessant. Det er mere hvad der står i SLA'en eller 'Terms of Service' man kan bruge til noget.

Nu er det jo heller ikke ligefrem nemt for Nets at smide nemID ud på en lyserød sky, som giver dem højere oppetid, da de jo ligesom har vores personlige data :)
Jeg prøver ikke på at beskytte Nets eller deres produkter, men lidt retfærdighed skal der dog være til, og som Allan siger, er jeg enig i, at nedetid ikke kan forudses.

Man kan desværre ikke sige så meget om nemID's seneste nedetid, da de holder informationer tæt til kroppen og svarede "af teknisk karakter.", sidst V2 spurgte ind til det.

  • 1
  • 0
Anders Dinsen

Tak for referencen til Charles Perrow, ham må jeg have på ønskelisten. Drømmen om "løst koblede" systemer har eksisteret i mange år, men jeg har svært ved at se at den virkelig kan blive realiseret med de nuværende paradigmer og teknologier. Indtil da giver jeg dig ret i at effektive overvågningssystemer og - hvis alt andet glipper - målrettet fokus på ansvarsfraskrivelse er vejen frem. Må jeg tilføje noget? Man kan også fokusere sin testning af systemet på at finde og afsløre sådanne problemer. Det kræver lidt kreativitet og et godt overblik over systemets funktion, men det giver altid spændende resultater, der kan hjælpe projektet til at se omfanget af problemet.

  • 0
  • 0
Georg Strøm Blogger

Perrow giver ikke selv nogle formler for at beregne pålideligheden af systemer. Hans konklusion er mere at nogle systemer er så tæt koblede og komplekse, at vi er nødt til at holde os fra dem, da det er umuligt at kontrollere dem. Rumfærgen med 2 uheld på 135 flyvninger er et godt eksempel.

Der er mulighed for at lave beregninger, eller i hvert fald estimater ud fra en statistik over hardwarefejl, softwarefejl og menneskelige fejl i tilsvarende systemer. Problemet er at få alle fejlmuligheder med, specielt menneskelige fejl under vedligehold bliver ofte udeladt.

Det er muligt at lave løst koblede systemer, hvis man tænker over dem fra begyndelsen. To eksempler er Internettet og telefonsystemet, som begge er opbygget så et enkelt nedbrud normalt kun vil berøre en del af systemet. En mulighed som jeg har set i fabrikker, er at de nederste niveauer af systemet har en høj grad af autonomi, så de vil køre videre selvom de øverste centraliserede og tæt koblede dele svigter i en kortere periode.

Det er muligt at lave mindre komplekse systemer, hvis man følger normale gode principper for systemdesign og opdeling. Og så ved at analysere hvordan det designede system egentlig vil reagere overfor påvirkninger i driften. Her er den stiltiende forudsætning blandt mange designere nok, at deres system kører i et statisk miljø med en jævn belastning, så de slet ikke når at overveje konsekvenserne af tilbagekoblinger og kompleksitet.

  • 1
  • 0
Jon Bendtsen

Tak for referencen til Charles Perrow, ham må jeg have på ønskelisten. Drømmen om "løst koblede" systemer har eksisteret i mange år, men jeg har svært ved at se at den virkelig kan blive realiseret med de nuværende paradigmer og teknologier. Indtil da giver jeg dig ret i at effektive overvågningssystemer og - hvis alt andet glipper - målrettet fokus på ansvarsfraskrivelse er vejen frem. Må jeg tilføje noget? Man kan også fokusere sin testning af systemet på at finde og afsløre sådanne problemer. Det kræver lidt kreativitet og et godt overblik over systemets funktion, men det giver altid spændende resultater, der kan hjælpe projektet til at se omfanget af problemet.


Den gamle digitale signatur er løst koblet. Du kan sagtens bruge din signatur selvom at certifikat udstederen er nede. Man kan endda nogle gange også verificere om certifikatet er ugyldigt, men kun hvis du allerede ved det er ugyldigt i forvejen. Hvis certifikatet er "stjålet", og certifikat udsteder revoker det, men din server endnu ikke har hentet listen over revokede certifikater før det "stjålne" certifikat bruges imod din server så kan du ikke afgøre om certifikatet er gyldigt eller ej. Men det er en afvejning du kan gøre på din server alt efter hvor hemmelige data du har på den osv. Evt. så kan du have en backup login løsning sådan som Danske Bank brugte via SMS login.

  • 1
  • 0
Christian Nobel

Hvis certifikatet er "stjålet", og certifikat udsteder revoker det, men din server endnu ikke har hentet listen over revokede certifikater før det "stjålne" certifikat bruges imod din server så kan du ikke afgøre om certifikatet er gyldigt eller ej.

Der er vel intet forgjort i at certifikat udsteder har redundante systemer, således at hvis CA-1 er nede, så kan der kontrolleres op mod CA-2 - dette lader jo som vist i praksis at være en del sværere at håndtere for det centrale single point of failure repræsenteret ved DanID.

  • 0
  • 0
Jon Bendtsen

Der er vel intet forgjort i at certifikat udsteder har redundante systemer, således at hvis CA-1 er nede, så kan der kontrolleres op mod CA-2 - dette lader jo som vist i praksis at være en del sværere at håndtere for det centrale single point of failure repræsenteret ved DanID.


Men det certifikat som du præsenterer kan kun være udsted af en CA, og dermed kan der ikke være redundans indbygget (gælder for normale x509 SSL certifikater). Så skal du til at have 2 certifikater eller bruge en anden slags certifikater, fx. PGP, som kan være signeret af flere.

  • 0
  • 0
Christian Nobel

Men det certifikat som du præsenterer kan kun være udsted af en CA, og dermed kan der ikke være redundans indbygget (gælder for normale x509 SSL certifikater).

Ok lad mig omformulere det - kan CA ikke godt lave et system med indbygget redundans, således at hvis CAs server i Ballerup går i dørken, så tager Århus over (eller hvordan man nu vil bygge det op)?

  • 0
  • 0
Jon Bendtsen

Ok lad mig omformulere det - kan CA ikke godt lave et system med indbygget redundans, således at hvis CAs server i Ballerup går i dørken, så tager Århus over (eller hvordan man nu vil bygge det op)?


Ja og nej. Du kan have flere servere som spreder listen over revokerede certifikater. Men kun Root CA certifikatet kan opdatere listen over revokerede certifikater som ofte har en kort leve tid.

Der findes protokoller til realtime verificering af udstedte certifikater, men så skal den være online flere steder på en gang. Da det egentlig bare er en liste/database så kunne den sikkert godt replikeres. Men hvor gamle må oplysningerne være før man ikke længere tør stole på dem?

Hvis dit Root CA certifikat som bruges til at udstede andre certifikater opbevares som en fil, så kan du teknisk set godt overføre den fil til andre computere, men så skal du holde styr på at du ikke får overlappende serial numbers. Og for en professionel certifikat udsteder så tror jeg ikke de opbevarer den som en fil, men nærmere i en hardware dongle.

Jeg tror desuden at en professionel udsteder har en ultra hemmelig root ca certifikat som de opbevarer i en bankbox eller lignende. Den bruger de så til at udstede nogle sub CA certifikater som de så bruger til at udstede client certifikater. Du kan opbygge (lange) certifikat kæder på den måde.

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