Изолированные сетевые контуры на одном рабочем месте: как разделить

Что значит «два контура» на одном рабочем месте

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

Важно различать «два кабеля» и реальную изоляцию. Два кабеля, воткнутые в один ПК, сами по себе ничего не гарантируют: операционная система может маршрутизировать трафик между интерфейсами, случайно создать сетевой мост, раздать интернет через общий доступ. Некоторые приложения тоже «выбирают» путь не так, как ожидается. Изоляция - это когда даже при ошибке пользователя или типовой настройке ОС обмен между контурами невозможен.

Обычно бизнесу и ИБ нужен результат, который можно проверить и поддерживать:

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

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

Откуда берутся утечки между контурами: короткая модель угроз

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

Самый частый источник проблем - непреднамеренный «мост» на уровне физики. Он появляется, когда кроме двух проводных подключений включают Wi‑Fi, вставляют USB‑модем или подключают смартфон как точку доступа. Для ПК это еще один интерфейс, который может стать обходным путем между контурами или дать выход в интернет там, где его быть не должно.

Дальше идут риски на уровнях L2 и L3. Даже без явной маршрутизации контур можно «подсветить» наружу служебным трафиком. DHCP может выдать неверные параметры, ARP покажет наличие соседей, а неправильные маршруты или включенный NAT превращают рабочую станцию в мини-шлюз. Иногда это выглядит безобидно: «просто заработала печать», а по факту один контур получил доступ к сегменту другого.

На уровне приложений утечки еще проще. Почта, мессенджеры и облака переносят файлы «сами по себе», особенно если пользователь вошел под одной и той же учетной записью в обоих контурах. Опасны и «мелочи»: общий буфер обмена, автосинхронизация браузера, менеджеры паролей, автозагрузка документов в корпоративные хранилища.

Утечкой обычно считают не только прямую передачу файлов. На практике настораживают такие признаки:

• DNS-запросы и попытки выйти к внешним доменам из закрытого контура;
• доступ к ресурсам «не той» сети (файловые шары, RDP, базы);
• появление маршрутов между подсетями или неожиданный NAT на рабочей станции;
• общие учетные данные и токены, которые открывают доступ из внешней среды;
• любые пакеты между контурами, даже если «это только служебное».

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

Физическое разделение: когда проще два устройства, а не один ПК

Если задача звучит как «изолированные сетевые контуры на одном рабочем месте», самый понятный и проверяемый путь - физически развести контуры по разным устройствам. Это снижает риск «случайного моста» и упрощает аудит: меньше настроек, меньше скрытых зависимостей.

Самый прямой вариант - два отдельных ПК: один работает только во внутреннем контуре, второй - только в контуре с интернетом (или другом внешнем сегменте). Это дороже по железу и месту, зато проще объяснить проверяющим и проще сопровождать.

Частый компромисс - два физических устройства, но один комплект периферии через KVM-переключатель. Пользователь нажимает кнопку и видит то один, то другой ПК. Здесь важно выбирать KVM без «умных» сетевых функций и без общего USB-хаба, который может пробрасывать не то, что ожидается. Для строгих режимов иногда запрещают общий звук, общие флешки и даже общий принтер.

Третий вариант - тонкий клиент и две независимые удаленные сессии на разные серверы/VDI, каждая в своем контуре. Это удобно для поддержки и учета, но требует дисциплины на стороне инфраструктуры: отдельные шлюзы, отдельные учетные записи, запрет копирования между сессиями, контроль буфера обмена и печати.

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

Физическое разделение обычно обязательно, если:

• есть требования регулятора или внутренней службы ИБ «только раздельные устройства»;
• обрабатываются гостайна, медданные или платежные данные в изолированном контуре;
• запрещены любые каналы переноса (USB, печать, буфер обмена);
• нельзя гарантировать контроль настроек ОС на рабочем месте;
• ожидаются регулярные проверки, и нужен самый доказуемый вариант.

