Сущность технологии СОМ. Библиотека программиста

ОглавлениеДобавить в закладки К обложке

COM и защита

Исходная версия COM не занималась проблемой защиты. Это можно рассматривать как упущение, так как многие примитивы NT без удаленного доступа (nonremotable) (например, процессы, потоки) могут быть защищены, несмотря на то, что ими нельзя управлять дистанционно. Версия Windows NT 4.0 вынудила добавить к COM обеспечение безопасности, так как стало возможным осуществлять доступ к серверным процессам практически от любой машины в сети. К счастью, поскольку COM использует в качестве средства сообщения RPC, то защита COM просто применяет существующую инфраструктуру защиты RPC.

Защита COM может быть разделена на три категории: аутентификация (authentication), контроль доступа (access control) и управление маркерами (token management). Аутентификация заключается в обеспечении подлинности сообщения, а именно: отправитель действительно тот, за кого он себя выдает, а данное сообщение действительно пришло от отправителя. Контроль за доступом проверяет, кто имеет допуск к объектам сервера и кто имеет право запуска серверного процесса. Управление маркерами осуществляет контроль за тем, чьи полномочия использованы при запуске серверных процессов и при выполнении самого вызова метода. В COM предусмотрены до некоторой степени разумные установки по умолчанию по всем трем аспектам защиты, что делает теоретически возможным писать приложения COM, не учитывая вопросов безопасности. Эти установки по умолчанию основаны на принципе наименьших сюрпризов; то есть если программист не делает ничего явного по защите, то маловероятно, что этим будут внесены какие-либо «дыры» в систему безопасности NT. В то же время построение даже простейшего рассредоточенного приложения на базе COM требует, чтобы каждому аспекту обеспечения безопасности было уделено определенное внимание.

Большинство аспектов защиты COM может быть сконфигурировано путем помещения в реестр нужной информации. Программа DCOMCNFG.ЕХЕ позволяет администраторам настраивать большинство установок (но не все), относящихся к защите COM. Для большинства этих установок (но не для всех) программист приложения может предпочесть употребление явных API-функций вместо установок в реестре. В целом большинство приложений используют комбинацию установок DCOMCNFG.EXE с явными API-функциями. Первый вариант проще для отладки системными администраторами, в то время как второй предполагает большую гибкость без риска неправильного обращения с DCOMCNFG.EXE.

Защита COM использует основные средства RPC для аутентификации и заимствования прав (impersonation). Напомним, что RPC использует загружаемые транспортные модули для того, чтобы после их загрузки в систему были добавлены новые сетевые протоколы. Транспортные модули именуются при помощи последовательностей протоколов (protocol sequences) (например, «ncadg_ip_udp»), которые преобразуются в реестре в специальную транспортную библиотеку DLL. Это позволяет третьим участникам устанавливать поддержку новых транспортных протоколов без модифицирования библиотеки COM. Подобным же образом RPC поддерживает загружаемые модули защиты, позволяя добавлять в систему новые протоколы защиты. Модули защиты именуются при помощи целых чисел, которые преобразуются в реестре в специальные DLL модулей защиты. Эти DLL должны соответствовать требованиям SSPI (Security Support Provider Interface – интерфейс провайдера поддержки безопасности), который является производным от Internet Draft Standard GSSAPI.

В системных заголовочных файлах определено несколько констант для известных модулей защиты. Ниже приведен текущий список известных на момент написания этого текста модулей защиты:

enum {

RPC_C_AUTHN_NONE = 0, // no authentication package

// модуля аутентификации нет

RPC_C_AUTHN_DCE_PRIVATE = 1, // DCE private key (not used)

// закрытый ключ DCE (не используется)

RPC_C_AUTHN_DCE_PUBLIC = 2, // DCE public key (not used)

// открытый ключ DCE (не используется)

RPC_C_AUTHN_DEC_PUBLIC = 4, // Digital Equip, (not used)

// цифровое оборудование (не используется)

RPC_C_AUTHN_WINNT = 10, // NT Lan Manager

// администратор локальной сети NT

RPC_C_AUTHN_GSS_KERBEROS,

RPC_C_AUTHN_MQ = 100, // MS Message Queue package

// модуль MS Message Queue (очереди сообщений Microsoft)

RPC_C_AUTHN_DEFAULT = 0xFFFFFFFFL

};

RPC_C_AUTHN_WINNT показывает, что должен использоваться протокол аутентификации Администратора локальной сети (NT LAN (local area network) Manager – NTLM). RPC_C_AUTHN_GSS_KERBEROS показывает, что будет использован протокол аутентификации Kerberos. Под Windows NT 4.0 поддерживается только протокол NTLM, если не установлена SSP третьего участника. Windows NT 5.0 будет выпущена с поддержкой как минимум NTLM и Kerberos. По вопросам получения других модулей защиты обращайтесь к соответствующей документации.


-= 185 =-
Регистрация.
Забыли пароль?
Логин
Пароль
Запомнить меня