Механизмы безопасности

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

Здесь рассматриваются следующие темы:

Механизмы безопасности Java SE
Механизмы безопасности Java EE

Механизмы безопасности Java SE

Java SE обеспечивает поддержку различных функций и механизмов безопасности.

Сервис аутентификации и авторизации Java (Java Authentication and Authorization Service — JAAS) — это набор API, которые позволяют службам аутентифицировать и обеспечивать контроль доступа для пользователей. JAAS предоставляет подключаемую и расширяемую среду для программной аутентификации и авторизации пользователей. JAAS — это базовый API Java SE и базовая технология для механизмов безопасности Java EE.
Java Generic Security Services (Java GSS-API) — это API на основе токенов, используемый для безопасного обмена сообщениями между взаимодействующими приложениями. GSS-API предлагает разработчикам приложений унифицированный доступ к сервисам безопасности на основе множества базовых механизмов безопасности, включая Kerberos.
Расширение Java Cryptography Extension (JCE) предоставляет структуру и реализацию для шифрования, генерации ключей и согласования ключей, а также алгоритмов кода аутентификации сообщений (MAC). Поддержка шифрования включает в себя симметричные, асимметричные, блочные и потоковые шифры. Блочные шифры работают с группами байтов. Потоковые шифры обрабатывают по одному байту за раз. Программное обеспечение также поддерживает безопасные потоки и запечатанные (sealed) объекты.
Расширение Java Secure Sockets (JSSE) предоставляет платформу и реализацию в Java протоколов Secure Sockets Layer (SSL) и Transport Layer Security (TLS) и включает в себя функциональность для шифрования данных, серверной аутентификации, целостности сообщений и, опционально, аутентификации клиента по цифровому сертификату для обеспечения безопасного интернет-соединения.
Простой слой аутентификации и безопасности (Simple Authentication and Security Layer — SASL) — это стандарт Интернета (RFC 2222), который определяет протокол для аутентификации и необязательного установления слоя безопасности между клиентскими и серверными приложениями. SASL определяет способ обмена данными аутентификации, но сам по себе не определяет содержимое этих данных. SASL — это фреймворк, в который могут вписываться конкретные механизмы аутентификации, которые определяют содержимое и семантику данных аутентификации.

Java SE также предоставляет набор инструментов для управления хранилищами ключей, сертификатами и файлами политик, генерирования и проверки подписей JAR, получения, распечатки и управления тикетами Kerberos.

Для получения дополнительной информации о безопасности Java SE посетите http://docs.oracle.com/javase/7/docs/technotes/guides/security/.

Механизмы безопасности Java EE

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

Безопасность на уровне приложений

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

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

Преимущества использования безопасности на уровне приложений.

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

Недостатки использования безопасности на уровне приложений:

Приложение зависит от атрибутов безопасности, которые нельзя передавать между типами приложений.
Поддержка нескольких протоколов делает этот тип безопасности уязвимым.
Данные близки или находятся в пределах уязвимости.

Для получения дополнительной информации об обеспечении безопасности на уровне приложений см. Защита контейнеров.

Безопасность транспортного уровня

Безопасность транспортного уровня обеспечивается транспортными механизмами, используемыми для передачи информации по проводам между клиентами и поставщиками. Таким образом, безопасность транспортного уровня опирается на безопасный транспорт HTTP (HTTPS) с использованием Secure Sockets Layer (SSL). Транспортная безопасность — это механизм безопасности «точка-точка», который можно использовать для проверки подлинности, целостности сообщений и конфиденциальности. При использовании защищённой SSL сессии сервер и клиент могут аутентифицировать друг друга и согласовывать алгоритм шифрования и криптографические ключи, прежде чем протокол приложения передаст или получит свой первый байт данных. Защита активна с момента, когда данные покидают клиента, до их прибытия в пункт назначения, и в обратную сторону, даже с учётом посредников. Проблема в том, что данные не защищены, когда они попадают в пункт назначения. Одним из решений является шифрование сообщения перед отправкой.

Безопасность транспортного уровня выполняется в несколько этапов следующим образом.

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

Цифровые сертификаты необходимы при запуске HTTPS с использованием SSL. Служба HTTPS большинства веб-серверов не будет работать, если не установлен цифровой сертификат. Цифровые сертификаты уже созданы для сервера GlassFish.

Преимущества использования безопасности транспортного уровня:

Это относительно простая, понятная, стандартная технология.
Она применима как к телу сообщения, так и к его вложениям.

К недостаткам использования безопасности транспортного уровня относятся:

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

Для получения дополнительной информации о безопасности транспортного уровня см. Установление безопасного соединения с использованием SSL.

Безопасность на уровне сообщений

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

Преимущества безопасности на уровне сообщений:

Сообщение остаётся защищённым на всех транзитных участках и после того, как сообщение прибывает в пункт назначения.
Защита может быть выборочно применена к различным частям сообщения и, если используется безопасность веб-сервисов XML, к вложениям.
Защита сообщений может использоваться при наличии нескольких транзитных посредников.
Безопасность сообщений не зависит от окружения, в котором работает приложение, и транспортного протокола.

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

GlassFish Server поддерживает безопасность сообщений с помощью Metro, стека веб-сервисов, который использует безопасность веб-сервисов (WSS) для защиты сообщений. Поскольку эта защита сообщений специфична для Metro и не является частью платформы Java EE, в этом руководстве не обсуждается использование WSS для защиты сообщений. См. Руководство пользователя Metro по ссылке https://javaee.github.io/metro/.