Compartilhar via

Proteção de serviços

A segurança de um serviço WCF (Windows Communication Foundation) consiste em dois requisitos principais: transferência de segurança e autorização. (Um terceiro requisito, a auditoria de eventos de segurança, é descrito na Auditoria.) Em resumo, a segurança de transferência inclui autenticação (verificando a identidade do serviço e do cliente), confidencialidade (criptografia de mensagem) e integridade (assinatura digital para detectar adulteração). A autorização é o controle do acesso aos recursos, por exemplo, permitindo que apenas usuários privilegiados leiam um arquivo. Usando recursos do WCF, os dois requisitos primários são facilmente implementados.

Com exceção da BasicHttpBinding classe (ou do <elemento basicHttpBinding> na configuração), a segurança de transferência é habilitada por padrão para todas as associações predefinidas. Os tópicos desta seção abordam dois cenários básicos: implementar a segurança e a autorização de transferência em um serviço de intranet hospedado no IIS (Serviços de Informações da Internet) e implementar a segurança e a autorização de transferência em um serviço hospedado no IIS.

Noções básicas de segurança

A segurança depende de credenciais. Uma credencial prova que uma entidade é quem ela diz ser. (Uma entidade pode ser uma pessoa, um processo de software, uma empresa ou qualquer coisa que possa ser autorizada.) Por exemplo, um cliente de um serviço faz uma declaração de identidade e a credencial prova essa declaração de alguma maneira. Em um cenário típico, ocorre uma troca de credenciais. Primeiro, um serviço faz uma declaração de sua identidade e prova isso para o cliente com uma credencial. Por outro lado, o cliente faz uma declaração de identidade e apresenta uma credencial para o serviço. Se ambas as partes confiarem nas credenciais do outro, um contexto seguro poderá ser estabelecido no qual todas as mensagens são trocadas em confidencialidade e todas as mensagens são assinadas para proteger sua integridade. Depois que o serviço estabelecer a identidade do cliente, ele poderá corresponder as declarações na credencial a uma função ou associação em um grupo. Em ambos os casos, usando a função ou o grupo ao qual o cliente pertence, o serviço autoriza o cliente a executar um conjunto limitado de operações com base nos privilégios de função ou grupo.

Mecanismos de segurança do Windows

Se o cliente e o computador de serviço estiverem em um domínio do Windows que exija que ambos façam logon na rede, as credenciais serão fornecidas pela infraestrutura do Windows. Nesse caso, as credenciais são estabelecidas quando um usuário do computador faz logon na rede. Cada usuário e cada computador na rede deve ser validado como pertencente ao conjunto confiável de usuários e computadores. Em um sistema Windows, cada usuário e computador também é conhecido como uma entidade de segurança.

Em um domínio do Windows apoiado por um controlador Kerberos, o controlador Kerberos usa um esquema com base na concessão de tíquetes para cada entidade de segurança. Os tíquetes que o controlador concede são confiáveis por outros concedentes de tíquetes no sistema. Sempre que uma entidade tenta executar alguma operação ou acessar um recurso (como um arquivo ou diretório em uma máquina), o tíquete é examinado quanto à sua validade e, se o tíquete for válido, o principal receberá outro tíquete para executar a operação. Esse método de concessão de tíquetes é mais eficiente do que a alternativa de tentar validar a entidade de segurança a cada operação.

Um mecanismo mais antigo e menos seguro usado em domínios do Windows é o NTLM (NT LAN Manager). Em casos em que Kerberos não pode ser usado (normalmente fora de um domínio do Windows, como em um grupo de trabalho), o NTLM pode ser usado como uma alternativa. O NTLM também está disponível como uma opção de segurança para o IIS.

Em um sistema Windows, a autorização funciona atribuindo cada computador e usuário a um conjunto de funções e grupos. Por exemplo, cada computador Windows deve ser configurado e controlado por uma pessoa (ou grupo de pessoas) na função do administrador. Outra função é a do usuário, que tem um conjunto de permissões muito mais restrito. Além da função, os usuários são atribuídos a grupos. Um grupo permite que vários usuários executem na mesma função. Na prática, portanto, um computador Windows é administrado atribuindo usuários a grupos. Por exemplo, vários usuários podem ser atribuídos ao grupo de usuários de um computador e um conjunto muito mais restrito de usuários pode ser atribuído ao grupo de administradores. Em um computador local, um administrador também pode criar novos grupos e atribuir outros usuários (ou até mesmo outros grupos) ao grupo.

Em um computador que executa o Windows, todas as pastas em um diretório podem ser protegidas. Ou seja, você pode selecionar uma pasta e controlar quem pode acessar os arquivos e se eles podem ou não copiar o arquivo ou (no caso mais privilegiado) alterar um arquivo, excluir um arquivo ou adicionar arquivos à pasta. Isso é conhecido como controle de acesso e o mecanismo para ele é conhecido como ACL (lista de controle de acesso). Ao criar a ACL, você pode atribuir privilégios de acesso a qualquer grupo ou grupo, bem como membros individuais de um domínio.

A infraestrutura do WCF foi projetada para usar esses mecanismos de segurança do Windows. Portanto, se você estiver criando um serviço implantado em uma intranet e cujos clientes estejam restritos a membros do domínio do Windows, a segurança será facilmente implementada. Somente usuários válidos podem fazer logon no domínio. Depois que os usuários são conectados, o controlador Kerberos permite que cada usuário estabeleça contextos seguros com qualquer outro computador ou aplicativo. Em um computador local, os grupos podem ser facilmente criados e, ao proteger pastas específicas, esses grupos podem ser usados para atribuir privilégios de acesso no computador.

Implementando a segurança do Windows nos Serviços intranet

Para proteger um aplicativo que é executado exclusivamente em um domínio do Windows, você pode usar as configurações de segurança padrão do vínculo WSHttpBinding ou do NetTcpBinding. Por padrão, qualquer pessoa no mesmo domínio do Windows pode acessar serviços WCF. Como esses usuários fizeram logon na rede, eles são confiáveis. As mensagens entre um serviço e um cliente são criptografadas para confidencialidade e assinadas para integridade. Para obter mais informações sobre como criar um serviço que usa a segurança do Windows, consulte Como proteger um serviço com credenciais do Windows.

Autorização usando a classe PrincipalPermissionAttribute

Se você precisar restringir o acesso de recursos em um computador, a maneira mais fácil é usar a PrincipalPermissionAttribute classe. Esse atributo permite que você restrinja a invocação de operações de serviço exigindo que o usuário esteja em um grupo ou função do Windows especificado ou seja um usuário específico. Para obter mais informações, consulte Como restringir o acesso com a classe PrincipalPermissionAttribute.

Representação

A representação é outro mecanismo que você pode usar para controlar o acesso aos recursos. Por padrão, um serviço hospedado pelo IIS será executado sob a identidade da conta ASPNET. A conta ASPNET pode acessar apenas os recursos para os quais ela tem permissão. No entanto, é possível definir a ACL para uma pasta para excluir a conta de serviço ASPNET, mas permitir que determinadas outras identidades acessem a pasta. Em seguida, a questão se torna como permitir que esses usuários acessem a pasta se a conta ASPNET não tiver permissão para fazer isso. A resposta é usar a representação, pela qual o serviço tem permissão para usar as credenciais do cliente para acessar um recurso específico. Outro exemplo é ao acessar um banco de dados do SQL Server ao qual apenas determinados usuários têm permissão. Para obter mais informações sobre como usar a representação, consulte Como representar um cliente em um serviço e delegação e representação.

Segurança na Internet

A segurança na Internet consiste nos mesmos requisitos que a segurança em uma intranet. Um serviço precisa apresentar suas credenciais para provar sua autenticidade e os clientes precisam provar sua identidade para o serviço. Depois que a identidade de um cliente for comprovada, o serviço poderá controlar quanto acesso o cliente tem aos recursos. No entanto, devido à natureza heterogênea da Internet, as credenciais apresentadas diferem daquelas usadas em um domínio do Windows. Enquanto um controlador Kerberos manipula a autenticação de usuários em um domínio com tíquetes para credenciais, na Internet, serviços e clientes dependem de qualquer uma das várias maneiras diferentes de apresentar credenciais. O objetivo deste tópico, no entanto, é apresentar uma abordagem comum que permite criar um serviço WCF acessível na Internet.

Usando o IIS e o ASP.NET

