DataSunrise erreicht AWS DevOps Kompetenz Status in AWS DevSecOps und Überwachung, Protokollierung, Performance

Konfiguration des DataSunrise Sniffers für MS SQL Server

Konfiguration des DataSunrise Sniffers für MS SQL Server

Das Hauptmerkmal von Microsoft SQL Server ist, dass seine Hauptclientanwendung, SQL Server Management Studio, immer eine Verschlüsselung erfordert, selbst wenn das Kontrollkästchen Verbindung verschlüsseln nicht aktiviert ist.

fed_1

Das bedeutet für jeden Sniffer, dass es unmöglich ist, verschlüsselten Verkehr zu belauschen, oder der Sniffer benötigt einen privaten Server-Schlüssel für seine Entschlüsselung. Der DataSunrise Sniffer kann SSL-Verkehr entschlüsseln, wenn er über den privaten Schlüssel verfügt, daher werden wir auf die Konfiguration eines Servers für den Betrieb von DataSunrise im Sniffer-Modus eingehen.

Standardmäßig ist der Server so konfiguriert, dass er mit temporären Schlüsseln arbeitet – es sind keine statischen Schlüssel und Zertifikate dafür eingerichtet. Das Zertifikat und der Schlüssel werden für jede Verbindung generiert. Eine solche Strategie garantiert ein hohes Maß an Sicherheit für alle Serververbindungen. Daher ist klar, dass der integrierte Microsoft-Kryptoprovierter in den neuesten Windows-Versionen das Prioritätsniveau aller seiner temporären Verschlüsselungen erhöht hat. Und es wird nun schwieriger, Verschlüsselungen zu aktivieren, die besser zum Mitschneiden geeignet sind, ohne zusätzliche Serverkonfiguration.

Zertifikat

Um temporäre Verschlüsselungen zu deaktivieren und einen statischen privaten Schlüssel zu erhalten, ist es notwendig, ein Zertifikat zu installieren. Dies kann über den SQL Server Konfigurations-Manager (Protokolle für MSSQLSERVER-Features, SQL Server Netzwerk-Konfigurationseinstellungen, Zertifikatsreiter) durchgeführt werden:

fed

Hier können wir ein Zertifikat aus der Liste auswählen, das aus dem lokalen Zertifikatspeicher in Windows hochgeladen wurde.

Es gibt einige Microsoft-Anforderungen für die Vorbereitung des Zertifikats.

  1. Das Zertifikat muss sich entweder im lokalen Computerzertifikatspeicher oder im aktuellen Benutzerzertifikatspeicher befinden.
  2. Die aktuelle Systemzeit muss nach der Eigenschaft Gültig ab des Zertifikats und vor der Eigenschaft Gültig bis des Zertifikats liegen.
  3. Das Zertifikat muss für die Serverauthentifizierung vorgesehen sein. Dies erfordert, dass die Eigenschaft Enhanced Key Usage des Zertifikats die Serverauthentifizierung (1.3.6.1.5.5.7.3.1) spezifiziert.
  4. Das Zertifikat muss mit der KeySpec-Option von AT_KEYEXCHANGE erstellt werden.
  5. Die Subject-Eigenschaft des Zertifikats muss angeben, dass der allgemeine Name (CN) mit dem Hostnamen oder vollständig qualifizierten Domänennamen (FQDN) des Servercomputers übereinstimmt. Wenn SQL Server auf einem Failover-Cluster ausgeführt wird, muss der allgemeine Name mit dem Hostnamen oder FQDN des virtuellen Servers übereinstimmen, und die Zertifikate müssen auf allen Knoten im Failover-Cluster bereitgestellt werden.

Um ein Zertifikat zu erstellen, das diesen Bedingungen entspricht, können Sie das Make Cert-Dienstprogramm verwenden, das im Windows SDK enthalten ist.

makecert -r -pe -n "CN= HERE24322118" -b 01/09/2016 -e 01/09/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

In diesem Beispiel wird das Zertifikat “HERE24322118” erstellt und im lokalen Zertifikatspeicher abgelegt. In diesem Stadium kann dieses Zertifikat aus der Zertifikatsliste des SQL Server Konfigurations-Managers ausgewählt werden. Und nach dem Neustart des Servers kann es verwendet werden, um Netzwerkverbindungen zu sichern.

Server-Schlüssel

Der nächste Schritt besteht darin, den Server-Schlüssel zu erhalten. Dazu ist es notwendig, ihn aus einem Zertifikatsspeicher zu exportieren und key.pem aus certname.pfx zu extrahieren:

openssl pkcs12 -in certname.pfx -nocerts -out key.pem -nodes

Key.pem ist der private Schlüssel, den der Sniffer benötigt.

<>Der Server ist konfiguriert und sein privater Schlüssel gewonnen, aber er verwendet immer noch temporäre Algorithmen aufgrund des Kryptoproviders. Um die Algorithmen zum temporären Schlüsselaustausch zu deaktivieren, muss auf die entsprechende Microsoft-Anleitung oder deren GUI-Interpretation – IIScrypto – verwiesen werden.

fed_3

Hier müssen Sie 2 Schlüsselaustauschalgorithmen deaktivieren: Diffie Hellman und ECDH. Die Änderungen werden nach dem Neustart des Hostservers wirksam.

Schlüsselintegration in DataSunrise

Der letzte Schritt besteht darin, den Schlüssel in DataSunrise zu installieren. Dazu öffnen wir die Konfigurationen-Registerkarte, wählen die erforderliche Datenbank aus, öffnen das Zertifikate-Fenster, den PrivateKey-Reiter und fügen den privaten Schlüssel, der aus der Datei kopiert wurde, ein.

fed_4

Die Konfiguration des Servers und die Firewall für SQL Server-Sniffing ist abgeschlossen. Und wir werden überlegen, wie wir den Schutz Ihrer Infrastruktur einfacher und besser gestalten können.

Nächste

Integration von DataSunrise mit Splunk Enterprise

Integration von DataSunrise mit Splunk Enterprise

Erfahren Sie mehr

Benötigen Sie die Hilfe unseres Support-Teams?

Unsere Experten beantworten gerne Ihre Fragen.

Allgemeine Informationen:
[email protected]
Kundenservice und technischer Support:
support.datasunrise.com
Partnerschafts- und Allianz-Anfragen:
[email protected]