Bewährte Methoden für das Verwenden systemeigener XML-Webdienste
Diese Funktion wird in zukünftigen Versionen von Microsoft SQL Server nicht mehr bereitgestellt. Verwenden Sie diese Funktion beim Entwickeln neuer Anwendungen nicht, und planen Sie das Ändern von Anwendungen, in denen es zurzeit verwendet wird.
Dieses Thema stellt einige bewährte Methoden für die Planung und Auswertung systemeigener XML-Webdienste in SQL Server vor, die in Geschäftslösungen verwendet werden. Diese Empfehlungen sollen Sie auf folgende Weise unterstützen:
Sichern der Installation von SQL Server, wenn systemeigene XML-Webdienste verwendet werden.
Verbessern der Leistung der Installation von SQL Server durch Bereitstellen von Verwendungsrichtlinien. Diese Richtlinien können Sie bei der Entscheidung unterstützen, ob Ihre Anwendung mithilfe systemeigener XML-Webdienste effektiv bereitgestellt wird.
Bewährte Methoden für die Sicherheit
Berücksichtigen Sie die folgenden Empfehlungen hinsichtlich bewährter Methoden für die Sicherheit, wenn Sie systemeigene XML-Webdienste bereitstellen:
Verwenden Sie Kerberos-Authentifizierung.
Beschränken Sie Endpunkt-Verbindungsberechtigungen auf bestimmte Benutzer oder Gruppen.
Verwenden Sie SSL (Secure Socket Layer), um vertrauliche Daten auszutauschen.
Verwenden Sie SQL Server hinter einer Firewall.
Stellen Sie sicher, dass das Windows-Gastkonto auf dem Server deaktiviert ist.
Steuern und aktualisieren Sie den Endpunktstatus nach Bedarf.
Verwenden Sie nach Möglichkeit sichere Endpunkt-Standardeinstellungen.
Verwenden von Kerberos-Authentifizierung
Wenn Sie CREATE ENDPOINT (Transact-SQL) zum Erstellen von Endpunkten verwenden, wählen Sie AUTHENTICATION=KERBEROS oder AUTHENTICATION = INTEGRATED aus, um die integrierte Windows-Sicherheit unter Kerberos als Authentifizierungstyp zu aktivieren, der für einen Endpunkt verwendet wird. Mit der ersten Option ist ausschließlich Kerberos als Authentifizierungsmodus für den Endpunkt zulässig. Die zweite Option ermöglicht, dass der Endpunkt NTLM- und Kerberos-Authentifizierung unterstützt.
Für die Authentifizierung stellt das Kerberos-Protokoll verbesserte Sicherheit bereit, indem integrierte Funktionen wie z. B. gegenseitige Authentifizierung verwendet werden. Dies bedeutet, dass die Identität von Servern und Clients authentifiziert wird.
Wenn Sie Kerberos-Authentifizierung verwenden, muss SQL Server dem Konto, für das die Anwendung ausgeführt wird, einen Dienstprinzipalnamen (Service Principal Name, SPN) zuordnen. Weitere Informationen finden Sie unter Registrieren von Kerberos-Dienstprinzipalnamen (Service Principal Names, SPNs) mithilfe von Http.sys.
Beschränken der Endpunkt-Verbindungsberechtigungen auf bestimmte Benutzer oder Gruppen
Nachdem Sie die Endpunkte erstellt haben, die für Ihre Bereitstellung erforderlich sind, sichern Sie diese, indem Sie Endpunkt-Verbindungsberechtigungen mithilfe von Transact-SQL-Anweisungen (z. B. GRANT CONNECT und ALTER ON ENDPOINT) festlegen. Wenn Sie Verbindungsberechtigungen zuweisen, gehen Sie sorgfältig vor und erteilen nur den betreffenden Benutzern oder der Gruppe Berechtigungen, die für den Endpunktzugriff auf SQL Server reserviert sind bzw. ist.
Im Allgemeinen sollten Sie Berechtigungen so einschränken, dass nur einzelne Benutzer Verbindungen mit Endpunkten herstellen können. Das Gewähren des Zugriffs für die public-Rolle wird nicht empfohlen. Sie sollten umfassende Kenntnisse des Berechtigungsmodells für SQL Server besitzen. Mithilfe dieses Modells können Sie den Endpunktzugriff mit Umsicht steuern.
.gif "Wichtiger Hinweis") Wichtig |
|---|
Die public-Rolle ist eine besondere Datenbankrolle, zu der jeder SQL Server-Benutzer gehört. Diese Rolle enthält Standardzugriffsberechtigungen für alle Benutzer, die auf die Datenbank zugreifen können. Da es sich bei dieser Datenbankrolle um eine integrierte Standardrolle von SQL Server handelt, die ein Mittel zum Gewähren des Zugriffs für alle Benutzer bereitstellt (ähnlich wie Jeder oder Authentifizierte Benutzer in den Windows-Berechtigungen), sollte diese mit Vorsicht verwendet werden, wenn Sie die Berechtigungen für SQL Server konfigurieren. |
Weitere Informationen finden Sie unter GRANT (Endpunktberechtigungen) (Transact-SQL).
Verwenden von SSL (Secure Socket Layer), um vertrauliche Daten auszutauschen
Das SSL-Protokoll (Secure Sockets Layer) bietet Unterstützung für Ver- und Entschlüsselung von Daten über eine sichere TCP/IP-Socketschnittstelle (Kombination aus IP-Adresse und TCP-Portnummer). Damit SQL Server-Endpunkte die SSL-Verschlüsselung zur Verfügung stellen können, müssen Sie zuvor ein Zertifikat konfigurieren.
Wenn Sie ein Zertifikat für den SSL-Standardport 443 registrieren, sollten Sie berücksichtigen, dass das gleiche Zertifikat möglicherweise auch für andere Anwendungen freigegeben wurde. Die Internetinformationsdienste (Internet Information Service, IIS) hosten möglicherweise SSL-Datenverkehr am gleichen Port; in diesem Fall kann sich diese Konfiguration auf Benutzer von IIS auswirken. Es kann aufgrund dieser Freigabe des SSL-Ports und seiner Zertifikate zu Auswirkungen auf die Sicherheit kommen.
Weitere Informationen finden Sie unter Konfigurieren eines Zertifikats zur Verwendung durch SSL.
Verwenden von SQL Server hinter einer Firewall
Um optimale Sicherheit zu gewährleisten, sollten Sie die systemeigenen XML-Webdienste ausschließlich hinter einer Firewall verwenden. Stellen Sie beim Einrichten von Endpunkten sicher, dass alle für den HTTP-Zugriff verwendeten TCP-Portnummern durch eine Firewall geschützt sind. Der direkte Zugriff auf eine Installation von SQL Server durch Internetclients sowie fehlender Firewallschutz ist keine empfohlene Netzwerkkonfiguration. Weitere Informationen finden Sie unter Sicherheitsüberlegungen bei SQL Server-Installationen.
Sicherstellen, dass das Windows-Gastkonto auf dem Server deaktiviert ist
Das Gastkonto ist ein integriertes Konto, das in den meisten Versionen von Microsoft Windows bereitgestellt wird. In Windows Server 2003 ist es standardmäßig deaktiviert. Für Windows 2000 Server und Windows NT Server 4.0 ist es standardmäßig aktiviert.
Damit das Risiko von Oberflächenangriffen bei der Verwendung von Endpunkten verringert wird, sollten Sie sicherstellen, dass das Gastkonto auf dem Server deaktiviert ist, auf dem SQL Server ausgeführt wird. Weitere Informationen finden Sie in dem Thema zum Deaktivieren oder Aktivieren eines lokalen Benutzerkontos in der Windows-Hilfe.
Steuern und Aktualisieren des Endpunktstatus nach Bedarf
Wenn Sie mithilfe von CREATE ENDPOINT (Transact-SQL) einen Endpunkt erstellen, lautet der Standardstatus STOPPED, wenn Sie ihn nicht ausdrücklich durch Angeben von STATE = STARTED starten. Verwenden Sie ALTER ENDPOINT (Transact-SQL) zum Angeben von STOPPED, STARTED oder DISABLED, um den Status eines vorhandenen Endpunkts zu steuern.
Verwenden Sie z. B. die folgenden Anweisungen, um den zuvor erstellten Endpunkt sql_endpoint zu starten oder zu stoppen:
ALTER ENDPOINT sql_endpoint STATE=STARTED
ALTER ENDPOINT sql_endpoint STATE=STOPPED
Sie sollten außerdem Endpunkte deaktivieren oder bestimmte Webmethoden für einen Endpunkt löschen bzw. den Endpunkt selbst löschen, wenn keine Verwendung für diese absehbar ist.
Das folgende Beispiel zeigt das Deaktivieren eines Endpunktes:
ALTER ENDPOINT sql_endpoint STATE=DISABLED
.gif "Hinweis") Hinweis |
|---|
Nachdem ein Endpunkt deaktiviert wurde, kann er erst neu gestartet werden, nachdem der SQL Server-Dienst (MSSQLServer) neu gestartet wurde. |
Wenn Sie eine Webmethode aus einem Endpunkt löschen möchten, verwenden Sie eine Anweisung, die dem folgenden Format ähnlich ist:
ALTER ENDPOINT sql_endpoint
FOR SOAP
(
DROP WEBMETHOD 'SayHello'
)
Verwenden Sie DROP ENDPOINT, um einen Endpunkt zu löschen.
Verwenden sicherer Endpunkt-Standardeinstellungen
Wenn Sie einen Endpunkt mithilfe von CREATE ENDPOINT oder ALTER ENDPOINT erstellen oder ändern, werden die folgenden Optionsstandardwerte angewendet, wenn nicht ausdrücklich etwas anderes festgelegt wird:
BATCHES = DISABLED
Der Transact-SQLBatch-Modus ist für den Endpunkt deaktiviert.
LOGIN_TYPE = WINDOWS
Nur Windows-Authentifizierung ist für Endpunktbenutzer zulässig.
Es wird empfohlen, diese Standardwerte nach Möglichkeit für die genannten Optionen zu verwenden, wenn Sie diese Einstellungen nicht ändern müssen, um Zugriff oder Funktionen zu unterstützen, der bzw. die für Ihre Anwendungsbereitstellung vorgesehen und erforderlich sind oder ist.
Weitere Informationen zur Auswahl eines Verschlüsselungsalgorithmus finden Sie unter Auswählen eines Verschlüsselungsalgorithmus.
Bewährte Methoden bezüglich der Leistung
Berücksichtigen Sie die folgenden Empfehlungen hinsichtlich bewährter Methoden für die Leistung, wenn Sie systemeigene XML-Webdienste bereitstellen:
Führen Sie die Bereitstellung in geeigneten Szenarien durch.
Sehen Sie zusätzliche Serverressourcen vor, wenn Sie SOAP-basierte Lösungen planen.
Konfigurieren Sie die geeignete WSDL-Option für Ihre Anforderungen.
Durchführen der Bereitstellung in geeigneten Szenarien
Die systemeigenen XML-Webdienste eignen sich am besten für Szenarien mit den folgenden Anforderungen:
Ihre Anwendung gibt XML-Daten zurück oder verarbeitet diese.
Ihre Anwendung verwendet für Geschäftslogik bevorzugt gespeicherte Prozeduren.
Sie möchten eine durch SQL Server gehostete Webdiensteanwendung als Teil Ihrer Geschäftslösung in andere Webdiensteanwendungen integrieren, um die Ziele einer Service Oriented Architecture (SOA, Dienstorientierte Architektur) zu erreichen.
Sie suchen nach einem Ersatz mit besserer Leistung für die SQLXML-Lösung der mittleren Schicht zum gemeinsamen Bereitstellen von Webdiensten auf dem gleichen Server.
Sie möchten einen statischen Bericht für eine Intranetwebsite erstellen und veröffentlichen, auf der die reichhaltige Funktionssammlung und der zusätzliche Aufwand von SQL Server 2005 Reporting Services oder höher Ihre Anforderungen übersteigt.
Auch in Szenarien mit den folgenden Anforderungen wird das Verwenden systemeigener XML-Webdienste nicht empfohlen:
Ihre Anwendung wird zum Einfügen oder Abrufen von BLOB-Daten (Binary Large Object) verwendet, z. B. von großen binary-, image- oder text-Werten.
Ihre Anwendung erfordert Transaktionsverarbeitung in Echtzeit und unternehmenswichtige Antwortzeiten.
Sie verwenden SQL Server in Kombination mit anderen verarbeitungsintensiven Anwendungen wie z. B. TPC C-Anwendungen (TPC Benchmark C).
Vorsehen zusätzlicher Serverressourcen beim Planen SOAP-basierter Lösungen
Beachten Sie für die Kapazitätsplanung, dass die SOAP-Leistung im Gegensatz zum TDS-Protokoll (Tabular Data Stream) je nach Anwendung unterschiedlich ist und zusätzliche Serverressourcen erfordern kann. Bei Tests von SQL Server 2005, die vom SQL Server-Produktteam durchgeführt wurden, war die Leistung in Szenarien, in denen große XML-Dokumente zurückgegeben wurden, für SOAP-basierten Zugriff hinsichtlich der Leistung um 20 bis 30 % geringer als bei TDS-basiertem Zugriff.
Konfigurieren der geeigneten WSDL-Option für Ihre Anforderungen
Bevor Sie systemeigene XML-Webdienste bereitstellen, sollten Sie die geeignete WSDL-Option für die Unterstützung aller Clients und Betriebssysteme ermitteln, die für Ihre Lösung erforderlich sind.
Die maximale Interoperabilität in heterogenen Umgebungen, in denen Webdiensteclients mit anderen Betriebssystemen als Windows vorhanden sind, erzielen Sie, wenn Sie einfaches WSDL verwenden. Für Nur-Windows-Umgebungen, in denen die Entwicklung mit Microsoft Visual Studio 2005 erfolgt, können Sie Standard-WSDL für den Zugriff auf die reichhaltige Typenunterstützung verwenden, die in Visual Studio 2005 enthalten ist.
Manchmal erfordern SOAP-Clients von Drittanbietern ein angepasstes WSDL für die Interoperabilität. Weitere Informationen finden Sie unter Implementieren von benutzerdefinierter WSDL-Unterstützung.