Как бесплатно/дешево связать OPC UA Server и OPC DA Client?

Сообщение **Strohmann** » 02 ноя 2017, 12:39

Здравствуйте, товарищи.

В рамках поиска замены WinCC натолкнулся на хорошую SCADA. Но она поддерживает только OPC DA. Контроллер, в свою очередь, имеет на борту только OPC UA.

Как лучше всего связать сервер и клиент? Все решения, которые находятся беглым поиском являются триальными версиями дорогущих программ.

Insat предлагает дешевый сервер, но он, насколько я понял, поддерживает только абсолютную адресацию. В то время, как Siemens вынуждает (а как иначе назвать то, что сохраняемость переменной настраивается только лишь при включенной опции "Оптимизированный доступ". Не хочешь оптимизировать - проставляй в каждом экземпляре галочку, которая делает весь блок сохраняемым) использовать оптимизированный доступ к блокам, что делает абсолютную адресацию невозможным.

Сообщение **hell_boy** » 02 ноя 2017, 13:28

Что за контроллер и SCADA?

Импортозамещение детектед http://elesy.ru/scada-infinity/descript ... teway.aspx

Сообщение **petr2off** » 03 ноя 2017, 03:33

Насчет infinity я не был бы так уверен. У меня была такая задачка устройство ТОР200 - которое поддерживает протокол OPC DA и OpenScada - которая поддерживает OPC UA. И пробовал я скрестить их с помощью шлюза infinity. Не получилось, хотя запросил софт на пробу официально и с разработчиками общался. Они все таки заточены на собственную среду.

Сообщение **Strohmann** » 03 ноя 2017, 05:45

Контроллер - SIMATIC ET200SP (1510 что-то там, ну да не важно), Simple Scada.
В этой ситуации с OPC UA невольно вспоминается шутка про кучу стандартов и желание создать новый, единый. И вот, куча стандартов лишь пополнилась ещё одним.

Сообщение **Romcheg** » 03 ноя 2017, 08:39

С OPC UA не все так просто - нужно понимать, что его применение повлечет за собой обязательную процедуру сертификации системы во ФСТЭК, либо вы будете использовать это все нелегально (противозаконно, до первого прихода "спецов" от ИБ в АСУТП по защите КИИ с проверками или ФСБ, с их новыми полномочиями по отслеживанию VPN и прочих каналов с шифрованием данных). Кстати, анализируя рынок SDK для данного стандарта, получили на практике очень неприятный результат: большинство западных компаний-разработчиков таких SDK официально закрыли продажи в Россию, по причине санкционной политики, а также запретов с нашей стороны на данные технологии, из-за использования шифрования. И как-то пока мало тех, кто реально осознает проблему использования OPC UA в пром.применении, потому что еще не копнули до ее сути, и есть вероятность, что осознают уже только постфактум, когда к ним придут "дяди" с вопросами показать разрешительные документы на применение этой технологии. :)

Сообщение **LexSL** » 03 ноя 2017, 10:41

Оччч интересно...а как же открытие SDK на github? и потом, OPC UA может использоваться и без шифрования.

А касательно подключения OPC UA server к OPC DA клиенту, то на том же github имеется репозиторий "https://github.com/OPCFoundation/UA-.NET.git", в котором имеется wrapper для этих целей. По правде, сказать он у меня не скомпилировался, так как C++ (да мне и не надо было, у меня была как раз таки обратная задача - OPC DA обернуть в OPC UA)

Сообщение **Romcheg** » 03 ноя 2017, 12:42

LexSL, С такими исходниками еще долго и упорно разбираться надо прежде чем их в продакшн вставлять. А без шифрования стандарт OPC UA - это не просто дырень, это открытые настежь ворота в систему.

Сообщение **VADR** » 03 ноя 2017, 14:07

Romcheg писал(а): придут "дяди" с вопросами показать разрешительные документы на применение этой технологии.

Даже стесняюсь спросить... А что, на OPC DA что-то подобное разрешающее есть???

Отправлено спустя 4 минуты 35 секунд:

Romcheg писал(а): А без шифрования стандарт OPC UA - это не просто дырень, это открытые настежь ворота в систему.

