Méthodes préconisées pour l'utilisation des services Web XML natifs
Cette fonctionnalité sera supprimée dans une prochaine version de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité.
Cette rubrique présente quelques recommandations à suivre au moment de planifier et d'évaluer les services Web XML natifs dans SQL Server pour les utiliser dans vos solutions d'entreprise. Ces recommandations sont destinées à vous aider dans les domaines suivants :
sécuriser davantage votre installation de SQL Server lorsque vous utilisez les services Web XML natifs ;
améliorer les performances de votre installation de SQL Server en proposant des consignes d'utilisation. Ces consignes peuvent vous aider à déterminer si votre application tire le meilleur parti des services Web XML natifs.
Meilleures pratiques recommandées en matière de sécurité
Tenez compte des recommandations suivantes en matière de sécurité lors du déploiement des services Web XML natifs :
Utilisez l'authentification Kerberos.
Limitez les autorisations de connexion aux points de terminaison à des utilisateurs ou des groupes spécifiques.
Utilisez Secure Sockets Layer pour échanger les données sensibles.
Utilisez SQL Server derrière un pare-feu.
Vérifiez que le compte Invité de Windows est désactivé sur le serveur.
Contrôlez et mettez à jour l'état du point de terminaison si nécessaire.
Utilisez les valeurs par défaut sécurisées du point de terminaison chaque fois que possible.
Utiliser l'authentification Kerberos
Lorsque vous utilisez l'instruction CREATE ENDPOINT (Transact-SQL) pour créer des points de terminaison, sélectionnez AUTHENTICATION=KERBEROS ou AUTHENTICATION=INTEGRATED pour activer la sécurité intégrée Windows sous Kerberos qui servira de type d'authentification sur un point de terminaison. La première option autorise uniquement Kerberos comme mode d'authentification pour le point de terminaison. La deuxième autorise le point de terminaison à prendre en charge l'authentification NTLM et Kerberos.
Pour l'authentification, le protocole Kerberos fournit une sécurité améliorée en utilisant des fonctions intégrées telles que l'authentification mutuelle. Par conséquent, l'identité des serveurs et des clients est authentifiée.
Lorsque vous utilisez l'authentification Kerberos, SQL Server doit associer un nom de principal du service au compte sur lequel il sera exécuté. Pour plus d'informations, consultez Inscription de noms de principaux du service Kerberos à l'aide de Http.sys.
Limiter les autorisations de connexion aux points de terminaison à des utilisateurs ou des groupes spécifiques
Après avoir créé les points de terminaison nécessaires à votre déploiement, sécurisez-les en définissant des autorisations de connexion aux points de terminaison à l'aide d'instructions Transact-SQL, telles que GRANT CONNECT et ALTER ON ENDPOINT. Lorsque vous attribuez des autorisations de connexion, soyez précis et accordez-les uniquement aux utilisateurs ou aux groupes spécifiques réservés pour l'accès par point de terminaison à SQL Server.
En général, vous devez restreindre les autorisations pour permettre uniquement aux utilisateurs individuels de se connecter aux points de terminaison. L'accès du rôle public n'est pas recommandé. Il est plutôt conseillé de bien maîtriser le modèle d'autorisations de SQL Server. Vous pouvez utiliser ce modèle pour contrôler judicieusement l'accès aux points de terminaison.
Important
Le rôle public est un rôle de base de données spécial auquel appartient chaque utilisateur de SQL Server. Ce rôle contient les autorisations d'accès par défaut de tous les utilisateurs pour lesquels la base de données est accessible. Comme ce rôle de base de données est un rôle intégré par défaut de SQL Server qui représente un moyen d'accorder l'accès à tous les utilisateurs (comparable à Tout le monde ou Utilisateurs authentifiés dans les autorisations Windows), il doit être utilisé avec prudence lors de la configuration des autorisations sur SQL Server.
Pour plus d'informations, consultez GRANT – octroi d'autorisations de point de terminaison (Transact-SQL).
Utiliser SSL (Secure Sockets Layer) pour échanger les données sensibles
Le protocole Secure Sockets Layer (SSL) assure la prise en charge du chiffrement et du déchiffrement des données sur une interface de socket (combinaison d'adresse IP et de numéro de port TCP) TCP/IP sécurisée. Pour que les points de terminaison SQL Server fournissent un chiffrement SSL, vous devez d'abord configurer un certificat.
Lorsque vous inscrivez un certificat pour le port SSL par défaut 443, tenez compte du fait que le même certificat peut également être partagé par d'autres applications. Par exemple, les services Internet (IIS, Internet Information Services) peuvent héberger du trafic SSL sur le même port, auquel cas cette configuration peut avoir une incidence sur les utilisateurs des services Internet. Il peut y avoir des conséquences en termes de sécurité à cause de ce partage du port SSL et de ses certificats.
Pour plus d'informations, consultez Configuration d'un certificat en vue de son utilisation par SSL.
Utiliser SQL Server derrière un pare-feu
Pour garantir le meilleur niveau de sécurité possible, il est préférable d'utiliser les services Web XML natifs uniquement derrière un pare-feu. Vérifiez lors de la configuration des points de terminaison que tous les numéros de port TCP utilisés pour fournir un accès HTTP sont protégés par le pare-feu. Le fait de permettre à une installation de SQL Server d'être directement accessible aux clients Internet et non protégée par un pare-feu n'est pas une configuration réseau recommandée. Pour plus d'informations, consultez Considérations sur la sécurité pour une installation SQL Server.
Vérifier que le compte Invité de Windows est désactivé sur le serveur
Le compte Invité est un compte d'utilisateur intégré fourni dans la plupart des versions de Microsoft Windows. Dans Windows Server 2003, il est désactivé par défaut. Dans Windows 2000 Server et Windows NT Server 4.0, il est activé par défaut.
Pour réduire la surface d'attaque lorsque des points de terminaison sont utilisés, vous devez vérifier que le compte Invité est désactivé sur le serveur où est exécuté SQL Server. Pour plus d'informations, consultez la rubrique « Pour activer ou désactiver un compte d'utilisateur local » dans l'aide de Windows.
Contrôler et mettre à jour l'état du point de terminaison si nécessaire
Lorsque vous créez un point de terminaison à l'aide de l'instruction CREATE ENDPOINT (Transact-SQL), l'état par défaut est STOPPED, sauf si vous le démarrez explicitement en spécifiant STATE=STARTED. Pour contrôler l'état d'un point de terminaison existant, utilisez ALTER ENDPOINT (Transact-SQL) pour spécifier STOPPED, STARTED ou DISABLED.
Par exemple, utilisez les instructions suivantes pour démarrer ou arrêter le point de terminaison sql_endpoint précédemment créé :
ALTER ENDPOINT sql_endpoint STATE=STARTED
ALTER ENDPOINT sql_endpoint STATE=STOPPED
Vous devez également désactiver les points de terminaison ou supprimer les méthodes Web spécifiques sur un point de terminaison, voire le point de terminaison, si vous n'en voyez pas l'utilité.
L'exemple suivant montre comment désactiver un point de terminaison :
ALTER ENDPOINT sql_endpoint STATE=DISABLED
Notes
Une fois le point de terminaison désactivé, il ne peut pas être redémarré tant que le service SQL Server (MSSQLServer) n'a pas redémarré.
Pour supprimer une méthode Web d'un point de terminaison, utilisez une instruction de la forme suivante :
ALTER ENDPOINT sql_endpoint
FOR SOAP
(
DROP WEBMETHOD 'SayHello'
)
Pour supprimer un point de terminaison, utilisez l'instruction DROP ENDPOINT.
Utiliser les valeurs par défaut sécurisées du point de terminaison chaque fois que possible
Lors de la création ou de la modification d'un point de terminaison à l'aide de l'instruction CREATE ENDPOINT ou ALTER ENDPOINT, les valeurs par défaut suivantes des options sont appliquées, sauf si vous les définissez explicitement d'une autre manière :
BATCHES = DISABLED
Le mode Transact-SQLbatch est désactivé pour le point de terminaison.
LOGIN_TYPE = WINDOWS
Seule l'authentification Windows est autorisée pour les utilisateurs du point de terminaison.
Si vous n'avez pas besoin de modifier ces paramètres pour prendre en charge un accès ou des fonctionnalités nécessaires au déploiement de votre application, il est recommandé d'utiliser chaque fois que possible les valeurs par défaut pour ces options.
Pour plus d'informations sur le choix d'un algorithme de chiffrement, consultez Choix d'un algorithme de chiffrement.
Meilleures pratiques recommandées en matière de performances
Tenez compte des recommandations suivantes en matière de performances lors du déploiement des services Web XML natifs :
Déployez des scénarios appropriés.
Tenez compte des ressources serveur supplémentaires lors de la planification de solutions basées sur SOAP.
Configurez l'option WSDL adaptée à vos impératifs.
Déployer des scénarios appropriés
Les services Web XML natifs conviennent mieux à des scénarios qui présentent les conditions suivantes :
Votre application retourne ou consomme des données XML.
Votre application dépend fortement des procédures stockées pour la logique métier.
Dans le cadre de votre solution d'entreprise, vous voulez intégrer une application de service Web hébergée par SQL Server à d'autres applications de service Web pour atteindre les objectifs d'une architecture orientée vers les services (SOA, Service Oriented Architecture).
Vous recherchez une solution de remplacement plus performante que la solution moyenne SQLXML pour déployer des services Web ensemble sur le même serveur.
Vous cherchez à produire et publier un rapport statique pour un site intranet où l'ensemble très complet des fonctionnalités disponibles et la charge supplémentaire de SQL Server 2005 Reporting Services (ou version ultérieure) peuvent dépasser vos attentes.
De même, le recours aux services Web XML natifs est déconseillé pour les scénarios qui présentent les conditions suivantes :
Votre application sert à insérer ou à récupérer des données BLOB (Binary Large OBject), telles que des grandes valeurs binary, image ou text.
Votre application exige un traitement des transactions en temps réel et des temps de réponse critiques.
Vous utilisez SQL Server en association avec d'autres applications exigeantes en traitement, telles que TPC Benchmark C (TPC-C).
Tenir compte des ressources serveur supplémentaires lors de la planification de solutions basées sur SOAP
À des fins de planification de la capacité, notez que contrairement au protocole TDS (Tabular Data Stream), les performances SOAP varient en fonction des applications et peuvent exiger des ressources serveur supplémentaires. Par exemple, lors des tests de SQL Server 2005 menés par l'équipe produit de SQL Server, dans des scénarios où des documents XML volumineux étaient retournés, les performances de l'accès SOAP étaient 20 à 30 pour cent supérieures à celles de l'accès TDS.
Configurer l'option WSDL adaptée à vos impératifs
Avant de déployer les services Web XML natifs, vous devez déterminer l'option WSDL appropriée à utiliser pour prendre en charge l'ensemble des clients et des systèmes d'exploitation indispensables à votre solution.
Pour une interopérabilité maximale dans des environnements hétérogènes dans lesquels les clients des services Web comportent des systèmes d'exploitation différents de Windows, utilisez WSDL simple. Pour les environnements exclusivement Windows dans lesquels vous développez avec Microsoft Visual Studio 2005, vous pouvez utiliser WSDL par défaut pour accéder à la prise en charge de type riche incluse dans Visual Studio 2005.
Il arrive que des clients SOAP tiers exigent un WSDL personnalisé pour des raisons d'interopérabilité. Pour plus d'informations, consultez Mise en œuvre d'une prise en charge WSDL personnalisée.