Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:
SQL ServerAzure SQL-DatenbankAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics 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 beim Starten kein Zertifikat auf dem Server bereitgestellt wurde, generiert SQL Server ein selbstsigniertes Zertifikat, das zum Verschlüsseln von Anmeldepaketen verwendet wird.
Bei selbstsignierten Zertifikaten kann die Sicherheit nicht garantiert werden. Der verschlüsselte Handshake basiert auf dem Windows NT-LAN-Manager (NTLM). Sie sollten ein überprüfbares Zertifikat auf SQL Server für sichere Konnektivität bereitstellen. Transport Layer Security (TLS) kann nur mit einer Zertifikatüberprüfung gesichert werden.
Anwendungen können auch die Verschlüsselung aller Netzwerkdatenverkehre anfordern, indem Verbindungszeichenfolgenstichwörter oder Verbindungseigenschaften verwendet werden. 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 von SQL Server Configuration Manager mithilfe der Option " Protokollverschlüsselung erzwingen " konfiguriert werden, und durch Konfigurieren des Clients, um verschlüsselte Verbindungen anzufordern. Standardmäßig erfordert die Verschlüsselung aller Netzwerkdatenverkehre für eine Verbindung, dass ein Zertifikat auf dem Server bereitgestellt wird. Indem Sie Ihren Client so festlegen, dass dem Zertifikat auf dem Server vertraut wird, sind Sie anfällig für Man-in-the-Middle-Angriffe. Wenn Sie ein überprüfbares Zertifikat auf dem Server bereitstellen, stellen Sie sicher, dass Sie die Clienteinstellungen zum Vertrauen des Zertifikats ändern.FALSE
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 wird, kann SQL Server Configuration Manager verwendet werden, um die Optionen für die Force Protocol Encryption und die Trust Server Certificate-Optionen festzulegen. In diesem Fall verwendet die Verschlüsselung ein selbstsigniertes Serverzertifikat ohne Überprüfung, wenn kein überprüfbares Zertifikat auf dem Server bereitgestellt wurde.
Anwendungen können auch das TrustServerCertificate Schlüsselwort oder das zugehörige Verbindungsattribute verwenden, um sicherzustellen, dass die Verschlüsselung stattfindet. Anwendungseinstellungen verringern niemals die Sicherheitsstufe, die von SQL Server Client Configuration Manager festgelegt wurde, könnte sie jedoch stärken. Wenn z. B. die Force-Protokollverschlüsselung für den Client nicht festgelegt ist, kann eine Anwendung die Verschlüsselung selbst anfordern. Um die Verschlüsselung zu gewährleisten, auch wenn kein Serverzertifikat bereitgestellt wird, kann eine Anwendung Verschlüsselung anfordern und TrustServerCertificate. Wenn jedoch TrustServerCertificate in der Clientkonfiguration nicht aktiviert wird, ist immer noch ein bereitgestelltes Serverzertifikat 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) | Die Verschlüsselung erfolgt nur, wenn ein überprüfbares Serverzertifikat vorhanden ist. Andernfalls schlägt der Verbindungsversuch fehl. |
| Nein | N/V | Ja | Ja | Verschlüsselung wird immer durchgeführt, es kann jedoch ein selbstsigniertes Serverzertifikat verwendet werden. |
| Ja | Nein | Wird ignoriert. | Wird ignoriert. | Die Verschlüsselung erfolgt nur, wenn ein überprüfbares Serverzertifikat vorhanden ist. Andernfalls schlägt der Verbindungsversuch fehl. |
| Ja | Ja | Nein (Standard) | Wird ignoriert. | Verschlüsselung wird immer durchgeführt, es kann jedoch ein selbstsigniertes Serverzertifikat verwendet werden. |
| Ja | Ja | Ja | Nein (Standard) | Die Verschlüsselung erfolgt nur, wenn ein überprüfbares Serverzertifikat vorhanden ist. Andernfalls 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. Stellen Sie für die sichere Konnektivität sicher, dass sowohl der Client als auch der Server verschlüsselung erforderlich sind. 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 Datenquelleninitialisierungseigenschaft, die im DBPROPSET_SQLSERVERDBINIT Eigenschaftensatz implementiert wird. Darüber hinaus wurde ein neues Verbindungszeichenfolgen-Schlüsselwort TrustServerCertificatehinzugefügt. Sie akzeptiert yes oder no Werte; no ist der Standardwert. Wenn Dienstkomponenten verwendet werden, akzeptiert true oder false werte; false ist die Standardeinstellung.
Weitere Informationen zu Verbesserungen am Eigenschaftensatz finden Sie unter Initialisierungs- und Autorisierungseigenschaften (Native Client OLE DB Provider).For more information about enhancements made to the DBPROPSET_SQLSERVERDBINIT property set, see Initialization and Authorization Properties (Native Client OLE DB Provider).
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, wobei SQL_TRUST_SERVER_CERTIFICATE_NO es sich um die Standardeinstellung handelt. Darüber hinaus wurde ein neues Verbindungszeichenfolgen-Schlüsselwort TrustServerCertificatehinzugefügt. Sie akzeptiert yes oder no Werte; no ist der Standardwert.