Опять же... а OPC DA - не дыра? Как только надо связать клиента с удалённым сервером - или пихай всё это в домен (далеко не лучший вариант), или делай одинаковые имена/пароли (учитывая, что нередко OPC-сервер требует админских прав на сервере - тоже весело получается), или грохай нафиг практически всю систему безопасности DCOM.

VADR писал(а): Опять же... а OPC DA - не дыра? Как только надо связать клиента с удалённым сервером - или пихай всё это в домен (далеко не лучший вариант), или делай одинаковые имена/пароли (учитывая, что нередко OPC-сервер требует админских прав на сервере - тоже весело получается), или грохай нафиг практически всю систему безопасности DCOM.

Кстати, чем закончилась эта эпопея, если речь про то о чем я подумал? Работает вторая или таки нихт унтерштутц?

Сообщение **VADR** » 03 ноя 2017, 17:27

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

слил образ с первой станции и раскатал на вторую

То есть найти настройки dcom, которые привели систему к работоспособному состоянию, так никому и не удалось.
Обидно. Значит Петрович пока уникальный специалист)

тоже, блин, умники - индивидуальный дистр под каждый аппаратный ключ

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

А вообще - надо было до вашего сервера второй модбас виланом прокинуть и там еще один OPC-сервер развернуть. Делов было бы на копейки, конфигурация тегов почти та же, а мороки с политиками и маршрутизацией модбаса намного меньше. Чуть бы потеряли в скорости опроса, но никто б и не заметил. Но умные мысли, они ж как всегда...

Сообщение **Serex** » 03 ноя 2017, 18:23

Что-то нет на моей памяти удачного применения любого OPC в сколь-нибудь сложных Ethernet-сетях.
Если бы была такая задача, то развернул бы локальную скаду с SQL-database и удаленно делал нужные выборки из этой базы. Как ни крути массовость SQL дает весьма продуманные программные продукты.

Сообщение **VADR** » 03 ноя 2017, 18:35

Serex писал(а): Что-то нет на моей памяти удачного применения любого OPC в сколь-нибудь сложных Ethernet-сетях.

Не могу сказать насчёт удачного применения, но после гемора с OPC DA экспериментировал с OPC UA - разница громадная. Хотя бы возможность налаживать связь поэтапно: наладил и проверил связь без авторизации и шифрования

накатил и проверил авторизацию

накатил и проверил шифрование. Если что-то не работает - понятно, в каком месте копать. А в случае с DCOM-based OPC - или всё работает, или всё не работает, и какой хотфикс какого сервиспака какого продукта всё сломал - фиг его знает.

Сообщение **Romcheg** » 03 ноя 2017, 18:53

VADR, Вот OPC DA у себя прописывал в скаде - и чего-то никаких ключей не использовал ни разу и шифрование даже не предусматривал, даже чтобы его отключать чтобы не использовалось. А вот к набору OPC UA идут в обязательном порядке файлы ключей PGP, да и сам стандарт по транспорту и логике, если без шифрования - это вообще как открытая книга: банальный чистый текст по HTTP, в нотепаде можно все читать и править. Я не утверждаю, что DA - это защищенность, но UA в исходном виде его просто переплюнул, поэтому в нем без серьезного шифрования вообще никак.

Romcheg писал(а): его применение повлечет за собой обязательную процедуру сертификации системы во ФСТЭК, либо вы будете использовать это все нелегально (противозаконно, до первого прихода "спецов" от ИБ в АСУТП по защите КИИ с проверками или ФСБ, с их новыми полномочиями по отслеживанию VPN и прочих каналов с шифрованием данных)

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

Сообщение **petr2off** » 03 ноя 2017, 19:08

Это да. С OPC угадать сложно. Я с OPC DA для ТОР200 почти месяц камлал - заработала, причем почему так и не понял. Как работает категорически не нравится. А на днях Modbus Universal OPC server. За 2 дня запустил. И то эти дни потратил на переписку с поставщиками - что бы комплектный дистрибутив прислали. Это меня в технологии OPC и пугает. Начинаешь читать FAQ по установки - и первое что там рекомендуют - дать максимальные права прочим пользователям. Т.е. если не хочешь геммороя с OPC DA - убей по возможности все защитные механизмы.

