Сегментация сети под требования регулятора: рабочая схема на своём железе

MAATRIX

Регулятор требует изолировать контур, где обрабатываются чувствительные данные, от остальной инфраструктуры — и это звучит просто, пока не доходит до конкретной сети из десятка серверов, общего firewall на всех и админов, которые заходят по SSH куда угодно с одного и того же ноутбука. На бумаге сегментация есть — в реальности любой сервис в общей подсети может достучаться до базы с защищаемыми данными. Разберём, как построить реальную, а не бумажную сегментацию: от логики зон до конкретных VLAN, правил firewall и минимального набора документов, которые не стыдно показать при проверке.

Что регулятор на самом деле хочет увидеть в сети

За формулировками про «изоляцию контура обработки» и «ограничение доступа» стоит одна инженерная идея: чувствительные данные должны находиться в сегменте, куда нельзя попасть иначе, чем через явно разрешённый и контролируемый путь. Проверяющему (в широком смысле — любому, кто оценивает соответствие требованиям к обработке защищаемой информации, будь то ПДн, финансовые данные или другая регулируемая категория) не важна конкретная технология: VLAN это, VXLAN, отдельная физическая сеть или SDN. Важны три вещи, которые проверяются по факту, а не по описанию:

• Сетевая изоляция подтверждена технически, а не только описана в политике безопасности — есть конфиг, который это обеспечивает, и его можно показать.
• Список разрешённых потоков конечен и объясним — на каждое правило firewall можно ответить «зачем оно» и «кто его добавил».
• Схема сети существует как документ, а не только в голове одного администратора, и совпадает с реальной конфигурацией на момент проверки.

Ключевая ошибка большинства небольших инфраструктур — не отсутствие сегментации, а разрыв между тем, что написано в политике, и тем, что реально настроено на коммутаторах и в firewall. Если политика говорит «доступ к серверу с защищаемыми данными только через VPN», а на деле там открыт SSH на 0.0.0.0/0 «на время отладки» полгода назад — это не техническая проблема, а управленческая, и именно её чаще всего находят при проверке.

Отдельно: эта статья — про инженерный подход к сегментации сети, а не про то, какие конкретно нормативные требования и в каком объёме применимы к вашей системе. Это отдельный вопрос к юристу или профильному консультанту; здесь — только про то, как технически построить изолированный контур, если вы уже знаете, что он вам нужен.

Логическая модель: зоны, а не один большой firewall

Прежде чем настраивать что-либо, стоит нарисовать зоны — даже на листе бумаги. Рабочая модель для типичной инфраструктуры на одном или нескольких серверах — это минимум три зоны с разным уровнем доверия:

1. Внешняя зона (edge/DMZ) — то, что смотрит в интернет: веб-сервер, балансировщик, публичное API. Сюда приходит любой трафик из сети, и по умолчанию эта зона считается скомпрометированной раньше остальных.
2. Прикладной сегмент — бизнес-логика, приложение, очереди, кэш. Принимает запросы только от edge-зоны, сам в интернет ходить не должен (кроме явно нужного — обновления, внешние API).
3. Защищаемый контур — там, где лежат чувствительные данные: база с персональными или иными регулируемыми данными, хранилище документов, платёжный модуль. Принимает соединения только от прикладного сегмента, и то не любые, а строго по портам и протоколам, которые реально нужны приложению.

К этому часто добавляют четвёртую зону — административную: отдельный сегмент, откуда идёт управление всеми остальными (SSH, панели управления, мониторинг). Административная зона не равна защищаемому контуру, но доступ в неё тоже нужно ограничивать — именно оттуда чаще всего приходит скомпрометированная учётка.

Правило простое и универсальное: трафик между зонами идёт только в одну логическую сторону и только по нужным портам. Edge обращается к прикладному сегменту — но не наоборот. Прикладной сегмент обращается к защищаемому контуру по порту базы данных — но обратного инициирующего соединения из контура в прикладной сегмент быть не должно, если это не требуется явно (например, для доставки уведомлений).

