Verschlüsselung und Zertifikatsüberprüfung in Microsoft.Data.SqlClient

Herunterladen von ADO.NET

Verwenden Sie Transport Layer Security (TLS), um den Datenverkehr zwischen Ihrer Anwendung und dem SQL Server zu verschlüsseln. Lassen Sie die Serverzertifikatsvalidierung aktiviert, um die Identität des Servers zu überprüfen. Verschlüsselung ohne Identitätsvalidierung schützt nicht vor einem Gegner in der Mitte , der sich als Server ausgibt.

Microsoft. Data.SqlClient setzt standardmäßig auf Encrypt=Mandatory und TrustServerCertificate=false. Encrypt=true ist ein Synonym für Mandatory. Für eine entfernte Verbindung fordern Sie diese Einstellungen ausdrücklich an und stellen Sie ein Serverzertifikat bereit, das der Client validieren kann:

Server=tcp:<server>,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;

Ersetzen Sie die Platzhalter und verwenden Sie eine Authentifizierungsmethode , die von Ihrem Server und Ihrer Anwendungsumgebung unterstützt wird. Für Azure SQL oder SQL-Datenbanken in Microsoft Fabric siehe Microsoft Entra Authentifizierung.

Wählen Sie einen Verschlüsselungsmodus

Encrypt kontrolliert, ob der Client eine Verschlüsselung benötigt. Ein Server kann auch eine Verschlüsselung erfordern. Diese Tabelle beschreibt das aktuelle Verhalten ohne Zertifikats-Pinning:

Verwenden Sie Mandatory für verschlüsselte Verbindungen zu Servern, die TDS 8.0 nicht unterstützen. Verwenden Strict Sie, wenn Ihr Endpunkt TDS 8.0 unterstützt, einschließlich SQL Server 2022 (16.x) und neueren Versionen. TDS 8.0 unterstützt TLS 1.2 und TLS 1.3; es benötigt kein TLS 1.3. Die ausgehandelte TLS-Version hängt auch von der Konfiguration des Clients, des Servers und Betriebssystems ab.

Optional ist kein Mittel gegen Zertifikatsfehler. Es kann Anwendungsdaten unverschlüsselt lassen, wenn der Server keine Verschlüsselung benötigt.

Konfigurieren Sie ein verifizierbares Serverzertifikat

Zur normalen Zertifikatsvalidierung:

1. Stellen Sie ein Zertifikat bereit, das die Anforderungen des SQL Server-Zertifikats erfüllt.
2. Fügen Sie den Namen, den die Clients zur Verbindung verwenden, in den jeweiligen alternativen Namen (SAN) des Zertifikats ein.
3. Machen Sie die ausstellende Zertifizierungsstelle und alle erforderlichen Zwischenzertifikate auf jedem Client-Host oder Container vertrauenswürdig.
4. Konfigurieren Sie den SQL Server so, dass er das Zertifikat verwendet, und behalten Sie TrustServerCertificate=false in Clients bei.
5. Erneuerung des Planzertifikats vor Ablauf, einschließlich aller Änderungen an Namen oder ausstellenden Befugnissen.

Ein Zertifikat einer öffentlichen oder unternehmensrechtlichen Zertifizierungsstelle kann diese Anforderungen erfüllen. Ein Unternehmenszertifikat wird in einem Linux-Container oder auf einem separaten Entwicklercomputer nicht automatisch als vertrauenswürdig eingestuft.

Verbinden Sie sich über einen Alias

Wenn die Verbindung ein Domain Name System (DNS)-Alias verwendet, das nicht im Zertifikat ist, sollten Sie zunächst ein Zertifikat ausstellen, das das Alias enthält. Alternativ setzen Sie HostNameInCertificate auf den erwarteten Namen im Zertifikat:

Server=tcp:sql-alias.contoso.com,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;HostNameInCertificate=sql-server.contoso.com;MultiSubnetFailover=true;

HostNameInCertificate ändert den Namen, den SqlClient während der Zertifikatsvalidierung erwartet. Es ändert nicht das Netzwerkziel und umgeht keine Vertrauensketten- und Ablaufprüfungen. Lass es undeaktiviert, wenn der Servername bereits mit dem Zertifikat übereinstimmt.

Pinne ein bestimmtes Serverzertifikat

ServerCertificate stellt eine lokale Zertifikatsdatei zur genauen Vergleichsweise mit dem Zertifikat des Servers bereit. Unterstützte Formate sind Privacy-Enhanced Mail (PEM) und Distinguished Encoding Rules (DER), einschließlich .cer Zertifikatsdateien. Verwenden Sie es mit Encrypt=Mandatory oder Encrypt=Strict, und behalten Sie TrustServerCertificate=false bei.

Server=tcp:<server>,1433;Database=<database>;Integrated Security=true;Encrypt=Strict;TrustServerCertificate=false;ServerCertificate=C:\certificates\sql-server.cer;MultiSubnetFailover=true;

Verteilt das erwartete Zertifikat über einen vertrauenswürdigen Kanal und schützt die Datei vor Austausch. Eine exakte Zertifikatsübereinstimmung ist eine Alternative zur normalen Ketten- und Namensvalidierung, keine zusätzliche, darauf aufsetzende Kontrolle. Die Zertifikatsbytes müssen übereinstimmen; derselbe Subjektname oder der öffentliche Schlüssel allein reicht nicht aus. Eine fehlende, unlesbare, ungültige oder nicht übereinstimmende PIN-Datei scheitert bei der Validierung.

Pinning macht die Bereitstellung des Clients von der Zertifikatsrotation abhängig. Aktualisieren Sie die PIN, wenn sich das Serverzertifikat ändert, einschließlich der Verlängerung. Erhalte keine PIN, indem du ein unverifiziertes Zertifikat aus dem Netzwerk annimmst.

SqlClient stellt keinen öffentlichen Rückruf für beliebige TLS-Serverzertifikatsvalidierung bereit. AccessTokenCallback kontrolliert die Erfassung von Authentifizierungstokens, nicht die TLS-Validierung.

Entwicklungszertifikate und Fehlerbehebung

Verwenden Sie ein vertrauenswürdiges Entwicklungszertifikat mit dem korrekten Servernamen. Wenn du Encrypt=true vorübergehend mit TrustServerCertificate=true in einer isolierten Entwicklungsumgebung verwendest, ist die Verbindung verschlüsselt, aber der Client überprüft das Serverzertifikat nicht.

Für die serverseitige Konfiguration siehe Zertifikatsübersicht.

Änderungen beim Verschlüsselungs- und Zertifikatsüberprüfungsverhalten

Diese Kompatibilitätshinweise erklären Verhaltensänderungen beim Upgrade älterer Anwendungen. Neue Anwendungen sollten die in diesem Artikel beschriebenen aktuellen Einstellungen verwenden.

Verwandte Inhalte

• Verbindungsstrings in ADO.NET
• Syntax der Verbindungszeichenfolge
• Bewährte Methoden für Sicherheit