Os requisitos de segurança da Internet e os mecanismos para resolver esses problemas não são novos. O IIS é o servidor Web da Microsoft para a Internet e tem muitos recursos de segurança que resolvem esses problemas; além disso, ASP.NET inclui recursos de segurança que os serviços do WCF podem usar. Para aproveitar esses recursos de segurança, hospede um serviço WCF no IIS.

Usando provedores de função e associação do ASP.NET

ASP.NET inclui uma associação e um provedor de funções. O provedor é um banco de dados de pares de nome de usuário/senha para autenticação de chamadores que também permite especificar privilégios de acesso de cada chamador. Com o WCF, você pode usar facilmente um provedor de associação e de função pré-existente por meio da configuração. Para obter um aplicativo de exemplo que demonstre isso, confira o exemplo Associação e provedor de funções.

Credenciais usadas pelo IIS

Ao contrário de um domínio do Windows apoiado por um controlador Kerberos, a Internet é um ambiente sem um único controlador para gerenciar os milhões de usuários que estão fazendo logon a qualquer momento. Em vez disso, as credenciais na Internet geralmente estão na forma de certificados X.509 (também conhecidos como certificados SSL ou Secure Sockets Layer). Esses certificados normalmente são emitidos por uma autoridade de certificação, que pode ser uma empresa de terceiros que atesta a autenticidade do certificado e a pessoa à qual ele foi emitido. Para expor seu serviço na Internet, você também deve fornecer um certificado confiável para autenticar seu serviço.

A pergunta surge neste momento, como você obtém tal certificado? Uma abordagem é acessar uma autoridade de certificação de terceiros, como Authenticode ou VeriSign, quando você estiver pronto para implantar seu serviço e comprar um certificado para seu serviço. No entanto, se você estiver na fase de desenvolvimento com o WCF e ainda não estiver pronto para se comprometer a comprar um certificado, existem ferramentas e técnicas para criar certificados X.509 que você pode usar para simular uma implantação de produção. Para obter mais informações, consulte Como trabalhar com certificados.

Modos de segurança

Programar a segurança do WCF envolve alguns pontos de decisão críticos. Uma das mais básicas é a escolha do modo de segurança. Os dois principais modos de segurança são o modo de transporte e o modo de mensagem.

Um terceiro modo, que combina a semântica de ambos os modos principais, é o transporte com o modo de credenciais de mensagem.

O modo de segurança determina como as mensagens são protegidas e cada opção tem vantagens e desvantagens, conforme explicado abaixo. Para obter mais informações sobre como definir o modo de segurança, consulte Como definir o modo de segurança.

Modo de transporte

Há várias camadas entre a rede e o aplicativo. Uma delas é a camada de transporte que gerencia a transferência de mensagens entre endereços de rede. Para a finalidade atual, é necessário apenas que você entenda que o WCF usa vários protocolos de transporte, cada um dos quais pode proteger a transferência de mensagens. (Para obter mais informações sobre transportes, consulte Transports.)

Um protocolo comumente usado é HTTP; outro é TCP. Cada um desses protocolos pode proteger a transferência de mensagens por um mecanismo (ou mecanismos) específico ao protocolo. Por exemplo, o protocolo HTTP é protegido usando SSL via HTTP, geralmente abreviado como "HTTPS". Portanto, ao selecionar o modo de transporte para segurança, você está optando por usar o mecanismo conforme determinado pelo protocolo. Por exemplo, se você selecionar a WSHttpBinding classe e definir seu modo de segurança como Transporte, estará selecionando SSL por HTTP (HTTPS) como o mecanismo de segurança. A vantagem do modo de transporte é que ele é mais eficiente do que o modo de mensagem porque a segurança é integrada em um nível relativamente baixo. Ao usar o modo de transporte, o mecanismo de segurança deve ser implementado de acordo com a especificação do transporte e, portanto, as mensagens podem fluir com segurança apenas de ponto a ponto sobre o transporte.

Modo de Mensagem

Por outro lado, o modo de mensagem fornece segurança incluindo os dados de segurança como parte de cada mensagem. Usando cabeçalhos de segurança XML e SOAP, as credenciais e outros dados necessários para garantir que a integridade e a confidencialidade da mensagem sejam incluídas em cada mensagem. Cada mensagem inclui dados de segurança, portanto, resulta em um impacto no desempenho, pois cada mensagem deve ser processada individualmente. (No modo de transporte, depois que a camada de transporte é protegida, todas as mensagens fluem livremente.) No entanto, a segurança da mensagem tem uma vantagem sobre a segurança de transporte: ela é mais flexível. Ou seja, os requisitos de segurança não são determinados pelo transporte. Você pode usar qualquer tipo de credencial do cliente para proteger a mensagem. (No modo de transporte, o protocolo de transporte determina o tipo de credencial do cliente que você pode usar.)

