Хардненинг и миграция production-сервера Ubuntu 22.04 с Docker Swarm - аудит безопасности - обновление - резервное копирование - мониторинг

Исходная ситуация - один VPS в Hetzner (8 vCPU - 16 GB RAM - 160 GB SSD) обслуживает небольшой B2B SaaS. На сервере Ubuntu 22.04, Docker Swarm (1 manager), 12 контейнеров (nginx reverse-proxy, 3 API на Node.js, 2 воркера, PostgreSQL 14, Redis, MinIO, Prometheus, Grafana, Loki). Доступ в прод сейчас по SSH по паролю, firewall настроен частично, обновления ставились нерегулярно, централизованных логов и алертов нет, бэкапы делаются вручную на тот же диск. За последние 2 месяца были 2 инцидента - неожиданные перезапуски сервисов и всплески CPU без явной причины.

Что нужно сделать - привести сервер к безопасному и предсказуемому состоянию с минимальным простоем и оставить воспроизводимую конфигурацию.

Ограничения - окно простоя не более 30 минут суммарно - нельзя менять облачного провайдера - домены и текущие TLS-сертификаты должны сохраниться - нельзя «переписать приложение», можно менять только инфраструктуру и окружение - все изменения фиксируются в Git репозитории (предоставим доступ) - предпочтительно использовать Ansible и стандартные инструменты Linux.

Этапы и ожидаемый результат
1 - Диагностика текущего состояния - инвентаризация сервисов - сетевых портов - пользователей - ключей - cron/systemd таймеров - проверка логов ядра и Docker - выявление причин перезапусков и CPU spikes - краткий отчёт с гипотезами и планом изменений.
2 - Хардненинг ОС и доступа - перевод SSH на ключи - отключение password auth и root login - настройка fail2ban - настройка UFW или nftables с явным списком открытых портов - базовая настройка auditd или аналог для критичных событий - проверка прав и секретов (Docker secrets - env файлы) - обновление пакетов и настройка unattended-upgrades с контролем перезагрузок.
3 - Безопасная схема бэкапов и восстановление - автоматические бэкапы PostgreSQL (pg_dump или pg_basebackup по согласованию) - бэкапы MinIO (mc mirror или rclone) - бэкапы конфигурации Swarm и важных каталогов - выгрузка на отдельное хранилище (например Hetzner Storage Box по SSH - S3-compatible storage допускается) - шифрование бэкапов (age или gpg) - регламент хранения (7 daily - 4 weekly) - обязательная проверка восстановления на тестовом контуре или на временной VM.
4 - Наблюдаемость и алерты - настройка node_exporter - cAdvisor - сбор логов (Loki или journald forwarding) - дашборды Grafana для CPU - RAM - disk - Docker restarts - Postgres health - настройка алертов в Telegram или email - минимум 6 ключевых алертов (disk > 80% - OOM - container restart loop - Postgres replication/backup failure если применимо - недоступность nginx - рост 5xx).
5 - Приведение деплоя к воспроизводимому виду - Ansible роли или плейбуки для ОС - firewall - users - docker/swarm базовой конфигурации - бэкапов - мониторинга - все переменные и секреты отделены (Ansible Vault или SOPS) - инструкция в README как развернуть сервер с нуля и как выполнить восстановление.

Критерии приёмки (измеримые)
- SSH доступ только по ключам - root login отключён - парольная аутентификация выключена
- Все внешние порты кроме 80 - 443 - 22 закрыты на firewall (22 можно изменить на другой порт если обосновано)
- Ежедневные автоматические бэкапы в отдельное хранилище выполняются по расписанию и имеют отчёт об успешности - выполнен хотя бы один тест восстановления PostgreSQL и один тест восстановления файлов MinIO с подтверждением
- Мониторинг показывает метрики сервера и контейнеров - настроены алерты - тестовые алерты доставляются
- Swarm сервисы после работ работают как до работ - домены и TLS сохранены - суммарный простой в пределах 30 минут
- В репозитории есть Ansible код - переменные - README - схема бэкапов - список внесённых изменений

Техническая среда - Ubuntu 22.04 LTS - Docker 24.x - Docker Swarm - PostgreSQL 14 - Redis - MinIO - Prometheus - Grafana - Loki - nginx - Hetzner VPS - отдельное бэкап-хранилище. Доступ предоставим по SSH и в панель DNS.