Überprüfen der Exchange Server-SSL-Konfigurationsoptionen

Die meisten Exchange-Organisationen verbringen viel Zeit damit, ihren Namespace, ihr SSL-Zertifikat, ihren Lastenausgleich und …

Reverse-Proxy-Optionen, aber nur wenige denken so viel über die verschiedenen Optionen für die Exchange-SSL-Bereitstellung nach. Das Verständnis der drei SSL-Optionen trägt wesentlich dazu bei, die richtige Entscheidung für Ihre Bereitstellung zu treffen.
Als alle Benutzer Exchange 2003 verwendeten, war SSL noch eine optionale – wenn auch empfohlene – Konfigurationsalternative für Organisationen, die Exchange für den Zugriff auf externe Clients veröffentlichen wollten. Mit dem heutigen modernen Internet ist SSL jedoch nicht mehr optional.
Secure Sockets Layer (SSL) und sein Cousin Transport Layer Security werden standardmäßig verwendet, um alle Client-zu-Server- und Server-zu-Server-Protokollsitzungen nach Möglichkeit zu sichern, es sei denn, das Protokoll bietet einen eigenen Sicherheitsmechanismus wie MAPI-RPC- oder RPC-Verschlüsselung.

Exchange Server SSL-Konfigurationsoptionen

Abbildung 1. Hier sehen Sie Ihre drei Exchange Server SSL-Konfigurationsoptionen.

Anstatt blindlings einem Konfigurationshandbuch zu folgen, das Ihrer spezifischen Exchange-Organisation möglicherweise die optimalen Vorteile bietet oder nicht, hilft Ihnen das Verständnis Ihrer SSL-Optionen bei der Auswahl der richtigen Lösung für den Lastenausgleich und den Reverse-Proxy.
Ihre drei SSL-Optionen sind Pass-Through, Offload und Bridging (Abbildung 1).
Jede dieser Optionen beschreibt die spezifische SSL-Sitzung. Nehmen wir für diesen Tipp an, dass zwischen dem öffentlichen Internet und Ihren Exchange-Servern mindestens eine Firewall besteht. Darüber hinaus sollten alle Exchange-Server gemäß den Supportgrenzen von Microsoft in geschützten internen Netzwerken platziert werden.

Exchange SSL Option 1: SSL-Pass-Through

SSL-Pass-Through ist die einfachste Option. Bei der Konfiguration fängt SSL Pass-Through die SSL-Sitzungen auf Netzwerkgeräten nicht ab, bevor sie die CAS-Rolle (Client Access Server) erreichen. Die Pass-Through-Option ist normalerweise nur für kleinere Exchange-Bereitstellungen mit wenigen Verbindungen geeignet.
SSL-Pass-Through gibt es in zwei Varianten: Eine, bei der eine Organisation keinen Lastausgleich oder einen Reverse-Proxy verwendet, und eine andere, bei der beide verwendet werden. Die spezifische Lastausgleichsoption spielt keine Rolle. Dies kann Windows Network Load Balancing, eine Microsoft Forefront Threat Management Gateway Server-Bereitstellung oder ein Hardware Load Balancer (HLB) sein. Der Nachteil ist, dass die beste IP-Adresse der eingehenden Verbindung die beste Lastausgleichsfunktion ist.
Dies ist in Exchange Server 2013 kein Problem, da diese Option der Typ des Layer 4-Lastausgleichs ist, mit dem Exchange 2013 arbeiten soll. Bei Exchange 2007 und Exchange 2010 kann die SSL-Weiterleitung jedoch abhängig von Ihren spezifischen Verkehrsmustern zu ungleichmäßigem Datenverkehr zu Ihren CAS-Rollen führen. Um die Last in Exchange 2007 oder Exchange 2010 gleichmäßig zu verteilen, benötigen Sie einen Layer 7 HLB oder Reverse Proxy, der eine der beiden nächsten Optionen verwendet.

Exchange SSL Option 2: SSL-Offload

