Mit dem Exchange Server 2013 von Microsoft ändert sich auch das Design einer HA Umgebung und dem der Sicherheitssysteme zum Schutz der Groupware-Lösung. Diese Änderungen betreffen nicht nur die Verbindungen der Clients zum Exchange, sondern auch die Exchange-Komponenten selbst. Durch die grundlegend anders funktionierende Kommunikation der „Mitspieler“ muss auch das Sicherheitskonzept entsprechend angepasst werden.
Der Exchange Server 2013 kennt nur noch zwei primäre Server-Typen, den Client Access Server (CAS) und den Mailbox Server. Dazu kommen drei wichtige Änderungen in der Kommunikation:
- SSL Offload und somit Layer 7 LoadBalancing (LB) wird nicht mehr von Microsoft unterstützt. Layer 4 LB ist die einzig unterstütze Methode von Microsoft bei Exchange Server 2013.
- Die Verbindungen eines Client zum CAS sind nun zustandslos, es gibt daher keine Affinität mehr zwischen einem Client, seiner Verbindung und dem CAS.
- Outlook Anywhere oder auch RPC über http(s) ist bei Exchange 2013 die Standardverbindung zwischen Client und Exchange. Das gilt sowohl über WAN als auch im LAN.
Diese Änderungen haben deutliche Auswirkungen auf den Aufbau von HA Exchange-Umgebungen und bringen doch einige Vorteile mit sich. Das Load Balancing an sich wird weniger komplex und durch die zwei primären Server-Typen gilt dies auch für die Microsoft Systeme selbst. Bei der Absicherung der Umgebung ergeben sich aber neue Herausforderungen. War es durch den vorher noch möglichen SSL Offload relativ einfach die eigentlichen Daten zu prüfen, muss man nun andere Wege finden. Vor allem ohne den von Microsoft supporteten Weg zu verlassen.
Da sich mit dem Exchange 2013 quasi alle Verbindungen angefangen bei mobilen Geräten über Outlook Web Access und auch den traditionellen Outlook Clients im LAN, einer https Verbindungen bedienen, wird dem Management und der Sicherheit dieser Verbindung eine wichtige Rolle zu teil. Da auch SSL Offload nicht mehr unterstützt wird, geht Microsoft davon aus, dass es eine Ende-zu-Ende Verschlüsselung zwischen Client und dem Exchange respektive dem CAS gibt. Grundsätzlich ist dies auch der richtige Weg eine TLS abgesicherte Kommunikation zu benutzen. Hier stellt sich nun vom Standpunkt der Sicherheit die Frage, will man die End-zu-Ende Kommunikation tatsächlich aufbrechen und Man-in-the-Middle spielen? Die klare Antwort ist hier leider jein. Unabhängig von der Frage des Aufbrechens der Verschlüsselung muss aber die https Verbindung vor (D)DoS Angriffen geschützt werden. Vorher war es eine Sache, den OWA zu verlieren, so lange die MAPI Verbindung der LAN Clients noch funktionierte, konnten die meisten noch damit leben. Ist nun aber der https-Service weg, geht gar nichts mehr. Die Vereinfachung einerseits bringt Probleme andererseits. Dies führt nun unweigerlich zur nächsten Frage, wie sichert man, selbst kleine Exchange Umgebungen, zukünftig ab.
Die Verbindung der Clients zum CAS muss geschützt werden. Die gilt besonders für Verbindungen aus dem Internet. Hier ist es mit Sicherheit keine Option diese Verbindungen per https Forward einfach weiterzuleiten. Dies wäre eine Option ohne Sicherheit und hier ist es nur die Frage der Zeit, bis ein Angriff auf den Exchange stattfinden wird. Es muss sinnvoller Weise eine Entkopplung her. Das schon vor einiger Zeit angesprochene Thema Application Delivery Controller (ADC) ist hier das Mittel der Wahl die Verbindung in Kombination einer NGFW oder einem anderen IPS effektiv zu schützen. Wählt man den ADC geschickt aus, erhält man einen Mehrwert in dem man den ADC dazu verwendet auch die anderen WAN Dienste sowie auch die internen Dienste über den ADC bereitzustellen. Durch die in den meisten Fällen vorhandene virtuelle Umgebung können diese ADC auch als virtueller Appliances eingebracht werden. Für Hardware ADC sprechen die Crypto-Prozessoren, um zu ggf. einen SSL Offload für andere Dienste machen zu können, für den neuen Exchange ist dies ja keine Option mehr.
Bei Fragen zum Thema Exchange Absicherung oder auch ADC, stehen wir wie gewohnt zur Verfügung.