Verschlüsseln und Signieren auf dem Gateway

Auf der Seite SMTP und die Sicherheit habe ich die verschiedenen Möglichkeiten einer Absicherung des normalerweise ungesicherten Mailverkehrs per SMTP beschrieben. Auf NoSpamProxy Encryption - Verschlüsseln und Signieren finden Sie ein paar Bildschirme des Gateways NoSpamProxy Encryption.

Alternativen und ihre Probleme

Ehe ich auf die Details einer Gateway-Lösung weiter eingehe, möchte ich kurz die Gründe aufführen, warum die anderen Alternativen für Firmen unpraktisch, risikobehaftet und damit ungeeignet sind.

Option	Probleme
S/Mime auf dem Client	Keine Stellvertreterfunktion und Weiterleitungsregeln, Urlaubsregeln Es ist unwahrscheinlich, dass Sie ihren "privaten Schlüssel" an alle Personen in Kopie geben, die von Ihnen weiter geleitete Mails (z.B. während ihres Urlaubs) bekommen oder ihre Stellvertreter sind. Diese könnten dann auch "in ihrem Namen" eine Mail schreiben und sogar korrekt signieren. Der Empfang von verschlüsselten Mails stellt ein Problem dar. Mobile Anwender / OWA Das gilt auch, wenn Sie nicht nur mit ihrem "PC mit Outlook" die Mails lesen, sondern z.B. Unterwegs per PDA oder Outlook Web Access solche verschlüsselte Mails lesen wollen. Ohne privaten Schlüssel können Sie ihre Mails nicht lesen. Probleme bei der Archivierung Ein Archivsystem kann maximal die verschlüsselten Elemente "Raw" in ein Archiv übertragen. Mangels "Masterkey" kann aber nur der Anwender selbst die Mails einsehen. Zumindest solange der den Private Key des damals verwendeten Zertifikats noch auffinden kann. Virenschutz Wie wollen Sie eine Mail auf Schadinhalt prüfen, wenn Sie gar nicht "rein" schauen können. Letztlich kann nur der Virenscanner auf dem Arbeitsplatz einen Schädling stoppen, wenn er sich nach der Decodierung weiter verbreiten will. Compliance Immer mehr Firmen installieren Filter, um den Versand von sensiblen Daten zu verhindern. Das oft als "Compliance" bezeichnete Filtersystem stoppt z.B. Mails mit internen Daten, Kontonummern oder Codenamen o.ä. Wenn der Absender aber auf dem Endgerät verschlüsselt, kann kein zentrales System diese Mails stoppen. S/Mime auf dem Client ist schwer für "Firmen" nutzbar, sondern eher für wenige ausgewählte Anwender, Funktionskonten oder Privatpersonen, die um die Bedeutung des "Zertifikats" und noch mehr um den privaten Schlüssel wissen. Für Firmen ist es sogar eher ratsam, verschlüsselte Mails, die nicht auf dem Transportweg inspiziert werden können, zu blockieren. Sowohl von extern als auch von intern nach draußen. Details siehe auch Sichere Mails mit S/Mime und PGP
TLS auf dem Server	Auch der Datenaustausch per SMTP kann über einen SSL-Tunnel verschlüsselt werden. Nur von Server zu Server, keine Sender zu Empfänger-Verschlüsselung Die Kommunikation wird nur von Server zu Server verschlüsselt, d.h. es ist nur der Transportweg über das LAN/WAN gesichert, aber nicht die Mail selbst auf dem Mailserver. Zudem hat weder Sender noch Empfänger eine Kontrolle, dass wirklich alle Teilstrecken verschlüsselt sind. Archiv/Virenscan auf Transport-Relays möglich Da die Mails auf dem Mailserver selbst unverschlüsselt wären, können Virenscanner, Archivprodukte, Regeln, Filter etc. vollständig genutzt werden. Probleme mit "nicht TLS-tauglichen" Relay-Stationen Wenn zwischen den Servern ein Smarthost oder Backup-MX ist oder der Provider Port 25 "umbiegt", dann funktioniert TLS nur, wenn dieses Relay auch TLS unterstützt. Trotzdem ist der Einsatz von SMTP über TLS/SSL ein wichtiger Schritt, um den Transportweg besser zu sichern und über die Identifizierung der Kommunikationspartner zukünftig auch Spam- und Fehlzustellungen zu verhindern.
VPN-Tunnel	Diese Anbindung verschlüsselt die Datenübertragung zwischen Partnern aber sicher nicht für den "freien Austausch" mit vielen Gegenstellen geeignet. Und selbst dann "vertrauen" sie dem anderen Netz/Server und haben noch keine Gewähr dass die Mail nicht doch "fremd" erstellt wurde. Diese Option können wir also getrost unterschlagen.

