Opdatering af systemer i et lille miljø

I store virksomheders IT-afdelinger er systemopdatering en kompliceret proces, der involverer et stort antal testsystemer, som spejler produktionssystemer, så hver ny patch fra operativsystem- og softwareleverandører kan testes i et virkelighedsnært miljø for at se, hvordan de interagerer med de hardware- og softwarekombinationer, der er tilgængelige i organisationen. I en ideel verden ville alle afdelinger have en styret patchproces, der straks reagerede på nyudgivne patches, testede øjeblikkeligt og anvendte dem, så snart patchen var anset for sikker og relevant. Men verden er ikke ideel, og i det virkelige liv må vi klare os med begrænsede ressourcer: fysiske, tidsmæssige og finansielle.

Patches frigives generelt af et par vigtige årsager: sikkerhed, stabilitet, ydeevne og lejlighedsvis for at levere nye funktioner. Bortset fra tilføjelsen af nye funktioner, som normalt håndteres gennem en anden udgivelsesproces, repræsenterer patches en rettelse af et kendt problem. Dette er ikke et “hvis det ikke er i stykker, skal du ikke rette det”-scenarie, men et “det er i stykker og er endnu ikke gået fuldstændigt ned”-scenarie, som kræver opmærksomhed – jo hurtigere jo bedre. En “sid tilbage og vent”-tilgang til patches er uklog, da eksistensen af en ny patch betyder, at ondsindede hackere har et “fix” at analysere, og selv hvis et exploit ikke eksisterede tidligere, vil det gøre det meget snart. Udgivelsen af patchen i sig selv kan være udløseren for det øjeblikkelige behov for den pågældende patch.

Dette patch-økosystem skaber et behov for en “patch hurtigt”-mentalitet. Patches bør aldrig ligge ubrugte; de skal anvendes, ofte så snart de er frigivet og testet. At vente med at patche kan betyde at køre med kritiske sikkerhedsfejl eller at holde systemer unødigt upålidelige.

Små IT-afdelinger har sjældent, hvis nogensinde, testmiljøer, hvad enten det drejer sig om servere, netværksudstyr eller endda desktops. Ikke ideelt, men realistisk set, selv hvis disse miljøer var tilgængelige, har få små afdelinger de ekstra menneskelige IT-ressourcer til rådighed til at køre disse tests rettidigt.

Dette er ikke så dystert, som det lyder. Den testning, der udføres for de fleste patches, er redundant med den testning, som allerede er udført af leverandøren. Leverandører kan umuligt teste enhver hardware- og softwareinteraktion, der nogensinde kan forekomme med deres produkter, men de tester generelt et bredt udvalg af permutationer og kigger på områder, hvor interaktioner er mest sandsynlige. Det er sjældent, at en stor leverandør lamme sin egen software med dårlige patches. Ja, det sker, og det er vigtigt at have gode sikkerhedskopier og rollback-planer, men i dagligdagen er patchning en relativt sikker proces, der er langt vigtigere at udføre hurtigt end at vente på muligheder, som måske eller måske ikke opstår.

Som enhver systemændring anvendes patches bedst i hyppige, små doser. Hvis patches anvendes hurtigt, skal normalt kun én eller få patches anvendes på samme tid. For operativsystemer skal du måske stadig håndtere flere patches ad gangen, især hvis du kun patcher ugentligt, men sjældent behøver du at patche snesevis eller hundredvis af filer på én gang, når det gøres på denne måde. Når det gøres sådan, er det langt nemmere at evaluere patches for negative virkninger og at rulle tilbage, hvis en patchproces går galt.

Det værste scenarie for en lille virksomhed, der mangler en ordentlig patch-test-arbejdsgang, er at vente med patches. At vente betyder, at systemer går uden nødvendig pleje i lange perioder, og når patches endelig anvendes, sker det ofte i store, samlede patchprocesser. At anvende mange patches på én gang øger chancerne for, at noget går galt, og når det sker, kan det være meget vanskeligere at identificere, hvilken(e) patch(es) der er skyld i det, og at producere en vej til afhjælpning.

Forsinket patchning er en proces, der giver lille eller ingen fordel for hverken IT eller en virksomhed, men medfører betydelig risiko for sikkerhed, stabilitet og ydeevne. Best practices for patchning i et lille miljø er enten at tillade systemer at opdatere sig selv så hurtigt som muligt eller at planlægge en regelmæssig patchproces, måske ugentligt, på et tidspunkt, hvor virksomheden er mest forberedt på, at patchning mislykkes, og at patch-afhjælpning kan håndteres. Uanset om du vælger at patche automatisk eller blot at gøre det regelmæssigt gennem en manuel proces, skal du patche ofte og hurtigt for at opnå de bedste resultater.