Накратко: При управляван сървър доставчикът поема част от сигурността, обикновено операционната система, PHP пакетите и стандартните услуги. Приложението, добавките, достъпите и отговорността по защита на данните най-често остават при Вас. След PHP2Shell изяснете и двете неща писмено: какво е направил доставчикът и какво още остава при Вас?
Какво означава „управляван“ и какво не
Терминът не е защитен. Един доставчик разбира под него може би само внасянето на актуализации на операционната система, друг поддържа и уеб сървъра, PHP, базата данни и резервните копия. Някои тарифи включват денонощно наблюдение, други само контактно лице в работно време.
Именно при ситуация като PHP2Shell се вижда колко точно е описанието на услугата. Двете уязвимости CVE-2026-109618 и CVE-2026-109619 са в самия PHP. Дали Вашият доставчик поддържа PHP като част от своята платформа, или PHP се счита за „Ваш софтуер“, пише в договора. Не разчитайте на предположението, че някой със сигурност се грижи.
Сигурност на управляван сървър: типично разпределение на задачите
Следващата таблица показва често срещано разпределение. Тя не замества прегледа на Вашия договор, но помага да зададете правилните въпроси.
| Област | Най-често при доставчика | Най-често при Вас |
|---|---|---|
| Хардуер, мрежа, виртуализация | да | не |
| Актуализации на операционната система | да | не |
| PHP пакети от платформата | често | ако са инсталирани от Вас |
| Рестартиране на PHP-FPM и уеб сървъра | често | при собствени услуги |
| PHP конфигурация за целия сървър | често | при специални желания |
| CMS, магазин, добавки, собствен код | не | да |
| Администраторски акаунти на приложението | не | да |
| Резервни копия | често | проверка на възстановяването |
| Оценка и уведомяване за нарушения на сигурността на данните | не | да |
| Наблюдение за атаки | според тарифата | според тарифата |
Неясните полета са същинският риск. Където бихте трябвали да впишете „според тарифата“ или „често“, липсва уредба.
Кои въпроси да зададете сега
Изпратете на доставчика кратко, делово запитване. Помолете за отговор в писмен вид, за да можете да го представите по-късно. Тези точки трябва да бъдат включени:
- Кои версии на PHP работят на нашия сървър и защитени ли са срещу CVE-2026-109618 и CVE-2026-109619?
- От кога е така и рестартирани ли са след това всички PHP процеси и уеб сървърът?
- Корекцията внесена ли е като бекпорт? Ако да, коя версия на пакета го доказва?
- Имало ли е данни за опити за атака или подозрителни процеси на нашия сървър?
- Запазват ли се логовете на уеб сървъра от 20.10.2026 г. нататък и как можем да ги получим?
Готов образец има в Попитайте хостинг доставчика за състоянието на пача. Номерът на версията в менюто за клиенти не е доказателство: при бекпортове той често остава непроменен, например 8.2.34.
Дори доставчикът да е пачнал PHP, приложението Ви остава за проверка. Пачът не премахва зловреден софтуер, внесен преди актуализацията, и не доказва, че нищо не се е случило.
Какво остава при Вас
Вашата част обхваща преди всичко приложението. Проверете CMS, магазина и добавките за актуално състояние, премахнете вече неизползваните разширения и прегледайте списъка с администратори. Обърнете внимание на нови файлове в папките за качване, чужди пренасочвания и необичайни планирани задачи в приложението.
Към това се добавя правната страна. Ако при инцидент лични данни попаднат в чужди ръце, по правило Вашата фирма като администратор е длъжна да уведоми, а не доставчикът. Той трябва да Ви информира като обработващ данни без забавяне. Основните положения обяснява Задължение за уведомяване по ОРЗД: 72 часа. Това е обща информация, не представлява правен съвет; конкретния случай оценяват длъжностните лица по защита на данните или адвокатите.
Една друга точка често се пропуска: софтуерът, който Вие или Вашата агенция сте инсталирали сами на управлявания сървър, например допълнителна версия на PHP от външен източник, контейнер или помощна програма, най-често не попада в поддръжката на доставчика. Затова попитайте и дали доставчикът знае какво работи освен стандартното оборудване. И изяснете кой поема разследването при подозрение. Много доставчици възстановяват платформата, но не проверяват дали и какви данни са били засегнати. Именно този отговор Ви трябва обаче за оценката на възможни задължения за уведомяване.
Подобрете договорите за в бъдеще
Използвайте ситуацията, за да фиксирате разпределението на задачите. Смисъл имат уредби за актуализациите за сигурност, включително рестарт, за информирането при критични уязвимости, за съхранението и предоставянето на логове и за подкрепата при инциденти. Попитайте и дали доставчикът Ви уведомява активно, или трябва сами да питате.
Собственият сървър без обслужване е алтернативата, но премества цялата работа към Вас. Какво означава това, описва Как сами да обезопасите root сървър и vServer.
Как помага PHP SOS конкретно?
- Четем описанието на Вашата услуга и съставяме матрица на задачите, която прави пропуските видими.
- Формулираме техническите въпроси към Вашия доставчик и оценяваме отговорите му.
- Проверяваме частта на приложението, която е при Вас, за следи и остарели компоненти.
- Каквото доставчикът не покрива, поемаме при желание чрез договор за поддръжка на сигурността или допълваме със следене на сигурността.
Често задавани въпроси
Автоматично ли е всичко защитено при управляван сървър?
Не. Управляван означава, че доставчикът поема определени, договорно уговорени задачи, най-често операционната система и стандартните услуги. Приложението, добавките, достъпите и собственият софтуер често остават при Вас.
Къде пише за какво отговаря моят доставчик?
В описанието на услугата и в условията на договора, често и в документ за разпределението на задачите. При лични данни към тях се добавя договорът за обработване на данни. Ако няма ясна уредба за актуализациите за сигурност, попитайте писмено.
Трябва ли въпреки управляван сървър сам да направя нещо във връзка с PHP2Shell?
Да. Получете потвърждение, че всички версии на PHP са пачнати, а процесите са рестартирани. Освен това проверете приложението си за следи и изяснете дали съществува задължение за уведомяване.
Кой уведомява за нарушение на сигурността на данните, ако доставчикът е бил засегнат?
Задължен да уведоми надзорния орган е по правило администраторът, т.е. Вашата фирма. Доставчикът като обработващ данни трябва да Ви информира без забавяне. Поискайте от длъжностното лице по защита на данните да оцени конкретния случай.