2009-05-25 22 views
11

Ich muss beweisen, dass die Verschlüsselungseinstellungen, die wir in der Verbindungszeichenfolge unserer App haben, funktionieren.Wie wird SQL Server-Datenverkehr verschlüsselt?

Was wäre der einfachste Weg zu überprüfen, ob der Datenverkehr von unserer Website zum SQL Server tatsächlich verschlüsselt ist?

Antwort

25

könnten Sie so etwas wie Wireshark verwenden, um die Pakete zu betrachten, auf sie über das Netzwerk übertragen sind

+0

+1 Dies ist ein großes Werkzeug dafür. – BenAlabaster

+1

+1, auf Wiedersehen zu meiner späten Antwort. – karim79

+1

Eine weitere +1 für Wireshark. Genau das benutze ich, um es Kunden zu beweisen, wenn sie fragen, ob etwas sicher ist. –

6

Ich würde das Force Protocol Encryption auf true and Trust Server-Zertifikat festgelegt in der DB-Verbindungszeichenfolge auf true. Der Server kann keine Verbindung herstellen, wenn er Ihnen nicht wie gewünscht eine verschlüsselte Verbindung bereitstellen kann. Es gibt eine article, die die Verschlüsselung mit SQL Server 2005 und höher abdeckt.

Einfacher Test ist eine Verbindung mit und ohne Verschlüsselung versuchen und scheitern, wenn es die unerwünschte Art der Verbindung ausgibt. Dann ist es an den DBA, IT oder Sie den Server zu konfigurieren, um Ihre Anforderungen zu erfüllen.

+2

+1 für Ihre Antwort. Im Gegensatz zur Wireshark-Option wird das Erstellen eines Tests zum Nachweis, dass die unverschlüsselte Verbindung zurückgewiesen wird, auch demonstrieren, dass die Anforderungen an die Anwendersicherheit nicht nur durch Ändern der Einstellungen auf der Datenbankserverseite herabgesetzt werden können. –

+2

Integrierte Sicherheit bedeutet, dass Sie NTLM- oder Kerberos-Authentifizierung verwenden. Es bedeutet nicht, dass Ihr Datenverkehr verschlüsselt ist. – Andomar

+0

@andomar ist korrekt --- Es ist mein Verständnis, dass die Kredits (unabhängig von integrierten oder gemischten Modus) verschlüsselt werden würde - es ist der Rest des Verkehrs, an den ich denke. –

11

Sie überprüfen die encrypt_option Spalte der sys.dm_exec_connections DMV. Auf diese Weise können Sie nicht nur beweisen, dass es verschlüsselt ist, Sie können es auch in Ihrer Anwendung bei der Inbetriebnahme validieren. Um die Verschlüsselung zu erzwingen, folgen Sie den in dieser MSDN How To: Enable Encrypted Connections to the Database Engine beschriebenen Methoden. Wenn entweder der Client oder der Server die Verschlüsselung erzwingt und ein Zertifikat bereitgestellt wird und der Client das Serverzertifikat akzeptiert, wird die Verbindung verschlüsselt. Um sicherzustellen, dass der Datenverkehr verschlüsselt ist, können Sie das integrierte Tool netmon.exe verwenden (muss von der Systemkomponente ad/remove installiert werden), laden Sie die verbesserten Microsoft Network Monitor 3.2 oder andere Tools von Drittanbietern herunter.

Als Alternative kann die Bereitstellungssite die IPSec-Verschlüsselung erzwingen.

+1

+1 für die verschlüsselung_option als eine einfache schnelle überprüfung. Verwenden Sie zum Kopieren und Einfügen eines Liners: 'SELECT encrypt_option FROM sys.dm_exec_connections WHERE session_id = @@ SPID'. Kein Beweis dafür, dass Ihre bereitgestellte Anwendung natürlich die Verschlüsselung verwendet, bestätigt aber den SQL Server _can_. – hlascelles

+0

@hlascelles: 'encrypt_option' ist ein Wert nach der Tat. Wenn es heißt, dass es verschlüsselt ist, bedeutet das, dass die App * verschlüsselten Verkehr verwendet. Auf dieser Sitzung zumindest (normalerweise auch auf allen anderen). –

+0

