Сентябрь 2008 г - oracle cloud · приложениями. Возможность...

Oracle ® Entitlements Server 10g (10.1.4.3)

Введение в Oracle Entitlements Server Сентябрь 2008 г.

___________________________________________________________ Введение в Oracle Entitlements Server, Oracle ® Entitlements Server 10g (10.1.4.3) © 2007, 2008, корпорация Oracle и ее дочерние предприятия. Все права защищены. Настоящее программное обеспечение (ПО) и сопутствующая документация предоставляются в соответствии с лицензионным соглашением, включающим ограничения на использование и разглашение информации, а также защищены законодательством об интеллектуальной собственности. Запрещается использование, копирование, воспроизведение, перевод, трансляция, изменение, выдача разрешения на использование, передача прав, распространение, демонстрация, исполнение, публикация или отображение любой части настоящего ПО и документации в любой форме и любым путем, за исключением тех случаев, когда это явно допускается лицензионным соглашением или разрешено законодательством. Запрещается проведение инженерного анализа, дизассемблирование и декомпиляция настоящего ПО, за исключением случаев, когда это требуется согласно закону в целях обеспечения взаимодействия. Информация, содержащаяся в настоящем документе, может изменяться без предварительного уведомления. Компания Oracle не дает гарантии, что такая информация не содержит ошибок. При обнаружении каких-либо ошибок просьба сообщить о них в компанию Oracle в письменном виде. Если настоящее программное обеспечение или сопутствующая документация предоставляется правительству США или иному лицу, получающему лицензию от имени правительства США, действительно следующее уведомление: ПРАВА ПРАВИТЕЛЬСТВА США. Программы, программное обеспечение, базы данных, а также сопутствующая документация и технические данные, предоставляемые заказчикам, представляющим правительство США, являются «коммерческим компьютерным ПО» или «коммерческими техническими данными» в соответствии с применимыми нормативами по приобретению различных материалов федеральными агентствами, а также со вспомогательными нормативами, действующими в конкретном агентстве. Как таковые, использование, дублирование, разглашение информации, изменение и адаптация подлежат ограничениям и условиям лицензии, изложенным в соответствующем договоре с правительством США, а также, в объеме, определяемом условиями договора с правительством США, ограничениям, изложенным в дополнительных правах согласно нормативу FAR 52.227-19 «Лицензирование коммерческого компьютерного программного обеспечения» (декабрь 2007 года). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065, США. Настоящее ПО разработано с целью общего использования в разнообразных приложениях управления информацией. ПО не предназначено для применения в любых потенциально опасных приложениях, в том числе в приложениях, которые могут создавать опасность травмы. В случае использования настоящего ПО в опасных приложениях вы несете ответственность за применение всех надлежащих мер по защите от сбоев, обеспечению избыточности и т.п., необходимых для обеспечения безопасного использования настоящего ПО. Корпорация Oracle и ее дочерние предприятия не несут какой-либо ответственности за ущерб, вызванный применением настоящего ПО в опасных приложениях. Oracle является зарегистрированным товарным знаком корпорации Oracle Corporation и/или ее дочерних предприятий. Прочие наименования могут являться товарными знаками соответствующих владельцев. Настоящее ПО и сопутствующая документация могут предоставлять доступ к содержимому, продуктам и услугам третьих сторон либо информацию о таком содержимом, продуктах и услугах. Корпорация Oracle и ее дочерние предприятия заявляют от отказе от ответственности по каким-либо гарантиям, связанным с содержимым, продуктами и услугами третьих сторон. Корпорация Oracle и ее дочерние предприятия не несут ответственности за какие-либо убытки, расходы или ущерб, понесенные вами в связи с использованием содержимого, продуктов или услуг третьих сторон либо в связи с доступом к такому содержимому, продуктам или услугам.

Содержание

1. Введение Аудитория и сфера применения 3 Руководство к нас тоящему документу 3 Сопут с тв ующая информация 4

2. Предоставление прав Обзор 5 Что такое предоставление прав? 6 Проблемы предоставления прав 7 Вывод логики безопасности из приложения 8 Системные требования для сервера предоставления прав 9

3. Что представляет собой Oracle Entitlements Server? Обзор 11 Архитектура 11

Сервер администрирования (PAP) 13 Модуль служб безопасности (PEP, PDP) 14

Управление предоставлением прав и их применение 15 Управление политикой 16

Модель политик 16 Ролевая политика 17 Политика доступа 18 Управление версиями политик и техпроцесс 19

Управление данными предоставления прав 20

Введение iii

4. Интеграция и развертывание Интеграция с приложениями 23

Готовые к применению модули служб безопасности 23 Использование программного интерфейса Java 24 Использование тегов JSP 25 Аннотации в WebLogic Workshop 26

Модули обеспечения безопасности 27 Развертывание на предприятии 27

