Compartilhar via

Serviços de segurança

  • Artigo

A segurança de um serviço WCF (Windows Communication Foundation) consiste em dois requisitos principais: segurança e autorização de transferência. (Um terceiro requisito, a auditoria de eventos de segurança, é descrito em Auditoria.) Resumidamente, a segurança de transferência inclui autenticação (verificação da 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, permissão para que apenas usuários privilegiados leiam um arquivo. Usando recursos do WCF, os dois requisitos principais são facilmente implementados.

Com exceção da classe BasicHttpBinding (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 afirma 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-a 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 serão trocadas em confidencialidade e todas as mensagens serã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 na função ou nos privilégios de grupo.

Mecanismos da 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 confiados por outros usuários autorizadores de tíquete no sistema. Sempre que uma entidade tenta executar alguma operação ou acessar um recurso (como um arquivo ou diretório em um computador), a validade do tíquete é examinada e, se for aprovada, a entidade de segurança receberá outro tíquete para 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). Nos casos em que Kerberos não pode ser usado (normalmente fora de um domínio do Windows, por exemplo, em um grupo de trabalho), o NTLM pode ser usado como 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 precisa ser configurado e controlado por uma pessoa (ou grupo de pessoas) na função de 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 desempenhem a mesma função. Na prática, portanto, um computador Windows é administrado pela atribuição de 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 um ou mais grupos, bem como a 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 criados facilmente e, na proteção de 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 da associação WSHttpBinding ouNetTcpBinding. 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 fins de confidencialidade e assinadas para fins integridade. Para saber mais sobre como criar um serviço que usa a segurança do Windows, confira Como proteger um serviço com credenciais do Windows.

Autorização usando a classe PrincipalPermissionAttribute

Se você precisa restringir o acesso de recursos em um computador, a maneira mais fácil é usar a classe PrincipalPermissionAttribute. 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 em uma função do Windows especificada ou seja um usuário específico. Para saber mais, confira 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 com 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 de uma pasta para excluir a conta de serviço ASPNET, mas permitir que outras identidades específicas 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 a fim de acessar um recurso específico. Outro exemplo é durante o acesso a um banco de dados SQL Server ao qual apenas determinados usuários têm permissão. Para saber mais sobre como usar a representação, confira 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 no 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 alguma das várias maneiras diferentes de apresentar credenciais. O objetivo deste tópico, no entanto, é apresentar uma abordagem comum que permita que você crie um serviço WCF acessível na Internet.

Usando IIS e 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, o 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

O ASP.NET inclui uma associação e um provedor de função. O provedor é um banco de dados de pares de nome de usuário/senha para autenticação de chamadores que também permite que você especifique os privilégios de acesso de cada chamador. Com o WCF, você pode usar facilmente uma associação pré-existente e um provedor de função 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. As credenciais na Internet geralmente são certificados X.509 (também conhecidos como certificados Secure Sockets Layer, ou SSL). 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 para a qual ele foi emitido. Para expor seu serviço na Internet, você também precisa fornecer um certificado confiável para autenticar seu serviço.

A pergunta que surge nesse momento é: como você obtém esse certificado? Uma abordagem é buscar uma autoridade de certificação, como Authenticode ou VeriSign, quando você está pronto para implantar seu serviço e comprar um certificado para ele. No entanto, se você estiver em fase de desenvolvimento com o WCF e ainda não estiver pronto para fazer a compra de 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 saber mais, confira Como trabalhar com certificados.

Modos de segurança

A programação da segurança do WCF envolve alguns pontos de decisão críticos. Um dos mais básicos é 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, confira 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 pontos de extremidade. Para a finalidade atual, é necessário apenas que você entenda que o WCF usa vários protocolos de transporte, e cada um deles pode proteger a transferência de mensagens. (Para saber mais sobre transportes, confira Transportes.)

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 por meio de SSL por HTTP, geralmente abreviado como "HTTPS". Portanto, ao selecionar o modo de transporte para segurança, você está optando por usar o mecanismo conforme ditado pelo protocolo. Por exemplo, se você selecionar a classe WSHttpBinding e definir seu modo de segurança como Transporte, vai selecionar 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 precisa 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 com a inclusão dos 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 a integridade e a confidencialidade da mensagem são incluídas em cada mensagem. Cada mensagem inclui dados de segurança, ou seja, isso atrapalha o desempenho porque cada mensagem precisa 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 do 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 do 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 qual tipo o cliente precisa usar para se autenticar no servidor.

No entanto, nem todos os cenários exigem um tipo de credencial de cliente. Usando o SSL sobre HTTP (HTTPS), um serviço se autentica no 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 faz com 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, o uso do transporte HTTP e a escolha do modo de transporte oferece várias opções, como Básico, Digest e outras. (Para saber mais sobre esses tipos de credencial, confira Noções básicas de autenticação HTTP.)

Se você estiver criando um serviço em um domínio do Windows que ficará disponível apenas para outros usuários da rede, será mais fácil usar o tipo de credencial de cliente do Windows. No entanto, talvez você também precise fornecer um serviço com um certificado. Isso é mostrado em Como especificar valores de credencial de 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ê tiver selecionado o Windows (e o serviço for executado em um domínio do Windows), você não especificará um valor de credencial real.

Identidade

No WCF, o termo identidade tem significados diferentes para o servidor e para o cliente. Resumidamente, na execução de 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 PrimaryIdentity e WindowsIdentity da classe ServiceSecurityContext. Para saber mais, confira Como examinar o contexto de segurança.

Por outro lado, no cliente, a identidade é usada para validar o serviço. No momento do design, um desenvolvedor cliente pode definir o elemento <identidade> como um valor obtido do serviço. No tempo de execução, 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 da entidade de usuário) se o serviço for executado com a identidade de determinado usuário ou um SPN (nome da entidade de serviço) se o serviço for executado em uma conta de computador. Para saber mais, confira Identidade de serviço e autenticaçã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 OperationContractAttribute e ServiceContractAttribute). O nível de proteção é um valor que especifica se as mensagens (ou partes de mensagem) que oferecem suporte a um serviço são assinadas e criptografadas ou enviadas sem assinaturas ou criptografia. Para saber mais sobre a propriedade, confira Noções básicas sobre o nível de proteção e, para obter exemplos de programação, confira Como definir a propriedade ProtectionLevel. Para saber mais sobre como criar um contrato de serviço com o ProtectionLevel no contexto, confira Design de contratos de serviço.

Confira também