Visão geral de segurança

A estrutura de segurança na WWSAPI (API de Serviços Web do Windows) fornece:

• Integridade da mensagem, confidencialidade, detecção de reprodução e autenticação de servidor usando a segurança de transporte.
• Autenticação de cliente, como validação de token de segurança, verificações de confiança de certificado e revogação, etc. usando segurança de mensagem SOAP ou segurança de transporte.

O modelo de programação de segurança

A segurança está associada aos canais de comunicação. Proteger um canal consiste nas etapas a seguir.

• Crie e inicialize uma ou mais associações de segurança apropriadas para os requisitos de segurança do aplicativo.
• Crie uma descrição de segurança que contenha essas associações de segurança.
• Crie um proxy de canal ou serviço (no lado do cliente) ou crie um ouvinte ou host de serviço (no lado do servidor) passando essa descrição de segurança.
• Execute as etapas normais de programação de canal de Abrir, Aceitar, Enviar, Receber, Fechar etc.

As mensagens enviadas e recebidas no canal são protegidas automaticamente pelo runtime de acordo com a descrição de segurança fornecida. Opcionalmente, essas etapas podem ser ajustadas especificando uma ou mais configurações de segurança em todo o canal na descrição de segurança ou nas configurações de segurança em toda a associação em uma associação de segurança.

Qualquer autorização necessária de identidades de remetente deve ser feita pelo aplicativo usando os resultados de processamento de segurança anexados a cada mensagem recebida. As etapas de autorização não são especificadas na descrição de segurança, nem são executadas automaticamente pelo runtime.

Erros na descrição de segurança, como associações sem suporte, propriedades/campos inaplicáveis, falta de propriedades/campos necessários ou valores de propriedade/campo inválidos, causarão falha na criação do canal ou do ouvinte.

Selecionando associações de segurança

Ao projetar a segurança para um aplicativo, a decisão principal é a seleção das associações de segurança a serem incluídas na descrição de segurança. Veja a seguir algumas diretrizes para escolher associações de segurança adequadas para o cenário de segurança de um aplicativo. Uma heurística útil é primeiro entender quais tipos de credenciais de segurança (como certificados X.509, nome de usuário/senhas de domínio do Windows, nome de usuário/senhas definidos pelo aplicativo) estarão disponíveis para o aplicativo e, em seguida, escolher uma associação de segurança que possa usar esse tipo de credencial.

• A segurança de transporte, em que a segurança é aplicada no nível do fluxo de bytes de transporte (abaixo dos limites da mensagem SOAP), é a primeira opção a ser considerada.

  • Para cenários de Internet e para esses cenários de Intranet em que um certificado X.509 pode ser implantado no servidor, o aplicativo pode usar WS_SSL_TRANSPORT_SECURITY_BINDING. O exemplo a seguir ilustra essa opção. Cliente: HttpClientWithSslExample Server: HttpServerWithSslExample.

    Se a autenticação do cliente por meio da autenticação de cabeçalho HTTP for desejada, um WS_HTTP_HEADER_AUTH_SECURITY_BINDING poderá ser adicionado para fornecer essa funcionalidade.

  • Para cenários de Intranet em que os protocolos de Autenticação Integrada do Windows, como Kerberos, NTLM e SPNEGO, são apropriados, o aplicativo pode usar WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING. O exemplo a seguir ilustra esta opção: Client: RequestReplyTcpClientWithWindowsTransportSecurityExample Server: RequestReplyTcpServerWithWindowsTransportSecurityExample.

    Cliente sobre pipes nomeados: RequestReplyNamedPipesClientWithWindowsTransportSecurityExample

    Servidor sobre pipes nomeados: RequestReplyNamedPipesServerWithWindowsTransportSecurityExample

  • Para cenários de computador local em que os protocolos de Autenticação Integrada do Windows, como Kerberos, NTLM e SPNEGO, são apropriados, o aplicativo pode usar WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING ou WS_NAMEDPIPE_SSPI_TRANSPORT_SECURITY_BINDING. OWS_NAMEDPIPE_CHANNEL_BINDING é preferencial nesses cenários porque garante que o tráfego não sairá do computador (essa é a propriedade de WS_NAMEDPIPE_CHANNEL_BINDING).