Распределенная модель развертывания 27 Централизованная модель развертывания 28 Масштабируемость 29

5. Резюме

iv Введение

Г Л А В А 1

Введение

Ниже приводится содержание и описывается структура настоящего документа.

Примечание: Продукт Oracle Entitlements Server ранее распространялся под наименованием BEA AquaLogic Enterprise Security. Некоторые элементы, например, объекты структуры, пути и т.п., могут использовать сокращение «ALES».

• «Аудитория и сфера применения» на стр. 3

• «Руководство к настоящему документу» на стр. 3

• «Сопутствующая информация» на стр. 4

Аудитория и сфера применения

Данный документ предназначен для всех пользователей продукта Oracle Entitlements Server, в том числе для бизнес-аналитиков, архитекторов и разработчиков системы безопасности, разработчиков приложений и администраторов.

Руководство к настоящему документу

В данном документе кратко описывает функции продукта Oracle Entitlements Server 10g, версия 3 (10.1.4.3), а также предоставляются обзор его архитектуры и возможностей. Документ включает следующие разделы:

• В разделе «Проблема предоставления прав» на стр. 5 описывается система

безопасности предприятия в контексте предоставления прав и поясняется, каким образом Oracle Entitlements Server обеспечивает выполнение требований к управлению предоставлением прав.

• В разделе «Что собой представляет Oracle Entitlements Server?» на стр. 11 описываются

компоненты, службы и функциональные возможности продукта Oracle Entitlements Server. • Из раздела «Интеграция и развертывание» на стр. 23 вы узнаете, как интегрировать Oracle

Введение страница 3

Г Л А В А 1

Entitlements Server в среду приложений с использованием различных моделей развертывания.

• В разделе «Резюме» на стр. 30 подытожена информация, содержащаяся в данном

документе.

Сопутствующая информация

Все входящие в комплект документы перечислены на главной странице документации к продукту Oracle Entitlements Server. Помимо прочего, комплект документации включает:

• Руководство для менеджеров политик – определение модели политики и описание

принципов управления данными политик, а также создания, импорта и экспорта таких данных.

• Руководство по интеграции – инструкции по интеграции готовых к использованию

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

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

• Защита производственной среды Oracle Entitlements Server – описание передового

опыта по безопасному развертыванию OES в производственных системах. • Безопасное программирование в приложениях Java – принципы обеспечения

безопасности для приложений Java.

страница 4 Введение

http://download.oracle.com/docs/cd/E12890_01/ales/docs32/index.html

http://download.oracle.com/docs/cd/E12890_01/ales/docs32/index.html

http://download.oracle.com/docs/cd/E12890_01/ales/docs32/policymanager/index.html

http://download.oracle.com/docs/cd/E12890_01/ales/docs32/integrateappenviron/index.html

http://download.oracle.com/docs/cd/E12890_01/ales/docs32/GettingStarted/index.html

http://download.oracle.com/docs/cd/E12890_01/ales/docs32/prodenv/index.html

http://download.oracle.com/docs/cd/E12890_01/ales/docs32/programmersguide/index.html

Г Л А В А 2

Предоставление прав

• «Обзор» на стр. 5

• «Что такое предоставление прав?» на стр. 6

• «Проблемы предоставления прав» на стр. 7

• «Вывод логики безопасности из приложения» на стр. 8

• «Системные требования для сервера предоставления прав» на стр. 9

Обзор

Требования к системам, обеспечивающим безопасный доступ к приложениям предприятия, за последние 10 лет кардинально изменились. Распространение Интернета вызвало необходимость защищать периметр ИТ-инфраструктуры предприятия посредством технологий, назначение которых сводится к принципу «Не впускать плохих!». Появление веб-технологий для обеспечения безопасности и решений для однократной регистрации позволило перенести вглубь ИТ-инфраструктуры предприятия проблему предоставления доступа и обеспечения безопасности. Системы управления идентификацией сделали возможной работу с идентификационными данными миллионов пользователей. Системы контроля доступа и федеративного управления идентификацией предоставляют заказчикам и партнерам более полный доступ к ресурсам предприятия, что ведет к повышению степени автоматизации и усовершенствовать системы самообслуживания, а также позволяет существенно повысить экономическую эффективность используемых решений.

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

Предоставление прав страница 5

Г Л А В А 2

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

Следующим шагом в развитии технологий для защиты приложений стало управление предоставлением прав пользователям и отделение логики безопасного использования приложений от уровня приложений. Oracle Entitlements Server (OES) предоставляет возможность централизованного управления предоставлением прав с распределенным обеспечением доступа как к компонентам приложений, так и к их бизнес-объектам. Основное назначение этого документа – описать возможности использования Oracle Entitlements Server для решения проблемы предоставления прав доступа к приложениям.

