Verwenden der Verschlüsselung ohne Überprüfung im systemeigenen SQL Server-Client
Gilt für: 
SQL Server Azure SQL-Datenbank Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)
Wichtig
SQL Server Native Client (SNAC) wird nicht ausgeliefert mit:
- SQL Server 2022 (16.x) und höhere Versionen
- SQL Server Management Studio 19 und spätere Versionen
Der SQL Server Native Client (SQLNCLI oder SQLNCLI11) und der Microsoft OLE DB-Legacyanbieter für SQL Server (SQLOLEDB) werden für neue Anwendungsentwicklungen nicht empfohlen.
Für neue Projekte verwenden Sie einen der folgenden Treiber:
Informationen zu SQLNCLI, das als Komponente der SQL Server-Datenbank-Engine (Versionen 2012 bis 2019) verfügbar ist, finden Sie in dieser Ausnahme für den Supportlebenszyklus.
SQL Server verschlüsselt stets Netzwerkpakete, die mit der Anmeldung verbunden sind. Wenn auf dem Server beim Start kein Zertifikat bereitgestellt wird, erstellt SQL Server ein selbstsigniertes Zertifikat, mit dem Anmeldungspakete verschlüsselt werden.
Bei selbstsignierten Zertifikaten kann die Sicherheit nicht garantiert werden. Der verschlüsselte Handshake basiert auf dem Windows NT-LAN-Manager (NTLM). Sie sollten für eine sichere Konnektivität unbedingt ein verifizierbares Zertifikat für SQL Server bereitstellen. Transport Layer Security (TLS) kann nur mit einer Zertifikatüberprüfung gesichert werden.
Anwendungen erfordern möglicherweise auch die Verschlüsselung des gesamten Netzwerkdatenverkehrs mit Verbindungszeichenfolgenschlüsselwörtern oder Verbindungseigenschaften. Die Schlüsselwörter sind "Verschlüsseln" für ODBC und OLE DB bei Verwendung einer Anbieterzeichenfolge mit IDbInitialize::Initialize oder "Use Encryption for Data" für ADO und OLE DB bei Verwendung einer Initialisierungszeichenfolge mit IDataInitialize. Dies kann auch durch SQL Server-Konfigurations-Manager mithilfe der Option "Protokollverschlüsselung erzwingen" konfiguriert werden und den Client so konfigurieren, dass verschlüsselte Verbindungen angefordert werden. Standardmäßig ist für die Verschlüsselung des Netzwerkverkehrs für eine Verbindung die Bereitstellung eines Zertifikats auf dem Server erforderlich. Wenn Sie festlegen, dass Ihr Client dem Zertifikat auf dem Server vertraut, werden Sie möglicherweise anfällig für Man-in-the-Middle-Angriffe. Wenn Sie ein verifizierbares Zertifikat auf dem Server bereitstellen, sollten Sie die Vertrauenseinstellungen des Clients für das Zertifikat in FALSE ändern.
Informationen zu Verbindungszeichenfolge Schlüsselwörtern finden Sie unter Verwenden von Verbindungszeichenfolgenstichwörtern mit SQL Server Native Client.
Um die Verschlüsselung zu aktivieren, die verwendet werden soll, wenn ein Zertifikat nicht auf dem Server bereitgestellt wurde, können SQL Server-Konfigurations-Manager verwendet werden, um sowohl die Optionen "Protokollverschlüsselung erzwingen" als auch die Optionen "Trust Server Certificate" festzulegen. In diesem Fall wird bei der Verschlüsselung ein selbstsigniertes Serverzertifikat ohne Überprüfung verwendet, wenn kein überprüfbares Zertifikat auf dem Server bereitgestellt wurde.
Anwendungen können auch das Schlüsselwort "TrustServerCertificate" oder das zugeordnete Verbindungsattribut verwenden, um sicherzustellen, dass eine Verschlüsselung durchgeführt wird. Anwendungseinstellungen verringern niemals die Vom SQL Server-Clientkonfigurations-Manager festgelegte Sicherheitsstufe, können sie jedoch stärken. Wenn beispielsweise Protokollverschlüsselung erzwingen nicht für den Client festgelegt ist, kann eine Anwendung die Verschlüsselung selbst anfordern. Um die Verschlüsselung sicherzustellen, selbst wenn kein Serverzertifikat bereitgestellt wurde, kann eine Anwendung die Verschlüsselung und "TrustServerCertificate" anfordern. Wenn "TrustServerCertificate" nicht in der Clientkonfiguration aktiviert ist, ist dennoch die Bereitstellung eines Serverzertifikats erforderlich. In der folgenden Tabelle werden alle Fälle beschrieben:
| Protokollverschlüsselung erzwingen - Clienteinstellung | Dem Serverzertifikat vertrauen | Verbindungszeichenfolge-/Verbindungsattribut 'Verschlüsseln/Verschlüsselung für Daten verwenden' | Verbindungszeichenfolge/Verbindungsattribut 'Dem Serverzertifikat vertrauen' | Ergebnis |
|---|---|---|---|---|
| Nein | N/V | Nein (Standard) | Wird ignoriert. | Keine Verschlüsselung. |
| Nein | N/V | Ja | Nein (Standard) | Eine Verschlüsselung findet nur statt, wenn ein überprüfbares Serverzertifikat vorliegt, anderenfalls schlägt der Verbindungsversuch fehl. |
| Nein | N/V | Ja | Ja | Verschlüsselung wird immer durchgeführt, es wird jedoch z. B. ein selbstsigniertes Serverzertifikat verwendet. |
| Ja | Nein | Wird ignoriert. | Wird ignoriert. | Eine Verschlüsselung findet nur statt, wenn ein überprüfbares Serverzertifikat vorliegt, anderenfalls schlägt der Verbindungsversuch fehl. |
| Ja | Ja | Nein (Standard) | Wird ignoriert. | Verschlüsselung wird immer durchgeführt, es wird jedoch z. B. ein selbstsigniertes Serverzertifikat verwendet. |
| Ja | Ja | Ja | Nein (Standard) | Eine Verschlüsselung findet nur statt, wenn ein überprüfbares Serverzertifikat vorliegt, anderenfalls schlägt der Verbindungsversuch fehl. |
| Ja | Ja | Ja | Ja | Verschlüsselung wird immer durchgeführt, es kann jedoch ein selbstsigniertes Serverzertifikat verwendet werden. |
Achtung
In der obigen Tabelle finden Sie lediglich einen Leitfaden für das Systemverhalten unter verschiedenen Konfigurationen. Für eine sichere Konnektivität müssen Sie dafür sorgen, dass sowohl der Client als auch der Server die Verschlüsselung erzwingen. Sorgen Sie außerdem dafür, dass der Server über ein verifizierbares Zertifikat verfügt und dass die Einstellung TrustServerCertificate für den Client auf FALSE festgelegt ist.
SQL Server Native Client OLE DB-Anbieter
Der OLE DB-Anbieter von SQL Server Native Client unterstützt die Verschlüsselung ohne Überprüfung durch das Hinzufügen der SSPROP_INIT_TRUST_SERVER_CERTIFICATE-Eigenschaft zur Datenquelleninitialisierung, die im DBPROPSET_SQLSERVERDBINIT-Eigenschaftensatz implementiert wird. Darüber hinaus wurde ein neues Verbindungszeichenfolgeschlüsselwort, „TrustServerCertificate“, hinzugefügt. Gültig sind die Werte YES oder NO, wobei NO die Standardeinstellung ist. Wenn Dienstkomponenten verwendet werden, sind die Werte "true" und "false" gültig, wobei "false" die Standardeinstellung ist.
Weitere Informationen zu Verbesserungen am DBPROPSET_SQLSERVERDBINIT-Eigenschaftensatz finden Sie unter Initialisierungs- und Autorisierungseigenschaften.
ODBC-Treiber für SQL Server Native Client
Der ODBC-Treiber für SQL Server Native Client unterstützt die Verschlüsselung ohne Überprüfung durch Ergänzungen der Funktionen SQLSetConnectAttr und SQLGetConnectAttr . SQL_COPT_SS_TRUST_SERVER_CERTIFICATE wurde hinzugefügt, um entweder SQL_TRUST_SERVER_CERTIFICATE_YES oder SQL_TRUST_SERVER_CERTIFICATE_NO anzunehmen, wobei SQL_TRUST_SERVER_CERTIFICATE_NO die Standardeinstellung ist. Darüber hinaus wurde ein neues Verbindungszeichenfolgeschlüsselwort, "TrustServerCertificate", hinzugefügt. Gültig sind die Werte "Ja" oder "Nein", wobei "Nein" die Standardeinstellung ist.