Trumpai: pataisų valdymo procesas nustato, kaip atnaujinimai eina nuo gavimo iki įrodymo: į kokią klasę patenka pataisa, kuriame lange ji diegiama, kaip testuojama ir atšaukiama, kas paleidžia iš naujo ir kaip įrodoma sėkmė. Įprasti atnaujinimai vyksta planuotu ritmu, avarinės pataisos eina iš anksto sutartu greituoju keliu. Taip gaisrininkų darbas virsta pakartojama eiga.
Kai kiekviena pataisa yra avarija
2026-10-21 vakare daugelyje įmonių kartojosi tas pats vaizdas. Pataisos jau buvo, BSI ragino skubėti, ir prasidėjo klausimai: ar dabar galime tiesiog atnaujinti? Kas testuoja? Kas iš naujo paleidžia tarnybas? Kas praneša vadovybei, kad parduotuvė trumpam išjungta? Ir kaip vėliau įrodysime, kad pavyko?
Įmonėse be proceso viską tenka išsiaiškinti tuo metu. Įmonėse su procesu atsakymas jau žinomas. Skirtumas ne technikoje, o iš anksto sutartose taisyklėse.
Pataisų valdymo proceso dalys
Tvarkingas procesas pirmiausia skiria, kiek pataisa skubi. Paprastai pakanka trijų klasių:
| Klasė | Tipinė priežastis | Langas | Testas | Patvirtinimas |
|---|---|---|---|---|
| Įprasta | klaidų taisymai, mažos rizikos saugumo atnaujinimai | pastovus mėnesinis terminas | staging aplinka, standartiniai testai | IT, pagal planą |
| Skubi | aukštas įvertinimas, sistema viešai pasiekiama | trumpam laikui paankstinta | sutrumpintas, svarbiausi procesai | IT vadovas |
| Avarinė | kritinė spraga, pranešta apie atakas, pvz., PHP2Shell | nedelsiant | greitas patikrinimas (smoke test) po įdiegimo | iš anksto suteiktas avarinis patvirtinimas |
Kas kokią klasę skiria, turėtų būti nustatyta taip pat, kaip ir kriterijai. Pats vertinimas priklauso ankstesniam žingsniui, žr. Pažeidžiamumų valdymas vidutinėms įmonėms.
Svarbus iš anksto suteiktas avarinis patvirtinimas. Vadovybė vieną kartą ramiai nusprendžia, kad avarinių pataisų atveju galima veikti nedelsiant, net jei tai reiškia trumpą nutrūkimą. Tada kritiniu atveju niekam nereikia naktį gauti sutikimo.
Ne mažiau svarbūs vaidmenys. Kiekvienai sistemai turėtų būti nustatyta, kas diegia atnaujinimus, kas testuoja pagal paskirtį, ar po to veikia parduotuvė ar portalas, ir kam pranešama. Išorinėms sistemoms hostingo teikėjas ir agentūra aiškiai priklauso sąrašui, nurodant vardus ir pasiekiamumą. Pastovus aptarnavimo langas turėtų būti žinomas įmonėje, kad pardavimai ir klientų aptarnavimas žinotų, kada galimi trumpi nutrūkimai.
Be to, matuokite, kiek iš tikrųjų trunka jūsų procesas: nuo pataisos paskelbimo iki įrodyto užbaigimo, atskirai pagal klasę. Šios jūsų pačių reikšmės parodo, kur stringama, ir leidžia matyti patobulinimus. Procesas, kurio trukmės niekas nežino, sunkiai valdomas.
Pataisos eiga aštuoniais žingsniais
Kiekviena pataisa, nepriklausomai nuo klasės, eina per tas pačias stotis. Skiriasi tik tempas ir testavimo gylis.
- Gavimas: pranešimas ar galimas atnaujinimas užregistruojamas su data ir šaltiniu.
- Klasifikavimas: nustatoma klasė, pagal inventorių nustatomos paveiktos sistemos.
- Pasirengimas: atsarginė kopija ar momentinė kopija (snapshot), aprašomas grįžimo kelias, informuojami dalyviai.
- Testas: pirmiausia staging aplinkoje arba mažiau kritinėje sistemoje.
- Įdiegimas: sutartame lange, sistema po sistemos.
- Paleidimas iš naujo: visos paveiktos tarnybos ir procesai, ne tik paketai.
- Įrodymas: užfiksuojama paketo būsena, pakeitimų žurnalo įrašas ir proceso paleidimas.
- Kontrolė: patikrinama veikla, saugumo spragų atveju papildomai ieškoma ankstesnio įsilaužimo pėdsakų.
6 žingsnis stebėtinai dažnai pamirštamas. PHP savo kodą įkelia paleisdamas procesus. Kol veikia seni PHP-FPM darbiniai procesai (worker) ar Apache procesai su mod_php, jie toliau dirba su senąja, pažeidžiama būsena. Kodėl taip yra ir kaip teisingai paleisti iš naujo, rasite skyriuje Po atnaujinimo: iš naujo paleisti PHP-FPM ir visus darbinius procesus.
Įrodymai, kurie vėliau svarbūs
Pataisa be įrodymo abejotinais atvejais laikoma neįdiegta, bent jau klientų, draudikų ar auditorių akyse. Kiekvienai sistemai užfiksuokite, kokia paketo būsena įdiegta, ar CVE numeriai yra pakeitimų žurnale ir kada buvo paleisti veikiantys procesai. Debian ir Ubuntu sistemose tam padeda tik skaitančios komandos, pavyzdžiui, šios (paketo pavadinimą pritaikykite savo sistemai):
# Ar įdiegtame pakete yra pataisos?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# Kada buvo paleisti veikiantys PHP-FPM procesai?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
Jei procesų paleidimo laikas ankstesnis už paketo įdiegimą, trūksta paleidimo iš naujo. Išsamiai tai aprašyta skyriuje CVE numerių įrodymas paketo pakeitimų žurnale.
Pataisa uždaro spragą ateičiai. Ji nepašalina kenkėjiškos programinės įrangos, kuri buvo įterpta anksčiau, ir neįrodo, kad anksčiau nieko nenutiko. Todėl avarinių pataisų atveju pėdsakų paieška turi būti pastovi eigos dalis.
Automatizuoti ten, kur saugu
Automatiniai operacinės sistemos paketų saugumo atnaujinimai atima daug rutininio darbo. Tačiau jie palengvina tik tada, kai yra atsarginių kopijų, kas nors skaito rezultatus ir iš naujo paleidžiamos paveiktos tarnybos. Kaip tai nustatyti Linux sistemoje ir kokios yra ribos, aprašyta straipsnyje Automatiniai saugumo atnaujinimai Linux serveriuose.
Konteineriams reikia atskiro kelio. Ten atnaujinama ne veikiančioje sistemoje, o iš naujo sukuriamas ir paleidžiamas atvaizdas (image) su ištaisyta PHP versija. Pataisų procesas, pažįstantis tik serverius, lengvai praleidžia šias sistemas. Todėl į pataisų kelių sąrašą įtraukite ir kūrimo konvejerius (build pipeline) bei atvaizdų registrus, nurodydami atsakingą asmenį ir tą patį įrodymą kaip klasikinių serverių atveju: kokia PHP versija veikia paleistame konteineryje ir nuo kada?
Programoms, CMS ir papildiniams paprastai reikia savo, išbandyto kelio, nes ten atnaujinimai dažniau keičia funkcijas. Pastovus mėnesio terminas tam tinkamiausias. Svarbu, kad galiausiai visi keliai susilietų toje pačioje dokumentacijoje: vienoje vietoje matyti, kuri sistema kokios būsenos.
Kaip PHP SOS padeda konkrečiai?
- Kartu su jumis užrašome pataisų klases, langus ir patvirtinimus, pritaikytus jūsų sistemoms ir organizacijai.
- Ten, kur tai prasminga, nustatome automatinius saugumo atnaujinimus su paleidimo iš naujo patikra ir pranešimais.
- Avarines pataisas perimame kartu su paleidimu iš naujo, įrodymu ir pėdsakų paieška per mūsų PHP pataisų paslaugą.
- Įrodymus kiekvienai sistemai vedame taip, kad galėtumėte juos pateikti klientams, draudikams ar auditoriams.
Išvada: pataisų valdymas atrodo neįspūdingai, kol veikia. Būtent tai ir yra tikslas: kai ateis kitas kritinis pranešimas, veiks išmokta eiga ir niekam nereikės improvizuoti.
Dažni klausimai
Kuo skiriasi pataisų valdymas ir pažeidžiamumų valdymas?
Pažeidžiamumų valdymas registruoja ir vertina spragas bei nusprendžia, ką daryti. Pataisų valdymas sprendimą įgyvendina: atnaujinimus išbando, įdiegia, iš naujo paleidžia tarnybas ir įrodo sėkmę. Abu glaudžiai susiję.
Ar saugumo atnaujinimus reikėtų diegti automatiškai?
Operacinės sistemos paketams tai dažnai prasminga, jei yra atsarginių kopijų ir po paleidimo atliekama patikra. Svarbu, kad iš naujo būtų paleistos ir paveiktos tarnybos. Kitaip PHP atveju senieji procesai su pažeidžiamu kodu lieka atmintyje.
Kaip įrodyti, kad pataisa tikrai veikia?
Įdiegta paketo būsena ir CVE numeriais paketo pakeitimų žurnale, diegimo laiku ir veikiančių procesų paleidimo laiku, kuris turi būti vėlesnis už diegimą.
Ką daryti, jei atnaujinimas ką nors sugadina?
Tam skirtas grįžimo kelias: atsarginė kopija ar momentinė kopija (snapshot) prieš atnaujinimą ir aprašyta atstatymo tvarka. Saugumo atnaujinimų atveju grįžimas turėtų būti išimtis ir būti derinamas su pereinamąja priemone.