SSL-Offload, im Allgemeinen als SSL-Terminierung bezeichnet, leitet eingehende SSL-Verbindungen an das Proxy-Gerät (HLB oder Reverse Proxy) weiter, das mit dem SSL-Zertifikat und dem privaten Schlüssel konfiguriert ist, um die SSL-Sitzung zu entschlüsseln.
Der Proxy hat dann vollen Zugriff auf die Protokollnutzdaten und kann die Sitzung vorauthentifizieren, präzise Header für den Lastausgleich einfügen und vieles mehr, bevor die Sitzung über ein Nicht-SSL-Protokoll mit Exchange verbunden wird.
SSL-Offload ist aus zwei Gründen nützlich: Erstens können Sicherheitssysteme den Netzwerkstrom zwischen dem Proxy und Exchange Server überprüfen. Zweitens wird der CPU-Overhead von entfernt SSL-Entschlüsselung auf Ihren Exchange-Servern.
Wenn Sie eine 32-Bit-Version von Exchange verwenden, kann sich dieser Overhead als kritisch erweisen. Auf moderner Hardware und Hypervisoren ist es möglich, genügend Prozessorkapazität bereitzustellen, um die Auswirkungen des Overheads auf den billigen Preis zu minimieren.
SSL-Offload hat jedoch die beiden Hauptnachteile:

  • Da der Netzwerkstrom unverschlüsselt ist, kann er sowohl von Sicherheitssystemen als auch von feindlichen Einheiten überprüft werden.
  • Exchange führt standardmäßig kein SSL-Offload durch. Sie müssen SSL für die gewünschten Protokolle deaktivieren und dann das SSL-Offload aktivieren, damit Exchange den Clients weiterhin die richtigen SSL-fähigen URLs sendet.

Exchange SSL Option 3: SSL-Bridging

Die SSL-Überbrückung, die üblicherweise als SSL-Initiierung bezeichnet wird, beginnt mit der SSL-Auslagerung. Eingehende SSL-Verbindungen werden an den Proxy geleitet. Der Proxy verwendet dann das SSL-Zertifikat und den privaten Schlüssel, um die SSL-Sitzung zu entschlüsseln, und ermöglicht dieselben Funktionen zur Verkehrsinspektion. Bei Verwendung der SSL-Überbrückung stellt der Proxy jedoch über ein SSL-geschütztes Protokoll eine Verbindung zu den Exchange-Servern her, um sicherzustellen, dass der Netzwerkstrom zwischen dem Proxy und Exchange sowohl verschlüsselt als auch sicher ist.
Der Hostname und das Zertifikat des Proxys müssen nicht mit denen auf den Exchange-Servern identisch sein. Das Proxy-Gerät erstellt eine neue SSL-Sitzung unabhängig von den vom Client verwendeten Parametern. Diese Flexibilität ermöglicht es Exchange-Administratoren, Hybrid zu implementieren PKI Lösungen, bei denen der Proxy Zertifikate für öffentliche Zertifizierungsstellen verwendet und Exchange-Server interne Zertifikate verwenden.
Durch SSL-Bridging wird der Netzwerkstrom jedoch verschlüsselt, sodass IDS-Anwendungen und andere Sicherheitssysteme den Datenverkehr nicht mehr überprüfen können, sobald er den Proxy verlässt. Wenn sich der Proxy in einem Umkreisnetzwerk befindet, ist dies häufig eine erforderliche Schutzstufe.
Stellen Sie sicher, dass die von Ihnen ausgewählte SSL-Option Ihren spezifischen Anforderungen entspricht. Auf diese Weise wird sichergestellt, dass Ihr Gesamtdesign den Erwartungen entspricht und die Wahrscheinlichkeit unerwarteter Probleme bei Ihrer Exchange Server-Bereitstellung verringert wird.
Über den Autor:
Devin Ganger ist ein Messaging-Architekt und technischer Redakteur mit mehr als 15 Jahren Erfahrung in der Verwaltung von Messaging-Systemen, Windows-, Unix- und TCP / IP-Netzwerken. Heute arbeitet er hauptsächlich mit Exchange Server, Windows Active Directory und verwandten Technologien von Microsoft und Drittanbietern. Ganger wurde von 2007 bis 2011 als Microsoft MVP für Exchange Server anerkannt.

Similar Posts

Leave a Reply