Зеленый замок возле адреса сайта давно стал настолько привычным, что его легко принять за знак безопасности вообще. SSL действительно нужен: он шифрует соединение между браузером посетителя и сервером. Но если на сайте установлен уязвимый плагин, пароль администратора состоит из шести символов, резервная копия хранится рядом с зараженными файлами, а соседний аккаунт на сервере плохо изолирован, один сертификат ничего из этого не исправит.
Поэтому защищенный виртуальный хостинг начинается далеко не с HTTPS. Хорошая площадка должна одновременно защищать сервер от внешних атак, разделять клиентов внутри общей системы, ограничивать последствия взлома одного аккаунта, фильтровать подозрительные запросы, помогать обнаруживать вредоносные файлы и давать возможность восстановить сайт, если защита все-таки не сработала.
Для виртуального хостинга это особенно важно. На одном физическом или виртуальном сервере могут находиться десятки и сотни сайтов разных владельцев. Вы не управляете операционной системой и не решаете, как настроен веб-сервер. Значительная часть безопасности оказывается в руках провайдера.
Это не делает shared-хостинг опасным по определению. Наоборот, для владельца обычного сайта он иногда безопаснее самостоятельно администрируемого VPS. Хороший хостер постоянно обновляет серверное ПО, следит за инфраструктурой, фильтрует атаки и устраняет проблемы, которыми владельцу собственного сервера пришлось бы заниматься самому.
Проблема в другом: два тарифа с одинаковыми 20 ГБ диска, PHP и бесплатным SSL могут очень сильно отличаться по уровню защиты. В таблице характеристик этого почти не видно.
Главная защита shared-хостинга находится между соседями
Представим обычный многоквартирный дом. Нас мало волнует, каким компьютером пользуется сосед. Но если его входная дверь открывает одновременно и нашу квартиру, конструкция дома явно плохая.
На виртуальном хостинге похожую задачу решает изоляция аккаунтов. Сайт одного клиента не должен иметь доступ к файлам, процессам и данным другого клиента только потому, что оба находятся на одном сервере.
Именно здесь часто используется CloudLinux с технологиями LVE и CageFS. LVE позволяет ограничивать ресурсы отдельных аккаунтов, а CageFS создает изолированное файловое окружение. Пользователь видит собственную часть файловой системы и не должен свободно просматривать содержимое соседних аккаунтов.
Для владельца сайта это важно сразу по двум причинам.
Первая — безопасность. Если злоумышленник получил доступ к одному сайту, хорошая изоляция затрудняет переход к файлам других клиентов на том же сервере.
Вторая — стабильность. Один плохо написанный скрипт или внезапно популярный сайт не должен бесконтрольно забрать весь процессор, память и дисковый ввод-вывод у остальных пользователей. Ограничения ресурсов позволяют локализовать такую нагрузку внутри конкретного аккаунта.
Поэтому сам факт наличия лимитов CPU и RAM на виртуальном хостинге не является недостатком. Наоборот, без таких ограничений сосед с неудачным импортом базы или бесконечным PHP-циклом мог бы замедлить весь сервер.
Важно другое: лимиты должны соответствовать тарифу и быть понятными. Если провайдер рекламирует мощный хостинг, но скрывает настолько жесткие ограничения процессора и числа процессов, что обычный WordPress регулярно упирается в них, проблема уже не в технологии, а в самом тарифе.
Почему зараженный сосед не должен заражать всех остальных
Сценарий страшилок про shared-хостинг обычно выглядит так: взломали один сайт, после чего злоумышленник получил доступ ко всему серверу. В хорошо настроенной современной среде это не должно происходить автоматически.
Изоляция аккаунтов как раз создается для того, чтобы успешная атака на один WordPress не превращалась в свободную прогулку по каталогам остальных клиентов.
Но абсолютной защиты не существует. Уязвимость в серверном программном обеспечении, ошибка конфигурации или серьезная проблема на уровне самой платформы способны изменить ситуацию. Поэтому важен не один конкретный инструмент, а несколько независимых уровней защиты.
Хороший хостинг не просто ставит CloudLinux и считает вопрос закрытым. Он обновляет операционную систему, веб-сервер, PHP и системные компоненты, ограничивает права пользователей, следит за подозрительной активностью и реагирует на обнаруженные уязвимости.
Пользователю проверить внутреннюю конфигурацию сервера сложно. Но перед покупкой можно хотя бы посмотреть, рассказывает ли провайдер о технологиях изоляции аккаунтов и ограничении ресурсов. Полное отсутствие информации по этому вопросу у крупного shared-хостинга выглядит страннее, чем наличие разумных лимитов.
SSL защищает дорогу к сайту, а не сам сайт
Бесплатный сертификат Let’s Encrypt сегодня должен восприниматься скорее как базовая функция, чем как отдельная система безопасности.
HTTPS шифрует данные между пользователем и сервером. Пароль от личного кабинета, данные формы или содержимое страницы нельзя так просто прочитать по дороге между браузером и сайтом.
Но SSL не проверяет безопасность установленного WordPress, не закрывает уязвимость в плагине, не удаляет вредоносный PHP-файл и не спасает пароль admin123.
Это примерно как бронированный автомобиль, который безопасно доставляет письмо к дому с открытой входной дверью. Транспорт защищен, но проблема находится в другом месте.
Поэтому хостинг, который описывает свою безопасность исключительно словами бесплатный SSL, фактически рассказывает только об одном обязательном элементе.
WAF, антивирус и DDoS-защита решают совершенно разные задачи
В описаниях тарифов защитные технологии часто складывают в один длинный набор: WAF, антивирус, анти-DDoS, защита от ботов, мониторинг. Для пользователя все это может звучать как несколько названий одной и той же функции. На самом деле они работают на разных участках.
WAF пытается остановить опасный запрос до приложения
Web Application Firewall анализирует HTTP-запросы к сайту и пытается распознать характерные признаки атак на веб-приложения.
Один из известных вариантов — ModSecurity, который может работать вместе с набором правил OWASP Core Rule Set. Такая система способна фильтровать множество типичных подозрительных запросов еще до того, как они попадут в PHP-приложение.
Это полезный дополнительный слой, особенно для популярных CMS, которые постоянно сканируют автоматические боты.
Но WAF нельзя считать заменой обновлениям. Если в плагине WordPress найдена критическая уязвимость, правильное решение — обновить или удалить этот плагин. Фильтр может остановить часть попыток эксплуатации, но строить безопасность вокруг надежды, что он поймает каждый вариант атаки, не стоит.
Более того, слишком агрессивные правила иногда блокируют нормальные запросы. Поэтому качество WAF зависит не только от его наличия, но и от настройки.
Пользователю необязательно разбираться в наборах правил. Достаточно понимать принцип: хорошая защита фильтрует подозрительный трафик, но не освобождает владельца сайта от обновления CMS.
Антивирус ищет проблему уже в файлах
Сканирование файлов решает другую задачу. Оно ищет вредоносный код, web-shell, подозрительные изменения и известные сигнатуры заражений внутри аккаунта.
Это особенно полезно для WordPress, Joomla и других CMS с большим количеством сторонних расширений. Сайт может быть заражен через старый плагин, украденный пароль FTP или скомпрометированную учетную запись администратора.
Хорошо, если хостинг не просто умеет запускать сканирование вручную, а регулярно проверяет файлы автоматически и уведомляет владельца об обнаруженной проблеме.
Еще лучше, если пользователь может увидеть конкретный зараженный файл, дату обнаружения и предпринятое действие, а не просто сообщение о том, что сайт заблокирован за вредоносный код.
Автоматическое удаление тоже не всегда идеально. Защитная система может поместить файл в карантин, но если источник заражения остался, вредоносный код вернется. Нужно найти причину: уязвимый плагин, украденный пароль, старую CMS или оставленный разработчиком скрипт.
Поэтому антивирус на хостинге полезен прежде всего как система раннего обнаружения, а не волшебная кнопка лечения сайта.
DDoS находится еще дальше от WordPress
DDoS-атака может вообще не иметь отношения к уязвимостям сайта. Цель злоумышленника — создать такой объем запросов или сетевого трафика, чтобы ресурс перестал отвечать нормальным посетителям.
Бороться с большой сетевой атакой внутри самого аккаунта на виртуальном хостинге бессмысленно. Трафик желательно фильтровать раньше, на инфраструктуре провайдера или специализированной защитной сети.
Поэтому наличие базовой DDoS-защиты у хостера является хорошим признаком. Но фраза защита от DDoS без подробностей мало что говорит.
Небольшой корпоративный сайт и крупный игровой сервис сталкиваются с совершенно разным масштабом угроз. Базовой автоматической фильтрации может хватить первому, но быть недостаточно второму.
Перед покупкой дорогого защищенного тарифа стоит выяснить, что именно включено в стоимость. Важно понять, фильтруются ли сетевые атаки автоматически, существуют ли ограничения по объему, может ли сайт быть временно отключен во время сильной атаки и нужна ли дополнительная услуга для расширенной защиты.
Обычному блогу максимальный анти-DDoS может никогда не понадобиться. Интернет-магазину, СМИ, публичному сервису или проекту, который уже атаковали, этот пункт становится значительно важнее.
Самая недооцененная защита начинается после успешного взлома
Звучит парадоксально, но безопасный хостинг нужно оценивать не только по тому, насколько хорошо он предотвращает проблему. Не менее важно, что произойдет, если сайт все-таки сломали, удалили или испортили.
Именно здесь резервные копии часто оказываются полезнее еще одного красивого значка безопасности в тарифе.
Представим, что злоумышленник получил административный доступ к WordPress и изменил сотни файлов. Антивирус обнаружил заражение только через несколько часов. Удалять вредоносный код вручную долго и ненадежно.
Если существует чистая резервная копия вчерашнего состояния, восстановление может занять несколько минут.
Но наличие слова backup в характеристиках еще недостаточно.
Хороший backup должен позволять вернуться назад
Полезно заранее выяснить, как часто создаются копии и сколько версий сохраняется.
Если хостинг ежедневно переписывает единственную резервную копию, заражение может попасть в нее раньше, чем владелец заметит проблему. Несколько точек восстановления намного полезнее одной.
Важно и то, что именно копируется. Файлы без базы данных не восстановят полноценный интернет-магазин. База без загруженных пользователями изображений тоже может оказаться недостаточной.
Хорошо, если пользователь может самостоятельно восстановить файлы, базу или весь аккаунт из панели управления без ожидания поддержки.
Для особенно важного проекта я бы все равно не полагалась исключительно на копию провайдера. Периодический независимый backup в другом хранилище защищает от ситуации, когда проблема затрагивает сам аккаунт или инфраструктуру хостинга.
Главное правило простое: если данные существуют только в одном месте, резервной копии у вас фактически нет.
Защищать нужно и панель управления
Можно построить прекрасную серверную безопасность и потерять сайт из-за украденного пароля от личного кабинета хостера.
Через панель управления злоумышленник иногда получает гораздо больше возможностей, чем через сам WordPress. Он может изменить DNS, скачать резервные копии, создать новый FTP-доступ, удалить сайт или получить доступ к базам.
Поэтому двухфакторная аутентификация для аккаунта хостинга является очень полезной функцией. Даже если пароль стал известен постороннему, одного его недостаточно для входа.
Это особенно важно, если один аккаунт используется для нескольких сайтов или принадлежащих компании доменов.
Разумеется, 2FA имеет смысл только вместе с нормальным уникальным паролем. Использовать один пароль одновременно для почты, WordPress и панели хостинга — отличный способ превратить одну утечку в несколько проблем сразу.
FTP лучше оставить в прошлом там, где можно использовать SFTP
Классический FTP передает учетные данные без такого уровня защиты, который сегодня хочется видеть при работе с важным сайтом. Если провайдер предлагает SFTP или другой защищенный способ передачи файлов, лучше использовать его.
SFTP работает поверх SSH и шифрует соединение. Для пользователя процесс почти не усложняется: большинство современных файловых клиентов поддерживают его напрямую.
Также полезно создавать отдельные учетные записи разработчикам и подрядчикам вместо передачи главного пароля от хостинга. После завершения работы такой доступ можно просто удалить.
Еще лучше, если права можно ограничить конкретным каталогом или сайтом.
Почта может стать входной дверью ко всему аккаунту
Защита хостинга иногда заканчивается там, где начинается электронная почта. Пароль можно сбросить через email, поэтому взлом основной почты владельца способен открыть дорогу к панели управления, CMS и другим сервисам.
Учетная запись, на которую зарегистрирован хостинг, должна быть защищена не хуже самого сайта. Уникальный пароль и двухфакторная аутентификация здесь так же важны.
Для бизнеса разумно следить и за тем, кому принадлежит административная почта. Если хостинг зарегистрировал бывший сотрудник на личный адрес, проблема безопасности возникает еще до любой технической атаки.
Как выбрать защищенный виртуальный хостинг без паранойи и переплаты
После перечисления всех угроз легко решить, что обычному сайту требуется банковский дата-центр, круглосуточный SOC и отдельная команда специалистов. Это не так.
Для корпоративного сайта, блога или небольшого интернет-магазина хороший виртуальный хостинг уже способен закрыть значительную часть инфраструктурной безопасности без участия владельца.
Я бы смотрела не на количество слов со словом защита в тарифе, а на конкретные механизмы.
У аккаунтов должна быть нормальная изоляция. Один клиент не должен свободно видеть файлы другого, а чрезмерная нагрузка соседнего сайта не должна положить весь сервер.
Должны регулярно обновляться серверные компоненты. Пользователь shared-хостинга не управляет операционной системой, поэтому это обязанность провайдера.
Нужен HTTPS с нормальным автоматическим выпуском и продлением сертификатов.
Полезен WAF или другой механизм фильтрации типовых веб-атак.
Желательно автоматическое сканирование файлов на вредоносный код.
Должна существовать понятная защита инфраструктуры от DDoS хотя бы на базовом уровне.
Нужны регулярные резервные копии с несколькими точками восстановления.
Хорошо, если панель поддерживает двухфакторную аутентификацию, а для передачи файлов доступны защищенные протоколы.
Но даже идеальный хостинг не защитит сайт, который владелец годами не обновляет.
Большая часть массовых атак на CMS автоматизирована. Боты не выбирают конкретную компанию из списка и не тратят неделю на сложный взлом. Они сканируют тысячи сайтов в поисках известных уязвимостей, слабых паролей и давно забытых расширений.
Поэтому свежая версия CMS и плагинов может дать больше реальной безопасности, чем самый громкий защищенный тариф.
Особенно опасны заброшенные расширения. Плагин может продолжать работать несколько лет, но если разработчик перестал выпускать обновления, обнаруженная позже уязвимость останется открытой.
Полезно периодически удалять все, чем сайт больше не пользуется. Не просто выключать плагин, а удалять его файлы, если он точно не нужен.
То же касается тестовых копий сайтов. Старый WordPress в каталоге old-site, забытый несколько лет назад, остается доступным из интернета и может стать такой же точкой входа, как основной проект.
Когда обычного защищенного хостинга уже мало
Shared-хостинг хорошо подходит большинству сайтов, но у его модели есть естественные пределы.
Если проекту нужны собственные правила firewall, необычная серверная конфигурация, отдельная частная сеть, специальные системы обнаружения атак или полный контроль над окружением, виртуальный хостинг становится тесным.
Тогда можно переходить на VPS, но важно понимать обратную сторону свободы. Собственный сервер не становится безопаснее автоматически.
На shared-хостинге обновлением системных пакетов, настройкой веб-сервера и общей защитой занимается провайдер. На unmanaged VPS большая часть этой работы переходит к клиенту.
Неправильно настроенный VPS с открытыми портами, входом root по слабому паролю и годами не установленными обновлениями может быть значительно опаснее хорошего виртуального хостинга.
Поэтому переходить на собственный сервер ради безопасности имеет смысл только тогда, когда есть человек, который действительно будет этой безопасностью заниматься.
Для интернет-магазина резервное копирование важнее красивого значка Secure
Коммерческий сайт стоит оценивать не только по вероятности атаки, но и по цене последствий.
Если небольшой блог недоступен два часа, это неприятно. Если магазин в этот момент принимает десятки заказов, проблема уже измеряется деньгами.
Поэтому интернет-магазину особенно важны несколько вещей одновременно: стабильная изоляция ресурсов, автоматический backup, фильтрация атак, быстрое восстановление и техническая поддержка, которая отвечает не через сутки.
Стоит проверить, можно ли восстановить только базу данных. Для магазина это особенно полезно, потому что именно там находятся заказы, клиенты, остатки и изменения каталога.
Полезно узнать и время хранения копий. Если заражение обнаружилось через неделю, а хостер хранит backups только три дня, чистой версии может уже не остаться.
Чем важнее сайт для бизнеса, тем меньше смысла выбирать хостинг только по минимальной цене.
Защищенный хостинг не должен мешать нормальному сайту работать
Есть и другая крайность. Провайдер может настолько агрессивно ограничивать процессы, блокировать запросы и запрещать функции PHP, что сайт постоянно сталкивается с ложными срабатываниями.
Безопасность не должна превращаться в невозможность обновить WordPress, принять нормальный запрос API или загрузить резервную копию.
Поэтому лучший вариант — не максимальное количество запретов, а нормально настроенная многоуровневая система.
Изоляция отвечает за соседей. LVE или аналогичные механизмы контролируют ресурсы. WAF отсеивает часть вредоносных запросов. Антивирус ищет подозрительные файлы. DDoS-фильтрация работает с сетевыми атаками. Backup позволяет восстановиться после проблемы. 2FA защищает административный вход.
Ни один из этих элементов не является абсолютной защитой. Вместе они делают успешную атаку сложнее, а ее последствия значительно менее болезненными.
И именно это я бы считала настоящим защищенным виртуальным хостингом.
Не тарифом, на котором рядом со словом SSL нарисован щит. Не обещанием стопроцентной безопасности, которой в интернете не существует. И не самым дорогим пакетом с десятком непонятных функций.
Хороший защищенный хостинг просто не ставит судьбу сайта в зависимость от одного барьера. Если пароль украли, помогает 2FA. Если вредоносный запрос дошел до сервера, его может остановить WAF. Если уязвимость все-таки сработала, изоляция ограничивает последствия. Если файлы заражены, сканер помогает обнаружить проблему. Если сайт испорчен окончательно, остается резервная копия.
А владелец со своей стороны обновляет CMS, использует уникальные пароли, удаляет ненужные плагины и не раздает административный доступ всем подряд.
В такой связке виртуальный хостинг действительно может быть безопасной площадкой даже для коммерческого сайта. Причем владельцу не приходится самостоятельно превращаться в системного администратора и специалиста по информационной безопасности.
Поэтому при выборе защищенного виртуального хостинга я бы задавала провайдеру не вопрос есть ли у вас SSL. Он должен быть практически везде. Гораздо полезнее узнать, как изолированы аккаунты, как защищается веб-трафик, проверяются ли файлы, сколько хранятся резервные копии, есть ли 2FA и что произойдет с сайтом во время атаки.
Ответы на эти вопросы расскажут о реальной безопасности намного больше любого изображения замка на странице тарифов.
