Teilen über

Verschlüsseln von Verbindungen mit SQL Server unter Linux

  • Artikel

Gilt für: SQL Server – Linux

SQL Server für Linux kann Transport Layer Security (TLS) zum Verschlüsseln der Daten verwendet werden, die über ein Netzwerk zwischen einer Clientanwendung und einer Instanz von SQL Server übertragen werden. SQL Server unterstützt unter Windows und Linux die gleichen TLS-Protokolle: TLS 1.2, 1.1 und 1.0. Die Schritte zum Konfigurieren von TLS sind jedoch spezifisch für das Betriebssystem, auf dem SQL Server ausgeführt wird.

Anforderungen an Zertifikate

Stellen Sie sicher, dass Ihre Zertifikate den folgenden Anforderungen entsprechen:

  • Die aktuelle Systemzeit muss nach der Valid from-Eigenschaft und vor der Valid to-Eigenschaft des Zertifikats liegen.

  • Das Zertifikat muss für die Serverauthentifizierung vorgesehen sein. Dazu muss die Enhanced Key Usage-Eigenschaft des Zertifikats Server Authentication (1.3.6.1.5.5.7.3.1) angeben.

  • Das Zertifikat muss mithilfe der KeySpec-Option von AT_KEYEXCHANGE erstellt werden. Normalerweise enthält die Schlüsselverwendungseigenschaft (KEY_USAGE) des Zertifikats auch die Schlüsselverschlüsselung (CERT_KEY_ENCIPHERMENT_KEY_USAGE).

  • Mit der Eigenschaft Subject des Zertifikats muss angegeben werden, dass der allgemeine Name (Common Name, CN) mit dem Hostnamen oder dem vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des Servercomputers übereinstimmt.

    Hinweis

    Platzhalterzertifikate werden unterstützt.

Konfigurieren der OpenSSL-Bibliotheken zur Verwendung (optional)

Sie können symbolische Verknüpfungen im /opt/mssql/lib/-Verzeichnis erstellen, die darauf verweisen, welche libcrypto.so- und libssl.so-Bibliotheken für die Verschlüsselung verwendet werden sollen. Dies ist hilfreich, wenn Sie erzwingen möchten, dass SQL Server eine bestimmte andere OpenSSL-Version als die vom System bereitgestellte Standardversion verwendet. Wenn diese symbolischen Verknüpfungen nicht vorhanden sind, lädt SQL Server die standardmäßig auf dem System konfigurierten OpenSSL-Bibliotheken.

Diese symbolischen Verknüpfungen sollten mit libcrypto.so und libssl.so benannt und in das /opt/mssql/lib/-Verzeichnis eingefügt werden.

Hinweis

Ein Beispiel für die Verwendung von Let's Encrypt zum Generieren eines Zertifikats finden Sie im Blogbeitrag "Entsperren der Leistungsfähigkeit von Daten in Azure mit SQL Server für Linux Azure-VMs und Azure AI-Suche".

Übersicht

TLS wird zum Verschlüsseln von Verbindungen einer Clientanwendung mit SQL Server verwendet. Bei ordnungsgemäßer Konfiguration bietet TLS sowohl Datenschutz als auch Datenintegrität für die Kommunikation zwischen dem Client und dem Server. TLS-Verbindungen können entweder vom Client oder vom Server initiiert werden.

Im folgenden Abschnitt wird das Einrichten der vom Client initiierten Verschlüsselung beschrieben.

Generieren eines Zertifikats

/CN sollte mit dem vollqualifizierten Domänennamen des SQL Server-Hosts identisch sein.

Achtung

In diesem Beispiel wird ein selbstsigniertes Zertifikat verwendet. Selbstsignierte Zertifikate sollten nicht für Produktionsszenarien verwendet werden. Sie sollten Zertifizierungsstellenzertifikate verwenden.

Stellen Sie sicher, dass die Ordner, in denen Sie Ihre Zertifikate und privaten Schlüssel speichern, für die mssql-Benutzer/-Gruppe zugänglich sind und die Berechtigung auf 700 (drwx-----) festgelegt ist. Sie können Ordner manuell erstellen, die Berechtigung auf 700 (drwx------) festlegen und die mssql-Benutzer/-Gruppe als Besitzer festlegen. Alternativ können Sie die Berechtigung auf 755 (drwxr-xr-x) und einen anderen Benutzer als Besitzer festlegen, sodass die Ordner dennoch für die mssql-Benutzergruppe zugänglich sind. Sie können z.B. einen Ordner namens sslcert unter dem Pfad /var/opt/mssql/ erstellen und das Zertifikat und den privaten Schlüssel speichern, wobei die Berechtigungen für die Dateien auf 600 festgelegt sind, wie im folgenden Beispiel gezeigt.

openssl req -x509 -nodes -newkey rsa:2048 -subj '/CN=mssql.contoso.com' -keyout mssql.key -out mssql.pem -days 365
sudo chown mssql:mssql mssql.pem mssql.key
sudo chmod 600 mssql.pem mssql.key
#Saving the certificate to the certs folder under /etc/ssl/ which has the following permission 755(drwxr-xr-x)
sudo mv mssql.pem /etc/ssl/certs/ drwxr-xr-x
#Saving the private key to the private folder under /etc/ssl/ with permissions set to 755(drwxr-xr-x)
sudo mv mssql.key /etc/ssl/private/

Konfigurieren von SQL Server