Простой пример: бухгалтерия работает во внутренней системе, а почта и веб - на отдельном ПК. Даже если пользователь ошибся, он физически не сможет «соединить» сети настройкой в ОС.

Физическая схема на одном ПК: две NIC и раздельная коммутация

Если нужно сделать изолированные контуры на одном рабочем месте на базе одного ПК, самый понятный физический вариант - две сетевые карты (NIC), и каждая уходит в свой коммутатор. Важно, чтобы эти коммутаторы не были связаны между собой аплинками и не попадали в один L2-домен.

Логика простая: одна NIC обслуживает внутренний контур (сеть предприятия), вторая - внешний (интернет или гостевой сегмент). Разделение держится не настройками на ПК, а кабелями и коммутацией, поэтому его легче проверить.

Чтобы схема была действительно «железной», обычно делают так:

• NIC-1 подключают в порт коммутатора контура A, NIC-2 - в порт коммутатора контура B (желательно в разных стойках или хотя бы на разных патч-панелях).
• На рабочем месте ставят две отдельные розетки (или два отдельных порта), а патч-корды маркируют с двух сторон: у розетки и в шкафу.
• Порты на коммутаторах подписывают под конкретное рабочее место и фиксируют в схеме коммутации.
• Запрещают любые «общие» устройства L2: один и тот же неуправляемый мини-свитч под столом, общая док-станция-адаптер, «разветвители».
• Проверяют, что между коммутаторами нет случайного физического соединения (в том числе через резервные кабели в шкафу).

Wi‑Fi как «второй контур» лучше рассматривать только как исключение. Его сложнее контролировать и аудировать: можно случайно подключиться не к той SSID, точку доступа могут переставить, а радиоканал не проверишь так же прозрачно, как провод. Если Wi‑Fi все же нужен для одного контура, разумнее делать его отдельной инфраструктурой (своими точками доступа и отдельной проводной обвязкой), а не «тем же самым» Wi‑Fi, что у другого контура.

Чтобы схему могли проверить и повторить, задокументируйте минимум: какие NIC (по MAC-адресам) относятся к каким контурам, номера розеток и портов на патч-панели, номера портов на коммутаторах и правила маркировки кабелей. На практике это один лист: «ПК - розетка - патч-панель - коммутатор - порт», с датой и ответственным.

Логическое разделение: VLAN, ACL и контроль трафика

Логическое разделение помогает держать два контура в одной кабельной инфраструктуре, но важно помнить: VLAN не равен физической изоляции. VLAN защищает от ошибок на уровне коммутатора, но не спасает, если кто-то включит неправильный порт, настроит trunk на рабочее место или появится устройство, которое начнет маршрутизировать трафик.

Практичный вариант выглядит так: каждому контуру выделяют свой VLAN, а порт к рабочей станции делают access (без тегов) и строго в одном VLAN. Если на одном ПК две сетевые карты, их подключают в разные access-порты разных VLAN. Trunk к ПК почти всегда лишний риск.

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

• любые соединения между подсетями контуров (any-any между VLAN);
• служебные протоколы обнаружения и управления, если они не нужны (LLMNR, mDNS, NetBIOS);
• доступ к DNS и прокси «чужого» контура;
• администрирование сетевого оборудования со стороны пользовательских VLAN.

Отдельная тема - «сервисы доверия». Если контуры действительно изолированы, им нужны раздельные DNS, раздельные прокси и, при необходимости, разные домены аутентификации (или разные зоны/контроллеры). Иначе появляется общая точка, через которую проще «переехать» из одного контура в другой.

На стороне инфраструктуры надежнее разводить контуры по VRF или даже по отдельным маршрутизаторам. VRF помогает держать независимые таблицы маршрутизации, чтобы контуры не «увидели» друг друга даже по ошибке.

Главное ограничение: нельзя полагаться на одну «галочку» в VLAN или на один запрет между подсетями. Защита должна быть слоистой: правильные VLAN, жесткие ACL, отдельные сервисы и минимум исключений, оформленных как правило, а не как привычка.

Запреты маршрутизации и мостов: что должно быть выключено

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

