Хардженінг та міграція 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 та стандартні інструменти.

Етапи та очікуваний результат
1 - Діагностика поточного стану - інвентаризація сервісів - мережевих портів - користувачів - ключів - cron/systemd таймерів - перевірка логів ядра та Docker - виявлення причин перезапусків та CPU spikes - короткий звіт з гіпотезами та планом змін.
2 - Хардненінг ОС і доступу - переклад SSH на ключі - відключення password auth і root login - налаштування fail2ban - налаштування UFW або nftables з явним списком відкритих портів - базове налаштування auditd або аналог для критичних подій - перевірка прав та секретів (Docker secrets - env файли) - оновлення перезавантажень.
3 - Безпечна схема бекапів та відновлення - автоматичні бекапи PostgreSQL (pg_dump або pg_basebackup за погодженням) - бекапи MinIO (mc mirror або rclone) - бекапи конфігурації Swarm і важливих каталогів - вивантаження на окреме сховище - наприклад Hetzner Storage шифрування бекапів (age або gpg) – регламент зберігання (7 daily – 4 weekly) – обов'язкова перевірка відновлення на тестовому контурі або на тимчасовій VM.
4 - Спостережливість і сповіщення - налаштування node_exporter - cAdvisor - збір журналів (Loki або journald forwarding) - Інформаційні панелі Grafana для CPU - RAM - диск - Перезавантаження Docker - Стан Postgres - налаштування сповіщень у Telegram або електронною поштою - принаймні 6 ключових сповіщень (диск > 80% - OOM - цикл перезапуску контейнера - Помилка реплікації/резервного копіювання Postgres, якщо можливо - недоступність 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.