Архитектура безопасности Java: -

спецификации, руководства, описания, API

1 Введение

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

С технологической точки зрения провайдера безопасность Java включает два аспекта:

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

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

1.1 Исходная Модель Песочницы

Исходная модель обеспечения безопасности, обеспеченная платформой Java, известна как модель песочницы, которая существовала, чтобы обеспечить очень ограниченную среду, в которой можно выполнить недоверяемый код, полученный из открытой сети. Сущность модели песочницы - то, что локальному коду доверяют, чтобы иметь полный доступ к жизненным системным ресурсам (таким как файловая система), в то время как загруженному удаленному коду (апплет) не доверяют и может получить доступ только к ограниченным ресурсам, обеспеченным в песочнице. Эта модель песочницы иллюстрируется в числе ниже.

Предыдущий контекст описывает эту графику.

Модель песочницы была развернута через Комплект разработчика для Java (JDK), и была обычно принята приложениями, созданными с JDK 1.0, включая поддерживающие Java веб-браузеры.

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

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

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

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

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

1.2 Развитие Модели Песочницы

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

[D]

Мелкомодульное управление доступом.

Эта возможность существовала в JDK с начала, но использовать это, писатель приложения должен был сделать существенное программирование (например, разделяя на подклассы и настраивая SecurityManager и классы ClassLoder). Браузер HotJava 1.0 является таким приложением, поскольку это позволяет пользователю браузера выбирать из небольшого количества различных уровней безопасности.

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

Легко конфигурируемая политика безопасности.

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

Легко расширяемая структура управления доступом.

До JDK 1.1, чтобы создать новое право доступа, необходимо добавить новое check метод к SecurityManager class. Новая архитектура позволяет введенные полномочия (каждое представление доступа к системному ресурсу) и автоматическая обработка всех полномочий (включая все же, чтобы быть определенными полномочиями) корректного типа. Никакой новый метод в SecurityManager class не должен быть создан в большинстве случаев. (Фактически, мы до сих пор не встречались с ситуацией, где новый метод должен быть создан.)

Расширение проверок безопасности ко всем программам Java, включая приложения так же как апплеты.

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

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

СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT

Свяжитесь с Нами