Serviços de segurança

  • Artigo

A segurança de um serviço WCF (Windows Communication Foundation) consiste em dois requisitos principais: segurança de transferência e autorização. (Um terceiro requisito, a auditoria de eventos de segurança, é descrito em Auditoria.) Em resumo, a segurança de transferência inclui autenticação (verificação da identidade do serviço e do cliente), confidencialidade (criptografia de mensagens) e integridade (assinatura digital para detetar adulteração). Autorização é o controle de acesso a recursos, por exemplo, permitindo 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 (ou do <elemento basicHttpBinding> na configuração), a segurança de transferência é habilitada BasicHttpBinding por padrão para todas as associações predefinidas. Os tópicos desta seção abrangem 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 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 afirmação de alguma forma. Em um cenário típico, ocorre uma troca de credenciais. Primeiro, um serviço faz uma reivindicação de sua identidade e prova isso ao cliente com uma credencial. Por outro lado, o cliente faz uma reivindicação de identidade e apresenta uma credencial para o serviço. Se ambas as partes confiarem nas credenciais da outra, então um contexto seguro pode 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 estabelece a identidade do cliente, ele pode 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 ambos 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 de 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 baseado na concessão de tíquetes para cada entidade de segurança. Os bilhetes que o controlador concede são confiáveis por outros concedentes de bilhetes no sistema. Sempre que uma entidade tenta realizar alguma operação ou acessar um recurso (como um arquivo ou diretório em uma máquina), o ticket é examinado quanto à sua validade e, se passar, o principal recebe outro ticket para a operação. Este método de concessão de bilhetes é mais eficiente do que a alternativa de tentar validar o principal para cada operação.

Um mecanismo mais antigo e menos seguro usado em domínios do Windows é o NT LAN Manager (NTLM). Nos casos em que o 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 de administrador. Outra função é a do usuário, que tem um conjunto muito mais restrito de permissões. 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, uma máquina Windows é administrada 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 uma máquina local, um administrador também pode criar novos grupos e atribuir outros usuários (ou até mesmo outros grupos) ao grupo.

Num computador com o Windows, todas as pastas de 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 isso é conhecido como a lista de controle de acesso (ACL). Ao criar a ACL, você pode atribuir privilégios de acesso a qualquer grupo ou grupos, bem como a membros individuais de um domínio.

A infraestrutura 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 sejam 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 fazem logon, o controlador Kerberos permite que cada usuário estabeleça contextos seguros com qualquer outro computador ou aplicativo. Em uma máquina local, 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 em Serviços de Intranet

Para proteger um aplicativo executado exclusivamente em um domínio do Windows, você pode usar as configurações de segurança padrão do WSHttpBinding ou da NetTcpBinding associação. Por padrão, qualquer pessoa no mesmo domínio do Windows pode acessar os 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 restringir a invocação de operações de serviço exigindo que o usuário esteja em um grupo ou função específica do Windows ou que seja um usuário específico. Para obter mais informações, consulte Como restringir o acesso com a classe PrincipalPermissionAttribute.

Falsificação de identidade

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 somente 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. A questão então se torna como permitir que esses usuários acessem a pasta se a conta ASPNET não tem permissão para fazê-lo. A resposta é usar a representação, em que o serviço tem permissão para usar as credenciais do cliente para acessar um determinado recurso. Outro exemplo é ao acessar um banco de dados do SQL Server para o 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 numa intranet. Um serviço precisa apresentar suas credenciais para provar sua autenticidade, e os clientes precisam provar sua identidade para o serviço. Uma vez comprovada a identidade de um cliente, o serviço pode 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 lida com a autenticação de usuários em um domínio com tíquetes para credenciais, na Internet, os 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 na 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 WCF podem usar. Para aproveitar esses recursos de segurança, hospede um serviço WCF no IIS.

Usando ASP.NET membros e provedores de função

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

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 fazem logon a qualquer momento. Em vez disso, as credenciais na Internet na maioria das vezes estão na forma de certificados X.509 (também conhecidos como certificados Secure Sockets Layer ou SSL). Esses certificados geralmente são emitidos por uma autoridade de certificação, que pode ser uma empresa terceirizada que garante a autenticidade do certificado e da pessoa para a 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 questão que se coloca neste momento é: como obter esse certificado? Uma abordagem é ir a uma autoridade de certificação de terceiros, como Authenticode ou VeriSign, quando 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 Trabalhando com certificados.

