Lühidalt: Veebisaidi tarneahel ulatub PHP projektist läbi distributsiooni ja veebimajutaja kuni CMS-i, pistikprogrammide, agentuuri ja integreeritud teenusteni. IT-turvalisuse jaoks loeb iga lüli, sest paik jõuab teie veebisaidile alles siis, kui kõik on selle edasi andnud. Kes tarneahela üles kirjutab, määrab igale lülile vastutava isiku ja tõendi ning piirab ligipääse, teeb selle töökindlaks.
Paik ja selle pikk teekond
21.10.2026 kell 14:00 UTC avaldas PHP projekt PHP2Shelli parandused. See ei sulgenud turvaauku mitte ühelgi veebisaidil. Kõigepealt pidid distributsioonid, nagu Debian, Ubuntu või RHEL-i perekond, parandused oma pakettidesse üle võtma; aruannete kohaselt tarniti tagasiportimisi (backport) osaliselt samal päeval. Seejärel pidid veebimajutajad ja administraatorid need paketid paigaldama ja kõik PHP protsessid taaskäivitama. Alles pärast seda oli vastav veebisait kaitstud.
Iga lüli selles ahelas võib viivitada. Ja igaühe taga on teine organisatsioon omaenda prioriteetidega. Kes ei tea, milline on tema ahel, ei oska öelda, kus paik parajasti on.
Mõnel ahelal on lisalülisid, mida peaaegu keegi ei tunne. Paljud Debiani ja Ubuntu serverid ei võta PHP-d distributsioonist, vaid Ondřej Surý hoidlast aadressil sury.org, levinud kolmanda poole allikast. Aruannete kohaselt on see pakkunud ehitusi kõigile harudele alates 5.6 kuni 8.5. See on kasulik, kuid see ei ole Debiani turvaarhiiv: kes seda allikat kasutab, sõltub teisest lülist, omaenda rütmi ja vastutusega. Kas server on nii seadistatud, näitab pakettide allikate nimekiri, ja just see teave kuulub ahela dokumentatsiooni.
Tarneahela lülid ülevaates
Allolev tabel näitab PHP veebisaidi tüüpilisi lülisid ja seda, mida saate igaühelt nõuda.
| Lüli | Tüüpiline risk | Mida peaksite kindlaks määrama |
|---|---|---|
| PHP projekt | turvaauk interpretaatoris, toe lõpp | kasutusel toetatud versioon, plaan toe lõpuks |
| Distributsioon või kolmanda poole allikas | tagasiportimine puudub või tuleb hilja | teada pakettide allikas, tellitud turvateated |
| Veebimajutaja või platvormiteenus | uuendus ilma taaskäivituseta, teavet ei anta | kohustus uuendada, taaskäivitada, tõendada ja teavitada |
| CMS-i tootja | turvaauk tuumas | uuenduskanal, vastutav isik |
| Pistikprogrammide ja teemade pakkuja | hüljatud või ebaturvalised laiendused | ainult hooldatud pistikprogrammid ametlikest allikatest |
| Agentuur või arendaja | kaugeleulatuvad ligipääsud, ebaselge vastutus | isiklikud ligipääsud, kirjalikud ülesanded |
| Välised skriptid ja teenused | võõras kood brauseris, andmete väljavool | nimekiri, kindlad versioonid, otstarve kontrollitud |
Kaks näidet PHP2Shelli nädalast näitavad, kui kergesti jääb lüli märkamata. Vercel juhib tähelepanu, et kohaliku arenduskeskkonna, rakenduse koodi või pistikprogrammide uuendusest ei piisa; otsustav on PHP käitusaeg, mis tegelikult sisu väljastab. Coolify soovitab iga rakenduse PHP käitusaja eraldi uuendada, ka Cloudflare'i taga. Ja aruannete kohaselt ei plaani WordPress.org PHP2Shelli vastu oma uuendust, sest turvaauk asub interpretaatoris. Kes ootab CMS-i, ootab asjata.
Ahela nähtavaks tegemine: viis sammu
Nii toote oma veebisaitide sõltuvustesse korra:
- Kirjutada ahel iga veebisaidi kohta üles: PHP käitusajast kuni väliste skriptideni, koos pakkuja või isiku nimega.
- Määrata iga lüli vastutaja: Kes paigaldab uuendused, kes kontrollib, kes keda teavitab?
- Kokku leppida tõendid: Mis loetakse tehtuks? PHP käitusaja puhul näiteks paketi seis ja taaskäivitus, nagu kirjeldatud artiklis Nii küsite oma veebimajutajalt paigaseisu kohta.
- Piirata ligipääse: Iga agentuur ja teenusepakkuja saab ainult õigused, mida vajab, isiklike kontodega.
- Planeerida alternatiivid: Mida teha, kui lüli kukub ära, näiteks pistikprogrammi pakkuja loobub või teenusepakkujat ei saa kätte?
Küsige igalt teenusepakkujalt, kuidas ta teid kriitilistest turvaaukudest teavitab. Kes vastab ainult järelepärimise peale, on PHP2Shelli-sarnases olukorras risk teie ajakavale. Fikseerige vastus kirjalikult.
Pistikprogrammid ja laiendused: kõige ülevaatamatum koht
Paljudel veebisaitidel on suurem osa tarneahelast nähtamatu: pistikprogrammid ja teemad, mis on aastate jooksul lisandunud. Igaüks pärineb teiselt pakkujalt, omaenda tempoga turvauuenduste juures. Mõned pakkujad loobuvad oma tootest teatamata. Teisi laiendusi hangitakse mitteametlikest allikatest ja need ei saa kunagi uuendusi.
Siin aitab lihtne reegel: iga pistikprogramm vajab otstarvet, hooldatud pakkujat ja ametlikku hankeallikat. Kui üks neist puudub, läheb see asendamise nimekirja. Sarnane kehtib integreeritud teenuste kohta, nagu makseteenuse pakkujad, broneerimissüsteemid, vestlusaknad või analüüsivahendid. Need toovad teie lehele oma koodi või saavad teie külastajate andmeid. Fikseerige, millised teenused on integreeritud, kes need tellis ja kas neid veel vaja on. Unustatud skript pakkujalt, kellega pole ammu enam lepingut, on lüli ilma vastutajata.
Kuidas hoida pistikprogramme ja pakette püsivalt ajakohasena, kirjeldab artikkel Sõltuvuste ajakohasena hoidmine: Composer, npm ja pistikprogrammid.
Tarneahel, lepingud ja NIS2
NIS2 alla kuuluvatele ettevõtetele kuulub tarneahela turvalisus sõnaselgelt riskijuhtimise juurde, seega ka suhted teenusepakkujate ja pakkujatega. Üksikasjad leiate lehelt NIS2 ja veebiserveri turvalisus. Kuid ka ilma seadusjärgse kohustuseta kehtib: välja antud ülesanded jäävad teie riskiks. Seetõttu kuuluvad nende viie sammu tulemused lepingutesse agentuuri, veebimajutaja ja teenusepakkujatega; milliseid punkte seal tuleks reguleerida, kirjeldab artikkel IT-teenusepakkujate lepingud: turvakohustused selgelt reguleerida. See leht on üldine teave ja ei ole õigusnõustamine.
Kuidas PHP SOS konkreetselt aitab?
- Joonistame koos teiega üles iga veebisaidi tarneahela, PHP käitusajast kuni väliste skriptideni.
- Kontrollime pistikprogramme, teemasid ja pakette hoolduse seisu ja päritolu osas ning soovitame asendust, kus vaja.
- Lepime veebimajutaja ja agentuuriga kokku, kes millise lüli eest vastutab ja milliseid tõendeid tarnitakse.
- Kus lüli on täitmata, võtame selle püsivalt enda peale turvahoolduslepingu kaudu.
Kokkuvõte: Veebisaidi turvalisus on sama tugev kui selle tarneahela kõige aeglasem lüli. Kes tunneb ahelat ja seob iga lüli vastutava isiku ja tõendiga, teab hädaolukorras, kus paik parajasti on.
Korduma kippuvad küsimused
Mida tähendab tarneahel veebisaidi puhul?
Kõik osalised, kelle tööst sõltub teie veebisaidi turvalisus: PHP projekt, Linuxi distributsioon, veebimajutaja või platvormiteenus, CMS-i tootja, pistikprogrammide ja teemade pakkujad, agentuur ja integreeritud teenused, näiteks makseteenuse pakkujad või välised skriptid.
Kas vastutan mina, kui teenusepakkuja ei paika?
Vastutus oma veebisaidi ja seal olevate andmete eest jääb üldjuhul teile, ka siis, kui ülesanded on välja antud. Seetõttu peaksid vastutusalad olema lepinguga selged ja neid tuleks kontrollida. Õigusliku hinnangu jaoks on pädevad advokaat ja andmekaitsespetsialist.
Kas piisab, kui veebimajutaja uuendab PHP?
Veebimajutaja PHP käitusaja puhul jah, kui ta taaskäivitab ka kõik protsessid ja seda tõendab. Kui osa teie rakendusest töötab mujal, näiteks konteinerites, platvormiteenustes või teisel serveril, tuleb seal iga käitusaeg eraldi uuendada.
Kuidas tuvastan riskantsed pistikprogrammid?
Hoiatusmärgid on pikalt puuduvad uuendused, pakkuja ilma tuvastatava turvakontaktita, hankimine mitteametlikest allikatest ja funktsioonid, mida keegi enam ei kasuta. Selliseid pistikprogramme tuleks asendada või eemaldada.