Сегментация сети для небольшой компании: зоны и правила

В плоской сети один заражённый ноутбук видит все серверы, принтеры и камеры, а любая ошибка администратора открывает всё сразу. Сегментация разделяет сеть на зоны и разрешает между ними только нужные потоки: тогда компрометация одного узла не превращается в компрометацию всего. Ниже порядок для небольшой компании: какие зоны выделить, как составить матрицу потоков, как реализовать правила на nftables и как переходить без простоев.

Статья опирается на логику направления «Архитектура кибербезопасности» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Примеры правил проверяйте на тестовой системе и держите второй путь доступа.

Что должно получиться

Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.

Шаг 1. Нарисуйте текущую схему

Без схемы сегментировать нечего. Соберите список узлов из реестра ИТ-активов и подсетей, отметьте, кто с кем разговаривает. Недостающие данные получите, наблюдая за трафиком на межсетевом экране и в журналах. Начните с одного листа: подсети, шлюзы, внешние подключения, облака.

Шаг 2. Выделите зоны

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

Шаг 3. Составьте матрицу потоков

Матрица — главный документ: она показывает, что разрешено из какой зоны в какую. Всё, чего нет в матрице, запрещено.

Шаг 4. Реализуйте разделение

Зоны реализуются отдельными подсетями и VLAN на коммутаторах, а правила между ними — на межсетевом экране (аппаратном или на сервере с Linux). Основные принципы правил:

• политика по умолчанию — запрет, разрешения явно по матрице;
• разрешайте ответы на уже установленные соединения;
• правила называйте по назначению и записывайте в документации;
• правила для управления привязывайте к адресам рабочих мест администраторов.

Пример фрагмента для маршрутизатора на Linux с nftables (имена интерфейсов и порты заменяйте своими; подробнее про nftables: firewall в Linux):

table inet zones {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    ct state invalid drop

    # пользователи -> серверы: только веб и база через приложение
    iifname "vlan10" oifname "vlan20" tcp dport { 443, 8443 } accept

    # пользователи -> DMZ: HTTPS
    iifname "vlan10" oifname "vlan30" tcp dport 443 accept

    # управление -> серверы и DMZ: SSH
    iifname "vlan40" oifname { "vlan20", "vlan30" } tcp dport 22 accept

    # DMZ -> серверы: только к бэкенду приложения
    iifname "vlan30" oifname "vlan20" ip daddr 192.0.2.20 tcp dport 8443 accept

    # гости: только в интернет
    iifname "vlan50" oifname "wan0" accept
  }
}

Перед применением проверьте синтаксис командой sudo nft -c -f ФАЙЛ. Для изменений правил подготовьте автоматический откат (например, отложенный запуск прежней конфигурации средствами systemd), чтобы не потерять доступ. Риск: неверное правило отрезает администраторов, держите вторую сессию или консоль гипервизора.

Шаг 5. Переходите поэтапно

1. Наблюдение. Сначала включите журналирование запрещённых соединений, не блокируя: так вы увидите потоки, о которых не знали.
2. Первая зона. Выделите гостей и устройства: самое простое и безопасное разделение.
3. Управление. Перенесите административные интерфейсы в отдельную зону с доступом через MFA: MFA для SSH и WireGuard.
4. Серверы и DMZ. Разделите публичные и внутренние системы, перенесите их по одному окну работ.
5. Включение запрета. Переведите правила из режима журналирования в блокировку для каждой зоны после разбора потоков.

Шаг 6. Проверьте результат

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

Диагностика

Где это в модели зрелости

Материал относится к направлению «Архитектура кибербезопасности» (карта: карта зрелости) и поддерживает направление «Сетевая безопасность» (материалы по сетевой безопасности). Уровень 1 закрывает схема сети и потоков, уровень 2 добавляет разделение на сегменты по назначению и учёт требований ИБ при проектировании новых систем.

Как проверить

1. Есть актуальная схема сети и матрица потоков, утверждённые ответственным.
2. Рабочие станции не имеют доступа к управлению серверами, гостевая сеть изолирована.
3. Политика межсетевого экрана по умолчанию — запрет, правила соответствуют матрице.
4. Новая система перед запуском получает зону и записи в матрице потоков.

Источники

• Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.
• Документация nftables (Wiki проекта netfilter): wiki.nftables.org.
• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy: csrc.nist.gov. Международная практика, не российский норматив.