Использование демилитаризованной зоны DMZ в системах АСУ ТП. Или немного про информационную безопасность

Часто встречающейся задачей в создании верхнего уровня АСУ ТП является необходимость организовать доступ к технологическим данным удаленным пользователям. Эти пользователи могут находиться как во внешней офисной сети предприятия, так и в других сетях или интернет. Ещё одной распространенной задачей является ретрансляция данных.

Сразу возникает задача защитить технологическую сеть от злоумышленников. Наиболее распространенное решение этой задачи приведено на рисунке 1.

Межсетевой экран (Firewall) настроен таким образом, что пропускает трафик из внешней сети в технологическую только для IP-адреса сервера технологических данных какого-то определенного порта.

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

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

Межсетевой экран (Firewall) №1 разрешает доступ из внешней сети в демилитаризованную зону и запрещает доступ из демилитаризованной зоны во внешнюю сеть. Межсетевой экран №2 запрещает доступ из демилитаризованной зоны в технологическую сеть и разрешает доступ из технологической сети в демилитаризованную зону. В результате получается, что доступа из внешней сети в технологическую нет. На рисунке 2 приведена схема с двумя межсетевыми экранами, на рисунке 3 с одним.

 

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

Чтобы такая схема заработала, необходима такая структура ПО:

  1. В технологической сети должно быть приложение Master, которое бы являлось инициатором обмена. По собственной инициативе подсоединялось к заданному IP-адресу и принудительно закачивало в него данные.
  2. В демилитаризованной зоне должно быть приложение Slave, которое принимает входящие соединения от приложения Master. В случае подключения Masterа, Slave пассивно принимает от него поток информации и обновляет свою внутреннюю базу данных.
  3. Приложение Slave предоставляет данные клиентам из внешней сети (протоколы МЭК 60870-5-104, ModBus TCP, БД и т.д.).
Настройка SCADA-системы ГИнЭС для работы в DMZ

Настройка приложения Master. Выберите пункт меню «настройки – параметры ОРС, запуска, список пользователей». На вкладке «демилитаризованная зона» поставьте галочку «Работать с демилитаризованной зоной». Отметьте «Ведущим», введите TCP порт, введите IP-адрес. Нажмите ОК.

Настройка приложения Slave. Выберите пункт меню «настройки – параметры ОРС, запуска, список пользователей». На вкладке «демилитаризованная зона» поставьте галочку «Работать с демилитаризованной зоной». Отметьте «Ведомым», введите TCP порт (он должен совпадать с портом приложения Master). Нажмите ОК.

Скачайте пример ниже. Запустите Slave_DMZ.exe, затем Master_DMZ.exe. Для изменения значения параметра в Master необходимо кликнуть по области со значением (состоянием). Состояния телесигналов (дискретных входов) изменяется на противоположное. При клике на значении телеизмерения в появившемся окошке необходимо ввести новое значение. Значение Slave изменится само.

Если сначала был запущен Master_DMZ.exe, затем Slave_DMZ.exe, то Master соединится со Slave в течение минуты.

Схема работы ПО и направления передачи информации приведена на рисунке 4.

 

 

Пример работы SCADA-системы ГИнЭС в демилитаризованной зоне Скачать пример работы SCADA-системы ГИнЭС в демилитаризованной зоне

{nice1}