Cloud als Frontend Proxy?

Wie wäre es, wenn auch On-Premises Exchange Server irgendwann über die Microsoft Cloud erreichbar wären?

Dieser Artikel beschreibt zum Teil heute schon verfügbare Möglichkeiten aber der letzte Schritt ist aktuell noch nicht mit Outlook möglich.

Aber Microsoft selbst hat zumindest für Outlook for IOS und Outlook for Android genau diesen Kommunikationsweg beschrieben und beworben:

Wie aufwändig ist es heute?

Microsoft setzt alles daran, dass immer mehr Firmen ihre Dienste aus der Cloud beziehen. Für viele speziell kleinere Firmen ist aus meiner Sicht die Cloud auch eine sehr günstige und sichere Art der Bereitstellung von Diensten und kann lokale Server durchaus ersetzen. Dennoch gibt es noch sehr viele lokal betriebene Exchange Server und selbst Microsoft erwartet nicht, dass Firmen in wenigen Jahren in die Cloud umziehen. So ist Anfang 2018 schon bekannt, dass es natürlich eine Exchange 2019-Version Ende 2018 geben wird und damit für die nächsten 5 Jahre der Support und die Weiterentwicklung sichergestellt ist.

Wer heute Exchange 2016 noch lokal einsetzt muss ich einige Gedanken über den Betrieb und die Sicherheit machen. Denn auch Anwender auf lokalen Exchange Servern erwarten natürlich eine Erreichbarkeit aus dem Internet. Nur die wenigsten Exchange Umgebungen werden hinter verschlossenen Burgmauern rein intern betrieben. Der Zugriff per Webbrowser oder mit Mobilgeräten gehört nicht nur mehr zum guten Ton sondern ist für viele Einsatzbereiche zwingend erforderlich. Damit sind einige Dinge verbunden, die sie natürlich genauso bereitstellen müssen

  • Internet-Anbindung
    Ohne Internet und öffentliche IP-Adresse geht natürlich gar nichts. Je nach Belastung und Anzahl der Anwender müssen Sie die erforderliche Bandbreite bereitstellen. Wenn Standorte geografisch verteilt sind und Anwender auf fernen Kontinenten über das Internet arbeiten, kann das durchaus eine Herausforderung sein
  • Port-Firewall
    Schützt die nicht für die Funktion erforderlichen Ports ihres Netzwerk. Exchange und die Clients nutzen fast ausschließlich HTTPS über 443/TCP und daher ist es natürlich nicht erforderlich, dass andere Ports wie 135/TCP u.a. erreichbar sind. Das ist ja das mindeste aber reicht nicht.
  • HTTP-Firewall und SSL-Zertifikat
    Denn ein erreichbarer Port 443 ist ein mögliches Einfallstor. Wer möchte hier nicht z.B. zu viele Anmeldeversuche pro Konto blockieren, ehe das Active Directory das Konto sperrt. Auch eine Drosselung von Durchsatz und Requests zum Wohle der Allgemeinheit sind wichtige Faktoren, die Exchange ohne fremde Hilfe nicht bereitstellen kann. Natürlich brauchen Sie selbst ein Zertifikat, welches Sie auch noch verwalten müssen.
  • Device Management
    Nicht jedes Gerät, welches vom Anwender mit einem gültigen Benutzernamen und Kennwort konfiguriert wird, ist aus Sicht der Firma ein "erlaubtes" Gerät. Compliance-Richtlinien sind ebenso ein Thema wie das Management der Geräte. Das betrifft nicht nur das Smartphone. Auch ein Outlook auf einem Consumer-Laptop könnte das Firmenpostfach in eine lokale OST-Datei replizieren oder als PST-Datei exportieren.
  • Mail-Relay mit Spam/Virenfilter
    Zuletzt möchte ich natürlich noch den SMTP-Zugang thematisieren. Ohne Spamfilter und Virenschutz dürfen Sie keinen Mailserver betreiben. In den Anfangszeiten haben die Hersteller von Mailservern noch versucht diese Funktion mit in das Produkt zu integrieren. Heute gibt es kaum noch ausreichend gute Filter im Produkt selbst. Ein vorgelagertes Schutzsystem muss in das Bild mit aufgenommen werden

Als Bild sieht das dann so aus:

Ich denke, dass Sie mit bei allen Punkten zustimmen werden. Das Problem ist aber, dass der Preis für all diese Lösungen nicht linear mit der Anzahl der Benutzer steigt, sondern jede Lösung quasi einen Festpreis als "Sockel" hat und nur die Lizenzen für die Anzahl der Benutzer mit ansteigt. Der Sockel ist es aber, der den Eigenbetrieb um so unwirtschaftlicher macht, je weniger Anwender die Funktion benötigen.

Hier kommt dann die Stärke der Cloud, da Sie all dieses Funktionen ebenfalls bereit stellt aber als "Shared Plattform" über alle Kunden skalieren kann. Damit ist der Anteil der Fixkosten pro Anwender deutlich geringer. Insofern

Routing mit Exchange Online Protection

Die Einrichtung eines Hybrid-Mode mit Exchange ist die Basis, um Benutzer sowohl On-Premises als auch in Office 365 mit der gleichen SMTP-Domäne, dem gleichen Adressbuch und Frei/Belegt-Zeiten zu betreiben. Über Hybrid ist es aber auch möglich, dass ihr On-Premises Server seine Mails nicht mehr selbst in das Internet sendet sondern Office 365 als "Outbound Relay" verwendet. Umgekehrt können Sie eingehend die Mails per MX-Record zu Exchange Online Protection senden, welches dann die meisten Spam-Nachrichten ablehnt oder filtert und nur nur erwünschte Mails zu ihrem Exchange Server durchstellt.

Diese Funktion ist fast komplett unabhängig von einem Exchange Hybrid Mode. Sie müssen nur per Office 365 Identity Management die Liste der gültigen Empfänger in Exchange Online Protection hinterlegen, damit Microsoft ungültige Empfänger gleich ganz abwehren kann. Das Bild sieht dann etwas anders aus:

In ihrer lokalen Umgebung entfällt das Mail-Relay und auch der komplette "böse" SMTP-Verkehr, der als Spam bislang lokal abgewehrt wurde, belastet nicht mehr ihre Leitung. Zur Vollständigkeit sollte ich sagen, dass es neben Exchange Online Protection natürlich noch andere "Hosted AntiSpam"-Anbieter gibt. Selbst mit Exchange Online Protection können Sie weiterhin Drittprodukte integrieren, um z.B. SMIME/PGP oder erweiterte Disclaimer etc. zu ergänzen. Sie können mich dazu gerne ansprechen oder z.B. Exchange Online Connector Routing lesen.

Hybrid Mobile Client

Wer Exchange betreibt wird sicher auch mitbekommen haben, wie Microsoft Ende 2014 die Firma Acompli aufgekauft hat. Das Produkt von Acompli war ein PIM Client for IOS und Android, der damals viel mehr Funktionen geliefert hat, als die in IOS oder Android integrierten Clients für ActiveSync. Microsoft hat die Apps dann kostenfrei gestellt und immer näher an Outlook gebracht. Der große Vorteil für Anwender ist die gute Integration von Mails, Terminen und Kontakten in einer App und dass bei einem Wechsel zwischen den Mobilplattformen die Bedienung für den Anwender quasi unverändert gebliebene ist. Er musste einfach nur "Outlook" auf dem Mobilgerät starten.

Technisch hat Acompli dies aber so gelöst, dass die App sich mit einem Service des Anbieters in der Amazon-Cloud verbunden hat, der dann mit den übergebenen Anmeldedaten samt Kennwort sich mit dem Exchange Server verbunden hat und die Mails über das Protokoll "ActiveSync" repliziert hat. Dies wurde mit einer "besseren Experience" für den Anwender begründet. Für viele Administratoren war das aber der Grund diese App zu sperren, die Anwender auf ihre Fehlverhalten (Weitergabe des Kennworts) aufmerksam zu machen, und eine Kennwortänderung zu erzwingen.

Mittlerweile ist nicht nur die App sondern auch die komplette Middleware zu Azure umgezogen worden und wird von Microsoft betrieben und allen Anwendern quasi kostenfrei zur Verfügung gestellt, die eine Exchange CAL oder Office 365 Lizenz haben. Ob Sie als Administrator oder Firma damit nun besser leben können, müssen Sie mit sich selbst ausmachen.

