Поделиться через

Маскировка (COM)

  • Статья

Маскировка — это возможность безопасности COM, которая определяет, какое удостоверение выполняет клиентские проекты по отношению к серверу во время олицетворения. При настройке маскировки промежуточного сервера маскирует собственное удостоверение и представляет удостоверение клиента серверу, который он вызывает от имени клиента. Основном; Удостоверение клиента, которое видно сервером, — это удостоверение, связанное с прокси-сервером. Удостоверение прокси-сервера определяется несколькими факторами, одним из которых является тип маскировки, который устанавливается (если таковой имеется). Маскировка не поддерживается поставщиком безопасности Schannel.

Дополнительные сведения о маскировке см. в следующих разделах:

Типы закрытий

Существует два типа плащ: статическая плащ и динамическая маскировка:

  • При статической маскировке (EOAC_STATIC_CLOAKING) сервер видит маркер потока от первого вызова клиента к серверу. Для первого вызова, если удостоверение прокси-сервера было установлено ранее во время вызова CoSetProxyBlanket, это удостоверение прокси-сервера используется. Однако если удостоверение прокси-сервера не было задано ранее, используется маркер потока. Если маркер потока отсутствует, используется маркер процесса. Для всех будущих вызовов используется набор удостоверений первого вызова.
  • При динамической маскировке (EOAC_DYNAMIC_CLOAKING), при каждом вызове текущего маркера потока (если есть маркер потока) используется для определения удостоверения клиента. Если маркер потока отсутствует, используется маркер процесса. Это означает, что серверы, вызываемые от имени клиента во время олицетворения, видят удостоверение com-клиента, который вызвал вызов, который обычно является требуемым поведением. (Конечно, для успешного олицетворения клиент должен предоставить серверу полномочия олицетворения, задав соответствующий уровень олицетворения. Дополнительные сведения см. в разделе "Уровни олицетворения".) Этот тип маскировки дорого.

Как маскировка влияет на удостоверение клиента

Когда выполняется зашифрованный вызов, и сервер запрашивает у клиента удостоверение, он обычно получает удостоверение, связанное с прокси-сервером. (Иногда служба проверки подлинности выполняет перевод с реального удостоверения, но обычно это удостоверение прокси-сервера. Прокси-сервер представляет удостоверение для сервера, зависящее от типа маскировки, установленного и других факторов.

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

Маскирование флагов Присутствие маркера потока Ранее задано удостоверение прокси-сервера Прокси-удостоверение (удостоверение клиента)
Закрывание не задано
 Don't care
 Don't care
 Маркер обработки или удостоверение проверки подлинности
EOAC_STATIC_CLOAKING
 Сейчас
 No
 Маркер потока
EOAC_STATIC_CLOAKING
 Сейчас
 Да
 Текущее удостоверение прокси-сервера
EOAC_STATIC_CLOAKING
 Отсутствует
 No
 Маркер обработки
EOAC_STATIC_CLOAKING
 Отсутствует
 Да
 Текущее удостоверение прокси-сервера
EOAC_DYNAMIC_CLOAKING
 Сейчас
 Don't care
 Маркер потока
EOAC_DYNAMIC_CLOAKING
 Отсутствует
 Не заботьтесь
Маркер обработки

В следующей блок-схеме показано, как удостоверение прокси-сервера определяется в разных ситуациях.

Diagram that shows the flow for determining the proxy identity.

Настройка маскировки

Маскировка задается в качестве флага возможностей в вызове CoInitializeSecurity, который задает маскировку для всего процесса. Затем возможность маскирования устанавливается до тех пор, пока клиент не изменит его с помощью вызова IClientSecurity::SetBlanket (или CoSetProxyBlanket), который задает маскировку для прокси-сервера.

По умолчанию прикрытие не задано. Чтобы задать его, передайте EOAC_STATIC_CLOAKING или EOAC_DYNAMIC_CLOAKING в параметр pCapabilities в CoInitializeSecurity или SetBlanket.

При включении статической маскировки с помощью CoInitializeSecurity каждый прокси-сервер выбирает маркер (поток или процесс) при первом вызове прокси-сервера. Если статическая маскировка включена с помощью SetBlanket, прокси-сервер берет маркер в потоке в то время. Если маркер потока недоступен при вызове SetBlanket , маркер процесса используется для удостоверения прокси-сервера. В основном SetBlanket исправляет удостоверение прокси-сервера.

При динамической маскировке удостоверение прокси-сервера определяется так же, независимо от того, задана ли динамическая маскировка с помощью CoInitializeSecurity или с SetBlanket. Текущий маркер потока используется при наличии одного из них; в противном случае используется маркер процесса.

Если для всего процесса задана маскировка через вызов CoInitializeSecurity , и вы хотите выполнять вызовы с маркером процесса, не олицетворяйте при выполнении вызовов.

Уровни олицетворения и олицетворения

Как упоминание ранее, возможность маскирования определяет, какое удостоверение представлено серверу во время олицетворения. Маскировка позволяет серверу проектировать удостоверение, отличное от собственного на другой сервер, который вызывается от имени клиента. Уровень олицетворения указывает, сколько полномочий клиент дал серверу.

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

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

В некоторых ситуациях сервер может задать маскировку, когда клиент устанавливает уровень олицетворения RPC_C_IMP_LEVEL_IMPERSONATE. Однако некоторые ограничения в действительности. Если исходный клиент задает уровень олицетворения RPC_C_IMP_LEVEL_IMPERSONATE, промежуточный сервер (выступая в качестве клиента на том же компьютере), может закрыть только одну границу компьютера. Это связано с тем, что маркер олицетворения на уровне олицетворения можно передавать только через одну границу компьютера. После пересечения границы компьютера доступ к доступу можно получить только к локальным ресурсам. Удостоверение, представленное серверу, зависит от типа закрытия, заданного. Если не задано прикрытие, удостоверение, представленное серверу, будет таким процессом, который выполняет немедленный вызов.

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

Например, предположим, что процесс A вызывает B и вызовЫ B. B устанавливает маскировку и A задает уровень олицетворения для олицетворения. Если A, B и C находятся на одном компьютере, передача маркера олицетворения от A до B, а затем на C будет работать. Но если A и C находятся на одном компьютере, и B не является, передача маркера будет работать между A и B, но не из B в C. Вызов из B в C завершится ошибкой, так как B не может вызывать C во время маскировки. Однако если A задает уровень олицетворения для делегата, маркер можно передать из B в C и вызов может завершиться успешно.

Сценарии маскирования

На следующем рисунке обработка вызовов B, вызовов C, вызовов D при скрытии не задана. В результате каждый промежуточный процесс видит удостоверение процесса, вызываемого им.

Diagram that shows the process when cloaking is not set.

При статической маскировке сервер видит удостоверение прокси-сервера, которое было установлено во время первого вызова клиента на сервер. На следующем рисунке показан пример удостоверения прокси-сервера, заданного во время вызова из B в C. При последующем вызове Process D видит удостоверение B при установке статической маскировки B и C.

Diagram that shows the process for static cloaking.

При динамической маскировке идентификатор вызывающего объекта во время олицетворения основан на текущем маркере потока, если есть один. На следующем рисунке показана ситуация, когда В и C задана динамическая маскировка и D отображается удостоверение A, несмотря на более ранний вызов из B в C.

Diagram that shows the process for dynamic cloaking.

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