(0) exportieren Drucken
Alle erweitern
Verwandte Hilfethemen
Loading
Keine Ressourcen gefunden
Verwandte Blog-Artikel
Loading
Keine Ressourcen gefunden
Erweitern Minimieren
1 von 1 fanden dies hilfreich - Dieses Thema bewerten.

Sicherheitshandbuch für Exchange 2010

Exchange 2010
 

Gilt für: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Letztes Änderungsdatum des Themas: 2012-03-08

Dieser Leitfaden wendet sich an IT-Administratoren, die für die Sicherung der Microsoft Exchange Server 2010-Bereitstellung zuständig sind. Er soll IT-Administratoren dabei unterstützen, die Sicherheitsanforderungen in einer Umgebung zu verstehen und zu verwalten, in der Exchange installiert ist.

In der Vergangenheit hat das Exchange-Team für jede Version von Microsoft Exchange ein eigenständiges Sicherheitshandbuch mit Informationen zu Berechtigungen und Sicherheit veröffentlicht. Dieser Ansatz war sinnvoll, um Dienste und Verzeichnisse nach dem Ausführen von Exchange 2010-Setup zu sperren. Beginnend mit Microsoft Exchange Server 2007, werden beim Setup von Exchange jedoch nur noch die Dienste aktiviert, die für die Serverrolle erforderlich sind, die installiert wird. Daher müssen nach der Installation von Microsoft Exchange keine eventuellen Sicherheitsrisiken mehr behoben werden. Vielmehr ist Exchange nun auf standardmäßige Sicherheit ausgelegt.

Aus diesem Grund erfordert Exchange 2010 kein Sperren oder Absichern, im Gegensatz zu früheren Versionen von Microsoft Exchange, in denen IT-Administratoren mithilfe mehrerer Verfahren Sperrungen für die Server vornehmen mussten, auf denen Microsoft Exchange ausgeführt wurde.

Exchange 2010 wurde nach den Prinzipien des Microsoft-Entwicklungszyklus für sichere Software (Security Development Lifecycle, SDL) entwickelt. Jede Funktion und jede Komponente wurden einer Sicherheitsüberprüfung unterzogen. Sorgfältig ausgewählte Standardeinstellungen gewährleisten eine erheblich sicherere Bereitstellung. Die Zielsetzung dieses Leitfadens besteht darin, Administratoren über sicherheitsrelevante Funktionen sowie über Funktionen zu informieren, die ggf. besondere Sicherheitsüberlegungen erforderlich machen. Dieser Leitfaden enthält Links zu sicherheitsspezifischen Themen in der Exchange 2010-Dokumentation. Diese Themen werden aufgeführt in Anhang 1: "Zusätzliche sicherheitsbezogene Dokumentation". In dem Leitfaden sind keine Schritte zur Verbesserung der Sicherheit des Windows Server-Betriebssystems aufgeführt.

Inhalt

Neuigkeiten

Der Exchange 2010-Entwicklungszyklus für sichere Software

Erreichen von Sicherheit – bewährte Methoden

Beibehalten der Sicherheit – bewährte Methoden

Verwenden von Netzwerkports und Absichern der Firewall

Einschränkungsparameter und Clienteinschränkungsrichtlinien

Rollenbasierte Zugriffssteuerung

Active Directory

Exchange Server-Konten

Dateisystem

Dienste

Zertifikate

Erwägungen zu NTLM

Authentifizierung mit zwei Faktoren

Verbund

Secure/Multipurpose Internet Mail Extensions (S/MIME)

Überlegungen zur Serverrolle

Anhang 1: Zusätzliche sicherheitsbezogene Dokumentation

Exchange 2010 enthält die folgenden neuen Sicherheitsfunktionen:

  • Rollenbasierte Zugriffssteuerung   Exchange 2010 arbeitet mit einem neuen, rollenbasierten Zugriffssteuerungsmodell, mit dem Organisationen die Berechtigungen, die verschiedenen Entscheidungsträgern wie Empfängeradministratoren, Serveradministratoren, Datensatz- und Discovery-Managern sowie Organisationsadministratoren gewährt werden, fein abgestuft verwalten können.

  • Einschränkungsrichtlinien   Mit Exchange 2010 werden Einschränkungsmechanismen für Postfach-, Clientzugriffs- und Transportserver eingeführt, um Ihre Organisation vor DoS-Angriffen (Denial-of-Service) zu schützen und um die Auswirkungen solcher Angriffe möglichst gering zu halten.

  • Verbunddelegierung   Mit Exchange 2010 werden neue Funktionen für die Verbunddelegierung eingeführt, mit denen Sie die Benutzer in die Lage versetzen können, auf sichere Weise mit Benutzern in externen Organisationen zusammenzuarbeiten. Mithilfe der Verbunddelegierung können Benutzer Kalender und Kontakte für Benutzer in externen Verbundorganisationen freigeben. Darüber hinaus wird auch die gesamtstrukturübergreifende Zusammenarbeit ermöglicht, ohne dass in Active Directory Vertrauensstellungen eingerichtet und verwaltet werden müssten.

  • Verwaltung von Informationsrechten   Exchange 2010 enthält neue Funktionen für den Schutz und die Steuerung von Informationen, die es Ihnen ermöglichen, den Inhalt von vertraulichen Nachrichten auf mehreren Ebenen zu schützen und gleichzeitig dafür zu sorgen, dass Ihre Organisation weiterhin in der Lage ist, geschützte Inhalte zu verschlüsseln, zu durchsuchen und mit Messagingrichtlinien zu versehen.

  • Kein Sicherheitskonfigurations-Assistent   In Exchange 2010 werden die Konfigurationsänderungen, die erforderlich sind, damit nur die von einer bestimmten Exchange-Serverrolle benötigten Dienste installiert und aktiviert werden und damit die Kommunikation nur auf die Ports beschränkt wird, die für die unter der jeweiligen Serverrolle ausgeführten Dienste und Prozesse benötigt werden, von Setup durchgeführt. Damit entfällt die Notwendigkeit des Einsatzes von Tools wie dem Sicherheitskonfigurations-Assistenten zur Konfiguration dieser Einstellungen.

Anfang 2002 führte Microsoft die Initiative "Trustworthy Computing" ein. Seit der Einführung dieser Initiative hat sich der Entwicklungsprozess bei Microsoft und im Microsoft Exchange-Team auf die Entwicklung von Software konzentriert, die zur Erhöhung der Sicherheit in Ihrer Organisation beiträgt. Weitere Informationen finden Sie unter Trustworthy Computing (möglicherweise in englischer Sprache).

In Exchange 2010 wurde Trustworthy Computing in den folgenden Kernbereichen implementiert:

  • Sicherer Entwurf (Secure by Design)   Exchange 2010 wurde in Übereinstimmung mit dem Trustworthy Computing-Sicherheitsentwicklungs-Lebenszyklus (möglicherweise in englischer Sprache) entworfen und entwickelt. Der erste Schritt bei der Erstellung eines sichereren Messagingsystems bestand darin, Bedrohungsmodelle zu entwerfen und jede Funktion bereits in der Entwurfsphase zu testen. Mehrere sicherheitsbezogene Verbesserungen wurden in Codierungsprozess und -methoden integriert. Integrierte Tools erkennen Pufferüberläufe und weitere potenzielle Sicherheitsbedrohungen. Kein System kann 100-prozentige Sicherheit garantieren. Indem jedoch beim gesamten Entwurfsprozess Grundsätze für sicheren Entwurf angewendet wurden, bietet Exchange 2010 mehr Sicherheit als frühere Versionen.

  • Standardmäßige Sicherheit (Secure by Default)   Ein Ziel von Exchange 2010 war die Entwicklung eines Systems, in dem der Großteil der Netzwerkkommunikation standardmäßig verschlüsselt wird. Mit Ausnahme der SMB-Kommunikation (Server Message Block) und eines Teils der UM-Kommunikation (Unified Messaging) wurde dieses Ziel erreicht. Durch die Verwendung von selbstsignierten Zertifikaten, dem Kerberos-Protokoll, SSL (Secure Sockets Layer) und sonstigen dem Industriestandard entsprechenden Verschlüsselungstechniken sind nahezu alle Exchange 2010-Daten im Netzwerk geschützt. Zusätzlich ermöglicht das rollenbasierte Setup, mit Exchange 2010 nur die für eine bestimmte und geeignete Serverrolle benötigten Dienste und zugehörigen Berechtigungen zu installieren. In früheren Versionen von Microsoft Exchange mussten alle Dienste für alle Funktionen installiert werden.

  • Antispam- und Antivirusfunktionen   Exchange 2010 enthält eine Suite von Antispam-Agents, die im Umkreisnetzwerk unter der Edge-Transport-Serverrolle ausgeführt werden und die auch unter der Hub-Transport-Serverrolle im internen Netzwerk installiert werden können. Die Antivirusfunktionen wurden durch Hinzufügen von Microsoft Forefront Protection 2010 for Exchange Server als Microsoft-Lösung weiter verbessert.

  • Sichere Bereitstellung (Secure by Deployment)   Während der Entwicklung von Exchange 2010 wurde die Vorversion in der Microsoft-IT-Produktionsumgebung bereitgestellt. Basierend auf den Daten dieser Bereitstellung, wurde der Microsoft Exchange Server Best Practice Analyzer aktualisiert, um reale Sicherheitskonfigurationen zu untersuchen, und in der Exchange 2010-Hilfe wurden bewährte Methoden für die Abläufe vor und nach der Bereitstellung dokumentiert.

    In der Vergangenheit wurde die Berechtigungsverwaltung nach Abschluss der Kerndokumentation dokumentiert und ausgeliefert. Wie jedoch bekannt ist, ist die Berechtigungsverwaltung kein Add-In-Prozess. Sie sollte in die gesamte Planung und die Implementierung der Exchange 2010-Bereitstellung integriert sein. Daher wurde die Dokumentation zur Berechtigungsverwaltung optimiert und in die Kerndokumentation integriert, um einen nahtlosen Kontext für Administratoren zur Planung und Bereitstellung des Verwaltungsmodells zur Verfügung zu stellen. Exchange 2010 umfasst ein neues, rollenbasiertes Berechtigungsmodell, das es ermöglicht, Administratoren und Benutzern fein abgestufte Berechtigungen zu gewähren, sodass diese in der Lage sind, ihre Aufgaben mit den minimal erforderlichen Berechtigungen auszuführen.

  • Kommunikation   Nach der Freigabe von Exchange 2010 bemüht sich das Exchange-Team, die Software kontinuierlich zu aktualisieren und Benutzer auf dem Laufenden zu halten. Indem diese ihr System mit Microsoft Update auf dem neuesten Stand halten, stellen sie sicher, dass in ihrer Organisation stets die aktuellen Sicherheitsupdates installiert werden. Exchange 2010 umfasst auch Antispamupdates. Zusätzlich können sie sich durch ein Abonnement der technischen Sicherheitsbenachrichtigungen von Microsoft stets über die neuesten Sicherheitsupdates für Exchange 2010 informieren.

Einige der grundlegenden bewährten Methoden unterstützen Sie dabei, eine Umgebung mit höherer Sicherheit zu erstellen und zu verwalten. Grundsätzlich besteht die wirksamste Vorgehensweise zur Optimierung Ihrer Exchange 2010-Umgebung hinsichtlich der Sicherheit darin, regelmäßig Analysetools auszuführen und die Software- und Antivirussignaturdateien immer auf dem aktuellen Stand zu halten.

Diese bewährten Methoden dienen dazu, eine Exchange 2010-Umgebung mit höherer Sicherheit einzurichten:

  • Delegiertes Setup   Der erste Exchange 2010-Server, den Sie in Ihrer Organisation installieren, setzt voraus, dass das Konto, das Sie für die Ausführung von Setup verwenden, ein Mitglied der Gruppe der Organisationsadministratoren ist. Das von Ihnen verwendete Konto wird der von Exchange 2010 Setup erstellten Rollengruppe "Organisationsverwaltung" hinzugefügt. Mithilfe des delegierten Setups können Sie es Administratoren, die nicht Mitglieder der Rollengruppe "Organisationsverwaltung" sind, ermöglichen, die nachfolgenden Server einzurichten. Weitere Informationen finden Sie unter Bereitstellen von Exchange Server 2010 und Delegieren der Installation.

  • Dateisystemberechtigungen   Exchange 2010 Setup gewährt die minimal erforderlichen Berechtigungen für das Dateisystem, in dem die Exchange-Binärdateien und -Daten gespeichert sind. Sie müssen keinerlei Änderungen an den Zugriffssteuerungslisten (Access Control Lists, ACLs) der Stammordner und des Ordners "Programme" im Dateisystem vornehmen.

  • Installationspfade   Es empfiehlt sich, die Exchange 2010-Binärdateien auf einem Laufwerk zu installieren, das kein Systemlaufwerk ist (d. h. auf einem anderen Laufwerk als dem, auf dem das Betriebssystem installiert ist). Die Exchange-Datenbanken und Transaktionsprotokolle können sehr schnell anwachsen und müssen sich daher auf Volumes ohne Betriebssystem befinden, die über die entsprechende Kapazität und Leistungsfähigkeit verfügen. Von verschiedenen Exchange-Komponenten werden zahlreiche weitere Protokolle wie Transportprotokolle erstellt und ebenfalls im gleichen Installationspfad wie die Exchange-Binärdateien gespeichert. Diese Protokolle können je nach Konfiguration und Messagingumgebung einen erheblichen Umfang annehmen. In Exchange 2010 können die maximale Größe zahlreicher Protokolldateien und der maximale Speicherplatz, den ein Protokolldateiordner in Anspruch nehmen kann, konfiguriert werden. Der Standardwert beträgt 250 Megabytes. Zur Verhinderung eines potenziellen Systemausfalls aufgrund von zu wenig Speicherplatz empfiehlt es sich, die Protokollierungsanforderungen für jede Serverrolle sorgfältig zu prüfen und die Protokollierungsoptionen und Speicherorte für Protokolldateien Ihren Anforderungen entsprechend zu konfigurieren.

  • Blockieren von Outlook-Legacyclients   Je nach Ihren Anforderungen können Sie die Blockierung von Outlook-Clients so konfigurieren, dass Outlook-Legacyclientversionen blockiert werden. Bestimmte Exchange 2010-Funktionen wie Outlook-Schutzregeln und persönliche Archive unterstützen keine Outlook-Legacyclients. Weitere Informationen zum Blockieren von Outlook-Clients finden Sie unter Konfigurieren der Sperrung von Outlook-Clients für die Verwaltung von Nachrichtendatensätzen.

  • Entkoppeln von SMTP-Adressen und Benutzernamen   Standardmäßig generiert Exchange E-Mail-Adressen und Aliases auf der Basis des Benutzernamens des Postfachbenutzers. Zahlreiche Organisationen erstellen eine zusätzliche E-Mail-Adressrichtlinie, um die E-Mail-Adressen von Benutzern von den Benutzernamen zu entkoppeln und dadurch die Sicherheit zu erhöhen. Wenn der Benutzername des Benutzers Ben Smith beispielsweise "bsmith" lautet und die Domäne "contoso.com" ist, lautet die von der standardmäßigen E-Mail-Adressrichtlinie generierte primäre E-Mail-Adresse "bsmith@contoso.com". Sie können eine zusätzliche E-Mail-Adressrichtlinie erstellen, um E-Mail-Adressen zu generieren, in denen nicht der Alias oder Benutzername des Benutzers verwendet wird. Wenn Sie beispielsweise eine E-Mail-Adressrichtlinie zur Verwendung der Vorlage %g.%s@domain erstellen, werden E-Mail-Adressen im Format "Vorname.Nachname@Domäne" generiert. Für den Benutzer Ben Smith generiert die Richtlinie die Adresse "Ben.Smith@contoso.com". Alternativ können Sie E-Mail-Adressen auch von den Benutzernamen entkoppeln, indem Sie beim Erstellen oder Aktivieren eines Postfachs einen Alias angeben, der sich vom Benutzernamen unterscheidet.

    noteAnmerkung:
    Wenn die primäre SMTP-Adresse eines Benutzers nicht dem Benutzerprinzipalnamen (User Principal Name, UPN)des Kontos entspricht, kann der Benutzer seine E-Mail-Adresse nicht verwenden, um sich bei Microsoft Office Outlook Web App anzumelden, und muss einen Benutzernamen im Format "DOMÄNE\Benutzername" angeben. Bei Verwendung von Microsoft Outlook muss der Benutzer den Benutzernamen im Format "DOMÄNE\Benutzername" angeben, wenn er aufgefordert wird, seine Anmeldeinformationen anzugeben, wenn Outlook die Verbindung zum AutoErmittlungsdienst herstellt.

Microsoft Update ist ein Dienst, der dieselben Downloads wie Microsoft Windows Update sowie zusätzlich aktuelle Updates für andere Microsoft-Programme bereitstellt. Mithilfe dieses Diensts können Sie die Sicherheit und Leistung des Servers auf dem optimalen Stand halten.

