Īsi: Managed Server gadījumā sniedzējs uzņemas daļu drošības, parasti operētājsistēmu, PHP pakotnes un standarta pakalpojumus. Lietojumprogramma, spraudņi, piekļuves un datu aizsardzības tiesiskā atbildība lielākoties paliek jums. Pēc PHP2Shell abus aspektus ir vērts noskaidrot rakstiski: ko sniedzējs ir izdarījis un kas vēl ir jūsu pusē?
Ko „managed“ nozīmē un ko nenozīmē
Šis jēdziens nav aizsargāts. Viens sniedzējs ar to varbūt saprot tikai operētājsistēmas atjauninājumu ieinstalēšanu, cits apkalpo arī tīmekļa serveri, PHP, datubāzi un rezerves kopijas. Daži tarifi ietver uzraudzību visu diennakti, citi tikai kontaktpersonu darba laikā.
Tieši tādā situācijā kā PHP2Shell kļūst redzams, cik precīzs ir pakalpojuma apraksts. Abas ievainojamības CVE-2026-109618 un CVE-2026-109619 atrodas pašā PHP. Vai jūsu sniedzējs PHP uztur kā savas platformas daļu vai arī PHP uzskatāms par „jūsu programmatūru“, rakstīts līgumā. Nepaļaujieties uz pieņēmumu, ka kāds jau par to rūpējas.
Managed Server drošība: tipiska uzdevumu sadale
Turpmākajā tabulā parādīts bieži sastopams sadalījums. Tā neaizstāj ieskatu jūsu līgumā, taču palīdz uzdot pareizos jautājumus.
| Joma | Parasti sniedzēja pusē | Parasti jūsu pusē |
|---|---|---|
| Aparatūra, tīkls, virtualizācija | jā | nē |
| Operētājsistēmas atjauninājumi | jā | nē |
| PHP pakotnes no platformas | bieži | ja instalētas pašu spēkiem |
| PHP-FPM un tīmekļa servera pārstartēšana | bieži | pašu pakalpojumiem |
| Servera mēroga PHP konfigurācija | bieži | īpašu vēlmju gadījumā |
| CMS, veikals, spraudņi, pašu kods | nē | jā |
| Lietojumprogrammas administratoru konti | nē | jā |
| Rezerves kopijas | bieži | atjaunošanas pārbaude |
| Datu aizsardzības pārkāpumu novērtēšana un ziņošana | nē | jā |
| Uzbrukumu uzraudzība | atkarībā no tarifa | atkarībā no tarifa |
Neskaidrie lauki ir patiesais risks. Kur jums būtu jāieraksta „atkarībā no tarifa“ vai „bieži“, regulējuma trūkst.
Kādus jautājumus jums tagad vajadzētu uzdot
Nosūtiet sniedzējam īsu, lietišķu vaicājumu. Lūdziet atbildi rakstveidā, lai to vēlāk varētu uzrādīt. Vaicājumā jābūt šiem punktiem:
- Kuras PHP versijas darbojas mūsu serverī un vai tās ir aizsargātas pret CVE-2026-109618 un CVE-2026-109619?
- Kopš kura laika tas ir spēkā un vai pēc tam ir pārstartēti visi PHP procesi un tīmekļa serveris?
- Vai labojums ir ieviests kā backports? Ja jā, kura pakotnes versija to apliecina?
- Vai bija norādes uz uzbrukumu mēģinājumiem vai aizdomīgiem procesiem mūsu serverī?
- Vai tīmekļa servera žurnāli tiek glabāti no 2026. gada 20. oktobra un kā mēs tos varam saņemt?
Pilnībā izstrādātu paraugu atradīsiet lapā Kā vaicāt hostinga sniedzējam par ielāpa stāvokli. Versijas numurs klientu izvēlnē nav pierādījums: backportu gadījumā tas bieži paliek nemainīts, piemēram, 8.2.34.
Pat ja sniedzējs ir ielāpojis PHP, jūsu lietojumprogramma tik un tā jāpārbauda. Ielāps nenoņem ļaunprātīgu programmatūru, kas tika ievadīta pirms atjauninājuma, un nepierāda, ka nekas nav noticis.
Kas paliek jūsu pusē
Jūsu daļa galvenokārt ir lietojumprogramma. Pārbaudiet CMS, veikala un spraudņu aktuālos stāvokļus, noņemiet vairs neizmantotos paplašinājumus un pārbaudiet administratoru sarakstu. Pievērsiet uzmanību jauniem failiem augšupielāžu mapēs, svešām novirzēm un neparastiem ieplānotiem uzdevumiem lietojumprogrammā.
Klāt nāk arī tiesiskā puse. Ja incidenta laikā personas dati nonāk svešās rokās, ziņošanas pienākums parasti ir jūsu uzņēmumam kā pārzinim, nevis sniedzējam. Tam kā datu apstrādātājam jūs jāinformē nekavējoties. Pamatprincipus izskaidro VDAR ziņošanas pienākums: 72 stundas. Tā ir vispārīga informācija, nevis juridiska konsultācija; konkrēto gadījumu novērtē datu aizsardzības speciālisti vai juristi.
Vēl viens punkts bieži tiek aizmirsts: programmatūra, ko jūs vai jūsu aģentūra paši instalējāt Managed Server, piemēram, papildu PHP versija no trešās puses avota, konteiners vai palīgprogramma, parasti nav sniedzēja uzturēšanas aptvērumā. Tāpēc vaicājiet arī, vai sniedzējam ir zināms, kas līdzās standarta komplektācijai darbojas. Un noskaidrojiet, kurš aizdomu gadījumā uzņemas izmeklēšanu. Daudzi sniedzēji platformu atjauno, bet neizmeklē, vai un kādi dati bija skarti. Tieši šāda atbilde jums tomēr vajadzīga, lai novērtētu iespējamos ziņošanas pienākumus.
Uzlabot līgumus nākotnei
Izmantojiet šo situāciju, lai uzdevumu sadali nostiprinātu rakstiski. Lietderīgi ir regulējumi par drošības atjauninājumiem, ieskaitot pārstartēšanu, par informēšanu kritisku ievainojamību gadījumā, par žurnālu glabāšanu un izsniegšanu un par atbalstu incidentu laikā. Vaicājiet arī, vai sniedzējs jūs aktīvi brīdina vai arī jums pašiem jāvaicā.
Alternatīva ir pašam savs serveris bez apkalpošanas, taču tā visu darbu pārceļ uz jums. Ko tas nozīmē, apraksta lapa Root servera un vServer aizsardzība pašu spēkiem.
Kā PHP SOS palīdz konkrēti?
- Mēs izlasām jūsu pakalpojuma aprakstu un sastādām uzdevumu matricu, kas padara redzamas nepilnības.
- Mēs formulējam tehniskos jautājumus jūsu sniedzējam un novērtējam tā atbildes.
- Mēs pārbaudām lietojumprogrammas daļu, kas ir jūsu pusē, vai tajā nav pēdu un novecojušu komponentu.
- To, ko sniedzējs neaptver, mēs pēc vēlēšanās uzņemamies ar drošības uzturēšanas līgumu vai papildinām ar drošības monitoringu.
Biežāk uzdotie jautājumi
Vai Managed Server gadījumā viss ir automātiski nodrošināts?
Nē. Managed nozīmē, ka sniedzējs uzņemas noteiktus, ar līgumu noteiktus uzdevumus, parasti operētājsistēmu un standarta pakalpojumus. Lietojumprogramma, spraudņi, piekļuves un pašu programmatūra bieži paliek jūsu pusē.
Kur norādīts, par ko atbild mans sniedzējs?
Pakalpojuma aprakstā un līguma noteikumos, bieži arī atsevišķā dokumentā par uzdevumu sadali. Ja tiek apstrādāti personas dati, klāt nāk datu apstrādes līgums. Ja drošības atjauninājumiem nav skaidra regulējuma, vaicājiet rakstiski.
Vai man Managed Server gadījumā tik un tā kaut kas jādara saistībā ar PHP2Shell?
Jā. Saņemiet apstiprinājumu, ka visas PHP versijas ir ielāpotas un procesi pārstartēti. Pārbaudiet arī savu lietojumprogrammu, vai tajā nav pēdu, un noskaidrojiet, vai pastāv ziņošanas pienākums.
Kurš ziņo par datu aizsardzības pārkāpumu, ja skarts bijis hostinga sniedzējs?
Uzraudzības iestādei ziņot parasti ir jāpārzinim, tātad jūsu uzņēmumam, nevis sniedzējam. Hostinga sniedzējam kā datu apstrādātājam jums jāpaziņo nekavējoties. Konkrēto gadījumu lieciet novērtēt savam datu aizsardzības speciālistam.