Аудит Linux-сервера и VPS/VDS перед принятием на сопровождение

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

Доступы и ответственность

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

• доступ к панели провайдера;
• SSH-пользователи и ключи;
• sudo-права;
• доступы к DNS и доменам;
• репозитории и CI/CD;
• хранилище резервных копий;
• внешние сервисы мониторинга;
• контакты ответственных.

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

Инвентаризация системы

Фиксируем:

1. 1Дистрибутив и версию ядра.
2. 2Дату последней перезагрузки.
3. 3Виртуальные CPU, память и диски.
4. 4Сетевые интерфейсы и публичные IP.
5. 5Установленные web/runtime/database компоненты.
6. 6Активные systemd-сервисы и контейнеры.
7. 7Планировщики cron и timers.
8. 8Точки монтирования и внешние хранилища.

Отдельно составляется карта домен → веб-сервер → приложение → база → внешние зависимости.

Ресурсы и признаки деградации

Текущая нагрузка не показывает всю картину, поэтому смотрим историю, если она доступна.

Проверяем:

• свободное место и inode;
• использование RAM и swap;
• load average и CPU steal;
• процессы с высокой нагрузкой;
• рост журналов;
• состояние файловой системы;
• лимиты открытых файлов и соединений;
• ошибки OOM и аварийные завершения.

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

Веб-сервер и приложения

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

Типовые риски:

• приложение запущено вручную в пользовательской сессии;
• конфигурация изменена, но не сохранена в репозитории;
• сертификат продлевается неизвестным скриптом;
• несколько проектов используют несовместимые версии runtime;
• health-check отсутствует;
• restart policy создает бесконечный цикл.

Конфигурации проверяются командой валидации до перезапуска сервиса.

Базы данных

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

Нельзя считать копирование каталога базы корректным бэкапом работающего сервера без понимания механизма согласованности.

Резервное копирование

Аудит должен ответить:

• что сохраняется;
• как часто;
• куда;
• сколько версий хранится;
• кто получает ошибку задания;
• шифруются ли копии;
• выполнялась ли проверка восстановления.

Единственная копия на том же VPS не защищает от потери диска или учетной записи провайдера.

Сеть, DNS и SSL

Проверяем открытые порты, firewall, слушающие процессы, DNS-записи и сертификаты. Служебные базы и панели не должны без необходимости быть доступны всему интернету.

Также фиксируются внешние allowlist, VPN и ограничения по IP: после миграции они часто становятся скрытой причиной отказа интеграций.

Обновления и безопасность

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

Базовые проверки:

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

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

Мониторинг и журналирование

Минимально контролируются доступность сервера и проектов, место на диске, память, CPU, срок SSL и состояние ключевых сервисов. Журналы должны иметь ротацию и достаточную глубину для диагностики.

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

Итог аудита

Хороший результат — это не список из сотни замечаний, а приоритетная карта:

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

Перед первыми изменениями создается точка восстановления и согласуется окно работ. Такой подход позволяет принять инфраструктуру без ненужного простоя и перейти к регулярному администрированию серверов, VPS/VDS, DNS и SSL.

Частые вопросы

Нужно ли останавливать сервер для аудита?

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

Можно ли обновить устаревший сервер без переноса?

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

Что делать, если резервные копии есть, но их никто не восстанавливал?

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

Нужно ли менять все SSH-ключи при смене подрядчика?

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