Нельзя точно сказать, в каком году программисты начали распространять свои программы вместе с исходными текстами. А вот время, когда ИТ-индустрия обратила серьезное внимание на открытое программное обеспечение, можно определить достаточно точно. В 1998 году компания Netscape заявила, что исходные тексты ее браузера будут доступны всем желающим. Тогда же был придуман термин Open Source, а ОС Linux, разработка которой началась в 1991 году, стала серьезно восприниматься как возможная альтернатива коммерческим операционным системам. Сторонники Linux с самого начала объявили надежность одним из преимуществ программ с открытым кодом, но окончательный ответ на вопрос, что безопаснее — открытые или коммерческие программы, не получены до сих пор.
Для многих «открытое программное обеспечение» — синоним программ, распространяемых на условиях лицензии GPL. Однако на деле это понятие трактуется шире, модель открытого программного обеспечения более многогранна и гибка, а GPL — лишь одна из ее реализаций. (Лицензия GPL требует, чтобы любое программное обеспечение, разработанное на основе GPL-программ, само оставалось таким же, тогда как открытое программное обеспечение допускает и другие варианты лицензий, с более мягкими условиями.) В соответствии с официальным определением открытого программного обеспечения (www.opensource.org/docs/definition_plain.html) лицензия на него должна удовлетворять следующим основным критериям.
Свободное распространение. Открытое программное обеспечение может распространяться как бесплатно, так и на коммерческое основе, если последнее не приводит к нарушению других требований.
Доступность исходных текстов. Открытое программное обеспечение должно распространяться вместе с исходными текстами; в противном случае необходимо указывать способ их получения, доступный потенциальным пользователям. За исходные тексты нельзя взимать дополнительную плату.
Изменяемость исходных текстов. Лицензия должна допускать внесение изменений в исходные тексты и разрешать повторное распространение модифицированных программ на тех же условиях, на которых распространяются исходные программы.
Распространение текстов. Лицензия может ограничивать распространение модифицированных исходных текстов, только если она разрешает распространение модификаций в виде отдельных файлов, которые вносятся в исходный текст основного проекта во время сборки. В этом случае, как и во всех других, лицензия должна допускать свободное распространение модифицированных программ в двоичной форме.
Представим себе такую ситуацию: владелец исходных текстов некоего проекта допускает свободное распространение этих текстов и модифицированных программ в двоичной форме, но не хочет, чтобы его разработка стала базой для других самостоятельных проектов. В этом случае он может ограничить право распространения модифицированных исходных текстов (но не двоичных файлов) «заплатами», которые применяются к основному исходному тексту, остающемуся его собственностью. Разработчик, намеренный получить или создать модифицированный программный продукт на его основе, должен получить исходные тексты у владельца и применить к ним необходимые заплаты. Этот пункт, пожалуй, — наиболее существенное расширение концепции открытого программного обеспечения в сравнении с концепцией GPL. Право модификации исходных текстов может быть ограничено для того, чтобы пользователи знали, чей код они используют.
При оценке влияния идей Open Source на ИТ-индустрию часто упускают следующие важные факты. Во-первых, даже GPL-программы могут быть частью коммерческого проекта. Во-вторых, другие варианты открытых лицензий, например BSD License или Apache License (полный список лицензий, официально признанных открытыми, можно найти по адресу www.opensource.org/licenses), позволяют создавать коммерческие продукты, полностью основанные на открытом программном обеспечении. И те, кто думают, что никогда не пользуются открытыми программами, скорее всего, заблуждаются.
Так, компания Oracle использует Web-сервер Apache в своих пакетах СУБД, в коммерческих вариантах Unix применяется программа sendmail для управления почтой, а ядро Mac OS X основано на коде FreeBSD. Даже такие устройства, как точки беспроводного доступа, могут содержать код, основанный на GPL-программах. Да и в Microsoft Windows Services for Unix входят программы, распространяемые на условиях GPL. Хотя этот инструментарий основан на закрытом коде компании Interix, в него включен, например, компилятор GCC, в отношении которого Microsoft тщательно соблюдает требования лицензии GNU. По словам Джона Лассера, основателя открытого проекта Bastille Hardening System, одна из проблем современного открытого программного обеспечения состоит в том, что очень часто оно присутствует невидимо [1].
Тем, кто опасается использовать открытые программы в системах с повышенными требованиями к безопасности, следует внимательно перечитать лицензии на применяемые ими продукты. Возможно, они уже давно задействуют программы, основанные на открытом коде.
Безопасность и открытость
ОС Linux отвоевала себе значительное жизненное пространство, однако этой системе вместе с другими открытыми программами вряд ли удастся монополизировать компьютерный мир. Открытое программное обеспечение, вероятно, обречено на отставание в таких областях, как мультимедиа, трехмерная анимация, визуальное и речевое распознавание. Это обусловлено хотя бы тем, что многие применяемые в подобных приложениях эффективные алгоритмы защищены патентами. Однако эти области далеки от проблем обеспечения ИТ-безопасности.
Хотя и здесь картина не очень проста. Например, согласно информации сайта www.zone-h.org, ежедневно публикующего данные об успешных сетевых атаках, на долю Linux-систем приходится примерно 66% зарегистрированных взломов, тогда как Windows 2000 и Windows 2003 вместе набрали лишь 26%. Впрочем, такие цифры не столько позволяют ответить на вопросы, сколько вызывают новые. В приведенной статистике, скорее всего, не учитываются уязвимости, связанные с распространением вирусов и троянских программ, хотя в этой области ОС Linux должна лидировать. Полезно было бы сопоставить эти цифры с соотношением Windows- и Linux-систем, подвергшихся атакам.
Любопытно отметить: на долю Windows XP приходится лишь 0,3% взломов. Правда, это вряд ли означает, что Windows XP в 87 раз безопаснее, чем Windows 2000 или Windows 2003. Просто XP реже используется в качестве серверной системы. Важно и то, что число взломов Windows-систем распределено по версиям, а число взломов Linux оценивается «в одной куче». Это не вполне справедливо: уровень безопасности систем на основе SELinux или Bastille Project выше, чем у систем, в которых эти средства отсутствуют или отключены.
В противостоянии Windows и Linux надежность и безопасность входят в состав ключевых вопросов. При этом, как часто случается в жарких спорах, аргументы разного рода смешиваются. От рассуждений об общих достоинствах и недостатках тех или иных моделей разработки их приверженцы незаметно переходят к обсуждению проблем и ошибок конкретных реализаций, а из частных случаев делаются общие выводы, и т.п. Для того чтобы сравнительный анализ безопасности открытых и коммерческих программ стал объективным, необходимо ответить на следующие вопросы.
- Обладает ли сама модель разработки Open Source преимуществами по сравнению с коммерческой моделью? Какое значение это имеет для пользователей?
- Какую роль играют традиции в вопросах обеспечения безопасности, унаследованные той или иной ИТ-экосистемой?
- Сможет ли модель разработки и поддержки Open Source эффективно справиться с ростом сложности проектов?
- Способно ли сообщество Open Source своевременно отвечать на стремительно нарастающие требования к защите?
Сколько глаз увидят исходные тексты?
Фундаментальные принципы модели разработки открытого программного обеспечения были сформулированы в уже упомянутой статье Реймонда:
- делайте ранние и частые релизы;
- стремитесь привлечь пользователей к работе в качестве соавторов или, по крайней мере, в качестве бета-тестеров.
Обе меры преследуют одну цель — увеличить число участников проекта. Сырые релизы продукта не привлекут пассивных пользователей, которые хотят быть исключительно его потребителями. Зато они могут заинтересовать активных пользователей, готовых искать ошибки и вносить исправления в исходные тексты (хотя таких, безусловно, меньшинство). В результате открытые проекты зачастую располагают большей базой бета-тестеров, чем коммерческие разработки. Причем, благодаря наличию исходных текстов, тестировщики могут не только сообщать об ошибках, но и самостоятельно исправлять их. Исходя из этой посылки разработчики утверждают, что их продукты надежнее коммерческих аналогов. Правда, ориентацию на «высококвалифицированных пользователей» можно расценить и как недостаток, поскольку такое открытое программное обеспечение часто оказывается непривлекательным для основной массы потребителей.
В споре о безопасности возможность анализа и исправления исходных текстов всеми заинтересованными участниками процесса расценивается приверженцами идей Open Source как одно из основных преимуществ, связанных с самой сутью открытой модели разработки. Но является ли открытость гарантией безопасности? Должны ли любые программы, связанные с защитой, быть открытыми? Некоторые авторитеты отвечают на оба вопроса утвердительно.
Так, Брюс Шнайер и Винсент Риджмен, автор криптографического протокола AES, полагают [2]: открытое программное обеспечение более безопасно «не только потому, что исходные тексты доступны для исследования большему числу людей, но и потому, что сама природа Open Source заставляет разработчиков писать более ясные коды и более строго следовать стандартам. В свою очередь, это упрощает исследования безопасности кода». А эксперт по вопросам безопасности компании EntireNet Поль Робишо считает, что лишь открытое программное обеспечение может дать гарантию отсутствия «черных ходов». Правда, добавляет он, «если вы не анализируете исходные тексты используемых программ, вы делаете глупость и можете получить по заслугам».
Есть и иные мнения. Аргументация приверженцев коммерческой модели (например, см. www.microsoft.com/resources/sharedsource/Security/ Needham.mspx) в основном сводится к тому, что тщательный анализ исходных текстов на предмет ошибок под силу только высококвалифицированным (и хорошо оплачиваемым) специалистам. Действительно, Windows XP — это примерно 55 млн. строк кода. И сколько же «нетренированных» глаз понадобилось бы для анализа соответствующих исходных текстов на предмет поиска возможных уязвимостей? Примером того, что множество глаз, просматривающих открытые коды, могут не заметить серьезных уязвимостей, являются недавно обнаруженные ошибки в системе идентификации Kerberos. Некоторые из них присутствовали в системе годами.
В Microsoft отмечают: всеобщая доступность исходных текстов упрощает поиск уязвимостей не только для заинтересованных в их исправлении, но и для тех, кто намерен использовать их в собственных неблаговидных целях. Следует добавить, что число ошибок и уязвимостей в программных продуктах, вообще говоря, не прямо пропорционально количеству взломов. Иногда одна-единственная ошибка, «облюбованная» взломщиками, может быть опаснее нескольких, не нашедших применения у хакеров.
Microsoft не прячет исходные тексты от тех, кто, по мнению руководства корпорации, достаточно квалифицирован для поиска ошибок и достаточно ответствен, чтобы не нанести урона безопасности и правам интеллектуальной собственности. Как утверждают в Microsoft, только три категории специалистов обладают достаточными квалификацией, ресурсами и ответственностью и могут реально разбираться в исходных текстах, не нанеся ущерба правам интеллектуальной собственности, это представители госструктур, сотрудники крупных образовательных и научных учреждений, специалисты крупных ИТ-компаний.
В рамках программы Shared Source доступ к исходным текстам предоставлен более чем 70 университетам. Увы, отечественные вузы, как и образовательные организации ряда других стран, в данную программу не входят. Это объясняется высоким уровнем пиратства и опасениями, что предоставление исходных текстов таким организациям может привести к утечке технологий.
Впрочем, к российским правительственным структурам Microsoft недоверия не испытывает. В рамках другой программы предоставления исходных текстов для ознакомления, Microsoft Government Security Program (кстати, наша страна подписала соглашение с Microsoft еще в 2003 году). Результатом стала сертификация Windows и других продуктов Microsoft, позволяющая использовать их в госучреждениях с повышенными требованиями к защите. Так, отечественные криптографические продукты, имеющие необходимые сертификаты, наилучшим образом реализованы именно на платформе Microsoft, что делает соответствующие операционные системы привлекательными для госструктур.
Крупные разработчики коммерческих программных продуктов, заинтересованные в их более тесной интеграции с операционными системами от Microsoft и стремящиеся максимально полно использовать возможности этих систем, также получают доступ к интересующим их фрагментам исходных текстов. Исходные тексты могут получить и крупные предприятия, не занятые непосредственно в сфере ИТ. Условием этого является наличие у них определенного числа легально приобретенных продуктов Microsoft. Российские предприятия пока такому требованию не отвечают.
Немногие возьмутся сегодня отстаивать концепцию security through obscurity («безопасность через неизвестность»), но невозможно доказать и то, что модель Open Source гарантирует большую безопасность. Сторонники коммерческих программных продуктов справедливо указывают: когда речь заходит об уровне защиты и других потребительских свойствах продукта, правильнее сравнивать не методики разработки, а качество готовых продуктов. И в данном отношении у Microsoft — серьезные аргументы. В соответствии с показателем надежности, в котором учитывается количество ошибок, обнаруженных за первые 150 дней пребывания продукта на рынке, решения Microsoft опережают дистрибутивы Linux корпоративного уровня. Например, у Red Hat Enterprise Server означенный показатель составляет 45 ошибок, тогда как у Windows Server 2003 — только 10.
Конечно, неуязвимых систем не существует, поэтому при оценке надежности продукта важно учитывать не только количество ошибок в изначальном релизе, но и то, насколько быстро и полно разработчик их исправляет. Microsoft делает это за 25 дней, а поставщики SuSe Linux — вдвое дольше. При этом Microsoft исправляет все обнаруженные ошибки, а многие разработчики Linux — нет, поскольку обращают внимание только на наиболее «интересные», с их точки зрения, огрехи. Кроме того, Microsoft, как и другие коммерческие производители, обладает специальными механизмами контроля над качеством, выявления и исправления ошибок. В случае с разработчиками открытого программного обеспечения часто приходится полагаться на их честное слово (впрочем, они его, как правило, держат).
Традиции и современность
Корни Linux — это многопользовательские Unix-системы с традиционно высокими требованиями к безопасности и надежности, которые развивались вместе с глобальными сетями и сами в чем-то определили их развитие. Современные версии Windows являются «потомками» систем, предназначенных для персональных компьютеров, требования безопасности которых не были столь строгими. Следует добавить, что в начале 90-х, во время зарождения доминирующего ныне поколения Windows, архитекторы этой операционной системы еще не обратили должного внимания на перспективы развития Сети.
Представители Microsoft отмечают, что неверно сравнивать общее число ошибок в Windows (учитывая все версии) и Linux. Ранние версии Windows появились еще тогда, когда ошибки Linux никто не считал, причем они не были ориентированы на роль Internet-серверов, да и требования к безопасности тогда были другими. На сегодняшний день количество технологий защиты, реализованных в продуктах той же Microsoft, превышает число аналогичных технологий, доступных пользователям открытого программного обеспечения. К их списку относятся идентификация на основе смарт-карт, встроенная технология для построения public key infrastructure, биометрические средства идентификации.
Весьма эффективными рычагами, с помощью которых Microsoft могла бы надавить на распространителей и пользователей Linux, являются обвинения разработчиков открытого программного обеспечения в нарушении прав интеллектуальной собственности на алгоритмы и методы решения задач. Они сталкиваются с проблемами интеллектуальной собственности уже давно, и не только в связи с патентами, принадлежащими Microsoft. Можно вспомнить, например, о мультимедиа-формате MP3, правообладатели которого требуют определенных лицензионных отчислений за каждую копию программного (или аппаратного) MP3-плейера, что делает невозможным бесплатное распространение связанных с MP3 программ. Вследствие этого многие дистрибутивы Linux выходят без средств воспроизведения MP3-файлов и некоторых других популярных мультимедиа-форматов, что снижает их ценность при использовании в домашних и настольных системах.
Проблемы открытого программного обеспечения в области запатентованных технологий не ограничиваются мультимедиа-форматами. По данным организации Open Source Risk Management, в Linux потенциально могут быть нарушены 283 патента, 27 из которых принадлежат Microsoft. Возникает естественный вопрос, почему же корпорация, известная, мягко говоря, недоброжелательным отношением к Linux, до сих пор не применила своего самого грозного оружия? Ведь угроза подачи исков о защите права интеллектуальной собственности против основных дистрибьюторов Linux вполне реальна. И ее нельзя устранить, просто переписав код: речь идет о патентах на идеи и базовые принципы, а новые идеи, увы, появляются реже новых программ. Пользователи коммерческих программных продуктов обычно защищены от подобных претензий, так как их производители берут на себя все издержки и ответственность (см., например, www.microsoft.com/windowsserversystem/facts/ indemnification/indemwp.mspx).
Вопросы сложности
Согласно известному правилу, сформулированному Фредериком Бруксом, автором книги «Мифический человеко-месяц», количество ошибок в проекте пропорционально квадрату числа участников проекта, тогда как объем полезной работы связан с числом участников линейной зависимостью. Если бы закон Брукса действовал безукоризненно, сложные проекты, особенно относящиеся к среде Open Source, никогда не доходили бы до стадии появления стабильной продукции и разваливались бы под лавиной ошибок. Очевидно, что в данном случае закон Брукса не работает.
Чтобы понять, почему это происходит, следует внимательно рассмотреть предпосылки, из которых исходил Брукс. Во-первых, ошибки чаще возникают на стыке элементов проекта, выполняемых разными разработчиками. Соответственно, чем больше «швов», тем больше ошибок. Во-вторых, модель взаимодействия разработчиков представляет собой полный граф (каждый разработчик взаимодействует со всеми остальными участниками проекта), число ребер которого пропорционально квадрату числа вершин.
В то время как первое предположение основано на опыте и, по-видимому, справедливо для любой модели разработки, второе предположение неверно для модели Open Source. Многие разработчики самостоятельно создают отдельные части проекта, общаясь преимущественно с представителями немногочисленной группы core team, своего рода менеджмента открытого проекта. Таким образом, предсказанная Бруксом зависимость должна выполняться только внутри core team, но не в более широких кругах разработчиков.
Отечественная специфика
Как утверждают в Microsoft, по поводу использования лицензионных программных продуктов корпорация проявляет жесткость лишь в отношении успешных компаний, доходы которых позволяют им приобретать лицензионные копии. Что же касается частных пользователей, многие из которых не в состоянии купить лицензионные продукты, Microsoft отказывается от принудительных действий, выдвигая резонный аргумент, связанный с интересами отечественных разработчиков. Очевидно, что ресурсы Microsoft позволяют пережить пиратство в России или, скажем, в Китае, тогда как разработчики из этих стран натиска пиратов порой не выдерживают. От немыслимого демпинга, задаваемого пиратами, более всего страдают те, кто имеют меньший финансовый «запас прочности».
Еще один вопрос: стоит ли развивать отечественную ИТ-индустрию на основе открытого программного обеспечения? Сторонники коммерческой модели справедливо отмечают, что сообществу Open Source недоступна «экспортная модель», с успехом используемая некоторыми отечественными фирмами. Те из них, которые разрабатывают Linux-приложения, лишены возможности продавать свою продукцию за рубеж. Как известно, основной доход Linux-компаний — продажа услуг (техническая поддержка, разработка решений системной интеграции), а экспортировать услуги крайне затруднительно. Интеллектуальная же основа отечественных открытых разработок быстро становится всеобщим достоянием. Кроме того, отечественные разработчики открытого программного обеспечения не могут создать вторичный рынок для собственных проектов, в отличие, например, от компании «1С», которая создает программную инфраструктуру вокруг своих продуктов.
Вероятно, было бы ошибкой воспринимать Open Source как основу отечественной ИТ-экономики. Нынешнее состояние российского рынка программного обеспечения, на которое влияет фактор пиратства и на котором услуги Linux-компаний востребованы меньше, чем сами Linux-программы, делает экспортную модель разработки выгодной не только для самих разработчиков, но и для страны в целом. В то же время отечественные разработчики Linux-систем и прикладных программ являются весьма стабильными.
Кто победит и кому это нужно?
Могут ли производители коммерческих программных продуктов одолеть сподвижников Open Source в конкурентной борьбе? Способно ли коммерческое программное обеспечение уничтожить модель разработки Open Source? Ответ на оба вопроса — скорее нет, чем да. Windows не искоренит Linux в обозримом будущем. И дело тут даже не в технических характеристиках, а в том, что структура разработки Linux слишком аморфна. При всех недостатках, присущих аморфности, она обладает большим запасом прочности и динамичности, чем любая отдельно взятая «жесткая» компания. А уж тем более коммерческая модель не подавит движение Open Source в целом. Модель открытого программного обеспечения в том виде, в каком мы ее знаем, возникла вместе с активным развитием Internet и исчезнет разве что вместе с Сетью.
Защитники коммерческой модели постоянно указывают на недостаточно высокий уровень профессионализма и мотивации у разработчиков открытого программного обеспечения. Это не совсем так. Далеко не все разработчики открытых программ являются любителями-дилетантами — некоторые профессиональные высокооплачиваемые программисты пишут открытые программы в свободное время. Нет оснований предполагать, что они будут хуже программ, написанных теми же программистами за деньги. Какой смысл делать вполсилы то, что можно вообще не делать?
К тому же профессиональные разработчики открытого программного обеспечения выставляют свою репутацию на суд не только сообщества Open Source, но и официального работодателя. Скажем, основоположник открытого проекта Looking Glass программист компании Sun Microsystems Хидея Кавахара в течение года разрабатывал «десктоп» Looking Glass в свободное время. Сейчас этот проект поддерживается Sun, но остается открытым. Да и вообще взаимодействие разработчиков открытого и коммерческого программного обеспечения далеко не всегда характеризуется как противостояние. Такие компании, как Oracle, Sun и IBM, поддерживают открытое программное обеспечение уже тем, что выпускают версии коммерческих продуктов для ОС Linux.
Возможно, ни одна компания в мире не способна бросить на разработку массовой операционной системы такие финансовые и интеллектуальные ресурсы, как Microsoft. Сопоставимые ресурсы могут быть только у Internet-сообщества в целом. Как сказал Линус Торвальдс, «если кто-то сумеет точно сформулировать задачу, обязательно найдется тот, кто ее решит». Кроме того, разработка открытого программного обеспечения чем-то напоминает биологические процессы с их самоорганизацией и естественным отбором. Финансовая слабость разработчиков открытого программного обеспечения иногда становится их силой. Колебания курса акций меньше влияют на разработку Linux, чем на разработку коммерческих программ. Многие «доткомы», пытавшиеся сделать Linux источником прибыли в 2000-2002 годах, разорились, но сам процесс разработки Linux продолжился.
А некоторые сторонники идей Open Source мечтают о крушении коммерческой модели. Надо сказать, это маловероятно, но если бы такое крушение произошло, обломки неизбежно засыпали бы и модель открытую. Дело не только в том, что открытое ПО не способно решить всех задач ИТ-отрасли. Сами коммерческие компании-разработчики часто оказываются полезными для разработчиков открытых программ (как и наоборот). Тот же Кавахара вряд ли сумел бы создавать свой Looking Glass, если бы не получал зар?плату в Sun, а услуги, оказанные сообществу Open Source корпорацией IBM, оказались бы, скорее всего, невозможными, если бы IBM не продавала собственные коммерческие продукты (в том числе для Linux).
В противовес приверженцам идей Open Source, которые утверждают, что подобное программное обеспечение непременно должно оказаться более безопасным, чем «закрытое», большинство аналитиков считают открытые продукты «не менее надежными, чем закрытые». Это звучит не так оптимистично, как хотелось бы фанатичным сторонникам модели Open Source, но достаточно обнадеживающе для тех, кто рассматривает возможность использования открытого программного обеспечения. А его развитие в ближайшее время будет осуществляться в том же русле, в котором оно оставалось все последние годы. Основные достоинства и недостатки открытого программного обеспечения, по-видимому, сохранятся.
Современная статистика не дает однозначного ответа на вопрос о том, что более безопасно — открытое или коммерческое программное обеспечение. Если при выборе системы основной акцент делается на обеспечении безопасности, возможно, как основу решения следует воспринимать человеческий фактор. Проблемы безопасности не являются чисто технологическими и во многом вырастают из сложностей человеческих отношений. Не случайно многие популярные решения в этой области, например поддерживающие мандатный контроль доступа, стремятся обезопасить системы от воздействия не только внешних, но и внутренних угроз. Некомпетентный и недостаточно мотивированный персонал может сделать небезопасной любую систему — вне зависимости от того, какие технологии применяют ее разработчики.
Выбор базового программного обеспечения для построения ИТ-системы зависит не только от финансовых возможностей компании и ее отношения к вопросам лицензирования, но и от доступности специфических решений или услуг в рамках конкретной модели создания и распространения программ, специфики существующей ИТ-структуры, квалификации персонала и многого другого. Универсального рецепта дать, пожалуй, нельзя. Сегодня ситуация и в мире открытых, и в мире коммерческих программ достаточно стабильна, поэтому аргументы в пользу той или иной системы не утратят своего значения и в ближайшем будущем.
Литература
- Information Security Magazine, 2001, No. 3.
- David A. Wheeler. Secure Programming for Linux and Unix HOWTO, 2003.
