Новая модель защиты для платформы Java

Защита информации - одна из основных особенностей технологии Java, реализующих возможность использования этого языка в сетевых средах. Наличие функций защиты информации в основных библиотеках и архитектуре виртуальной машины Java предусматривалось изначально. В JDK 1.0, однако, система защиты информации была недостаточно гибкой и плохо поддавалась настройке. В JDK 1.1 появилась возможность помечать программы цифровой подписью, несколько улучшившая функциональные характеристики механизма безопасности Java. С появлением новых функций защиты информации модель безопасности JDK 1.2 стала еще более гибкой и поддающейся настройке. Одним из главных компонентов JDK 1.2, претерпевших изменения по сравнению с предыдущими версиями, стала именно модель защиты информации.

Защита информации в JDK 1.0: "песочница"

JDK 1.0 был снабжен моделью защиты информации, которая позволяла без опасений выполнять код, поступающий из непроверенных источников. Такой код работал внутри так называемой "песочницы", предотвращавшей выполнение операций, которые могли привести к нежелательным последствиям. Браузеры, поддерживавшие эту модель, не допускали выполнение апплетами многих действий, в том числе операций чтения/записи на локальный диск и установления соединений с любыми ресурсами, помимо сервера-источника.

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

Защита информации в JDK 1.1: цифровые подписи

В JDK 1.1 были введены контейнеры для Java-программ - архивы JAR, - и появилась возможность помечать их цифровой подписью. Такая подпись дает возможность выполнять аутентификацию и верификацию JAR-файла. (Первое позволяет получить сведения о создателе программы, а второе - убедиться в том, что никто ее не изменял с момента подписания.)

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

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

Новые функции JDK 1.1 облегчили жизнь программистам, но не могли удовлетворить требованиям сетевых администраторов. Привилегии выдавались подписанным JAR-файлам по принципу "все или ничего" - примерно такая же модель защиты информации используется в средствах управления ActiveX. Если код признается заслуживающим доверия, он получает полный доступ к системе. Сетевые администраторы не могли ограничивать его частично.

Хотя с помощью JDK 1.1 можно было создавать произвольные "песочницы" для Java-приложений, это требовало кропотливого труда и было не под силу неопытному пользователю. Кроме того, необходимость в таких специализированных средах защиты информации возникала не слишком часто. Большинству разработчиков они не были нужны; апплеты просто должны были выполнять какие-то полезные действия. (Другими словами, программисты всеми силами старались обойти налагаемые системой защиты информации ограничения.) Одним из основных недостатков архитектуры безопасности JDK 1.0 и 1.1 было отсутствие единого API-интерфейса защиты информации, который позволил бы преодолевать границы "песочницы".

Защита информации в JDK 1.2: расширенная "песочница"

Механизм защиты информации JDK 1.2 расширяет модель безопасности JDK 1.1, предоставляя более гибкий контроль над привилегиями апплетов, поступающих из заслуживающих доверия источников. Возможности остальных программ по-прежнему ограничиваются "песочницей", определенной JDK 1.0. Новая модель позволяет администраторам выборочно отключать ограничения для программ, помеченных цифровой подписью.

По умолчанию заслуживающие доверия программы выполняются в так называемой расширенной "песочнице" (Extended Java Sandbox). Расширенная "песочница" отличается от обычной возможностью доступа к выделенному участку локального жесткого диска (/sandbox). Создание расширенной по настройке системы "песочницы" происходит автоматически, без каких-либо действий со стороны администратора.

Архитектура JDK 1.2

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

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

Принцип действия

При осуществлении запроса к API на выполнение "опасных" действий (например, чтения из файла) объект Java, называемый "контроллером доступа" (access controller), определяет, разрешить операцию или нет. Свое решение контроллер доступа принимает на основе проверки содержимого стека вызовов (call stack).

Каждый метод в стеке вызовов является членом одного из классов; каждый класс принадлежит к одному из доменов защиты; каждый домен защиты устанавливает свою политику (набор прав). Таким образом, каждому методу в стеке вызовов присвоен некий набор прав.

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

Привилегированные домены

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

Привилегированные домены дают API Java возможность выполнять "опасные" операции от имени кода, заслуживающего меньшего доверия. Допустим, не заслуживающий доверия апплет (не имеющий разрешения на считывание данных из локальных файлов) делает запрос к API на вывод символов шрифтом, хранящимся в локальном файле. Если домен защиты соответствующего кода API является привилегированным, то контроллер доступа даст разрешение на операцию. Это произойдет несмотря на то, что глубже в стеке находится метод, у которого нет права на чтение из локальных файлов.

Единый набор правил для апплетов и приложений

Следует отметить, что в модели безопасности JDK 1.2 появилась возможность использовать один и тот же набор правил безопасности для приложений и апплетов.

Строго определенный диспетчер защиты информации

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

Создание диспетчеров безопасности с помощью JDK 1.0 и 1.1 было чревато серьезными трудностями, поскольку при решении подобной задачи легко допустить ошибку, которая может привести к образованию бреши в системе безопасности.

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

Производительность

Из вышеперечисленного логично было бы сделать вывод, что новый механизм защиты информации существенно замедляет выполнение вызовов API Java. Однако в JDK 1.2 использован ряд методик, позволяющих ускорить процесс проверки прав. Контроллер доступа пропускает системные домены (то есть считает, что код API Java обладает всеми привилегиями) и повторяющиеся домены. Кроме того, он прекращает проверку после обнаружения первого же привилегированного домена. Таким образом, в большинстве случаев время уходит только на запуск метода API. По словам Роланда Шемерса, проведенное Sun внутреннее тестирование показало, что проверка прав доступа происходит "крайне быстро".

Таким образом, функции защиты информации JDK 1.2 расширяют модель безопасности JDK 1.0 и 1.1, тем самым упрощая ее использование. Система безопасности JDK 1.2 дает сетевым администраторам возможность создавать гибкие схемы защиты информации для Java-приложений. Более подробно о новой системе безопасности можно узнать из источников, приведенных в списке использованной литературы.

Список использованной литературы