Bundesamt für Sicherheit in der Informationstechnik

M 5.100 Absicherung der Kommunikation von und zu Exchange-Systemen

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Ein Groupware-Server kommuniziert mit Groupware-Clients, Browsern, Telefonie- sowie Kommunikationsanwendungen und anderen Groupware-Systemen. Auch zwischen einzelnen Groupware-Systemkomponenten findet ein Datenaustausch statt. Die Kommunikation erfolgt über das lokale Netz und/oder externe Netze. In allen Fällen werden Daten übertragen, die geschützt werden müssen. Dies sind nicht nur die Daten, die genutzt werden, um Benutzer zu authentisieren ( z. B. Benutzername und Passwort), sondern auch Geschäftsinformationen und im privaten Umfeld persönliche Daten.

Es muss daher entschieden werden, mit welchen Schutzmechanismen die Kommunikation abgesichert wird.

Bei der Übertragung schützenswerter Daten von und zu Groupware-Systemen sollten diese möglichst verschlüsselt werden. Zum Schutz der Daten können unterschiedliche Verfahren eingesetzt werden. Es ist daher zu entscheiden, welches Verfahren unter Kosten-Nutzen-Aspekten das günstigste ist. Die Entscheidung ist nachvollziehbar zu dokumentieren.

Einsatz von IPSec

IPSec bietet eine generelle Absicherung der Kommunikation auf IP -Ebene: Alle Datenpakete werden verschlüsselt und integritätsgeschützt. Vorteilhaft an diesem Verfahren ist, dass beim Einsatz von IPsec auf Microsoft Exchange-Systemebene keine zusätzlichen Konfigurationen durchzuführen sind, da der IPSec-Schutz auf Betriebssystem-Ebene konfiguriert wird.

Für eine Absicherung der E-Mail-Kommunikation stehen mehrere mögliche Lösungsansätze zur Verfügung:

  • Auf physikalischer Ebene ist eine Linkverschlüsselung denkbar, jedoch im Allgemeinen nicht praktikabel.
  • Auf Netzebene ist die Einrichtung eines Virtuellen Privaten Netzes (VPN) möglich.

Wegen der hohen Verbreitung des Internet-Protokolls IP wird dabei in der Regel IPSec oder andere VPN-Lösungen verwendet. IPSec erlaubt die Absicherung von IP-Verbindungen zwischen Standorten, zwischen Endgeräten und auch von Endgeräten zu Standorten. Es können sowohl fest vorkonfigurierte Schlüssel (Preshared Keys) als auch Public Key Infrastrukturen (PKI) für das Schlüsselmanagement verwendet werden.

Um auf Basis von IPSec eine Absicherung der Exchange-Kommunikation zu erreichen, müssen alle am E-Mail-Routing beteiligten Rechner über IPSec kommunizieren.

In reinen Windows-Netzen (Versionen ab Windows 2000) ist IPSec standardmäßig ohne zusätzliche Lizenzen verfügbar. Es entsteht jedoch administrativer Aufwand für die Konfiguration. Weitere Informationen finden sich in M 5.90 Einsatz von IPSec unter Windows.

Einsatz von TLS/SSL

Für alle HTTP -basierten Zugriffe ist SSL grundsätzlich zu empfehlen. Dies gilt auch für die interne Kommunikation zwischen Komponenten des Microsoft Exchange-Systems und anderen Komponenten, die die Möglichkeit der SSL-Absicherung bieten. In allen Einsatzszenarien ist die Verschlüsselung der Übertragungswege zwischen einem Client und einem Microsoft-Exchange-Server sinnvoll oder erforderlich. Dies betrifft besonders die Übertragung sensitiver Daten über nicht vertrauenswürdige Kommunikationswege, wie beispielsweise das Internet. Gerade in einer Microsoft-Exchange-Umgebung sollte hierfür das SSL- bzw. TLS-Protokoll (siehe auch M 5.66 Clientseitige Verwendung von SSL/TLS ) eingesetzt werden. Die Entscheidung über einen optionalen oder erzwungenen Einsatz von SSL / TLS sollte vom Standort der zugreifenden Clients und dem Schutzbedarf der übertragenen Daten abhängig gemacht werden. Die Verschlüsselung der Übertragungsstrecke ermöglicht auch die Verwendung von schwächeren Authentisierungsmechanismen, wie z. B. die Kennwort-basierte Klartext-Authentisierung.

