Email GW Verschlüsselung

[ThomasAnderson 0]

Hallo,

 

habt Ihr Empfehlungen für eine Gateway basierte Email Verschlüsselungs-Lösung.

Anforderungen:

- einfache Integration (Exchange)

- transparent (ohne User Interaktion) bspw. durch Filterfunktionen zur Überprüfung der Inhalte der Mail

- Zusammenarbeit mit anderen PGP S/MIME Systemen

- zentral administrierbar

- am besten auch noch mit alternativem Weg für verschlüsselte Email (verschlüsselte PDF oder Webportal)

 

Was haltet ihr von der:

http://www.alpha2000.de/download/ironport_email_verschluesselung.pdf

 

Danke für die Tipps.

 

PS.: Falls jemand eine nicht PGP basierte sondern bspw. TLS Lösung o.Ä. empfehlen möchte, scheut Euch nicht :)
 

bearbeitet 18. Juni 2014 von ThomasAnderson

[NilsK 2.934]

Moin,

 

zwei Produkte, die ich für empfehlenswert halte:

• Zertificon Z1
• enQsig

 

Gruß, Nils

bearbeitet 18. Juni 2014 von NilsK

[DocData 85]

Ganz klar Zertificon Z1.

bearbeitet 18. Juni 2014 von DocData

[NorbertFe 2.034]

Kann mich zumindest bei Zertificon anschliessen. EnQsig kenn ich nur oberflächlich.

 

Bye

Norbert

[ThomasAnderson 0]

Die Ciscolösung hat noch niemand ausprobiert?

[Daniel -MSFT- 129]

Schau Dir mal Office 365 Message Encryption an. Es ist in den Office 365 E3/E4-Plänen mit enthalten und kann separat als Bestandteil von Windows Azure Rights Management für 1,50 EUR pro User und Monat erworben werden, um mal eine Hausnummer zu nennen. Damit bekommt man Rights Management für Dateien sowie E-Mails auf Basis der gleichen Technologie: http://blogs.office.com/2013/11/21/introducing-office-365-message-encryption-send-encrypted-emails-to-anyone/

 

Ich hatte PGP-S/MIME-Gateways schon vor 15 Jahren implementiert. Allerdings scheitern solche Projekte regelmäßig daran, dass der Empfänger sich um ein Zertifikat/Key kümmern muss, wenn man verschlüsseln will. PGP hat meines Wissens auch keinen Zeitstempel beim Key, so dass das Zurückrufen von Keys bei Kompromittierung gegenüber S/MIME weniger gut möglich ist (zentrale Keyring-Server haben sich nicht durchgesetzt).

 

Die meisten Einsatzumgebungen für E-Mail-Verschlüsselung stammen aber aus Schutzanforderungen für persönliche oder geschäftskritische Daten. Mit PGP oder S/MIME geht das in der Regel nur mit einem Subset der Kommunikationspartner, die in der Regel dann auch im Voraus bekannt sind. Der technische Aufwand bei der Empfängerseite hat nach meiner Erfahrung oft dazu geführt, dass eher darauf gesetzt wird, Verschlüsselung auf dem Transportweg zwischen den bekannten Kommunikationspartnern zu erzwingen und unverschlüsselte Kommunikation zwischen diesen zu blockieren - Regulated Partner with Forced TLS Scenario - und Opportunistic Encryption für jedermann anzubieten, bis neue Partner als Trusted Partner aufgenommen werden: Understanding Transport Layer Security (TLS) in FOPE

 

Daher sind meiner Erfahrung nach Lösungen, die ohne große technische Voraussetzungen beim Empfänger arbeiten, hier klar im Vorteil. Weiterhin erlauben solche Lösungen die Integration von Rights Management wie "Do not Reply all", "Read only", etc. und können auf sicheren Dateiaustausch ausgeweitet werden.

 

Have fun!
Daniel

[cink 10]

