Práticas recomendadas para usar XML Web Services Nativos

Ao usar CREATE ENDPOINT (Transact-SQL) para criar pontos de extremidade, selecione AUTHENTICATION=KERBEROS ou AUTHENTICATION = INTEGRATED para habilitar a segurança integrada do Windows no Kerberos a ser usada como tipo de autenticação em um ponto de extremidade. A primeira opção só permitirá o Kerberos como o modo de autenticação para o ponto de extremidade. A segunda opção permite que o ponto de extremidade suporte a autenticação NTLM e Kerberos.

Para a autenticação, o protocolo Kerberos oferece segurança aprimorada usando recursos internos como autenticação mútua. Isso significa que a identidade de servidores e clientes é autenticada.

Quando você estiver usando a autenticação Kerberos, o SQL Server precisará associar um SPN (nome da entidade de serviço) à conta na qual estará sendo executado. Para obter mais informações, consulte Registrando nomes da entidade de serviço Kerberos usando Http.sys.

Após criar os pontos de extremidade necessários à implantação, proteja-os definindo as permissões de conexão de ponto de extremidade com instruções Transact-SQL, como GRANT CONNECT e ALTER ON ENDPOINT. Ao atribuir permissões de conexão, seja específico e conceda permissão somente aos usuários ou grupos específicos reservados para acesso dos pontos de extremidade ao SQL Server.

Geralmente, você deve limitar as permissões para permitir que somente usuários individuais se conectem aos pontos de extremidade. Não é recomendável conceder acesso à função public. Em vez disso, recomendamos entender completamente o modelo de permissões do SQL Server. Você pode usar esse modelo para controlar cautelosamente o acesso dos pontos de extremidade.

Importante

A função public é uma função de banco de dados especial ao qual pertence todo usuário do SQL Server. Essa função contém permissões de acesso padrão para qualquer usuário que possa acessar o banco de dados. Como essa função de banco de dados é uma função padrão interna do SQL Server, além de um meio de conceder acesso a todos os usuários (semelhante a Todos ou Usuários Autenticados nas permissões do Windows), ela deve ser usada com cautela ao configurar permissões no SQL Server.

Para obter mais informações, consulte Permissões de ponto de extremidade GRANT (Transact-SQL).

O protocolo SSL suporta a criptografia e descriptografia de dados em uma interface segura de soquete TCP/IP (combinação de endereço IP com número de porta TCP). Para que os pontos de extremidade do SQL Server ofereçam criptografia SSL, você precisa antes configurar um certificado.

Ao registrar um certificado para a porta SSL 443 padrão, considere que o mesmo certificado também pode ser compartilhado por outros aplicativos. Por exemplo, o IIS (serviços de informações da Internet) podem estar hospedando o tráfego SSL na mesma porta, caso em que essa configuração pode prejudicar os usuários do IIS. Talvez houvesse implicações de segurança devido a esse compartilhamento da porta SSL e seus certificados.

Para obter mais informações, consulte Configurando um certificado para ser usado no SSL.

Para obter a melhor segurança possível, você deveria usar somente XML Web Services Nativos protegidos por um firewall. Verifique, ao configurar os pontos de extremidade, se todos os números de porta TCP usados para oferecer acesso HTTP estão protegidos pelo firewall. Não é recomendável uma configuração de rede que permite a uma instalação do SQL Server ser acessada diretamente por clientes de Internet sem proteção de um firewall. Para obter mais informações, consulte Considerações sobre segurança para uma instalação do SQL Server.

A conta Convidado é uma conta de usuário interna fornecida na maioria das versões do Microsoft Windows. No Windows Server 2003, ela fica desabilitada por padrão. No Windows 2000 Server e Windows NT Server 4.0, ela é habilitada por padrão.

Para diminuir o risco de ataques de superfície ao usar os pontos de extremidade, você deve verificar se a conta Convidado está desabilitada no servidor em que o SQL Server está sendo executado. Para obter mais informações, consulte o tópico sobre como desabilitar ou ativar uma conta de usuário local na Ajuda do Windows.

Quando você cria um ponto de extremidade usando CREATE ENDPOINT (Transact-SQL), o estado padrão é parado, a menos que você o inicie explicitamente especificando STATE = STARTED. Para controlar o estado de um ponto de extremidade existente, use ALTER ENDPOINT (Transact-SQL) para especificar STOPPED, STARTED ou DISABLED.

