Freigeben über

Transport Layer Security und digitale Zertifikate

  • Artikel

In diesem Artikel werden Details zu TLS (Transport Layer Security) und digitalen Zertifikaten beschrieben.

Transport Layer Security (TLS)

TLS- und SSL-Protokoll befinden sich zwischen der Anwendungsprotokollebene und der TCP/IP-Ebene, wo sie Anwendungsdaten schützen und an die Transportebene senden können. TLS- und SSL-Protokoll verwenden Algorithmen einer Verschlüsselungssammlung zum Erstellen von Schlüsseln und Verschlüsseln von Informationen. Client und Server handeln die Protokollversion und die Verschlüsselungssammlung aus, die während der ersten Verbindungsphase (vor der Anmeldung) der Verbindungsherstellung für die Verschlüsselung verwendet werden sollen. Im TLS-Handshake wird immer die höchste unterstützte TLS-Version bevorzugt. Informationen zum Überprüfen der TLS-Protokollversionen, die von verschiedenen Versionen von Windows-Betriebssystemen unterstützt werden, finden Sie unter Protokolle in TLS/SSL (Schannel SSP). Es gibt mehrere bekannte Sicherheitsrisiken bei SSL und früheren TLS-Versionen. Für eine sichere Kommunikation sollten Sie ein Upgrade auf TLS 1.2 durchführen.

SQL Server kann TLS zum Verschlüsseln der Daten verwenden, die über ein Netzwerk zwischen einer Clientanwendung und einer Instanz von SQL Server übertragen werden. TLS verwendet ein Zertifikat, um die Verschlüsselung zu implementieren.

Das Aktivieren der TLS-Verschlüsselung erhöht die Sicherheit von Daten, die netzwerkübergreifend zwischen Instanzen von SQL Server und Anwendungen übertragen werden. Wenn der gesamte Datenverkehr jedoch zwischen SQL Server und einer Clientanwendung mithilfe von TLS verschlüsselt wird, sind die folgenden zusätzlichen Verarbeitungsschritte erforderlich:

  • Ein zusätzlicher Netzwerkroundtrip ist zum Zeitpunkt des Verbindungsaufbaus erforderlich.
  • Die von der Anwendung an die SQL Server-Instanz gesendeten Pakete müssen vom Client-TLS-Stapel verschlüsselt und vom Server-TLS-Stapel entschlüsselt werden.
  • Die von der Instanz von SQL Server an die Anwendung gesendeten Pakete müssen vom Server-TLS-Stapel verschlüsselt und vom Client-TLS-Stapel entschlüsselt werden.

Wichtig

Seit SQL Server 2016 (13.x) wird Secure Sockets Layer (SSL) nicht mehr unterstützt. Verwenden Sie stattdessen TLS (TLS 1.2 wird empfohlen). Weitere Informationen finden Sie unter TLS 1.2-Unterstützung für Microsoft SQL Server (KB3135244). Mit SQL Server 2022 wird die Unterstützung für TLS 1.3 eingeführt. Weitere Informationen finden Sie unter TLS 1.3-Unterstützung. Wenn keine übereinstimmenden Protokolle zwischen dem Client- und Servercomputer vorhanden sind, kann der unter Schließen einer vorhandenen Verbindung wurde vom Remotehost erzwungen (Betriebssystemfehler 10054) beschriebene Fehler auftreten.

Übersicht über digitale Zertifikate

Digitale Zertifikate sind elektronische Dateien, die wie ein Online-Kennwort zum Überprüfen der Identität eines Benutzers oder Computers funktionieren. Sie dienen dazu, den verschlüsselten Kanal zu erstellen, der für die Clientkommunikation verwendet wird. Ein Zertifikat ist eine digitale Anweisung, die von einer Zertifizierungsstelle (ZS) ausgestellt wird, die für die Identität des Zertifikatinhabers bürgt und den Parteien eine sichere Kommunikation durch Verschlüsselung ermöglicht.