Interessant wird das Bild, wenn Sie nicht nur Outlook for IOS/Android betrachten sondern auch andere ActiveSync-Geräte mit verwalten. Das konnten Sie bisher mit eigenen lokal betriebenen oder gehosteten MDM-Lösungen erreichen. Aber auch Office 365 biete eine MDM-Lösung mit an, die sich zwischen ihren Exchange Server und das Endgerät integriert.

In dem Blog-Artikel wird explizit auch Exchange On-Premises beschrieben und folgendes Bild gezeichnet:


Quelle: A new architecture for Exchange hybrid customers enables Outlook mobile and security
https://blogs.technet.microsoft.com/exchange/2018/04/02/a-new-architecture-for-exchange-hybrid-customers-enables-outlook-mobile-and-security

Das ist durchaus eine Weiterentwicklung zur Dokumentation auf:


Quelle: Outlook for iOS and Android in Exchange Online: FAQ
https://technet.microsoft.com/en-us/library/mt465746(v=exchg.150).aspx

Wenn ich diese Veränderung nun in das "Big Picture" einbinde, in dem ihre Client im Internet über die Office 365 Cloud dann auf den Exchange Server per ActiveSync zugreifen, dann wird ihre eigene DMZ schon wieder etwas überschaubarer:

Das Device Management als auch der Reverse Proxy, über den die mobilen Clients auf ihren On-Premise Exchange Server zugreifen, steht schon in Office 365.

Hybrid Outlook?

Wenn Sie sich nun aber genau das Bild anschauen, dann könnten Sie durchaus auf den Gedanken kommen, dass auch die Outlook-Clients, die nicht im internen LAN unterwegs sind, doch auch über einen Office 365 Frontend Server auf ihre On-Premise Server zugreifen könnten. Das könnte dann so aussehen:

Sie würden damit jede Menge Themen gleich mit erschlagen:

  • Bandbreiten DoS-Schutz
    Ihr eigener Exchange Server müsste per HTTPS gar nicht mehr direkt erreichbar sein. Alle Clients (und Angreifer) würden Office 365 Systeme ansprechen
  • Pre-Auth
    Die Office 365 Umgebung kann die Authentifizierung des Clients übernehmen und auch hier einen Schutz gegen Brute-Force-Angriffe etablieren.

Allerdings hat dieser Ansatz natürlich auch Einschränkungen:

  • Abhängigkeit von Office 365br> Hoffen wir bei so einem Setup, dass die bösen Jungs immer weniger Ressourcen haben, also die guten Jungs
  • Authentifizierung und Inhalte
    Der Zugang zu den Postfachinhalten wird natürlich über Credentials gesichert. Wenn der Client sich aber an der Cloud authentifiziert, dann könnte theoretisch jemand mit den Daten auch die Daten auf ihrem Server lesen. Interessant wäre hier eine Verschlüsselung der Inhalte zwischen Client und Server auch über den Proxy hinweg und das der "DecryptionKey" eben doch wieder "direkt" übertragen wird. Man könnte ja alle Mails per SMIME sichern und damit über Client-Zertifikate sogar die Endgeräte kontrollieren

Das ist nur eine Kurzfassung und viel weiter möchte ich auch gar nicht einsteigen, denn dieser Zugriff ist aktuell nicht möglich und ich weiß auch nicht, ob er überhaupt möglich sein wird.

Graph/REST-API

Wer zukünftig auf Exchange-Online Daten zugreifen möchte, sollte nicht mehr allzu lange auf EWS setzen, sondern sich die REST-API anschauen. Interessant ist hier, dass mit dem Exchange Hybrid Mode auch Postfächer auf lokalen Exchange Servern so per REST erreichbar sind. Hier ist die Cloud schon ein "Frontend Proxy"

Nebeneffekt WAN-Optimierung

