Outlook Anywhere - Sicherheit

Hinweis:
Outlook Anywhere ist durch SSL sicher. Schwachpunkt ist der Client. Eine Postfach in einer OST-Datei ist nur so gut gesichert wie Windows selbst gesichert ist. Das wird noch wichtiger, wenn Tables und Slates Windows noch mobiler machen und Endgeräte nicht mehr zwingend Mitglied der Domäne sind.

Für die Betrachtung der Sicherheit dürfen Sie sich nicht nur auf den Server konzentrieren, sondern müssen zumindest drei Aspekte beleuchten:


Der Server

Natürlich müssen Sie den Server "sichern". Selbst wenn sie einen kryptischen Namen gewählt haben, so wird der Zugang, welcher über den 443 seine Dienste anbietet, in der Regel nach kurzer Zeit "gefunden". Portscanner sind permanent auf der Suche nach Schwachstellen und so sollten Sie angemessen Mittel einsetzen, um ihren Server zu sichern.
Siehe auch OA Proxy


Die Verbindung

Zwischen Client und Server werden alle Daten per HTTPS verschlüsselt. Wenn man mal davon absieht, dass diverse ältere SSL-Implementierungen Schwachstellen hatten oder früher zu kurze Schlüssellängen verwendet wurden, ist heute HTTPS ein relativ "sicheres" Protokolle, welches eine Ende zu Ende-Verschlüsselung gewährleistet, zumindest solange die ausstellenden Zertifizierungsstellen die Antragsteller prüfen und ungültige Zertifikate über die CRL vom Client erkannt werden können


Der Client

Oft vergessen wird aber der Client. So "schön" die einfache Konfiguration (mit Autodiscover sogar automatisch) ist, so kann dies nicht darüber wegtäuschen, dass jeder Anwender mit Benutzername und Kennwort sich ein Profil auf einem beliebigen PC einrichten kann. Sie haben keine Kontrolle über den Desktop, lokale Kennworte, Schutz der OST-Datei etc.

Beachten Sie hier auf jeden Fall die "fehlende" Sicherheit von Clients, wenn Sie hier keine Beschränkung oder Regelung vorsehen.

Der Server

Natürlich haben Sie erst mal ein schlechtes Gefühl, einen IIS direkt am Internet zu betreiben, nur damit Clients auf das virtuelle Verzeichnis "/RPC" zugreifen können. Aber hier können Sie dann mit einer Firewall die Sicherheit erhöhen, welche die HTTPS-Verbindung annimmt und nach innen weiter gibt.

So kann z.B. der ISA-Server über eine Webveröffentlichung gezielt Verbindungen zu dieser URL passieren lassen, während alle anderen Zugriffsversuche (z.B. nach /MSADC, /Scripts, /CGI-BIN etc.) von außen blockiert werden.

Risiko Client

Kaum haben Sie als Administrator den RPC-Zugang per Zertifikat und Reverse Proxy gesichert, kann doch jeder Anwender auf seinem privaten PC zuhause einfach "Outlook Anywhere" einrichten. Mit funktionierender "Autodiscover-Konfiguration" muss er dazu nicht mal wissen wie es geht. Und schon arbeiten die Anwender munter mit Outlook auf ihrem Server ohne, dass Sie überhaupt eine Möglichkeit haben, auf dem Client irgendwelche Richtlinien durchzusetzen. Der Client kann also "ohne Kennwort" und ohne Verschlüsselung betrieben werden. Selbst die Absicherung der OST.-Datei durch Verschlüsselung ist nicht von ihnen zu steuern. Der PC ist nämlich gar nicht in ihrer Domäne und schon gar keinen Gruppenrichtlinien unterworfen. Und dass darauf "nur" ihr Mitarbeiter sich anmeldet, ist auch nicht Vorauszusetzen. Und morgen sendet die Tochter, der Sohnemann oder wer auch immer im Haus eine Mail im Namen des Mitarbeiters ?. Und was passiert, wenn es sich um ein schickes privates Notebook handelt, welches so mobil ist, dass es nicht nur vom Mitarbeiter mal mit den Urlaub genommen wird, sondern auch sehr einfach anderweitig "Beine machen" kann ?.