Eine wichtige Funtkion von Microsoft Update ist die Windows-Funktion "Automatische Updates". Diese Funktion installiert automatisch wichtige Updates, die für die Sicherheit und Zuverlässigkeit des Computers unerlässlich sind. Ohne diese Sicherheitsupdates ist der Computer anfälliger für Angriffe durch Internetbetrüger und bösartige Software (Malware).

Am zuverlässigsten ist es, sich die Microsoft-Updates mithilfe der Windows-Funktion "Automatische Updates" automatisch auf dem Computer installieren zu lassen. Sie können "Automatische Updates" aktivieren, wenn Sie sich bei Microsoft Update anmelden.

Windows analysiert daraufhin die auf dem Computer installierte Microsoft-Software und überprüft, welche aktuellen und früheren wichtigen Updates benötigt werden. Diese werden anschließend heruntergeladen und automatisch installiert. Danach wiederholt Windows den Aktualisierungsvorgang für wichtige Updates, sobald Sie eine Verbindung mit dem Internet herstellen.

Informationen zum Aktivieren von Microsoft Update finden Sie unter Microsoft Update.

Der Standardmodus von Microsoft Update erfordert, dass jeder Exchange-Server zum Empfangen automatischer Updates mit dem Internet verbunden ist. Wenn Sie Server betreiben, die nicht mit dem Internet verbunden sind, können Sie WSUS (Windows Server Update Services) installieren, um die Verteilung der Updates auf die Computer in der Organisation zu verwalten. Anschließend können Sie Microsoft Update auf den internen Microsoft Exchange-Computern so konfigurieren, dass diese die Updates vom internen WSUS-Server anfordern. Weitere Informationen finden Sie unter Microsoft Windows Server Update Services 3.0 (möglicherweise in englischer Sprache). 

WSUS ist nicht die einzige verfügbare Microsoft Update-Verwaltungslösung. Weitere Informationen zu den Microsoft-Sicherheitsversionen, zu Prozessen, zur Kommunikation und zu Tools finden Sie im Handbuch zu Microsoft Sicherheitsupdates (möglicherweise in englischer Sprache).

Es ist nicht mehr erforderlich, die folgenden Tools zu installieren oder auszuführen:

  • Das Sicherheitstool URLScan ist für IIS 7 nicht erforderlich. Unter früheren Versionen von Microsoft Exchange war es üblich, IIS-Tools wie URLScan zu installieren, um eine IIS-Installation zu sichern. Exchange 2010 setzt Windows Server 2008 voraus, bei dem IIS 7 zum Lieferumfang gehört. Zahlreiche der Sicherheitsfunktionen, die ursprünglich von URLScan bereitgestellt wurden, befinden sich nun in den Anforderungsfilterungsfunktionen von IIS 7.

  • Es ist nicht mehr notwendig, Exchange Best Practices Analyzer zu installieren. Unter früheren Versionen von Microsoft Exchange war es üblich, vor der Installation und in regelmäßigen Zeitabständen danach Exchange Best Practices Analyzer zu installieren und auszuführen. Exchange 2010 Setup umfasst die Komponenten von Exchange Best Practices Analyzer und führt sie während des Setups aus. Es ist nicht erforderlich, Exchange Best Practices Analyzer vor dem Setup auszuführen.

  • Es ist nicht mehr notwendig, den Sicherheitskonfigurations-Assistenten (Security Configuration Wizard, SCW) oder die Exchange-Vorlagen für SCW zu verwenden. Exchange 2010 Setup installiert nur die Dienste, die für eine bestimmte Exchange-Serverrolle erforderlich sind, und erstellt die Windows-Firewall mit erweiterten Sicherheitsregeln, damit nur die Ports geöffnet werden, die für die Dienste und Prozesse dieser Serverrolle benötigt werden. Hierfür muss nicht mehr der Sicherheitskonfigurations-Assistent ausgeführt werden. Im Gegensatz zu Exchange Server 2007 ist Exchange 2010 nicht Bestandteil der SCW-Vorlagen.

Diese Empfehlungen zu den bewährten Methoden dienen dazu, Ihre Exchange 2010-Umgebung sicher zu halten.

Wie weiter oben bereits erwähnt, ist das Ausführen von Microsoft Update eine bewährte Methode. Zusätzlich zum Ausführen von Microsoft Update auf allen Servern ist es außerdem sehr wichtig, alle Clientcomputer auf dem aktuellen Stand zu halten und die Antivirusupdates auf allen Computern in der Organisation zu verwalten.

Außer für die Microsoft-Software sollten Sie auch für alle anderen Softwareprogramme in der Organisation stets die neueen Updates ausführen.

Exchange 2010 verwendet außerdem die Microsoft Update-Infrastruktur, um die Antispamfilter auf dem neueen Stand zu halten. Bei manuellen Updates muss der Administrator standardmäßig Microsoft Update besuchen und die Inhaltsfilterupdates herunterladen und installieren. Alle zwei Wochen stehen aktualisierte Inhaltsfilterdaten zur Verfügung.

Bei manuellen Updates mithilfe von Microsoft Update sind keine Microsoft-IP-Zuverlässigkeitsdienst- oder Spamsignaturdaten eingeschlossen. Der IP-Zuverlässigkeitsdienst von Microsoft sowie Spamsignaturdaten sind nur in Verbindung mit den automatischen Antispamupdates von Forefront Security für Exchange verfügbar.

Weitere Informationen zum Aktivieren von automatischen Forefront-Antispamupdates finden Sie unter Grundlegendes zu Antispamupdates.

Über E-Mail-Systeme verbreitete Viren, Würmer und andere bösartige Inhalte verursachen zahlreiche Schäden, mit denen die meisten Administratoren von Microsoft Exchange konfrontiert sind. Aus diesem Grund müssen Sie eine defensive Antivirusbereitstellung für alle Messagingsysteme entwickeln. In diesem Abschnitt erhalten Sie Empfehlungen zu bewährten Methoden für die Bereitstellung von Antivirussoftware für Exchange 2010.

Sie sollten insbesondere zwei wichtige Änderungen in Exchange 2010 bei der Auswahl eines Anbieters von Antivirussoftware berücksichtigen:

  • Bei Exchange Server 2007 basiert Microsoft Exchange auf einer 64-Bit-Architektur.

  • Exchange 2010 stellt Transport-Agent-Funktionen bereit.

Diese beiden Änderungen bedeuten, dass Anbieter Exchange 2010-spezifische Antiviurssoftware zur Verfügung stellen müssen. Antivirussoftware, die für frühere Versionen von Exchange geschrieben wurde, funktioniert vermutlich nicht ordnungsgemäß mit Exchange 2010.

Für intensiven Schutz empfiehlt es sich, zusätzlich zu Antivirussoftware auf dem Benutzerdesktop auch auf dem SMTP-Gateway oder auf den Exchange-Servern, auf denen die Postfächer gespeichert sind, speziell für Messagingsysteme entwickelte Antivirussoftware bereitzustellen.

Sie können entscheiden, welche Arten von Antivirussoftware verwendet werden sollen und wo die Software bereitgestellt werden soll, indem Sie die Kosten und das Risiko, das Sie einzugehen bereit sind, geeignet aufeinander abstimmen. Beispielweise führen einige Unternehmen die Antivirusmessagingsoftware auf dem SMTP-Gateway, das Antivirusscannen auf Dateiebene auf dem Exchange-Server und die Antivirusclientsoftware auf dem Benutzerdesktop aus. Dieser Ansatz ermöglicht einen messagingspezifischen Schutz auf dem Client. Andere Unternehmen sind bereit, höhere Kosten auf sich zu nehmen, und verbessern die Sicherheit, indem sie Antivirusmessagingsoftware auf dem SMTP-Gateway, das Antivirusscannen auf Dateiebene auf dem Exchange-Server und die Antivirusclientsoftware auf dem Benutzerdesktop ausführen sowie zusätzlich Antivirussoftware einsetzen, die mit Exchange VSAPI 2.5 (Virus Scanning Application Programming Interface) auf dem Exchange-Postfachserver kompatibel ist.

Transportbasierte Antivirussoftware wird als Transport-Agent implementiert oder umfasst Transport-Agents. Transport-Agents reagieren auf Transportereignisse in ähnlicher Weise wie Ereignissenken in früheren Versionen von Microsoft Exchange. Weitere Informationen finden Sie unter Grundlegendes zu Transport-Agents.

noteAnmerkung:
Nachrichten, die nicht übertragen werden, etwa Elemente in Öffentlichen Ordnern, gesendete Elemente und Kalenderelemente, die nur auf einem Postfachserver gescannt werden können, sind durch die Virenprüfung auf Transportebene nicht geschützt.

Drittanbieter können angepasste Transport-Agents entwickeln, um das zugrunde liegende MIME-Analysemodul für eine stabile Virenüberprüfung auf Transportebene zu nutzen. Eine Liste der Exchange-Antivirus- und -Antispampartner finden Sie unter Unabhängige Softwareanbieter (möglicherweise in englischer Sprache).

Darüber hinaus steht mit Forefront Protection für Exchange ein Antivirussoftwarepaket zur Verfügung, das eng in Exchange 2010 integriert ist und zusätzlichen Antivirusschutz für Ihre Exchange-Umgebung bietet. Weitere Informationen finden Sie unter Microsoft Forefront Protection 2010 für Exchange Server.

Der wichtigste Ort, an dem Messagingantivirussoftware ausgeführt werden sollte, ist die erste Verteidigungslinie in Ihrer Organisation. Dies ist das SMTP-Gateway, über das externe Nachrichten in Ihre Messagingumgebung gelangen. In Exchange 2010 ist die erste Verteidigungslinie der Edge-Transport-Server.

Wenn Sie vor Exchange einen anderen SMTP-Server oder ein anderes Gateway als Exchange verwenden, um eingehende E-Mail-Nachrichten zu empfangen, sollten Sie auf den Nicht-Exchange-SMTP-Hosts ausreichende Antispam- und Antivirusfunktionen implementieren.

In Exchange 2010 werden alle Nachrichten über einen Hub-Transport-Server weitergeleitet. Dies umfasst Nachrichten, die von außerhalb der Exchange-Organisation gesendet oder empfangen werden, und Nachrichten, die innerhalb der Exchange-Organisation gesendet werden. Hierbei handelt es sich um Nachrichten, die an ein Postfach gesendet werden, das sich auf dem gleichen Postfachserver wie der Sender befindet. Zum besseren Schutz vor organisationsinternen Virenausbrüchen und zur Bereitstellung einer zweiten Verteidigungslinie wird außerdem empfohlen, transportbasierte Antivirussoftware auf Hub-Transport-Servern auszuführen.

Neben der Suche nach Viren auf Transportservern kann eine auf der Microsoft Exchange-Virenscanner-API (VSAPI) basierende Scannerlösung, die auf Postfachservern ausgeführt wird, in zahlreichen Organisationen eine wichtige Verteidigungsebene darstellen. Sie sollten erwägen, eine VSAPI-Antiviruslösung auszuführen, falls eine der folgenden Bedingungen zutrifft:

  • Ihre Organisation stellt keine vollständigen und zuverlässigen Desktop-Antivirusscanprodukte bereit.

  • Ihre Organisation möchte den zusätzlichen Schutz, den Scans der Postfachdatenbanken bieten können.

  • Ihre Organisation hat benutzerdefinierte Anwendungen mit programmseitigem Zugriff auf eine Exchange-Datenbank entwickelt.

  • Ihre Benutzercommunity veröffentlicht regelmäßig Nachrichten in Öffentlichen Ordnern.

Antiviruslösungen, die Exchange VSAPI verwenden, werden unmittelbar im Exchange-Informationsspeicherprozess ausgeführt. VSAPI-Lösungen sind vermutlich die einzigen Lösungen, die Schutz vor Angriffsvektoren bieten, die infizierte Inhalte in den Exchange-Informationsspeicher platzieren und dabei die standardmäßigen Scans auf den Clients und während der Übertragung umgehen. VSAPI ist beispielsweise die einzige Lösung, die die Daten überprüft, die über CDO (Collaboration Data Objects), WebDAV und Exchange-Webdienste (EWS) an eine Datenbank übertragen werden. Außerdem stellt eine VSAPI-Lösung bei einem Virusausbruch häufig die schnellste Möglichkeit dar, Viren aus einer infizierten E-Mail-Datenbank zu entfernen und zu löschen.

Bedenken Sie Folgendes, falls Sie zum Schutz Ihrer Exchange-Server eine Antivirussoftware auf Dateisystemebene bereitstellen:

  • Sie müssen die Exchange-Serververzeichnisse, in denen die Exchange-Postfach- und Öffentliche Ordner-Datenbanken gespeichert sind, bei Antivirusscannern auf Dateisystemebene ausschließen. Weitere Informationen finden Sie unter Antivirenscans auf Dateiebene für Exchange 2010.

  • Antivirusscanner auf Dateisystemebene dienen nur zum Schutz von Dateien. Zum Schutz von E-Mail-Nachrichten sollten Sie auch erwägen, Exchange-aktivierte Antivirus- oder Messagingsicherheitsprodukte wie die zu implementieren, die in Microsoft Forefront oder einem geeigneten Partner- oder Drittanbieterprodukt enthalten sind. Weitere Informationen zum Antispam- und Antivirusschutz finden Sie unter Grundlegendes zur Antispam- und Antivirusfunktionalität. Ausführliche Informationen finden Sie auch unter Forefront Protection 2010 for Exchange Server: Übersicht (möglicherweise in englischer Sprache).

  • Sie müssen die Antivirus- und Antispamsignaturen immer auf dem aktuellen Stand halten, um einen effektiven Schutz zu gewährleisten.

  • Berichte, die von Antivirus- und Antispamsoftware oder -diensten ausgegeben werden, sollten regelmäßig überprüft werden, damit sichergestellt ist, dass der Schutz aktiviert ist und ordnungsgemäß funktioniert und dass Vorfälle schnell erkannt und die erforderlichen Maßnahmen ergriffen werden.

Spam- und Virenfilter werden durch Microsoft Exchange Hosted Services verbessert oder stehen dort als Dienst zur Verfügung. Exchange Hosted Services ist eine Gruppe von vier unterschiedlichen Hosted Services:

  • Hosted Filtering unterstützt Organisationen beim Schutz vor per E-Mail übertragener Malware.

  • Hosted Archive ermöglicht es Organisationen, Anforderungen bezüglich der Kompatibilität und der Aufbewahrung einzuhalten.

  • Hosted Encryption dient dazu, vertrauliche Daten zu verschlüsseln.

  • Mit Hosted Continuity können Organisationen den E-Mail-Zugriff während und nach Ausfällen erhalten.

Diese Dienste sind in alle lokalen Exchange-Server integriert, die vom Unternehmen selbst verwaltet werden. Weitere Informationen finden Sie unter Forefront Online Protection for Exchange.

In Exchange 2010 können Sie mithilfe der Anlagenfilterung Filter auf Edge-Transport-Server anwenden, um die von Benutzern empfangenen Anlagen zu steuern. Die Bedeutung der Anlagenfilterung nimmt in modernen Umgebungen ständig zu. Zahlreiche Anlagentypen enthalten schädliche Viren oder unangebrachtes Material, das den Computern der Benutzern oder der Organisation beachtlichen Schaden zufügen kann, indem wichtige Unterlagen beschädigt oder vertrauliche Informationen der Öffentlichkeit zugänglich gemacht werden.

Folgende Arten der Anlagenfilterung können zur Steuerung der Anlagen, die in Ihrer Organisation über einen Edge-Transport-Server ein- oder ausgehen, verwendet werden:

Filterung anhand von Dateinamen oder Dateinamenerweiterungen   Sie können Anlagen filtern, indem Sie den genauen Dateinamen oder die Dateinamenerweiterung angeben, der/die gefiltert werden soll. Ein Beispiel für einen genauen Dateinamenfilter ist die Datei "BadFilename.exe". Ein Beispiel für einen Filter für Dateinamenerweiterungen ist "*.exe".

Filterung anhand von MIME-Inhaltstypen von Dateien   Sie können Anlagen auch filtern, indem Sie den zu filternden MIME-Inhaltstyp angeben. MIME-Inhaltstypen zeigen an, ob eine Anlage, z. B. ein JPEG-Bild, eine ausführbare Datei, eine Microsoft Office Excel 2010-Datei oder ein anderer Dateityp ist. Inhaltstypen werden als "Typ/Untertyp" ausgedrückt. Beispielsweise wird der Inhaltstyp für JPEG-Bilder als "image/jpeg" ausgedrückt.

Falls eine Anlage einem dieser Filterkriterien entspricht, können Sie die folgenden Aktionen zur Ausführung für die Anlage konfigurieren:

  • Ganze Nachricht mit Anlage blockieren

  • Anlage entfernen, Nachricht jedoch passieren lassen

  • Nachricht mit Anlage ohne Benachrichtigung löschen

