Просмотр сообщений
81
Компьютеры, периферия, мультимедиа и ПО / Свободное ПО на АЭС ...
« : 27.02.08, 16:29:43 »
А.Г. Полетыкин, Е.Ф. Жарко, И.Н. Зуенкова, В.Г. Промыслов, М.Е. Бывайков, Н.Э. Менгазетдинов
Обеспечение технологической независимости, лицензионной чистоты и безопасности программного обеспечения в атомной энергетике
Аннотация
В статье рассматриваются вопросы обеспечения технологической независимости, лицензионной чистоты и безопасности, возникающие при применении программного обеспечения в АСУ ТП АЭС. Исследуются виды зависимости, источники опасности и излагается точка зрения Института проблем управления им. В.А. Трапезникова РАН на решение этих вопросов.
Введение
Программное обеспечение (ПО) стало одной из составляющих окружающей среды. Оно работает в мобильных телефонах, домашних компьютерах, в магазинах, медицинских учреждениях, предприятиях, на транспорте, в системах жизнеобеспечения, в системах, важных для безопасности, включая ядерную.
Нужно отметить, что во многих случаях используется одно и то же программное обеспечение. Ярким примером является операционная система Windows фирмы Microsoft, применяемая широким спектром пользователей: от игровых залов до третьего энергоблока Калининской АЭС.
В данной статье изложена официальная точка зрения Института проблем управления им. В.А. Трапезникова РАН на обеспечение технологической независимости, лицензионной чистоты, качества и безопасности ПО в атомной энергетике.
1. Технологическая независимость и лицензионная чистота
Технологическая зависимость организации А от организации Б возникает при наступлении одного из следующих случаев.
(1) А использует ПО, произведенное Б, но Б не передает А исходные коды ПО;
(2) Б передает исполняемые и исходные коды ПО А, но не производит обучение персонала А в объеме, необходимом для внесения изменений и доработок в ПО;
(3) Б передает исполняемые и исходные коды ПО А, по возможности обучает персонал А правилам внесения изменений и доработок в ПО, но оставляет за собой через лицензионные соглашения права собственности на ПО, которые позволяют Б контролировать применение ПО.
Случай (1) типичен при применении операционных систем ведущих мировых производителей, SCADA-систем и т. п. Это ? худшая из всех видов зависимостей. В этом случае пользователь ПО зависит о прихотей производителей, которые по своему усмотрению могут менять ПО, что вынуждает пользователей нести значительные расходы по адаптации нового ПО, его испытаниям и т. п. Кроме этого, при использовании продукции иностранных поставщиков зависимость типа (1) может существенно ограничить применение конечного продукта, в котором используется ПО, например из-за эмбарго, политических, конкурентных и других причин.
Случай (2) имеет место при использовании ПО "с открытым кодом". К ним, в частности, относятся версии операционных систем LINUX, компиляторы, Web-броузеры, утилиты и т.п.
В этом случае пользователь имеет возможность получить независимость. Но для этого ему нужно создать группу, лабораторию или целый институт, набрать в него квалифицированных специалистов, которые способны разобраться в исходных кодах ПО и содержать их в течение всего времени эксплуатации данного ПО.
Это требует значительных финансовых затрат и под силу либо государству в целом, либо отрасли (Министерство обороны, РОСАТОМ, Академия наук), либо крупной корпорации (РАО ЕЭС, Газпром и т. п.).
Случай (3) ? это лицензионная зависимость. Часто она наступает при применении ПО "с открытым кодом", произведенным фирмами США и других стран. Примером может служить продукт Open Office фирмы Sun, который будучи продукцией США не может поставляться в ряд стран и организаций. В этом случае определенная зависимость от фирмы или иностранного государства не может быть устранена полностью, а конечный продукт не будет лицензионно чистым.
Если понимать под А отечественные фирмы ? строители АЭС (Атомстройэкспорт, Росэнергоатом), то как им обеспечить технологическую независимость и лицензионную чистоту своей конечной продукции ? энергоблоков АЭС ? от иностранных фирм-изготовителей ПО и политики чужих государств.
Есть только два пути. Первый ? заказывать ПО в России либо у подконтрольных заказчику фирм, либо у государственных организаций, недосягаемых для недружественных действий. К ним относятся федеральные государственные унитарные предприятия РОСАТОМа, институты РАН, федеральные ядерные центры и другие отечественные организации.
Второй путь связан с преодолением зависимости типов (2) и, частично (3). Это можно сделать либо указанным выше способом, либо путем установления контроля над фирмой-поставщиком ПО.
2. Безопасность ПО
Безопасное ПО ? это ПО, выполняющее только возложенные на него владельцем задачи и не выполняющее никаких других.
Для того, чтобы проверить выполнение требуемых задач проводятся испытания.
Однако, выполняет ли ПО другие, непредусмотренные законным владельцем задачи, испытаниями проверить нельзя.
Например, как можно проверить отсутствие закладки в операционной системе, которая содержит суперпароль для входа в систему? Для программиста ответ очевиден: нужно проанализировать исходный код ПО. Иного пути нет.
Иными словами, ПО должно быть подвергнуть операции верификации исходного кода и документации.
Вообще говоря, это утверждение носит характер аксиомы для всех, кто занимается ПО для АЭС, поскольку оно содержится в нормативных документах [ ].
Однако на практике это требование часто нарушается. Так, на третьем блоке Калининской АЭС в системе верхнего блочного уровня (системе, важной для ядерной безопасности) используются операционные системы MS Windows и Open WMS, верификацию исходного кода которых никто не проводил. То есть, используется иностранное ПО, безопасность которого не подтверждена.
Мы считаем, что практика применения на АЭС ПО сомнительной безопасности должна быть законодательно запрещена, а само ПО заменено.
Какая бы фирма, российская или зарубежная, ни разрабатывала ПО для АЭС, процедура его изготовления должна производиться по методам, обеспечивающим качество и безопасность.
3. Заключение
ИПУ РАН является одним из ведущих российских разработчиков технологий и ПО для АСУ ТП АЭС.
В частности, системы верхнего блочного уровня (СВБУ), разрабатываемые в России, базируются не технических решениях, предложенных ИПУ РАН.
ИПУ РАН является разработчиком СВБУ для АЭС "Бушер"(Иран) и поставщиком ПО для АЭС "Куданкулам" (Индия), а также поставляет компоненты ПО и системы на отечественные ядерные установки.
ПО ИПУ РАН, в частности, включает в себя операционную систему, построенную на основе ПО "с открытым кодом", SCADA-систему и другие продукты собственного производства. Более подробная информация представлена в отдельной статье, входящей в данный номер журнала.
Обеспечение технологической независимости, лицензионной чистоты и безопасности программного обеспечения в атомной энергетике
Аннотация
В статье рассматриваются вопросы обеспечения технологической независимости, лицензионной чистоты и безопасности, возникающие при применении программного обеспечения в АСУ ТП АЭС. Исследуются виды зависимости, источники опасности и излагается точка зрения Института проблем управления им. В.А. Трапезникова РАН на решение этих вопросов.
Введение
Программное обеспечение (ПО) стало одной из составляющих окружающей среды. Оно работает в мобильных телефонах, домашних компьютерах, в магазинах, медицинских учреждениях, предприятиях, на транспорте, в системах жизнеобеспечения, в системах, важных для безопасности, включая ядерную.
Нужно отметить, что во многих случаях используется одно и то же программное обеспечение. Ярким примером является операционная система Windows фирмы Microsoft, применяемая широким спектром пользователей: от игровых залов до третьего энергоблока Калининской АЭС.
В данной статье изложена официальная точка зрения Института проблем управления им. В.А. Трапезникова РАН на обеспечение технологической независимости, лицензионной чистоты, качества и безопасности ПО в атомной энергетике.
1. Технологическая независимость и лицензионная чистота
Технологическая зависимость организации А от организации Б возникает при наступлении одного из следующих случаев.
(1) А использует ПО, произведенное Б, но Б не передает А исходные коды ПО;
(2) Б передает исполняемые и исходные коды ПО А, но не производит обучение персонала А в объеме, необходимом для внесения изменений и доработок в ПО;
(3) Б передает исполняемые и исходные коды ПО А, по возможности обучает персонал А правилам внесения изменений и доработок в ПО, но оставляет за собой через лицензионные соглашения права собственности на ПО, которые позволяют Б контролировать применение ПО.
Случай (1) типичен при применении операционных систем ведущих мировых производителей, SCADA-систем и т. п. Это ? худшая из всех видов зависимостей. В этом случае пользователь ПО зависит о прихотей производителей, которые по своему усмотрению могут менять ПО, что вынуждает пользователей нести значительные расходы по адаптации нового ПО, его испытаниям и т. п. Кроме этого, при использовании продукции иностранных поставщиков зависимость типа (1) может существенно ограничить применение конечного продукта, в котором используется ПО, например из-за эмбарго, политических, конкурентных и других причин.
Случай (2) имеет место при использовании ПО "с открытым кодом". К ним, в частности, относятся версии операционных систем LINUX, компиляторы, Web-броузеры, утилиты и т.п.
В этом случае пользователь имеет возможность получить независимость. Но для этого ему нужно создать группу, лабораторию или целый институт, набрать в него квалифицированных специалистов, которые способны разобраться в исходных кодах ПО и содержать их в течение всего времени эксплуатации данного ПО.
Это требует значительных финансовых затрат и под силу либо государству в целом, либо отрасли (Министерство обороны, РОСАТОМ, Академия наук), либо крупной корпорации (РАО ЕЭС, Газпром и т. п.).
Случай (3) ? это лицензионная зависимость. Часто она наступает при применении ПО "с открытым кодом", произведенным фирмами США и других стран. Примером может служить продукт Open Office фирмы Sun, который будучи продукцией США не может поставляться в ряд стран и организаций. В этом случае определенная зависимость от фирмы или иностранного государства не может быть устранена полностью, а конечный продукт не будет лицензионно чистым.
Если понимать под А отечественные фирмы ? строители АЭС (Атомстройэкспорт, Росэнергоатом), то как им обеспечить технологическую независимость и лицензионную чистоту своей конечной продукции ? энергоблоков АЭС ? от иностранных фирм-изготовителей ПО и политики чужих государств.
Есть только два пути. Первый ? заказывать ПО в России либо у подконтрольных заказчику фирм, либо у государственных организаций, недосягаемых для недружественных действий. К ним относятся федеральные государственные унитарные предприятия РОСАТОМа, институты РАН, федеральные ядерные центры и другие отечественные организации.
Второй путь связан с преодолением зависимости типов (2) и, частично (3). Это можно сделать либо указанным выше способом, либо путем установления контроля над фирмой-поставщиком ПО.
2. Безопасность ПО
Безопасное ПО ? это ПО, выполняющее только возложенные на него владельцем задачи и не выполняющее никаких других.
Для того, чтобы проверить выполнение требуемых задач проводятся испытания.
Однако, выполняет ли ПО другие, непредусмотренные законным владельцем задачи, испытаниями проверить нельзя.
Например, как можно проверить отсутствие закладки в операционной системе, которая содержит суперпароль для входа в систему? Для программиста ответ очевиден: нужно проанализировать исходный код ПО. Иного пути нет.
Иными словами, ПО должно быть подвергнуть операции верификации исходного кода и документации.
Вообще говоря, это утверждение носит характер аксиомы для всех, кто занимается ПО для АЭС, поскольку оно содержится в нормативных документах [ ].
Однако на практике это требование часто нарушается. Так, на третьем блоке Калининской АЭС в системе верхнего блочного уровня (системе, важной для ядерной безопасности) используются операционные системы MS Windows и Open WMS, верификацию исходного кода которых никто не проводил. То есть, используется иностранное ПО, безопасность которого не подтверждена.
Мы считаем, что практика применения на АЭС ПО сомнительной безопасности должна быть законодательно запрещена, а само ПО заменено.
Какая бы фирма, российская или зарубежная, ни разрабатывала ПО для АЭС, процедура его изготовления должна производиться по методам, обеспечивающим качество и безопасность.
3. Заключение
ИПУ РАН является одним из ведущих российских разработчиков технологий и ПО для АСУ ТП АЭС.
В частности, системы верхнего блочного уровня (СВБУ), разрабатываемые в России, базируются не технических решениях, предложенных ИПУ РАН.
ИПУ РАН является разработчиком СВБУ для АЭС "Бушер"(Иран) и поставщиком ПО для АЭС "Куданкулам" (Индия), а также поставляет компоненты ПО и системы на отечественные ядерные установки.
ПО ИПУ РАН, в частности, включает в себя операционную систему, построенную на основе ПО "с открытым кодом", SCADA-систему и другие продукты собственного производства. Более подробная информация представлена в отдельной статье, входящей в данный номер журнала.
