Door karma4: Door Briolet: Reeds bij installatie is bekend wanneer hij verloopt. De vervangingsdatum kun je simpel in een digitale agenda zetten. (Beter een paar week ervoor)
Het is geen overmacht dus ben ik benieuwd hoe ze met geclaimde schade omgaan.
In het ITSM proces met ITIL is dit soort zaken niet geregeld. Het klinkt voor een normaal mens logisch dat je klokken / licenties / certificaten met een tijdsmoment op tijd moet vervangen. De gedachte en dogma is dat elke verandering tot problemen kan leiden en als je niets zelf veranderd dat het dan wel blijft werken. Een dogma dat wat nuancering behoeft.
- Er moet een planning met uren en budget ingeschoten worden.
- De planning kent afhankelijkheden bijvoorbeeld de betaling en verkrijgen van nieuw certificaat.
- In het verdeel en heers is niemand echt verantwoordelijk voor de continuïteit
Resultaat is dat degene op de vloer (geoutsourced want onbelangrijk) het niet kan uitvoeren en wel de schuld krijgt.
Dat noemen ze dan inderdaad overmacht want de best practices zijn ingevuld.
Nee ik vind dat net goed, eerder triest. Het is een beschrijving uit de praktijk.
De triestheid, en het veel-schijven probleem zijn bekend.
In het ITIL proces zou dit eerder onderdeel van monitoring/bewaking zijn - met een alarm geruime tijd voor verloopdatum.
Dat test zowel het werken van de interface/API als certificaat geldigheidsduur . Net zo goed als diskfailures en aanstaande diskfailures bewaakt moeten worden.
Maar goed, het _is_ lastig om dit in grote organisaties bij allerlei interne API koppelingen goed te doen.
In mijn (werk)omgeving hebben we bewust kozen voor certificaten die 1 jaar geldig zijn puur om de routine van bewaken/aanvragen/vervangen erin te houden. Als je kiest voor langer dan zijn mensen die wisten hoe/wat/waar , zowel aan de technische kant als aan de proceskant mbt tot het regelen van een purchase vaak al naar een andere rol of functie.
Een 'normale' webserver is wat dat betreft vrij makkelijk - dat is voor een beheerder bekend terrein , overal manuals etc .
Allerlei interne API koppelingen met SSL erop tussen systemen die erg kritisch zijn zijn veel lastiger - de reguliere beheerders hebben die zelden 'from scratch' gebouwd, want dat deed de leverancier, en dan na drie of vijf jaar opeens zo'n diepliggende component als een SSL certificaat aanpakken is een klamme handjes moment .
Met wat ironie was er misschien ook zo'n strak security beleid dat het onsluiten van die API voor een bewakings/monitoring systeem niet mogelijk was. En heeft de leverancier die caveat 'certificaat verloopt over drie jaar' al of niet in de oplever documentatie gezet, maar is die natuurlijk nooit in dat detail tussen de oren van de beheerorganisatie gekomen.
Het _is_ uiteindelijk een faal van de organisatie maar het kan inderdaad erg lastig zijn in dat type organisaties.