Digitale Zertifikate bieten die folgenden Dienste:

  • Verschlüsselung: Sie helfen dabei, die ausgetauschten Daten vor Diebstahl oder Manipulation zu schützen.
  • Authentifizierung: Sie prüfen, ob ihre Inhaber (Personen, Websites und sogar Netzwerkgeräte wie z. B. Router) wirklich sind, wer/was sie zu sein vorgeben. In der Regel erfolgt die Authentifizierung unidirektional, wobei die Quelle die Identität des Ziels überprüft, aber auch eine gegenseitige TLS-Authentifizierung möglich ist.

Ein Zertifikat enthält einen öffentlichen Schlüssel und fügt diesen öffentlichen Schlüssel an die Identität einer Person, eines Computers oder eines Dienstes an, der den entsprechenden privaten Schlüssel enthält. Die öffentlichen und privaten Schlüssel werden vom Client und Server verwendet, um die Daten zu verschlüsseln, bevor sie übertragen werden. Für Windows-Benutzer, -Computer und -Dienste wird die Vertrauensstellung in der Zertifizierungsstelle hergestellt, wenn das Stammzertifikat im Speicher vertrauenswürdiger Stammzertifikate definiert ist und das Zertifikat einen gültigen Zertifizierungspfad enthält. Ein Zertifikat gilt als gültig, wenn es nicht widerrufen wurde (es befindet sich nicht in der Zertifikatssperrliste oder der Zertifikatssperrliste der Zertifizierungsstelle) oder abgelaufen ist.

Die drei primären Typen digitaler Zertifikate werden in der folgenden Tabelle beschrieben:

type BESCHREIBUNG Vorteile Nachteile
Selbstsigniertes Zertifikat Das Zertifikat wird von der Anwendung signiert, die es erstellt hat, oder mithilfe von New-SelfSignedCertificate erstellt. Kosten (kostenlos) - Das Zertifikat wird von Clientcomputern und mobilen Geräten nicht automatisch als vertrauenswürdig eingestuft. Das Zertifikat muss auf allen Clientcomputern und Geräten manuell dem Speicher vertrauenswürdiger Stammzertifikate hinzugefügt werden, aber nicht alle mobilen Geräte lassen Änderungen am Speicher vertrauenswürdiger Stammzertifikate zu.

- Nicht alle Dienste funktionieren mit selbstsignierten Zertifikaten.

- Es ist schwierig, eine Infrastruktur für die Verwaltung des Zertifikatlebenszyklus einzurichten. Beispielsweise können selbstsignierte Zertifikate nicht widerrufen werden.
Durch eine interne Zertifizierungsstelle ausgestelltes Zertifikat Das Zertifikat wird von einer Public Key-Infrastruktur (PKI) in Ihrer Organisation ausgestellt. Ein Beispiel sind die Active Directory-Zertifikatdienste (AD CS). Weitere Informationen finden Sie unter Active Directory-Zertifikatdienste (Übersicht). - Ermöglichen Organisationen, ihre eigenen Zertifikate auszustellen.

- Kostengünstiger als Zertifikate einer kommerziellen Zertifizierungsstelle.		 - Erhöhte Komplexität beim Bereitstellen und Verwalten der PKI.

- Das Zertifikat wird von Clientcomputern und mobilen Geräten nicht automatisch als vertrauenswürdig eingestuft. Das Zertifikat muss auf allen Clientcomputern und Geräten manuell dem Speicher vertrauenswürdiger Stammzertifikate hinzugefügt werden, aber nicht alle mobilen Geräte lassen Änderungen am Speicher vertrauenswürdiger Stammzertifikate zu.
Von einer kommerziellen ZS ausgestelltes Zertifikat Das Zertifikat wird von einer vertrauenswürdigen kommerziellen ZS erworben. Die Zertifikatbereitstellung wird vereinfacht, da alle Clients, Geräte und Server den Zertifikaten automatisch vertrauen. Kosten: Sie müssen vorausplanen, um die Anzahl der erforderlichen Zertifikate zu minimieren.

