Страница 198 из 372
• Далее общение сервера 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, содержащей некоторые данные об удаленной машине, о клиенте, о требуемом уровне безопасности
• IID запрашиваемого интерфейса (обычно IID_IClassFactory)
Единственный выходной параметр при успешном выполнении вызова возвращает указатель на запрашиваемый интерфейс.
Самый интересный для нас параметр — указатель на структуру COSERVERINFO. Предположим для начала, что этот указатель равен NULL.
В этом случае вся связанная с данным вызовом информация на стороне клиента определяется по умолчанию:
• Имя машины
В реестре машины клиента под ключом CLSID должен иметься раздел для нужного класса (CLSID класса), а в нем подключен RemoteServerName, определяющий имя удаленной машины, на которой установлено приложение, содержащее этот класс.
• Уровень аутентификации
Как клиентское, так и серверное приложение должны определить требуемый ими уровень аутентификации. При их несовпадении выбирается максимальный из двух уровней. Уровень аутентификации по умолчанию для всех приложений, установленных на данной машине, определяется ее администратором. Приложение может само определить требуемый ему уровень аутентификации и даже изменить его в процессе выполнения. Ниже приводятся возможные значения этого уровня:
1. None
Аутентификация не выполняется. В этом случае клиент анонимен для сервера и никакого контроля за передаваемыми данными не проводится.
2. Co
Именно этот уровень обычно выбирается администратором как уровень по умолчанию. Аутентификация клиента выполняется при первом соединении клиента с сервером. Защиты передаваемых данных нет.
3. Call
Аутентификация клиента выполняется при каждом вызове метода сервера. Выполняется защита от перехвата и прочтения передаваемых данных стандартными средствами. Для этого выполняется шифрование последовательных номеров передаваемых пакетов.
4. Packet
Аутентификация выполняется при пересылке каждого пакета. Шифруются номера передаваемых пакетов.
5. Packet lntegrity
Кроме того, что выполняется на предыдущем уровне, вычисляется, шифруется и передается контрольная сумма пакета. В результате контролируется целостность передаваемых данных.
6. Packet Privacy
В дополнение к функциональности предыдущего уровня выполняется шифрование всех передаваемых данных.
Выбор того или иного уровня аутентификации определяется соотношением степени секретности данных и расходами на поддержку того или иного уровня безопасности. СОМ+ предоставляет возможность задавать разные уровни безопасности динамически, что позволяет гибко учитывать требования приложения к безопасности.
• Уровень имперсонализации
Этот уровень определяется только клиентским приложением (и серверным, когда оно выступает клиентом по отношению к другому серверному приложению). Уровень имперсонализации определяет объем прав доступа, которые клиентское приложение желает передать серверному.
Рассмотрим прежде всего сам механизм имперсонализации. После входа пользователя в систему все запускаемые (прямо и косвенно) им процессы имеют маркер доступа (access token), содержащий, в частности, такую информацию как SID (Security IDentifier) пользователя и SID всех груп, в которых зарегистрирован данный пользователь, а также различные его привилегии. Каждому локальному ресурсу приписан список ACL (Access Control List), содержащий элементы АСЕ (Access Control Entry), в каждом из которых разрешается или запрещается определенный набор способов доступа к данному ресурсу для некоторого SID. При попытке обращения некоторого потока к некоторому локальному ресурсу происходит последовательный просмотр ACL этого ресурса и все SID из маркера доступа процесса, содержащего данный поток, сопоставляются с SID из очередного АСЕ. Процесс просмотра ACL прекращается, как только выясняется, что данный поток обладает достаточными правами для доступа к ресурсу, либо, напротив, что доступ запрещается.
Каждое запущенное серверное приложение в СОМ+ является принципалом, обладающим собственным SID. Предположим, что некоторый поток в этом приложении исполняет вызов, пришедший от некоторого клиента. По умолчанию права доступа данного потока определяются маркером доступа процесса, в котором исполняется приложение. Таким образом, по умолчанию используются права доступа, данные администратором принципалу, от имени которого запущено приложение. Однако, как правило, принципал, от имени которого запущено приложение, не совпадает с клиентом, запустившим приложение. Таким образом, прав приложения может быть недостаточно для доступа к необходимым локальным ресурсам. Однако эти права могут иметься у клиента. Вызвав функцию ImpersonateClient (подробнее это будет рассмотрено далее), поток серверного приложения будет далее использовать новый маркер доступа, содержащий данные вызвавшего его клиента, и, следовательно, сможет выступать от его имени.