Что защищать на VPS: составляем понятный план безопасности

Без плана безопасность VPS быстро превращается в случайный набор действий: сменить порт SSH, поставить несколько программ, запретить что-нибудь в сетевом фильтре. Эти меры могут быть полезны, но они не спасут от удаления единственной копии данных или захвата почты, через которую восстанавливается доступ к хостеру.

План безопасности начинается не с названия угрозы, а с простого вопроса: что случится с проектом, если завтра пропадёт сервер, домен, пароль владельца или содержимое сайта? Ответ показывает, какую проблему нужно закрыть первой.

Перечислите то, что нельзя потерять

В информационной безопасности ценные данные и возможности называют активами. Термин удобен, но за ним стоят обычные вещи:

• исходники и история сайта;
• пользовательские загрузки и база данных;
• право управлять доменом и DNS;
• доступ к панели хостера;
• SSH-ключи администраторов;
• пароли и токены внешних сервисов;
• конфигурация Nginx и серверных приложений;
• резервная копия и инструкция восстановления.

Для каждого пункта отметьте, что именно недопустимо. Страницы сайта нельзя незаметно подменить, базу пользователей нельзя раскрыть, домен нельзя передать постороннему, а резервная копия должна оставаться доступной после потери VPS.

Не забывайте об учётных записях, через которые восстанавливаются остальные. Если почта владельца позволяет сбросить пароль хостера и регистратора домена, её защита важнее многих настроек внутри Linux.

Отделите восстанавливаемое от уникального

Ubuntu и Nginx можно установить заново. Статический сайт можно снова собрать, если исходники, зависимости и инструкция сохранились. Эти части требуют времени, но они воспроизводимы.

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

Для каждого важного пункта запишите источник восстановления. Например: исходники находятся в GitHub, DNS управляется в кабинете регистратора, конфигурация Nginx входит в локальный архив, резервные коды второго фактора лежат отдельно от компьютера администратора.

Если ответ звучит как «наверное, это есть на сервере», восстановление ещё не подготовлено.

Найдите все способы управлять системой

Сайт зависит не только от VPS. Нарисуйте или перечислите места, где человек или программа может изменить работу проекта:

• SSH-вход на сервер;
• консоль и кнопки в панели хостера;
• управление доменом и DNS;
• GitHub и процесс публикации;
• административная панель сайта;
• загрузка файлов посетителями;
• токены внешних API;
• обращения в поддержку, где личность подтверждается по почте или данным владельца.

Для каждого способа спросите: кто им пользуется, как подтверждается доступ, можно ли выдать более узкие права и что останется в журнале после действия.

Публичный сайт на портах 80 и 443 должен принимать запросы от любого посетителя. SSH, база данных и административные интерфейсы не обязаны быть так же открыты. Разные назначения требуют разных правил, а не общего запрета всего сетевого трафика.

Описывайте путь к ущербу, а не слово «взлом»

Фраза «VPS могут взломать» не подсказывает действие. Полезный сценарий показывает начало, путь и последствие. Например:

• закрытый SSH-ключ скопирован с ноутбука, после чего посторонний входит на VPS и меняет файлы сайта;
• уязвимый плагин WordPress получает право записи во весь каталог и внедряет код в другие файлы;
• администратор включает ошибочное правило UFW, теряет SSH, а консоль провайдера заранее не проверена;
• токен попадает в публичный репозиторий и используется для обращения к платному API;
• злоумышленник получает доступ к почте владельца и меняет DNS домена;
• VPS удалён, а единственный архив находился на его же диске.

Каждый сценарий ведёт к своему набору мер. Украденный SSH-ключ требует отдельных ключей, парольной фразы, быстрого отзыва и проверки входов. Потеря диска требует копии вне VPS и теста восстановления. Смена порта SSH не решает ни одну из этих двух задач полностью.