systemctl stop mssql-server
sudo cat /var/opt/mssql/mssql.conf
sudo /opt/mssql/bin/mssql-conf set network.tlscert /etc/ssl/certs/mssql.pem
sudo /opt/mssql/bin/mssql-conf set network.tlskey /etc/ssl/private/mssql.key
sudo /opt/mssql/bin/mssql-conf set network.tlsprotocols 1.2
sudo /opt/mssql/bin/mssql-conf set network.forceencryption 0
systemctl restart mssql-server

Registrieren des Zertifikats auf dem Clientcomputer (Windows, Linux oder macOS)

  • Wenn Sie ein von der Zertifizierungsstelle signiertes Zertifikat verwenden, müssen Sie das Zertifizierungsstellenzertifikat (Certificate Authority, CA) anstelle des Benutzerzertifikats auf den Clientcomputer kopieren.

  • Wenn Sie das selbstsignierte Zertifikat verwenden, kopieren Sie die .pem-Datei in die folgenden Ordner bzw. in die Distribution, und führen Sie die Befehle aus, um sie zu aktivieren:

  • Ubuntu: Kopieren Sie das Zertifikat in /usr/share/ca-certificates/, ändern Sie die Erweiterung in .crt, und verwenden Sie dpkg-reconfigure ca-certificates, um dieses als Zertifizierungsstellenzertifikat für das System zu verwenden.

  • RHEL: Kopieren Sie das Zertifikat in /etc/pki/ca-trust/source/anchors/, und verwenden Sie update-ca-trust, um dieses als Zertifizierungsstellenzertifikat für das System zu verwenden.

  • SUSE: Kopieren Sie das Zertifikat in /usr/share/pki/trust/anchors/, und verwenden Sie update-ca-certificates, um dieses als Zertifizierungsstellenzertifikat für das System zu verwenden.

  • Windows: Importieren Sie die .pem-Datei als Zertifikat unter Aktueller Benutzer > Vertrauenswürdige Stammzertifizierungsstellen > Zertifikate.

  • macOS:

    • Kopieren Sie die Zertifikatdatei nach /usr/local/etc/openssl/certs

    • Führen Sie den folgenden Befehl aus, um den Hashwert zu erhalten:

      /usr/local/Cellar/openssl/1.0.2l/openssl x509 -hash -in mssql.pem -noout

    • Benennen Sie das Zertifikat in den Wert um. Beispiel: mv mssql.pem dc2dd900.0 Stellen Sie sicher, dass sich dc2dd900.0 in /usr/local/etc/openssl/certs befindet.

Exemplarische Verbindungszeichenfolgen

Achtung

Verwenden Sie immer ein sicheres Kennwort. Weitere Informationen finden Sie unter Password Policy.

  • SQL Server Management Studio

    Screenshot des Verbindungsdialogs von SQL Server Management Studio.

  • sqlcmd

    sqlcmd -S <sqlhostname> -N -U sa -P '<password>'

  • ADO.NET

    "Encrypt=True; TrustServerCertificate=False;"

  • ODBC

    "Encrypt=Yes; TrustServerCertificate=no;"

  • JDBC

    "encrypt=true; trustServerCertificate=false;"

Häufige Verbindungsfehler

Fehlermeldung Fix
The certificate chain was issued by an authority that is not trusted. Dieser Fehler tritt auf, wenn Clients die Signatur des Zertifikats, das von SQL Server während des TLS-Handshakes angezeigt wird, nicht überprüfen können. Stellen Sie sicher, dass der Client entweder direkt dem SQL Server-Zertifikat vertraut, oder der Zertifizierungsstelle, die das SQL Server-Zertifikat signiert hat.
The target principal name is incorrect. Stellen Sie sicher, dass das Feld „Allgemeiner Name“ auf dem SQL Server-Zertifikat mit dem in der Verbindungszeichenfolge des Clients angegebenen Servernamen übereinstimmt.
An existing connection was forcibly closed by the remote host. Dieser Fehler kann auftreten, wenn der Client die für SQL Server erforderliche TLS-Protokollversion nicht unterstützt. Wenn SQL Server beispielsweise für die Verwendung von TLS 1.2 konfiguriert ist, müssen Sie sicherstellen, dass Ihre Clients auch das TLS 1.2-Protokoll unterstützen.

Ubuntu 20.04 und andere aktuelle Linux-Distributionsversionen

Symptom

Wenn eine SQL Server für Linux-Instanz ein Zertifikat lädt, das mit einem Signaturalgorithmus mit weniger als 112 Bits Sicherheit erstellt wurde (z. B. MD5, SHA-1), kann ein Verbindungsfehler auftreten, wie in diesem Beispiel:

Eine Verbindung mit dem Server wurde erfolgreich hergestellt, aber dann trat während des Anmeldevorgangs ein Fehler auf. (Anbieter: SSL-Anbieter, Fehler: 0 – Eine vorhandene Verbindung wurde vom Remotehost zwangsweise geschlossen.) (Microsoft SQL Server, Fehler: 10054)

Der Fehler ist darauf zurückzuführen, dass unter Ubuntu 20.04 und höheren Versionen standardmäßig die OpenSSL-Sicherheitsstufe 2 aktiviert ist. Die Sicherheitsstufe 2 verhindert die Einrichtung von TLS-Verbindungen mit weniger als 112 Bits Sicherheit.

Lösung

Installieren Sie ein Zertifikat mit einem Signaturalgorithmus mit mindestens 112 Bits Sicherheit. Signaturalgorithmen, die diese Anforderung erfüllen: SHA-224, SHA-256, SHA-384 und SHA-512.