# Ielāpu pārvaldība kā process, nevis ugunsdzēsēju darbs

> Ielāpu pārvaldība kā process: ielāpu klases, apkopes logi, tests, atkāpšanās ceļš, pārstartēšana un apliecinājums, lai kritiski atjauninājumi darbotos.

Avots: https://phpsos.de/lv/blog/patch-management-prozess/  
Aktuāls uz: 25.10.2026  
Pakalpojuma sniedzējs: PHP SOS, PHP ārkārtas palīdzība un serveru drošība. Tūlītēja palīdzība pa WhatsApp: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20nepiecie%C5%A1ama%20pal%C4%ABdz%C4%ABba%20ar%20m%C5%ABsu%20PHP%20serveri.%20Uz%C5%86%C4%93mums%3A%20%E2%80%A6%20Vietne%3A%20%E2%80%A6

**Īsi sakot:** Ielāpu pārvaldības process nosaka, kā atjauninājumi norit no saņemšanas līdz apliecinājumam: kurā klasē ielāps ietilpst, kurā logā tas tiek uzstādīts, kā tiek testēts un atgriezts, kas pārstartē un kā apliecina panākumus. Ikdienas atjauninājumi norit plānoti ritmā, ārkārtas ielāpi seko iepriekš saskaņotam ātrajam ceļam. Tā ugunsdzēsēju darbi kļūst par atkārtojamu procesu.

## Kad katrs ielāps ir ārkārtas situācija

2026. gada 21. oktobra vakarā daudzos uzņēmumos atkārtojās viens un tas pats modelis. Ielāpi bija klāt, BSI mudināja, un sākās jautājumi: vai mēs tagad drīkstam vienkārši atjaunināt? Kas testē? Kas pārstartē pakalpojumus? Kas paziņo vadībai, ka veikals uz brīdi nebūs pieejams? Un kā pēc tam pierādīt, ka tas izdevās?

Uzņēmumos bez procesa tas viss jānoskaidro tajā brīdī. Uzņēmumos ar procesu atbilde jau ir noteikta. Atšķirība nav tehnikā, bet vienošanās, kas panāktas iepriekš.

## Ielāpu pārvaldības procesa pamatelementi

Noturīgs process vispirms nošķir, cik steidzams ir ielāps. Parasti pietiek ar trim klasēm:

| Klase | Tipisks iemesls | Logs | Tests | Apstiprinājums |
|---|---|---|---|---|
| Ikdienas | kļūdu labojumi, drošības atjauninājumi ar zemu risku | fiksēts ikmēneša termiņš | Staging, standarta testi | IT, pēc plāna |
| Steidzams | augsts novērtējums, sistēma publiski sasniedzama | īstermiņā pavirzīts uz priekšu | saīsināts, svarīgākās darbības | IT vadītājs |
| Ārkārtas | kritiska nepilnība, ziņots par uzbrukumiem, piem., PHP2Shell | nekavējoties | dūmu tests pēc uzstādīšanas | iepriekš izsniegts ārkārtas apstiprinājums |

