Безопасность сайта: свой сервер или SaaS-платформа

21 октября 2026 года в Нидерландах временно перестали работать государственные онлайн-сервисы, включая DigiD, систему входа в личные кабинеты. Причиной называют уязвимости PHP. Если такое случается с государственными системами, возникает вопрос: что происходит с сайтом небольшой компании, за которым никто не следит?

Что произошло в Нидерландах 21 октября 2026 года

Государственные сервисы Нидерландов, включая DigiD, были временно недоступны 21 октября 2026 года, а причиной называют уязвимости PHP. DigiD — общенациональная система, через которую жители страны входят в кабинеты государственных и других организаций.

Судя по опубликованным материалам, сайты отключали как меру предосторожности, а не из-за подтверждённых взломов. Подробный разбор инцидента с DigiD и уязвимостями PHP опубликовали в блоге веб-студии Мегагрупп, там же собраны ссылки на первоисточники.

PHP — язык программирования, на котором работает серверная часть сайта: он обрабатывает формы, обращается к базе данных и собирает страницы. На PHP построены WordPress, Drupal, Joomla и «1С-Битрикс». Разработчики PHP выпустили исправления в день отключения. Дальше всё зависело от того, кто и как быстро их установит.

Почему PHP и CMS так часто становятся точкой входа

PHP стоит на большинстве сайтов, поэтому любая найденная в нём дыра сразу даёт злоумышленникам огромный список целей. W3Techs оценивает долю PHP примерно в три четверти среди сайтов с известным серверным языком.

Атаки редко бывают персональными. Боты круглосуточно сканируют интернет и проверяют сайты на известные дыры в PHP, CMS (системе управления сайтом) и плагинах. Размер компании им безразличен. Типичный итог взлома сайта: рассылка спама, скрытые редиректы на мошеннические страницы, кража клиентской базы, майнинг на чужом сервере.

Самый частый сценарий — устаревшая версия PHP. У каждой ветки ограниченный срок жизни: два года активной поддержки и ещё два года только исправлений безопасности. Ветка 8.1 с начала 2026 года обновлений не получает, а у 8.2 поддержка заканчивается 31 декабря 2026 года. Версия 7.4 живёт без исправлений с 2022 года.

Вторая группа риска — плагины и темы сторонних авторов. Это чужой код с доступом к файлам и базе, а обновление плагинов откладывают из страха сломать вёрстку. Третья — брошенные сайты: разработчик ушёл, договор закончился, сайт продолжает работать.

Это похоже на роутер с прошивкой пятилетней давности или Windows без патчей (исправлений безопасности). Всё работает, пока не появится бот, знающий старую дыру. Обновление CMS при этом не закрывает проблему в самом PHP: можно держать WordPress свежим и работать на устаревшем окружении.

Свой сервер или VPS: полный контроль и полная ответственность

На своём сервере вы получаете свободу и отвечаете за всё, что на нём установлено. VPS (виртуальный выделенный сервер) — арендованная часть физической машины, где вы сами выбираете систему и настройки. Выбор «свой сервер или облако» по сути сводится к вопросу, кто занимается обслуживанием.

Плюсы понятны: любые версии ПО, любой код, любые расширения, перенос куда угодно. Минусы тоже: обновления ядра CMS, PHP и операционной системы, бэкапы (резервные копии) и мониторинг лежат на владельце или его подрядчике. Поддержка сайта становится отдельной работой, которую нужно кому-то поручить и оплачивать.

Типичная история: сайт сделал фрилансер, настроил VPS для сайта и пропал. Через два года никто не знает, где хранятся пароли и какая версия PHP стоит на сервере.

На обычном виртуальном хостинге проще: PHP там обычно обновляет провайдер, а CMS и плагины остаются на вас. В договоре на хостинг сайта для бизнеса стоит проверить, где проходит граница ответственности.

Как устроена SaaS-платформа и где у неё слабые места

SaaS (программа как услуга) — модель, при которой вы пользуетесь готовой платформой, а сервер, обновления и защиту обслуживает её разработчик. Выбирая SaaS-платформу для сайта, вы редактируете страницы и товары, а серверное окружение вас не касается.

К этому типу относятся конструкторы вроде Тильды, облачные CMS веб-студий и облачные версии коробочных систем, например «1С-Битрикс». Модель у них общая, различаются возможности и условия.

Плюсы: обновления идут без участия владельца, есть единый ответственный, сайт запускается быстро, резервное копирование обычно входит в тариф.

Минусы тоже есть:

• Зависимость от провайдера. Платформа может изменить тарифы или условия, и вы окажетесь в положении арендатора.
• Ограниченная кастомизация. Нестандартную логику сделать сложно или невозможно.
• Перенос сайта. Экспорт часто неполный, дизайн и структуру приходится собирать заново.
• Остаточные риски. Уязвимость может появиться и у платформы, а утёкший пароль владельца или сотрудника остаётся вашей зоной ответственности.

Сравнение: свой сервер и SaaS

Главное различие в том, кто отвечает за каждый пункт: на VPS почти всё лежит на вас, на SaaS большую часть берёт поставщик.

Кто ставит обновления. Свой сервер или VPS: владелец или подрядчик, и это касается ОС, PHP, CMS и плагинов. SaaS: поставщик платформы, он обновляет ядро и серверное окружение.

Кто делает бэкапы. Свой сервер или VPS: тот, кто их настроил, а без настройки копий нет. SaaS: обычно платформа, но условия нужно уточнить.

Кто отвечает за защиту. Свой сервер или VPS: владелец сервера, от настроек доступа до мониторинга. SaaS: поставщик отвечает за инфраструктуру, владелец за пароли и доступы сотрудников.

Гибкость. Свой сервер или VPS: максимальная, возможен любой код и любые расширения. SaaS: ограничена возможностями платформы.

Стоимость владения. Свой сервер или VPS: аренда недорогая, но добавляется оплата администрирования или ваше время. SaaS: регулярная подписка, администрирование уже включено, нестандартные доработки оплачиваются отдельно.

Сложность переезда. Свой сервер или VPS: ниже, потому что файлы и база у вас. SaaS: выше, потому что экспорт ограничен и часть работы придётся переделывать.

Чек-лист для владельца сайта

Проверка занимает один вечер, если знать, где смотреть. Вот что стоит сделать:

1. Выяснить версию PHP и CMS: в панели хостинга или у подрядчика.
2. Сверить версию PHP с официальной страницей php.net и узнать, получает ли она исправления безопасности.
3. Выяснить, кто отвечает за обновление CMS и плагинов, и зафиксировать это письменно.
4. Настроить резервное копирование сайта: копии хранить отдельно от сервера и хотя бы раз проверить восстановление.
5. Включить двухфакторную авторизацию в админке сайта и в кабинете хостинга.
6. Удалить неиспользуемые плагины и темы: даже отключённые, они остаются уязвимыми.
7. Отозвать доступы у бывших подрядчиков и завести отдельные учётные записи сотрудникам.
8. Если сайт заброшен, закрыть его или перевести в режим заглушки.

Вывод: у безопасности должен быть хозяин

Универсального ответа нет: на своём сервере вы получаете контроль и обязанность следить за обновлениями, на SaaS-платформе делегируете обслуживание и принимаете ограничения. Безопаснее не та модель, где «всё само обновляется», а та, где вы точно знаете, кто отвечает за обновления, бэкапы и доступы, и этот человек или команда существует и сегодня.