Что такое предоставление прав?

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

Рисунок 2-1. Типичное приложение для интернет-банкинга

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

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

страница 6 Предоставление прав

Г Л А В А 2

• Может ли данный клиент выполнять перевод средств с данного счета – и если да, то при каких условиях?

• Какими счетами может управлять пользователь?

• Какие права клиент может передавать (делегировать) другим лицам? Кому он может их передавать? В каких объемах?

Система предоставления прав используется для создания подобных прав и управления ими, а также для принятия и записи решений по предоставлению доступа, принимаемых в ходе работы приложения. Банковское приложение может включать программные компоненты (например, серверные Java-страницы JSP, спецификации EJB или ссылки), а также логические объекты, такие как счета клиентов. Используемая банком система предоставления прав должна «уметь» управлять предоставлением прав для обоих типов ресурсов конкретного приложения. Банку также необходима возможность предоставлять клиентам новые функции, которые можно быстро развертывать. По мере развертывания новых функций набор прав, предоставляемых пользователю, также будет изменяться. И банк должен обеспечивать возможность делать все это, не меняя код приложения и не тестируя его заново.

Проблемы предоставления прав

Управление предоставляемыми правами и применение их в приложении обычно связаны с рядом проблем.

Первая сложность – это наличие встроенных решений. Речь идет о решениях по авторизации, заранее заложенных в коде приложения. Встроенные решения создают сразу несколько проблем. Логика системы безопасности может различаться для разных приложений. Любые изменения логики безопасности требуют внесения изменений в приложение, которое после этого необходимо повторно протестировать и развернуть. Если решения о предоставлении доступа заложены в код приложения, то нет возможности централизованно управлять логикой системы безопасности или контролировать ее. Кроме того, не будет возможности проанализировать логику доступа с целью определить, какие пользователи имеют право выполнять те или иные действия. Наконец, принятое решение не всегда возможно зарегистрировать в системе учета. Вторая проблема связана с тем, что предприятия уже используют ряд технологий для обеспечения безопасности. Многие компании используют централизованные каталоги для хранения данных о пользователях, веб-системы для однократной регистрации и продукты для инициализации пользователей. Система предоставления прав должна предусматривать возможность интеграции с этими технологиями с целью получения идентификационных данных и атрибутов пользователей, требуемых для принятия решений о доступе. Наконец, проблемы могут возникать из-за сложности модели предоставления прав, действующей в организации. Отрасли экономики, деятельность в которых строго регулируется, могут испытывать необходимость в создании сложных правил,


Г Л А В А 2

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

Вывод логики безопасности из приложения

Значительным преимуществом продукта Oracle Entitlements Server (OES) является то, что он позволяет вывести из приложения логику безопасности и затем централизованно ею управлять. На рисунке 2-2 изображен простой пример из сферы биржевой торговли. С данным приложением могут работать пользователи самых разных типов. Однако выполнять биржевые операции в этом приложении могут только пользователи, зарегистрированные как биржевые брокеры. Кроме того, брокеры имеют право осуществлять сделки только с использованием тех клиентских счетов, на работу с которыми они уполномочены. При этом не должен быть превышен лимит объема операций, заданный для каждого такого счета.

Рисунок 2-2. Вывод логики принятия решений о доступе из приложения

До использования OES После использования OES

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

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


Г Л А В А 2

Запрос авторизации («Разрешен ли доступ?») выполняется с использованием следующей информации:

• запрошенное действие («Trade», т.е. биржевая торговля);

• ресурс («Account», т.е. счет, с которым будут проводиться биржевые операции);

• субъект (кто запрашивает авторизацию для выполнения этих операций – «User», т.е. пользователь);

• контекст из приложения, требуемый для принятия решения об авторизации («Amount», т.е. предельный объем биржевых операций).

В данном случае Oracle Entitlements Server отвечает за получение требуемой информации о пользователе и счете. Продукт собирает требуемую информацию, оценивает политики, применимые к счетам в приложении, и возвращает решение о доступе. Кроме того, OES ведет учет информации о принятом решении. Важно отметить, как именно разработчик вносит в программу явный запрос на авторизацию (см. рисунок 2-2). Для объектов, управляемых продуктом WebLogic Server, такой запрос автоматически подается сервером. Для таких объектов J2EE, как серверные страницы Java (JSP), компоненты EJB и веб-службы, а также для таких объектов WebLogic Portal, как книги, страницы и рабочие столы, запрос на доступ «IsAccessAllowed» выполняется всякий раз, когда какое-либо приложение пытается получить доступ к одному из этих ресурсов. Для контроля доступа к этим «управляемым контейнером» объектам незачем изменять приложение.

Системные требования для сервера предоставления прав

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


Г Л А В А 2