Por exemplo, use as instruções a seguir para iniciar ou parar o sql_endpoint do ponto de extremidade criado anteriormente:

ALTER ENDPOINT sql_endpoint STATE=STARTED

ALTER ENDPOINT sql_endpoint STATE=STOPPED

Você também deve desabilitar os pontos de extremidade, ou então descartar os métodos de Web específicos em um ponto de extremidade ou o ponto de extremidade, se não tiver nenhum uso previsível para eles.

O exemplo a seguir mostra como desabilitar um ponto de extremidade:

ALTER ENDPOINT sql_endpoint STATE=DISABLED

Observação
Depois que um ponto de extremidade é desabilitado, ele não pode ser reiniciado enquanto o serviço do SQL Server (MSSQLServer) não for reiniciado.

Para descartar um método de Web de um ponto de extremidade, você usaria uma instrução semelhante ao formato a seguir:

ALTER ENDPOINT sql_endpoint

FOR SOAP

(

DROP WEBMETHOD 'SayHello'

)

Para descartar um ponto de extremidade, use DROP ENDPOINT.

Quando você cria ou modifica um ponto de extremidade usando CREATE ENDPOINT ou ALTER ENDPOINT, os padrões de opção a seguir são aplicados, a menos que você defina outros explicitamente:

• BATCHES = DISABLED

  O modo de loteTransact-SQL fica desabilitado para o ponto de extremidade.

• LOGIN_TYPE = WINDOWS

  Somente a Autenticação do Windows é permitida para usuários de ponto de extremidade.

A menos que você precise modificar essas configurações para dar suporte a acesso ou funcionalidade desejados ou necessários na implantação do aplicativo, é recomendável usar os padrões dessas opções sempre que possível.

Para obter informações sobre como escolher um algoritmo de criptografia, consulte Escolhendo um algoritmo de criptografia.

Os XML Web Services Nativos são mais adequados a cenários com os requisitos a seguir:

• O aplicativo retorna ou consome dados XML.

• O aplicativo depende intensamente de procedimentos armazenados para lógica de negócios.

• Como parte de sua solução comercial, você deseja integrar um aplicativo de serviço da Web hospedado no SQL Server a outros aplicativos de serviço da Web para alcançar os objetivos de uma SOA (arquitetura orientada a serviços).

• Você está procurando um substituto com melhor desempenho para a solução de camada intermediária SQLXML a fim de implantar serviços da Web juntos no mesmo servidor.

• Você deseja produzir e publicar um relatório estático para um site de intranet em que o amplo conjunto de recursos e a sobrecarga adicional do SQL Server 2005 Reporting Services ou superior pode exceder seus requisitos.

Da mesma maneira, em cenários com os requisitos a seguir, não recomendamos usar XML Web Services Nativos:

• O aplicativo é usado para inserir ou recuperar dados de BLOB (objeto binário grande), como valores de binaryimage ou text grandes.

• O aplicativo exige processamento de transações em tempo real e tempos de resposta de missão crítica.

• Você está usando o SQL Server em combinação com outros aplicativos de processamento intensivo como aplicativos de TPC Benchmark C (TPC-C).

Para fins de planejamento de capacidade, observe que, diferentemente do protocolo TDS, o desempenho do SOAP varia dependendo do aplicativo e pode exigir sobrecarga adicional dos recursos do servidor. Por exemplo, nos testes do SQL Server 2005 executados pela equipe de produto do SQL Server, em cenários em que grandes documentos XML foram retornados, o desempenho para acesso baseado em SOAP levou de 20 a 30% mais tempo do que o acesso baseado em TDS.

Antes de implantar XML Web Services Nativos, você deve determinar a opção de WSDL apropriada que será usada para suportar todos os clientes e sistemas operacionais necessários à sua solução.

Para garantir a máxima interoperabilidade em ambientes heterogêneos nos quais os clientes de serviços da Web incluem sistemas operacionais diferentes do Windows, use o WSDL simples. Para ambientes que executam somente Windows nos quais você está desenvolvendo com o Microsoft Visual Studio 2005, é possível usar o WSDL padrão para acessar o suporte de tipo elaborado incluso no Visual Studio 2005.

Às vezes, clientes SOAP de terceiros podem exigir um WSDL personalizado para fins de interoperabilidade. Para obter mais informações, consulte Implementando suporte a WSDL personalizado.