Сегментация сервера — единственный способ не положить всю инфраструктуру одной ошибкой

Сегментация сервера — единственный способ не положить всю инфраструктуру одной ошибкой

Анализ логов показывает одну и ту же картину: веб, БД, очередь и админка живут на одном хосте, а потом удивляются, почему компрометация web-процесса превращается в полный доступ. Разберем техническую составляющую реализации.

Базовая схема простая:
— публичный слой: reverse proxy, WAF, static;
— прикладной слой: только внутренние порты, без прямого доступа из интернета;
— данные: БД, Redis, очереди — в отдельной подсети или хотя бы на отдельном интерфейсе;
— управление: SSH, панели, бэкапы — через VPN или bastion, не через белый IP.

Дальше важна изоляция на уровне ОС и сети. Контейнеры без жестких cgroup/seccomp/namespace — это не изоляция, а декорация. Для сервисов задавайте минимальные права, отдельного пользователя, отдельный каталог, закрытый outbound, если процессу не нужен внешний трафик. Проверка цепочки прохождения запроса должна показывать: внешний мир видит только edge, а внутренние сервисы не торчат в scan-поле.

Отдельно проверьте lateral movement: если один сервис скомпрометирован, он не должен читать ключи соседей, ходить в метаданные облака и поднимать привилегии через общие socket’ы. Секреты — по принципу least privilege, а доступ между сегментами — через явные ACL, а не “по умолчанию разрешено”.

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