ресурсов. Далее, решение для предоставления прав должно быть простым с точки зрения администрирования. Ключевой функцией решения является централизованное управление предоставлением прав. Администрирование доступа должно быть централизованным, однако соответствующие политики необходимо распределять по набору «точек принятия решений в рамках политики» (PDP), функционирующих на одном уровне с приложением. Поскольку условия ведения бизнеса постоянно меняются, необходима возможность управлять предоставлением прав бизнес-пользователей к их приложениям. Решение для предоставления прав должно обеспечивать возможность утверждения политик безопасности и управления их версиями. Наконец, решение для предоставления прав должно легко развертываться и интегрироваться с другими системами в инфраструктуре предприятия. Оно должно быть достаточно гибким, чтобы предоставлять возможность выбора между центральной точкой принятия решений в рамках политики и полностью распределенным набором таких точек. Необходима возможность передавать в точки принятия решений запросы из различных сред приложений посредством какого-либо механизма, не зависящего от используемого языка (например, посредством веб-служб – Web Services). Кроме того, решение для предоставления прав должно легко интегрироваться в инфраструктуру обеспечения безопасности, уже используемую на предприятии – включая интеграцию с хранилищами данных о пользователях на предприятии, с веб-решениями для однократной регистрации и со средствами инициализации пользователей.


Г Л А В А 3

Что представляет собой Oracle Entitlements Server?

• «Обзор» на стр. 12

• «Архитектура» на стр. 12

• «Управление предоставлением прав и их применение» на стр. 17

Обзор

Oracle Entitlements Server (OES) представляет собой систему для предоставления прав, поддерживающую централизованное определение сложной структуры прав на работу с приложениями, а также распределенное применение предоставляемых прав в рабочем цикле приложений. OES позволяет вывести из приложения механизмы принятия решений о доступе. Продукт предоставляет средства для определения ресурсов и бизнес-объектов приложений, представления таких объектов в иерархических отношениях, а также для создания политик, описывающих, каким пользователям, группам и рабочим ролям может быть предоставлен доступ к конкретным объектам. Можно создавать политики, контролирующие доступ как к программным компонентам приложения, так и к произвольным бизнес-объектам в приложении. Кроме того, продукт Oracle Entitlements Server включает модуль интеграции, который обеспечивает легкую интеграцию с существующими решениями для проверки подлинности, однократной веб-регистрации, управления идентификацией и инициализации пользователей.

Архитектура

Как показано на рисунке 3-1, архитектура Oracle Entitlements Server включает два основных компонента – сервер администрирования (Administration Server) и модули служб безопасности (Security Service Modules).

Что представляет собой Oracle Entitlements Server страница 11?

Г Л А В А 3

Рисунок 3-1. Архитектура

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

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

• как централизованный сервер предоставления прав, который можно запускать

через веб-службы, протокол RMI или протокол запросов/ответов XACML 2.0;

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

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

страница 12 Что представляет собой Oracle Entitlements Server?

Г Л А В А 3

Сервер администрирования (PAP)

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

Сервер администрирования состоит из нескольких компонентов. Диспетчер бизнес-логики (Business Logic Manager, BLM) осуществляет взаимодействие с базой данных политик, обеспечивая персистентность данных политик и других данных. Диспетчер бизнес-логики поддерживает операции управления транзакциями, предназначенные для создания и изменения пользователей, атрибутов, ролей и политик. Распределитель политик (Policy Distributor) управляет процессом распределения политики по модулям служб безопасности с целью применения прав в рабочем цикле приложений. Распределение политик по модулям SSM представляет собой инкрементный, транзакционный процесс. Загрузчик политик (Policy Loader) управляет импортом и экспортом данных политики. Политику можно экспортировать в формат XACML 2.0.

Рисунок 3-2. Сервер администрирования

При этом предоставляются программные интерфейсы Java и веб-служб, так что вы можете включать функции служб безопасности в приложения заказчика с целью автоматизации администрирования. Административные программные интерфейсы приложений также могут использоваться для осуществления интеграции с системами инициализации пользователей. Например, с помощью коннектора инициализации атрибуты нового сотрудника могут быть переданы в Oracle Entitlements Server. Сотруднику на основе его атрибутов будет сразу же предоставлен доступ к нужному набору приложений.


Г Л А В А 3

Модуль служб безопасности (PEP, PDP)

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

Сервер предоставления прав также представляет собой модуль служб безопасности, однако этот модуль развертывается на центральном сервере, а не распределяется по отдельным компьютерам, на которых выполняются приложения. В таком случае централизованный сервер предоставления прав получает запрос авторизации от приложения либо в виде запроса веб-служб, либо через протокол запросов/ответов XACML 2.0. Как и распределенные модули служб безопасности, централизованный сервер можно интегрировать с различными точками получения информации о политике (PIP) для получения и кэширования информации о пользователе или приложении, используемой для принятия решений в рамках политики.

