9.2.8. Защита

Как и в CORBA, система защиты DCOM в основном обеспечивает защиту обра­щений к объектам. Однако способ реализации защищенных обращений здесь аб­солютно иной. Хотя DCOM чаще всего входит в одну из операционных систем семейства Windows, разработчики DCOM совершенно оправданно решили по возможности отделить защиту DCOM от служб защиты Windows. Таким обра­зом они сохранили возможность реализации DCOM на других операционных системах с сохранением защиты обращений.

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

Декларативная защита

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

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

DCOM поддерживает несколько уровней аутентификации (authentication le­vels), представленных в табл. 9.8. По умолчанию большинство систем считают достаточной аутентификацию, происходящую в ходе первого контакта клиента с сервером (уровень CONNECT). Однако можно также требовать идентификации при каждом обращении к серверу (CALL) или даже при каждом получении данных от клиента (PACKET). Уровни PACKETJNTEGRITY и PACKET_PRIVACY - это уже не просто уровни аутентификации, а скорее добавление к уровню PACKET проверки целост­ности и конфиденциальности соответственно.

Чтобы защитить клиента от злонамеренных действий сервера, можно опреде­лить, в какой степени сервер имеет право присвоить себе роль или мандат клиен­та, обращающегося к объекту (табл. 9.9). Для этого используются так называе­мые уровни обезличивания (impersonation levels). Если уровень обезличивания имеет значение ANONYMOUS, сервер не может определить, кто именно к нему обра­щается, а значит, не может каким-либо образом выступать от имени клиента.

Если клиент хочет получить доступ к ресурсам, он должен позволить серверу осуществлять контроль доступа, что требует уровня обезличивания IDENTIFY. Этот уровень позволяет серверу идентифицировать клиента, однако эта иденти­фикация может использоваться только на этом сервере и только для проверки наличия у клиента необходимых прав доступа.

Если разрешить серверу выдавать себя за клиента (уровень IMPERSONATE), по­является возможность обращений к локальным объектам этого сервера, в ходе которых сервер будет использовать мандат клиента. Если необходимо обраще­ние за пределы одной машины, уровень должен быть установлен в DELEGATE, что позволит клиенту делегировать права доступа серверу.

Программная защита

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

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

У программной защиты имеется интересная черта: процесс может также ука­зать и службу защиты, которую он хочет использовать для обеспечения защиты. Обычно эта служба относится к той операционной системе, поверх которой ра­ботает DCOM. DCOM различает пять служб аутентификации, представленных в табл. 9.10, а также три службы авторизации, перечисленные в табл. 9.11. Число служб в обоих случаях легко увеличить. Наличие или отсутствие конкретной службы зависит не от DCOM, а от операционной системы. Так, например, в Win­dows 2000 обычно доступны такие службы, как SSL и версия Kerberos с асиммет­ричной криптосистемой.

Так настроить параметры активизации, чтобы клиент получил возможность создавать экземпляры объекта, невозможно. Эту информацию можно только декларировать, поскольку SCM машины, на которой создается объект, всегда проверяет реестр, чтобы убедиться, что привилегии клиента соответствуют акти­визации. Однако можно делегировать право на активизацию другому процессу. Детали можно найти в [132].