ВМоисеев>nscl,сегодня, 14:29 [15004403]
>Владимир, а у вас нет случаем путёвки на другой глобус ?...

Я не молод, и мне непонятен данный текст.
Что тут непонятного ? Использовать ненадежные и даже недостаточно проверенные системы на критических объектах - смертельно опасно, в том числе в глобальном масштабе. Когда разнесло Чернобыль - активность осела на пол-Европы. Фукусимский пищевой плутоний вполне себе успешно доплыл до побережий Канады и США. Какой адовЪ 3,14-здец случится, если произойдет авария на отечественном объекте, работающим с тысячами тонн химического или биологического оружия - даже представлять страшно.

Опыт Ирана с их Stuxnet, покромсавшим управление центрифугами и немного засравшим окрестности фторидом урана, очень наглядно продемонстрировал глубину текущего звиздеца.
На безопасность во многих промышленных системах много лет забивали болт, наивно считая, что простая изоляция сети от внешнего мира - вполне достаточная мера, а внутри могут жить всякие говнооси типа дос, виндовс-98/2k/nt* и т.п., а намертво прошитые внутрь контроллеров стандартные инженерные пароли, дающие к этим самым контроллерам максимальный уровень доступа - до сих пор чуть ли не норма жизни. При этом до статуса OpenHardware там как до Китая пешком, более-менее глубоко пром-автоматику на предмет безопасности стали изучать совсем недавно, и сколько ещё граблей лежит по пути - никто не знает.

И мне элементарно по-человечески страшно, когда на форуме разработчиков всерьез обсуждают применимость двух-звенок, да ещё с клиентом и СУБД под виндовс, с прослойками типа кривущщего и не отличающегося особой надежностью MDAC, при этом хвастаясь, на каком "няшном" объекте ЭТО планируется внедрять.

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

Умозрительно не смог добиться гарантированной безопасности и масштабирования не только 2-х, но и 3-х уровневой системе. Мозгов не хватило. Добавил ещё 2-ва уровня. Гарантированной безопасности в нашем несовершенном мире не существует. Есть конечно такое направление - математически доказуемая безопасность, но оно пока больше теоретическое, и представляет сугубо научный интерес. Можно лишь учесть ошибки предшественников и не ходить по тем же граблям.

Реализация прототипа , и есть не что иное, как попытка добиться возможности представления клиентам подобных систем, удаленных на географическое расстояние, конфиденциальной информации.Зачем это вообще ? Основная проблема при организации такого доступа - защита конечных точек и управление ключами. Используйте стандартнейший SSH на RSA-ключах в 8192 бит. Это совершенно прекрасно работает и изумительно защищается средствами глубокой изоляции приложений.

Нельзя закрывать крипто алгоритмы и способы передачи симметричного ключа - сиё крайне опасно.А это здесь кто-то предлагал ? Вау.
Опять же, всё придумано до нас. Не будучи криптографом, нет смысла даже пытаться что-то мутить своё в крипто. Надо взять стандартные, проверенные временем протоколы, и сосредоточить все силы на защите конечных точек и управлении ключами.

Если файл текстовый, и выгружается раз в час - выложите его на SSH. Дешево, сердито, и весьма надежно. Нужно постоянное соединение - библиотека OpenSSL, с 1.0.1 версии даже с теплой ламповой отечественной криптографией на ГОСТ-е. Недостаточно параноидально ? Дополнительно закриптуйте выгрузку на открытом ключе получателя. Там есть готовые стандартные решения - PGP и OpenSSL (оно умеет очень много чего в плане крипто), использование x509 сертификатов с отечественным ГОСТом там тоже есть.

Изоляция - передачей выгрузкой через SSH, на ключах, логины извне только под SELinux-restricted учетками, и только на системы с актуальными апдейтами.

А мутить адовые двухзвенки под виндовс, да ещё и с использованием MDAC на таких объектах - преступление.

Если какая-то система просто работала десятилетиями - это НИЧЕГО не говорит о её безопасности. Ваапсче. Системы на аццессе, дбф-ках и файловых базах типа .1СD тоже при более-менее адекватном уровне надежности сервера работали "десятилетиями". До первого вируса-шифровальщика.

Ну, использовать хранимки как механизм безопасности - можно, но только очень осторожно =)

