Na kratko: Postopek upravljanja popravkov določa, kako posodobitve tečejo od prejema do dokazila: v kateri razred spada popravek, v katerem oknu se namesti, kako se preizkusi in vrne, kdo znova zažene in kako se dokaže uspeh. Rutinske posodobitve tečejo po načrtu v ritmu, nujni popravki sledijo vnaprej dogovorjeni hitri poti. Tako gasilske akcije postanejo ponovljiv postopek.
Ko je vsak popravek nujni primer
Zvečer 21. 10. 2026 se je v mnogih podjetjih ponovil isti vzorec. Popravki so bili tu, BSI je pritiskal in vprašanja so se začela: Ali zdaj smemo kar posodobiti? Kdo preizkusi? Kdo znova zažene storitve? Kdo vodstvu sporoči, da trgovine za kratek čas ne bo? In kako naknadno dokažemo, da je uspelo?
V podjetjih brez postopka je treba vse to razjasniti v trenutku. V podjetjih s postopkom je odgovor že določen. Razlika ni v tehniki, ampak v dogovorih, sklenjenih vnaprej.
Gradniki postopka upravljanja popravkov
Nosilen postopek najprej razlikuje, kako nujen je popravek. Praviloma zadoščajo trije razredi:
| Razred | Značilen povod | Okno | Test | Odobritev |
|---|---|---|---|---|
| Rutina | odprava napak, varnostne posodobitve z nizkim tveganjem | stalen mesečni termin | staging, standardni testi | IT, po načrtu |
| Nujno | visoka ocena, sistem javno dosegljiv | kratkoročno predčasno | skrajšan, najpomembnejši postopki | vodja IT |
| Nujni primer | kritična vrzel, prijavljeni napadi, npr. PHP2Shell | takoj | hitri preizkus po namestitvi | vnaprej podeljena odobritev za nujne primere |
Kdo dodeli kateri razred, bi moralo biti določeno enako kot merila za to. Sama ocena sodi v predhodni korak, glejte Upravljanje ranljivosti v srednje velikih podjetjih.
Pomembna je vnaprej podeljena odobritev za nujne primere. Vodstvo se enkrat v miru odloči, da se pri nujnih popravkih sme ukrepati takoj, tudi če to pomeni kratek izpad. V skrajnem primeru potem nihče ponoči ne išče soglasja.
Enako pomembne so vloge. Za vsak sistem bi moralo biti določeno, kdo namešča posodobitve, kdo strokovno preizkusi, ali trgovina ali portal po tem deluje, in kdo je obveščen. Pri oddanih sistemih sta ponudnik gostovanja in agencija izrecno zraven, z imenom in dosegljivostjo. Stalno vzdrževalno okno naj bo interno znano, da prodaja in služba za stranke vesta, kdaj so mogoči kratki izpadi.
Merite tudi, kako dolgo vaš postopek dejansko traja: od objave popravka do dokazanega zaključka, ločeno po razredih. Te lastne vrednosti pokažejo, kje zataka, in naredijo izboljšave vidne. Postopka, katerega trajanja nihče ne pozna, je težko voditi.
Potek popravka v osmih korakih
Vsak popravek, ne glede na razred, gre skozi iste postaje. Razlikujeta se le hitrost in globina testiranja.
- Prejem: Obvestilo ali razpoložljiva posodobitev se zabeleži z datumom in virom.
- Razvrstitev: Določiti razred, po popisu ugotoviti prizadete sisteme.
- Priprava: Varnostna kopija ali posnetek, opis poti nazaj, obvestilo udeležencev.
- Test: najprej v stagingu ali na manj kritičnem sistemu.
- Namestitev: v dogovorjenem oknu, sistem za sistemom.
- Ponovni zagon: vse prizadete storitve in procesi, ne le paketi.
- Dokazilo: zabeležiti stanje paketa, vnos v dnevniku sprememb in zagon procesa.
- Kontrola: preveriti delovanje, pri varnostnih vrzeli dodatno paziti na sledi prejšnjega vdora.
Korak 6 se presenetljivo pogosto pozabi. PHP kodo naloži ob zagonu procesov. Dokler tečejo stari delavci PHP-FPM ali procesi Apache z mod_php, še naprej delajo s starim, ranljivim stanjem. Zakaj je tako in kako pravilno znova zagnati, je na strani Po posodobitvi: ponovni zagon PHP-FPM in vseh delavcev.
Dokazila, ki pozneje štejejo
Popravek brez dokaza v dvomu ni nameščen, vsaj ne v odnosu do strank, zavarovalnic ali revizorjev. Pri vsakem sistemu zabeležite, katero stanje paketa je nameščeno, ali so številke CVE v dnevniku sprememb in kdaj so bili zagnani delujoči procesi. Na sistemih Debian in Ubuntu pomagajo ukazi samo za branje, kot so ti (ime paketa prilagodite svojemu sistemu):
# Ali nameščeni paket vsebuje popravke?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# Kdaj so bili zagnani delujoči procesi PHP-FPM?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
Če je čas zagona procesov pred namestitvijo paketa, ponovni zagon manjka. Podrobno to opisuje Dokazovanje številk CVE v dnevniku sprememb paketa.
Popravek zapre vrzel za prihodnost. Ne odstrani škodljive programske opreme, vnesene prej, in ne dokazuje, da se prej ni nič zgodilo. Pri nujnih popravkih zato iskanje sledi sodi trdno v postopek.
Avtomatizirajte, kjer je varno
Samodejne varnostne posodobitve paketov operacijskega sistema odpravijo veliko rutinskega dela. Razbremenijo pa le, če obstajajo varnostne kopije, rezultate nekdo prebere in se znova zaženejo tudi prizadete storitve. Kako to nastaviti pod Linuxom in kakšne so meje, opisuje Samodejne varnostne posodobitve na strežnikih Linux.
Vsebniki potrebujejo lastno pot. Tam se ne posodablja v delujočem sistemu, ampak se slika s popravljeno različico PHP znova zgradi in uvede. Postopek popravljanja, ki pozna samo strežnike, te sisteme zlahka spregleda. V seznam poti popravljanja zato vključite tudi cevovode za gradnjo in registre slik, z odgovorno osebo in enakim dokazilom kot pri klasičnih strežnikih: katera različica PHP teče v uvedenem vsebniku in od kdaj?
Aplikacije, CMS in vtičniki običajno potrebujejo lasten, preizkušen postopek, ker posodobitve tam pogosteje spreminjajo funkcije. Stalni mesečni termin je za to pravo mesto. Na koncu je pomembno, da se vse poti stekajo v isti dokumentaciji: eno mesto, kjer je videti, kateri sistem je na katerem stanju.
Kako PHP SOS pomaga konkretno?
- Z vami zapišemo razrede popravkov, okna in odobritve, prilagojene vašim sistemom in organizaciji.
- Uredimo samodejne varnostne posodobitve s preverjanjem ponovnega zagona in obveščanjem, kjer je to smiselno.
- Prevzamemo nujne popravke, vključno s ponovnim zagonom, dokazilom in iskanjem sledi, prek naše storitve popravljanja PHP.
- Dokazila vodimo za vsak sistem tako, da jih lahko predložite strankam, zavarovalnicam ali revizorjem.
Sklep: Upravljanje popravkov deluje neopazno, dokler deluje. Točno to je cilj: ko pride naslednje kritično obvestilo, teče uigran postopek in nihče ne mora improvizirati.
Pogosta vprašanja
Kakšna je razlika med upravljanjem popravkov in upravljanjem ranljivosti?
Upravljanje ranljivosti zajema in ocenjuje vrzeli ter odloča, kaj storiti. Upravljanje popravkov odločitev izvede: posodobitve preizkusi, namesti, znova zažene storitve in dokaže uspeh. Oba se prepletata.
Ali naj se varnostne posodobitve nameščajo samodejno?
Za pakete operacijskega sistema je to pogosto smiselno, če obstajajo varnostne kopije in se po izvedbi preveri rezultat. Pomembno je, da se znova zaženejo tudi prizadete storitve. Pri PHP sicer v pomnilniku ostanejo stari procesi z ranljivo kodo.
Kako dokažem, da popravek res deluje?
Z nameščenim stanjem paketa in številkami CVE v dnevniku sprememb paketa, časom namestitve in časom zagona delujočih procesov, ki mora biti po namestitvi.
Kaj storiti, če posodobitev nekaj pokvari?
Za to obstaja pot nazaj: varnostna kopija ali posnetek pred posodobitvijo in opisan postopek vračanja. Pri varnostnih posodobitvah naj bo vračanje izjema in naj se poveže s prehodnim ukrepom.