Как гласит старая восточная поговорка, «на бога надейся, но верблюда привяжи». Эти умные слова применимы ко многим сферам жизни и техники и, в частности, к принятию решения относительно допущения мобильного кода (также известного как апплеты или загружаемые коды) извне в вашу сеть.

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

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

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

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

Действия по защите от мобильного кода зависят от природы используемых приложений и общей системы защиты. Носит ли присутствие Java и ActiveX в вашей организации только периферийный характер? Т. е. попадают ли они только через внешнюю дверь при серфинге в Web? Или на вашем предприятии активно используется документооборот на базе Java?

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

Основные усилия по обеспечению защиты от мобильного кода (как и при организации любой защиты) приходится тратить на убеждение в реальности угрозы и в необходимости выделения средств на ее предотвращение. Руководители отделов и бухгалтеры предпочитают оперировать осязаемыми величинами; они хотели бы получить нечто определенное в качестве отдачи от вложенных средств, будь то новая машина, компьютерная программа или высокопроизводительная кофеварка для комнаты отдыха.

Чтобы помочь потенциальным пользователям составить обоснование, некоторые разработчики продуктов защиты от мобильного кода размещают на своих серверах Web демонстрации разрушительных атак, которые вы можете показать тем, кто в вашей компании отвечает за принятие решений. Finjan готова выслать «живую» демонстрацию, способную как минимум до полусмерти напугать вашего вице-президента.

Эта демонстрация включает безвредного «троянского коня» под названием «Голосуй за Билла!» для показа деструктивного потенциала не заслуживающего доверия мобильного кода. Щелчок на исполняемом файле приводит к появлению на первый взгляд безвредного опроса общественного мнения с одним вопросом о Билле Клинтоне. Выбор ответа «да» или «нет» приводит к запуску хака с созданием на рабочем столе Windows новой папки с соответствующим названием «You Have Been Hacked!». Затем вредоносный код копирует файлы с жесткого диска в группу программ.

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

Как упоминалось ранее, необходимость написания программного обеспечения в предельно короткие сроки ведет к тому, что даже лучшие из лучших программистов допускают ошибки или грешат небрежностью, лишь бы успеть вовремя. При таких условиях разработки меры защиты принимаются уже после написания программы или даже не рассматриваются вообще. Например, вам может потребоваться высококритичное приложение на Java для поддержки электронной коммерции, с помощью которого ваши партнеры по бизнесу могли бы извлекать информацию прямо из вашей базы данных. Такого рода приложения получают все большее распространение и позволяют сэкономить значительное время и деньги. Однако они делают вашу сеть уязвимой для вторжения извне. Помимо создания шифруемого канала через Secure Sockets Layer (SSL) необходимые меры защиты нужно предусмотреть еще на стадии разработки, в частности ввести уровни доступа и параметры защиты, чтобы внешние пользователи не имели доступа к остальной части вашей сети. Если меры защиты не будут приняты с самого начала — еще на стадии разработки, то в такой системе бреши в защите будут обнаруживаться снова и снова.

Тестирование программного обеспечения составляет неотъемлемую часть процесса разработки, но многочисленные существующие инструменты и процедуры тестирования предназначаются обычно для проверки функциональности программы, а не ее защиты. Тестирование функциональности предполагает всего лишь выполнение каждой функции программы для проверки правильности ее работы. Тестирование защиты имеет принципиальные отличия от тестирования функциональности. Оно требует гораздо большей изобретательности и умения предугадывать действия злоумышленника.

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

Анализ рисков призван дать ответы на ряд вопросов, в том числе:

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

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

Другую часть мер защиты от мобильного кода составляет предотвращение попадания внешних, вредоносных или некорректно написанных апплетов внутрь вашей сети. При всей радикальности (и эффективности) такой метод, как полное запрещение выполнения Java и ActiveX во всей сети, становится все более непрактичным. Тем не менее в некоторых средах блокирование мобильного кода по-прежнему применяется. «Я знаю множество компаний, работающих по правительственным контрактам, где использование ActiveX запрещено, — говорит Курт Зиглер из Computer Associates. — Они приобретают наши продукты для выявления фактов использования ActiveX с целью предотвращения попадания этих элементов управления в сеть».

Недавно так называемый Guninski Exploit еще раз высветил всю уязвимость ActiveX. Он использовал дыру, обнаруженную в Microsoft Internet Explorer (IE) 5.0 в августе 1999 года. Ошибка в браузере позволяла запустить на ПК пользователя программу при его обращении к зараженной странице Web или получении зараженной электронной почты HTML. С помощью этой разработки (exploit) злоумышленник мог установить контроль над компьютером пользователя, в том числе копировать и перезаписывать файлы. Guninski Exploit ведет свое происхождение от элемента управления ActiveX под названием «объект конструирования библиотек типов для составления коротких сценариев» из комплекта IE 5 (впоследствии Microsoft выпустила соответствующую заплату).