Tam, kurš kuru klasi piešķir, jābūt tikpat noteiktam kā kritērijiem. Pats novērtējums pieder pie iepriekšējā soļa, skatiet [Ievainojamību pārvaldība vidējiem uzņēmumiem](https://phpsos.de/lv/blog/schwachstellenmanagement-mittelstand/).

Svarīgs ir iepriekš izsniegts ārkārtas apstiprinājums. Vadība vienreiz mierīgi nolemj, ka ārkārtas ielāpu gadījumā drīkst rīkoties nekavējoties, pat ja tas nozīmē īslaicīgu pārtraukumu. Ārkārtas situācijā nevienam tad nav naktī jāmeklē piekrišana.

Tikpat svarīgas ir lomas. Katrai sistēmai jābūt noteiktam, kas uzstāda atjauninājumus, kas funkcionāli testē, vai veikals vai portāls pēc tam darbojas, un kam tiek ziņots. Ārpakalpojumu sistēmām hostinga pakalpojumu sniedzējs un aģentūra ir skaidri jāiekļauj, ar vārdu un sasniedzamību. Fiksētajam apkopes logam jābūt zināmam uzņēmumā, lai pārdošana un klientu apkalpošana zinātu, kad iespējami īsi pārtraukumi.

Turklāt mēriet, cik ilgi jūsu process patiešām aizņem: no ielāpa publicēšanas līdz apliecinātam noslēgumam, atsevišķi pa klasēm. Šīs paša uzņēmuma vērtības parāda, kur sanāk aizķeršanās, un padara uzlabojumus redzamus. Procesu, kura ilgumu neviens nezina, ir grūti vadīt.

## Ielāpa norise astoņos soļos

Katrs ielāps, neatkarīgi no klases, iziet cauri vieniem un tiem pašiem posmiem. Atšķiras tikai temps un testēšanas dziļums.

1. **Saņemšana:** ziņojums vai pieejamais atjauninājums tiek reģistrēts ar datumu un avotu.
2. **Klasificēšana:** noteikt klasi, pēc inventāra noteikt skartās sistēmas.
3. **Sagatavošana:** rezerves kopija vai momentuzņēmums, aprakstīt atkāpšanās ceļu, informēt iesaistītos.
4. **Tests:** vispirms Staging vidē vai mazāk kritiskā sistēmā.
5. **Uzstādīšana:** saskaņotajā logā, sistēma pēc sistēmas.
6. **Pārstartēšana:** visi skartie pakalpojumi un procesi, ne tikai pakotnes.
7. **Apliecinājums:** fiksēt pakotnes stāvokli, izmaiņu žurnāla ierakstu un procesa startēšanu.
8. **Kontrole:** pārbaudīt darbību, drošības nepilnību gadījumā papildus pievērst uzmanību agrākas ielaušanās pēdām.

6. solis tiek aizmirsts pārsteidzoši bieži. PHP ielādē savu kodu, startējot procesus. Kamēr darbojas veci PHP-FPM darbinieki (worker) vai Apache procesi ar mod_php, tie turpina strādāt ar veco, ievainojamo stāvokli. Kāpēc tā notiek un kā pareizi pārstartēt, lasiet sadaļā [Pēc atjauninājuma: PHP-FPM un visu darbinieku pārstartēšana](https://phpsos.de/lv/php2shell/php-fpm-neustart/).

## Apliecinājumi, kas vēlāk nozīmē daudz

Ielāps bez pierādījuma šaubu gadījumā nav uzstādīts, vismaz attiecībā pret klientiem, apdrošinātājiem vai pārbaudītājiem. Katrai sistēmai fiksējiet, kāds pakotnes stāvoklis ir uzstādīts, vai CVE numuri ir izmaiņu žurnālā un kad startēti darbojošies procesi. Debian un Ubuntu sistēmās palīdz tikai lasošas komandas, piemēram, šīs (pakotnes nosaukumu pielāgojiet savai sistēmai):

```bash
# Vai uzstādītā pakotne satur labojumus?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# Kad tika startēti darbojošies PHP-FPM procesi?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
```

Ja procesu startēšanas laiks ir pirms pakotnes uzstādīšanas, pārstartēšana nav veikta. Detalizēti to apraksta [CVE numuru apliecināšana pakotnes izmaiņu žurnālā](https://phpsos.de/lv/blog/cve-im-changelog-nachweisen/).

> **Svarīgi:**
> Ielāps aizver nepilnību nākotnei. Tas nenoņem ļaunprātīgo programmatūru, kas ielaista iepriekš, un nepierāda, ka iepriekš nekas nav noticis. Ārkārtas ielāpu gadījumā pēdu meklēšana tāpēc ir cieši saistīta ar norisi.

## Automatizēt tur, kur tas ir drošs

Automātiski drošības atjauninājumi operētājsistēmas pakotnēm noņem daudz rutīnas darba. Tie atslogo tikai tad, ja ir rezerves kopijas, kāds lasa rezultātus un tiek pārstartēti arī skartie pakalpojumi. Kā to iestatīt Linux sistēmās un kādi ir ierobežojumi, apraksta [Automātiski drošības atjauninājumi Linux serveros](https://phpsos.de/lv/blog/automatische-sicherheitsupdates/).

Konteineriem vajadzīgs savs ceļš. Tur atjaunināšana notiek nevis darbojošā sistēmā, bet attēls (image) ar labotu PHP versiju tiek būvēts no jauna un izvietots. Ielāpu process, kas pazīst tikai serverus, šīs sistēmas viegli palaiž garām. Tāpēc ielāpu ceļu sarakstā iekļaujiet arī būvēšanas konveijerus (build pipelines) un attēlu reģistrus, ar atbildīgo personu un to pašu apliecinājumu kā klasiskajiem serveriem: kāda PHP versija darbojas izvietotajā konteinerā un kopš kura laika?

Lietojumprogrammām, CMS un spraudņiem parasti vajadzīgs savs, pārbaudīts ceļš, jo atjauninājumi tur biežāk maina funkcijas. Fiksētais ikmēneša termiņš tam ir īstā vieta. Galu galā svarīgi, lai visi ceļi saplūstu vienā dokumentācijā: vienā vietā, kur redzams, kura sistēma ir kādā stāvoklī.

## Kā PHP SOS palīdz konkrēti?

- Mēs kopā ar jums pierakstām ielāpu klases, logus un apstiprinājumus, kas atbilst jūsu sistēmām un organizācijai.
- Mēs iestatām automātiskus drošības atjauninājumus ar pārstartēšanas pārbaudi un paziņojumu, kur tas ir lietderīgi.
- Mēs veicam ārkārtas ielāpus, ieskaitot pārstartēšanu, apliecinājumu un pēdu meklēšanu, ar mūsu [PHP ielāpu servisu](https://phpsos.de/lv/leistungen/php-patch-service/).
- Mēs vedam apliecinājumus katrai sistēmai tā, lai jūs tos varētu uzrādīt klientiem, apdrošinātājiem vai pārbaudītājiem.

**Secinājums:** Ielāpu pārvaldība šķiet neuzkrītoša, kamēr tā darbojas. Tieši tas ir mērķis: kad nāk nākamais kritiskais ziņojums, norit ieviests process, un nevienam nav jāimprovizē.


## Biežāk uzdotie jautājumi

**Kāda ir atšķirība starp ielāpu pārvaldību un ievainojamību pārvaldību?**  
Ievainojamību pārvaldība uzskaita un novērtē nepilnības un izlemj, kas jādara. Ielāpu pārvaldība īsteno lēmumu: testē atjauninājumus, uzstāda tos, pārstartē pakalpojumus un apliecina panākumus. Abas darbojas kopā.

**Vai drošības atjauninājumi būtu jāuzstāda automātiski?**  
Operētājsistēmas pakotnēm tas bieži ir lietderīgi, ja ir rezerves kopijas un pēc izpildes tiek veikta pārbaude. Svarīgi, lai tiktu pārstartēti arī skartie pakalpojumi. PHP gadījumā citādi atmiņā paliek veci procesi ar ievainojamo kodu.

**Kā pierādīt, ka ielāps tiešām darbojas?**  
Ar uzstādīto pakotnes stāvokli un CVE numuriem pakotnes izmaiņu žurnālā, uzstādīšanas laiku un darbojošos procesu startēšanas laiku, kam jābūt vēlākam par uzstādīšanu.

**Ko darīt, ja atjauninājums kaut ko sabojā?**  
Tam ir atkāpšanās ceļš: rezerves kopija vai momentuzņēmums pirms atjauninājuma un aprakstīta atjaunošanas kārtība. Drošības atjauninājumiem atgriešanai vajadzētu būt izņēmumam, un to jāsavieno ar pagaidu pasākumu.

## Avoti

- [php.net: drošības paziņojumi](https://www.php.net/)
- [Debian Security Tracker](https://security-tracker.debian.org/)
- [Ubuntu Security Notices](https://ubuntu.com/security/notices)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)