Prácticas recomendadas para utilizar servicios Web XML nativos

Artículo
12/15/2008

Este tema presenta algunas prácticas recomendadas al planear y evaluar servicios Web XML nativos en SQL Server 2005 para su uso en soluciones empresariales. Estas recomendaciones pretenden ayudarle de las siguientes maneras:

Ayudar a proteger su instalación de SQL Server cuando utiliza servicios Web XML nativos en SQL Server 2005.
Ayudar a mejorar el rendimiento de su instalación de SQL Server ofreciendo directrices de uso. Esas directrices pueden ayudarle a decidir si su aplicación recibe un servicio eficaz con el uso de servicios Web XML nativos en SQL Server 2005.

Prácticas recomendadas de seguridad

Tenga en cuenta las siguientes prácticas recomendadas de seguridad cuando implemente servicios Web XML en SQL Server 2005:

Utilice la autenticación Kerberos.
Limite los permisos de conexión de extremo a grupos o usuarios específicos.
Utilice la Capa de sockets seguros para intercambiar datos importantes.
Utilice SQL Server detrás de un firewall.
Verifique si la cuenta de invitado de Windows está deshabilitada en el servidor.
Controle y actualice el estado del extremo según sea necesario.
Utilice valores predeterminados del extremo protegidos siempre que sea posible.

Utilice la autenticación Kerberos

Cuando utilice CREATE ENDPOINT para crear extremos, seleccione AUTHENTICATION=KERBEROS o AUTHENTICATION = INTEGRATED para permitir que se use la seguridad integrada de Windows en Kerberos como el tipo de autenticación utilizado en un extremo. La primera opción sólo permitirá Kerberos como modo de autenticación para el extremo. La segunda opción permite que el extremo sea compatible con la autenticación NTLM y Kerberos.

Para la autenticación, el protocolo Kerberos proporciona seguridad mejorada utilizando características integradas como la autenticación mutua. Esto significa que la identidad de ambos servidores y clientes está autenticada.

Cuando utiliza la autenticación Kerberos, SQL Server debe asociar un Nombre principal de servicio (SPN) con la cuenta en la que se ejecutará. Para obtener más información, vea Registrar nombres principales de servicio de Kerberos mediante Http.sys.

Limite los permisos de conexión de extremo a grupos o usuarios específicos.

Después de crear los extremos necesarios para la implementación, protéjalos estableciendo permisos de conexión de extremo utilizando instrucciones Transact-SQL, como GRANT CONNECT y ALTER ON ENDPOINT. Cuando asigne permisos de conexión, sea específico y conceda permisos de conexión sólo a usuarios específicos o a un grupo específico que esté reservado para el acceso del extremo a SQL Server.

Generalmente debe limitar los permisos para permitir sólo que se conecten usuarios individuales a extremos. No se recomienda otorgar acceso a la función public. En su lugar, se recomienda comprender totalmente el modelo de permisos para SQL Server. Puede usar este modelo para controlar el acceso al extremo razonablemente.

Importante:
La función public es una función de base de datos especial a la que pertenecen todos los usuarios de SQL Server. Esta función contiene permisos de acceso predeterminados para cualquier usuario que pueda tener acceso a la base de datos. Como esta base de datos es una función integrada predeterminada de SQL Server y sirve como forma de otorgar acceso a todos los usuarios (similar a Todos o Usuarios autenticados en los permisos de Windows), debe usarse con precaución cuando se configuren permisos en SQL Server.

La función public es una función de base de datos especial a la que pertenecen todos los usuarios de SQL Server. Esta función contiene permisos de acceso predeterminados para cualquier usuario que pueda tener acceso a la base de datos. Como esta base de datos es una función integrada predeterminada de SQL Server y sirve como forma de otorgar acceso a todos los usuarios (similar a Todos o Usuarios autenticados en los permisos de Windows), debe usarse con precaución cuando se configuren permisos en SQL Server.

Para obtener más información, vea GRANT (permisos de extremo de Transact-SQL).

Utilice la Capa de sockets seguros para intercambiar datos importantes.

El protocolo Capa de sockets seguros (SSL) proporciona soporte para el cifrado y descifrado de datos en una interfaz de socket TCP/IP seguro (combinación de dirección IP y número de puerto TCP). Para que los extremos de SQL Server proporcionen cifrado SSL, primero debe configurar un certificado.

Cuando registre un certificado para el puerto SSL predeterminado de 443, tenga en cuenta que el mismo certificado también puede ser compartido por otras aplicaciones. Por ejemplo, los Servicios de Internet Information Server (IIS) pueden estar alojando tráfico SSL en el mismo puerto, en cuyo caso esta configuración puede afectar a usuarios de IIS. Podría haber implicaciones de seguridad derivadas de compartir el puerto SSL y sus certificados.

Para obtener más información, vea Configurar certificados para su uso con SSL.

Use SQL Server detrás de un firewall

Para la mejor seguridad posible, sólo debe usar servicios Web XML nativos en SQL Server 2005 detrás de un firewall. Asegúrese de que, cuando configura extremos, todos los puertos TCP que utilice para proporcionar acceso HTTP estén protegidos por el firewall. Permitir que los clientes de Internet tengan acceso a una instalación de SQL Server y que no esté protegida por un firewall no es una configuración de red recomendada. Para obtener más información, vea Consideraciones de seguridad para una instalación de SQL Server.

Verifique si la cuenta de invitado de Windows está deshabilitada en el servidor.

La cuenta de invitado es una cuenta de usuario integrada proporcionada en la mayoría de versiones de Microsoft Windows. En , está deshabilitada de forma predeterminada. Para y está habilitada de forma predeterminada.

