9.1.8. Защита

Защита в CORBA имеет долгую историю. Исходные версии спецификаций CORBA вряд ли стоит принимать во внимание, по той простой причине, что отдельные попытки описать службу защиты провалились. В CORBA версии 2.4 описание службы защиты занимает более 400 страниц и четко объясняет, каким образом в системы CORBA вносится защита. Рассмотрим защиту системы CORBA побли­же. Обзор по этой теме, написанный одним из авторов исходной спецификации защиты CORBA, можно найти в [66].

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

Ядро защиты в CORBA формируется путем поддержания защищенных обра­щений к объекту. Базовая идея состоит в том, что объекты прикладного уровня ничего не должны знать об использовании различных служб защиты. Однако ес­ли клиент имеет особые требования к защите, у него должен быть способ заявить эти требования, чтобы при обращении к объектам они принимались во внима­ние. Аналогичная ситуация возникает и с объектом, к которому происходит об­ращение. Подобный подход ведет к ситуации, представленной на рис. 9.15

.

Когда клиент выполняет привязку к объекту, чтобы потом иметь возможность к нему обращаться, ORB клиента определяет, какие службы защиты со стороны клиента понадобятся для защищенного обращения. Выбор служб определяется правилами защиты, ассоциированными с административным доменом, в котором выполняется клиент, и особо — правилами данного клиента.

Правила защиты задаются объектами правил (policy objects), ассоциирован­ными с клиентом. На практике домен, в котором исполняется клиент, открывает свои правила защиты для ORB этого клиента посредством указанного набора объектов правил. С клиентом автоматически ассоциируются правила по умолча­нию. Примерами объектов правил могут быть те объекты, которые определяют тип применяемой защиты сообщений или хранят списки доверенных сторон. Другие примеры и детали можно найти в [66].

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

Для поддержания защиты в CORBA могут применяться различные подходы. В частности, чтобы сделать брокер ORB по возможности более общим, жела­тельно определить различные службы защиты через стандартные интерфейсы, которые скроют реализацию этих служб. Службы, которые можно определить подобным образом, в CORBA именуются взаимозаменяемыми (replaceable).

Взаимозаменяемые службы защиты предполагается реализовывать вместе с двумя разными перехватчиками, как показано на рис. 9.16. Перехватчик контро­ля доступа (access control interceptor) — это перехватчик уровня запросов, кото­рый проверяет права доступа, связанные с обращением. Кроме него имеется перехватчик защищенных обращений (secure invocation interceptor) уровня сооб­щений, отвечающий за реализацию защиты сообщений. Другими словами, этот перехватчик занимается шифрованием запросов и ответов, поддерживая их це­лостность и конфиденциальность.

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

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

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

Критически важную роль в организации ассоциации защиты играет отдель­ный объект со стандартизованным интерфейсом, именуемый сейфовым объектом (vault object). Сейфовый объект вызывается перехватчиком защищенных сооб­щений для создания объекта контекста защиты. Перехватчик читает информа­цию о правилах из ассоциированных с клиентом объектов правил и передает эту информацию в сейфовый объект. Понятно, что сейфовый объект должен быть реализован в виде части ORB, чтобы его невозможно было подделать, и относит­ся к доверенной вычислительной базе каждой системы CORBA.