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

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

6 управления безопасностью

6.1 Управление Апплетами и Приложениями

В настоящий момент весь Java 2 системных кода SDK вызывает методы SecurityManager, чтобы проверить политику в настоящий момент в действительности и выполнить проверки управления доступом. обычно есть менеджер безопасности (реализация SecurityManager) установлен всякий раз, когда апплет работает; appletviewer и большинство браузеров, включая тех от Netscape и Microsoft, устанавливают менеджера безопасности.

Менеджер безопасности автоматически не устанавливается, когда приложение работает. Чтобы применить ту же самую политику безопасности к приложению, найденному на локальной файловой системе относительно загруженных апплетов, любой, пользователь, запускающий приложение, должен вызвать виртуальную машину Java с новым "-Djava.security.manager" параметром командной строки (который устанавливает значение java.security.manager свойства), как в

    java -Djava.security.manager  SomeApp

или само приложение должно вызвать setSecurityManager метод в java.lang. Системный класс, чтобы установить менеджера безопасности.

Возможно определить на командной строке определенного менеджера безопасности, который будет использоваться, следующим "-Djava.security.manager" с равнянием и именем класса, который будет использоваться в качестве менеджера безопасности, в качестве в

    java -Djava.security.manager=COM.abc.MySecMgr  SomeApp

Если никакой менеджер безопасности не определяется, встроенный менеджер безопасности по умолчанию используется (если приложение не устанавливает различного менеджера безопасности). Все следующее эквивалентно и результат в использовании менеджера безопасности по умолчанию:

    java -Djava.security.manager  SomeApp
    java -Djava.security.manager=""  SomeApp
    java -Djava.security.manager=default  SomeApp

Java 2 SDK включает свойство, названное java.class.path. Классы, которые сохранены на локальной файловой системе, но не должны быть обработаны как базовые классы (например, классы, встроенные в SDK), должны быть на этом пути. Классы на этом пути загружаются безопасным загрузчиком класса и таким образом подвергаются осуществляемой политике безопасности.

Есть также "-Djava.security.policy" параметр командной строки, использование которого определяет, какие файлы политики используются. Этот параметр командной строки описывается подробно в "Системном и Пользовательском разделе" Файлов Политики по умолчанию. В основном, если Вы не будете включать "-Djava.security.policy" на командной строке, то тогда файлы политики, определенные в файле свойств безопасности, будут использоваться.

Можно использовать "-Djava.security.policy" параметр командной строки, чтобы определить дополнительное или различный файл политики, вызывая выполнение приложения. Например, если Вы введете следующий, где ИЗНАНОЧНОЙ ВЯЗКОЙ является URL, определяющий расположение файла политики, то тогда указанный файл политики будет загружен в дополнение ко всем файлам политики, определенным в файле свойств безопасности:

    java -Djava.security.manager -Djava.security.policy=pURL SomeApp

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

java -Djava.security.manager -Djava.security.policy==pURL SomeApp

6.2 SecurityManager против AccessController

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

Мы не имеем в это время, пересмотренное никакой системный код, чтобы вызвать AccessController вместо того, чтобы вызвать SecurityManager (и проверить на существование classloader) из-за потенциала существующих сторонних приложений, которые разделяют SecurityManager на подклассы и настраивают check методы. Фактически, мы добавили новый метод SecurityManager.checkPermission это по умолчанию просто вызывает AccessController.checkPermission.

Чтобы понять отношение между SecurityManager и AccessController, достаточно отметить, что SecurityManager представляет понятие центральной точки управления доступом, в то время как AccessController реализует определенный алгоритм управления доступом со специальными функциями такой как doPrivileged метод. Совершенствуя SecurityManager, мы поддерживаем обратную совместимость (например, для тех приложений, которые записали их собственные классы менеджера безопасности, основанные на более ранних версиях JDK), и гибкость (например, для кого-то желающего настроить модель обеспечения безопасности, чтобы реализовать мандатное управление доступом или многоуровневую безопасность). Предоставляя AccessController, мы создаем в алгоритме, которому мы верим, является самым рестриктивным, и это освобождает типичного программиста от бремени необходимости записать обширный код в системе защиты в большинстве сценариев.

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

6.3 Вспомогательные Инструменты

Этот раздел кратко описывает использование трех инструментов, которые помогают в развертывании новых средств защиты. Эти инструменты могут быть упакованы вместе в будущем.

Более обширная документация для инструментов может быть найдена в

/docs/technotes/tools/solaris

/docs/technotes/tools/windows

подкаталоги SDK выпускают каталог (где разделители каталога фактически "\" на системах Windows).

Например, если Java, 2 SDK устанавливаются в каталоге, названном "/j2sdk1.2" на системе Соляриса, то keytool документация для Соляриса и пользователей Windows, соответственно, может быть найдена в

/j2sdk1.2/docs/tooldocs/solaris/keytool.html
/j2sdk1.2/docs/tooldocs/windows/keytool.html

Если Java, 2 SDK устанавливаются в каталоге по имени "C:\j2sdk1.2" на системе Windows, то keytool документация для Соляриса и пользователей Windows, соответственно, может быть найдена в

C:\j2sdk1.2\docs\tooldocs\solaris\keytool.html
C:\j2sdk1.2\docs\tooldocs\windows\keytool.html

6.3.1 Инструмент управления Ключа и Сертификата

keytool является ключом и утилитой управления сертификатом. Это позволяет пользователям администрировать свои собственные пары "открытый/закрытый ключ" и связанные сертификаты для использования в самоаутентификации (где пользователь аутентифицирует себя другим пользователям/службам), или целостность данных и службы аутентификации, используя цифровые подписи. Информация об аутентификации включает и последовательность (цепочка) сертификатов X.509, и связанный закрытый ключ, на который может сослаться так называемый "псевдоним". Этот инструмент также управляет сертификатами (которым "доверяет" пользователь), которые сохранены в той же самой базе данных как информация об аутентификации, и могут быть сосланы "псевдонимом".

keytool хранит ключи и сертификаты в так называемом keystore. Значение по умолчанию keystore реализация реализует keystore как файл. Это защищает закрытые ключи с паролем.

Цепочки сертификатов X.509 обеспечиваются организациями под названием Центры сертификации, или Идентификационные данные АВАРИИ (включая АВАРИЮ) используют свои закрытые ключи, чтобы аутентифицировать их ассоциацию с объектами (такой как с каналами, которые защищаются, используя SSL), с архивами кода, который они подписали, или (для АВАРИИ) с сертификатами X.509, которые они выпустили. Как инструмент начальной загрузки, может использоваться сгенерированное использование сертификатов-genkey команды, пока Центр сертификации не возвращает цепочку сертификата.

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

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

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

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

% keytool -help
KeyTool usage:

-certreq     [-v] [-alias <alias>] [-sigalg <sigalg>]
             [-file <certreq_file>] [-keypass <keypass>]
             [-keystore <keystore>] [-storepass <storepass>]
             [-storetype <i>storetype</i>]

-delete      [-v] -alias <alias>
             [-keystore <keystore>] [-storepass <storepass>]
             [-storetype <i>storetype</i>]

-export      [-v] [rfc] [-alias <alias>] [-file <cert_file>]
             [-keystore <keystore>] [-storepass <storepass>]
             [-storetype <i>storetype</i>]

-genkey      [-v] [-alias <alias>] [-keyalg <keyalg>]
             [-keysize <keysize>] [-sigalg <sigalg>]
             [-dname <distinguished_name>] [-validity <valDays>]
             [-keypass <keypass>] [-keystore <keystore>]
             [-storepass <storepass>]
             [-storetype <i>storetype</i>]

-help

-identitydb  [-v] [-file <idb_file>] [-keystore <keystore>]
             [-storepass <storepass>]
             [-storetype <i>storetype</i>]

-import      [-v] [-noprompt] [-alias <alias>]
             [-file <cert_file>] [-keypass <keypass>]
             [-keystore <keystore>] [-storepass <storepass>]
             [-storetype <i>storetype</i>]

-keyclone    [-v] [-alias <alias>] -dest <dest_alias>
             [-keypass <keypass>] [-new <new_keypass>]
             [-keystore <keystore>] [-storepass <storepass>]
             [-storetype <i>storetype</i>]

-keypasswd   [-v] [-alias <alias>]
             [-keypass <old_keypass>] [-new <new_keypass>]
             [-keystore <keystore>] [-storepass <storepass>]
             [-storetype <i>storetype</i>]

-list        [-v | -rfc] [-alias <alias>]
             [-keystore <keystore>] [-storepass <storepass>]
             [-storetype <i>storetype</i>]

-printcert   [-v] [-file <cert_file>]

-selfcert    [-v] [-alias <alias>] [-sigalg <sigalg>]
             [-dname <distinguished_name>] [-validity <valDays>]
             [-keypass <keypass>] [-keystore <keystore>]
             [-storepass <storepass>]
             [-storetype <i>storetype</i>]

-storepasswd  [-v] [-new <new_storepass>]
             [-keystore <keystore>] [-storepass <storepass>]
              [-storetype <i>storetype</i>]

6.3.2 PolicyTool

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

См. документацию PolicyTool для информации об использовании и примеров с актуальными снимками экрана. Документация может быть найдена в policytool.html файл в

/docs/technotes/tools/solaris/

или

/docs/technotes/tools/windows/

каталог в каталоге, в котором был установлен SDK (где разделители файлов являются фактически наклонными чертами влево на системах Windows).

передозировка снимка экрана окно PolicyTool

6.3.3 Инструмент Подписания и Проверки JAR

jarsigner инструмент может использоваться, чтобы в цифровой форме подписать архивы Java (файлы JAR), и проверить такие подписи. Этот инструмент, как PolicyTool, зависит от keystore, которым управляет keytool. Его использование быстро получается в итоге ниже.

% jarsigner
Usage: jarsigner [options] jar-file alias
       jarsigner -verify [options] jar-file
  [-keystore <url>]         keystore file location
  [-storepass <password>]   password for keystore integrity
  [-keypass <password>]     password for private key (if different)
  [-sigfile <file>]         name of .SF/.DSA file
  [-signedjar <file>]       name of signed JAR file
  [-verify]                 verify a signed JAR file
  [-verbose]                verbose output when signing/verifying
  [-certs]          display certificates when verbose and verifying
  [-internalsf]             include .SF file inside signature block
  [-sectionsonly]           don't compute hash of entire manifest

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

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

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