Lyhyesti: Verkkosivuston toimitusketju ulottuu PHP-projektista jakelun ja hosting-yrityksen kautta CMS:ään, lisäosiin, toimistoon ja sisäänrakennettuihin palveluihin. IT-turvallisuuden kannalta jokaisella lenkillä on merkitystä, sillä korjaus tavoittaa verkkosivustonne vasta, kun kaikki ovat välittäneet sen eteenpäin. Joka kirjaa ketjun ylös, määrittää jokaiselle lenkille vastuutahon ja todisteen sekä rajaa käyttöoikeudet, tekee ketjusta kestävän.
Yksi korjaus ja sen pitkä matka
21.10.2026 kello 14.00 UTC PHP-projekti julkaisi PHP2Shellin korjaukset. Sillä ei yksikään verkkosivusto vielä suojautunut. Ensin jakeluiden, kuten Debianin, Ubuntun tai RHEL-perheen, oli otettava korjaukset paketteihinsa; raporttien mukaan backportit toimitettiin osin samana päivänä. Sitten hosting-yritysten ja ylläpitäjien oli asennettava nämä paketit ja käynnistettävä kaikki PHP-prosessit uudelleen. Vasta sen jälkeen kyseinen verkkosivusto oli suojattu.
Jokainen ketjun lenkki voi viivästyttää. Ja jokaisen takana on eri organisaatio omine prioriteetteineen. Joka ei tiedä, miltä sen ketju näyttää, ei voi sanoa, missä korjaus juuri nyt on.
Joissakin ketjuissa on lisälenkkejä, joita lähes kukaan ei tunne. Monet Debian- ja Ubuntu-palvelimet hakevat PHP:n jakelun sijaan Ondřej Surýn ylläpitämästä sury.org-pakettivarastosta, joka on yleinen kolmannen osapuolen lähde. Raporttien mukaan se on tarjonnut koontiversioita kaikille haaroille 5.6:sta 8.5:een. Se on hyödyllistä, mutta se ei ole Debianin tietoturva-arkisto: joka käyttää tätä lähdettä, riippuu toisesta lenkistä, jolla on oma tahtinsa ja oma vastuunsa. Se, onko palvelin määritetty näin, näkyy pakettilähteiden luettelosta, ja juuri tämä tieto kuuluu ketjun dokumentaatioon.
Toimitusketjun lenkit yleiskuvana
Seuraava taulukko näyttää PHP-verkkosivuston tyypilliset lenkit ja sen, mitä kultakin voitte vaatia.
| Lenkki | Tyypillinen riski | Mitä kannattaa sopia |
|---|---|---|
| PHP-projekti | aukko tulkissa, tuen päättyminen | käytössä tuettu versio, suunnitelma tuen päättymiselle |
| Jakelu tai kolmannen osapuolen lähde | backport puuttuu tai tulee myöhässä | tunnettu pakettilähde, tietoturvatiedotteet tilattu |
| Hosting-yritys tai alustapalvelu | päivitys ilman uudelleenkäynnistystä, ei tiedotusta | velvoite päivittää, käynnistää uudelleen, todistaa ja ilmoittaa |
| CMS-valmistaja | aukko ytimessä | päivityskanava, vastuuhenkilö |
| Lisäosien ja teemojen toimittaja | hylätyt tai turvattomat laajennukset | vain ylläpidetyt lisäosat virallisista lähteistä |
| Toimisto tai kehittäjä | laajat käyttöoikeudet, epäselvä vastuu | henkilökohtaiset tunnukset, kirjalliset toimeksiannot |
| Ulkoiset komentosarjat ja palvelut | vieras koodi selaimessa, tietovuoto | luettelo, kiinteät versiot, tarkoitus tarkistettu |
Kaksi esimerkkiä PHP2Shell-viikolta osoittaa, kuinka helposti lenkki jää huomaamatta. Vercel huomauttaa, ettei paikallisen kehitysympäristön, sovelluskoodin tai lisäosien päivitys riitä; ratkaisevaa on PHP-ajoympäristö, joka todellisuudessa palvelee. Coolify neuvoo päivittämään jokaisen sovelluksen PHP-ajoympäristön erikseen, myös Cloudflaren takana. Ja raporttien mukaan WordPress.org ei suunnittele omaa päivitystä PHP2Shelliä vastaan, koska aukko on tulkissa. Joka odottaa CMS:ää, odottaa turhaan.
Ketju näkyväksi: viisi vaihetta
Näin saatte järjestystä verkkosivustojenne riippuvuuksiin:
- Kirjaa ketju ylös verkkosivustoittain: PHP-ajoympäristöstä ulkoisiin komentosarjoihin, toimittajan tai henkilön nimellä.
- Määritä vastuu lenkeittäin: Kuka asentaa päivitykset, kuka tarkistaa, kuka tiedottaa kenelle?
- Sovi todisteista: Mikä katsotaan tehdyksi? PHP-ajoympäristön kohdalla esimerkiksi paketin tila ja uudelleenkäynnistys, kuten sivulla Näin kysytte hosting-yritykseltänne päivitysten tilaa kuvataan.
- Rajaa käyttöoikeudet: Jokainen toimisto ja palveluntarjoaja saa vain tarvitsemansa oikeudet, henkilökohtaisilla tileillä.
- Suunnittele vaihtoehtoiset reitit: Mitä tehdään, jos lenkki pettää, esimerkiksi lisäosan toimittaja lopettaa tai palveluntarjoajaa ei tavoiteta?
Kysykää jokaiselta palveluntarjoajalta, miten hän tiedottaa teille kriittisistä aukoista. Joka vastaa vain pyynnöstä, on PHP2Shellin kaltaisessa tilanteessa riski aikatauluillenne. Kirjatkaa vastaus kirjallisesti.
Lisäosat ja laajennukset: epäselvin kohta
Monilla verkkosivustoilla suurin osa toimitusketjusta on näkymätön: vuosien varrella tulleet lisäosat ja teemat. Jokainen on eri toimittajalta, omalla tietoturvapäivitysten tahdillaan. Jotkin toimittajat luopuvat tuotteestaan ilmoittamatta. Toisia laajennuksia hankitaan epävirallisista lähteistä, eivätkä ne saa koskaan päivityksiä.
Tässä auttaa yksinkertainen sääntö: jokaisella lisäosalla on oltava tarkoitus, ylläpidetty toimittaja ja virallinen hankintalähde. Jos jokin puuttuu, se kuuluu korvattavien listalle. Samoin on sisäänrakennettujen palvelujen laita, kuten maksupalveluntarjoajat, varausjärjestelmät, chat-ikkunat tai analytiikkatyökalut. Ne tuovat sivullenne omaa koodiaan tai saavat kävijöidenne tietoja. Kirjatkaa, mitkä palvelut on liitetty, kuka on ne tilannut ja tarvitaanko niitä vielä. Unohtunut komentosarja toimittajalta, jonka kanssa ei ole ollut sopimusta pitkään aikaan, on lenkki ilman vastuuhenkilöä.
Miten lisäosat ja paketit pidetään pysyvästi ajan tasalla, kuvaa artikkeli Riippuvuuksien pitäminen ajan tasalla: Composer, npm ja lisäosat.
Toimitusketju, sopimukset ja NIS2
NIS2:n piiriin kuuluvilla yrityksillä toimitusketjun turvallisuus kuuluu nimenomaisesti riskienhallintaan, siis myös suhteet palveluntarjoajiin ja toimittajiin. Yksityiskohdat löytyvät sivulta NIS2 ja verkkopalvelimen tietoturva. Mutta myös ilman lakisääteistä velvoitetta pätee: ulkoistetut tehtävät pysyvät teidän riskinänne. Siksi viiden vaiheen tulokset kuuluvat sopimuksiin toimiston, hosting-yrityksen ja palveluntarjoajien kanssa; mitä asioita niissä kannattaa sopia, kuvaa artikkeli IT-palveluntarjoajan sopimukset: tietoturvavelvoitteet selkeiksi. Tämä sivu on yleistä tietoa eikä oikeudellista neuvontaa.
Miten PHP SOS auttaa konkreettisesti?
- Piirrämme kanssanne jokaisen verkkosivuston toimitusketjun PHP-ajoympäristöstä ulkoisiin komentosarjoihin.
- Tarkistamme lisäosien, teemojen ja pakettien ylläpitotilan ja alkuperän ja suosittelemme korvaajaa tarvittaessa.
- Sovimme hosting-yrityksen ja toimiston kanssa, kuka vastaa mistäkin lenkistä ja mitä todisteita toimitetaan.
- Missä lenkki on vailla vastuuhenkilöä, otamme sen pysyvästi hoitoomme tietoturvahuoltosopimuksella.
Yhteenveto: Verkkosivuston turvallisuus on yhtä vahva kuin sen toimitusketjun hitain lenkki. Joka tuntee ketjun ja yhdistää jokaisen lenkin vastuutahoon ja todisteeseen, tietää hätätilanteessa, missä korjaus on.
Usein kysytyt kysymykset
Mitä toimitusketju tarkoittaa verkkosivuston kohdalla?
Kaikkia osapuolia, joiden työstä verkkosivustonne turvallisuus riippuu: PHP-projektia, Linux-jakelua, hosting-yritystä tai alustapalvelua, CMS-valmistajaa, lisäosien ja teemojen toimittajia, toimistoa sekä sisäänrakennettuja palveluja kuten maksupalveluntarjoajia tai ulkoisia komentosarjoja.
Olenko vastuussa, jos palveluntarjoaja ei asenna päivityksiä?
Vastuu omasta verkkosivustosta ja sen tiedoista pysyy yleensä teillä, vaikka tehtäviä olisi ulkoistettu. Siksi vastuut pitäisi sopia sopimuksessa selkeästi ja niitä pitäisi valvoa. Oikeudellisen arvioinnin tekevät asianajaja ja tietosuojavastaava.
Riittääkö, että hosting-yritys päivittää PHP:n?
Hosting-yrityksen PHP-ajoympäristön osalta kyllä, kunhan se käynnistää myös kaikki prosessit uudelleen ja osoittaa sen. Jos osa sovelluksestanne toimii muualla, esimerkiksi konteissa, alustapalveluissa tai toisella palvelimella, jokainen ajoympäristö on päivitettävä erikseen.
Miten tunnistan riskialttiit lisäosat?
Varoitusmerkkejä ovat pitkä aika ilman päivityksiä, toimittaja ilman tunnistettavaa tietoturvayhteyshenkilöä, epävirallisista lähteistä hankinta ja toiminnot, joita kukaan ei enää käytä. Tällaiset lisäosat pitäisi korvata tai poistaa.