Para reducir el riesgo de ataques de superficie cuando se usan extremos, debe asegurarse de que la cuenta de invitado está deshabilitada en el servidor en el que se ejecuta SQL Server. Para obtener más información, vea el tema "Para deshabilitar o activar una cuenta de usuario local" en la ayuda de Windows.

Controle y actualice el estado del extremo según sea necesario

Cuando cree un extremo utilizando CREATE ENDPOINT, el estado predeterminado se detiene a menos que lo inicie explícitamente especificando STATE = STARTED. Para controlar el estado de un extremo existente, utilice ALTER ENDPOINT para especificar STOPPED, STARTED o DISABLED.

Por ejemplo, utilice las siguientes instrucciones para iniciar o detener el extremo creado previamente sql_endpoint:

ALTER ENDPOINT sql_endpoint STATE=STARTED

ALTER ENDPOINT sql_endpoint STATE=STOPPED

También debe deshabilitar extremos o quitar métodos Web específicos en un extremo, o el extremo, si no tiene ningún uso previsto para ellos.

En el siguiente ejemplo se muestra la deshabilitación de un extremo:

ALTER ENDPOINT sql_endpoint STATE=DISABLED

[!NOTA] Después de deshabilitar un extremo, no se puede reiniciar hasta que no se reinicia el servicio SQL Server (MSSQLServer).

Para quitar un método Web de un extremo, debe usar una instrucción similar al siguiente formato:

ALTER ENDPOINT sql_endpoint

FOR SOAP

(

DROP WEBMETHOD 'SayHello'

)

Para quitar un extremo, utilice DROP ENDPOINT.

Utilice valores predeterminados del extremo protegidos siempre que sea posible

Cuando cree o modifique un extremo utilizando CREATE ENDPOINT o ALTER ENDPOINT, se aplicarán las siguientes opciones predeterminadas, a menos que lo establezca explícitamente de otra manera:

BATCHES = DISABLED
Transact-SQL El modo batch se deshabilita para el extremo.
LOGIN_TYPE = WINDOWS
Sólo se permite la autenticación de Windows para usuarios de extremos.

A menos que modifique esta configuración por razones de compatibilidad de acceso o funcionalidad que tenga pensadas y requiera en la implementación de su aplicación, le recomendamos que utilice esas opciones predeterminadas siempre que sea posible.

Para obtener información acerca de la elección de un algoritmo de cifrado, vea Elegir un algoritmo de cifrado.

Prácticas recomendadas de rendimiento

Tenga en cuenta las siguientes prácticas recomendadas de rendimiento cuando implemente servicios Web XML en SQL Server 2005:

Realice implementaciones en escenarios adecuados.
Tenga en cuenta los recursos del servidor adicionales cuando planee soluciones basadas en SOAP.
Configure la opción WDSL adecuada para sus requisitos.

Realice implementaciones en escenarios adecuados

Los servicios Web XML nativos de SQL Server 2005 se adaptan mejor a escenarios con los siguientes requisitos:

Su aplicación devuelve o consume datos XML.
Su aplicación depende en gran medida de procedimientos almacenados para la lógica empresarial.
Como parte de su solución empresarial, desea integrar una aplicación de servicio Web alojada en SQL Server con otras aplicaciones de servicios Web para lograr los objetivos de la Arquitectura orientada a servicios (SOA).
Está buscando un reemplazo de mejor rendimiento para la solución de capa media SQLXML para implementar servicios Web juntos en el mismo servidor.
Desea crear y publicar un informe estático para un sitio Web de una intranet en el que el conjunto de características enriquecidas y la sobrecarga adicional de SQL Server 2005 Reporting Services (SSRS) pueden sobrepasar sus requisitos.

De forma similar, en escenarios con los siguientes requisitos, no recomendamos utilizar servicios Web XML nativos en SQL Server 2005:

Su aplicación se utiliza para insertar o recuperar datos de objetos binarios grandes (BLOB), como valores de binaryimage o text grandes.
Su aplicación requiere el procesamiento de transacciones en tiempo real y tiempos de respuesta de gran importancia.
Está utilizando SQL Server en combinación con otras aplicaciones de procesamiento intensivo, como aplicaciones TPC Benchmark C (TPC-C).

Tenga en cuenta los recursos del servidor adicionales cuando planee soluciones basadas en SOAP

Por motivos de planeamiento de capacidad, tenga en cuenta que a diferencia del protocolo TDS (Tabular Data Stream, secuencia de datos tabular), el rendimiento de SOAP varía por aplicación y puede requerir una sobrecarga de recursos del servidor adicional. Por ejemplo, en pruebas preliminares de SQL Server 2005 realizadas por el equipo de producto de SQL Server, en escenarios en los que se devolvieron grandes documentos XML, el acceso basado en SOAP tardó un 20 o un 30 por ciento más que el acceso basado en TDS.

Configure la opción WDSL adecuada para sus requisitos.

Antes de implementar los servicios Web XML nativos en SQL Server 2005, debe determinar la opción WSDL adecuada que se usará para dar soporte a todos los clientes y sistemas operativos necesarios para su solución.

Para lograr una máxima interoperabilidad en entornos heterogéneos en los que los clientes de servicios Web incluyen sistemas operativos que no son de Windows, utilice WSDL simple. Para entornos que sólo son de Windows en los que está programando con Microsoft Visual Studio 2005, puede usar el WSDL predeterminado para tener acceso al soporte de tipo enriquecido incluido en Visual Studio 2005.

A veces, clientes SOAP de terceros pueden requerir un WSDL personalizado para su interoperabilidad. Para obtener más información, vea Implementar compatibilidad WSDL personalizada.

Vea también

Compartir a través de