Weitere Informationen finden Sie unter Grundlegendes zur Anlagenfilterung.

noteAnmerkung:
Der Anlagenfilter-Agent kann nicht zum Filtern von Anlagen auf Basis des Inhalts verwendet werden. Zum Überprüfen des Inhalts von Nachrichten und Anlagen können Sie Transportregeln verwenden und dann Maßnahmen wie das Löschen oder Ablehnen der Nachricht ergreifen, oder Sie können die Nachrichten und Anlagen mithilfe der Verwaltung von Informationsrechten (Information Rights Management, IRM) schützen. Weitere Informationen finden Sie unter Grundlegendes zu Transportregeln.

Die von Forefront Protection für Exchange Server bereitgestellte Dateifilterung umfasst erweiterte Funktionen, die über den Anlagenfilter-Agent, der im Lieferumfang von Exchange 2010 enthalten ist, nicht verfügbar sind.

Beispielsweise können Containerdateien, also Dateien, die andere Dateien enthalten, auf nicht ordnungsgemäße Dateitypen überprüft werden. Mit der Filterungsfunktion von Forefront Protection für Exchange Server können die folgenden Containerdateien durchsucht und Aktionen für eingebettete Dateien ausgeführt werden:

  • PKZip (ZIP)

  • GNU Zip (GZIP)

  • Selbstextrahierende komprimierte Dateiarchive (ZIP)

  • Komprimierte Dateien (ZIP)

  • Java-Archiv (JAR)

  • TNEF (WINMAIL.DAT)

  • Structured Storage (DOC, XLS, PPT und andere)

  • MIME (EML)

  • SMIME (EML)

  • UUEncode (UUE)

  • Unix-Tape-Archiv (TAR)

  • RAR-Archiv (RAR)

  • MACBinary (BIN)

noteAnmerkung:
Der Anlagenfilter-Agent in Exchange 2010 ermittelt Dateitypen sogar dann, wenn sie umbenannt wurden. Durch die Anlagenfilterung wird ebenfalls sichergestellt, dass komprimierte ZIP- und LZH-Dateien keine blockierten Anlagen enthalten, indem ein Abgleich der Dateinamenerweiterung mit den Dateien in komprimierten ZIP- oder LZH-Dateien durchgeführt wird. Bei der Dateifilterung in Forefront Protection für Exchange Server kann darüber hinaus festgestellt werden, ob eine blockierte Anlage in einer Containerdatei umbenannt wurde.

Dateien können ebenfalls nach Dateigröße gefiltert werden. Des Weiteren können Sie Forefront Protection für Exchange Server so konfigurieren, dass auf Grundlage von Übereinstimmungen mit Exchange-Dateifiltern Dateien isoliert oder E-Mail-Benachrichtigungen gesendet werden.

Weitere Informationen finden Sie unter Schützen Ihrer Microsoft Exchange-Organisation mit Microsoft Forefront Security für Exchange Server (möglicherweise in englischer Sprache).

Exchange Best Practices Analyzer ist eines der effektivsten Tools, mit dessen regelmäßiger Ausführung Sie überprüfen können, ob Ihre Exchange-Umgebung sicher ist. Exchange Best Practices Analyzer untersucht automatisch eine Microsoft Exchange-Bereitstellung und ermittelt, ob die Konfiguration den bewährten Methoden von Microsoft entspricht. In Exchange 2010 wird Exchange Best Practices Analyzer als Teil von Exchange-Setup installiert und kann über den Abschnitt "Tools" der Exchange-Verwaltungskonsole ausgeführt werden. Mit dem geeigneten Netzwerkzugriff überprüft Exchange Best Practices Analyzer alle AD DS- (Active Directory Domain Services, Active Directory-Domänendienste) und Exchange-Server. Mit Exchange Best Practices Analyzer wird auch die Vererbung von Berechtigungen geprüft. Darüber hinaus werden die RBAC-Berechtigungen auf Gültigkeit überprüft. Dies umfasst Tests zur Sicherstellung, dass alle Benutzer auf die Exchange-Systemsteuerung (Exchange Control Panel, ECP) zugreifen können, dass alle beim Setup von Exchange erstellten standardmäßigen RBAC-Rollen ordnungsgemäß konfiguriert sind und dass in der Exchange-Organisation mindestens ein administratives Konto vorhanden ist.

Windows Server 2008 umfasst die Windows-Firewall mit erweiterter Sicherheit, eine Firewall für die Überprüfung zustandsbehafteter Pakete, die standardmäßig aktiviert ist. Die Windows-Firewall mit erweiterter Sicherheit bietet die folgenden Funktionen:

  • Filterung des gesamten IPv4- und IPv6-Datenverkehrs, der vom Computer empfangen wird oder diesen verlässt. Standardmäßig wird der gesamte eingehende Datenverkehr blockiert, es sei denn, es handelt sich um eine Antwort auf eine vorherige ausgehende Anforderung des Computers (angeforderter Datenverkehr), oder er wird dediziert mit einer Regel zugelassen, die zu diesem Zweck erstellt wurde. Ebenfalls standardmäßig wird der gesamte ausgehende Datenverkehr zugelassen, abgesehen von Dienstabsicherungsregeln, die verhindern, dass Standarddienste auf unerwartete Weise kommunizieren. Sie können Datenverkehr auf Basis von Portnummern, IPv4- oder IPv6-Adressen, dem Pfad und Namen einer Anwendung oder dem Namen eines Diensts zulassen, der auf dem Computer ausgeführt wird, oder auf Basis anderer Kriterien.

  • Schutz des beim Computer eingehenden oder ausgehenden Netzwerkverkehrs unter Verwendung des IPsec-Protokolls zur Überprüfung der Integrität des Netzwerkverkehrs, zur Authentifizierung der Identität der sendenden und empfangenden Computer oder Benutzer und zur optionalen Verschlüsselung des Datenverkehrs, um dessen Vertraulichkeit sicherzustellen.

Exchange 2010 wurde für die Ausführung mit aktivierter Windows Server-Firewall mit erweiterter Sicherheit entwickelt. Über Exchange-Setup werden die erforderlichen Firewallregeln erstellt, mit denen die Kommunikation der Exchange-Dienste und -Prozesse ermöglicht wird. Hierbei werden nur die Regeln erstellt, die von den Diensten und Prozessen benötigt werden, die für eine gegebene Serverrolle installiert wurden. Weitere Informationen zur Verwendung der Netzwerkports und Firewallregeln, die für jede Exchange 2010-Serverrolle erstellt werden, finden Sie unter Exchange-Netzwerkportreferenz.

Unter Windows Server 2008 und Windows Server 2008 R2 ermöglicht die Windows-Firewall mit erweiterter Sicherheit die Angabe des Prozesses oder Diensts, für den ein Port geöffnet wird. Dies ist sicherer, da die Verwendung des Ports auf den Prozess oder Dienst beschränkt wird, der in der Regel angegeben wurde. Über Exchange 2010-Setup werden Firewallregeln mit dem angegebenen Prozessnamen erstellt. In einigen Fällen wird aus Kompatibilitätsgründen eine zusätzliche Regel erstellt, die nicht auf den Prozess beschränkt ist. Sie können Regeln, die nicht auf die Prozesse beschränkt sind, deaktivieren oder entfernen und die entsprechenden Regeln, die ebenfalls von Exchange 2010-Setup erstellt werden und auf Prozesse beschränkt sind, beibehalten, wenn Ihre Bereitstellung dies unterstützt. Die Regeln, die nicht auf Prozesse beschränkt sind, sind durch das "(GFW)" im Regelnamen gekennzeichnet. Es empfiehlt sich, die Regeln in Ihrer Umgebung ausreichend zu testen, bevor Sie Regeln deaktivieren, die nicht auf einen Prozess beschränkt sind.

In der folgenden Tabelle werden die von Exchange-Setup erstellten Windows-Firewallregeln aufgeführt, einschließlich der für die einzelnen Serverrollen geöffneten Ports.

Windows-Firewallregeln

Regelname Serverrollen Port

MSExchangeRPCEPMap (GFW) (TCP eingehend)

Alle Rollen

RPC-EPMap

MSExchangeRPC (GFW) (TCP eingehend)

Clientzugriff, Hub-Transport, Postfach, Unified Messaging

Dynamisches RPC

MSExchange - IMAP4 (GFW) (TCP eingehend)

Clientzugriff

143, 993 (TCP)

MSExchange - POP3 (GFW) (TCP eingehend)

Clientzugriff

110, 995 (TCP)

MSExchange - OWA (GFW) (TCP eingehend)

Clientzugriff

5075, 5076, 5077 (TCP)

MSExchangeMailboxReplication (GFW) (TCP eingehend)

Clientzugriff

808 (TCP)

MSExchangeIS (GFW) (TCP eingehend)

Postfach

6001, 6002, 6003, 6004 (TCP)

MSExchangeTransportWorker (GFW) (TCP eingehend)

Hub-Transport

25, 587 (TCP)

SESWorker (GFW) (TCP eingehend)

Unified Messaging

Beliebig

UMService (GFW) (TCP eingehend)

Unified Messaging

5060, 5061 (TCP)

UMWorkerProcess (GFW) (TCP eingehend)

Unified Messaging

5065, 5066, 5067, 5068

importantWichtig:
Wenn Sie den von einem Exchange 2010-Dienst verwendeten Standardport ändern, müssen Sie auch die entsprechende Firewallregel der Windows-Firewall mit erweiterter Sicherheit ändern, um die Kommunikation über den nicht standardmäßigen Port zu ermöglichen, den Sie verwenden möchten. Wenn Sie die für einen Dienst verwendeten Standardports ändern, werden die Firewallregeln von Exchange 2010 nicht angepasst.

Zur Steuerung von unterschiedlichen Verbindungsparametern, die jedem Protokoll zugeordnet sind, stellt Exchange 2010 Einschränkungsparameter für die Transportserverrolle, die Clientzugriffsserverrolle und die Postfachserverrolle zur Verfügung. Exchange 2010 umfasst darüber hinaus auch Clienteinschränkungsrichtlinien zur Steuerung der Arbeitslast der Clientzugriffsserver. Diese Einschränkungsparameter und -richtlinien tragen dazu bei, die Arbeitslast zu steuern und die Exchange 2010-Server vor DoS-Angriffen (Denial-of-Service) zu schützen, die auf unterschiedliche Protokolle gerichtet sind.

Auf Exchange 2010-Transportservern werden auf dem Server und auf Sende- und Empfangsconnectors Nachrichteneinschränkungsparameter implementiert, um die Nachrichtenverarbeitungsraten, die SMTP-Verbindungsraten und die Zeitlimitwerte für SMTP-Sitzungen zu steuern. In Kombination verhindern diese Einschränkungsparameter, dass Transportserver vom Empfang und vom Versand großer Nachrichtenmengen überfordert werden, und bieten Schutz vor nicht autorisierten SMTP-Clients und DoS-Angriffen.

Sie können auf Exchange 2010-Transportservern mit dem Cmdlet Set-TransportServer die folgenden Einschränkungsrichtlinien konfigurieren:

Einschränkungsparameter für Transportserver

Parameter Beschreibung

MaxConcurrentMailboxDeliveries

Der Parameter MaxConcurrentMailboxDeliveries gibt die maximale Anzahl an Übermittlungsthreads an, die beim Senden von Nachrichten an Postfächer gleichzeitig auf dem Hub-Transport-Server geöffnet sein dürfen. Der Speichertreiber auf dem Hub-Transport-Server ist für die Übermittlung von Nachrichten an Postfachserver und von Postfachservern zuständig. Dieser Grenzwert bezieht sich auf die Übermittlung von Nachrichten an beliebige Postfächer in der Exchange-Organisation.

Standard   20 Zustellungen

MaxConcurrentMailboxSubmissions

Der Parameter MaxConcurrentMailboxSubmissions gibt die maximale Anzahl an Übermittlungsthreads an, die bei der Übernahme von Nachrichten von Postfächern gleichzeitig auf dem Hub-Transport-Server geöffnet sein dürfen. Der Speichertreiber auf dem Hub-Transport-Server ist für die Übermittlung von Nachrichten an Postfachserver und von Postfachservern zuständig. Dieser Grenzwert bezieht sich auf die Übernahme neuer Nachrichten von beliebigen Postfächern in der Exchange-Organisation.

Standard   20 Übermittlungen

MaxConnectionRatePerMinute

Der Parameter MaxConnectionRatePerMinute gibt die maximale Geschwindigkeit an, mit der neue eingehende Verbindungen zum Hub-Transport-Server oder zum Edge-Transport-Server geöffnet werden können. Diese Verbindungen werden für einen beliebigen Empfangsconnector geöffnet, der sich auf dem Server befindet.

Standard   1.200 Verbindungen pro Minute

MaxOutboundConnections

Der Parameter MaxOutboundConnections gibt die maximale Anzahl gleichlaufender ausgehender Verbindungen an, die auf dem Hub-Transport-Server oder dem Edge-Transport-Server gleichzeitig geöffnet sein können. Die ausgehenden Verbindungen laufen über die Sendeconnectors, die sich auf dem Server befinden. Der Wert, der mit dem Parameter MaxOutboundConnections angegeben wird, bezieht sich auf alle Sendeconnectors, die sich auf dem Transportserver befinden.

Standard   1.000 Verbindungen

Wenn Sie den Wert "Unbegrenzt" eingeben, wird die Anzahl der ausgehenden Verbindungen nicht beschränkt.

Dieser Wert kann auch in der Exchange-Verwaltungskonsole konfiguriert werden.

MaxPerDomainOutboundConnections

Der Parameter MaxPerDomainOutboundConnections gibt die maximale Anzahl an Verbindungen an, die ein mit dem Internet verbundener Hub-Transport-Server oder Edge-Transport-Server zu einer einzigen Remotedomäne geöffnet haben kann. Die ausgehenden Verbindungen zu Remotedomänen laufen über die Sendeconnectors, die sich auf dem Server befinden.

Standard   20 Verbindungen pro Domäne

Wenn Sie den Wert "Unbegrenzt" eingeben, wird die Anzahl der ausgehenden Verbindungen pro Domäne nicht beschränkt.

Dieser Wert kann auch in der Exchange-Verwaltungskonsole konfiguriert werden.

PickupDirectoryMaxMessagesPerMinute

Der Parameter MaxPerDomainOutboundConnections gibt die Geschwindigkeit der Nachrichtenverarbeitung für die Verzeichnisse PICKUP und Wiedergabe an. Jedes Verzeichnis kann Nachrichtendateien unabhängig voneinander mit einer Geschwindigkeit verarbeiten, die durch den Parameter PickupDirectoryMaxMessagesPerMinute angegeben ist. Standardwerte   Standardmäßig kann das PICKUP-Verzeichnis 100 Nachrichten pro Minute und das Wiedergabeverzeichnis 100 Nachrichten pro Minute gleichzeitig verarbeiten.

Das PICKUP-Verzeichnis und das Wiedergabeverzeichnis werden alle 5 Sekunden oder 12-mal pro Minute auf neue Nachrichten überprüft. Dieses Abrufintervall von 5 Sekunden kann nicht konfiguriert werden. Das bedeutet, die maximale Anzahl von Nachrichten, die während eines Abrufintervalls verarbeitet werden kann, ist der Wert, den Sie dem Parameter PickupDirectoryMaxMessagesPerMinute zuordnen, dividiert durch 12 (PickupDirectoryMaxMessagesPerMinute/12). Standardmäßig können ungefähr 8 Nachrichten während des Abrufintervalls von 5 Sekunden verarbeitet werden.

Die folgenden Einschränkungsparameter stehen auf Sendeconnectors zur Verfügung: Verwenden Sie das Cmdlet Send-Connector, um diese Parameter zu konfigurieren.

Einschränkungsparameter für Sendeconnectors

Parameter Beschreibung

ConnectionInactivityTimeOut

Mit dem Parameter ConnectionInactivityTimeOut wird die maximale Zeit angegeben, für die eine geöffnete SMTP-Verbindung zu einem Zielmessagingserver im Leerlauf bleiben kann, bis die Verbindung geschlossen wird.

Standard   10 Minuten

SmtpMaxMessagesPerConnection

Der Parameter SmtpMaxMessagesPerConnection gibt die maximale Anzahl von Nachrichten an, die dieser Sendeconnectorserver pro Verbindung senden kann.

Standard   20 Nachrichten

Sie können die folgenden Einschränkungsparameter auf Empfangsconnectors auf Exchange 2010-Transportservern konfigurieren, um Verbindungsparameter wie Inaktivitätszeitlimits, maximale Anzahl an Verbindungen und Anzahl der SMTP-Protokollfehler zu steuern, die während einer Verbindung zulässig sind. Verwenden Sie das Cmdlet Set-ReceiveConnector, um diese Parameter zu konfigurieren.

Einschränkungsparameter für Empfangsconnectors

Parameter Beschreibung

ConnectionInactivityTimeOut

