Реализация сервисов проверки целостности данных и шифрования трафика

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

Делегирование

Подробно понятие делегирования (как и понятие имперсонализация) будут рассматриваться далее. Здесь будет объяснена только его суть и описан механизм реализации делегирования в Windows 2000 Kerberos.

При имперсонализации клиента (с его согласия) сервер получает доступ к локальным ресурсам от имени данного клиента (уровень передаваемых прав доступа определяется клиентом). Однако имперсонализация не позволяет серверу делать удаленные вызовы других серверов от имени клиента. Конечно, выполняя некоторый вызов клиента С сервер S может послать удаленный вызов на другой сервер Q, но с точки зрения сервера Q вызов получен именно от сервера S, а не клиента С. Следовательно, даже если клиент С имеет особые права доступа к серверу Q, сервер S не сможет ими воспользоваться, выполнив простую имперсонализацию клиента С.

В чем причина ограниченности возможностей имперсонализации? Имперсонализация реализуется средствами конкретной операционной системы. При имперсонализации в Windows потоку в серверном процессе, выполняющему вызов пользователя, приписывается маркер доступа (access token), в котором записаны права данного пользователя, а не серверного процесса (как обычно бывает по умолчанию). Это позволяет получить от имени пользователя доступ к локальным ресурсам, т. к. при этом просто сопоставляются права доступа из маркера доступа со списком принципалов, которым разрешен или запрещен доступ к конкретному локальному ресурсу.

При удаленном доступе необходимо обеспечить такие сервисы как аутентификация, контроль целостности данных, шифрование трафика. Очевидно, что маркер доступа не содержит необходимых для этого данных. Фактически, говоря в терминах протокола Kerberos, Сервер S должен обратиться к KDS с запросом на получение билета для сервера Q, причем сервер Q при получении этого билета должен быть уверен, что получил он его от клиента С, а не от сервера S.

Данная возможность реализована в Kerberos и называется делегированием. Отметим, что делегирование отсутствует в NT LAN Manager.

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

• Клиент С посылает серверу S (которым он уже аутентифицирован) свой билет для KDS — и ключ сессии с KDS —

Сервер S должен иметь эти данные для того, чтобы получить от KDC билет для какого-либо другого сервера (например, Q), выданный как бы клиенту С. В отличие от сервера Q, KDS обмануть очень сложно (да и сервер Q можно обмануть только с помощью самого KDS). Поэтому от KDS и не скрывается то, что запрашивает билет сервер S, но выписать его необходимо на имя клиента С. Среди флагов билета TGT должен быть флаг forwardable, указывающий на то, что клиент С еще при первом обращении к KDS уведомил его о том, что в будущем он будет делегировать свои полномочия другим серверам (кстати, не любому серверу, а только тому, который зарегистрирован в домене как заслуживающий доверия (trusted) сервер).

• Сервер S посылает (от лица клиента С) запрос KDS на получение билета для сервера Q, в который включается, как обычно, имя сервера Q, билет и аутентификатор

Зметим, что в аунтетификатор включается имя клиента и он кодируется ключом сессии клиента С и KDS.

• KDS аутентифицирует клиента

Конечно, KDS замечает, что билет запрашивает не клиент С (вызов пришел не с того IP адреса, который указан в TGT). Однако он закрывает на это глаза в связи с тем, что в

TGT имеется флаг forwardable, и отправитель запроса знает ключ, который он мог получить только от клиента

• KDS посылает серверу S запрошенный билет, зашифрованный ключом сервера Q, и ключ сессии сервера S и сервера Q -

• Далее общение сервера S и сервера Q проходит как обычное общение клиента и сервера. Заметим, что с точки зрения сервера Q он работает с клиентом С. Это позволяет серверу S делегировать полученные от клиента полномочия серверу Q и т. д. Для этого у него есть все необходимое: TGT, закодированный ключом KDS, и ключ сессии

Удаленный вызов за пределы домена

Проблема удаленного вызова за пределы домена состоит в том, что клиент должен получить билет для сервера из другого домена у KDS этого другого домена. Но наш клиент не зарегистрирован в этом новом домене и, следовательно, не может получить там TGT.

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

• Клиент С из первого домена, желающий получить доступ к серверу R из второго домена обращается прежде всего к KDS своего домена. Первый KDS возвращает клиенту новую версию его TGT, зашифрованную паролем и ключ сессии для общения с KDS второго домена (это ключ хранится и в новой версии TGT).

• Клиент отправляет KDS второго домена новый TGT, зашифрованный ключом и аутентификатор, зашифрованный ключом сессии клиента и второго KDS.

• Второй KDS расшифровывает TGT и, доверяя первому KDS, возвращает клиенту билет для запрашиваемого сервера из своего домена.

Модель безопасности в СОМ+

Как уже говорилось ранее, определенная независимость модели безопасности, используемой в СОМ+, достигается за счет использования интерфейса SSPI, через который СОМ+ может пользоваться услугами различных провайдеров сервиса безопасности SSP. Для определенности остановимся на SSP, представленном реализацией в Windows 2000 протокола Kerberos. Будем полагать, что все клиенты и серверы в данном домене используют этот SSP.

Как и другие сервисы СОМ+, сервис безопасности может быть использован без написания какого-либо кода, за счет администрирования. Однако возможен (и в некоторых случаях очень полезен) программный доступ к этому сервису.

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

Активация серверного приложения клиентским приложением

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

• CLSID нужного класса

• Тип сервера (сервер в процессе клиента, локальный или удаленный)

• Указатель на структуру COSERVERINFO, содержащей