Modos de Segurança

Programar a segurança WCF envolve alguns pontos críticos de decisão. 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, consulte Como definir o modo de segurança.

Modo de Transporte

Existem várias camadas entre a rede e a aplicação. Uma delas é a camada de transporte *,* que gerencia a transferência de mensagens entre endpoints. Para o presente propósito, é 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 Transportes.)

Um protocolo comumente usado é HTTP; outro é o TCP. Cada um desses protocolos pode proteger a transferência de mensagens por um mecanismo (ou mecanismos) específico para o protocolo. Por exemplo, o protocolo HTTP é protegido usando SSL sobre HTTP, comumente abreviado como "HTTPS". Assim, quando você seleciona o modo de transporte para segurança, você está optando por usar o mecanismo conforme ditado pelo protocolo. Por exemplo, se você selecionar a WSHttpBinding classe e definir seu modo de segurança como Transporte, estará selecionando SSL sobre HTTP (HTTPS) como o mecanismo de segurança. A vantagem do modo de transporte é que é mais eficiente do que o modo de mensagem, porque a segurança é integrada a um nível comparativamente baixo. Ao usar o modo de transporte, o mecanismo de segurança deve ser implementado de acordo com a especificação para o 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 ao incluir 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 a integridade e confidencialidade da mensagem são incluídos em cada mensagem. Cada mensagem inclui dados de segurança, o que resulta em um impacto no desempenho, pois cada mensagem deve ser processada individualmente. (No modo de transporte, uma vez que a camada de transporte está protegida, todas as mensagens fluem livremente.) No entanto, a segurança das mensagens tem uma vantagem sobre a segurança dos transportes: é mais flexível. Ou seja, os requisitos de segurança não são determinados pelo transporte. Você pode usar qualquer tipo de credencial de cliente para proteger a mensagem. (No modo de transporte, o protocolo de transporte determina o tipo de credencial de cliente que você pode usar.)

Transporte com credenciais de mensagem

O terceiro modo combina o melhor do transporte e da segurança da mensagem. Neste modo, a segurança do transporte é utilizada para garantir de forma eficiente a confidencialidade e 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, você também pode especificar um tipo de credencial de cliente. O tipo de credencial de cliente especifica o tipo que um cliente deve usar para autenticar-se no servidor.

No entanto, nem todos os cenários exigem um tipo de credencial de cliente. Usando SSL sobre HTTP (HTTPS), um serviço autentica-se 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 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 outros. (Para obter mais informações sobre esses tipos de credenciais, 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 é o tipo de credencial de cliente do Windows. No entanto, também pode ser necessário fornecer um serviço com um certificado. Isso é mostrado em Como: Especificar valores de credenciais 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 também seja necessário configurar o serviço com as credenciais reais. Se você selecionou Windows (e o serviço será executado em um domínio do Windows), não especifique um valor de credencial real.

Identidade

No WCF, o termo identidade tem significados diferentes para o servidor e o cliente. Em resumo, 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 WindowsIdentity propriedades e PrimaryIdentity da ServiceSecurityContext classe. Para obter mais informações, consulte Como examinar o contexto de segurança.

Em contraste, no cliente, a identidade é usada para validar o serviço. Em tempo de design, um desenvolvedor cliente pode definir o <elemento de identidade> para um valor obtido do serviço. Em 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 encerra a comunicação. O valor pode ser um nome principal de usuário (UPN) se o serviço for executado sob a identidade de um usuário específico ou um nome principal de serviço (SPN) se o serviço for executado sob uma conta de máquina. 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 ProtectionLevel propriedade ocorre em várias classes de atributo (como as classes e ).ServiceContractAttributeOperationContractAttribute O nível de proteção é um valor que especifica se as mensagens (ou partes da mensagem) que suportam 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 com o ProtectionLevel contexto, consulte Projetando contratos de serviço.

Consulte também