Option

Probleme

S/Mime auf dem Client

Keine Stellvertreterfunktion und Weiterleitungsregeln, Urlaubsregeln
Es ist unwahrscheinlich, dass Sie ihren "privaten Schlüssel" an alle Personen in Kopie geben, die von Ihnen weiter geleitete Mails (z.B. während ihres Urlaubs) bekommen oder ihre Stellvertreter sind. Diese könnten dann auch "in ihrem Namen" eine Mail schreiben und sogar korrekt signieren. Der Empfang von verschlüsselten Mails stellt ein Problem dar.
Mobile Anwender / OWA
Das gilt auch, wenn Sie nicht nur mit ihrem "PC mit Outlook" die Mails lesen, sondern z.B. Unterwegs per PDA oder Outlook Web Access solche verschlüsselte Mails lesen wollen. Ohne privaten Schlüssel können Sie ihre Mails nicht lesen.
Probleme bei der Archivierung
Ein Archivsystem kann maximal die verschlüsselten Elemente "Raw" in ein Archiv übertragen. Mangels "Masterkey" kann aber nur der Anwender selbst die Mails einsehen. Zumindest solange der den Private Key des damals verwendeten Zertifikats noch auffinden kann.
Virenschutz
Wie wollen Sie eine Mail auf Schadinhalt prüfen, wenn Sie gar nicht "rein" schauen können. Letztlich kann nur der Virenscanner auf dem Arbeitsplatz einen Schädling stoppen, wenn er sich nach der Decodierung weiter verbreiten will.
Compliance
Immer mehr Firmen installieren Filter, um den Versand von sensiblen Daten zu verhindern. Das oft als "Compliance" bezeichnete Filtersystem stoppt z.B. Mails mit internen Daten, Kontonummern oder Codenamen o.ä. Wenn der Absender aber auf dem Endgerät verschlüsselt, kann kein zentrales System diese Mails stoppen.

S/Mime auf dem Client ist schwer für "Firmen" nutzbar, sondern eher für wenige ausgewählte Anwender, Funktionskonten oder Privatpersonen, die um die Bedeutung des "Zertifikats" und noch mehr um den privaten Schlüssel wissen.

Für Firmen ist es sogar eher ratsam, verschlüsselte Mails, die nicht auf dem Transportweg inspiziert werden können, zu blockieren. Sowohl von extern als auch von intern nach draußen.

Details siehe auch Sichere Mails mit S/Mime und PGP

TLS auf dem Server

Auch der Datenaustausch per SMTP kann über einen SSL-Tunnel verschlüsselt werden.

Nur von Server zu Server, keine Sender zu Empfänger-Verschlüsselung
Die Kommunikation wird nur von Server zu Server verschlüsselt, d.h. es ist nur der Transportweg über das LAN/WAN gesichert, aber nicht die Mail selbst auf dem Mailserver. Zudem hat weder Sender noch Empfänger eine Kontrolle, dass wirklich alle Teilstrecken verschlüsselt sind.
Archiv/Virenscan auf Transport-Relays möglich
Da die Mails auf dem Mailserver selbst unverschlüsselt wären, können Virenscanner, Archivprodukte, Regeln, Filter etc. vollständig genutzt werden.
Probleme mit "nicht TLS-tauglichen" Relay-Stationen
Wenn zwischen den Servern ein Smarthost oder Backup-MX ist oder der Provider Port 25 "umbiegt", dann funktioniert TLS nur, wenn dieses Relay auch TLS unterstützt.

Trotzdem ist der Einsatz von SMTP über TLS/SSL ein wichtiger Schritt, um den Transportweg besser zu sichern und über die Identifizierung der Kommunikationspartner zukünftig auch Spam- und Fehlzustellungen zu verhindern.

VPN-Tunnel

Diese Anbindung verschlüsselt die Datenübertragung zwischen Partnern aber sicher nicht für den "freien Austausch" mit vielen Gegenstellen geeignet. Und selbst dann "vertrauen" sie dem anderen Netz/Server und haben noch keine Gewähr dass die Mail nicht doch "fremd" erstellt wurde. Diese Option können wir also getrost unterschlagen.

All diese Verfahren lassen sich auch kombinieren, so dass die Sicherheit noch gesteigert wird. Allerdings addieren sich dann auch die Einschränkungen wieder.