Приложение, собранное вручную или с помощью нейросети, может открываться в браузере и при этом оставаться небезопасным для production. Работоспособность не означает готовность к публичному запуску. До публикации стоит пройти базовый чек-лист: он не сделает систему неуязвимой, но заметно сократит последствия ошибок в коде, конфигурации и зависимостях.
Ниже разберём, что проверить перед запуском приложения на Linux-сервере: изоляцию сервисов, открытые порты, доступ к базе данных, хранение секретов, вход пользователей, HTTPS, логи, мониторинг и бэкапы.
1. Изолируйте приложение и сервисы
Даже статический сайт, который Nginx раздаёт из HTML, CSS и JavaScript-файлов, лучше не смешивать с базой данных, Redis, резервными копиями и другими сервисами на одном уровне доступа. Контейнеры помогают ограничить область поражения: при уязвимости в веб-приложении злоумышленник не должен автоматически получать доступ ко всему серверу.
Размещайте веб-приложение, базу данных и Redis в отдельных контейнерах или изолированных средах. Разрешайте между ними только необходимые соединения. Контейнер тоже требует настройки: не запускайте процесс от root без необходимости, не выдавайте лишние Linux capabilities и не монтируйте в него файловую систему хоста целиком.
Изоляция не устраняет уязвимости, но ограничивает их последствия. Это особенно важно, когда на одном VPS работают несколько приложений.
2. Проверьте открытые порты и firewall
Частая ошибка при деплое через Docker Compose: конфигурацию для разработки переносят на публичный сервер без изменений. Например, PostgreSQL оказывается опубликован на порту 5432, хотя к нему должно подключаться только приложение внутри сети контейнеров.
Посмотрите на каждый порт, доступный из интернета, и ответьте на простой вопрос: зачем он нужен внешнему пользователю? Для сайта обычно нужны 80 и 443. SSH можно ограничить доверенными IP-адресами или доступом через VPN. PostgreSQL, MySQL, Redis, панели мониторинга и административные интерфейсы в большинстве случаев не должны быть доступны всему интернету.
Настройте firewall по принципу минимального доступа и проверьте результат снаружи сервера. Правило может выглядеть корректно, но порядок правил Docker или сетевого экрана иногда открывает порт вопреки ожиданиям.
3. Закройте базу данных и выдайте минимум прав
В базе данных часто находятся учётные записи, адреса электронной почты, документы, заказы и персональные данные. Поэтому база не должна слушать публичный интерфейс без явной необходимости. Если удалённое подключение действительно нужно, ограничьте его сетевыми правилами и отдельными учётными записями.
Не подключайте приложение к PostgreSQL или MySQL от имени суперпользователя. Создайте отдельную роль и выдайте ей только права, нужные конкретному сервису. Приложению, которое читает и изменяет данные в своей базе, не нужны полномочия на создание пользователей, управление другими базами или изменение системных настроек.
Не используйте одну привилегированную учётную запись для нескольких сервисов. При компрометации одного из них лишние права превращают локальную проблему в инцидент всей инфраструктуры.
4. Уберите секреты из кода и репозитория
Пароли баз данных, API-ключи, JWT-секреты, SMTP-пароли и токены сторонних сервисов не должны попадать в исходный код и Git-репозиторий. Файл .env удобнее, чем секрет прямо в коде, но сам по себе не является защищённым хранилищем. Тот, кто получил доступ к файлу, получит и его содержимое.
Для небольшого проекта задайте конфигурационным файлам корректные права, исключите их из Git и убедитесь, что веб-сервер их не раздаёт. В более крупной инфраструктуре используйте отдельное хранилище секретов. Если ключ уже попал в публичный репозиторий, удаления из последнего коммита недостаточно: считайте его скомпрометированным и замените.
5. Проверьте регистрацию, вход и права доступа
Пароли нельзя хранить открытым текстом или просто пропускать через быстрый хеш, например SHA-256. Используйте специализированные алгоритмы хеширования паролей с солью и подходящими параметрами сложности. Их задача в том числе сделать массовый перебор хешей дорогим после утечки базы.
Защитите форму входа и API от перебора: добавьте rate limiting и увеличивайте задержку либо временно ограничивайте новые попытки после серии ошибок. Не раскрывайте в ответах, существует ли конкретный адрес электронной почты или логин. Одинаковое сообщение для неверных учётных данных уменьшает возможности для разведки.
Проверьте сессии и токены. Cookie должны передаваться только по HTTPS и иметь безопасные атрибуты. У токенов должен быть ограниченный срок жизни и понятный сценарий отзыва: например, после смены пароля или блокировки аккаунта старый токен не должен сохранять доступ неделями.
Аутентификация отвечает на вопрос, кто делает запрос, а авторизация отвечает на вопрос, что ему разрешено. Недостаточно скрыть ссылку на админ-панель в интерфейсе. Backend обязан проверять право доступа на каждом защищённом маршруте и на каждом объекте. Пользователь, который запрашивает заказ №123, должен иметь право видеть именно этот заказ.
6. Включите HTTPS и уберите служебные страницы из production
В production приложение должно работать только через HTTPS. Без шифрования логины, токены и другие данные могут быть перехвачены или подменены. Сертификат можно получить бесплатно, а выпуск и продление автоматизировать.
После настройки пройдитесь по приложению глазами внешнего пользователя. Проверьте, не доступны ли файлы .env, архивы с бэкапами, Swagger, Prometheus, Grafana, страницы отладки и административные панели. Сообщения об ошибках не должны отдавать абсолютные пути на сервере, стек вызовов или детали внутренней конфигурации.
7. Настройте логи, мониторинг и реакцию на события
Если процессор внезапно загружен на 100%, с неизвестного IP идут тысячи запросов, кто-то перебирает SSH или в базе появляются странные операции, без журналов останется только факт сбоя. Логируйте ошибки приложения, успешные и неуспешные входы, изменения прав, административные действия, необычные ответы API и важные системные события.
Не записывайте в логи пароли, токены, cookie, приватные ключи и другие секреты. Журналы тоже содержат чувствительную информацию, поэтому для них нужны ограниченный доступ и понятный срок хранения.
Мониторинг дополняет логи: он помогает заметить рост нагрузки, нехватку памяти, заполнение диска, остановку процесса или аномальную активность до того, как проблему увидят пользователи. Минимальный уровень защиты включает контроль SSH-брутфорса и блокировку адресов после большого числа неудачных попыток. Для наблюдения за событиями на Linux-хосте можно использовать EDR-агент, например Open Defender. Такой инструмент дополняет безопасную конфигурацию, но не заменяет её.
8. Сделайте резервные копии и проверьте восстановление
Бэкапы нужны не только на случай утечки данных. Данные могут быть зашифрованы вымогателем, удалены ошибочной миграцией или повреждены из-за сбоя. Настройте резервное копирование базы и важных файлов до запуска приложения, храните копии отдельно от основного сервера и не открывайте их для доступа из интернета.
Существование резервной копии ещё не означает, что она поможет. Регулярно проверяйте, что архив создаётся, доступен в нужном месте и действительно восстанавливается. Только успешное тестовое восстановление подтверждает работоспособность бэкапа.
Краткий чек-лист перед запуском приложения
- Приложение, база данных и вспомогательные сервисы изолированы.
- Снаружи доступны только необходимые порты, firewall проверен извне.
- База данных и Redis не открыты всему интернету, роли сервисов ограничены.
- Секреты не лежат в репозитории и не раздаются веб-сервером.
- Пароли хешируются безопасным алгоритмом, вход защищён от перебора.
- Авторизация проверяется на backend для маршрутов и объектов.
- HTTPS включён, отладочные страницы и внутренние панели закрыты.
- Есть логи, мониторинг и уведомления, в журналы не попадают секреты.
- Резервные копии хранятся отдельно и проверены восстановлением.
Этот чек-лист не исключает все риски, но создаёт заметную разницу между запуском приложения вслепую и базовой подготовкой сервера к реальной эксплуатации.