Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Маскирование — это функция безопасности COM, которая определяет, какое удостоверение клиент показывает серверу во время имперсонации. При включении маскировки промежуточный сервер скрывает свою идентичность и выставляет идентичность клиента серверу, к которому он обращается от имени клиента. По сути, удостоверение клиента, видимое сервером, — это удостоверение, связанное с прокси-сервером. Идентификация прокси определяется несколькими факторами, один из которых - тип используемой маскировки (если таковая имеется). Маскировка не поддерживается поставщиком безопасности Schannel.
Дополнительные сведения о маскировке см. в следующих разделах:
- Типы маскировки
- Как маскировка влияет на идентичность клиента
- Настройка маскировки
- Уровни маскировки и олицетворения
- сценарии маскирования
- Связанные темы
Типы маскировки
Существует два типа маскировки: статическая маскировка и динамическая маскировка.
- При статической маскировке (EOAC_STATIC_CLOAKING) сервер видит маркер потока от первого вызова клиента к серверу. Для первого вызова, если удостоверение прокси-сервера было установлено ранее во время вызова CoSetProxyBlanket, используется это удостоверение прокси-сервера. Однако если прокси-идентификация не была задана ранее, используется токен потока. Если маркер потока отсутствует, используется маркер процесса. Для всех будущих вызовов используется идентификатор, установленный в первом вызове.
- При динамической маскировке (EOAC_DYNAMIC_CLOAKING) при каждом вызове используется текущий маркер потока (если он есть) для определения личности клиента. Если маркер потока отсутствует, используется маркер процесса. Это означает, что серверы, вызываемые от имени клиента во время олицетворения, видят удостоверение COM-клиента, инициировавшего вызов, что обычно является требуемым поведением. (Конечно, для успешного олицетворения клиент должен предоставить серверу полномочия олицетворения, задав соответствующий уровень олицетворения. Дополнительные сведения см. в разделе Уровни олицетворения.) Этот тип маскировки дорого.
Как маскировка влияет на идентичность клиента
Когда выполняется зашифрованный вызов, и сервер запрашивает у клиента удостоверение, он обычно получает удостоверение, связанное с прокси-сервером. (Иногда служба проверки подлинности преобразует реальное удостоверение, но обычно прокси-удостоверение — это то, что видит сервер.) Прокси-сервер представляет удостоверение серверу, которое зависит от типа установленной маскировки и других факторов.
Подводя итог, идентификация клиента является функцией установки флагов маскирования, токена процесса, наличия или отсутствия токена потока и того, задана ли ранее личность прокси. В следующей таблице показана результирующая идентификация прокси-сервера (удостоверение клиента) при изменении этих факторов.
| Маскирование флагов | Присутствие маркера потока | Ранее задана идентификация прокси. | Прокси-удостоверение (удостоверение клиента) |
|---|---|---|---|
| Маскировка не задана |
Не заботьтесь |
Не заботьтесь |
Процессный токен или удостоверение личности для аутентификации |
| EOAC_STATIC_CLOAKING |
Присутствующий |
Нет |
Маркер потока |
| EOAC_STATIC_CLOAKING |
Присутствующий |
Да |
Текущая идентификация прокси |
| EOAC_СТАТИЧЕСКОЕ_Маскирование |
Нет |
Нет |
Маркер обработки |
| EOAC_STATIC_CLOAKING |
Отсутствует |
Да |
Текущая идентичность прокси |
| EOAC_DYNAMIC_CLOAKING |
Присутствующий |
Не заботьтесь |
Маркер потока |
| EOAC_DYNAMIC_CLOAKING |
Нет |
Не заботьтесь |
Маркер обработки |
В следующей блок-схеме показано, как удостоверение прокси-сервера определяется в разных ситуациях.
Настройка маскировки
Закрывание задается в качестве флага возможностей в вызове CoInitializeSecurity, который задает маскировку для всего процесса. Затем возможность маскирования устанавливается до тех пор, пока клиент не изменит его через вызов IClientSecurity::SetBlanket (или CoSetProxyBlanket), который задает маскировку для прокси-сервера.
По умолчанию прикрытие не задано. Чтобы задать его, передайте параметру pCapabilities значение EOAC_STATIC_CLOAKING или EOAC_DYNAMIC_CLOAKING в CoInitializeSecurity или SetBlanket.
При включении статической маскировки с помощью CoInitializeSecurityкаждый прокси получает токен (потоковый или процессный) при первом вызове. Если статическая маскировка включена с помощью SetBlanket, прокси-сервер подхватывает токен в потоке в тот момент. Если маркер потока недоступен при вызове SetBlanket, маркер процесса используется для удостоверения прокси-сервера. В основном SetBlanket устанавливает идентификацию прокси-сервера.
При динамической маскировке удостоверение прокси-сервера определяется одинаково, независимо от того, задана ли динамическая маскировка с помощью CoInitializeSecurity или с использованием SetBlanket. Текущий маркер потока используется при наличии одного из них; в противном случае используется маркер процесса.
Если для всего процесса задано скрытие с помощью вызова CoInitializeSecurity, и вы хотите выполнить вызовы с маркером процесса, не выполняйте олицетворение при выполнении вызовов.
Уровни маскировки и имитации
Как упоминалось ранее, функция сокрытия определяет, какая идентичность представлена серверу во время имитации. Маскировка позволяет серверу представлять удостоверение, отличное от собственного, другому серверу, который он вызывает от имени клиента. Уровень олицетворения указывает, сколько полномочий клиент дал серверу.
Имперсонализация без маскировки может работать, но это может быть не лучшим выбором, так как в некоторых случаях конечный сервер должен знать личность начального вызывающего объекта. Это невозможно сделать, не используя маскировку, так как трудно убедиться, что только авторизованные клиенты могут получить доступ к удаленному компьютеру. Если олицетворение используется без маскировки, идентификатор, представленный нижестоящему серверу, является идентификатором непосредственно вызывающего процесса.
Однако маскировка не полезна без олицетворения. Маскировка имеет смысл только в том случае, если клиент установил уровень олицетворения для олицетворения или делегирования. (При более низких уровнях имперсонации сервер не может выполнять замаскированные вызовы.) Успешность маскировки зависит от количества пересекаемых границ компьютера и уровня имперсонации, который показывает, сколько полномочий имеет сервер для действий от имени клиента.
В некоторых ситуациях сервер может установить режим маскировки, когда клиент задает уровень олицетворения RPC_C_IMP_LEVEL_IMPERSONATE. Однако некоторые ограничения действуют. Если исходный клиент задает уровень олицетворения RPC_C_IMP_LEVEL_IMPERSONATE, промежуточный сервер, действующий как клиент на том же компьютере, может скрыться только за пределами одной границы компьютера. Это связано с тем, что токен имперсонейшн можно передавать только через одну границу вычислительной системы. После пересечения границы компьютера доступ к доступу можно получить только к локальным ресурсам. Подтверждение, представляемое серверу, зависит от установленного типа маскирования. Если прикрытие не установлено, удостоверение, представленное серверу, будет принадлежать процессу, совершающему непосредственный вызов.
Чтобы скрыть несколько границ между компьютерами, необходимо указать как соответствующий флаг возможности маскирования, так и имперсонацию с уровнем делегата. При использовании этого типа олицетворения учетные данные клиента, как локальные, так и сетевые, предоставляются серверу, поэтому маркер олицетворения может пересекать любое количество границ компьютера. Снова идентификация, представленная серверу, зависит от типа маскировки, заданного. Если маскировка на уровне делегирования не установлена, удостоверение, представленное серверу, относится к процессу, выполняющему вызов.
Например, предположим, что процесс A вызывает B, а B вызывает C. B устанавливает маскировку, а A задает уровень олицетворения на олицетворение. Если A, B и C находятся на одном компьютере, передача маркера олицетворения от A к B, а затем к C будет успешной. Но если A и C находятся на одном компьютере, и B не является, передача маркера будет работать между A и B, но не из B в C. Вызов из B в C завершится ошибкой, так как B не может вызывать C во время маскировки. Однако если A задает уровень олицетворения для делегата, маркер можно передать из B в C и вызов может завершиться успешно.
Сценарии маскирования
На следующем рисунке процесс A вызывает процесс B, затем вызывает C, затем вызывает D, когда режим скрытия не установлен. В результате каждый промежуточный процесс видит идентичность процесса, который его вызвал.
При статической маскировке сервер видит удостоверение прокси-сервера, которое было установлено во время первого вызова клиента на сервер. На следующем рисунке показан пример идентификатора прокси, заданного во время вызова от B к C. При последующем вызове Process D видит идентификатор B, когда установлена статическая маскировка B и C.
При динамической маскировке идентификатор вызывающего объекта во время олицетворения основан на текущем маркере потока, если есть один. На следующем рисунке показана ситуация, когда B и C устанавливают динамическую маскировку, и D видит идентификатор A, несмотря на более ранний вызов от B к C.