Der zweite Teil beschäftigt sich mit einer internen Lösung zur eMail-Security. Diese stellt ebenfalls Ansprüche an die vorhandene oder noch zu schaffende Infrastruktur die erfüllt werden müssen. Auch ist die Auswahl einer geeigneten Lösung nicht trivial, da diese zum Benutzerverhalten und den Anforderungen passen muss.
Fällt die Entscheidung zur eMail-Security auf eine Inhouse-Lösung, dann sind Fragen zur Redundanz und Verfügbarkeit zu stellen.Welche Verfügbarkeit soll und ist mit der vorhandenen Internet-Anbindung überhaupt zu erreichen? Wie lange darf die eMail-Kommunikation ausfallen, respektive, wie viel Zeit darf eine Reparatur oder ein Austausch in Anspruch nehmen? Sind diese Fragen hinreichend geklärt und die Ausfallzeiten aus betriebswirtschaftlicher Sicht noch zu vertreten, ist jetzt die technische Umsetzung zu entwickeln. Diese Umsetzung führt wiederum zu weiteren Fragen:
Wie sollen unerwünschte eMails gefiltert werden, welchen Einfluss soll der einzelne Benutzer auf die Filteroptionen haben? Welche Strategie bei der Annahme von eMails soll zu Einsatz kommen? Werden eMails angenommen und anschließend gefiltert oder soll abgewiesen werden? Gerade diese Frage hat weitreichende rechtliche Konsequenzen. Was passiert nach der Annahme mit den jeweiligen eMails? Sollen diese isoliert und der Anwender benachrichtigt werden oder sollen sie nur markiert zum Anwender gesendet werden? Erst wenn diese Fragen hinreichend geklärt sind, kann nach der eigentlichen technischen Lösung gesucht werden.
In Anbetracht der Massen an unerwünschten eMails ist es keine optimale Strategie alle Mails anzunehmen und dann zu filtern oder gar zu prüfen, ob es den Empfänger wirklich gibt. Nach kürzester Zeit sind hunderte von Unzustellbarkeitsbenachrichtigungen in der Ausgangs-Queue die man seinerseits durch die gefälschten Absender nicht zustellen kann. Daher scheidet diese „Strategie“ von vorn herein aus. Es bedarf also einer Lösung, die schon bei der Annahme einer eMail bestimmte Prüfungen vornimmt um Spam’s zu erkennen und diesen dann die Annahmen verweigert. Das Gleiche gilt auch für unbekannte Empfänger, hier muss auch direkt abgewiesen werden. Diese beiden grundlegenden Funktionen an der Schnittstelle zum Internet sind also zwingend abzubilden.
Systeme mit Prüfung der Sender-Reputation haben sich hier in den vergangenen Jahren durchgesetzt. Der Wert der Reputation bezieht sich auf die IP-Adresse des Systems, welches die eMail einliefern möchte. Bei der Verbindung wird mit einer Echtzeit-Anfrage die Wertigkeit der IP-Adresse des Gegenübers ermittelt. Ist die Reputation des Senders schlecht, dann wird die eMail abgewiesen. Bei entsprechend guter Reputation wird sie angenommen. Diese Systeme erreichen eine Reduktion des Spams von mehr als 80%. Geht die Funktionalität am Gateway noch etwas weiter, dann können diese Systeme Hash-Werte der Inhalte und Inhalte selbst prüfen und ggf. diese eMails dann gleich abweisen. Damit erhöht sich die Erkennungsrate noch mal deutlich. Aber selbst diese Kombination von Reputation und Teilinhalte ist oft nicht ausreichend um bis auf wenige Ausnahmen unerwünschte eMails zu erkennen.
Gerade die eMails die sich an der Grenze zum eindeutigen Spam befinden, lassen sich so nicht vom Posteingang des Anwenders fernhalten. Aus diesem Grund bedarf es weitere Mechanismen. An dieser Stelle ist dann die Frage zu klären, ob die eMails markiert oder isoliert werden sollen. Beide Varianten bieten Vor- aber auch Nachteile. Hier ist zu überdenken, wie die isolierten Mails gesichert werden sollen. Werden sie lediglich markiert, dann werden diese über die Sicherung der Groupware-Lösung abgedeckt. Kommt eine Lösung mit Isolation zum Einsatz, muss eine entsprechend andere Lösung gefunden werden.
Eine weitere Frage ist die Stelle in der eMail-Kette an der gefiltert werden soll. Eine Lösung die mit auf der Groupware-Lösung installiert ist, benötigt auch entsprechende Ressourcen. Weist die Groupware-Lösung schon eine entsprechende Last auf, dann ist es keine Option diese noch mit einem weiteren Dienst zu belasten. In den meisten Fällen kommt daher eine dedizierte Lösung zum Einsatz um die Last von der Groupware-Lösung fern zu halten.
Zur Groupware-Lösung wird noch mindestens ein weiteres System benötigt. Ein direkter Zugriff aus dem Internet auf die Groupware-Lösung stellt ein erhebliches Sicherheitsrisiko da. Aus diesem Grund muss es ein System geben, was zwischen dem Internet und der Groupware-Lösung steht. In der Vergangenheit waren dies oft auf Linux basierende Systeme. Bei Lösungen auf Basis von Exchange 2007/2010 kann aber auch ein Hub/Transport- oder Edge-Server von Microsoft diese Aufgabe übernehmen. Eine andere Option ist dazu eine eMail-Security Appliance zu verwenden, um Spam- und Viren-Prüfungen durchzuführen und die Groupware-Lösung zu schützen. Der Einsatz eines Proxy für diese Aufgabe ist ebenfalls möglich.
Bei aller Konzentration auf die unerwünschten eMails darf die Absicherung der internen eMails nicht außer Acht gelassen werden. Häufig wird daher ein Schutz vor Schadcode auf der Groupware-Lösung selbst vergessen, der aber ebenfalls ein wichtiger Bestandteil der unternehmensweiten Sicherheitsstrategie ist.
Wie gewohnt, stehen wir gerne zu Fragen über dieses Thema zur Verfügung.