Для первого варианта плана достаточно примерно десяти сценариев, которые действительно относятся к проекту. Новый пункт нужен, если он приводит к другой защите или другому способу восстановления.

Выберите, что исправлять раньше

Оцените каждый сценарий по трём вопросам:

1. Насколько легко он может произойти именно в вашей системе?
2. Какой ущерб он причинит?
3. Как быстро владелец заметит событие?

Точных процентов не требуется. Значений «низко», «средне» и «высоко» достаточно, если рядом написана причина. Сценарий с высокой вероятностью и потерей уникальных данных получает приоритет перед редким событием, которое легко обнаружить и исправить.

Обычно в начало списка попадают потеря доступа к хостеру или домену, утечка административного ключа, отсутствие внешней копии и возможность веб-приложения изменять весь сервер. Точный порядок зависит от состава проекта.

Не выбирайте меру только потому, что для неё существует знакомая команда. Установка Fail2Ban не компенсирует отсутствие обновлений, а внешний мониторинг не возвращает удалённые данные.

Свяжите каждый риск с действием и проверкой

Запись «усилить SSH» невозможно закончить и проверить. Хорошая формулировка выглядит так: «создать отдельный ключ владельца, подтвердить вход во второй сессии, отключить пароль и проверить итоговую конфигурацию».

Другие примеры:

• лишние публичные службы → разрешить только нужные порты и проверить их снаружи;
• пропущенные исправления → включить обновления безопасности и проверять журнал их установки;
• секрет в Git → удалить значение из кода, отозвать его у поставщика и выдать новое;
• потеря VPS → скачать архив на локальный компьютер и распаковать его в тестовый каталог;
• незамеченная подмена DNS → защитить кабинет регистратора и регулярно сверять записи.

У каждого действия должен быть ответственный человек и наблюдаемый результат. «Настроить мониторинг» становится задачей только после указания адреса проверки, способа уведомления и первого действия при тревоге.

Ведите одну рабочую таблицу

Для небольшого VPS достаточно простого документа без закрытых данных:

Что может произойти	Последствие	Что уже сделано	Следующее действие	Как проверить
Потерян SSH-ключ	посторонний вход	ключ защищён парольной фразой	отдельные ключи для людей	удалить тестовый ключ и проверить отказ
Удалён VPS	потеря сайта и настроек	исходники есть в Git	скачать конфигурацию и данные	распаковать локальный архив
Ошибка UFW закрыла SSH	потеря сетевого входа	известна консоль хостера	проверить консоль до изменений	открыть новую SSH-сессию

Не записывайте в такую таблицу сами пароли, токены и резервные коды. Документ описывает местонахождение и порядок действий, но не становится ещё одним хранилищем секретов.

После выполнения обновляйте колонку защиты и дату проверки. Устаревшая отметка «копия есть» опаснее честного пустого поля, если никто не знает возраст и содержимое архива.

Проверьте один неприятный случай заранее

Выберите реалистичную ситуацию, например потерю ноутбука с SSH-ключом. Попробуйте по документу ответить:

• как попасть в панель и на сервер без этого ключа;
• где удалить его открытую часть;
• какие ещё системы принимали тот же ключ;
• как узнать, использовался ли он посторонним;
• кто и где создаст новую пару.

Если ответ приходится придумывать во время проверки, допишите конкретный шаг. Такая короткая репетиция полезнее длинного списка продуктов безопасности.

Возвращайтесь к плану после появления нового администратора, домена, плагина, публичного порта, способа публикации или места хранения данных. Изменился проект — изменились и реальные пути к ущербу.

Дальше меры выполняются по очереди: защита SSH, правила UFW и nftables, автоматические исправления безопасности и ручная локальная резервная копия. При подозрительном событии понадобится отдельный план реагирования.

Первоисточники

• NIST SP 800-30 Rev. 1: руководство по оценке рисков
• OWASP: основы моделирования угроз
• CISA: базовые меры кибербезопасности