Lyhyesti: Päivitysten hallinnan prosessi määrittää, miten päivitykset etenevät saapumisesta todisteeseen: mihin luokkaan korjaus kuuluu, missä ikkunassa se asennetaan, miten testataan ja palautetaan, kuka käynnistää uudelleen ja miten onnistuminen todistetaan. Rutiinipäivitykset etenevät suunnitellusti omassa tahdissaan, hätäkorjaukset noudattavat etukäteen sovittua pikareittiä. Näin palokunta-ajoista tulee toistettava toimintatapa.
Kun jokainen päivitys on hätätilanne
21.10.2026 illalla monessa yrityksessä toistui sama kuvio. Korjaukset olivat saatavilla, BSI (Saksan liittovaltion tietoturvavirasto) patisti, ja kysymykset alkoivat: Saammeko nyt vain päivittää? Kuka testaa? Kuka käynnistää palvelut uudelleen? Kuka kertoo johdolle, että verkkokauppa on hetken pois käytöstä? Ja miten todistamme jälkeenpäin, että onnistuimme?
Yrityksissä ilman prosessia kaikki tämä on ratkaistava siinä hetkessä. Yrityksissä, joissa prosessi on, vastaus on jo olemassa. Ero ei ole tekniikassa vaan etukäteen tehdyissä sopimuksissa.
Päivitysten hallinnan prosessin rakennuspalikat
Kantava prosessi erottaa ensin, kuinka kiireellinen päivitys on. Kolme luokkaa riittää yleensä:
| Luokka | Tyypillinen syy | Ikkuna | Testi | Hyväksyntä |
|---|---|---|---|---|
| Rutiini | virhekorjaukset, tietoturvapäivitykset joiden riski on pieni | kiinteä kuukausittainen ajankohta | testiympäristö, vakiotestit | IT, suunnitelman mukaan |
| Kiireellinen | korkea luokitus, järjestelmä julkisesti tavoitettavissa | aikaistettu lyhyellä varoitusajalla | lyhennetty, tärkeimmät toiminnot | IT-päällikkö |
| Hätätilanne | kriittinen aukko, hyökkäyksiä raportoitu, esim. PHP2Shell | heti | savutesti asennuksen jälkeen | etukäteen annettu hätähyväksyntä |
Se, kuka luokan antaa, kannattaa sopia yhtä tarkkaan kuin perusteetkin. Arviointi itsessään kuuluu edeltävään vaiheeseen, katso Haavoittuvuuksien hallinta pk-yrityksessä.
Tärkeää on etukäteen annettu hätähyväksyntä. Johto päättää kerran rauhassa, että hätäkorjauksissa saa toimia heti, vaikka se tarkoittaisi lyhyttä katkosta. Hätätilanteessa kenenkään ei tarvitse silloin hakea lupaa yöllä.
Yhtä tärkeitä ovat roolit. Jokaisesta järjestelmästä pitäisi olla selvää, kuka asentaa päivitykset, kuka testaa toiminnallisesti, toimiiko verkkokauppa tai portaali sen jälkeen, ja ketä tiedotetaan. Ulkoistetuissa järjestelmissä hosting-yritys ja toimisto kuuluvat nimenomaisesti mukaan nimineen ja tavoitettavuustietoineen. Kiinteä huoltoikkuna kannattaa tehdä tutuksi talon sisällä, jotta myynti ja asiakaspalvelu tietävät, milloin lyhyet katkot ovat mahdollisia.
Mitatkaa lisäksi, kuinka kauan prosessinne todellisuudessa kestää: korjauksen julkaisusta todistettuun päätökseen, luokittain eroteltuna. Nämä omat arvot osoittavat, missä kohtaa takkuaa, ja tekevät parannukset näkyviksi. Prosessia, jonka kestoa kukaan ei tunne, on vaikea ohjata.
Päivityksen kulku kahdeksassa vaiheessa
Jokainen päivitys luokasta riippumatta käy läpi samat vaiheet. Vain vauhti ja testin syvyys vaihtelevat.
- Vastaanotto: tiedote tai saatavilla oleva päivitys kirjataan päivämäärän ja lähteen kanssa.
- Luokitus: määritetään luokka ja luettelon perusteella kohteena olevat järjestelmät.
- Valmistelu: varmuuskopio tai tilannekuva, paluutien kuvaus, osallisten tiedottaminen.
- Testi: ensin testiympäristössä tai vähemmän kriittisessä järjestelmässä.
- Asennus: sovitussa ikkunassa, järjestelmä kerrallaan.
- Uudelleenkäynnistys: kaikki kohteena olevat palvelut ja prosessit, ei vain paketit.
- Todiste: paketin tila, muutoslokin merkintä ja prosessin käynnistys kirjataan.
- Tarkastus: toiminnan tarkistus, tietoturva-aukkojen kohdalla lisäksi aiemman tunkeutumisen jälkien etsintä.
Vaihe 6 unohtuu yllättävän usein. PHP lataa koodinsa prosessien käynnistyessä. Niin kauan kuin vanhat PHP-FPM-työprosessit tai Apachen prosessit mod_php:n kanssa ovat käynnissä, ne jatkavat vanhalla, haavoittuvalla tilalla. Miksi näin on ja miten uudelleenkäynnistys tehdään oikein, selviää sivulta Päivityksen jälkeen: PHP-FPM ja kaikki työprosessit uudelleen.
Todisteet, jotka merkitsevät myöhemmin
Päivitys ilman todistetta on epäselvissä tapauksissa asentamatta, ainakin asiakkaiden, vakuutusyhtiöiden tai tarkastajien silmissä. Kirjatkaa jokaisesta järjestelmästä, mikä paketin tila on asennettu, ovatko CVE-numerot muutoslokissa ja milloin käynnissä olevat prosessit on käynnistetty. Debian- ja Ubuntu-järjestelmissä auttavat lukevat komennot kuten nämä (muokatkaa paketin nimi omaan järjestelmäänne sopivaksi):
# Sisältääkö asennettu paketti korjaukset?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# Milloin käynnissä olevat PHP-FPM-prosessit on käynnistetty?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
Jos prosessien käynnistysaika on ennen paketin asennusta, uudelleenkäynnistys puuttuu. Tarkemmin asiaa käsittelee CVE-numeroiden osoittaminen paketin muutoslokista.
Päivitys sulkee aukon tulevaisuutta varten. Se ei poista haittaohjelmaa, joka on tuotu sisään aiemmin, eikä todista, ettei aiemmin ole tapahtunut mitään. Siksi hätäkorjauksiin kuuluu kiinteästi jälkien etsintä.
Automatisoi, missä se on turvallista
Käyttöjärjestelmäpakettien automaattiset tietoturvapäivitykset vievät paljon rutiinityötä. Ne kuitenkin helpottavat vain, jos varmuuskopiot ovat olemassa, joku lukee tulokset ja myös kohteena olevat palvelut käynnistetään uudelleen. Miten tämä otetaan käyttöön Linuxissa ja mitkä ovat rajat, kuvaa artikkeli Automaattiset tietoturvapäivitykset Linux-palvelimilla.
Kontit tarvitsevat oman tiensä. Siellä ei päivitetä käynnissä olevaa järjestelmää, vaan korjatun PHP-version sisältävä image rakennetaan uudelleen ja otetaan käyttöön. Prosessi, joka tuntee vain palvelimet, ohittaa nämä järjestelmät helposti. Ottakaa siksi myös koontiputket ja image-rekisterit päivitysteiden luetteloon, vastuuhenkilön kanssa ja samalla todisteella kuin perinteisillä palvelimilla: mikä PHP-versio on käytössä julkaistussa kontissa ja mistä lähtien?
Sovellukset, CMS ja lisäosat tarvitsevat yleensä oman testatun reittinsä, koska päivitykset muuttavat niissä toimintoja useammin. Kiinteä kuukausittainen ajankohta on siihen oikea paikka. Tärkeää on lopulta, että kaikki reitit yhtyvät samaan dokumentaatioon: yhteen paikkaan, josta näkee, missä tilassa mikäkin järjestelmä on.
Miten PHP SOS auttaa konkreettisesti?
- Kirjaamme kanssanne ylös korjausluokat, ikkunat ja hyväksynnät, jotka sopivat järjestelmiinne ja organisaatioonne.
- Otamme käyttöön automaattiset tietoturvapäivitykset uudelleenkäynnistystarkistuksella ja ilmoituksella, missä se on järkevää.
- Hoidamme hätäkorjaukset uudelleenkäynnistyksineen, todisteineen ja jälkien etsintöineen PHP-korjauspalvelumme kautta.
- Ylläpidämme todisteet järjestelmäkohtaisesti niin, että voitte esittää ne asiakkaille, vakuutusyhtiöille tai tarkastajille.
Yhteenveto: Päivitysten hallinta vaikuttaa vaatimattomalta niin kauan kuin se toimii. Juuri se on tavoite: kun seuraava kriittinen tiedote tulee, käytössä on harjoiteltu toimintatapa, eikä kenenkään tarvitse improvisoida.
Usein kysytyt kysymykset
Mitä eroa on päivitysten hallinnalla ja haavoittuvuuksien hallinnalla?
Haavoittuvuuksien hallinta kirjaa ja arvioi aukot ja päättää, mitä tehdään. Päivitysten hallinta toteuttaa päätöksen: päivitysten testaaminen, asentaminen, palveluiden uudelleenkäynnistys ja onnistumisen todistaminen. Molemmat nivoutuvat toisiinsa.
Pitäisikö tietoturvapäivitykset asentaa automaattisesti?
Käyttöjärjestelmän paketeille se on usein järkevää, kunhan varmuuskopiot ovat olemassa ja ajon jälkeen tarkistetaan tulos. Tärkeää on, että myös kohteena olevat palvelut käynnistyvät uudelleen. PHP:ssä muuten vanhat prosessit jäävät muistiin haavoittuvan koodin kanssa.
Miten todistan, että päivitys todella tehoaa?
Asennetun paketin tilalla ja CVE-numeroilla paketin muutoslokissa, asennushetkellä ja käynnissä olevien prosessien käynnistysajalla, jonka on oltava asennuksen jälkeen.
Mitä tehdä, jos päivitys rikkoo jotain?
Sitä varten on paluutie: varmuuskopio tai tilannekuva ennen päivitystä ja kuvattu menettely palauttamiseen. Tietoturvapäivityksissä palauttamisen pitäisi olla poikkeus, ja siihen pitäisi liittää väliaikainen toimenpide.