Обзор безопасности Java EE

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

Приложения слоя предприятия и веб-слоя состоят из компонентов, которые развёрнуты в различных контейнерах. Эти компоненты объединяются для создания многослойного корпоративного приложения. Безопасность компонентов обеспечивается их контейнерами. Контейнер обеспечивает два вида безопасности: декларативный и программный.

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

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

Аннотации (иногда называемые также метаданными) используются для указания информации о безопасности в файле класса. Когда приложение развёрнуто, эта информация может быть использована или переопределена дескриптором развёртывания приложения. Аннотации избавляют от необходимости записывать декларативную информацию внутри XML-дескрипторов. Вместо этого вы просто помещаете аннотации в код, и необходимая информация генерируется автоматически. В этом уроке аннотации используются для защиты приложений везде, где это возможно. Для получения дополнительной информации об аннотациях см. Использование аннотаций для указания информации о безопасности.
Программная безопасность встроена в приложение и используется для принятия решений по доступу. Программная безопасность полезна, когда одной декларативной безопасности недостаточно для реализации модели безопасности приложения. Для получения дополнительной информации о программной безопасности прочитайте Использование программной безопасности.

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

Больше информации об этих концепциях и механизмах можно найти в главе о безопасности в спецификации Java EE 8.

В других главах этой части обсуждаются требования к безопасности в приложениях веб-слоя и слоя предприятия, а также API безопасности Java EE.

Глава 51 «Начало работы по защите веб-приложений» объясняет, как усилить безопасность веб-компонентов, таких как сервлеты.
Глава 52 «Начало работы по защите EJB-приложений» объясняет, как усилить безопасность компонентов Java EE, таких как Enterprise-бины и клиентские приложения.
Глава 53 «Использование API безопасности Java EE» описывает функциональность аутентификации и проверки учётных данных, предоставляемую API безопасности Java EE, и примеры.

Простое руководство по безопасности приложений

Поведение безопасности среды Java EE может стать более понятным при изучении того, что происходит в простом приложении с веб-клиентом, пользовательским интерфейсом и бизнес-логикой Enterprise-бина.

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

Шаг 1: Первоначальный запрос

На первом шаге этого примера веб-клиент запрашивает основной URL приложения. Это действие показано на рисунке 50-1.

Рисунок 50-1 Первоначальный запрос

Схема первоначального запроса от веб-клиента к веб-серверу для доступа к защищённому ресурсу

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

Шаг 2: Начальная аутентификация

Веб-сервер возвращает форму, которую веб-клиент использует для сбора данных аутентификации, таких как имя пользователя и пароль, от пользователя. Веб-клиент пересылает данные аутентификации на веб-сервер, где они проверяются веб-сервером, как показано на рис. 50-2. Механизм проверки может быть локальным для сервера или использовать сервисы безопасности. По итогам проверки веб-сервер устанавливает учётные данные для пользователя.

Рисунок 50-2 Начальная аутентификация

Диаграмма начальной аутентификации: сервер отправляет форму клиенту, который отправляет данные аутентификации на сервер для проверки

Шаг 3: Авторизация URL

Учётные данные используются в будущем для определения того, авторизован ли пользователь для доступа к ограниченным ресурсам, которые он может запросить. Веб-сервер обращается к политике безопасности, связанной с веб-ресурсом, чтобы определить роли безопасности, которым разрешён доступ к ресурсу. Политика безопасности определяется на основе аннотаций или дескриптора развёртывания. Затем веб-контейнер проверяет учётные данные пользователя для каждой роли, чтобы определить, может ли он соотнести пользователя с этой ролью. На рисунке 50-3 показан этот процесс.

Рис. 50-3. Авторизация URL

Схема авторизации URL

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

Шаг 4: Выполнение исходного запроса

Если пользователь авторизован, веб-сервер возвращает результат исходного запроса URL, как показано на рис. 50-4.

Рисунок 50-4 Выполнение исходного запроса

Диаграмма выполнения запроса, показывающая результат возврата сервером клиенту

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

Шаг 5: Вызов бизнес-методов Enterprise-бина