Ну жизнь на месте не стоит. Когда появился OPC - даже одно АРМ рядом с контроллером было офигеть как круто, а уж два взаиморезервированных - тем более. Тогда маршрутизацией вообще не заморачивались. На моем первом объекте была супер-инновация по тем временам - вместо хаба стоял свитч).
Структура сетей с тех пор сильно поменялась, а OPC DA как был, так и остался. Да и майкрософт с технологиями как всегда впереди. В самих продуктах от MS от DCOM уже давно уходят. Наверное и промавтоматике настало время. Хотя жизненные циклы того оборудования еще не вышли, верх давно уже пора менять.

Сообщение **Serex** » 03 ноя 2017, 20:20

:) А в это время разрабатываются SCADA, у которых единственный интерфейс работы с оборудованием OPC DA

Я как раз сейчас переписываюсь по проекту, где такая SCADA будет установлена.

Сообщение **VADR** » 03 ноя 2017, 20:24

Romcheg писал(а): Вот OPC DA у себя прописывал в скаде - и чего-то никаких ключей не использовал ни разу и шифрование даже не предусматривал, даже чтобы его отключать чтобы не использовалось.

На разных машинах сервер и клиент? С компьютерами не в домене, не с одинаковой парой имя/пароль и без шаманства в локальных политиках безопасности, настройках DCOM, свойствах проводника и прочих ещё менее очевидных местах?
Если имеются в виду ключи, о которых я говорил - то это аппаратные USB-ключи защиты для конкретного OPC-сервера и скады. И там разработчики применили гениальное решение - под каждый аппаратный ключ свой дистрибутив (в каких файлах отличия - я не искал). То есть в сегодняшней ситуации, когда у меня одна станция в работе и одна в ЗИПе - это нормально. А вот если в работе будет десяток и одна в ЗИПе - тут уж так моментально не переставишь вместо любой, подменив только конфиг.

Romcheg писал(а): А вот к набору OPC UA идут в обязательном порядке файлы ключей PGP

Это если делается шифрование. Если без него - авторизоваться можно и без ключей, по имени/паролю. Но с шифрованием, конечно, же, лучше. И то, что ключи лежат именно в файлах - очень хорошо: удобно при необходимости переносить. Все хитрые способы хранения "у чёрта в заднице" - это "замок от честных людей": лишний гемор честному пользователю и совершенно не помеха потенциальному злоумышленнику.

Romcheg писал(а): сам стандарт по транспорту и логике, если без шифрования - это вообще как открытая книга: банальный чистый текст по HTTP, в нотепаде можно все читать и править.

Я ещё страшнее скажу: весь xml-всегда текст. И что? Если данные представлены в бинарном виде, а не в текстовом, это как-то помешает злоумышленнику с ними работать? Я вас умоляю, не в блокноте же в самом деле он будет это делать :). А чтобы защититься - снова надо шифрование. А шифрование в винде... с ним-то проблем нет? Не помню, чтобы MS поддерживал ГОСТовские алгоритмы :). Впрочем, даже лицензионное соглашение на все известные мне продукты от MS противоречит Гражданскому Кодексу, и что, они запрещены?

Сообщение **hell_boy** » 04 ноя 2017, 10:31

Strohmann писал(а):Контроллер - SIMATIC ET200SP (1510 что-то там, ну да не важно)

https://www.tanindustrie.de/en/Opc.php

Сообщение **hell_boy** » 10 ноя 2017, 16:17

Romcheg писал(а):С OPC UA не все так просто - нужно понимать, что его применение повлечет за собой обязательную процедуру сертификации системы во ФСТЭК, либо вы будете использовать это все нелегально (противозаконно, до первого прихода "спецов" от ИБ в АСУТП по защите КИИ с проверками или ФСБ, с их новыми полномочиями по отслеживанию VPN и прочих каналов с шифрованием данных)

Можно про это поподробнее? Если у меня закрытая от постороннего мира сеть АСУ ТП и в качестве протокола для связи ПЛК и СКАДА используется MODBUS/TCP, то что будет?