На уровне ОС: убрать все, что «склеивает» интерфейсы

Сначала проверьте, что на машине отключена маршрутизация между сетевыми картами и нет сервисов, которые делают NAT или «раздачу интернета». Это относится и к IPv4, и к IPv6: IPv6 нередко включен по умолчанию и иногда создает неожиданный путь.

Минимальный набор запретов, который стоит подтвердить:

• отключена IP-forwarding (пересылка пакетов) для IPv4 и IPv6;
• не создан «Сетевой мост» между адаптерами;
• выключен общий доступ к интернету (ICS) и любые режимы «раздать сеть»;
• нет локального NAT, VPN в режиме «шлюза» и прокси, слушающего на обоих интерфейсах;
• исключены ситуации, когда ОС «перекидывает» выход через метрику маршрутов и начинает использовать «не тот» интерфейс.

Практический пример: сотрудник подключил внутренний контур и интернет, а затем включил «мобильную точку доступа» или ICS, чтобы «на минуту» дать интернет второму устройству. В этот момент рабочее место превращается в мост между контурами.

На уровне коммутатора и виртуализации: запретить неожиданные мосты

Со стороны коммутатора порт каждого контура должен быть настроен так, чтобы станция не могла вести себя как сетевое устройство. Обычно помогают базовые политики порта: ограничение MAC-адресов, защита от подмены DHCP, отключение всего, что не нужно для роли «конечное устройство».

Если на ПК есть виртуальные машины, отдельный риск создают виртуальные коммутаторы: режим bridge может связать две физические NIC через vSwitch. Правило простое: виртуальные сети каждого контура живут отдельно, без bridge между ними и без «общих» адаптеров управления. Если это рабочая станция для корпоративных задач (например, в проектах системной интеграции), лучше закрепить запреты политиками, а не держать их на «честном слове» пользователя.

Как настроить: порядок работ шаг за шагом

Настройку проще делать по порядку: сначала правила, потом железо и сеть, и только затем ОС и приложения. Так легче доказать, что контуры действительно не пересекаются.

Порядок работ

1. Зафиксируйте требования. Опишите для каждого контура: какие подсети и сервисы разрешены, какие каналы строго запрещены (например, доступ из защищенного контура в интернет, общий DNS, общий прокси, общий файловый обмен).

2. Соберите физическую схему. Запишите, где какая NIC, какой кабель и какой порт коммутатора. Если по политике нужен максимум разрывов, используйте отдельные коммутаторы (или хотя бы разные порты и разные VLAN) и отключите Wi‑Fi, Bluetooth и модемы, если они не нужны.

3. Настройте сеть: VLAN/ACL/межсетевой экран. Разделите контуры VLAN-ами, а правилами (ACL) запретите любой трафик между ними. Важно: не должно быть маршрута «из A в B» ни на L3-коммутаторе, ни на межсетевом экране, ни на самом ПК. Если где-то есть L3, проверьте, что межвлановая маршрутизация между этими VLAN выключена.

4. Настройте ОС. Убедитесь, что отключены IP forwarding, сетевой мост (bridge), ICS/общий доступ к интернету, лишние виртуальные адаптеры (VPN-клиенты, Hyper‑V/VirtualBox свитчи). Разнесите профили сети и правила локального фаервола по интерфейсам. У каждой NIC должен быть свой «мир», без запасных маршрутов через вторую карту.

5. Ограничьте приложения. Разведите DNS (или запретите внешние DNS в защищенном контуре), настройте прокси только там, где он разрешен, и закрепите правила по USB-носителям и обмену файлами политиками, чтобы «обходные пути» не стали мостом.

Что сдать на приемку ИБ

Подготовьте короткий пакет доказательств: схема портов и VLAN, список правил ACL/фаервола, вывод таблиц маршрутизации с ПК, результаты проверок (ping/traceroute, попытки доступа к запрещенным подсетям), протокол с датой, ответственными и версией конфигурации.

Пример сценария: внутренний контур и интернет на одном месте

