home | login | register | DMCA | contacts | help | donate |      

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
А Б В Г Д Е Ж З И Й К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Э Ю Я


my bookshelf | genres | recommend | rating of books | rating of authors | reviews | new | форум | collections | читалки | авторам | add

реклама - advertisement



Открытые стандарты и открытые решения

В главе 7 я рассказывал о преимуществах использования открытого, общедоступного шифрования вместо частного, закрытого. Поскольку единственным свидетельством в пользу безопасности криптографических примитивов является длительное исследование многими специалистами, наиболее выгодно сделать их открытыми. Именно этот довод побуждает любого разумного разработчика системы безопасности использовать открытые решения для всего, что связанно с безопасностью, включая открытый исходный код программного обеспечения.

Обратите внимание: безопасность не имеет ничего общего с функциональностью. Поэтому никакое бета-тестирование не поможет выявить недостатки безопасности. Единственный способ обрести уверенность в устойчивости системы к нападениям – это длительное испытание ее специалистами. И только одним способом можно достичь этого – сделать подробности системы общеизвестными.

Детали хорошо спроектированной защиты не являются секретом. В тайне сохраняются лишь некоторые изменяемые параметры: ключи шифрования, пароли, маркеры доступа и т. д. Противоположность этому – «безопасность через засекречивание» (security by obscurity), где сохранение в тайне деталей системы становится условием безопасности. Если система разработана таким образом, то ее защита довольно хрупкая. Как смогли убедиться разработчики системы безопасности цифровой сотовой связи или схемы шифрования DVD, или интерфейса FireWire, рано или поздно потаенное становится явным. Плохо разработанная система защищена, пока детали остаются в секрете, но быстро ломается, как только о них кто-нибудь узнает. Хорошо разработанная система безопасна, даже если ее детали общеизвестны.

Итак, поскольку хорошая разработка системы безопасности не связана с засекречиванием и можно много выгадать, если опубликовать подробности системы безопасности, имеет смысл поступать именно так. Открытые системы, скорее всего, будут тщательно исследоваться, а значит, будут и более надежны, чем закрытые системы.

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

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

Это наивное утверждение. Обнародование исходного кода увеличивает не количество слабых мест, а осведомленность широкой публики. Производители, держащие исходный код в тайне, скорее всего, небрежны. А производители, делающие свой код открытым, имеют больше шансов обнаружить уязвимые места и устранить их. Засекреченное программное обеспечение ненадежно. Публикация исходного кода обеспечивает большую безопасность, чем сохранение его в тайне.

Однако открытое программное обеспечение не гарантирует безопасность. Нужно помнить о двух вещах.

Во-первых, простая публикация кода не означает автоматически, что его станут исследовать на предмет безопасности, и уж конечно не означает, что этим займутся специалисты. Например, исследователи нашли ошибки переполнения буфера в коде, созданном в Массачусетском технологическом институте для Kerberos, через десять лет после выпуска этого кода. Другой открытый модуль – программа Mailman, предназначенная для работы со списками адресатов конференций, – более трех лет имела бросающиеся в глаза недостатки защиты, пока сам разработчик не пересмотрел код и не обнаружил их.

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

Кроме того, обнародование кода не гарантирует, что проблемы безопасности решаются сразу, как только обнаруживаются. Нет оснований надеяться, что некая часть открытого исходного кода двухлетней давности имеет меньше недостатков, чем часть закрытого кода такого же стажа. Если открытый исходный код интенсивно исследовался, это может быть похоже на правду. Но только то обстоятельство, что часть исходного кода была доступной в течение нескольких лет, само по себе ничего не означает[60].

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

Также обратите внимание, что в этом исследовании полностью игнорируется существенный вопрос о том, как сделать программное обеспечение безопасным в первую очередь на стадии разработки. Использование открытого кода – это, во-первых, стратегия бизнеса и, во-вторых, стратегия безопасности. К сожалению, похоже, что традиционные методы закрытого программного обеспечения более эффективны при создании высококачественного крупного продукта. Возможно, лучше всего в отношении безопасности создать закрытое программное обеспечение и затем сделать его открытым (как поступила Netscape со своим кодом браузера).


Выявление недостатков защиты продуктов при использовании | Секреты и ложь. Безопасность данных в цифровом мире | Перепроектирование и закон