Absicherung der Client-Server-Kommunikation

Ist ein Microsoft Outlook-Client als Exchange-Client konfiguriert, kann die Kommunikation geschützt werden . Verwendet Microsoft Outlook nur die Internet-Protokolle ( POP3 , IMAP 4, SMTP , NNTP ) beim Zugriff auf den Exchange-Server, so sollte die Verbindung mit TLS abgesichert werden. Dies gilt generell auch für den Zugriff auf andere E-Mail-Server.

Eines der möglichen Szenarien für den Einsatz von SSL/TLS ergibt sich aus der Zugriffsmöglichkeit auf einen Exchange-Server über Outlook Web Access (OWA). Die Verschlüsselung der Übertragungswege hat hier zwischen dem Web-Browser und dem (hier erforderlichen) IIS -Server zu erfolgen.

Über das HTTP-Protokoll können unterschiedliche Dienste eines Microsoft-Exchange-Systems angesprochen werden. Der Client-Zugriff auf die Postfachspeicher erfolgt in der Regel über HTTP. Die HTTP-Dienste müssen generell sicher konfiguriert sein, so dass einerseits Zugriffe, die schützenswerte Daten übertragen, mit SSL/TLS geschützt und andererseits nur die benötigten Dienste aktiviert werden.

Dabei sind die über HTTP zugreifbaren RPC-Schnittstellen und WebDAV-Schnittstellen mit besonderen Risiken verbunden:

RPC-Schnittstelle

Die RPC -Schnittstelle ist grundsätzlich mit SSL abzusichern. Weitere Details finden sich in M 2.481 Planung des Einsatzes von Exchange für Outlook Anywhere.

WebDAV-Schnittstelle

Das WebDAV-Protokoll (Web-based Distributed Authoring and Versioning) erlaubt einen dateisystemähnlichen Zugriff auf Informationen über das HTTP-Protokoll. Da der WebDAV-Zugriff bei Exchange unter Umständen auch auf das lokale Dateisystem des Clients erfolgen kann, muss dieses vor unberechtigten Zugriffen geschützt werden. Dabei sollte der Schutz der über WebDAV angebotenen Daten im Vordergrund stehen. Falls aber ein Angreifer über WebDAV auf das lokale Dateisystem zugreifen kann, können dadurch weitere Angriffe vorbereitet werden. Daher sollte der Zugriff auf WebDAV nur authentisiert und über SSL geschützt erfolgen. Zusätzlich ist immer auf die strenge Vergabe von Berechtigungen zu achten.

Absicherung der Server-Server-Kommunikation

Die Server-Server-Kommunikation muss unter Exchange dann verschlüsselt werden, wenn vertrauliche Daten über ungesicherte Netze übertragen werden oder die Authentisierung an einem der Server mittels Klartext-Authentisierung stattfindet.

Die zur Verfügung stehenden Verschlüsselungsmechanismen hängen von den verwendeten Exchange-Konnektoren ab. Insofern ist bei der Wahl des Konnektors auch darauf zu achten, welche Verschlüsselungsmechanismen dadurch benutzt werden können.

Absicherung der Nachrichten-Kommunikation

Auf Nachrichten-Ebene haben sich in der Praxis zur Absicherung von E-Mails auf S/MIME und OpenPGP basierende Programme durchgesetzt. Das Schlüsselmanagement von S/MIME setzt den Betrieb einer Public-Key-Infrastruktur (PKI) voraus. PGP setzt dagegen auf ein offenes Schlüsselmanagement und verlangt keinen Aufbau einer zentralen PKI.

Die Absicherung auf Nachrichten-Ebene wird von Drittherstellern in der Regel als Plug-In-Lösung für einen oder mehrere E-Mail-Clients realisiert (siehe M 5.110 Absicherung von E-Mail mit SPHINX (S/MIME) ).

Auch auf der Ebene des Dateisystems sind Lösungen, z. B. in Form von Shell-Erweiterungen, zur Verschlüsselung und Signatur einzelner Dateien verfügbar. Derart geschützte Dateien können dann als Dateianhänge via E-Mail versendet werden.