И Java, и ActiveX имеют встроенные механизмы защиты. Новейшая модель защиты Java позволяет задавать детализированные параметры правил и предусматривает изощренный прикладной программный интерфейс шифрования. Модель защиты ActiveX носит не столь всеобъемлющий характер и по-прежнему базируется на подходе «все или ничего» с низким уровнем детализации. «Java опирается на более структурированный подход, — добавляет Зиглер. — Sun Microsystems предлагает гораздо более надежный способ реализации защиты. Вместе с тем, сознавая, что мобильный код может представлять серьезную угрозу и нанести значительный вред, Microsoft пытается укрепить защиту ActiveX».

Изначально модель защиты Java опиралась на концепцию «ящика с песком» («песочницы») для ограничения доступа к локальным ресурсам. При всей своей эффективности, например для предотвращения доступа апплета к корневому каталогу, такой подход ограничивал полезность Java с точки зрения ее применения в корпоративной среде и опирался на принцип «все или ничего» — т. е. апплет либо признавался заслуживающим доверия, либо не признавался. «Ящик с песком» предназначался для создания закрытой среды выполнения кода без доступа к системным ресурсам (см. Рисунок 1).

Модель защиты в Java 2 вводит несколько новых концепций. Корпоративная модель защиты в Java 2 позволяет задавать детализированные параметры защиты, с помощью которых автор приложения может заранее определить, к чему и при каких условиях апплет имеет право доступа (см. Рисунок 2). Кроме того, она обеспечивает простой способ конфигурации правил защиты (с помощью утилиты Policy Tool), легко расширяемую структуру управления доступом и распространение проверки защиты на все программы Java.

В случае Java 2 после загрузки коду присваивается уровень полномочий в соответствии с действующими правилами защиты. Уровень полномочий определяет уровень доступа к данному ресурсу, в частности право чтения или записи файлов, право подключения к хосту или порту. При отсутствии явным образом заданных прав код не может обращаться к ресурсам, доступ к которым предоставляется в соответствии с параметрами полномочий. Такой контроль доступа может применяться к апплетам Java и другому коду Java, в том числе приложениям, Beans и сервлетам.

Последняя появившаяся редакция комплекта разработки Java (Java Development Kit, JDK) предоставляет средства для реализации контроля доступа в зависимости от того, откуда поступил код и кем он был подписан. Однако сам по себе JDK не предусматривает никаких средств контроля доступа с учетом того, кем выполняется код. Эту функциональность позволяет реализовать служба авторизации и идентификации Java (Java Authentication and Authorization Service, JAAS) компании Sun Microsystems.

Некоторые предприятия предпринимают крайние меры в виде полного блокирования Java и ActiveX. Однако для большинства организаций это представляется ненужным и чересчур ограничивает их возможности. Достижения в технологиях мобильного кода и его потенциальная полезность дают слишком много преимуществ, чтобы у компании не возникало желания поднять крепостной мост и запереть ворота. Однако если доступ мобильного кода все же требуется перекрыть, то это можно легко сделать из Netscape Communicator или IE.

Чтобы блокировать мобильный код в Netscape, откройте меню Options, выберите Security Preferences и затем щелкните на Disable Java. В том же диалоговом окне вы можете блокировать JavaScript и «плюшки».

В IE перейдите в меню View, щелкните на Tools, затем на Internet Options и наконец выберите закладку Security. Здесь вы можете задать уровень защиты — высокий (High), средний (Medium), средне-низкий (Medium-Low) или низкий (Low). Кроме того, щелкнув на кнопке Custom, вы можете задать свои собственные параметры, определяющие, что разрешается, а что запрещается делать.

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

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

Наивысший уровень общей защиты сети обеспечивают продукты с поддержкой централизованного контроля за параметрами защиты. Будь у них полномочия, отдельные пользователи могли бы изменить ограничения защиты, когда им представится шанс просмотреть анимацию или поиграть в игру. По возможности, этого надо попытаться избежать посредством введения правил в масштабах всей компании. Такого рода централизованное управление защитой предлагает Enterprise Desktop Security компании Finjan. В случае его применения любые нарушающие профиль защиты данного ПК действия будут автоматически блокированы, и подозрительный код будет уничтожен до того, как он нанесет какой-нибудь вред. Кроме того, Finjan предлагает SurfinGate и SurfinShield, специально предназначенные для предотвращения проникновения в сеть вредоносных или потенциально опасных апплетов.

