Prácticas recomendadas para utilizar servicios Web XML nativos
Esta característica se quitará en una versión futura de Microsoft SQL Server. Evite utilizar esta característica en nuevos trabajos de desarrollo y tenga previsto modificar las aplicaciones que actualmente la utilizan.
Este tema presenta algunas prácticas recomendadas que se deben tener en cuenta al planear y evaluar servicios web XML nativos en SQL Server 2005 o SQL Server 2008 para su uso en soluciones empresariales. Estas recomendaciones pretenden ayudarle de las siguientes maneras:
Ayudar a proteger su instalación de SQL Server cuando usa servicios web XML nativos en SQL Server 2005 o SQL Server 2008.
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 nativos:
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 confidenciales.
Utilice SQL Server detrás de un firewall.
Compruebe 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 seguros siempre que sea posible.
Utilice la autenticación Kerberos.
Cuando use CREATE ENDPOINT (Transact-SQL) 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 admita 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 servidores y clientes está autenticada.
Cuando utiliza la autenticación Kerberos, SQL Server debe asociar un Nombre principal de servicio (SPN) a 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 concreto y conceda permisos de conexión solo 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 que solo se conecten usuarios individuales a extremos. No se recomienda conceder acceso a la función public. En su lugar, se recomienda conocer totalmente el modelo de permisos para SQL Server. Puede usar este modelo para controlar razonablemente el acceso al extremo.
.gif "Nota importante") 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 función de base de datos es una función integrada predeterminada de SQL Server y actúa como medio para conceder acceso a todos los usuarios (similar a Todos o Usuarios autenticados en los permisos de Windows), se debe usar 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 confidenciales.
El protocolo Capa de sockets seguros (SSL) proporciona soporte para el cifrado y descifrado de datos en una interfaz de sockets TCP/IP seguros (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 es posible que el mismo certificado también sea compartido por otras aplicaciones. Por ejemplo, Internet Information Services (IIS) puede estar hospedando tráfico SSL en el mismo puerto, en cuyo caso esta configuración puede afectar a los 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 detrás de un firewall. Asegúrese de que, cuando configure extremos, todos los números de puerto TCP que utilice para proporcionar acceso HTTP estén protegidos por el firewall. Permitir que los clientes de Internet tengan acceso directo 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.
Compruebe 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 Windows Server 2003, está deshabilitada de forma predeterminada. En Windows 2000 Server y Windows NT Server 4.0 está habilitada de forma predeterminada.
Para reducir el riesgo de ataques de área expuesta 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 (Transact-SQL), el estado predeterminado se detiene a menos que lo inicie explícitamente especificando STATE = STARTED. Para controlar el estado de un extremo existente, use ALTER ENDPOINT (Transact-SQL) para especificar STOPPED, STARTED o DISABLED.
Por ejemplo, utilice las instrucciones siguientes para iniciar o detener el extremo sql_endpoint creado anteriormente:
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 ejemplo siguiente se muestra la forma de deshabilitar un extremo:
ALTER ENDPOINT sql_endpoint STATE=DISABLED
[!NOTA]
Después de deshabilitar un extremo, no se puede reiniciar hasta que se reinicie el servicio SQL Server (MSSQLServer).
Para quitar un método web de un extremo, debe usar una instrucción que tenga un formato similar al siguiente:
ALTER ENDPOINT sql_endpoint
FOR SOAP
(
DROP WEBMETHOD 'SayHello'
)
Para quitar un extremo, utilice DROP ENDPOINT.
Utilice valores predeterminados del extremo seguros 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 establezca explícitamente lo contrario:
BATCHES = DISABLED
El modo batch de Transact-SQL se deshabilita para el extremo.
LOGIN_TYPE = WINDOWS
Solo 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 prevea y requiera en la implementación de su aplicación, se recomienda usar estas 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 nativos:
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 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 hospedada 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 nivel intermedio SQLXML para implementar servicios web conjuntamente 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) o posterior pueden superar sus requisitos.
De forma similar, en escenarios con los siguientes requisitos, no recomendamos usar servicios web XML nativos:
Su aplicación se utiliza para insertar o recuperar datos de objetos binarios grandes (BLOB), como valores 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 adicional de recursos del servidor. Por ejemplo, en pruebas 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, 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 diferentes de Windows, utilice WSDL simple. Para entornos que sólo son de Windows en los que está programando con MicrosoftVisual 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.