Модератор: Глоб.модераторы
да. про это забыл сказать (думал что очевидно).
Далеко не всегда это возможно сделать. Немного это упрощается в доменной структуре, но тянуть домены в АСУТП - нафиг-нафиг.
Решение маленькой кучки и создание большой :). По мне так лучше в АСУТП вообще от продукции MS уходить постепенно...
Какие проблемы может создавать домен в асу тп? Единственная проблема, с которой мы сталкивались на данный момент это отсутствие грамотного администрирования на местах. Но думаю проблема с администрированием будет при любой структуре.
1. Необходимость иметь в системе выделенные сервера в качестве контроллеров домена (минимум - 2). Можно, конечно, применить виртуализацию и запустить контроллеры домена в виртуалках на разных физических машинах, но это решение опять таки не лишённое недостатков.
Next Next" - всё вроде как работает. Как только возникают проблемы - проще переустановить всё "с нуля", ибо в логах информация "столь же правдивая, сколь и бесполезная".
1. Уже не раз сталкивался с ситуацией: выходит версия прикладного ПО под новую версию ОС, под старую разработка прекращается. Старая ОС снимается с поддержки. Производители компьютеров перестают разрабатывать драйвера для нового железа под старую ОС. Старый прикладной софт оказывается не совместим с новой ОС. Итог - приходится вкладывать очень приличные деньги за новые версии прикладного софта, несмотря на то, что новый функционал не особо и нужен (всё необходимое уже было).
1. Это как раз таки плюс. А где хранить важные данные вроде проекта, документации, специального ПО, архива и т.д. кроме как на серверах с аппаратным рейдом, дублированным питанием и прочими плюшками для высокой надежности. А то что их два позволяет вообще практически ничего не бояться.VADR писал(а): 1. Необходимость иметь в системе выделенные сервера в качестве контроллеров домена (минимум - 2). Можно, конечно, применить виртуализацию и запустить контроллеры домена в виртуалках на разных физических машинах, но это решение опять таки не лишённое недостатков.
2. Необходимость дополнительных операций в виде аутентификации и авторизации пользователя и т.п. Это всё - время. В АСУТП станции должны быть "лишённые лишнего и не лишённые не лишнего".
3. Проблемы с отладкой. Когда процедура администрирования умещается в формулу "Next Next Next" - всё вроде как работает. Как только возникают проблемы - проще переустановить всё "с нуля", ибо в логах информация "столь же правдивая, сколь и бесполезная".
1. Зато на этом можно и выиграть. Мы например продаем новые поколения ПТК т.к. старые, работающие на виндовс ХР уже не поддерживаются ввиду прекращения поддержки этой самой виндовс. А так бы поставили ПТК в каком нить 95 году и тяни его лет 20-30. А там проблемы растут как снежный ком, начиная с того что уже половина элементной базы не выпускается и заканчивая тем, что люди уже забыли что там и как за 20 лет и приходится восстанавливать снания чуть ли не с нуля.VADR писал(а):
1. Уже не раз сталкивался с ситуацией: выходит версия прикладного ПО под новую версию ОС, под старую разработка прекращается. Старая ОС снимается с поддержки. Производители компьютеров перестают разрабатывать драйвера для нового железа под старую ОС. Старый прикладной софт оказывается не совместим с новой ОС. Итог - приходится вкладывать очень приличные деньги за новые версии прикладного софта, несмотря на то, что новый функционал не особо и нужен (всё необходимое уже было).
2. Восстановление из резервной копии нормально работает на компьютерах с идентичной конфигурацией. Небольшое изменение - и уже как повезёт: получится драйвера подтянуть или нет. Есть, конечно, отдельные продукты сторонних фирм, умеющие при восстановлении подставлять драйвера, но помогают тоже далеко не всегда.
3. "удобство использования несравненное" только при отсутствии сравнения :)
Да ничего подобного. Для хранения есть, как ни странно, системы хранения :). С дублированным питанием, дублированным аппаратным рейдом с доступом по сети и прочими плюшками. И те же IT-шники активно их используют, несмотря на то, что у них есть пары контроллеров доменов и ещё кучи серверов.Alex question писал(а): 1. Это как раз таки плюс. А где хранить важные данные вроде проекта, документации, специального ПО, архива и т.д. кроме как на серверах с аппаратным рейдом, дублированным питанием и прочими плюшками для высокой надежности. А то что их два позволяет вообще практически ничего не бояться.
Опять же - ничего подобного. В АСУТП оператор не должен заморачиваться такими вещами, как права доступа. У него есть технологический объект, которым надо управлять, и всё остальное подчинено этому. Если с утра владелец предприятия спросит, почему произошёл простой стоимостью в десяток мегаевров, любые объяснения будут впустую. В реальной жизни операторские станции должны быть полностью подчинены основной задаче, и всё что может этому помешать - лишнее. Оператор не должен вводить паролей (и, соответственно, помнить их), станции должны включаться в автомате и предоставлять оператору весь нужный для работы функционал. И не давать делать ничего лишнего. Всё это прекрасно делается без доменов.
В смысле? Низкая квалификация местного персонала? Да ни в коем разе. Это практически никакая информативность логов в системе и практически полное отсутствие в той же системе документации. То, что есть - обычно ничего не даёт.
Можно выиграть - кому? Продавцам систем? Вот выпустила фирма MS ОС winXP, которая имела не так много нового функционала, нужного для работы оператора, по сравнению с win2000. Висту пропускаем как совершенно не годную для таких целей ОС. Потом "семёрка" - и опять из новшеств практически нет нужных в наших задачах. "Восьмёрка" - туда же, где "Виста", "десятка"... фиг его знает, не оценил ещё. С выпуском каждой версии постепенно старые снимаются с поддержки (ну я выше уже описывал...), в итоге конечный пользователь вынужден платить деньги и не получать за них чего-либо нового. Так это, вообще говоря, называется жлобством.Alex question писал(а): 1. Зато на этом можно и выиграть. Мы например продаем новые поколения ПТК т.к. старые, работающие на виндовс ХР уже не поддерживаются ввиду прекращения поддержки этой самой виндовс. А так бы поставили ПТК в каком нить 95 году и тяни его лет 20-30. А там проблемы растут как снежный ком, начиная с того что уже половина элементной базы не выпускается и заканчивая тем, что люди уже забыли что там и как за 20 лет и приходится восстанавливать снания чуть ли не с нуля.
Очень хорошо. Как там в теории надёжности? Первый период - "приработка", в это время вылезают дефекты изготовления и прочая подобная хрень. Техника может ломаться, быстренько за 15 минут перенакатываем и меняем железяку по гарантии. Потом количество выходов из строя снижается, а затем - снова увеличивается ("износ"). Как раз примерно тогда, когда эта техника оказывается снятой с производства и продавцы разводят руками... Конечный пользователь снова попадает на деньги. Ну почему я без проблем могу перенести почти любой линукс на другой компьютер, лишь бы архитектура процессора совпадала (или хотя бы была совместима) и хватало памяти. Все возможные косяки решаются максимум за 5 минут с использованием встроенной документации. В принципе, на моей домашней машине федорка 3 компьютера пережила :). Переустановил только потому, что на новой машине архитектура x64.
А это я сейчас исправлю :)
Это чуть ли не главная проблема, потому что АСУшники и КИПовцы не есть администраторы. Организуя такую сеть Вы вешаете на заказчика ещё одну штатную единицу - админа - или подкладываете ему бомбу замедленного действия.
А Вы не задумывались, сколько всего "лишнего" можно сделать с рабочей станции, которая включена в одну сеть с технологическими контроллерами АСУ ТП, и на которой не настроены системные политики? Именно правильная организация домена позволяет привязать права к компьютеру (да-да, не оператору, а к железке), и сделать это не для одного -двух, сразу всех компьютеров сети (а таких может быть до сотни). И действительно, нечего оператору вводить пароль для входа в операционную систему. Существует идентификация компьютера в сети на основе сертификатов безопасности, автоматический вход рабочей станции в сеть под заранее определенным логином и т.д. На производстве для ограничения уровня доступа с АРМ оператора к управлению ТП должен быть (на мой взгляд) другой метод - ограничение физического доступа к рабочему месту. И разграничение прав на уровне HMI системы диспетчеризации (или SCADA системы, хоть это и не правильное название). Именно потому, что "Необходимость дополнительных операций в виде аутентификации и авторизации пользователя и т.п. Это всё - время", и вопросы о необходимости авторизации должны быть делегированы разработчику интерфейса оператора, а не администратору домена.
Не больше чем разрешат. А ослушаются так пускай за ворота отправляются и ущерб возмещают.
Ну вот, сами решили - сами и разгребаете.
Так это прямой косяк поставщика системы. И не надо собственные косяки прикрывать за счёт заказчика, объясняя ему как всё сложно. А то можно до кучи ещё и сетевые экраны притащить сюда.
Да не может быть, поймите Вы! Сеть предприятия - это одно. Сеть АСУТП - совсем другое. А когда эти вещи объединяются, то геморрой растёт в квадрате а затраты - в кубе, и начинаются вопли про стакснет и blackenergy. И админы у этих сетей разные должны быть физически, точнее в АСУТПшной сети админы вообще должны быть не нужны, иначе офисные адмны обязательно влезут и что-ниюудь покрутят.
С этим согласен. (для этого дописал про физическое разделение сетей - просто не успел отправить до Вашего ответа)
И с этим согласен.
А вот против этого как раз и возражал.
Четко надо понимать, что ИБ отдельно не бывает))) Это всего лишь составная часть общей системы безопасности пром. предприятия. Защита периметра, физическая защита объекта, пожарно-охранные сигнализации, система контроля и управления доступом, видеонаблюдение и т.п. - это все составные части системы защиты. И все попытки, в последние годы, преподнести ИБ как единственную составляющую - это тупой холивар, преследующий коммерческие цели.Dotarev писал(а): Главное, что я хотел сказать - сейчас недостаточно разработчику задумываться о том, как система должна работать. Необходимо задумываться, с какой стороны систему можно сломать. И принимать адекватные решения. Если производство опасное - надо продумывать и сетевую безопасность ЛВС, и сисадмин нормальный на производстве должен быть, и физическое разделение сетей, и разбиение на VLAN, а уж межсетевой экран - тот обязательно найдется. Потому что сервер, собирающий данные с контроллеров и раздающий их на рабочие места - он и выполняет функции межсетевого экрана. Надо это четко понимать.
На живой станции, никого не предупредив, включение в сеть там вообще не планировалось. Коллега выдернул сетевой кабель и продолжил спокойно работать. Прервался на 2 минуты когда админ пришёл ногами смотреть куда подевался коннект и пришлось вежливо и корректно, но отправить его в пешее путешествие обратно. Неправда."Почти все начальники - дилетанты." © hell_boy )))
Если есть в АСУ ТП хоть один компьютер, то уже должен быть человек (администратор), который будет его обслуживать. А если компьютеров много (система довольно большая, несколько десятков рабочих мест, десяток серверов и т.д.) то администратор просто необходим. И не важно при этом домен или рабочая группа, виндовс или линукс. В конце концов сам компьютер тоже имеет полное право сломаться и кто то должен его починить, переустановить ПО при необходимости.
Наконец-то!
И пусть в той теме я не согласен, что ПЛК будут выкинуты как ненужное устройство (хотя всё может быть: простейший ПИД-регулятор из датчика и частотника - реальность; система сбора данных без управления, не имеющая контроллеров - тоже), однако с основной мыслью согласен: если элемент системы не нужен, значит он вреден.
хыхыхы
Да мне даже не пришлось этого делать - Вы сами с абсурда и начали.
Это сказали Вы:
Это даже не абсурд - это серьёзнее.
есть
случается
Во всём мире полно таких людей, но я не держу их под боком и не плачу им зарплату потому что они нужны только когда автомобиль ломается, а случается это нечасто, и часто я поломки могу устранить и самостоятельно. И ещё я не покупаю такой автомобиль, который без специального человека не проедет и ста километров. Но есть люди, которые считают что непрерывный сервис - это в порядке вещей и считают нормальным набить автомобиль такими вещами, которые непрерывно нужно обслуживать и платить за это, ездить в это время на автомобиле, соответственно, они не могут. Автомобили они покупают соответствующие. Это их право, пожалуйста. Разница автомобиля и ПК в АСУТП в том, что геморройный автомобиль типа ренжровера люди покупают себе сами и по своей воле, и только они с этим геморроем живут, это их выбор. А АСУТП продают на сторону, для других людей, и если на этих людей не наплевать то можно сделать так чтобы было удобно. А можно наплевать и закатать им например QNX вместо винды или сеть с доменами - пусть развлекутся, им же скучно. Зато звучит внушительно и выглядит мощно - даром что ни на чёрта не сдалось.
