Возможна ли разработка качественного программного обеспечения за «железным занавесом»?
Недавняя законодательная инициатива депутатов Геннадия Гудкова и Александра Хинштейна, которые предлагают отказаться от использования программных продуктов западных производителей в ряде отраслей, критических для национальной безопасности страны, породила немало споров. Многие специалисты полагают, что законодатели, движимые благими намерениями, мягко говоря, не до конца представляют себе масштаб задач, который они предлагают решить отечественным программистам, существо технических проблем информационной безопасности, а также закономерности международного разделения труда в инновационной сфере.
На вопросы обозревателя еженедельника Computerworld Россия Павла Куприянова отвечает директор Института системного проектирования РАН член-корреспондент РАН Виктор Иванников, который не понаслышке знает, каково это — разрабатывать информационные технологии за «железным занавесом».
Как вы относитесь к новой законодательной инициативе?
Для начала хочу напомнить об уже подзабытой вещи — «проблеме 2000 года». Тогда тоже нагнеталась истерия, утверждалось, что настанет конец света — остановится железнодорожный транспорт, авиационные перевозки, произойдет что-то страшное на атомных станциях. Это происходило и у нас, но особенно в США, где на решение так называемой «проблемы» были направлены огромные бюджетные деньги. Между тем решение подобного рода технических задач — дело конкретных предприятий, а не государства.
|
| Виктор Иванников: «Программные системы, за исключением самых специальных, которые разрабатываются исключительно в интересах военного ведомства, обречены» |
В результате, с одной стороны, шли многочисленные конференции в дорогих отелях. А с другой — анализ программ, с тем, чтобы немного подправить представление дат. И все, как и предполагалось специалистами, а не политиками, не генералами, все прошло спокойно, без потрясений.
Законодательная инициатива, авторы которой из соображений безопасности предлагают переходить на разработку программного обеспечения для критических отраслей внутри страны, во многом объясняется компьютерным невежеством парламентариев и других заинтересовавшихся лиц. Впервые услышав о таких далеко не новых явлениях, как «троянские кони», и встревоженные за судьбу страны, они предлагают закон, который должен спасти Отечество. Но можно предположить, что на самом деле речь идет скорее о лоббировании интересов определенных отечественных компаний, которые ничего существенного не сделают, это очевидно, но бюджетные деньги освоят.
Расскажите подробнее о троянских конях.
Это вещь давно известная. Это те программные, а может быть, и аппаратные компоненты, которые тайно закладываются в систему и с помощью которых можно ее заблокировать или нарушить ее нормальное функционирование.
В качестве возможно самого яркого проявления троянских коней вспоминают один эпизод арабо-израильской войны, когда во время воздушного сражения в долине Бекаа была парализована система управления сирийской авиацией. Тогда соотношение сбитых самолетов было колоссальным в пользу израильских летчиков, потому что сирийские «ослепли».
На практике троянские кони встречаются очень широко. Помимо нанесения какого-то вреда, троянские кони могут использоваться и как средство защиты от несанкционированного распространения компьютерных программ. Производители, ищущие средства защиты от того, чтобы бесплатно не использовали их продукты, вносят троянских коней, которые в случае незаконного копирования приводят к постепенной деградации системы.
Можно ли эффективно находить троянских коней?
Проблема их поиска относится к классу принципиально нерешаемых задач. Приблизительно так же, как является неразрешимой на первый взгляд гораздо более простая проблема мертвого кода. Мертвый код — это такая часть программы или электрической схемы, которая никогда, ни при каких условиях, ни при каких входных данных не выполняется.
Это существенная проблема, особенно для систем с ограниченной памятью. Мертвый код может занимать до 30% программы, особенно его много получается при развитии приложений, ведь в них вносятся все новые и новые куски. Проблема мертвого кода алгоритмически неразрешима. Это значит, что я не могу создать такой инструмент, который для любой программы находил бы мертвый код. Но бороться с этой проблемой надо, нужно создавать инструменты, которые помогают человеку находить мертвый код. И в некоторых сомнительных случаях решение должен принимать человек.
Этой проблемой заинтересовались в начале 50-х годов. Соответствующие теорема Райса и теорема Успенского были доказаны одновременно и независимо, только у Владимира Андреевича она формулируется более обобщенно. Теоремы фактически гласят, что распознавание любого нетривиального свойства алгоритма является неразрешимой проблемой.
Обнаружение троянских коней тоже относится к неразрешимым проблемам. Вся беда в том, что нет никаких инструментов, которые помогают находить троянских коней. Это одна из крайне интересных задач из области теоретической безопасности. Безусловно, нужно работать в этом направлении, создавать инструменты. Мне попадалось достаточно много научных статей по поиску троянских кодов. Но на поверку это были работы в области поиска вирусов, то есть поиска по известной сигнатуре. Когда мы имеем дело с троянскими конями, непонятно, что именно искать. Здесь важно, что в программе содержится такой компонент, который делает то, что находится вне ее известной функциональности.
Помогает ли решению этой проблемы открытие исходного кода?
Это помогает в случае маленьких программ. Но взять, например, Windows — это 75 млн. строк связного текста. Мыслимо ли провести за разумное время его аудит? Очевидно, нет. Да и вообще любые большие программы — полмиллиона строк, миллион — как в них найти что-то?
Все равно, конечно, приходится проводить аудит, устраивать дополнительные тестовые прогоны, другого выхода нет. В общем, этот вопрос остается открытым.
Раз чужой программный код проверить невозможно, может быть, стоит создавать свой?
Что касается обсуждаемого законопроекта, его нелепость заключается в том, что безопасность является не единственным требованием к информационным системам. Да и безопасность не ограничивается троянскими конями. Скажем, распространение на компакт-дисках информации, которая была взята из Центробанка — это тоже нарушение безопасности. Это аспект проблемы, который нужно решать организационными методами. В Центробанке он не был решен, и результат плачевен. Подобные законодательные меры бессмысленны уже потому, что затрагивают лишь технический аспект проблемы безопасности.
Кроме того, каждая организация, когда заказывает создание какой-то информационной системы, описывает свои требования к ней, в том числе и требования по части безопасности. Поэтому законодательно целесообразно регулировать ответственность организации за соблюдение требований безопасности, а не диктовать конкретные технические шаги по обеспечению безопасности.
Еще один аспект. Лет восемь назад я встречался с Эдвардом Фейгенбаумом, главным экспертом ВВС США. Группа под его началом составила документ о стратегии в области программного обеспечения в интересах военного ведомства. Это многотомный труд, в котором все тома, кроме одного, секретные. Что мне в этом томе особенно запомнилось — это требование, чтобы любая программа, кроме сугубо специальных, имела двойное назначение. То есть могла использоваться за пределами военного ведомства. Ибо программы, которые разрабатываются исключительно в интересах военного ведомства, обречены.
Почему?
Потому что военные ведомства очень сильно бюрократизированы. Те программные системы, которые они создают, ориентированы на многолетнее применение, но все устаревает. Только при широком использовании программного продукта возможна его профессиональная критика и улучшение. Чем шире используется продукт, тем выше становится его качество по надежности, по функциональности, потому что обеспечивается эффективная обратная связь.
Вы хотите сказать, что создать новую технологию изолированно нельзя?
Куда нас толкают авторы этой законодательной инициативы — это то, что мы уже проходили. Создание технологий в изолированной среде — это было в Советском Союзе, этим и было вызвано наше отставание компьютерной сферы. С точки зрения изолированного производства более выгодно производить копирование, чем собственную разработку. Постепенно копирование затягивает.
Этот процесс начался в середине 60-х годов, когда было принято решение копировать ЕС с IBM/360. Позаимствовали программное обеспечение, архитектуру машин, потом начали копировать микропроцессоры Intel 8086. А вот 80286 уже не смогли. В общем, попытка воспроизвести чужие разработки всегда приводит к застою в отрасли.
Но так ли нужно таким отраслям, как транспорт или оборонная промышленность, все самое последнее? Может быть, лучше использовать свое, но надежное?
Здесь мы опять возвращаемся к разговору о размере программ. Я уже упоминал Windows — это 75 млн. строк. Исходите из того, что сейчас производительность труда программиста бешено выросла, и она составляет где-то 15 тыс. строк в год. Легко вычислить, что на создание системы аналогичного размера уйдет 5 тыс. человеко-лет. Есть ли у нас соответствующие столь масштабным задачам коллективы?
Какие существуют альтернативные способы обезопасить программное обеспечение?
В качестве одного из примеров я могу привести созданную в нашем институте технологию, которая позволяет автоматически генерировать тесты для проверки правильности программ. Особенно хорошо она работает с ОС Linux, в которой тоже много ошибок.
Конечно, верификация позволяет проверить лишь процесс выполнения программой своих функций. «Троянов» она не выявляет. Но катастрофы случаются не только вследствие наличия злого умысла, но и вследствие обычных ошибок. Наиболее известны примеры с космическими аппаратами, что у нас, что в США. Скажем, посадка на Венеру спускаемого аппарата, которая провалилась из-за известной ошибки в программном обеспечении. Конечно же, ошибки, которая стала известной потом. Поэтому верификация программ — один из ключевых вопросов.