Escolhendo opções de QOS de segurança

As opções de QOS de segurança são passadas como parte do parâmetro SecurityQOS dado à função RpcBindingSetAuthInfoEx . Use as práticas recomendadas a seguir.

Usar Autenticação Mútua

A autenticação mútua verdadeira está disponível apenas para determinados provedores de segurança: Negotiate (quando negocia Kerberos), Kerberos e Schannel. O NTLM não dá suporte à autenticação mútua. O uso da autenticação mútua requer que um nome de entidade de segurança do servidor bem formado seja fornecido. Muitos desenvolvedores usam a seguinte prática de segurança com falha: o servidor é chamado para solicitar seu nome principal (RpcMgmtInqServerPrincName) e, em seguida, solicitam cegamente a autenticação mútua usando esse nome principal. Essa abordagem interrompe toda a ideia de autenticação mútua; a ideia de autenticação mútua é que apenas determinados servidores são chamados porque são confiáveis para analisar e lidar com seus dados. Usando a prática de segurança com falha descrita recentemente, os desenvolvedores dão seus dados a qualquer pessoa inteligente o suficiente para retornar seu nome.

Por exemplo, se o software cliente deve chamar apenas um servidor em execução nas contas de Joe, Pete ou Alice, a função RpcMgmtInqServerPrincName deve ser chamada e o nome enviado de volta deve ser verificado. Se for Joe, Pete ou Alice, a autenticação mútua deverá ser solicitada usando o nome da entidade de segurança do servidor. Isso garante que ambas as metades da conversa vão para a mesma entidade de segurança.

Se o software cliente deve chamar um serviço em execução somente na conta de Joe, componha diretamente o nome principal do servidor de Joe e faça a chamada. Se o servidor não for Joe, a chamada simplesmente falhará.

Muitas vezes, os serviços são executados como serviços do sistema Windows, o que significa que eles são executados na conta do computador. A autenticação mútua e a criação de um nome de entidade de segurança do servidor ainda são recomendadas.

Usar o ImpersonationType mais baixo que permite que a chamada passe

Essa prática recomendada é bastante autoexplicativa. Mesmo que a autenticação mútua seja usada, não dê ao servidor mais direitos do que o necessário; um servidor legítimo pode ter sido comprometido e, mesmo que os dados enviados caiam em mãos erradas nesses casos, pelo menos o servidor não poderá acessar outros dados na rede em seu nome. Alguns servidores rejeitarão uma chamada que não tem informações suficientes para determinar e possivelmente representar o chamador. Além disso, lembre-se de que algumas sequências de protocolo dão suporte à segurança em nível de transporte (ncacn_np e ncalrpc). Nesses casos, o servidor sempre poderá representar você se você especificar um nível de representação suficientemente alto por meio do parâmetro NetworkOptions ao criar o identificador de associação.

Por fim, alguns provedores de segurança ou transportes podem aumentar de forma transparente ImpersonationType para um nível mais alto do que o especificado. Ao desenvolver um programa, certifique-se de tentar fazer chamadas com o ImpersonationType pretendido e marcar se você está recebendo ImpersonationType mais alto no servidor.