Trumpai: White-label IT sauga jūsų agentūrai reiškia: jūs išlaikote santykį su klientu, o mes fone atliekame saugumo darbus. Esant PHP2Shell tai reiškia visų klientų svetainių inventorių, prioritetizavimą pagal riziką, pataisą ir paleidimą iš naujo kiekviename serveryje bei kiekvieno kliento įrodymą, kurį galite perduoti.
Kodėl agentūros esant PHP2Shell patiria ypatingą spaudimą
Agentūra su daug klientų retai prižiūri vienodą aplinką. Dalis svetainių yra nuosavuose serveriuose su Plesk, dalis pas klientų hostingo teikėjus, kai kurie seni projektai veikia su PHP versijomis, kurios seniai oficialių atnaujinimų nebegauna. Prisideda skirtingos sistemos: WordPress, TYPO3, Shopware, Craft CMS, Laravel nuosavi sprendimai.
Esant spragai pačiame PHP, paliečiami visi projektai vienu metu. Klientai tikisi atsakymo, ar jų svetainė saugi, o projekto komanda užimta vykstančiais užsakymais. Daug priežiūros sutarčių reglamentuoja CMS, bet ne serverį po juo.
Prisideda sistemos, kurios nebepasirodo jokiame projektų sąraše: staging aplinkos subdomenuose, baigtų projektų kampanijų puslapiai, kūrėjų bandomieji diegimai savuose vServer. Jos dažnai veikia su senesnėmis PHP versijomis, nėra stebimos, bet vis tiek nešioja jūsų agentūros ar kliento vardą. Automatizuotiems skenavimams jos matomos lygiai taip pat kaip pagrindinė svetainė.
Kokius klausimus jūsų klientai dabar kelia
- Ar mano svetainė paveikta ir ar ji jau pataisyta?
- Ar prieš pataisą jau kas nors buvo įterpta?
- Ar CMS atnaujinimas laikomas apsauga? Ne, CMS atnaujinimas PHP spragos neuždaro.
- Ar turiu atjungti svetainę nuo tinklo? BSI (Vokietijos federalinė informacijos saugumo tarnyba) to rekomenduoja serveriams, kurių negalima iš karto atnaujinti.
Į kiekvieną iš šių klausimų jūsų agentūrai reikia įrodomo atsakymo kiekvienam klientui, o ne bendro laiško su bendrais teiginiais.
Kaip vyksta white-label IT sauga agentūroms
Dirbame kaip jūsų komandos dalis, bet be savo kontakto su klientais. Pasiskirstymas aiškus:
| Užduotis | Jūsų agentūra | PHP SOS |
|---|---|---|
| Komunikacija su klientais ir atsiskaitymas | taip | ne |
| Visų klientų svetainių inventorius su PHP būsena | pateikia prieigas | sudaro ir prižiūri |
| Pataisa, paleidimas iš naujo, patikra kiekviename serveryje | patvirtina priežiūros langą | atlieka arba koordinuoja su hostingo teikėjais |
| Pažeidimo patikra | gauna išvadą | ieško webshell ir anomalijų |
| Įrodymas kiekvienam klientui | perduoda | parengia neutraliai arba jūsų formatu |
Svetainėms pas svetimus hostingo teikėjus gauname paketo būsenos patvirtinimą. Vien rodomo versijos numerio nepakanka, nes backport gali palikti jį nepakeistą.
Pirmiausia teikite pirmenybę serveriams su Apache ir mod_php, kur PHP komanda riziką vertina didžiausią, paskui parduotuvėms ir svetainėms su prisijungimais, paskui projektams su PHP 8.1 ar senesne versija. Statinius senus projektus, kurių niekam nebereikia, geriau išjunkite, užuot juos pataisę.
Kelios klientų svetainės viename serveryje: patikrinti izoliaciją
Agentūrų serveriuose daug klientų svetainių dažnai dalijasi viena mašina. Jei viena iš jų pažeidžiama, atskyrimas lemia, ar užpuolikas prieis ir prie kitų. Svarbūs atskiri sistemos naudotojai ir PHP-FPM baseinai kiekvienai svetainei, tvarkingos failų teisės ir ribos, tokios kaip open_basedir. Plesk serveriuose šiuos nustatymus galima patikrinti kiekvienai prenumeratai.
Po pataisos galioja: paleisti iš naujo visus baseinus ir darbinius procesus (worker). Tik tada atmintyje nebeveikia seni PHP procesai. Žurnalus nuo 2026-10-20 reikėtų išsaugoti kiekvienai klientų svetainei.
Klientų informavimas: kas įrodyta, o kas ne
Didžiausias šios padėties gundymas yra raminantis bendras laiškas. Saugesnis yra pareiškimas kiekvienam klientui, kuriame yra tik tai, kas įrodyta: koks serveris, koks PHP paketo būsena, kada paleista iš naujo, ar buvo atlikta pažeidimo patikra ir kokiu rezultatu. Kas dar atvira, taip pat nurodoma.
Tokių formuluočių kaip „Jūsų svetainė saugi“ geriau vengti. Pataisa uždaro spragą, bet neįrodo, kad anksčiau nieko neįvyko. Kas tai sąžiningai atskiria, vėliau neturės aiškintis, jei vis dėlto atsiras radinys.
Priežiūros sutartis po PHP2Shell sudaryti iš naujo
Daug agentūrų sutarčių reglamentuoja CMS ir plėtinių atnaujinimus, bet apie serverį tyli. Pasinaudokite padėtimi ir kiekvienam klientui užfiksuokite, kas atnaujina PHP, kas atsako už paleidimus iš naujo, kas sprendžia incidento atveju ir kokios paslaugos užsakomos atskirai. Prie to priklauso ir duomenų tvarkymo susitarimas su visais dalyvaujančiais paslaugų teikėjais. Sutartinį sureguliavimą išsiaiškinkite su savo teisine konsultacija.
Kaip konkrečiai padeda PHP SOS?
- Perimame visų klientų svetainių inventorizaciją su PHP versija, veikimo režimu, hostingo teikėju ir atsakomybe.
- Per savo PHP pataisų paslaugą pataisome jūsų pačių serverius, paleidžiame iš naujo visus darbinius procesus (worker) ir tai įrodome kiekvienam klientui.
- Tikriname prioritetines svetaines dėl pažeidimo ir radinio atveju išvalome, kol incidentas bus užbaigtas ir dokumentuotas.
- Pateikiame tekstų blokus jūsų klientų informavimui, kuriuos galite pritaikyti ir patys išsiųsti.
- Po to pageidaujant su saugumo priežiūros sutartimi perimame nuolatinę saugumo priežiūrą fone.
Dažni klausimai
Ar kreipiatės tiesiogiai į mūsų klientus?
Tik jei to norite. White-label modelyje dirbame tik fone, o visa komunikacija eina per jūsų agentūrą. Savo dokumentaciją pateikiame neutralią arba jūsų formatu.
Ar tam reikia duomenų tvarkymo sutarties?
Jei prieiname prie sistemų su jūsų klientų asmens duomenimis, paprastai reikia duomenų tvarkymo susitarimo, dažnai kaip pavaldaus duomenų tvarkytojo susitarimo. Kaip tai dera su jūsų esamomis sutartimis, išsiaiškinkite su teisine konsultacija. Reikiamą informaciją apie savo veiklą pateikiame.
O klientų svetainės, kurių serverių mes nevaldome?
Jei klientų svetainės yra pas svetimus hostingo teikėjus, jūsų vardu arba pagal jūsų šablonus gauname patvirtinimus apie pataisų būseną ir paleidimą iš naujo. Kur yra tik FTP ar CMS prieiga, tikriname, ką iš ten galima padaryti, ir atvirai pažymime, ką gali įrodyti tik hostingo teikėjas.
Ar galime tai ilgam išorsinti ir po PHP2Shell?
Taip. Daug užduočių kartojasi su kiekviena spraga: prižiūrėti inventorių, diegti pataisas, įrodyti paleidimus iš naujo, pranešti apie anomalijas. Šį darbą galima organizuoti kaip nuolatinę priežiūrą fone.