Evaluation einer zentralen E-Mail-Domain für Unternehmen mit Sitz in unterschiedlichen Ländern & Lokalitäten
Aus Winfwiki
| Name des Autors / der Autoren: | Dennis Bersau |
| Titel der Arbeit: | Evaluation einer zentralen E-Mail-Domain für Unternehmen mit Sitz in unterschiedlichen Ländern & Lokalitäten |
| Hochschule und Studienort: | FOM Düsseldorf |
Inhaltsverzeichnis |
1 Einleitung
Das Thema E-Mail-Kommunikation ist in der heutigen Zeit nicht mehr wegzudenken und immer wichtiger für Unternehmen geworden. Es ist zum Hauptbestandteil der Kommunikation innerhalb des eigenen Unternehmens oder auch Unternehmensübergreifend herangewachsen. Mittlerweile bietet fast jedes Unternehmen, sei es auch noch so klein, seinen Kunden die Möglichkeit mit Ihnen per E-Mail in Kontakt zu treten. Dies ist natürlich auch dem Internet und dem neuen vernetzten Zeitalter zu Verdanken. Ein Unternehmen erhält durch eine zentrale E-Mail-Domain ein einheitliches Auftreten nach Aussen und stärkt damit die Coperate Identity. Zusätzlich wird die gesamte Infrastruktur für die E-Mail-Kommunikation vereinfacht durch eine neue zentrale Administration. Durch eine zentrale Stelle der E-Mail-Verteilung und -Filterung können Kosten eingespart werden, da nicht an jedem Standort eine enstsprechende Filterung von Viren und Spam erbracht werden muss. Um das Thema einzugrenzen handelt diese Seminarbeit über den Einsatz eines zentralen E-Mail-Knoten innerhalb eines Großkonzerns.
2 Einsatzszenarien
Es ist generell egal ob ein Unternehmen im Mittelstand beheimatet oder als Großunternehmen auf der ganzen Welt bekannt ist. Wenn es einen Sitz in unterschiedlichen Ländern bzw. Lokalitäten hat, macht es Sinn über eine zentrale E-Mail-DOmain mit einen zentralen E-Mail-Knoten nachzudenken. In der Regel hat jedes Land seine eigene Top-Level-Domain (TLD) und unterschiedliche Standorte können ebenfalls durchaus unterschiedliche Domains besitzen. Oft gibt es für jede E-Mail-Domain auch einen dedizierten E-Mail-Knoten. Es muss also für jeden Knoten eine entsprechende Anti-Viren- und Anti-Spam-Lösung gefunden werden.
Stellt man eine zentrale Lösung bereit, können enorme Kosten gespart werden. Dies macht bei Großkonzernen natürlich mehr aus als bei kleinen Unternehmen, aber selbst für diese kann es sich lohnen.
Mögliche Einsatzmöglichkeiten, um diese zentrale Platform zu schaffen, können Internetanbieter wie GoogleMail, web.de oder GMX sein. Diese sind i.d.R. aber eher ein Ansprechpartner für kleinere Unternehmen mit weniger als 3000 E-Mail-Adressen. Größere Konzerne verügen oft selber über ein oder mehrere Racks in einem Rechenzentrum oder betreiben gar selber eins. Somit wird hier eher auf die Alternative eigener Server zurrückgegriffen werden. Hierfür müssen allerdings bestimmte Vorrausetzungen geschaffen sein um eine sichere und saubere Kommunikation zwischen den Systemen zu gewährleisten!
In dieser Seminararbeit geht es hauptsächlich um die Umsetzung in Großkonzernen mit verschiedenen Rechenzentren in verschiedenen Ländern.
3 Umsätzungmöglichkeiten bei den unterschiedlichen Einsatzszenarien
3.1 Virtuelles Privates Netzwerk
Um eine sichere Verbindung zwischen den unterschiedlichen Lokalitäten und Rechenzentren herzustellen, ist es zwingend notwending ein verschlüsseltes Netzwerk einzurichten. Dies passiert aus einen einfachen Grund, kein Unternehmen wird eine komplett autake Leitung, durch verschiedene Länder, Städte, etc. legen und einen Single Point Of Failure riskieren, wenn ein ebenso sicheres Netzwerk über bereits vorhandene Datenkabel realisiert werden kann (besser bekannt als das Internet).
Es muss eine Site-to-SiteVPN Verbindung der jeweiligen Standorte stattfinden, genauer spezifiert würde man dies mit Intranet VPN erklären.[1]
In der Regel werden Virtuelle Private Networks mit Internet Protocol Security (IPsec) verschlüsselt, da dieses Protokol direkt auf der Vermittlungsschicht des OSI-Modells arbeitet.[2] Durch neue Techniken wie das Internet Key Exchange (IKEv2) Protocol[3] wurde die Authenzierung leichter und für Administratoren einfacher zu implementieren. Beide Parteien tauschen Ihre öffentliche Schlüssel aus und verhandeln dann über die weitere Verschlüsselung. So haben nach ingesamt 6 Schritten alle Verhandlungen und Austausche stattgefunden und es können Daten über eine sichere Verbindung verschickt werden.[4]
3.2 Identitätsmanagement
Die Userdaten für das IdM kommen aus einem Verzeichnis, oft Microsoft Active Directory, was wiederum in einem anderen Land stehen kann. Das IdM-System speichert diese Userdaten und ergänzt sie mit den jeweiligen Intranet-Applikationen und gewährt oder verweigert dem jeweiligen User dort den Zugriff. Durch diese zentrale Kontrollstelle ist es mit dem Einsatz eines IdM-System ebenfalls möglich, für die verschiedenen Intranet-Applikationen einen Single-Sign-On-Service (SSO) anzubieten. So muss sich der User nur das Passwort von seinem sogenannten NT-Account (Account für die Anmeldung am PC bzw. an Microsoft Windows) merken. Ein weiter Vorteil ist, dass durch SSO-Technik der User sich oft nur einmal anmelden muss (Seamless login).[7]
3.3 Domain Name System
3.4 Sicherheit & Datenschutz
Jedes Land hat unterschiedliche Bedingungen was die Kommunikation mit dem Medium E-Mail in Firmen betrifft. So müssen E-Mails eine bestimmte Zeit gespeichert werden bzw. zurück verfolgbar sein. Ebenfalls kann das anhängen eines Disclaimers an jede E-Mail beim verschicken vom Gesetzgeber vorgeschrieben werden oder auch das zusätzliche Filtern von ankommenden und abgehenden E-Mails. In Deutschland sind Beispielsweise Disclaimer bei verschickten E-Mail Nachrichten keine Pflicht, da Sie vor Gericht kaum nutzbar gemacht werden können. In Deutschland ist es z.B. auch gesetzlich verboten E-Mails seiner Mitarbeiter zu löschen. So müssen Spam-E-Mails eine bestimmte Zeit vorgehalten werden und bereits ausgelieferte E-Mails müssen zumindest ebenfalls in der Form verfolgbar sein, dass die komplette Nachricht bis zum Absender verfolgt werden kann.
Aus dem Internet annehmende Mail-Relay-Server müssen bei Konzernen die an der New Yorker Börse notiert sind, durch regelmäßige SOX Kontrollen auf die Sicherheit überprüft werden. Geprüft wird im ersten Hinblick, dass keine Viren, Malware oder ähnliche Bedrohungen das Intranet verseuchen.
In vielen Ländern ist es ebenfalls pflicht, als Unternehmen, bestimmte Angabe zu der jeweiligen Firma in seiner Signatur anzugeben. In Deutschland sind das die folgenden Angaben: Die exakte Firma inkl. Geschäftsform, Ort der Niederlassung oder Sitz der Gesellschaft, den Eintrag im Handelsregister, bei GmbH die Geschäftsführer, bei Unternehmen ohne natürlicher Person als Gesellschafter sämtliche Angaben zur Haftenden Gesellschaft bzw. bei Aktiengesellschaften die Namen aller Vorstandsmitglieder und dem Vorsitzenden des Aufsichtsrates.[10]
Als weiteres Beispiel gilt England. Dort wird vom Gesetzgeber vorgeschrieben, dass ein- und ausgehende E-Mails nochmals von einem speziellen Content-Filter überprüft werden. Dort werden bestimmte Gesetztesvorlagen geprüft.
4 Eingrenzungen
Die hier vorgestellte Lösung basiert auf einer User-Anzahl von 65.000. Als Mail-Relay-Server werden AnubisNetworks e4000 Appliances eingesetzt. Die Appliances arbeiten als Verteiler, Anti-Spam- & Anti-Virus-Lösung. Die Postfächer der User liegen auf unterschiedlichen Microsoft Exchange Servern an verschiedenen Standorten. Die Postfächer werden hier nicht weiter betrachtet.
Die Kommunikation der unterschiedlichen Standorte untereinander findet ebenfalls über den zenztralen E-Mail-Knoten statt. Die zu erwartenden ankommenden E-Mails aus dem Interent werden auf durchschnittlich 400.000 pro Stunde geschätzt, Spam mit eingerechnet.
Es gibt insgesamt 30 Unterschiedliche Standorte mit unterschiedlicher Anzahl an Benutzern.
5 Aufbau zentraler E-Mail Domain
Nachdem die Vorrausetzungen geklärt sind, geht es an die Planung des E-Mail-Knoten, dort ist zu beachten, dass die Infrastruktur die Massen an E-Mails, die durch eine entsprechende Anzahl an Mitarbeiter immer weiter steigen kann, gewachsen ist.
5.1 Aufbau Infrastruktur
Um die o.a. durchschnittlische Rate ankommender E-Mails auch verarbeiten zu können, braucht man mehr als nur einen Server. Nach Auswertung von Analysen & Statistiken werden 12 Mail-Relay-Server für Internet-E-Mails benötigt (MTA EXT), 6 Mail-Relay-Server für die Kommunikation zwischen den Unterschiedlichen Standorten und Richtung Internet (MTA INT). Desweiteren werden 8 Filter-Server für Internet-E-Mails (2L EXT) und 3 Filter-Server für interne Kommunikation (2L INT) benötigt. Um Redundant ausgelegt zu sein, werden jeweils 2 Server für LDAP/Spike (DS SPK) und dem Webserver mit der Administrationsoberfläche (Web Service) eingesetzt. Um Server im Rechenzentrum die Möglichkeit zu geben E-Mails zu verschicken, können zusätzliche Mail-Relay-Server eingesetzt werden. Diese werden dann als „Point of Present“ im jeweiligen Rechenzentrum untergebracht (DC PoP). Um eine ordentliche Lastverteilung zu gewährleisten werden vor jeder Gruppe von Servern Load-Balancer plaziert über die auch die komplette Kommunikation stattfindet.
5.2 Leistungsumfang
Bei einem komplexen System wie einem E-Mail-Knoten braucht es, wie in 5.1 beschrieben, eine enorme Masse an Server und entsprechender Leistung.
Die eingesetzten AnubisNetworks e4000 Appliances sind die Größten im Angebot von AnubisNetworks. Mit insgesamt 8 Kernen und 8GB Arbeitspeicher ist ein Server sehr Leistungstark. Die eingesetzte Software AnubisNetworks Mail Protection Service Enterprise Edition bietet viele Features in einer Lösung an. So kann zentralisiert auf einer grafischen Web-Administrationsoberfläche die gesamte Umgebung verwaltet und administiert werden. Durch unterschiedliche Benutzergruppen, können ebenfalls unterschiedliche Rechte vergeben werden. So ist es möglich einfache Aufgaben an den First-Level-Support zu übertragen und Kunden schneller bei Ihren Problemen zu helfen. So kann z.B. ein Mitarbeiter im Fist-Level-Support Mails verfolgen und sehen was mit Ihnen passiert ist (Quarantäne, Virus, Ausgeliefert, etc.). Sollten E-Mails in der Quarantäne gelandet sein, kann ebenfalls der Mitarbeiter des First-Level-Supports diese hieraus befreien und dem Kunden zustellen.
Die MPS Software setzt im Kampf gegen den Spam auf unterschiedliche Techniken, u.A. die bekannten Techniken real-time Blacklist oder Spam-Assassin , aber auch ein eigene Technik, dem Spike-Server, wo E-Mails auf spezielle Hinweise untersucht werden, z.B. Bilder.
| | | | | |||
| Layer | Component | Protocol | Layer | Component | ||
| A | INTERNET | 25/TCP | MTA LAYER | MTA | SMTP Traffic | |
| B | MTA LAYER | MTA | 389/TCP | SERVICES LAYER | LDAP Servers | E-Mail Alias Validation |
| B | MTA LAYER | MTA | 389/TCP | SERVICES LAYER | LDAP Servers | Routing Information |
| C | MTA LAYER | MTA | 25/TCP | MTA LAYER | MTA | SMTP Traffic |
| D | MTA LAYER | MTA | 53/TCP
53/UDP | MTA LAYER | DNS cache | Name resolution |
| E | MTA LAYER | Filter | 20025/UDP | SERVICES LAYER | Spike Servers | Pre queue filtering |
| F | MTA LAYER | MTA | 10025/TCP | DATA LAYER | Anubis Filters | Pre queue filtering |
| G | DATA LAYER | Filter | 20025/UDP | SERVICES LAYER | Spike Servers | Pre queue filtering |
| H | DATA LAYER | Filter | 389/TCP | SERVICES LAYER | LDAP Servers | User settings |
| I | DATA LAYER | Filter | 53/UDP | DATA LAYER | DNS cache | Name resolution |
| I | DATA LAYER | Data Cluster | 10001/TCP | DATA LAYER | Data Cluster | Distributed tracking |
| I | DATA LAYER | Data Cluster | 10001/TCP | DATA LAYER | Data Cluster | Distributed quarantine |
| J | MTA LAYER | MTA | 25/TCP | INTERNAL NETWORK | SMTP Traffic | |
| K | MTA LAYER | MTA | 25/TCP | INTERNET | SMTP Traffic | |
Die Tabelle beschreibt den Weg der E-Mail zum Postfach und welche Schritte abgearbeitet und Verbindungen dabei aufgebaut werden. Nachdem die E-Mail am Mail-Relay-Server angekommen ist, werden zuerst einfache LDAP-Abfragen getätigt, um festzustellen, ob der Empfänger uns auch bekannt ist. Ist dies der Fall, wird die E-Mail zur Weiterverarbeitung an einen anderen MTA verschickt. Dieser initiert die Abfrage ob die Sender-Adresse überhaupt gültig ist anhand einer DNS-Abfrage. Ergibt sich dort keine Antwort, wird direkt zum letzten Schritt gesprungen und die E-Mail rejected und dem Sender mitgeteilt, dass wir ein Problem mit seiner Adresse festgestellt haben. Ist alles ok mit dem Sender, beginnt die Prozedur des Filterns. Sind alle Standard-Filter abgearbeitet wird im LDAP nach speziellen Filtern (Blacklisten etc.) für den Empfänger nachgeschaut. Steht hier nichts Nachteiliges für den Sender drinne, beginnt die Aufsplittung der E-Mail-Information auf unterschiedliche Server (einfacher Log-Eintrag oder bei Quarantäne komplette E-.Mail), um auch bei einem Ausfall redundant zu sein. Wurden alle Tests erfolgreich absolviert wird die E-Mail entsprechend der Routing information ausgeliefert. Sollte dies nicht fall sein, meldet der Mail-Relay-Server eine Fehlermeldung an den Sender zurück.
In der Tabelle nicht erwähnt sind weitere zusätzliche Maßnahmen gegen Spam und für sichere E-Mail-Kommunikation. Diese sind das Sender Policy Framework (SPF) und die DomainKeys Identified Mail (DKIM) Signatures.
Beim SPF werden zusätzlich zu den normalen MX-Einträgen im DNS noch TXT-Einträge hinterlegt, wo alle Mail-Relay-Server hinterlegt sind, die E-Mails in das Internet schicken.[12] Der annehmende Mail-Relay-Server ruft die Informationen vom DNS ab und vergleicht diese mit dem absendenden Mail-Relay-Server. Sollte die IP nicht vorhanden sein, wird die E-Mail abgelehnt.
Wenn E-Mails mittels DKIM verschickt werden, werden diese mit einem privaten Schlüssel versehen und müssen vom Empfänger mit dem passenden öffentlichen Schlüssel wieder ausgepackt werden. Diese Technik des asymmetrischen Verschlüsselns ist bereits beim VPN gerne gesehen und eine sichere und erprobte Angelegenheit. Auch hier wird im DNS ein weiterer TXT-Eintrag mit dem entsprechenden öffentlichen Schlüssel gemacht.[13]
| | | | | |||
| Layer | Component | Protocol | Layer | Component | ||
| A | INTERNAL NETWORK (OpCo) | 25/TCP | MTA LAYER | MTA | SMTP Traffic | |
| B | MTA LAYER | MTA | 25/TCP | MTA LAYER | MTA | SMTP Traffic |
| C | MTA LAYER | MTA | 53/TCP
53/UDP | MTA LAYER | DNS Cache | Name resolution |
| D | MTA LAYER | MTA | 10025/TCP | DATA LAYER | Anubis Filter | Post queue filtering |
| E | DATA LAYER | Filter | 389/TCP | SERVICES LAYER | LDAP Servers | User settings |
| F | DATA LAYER | Filter | 53/UDP | DATA LAYER | DNS Cache | Name resolution |
| F | DATA LAYER | Data Cluster | 10001/UDP | DATA LAYER | Data Cluster | Distributed Tracking |
| F | DATA LAYER | Data Cluster | 10001/TCP | DATA LAYER | Data Cluster | Distributed Quarantine |
| G | MTA LAYER | MTA | 25/TCP | INTERNET | SMTP Traffic | |
| H | MTA LAYER | MTA | 25/TCP | CONTENT FILTER UK | SMTP Traffic originated from United Kingdom | |
| I | MTA LAYER | MTA | 25/TCP | CONTENT FILTER IE | SMTP Traffic originated from Ireland | |
Bei Ausgehenden E-Mails sieht die Kommunikation fast identisch aus. Auch hier werden vor dem Verschicken Richtung Internet einige Routineaufgaben durchgeführt. Darunter die Einfache Abfrage ob der Sender eine valide E-Mail-Adresse hat oder auch eine vereinfachte Form des Spam-Filters, in diesem Fall nur die Anubis-Filter, um zu verhindern, dass Spam über interne Kommunikations-Wege verschickt wird.
Wir sehen eine Besonderheit, sollte eine E-Mail von England oder Irland ins Internet geschickt werden, muss diese vorher über einen Content Filter. Diese E-Mails werden also noch einmal Richtung internes Netzwerk geschickt und dann direkt von den Content-Filter-Servern ins Internet versendet.
| | | | | |||
| Layer | Component | Protocol | Layer | Component | ||
| A | INTERNAL NETWORK (OpCo) | 25/TCP | MTA LAYER | MTA | SMTP Traffic | |
| B | MTA LAYER | MTA | 25/TCP | MTA LAYER | MTA | SMTP Traffic |
| C | MTA LAYER | MTA | 53/TCP
53/UDP | MTA LAYER | DNS Cache | Name resolution |
| D | MTA LAYER | MTA | 10025/TCP | DATA LAYER | Anubis Filter | Post queue filtering |
| E | MTA LAYER | Filter | 20025/TCP | SERVICES LAYER | Spike Servers | Pre queue filtering |
| F | DATA LAYER | Filter | 389/TCP | SERVICES LAYER | LDAP Servers | User settings |
| G | DATA LAYER | Filter | 53/UDP | DATA LAYER | DNS Cache | Name resolution |
| G | DATA LAYER | Data Cluster | 10001/UDP | DATA LAYER | Data Cluster | Distributed Tracking |
| G | DATA LAYER | Data Cluster | 10001/TCP | DATA LAYER | Data Cluster | Distributed Quarantine |
| H | MTA LAYER | MTA | 25/TCP | INTERNAL | SMTP Traffic | |
Um die E-Mail-Kommunikation zu vervollständigen bleibt nurnoch die Kommunikation zwischen den einzelnen Standorten, die ja ebenfalls über den zentralen E-Mail-Knoten stattfindet.
Es ähnelt dem verschicken Richtung Internet, jedoch wird hier aus Sicherheitsgründen nochmals eine weitere Spam-Erkennung, zusätzlich zu den Anubis-Filtern durchgeführt, dies geschieht in Form einer Abfrage auf die Spike-Server. Die Filter und Werte sind weniger „agressiv“ eingestellt als bei der E-Mail-Kommunikation vom Internet. Sinn dahinter ist wiederum das Abfangen von potentiellen Gefahren durch übernommene Rechner etc.
Bei allen E-Mail-Kommunikationswegen werden die E-Mails von zwei Anti-Virus-Programmen überprüft. Auch dies dient der Ausfallsicherheit, sollte ein Programm mal Probleme mit neuen Pattern-Updates bekommen oder das komplette Programm aktualisiert werden müssen.
Ein weiterer wichtiger Punkt in der E-Mail-Kommunikation ist der eigentliche SMTP Traffic. Jede E-Mail ist wie eine Postkarte für jeden lesbar, wenn er sich in die Verteilung einmischt.
Um dies effektiv zu erschweren wird jeder sendende Mail-Relay-Server zuerst aufgefordert die Kommunikation Verschlüsselt per Secure Socket Layer (SSL) bzw. per Transport Layer Security (TLS) Protokoll aufzubauen. Die Verschlüsselung findet in der Darstellungsschicht des OSI-Modells statt[14]. Dies ist allerdings immer noch keine 100% Sicherheit, dass die Daten nicht manipuliert worden durch einen Dritten. Daher gilt weiterhin, wenn vertrauliche Informationen per E-Mail verschickt werden müssen diese nochmal explizit auf Programmebene, z.B. per S/MIME vers[15] verschlüsselt werden.
Durch die zentrale Administration über eine Web-GUI kann jedem User, wie schon anfangs erwähnt, der Zugriff auf bestimmte Bereiche auf die GUI freigeschaltet werden. So ist für die nächste Version der Software MPS geplant, jedem Benutzer für seine eigene Quarantäne Zugriff anzubieten. Ob es weitere bestimmte Einstellungen auf Benutzerebene geben wird, hat der Hersteller nicht erwähnt. Auf Abb. 9 ist die Startseite mit den wichtigsten Informationen und Statistiken zu sehen. Über Search und Outbound greift man direkt auf die Logs bzw. auf die Quarantäne zu um z.B. eine E-Mail zuverfolgen und bei Auslieferung in die Quarantäne, um diese wieder freizugeben.
6 Risikoanalyse
Der Einsatz einer zentralen Komponente bringt immer bestimmte Vor- und Nachteile. Die Vorteile bei einem zentralen E-Mail-Knoten liegen auf jedenfall bei der Bekämpfung von Spam. Durch eine zentrale Kommunikation zu allen Standorten des Unternehmens muss der Spam-Filter viele unterschiedliche Spam-E-Mails von unterschiedlichster Art, in Form von Bildern, Schriftarten oder Texten erkennen. Dies wird anfangs noch zu mehr Spam-E-Mails führen die den Filter passieren. Die Filter werden automatisch mit Updates versorgt und lernen bei jeder verarbeiteten E-Mail dazu. So wird, je mehr Spam beim E-Mail-Knoten ankommt, immer weniger zum Postfach des Mitarbeiters ausgeliefert. Eine neue Form des Spam sind Non Delivery Reports (NDRs), wo ein Angreifer die existierende E-Mail-Adresse eines Opfers benutzt und E-Mails an irgendwelche Mail-Relay-Server mit falschen Empfänger-Informationen schickt. Dieser Mail-Relay-Server verschickt dann an den vermeintlichen Absender den Bericht, dass der Empfänger nicht existiert. Durch unseren zentralen E-Mail-Knoten können wir diese Art von Spam ebenfalls verhindern. Jede E-Mail ins Internet wird durch den Knoten geschickt, so weiss dieser, ob der nun ankommende NDR berechtigt ist oder nicht und blockiert ihn, sollte nicht vorher eine E-Mail an das entsprechende Mail-Relay geschickt worden sein. Potentielle Gefahren durch Viren werden direkt im ersten Schritt unterbunden durch zwei unabhängige Anti-Viren-Programme. Durch die zentrale Administration kann zusätzlich noch gefiltert werden. Es können nur ein Standort oder bis auf User-Ebene bestimmte zusätzliche Filter, z.B. Blacklist, eingebunden werden. Die Administration des kompletten E-Mail-Knoten erfolgt über die Web-GUI und kann von einem Team betrieben werden. Bei Großunternehmen bietet die Web-GUI ebenfalls den Vorteil, dass eine einfache E-Mail-Verfolgung und E-Mails aus der Quarantäne holen, vom First-Level-Support bearbeitet und gelöst werden kann. Der komplette Aufwand um Spam und Viren effektiv abzuwehren geschieht nur an einer Stelle, so dass in jedem anderen Standort Kosten für Hard- und Software, sowie Housing (Strom, Klima, etc.) wegfällt. Die Umgebung wurde im „Best Pratice“ aufgebaut, was besagt, dass bevor eine E-Mail vom Postfach ggfs nochmal auf Viren und Spam kontrolliert wird von einer getrennten Umgebung gescannt und dann erst aufgeliefert wird. Dies ist Standard bei vielen Unternehmen und erhöht die Sicherheit im Umgang mit E-Mails. Ein netter Nebeneffekt der zentralen E-Mail-Domain ist ein einheitliches Auftreten nach Aussen. Es dient der Coperate Identity und durch automatisches Anhängen von Signaturen und Disclaimer ebenfalls der rechtlichen Sicherheit. Durch Zuordnung der User zu den einzelnen Standorten wird so ebenfalls immer der passende Inhalt ausgewählt. Durch zentralisierte Hardware für mehrere Standorte erhöht sich die Anforderung an die Verfügbarkeit enorm. Sollte die Umgebung ausfallen, ist das gesamte Unternehmen inkl. aller Standorte von der E-Mail-Kommunikation abgeschnitten. Die vorgestellte Infrastruktur ist voll redundant ausgelegt, allerdings kann es auch hier zu Problemen führen. Sollte jeweils in den unterschiedlichen Schichten zur gleichen Zeit ein Server ausfallen, hat dies noch keine Auswirkung auf die Funktionen der E-Mail-Kommunikation. Dies sieht bei zwei Ausfällen innerhalb einer Schicht schon nicht mehr so gut aus. So kann, z.B. wenn im Data Layer zwei von drei internen Filter-Servern ausfallen, ein Verlust von E-Mails in der Quarantäne und den entsprechenden Log-Einträgen entstehen. Genauso kritisch ist die Services Layer Schicht zu betrachten. Sollten hier beide Server ausfallen, fehlt die LDAP Information und dem MTA ist nicht bekannt, wohin er eine E-Mail ausliefern soll. Dies ist im MTA Layer schon wesentlich einfacher. Sollten hier alle bis auf einen Server ausfallen, entsteht nur eine Verzögerung der Auslieferung. Beim Access Layer besteht die wenigste Gefahr. Fallen hier beide Server aus, so kann lediglich die Konfiguration nicht mehr angepasst werden und der First-Level-Support kann keine Nachrichten mehr aus der Quarantäne ausliefern. Die eigentliche E-Mail-Kommunikation läuft wie gehabt weiter.
7 Fazit
Eine zentrale E-Mail-Domain mit einem zentralen E-Mail-Knoten bietet viele Vorteile. Durch eine zentrale Administrations-Oberfläche lassen sich einfache Aufgaben direkt vom First-Level-Support lösen und die gesamte Umgebung durch nur ein Team betreiben. Es bietet einen zentralen Schutz vor Viren und einen weit aus effektiveren Schutz vor Spam, ohne das jeder Standort selber teure Anti-Virus/Anti-Spam Lösungen braucht. So spart das Unternehmen Kosten, auch durch Housing. Durch die Trennung von Postfach und Anti-Virus/Anti-Spam betreiben wir eine Lösung nach dem „Best Pratice“ Prinzip, was sich ebenfalls bei anderen Unternehmen bewehrt hat. Und durch eine zentrale E-Mail-Domain fördern wir die Corporate Identity des Unternehmens durch ein einheitliches Auftreten nach Aussen. Als Nachteil sind die hohen Vorrausetzungen zu nennen, um einen zentralen E-Mail-Knoten betreiben zu können. Sollte kein VPN, IdM oder DNS vorhanden sein, entstehen hier enorme Kosten um dies umzusetzen. Ebenfalls ensteht durch den nur einen zentralen E-Mail-Knoten ein Single Point Of Failure, den es gilt zu verhindern, da es bei einem Ausfall dazu führen kann, dass u. U. das gesamte Unternehmen nicht mehr per E-Mail kommunizieren kann.
8 Fußnoten
- ↑ Vgl. http://www.teco.edu/~zimmer/vpn/node14.html, 05.07.2010, 16:05
- ↑ Vgl. IPsec, S.25
- ↑ Vgl. RFC 4306, http://tools.ietf.org/html/rfc4306, 09.07.2010, 20:07
- ↑ Vgl. Sicherheit & Kryptographie, S. 156f
- ↑ Vgl. http://www.searchsecurity.de/themenbereiche/identity-und-access-management/user-management-und-provisioning/articles/143913/ 05.07.2010, 16:29
- ↑ Vgl. Enterprisewide identity mgmt, S. 19
- ↑ Vgl. Collaboration und Webservices, S. 59
- ↑ Vgl. RFC 974, http://tools.ietf.org/html/rfc974, 09.07.2010, 13.49
- ↑ Vgl. RFC 1035, http://tools.ietf.org/html/rfc1035, 09.07.2010, 14:07
- ↑ Vgl. HGB §37a, GmbHG §35a, AktG §80
- ↑ Vgl. AnubisNetworks Operations Guide, S. 10
- ↑ Vgl. RFC 4408, http://tools.ietf.org/html/rfc4408, 09.07.2010, 9:51
- ↑ Vgl. RFC 5672 http://tools.ietf.org/html/rfc5672, 09.07.2010, 10:30
- ↑ Vgl. VPN- Virtual private Networks, S. 283
- ↑ Vgl. RFC 3851, http://tools.ietf.org/html/rfc3851, 10.07.2010, 13:32
9 Abkürzungsverzeichnis
| TLD | Top Level Domain |
| SMTP | Simple Mail Transport Protocol |
| VPN | Virtual Private Network |
| IdM | Identity Management |
| OpCo | Operating Company |
| LDAP | Lightweight Directory Access Protocol |
| SPF | Sender Policy Framework |
| DKIM | DomainKey Identified Mail Signatures |
| MTA | Mail Transfer Agent |
| DNS | Domain Name System |
| TCP | Transmission Control Protocol |
| UDP | User Datagram Protocol |
| IPsec | Internet Security Protocol |
| SSO | Single-Sign-On |
| GUI | Graphical User Interface |
| SSL | Secure Socket Layer |
| TLS | Transport Layer Security |
| S/MIME | Secure / Multipurpose Internet Mail Extensions |
| MBB | Mailbackbone |
| NDR | Non Delivery Report |
10 Abbildungsverzeichnis
Abb. 1: Übersicht VPN, Quelle: Virtuelle private Netze, http://www.teco.edu/~zimmer/vpn/IMG8.GIF
Abb. 2: Identitätsmanagementzyklus, Quelle: Enterprisewide identity management, S. 12
Abb. 3: Aufbau des DNS, Quelle: Denic, http://www.denic.de/typo3temp/pics/D_fdad64827d.jpg
Abb. 4: logischer Aufbau MBB, Quelle: AnubisNetworks Operations Guide, S. 10
Abb. 5: Übersicht Infrastruktur inkl. SMTP Traffic, Quelle: AnubisNetworks Operations Guide, S. 12
Abb. 6: Internet-E-Mails Filterprozess, Quelle: AnubisNetworks Operations Guide, S. 29
Abb. 7: Ausgehender E-Mail-Prozess inkl. Filterung, Quelle: AnubisNetworks Operations Guide, S. 31
Abb. 8: E-Mail-Prozess zwischen Standorten inkl. Filterung, Quelle: AnubisNetworks Operations Guide, S. 37
Abb. 9: Übersicht Admin-Web-Oberfläche, Einstellungen, Daten & Zahlen wurden entfernt
11 Tabellenverzeichnis
Tabelle 1: Kommunikationswege Internet-E-Mails Filterprozess, Quelle: In Anlehnung an: AnubisNetwork Operations Guide, S. 30
Tabelle 2: Kommunikationswege Ausgehender E-Mail-Prozess inkl. Filterung, Quelle: In Anlehnung an: AnubisNetwork Operations Guide, S. 32
Tabelle 3: Kommunikation E-Mail-Prozess zwischen Standorten inkl. Filterung, Quelle: In Anlehnung an: AnubisNetwork Operations Guide, S. 38
12 Literatur- und Quellenverzeichnis
What is a VPN (http://www.potaroo.net/papers/vpn.pdf, 05.07.2010, 15:57)
Virtuelle private Netze weltweite LANs (http://www.teco.edu/~zimmer/publ/VPN.pdf, 05.07.2010, 16:05)
AnubisNetworks Operations Guide
AnubisNetworks Product Datasheet (http://www.anubisnetworks.com/sites/default/files/AF_MPS_ENTERPRISE_EDITION.pdf, 08.07.2010, 15:36)
IPSec – The New Security Standard for the Internet, Intranets, and Virtual Private Networks (http://books.google.de/books?id=ZKIxicvgGJ8C&lpg=PA1&dq=IPSec%20%E2%80%93%20The%20New%20Securit&client=firefox-a&pg=PT42#v=onepage&q&f=false, 09.07.2010, 20:00)
Leichter Tunneln (http://www.heise.de/security/artikel/Einfacher-VPN-Tunnelbau-dank-IKEv2-270056.html, 09.07.2010, 20:00)
Sicherheit und Kryptographie im Internet: Von sicherer E-mail bis zu IP-Verschlüsselung (http://books.google.de/books?id=rj36vlOIRAkC&lpg=PA156&dq=IKEv2&client=firefox-a&pg=PA156#v=onepage&q=IKEv2&f=false, 09.07.2010, 20:18)
Enterprisewide identity management: managing secure and controllable access in the extended enterprise environment (http://books.google.de/books?id=LC3QGjrfrnUC&lpg=PA18&dq=provisionierung%20user%20identity&pg=PA19#v=onepage&q&f=false, 09.07.2010, 20:39)
Collaboration und Webservices: Architekturen, Portale, Techniken und Beispiele (http://books.google.de/books?id=RbXoCoNuBN4C&lpg=PA33&dq=single%20sign%20on%20integration&pg=PA59#v=onepage&q=single%20sign%20on%20integration&f=false, 09.07.2010, 20:57)
VPN- Virtual private Networks (http://books.google.de/books?id=XMez2I_eRggC&lpg=PA283&dq=secure%20socket%20layer%20osi%20darstellungsschicht&pg=PA283#v=onepage&q&f=false, 10.07.2010, 10:54)