Einen Vorteil hat der Weg über die Office 365 Cloud aber noch, auf den ich dennoch eingehend will. Er ist heute schon für "Outlook for IOS" und "Outlook for Android" nutzbar. Wer heute Exchange On-Premises betreibt und seine Firma im Rahmen der Upgrades von Exchange 5.x, 200x, 2010 auf die aktuelle Version schon zentralisiert hat, betreibt wenige Server an noch weniger Standorten. Ich habe einige Kunden, die alle Postfächer sogar am Standort oder in der Nähe der Firmenzentrale betreiben. Das hat für Anwender in anderen Kontinenten natürlich schon die ein oder anderen Nachteile. Entfernung und Provider als auch Peering sind hier ein Thema und auch wenn Outlook im Cached Mode sehr effektiv sein kann, so sind Latenzzeiten durchaus merklich. Für gewisse Aktionen (Free/Busy, Mailtipps, Stellvertreterzugriff etc.) ist ein Online-Zugriff erforderlich. Heute gibt es nur zwei Optionen

  1. Über eigenen WAN
    Sofern der entfernte Standort mit einer eigenen WAN-Verbindung angebunden ist, kann der Client direkt intern den Weg zum On-Premises Exchange Server nutzen. Das ist in der Regel ein schneller Weg aber durchaus teuer und steht im Wettbewerb mit noch "wichtigeren" Daten, z.B. Produktionsteuerung oder Vertrieb und insbesondere VoIP
  2. Über Internet, ggfls. mit VPN
    Wer kein eigenen WAN hat, kann den Server natürlich über das Internet erreichen. Wenn Exchange nicht nativ per MAPI/HTTP erreichbar sein soll, wird oft und gerne ein VPN genutzt. Damit ist quasi auch eine Pre-Authentication möglich und vor allem kann ein Administrator das Endgerät besser kontrollieren, z.B. über Computerzertifikate und Policies. Kritisch ist hier natürlich die schlecht vorhersehbare Laufzeit und Stabilität. Das Internet ist zwar per Definition ausfallsicher aber immer mehr Staaten filtern und regulieren aber selbst Hotels und Provider "managen" den Verkehr über Prioritäten. Wenn dann der Weg zwischen dem lokalen Provider und dem Internetprovider der Firma über öffentliche Peerings geht, dann kann es schon mal eng werden.

In das Bild könnte Office 365 und das Microsoft Global Network passen. Microsoft betreibt ein weltumspannendes Netzwerk und versucht mit möglichst vielen Providern ein "Peering" zu erreichen. Es mit mittlerweile der Regelfall, dass ein Kunde bei einem Provider innerhalb des gleichen Providers zum Microsoft Netzwerk kommt. Sie als Kunde bezahlen ihren Provider für eine gute Leistung und bezahlen auch Microsoft. Es gibt also keine weitere Person, die ihren Verkehr "ungern" überträgt.

Würde nun ihr Client über seinen Provider den nächstmöglichen Office 365 Entry-Punkt ansprechen und der Frontend Server dort über das schnelle Microsoft Netzwerk den Weg zu ihrem On-Premise Server nutzen, dann könnte die Performance deutlich besser sein als über das nicht in ihrem Sinne QoS-geregelte Internet (Option 2) oder eine eigene schwache WAN-Verbindung (Option 1)

Übrigens nutzen natürlich alle Office 365 Dienste schon diese Optimierung. Wenn ihr Postfach in Exchange Online in Dublin liegt und der Vertriebsleiter gerade in Australien oder Süd Amerika unterwegs ist, dann geht er nicht über das Internet bis nach Dublin/Amsterdam sondern verbindet sich vor Ort mit dem "nächsten" Frontend-Server, der die Anfrage über das Microsoft Netzwerk zu, Frontend Server im Datacenter weiter gibt. Der zweite Frontend Server weiß genau, zu welcher Backend Server gerade die aktive Datenbank mit ihrem Postfach hat. Das gleiche Verfahren nutzen auch SharePoint, OneDrive und alle anderen Office 365 Dienste.

Wenn Sie dann über den Exchange Hybrid Mode ihr Postfach dann doch von On-Premises nach Exchange Online verlagern sollten, würde sich für den Client nicht einmal etwas ändern.

Hinweis

Aktuell hat Microsoft diesen Weg "über" die Cloud Mobile Devices schon einmal umgesetzt.

Sie können selbst diesen Weg auch umsetzen, indem Sie in Azure eigene Reverse Proxy Server betreiben, die ihre Requests über die Cloud zu ihrer On-Premises Umgebung routen

Dieses System müssen Sie dann aber auch selbst konfigurieren, betreiben und natürlich direkt bezahlen.

Hinweis:
Dieser Überlegungen eines Frontend Proxy für Outlook (MAPI/HTTP) und OWA zum Zugriff auf einen On-Premises Server sind natürlich rein theoretische Überlegungen und aktuell nicht möglich. Aktuell wird ihr Client per Autodiscover V2 oder Autodiscover Redirect immer direkt zum Postfachserver umgeleitet.

Weitere Links