Mit dem Parameter ConnectionInactivityTimeOut wird die maximale Zeit angegeben, für die eine geöffnete SMTP-Verbindung zu einem Quellmessagingserver im Leerlauf bleiben kann, bis die Verbindung geschlossen wird.

Standard auf Hub-Transport-Servern   5 Minuten

Standard auf Edge-Transport-Servern   1 Minute

ConnectionTimeOut

Mit dem Parameter ConnectionTimeOut wird die maximale Zeit angegeben, für die eine SMTP-Verbindung zu einem Quellmessagingserver geöffnet bleiben kann, und zwar auch dann, wenn der Messagingserver Daten überträgt.

Standard auf Hub-Transport-Servern   10 Minuten

Standard auf Edge-Transport-Servern   5 Minuten

Der im Parameter "ConnectionTimeout" angegebene Wert muss größer als der des Parameters "ConnectionInactivityTimeout" sein.

MaxInboundConnection

Der Parameter MaxInboundConnection gibt die maximale Anzahl eingehender SMTP-Verbindungen an, die von diesem Empfangsconnector gleichzeitig zugelassen werden.

Standard   5.000

MaxInboundConnectionPercentagePerSource

Der Parameter MaxInboundConnectionPercentagePerSource gibt die maximale Anzahl von SMTP-Verbindungen von einem einzigen Quellmessagingserver aus an, die von einem Empfangsconnector gleichzeitig zugelassen werden. Der Wert wird als Prozentsatz der verbleibenden verfügbaren Verbindungen auf einem Empfangsconnector ausgedrückt. Die maximale Anzahl von Verbindungen, die vom Empfangsconnector zugelassen werden, wird mit dem Parameter MaxInboundConnection definiert. Standard   2 Prozent

MaxInboundConnectionPerSource

Der Parameter MaxInboundConnectionPerSource gibt die maximale Anzahl von SMTP-Verbindungen von einem einzigen Quellmessagingserver aus an, die von einem Empfangsconnector gleichzeitig zugelassen werden.

Standard   100 Verbindungen

MaxProtocolErrors

Der Parameter MaxProtocolErrors gibt die maximale Anzahl von SMTP-Protokollfehlern an, die von einem Empfangsconnector zugelassen werden, bevor dieser die Verbindung zu dem Quellmessagingserver beendet.

Standard   5 Fehler

Die folgenden Einschränkungsparameter stehen für den Microsoft Exchange-POP3-Dienst auf Clientzugriffsservern zur Verfügung. Verwenden Sie das Cmdlet Set-POPSettings, um diese Parameter zu konfigurieren. Weitere Informationen finden Sie unter Festlegen von Verbindungslimits für POP3.

Einschränkungsparameter für den POP3-Dienst

Parameter Beschreibung

MaxCommandSize

Der Parameter MaxCommandSize gibt die maximale Größe eines Einzelbefehls an. Der Bereich möglicher Werte ist 40 bis 1.024 Bytes.

Standard   40 Bytes

MaxConnectonFromSingleIP

Der Parameter MaxConnectionFromSingleIP legt die Anzahl der Verbindungen fest, die der angegebene Server von einer einzelnen IP-Adresse annimmt. Die möglichen Werte liegen zwischen 1 und 25.000.

Standard   2.000 Verbindungen

MaxConnections

Der Parameter MaxConnections gibt die Gesamtanzahl von Verbindungen an, die der angegebene Server annimmt. Dies umfasst authentifizierte und nicht authentifizierte Verbindungen. Die möglichen Werte liegen zwischen 1 und 25.000.

Standard   2.000 Verbindungen

MaxConnectionsPerUser

Der Parameter MaxConnectionsPerUser gibt die maximale Anzahl der Verbindungen an, die der Clientzugriffsserver von einem einzelnen Benutzer annimmt. Die möglichen Werte liegen zwischen 1 und 25.000.

Standard   16 Verbindungen

PreAuthenticationConnectionTimeOut

Der Parameter PreAuthenticatedConnectionTimeout gibt die Wartezeit vor dem Schließen einer nicht authentifizierten Leerlaufverbindung an. Der Bereich möglicher Werte ist 10 bis 3.600 Sekunden.

Standard   60 Sekunden

Die folgenden Einschränkungsparameter stehen für den Microsoft Exchange-IMAP4-Dienst auf Clientzugriffsservern zur Verfügung. Verwenden Sie das Cmdlet Set-IMAPSettings, um diese Parameter zu konfigurieren. Weitere Informationen finden Sie unter Festlegen von Verbindungslimits für IMAP4.

Einschränkungsparameter für den IMAP4-Dienst

 

Parameter Beschreibung

AuthenticationConnectionTimeOut

Der Parameter AuthenticatedConnectionTimeout gibt die Wartezeit vor dem Schließen einer authentifizierten Leerlaufverbindung an. Der Bereich möglicher Werte ist 30 bis 86.400 Sekunden.

Standard   1.800 Sekunden

MaxCommandSize

Der Parameter MaxCommandSize gibt die maximale Größe eines Einzelbefehls an. Die Standardgröße liegt bei 40 Bytes. Der Bereich möglicher Werte ist 40 bis 1.024 Bytes.

Standard   40 Bytes

MaxConnectionFromSingleIP

Der Parameter MaxConnectionFromSingleIP legt die Anzahl der Verbindungen fest, die der angegebene Server von einer einzelnen IP-Adresse annimmt. Die möglichen Werte liegen zwischen 1 und 25.000.

Standard   2.000 Verbindungen

MaxConnections

Der Parameter "MaxConnections" gibt die Gesamtanzahl von Verbindungen an, die der angegebene Server annimmt. Dies umfasst authentifizierte und nicht authentifizierte Verbindungen. Die möglichen Werte liegen zwischen 1 und 25.000.

Standard   2.000 Verbindungen

MaxConnectionsPerUser

Der Parameter MaxConnectionsPerUser gibt die maximale Anzahl der Verbindungen an, die der Clientzugriffsserver von einem einzelnen Benutzer annimmt. Die möglichen Werte liegen zwischen 1 und 25.000.

Standard   16 Verbindungen

PreAuthenticatedConnectionTimeOut

Der Parameter PreAuthenticatedConnectionTimeout gibt die Wartezeit vor dem Schließen einer nicht authentifizierten Leerlaufverbindung an. Der Bereich möglicher Werte ist 10 bis 3.600 Sekunden.

Standard   60 Sekunden

In Exchange 2010 können Sie mit Clienteinschränkungsrichtlinien die Leistung von Clientzugriffsservern verwalten, indem Sie Parameter wie die folgenden steuern: die Anzahl gleichlaufender Verbindungen für jedes Clientzugriffsprotokoll und die Zeit in Prozent, die während einer Clientsitzung für LDAP-, RPC- und Clientzugriffsvorgänge zur Verfügung steht. Es gibt eine standardmäßige Clientzugriffsrichtlinie, die im Allgemeinen ausreichend ist, um die Arbeitslast von Clientzugriffsservern zu verwalten. Sie können die standardmäßigen Richtlinienparameter ändern oder benutzerdefinierte Richtlinien erstellen, die den Anforderungen Ihrer Bereitstellung gerecht werden.

Einschränkungsrichtlinien stehen für die folgenden Benutzergruppen und Zugriffsmethoden zur Verfügung:

  • Anonymer Zugriff

  • Standortübergreifender Zugriff (Cross-premises Access, CPA)

  • Exchange ActiveSync (EAS)

  • Exchange-Webdienste (Exchange Web Services, EWS)

  • IMAP

  • POP

  • Outlook Web App (OWA)

  • RPC-Clientzugriff (RPC Client Access, RCA)

Die folgenden Einschränkungseinstellungen stehen in den Clienteinschränkungsrichtlinien für jede der folgenden Benutzergruppen (anonymer Zugriff und CPA) und Zugriffsmethoden (EAS, EWS, IMAP, OWA, POP und RCA) zur Verfügung:

Einstellungen für Clienteinschränkungsrichtlinien

Einschränkungseinstellung Anonymer Zugriff CPA EAS EWS IMAP OWA POP RCA

Max. Parallelität

Ja

Ja

Ja

Ja

Ja

Ja

Ja

Ja

Prozentualer Nutzungszeitraum in AD

Ja

N/V

Ja

Ja

Ja

Ja

Ja

Ja

Prozentualer Nutzungszeitraum im Clientzugriffsserver

Ja

Ja

Ja

Ja

Ja

Ja

Ja

Ja

Prozentualer Nutzungszeitraum beim Postfach-Remoteprozeduraufruf

Ja

Ja

Ja

Ja

Ja

Ja

Ja

Ja

CPA   Standortübergreifender Zugriff

EAS   Exchange ActiveSync

EWS   Exchange-Webdienste

OWA   Outlook Web App

Neben diesen Einschränkungseinstellungen auf Basis von Benutzergruppen und Zugriffsmethoden stehen in einer Clienteinschränkungsrichtlinie die folgenden Einschränkungseinstellungen zur Verfügung:

Parameter für Clienteinschränkungsrichtlinien

Parameter Beschreibung

CPUStartPercent

Der Parameter CPUStartPercent gibt den CPU-Prozentsatz pro Prozess an, ab dem Benutzer, die dieser Richtlinie unterliegen, zurückgewiesen werden. Die gültigen Werte reichen von 0 bis 100. Verwenden Sie den Wert "$null", um die auf dem CPU-Prozentsatz basierende Einschränkung für diese Richtlinie zu deaktivieren.

EASMaxDeviceDeletesPerMonth

Der Parameter EASMaxDeviceDeletesPerMonth gibt einen Grenzwert für die Anzahl von Exchange ActiveSync-Partnerschaften an, die ein Benutzer pro Monat löschen kann. Standardmäßig kann jeder Benutzer maximal 20 Partnerschaften pro Kalendermonat löschen. Bei Erreichen des Grenzwerts tritt beim erneuten Versuch, Partnerschaften zu löschen, ein Fehler auf, und dem Benutzer wird eine Fehlermeldung angezeigt.

EASMaxDevices

Der Parameter EASMaxDevices gibt einen Grenzwert für die Anzahl von Exchange ActiveSync-Partnerschaften an, über die ein Benutzer gleichzeitig verfügen kann. Standardmäßig kann jeder Benutzer 10 Exchange ActiveSync-Partnerschaften für sein Exchange-Konto erstellen. Bei Erreichen des Grenzwerts müssen die Benutzer zum Erstellen neuer Partnerschaften zunächst vorhandene Partnerschaften löschen. Wenn der Grenzwert überschritten wurde, wird per E-Mail eine Fehlermeldung mit einer Beschreibung dieser Einschränkung an den Benutzer gesendet. Darüber hinaus wird beim Überschreiten des Grenzwerts durch einen Benutzer im Anwendungsprotokoll ein Ereignis protokolliert.

EWSFastSearchTimeOutInSeconds

Der Parameter EWSFastSearchTimeoutInSeconds gibt den Zeitraum bis zur Zeitüberschreitung einer mit Exchange-Webdiensten durchgeführten Suche an. Dauert die Suche länger als der vom Richtlinienwert angegebene Zeitraum, wird die Suche angehalten und ein Fehler zurückgegeben. Der Standardwert für diese Einstellung liegt bei 60 Sekunden.

EWSFindCountLimit

Der Parameter EWSFindCountLimit gibt die maximale Ergebnisgröße für FindItem- oder FindFolder-Aufrufe an, die während des aktuellen Prozesses für diesen Benutzer im Speicher auf dem Clientzugriffsserver verbleiben kann. Bei dem Versuch, mehr Elemente oder Ordner zu suchen, als der jeweilige Richtliniengrenzwert zulässt, wird ein Fehler zurückgegeben. Der Grenzwert wird jedoch nicht erzwungen, wenn der Aufruf im Rahmen der Anzeige einer Indexseite erfolgt. Bei diesem Szenario werden die Suchergebnisse abgeschnitten, um die im Richtliniengrenzwert festgelegte Anzahl von Elementen und Ordnern einzuschließen. Sie können die Suchergebnisse dann über weitere FindItem- oder FindFolder-Aufrufe weiter durchsuchen.

EWSMaxSubscriptions

Der Parameter EWSMaxSubscriptions gibt die maximale Anzahl aktiver Push- und Pullabonnements an, die ein Benutzer gleichzeitig auf einem bestimmten Clientzugriffsserver ausführen kann. Versucht ein Benutzer, mehr Abonnements als das festgelegte Maximum zu erstellen, schlägt das Abonnement fehl, und in der Ereignisanzeige wird ein Ereignis protokolliert.

ExchangeMaxCmdlets

Der Parameter ExchangeMaxCmdlets gibt die Anzahl der Cmdlets an, die in einem bestimmten Zeitraum ausgeführt werden können, bevor ihre Ausführung verlangsamt wird. Der von diesem Parameter angegebene Wert muss kleiner als der vom Parameter PowerShellMaxCmdlets parameter angegebene Wert sein.

Der Zeitraum für diesen Grenzwert wird vom Parameter PowerShellMaxCmdletsTimePeriod angegeben. Es wird empfohlen, Werte für beide Parameter zugleich festzulegen.

ForwardeeLimit

Der Parameter ForwardeeLimit gibt die Grenzwerte für die Anzahl der Empfänger an, die in den "Posteingangsregeln" konfiguriert werden können, wenn die Weiterleitungs- oder Umleitungsaktion verwendet wird. Dieser Parameter begrenzt nicht die Anzahl der Nachrichten, die an konfigurierte Empfänger weitergeleitet oder umgeleitet werden können.

MessageRateLimit

Der Parameter MessageRateLimit gibt die Anzahl der Nachrichten pro Minute an, die zum Transport übermittelt werden können. Bei Nachrichten, die mithilfe der Postfachserverrolle (mit Outlook Web App, Exchange ActiveSync oder mit den Exchange-Webdiensten) übermittelt werden, führt dies zu einer Verzögerung der Nachrichtenzustellung, bis das Kontingent des Benutzers verfügbar ist. Insbesondere verbleiben Nachrichten länger im Ordner "Postausgang" oder "Entwürfe", wenn Benutzer Nachrichten mit einer Rate übermitteln, die größer als die im Parameter "MessageRateLimit" festgelegte Rate ist.

Bei POP- und IMAP-Clients, die Nachrichten direkt per SMTP zum Transport übermitteln, tritt vorübergehend ein Fehler auf, wenn sie Nachrichten mit einer Rate übermitteln, die größer als die im Parameter "MessageRateLimit" festgelegte Rate ist. Exchange versucht, zu einem späteren Zeitpunkt eine Verbindung herzustellen und die Nachrichten zu übermitteln.

PowerShellMaxCmdletQueueDepth

Der Parameter PowerShellMaxCmdletQueueDepth gibt die Anzahl der Vorgänge an, die der Benutzer ausführen darf. Dieser Wert wirkt sich unmittelbar auf das Verhalten der Parameter PowerShellMaxCmdlets und PowerShellMaxConcurrency aus. Der Parameter PowerShellMaxConcurrency nutzt beispielsweise mindestens zwei vom Parameter PowerShellMaxCmdletQueueDepth definierte Vorgänge, doch auch zusätzliche Vorgänge werden pro Cmdlet-Ausführung genutzt. Die Anzahl von Vorgängen ist abhängig von den ausgeführten Cmdlets. Es wird empfohlen, den Wert für den Parameter PowerShellMaxCmdletQueueDepth auf mindestens das Dreifache des Werts für den Parameter PowerShellMaxConcurrency parameter festzulegen. Dieser Parameter hat keine Auswirkungen auf Exchange-Systemsteuerungs- oder Exchange-Webdienste-Vorgänge.

PowerShellMaxCmdlets

Der Parameter PowerShellMaxCmdlets gibt die Anzahl der Cmdlets an, die in einem bestimmten Zeitraum ausgeführt werden können, bevor ihre Ausführung beendet wird. Der von diesem Parameter angegebene Wert muss größer als der vom Parameter ExchangeMaxCmdlets angegebene Wert sein. Der Zeitraum für diesen Grenzwert wird vom Parameter PowerShellMaxCmdletsTimePeriod angegeben. Beide Werte müssen gleichzeitig festgelegt werden.

PowerShellMaxCmdletsTimePeriod

Der Parameter PowerShellMaxCmdletsTimePeriod gibt den Zeitraum in Sekunden ein, den die Einschränkungsrichtlinie nutzt, um zu bestimmen, ob die Anzahl der ausgeführten Cmdlets die von den Parametern PowerShellMaxCmdlets und ExchangeMaxCmdlets angegebenen Grenzwerte überschreitet.

PowerShellMaxConcurrency

Der Parameter PowerShellMaxConcurrency gibt kontextabhängig unterschiedliche Informationen an:

Im Kontext der Remote-PowerShell gibt der Parameter PowerShellMaxConcurrency die maximale Anzahl von Remote PowerShell-Sitzungen an, die für einen Remote PowerShell-Benutzer gleichzeitig geöffnet sein dürfen.