Сотруднику нужно работать с внутренними документами (файловый сервер, СЭД, почта внутри организации), но иногда заходить в интернет для справок, обновлений и общения с внешними подрядчиками. Задача - сделать так, чтобы «внутреннее» не могло уйти наружу, а «интернет» не мог добраться до внутренних адресов.

Внутренний контур подключают к отдельному коммутатору или порту, который видит только корпоративные ресурсы. На рабочей станции у этой сетевой карты обычно нет шлюза по умолчанию (default gateway), а DNS указывает только на внутренние серверы. Тогда трафик во внешний мир просто не знает, куда маршрутизироваться. Дополнительно на сетевом оборудовании фиксируют правила, чтобы внутренний сегмент не ходил в интернет даже при ошибке настроек на ПК.

Внешний контур дают через отдельный интерфейс (например, Wi‑Fi или второй порт), который имеет выход в интернет. Здесь, наоборот, на шлюзе или на ПК режут доступ к внутренним подсетям и внутреннему DNS. Если пользователь случайно откроет внутренний адрес в браузере, соединение не установится.

Как это обычно выглядит для пользователя:

• две отдельные сессии: рабочие документы во внутренней сессии, браузер для интернета - во внешней;
• или два профиля/две виртуальные машины: «Корпоративная» и «Интернет», перенос файлов между ними запрещен или сильно ограничен;
• разные приложения по назначению: корпоративный мессенджер и файловый клиент - только во внутреннем контуре, публичные почтовые сервисы и сайты - только во внешнем.

Чтобы потом было что проверять, оставьте артефакты:

• схема: какие порты, какие интерфейсы, какие подсети, где стоят запреты;
• снимки настроек: таблица маршрутизации, параметры DNS, правила брандмауэра;
• результаты тестов: пинги/трассировки до внутренних адресов из внешней сессии (должны быть «мимо») и попытки выхода в интернет из внутренней (должны не проходить).

Такой сценарий часто встречается в госорганах и крупных компаниях: рабочие станции подключают к «чистому» внутреннему сегменту, а интернет дают отдельно, без права пересечения сетей.

Тесты, которые подтверждают отсутствие утечек

Проверки удобнее делать по принципу: сначала убедиться, что настройки верные, затем попытаться нарушить изоляцию на L3 и L2, и в конце подтвердить это пассивным наблюдением.

Быстрые проверки настроек

На каждом интерфейсе проверьте IP-адрес, маску, шлюз и DNS. Частая причина утечек - «лишний» шлюз на втором интерфейсе или DNS, который обслуживает оба контура.

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

Короткий набор активных тестов:

• ping до запрещенных подсетей и адресов в другом контуре (ожидаем таймаут);
• traceroute до тех же адресов (ожидаем, что трасса не строится или обрывается сразу);
• попытка подключиться к типовым портам (например, 80/443/445) в «чужом» контуре (ожидаем отказ или таймаут);
• проверка DNS: запросите имя, которое должен резолвить только «чужой» DNS, и убедитесь, что ответа нет;
• проверка L2: отключите и снова подключите кабель, обновите адрес (DHCP) и убедитесь, что адрес не выдается из «чужого» пула.

Пассивная проверка и фиксация результата

Сделайте захват трафика по очереди на каждом интерфейсе и поищите неожиданные пакеты: DHCP/ARP из другого контура, DNS-запросы «не к тому» серверу, широковещательные объявления, которых там быть не должно.

Пример: на рабочей станции с двумя NIC вы запускаете захват на «внутреннем» интерфейсе. Если там появляются DHCP-ответы от интернет-коммутатора или DNS-запросы к публичному резолверу, изоляция нарушена.

Успешный тест - это не «вроде не работает», а повторяемый результат: запрещенные цели недоступны, маршруты не появляются после перезагрузки, DHCP и DNS строго свои. В отчет обычно прикладывают: снимок ipconfig/ifconfig, таблицу маршрутов, ARP-таблицу, результаты ping/traceroute и короткие фрагменты захвата (пары минут достаточно) с отметкой времени и именем интерфейса.