Как выделить контур на одном арендованном сервере

Если у вас не своя серверная с управляемыми коммутаторами, а один или несколько арендованных серверов, сегментация всё равно возможна — просто она делается программно, средствами гипервизора и сети внутри ОС.

Вариант 1: один физический сервер, несколько VM/контейнеров, VLAN через мосты. Если сервер под Proxmox VE или похожим гипервизором, для каждой зоны создаётся отдельный виртуальный мост (bridge) с собственным VLAN ID, и каждая VM/CT подключается только к своему мосту:

# /etc/network/interfaces на узле Proxmox
auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 10,20,30

auto vmbr0.10
iface vmbr0.10 inet static
    address 10.10.10.1/24
    # зона edge

auto vmbr0.20
iface vmbr0.20 inet static
    address 10.10.20.1/24
    # прикладной сегмент

auto vmbr0.30
iface vmbr0.30 inet static
    address 10.10.30.1/24
    # защищаемый контур (ПДн/чувствительные данные)

Каждой VM при создании назначается конкретный VLAN tag (10, 20 или 30) на сетевом интерфейсе — и с этого момента трафик между зонами физически не пойдёт мимо firewall на узле, потому что это разные широковещательные домены. Здесь легко ошибиться: если VLAN tag на интерфейсе VM выставлен неверно или забыт, машина «повисает» не в той сети — это одна из самых частых практических граблей при настройке VLAN в Proxmox, разбор конкретного случая с пропавшим доступом есть в статье «Сеть в Proxmox: мосты, VLAN и почему пропал доступ».

Вариант 2: несколько арендованных серверов, разделение подсетями и приватной сетью. Если провайдер даёт приватную сеть между вашими серверами, выносите защищаемый контур на сервер, у которого публичный IP вообще не привязан к сервису с данными — только приватный интерфейс, через который к нему обращается прикладной сервер. Внешнего пути к базе просто не существует физически.

Вариант 3: контейнеризация с сетевой изоляцией. Docker/Podman с отдельными сетями (docker network create --internal) для контура с данными — рабочий подход для небольших проектов, но он слабее VLAN по границе: изоляция там на уровне namespace, а не отдельного L2-сегмента, и требует аккуратности с публикацией портов (-p, которая по умолчанию слушает на всех интерфейсах).

Какой бы вариант ни выбрали, IP-план стоит держать явным и записанным — не «случайные» адреса, а осознанная схема:

Firewall между сегментами: запрещено всё, что не разрешено явно

Сама по себе VLAN-изоляция не даёт защиты — она просто разводит трафик по разным L2-доменам. Реальная граница контроля — firewall между зонами, настроенный по принципу default deny: базовая политика — DROP, и только сверху добавляются точечные разрешения.

Пример на nftables для узла-маршрутизатора между зонами (10.10.20.0/24 — прикладной сегмент, 10.10.30.0/24 — защищаемый контур):

table inet filter {
    chain forward {
        type filter hook forward priority 0; policy drop;

        # разрешаем только прикладному сегменту стучаться в БД контура по 5432
        ip saddr 10.10.20.0/24 ip daddr 10.10.30.0/24 tcp dport 5432 accept

        # разрешаем уже установленные и связанные соединения (ответы БД)
        ct state established,related accept

        # явный лог того, что отбрасывается — пригодится при разборе инцидентов
        log prefix "DROP-INTER-ZONE: " counter drop
    }
}

Ключевой момент — политика drop по умолчанию и явные accept только под конкретные порты и направления, а не «разрешить подсеть 10.10.20.0/24 целиком». Разница между «разрешить один порт нужному сервису» и «разрешить всю подсеть, потому что так проще» — это ровно та грань, где сегментация превращается в антипаттерн: подробный разбор, почему широкие правила «на всякий случай» рано или поздно аукаются, есть в статье «Антипаттерн: firewall "разрешить всё, потом разберёмся"».