С помощью InterScan WebProtect и Web VirusWall от Trend Micro системные администраторы могут определить и реализовать общекорпоративную политику в отношении мобильного кода в зависимости от его источника.

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

Кроме того, Computer Associates приобрела разработчика средств защиты, компанию Security-7, и включила ее пакет защиты от мобильного кода SafeGate и SafeAgent в корпоративную платформу. Вместе с третьим купленным ею продуктом под названием SessionWall они представляют всю гамму средств защиты: обеспечивают защиту от вредоносного кода на уровне шлюза, внутри сети (Intranet) и на уровне настольной системы.

Модель защиты Netscape предполагает выдачу предупреждающего сообщения. Конечный пользователь может сам сделать выбор — разрешить или не разрешить апплету доступ к системным ресурсам. Модель защиты Java 2 предусматривает задание правил заранее, чтобы конечному пользователю не приходилось задавать их динамически. Каждый из подходов имеет свои преимущества — все зависит от целевого пользователя.

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

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

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

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

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

Microsoft поддерживает цифровые сертификаты с помощью Authenticode, функции IE. Authenticode позволяет подписывать элементы управления ActiveX и другие программные компоненты. Недостаток Authenticode и других решений на уровне клиента состоит именно в том, что они являются решениями на уровне клиента: ответственность за принятие нелегких решений в области защиты возлагаются на конечного пользователя. Как следствие, в масштабах предприятия защита может оказаться несогласованной. Как упоминалось ранее, решения на базе сервера с применением брандмауэра или серверного программного обеспечения (такого, как InterScan WebProtect от Trend Micro или Unicenter TNG от Computer Associates) обеспечивают единый центр контроля за политикой защиты, которую конечные пользователи не могут нарушить на уровне настольной системы.

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

При возникновении сомнений относительно благонадежности конкретного владельца сертификата (компании или частного лица) вы можете провести свою собственную проверку. Появляющийся на экране сертификат Authenticode содержит ссылку на Web-сервер инициатора кода, так что вы можете получить более детальное представление о том, чем же занимается его отправитель.

Подход Sun Microsystems к цифровой подписи апплетов Java предполагает помещение кода Java и всех связанных с ним файлов в один файл — так называемый архив Java (Java Archive, JAR). Затем цифровая подпись применяется ко всему файлу JAR. Sun предоставляет для этой цели утилиту с графическим интерфейсом под названием Jarsinger. Эта утилита позволяет подписывать файлы JAR и проверять подписи и целостность подписанных файлов. При генерации цифровых подписей для файлов JAR она использует информацию о ключах и сертификатах из хранилища ключей. Утилита для управления ключами и сертификатами Keytool позволяет создавать и администрировать эти хранилища файлов, с ее помощью пользователи могут управлять своими парами открытых/личных ключей и соответствующими сертификатами.

Единственный перспективный путь защиты от мобильного кода состоит в принятии стандартов и проведении обязательного тестирования и сертификации всего мобильного кода. В настоящее время единый стандарт защиты отсутствует, а независимым тестированием мобильного кода на соответствие практике защиты никто не занимается.

Потребность в подобного рода услугах у разработчиков и системных архитекторов уже назрела, и в Англии такая система уже существует. В Соединенных Штатах общим ориентиром при создании мобильного кода с учетом требований защиты могли бы служить принятые правительственные стандарты, такие, как Оранжевая книга. Формально называемая «Критерии Министерства обороны для оценки защиты компьютерных систем», Оранжевая книга описывает строгий метод оценки эффективности защиты в системах любого типа.

Web — далеко не безопасная игрушка. Последовательная политика защиты в масштабах всей компании является теперь неотъемлемым компонентом любого предприятия. Мобильный код может изменить сами методы работы, но он также способен после одного щелчка мышью вывести из строя всю вашу систему.

Дэн Блачарски — автор множества статей по сетевым технологиям и вопросам защиты. С ним можно связаться по адресу: dblach@pacbell.net.

Дополнительную информацию о Java можно найти на http://www.java.sun.com.

Дополнительную информацию об ActiveX можно получить на http://www.microsoft.com/com/tech/activex.asp/.

Оранжевая книга может служить в качестве общего ориентира при разработке защиты для мобильного кода. См. http://www.fas.org/irp/nsa/rainbow/std001.htm.

Фред МакЛеин, создатель элемента управления Exploder ActiveX, имеет свой сервер Web http://www.halcyon.com/mclain/ActiveX.