Systeme und ihr Umfeld

E-Mail-Sicherheit

Verbindlicher Versand

Von Norbert Luckhardt, Hannover

Wie kann man sicherstellen, dass Sicherheitsrichtlinien in Bezug auf Mail-Verschlüsselung, -Signatur und -Archivierung eingehalten werden? Eine Universallösung gibt es nicht, aber eine ganze Menge Ansätze, die sich für verschiedene Policies und Anwendungsfelder mehr oder weniger gut eignen.

Verschlüsselte Nachrichten haben leider immer noch Seltenheitswert. Selbst wenn es eine Firmenrichtlinie gibt, die für bestimmte Inhalte oder Empfänger das Chiffrieren oder Signieren vorschreibt, bleibt fraglich, ob diese Policy eingehalten wird. Auch das Vorhandensein einer Public Key Infrastructure (PKI) ist noch keine Garantie für deren Nutzung durch die Mitarbeiter. Häufig empfinden Anwender die Verschlüsselungs- und Signiervorgänge durch Mailprogramme oder Plug-ins als lästig oder zu kompliziert oder vergessen schlichtweg, die entsprechenden Einstellungen zu aktivieren (und eine Vorgabe für alle Mails ist mangels globaler PKI unmöglich).

Innerhalb von Messaging-Systemen (Groupware) wie Lotus Notes oder Microsoft Exchange hat man mehr Möglichkeiten: Notes authentifiziert die Absender beispielsweise anhand ihrer Anmeldekennung (ID), bei entsprechender Konfiguration des Servers laufen E-Mails zudem verschlüsselt, auch zwischen verschiedenen Lotus-Servern. Sobald man die Lotus-Welt jedoch verlässt, sind wieder Plug-ins gefragt, die üblicherweise dem Anwender das letzte Wort überlassen. In Exchange-Umgebungen ermöglicht allerdings [externer Link] Biodatas Outlook-Plug-in Securedesk die Festlegung bestimmter Domains oder Adressaten (per Regular Expression), an die Anwender E-Mails signiert oder verschlüsselt schicken müssen. Wie alle Policy-Einstellungen kann der Securedesk-Administrator diese Werte gegen Modifikationen durch den Nutzer sperren.

Zusatzsoftware zur Umsetzung von Verschlüsselungsrichtlinien (durch PGP und S/MIME) sowie für revisionssichere Archivierung, automatische E-Mail-Fußnoten (Disclaimer), Inhaltsprüfung und einiges andere bietet für Notes- und Exchange-Installationen unter anderem [externer Link] GROUP Technologies mit ihren securiQ-Produkten an. Ähnliche Funktionen mit einer transparenten serverbasierten PGP-Ver- und Entschlüsselung (an einen Firmenschlüssel) ermöglicht Mail essentials von GFI auf Exchange und mit SMTP/POP3-Servern. Die britische Firma 5GM setzt bei seinem 5GM-Mail OpenGateway für den Transportschutz sowie für beweissichere Auslieferung (inkl. Aushandlung unterstützter/akzeptierter Dateitypen in Attachments) und Archivierung auf ein eigenes Protokoll (G5), sodass auf beiden Seiten G5-Software notwendig ist; für externe Partner will 5GM eine kostenlose Lite-Version anbieten, die ausschließlich empfangen kann (zum Redaktionsschluss war allerdings nur eine Version für Microsoft Exchange verfügbar).

Zwischen zwei Servern im eigenen Einflussbereich lässt sich eine transparente Verschlüsselung auch relativ leicht durch Skripte in Verbindung mit Kommandozeilenversionen von Kryptosoftware einrichten, beispielsweise mit dem PGP/E-Business-Server von [externer Link] NAI oder dem OpenSource-Projekt GnuPG, für das vor kurzem auch eine frühe Version 0.8.2 des SMTP-Proxies GEAM (Geam Encrypts All Mail) freigegeben wurde. Applicances für diese Zwecke sowie unter anderem Inhaltsprüfung und Protokollierung liefert beispielsweise MIRAPOINT mit dem Message Director, der als SMTP-Gateway per SMTP/TLS (RFC 2487) den Server-zu-Server-Transportweg sichert.

Heterogene Clients

Ende-zu-Ende-Sicherheit mit beliebigen und heterogenen Mail-Clients sowie gleichzeitig hohe Transparenz für den Anwender und eine zentral gesteuerte Policy, an der die Nutzer nicht "vorbeikommen", verspricht [externer Link] Applied Security mit fideAS mail. Die Windows-Software überwacht auf PCs ein- und ausgehende E-Mails per POP3 und SMTP auf der Winsock-Ebene und ver- oder entschlüsselt entsprechend der benutzerspezifischen Policy transparent im Hintergrund. Der Anwender sieht davon nur dann etwas, wenn in den Richtlinien eine Auswahlmöglichkeit eingeräumt wurde. Als Veschlüsselungsprotokoll nutzt Version 1.x von fideAS mail PEM/ [externer Link] MailTrusT; für Ende Juli ist die Version 2.0 geplant, die auch S/MIME unterstützen soll.