Sie sind tot richtig. Entschuldigung, ich kam aus Sicht des Administrators dazu: Testen eines SQL Server-Deployments von einer Workstation aus (zB Überprüfen von Zertifikaten). Wie @Remus sagt, fügen Sie für eine Laufzeitprüfung die obige Zeile zu Ihrem implementierten Code hinzu (mithilfe der WHERE-Klausel, um sicherzustellen, dass es sich um Ihre tatsächliche Verbindung handelt). – hlascelles

0

Um sicherzustellen, dass die Verschlüsselung verwendet wird, müssen Sie enable the force encryption option auf dem Server.

Clientseitige Verschlüsselung ist nicht obligatorisch. Die Serverseite ist obligatorisch.

Wenn der SQL Server-Dienst gestartet wird, wird er angehalten, wenn er das Zertifikat nicht lesen kann oder andere Hindernisse vorhanden sind. Es akzeptiert keine unverschlüsselten Verbindungen.

Um zu antworten, benutzte ich einen Paket-Sniffer der erste, den ich verwendete Verschlüsselung zu überprüfen, dann verließ ich mich nur auf die Tatsache, dass serverseitige Verschlüsselung obligatorisch ist und SQL wird nicht gestartet.

For SQL 2000, KB 276553

Denken Sie daran, dass es eine aktuelle SQL Server Einschränkung ist, wenn Sie Verschlüsselung auf dem Server aktivieren. Verschlüsselung wird für alle eingehenden Verbindungen sein. Wenn Sie die Verschlüsselung auf dem Client Computer aktivieren, werden alle abgehenden Verbindungen von diesem Client versuchen eine verschlüsselte Verbindung zu einem SQL Server zu machen.

A KB search for SQL 2005

Später bearbeiten:

Verwenden Sie eine ältere Version des MS JDBC-Client: Es kann nicht die serverseitige Verschlüsselung umgehen ...

+0

Durch "müssen Sie die Verschlüsselung auf dem Server aktivieren," meinst du "müssen Sie die erforderlichen Verschlüsselungsverbindungen auf dem Server aktivieren"? Wenn diese Einstellung nicht auf "true" gesetzt ist, erlaubt der Server sowohl unverschlüsselte als auch Erst-Login-Paket-nur-verschlüsselte Verbindungen. –

+0

@BenGribaudo Sobald das Kontrollkästchen in der SQL Server-Konfiguration aktiviert ist, akzeptiert der Server nur verschlüsselte Verbindungen. Serverseitige Verschlüsselung ist obligatorisch, wenn dies aktiviert ist. Alle meine Server haben das. – gbn

1

Es gibt ein anderes viel unterschätztes Tool von Microsoft selbst: "Microsoft Network Monitor". Im Prinzip ist das sehr ähnlich zu wireshark mit der Ausnahme, dass einige MS-Protokolle eine bessere Parser- und Visualisierungsunterstützung als Wireshark selbst haben und offensichtlich nur unter Windows laufen würden ;-).

Das Tool ist ziemlich alt und sieht verlassen aus (habe bis jetzt keine neuere Version gesehen), aber es macht immer noch einen guten Job und die Grammatik für die Definition neuer Protokolle ist recht ordentlich/interessant - also besitzt diese noch eine Menge Power für die Zukunft. mnm 3.4 about dialog

Analyse Beispiel - Die Aufzeichnung wird für TDS gefiltert - so dass die anderen Pakete werden discared meist:

Example Session for TDS (MSSQL)

Dies ist für SQL Server-Verbindungen auch wahr ist. Das MNM kann sogar die Ergebnismengen visualisieren, die über die Leitung gehen - ganz ordentlich. Nichtsdestoweniger würde ein wie oben beschriebener Drahthai ausreichen, um die Verschlüsselung und die angewandten Zertifikate auf dem Draht selbst zu validieren. Bedeutet, dass es das TDS-Protokoll vollständig verstehen kann.

TLS Handhabung

auch mit einer Verlängerung (so genannte Experten) ‚NmDecrypt‘ und die richtigen Zertifikate (einschließlich privater Schlüssel) - es ist möglich protocolls zu entschlüsseln - ganz nett für TDS, die verwendet TLS INNEN TDS - kein Wunder - niemand hat wirklich realisiert, dass noch als voll unterstützte Protokoll für wireshark;)

Links für die Werkzeuge:

Verwandte Themen