Patchning i en liten miljö

I IT-avdelningar på företagsnivå är patchning av system en komplicerad process som involverar ett stort antal testsystem som speglar produktionssystemen, så att varje ny patch som anländer från leverantörer av operativsystem och programvara kan testas i en verklig miljö för att se hur de samverkar med de kombinationer av hård- och programvara som finns i organisationen. I en idealisk värld skulle varje avdelning ha en styrd patchningsprocess som omedelbart reagerade på nyligen publicerade patchar, testade dem ögonblickligen och tillämpade dem så snart patchen bedömdes som säker och tillämplig. Men världen är inte idealisk och i verkligheten måste vi klara oss med begränsade resurser: fysiska, tidsmässiga och ekonomiska.

Patchar släpps i allmänhet av några få nyckelskäl: säkerhet, stabilitet, prestanda och, ibland, för att tillhandahålla nya funktioner. Med undantag för tillägget av nya funktioner, vilket normalt hanteras genom en annan utgivningsprocess, representerar patchar en åtgärd av ett känt problem. Detta är inte ett scenario av typen “om det inte är trasigt, laga det inte” utan ett scenario av typen “det är trasigt och har ännu inte havererat fullständigt” som kräver uppmärksamhet – ju förr desto bättre. Att inta en avvaktande hållning till patchar är oklokt eftersom själva existensen av en ny patch innebär att illvilliga hackare har en “åtgärd” att analysera, och även om en exploatering inte existerade tidigare kommer den att göra det inom mycket kort tid. Själva utgivningen av patchen kan vara den utlösande faktorn för det omedelbara behovet av nämnda patch.

Detta patchekosystem skapar ett behov av en mentalitet som präglas av att “patcha snabbt”. Patchar bör aldrig bli liggande, de måste ofta tillämpas så snart de släpps och har testats. Att vänta med att patcha kan innebära att man kör med kritiska säkerhetsbrister eller håller system onödigt opålitliga.

Små IT-avdelningar har sällan, om ens någonsin, testmiljöer, vare sig för servrar, nätverksutrustning eller ens skrivbordsdatorer. Inte idealiskt, men realistiskt sett, även om dessa miljöer fanns tillgängliga har få små avdelningar de överskjutande mänskliga IT-resurser som behövs för att köra dessa tester i tid.

Detta är inte så dystert som det låter. De tester som görs för de flesta patchar är överlappande med patchning som redan testats av leverantören. Leverantörer kan omöjligt testa varje samverkan mellan hård- och programvara som någonsin skulle kunna inträffa med deras produkter, men de testar i allmänhet ett brett spektrum av permutationer och tittar på områden där samverkan är mest sannolik. Det är sällsynt att en större leverantör sätter sin egen programvara ur spel med dåliga patchar. Ja, det inträffar, och att ha goda säkerhetskopior och planer för återställning är viktigt, men i den dagliga driften är patchning en relativt säker process som det är långt viktigare att göra skyndsamt än att vänta på tillfällen som kanske eller kanske inte uppstår.

Liksom varje systemändring tillämpas patchar bäst i frekventa, små doser. Om patchar tillämpas skyndsamt behöver normalt endast en eller några få patchar tillämpas vid samma tillfälle. För operativsystem kan du fortfarande behöva hantera flera patchar på en gång, i synnerhet om du endast patchar varje vecka, men sällan måste du patcha dussintals eller hundratals filer vid ett och samma tillfälle när det görs på detta sätt. När det görs så här är det betydligt enklare att utvärdera patchar med avseende på skadliga effekter och att återställa om en patchningsprocess går illa.

Det värsta scenariot för ett litet företag som saknar ett ordentligt arbetsflöde för patchtestning är att vänta med patchar. Att vänta innebär att system blir utan nödvändig vård under långa tidsperioder och när patchar slutligen tillämpas sker det ofta i stora, samlade patchningsprocesser. Att tillämpa många patchar på en gång ökar risken för att något går fel, och när det gör det kan det vara mycket svårare att identifiera vilken eller vilka patchar som är orsaken och att ta fram en väg till åtgärd.

Fördröjd patchning är en process som ger föga eller ingen fördel för vare sig IT eller ett företag, men som medför betydande risk för säkerhet, stabilitet och prestanda. Bästa praxis för patchning i en liten miljö är antingen att låta system patcha sig själva så snabbt som möjligt eller att schemalägga en regelbunden patchningsprocess, kanske varje vecka, under en tidpunkt då företaget är som bäst förberett på att patchning kan misslyckas och att patchåtgärder behöver hanteras. Vare sig du väljer att patcha automatiskt eller helt enkelt att göra det regelbundet genom en manuell process, patcha ofta och skyndsamt för bästa resultat.