• A segurança de modo misto, em que a segurança de transporte protege a conexão e um cabeçalho WS-Security na mensagem SOAP fornece autenticação de cliente, é a próxima opção a ser considerada. As associações a seguir são usadas em conjunto com uma das associações de segurança de transporte descritas na seção anterior.

  • Quando o cliente é autenticado por um par de nome de usuário/senha no nível do aplicativo, o aplicativo pode usar um WS_USERNAME_MESSAGE_SECURITY_BINDING para fornecer os dados de autenticação. Os exemplos a seguir ilustram o uso dessa associação em conjunto com um WS_SSL_TRANSPORT_SECURITY_BINDING:

    • Cliente: HttpClientWithUsernameOverSslExample
    • Servidor: HttpServerWithUsernameOverSslExample

  • Quando o cliente é autenticado por um tíquete Kerberos, o aplicativo pode usar um WS_KERBEROS_APREQ_MESSAGE_SECURITY_BINDING para fornecer os dados de autenticação.

  • Ao usar um contexto de segurança, o cliente primeiro estabelece um contexto de segurança com o servidor e, em seguida, usa esse contexto para autenticar mensagens. Para habilitar essa funcionalidade, a descrição de segurança deve conter um WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING. Depois de estabelecidos, os contextos de segurança podem ser transmitidos por meio de tokens leves, o que evita a necessidade de enviar as credenciais de cliente potencialmente grandes e computacionalmente caras com cada mensagem.

  • Em um cenário de segurança federada , o cliente primeiro obtém um token de segurança emitido por um STS (serviço de token de segurança) e, em seguida, apresenta o token emitido para um serviço. Lado do cliente: para obter o token de segurança do STS, o aplicativo pode usar WsRequestSecurityToken. Como alternativa, o aplicativo pode usar uma biblioteca de provedores de token de segurança do lado do cliente, como CardSpace ou LiveID, e usar sua saída para criar localmente um token de segurança usando WsCreateXmlSecurityToken. De qualquer forma, depois que o token de segurança estiver disponível para o cliente, ele poderá ser apresentado ao serviço usando uma descrição de segurança que contém um WS_XML_TOKEN_MESSAGE_SECURITY_BINDING. Lado do servidor: se o token de segurança emitido pelo STS for um token SAML, o servidor poderá usar uma descrição de segurança com um WS_SAML_MESSAGE_SECURITY_BINDING.

    Observação

    Windows 7 e Windows Server 2008 R2: o WWSAPI dá suporte apenas a Ws-Trust e Ws-SecureConversation , conforme definido pelo LWSSP (Lightweight Web Services Security Profile). Para obter detalhes sobre a implementação da Microsoft, consulte a seção Sintaxe MESSAGE do LWSSP.

     

• A opção final a ser considerada é usar associações de autenticação sem usar uma associação de proteção, como WS_SSL_TRANSPORT_SECURITY_BINDING. Isso fará com que as credenciais sejam transmitidas em texto não criptografado e possam ter implicações de segurança. O uso dessa opção deve ser avaliado cuidadosamente para garantir que não haja vulnerabilidades como resultado. Um exemplo de um possível uso é trocar mensagens entre servidores back-end por uma rede privada segura. As configurações a seguir dão suporte a essa opção.

  • WS_HTTP_HEADER_AUTH_SECURITY_BINDING dá suporte a essa opção em todas as configurações.
  • WS_USERNAME_MESSAGE_SECURITY_BINDING dá suporte a essa opção no servidor ao usar HTTP como transporte.
  • WS_KERBEROS_APREQ_MESSAGE_SECURITY_BINDING dá suporte a essa opção no servidor ao usar HTTP como transporte.
  • WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING dá suporte a essa opção no servidor ao usar HTTP como transporte.
  • WS_SAML_MESSAGE_SECURITY_BINDING dá suporte a essa opção no servidor ao usar HTTP como transporte.

  Habilitar essa opção requer definir explicitamente o WS_PROTECTION_LEVEL para um valor diferente de WS_PROTECTION_LEVEL_SIGN_AND_ENCRYPT.

Canais e segurança

Conforme observado acima, a segurança tem como escopo canais. Além disso, as operações de canal são mapeadas para etapas de segurança de forma consistente em todas as associações de segurança.

