Compartilhar via


Cloaking (COM)

Cloaking é um recurso de segurança COM que determina qual identidade o cliente projeta para o servidor durante a representação. Quando a ocultação é definida, o servidor intermediário mascara sua própria identidade e apresenta a identidade do cliente ao servidor que ele chama em nome do cliente. Basicamente; A identidade do cliente que é vista pelo servidor é a identidade associada ao proxy. A identidade do proxy é determinada por vários fatores, um dos quais é o tipo de camuflagem que é definido (se houver). O cloaking não é suportado pelo provedor de segurança Schannel.

Os tópicos a seguir fornecem mais informações sobre cloaking:

Tipos de camuflagem

Existem dois tipos de camuflagem: camuflagem estática e camuflagem dinâmica:

  • Com o cloaking estático (EOAC_STATIC_CLOAKING), o servidor vê o token de thread da primeira chamada de um cliente para o servidor. Para a primeira chamada, se a identidade do proxy foi definida anteriormente durante uma chamada para CoSetProxyBlanket, essa identidade de proxy será usada. No entanto, se a identidade do proxy não tiver sido definida anteriormente, o token de thread será usado. Se nenhum token de thread estiver presente, o token de processo será usado. Para todas as chamadas futuras, a identidade definida na primeira chamada é usada.
  • Com o dynamic cloaking (EOAC_DYNAMIC_CLOAKING), em cada chamada o token de thread atual (se houver um token de thread) é usado para determinar a identidade do cliente. Se não houver nenhum token de thread, o token de processo será usado. Isso significa que os servidores chamados em nome do cliente durante a representação veem a identidade do cliente COM que originou a chamada, que geralmente é o comportamento desejado. (É claro que, para que a representação seja bem-sucedida, o cliente deve ter dado ao servidor autoridade para representar definindo um nível de representação apropriado. Para obter mais informações, consulte Níveis de representação.) Esse tipo de camuflagem é caro.

Como o encobrimento afeta a identidade do cliente

Quando uma chamada criptografada é feita e o servidor pede ao cliente sua identidade, ele geralmente obtém a identidade vinculada ao proxy. (Às vezes, o serviço de autenticação executa uma tradução da identidade real, mas geralmente a identidade do proxy é a identidade que o servidor vê.) O proxy apresenta uma identidade para o servidor que depende do tipo de cloaking definido e de outros fatores.

Para resumir, a identidade do cliente é uma função do conjunto de sinalizadores de camuflagem, do token de processo, da presença ou ausência de um token de thread e se a identidade do proxy foi definida anteriormente. A tabela a seguir mostra a identidade de proxy resultante (identidade do cliente) quando esses fatores variam.

Bandeiras de camuflagem Presença do Token de Thread Identidade de proxy definida anteriormente Identidade do Proxy (Identidade do Cliente)
Cloaking não definido
Não importa
Não importa
Token de processo ou identidade de autenticação
EOAC_STATIC_CLOAKING
Presente
Não
Token de thread
EOAC_STATIC_CLOAKING
Presente
Sim
Identidade de proxy atual
EOAC_STATIC_CLOAKING
Não presente
Não
Token de processo
EOAC_STATIC_CLOAKING
Não presente
Sim
Identidade de proxy atual
EOAC_DYNAMIC_CLOAKING
Presente
Não importa
Token de thread
EOAC_DYNAMIC_CLOAKING
Não presente
Não se importe
Token de processo

O fluxograma a seguir ilustra como a identidade do proxy é determinada em diferentes situações.

Diagram that shows the flow for determining the proxy identity.

Cloaking de configuração

Cloaking é definido como um sinalizador de capacidade em uma chamada para CoInitializeSecurity, que define cloaking para todo o processo. O recurso de cloaking é então definido até que o cliente o altere por meio de uma chamada para IClientSecurity::SetBlanket (ou para CoSetProxyBlanket), que define o cloaking para o proxy.

Por padrão, a camuflagem não está definida. Para defini-lo, passe EOAC_STATIC_CLOAKING ou EOAC_DYNAMIC_CLOAKING para o parâmetro pCapabilities em CoInitializeSecurity ou SetBlanket.

Quando o cloaking estático é habilitado usando CoInitializeSecurity, cada proxy pega um token (thread ou processo) na primeira vez que você faz uma chamada no proxy. Quando o cloaking estático é habilitado usando SetBlanket, o proxy pega o token no thread naquele momento. Se nenhum token de thread estiver disponível quando SetBlanket for chamado, o token de processo será usado para a identidade do proxy. Basicamente, SetBlanket corrige a identidade do proxy.