Рисунок 3-3. Модуль служб безопасности (SSM)

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


Г Л А В А 3

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

Управление предоставлением прав и их применение

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

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

Разработчики, которые создают новые приложения или модифицируют уже существующие, интегрируют Oracle Entitlements Server с нужными приложениями. Это можно делать самыми разными способами, но цель в данном случае состоит в том, чтобы вывести логику системы безопасности из приложения, так чтобы можно было управлять ею с одной консоли. Такое центральное управление достигается путем подачи запросов на авторизацию в Oracle Entitlements Server, который затем оценивает политику контроля доступа и возвращает решение о доступе. Поскольку набор служб безопасности также входит в пакет, разработчики могут использовать продукт Oracle Entitlements Server в качестве платформы интеграции для других систем – таких, как системы проверки подлинности, однократной веб-регистрации и управления идентификацией.


Г Л А В А 3

Управление политикой

Политика создается и управляется администраторами и архитекторами по безопасности. В модели на основе политик можно разрешать доступ при совпадении атрибутов ресурса с атрибутами пользователя или группы.

Модель на основе меток дает политике возможность авторизации доступа в случае, если атрибуты ресурса соответствуют атрибутам пользователя или группы. Пример: «Разрешить доступ к записям о клиентах только в том случае, если код региона клиента совпадает с кодом региона, назначенным представителю центра обработки вызовов». Такой тип модели очень полезен, если и у ресурсов, и у пользователей есть описательные атрибуты, применимые для разработки политик.

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

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

Модель политик

Общая форма политики имеет следующий вид: Результат (Роль | Действие, Ресурс, Субъект) Ограничения Этот формат политики можно интерпретировать так: «Разрешить, отказать или передать действие для данного ресурса субъекту в соответствии с определенным набором ограничений», где: • Результатом может быть «grant» (разрешить), «deny» (отказать) или «delegate»

(передать).


Г Л А В А 3

• Роль (role) представляет собой роль, которую предполагается назначить пользователям или группам.

• Действие – это полномочие в отношении данного ресурса. Действия могут быть как

стандартными действиями для компонентов программ (напр., «URL: Get, Post»), так и определяемыми пользователями действиями для бизнес-объектов (напр.: «Счет в банке: Перевести деньги»).

• Ресурс – это подлежащая защите часть приложения. Ресурсами могут быть

компоненты, управляемые контейнером (напр., URL-адреса, компоненты EJB и т.п.), либо произвольные бизнес-объекты в приложении. Ресурсы хранятся в виде иерархии и могут обладать атрибутами. Например, у банковского счета имеются владелец, дата создания и лимит банковского перевода. Политики, привязанные к ресурсам в иерархии, наследуются любыми ресурсами-потомками.

• Субъект – это лицо, которому будет разрешено (или отказано) в праве выполнять действие и

пользоваться ресурсом. Субъектами могут быть пользователи, группы или роли. • Ограничения – это прочие условия, которые должны выполняться, чтобы политика давала

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

Ролевая политика

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