Сообщение **Romcheg** » 11 ноя 2017, 08:44

hell_boy писал(а):Можно про это поподробнее? Если у меня закрытая от постороннего мира сеть АСУ ТП и в качестве протокола для связи ПЛК и СКАДА используется MODBUS/TCP, то что будет?

Согласно новым веяниям в ИБ, если ваш объект будет относится к критически важным инфраструктурам, то его будут наблюдать и проверять соответствующие органы для этого создаваемые (они ж вон сейчас как активно пиарятся за эти места тепленькие). Как мы уже не раз убедились по ИБшным докладам - им все равно, открытая ваша система, или закрытая, найти на чем поднять истерику они умеют (это их основной хлеб), Поэтому готовимся, что все Модбасы сразу станут первыми лакомыми кусочками для их интересов. А уж убеждать их, что не верблюд - дело бесполезное.
А по поводу шифрования - видимо никто никогда не сталкивался с этим? Уже давно ситуация здесь такова, что если в ПО или ПТК заявляется функция шифрования, такое решение в обязательном порядке должно проходить сертификацию во ФСТЭК. И им не важно, что у вас где-то на такой-то на такой-то вкладке есть галочка, которая это отключает, или при каких-то условиях шифрование не используется - это абсолютно не важно, если оно заявлено, вы автоматом попадаете под их юрисдикцию. Да, предвижу удивления, что у нас больше половины технологий сейчас получаются вне закона, да, это так, но - до первых проверок, а они уже руки основательно туда тянут. Представляете какой для них куш лежит не охваченный, где можно будет поживиться?

Сообщение **hell_boy** » 11 ноя 2017, 12:03

Есть регламентирующие документы про обязательность сертификации средств шифрования в АСУ ТП? Аудит по приказу ФСТЭК №31 прошли. Меры предписаны такие: контроль сменных носителей, контроль целостности ПО, антивирусная защита, резервное копирование, видеорегистрация действий и контроль физического доступа персонала, внедрение комплексной системы информационной безопасности.

Сообщение **Romcheg** » 12 ноя 2017, 12:10

Применять международные алгоритмы шифрования в нашей стране для защиты тайн (в том числе персональных данных) запрещено.
Чтобы создавать отечественные программные или аппаратные средства защиты информации нужна лицензия ФСТЭК на деятельность по разработке и (или) производству средств защиты конфиденциальной информации. Если продукт будет использовать шифрование, то нужна ещё одна похожая лицензия, но уже от ФСБ.
Чтобы готовый продукт мог использоваться для защиты служебных тайн или персональных данных, необходимо чтобы он был сертифицирован ФСТЭК и, если в нём есть шифрование — то и ФСБ.
Таким образом в нашей стране все что касается средств защиты информации (СЗИ) — вотчина ФСТЭК. Все что касается средств криптографической защиты информации (СКЗИ) — дело ФСБ.
И не важно, АСУТП это или еще что-то, это общие правила.
Как народ шутит: надо пройти 14 "кругов ада" (7 во ФСТЭК и 7 в ФСБ) имя которым «лицензирование» и «сертификация»...

Сообщение **VADR** » 12 ноя 2017, 17:02

Получается, что нельзя:
1. Использовать точки доступа wifi с включенным шифрованием (а без шифрования они представляют из себя дыру)
2. Использовать ssl, tls и т.д. и т.п., включая не только web-сайты, но и разные системы клиент-банк, банковские приложения на смартфонах (кто-нибудь настраивал на смартфоне ГОСТовское шифрование?)
3. Использовать файловые системы с возможностью шифрования данных. Ну, то есть, как минимум: ntfs низзя, fat32 - можно.
4. Использовать сетевые протоколы с поддержкой шифрования. Ну, то есть в сегодняшних реалиях - сети надо бы отключить нахрен все.
Однако всё перечисленное до сих пор применяется.
Кстати... Команда использовать исключительно открытые форматы документов в госучреждениях прошла не менее десятка лет назад. То есть, во всех госучреждениях (и не только - школы тоже посчитали) такие программы, как word и excel должны были перестать использоваться. И?