Public Key Infrastruktur

Microsoft Outlook bietet einen eingebauten Mechanismus zur E-Mail-Verschlüsselung auf Basis von S/MIME. Dieser nutzt die Vertrauensbeziehungen einer Public Key Infrastruktur, die mit Hilfe der eigenen Windows Enterprise CA (Certification Authority) oder einer fremden CA betrieben werden kann. Die von einer CA selbstsignierten Wurzelzertifikate müssen dem System zur Verfügung stehen. Dazu sollten die als vertrauenswürdig geltenden Wurzelzertifikate für alle Outlook-Clients zentral über eine Windows-Gruppenrichtlinie konfiguriert werden.

Weitere Sicherheitsvorkehrungen

Um einen sicheren Betrieb einer PKI zu gewährleisten, sind die folgenden Vorkehrungen zu treffen:

  • Absicherung der eingesetzten Komponenten und
  • Verwendung von Zertifikatsrückruflisten (Certificate Revocation List, CRL).

Zusätzlich zu den allgemein bekannten Systemkomponenten von Microsoft Exchange-Server müssen noch die Komponenten abgesichert werden, die für den Betrieb von Exchange mit Verschlüsselungs- und Signatur-Funktionalität zuständig sind.

Beim Rückruf eines oder mehrerer Benutzerzertifikate spielt die Gültigkeitsdauer der Zertifikatsrückrufliste eine wesentliche Rolle. Es wird empfohlen, die CRL nach einem Rückruf sofort zu veröffentlichen und nicht auf den nächsten eingeplanten Zeitpunkt der Veröffentlichung zu warten. Es ist jedoch zu beachten, dass durch die Veröffentlichung einer neuen CRL die alte Liste nicht automatisch ihre Gültigkeit verliert und somit die Clients, die bereits eine gültige CRL besitzen, von der neuen keinen Gebrauch machen müssen. Generell empfiehlt es sich daher, die Gültigkeitsdauer von CRLs relativ kurz zu bemessen, so dass die Clients entsprechend häufig ihre CRLs erneuern müssen.

Wie diese Anforderungen konkret umzusetzen sind, kann den Informationen aus dem Microsoft Technet entnommen werden, beispielsweise für die Version 2010 in folgenden Dokumenten:

  • Eine Übersicht der Netzwerkschnittstellen bietet "Exchange Network Port Reference: Exchange 2010 Help".
  • Die Nutzung von Outlook Web Access ist standardmäßig für jeden E-Mail-Benutzer möglich. Zugriffseinschränkungen und Segmentierung der Zugriffsobjekte sind dabei adäquate Mittel der Wahl, um eine sichere Konfiguration von Outlook Web Access durchzuführen, siehe auch "Understanding Security for Outlook Web App: Exchange 2010 Help".
  • Outlook Anywhere (früher RPC-over-HTTP) wird unter "Understanding Outlook Anywhere: Exchange 2010 Help" behandelt.
  • ActiveSync wird unter "Understanding Client Access: Exchange 2010 Help" behandelt.
  • In Exchange 2010 wird die WebDAV-Schnittstelle nicht mehr unterstützt.
  • Die TLS-Absicherung bei Transport-Servern wird unter "TLS Functionality and Related Terminology in Exchange 2010: Exchange 2010 Help" beschrieben. Die Deaktivierung der TLS-Absicherung wird nicht empfohlen.
  • Die Absicherung von Unified-Messaging-Servern wird unter "Securing Unified Messaging Network Traffic: Exchange 2010 Help" beschrieben.
  • Für Client-Access-Server und weitere Exchange Server-Rollen sind die in "Securing Client Access Servers: Exchange 2010 Help" beschriebenen Vorgaben zu beachten.

Prüffragen:

  • Wurde nachvollziehbar entschieden, mit welchen Schutzmechanismen die Kommunikation von und zu Exchange-Systemen abgesichert wird?

  • Wird die Übertragung schützenswerter Daten von und zu Microsoft Exchange-Systemen verschlüsselt?

  • Sind vorhandene WebDAV-Schnittstellen abgesichert?

Stand: 13. EL Stand 2013