Im Kontext der Exchange-Webdienste gibt der Parameter PowerShellMaxConcurrency die maximale Anzahl von Cmdlets an, die ein Benutzer gleichzeitig ausführen darf.

Dieser Parameterwert steht nicht unbedingt in Korrelation zur Anzahl der Browser, die der Benutzer geöffnet hat.

RecipientRateLimit

Der Parameter RecipientRateLimit gibt die Grenzwerte für die Anzahl der Empfänger an, die ein Benutzer binnen 24 Stunden adressieren darf.

Weitere Informationen zu Exchange 2010-Einschränkungsrichtlinien finden Sie unter Grundlegendes zu Clienteinschränkungsrichtlinien.

Die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) ist ein neues Berechtigungsmodell in Exchange 2010, das es ermöglicht, sowohl grob als auch präzise zu steuern, welche Aktionen Administratoren und Benutzer durchführen können. Mit RBAC erübrigt sich die Änderung von Zugriffssteuerungslisten (Access Control Lists, ACLs) für Active Directory-Objekte wie Organisationseinheiten und Container, um eine fein abgestufte Delegierung von Berechtigungen für Gruppen wie Helpdeskmitarbeiter oder für Funktionen wie die Empfängerverwaltung zu ermöglichen. Active Directory

Weitere Informationen finden Sie unter Grundlegendes zur rollenbasierten Zugriffssteuerung. Eine Liste der im Lieferumfang von Exchange 2010 enthaltenen standardmäßigen RBAC-Verwaltungsrollen finden Sie unter Integrierte Verwaltungsrollen. Eine Liste mit standardmäßigen Rollengruppen finden Sie unter Integrierte Rollengruppen.

Rollengruppen werden bei Exchange 2010-Setup oder von Ihnen in Active Directory als universelle Sicherheitsgruppen in der Organisationseinheit "Microsoft Exchange Security Groups" erstellt. Sie können einer Rollengruppe Mitglieder hinzufügen, indem Sie das Cmdlet New-RoleGroupMember oder die Exchange-Systemsteuerung verwenden. Wenn Sie einer Rollengruppe ein Mitglied hinzufügen, wird der Benutzer oder die Gruppe der entsprechenden Active Directory-Sicherheitsgruppe hinzugefügt. Sie können eine Richtlinie für eingeschränkte Gruppen verwenden, um die Mitgliedschaft in wichtigen RBAC-Rollengruppen wie der Discoveryverwaltung einzuschränken. Wenn Sie eine Richtlinie für eingeschränkte Gruppen implementieren, wird die Gruppenmitgliedschaft von Active Directory-Domänencontrollern überwacht, und alle Benutzer, die nicht in die Richtlinie eingeschlossen sind, werden automatisch entfernt.

importantWichtig:
Bei Verwendung von eingeschränkten Gruppen zum Einschränken der Gruppenmitgliedschaft in RBAC-Rollengruppen müssen alle Änderungen, die Sie mit Exchange 2010-Tools an einer Rollengruppe vornehmen, auch an der Richtlinie für eingeschränkte Gruppen in Active Directory durchgeführt werden. Ausführliche Informationen hierzu finden Sie unter Sicherheitseinstellungen für Gruppenrichtlinien (möglicherweise in englischer Sprache).

Exchange Server speichert Konfigurationsdaten in der Partition "Konfiguration" und Empfängerdaten in der Partition "Domäne" des Active Directory-Domänendiensts (AD DS). Ausführliche Informationen zu den Berechtigungen, die für das Einrichten einer Exchange 2010-Organisation erforderlich sind, finden Sie unter Berechtigungsreferenz für die Exchange 2010-Bereitstellung. Die Kommunikation mit Active Directory-Domänencontrollern wird mit Kerberos-Authentifizierung und Verschlüsselung gesichert.

Exchange 2010 stellt in Exchange eine neue Autorisierungsschicht bereit, die als rollenbasierte Zugriffssteuerung (RBAC) bezeichnet wird, und arbeitet nicht mehr mit der Anwendung von Zugriffssteuerungseinträgen (Access Control Entries, ACEs) auf jedes Konto, für das die geeigneten Berechtigungen erforderlich sind. In früheren Versionen von Microsoft Exchange arbeitete Exchange-Setup mit ACEs in Active Directory, damit die Exchange-Administratoren in der Lage waren, Objekte innerhalb der Partition "Domäne" zu verwalten. Exchange-Administratoren haben nun die Möglichkeit, über RBAC bestimmte Vorgänge innerhalb eines spezifischen Geltungsbereichs durchzuführen. Der Exchange-Server führt die autorisierten Aktionen im Namen des Administrators oder der Benutzer aus, indem er die Berechtigungen verwendet, die in Active Directory über die Sicherheitsgruppen "Exchange Windows Permissions" und "Exchange Trusted Subsystem" gewährt wurden. Weitere Informationen zu RBAC finden Sie unter Grundlegendes zur rollenbasierten Zugriffssteuerung.

In Exchange 2010 werden mit "/PrepareDomain" keine ACEs für die universelle Sicherheitsgruppe "Exchange Windows Permissions" auf den Container AdminSDHolder in Active Directory angewendet. Wenn "/PrepareDomain" beliebige ACEs erkennt, die der universellen Sicherheitsgruppe "Exchange Windows Permissions" gewährt wurden, werden die ACEs entfernt. Dieses Vorgehen hat die folgenden Auswirkungen:

  • Mitglieder der universellen Sicherheitsgruppe "Exchange Windows Permissions" können die Mitgliedschaft in geschützten Sicherheitsgruppen wie "Enterprise Admins" und "Domain Admins" nicht ändern. Dieses Vorgehen hat wiederum die folgenden Auswirkungen:

  • Mitglieder der universellen Sicherheitsgruppe "Exchange Windows Permissions" können keine Kennwortrücksetzung für ein Konto erzwingen, das mit AdminSDHolder geschützt wird.

  • Mitglieder der universellen Sicherheitsgruppe "Exchange Windows Permissions" können nicht die Berechtigungen einer beliebigen Gruppen oder eines Kontos ändern, die bzw. das mit "AdminSDHolder" geschützt wird.

Als bewährte Methode empfiehlt es sich, dass keine Konten für Postfächer aktiviert werden, die mit AdminSDHolder geschützt werden, und dass separate Konten für Active Directory-Administratoren eingerichtet werden: ein Konto für die Active Directory-Administration und ein Konto für die tägliche Nutzung einschließlich E-Mail. Weitere Informationen finden Sie in den folgenden Themen:

Bei Exchange 2010-Setup wird die neue Organisationseinheit "Microsoft Exchange Security Groups" in der Stammdomäne erstellt. In der folgenden Tabelle werden die neuen universellen Sicherheitsgruppen aufgeführt:

Microsoft Exchange-Sicherheitsgruppen

Sicherheitsgruppe Beschreibung

Exchange All Hosted Organizations

Diese Gruppe enthält alle Gruppen "Exchange Hosted Organization Mailboxes". Sie wird zum Anwenden von Kennworteinstellungsobjekten auf alle gehosteten Postfächer verwendet. Diese Gruppe sollte nicht gelöscht werden.

Exchange Servers

Diese Gruppe enthält alle Exchange-Server. Diese Gruppe sollte nicht gelöscht werden. Es wird dringend davon abgeraten, Änderungen an der Mitgliedschaft zu dieser Gruppe vorzunehmen.

Exchange Trusted Subsystem

Diese Gruppe enthält Exchange-Server, die Exchange-Cmdlets in Namen von Benutzern über den Verwaltungsdienst ausführen. Die Mitglieder dieser Gruppe verfügen über die Berechtigung zum Lesen und Ändern der gesamten Exchange-Konfiguration und auch von Benutzerkonten und Gruppen. Diese Gruppe sollte nicht gelöscht werden.

Exchange Windows Permissions

Diese Gruppe enthält Exchange-Server, die Exchange-Cmdlets in Namen von Benutzern über den Verwaltungsdienst ausführen. Die Mitglieder dieser Gruppe verfügen über die Berechtigung zum Lesen und Ändern aller Windows-Konten und -Gruppen. Diese Gruppe sollte nicht gelöscht werden. Es wird dringend davon abgeraten, Änderungen an der Mitgliedschaft zu dieser Gruppe vorzunehmen. Es empfiehlt sich zudem, die Gruppenmitgliedschaft zu überwachen.

ExchangeLegacyInterop

Diese Gruppe sorgt für Interoperabilität mit Exchange 2003-Servern in derselben Gesamtstruktur. Diese Gruppe sollte nicht gelöscht werden.

Neben diesen Sicherheitsgruppen werden beim Setup auch die folgenden Sicherheitsgruppen erstellt, die den RBAC-Rollengruppen mit demselben Namen entsprechen.

Sicherheitsgruppen, die RBAC-Rollengruppen entsprechen

Sicherheitsgruppe RBAC-Rollengruppe

Delegated Setup

Delegiertes Setup

Discovery Management

Erkennungsverwaltung

Help Desk

Helpdesk

Hygiene Management

Verwaltung von Nachrichtenschutz

Organization Management

Organisationsverwaltung

Public Folder Management

Verwaltung Öffentlicher Ordner

Recipient Management

Empfängerverwaltung

Records Management

Datensatzverwaltung

Server Management

Serververwaltung

UM Management

UM-Verwaltung

View-Only Organization Management

Organisationsverwaltung – nur Leserechte

Auch wenn Sie eine neue Rollengruppe erstellen, erstellt Exchange 2010 eine Sicherheitsgruppe mit demselben Namen wie dem der Rollengruppe. Weitere Informationen finden Sie in den folgenden Themen:

Wenn Benutzer mit den Cmdlets Add-RoleGroupMember oder Remove-RoleGroupMember oder mit dem Benutzer-Editor für die rollenbasierte Zugriffssteuerung in der Exchange-Systemsteuerung den Rollengruppen hinzugefügt oder aus diesen entfernt werden, werden sie auch diesen Sicherheitsgruppen hinzugefügt oder daraus entfernt.

Exchange 2010-Setup erstellt Verzeichnisse mit den minimalen Berechtigungen, die erforderlich sind, damit Exchange 2010 funktioniert. Es wird nicht empfohlen, die Berechtigungen für die standardmäßigen Zugriffsteuerungslisten für Verzeichnisse, die von Setup erstellt wurden, zusätzlich abzusichern.

Bei Exchange 2010-Setup werden keinerlei Windows-Dienste standardmäßig deaktiviert. In der folgenden Tabelle sind Dienste aufgeführt, die standardmäßig für jede Serverrolle aktiviert werden. Es werden nur die Dienste standardmäßig aktiviert, die für den Betrieb einer bestimmten Exchange 2010-Serverrolle erforderlich sind.

Von Exchange-Setup installierte Dienste

Dienstname Dienstkurzname Sicherheitskontext Beschreibung und Abhängigkeiten Standardstarttyp Serverrollen Erforderlich (E) oder optional (O)

Microsoft Exchange Active Directory-Topologie

MSExchangeADTopology

Lokales System

Stellt Exchange-Diensten Active Directory-Topologieinformationen bereit. Wenn dieser Dienst beendet wird, können die meisten Exchange-Dienste nicht starten. Dieser Dienst hat keine Abhängigkeiten.

Automatisch

Postfach, Hub-Transport, Clientzugriff, Unified Messaging

E

Microsoft Exchange ADAM

ADAM_MSExchange

Netzwerkdienst

Speichert Konfigurations- und Empfängerdaten auf dem Edge-Transport-Server. Dieser Dienst stellt die benannte Instanz von AD LDS (Active Directory Lightweight Directory Service) dar, die während der Installation des Edge-Transport-Servers automatisch von Setup erstellt wird. Dieser Dienst ist vom COM+-Ereignissystemdienst abhängig.

Automatisch

Edge-Transport

E

Microsoft Exchange-Adressbuch

MSExchangeAB

Lokales System

Verwaltet Verbindungen des Clientadressbuchs. Dieser Dienst ist vom Microsoft Exchange Active Directory-Topologiedienst abhängig.

Automatisch

Clientzugriff

E

Microsoft Exchange-Antispamupdate

MSExchangeAntispamUpdate

Lokales System

Stellt den Antispamupdate-Dienst Microsoft Forefront Protection 2010 für Exchange Server bereit. Auf Hub-Transport-Servern ist dieser Dienst vom Microsoft Exchange Active Directory-Topologiedienst abhängig. Auf Edge-Transport-Servern ist dieser Dienst vom Microsoft Exchange-ADAM-Dienst abhängig.

Automatisch

Hub-Transport, Edge-Transport

O

Microsoft Exchange-Anmeldeinformationsdienst

MSExchangeEdgeCredential

Lokales System

Überwacht Änderungen an Anmeldeinformationen in AD LDS und installiert die Änderungen auf dem Edge-Transport-Server. Dieser Dienst ist vom Microsoft Exchange-ADAM-Dienst abhängig.

Automatisch

Edge-Transport

E

Microsoft Exchange EdgeSync

MSExchangeEdgeSync

Lokales System

Stellt auf abonnierten Edge-Transport-Servern über einen sicheren LDAP-Kanal (Lightweight Directory Access Protocol) eine Verbindung mit AD LDS her, um Daten zwischen einem Hub-Transport- und einem Edge-Transport-Server zu synchronisieren. Dieser Dienst ist vom Microsoft Exchange Active Directory-Topologiedienst abhängig. Wenn "Edge-Abonnement" nicht konfiguriert ist, kann dieser Dienst deaktiviert werden.

Automatisch

Hub-Transport

O

Microsoft Exchange-Dateiverteilung

MSExchangeFDS

Lokales System

Verteilt das Offlineadressbuch (OAB) und benutzerdefinierte Unified Messaging-Eingabeaufforderungen. Dieser Dienst ist vom Microsoft Exchange Active Directory-Topologie- und Arbeitsstationsdienst abhängig.

Automatisch

Clientzugriff, Unified Messaging

E

Formularbasierte Microsoft Exchange-Authentifizierung

MSExchangeFBA

Lokales System

Stellt die formularbasierte Authentifizierung für Outlook Web App und die Exchange-Systemsteuerung bereit. Wenn dieser Dienst beendet wird, erfolgt keine Authentifizierung der Benutzer durch Outlook Web App und die Exchange-Systemsteuerung. Dieser Dienst weist keine Abhängigkeiten auf.

Automatisch

Clientzugriff

E

Microsoft Exchange IMAP4

MSExchangeIMAP4

Netzwerkdienst

Stellt Clients IMAP4-Dienste zur Verfügung. Wenn dieser Dienst beendet wird, können Clients über das IMAP4-Protokoll keine Verbindung mit diesem Computer herstellen. Dieser Dienst ist vom Microsoft Exchange Active Directory-Topologiedienst abhängig.

Manuell

Clientzugriff

O

Microsoft Exchange-Informationsspeicher

MSExchangeIS

Lokales System

Verwaltet den Exchange-Informationsspeicher. Hierzu gehören Postfachdatenbanken und Öffentliche Ordner-Datenbanken. Wenn dieser Dienst beendet wird, stehen Postfachdatenbanken und Öffentliche Ordner-Datenbanken auf diesem Computer nicht zur Verfügung. Wenn dieser Dienst deaktiviert ist, werden alle ausdrücklich von diesem Dienst abhängigen Dienste nicht gestartet. Dieser Dienst ist vom RPC-, Server-, Windows-Ereignisprotokoll- und Arbeitsstationsdienst abhängig.

Automatisch

Postfach

E

Microsoft Exchange-Mailübergabedienst

MSExchangeMailSubmission

Lokales System

Übermittelt Nachrichten vom Postfachserver an Exchange 2010-Hub-Transport-Server. Dieser Dienst ist vom Microsoft Exchange Active Directory-Topologiedienst abhängig.

Automatisch

Postfach

E

Microsoft Exchange-Postfach-Assistenten

MSExchangeMailboxAssistants

Lokales System

Führt die Hintergrundverarbeitung von Postfächern im Exchange-Speicher aus. Dieser Dienst ist vom Microsoft Exchange Active Directory-Topologiedienst abhängig.

Automatisch

Postfach

E

Microsoft Exchange-Postfachreplikationsdienst

MSExchangeMailboxReplication

Lokales System

Verarbeitet Postfachverschiebungen und Verschiebungsanforderungen. Dieser Dienst ist vom Microsoft Exchange Active Directory-Topologie- und Net.Tcp-Portfreigabedienst abhängig.

Automatisch

Clientzugriff

O

Microsoft Exchange-Überwachung

MSExchangeMonitoring

Lokales System

Ermöglicht Anwendungen das Aufrufen von Exchange-Diagnose-Cmdlets. Dieser Dienst weist keine Abhängigkeiten auf.

Manuell

Alle

O

Microsoft Exchange POP3

MSExchangePOP3

Netzwerkdienst

Stellt Clients POP3-Dienste zur Verfügung. Wenn dieser Dienst beendet wird, können Clients über POP3 keine Verbindung mit diesem Computer herstellen. Dieser Dienst ist vom Microsoft Exchange Active Directory-Topologiedienst abhängig.

Manuell

Clientzugriff

O

Geschützter Microsoft Exchange-Diensthost

MSExchangeProtectedServiceHost

Lokales System

Stellt einen Host für verschiedene Exchange-Dienste bereit, die vor anderen Diensten geschützt werden müssen. Dieser Dienst ist vom Microsoft Exchange Active Directory-Topologiedienst abhängig.

Automatisch

Hub-Transport, Clientzugriff

E

Microsoft Exchange-Replikationsdienst

MSExchangeRepl

Lokales System

Stellt Replikationsfunktionen für Postfachdatenbanken auf Postfachservern in einer Database Availability Group (DAG) bereit. Dieser Dienst ist vom Microsoft Exchange Active Directory-Topologiedienst abhängig.

Automatisch

Postfach

O

Microsoft Exchange-RPC-Clientzugriff

MSExchangeRPC

Netzwerkdienst

Verwaltet Client-RPC-Verbindungen für Exchange. Dieser Dienst ist vom Microsoft Exchange Active Directory-Topologiedienst abhängig.

Automatisch

Postfach, Clientzugriff

O (Postfach), E (Clientzugriff)

Microsoft Exchange-Suchindizierung

MSExchangeSearch

Lokales System

Fördert die Indizierung von Postfachinhalten, sodass die Leistung der Inhaltssuche verbessert wird. Dieser Dienst ist vom Microsoft Exchange Active Directory-Topologie- und vom Microsoft Search-Dienst (Exchange Server) abhängig.

Automatisch

Postfach

O

Microsoft Exchange-Servererweiterung für Windows Server-Sicherung

WSBExchange

Lokales System

Versetzt die Benutzer der Windows Server-Sicherung in die Lage, Anwendungsdaten für Microsoft Exchange zu sichern und wiederherzustellen. Dieser Dienst weist keine Abhängigkeiten auf.

Manuell

Postfach

O

Microsoft Exchange-Diensthost

MSExchangeServiceHost

Lokales System

Stellt eine Host für verschiedene Exchange-Dienste bereit. Auf internen Serverrollen ist dieser Dienst vom Microsoft Exchange Active Directory-Topologiedienst abhängig. Auf Edge-Transport-Servern ist dieser Dienst vom Microsoft Exchange-ADAM-Dienst abhängig.

Automatisch

Alle

E

Microsoft Exchange-Sprachmodul

MSSpeechService

Netzwerkdienst

Stellt Sprachverarbeitungsdienste für Unified Messaging zur Verfügung. Dieser Dienst ist vom Windows-Verwaltungsinstrumentationsdienst (Windows Management Instrumentation, WMI) abhängig.

Automatisch

Unified Messaging

E

Microsoft Exchange-Systemaufsicht

MSExchangeSA

Lokales System

Leitet Verzeichnissuchen an einen globalen Katalogsserver für Outlook-Legacyclients weiter, generiert E-Mail-Adressen und OABs, aktualisiert Frei/Gebucht-Informationen für Legacyclients und verwaltet Berechtigungen und Gruppenmitgliedschaften für den Server. Wenn dieser Dienst deaktiviert ist, werden alle ausdrücklich von diesem Dienst abhängigen Dienste nicht gestartet. Dieser Dienst ist vom RPC-, Server-, Windows-Ereignisprotokoll- und Arbeitsstationsdienst abhängig.

Automatisch

Postfach

E

Microsoft Exchange-Einschränkung

MSExchangeThrottling

Netzwerkdienst

Beschränkt die Rate der Benutzervorgänge. Dieser Dienst ist vom Microsoft Exchange Active Directory-Topologiedienst abhängig.

Automatisch

Postfach

E

Microsoft Exchange-Transport

MSExchangeTransport

Netzwerkdienst

Stellt den SMTP-Serverstapel und -Transportstack bereit. Auf Hub-Transport-Servern ist dieser Dienst vom Microsoft Exchange Active Directory-Topologiedienst abhängig. Auf Edge-Transport-Servern ist dieser Dienst vom Microsoft Exchange-ADAM-Dienst abhängig.

Automatisch

Hub-Transport, Edge-Transport

E

Microsoft Exchange-Transportprotokollsuche

MSExchangeTransportLogSearch

Lokales System

Stellt Remotesuchfunktionen für Microsoft Exchange-Transportprotokolldateien zur Verfügung. Auf Hub-Transport-Servern ist dieser Dienst vom Microsoft Exchange Active Directory-Topologiedienst abhängig. Auf Edge-Transport-Servern ist dieser Dienst vom Microsoft Exchange-ADAM-Dienst abhängig.

Automatisch

Hub-Transport, Postfach, Edge-Transport

O

Microsoft Exchange Unified Messaging

MSExchangeUM

Lokales System

Aktiviert Microsoft Exchange Unified Messaging-Funktionen. Hierdurch wird das Speichern von Sprach- und Faxnachrichten in Exchange ermöglicht, und Benutzer erhalten telefonischen Zugriff auf E-Mail, Voicemail, den Kalender, die Kontakte oder eine automatische Telefonzentrale. Wenn dieser Dienst beendet wird, steht Unified Messaging nicht zur Verfügung. Dieser Dienst ist vom Microsoft Exchange Active Directory-Topologie- und Microsoft Exchange-Sprachmoduldienst abhängig.

Automatisch

Unified Messaging

E

Microsoft Search (Exchange Server)

msftesql-Exchange

Lokales System

Es handelt sich um eine für Microsoft Exchange angepasste Version von Microsoft Search. Dieser Dienst ist vom RPC-Dienst abhängig.

Manuell

Hub-Transport, Postfach

O

Über Exchange 2010-Setup werden selbstsignierte Zertifikate erstellt, um die Kommunikation über unterschiedliche Protokolle wie HTTP, SMTP, POP3 and IMAP4 zu sichern. Die von Setup erstellten selbstsignierten Zertifikate sind für fünf Jahre gültig. Damit ist sichergestellt, dass die selbstsignierten Zertifikate für einen beträchtlichen Teil einer Exchange 2010-Bereitstellung nicht erneuert werden müssen und dass Messagingdienste vom Ablauf der selbstsignierten Zertifikate nicht betroffen sind.

Für externe Clientzugriffsmechanismen und -protokolle wie Outlook Web App, POP3, IMAP4, Outlook Anywhere und AutoErmittlung wird Folgendes empfohlen:

  • Verwenden Sie Zertifikate, die von einer kommerziellen Zertifizierungsstelle (Certification Authority, CA) signiert wurden, die für die Clients, die auf diese Dienste zugreifen, als vertrauenswürdig betrachtet wird.

  • Verwenden Sie den neuen Exchange-Zertifikat-Assistenten oder das Cmdlet New-ExchangeCertificate, um Anforderungen hinsichtlich der Signatur von Zertifikaten an kommerzielle CAs zu stellen. Bei Zertifikatsanforderungen, die mit diesen Tools generiert wurden, ist gewährleistet, dass alle von Exchange gestellten Anforderungen an Zertifikate erfüllt werden.

  • Berücksichtigen Sie die Zertifikatsanforderungen für jedes Protokoll oder jeden Dienst, für das oder den der Zugriff durch externe Clients zugelassen werden soll.

    • Auf Clientzugriffsservern werden Zertifikate verwendet, um den HTTP-Datenverkehr (Outlook Anywhere, Outlook Web App, AutoErmittlung, Exchange ActiveSync und Exchange-Webdienste) mithilfe von SSL und den POP3- und IMAP4-Datenverkehr mit SSL oder TLS (Transport Layer Security) zu schützen. Weitere Informationen finden Sie unter Verwalten von SSL für einen Clientzugriffsserver.

    • Auf Transportservern werden Zertifikate verwendet, um den SMTP-Datenverkehr mit TLS zu schützen. Weitere Informationen finden Sie unter Grundlegendes zu TLS-Zertifikaten.

    • Auf Unified Messaging-Servern werden Zertifikate verwendet, um den VoIP-Datenverkehr (Voice over Internet Protocol) zu schützen. Weitere Informationen finden Sie unter Grundlegendes zu Unified Messaging VoIP-Sicherheit.

    • Verbundzertifikate werden verwendet, um die SAML-Token zu verschlüsseln, die mit dem Microsoft Federation Gateway (MFG) und mit Verbundpartnerorganisationen ausgetauscht werden. Weitere Informationen finden Sie unter Grundlegendes zum Verbund.

  • Überwachen Sie die Gültigkeitsdaten von Zertifikaten, und erneuern Sie Zertifikate von CAs frühzeitig, um eine Dienstunterbrechung zu vermeiden.

  • Schützen Sie beim Speichern von Zertifikaten, die mit dem zugehörigen privaten Schlüssel exportiert wurden, die exportierte Datei anhand der geeigneten Zugriffsteuerungen für den Ordner, in dem die Datei gespeichert wird. Erwägen Sie je nach den Sicherheitsanforderungen Ihrer Organisation, die Überwachung des Dateizugriffs für Ordner zu aktivieren, in denen Zertifikatdateien mit privaten Schlüsseln gespeichert werden.

Das NTLM-Protokoll ist wesentlich unsicherer als das Kerberos-Protokoll. Unter Exchange 2010 unterstützen die Protokolle POP3 und IMAP4 keine NTLM-Authentifizierung, wenn SecureLogin als LoginType angegeben wird. Ausführliche Informationen finden Sie unter Konfigurieren der Authentifizierung für POP3 und IMAP4. Für Exchange 2010-Dienste, die die integrierte Windows-Authentifizierung verwenden, kann entweder NTLM oder Kerberos als Protokoll eingesetzt werden. Kerberos wird für die Kommunikation des Clientzugriffsservers mit einem Exchange 2010-Postfachserver und zwischen Clientzugriffsservern für Outlook Web App, Exchange ActiveSync und die Exchange-Webdienste verwendet. Ausführliche Informationen zu Diensten, die NTLM für die Authentifizierung verwenden, finden Sie unter Exchange-Netzwerkportreferenz.

Authentifizierungsmechanismen mit zwei Faktoren verwenden zusätzlich zu den Anmeldeinformationen des Benutzers (Benutzername und Kennwort) einen weiteren Authentifikator, wie wahlfrei generierte Token oder ein digitales Zertifikat auf einer Smartcard zusammen mit einer PIN. Die Authentifizierung mit zwei Faktoren wird in vielen Organisationen eingesetzt, um den sicheren Zugriff auf das Netzwerk der Organisation zu ermöglichen.

Exchange 2010 enthält keine systemeigene Unterstützung für die Authentifizierung mit zwei Faktoren. Exchange 2010 verwendet Internet Information Server (IIS) 7 für den Clientzugriff über HTTP (AutoErmittlung, Outlook Web App, Outlook Anywhere, Exchange ActiveSync und Exchange-Webdienste). Bei Partnern und Drittanbietern sind zahlreiche Produkte für die Authentifizierung mit zwei Faktoren erhältlich, die in IIS integriert werden können und mit Exchange-Clientzugriffsdiensten wie Outlook Web App zusammenarbeiten. Es empfiehlt sich vor der Bereitstellung von Produkten für die Authentifizierung mit zwei Faktoren für Exchange-Dienste, diese in geeigneter Weise zu testen und somit sicherzustellen, dass sie den Sicherheitsanforderungen Ihrer Organisation gerecht werden und die benötigten Funktionen bieten.

Mit Exchange 2010 werden neue Verbundfunktionen eingeführt, um die sichere Zusammenarbeit zwischen verbundenen Exchange-Organisationen zu ermöglichen. Exchange 2010-Organisationen können eine Verbundvertrauensstellung über das Microsoft Federation Gateway erstellen und dann Organisationsbeziehungen mit anderen Partnerorganisationen einrichten, um Verfügbarkeitsinformationen und Kalender freizugeben. Organisationen können den Benutzern zudem mithilfe von Freigaberichtlinien ermöglichen, ihre Verfügbarkeitsinformationen, Kalender und Kontakte für Benutzer in externen Partnerorganisationen freizugeben. Weitere Informationen zu Verbundvertrauensstellungen und der Freigabe im Verbund finden Sie unter Grundlegendes zum Verbund und unter Grundlegendes zur Verbunddelegierung.

Nachdem Sie über das MFG eine Verbundvertrauensstellung eingerichtet haben, kann die Freigabe zwischen zwei Partnerorganisationen erst dann erfolgen, wenn Sie eine Organisationsbeziehung erstellt haben. Standardmäßig wird die Freigabe zwischen Ihren Benutzern und den Benutzern in externen Partnerorganisationen jedoch mithilfe der standardmäßigen Freigaberichtlinie ermöglicht, die Benutzern zugewiesen wird. Die Richtlinie ermöglicht die Kalenderfreigabe nur mit Frei/Gebucht-Informationen für Benutzer in allen externen Partnerorganisationen. Wenn Sie nicht zulassen möchten, dass Benutzer ihren Kalender sowie Frei/Gebucht-Informationen für Benutzer in allen externen Partnerdomänen freigeben, müssen Sie die standardmäßige Freigaberichtlinie deaktivieren oder die in der Richtlinie angegebenen Domänennamen auf ausschließlich die Domänen ändern, mit denen eine Freigabe zulässig sein soll. Diese Änderung müssen Sie vornehmen, bevor Sie eine Verbundvertrauensstellung über MFG erstellen. Weitere Informationen finden Sie unter Deaktivieren einer Freigaberichtlinie und Konfigurieren der Einstellungen für Freigaberichtlinien.

Sie können sämtliche Verbundfunktionen für eine Organisation einschließlich der Verbunddelegierung deaktivieren, indem Sie die Verbundvertrauensstellung der Organisation über MFG entfernen. Weitere Informationen finden Sie unter Entfernen einer Verbundvertrauensstellung.

Secure/Multipurpose Internet Mail Extensions (S/MIME) ist ein Standard für das Verschlüsseln mit öffentlichem Schlüssel und das Signieren von MIME-Daten. Dies macht die Authentifizierung, Nachrichtenintegrität, Unanfechtbarkeit und Datenvertraulichkeit für Nachrichtendaten möglich. Mit S/MIME-Zertifikaten können Benutzer Nachrichten signieren und/oder verschlüsseln. Weitere Informationen zu S/MIME finden Sie unter Informationen zu S/MIME.

S/MIME ist eine clientseitige Technologie, die keine Interoperabilitätsanforderungen an E-Mail-Server stellt. Aus der Perspektive der Nachrichtenübermittlung werden mit S/MIME signierte oder verschlüsselte Nachrichten in der gleichen Weise wie Klartextnachrichten (nicht verschlüsselte Nachrichten) übertragen. Die eigentliche Darstellung der Nachricht erfolgt auf der Clientseite, nachdem Zertifikat und Nachricht auf Gültigkeit überprüft wurden. Bei Outlook Web App wird die Unterstützung für S/MIME mithilfe eines ActiveX-Steuerelements bereitgestellt. Obwohl Outlook Web App die meisten gängigen Browser wie Microsoft Internet Explorer, Mozilla Firefox und Safari unterstützt, sind ActiveX-Steuerelemente ein Merkmal von Internet Explorer. Benutzer von Outlook Web App, die andere Browser verwenden, können nicht auf S/MIME-Funktionen zugreifen und müssen ggf. einen anderen E-Mail-Client verwenden, der S/MIME unterstützt. Weitere Informationen zur Unterstützung von S/MIME in Outlook Web App finden Sie unter Outlook Web App und S/MIME.

Weitere Informationen zur Unterstützung von S/MIME in Outlook finden Sie unter Zertifikate und Kryptografie beim E-Mail-Nachrichtenversand in Outlook (Übersicht).

Obwohl S/MIME für Organisationen einige Sicherheitsvorteile bietet, sollten Sie bei der Beurteilung der Technologie Folgendes berücksichtigen:

  • Mit S/MIME verschlüsselte Nachrichten sind für die Organisation nicht transparent. Nachrichtensicherheitssoftware wie Antivirus- und Antispamprogramme kann den Nachrichteninhalt einschließlich des Nachrichtentexts und aller Anlagen nicht überprüfen.

  • Da Nachrichteninhalt und Anlagen verschlüsselt sind, können die Messagingrichtlinien Ihrer Organisation, einschließlich Transportregeln, nicht auf mit S/MIME verschlüsselte Nachrichten angewendet werden.

  • Werden mit S/MIME signierte Nachrichten in einer Weise geändert, dass sie den Messagingrichtlinien Ihrer Organisation entsprechen, indem beispielsweise ein Haftungsausschluss oder eine personalisierte Signatur hinzugefügt wird, wird die Nachricht damit ungültig.

  • Der Inhalt von verschlüsselten Nachrichten kann nicht auf Inhaltsverletzungen überprüft werden, und die Organisation kann keine Vorsorge treffen, dass vertrauliche Informationen das Unternehmen nicht verlassen. Hierzu gehören auch Informationen, die eine persönliche Identifizierung ermöglichen.

  • Mit S/MIME verschlüsselte Nachrichten können von der Exchange-Suche nicht indiziert und daher auch mit Ermittlungsfunktion nicht durchsucht werden.

  • Damit bei eventuellen Rechtsstreitigkeiten die jeweiligen Vorschriften oder Offenlegungspflichten erfüllt werden können, muss Ihre Organisation möglicherweise unverschlüsselte Kopien aller verschlüsselten Nachrichten erstellen.

Exchange 2010 umfasst IRM-Funktionen, die es der Organisation ermöglichen, vertrauliche Nachrichteninhalte mit einem dauerhaften Schutz zu versehen, sodass nur angegebene Empfänger auf mit IRM geschützte Nachrichten zugreifen können. Die Organisation kann zudem auch Steuerungsmechanismen implementieren, mit denen vorgegeben wird, wie der Inhalt nach der Zustellung an die Empfänger verwendet werden kann. So können Sie beispielsweise verhindern, dass Nachrichten gedruckt, beantwortet oder innerhalb oder außerhalb der Organisation weitergeleitet werden. Darüber hinaus kann Ihre Organisation die per IRM geschützten Inhalte entschlüsseln, um sie mit Antivirus- und Antispamsoftware und anderen Transport-Agents zu scannen, es können Messagingrichtlinien angewendet werden, die Transportregeln verwenden, und per IRM geschützte Nachrichten können archiviert und durchsucht werden. IRM-Funktionen stehen zudem in allen Webbrowsern zur Verfügung, die von Outlook Web App und von Windows Mobile-Geräten unterstützt werden. Weitere Informationen zu IRM finden Sie unter Grundlegendes zur Verwaltung von Informationsrechten.

In diesem Abschnitt geht es um sicherheitsrelevante Überlegungen zur Exchange 2010-Serverrolle.

In Exchange 2010 wurden architekturspezifische Änderungen am Exchange-Informationsspeicher und an der Konnektivität von MAPI-Clients wie Outlook vorgenommen. MAPI-Clients stellen die Verbindung zum Clientzugriffsserver her. Dadurch wird der Postfachserver vom Clientdatenverkehr isoliert. Postfachserver kommunizieren nur mit Clientzugriffsservern, die RPCSec verwenden, und mit Active Directory-Domänendienst-Servern (AD DS) in Ihrer Organisation. Für Postfachserver ist keine Internetkonnektivität erforderlich.

Der Speicher ist eine wichtige Komponente von Postfachservern. Sie müssen das Speichersubsystem des Postfachservers so planen, dass für Ihre Bereitstellung eine zufriedenstellende Leistung sowie ausreichend Speicherplatz gewährleistet sind. Weitere Informationen zum Planen des Speichers des Postfachservers finden Sie unter Speicherentwurf für Postfachserver.

Nach der Bereitstellung des Postfachservers sollten Sie Folgendes überwachen:

  • Verfügbarkeit des Speichersubsystems

  • Verfügbarkeit von ausreichend freiem Speicherplatz auf Volumes, die die Postfachdatenbank und die Transaktionsprotokolle enthalten Die Bereitstellung einer Postfach- oder Öffentliche Ordner-Datenbank wird aufgehoben, wenn das Volume, auf dem die Datenbank oder die Transaktionsprotokolle gespeichert werden, nicht mehr genügend freien Speicherplatz aufweist.

Sie können Microsoft Federation Gateway und System Center Operations Manager verwenden, um die Speicherverfügbarkeit und den freien Speicherplatz zu überwachen. Weitere Informationen finden Sie unter Systems Center Operations Manager 2007.

Wenn Sie die folgenden Funktionen verwenden möchten, müssen Sie bei der Planung und Überwachung des Speichers deren Speicheranforderungen berücksichtigen:

  • Journale   Wenn Sie zum langfristigen Archivieren von Nachrichten Journale verwenden, werden Nachrichten, die von allen und an alle Empfänger in einer Postfachdatenbank oder von den bzw. an die in einer Journalregel angegebenen Empfänger gesendet werden, in Abhängigkeit davon, ob Sie Standardjournale (pro Postfachdatenbank) oder Premiumjournale (Journalregeln) einsetzen, in einem Journalbericht an das Journalpostfach oder die angegebenen Empfänger übermittelt. Hieraus ergibt sich ggf. eine größere Anzahl an Journalberichten, die an ein Journalpostfach zugestellt werden. Bei der Planung des Speichers für Postfachserver müssen Sie daher die Größe der Journalpostfächer berücksichtigen. Sie können die Größe der Journalpostfächer steuern, indem Sie für ein Journalpostfach ein ausreichendes Postfachkontingent konfigurieren. Weitere Informationen zur Journalfunktion und zu Postfachkontingenten finden Sie in den folgenden Themen:

  • Aufbewahrung für eventuelle Rechtsstreitigkeiten   Wenn Sie ein Postfach für eventuelle Rechtsstreitigkeiten aufbewahren, werden Elemente, die vom Benutzer mithilfe der Funktion "Gelöschte Elemente wiederherstellen" in Outlook und Outlook Web App gelöscht wurden, sowie Nachrichten, die von automatisierten Prozessen wie MRM gelöscht wurden, aufbewahrt, bis das Rechtsverfahren abgeschlossen ist, d. h., bis der Aufbewahrungsstatus entfernt wird. In Exchange 2010 ist das Warnkontingent für wiederherstellbare Elemente und das Kontingent für wiederherstellbare Elemente auf 20 bzw. 30 GB festgelegt. Weitere Informationen finden Sie in den folgenden Themen:

Die Hochverfügbarkeit von Postfachservern ist für die Sicherstellung der Verfügbarkeit des Messagingdiensts von ausschlaggebender Bedeutung. Exchange 2010 enthält Database Availability Groups (DAGs) für die Hochverfügbarkeit von Postfachservern. DAGs können für Verfügbarkeit sorgen, wenn in Ihrer Exchange-Bereitstellung ein Fehler im Speichersubsystem, beim Server oder bei der Netzwerkkonnektivität auftritt oder wenn es zu einem Ausfall des gesamten Datencenters kommt. Weitere Informationen zur Planung und Implementierung einer hoch verfügbaren Exchange 2010-Bereitstellung finden Sie unter Hohe Verfügbarkeit und Ausfallsicherheit für Standorte.

Standardmäßig wird der Replikationsdatenverkehr (Protokollversand) zwischen DAG-Mitgliedern, die sich an unterschiedlichen Active Directory-Standorten befinden, in Exchange 2010 verschlüsselt. Sie können den Replikationsdatenverkehr zwischen Servern am gleichen Active Directory-Standort verschlüsseln, indem Sie die Eigenschaft "NetworkEncryption" von DAGs auf "Aktiviert" festlegen. Verwenden Sie das Cmdlet Set-DatabaseAvailabilityGroup, um diese Eigenschaft für eine DAG zu ändern.

Die Replikation erfolgt über einen einzigen TCP-Port, standardmäßig TCP-Port 64327. Sie können den für die Replikation verwendeten Port ändern. Weitere Informationen finden Sie unter Konfigurieren der Eigenschaften der Datenbankverfügbarkeitsgruppe.

Parameter für Hochverfügbarkeit

Parameter Beschreibung

NetworkEncryption

Der Parameter NetworkEncryption gibt an, ob die Netzwerkverschlüsselung aktiviert ist. Gültige Werte sind:

  • Disabled   Für alle Netzwerke deaktiviert

  • Enabled   Für alle Netzwerke aktiviert

  • InterSubnetOnly   Nur für die Kommunikation zwischen Subnetzen aktiviert

  • SeedOnly   Nur für Seeding aktiviert

Standard   InterSubnetOnly

ReplicationPort

Der Parameter ReplicationPort gibt einen TCP-Port (Transmission Control Protocol) für Replikationsaktivitäten (Protokollversand und Seeding) an.

Standard   Wird dieser Parameter nicht angegeben, wird TCP-Port 64327 als Standardport für die Replikation verwendet.

Standardmäßig ermöglicht Exchange 2010 Administratoren keinen Zugriff auf Postfächer. Wenn in Ihrer Organisation Anwendungen oder Dienste verwendet werden, für die der Zugriff auf ein Postfach erforderlich ist, müssen Sie den Konten, die von diesen Anwendungen oder Diensten verwendet werden, die geeigneten Postfachberechtigungen zuweisen. Es empfiehlt sich, derartige Anwendungen oder Dienste nicht für die Verwendung von Administratoranmeldeinformationen zu konfigurieren.

Obwohl alle Postfächer potenziell vertrauliche Informationen enthalten können, die für eine Organisation von Belang sind, sollte den folgenden Postfächer aus Sicherheitsgründen besondere Aufmerksamkeit zukommen, und die Berechtigungen zum Zugriff auf diese Postfächer müssen kontrolliert und überwacht werden, um den Sicherheitsanforderungen der Organisation gerecht zu werden.

  • Discoverypostfächer   Discoverypostfächer werden von der Exchange 2010-Funktion für die Suche in mehreren Postfächern verwendet. Hiermit können Discovery-Manager, die Mitglied der Rollengruppe "Discoveryverwaltung" sind, Nachrichten in allen Postfächer einer Exchange 2010-Organisation suchen. Von der Discoverysuche zurückgegebene Nachrichten werden in das angegebene Discoverypostfach kopiert. Bei Exchange 2010-Setup wird ein Standarddiscoverypostfach erstellt. Weitere Informationen finden Sie unter Grundlegendes zur Suche in mehreren Postfächern.

  • Journalpostfächer   Wenn Sie für eine Postfachdatenbank die Journalfunktion konfigurieren oder Journalregeln erstellen, um Nachrichten an bestimmte Empfänger und von bestimmten Empfängern in einem Journal zu erfassen, werden Journalberichte an das angegebene Journalpostfach übermittelt. Weitere Informationen finden Sie in den folgenden Themen:

Zusätzlich zum Schutz dieser Postfächer kann der Administrator auch Transportregeln verwenden, um den Nachrichteninhalt zu überprüfen sowie eine Kopie der Nachricht an einen anderen Empfänger – sogar einen Bcc-Empfänger – zu senden. Die Berechtigungen, die für die Verwaltung von Transportregeln erforderlich sind, finden Sie im Abschnitt zu Transportregeln im Thema Messagingrichtlinie und einhaltung Berechtigungen. Es empfiehlt sich, die Erstellung und Änderung von Transportregeln mit den geeigneten Kontrollmechanismen zu überwachen und zu steuern und Transportregelaktionen für alle Regeln regelmäßig einem Audit zu unterziehen.

Unter Exchange 2010 stellen die folgenden Clients für den Zugriff auf Postfächer Verbindungen zu Clientzugriffsservern her:

  • Outlook-Clients, die MAPI verwenden

  • Outlook-Clients, die Outlook Anywhere verwenden

  • Webbrowser, die Outlook Web App verwenden

  • Mobile Geräte, die Exchange ActiveSync verwenden

  • POP3- und IMAP4-Clients

  • Anwendungen, die Exchange-Webdienste (EWS) verwenden

Standardmäßig werden diese Clientzugriffsmethoden über verschlüsselte Datenpfade gesichert. Ebenso standardmäßig verwenden Outlook-Clients, die mit MAPI auf einen Clientzugriffsserver zugreifen, die RPC-Verschlüsselung. Der Zugriff mit Outlook Web App, Outlook Anywhere und Exchange ActiveSync wird mit SSL (Secure Sockets Layer) gesichert.

Für den externen Clientzugriff müssen Sie Zertifikate erwerben und installieren, die von einer Zertifizierungsstelle (Certification Authority, CA) signiert sind, der der Client vertraut. Weitere Informationen finden Sie unter Verwalten von SSL für einen Clientzugriffsserver.

POP3- und IMAP4-Dienste sind auf Exchange 2010-Clientzugriffsservern standardmäßig deaktiviert. Wenn Sie diese Dienste aktivieren, empfiehlt es sich, TLS oder SSL zu verwenden, um mit diesen Protokollen zur Sicherung der Kommunikation beizutragen. Weitere Informationen finden Sie in den folgenden Themen:

Werden Clientzugriffsserver für den externen Zugriff veröffentlicht, empfiehlt es sich zudem, die geeigneten Firewalls und Zugriffssteuerungen einzusetzen. Microsoft Forefront Threat Management Gateway (TMG) 2010 enthält Veröffentlichungs-Assistenten, mit denen Exchange 2010-Clientzugriffsserver auf einfache und sichere Weise für den externen Zugriff veröffentlicht werden können. Weitere Informationen finden Sie unter Forefront Threat Management Gateway (TMG) 2010.

importantWichtig:
Die Implementierung von Clientzugriffsservern in Umkreisnetzwerken wird nicht unterstützt.

Auf Clientzugriffsservern wird IIS (Internet Information Server) verwendet, um über HTTP den Zugriff auf Dienste wie Outlook Web App, Exchange ActiveSync, Outlook Anywhere, AutoErmittlung, die Exchange-Systemsteuerung (ECP), die Exchange-Webdienste und das Offlineadressbuch (OAB) zu gewähren. Für Remote-PowerShell wird ebenfalls IIS verwendet. Darüber hinaus werden alle RPS-Anforderungen, einschließlich Anforderungen der Exchange-Verwaltungskonsole (EMC), in IIS-Protokollen erfasst. Die IIS-Protokolle können im Lauf der Zeit eine große Menge Speicherplatz in Anspruch nehmen. IIS, eine Komponente von Windows Server, enthält keinen Mechanismus zum Löschen älterer Protokolle auf Basis der Größe des Verzeichnisses, in dem sich die Protokolldateien befinden. Es hat sich daher bewährt, IIS-Protokolle auf ein Volume zu verschieben, auf dem sich kein Betriebssystem befindet, sodass das Wachstum der Protokolldateien nicht bewirkt, dass auf dem Systemdatenträger schließlich nicht mehr genügend Speicherplatz verfügbar ist und unter Umständen der Dienst ausfällt. Sie sollten das Wachstum der Protokolldatei überwachen und einen Mechanismus implementieren, mit dem Protokolle je nach Bedarf manuell archiviert oder gelöscht werden. Weitere Informationen finden Sie unter Konfigurieren der Protokollierung in IIS 7.

Exchange 2010 stellt zwei Transportserverrollen bereit, die für jeweils unterschiedliche Zwecke entwickelt wurden.

  • Edge-Transport   Die Edge-Transport-Serverrolle ist ein Transportserver, der keiner Domäne angehört und der sich normalerweise in Umkreisnetzwerken befindet. Hierüber werden Nachrichten zwischen Ihrer Exchange-Organisation und externen SMTP-Hosts übertragen. Obwohl sie eigentlich für Umkreisnetzwerke entwickelt wurden, können Edge-Transport-Server auch im internen Netzwerk implementiert und als Mitgliedsserver einer Active Directory-Domäne hinzugefügt werden.

  • Hub-Transport   Die Hub-Transport-Serverrolle überträgt Nachrichten innerhalb der Organisation, einschließlich Nachrichten zwischen Exchange-Servern, Nachrichten von SMTP-Clients (über POP3 und IMAP4) sowie Nachrichten von Anwendungsservern und Geräten.

Unter Exchange 2010 wird die SMTP-Kommunikation standardmäßig mit TLS gesichert.

SMTP-Kommunikation zwischen Hub-Transport-Servern   Die Hub-Transport-Server in einer Exchange-Organisation verwenden TLS, um zur Sicherung der SMTP-Kommunikation in der Organisation beizutragen. Es empfiehlt sich, TLS auf Hub-Transport-Servern aktiviert zu lassen. Unter Exchange 2010 können Organisationen, die andere Geräte oder Vorrichtungen als Exchange für die TLS-Verschlüsselung verwenden, TLS von den Hub-Transport-Servern auf diese Geräte auslagern. Weitere Informationen finden Sie unter Deaktivieren von TLS zwischen Active Directory-Standorten zur Unterstützung der WAN-Optimierung.

SMTP-Kommunikation zwischen Hub-Transport- und Edge-Transport-Servern   Der gesamte Datenverkehr zwischen Hub-Transport- und Edge-Transport-Servern wird authentifiziert und verschlüsselt. Der zugrundeliegende Mechanismus für Authentifizierung und Verschlüsselung ist MTLS (Mutual TLS). Statt die X.509-Gültigkeitsprüfung zur Zertifikatüberprüfung zu verwenden, verwenden Exchange 2010-Benutzer direkte Vertrauensstellungen zum Authentifizieren der Zertifikate. "Direkte Vertrauensstellung" bedeutet, dass das Vorhandensein des Zertifikats in Active Directory oder AD LDS (Active Directory Lightweight Directory Services) die Gültigkeit des Zertifikats bezeugt. Active Directory wird als vertrauenswürdiger Speicherungsmechanismus angesehen. Wenn die direkte Vertrauensstellung verwendet wird, ist es nicht von Bedeutung, ob das Zertifikat selbstsigniert ist oder von einer Zertifizierungsstelle signiert wurde. Wenn Sie einen Edge-Transport-Server bei einem Active Directory-Standort anmelden, veröffentlicht das Edge-Abonnement das Zertifikat des Edge-Transport-Servers in Active Directory. Hub-Transport-Server betrachten das veröffentlichte Zertifikat als gültig. Der Microsoft-EdgeSync-Dienst aktualisiert AD LDS auf Edge-Transport-Servern, die über Hub-Transport-Server-Zertifikate verfügen, die vom Edge-Transport-Server als gültig erkannt wurden.

SMTP-Kommunikation zwischen Edge-Transport-Servern und externen Hosts   Unter Exchange 2010 wird die SMTP-Kommunikation zwischen Edge-Transport-Servern und anonymen Hosts standardmäßig unter Verwendung von opportunistischem TLS gesichert. Es wird kein von einer vertrauenswürdigen Zertifizierungsstelle ausgestelltes Zertifikat benötigt, und es sind keine Konfigurationsschritte erforderlich. Empfangsconnectors stellen TLS-Aushandlung für eingehende SMTP-Verbindungen bereit. Sendeconnectors versuchen ebenfalls, eine TLS-Aushandlung für alle ausgehenden SMTP-Verbindungen durchzuführen. Beim opportunistischen TLS erfolgt keine Zertifikatüberprüfung, daher können selbstsignierte Zertifikate verwendet werden. Weitere Informationen finden Sie unter TLS-Funktionen und die zugehörige Terminologie in Exchange 2010.

noteAnmerkung:
Hub-Transport-Server können standardmäßig nicht mit externen SMTP-Hosts kommunizieren, da es auf Hub-Transport-Servern keine Empfangsconnectors gibt, die die Kommunikation von anonymen Hosts zulassen. Sie können Hub-Transport-Server jedoch für die Kommunikation mit anonymen Hosts konfigurieren. Weitere Informationen finden Sie unter Direktes Konfigurieren der Internetnachrichtenübermittlung über einen Hub-Transport-Server. Von der Verwendung dieser Topologie wird jedoch abgeraten, da hiermit der Exchange 2010-Server und alle auf dem Server installierten Rollen über das Internet verfügbar gemacht werden, und dies bringt erhebliche Sicherheitsrisiken mit sich. Stattdessen sollten Sie ein auf Umkreisnetzwerken basierendes SMTP-Gateway wie den Edge-Transport-Server implementieren.

SMTP-Kommunikation zwischen Hub-Transport- oder Edge-Transport-Servern und Smarthosts   Unter Exchange 2010 können Sie einen Sendeconnector für das Weiterleiten von E-Mails für Remotedomänen an ein SMTP-Gateway konfigurieren, das sich im Allgemeinen im Umkreisnetzwerk befindet. Hierzu gehören auch E-Mails, die über das Internet gesendet werden. Obwohl es möglich ist, einen Sendeconnector zu erstellen, der E-Mails an einen Smarthost weiterleitet, ohne dass eine Authentifizierung erforderlich ist, empfiehlt es sich, für solche Connectors eine geeignete Authentifizierung zu verwenden. Bei Verwendung der Standardauthentifizierung ist die Standardauthentifizierung über TLS empfehlenswert. Wenn Sie sich für eine externe Sicherungsoption entscheiden, wird davon ausgegangen, dass die Authentifizierung über einen nicht von Exchange bereitgestellten Mechanismus wie IPsec erfolgt. Beim Konfigurieren des Connectors mit der Adresse eines Smarthosts können Sie entweder die IP-Adresse des Smarthosts oder dessen FQDN (Fully-Qualified Domain Name, vollqualifizierter Domänenname) verwenden. Es empfiehlt sich, die IP-Adresse des Smarthosts zu verwenden, da diese Schutz vor DNS-Poisoning (Angriff, bei dem es gelingt, die Zuordnung zwischen einer URL und der zugehörigen IP-Adresse zu fälschen) bietet, wobei die Verwendung des FQDNs jedoch komfortabler ist.

Verwenden von Domänensicherheit für die SMTP-Kommunikation mit Partnern   Unter Exchange 2010 können Sie Domänensicherheit verwenden, um zur Sicherung der Nachrichtenkommunikationspfade zu Partnerdomänen beizutragen. Im Zuge der Domänensicherheit wird zur Gewährleistung sitzungsbasierter Verschlüsselung und Authentifizierung MTLS verwendet. Bei der MTLS-Authentifizierung überprüfen die Quell- und Zielhosts die Verbindung mit einer X.509-Zertifikatüberprüfung. Transportserver, die mit für Domänensicherheit konfigurierten Partnerdomänen kommunizieren, benötigen ein von einem vertrauenswürdigen Drittanbieter oder einer internen Zertifizierungsstelle signiertes Zertifikat. Bei Verwendung einer internen Zertifizierungsstelle muss die Zertifikatsperrliste (Certificate Revocation List, CRL) veröffentlicht werden und vom Partnerhost aus einsehbar sein. Weitere Informationen finden Sie in den folgenden Themen:

Exchange 2010 verwendet den standardmäßigen SMTP-Port (TCP-Port 25) für die SMTP-Kommunikation. Bei Exchange-Setup werden die erforderlichen Firewallregeln in der Windows-Firewall mit erweiterter Sicherheit erstellt, um die Kommunikation über Standardports zu ermöglichen. Wenn Sie für einen Connector einen anderen Port angeben, passt Exchange die Firewallregeln nicht an und erstellt auch nicht automatisch eine neue Regel, um die Kommunikation über den nicht standardmäßigen Port zuzulassen. Sie müssen die Firewallkonfiguration manuell anpassen, damit die Kommunikation über nicht standardmäßige Ports zugelassen wird. Wenn Sie einen Empfangsconnector für einen nicht standardmäßigen Port konfigurieren, müssen auch die SMTP-Clients, die Nachrichten an den Connector übermitteln, für die Verwendung des nicht standardmäßigen Ports konfiguriert werden.

Unter Exchange 2010 können Sie die Hub-Transport-Serverrolle auf einem Exchange 2010-Postfachserver installieren. Dies schließt auch einen Postfachserver ein, der Mitglied einer Database Availability Group (DAG) ist. Es empfiehlt sich jedoch, die Hub-Transport-Serverrolle nicht auf einem Postfachserver zu installieren, insbesondere in Topologien, in denen keine Edge-Transport-Server bereitgestellt werden, um die Postfachserver vom Internet zu isolieren. Sie können die Hub-Transport-Serverrolle auf Clientzugriffsservern installieren. Wenn Serverrollen jedoch auf demselben Server zusammengefasst werden, müssen Sie die Größenrichtlinien für jede einzelne Serverrolle berücksichtigen.

Bei Angabe eines Smarthosts für einen Sendeconnector auf einem Hub-Transport- oder Edge-Transport-Server ist es ratsam, IP-Adressen anstelle des FQDN des Smarthosts zu verwenden, um Schutz vor DNS-Poisoning und -Spoofing zu bieten. Damit werden zudem die Auswirkungen von DNS-Ausfällen auf die Transportinfrastruktur minimiert. DNS-Server, die sich in Umkreisnetzwerken befinden, dürfen nur für die ausgehende Auflösung verwendet werden. Die DNS-Server in Umkreisnetzwerken enthalten ggf. Einträge für Hub-Transport-Server. Sie können auch Hosts-Dateien auf Edge-Transport-Servern verwenden, um die Erstellung von Einträgen für Hub-Transport-Server auf DNS-Servern zu verhindern, die sich in Umkreisnetzwerken befinden.

Neben den in diesem Abschnitt erörterten Schritten sollten Sie auch erwägen, auf Connectors ausreichende Nachrichtengrößenbeschränkungen und auf Transportservern Nachrichteneinschränkungseinstellungen zu verwenden. Weitere Informationen finden Sie in den folgenden Themen:

Bei der Planung der Bereitstellung der Unified Messaging-Serverrolle müssen Sie die von UM verwendeten unterschiedlichen Kommunikationskanäle für die Kommunikation mit IP-Gateways oder IP-PBX-Anlagen berücksichtigen.

Nach der Konfiguration von UM-Wähleinstellungen kommunizieren diese standardmäßig im Modus "Ungesichert". Darüber hinaus senden und empfangen Unified Messaging-Server, die über UM-Wähleinstellungen verfügen, Daten von IP-Gateways, IP-PBX-Anlagen und anderen Exchange 2010-Computern ohne jede Verschlüsselung. Im ungesicherten Modus werden weder der RTP-Medienkanal (Real-Time Transport Protocol) noch die SIP-Signalinformationen verschlüsselt.

Sie können einen Unified Messaging-Server für die Verwendung von MTLS zur Verschlüsselung des SIP- und RTP-Datenverkehrs konfigurieren, der von anderen Geräten und Servern gesendet und empfangen wird. Wenn Sie einen Unified Messaging-Server zu einem Satz mit UM-Wähleinstellungen hinzufügen und die Wähleinstellungen für die Verwendung des SIP-gesicherten Modus konfigurieren, wird nur der SIP-Signalverkehr verschlüsselt, und die RTP-Medienkanäle verwenden weiterhin TCP. TCP ist nicht verschlüsselt. Wenn Sie jedoch einen Unified Messaging-Server zu einem Satz mit UM-Wähleinstellungen hinzufügen und die Wähleinstellungen für die Verwendung des SIP-gesicherten Modus konfigurieren, werden sowohl der SIP-Signalverkehr als auch die RTP-Medienkanäle verschlüsselt. Ein sicherer Signalmedienkanal, der SRTP (Secure Real-Time Transport Protocol) nutzt, verwendet auch MTLS zum Verschlüsseln der VoIP-Daten.

Wenn das von Ihnen verwendete IP-Gateway oder die IP-PBX-Anlage IPsec unterstützen, können Sie auch IPsec verwenden, um zur Sicherung der Kommunikation zwischen einem UM-Server und dem IP-Gateway oder der IP-PBX-Anlage beizutragen.

Weitere Informationen finden Sie unter Grundlegendes zu Unified Messaging VoIP-Sicherheit.

UM übermittelt zudem Nachrichten wie Benachrichtigungen über verpasste Anrufe und Voicemailnachrichten an Hub-Transport-Server. Standardmäßig erfolgt diese Kommunikation über SMTP unter Verwendung der TLS-Verschlüsselung.

Sie können eine UM-Postfachrichtlinie für den Zugriff ohne PIN konfigurieren. Damit kann ein Anrufer auf Voicemail zugreifen, ohne auf Basis der Anrufer-ID des Anrufs eine PIN eingeben zu müssen. Spoofing der Anrufer-ID ist nicht von Bedeutung. Es empfiehlt sich, den Zugriff auf Voicemail ohne PIN nicht zuzulassen. Darüber hinaus ist es ratsam, die standardmäßigen PIN-Einstellungen zu überprüfen und diese so zu konfigurieren, dass sie den Sicherheitsanforderungen Ihrer Organisation entsprechen. Die folgenden Einstellungen können mit dem Cmdlet Set-UMMailboxPolicy für eine UM-Postfachrichtlinie konfiguriert werden:

Parameter zum Steuern der Benutzer-PIN für den Zugriff auf Voicemail

Parameter Beschreibung

AllowCommonPatterns

Der Parameter AllowCommonPatterns gibt an, ob offensichtliche PINs zugelassen werden sollen. Beispiele für offensichtliche PINs sind u. a. Teile der Telefonnummer sowie aufeinanderfolgende oder sich wiederholende Ziffern. Wenn der Parameter auf "$false" festgelegt ist, aufeinanderfolgende und sich wiederholende Ziffern und das Suffix der Postfachdurchwahl zurückgewiesen. Wenn er auf "$true" festgelegt ist, wird nur das Suffix der Postfachdurchwahl zurückgewiesen.

AllowPinlessVoiceMailAccess

Der Parameter AllowPinlessVoiceMailAccess gibt an, ob Benutzer, die der UM-Postfachrichtlinie zugeordnet sind, für den Zugriff auf ihre Voicemailnachrichten eine PIN verwenden müssen. Für den Zugriff auf E-Mail-Nachrichten und den Kalender ist nach wie vor eine PIN erforderlich.

Standard   Deaktiviert ($false)

LogonFailusresBeforePINReset

Der Parameter LogonFailuresBeforePINReset gibt die Anzahl aufeinanderfolgender, nicht erfolgreicher Anmeldeversuche an, die zugelassen werden, bevor die Postfach-PIN automatisch zurückgesetzt wird. Zum Deaktivieren dieser Funktion legen Sie den Parameter auf "Unbegrenzt" fest. Wenn dieser Parameter nicht auf "Unbegrenzt" festgelegt ist, muss ein geringerer Wert als der Wert des Parameters MaxLogonAttempts festgelegt werden. Der Wertebereich ist 0 bis 999.

Standard   5 Fehleingaben

MaxLogonAttempts

Der Parameter MaxLogonAttempts gibt die Anzahl aufeinanderfolgender, nicht erfolgreicher Anmeldeversuche an, die ein Benutzer ausführen kann, bevor die UM-Postfächer gesperrt werden. Der Wertebereich ist 1 bis 999.

Standard   15 Versuche

MinPINLength

Der Parameter MinPINLength gibt die Mindestanzahl von Stellen an, die für eine PIN für UM-aktivierte Benutzer erforderlich sind. Der Wertebereich ist 4 bis 24.

Standard   6 Stellen

PINHistoryCount

Der Parameter PINHistoryCount gibt die Anzahl vorheriger PINs an, die gespeichert und bei einem Zurücksetzen der PIN nicht mehr zugelassen werden. Dieser Wert umfasst auch das erste Festlegen der PIN. Der Wertebereich ist 1 bis 20.

Standard   5 PINs

PINLifetime

Der Parameter PINLifetime gibt die Anzahl von Tagen an, nach denen ein neues Kennwort erforderlich ist. Der Wertebereich ist 1 bis 999. Wenn Sie "Unbegrenzt" angeben, laufen die PINs der Benutzer nie ab.

Standard   60 Tage

In Exchange 2010 können Voicemailnachrichten als geschützt gekennzeichnet werden. Voicemailnachrichten werden mithilfe von IRM (Information Rights Management, Verwaltung von Informationsrechten) geschützt. Sie können die Schutzeinstellungen für Voicemail über die folgenden Parameter in einer UM-Postfachrichtlinie konfigurieren. Weitere Informationen finden Sie in den folgenden Themen:

Parameter für geschützte Voicemail

Parameter Beschreibung

ProtectAuthenticatedVoicemail

Der Parameter ProtectAuthenticatedVoiceMail gibt an, ob über UM-Server (Unified Messaging), die Outlook Voice Access-Anrufe für UM-aktivierte Benutzer beantworten, die der UM-Postfachrichtlinie zugeordnet sind, geschützte Voicemailnachrichten erstellt werden. Wenn der Wert auf "Private" festgelegt ist, werden nur als privat gekennzeichnete Nachrichten geschützt. Wenn der Wert auf "All" festgelegt ist, werden alle Voicemailnachrichten geschützt.

Standard   Kein (Voicemailnachrichten werden nicht geschützt)

ProtectUnauthenticatedVoiceMail

Der Parameter ProtectUnauthenticatedVoiceMail gibt an, ob über UM-Server (Unified Messaging), die Anrufe für UM-aktivierte Benutzer beantworten, die der UM-Postfachrichtlinie zugeordnet sind, geschützte Voicemailnachrichten erstellt werden. Dies gilt auch, wenn eine Nachricht von einer automatischen UM-Telefonzentrale an einen UM-aktivierten Benutzer gesendet wird, der der UM-Postfachrichtlinie zugeordnet ist. Wenn der Wert auf "Private" festgelegt ist, werden nur als privat gekennzeichnete Nachrichten geschützt. Wenn der Wert auf "All" festgelegt ist, werden alle Voicemailnachrichten geschützt.

Standard   Kein (Voicemailnachrichten werden nicht geschützt)

RequireProtectedPlayOnPhone

Der Parameter RequireProtectedPlayOnPhone gibt an, ob Benutzer, die der UM-Postfachrichtlinie zugeordnet sind, für geschützte Voicemailnachrichten nur die Funktion "Wiedergabe über Telefon" verwenden oder auch Multimediasoftware einsetzen können, um die geschützte Nachricht wiederzugeben.

Standard   $false Die Benutzer können geschützte Voicemailnachrichten über beide Methoden abhören.

importantWichtig:
Damit UM-Server weiterhin Anrufe beantworten können, ist es wichtig, dass sie auf Active Directory zugreifen können. Es empfiehlt sich, die Verfügbarkeit von Active Directory zu überwachen.

In diesem Abschnitt werden Links zu zusätzlicher sicherheitsbezogener Exchange-Dokumentation bereitgestellt.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft. Alle Rechte vorbehalten.