Com o encobrimento dinâmico, a identidade do proxy é determinada da mesma maneira, independentemente de o encobrimento dinâmico ser definido usando CoInitializeSecurity ou SetBlanket. O token de thread atual é usado se houver um; caso contrário, o token de processo será usado.

Se a ocultação estiver definida para todo o processo por meio de uma chamada para CoInitializeSecurity e você quiser fazer chamadas com o token de processo, não represente ao fazer chamadas.

Níveis de camuflagem e representação

Como mencionado anteriormente, o recurso de ocultação determina qual identidade é apresentada a um servidor durante a representação. O Cloaking fornece uma maneira de um servidor projetar uma identidade diferente da sua para outro servidor que ele está chamando em nome do cliente. O nível de representação indica quanta autoridade o cliente deu ao servidor.

A representação sem camuflagem funciona, mas pode não ser a melhor escolha porque, em alguns casos, o servidor final precisa saber a identidade do chamador inicial. Isso não pode ser feito sem o uso de cloaking porque é difícil garantir que apenas clientes autorizados possam acessar um computador remoto. Quando a representação é usada sem camuflagem, a identidade apresentada a um servidor downstream é a do processo de chamada imediata.

No entanto, a camuflagem não é útil sem imitação. A camuflagem só faz sentido quando o cliente define um nível de representação de representação ou delegado. (Com níveis de representação mais baixos, o servidor não pode fazer chamadas ocultas.) Se o cloaking é bem-sucedido depende do número de limites de computador cruzados e do nível de representação, que indica quanta autoridade o servidor tem para agir em nome do cliente.

Em algumas situações, faz sentido para o servidor definir cloaking quando o cliente define o nível de representação como RPC_C_IMP_LEVEL_IMPERSONATE. No entanto, algumas limitações estão em vigor. Se o cliente original definir o nível de representação como RPC_C_IMP_LEVEL_IMPERSONATE, o servidor intermediário (atuando como um cliente no mesmo computador) poderá ocultar apenas um limite de computador. Isso ocorre porque um token de representação em nível de representação pode ser passado através de apenas um limite de computador. Depois que o limite do computador for ultrapassado, somente os recursos locais poderão ser acessados. A identidade apresentada ao servidor depende do tipo de camuflagem definido. Se nenhuma ocultação for definida, a identidade apresentada a um servidor será a do processo que faz a chamada imediata.

Para ocultar vários limites de computador, você deve especificar um sinalizador de capacidade de ocultação apropriado e representação em nível de delegado. Com esse tipo de representação, as credenciais locais e de rede do cliente são fornecidas ao servidor, para que o token de representação possa cruzar qualquer número de limites do computador. Novamente, a identidade apresentada ao servidor depende do tipo de camuflagem definido. Se nenhuma ocultação for definida com representação em nível de delegado, a identidade apresentada a um servidor será a do processo que faz a chamada.

Por exemplo, suponha que o Processo A chame B e B chame C. B tenha definido cloaking e A tenha definido o nível de representação para representar. Se A, B e C estiverem no mesmo computador, passar o token de representação de A para B e, em seguida, para C funcionará. Mas se A e C estiverem no mesmo computador, e B não estiver, passar o token funcionará entre A e B, mas não de B para C. A chamada de B para C falhará porque B não pode chamar C durante a camuflagem. No entanto, se A definir o nível de representação para delegar, o token poderá ser passado de B para C e a chamada poderá ser bem-sucedida.

Cenários de camuflagem

Na ilustração a seguir, o Processo A chama B, chama C, chama D quando o encobrimento não está definido. Como resultado, cada processo intermediário vê a identidade do processo que o chamou.

Diagram that shows the process when cloaking is not set.

Com o cloaking estático, o servidor vê a identidade de proxy que foi definida durante a primeira chamada do cliente para o servidor. A figura a seguir mostra um exemplo da identidade de proxy que está sendo definida durante uma chamada de B para C. Em uma chamada subsequente, o Processo D vê a identidade de B quando o encobrimento estático é definido por B e C.

Diagram that shows the process for static cloaking.

Com o encobrimento dinâmico, a identidade do chamador durante a representação é baseada no token de thread atual, se houver. A ilustração a seguir mostra a situação em que B e C definem camuflagem dinâmica e D vê a identidade de A, apesar de uma chamada anterior de B para C.

Diagram that shows the process for dynamic cloaking.

Delegação e representação