SCADA и корпоративная сеть: строим демилитаризованную зону

В марте, когда мы делали срочный аудит у клиентов с оборудованием Siemens после первых сообщений о Stuxnet, одним из выводов была довольно очевидная вещь: машина с WinCC стоит в той же сети, что и бухгалтерия с интернетом. Мы это задокументировали и выдали рекомендацию. В апреле клиент вернулся с вопросом: «Хорошо, и что теперь делать конкретно?»

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

Почему не просто VLAN

Первое, о чём говорят, когда слышат «разделить сети» - это VLAN. И VLAN - нормальное средство, мы его использовали. Но VLAN без строгой маршрутизации на уровне L3 - это административный забор, который легко перепрыгнуть. Если на том же коммутаторе кто-нибудь перепишет конфиг или воткнёт тегированный транк не туда - изоляция исчезает. И главное: при IP-маршрутизации между VLAN корпоративного LAN и технологическим сегментом трафик всё равно ходит, просто через конкретные порты. При компрометации машины в офисной сети атакующий получает прямой IP-маршрут до SCADA.

Задача стояла жёстче: чтобы из офиса не было прямого IP-доступа до ПЛК вообще, при этом данные производственной отчётности должны попадать в корпоративную базу в реальном времени.

Что построили

Архитектура получилась трёхзонная:

• Корпоративная сеть - офис, бухгалтерия, ERP, интернет. Обычный LAN, ничего экзотического.
• Технологическая сеть - ПЛК, SCADA-сервер с WinCC, панели оператора. Физически отдельный коммутатор, без выхода в корпоративную сеть и тем более наружу.
• DMZ - промежуточная зона с однонаправленным шлюзом данных.

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

Для производственной отчётности SCADA-сервер пишет данные в буфер на стороне DMZ. Шлюз забирает их и кладёт в базу на корпоративной стороне. Задержка - несколько секунд, для производственной аналитики это приемлемо.

Где было неприятно

Оказалось, что часть ПЛК на объекте общалась со SCADA-сервером по протоколу, который сам клиент не мог чётко описать. «Ну, оно работает, и ладно» - типичная история для промышленных систем, которые запустили лет пять назад и не трогали. Пришлось снимать трафик и разбираться: Modbus RTU через конвертеры, местами OPC DA через DCOM. DCOM - отдельная история, потому что он порождает хаотичные порты и с ним сложно работать даже в обычных сетях, не то что при строгой изоляции.

В итоге для OPC-коммуникации пришлось поставить на границе DMZ выделенный OPC-прокси, который выступает для корпоративной стороны единственной точкой чтения данных - никаких DCOM-соединений напрямую через границу зон. Это добавило неделю к проекту, потому что совместимость OPC-прокси с конкретной версией WinCC пришлось проверять аккуратно.

Удалённый доступ

Отдельный вопрос - доступ поставщика АСУ ТП для обслуживания. На объекте это решалось TeamViewer с дефолтным паролем - мы его закрыли ещё в марте. Теперь нужно было сделать нормально.

Договорились на такую схему: доступ только через корпоративный VPN клиента с двухфакторной аутентификацией, после - прыжок через выделенный jump-хост в технологическом DMZ. Ни прямого RDP, ни TeamViewer. Каждое подключение логируется, журнал доступен клиенту. Поставщику это не понравилось - «неудобно». Мы выразили понимание.

Что не решает эта архитектура

Флешки инженеров-наладчиков. Однонаправленный шлюз защищает от сетевых атак, но если обслуживающий персонал принесёт заражённый USB-носитель непосредственно к машине в технологическом сегменте - это другой вектор. Здесь единственный ответ - организационные меры: запрет съёмных носителей плюс белый список разрешённых устройств через GPO (или аналог для изолированных машин). На объекте это отдельная задача, которую клиент взял на себя внутри.

Кроме того, однонаправленный шлюз не означает, что технологическая сеть теперь безопасна сама по себе - это изоляция от корпоративного LAN, не защита от угроз внутри промышленного сегмента. Если там есть устаревшее ПО, незапатченные ОС на панелях оператора - это отдельная история.

Итог

Проект занял около трёх недель от аудита до сдачи. Основная часть времени ушла не на сетевую архитектуру - она сложилась быстро - а на инвентаризацию протоколов, OPC-прокси и согласование процедуры удалённого доступа с поставщиком.

Если у вас есть SCADA или любая другая АСУ ТП, подключённая к корпоративной сети - первый шаг это понять, что именно и как соединено. Без этого разговор об изоляции остаётся абстрактным. Такой аудит мы как раз и проводим - смотрим на реальную топологию, протоколы, точки доступа и выдаём конкретную картину, а не список рекомендаций из учебника.