Der Benutzer sieht bei fideAS mail höchstens eine Auswahlbox; zwingend vorgeschriebene Regeln laufen völlig transparent im Hintergrund.

Die fideASmail-Policies unterstützen zur einfacheren Administration Vererbung und unterscheiden verschiedene Sicherheitslevel, die neben der Benutzerentscheidung und einem unbeeinflussten Versand die zwingende Chiffrierung, eine Verschlüsselung "falls möglich" oder ein Sendeverbot vorsehen. Der Benutzer muss (und kann) keinerlei Einstellungen vornehmen. Die Policy und alle notwendigen Zertifikate holt fideAS mail automatisch von einem zentralen ldap-Server. Da die E-Mails erst beim tatsächlichen Versand bearbeitet werden, ist auch der Betrieb ohne ständige Verbindung zum Internet möglich; eventuell ist beim Anmelden an das System ein kurzer Verbindungsaufbau zum Policy-Update notwendig.

Die zentral verwaltete Policy gibt dem fideASmail-Client vor, für welche E-Mail-Empfänger verschlüsselt werden muss oder kann.

"Kunden und Partner" können sich laut apsec die notwendige Software zum Anschluss an die Firmen-PKI aus dem Internet holen und installieren. In der Praxis erscheint jedoch zweifelhaft, ob Externe einen derart starken Eingriff in ihren Mail-Fluss hinnehmen würden: Die Software verhindert beispielsweise rigoros den Versand durch Absendeadressen, für die keine Benutzerpolicy vorliegt – und die Hoheit über die Zulässigkeit und Sicherung abgehender Nachrichten liegt ausschließlich beim fideASmail-Administrator. Zudem verlief die testweise Installation auf zwei Redaktionssystemen nicht so problemlos wie erwartet – die apsec-Entwickler konnten die Mankos allerdings in kurzer Zeit beheben.

Für das "Policy Enforcement" des Mailausgangs bei (mobilen) Mitarbeitern, Außenstellen oder auch Key Accounts wichtiger Zulieferer dürfte fideAS mail aber eine sehr benutzerfreundliche Lösung darstellen. Ein Wermutstropfen ist bei all der Transparenz allerdings, dass digitale Signaturen, mit denen das Programm die Nachrichten versieht, ebenso unsichtbar verschwinden wie die Chiffrierung; der Anwender hat keine unmittelbare Möglichkeit, die Authentizität eingehender E-Mails zu prüfen.

Basis WWW

Anstatt seine Kontrolle in die Mail-Verwaltung von Kunden und Partnern auszudehnen, kann man die E-Mails auch im Bereich eigener Kontrolle halten. Diesen Weg geht beispielsweise der IME Messenger von [externer Link] Tumbleweed, indem er die Nachrichten in einem Webserver vorhält (womit es sich streng genommen nicht mehr um E-Mails handelt). Dadurch kann der Betreiber natürlich jegliche Vorgänge exakt nachvollziehen und steuern: Zugriff nur über veschlüsselte Verbindungen, Status der Nachricht (ausgeliefert, gelesen, beantwortet, ...) sowie ihrer Anhänge und so weiter.

Als Client dient ein Webbrowser, zur Authentifizierung ein Account- oder Nachrichten-(Package-)Passwort. Über neue IME-Packages benachrichtigt der Server den Adressaten per normaler E-Mail, die einen gezielten Link auf die bereitliegende Nachricht enthält. Je nach Sicherheitseinstellung kann der Empfänger unter diesem Link die Botschaft unmittelbar lesen, muss erst ein Passwort eingeben oder benötigt einen eigenen IME-Account mit In- und Outbox. Solche Accounts können auch automatisiert aus Kundendateien eingerichtet werden, wobei eine Kundennummer oder andere Teile der Bestandsdaten das initiale Passwort abgeben.

Optionen bei der Erstellung einer IME-Package – hier zählt vor allem Nachvollziehbarkeit

Die Betonung dieser Lösung liegt auf der Nachweisbarkeit der Zustellung und der Anzeige oder des Downloads von Dateianhängen, wie sie etwa bei Rechnungsstellungen notwendig sind (Electronic Bill Presentment). Derartige Dienste lassen sich auch an Application Service Provider (ASP) auslagern: Beispielsweise bietet die [externer Link] Deutsche Post Com eine rechtsverbindliche Online-Zustellung in einem Java-Applet mit 128-Bit-Verschlüsselung an. Die Rechnungsdaten (ggf. auch mit umfangreichen Einzelnachweisen) gehen dazu in einem Inhouse-Format/ASCII, als EDIFACT-, IDoc- oder XML-Dokument an den Dienstleister.