Ein Dieb wird sich sicher über die Hardware freuen, besonders wenn Sie ungeschützt ist, aber noch interessanter können natürlich die Daten sein. Im Bereich mobiler Endgeräte gibt es zumindest ActiveSync Policies, die ein Kennwort erfordern, auch wenn dies kein 100% Schutz sein kann.

Client absichern

Leider gibt es innerhalb von Exchange und Outlook keine Richtlinie oder Policies, die "InBand" übertragen und vom Outlook umgesetzt werden. Sie können also allein auf dem Exchange Server die Outlook Clients in keiner Weise steuern, beschränken, konfigurieren oder sicheren.

Wenn Sicherheit ein Thema ist, dann sollten Sie den Zugriff per Outlook AnyWhere als auch MAPI/HTTP nur für Windows Clients erlauben, die Sie auch managen. Und damit sind das klassische die Computer, die Mitgliedin ihrem Forest sind und damit auch per Gruppenrichtlinien, Softwareverteilung etc. gemanaged werden können.

Und genau das ist auch der Hebel, dass Sie diese Clients entsprechend "Besonders" ausstatten können, z.B. mit Zertifikaten, um Sie von "unbekannten Clients" zu unterscheiden. Folgende Dinge sind daher denkbar.

  • Client Zertifikate
    Wenn der Zugang per RPC/HTTP nicht per "Benutzername/Kennwort" sondern über Client-Zertifikate gesichert wird, die zudem nicht "exportierbar" sind, dann können Sie schon über das Rollout dieser Zertifikate steuern, wer sich mit dem Server verbinden darf,
    Ein 100% Schutz ist dies natürlich nicht, wenn System" geclont" werden können oder das Zertifikat auf einer USB-Smartcard vom Anwender einfach eingesteckt werden kann und so doch wieder eine schlecht geschützte OST-Datei auf privaten PCs landen kann.
    Configure Smart Card Authentication für Outlook Anywhere http://technet.microsoft.com/en-us/library/hh227263.aspx
    Using TMG and UAG to Securely Publish Outlook Web App and Exchange Activesync with Certificate Based Authentication
  • VPN
    Wenn der RPC-Zugangspunkt nur per VPN erreichbar ist, undfür den Aufbau des VPNs ein Zertifikat oder eine andere Kopplung an die Clienthardware möglich ist, dann kann so der offene Zugang blockiert werden. Verschiedene VPN-Clients können sogar noch Policies lokal durchsetzen. So wäre es auch denkbar, Privat-PCs zuzulassen, solange sie den VPN-Client mit entsprechenden Richtlinien verwenden. Wobei die Akzeptanz hier natürlich gering sein wird, weil zum Einen immer erst eine VPN-Verbindung erforderlich ist, die oft Verbindungen zu anderen Systemen auch über "dir Firma" leitet und zudem Auswirkungen auf den Client nicht ausgeschlossen sind.
  • IPSec
    Ein anderer Weg, der schon lange möglich ist, ist die Absicherung der Verbindung per IPSEC. Über eine entsprechende Gruppenrichtlinie und Computerzertifikate kann der Kanal zwischen dem Desktop und dem RPC-Zugangspunkt per IPSEC abgesichert werden. Das ist dann quasi ein VPN für ein Ziel und erfordert auch, dass der Client sich ausweisen kann. Faktisch ist der Zugang durch fremde Clients damit verhindert.
    Using IPsec to Secure Access to Exchange (http://go.microsoft.com/fwlink/?LinkId=207227 , https://www.microsoft.com/en-us/download/details.aspx?id=23708)
  • Direct Access
    Die IPSec-Variante wurde durch Windows 7 Enterprise/Business und Windows 2008R2 und Direct Access noch deutlich verbessert. Hier wird auch kein explizites VPN mehr aufgebaut, aber die Verbindungen sind gesichert, weil sich der Client als Domainmitglied ausweist. Fremde Clients kommen gar nicht an den Zugangspunkt heran.

Microsoft selbst hat den ein oder anderen Artikel dazu schon beigesteuert

RPC/HTTP pro Benutzer steuern

Oft muss es ja aber gar nicht so aufwändig sein. Gerade im Mittelstand wird oft eine pragmatische Lösung gewählt und die Sicherheit aus einer Kombination von "Verpflichtung/Information" der berechtigten Mitarbeiter und einer Blockade aller "nicht relevanten" Postfächer umgesetzt. Den Zugriff per Outlook Anywhere können Sie nämlich pro Postfach steuern:

# OutlookAnywhere aktivieren
set-casmailbox -identity $mailbox -MAPIBlockOutlookRpcHttp:$false

# Outlook Anywhere deaktivieren
set-casmailbox -identity $mailbox -MAPIBlockOutlookRpcHttp:$true

Und damit die Clients das auch mitbekommen sehen Sie hier einmal eine Autodiscover-Auswertung mit aktiviertem (hinten) und deaktivierten (vorne) Outlook Anywhere.

Sobald auf der Mailbox der Zugriff per Outlook Anywhere blockiert ist, bekommt der Client die Information auch nicht mehr mit.

Ehe sie nun aber per PowerShell erst mal bei allen Personen OA deaktivieren und danach wieder aktivieren, sollten Sie besser ein Skript einsetzen, welches nur die Benutzer deaktiviert, die z.B. nicht in einer Liste der "erlaubten Personen" enthalten sind. Das macht z.B. folgendes Skript

set-oaaccess.1.0.ps1

Sie können das Skript natürlich auch anpassen, dass es die Mitgliedschaft einer Windows Gruppe auswertet.. Wenn Sie aber eh schon eine Gruppe pflegen undeinen ISA/TMG haben, der eine Authentifizierung durchführt, dann können Sie zusätzlich auch hier die Veröffentlichung auf die Mitglieder dieser Gruppe beschränken. Sie sollten aber dennoch die Einstellungen am Postfach vornehmen, damit der Client per Autodiscover nicht in die Irre geführt wird.

Zertifikate und MSSTD

Outlook bekommt über Autodiscover die Einstellungen für Outlook Anywhere und per Default wird hier auch der Name des Zertifikats mit übermittelt. Der Client trägt dies dann sogar in der lokalen Konfiguration ein.

Das kann natürlich dann wieder zu Problemen führen, wenn der Namen nicht passt, z.B. weil das SAN-Zertifikat anders ausgestellt wurde oder ein Reverse-Proxy mit einem anderen Namen arbeitet. Und Outlook "warnt" dann natürlich sofort. Wenn ich bei mir manuell hier ein "msstd:owa.netatwork.local" eintrage und Outlook starte, dann erhalten ich folgenden Fehler:

Und natürlich fordert mich Outlook zur Eingabe der Anmeldedaten an, aber lässt mich dennoch nicht zu. Es ist daher wichtig, dass die Konfiguration auf dem Server entsprechend konfiguriert ist.

Empfehlung:
Adresse des RPCHTTP-Proxy-Zugangs ist gleich, egal ob der Zugriff von extern oder intern erfolgt.
Sollte das nicht gehen, dann bleibt ihnen nur die Prüfung des Zertifikatsnamens abzuschalten.

Das geht per PowerShell

# Setzen eines anderen MSSTD-Namens
Set-OutlookProvider EXPR `
    -Server $null `
    -CertPrincipalName msstd:internal.company.local

# Leeren des Felds, damit keine Prüfung stattfindet
Set-OutlookProvider EXPR `
    -Server $null `
    -CertPrincipalName $null

Wenn Outlook den Namen nicht mehr prüft, dann fehlt natürlich ein Baustein bei der Sicherheit. Andererseits wird ein Angreifer, der ihnen ein anderes Zertifikat als "Man in the Middle" unterschiebt, sicher auch diese Hürde nehmen.

Weitere Links