Корпоративные информационные системы

Поскольку CORBA Security Service поддерживает два вида приложений с точки зрения их явного использования API Сервиса, то можно делить домены политик безопасности еще на две группы – домены системных политик безопасности и домены прикладных политик безопасности. Задание и использование системных политик безопасности выполняется силами ORB, Сервиса Безопасности и операционной системы, и приложения об этом может даже не знать,

 
Рисунок 11.5

• Домен среды безопасности (security environment domain)

Понятие «домена  среды безопасности» тесно связано с «доменом политик безопасности». Домен политик – это логическая область с заданным набором политик и их значений. Домен среды – это область, в которой используется некий единый подход, который обеспечивает защиту ресурсов в соответствии с заданными политиками.

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

С точки зрения организации взаимодействия в защищенной гетерогенной среде, можно также  принять во внимание отличия в реализации ORB’ов, введя тем самым, понятие «домена ORB».

Общая схема  организации защищенного взаимодействия объектов с учетом наличия различных  технологических доменов и доменов ORB может выглядеть так:

 
Рисунок 11.6

11.8.5 Объектная модель обеспечения безопасности

Объектную модель CORBA Securtiy Service удобнее рассматривать  по частям, а именно, с точки зрения различных участников процесса разработки и эксплуатации системы. Здесь мы будем рассматривать эту модель с двух точек зрения – с точки зрения разработчика приложений и администратора системы.

11.8.5.1 Модель с точки зрения разработчика

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

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

Начнем с  задания удостоверений и аутентификации.

 
Рисунок 11.7

Основой для  выполнения аутентификации (если она необходима) является объект Credentials. Пути создания и настройки этого объекта могут быть различными. Например, если принципал уже аутентифицирован, то для получения объекта Credentials можно использовать интерфейс Current. Напоминаем, что интерфейсы Current, определенные в различных сервисах CORBA, в принципе предназначены для решения одной задачи, а именно: они позволяют получить доступ к информации, передаваемой по ORB, в контексте (и потоке) текущего вызова. Интерфейс Current Сервиса Безопасности обеспечивает доступ к параметрам, связанным с безопасностью (подобно тому, как интерфейс Current Сервиса Объектных Транзакций обеспечивает доступ к параметрам текущей транзакции).

В общем случае, т.е. тогда, когда принципал (User на приведенном  выше рисунке) должен быть аутентифицирован, но еще не аутентифицирован.

User Sponsor (который  нарисован с использованием пунктирной  линии потому, что это не CORBA-интерфейс,  а некоторый фрагмент кода  приложения) получает от пользователя  необходимые данные (например, учетное имя и пароль), а затем обращается к объекту Principal Authenticator, который проводит аутентификацию и в качестве ее результата получает объект Credentials, который содержит идентификатор принципала и его привилегии. Как правило (но не обязательно!) эти действия выполняются в клиентском приложении.

После того, как  все необходимые удостоверения  заданы для данного принципала, они  используются при выполнении защищенных вызовов. Программист может при  необходимости менять эти удостоверения. Сделать это можно двумя способами: либо изменить состояние соответствующего объекта Credentials (для чего предусмотрен метол set_attributes()), либо изменив политики на уровне самой объектной ссылки обычными средствами управления политиками CORBA (за режим привилегий при вызове отвечает политика InvocationCredentialsPolicy, рисунок 9.8).

 
Рисунок 11.8

В обоих случаях  эффект изменений распространяется на все последующие вызовы с использованием данного объекта Credentials и/или данной объектной ссылки.

Что касается собственно выполнения защищенного удаленного вызова, то здесь все внешне выглядит, как обычно – все необходимое с точки зрения параметров безопасности выполняется ORB’ом и Сервисом Безопасности без участия самих приложений – как клиента, так и сервера.

 
Рисунок 11.9

Security Service перехватывает  вызов и с помощью интерфейса Current получает доступ ко всем  атрибутам объекта Credentials.

 
Рисунок 11.10

Переходим на сторону  сервера. Там выполняются похожие  действия –Security Service перехватывают  пришедший по ORB’у запрос. Получить доступ к параметрам безопасности – идентификатору принципала и его привилениям – можно с помощью вызова метода get_attributes() интерфейса Current. Далее эти привилегии используются при принятии решения, можно ли разрешить доступ данному принципалу в контексте этого вызова к данному серверному объекту (т.е. выполняется авторизация), см. рисунок 11.10.

Похожие механизмы  используются и в случае, когда  имеет место цепочка вызовов, т.е. некоторый промежуточный объект выступает сначала в роли сервера, а затем, при последующем вызове – уже в роли клиента. Если приложение использует API Security Service, то промежуточный объект может анализировать параметры безопасности пришедшего запроса и, в случае необходимости, менять из перед выполнением следующего вызова в цепочке. Для этой цели опять используется интерфейс Current:

Рисунок 11.11

Для получения  привилегий, содержащихся в полученном запросе, удобно использовать атрибут received_credentials интерфейса Current.