Владимир, а можно поинтересоваться, когда это у нас сервер РСУБД, тем более такой, как MSSQL, стал гарантировать время исполнения запроса ? Мне просто интересно. Что в него данные можно положить - не вопрос, но гарантированть время исполнения ...

И чем предложенный вами алгоритм лучше того, что использован в современных криптосистемах ? В той же PGP / x509 / SSL ? Он также проверен ? А с ГСЧ там всё в порядке ?

Левый зрительПроблемы на этих станциях никак не связаны со сбоями АСУ.
И с чем же они были связаны ? Центрифуги для изотопного обогащения сами поломались ?

Левый зрительНе волнуйтесь, техпроцесс уничтожения на автоматику завязан не сильно.Тогда зачем в теме такие пафосные намеки про уровень безопасности для такого серьезного бизнеса стратегического объекта ? Так и напишите - пишем двухзвенную говноподелку на дельфях + MSSQL с MDAC и ADO для учета рабочих смен дворников и уборщиц. Все данные резервируются на бумаги у тети Люси, базу можно и пролюбить, бэкап не нужен.

Левый зрительНужно только учитывать, что Stuxnet разрабатывался противниками Ирана, именно для целей покромсать центрифуги. Т.е. был неслабый бюджет, участвовали спецслужбы, и без внутреннего инсайда и, вероятно, помощи производителя железа и ПО использовавшихся в АСУ тоже не обошлось.Это высказывание противоречит вашей первой фразе. Или вы считаете, что наши объекты менее круты и им такой серьезно вооруженный противник не грозит ?

Левый зрительСюрприз: винда и, соответственно, извращенный вариант COM - OPC давно промышленный стандарт. Трудно найти железку, к которой не было бы драйвера с его поддержкой.И ? DOS тоже местами пром.стандарт. Он стал от этого безопаснее ?

Левый зрительКонтроллер имеет замочек с ключиком, имеющим, как минимум, 2 положения: RUN, Program. В режиме RUN изменение управляющей логики невозможно. Что же это иранские атомщики-то такие ту-у-упые оказались, ключик видимо повернуть забыли ?

Левый зрительОбычно системы АСУ делаются 3 уровневые. При проектировании обычно исходят из предпосылки, что верхний уровень (скады, бд, и прочее компьютерное барахло) абсолютно ненадежно. Аварийная защита делается на специальных контроллерах, работающих в параллель основным, и не имеющих связи с верхним уровнем. В простейших случаях защита релейная.Вот вас послушать - так прямо всё шоколадно. А безопасники и куча экспертов на каждой второй конференции бьют в набат и призывают хотя бы начать шевелить задницей в сторону усиления защиты SCADA-систем и с кучи всего с ними связанного.
Я вот прямо даже и не знаю, кому верить.

ВМоисеевУправление объектом ведется парой (резервирование) микроконтроллеров с операционной системой реального времени. ОСРВ микроконтроллеров также обрабатывает запросы обмена данными со стороны OPC, который и хранит данные в MSSQL.
Замечательно. То есть MSSQL явно вне системы реального времени. Я так понял, что вопрос про безопасность касался как раз таки этой БД и передачи данных из нее неким внешним получателям ? Тогда какая нафиг разница, что это за данные, и что там за объект ? Сколько хоть данных-то по объему и как часто надо передавать ?

У некоторых появилась возможность хранить весь трафик сессии взаимодействия <клиент,сервер приложений> в надежде получить старый закрытый ключ сервера и дешифрировать.
Если вы не передаете каких-то больших объемов данных, то траффика там будет совсем немного, и эта возможность появилась даже не позавчера.
Кстати, помимо атак на конфиденциальность есть ещё атаки на доступность и атаки на целостность.

В среде прототипа попытаемся закрыть эту брешь. Сделаем так (предложение):
1-8. гуиды, временные ключи... Это все прекрасно. Но самый главный вопрос - проверка доверия ключам сервера и ключам клиента. Конечно, если у вас ключи жестко вшиты - то можно ничего и не проверять. Но ключи надо и менять иногда. А если, как я понял, клиент сильно удален от объекта - то вопрос организации доверия при передаче/обновлении ключей - и есть самая сложная задача. Ну и с ГСЧ не накосячить.

Я не зря спросил, от кого и от чего вы защищаетесь, и в каких условиях. Потому что 100% защиты не существует, а без хотя бы примерных оценок сил противника начинать строить какую-либо защиту бессмысленно.

С уважением, Владимир.