Практический совет, который часто упускают: заведите матрицу доступа отдельным документом (таблица «откуда → куда → порт → зачем») и сверяйте с ней конфиг firewall при каждом изменении. Без такой матрицы через полгода никто не вспомнит, зачем в правилах висит проброс с edge-зоны напрямую на порт БД — а такое разрешение, оставленное «для теста», и есть типичный провал сегментации при проверке.

Есть и обратная крайность — слишком много узких правил ради избыточной детализации. На не самом мощном сервере производительность firewall может начать деградировать при большом количестве правил линейного поиска, особенно если они не сгруппированы и не используют быстрые структуры вроде nftables sets. Ориентир, с какого порядка величины стоит задумываться об оптимизации структуры правил, — в статье «Предел числа правил в firewall: с какого количества пакет начинает тормозить». Для типичной сегментации из 3–4 зон до этого предела обычно далеко, но раздутый список правил — сигнал пересмотреть структуру, а не просто добавлять ещё.

Минимизация точек входа в защищаемый контур

Каждый дополнительный способ попасть в защищаемый сегмент — это дополнительная поверхность атаки, и здесь работает простое правило: чем меньше точек входа, тем меньше что проверять и что объяснять регулятору.

Практические меры, которые реально снижают число точек входа:

• Один административный вход, а не N. Прямой SSH-доступ к серверам защищаемого контура с рабочих машин админов — плохая практика, даже если IP отфильтрованы. Правильная схема — bastion/jump host в административной зоне: админ заходит по SSH на bastion (с ключом и, желательно, 2FA), а с bastion — дальше внутрь, причём и это соединение тоже фильтруется firewall по конкретным адресам назначения.
• Нет прямого выхода контура в интернет. Серверу с защищаемыми данными не нужен произвольный исходящий доступ — только NTP, DNS через контролируемый резолвер, возможно репозиторий пакетов через прокси. Открытый исходящий трафик из защищённого сегмента — частая недооценённая дыра: через неё утечка данных или C2-канал скомпрометированного сервиса проходит так же легко, как и входящий.
• Управление через VPN, а не через публичный IP на панели. Админ-панель, панель хостинг-провайдера, консоль мониторинга должны быть доступны только через VPN или из ограниченного списка IP, а не торчать в интернет с формой логина.
• Учётные записи и ключи — по одной на человека и на сервис. Общая учётка «admin», через которую заходят три разных инженера, делает бессмысленным аудит доступа — вы не можете сказать, кто именно заходил в контур в конкретный момент.

Важная оговорка: минимизация точек входа — не про «закрыть всё и молиться», а про осознанный список из небольшого числа путей, каждый из которых обоснован и залогирован. На практике список точек входа имеет тенденцию расти — «временный» доступ подрядчику, отладочный порт, оставленный после инцидента, — и регулярная ревизия (например, раз в квартал) держит его в разумных границах.

Документирование схемы сети

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

1. Схема сети (диаграмма) — зоны, подсети, направления разрешённого трафика, точки входа. Не обязательно дорогой инструмент — draw.io, PlantUML или аккуратная схема в Miro подойдут, если она реально отражает текущее состояние.
2. IP-план — таблица подсетей и их назначения (тот же формат, что в примере выше), с указанием, где физически или логически расположен каждый сегмент.
3. Матрица доступа между зонами — откуда, куда, по какому порту, кем и когда добавлено правило, зачем оно нужно. Это документная проекция конфига firewall — и она обязана совпадать с реальным конфигом.
4. Список точек входа и способов управления — bastion-хосты, VPN, административные учётки, кто имеет к ним доступ.
5. Журнал изменений сетевой конфигурации — минимум: кто, когда и зачем менял правила firewall или структуру VLAN. Простой git-репозиторий с конфигами под версионным контролем и осмысленными commit-сообщениями закрывает большую часть этого требования бесплатно.

Практический лайфхак: держите конфиги firewall, схему VLAN и IP-план в одном git-репозитории, а диаграмму — генерируемой из текстового описания (PlantUML/Mermaid), а не рисуемой руками. Тогда схема физически не «отстаёт» от реальности так же легко, как картинка, которую никто не открывал полгода.

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

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