Чек-лист безопасного VPS для малого бизнеса: доступы, обновления, бэкапы, мониторинг

Содержание

• Доступы: кто и как попадает на сервер
• Обновления: система не должна стареть незаметно
• Firewall и открытые порты
• Бэкапы: не «когда-нибудь», а по расписанию
• Мониторинг: узнать о проблеме раньше клиента
• Логи и следы изменений
• Быстрый самопроверочный список
• Когда стоит провести аудит VPS

VPS часто покупают как «просто сервер»: разместить сайт, CRM, бота, почтовый сервис или AI-инструмент. Но как только на нём появляется рабочий бизнес-процесс, это уже часть инфраструктуры. Если доступы, обновления и резервные копии настроены наугад, проблема обычно проявляется в самый неудобный момент: сайт лежит, заявки не приходят, админ недоступен, а свежего бэкапа нет.

Ниже — практический чек-лист базовой безопасности VPS/VDS для малого бизнеса. Он не заменяет полноценный аудит, но помогает быстро понять, где сервер уже выглядит аккуратно, а где держится на честном слове.

Доступы: кто и как попадает на сервер

• SSH-доступ по ключам. Парольный вход лучше отключить, особенно для пользователя root.
• Отдельные пользователи для администрирования. Не стоит работать постоянно под root, если задачи можно выполнять через sudo.
• Список актуальных доступов. Уволенные сотрудники, старые подрядчики и временные ключи не должны оставаться на сервере годами.
• Ограничение входа. Для критичных серверов полезны firewall-правила, VPN или доступ только с доверенных IP.

Обновления: система не должна стареть незаметно

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

• регулярные обновления ОС и security-пакетов;
• контроль версий PHP, Node.js, Python и других runtime-сред;
• аккуратное обновление WordPress, плагинов, Laravel-приложений и зависимостей;
• проверка после обновлений, чтобы сайт или сервис не сломался молча.

Firewall и открытые порты

На сервере должны быть открыты только те порты, которые реально нужны: обычно 80/443 для сайтов, SSH для администрирования и отдельные порты для внутренних сервисов — только если они защищены и действительно должны быть доступны извне.

Хорошая практика — периодически проверять, что «случайно наружу» не торчат базы данных, панели, dev-сервисы, тестовые API или мониторинг без авторизации.

Бэкапы: не «когда-нибудь», а по расписанию

Бэкап считается рабочим только тогда, когда понятно три вещи: что копируется, куда копируется и как это восстановить.

• Файлы сайта и приложений. Код, загрузки, конфиги без секретов в открытом виде.
• Базы данных. MySQL, PostgreSQL и другие хранилища должны копироваться отдельно и регулярно.
• Внешнее хранение. Бэкап на том же сервере не спасает при потере VPS.
• Тест восстановления. Хотя бы иногда нужно проверять, что архив действительно разворачивается.

Мониторинг: узнать о проблеме раньше клиента

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

Для малого бизнеса часто достаточно базового набора: uptime-проверка сайта, уведомления о недоступности, контроль диска, CPU/RAM, срока SSL-сертификата и ошибок в логах. Главное — чтобы уведомление получал тот, кто реально может отреагировать.

Логи и следы изменений

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

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

Быстрый самопроверочный список

• Root-вход по паролю отключён.
• Есть актуальный список SSH-ключей и пользователей.
• Firewall включён, лишние порты закрыты.
• Обновления безопасности устанавливаются регулярно.
• Бэкапы уходят во внешнее хранилище.
• Восстановление из бэкапа хотя бы раз проверялось.
• Есть мониторинг сайта, диска, нагрузки и SSL.
• Понятно, кто получает аварийные уведомления.
• Пароли, токены и ключи не лежат в открытых файлах и чатах.

Когда стоит провести аудит VPS

Аудит нужен не только после аварии. Его стоит сделать перед запуском нового сайта или сервиса, после смены подрядчика, перед рекламной кампанией, при переносе проекта на VPS/VDS или если сервер давно никто системно не проверял.