Transporte com credenciais de mensagem

O terceiro modo combina o melhor da segurança do transporte e da mensagem. Nesse modo, a segurança de transporte é usada para garantir com eficiência a confidencialidade e a integridade de cada mensagem. Ao mesmo tempo, cada mensagem inclui seus dados de credencial, o que permite que a mensagem seja autenticada. Com a autenticação, a autorização também pode ser implementada. Ao autenticar um remetente, o acesso aos recursos pode ser concedido (ou negado) de acordo com a identidade do remetente.

Especificando o tipo de credencial do cliente e o valor da credencial

Depois de selecionar um modo de segurança, talvez você também queira especificar um tipo de credencial de cliente. O tipo de credencial do cliente especifica o tipo que um cliente deve usar para se autenticar no servidor.

No entanto, nem todos os cenários exigem um tipo de credencial de cliente. Usando SSL sobre HTTP (HTTPS), um serviço se autentica para o cliente. Como parte dessa autenticação, o certificado do serviço é enviado ao cliente em um processo chamado negociação. O transporte protegido por SSL garante que todas as mensagens sejam confidenciais.

Se você estiver criando um serviço que exija que o cliente seja autenticado, sua escolha de um tipo de credencial de cliente dependerá do transporte e do modo selecionados. Por exemplo, usar o transporte HTTP e escolher o modo de transporte oferece várias opções, como Basic, Digest e outras. (Para obter mais informações sobre esses tipos de credencial, consulte Noções básicas sobre autenticação HTTP.)

Se você estiver criando um serviço em um domínio do Windows que estará disponível apenas para outros usuários da rede, o mais fácil de usar será o tipo de credencial do cliente Windows. No entanto, talvez você também precise fornecer um serviço com um certificado. Isso é mostrado em Como especificar valores de credencial do cliente.

Valores de credencial

Um valor de credencial é a credencial real que o serviço usa. Depois de especificar um tipo de credencial, talvez você também precise configurar seu serviço com as credenciais reais. Se você selecionou o Windows (e o serviço será executado em um domínio do Windows), você não especificará um valor de credencial real.

Identidade

No WCF, o termo identidade possui significados diferentes para o servidor e o cliente. Resumindo, ao executar um serviço, uma identidade é atribuída ao contexto de segurança após a autenticação. Para exibir a identidade real, verifique as propriedades WindowsIdentity e PrimaryIdentity da classe ServiceSecurityContext. Para obter mais informações, consulte Como examinar o contexto de segurança.

Por outro lado, no cliente, a identidade é usada para validar o serviço. Em tempo de design, um desenvolvedor cliente pode definir o <elemento de identidade> como um valor obtido do serviço. Em runtime, o cliente verifica o valor do elemento em relação à identidade real do serviço. Se a verificação falhar, o cliente encerrará a comunicação. O valor poderá ser um UPN (nome de entidade de usuário) se o serviço for executado sob a identidade de um determinado usuário ou um SPN (nome de entidade de serviço) se o serviço for executado em uma conta de computador. Para obter mais informações, consulte Identidade e Autenticação do Serviço. A credencial também pode ser um certificado ou um campo encontrado em um certificado que identifica o certificado.

Níveis de proteção

A propriedade ProtectionLevel ocorre em várias classes de atributo (como as classes ServiceContractAttribute e OperationContractAttribute). O nível de proteção é um valor que especifica se as mensagens (ou partes de mensagem) que dão suporte a um serviço são assinadas, assinadas e criptografadas ou enviadas sem assinaturas ou criptografia. Para obter mais informações sobre a propriedade, consulte Noções básicas sobre o nível de proteção e para exemplos de programação, consulte Como definir a propriedade ProtectionLevel. Para obter mais informações sobre como criar um contrato de serviço no contexto de ProtectionLevel, consulte Como Criar Contratos de Serviço.

Consulte também

  • Last updated on