Промежуточный объект может быть самостоятельным принципалом и выполнять последующий вызов «от собственного имени». Это означает, что он должен получить свой объект Credential вместо того, чтобы извлекать существующий в контексте пришедшего запроса объект с помощью Current. В этом случае промежуточный объект обращается к методу authenticate() объекта PrincipalAuthenticator, а затем настраивает его с помощью метода set_attributes() объекта Credentials.

Что касается других аспектов управления приложением –  принятия решений о предоставлении доступа или выполнении аудита –  то спецификация не предусматривает  объявления определенных политик и  не занимается строгой формализацией  этих процессов. Тем не менее, CORBA Security Service предоставляет некоторые стандартные вспомогательные объекты, например, AuditChannel – логический канал вывода информации, или AuditDecision (для принятия решения, нужно ли отслеживать определенное событие), которые удобно использовать в системе аудита,

11.8.5.2 Модель с точки зрения администратора

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

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

Среди всех возможных  видов компонентов и сервисов, которые могут использовать политики безопасности (сами приложения, ORB, реализации Сервиса Безопасности CORBA, другие сервисы), спецификация подробно описывает только то, что происходит на уровне ORB.

local interface SecurityManager {   readonly attribute Security::MechandOptionsList supported_mechanisms;    readonly attribute CredentialsList own_credentials;    readonly attribute RequiredRights required_rights_object;    readonly attribute PrincipalAuthenticator principal_authenticator;    readonly attribute AccessDecision access_decision;    readonly attribute AuditDecision audit_decision;  ...  CORBA::Policy get_security_policy (in CORBA::PolicyType policy_type); };

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

11.8.6 Основные политики безопасности

CORBA Security Service определяет  следующие основные стандартные  политики безопасности:

• Политика предоставления доступа при вызове (Invocation access policy).

const CORBA::PolicyType SecClientInvocationAccess = 1; const CORBA::PolicyType SecTargetInvocationAccess = 2;     module SecurityAdmin {   interface AccessPolicy : CORBA::Policy { ... }   interface DomainAccessPolicy : AccessPolicy { ... }  ... };

• Политика аудита при выполнении вызова (Invocation audit policy). Эта политика позволяет указать, какие события в процессе выполнения вызовов нужно отслеживать в системе аудита.

const CORBA::PolicyType SecClientInvocationAudit = 4; const CORBA::PolicyType SecTargetInvocationAudit = 5;    module SecurityAdmin {   interface AuditPolicy : CORBA::Policy { … }   ... };

• Политика выполнения удаленного вызова (Secure Invocation policy), которая, в частности, позволяет определить необходимость установки доверительных отношений и уровень защиты информации (Quality of Protection).

const CORBA::PolicyType SecClientSecureInvocation = 8; const CORBA::PolicyType SecTargetSecureInvocation = 9;     module SecurityAdmin {   interface SecureInvocationPolicy : CORBA::Policy { … }   ./.. };

• Политика делегирования при выполнении вызова (Invocation delegation policy); позволяет задать поведение промежуточного объекта, участвующего в цепочке вызовов, с точки зрения делегирования удостоверений.

const CORBA::PolicyType SecDelegation = 7;    module SecurityAdmin {   interface DelegationPolicy : CORBA::Policy { … }    ... };

• Политика предоставления доступа для приложения (Application access policy). Эта политика отличается от Invocation access policy тем, что может использоваться непосредственно приложением и не обязана находиться под управлением менеджера домена политик безопасности. Invocation-политики управляются и используются не приложением, а ORB’ом.

const CORBA::PolicyType SecApplicationAccess = 3;

• Политика аудита для приложения. Как и предыдущая политика, она предназначена для использования (управления режимом аудита) непосредственно из приложения.

const CORBA::PolicyType SecApplicationAudit = 6;

• Политика доказательности (Non-repudiation policy). Определяет режимы генерации и контроля свидетельств о событиях. За ее использование отвечает приложение, а не ORB.

const CORBA::PolicyType SecNonRepudiation = 10;

• Политика конструирования (Construction policy), которая позволяет определить, нужно ли создавать новый домен политик безопасности при создании нового объекта с определенными политиками (CORBA::SecConstruction). Политика применяется в момент создания объектной ссылки объектным адаптором POA.

11.8.6.1 Управление политиками безопасности  на уровне приложения

Взаимодействие  с Сервисом Безопасности CORBA – явное  или неявное – начинается с момента создания объектной ссылки на CORBA-объект при работе в защищенной среде. Как всегда, фабрикой CORBA-объектов являются объектные адаптеры (POA). В этот момент ORB сопоставляет объектную ссылку с разными видами доменов безопасности – политик безопасности, технологическими доменами, доменами среды. После получения объектной ссылки приложение может использовать стандартные методы типов CORBA::Object, DomainManager, CORBA::Policy для управления политиками. Графически это можно изобразить следующим образом: