Anders Møller

Udløbet SSL-certifikat sendte Ingeniøren og Version2 i sort

Hos en professionel leverandør vil certifikathåndtering håndteres uden email til specifikke medarbejdere eller fællespostkasser. Risikoen for at bolden falder ned mellem to stole er for stor. I hvert fald i en reguleret branche. Det er sagen her et godt eksempel på. En overdragelse har fordret at incidentet fik lov at opstå.

Certifikater bør styres et centralt sted og et moderne sted vil de fleste decentrale certifikater udskiftes automatisk uden behov for interaktion med menneske ud over en 'certifikat udskiftet ok' til ack køen i overvågning..

https://www.venafi.com/solutions for eksempel har værktøjer til håndtering af store mængder certifikater.

Fornyelsen skal ske proaktivt ud fra et skema, det aktivt tildeler en opgave til en afdeling, der har rette adgange og kompetencer, skulle det alligevel ske manuelt. Visse brancher er nok ikke store nok til at automatisk udskiftning giver værdi. De udfører skiftet så systemet automatisk tager nyt i brug på udløbsdato. Hvis der er afhængigheder til eksterne partnere er opgaven endnu mere under behov for processer.

Dernæst, hvis det alligevel glipper, skal overvågningsværktøjet samle warning op i eventloggen hvor det alligevel logges som advarsler. SCOM f.eks samler op første gang 20 dage før udløb svjh. Dernæst assigne til en operativ afdeling der sidder med incidenthåndtering. Over dagene frem til udløb skal prioriteten stige.

Alternativt er et major incident som denne artikel egentlig omhandler (afbrydelse af service i længere tid), og man kan kun gisne om hvilke andre sites der blev ramt.

Når det så er sagt er det også uprofessionelt at lave en artikel om at ens leverandør eller dennes underpinnings har trådt i spinaten. Grundlæggende er det mediets eget ansvar at sikre den rette kontrakt for at drive service effektivt.

Men. IT branchen er jo også den mindst modne. Jeg føler mig ret overbevist om at produktionsvirksomheder for længst har processer for sådan noget og bliver målt herpå. Lufthavne, flyproducenter, fabrikker, hvor hvert minuts udetid koster kassen, bare for at nævne nogen.

Special report. Jow.

21. januar 2018 kl. 14:57
Dankort-systemet fejlede i timevis efter opdatering

Det er et klassisk eksempel på fejlende Change og Release Mgmt.

Man overlader til Incident processen at sørge for at servicen kommer op. I sidste ende peger de bare på deres leverandør, i stedet for at tage ansvar for slutbrugerens oplevelse af servicen. Det er desværre et ret normalt billede af manglende kommunikation og koordination mellem en serviceprovider og de aftaler de måtte have i under-pinning contracts. Problemet for NETS er bare, at det for slutbrugeren er komplet ligemeget hvad årsagen er, dankortet skal bare virke. At nedbrudsperioden kunne have været forkortet med transaktions/systemovervågning, verifikation, loganalyse mv. er en helt anden og fornuftig tankegang, men når dagen er slut er root cause til "nedbruddet" manglende validering og ufuldstændig Change og Release.

Det ville ikke undre mig om den del af servicen der var påvirket afhænger af viden på en eller meget få personer.

Situationen viser meget godt, hvor sårbare de fællesservices vi har i Danmark, er.

Lige så nemt som det tilsyneladende har været at åbne i den accessliste, eller hvad der nu var konfigureret forkert i den centrale dims, lige så nemt havde det været at undgå eller opdage det i tide.

4. juli 2013 kl. 12:15