Grant (//role/Менеджеры_банка, //app/Отчеты_по_счетам, все) if (JobTitle=Менеджер_банка) В этом примере роль «Менеджер_банка» будет предоставлена для пользования ресурсом приложения «Отчеты_по_счетам» всем тем пользователям, должность которых – «Менеджер_банка». Здесь атрибут пользователя используется в ограничении для сужения условий, при соблюдении которых роль назначается субъекту. Можно также использовать ролевую политику для разделения обязанностей. В следующем примере показана простая политика разделения обязанностей. Данная политика откажет в предоставлении роли «Аналитик» всем, кому назначена роль «Брокер» в приложении «Брокерские_операции». Deny (//role/Аналитик, //app/Брокерские_операции, //role/Брокер)


Г Л А В А 3

В последнем примере показано, каким образом можно использовать политику для передачи (делегирования) роли другому лицу. В этом примере Джон уходит в отпуск. Его роль «Утверждающее_лицо» в приложении «Счета_к_оплате» на период его отпуска (с 1 по 10 августа) будет передана работникам его группы (JReports). Delegate (//role/Утверждающее_Лицо, //app/Счета_к_оплате, //grp/JReports, Джон) if (дата > 08/01/06) and (дата < 08/1 0/0 6)

Политика доступа

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

Grant (просмотр, //app/Отчеты, //group/Менеджеры_подразделений) if reportBusUnit= userBusUnit

В данном примере политика разрешает действие «Просмотр» в отношении ресурса приложения «Отчеты» всем членам группы «Менеджеры_подразделений», но только в том случае, если данный пользователь принадлежит к тому же бизнес-подразделению, к которому относится отчет. В этом ограничении используется как атрибут пользователя (BusinessUnit – бизнес-подразделение), так и атрибут ресурса (BusinessUnit).

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

Grant (перевод, //app/Счет, everyone) if user IN Владельцы_счета AND Заявка_на_перевод <= Лимит_перевода

В последнем примере показана дополнительная функция ядра обработки политик. Как правило, ядро обработки политик оценивает набор политик с целью принятия конкретного решения о доступе и возвращает решение об авторизации («разрешить» или «отказать»). При использовании функции Отчет ядро обработки политик, помимо решения об авторизации, возвращает дополнительные данные. В приведенном ниже случае в приложение передается значение атрибута Лимит_перевода. После этого приложение может использовать такие данные для дополнительной обработки.


Г Л А В А 3

Grant (перевод, //app/Счет, everyone) if user IN Владельцы_счета AND (Отчет(Лимит_перевода))

Управление версиями политик и техпроцесс

Репозиторий Oracle Enterprise Repository осуществляет управление метаданными для любого типа программных активов – от бизнес-процессов и веб-служб до приложений и компонентов. Репозиторий сопоставляет отношения и взаимозависимости, связывающие такие активы, благодаря чему оптимизируется анализ воздействия, а также расширяются возможности для повторного использования активов и для измерения их воздействия на объем прибыли.

На рисунке 3-4 приведен типичный пример взаимодействия продуктов Oracle Enterprise Repository и Oracle Entitlements Server. При совместном использовании с Oracle Entitlements Server репозиторий Oracle Enterprise Repository предоставляет возможность управления версиями политик и организации техпроцесса с целью утверждения политики и передачи уведомлений о ее обновлениях. Администратор системы безопасности определяет роли, политики, атрибуты и другие данные, необходимые для применения набора прав на работу с приложением (или несколькими приложениями). Администратор может в любой момент записать такую информацию в репозиторий Oracle Enterprise Repository в качестве актива. Если выбранное имя совпадает с именем набора политик, уже имеющегося в Oracle Enterprise Repository, то будет создана новая версия набора политик. Технический процесс, определенный в Oracle Enterprise Repository, будет применяться каждый раз, когда создается новый набор политик или новая версия существующего набора. Такой техпроцесс может включать в себя уведомления или утверждения, проводимые до регистрации нового актива или версии. Администратор также может переносить существующий набор политик из репозитория в приложение Entitlements Administration для просмотра или изменения такого набора.

В качестве типичного примера использования можно указать перенос элементов между промежуточными средами. Рассмотрим случай перехода от среды разработки к среде контроля качества. Администратор системы безопасности экспортирует информацию о политике в репозиторий Oracle Enterprise Repository. Для регистрации политики в Oracle Enterprise Repository требуется ее утверждение менеджером проекта. После утверждения политики Oracle Enterprise Repository может создать набор уведомлений. После этого администратор системы безопасности должен импортировать политику в Oracle Entitlements Server для ее применения в среде контроля качества. Для выполнения импорта также требуется утверждение, которое затем может сгенерировать второй набор уведомлений.


Г Л А В А 3

Рисунок 3-4. Управление версиями политик с помощью Oracle Enterprise Repository

Управление данными предоставления прав

С помощью приложения Entitlements Administration администраторы определяют компоненты определений политик и встраивают такие компоненты в политики, управляющие предоставлением прав пользователям. Администраторы имеют возможность управлять данными предоставления прав как для организации в целом, так и для отдельных приложений.

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


Г Л А В А 3

Рисунок 3-5. Управление политиками для приложения

В предыдущих версиях пользователи приложения Entitlements Administration работали со всеми политиками в одной линейной структуре. В данной версии добавлены узлы «organization» (организация) и «application» (приложение), благодаря чему политики можно упорядочивать (и осуществлять управление ими) для каждого приложения по отдельности. Узел «organization» содержит всех пользователей и группы, а также одно или несколько приложений; при этом управлять политиками, защищающими одно приложение, можно независимо друг от друга. Это не только представляет собой существенное усовершенствование пользовательского интерфейса, но и позволяет указывать для приложений различных администраторов, предоставляя им полный спектр полномочий для управления политиками, защищающими конкретное приложение. При этом администраторы получают лишь ограниченные права на работу с политиками, защищающими другие приложения (или вообще их не получают). Рисунок 3-6. Дерево «Organization/Application»

С целью облегчить разработку и текущий анализ политики в приложение Entitlements Administration включены функция отчетности по политикам и модуль моделирования политики:


Г Л А В А 3

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

• Моделирование политики позволяет администратору находить ошибки в политиках,

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

Рисунок 3-7. Запуск моделирования политики в Entitlements Administration


Г Л А В А 4

Интеграция и развертывание

В этой главе описаны методы интеграции Oracle Entitlements Server в среду приложений с использованием различных моделей развертывания.

• «Интеграция с приложениями» на стр. 23

• «Модули обеспечения безопасности» на стр. 27

• «Развертывание на предприятии» на стр. 27

Интеграция с приложениями

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

Программные интерфейсы управления можно применять для создания пользователей, групп и ролей, определения политик доступа или сопоставления ролей, а также для распределения политик по модулям служб безопасности. Программные интерфейсы управления можно запускать через вызовы Java или веб-служб. И последнее – продукт Oracle Entitlements Server работает с самыми разными каталогами и реляционными базами данных, необходимыми для проверки подлинности пользователей или получения информации об атрибутах пользователя.

Готовые к применению модули служб безопасности

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

Интеграция и развертывание страница 23

Г Л А В А 4

служб безопасности предлагаются для продуктов, входящих в состав платформы WebLogic, а также для веб-серверов. Кроме того, такие модули обеспечивают интеграцию с продуктом Oracle Enterprise Repository для управления версиями политик и организации соответствующего техпроцесса.

В состав версии Oracle Entitlements Server 10g 1.0.4.3 входят следующие готовые к применению модули служб безопасности (SSM):

• WLS SSM (для WebLogic 9.x/10.x) • WLS 8.1 SSM (для WebLogic 8.1) • Web Server SSM (для Microsoft IIS и Apache Web Server) • Web Service SSM • WebSphere SSM • Oracle SSM • RMI SSM • SharePoint (MOSS) SSM

Использование программного интерфейса Java

Для определяемых пользователем объектов приложения разработчик включает в код приложения явные запросы в Oracle Entitlements Server, заменяя ими логику контроля доступа, реализованную для каждого приложения. На рисунке 4-1 показано типичное применение этой процедуры.

Рисунок 4-1. Интеграция приложений с помощью программного интерфейса Java

страница 24 Интеграция и развертывание

Г Л А В А 4

Рассмотрим этот пример более подробно. В левой верхней части рисунка изображено приложение, с помощью которого пользователь пытается перевести с одного счета на другой тысячу долларов США. Приложению необходимо проверить, имеет ли пользователь право на осуществление этого перевода.

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

....}

Также отметим, что приложение Java могло через тот же программный интерфейс передавать запросы в модуль службы безопасности Java, встроенный в его рабочий цикл, или подавать удаленные запросы в модули служб безопасности веб-служб или протокола RMI.

Для простоты на рисунке показано, как можно программным путем интегрировать систему предоставления прав с приложением. Также существует возможность инкапсулировать интеграцию программы-клиента (на основе используемой программной модели), таким образом сведя к минимуму объем кода, требуемого для выполнения интеграции, и стандартизировав интеграцию с приложением.

Использование тегов JSP

Для элементов предоставления информации JSP-разработчикам предоставляется библиотека тегов. Библиотека тегов дает возможность защитить доступ к элементам уровня страницы, таким как кнопки, пункты меню, вкладки и ссылки, а также к любым другим данным на странице. В примере, представленном на рисунке 4-2, JSP-разработчик предоставляет разрешение на просмотр частной (private) информации только тем лицам, которые имеют на это право. Тег «IsAccessAllowed» в JSP-коде инициализирует запрос в ядро обработки политик. Отображенная ниже политика разрешения применяется к ресурсу /examplewebapp/private, идентифицируемому тегом. Всем пользователям в группе «Private» доступ будет разрешен (Grant), благодаря чему они увидят таблицу с частной информацией. Всем прочим пользователям будет отказано в доступе, а таблица с частной информацией отображаться не будет.


Г Л А В А 4

Рисунок 4-2. Использование библиотеки тегов

<sam ple1 :isAccessAllowed resource="examplewebapp/private"> <h2>private information</h2> <blockquote> <table border="1"> <tr> <td > private</td ><td >private </td ></tr> <tr> <td >secret</td ><td >secret</td> </tr> </table> </blockquote> </sample1 :isAccessAllowed> Grant(view, / /examplewebapp/private, / /group/Private)

Аннотации в WebLogic Workshop

Помимо прочего, продукт Oracle Entitlements Server представляет пользователям WebLogic Workshop возможность создавать аннотации к Java-объектам указывающие на то, что для этих объектов следует обеспечить защиту. В аннотации указываются имя ресурса, действие, применяемое к этому ресурсу, и какие-либо атрибуты ресурса, связанные с безопасностью. Проект Workshop можно просматривать, а его ресурсы, действие и любые атрибуты ресурсов – импортировать в Oracle Entitlements Server. После этого администратор системы безопасности может с помощью приложения Entitlements Administration создавать для данного ресурса требуемые ролевые политики или политики доступа. Благодаря этому разработчик и архитектор по безопасности могут работать вместе. В рамках такой модели разработчик указывает, какие объекты нуждаются в защите, а планировщик системы безопасности определяет механизм защиты этих объектов.


Г Л А В А 4

Модули обеспечения безопасности

Разработчики и третьи стороны вполне могут использовать интерфейсы Security Service Provider Interfaces (SSPI), предлагаемые провайдерами услуг по обеспечению безопасности для разработки своих систем обеспечения безопасности. Однако в комплект поставки данного продукта входит ряд готовых к применению модули от ведущих вендоров, обеспечивающих проверку подлинности, авторизацию, проверку идентификации, сопоставление учетных данных и учет.

OES предлагает следующие готовые к применению инструменты извлечения атрибутов (ретриверы), используемые модулями ASI Authorization и ASI Role Mapping.

— RDBMSAttribute Retriever — LDAPAttribute Retriever — SDOAttribute Retriever — ALESIdentity Attribute Retriever — Custom Attribute Retriever

Если готовые ретриверы атрибутов не соответствуют вашим потребностям, можно разработать собственную систему и управлять ею со специальной консоли.

Развертывание на предприятии

Продукт поддерживает две основные модели развертывания. Различие между этими моделями заключается в размещении точки принятия решений в рамках политики (PDP). В частности, роль такой точки выполняет модуль служб безопасности. В распределенной модели точка PDP встраивается в контейнер приложения, а все службы безопасности полностью распределяются. В централизованной модели приложения-клиенты подают запросы в центральную точку принятия решений посредством вызовов по протоколу RMI или SOAP. Центральная точка принятия решений в рамках политики оценивает политику и принимает решение о предоставлении доступа, после чего возвращает в приложение-клиент результат авторизации. Эти две модели не являются взаимоисключающими: их можно использовать в любом сочетании.

Распределенная модель развертывания

Типичный пример распределенного развертывания показан на рисунке 4-3. В распределенной модели модули служб безопасности подключаются к контейнеру приложения. Для продуктов WebLogic, наиболее распространенных веб-серверов, а также для приложений Java предоставляются готовые к применению модули служб безопасности. В распределенной модели модуль служб безопасности выступает в качестве точки принятия решений в рамках политики и точки применения политики.


Г Л А В А 4

Модуль служб безопасности WebLogic обеспечивает защиту объектов J2EE в составе WebLogic Server, таких как серверные страницы JSP, компоненты EJB, веб-службы и Java-объекты POJO. Кроме того, модуль защищает в WebLogic Portal объекты портала, такие как книги, страницы, портлеты и рабочие столы. Модуль служб безопасности Java открывает доступ к службам рабочего цикла через программные интерфейсы Java. Такой модуль может использоваться для защиты приложений в других Java-средах. Рисунок 4-3. Распределенное развертывание

Централизованная модель развертывания

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


Г Л А В А 4

Рисунок 4-4. Централизованное развертывание

C++ Client(PEP)

Масштабируемость

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


Г Л А В А 5

Резюме

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

В настоящее время многие предприятия сталкиваются с тремя следующими проблемами:

• наличие в приложениях встроенных решений по предоставлению прав;

• интеграция с существующими решениями для обеспечения безопасности;

• сложность модели предоставления прав.

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

Продукт Oracle Entitlements Server характеризуется гибкостью в развертывании. Он может использоваться в развертывании на основе контейнера с подключаемыми модулями служб безопасности для продуктов WebLogic, веб-серверов и Java-приложений. Также OES можно использовать в развертывании на основе служб с клиентскими приложениями, передающими запросы по протоколу SOAP в центральный модуль служб безопасности Web Service (Web Service SSM).

Продукт Oracle Entitlements Server – это система предоставления прав, дающая средства для определения ресурсов и бизнес-объектов приложений, представления таких объектов в иерархических отношениях, а также для создания политик, описывающих, каким пользователям, группам и рабочим ролям может быть предоставлен доступ к конкретным объектам.

OES позволяет вывести из приложения механизм принятия решений о предоставлении прав. Можно создавать политики, контролирующие доступ как к программным компонентам приложения, так и к произвольным бизнес-объектам в приложении. Oracle Entitlements Server поддерживает иерархическую модель ресурсов и политик с возможностью наследования. Кроме того, продукт поддерживает два типа политик –

страница 30 Резюме

Г Л А В А 5

для определения ролей и для контроля доступа к ресурсам в приложении.

Oracle Entitlements Server также представляет собой платформу служб безопасности, поддерживающую пять основных служб – проверку подлинности, авторизацию, сопоставление ролей, учет и сопоставление учетных данных. Такая инфраструктура служб основывается на системе обеспечения безопасности WebLogic и поддерживает те же интерфейсы SSPI, что и WebLogic. Можно добавлять собственные модули обеспечения безопасности взамен модулей, поставляемых вместе с Oracle Entitlements Server, либо в дополнение к ним.

Резюме страница 31

Сентябрь 2008 г - oracle cloud · приложениями. Возможность...

Documents