• Criação de canal: o conjunto de associações de segurança especificado na descrição de segurança é validado e permanece fixo para o canal posteriormente. A forma da pilha de canais, incluindo quaisquer canais laterais a serem usados para negociações baseadas em WS-Trust, também é determinada.
• Canal aberto: todas as credenciais fornecidas como parte das associações de segurança são carregadas e as sessões de segurança são estabelecidas. Em geral, um canal aberto contém o estado de segurança "ao vivo". Abrir um canal cliente também especifica o endereço do ponto de extremidade do servidor em relação ao qual a autenticação do servidor será feita pelo runtime.
• Entre o canal aberto e o fechamento: as mensagens podem ser enviadas e recebidas com segurança durante essa fase.
• Envio de mensagens: os tokens de contexto de segurança são obtidos ou renovados conforme necessário e a segurança é aplicada a cada mensagem transmitida de acordo com a descrição de segurança. Erros encontrados ao aplicar a segurança são retornados ao aplicativo como erros de envio.
• Recebimento de mensagens: a segurança é verificada em cada mensagem recebida de acordo com a descrição de segurança. Todos os erros de verificação de segurança de mensagem são retornados ao aplicativo como erros de recebimento. Esses erros por mensagem não afetam o estado do canal ou os recebimentos subsequentes. O aplicativo pode descartar um recebimento com falha e reiniciar um recebimento para outra mensagem.
• Anulação do canal: o canal pode ser anulado a qualquer momento para interromper todas as E/Ss no canal. Ao anular, o canal entrará em um estado com falha e não permitirá mais envios ou recebimentos. No entanto, o canal ainda pode manter algum estado de segurança "ao vivo", portanto, um fechamento de canal subsequente será necessário para descartar todo o estado corretamente.
• Fechamento do canal: o estado de segurança criado ao abrir é descartado e as sessões são interrompidas. Os tokens de contexto de segurança são cancelados. A pilha de canais permanece, mas não contém nenhum estado de segurança 'ativo' ou credenciais carregadas.
• Canal gratuito: a pilha de canais criada na criação, juntamente com todos os recursos de segurança, é liberada.

APIs de segurança

A documentação da API para segurança é agrupada nos tópicos a seguir.

• Descrição de segurança
  • Configurações do Canal de Segurança
  • Associações de segurança
    • Credenciais de Segurança
    • Configurações de associação de segurança
• Federação
• Contexto de segurança
• Identidade de ponto de extremidade
• Resultados do processamento de segurança

Segurança

Ao usar o API de Segurança WWSAPI, os aplicativos enfrentam vários riscos de segurança:

Configuração incorreta acidental

O WWSAPI dá suporte a uma variedade de opções de configuração relacionadas à segurança. Confira, por exemplo , WS_SECURITY_BINDING_PROPERTY_ID. Algumas dessas opções, como WS_SECURITY_BINDING_PROPERTY_ALLOW_ANONYMOUS_CLIENTS permitem que o aplicativo reduza o nível padrão de segurança fornecido pelas várias Associações de Segurança. O uso dessas opções deve ser cuidadosamente avaliado para garantir que não haja vetores de ataque resultantes.

Além disso, conforme descrito acima, o WWSAPI permite que um aplicativo desabilite deliberadamente determinadas etapas necessárias para proteger totalmente uma troca de mensagens, como permitir desabilitar a criptografia mesmo que as credenciais de segurança sejam transmitidas. Isso tem permissão para habilitar determinados cenários específicos e não deve ser usado para comunicação geral. O WS_PROTECTION_LEVEL deve ser especificamente reduzido para habilitar esses cenários, e os aplicativos não devem alterar esse valor, a menos que seja absolutamente necessário, pois isso desabilitará muitas verificações projetadas para garantir uma configuração segura.

Armazenar informações confidenciais na memória

Informações confidenciais, como senhas, armazenadas na memória, são vulneráveis a serem extraídas por um invasor privilegiado por meio, por exemplo, do arquivo de página. O WWSAPI faz uma cópia das credenciais fornecidas e criptografa essa cópia, deixando os dados originais desprotegidos. É responsabilidade do aplicativo proteger a instância original. Além disso, a cópia criptografada é brevemente descriptografada durante o uso, abrindo uma janela para extraí-la.

Negação de serviço

O processamento de segurança pode consumir recursos significativos. Cada associação de segurança adicional aumenta esses custos. O WWSAPI anula o processamento de segurança assim que uma falha de verificação de segurança é encontrada, mas determinadas verificações, como decisões de autorização, podem não ocorrer até que um trabalho significativo seja executado.

Enquanto uma mensagem é processada no servidor, o estado de segurança é armazenado no heap de mensagens. O aplicativo pode limitar o consumo de memória durante o processamento de segurança reduzindo o tamanho desse heap por meio de WS_MESSAGE_PROPERTY_HEAP_PROPERTIES. Além disso, determinadas associações de segurança, como a WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING, podem fazer com que o servidor aloque recursos em nome do cliente. Os limites para esses recursos podem ser configurados por meio dos seguintes valores de WS_SECURITY_BINDING_PROPERTY_ID :

• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_MAX_PENDING_CONTEXTS
• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_MAX_ACTIVE_CONTEXTS
• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_RENEWAL_INTERVAL
• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_ROLLOVER_INTERVAL

Definir esses limites para valores baixos reduz o consumo máximo de memória, mas pode levar a clientes legítimos sendo rejeitados quando a cota é atingida.