Hallo zusammen,

 

enQsig hat den Vorteil, dass zum einen eine windowsbasierte Lösung ist und sie sich somit nahtlos an Exchange docken kann, aber nicht muss. Frank Carius steckt als Ideengeber und Miteigentümer der Software dahinter, das heißt, technisch ist sie schon sehr weit vorne. Es gibt einige Schmankerl in Sachen Zertifikatsverwaltung, die es durchaus lohnenswert machen, sich die Software näher anzusehen. Nähere Infos dazu gerne bei mir direkt, oder auf www.enqsig.de. Ein weiterer Vorteil gegenüber der Z1 ist die deutlich bessere Bedien- und Verwaltbarkeit der Software. Dies wurde uns bislang durch die Bank bestätigt. Nicht ohne Grund hat sich die Software erst kürzlich bei einem sehr großen Finanzdienstleister gegen die Z1 durchgesetzt. CaseStudy und Name folgen demnächst. Auch preislich müssen wir uns nicht verstecken.

 

Zum Thema Office 365 Verschlüsselung: Klingt alles immer super. Aber die entscheidenden Nachteile liegen auf der Hand: Der Empfänger einer E-Mail benötigt zwingend ein Microsoft-Konto. Ich kann gut verstehen, wenn das jemand nicht möchte. Er ist zudem von einer funktionierenden Internetverbindung abhängig, um die E-Mail lesen zu können. Das ist nicht immer gewährleistet. Gerade wenn es um Punkte wie Archivierung etc. geht, wird es dann zudem kniffelig.

 

Gruß Stefan

bearbeitet 18. Juni 2014 von cink

[ThomasAnderson 0]

Hi,

 

die TLS Lösung geht dann doch durch das Email GW durch und kann nicht von diesem gescannt / aussortiert / gefiltert werden, da sie am Exchange ansetzt?

[cink 10]

Hi,

 

jain. Der Exchangeserver macht wohl eine TLS Verbindung, diese endet aber schon bei enQsig. TLS ist lediglich eine Verbindungsverschlüsselung und schützt somit nur die Verbindungen zwischen zwei Servern. Die E-Mail als solches bleibt zu jeder Zeit unverschlüsselt. enQsig kann die E-Mail also über TLS empfangen, dann per S/MIME oder PGP verschlüsseln/signieren und sie anschließend über eine TLS Verbindung an den nächsten Server weiterleiten, sofern dieser TLS unterstützt.

 

Gruß Stefan

[ThomasAnderson 0]

Ich meinte das Beispiel von Daniel. Da der Exchange ja hinter dem Email GW steht.

So wie es momentan aussieht läuft das Ganze auf eine "only TLS" Lösung raus, und das solange bis sich andere Lösungen mehr etabliert haben.

[Daniel -MSFT- 129]

Ich meinte das Beispiel von Daniel. Da der Exchange ja hinter dem Email GW steht.

 

E-Mail-Filtern/Scannen/AV machst Du in dem Beispiel direkt auf Transportebene .

[ara 10]

http://www.ciphermail.com/gateway.html

 

läuft hier sehr zuverlässig, kostet nichts, funktioniert einfach :)

[ThomasAnderson 0]

E-Mail-Filtern/Scannen/AV machst Du in dem Beispiel direkt auf Transportebene .

Kann jedes Email GW den Tunnel aufbrechen / hineinsehen oder verstehe ich da gerade etwas falsch.

Genau dafür ist der Tunnel doch gedacht?

[Daniel -MSFT- 129]

Nein, ein zwischengeschaltetes Gateway hilft Dir bei verschlüsselter Kommunikation an der Stelle nicht weiter. Die Arbeit muss im Verschlüsselungs-Gateway auf Transport-Ebene erfolgen, bevor verschlüsselt wird.

[ThomasAnderson 0]

Alles klar jetzt hats geschnackelt :) :thumb1: