Transportsicherheit für Datenbankspiegelung und AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

Artikel
06/25/2013

Die Transportsicherheit in SQL Server 2005 und höheren Versionen schließt die Authentifizierung und optional die Verschlüsselung der Nachrichten ein, die zwischen den Datenbanken ausgetauscht werden. Für die Datenbankspiegelung und AlwaysOn-Verfügbarkeitsgruppen werden Authentifizierung und Verschlüsselung am Datenbankspiegelungs-Endpunkt konfiguriert. Eine Einführung zu Datenbankspiegelungs-Endpunkten finden Sie unter Der Datenbankspiegelungs-Endpunkt (SQL Server).

In diesem Thema:

Authentifizierung
Datenverschlüsselung
Verwandte Aufgaben

Authentifizierung

Unter Authentifizierung versteht man den Prozess, mit dem überprüft wird, ob es sich bei einem Benutzer wirklich um die Person handelt, die der Benutzer angeblich ist. Verbindungen zwischen Datenbank-Spiegelungsendpunkten erfordern die Authentifizierung. Verbindungsanforderungen von einem Partner oder ggf. einem Zeugen müssen authentifiziert werden.

Der für Datenbankspiegelung oder AlwaysOn-Verfügbarkeitsgruppen von einer Serverinstanz verwendete Authentifizierungstyp ist eine Eigenschaft des Endpunkts der Datenbankspiegelung. Für Datenbankspiegelungs-Endpunkte sind zwei Arten von Transportsicherheit verfügbar: Windows-Authentifizierung (die Security Support Provider Interface (SSPI)) oder zertifikatbasierte Authentifizierung.

Windows-Authentifizierung

Bei der Windows-Authentifizierung erfolgt die Anmeldung jeder Serverinstanz bei der anderen Seite mithilfe der Windows-Anmeldeinformationen des Windows-Benutzerkontos, unter dem der Prozess ausgeführt wird. Die Windows-Authentifizierung erfordert eventuell eine manuelle Konfiguration von Anmeldekonten, je nach den folgenden Bedingungen:

Wenn die Instanzen von SQL Server als Dienste unter dem gleichen Domänenkonto ausgeführt werden, ist keine zusätzliche Konfiguration erforderlich.
Wenn die Instanzen von SQL Server als Dienste unter unterschiedlichen Domänenkonten ausgeführt werden (in der gleichen oder einer vertrauenswürdigen Domäne), müssen die Anmeldeinformationen jedes Kontos in master auf jeder der anderen Serverinstanzen erstellt werden. Dieser Anmeldung müssen CONNECT-Berechtigungen für den Endpunkt gewährt werden.
Wenn die Instanzen von SQL Server als Netzwerkdienstkonto ausgeführt werden, muss die Anmeldung zu jedem Hostcomputer-Konto (DomainName**\**ComputerName$) in master auf jedem der anderen Server erstellt werden. Dieser Anmeldung müssen CONNECT-Berechtigungen für den Endpunkt gewährt werden. Das liegt daran, dass eine Serverinstanz, die unter dem Netzwerkdienstkonto ausgeführt wird, mit dem Domänenkonto des Hostcomputers authentifiziert wird.

Hinweis
Ein Beispiel zum Einrichten einer Datenbankspiegelungssitzung mithilfe der Windows-Authentifizierung finden Sie unter Beispiel: Einrichten der Datenbankspiegelung mithilfe der Windows-Authentifizierung (Transact-SQL).

Zertifikate

Unter bestimmten Umständen – z. B. wenn sich Serverinstanzen nicht in vertrauenswürdigen Domänen befinden oder wenn SQL Server als lokaler Dienst ausgeführt wird – steht die Windows-Authentifizierung nicht zur Verfügung. In solchen Fällen werden zum Authentifizieren der Verbindungsanforderungen anstelle der Benutzeranmeldeinformationen Zertifikate benötigt. Der Spiegelungsendpunkt jeder Serverinstanz muss mit ihrem eigenen lokal erstellten Zertifikat konfiguriert werden.

Die Verschlüsselungsmethode wird beim Erstellen des Zertifikats festgelegt. Weitere Informationen finden Sie unter Ermöglichen des Verwendens von Zertifikaten für ausgehende Verbindungen für einen Datenbankspiegelungs-Endpunkt (Transact-SQL). Gehen Sie bei der Verwaltung der von Ihnen verwendeten Zertifikate mit großer Vorsicht vor.

Eine Serverinstanz verwendet den privaten Schlüssel ihres eigenen Zertifikats, um bei einem Verbindungsaufbau ihre Identität einzurichten. Die Serverinstanz, die die Verbindungsanforderung empfängt, verwendet den öffentlichen Schlüssel des Absenderzertifikats, um die Identität des Absenders zu authentifizieren. Angenommen es gibt z. B. zwei Serverinstanzen, Server_A und Server_B. Von Server_A wird ein privater Schlüssel zur Verschlüsselung des Verbindungsheaders verwendet, bevor eine Verbindungsanforderung an Server_B gesendet wird. Von Server_B wird der öffentliche Schlüssel des Zertifikats von Server_A verwendet, um den Verbindungsheader zu entschlüsseln. Wenn der entschlüsselte Header richtig ist, weiß Server_B, dass der Header von Server_A verschlüsselt wurde, und die Verbindung wird authentifiziert. Wenn der entschlüsselte Header nicht richtig ist, erkennt Server_B, dass die Verbindungsanforderung nicht authentisch ist, und verweigert den Verbindungsaufbau.

Datenverschlüsselung

Standardmäßig setzt ein Datenbank-Spiegelungsendpunkt die Verschlüsselung der über Spiegelungsverbindungen gesendeten Daten voraus. In diesem Fall kann der Endpunkt nur Verbindungen mit Endpunkten herstellen, die ebenfalls mit Verschlüsselung arbeiten. Sofern Sie nicht garantieren können, dass Ihr Netzwerk sicher ist, wird empfohlen, das Verschlüsseln bei Verbindungen zur Datenbankspiegelung vorauszusetzen. Allerdings können Sie die Verschlüsselung auch deaktivieren oder festlegen, dass die Verschlüsselung zwar unterstützt wird, jedoch nicht erforderlich ist. Bei deaktivierter Verschlüsselung werden die Daten niemals verschlüsselt, und der Endpunkt kann keine Verbindung mit einem Endpunkt herstellen, der die Verschlüsselung erfordert. Wenn die Verschlüsselung unterstützt wird, werden die Daten nur dann verschlüsselt, wenn der gegenüberliegende Endpunkt die Verschlüsselung unterstützt oder erfordert.

Hinweis
Alle durch SQL Server Management Studio erstellten Spiegelungsendpunkte werden entweder mit erforderlicher Verschlüsselung oder mit deaktivierter Verschlüsselung erstellt. Zum Ändern der Verschlüsselungseinstellung zu SUPPORTED verwenden Sie die Transact-SQL-Anweisung ALTER ENDPOINT. Weitere Informationen finden Sie unter ALTER ENDPOINT (Transact-SQL).

Sie können auch die Verschlüsselungsalgorithmen steuern, die von einem Endpunkt verwendet werden können, indem Sie einen der folgenden Werte für die ALGORITHM-Option in einer CREATE ENDPOINT- oder ALTER ENDPOINT-Anweisung angeben:

RC4

Gibt an, dass der Endpunkt den RC4-Algorithmus verwenden muss. Dies ist die Standardeinstellung.

Hinweis
Der RC4-Algorithmus ist veraltet. 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 so bald wie möglich das Ändern von Anwendungen, in denen es zurzeit verwendet wird. Stattdessen wird die Verwendung von AES empfohlen.

AES

Gibt an, dass der Endpunkt den AES-Algorithmus verwenden muss.

AES RC4

Gibt an, dass die beiden Endpunkte einen Verschlüsselungsalgorithmus aushandeln, wobei dieser Endpunkt dem AES-Algorithmus den Vorzug gibt.

RC4 AES

Gibt an, dass die beiden Endpunkte einen Verschlüsselungsalgorithmus aushandeln, wobei dieser Endpunkt dem RC4-Algorithmus den Vorzug gibt.

Wenn das Verbinden der Endpunkte beide Algorithmen angibt, jedoch in unterschiedlicher Reihenfolge, wird die Einstellung des Endpunkts verwendet, der die Verbindung annimmt.

Hinweis
Der RC4-Algorithmus wird nur aus Gründen der Abwärtskompatibilität unterstützt. Neues Material kann nur mit RC4 oder RC4_128 verschlüsselt werden, wenn die Datenbank den Kompatibilitätsgrad 90 oder 100 besitzt. (Nicht empfohlen.) Verwenden Sie stattdessen einen neueren Algorithmus, z. B. einen der AES-Algorithmen. In SQL Server 2012 kann mit RC4 oder RC4_128 verschlüsseltes Material in jedem Kompatibilitätsgrad entschlüsselt werden. Obwohl deutlich schneller als AES, ist RC4 ein relativ schwacher Algorithmus, während AES ein relativ starker Algorithmus ist. Deshalb wird empfohlen, den AES-Algorithmus zu verwenden.

Der RC4-Algorithmus wird nur aus Gründen der Abwärtskompatibilität unterstützt. Neues Material kann nur mit RC4 oder RC4_128 verschlüsselt werden, wenn die Datenbank den Kompatibilitätsgrad 90 oder 100 besitzt. (Nicht empfohlen.) Verwenden Sie stattdessen einen neueren Algorithmus, z. B. einen der AES-Algorithmen. In SQL Server 2012 kann mit RC4 oder RC4_128 verschlüsseltes Material in jedem Kompatibilitätsgrad entschlüsselt werden.

Obwohl deutlich schneller als AES, ist RC4 ein relativ schwacher Algorithmus, während AES ein relativ starker Algorithmus ist. Deshalb wird empfohlen, den AES-Algorithmus zu verwenden.

Informationen zur Transact-SQL-Syntax zum Angeben der Verschlüsselung finden Sie unter CREATE ENDPOINT (Transact-SQL).