Веб-страница выполняет удалённый вызов метода для Enterprise-бина, используя учётные данные пользователя для установления безопасной связи между веб-страницей и Enterprise-бином, как показано на рис. 50-5. Ассоциация реализована в виде двух связанных контекстов безопасности: один на веб-сервере и один в контейнере EJB.

Рис. 50-5. Вызов бизнес-метода Enterprise-бина

Схема процесса авторизации между веб-компонентом и Enterprise-бином

Контейнер EJB отвечает за обеспечение контроля доступа к методу Enterprise-бина. Контейнер обращается к политике безопасности, связанной с Enterprise-бином, чтобы определить роли безопасности, которым разрешён доступ к методу. Политика безопасности определяется на основе аннотаций или дескриптора развёртывания. Для каждой роли контейнер EJB определяет, может ли он определить роль вызывающего субъекта, используя контекст безопасности, связанный с вызовом.

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

Если вызов авторизован, контейнер отправляет управление методу Enterprise-бина. Результат выполнения вызова бином возвращается на веб-страницу и, в конечном счёте, пользователю веб-сервером и веб-клиентом.

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

Правильно реализованный механизм безопасности обеспечивает следующие функциональные возможности:

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

В идеале, корректно реализованные механизмы безопасности также будут обеспечивать

Лёгкость администрирования
Прозрачность для пользователей системы
Сквозная совместимость между приложениями и предприятиями

Характеристики безопасности приложений

Приложения Java EE состоят из компонентов, которые могут содержать как защищённые, так и незащищённые ресурсы. Зачастую требуется защитить ресурсы, чтобы обеспечить доступ только авторизованным пользователям. Авторизация обеспечивает контролируемый доступ к защищённым ресурсам. Авторизация основана на идентификации и аутентификации. Идентификация — это процесс, позволяющий системе распознавать субъект, а аутентификация — это процесс, проверяющий личность пользователя, устройство или другого субъекта в информационной системе, обычно в качестве предварительного условия для предоставления доступа к ресурсам в системе.

Авторизация и аутентификация не требуются для доступа субъекта к незащищённым ресурсам. Доступ к ресурсу без аутентификации называется неаутентифицированным, или анонимным доступом.

Характеристики безопасности приложений, которые при правильном обращении помогают минимизировать угрозы безопасности, с которыми сталкивается предприятие:

Аутентификация: средство, с помощью которого взаимодействующие объекты, такие как клиент и сервер, доказывают друг другу, что они действуют от имени определённых идентичностей, которым разрешён доступ. Это гарантирует, что пользователи являются теми, за кого они себя выдают.
Авторизация, или контроль доступа: средства, с помощью которых взаимодействия с ресурсами ограничиваются заданным набором пользователей или программ с целью обеспечения соблюдения целостности, конфиденциальности или доступности. Это гарантирует, что пользователи имеют разрешение на выполнение операций или доступ к данным.
Целостность данных: средство, используемое для доказательства того, что информация не была изменена третьей стороной — субъектом, не являющимся источником информации. Например, получатель данных, отправленных по открытой сети, должен иметь возможность обнаруживать и отбрасывать сообщения, которые были изменены после их отправки. Это гарантирует, что только авторизованные пользователи могут изменять данные.
Конфиденциальность, или приватность данных. Средства, используемые для обеспечения того, чтобы информация была доступна только пользователям, имеющим доступ к ней. Это гарантирует, что только авторизованные пользователи могут просматривать конфиденциальные данные.
Безотзывность: средство, используемое для доказательства того, что пользователь, совершивший какое-либо действие, не может отрицать, что он это сделал. Это гарантирует, что транзакции могут быть подтверждены.
Качество обслуживания: средства, используемые для обеспечения лучшего обслуживания выбранного сетевого трафика по различным технологиям.
Аудит: средство, используемое для сбора защищённой от несанкционированного доступа записи событий, связанных с безопасностью, с целью оценки эффективности политик и механизмов безопасности. Для этого система ведет учёт транзакций и информацию о безопасности.