Типовые ошибки и скрытые «мосты»

Даже если контуры настроены, утечки чаще появляются из-за «удобств», которые кто-то включил по привычке. Проблема в том, что ОС пытается «помочь» и незаметно связывает интерфейсы.

Самая частая ошибка - включили общий доступ к подключению или создали сетевой мост. В Windows это может выглядеть как случайно появившийся «Network Bridge» или включенный Internet Connection Sharing. В итоге один интерфейс начинает раздавать сеть другому, и два контура перестают быть независимыми.

Не менее коварен «третий канал», про который забыли: Wi‑Fi, Bluetooth PAN, USB‑модем или телефон в режиме модема. Человек отключил кабель, но беспроводной интерфейс остался активным и стал запасным маршрутом. На рабочих станциях это происходит часто, особенно на ноутбуках или моноблоках.

Что обычно создает скрытый мост между контурами:

• один и тот же DNS или прокси обслуживает оба контура, и запросы начинают уходить «не туда»;
• виртуальная машина или контейнер получили два адаптера и начали пересылать трафик между ними;
• администратор добавил маршрут «временно», чтобы «проверить доступ», и не убрал его;
• включили NAT/маршрутизацию на хосте, потому что так быстрее «поднять интернет»;
• нет приемочного теста, поэтому схема работает «на глаз».

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

Как быстро заметить проблему

Начните с визуальных признаков: появился «мост», включился общий доступ, активны беспроводные интерфейсы, у ВМ два сетевых подключения.

Дальше проверьте базовые вещи на ПК:

route print
ipconfig /all

Ищите неожиданные шлюзы по умолчанию, маршруты в «чужую» подсеть и DNS, который не должен обслуживать оба контура. Без приемочного теста изоляции такие ошибки легко пропустить.

Чеклист и следующие шаги: как закрепить результат

Перед вводом рабочего места в эксплуатацию важно не только настроить два контура, но и зафиксировать, что именно было сделано. Это экономит время при проверках и снижает риск, что изоляция «сломается» после обновлений или замены оборудования.

Короткая проверка перед запуском:

• физика: кабели и порты подписаны, каждый контур уходит в свой коммутатор (или в строго выделенные порты), «случайных» патчкордов рядом не остается;
• сеть: на нужном интерфейсе есть только «свой» шлюз и DNS, нет лишних маршрутов, отключены автоподключения к Wi‑Fi и Bluetooth, если они не требуются;
• ОС: выключены маршрутизация и сетевой мост, установлен запрет на общий доступ к подключению, проверены политики брандмауэра для каждого интерфейса;
• приложения: обновляторы, агенты удаленного доступа и облачные клиенты работают только там, где это разрешено, и не «видят» второй контур;
• тест: выполнены контрольные пинги/трассировки и проверка доступа к типовым ресурсам каждого контура.

После настройки соберите «пакет приемки» для аудита: схему подключений, список MAC-адресов и портов коммутаторов, снимки таблицы маршрутизации, статуса сетевых адаптеров, правил брандмауэра, а также результаты тестов (логи команд или отчеты). Храните это вместе с датой и ответственным.

Регулярная проверка (особенно после обновлений ОС, замены коммутатора или переезда): повторите базовые тесты изоляции и сравните маршруты с «эталоном», убедитесь, что не появился сетевой мост, виртуальные адаптеры или новый «лишний» шлюз. Отдельно проверьте, что порты коммутаторов и настройки VLAN/ACL не изменились, и просмотрите журналы безопасности на предмет неожиданной активности.

Если нужны формальные требования, сложные правила VLAN/ACL и приемочные испытания, имеет смысл подключать системного интегратора. Когда важны локальная поддержка и предсказуемые поставки, такие задачи часто закрывают «под ключ» вместе с рабочими станциями и сервисом: например, через GSE.kz (gse.kz) как производителя и системного интегратора с круглосуточной технической поддержкой.