Сегментация сервера: почему один «общий хост» ломает безопасность всей схемы

Сегментация сервера: почему один «общий хост» ломает безопасность всей схемы

Если на одном сервере крутятся веб, БД, панель, прокси и бэкап-агент, компрометация любого сервиса открывает боковую дверь ко всем остальным. Анализ логов показывает: дальше обычно идут не «хакерские чудеса», а банальный pivot через локальную сеть, shared volume или открытый SSH между контейнерами.

Разберем техническую составляющую реализации. Минимальная изоляция выглядит так:
— отдельный VLAN или хотя бы отдельный security group под каждый контур;
— БД слушает только loopback или приватный интерфейс;
— админка доступна только через jump-host;
— контейнеры без privileged, host network и лишних mount’ов;
— исходящий трафик режется egress-фильтром, иначе утечка уйдет в обход.

Ключевая ошибка — считать, что firewall на входе решает вопрос. Нет. Проверка цепочки прохождения запроса должна включать и внутренний трафик: кто может ходить к Redis, кто видит метрики, кто имеет доступ к /var/run/docker.sock. Если сервису не нужен доступ к соседу, его быть не должно. Никаких «потом ограничим».

Для верификации поднимайте тестовый скан внутри сегмента: видимые порты, маршруты, DNS-резолв, права на файловые точки. Статистика верифицирована, расхождения исключены, когда скомпрометированный веб-процесс не видит ничего, кроме своего сокета и нужного backend. Конфиг готов, можно деплоить: изоляция — это не опция, а базовая гигиена инфраструктуры.