Um zu beweisen, dass ein Zertifikatinhaber ist, wer er zu sein vorgibt, muss das Zertifikat den Zertifikatinhaber bei anderen Clients, Geräten oder Servern genau identifizieren. Die drei grundlegenden Methoden hierzu werden in der folgenden Tabelle beschrieben:

Methode BESCHREIBUNG Vorteile Nachteile
Zertifikatsantragstellerabgleich Das Feld Antragsteller des Zertifikats enthält den allgemeinen Namen (Common Name, CN) des Hosts. Beispielsweise kann das für www.contoso.com ausgestellte Zertifikat für die Website https://www.contoso.com verwendet werden. - Kompatibel mit allen Clients, Geräten und Diensten.

- Abschottung. Das Widerrufen des Zertifikats für einen Host wirkt sich nicht auf andere Hosts aus.		 - Anzahl der erforderlichen Zertifikate. Sie können das Zertifikat nur für den angegebenen Host verwenden. Beispielsweise können Sie das www.contoso.com-Zertifikat auch dann nicht für ftp.contoso.com verwenden, wenn die Dienste auf demselben Server installiert sind.

- Komplexität. Auf einem Webserver erfordert jedes Zertifikat eine eigene IP-Adressbindung.
Abgleich mit alternativem Antragstellernamen (Subject Alternative Name, SAN) Zusätzlich zum Feld Antragsteller enthält das Feld Alternativer Antragstellername des Zertifikats eine Liste mit mehreren Hostnamen. Zum Beispiel:
www.contoso.com
ftp.contoso.com
ftp.eu.fabirkam.net		 - Benutzerfreundlichkeit. Sie können dasselbe Zertifikat für mehrere Hosts in mehreren separaten Domänen verwenden.

- Die meisten Clients, Geräte und Dienste unterstützen SAN-Zertifikate.

- Überwachung und Sicherheit. Sie wissen genau, welche Hosts das SAN-Zertifikat verwenden können.		 - Mehr Planung erforderlich. Sie müssen die Liste der Hosts angeben, wenn Sie das Zertifikat erstellen.

- Mangelnde Abschottung. Sie können Zertifikate für einige der angegebenen Hosts nicht selektiv widerrufen, ohne dass sich dies auf alle Hosts im Zertifikat auswirkt.
Platzhalterzertifikatabgleich Das Feld Antragsteller des Zertifikats enthält den allgemeinen Namen als Platzhalterzeichen (*) sowie eine einzelne Domäne oder Unterdomäne. Zum Beispiel: *.contoso.com oder *.eu.contoso.com. Das *.contoso.com-Platzhalterzertifikat kann für Folgendes verwendet werden:
www.contoso.com
ftp.contoso.com
mail.contoso.com		 Flexibilität. Sie müssen keine Liste der Hosts angeben, wenn Sie das Zertifikat anfordern, und Sie können das Zertifikat auf einer beliebigen Anzahl von Hosts verwenden, die Sie in Zukunft möglicherweise benötigen. - Sie können keine Platzhalterzertifikate mit anderen Domänen der obersten Ebene (TLDs) verwenden. Beispielsweise können Sie das *.contoso.com-Platzhalterzertifikat nicht für *.contoso.net-Hosts verwenden.

- Sie können Platzhalterzertifikate nur für Hostnamen auf der Ebene des Platzhalters verwenden. Beispielsweise können Sie das *.contoso.com-Zertifikat nicht für www.eu.contoso.com verwenden. Sie können auch nicht das *.eu.contoso.com-Zertifikat für www.uk.eu.contoso.com verwenden.

- Ältere Clients, Geräte, Anwendungen oder Dienste unterstützen möglicherweise keine Platzhalterzertifikate.

- Mit EV-Zertifikaten (Extended Validation) sind keine Platzhalter verwendbar.

- Sorgfältige Überwachung und Kontrolle sind erforderlich. Wenn das Platzhalterzertifikat kompromittiert ist, wirkt sich dies auf jeden Host in der angegebenen Domäne aus.

Zugehöriger Inhalt