E-Mail-Verschlüsselung und wie sie (k)ein Eigentor werden könnte - Was meint Ihr dazu?
Guten Morgen Kollegen,
ich arbeite im Bereich der Rechtsberatung und wir müssen natürlich im Hinblick auf Kundenwünsche auch verschlüsselte Email-Kommunikation anbieten.
Ich spiele mit dem Gedanken entweder
eine CipherMail-Appliance vor unseren Exchange zu setzen, so dass sie die Ver- und Entschlüsselung automatisch unternimmt oder
das Ganze mit GPG4Win in neuester Version mit Outlook-Plugin und einem zentralen internen SKS, der allerdings keine Synchronisierung durchführen wird, zu machen.
Die zweite Lösung teste ich derzeit und bin recht zufrieden.
Was ich mir erhoffe:
Den Flow, den ich mir ausgedacht habe:
Ich setze rein auf asymmetrische Verschlüsselung und zwar auf OpenPGP. Unsere Firma wird die Verschlüsselung unseren Kunden vorgeben, um Inkompatibilitäten vorzubeugen.
Die offiziellen Schlüssel unserer Mitarbeiter würde ich in die Outlooksignaturen einbetten und/oder den offiziellen Schlüssel als Ascii-Datei anhängen.
Offizielle Schlüssel unserer Kundschaft können die Mitarbeiter per Copy/Paste aus eingehenden Emails entnehmen und mit nur 3 Mausklicks im SKS einstellen.
Die Mitarbeiter können über Kleopatra die benötigten offiziellen Schlüssel der Kontaktpartner einfach importieren, wenn sie die noch nicht haben.
Die Emailverschlüsselung und Signierung in Outlook ist dann mit einem Mausklick auf die entsprechende Schaltfläche gemacht.
Ich sehe in dem System den Vorteil, dass Emails auf dem Emailserver nach wie vor verschlüsselt bleiben. Wird er kompromittiert z.B. durch OWA, sieht der Angreifer nur verschlüsselten Krempel.
Da die Ver- und Entschlüsselung clientbasiert ist, ist ein direktes Feedback möglich. Wenn die zentrale Ver- und Entschlüsselungsinstanz ausfällt, gelten zugestellte Emails, die sich nicht (mehr) entschlüsseln lassen dennoch als zugestellt und fristwahrend. Ich sehe im Endpunktsystem die Möglichkeit, Fehler schneller auszumerzen. Die für die Nutzer erstellten Schlüsselpaare würden natürlich gesondert, gesichert und zentral gelagert, um im Falle eines Ausfalls eines Clientsystems, die Ver- und Entschlüsselung schneller wieder in Gang zu bringen.
Der größte Nachteil liegt aus meiner Sicht in der Nachverarbeitung verschlüsselter Emails.
Wenn wir diese in unser Dokumentenmanagementsystem übernehmen wollen, wird es schwierig. Sie müssten zuerst in PDFs umgewandelt werden, damit sie entschlüsselt bleiben aus meiner Sicht.
Wie ist Eure Meinung zu dem Ansatz?
Sehe ich da vielleicht etwas falsch?
Habt vielen Dank für konstruktive Antworten und Euch allen einen guten Start in die Woche.
Andreas
ich arbeite im Bereich der Rechtsberatung und wir müssen natürlich im Hinblick auf Kundenwünsche auch verschlüsselte Email-Kommunikation anbieten.
Ich spiele mit dem Gedanken entweder
eine CipherMail-Appliance vor unseren Exchange zu setzen, so dass sie die Ver- und Entschlüsselung automatisch unternimmt oder
das Ganze mit GPG4Win in neuester Version mit Outlook-Plugin und einem zentralen internen SKS, der allerdings keine Synchronisierung durchführen wird, zu machen.
Die zweite Lösung teste ich derzeit und bin recht zufrieden.
Was ich mir erhoffe:
- Ich will das Ganze so kostengünstig wie möglich halten.
- Die Nutzer sollen simpel Emails verschicken und verschlüsseln können. (Mit Kleopatra, Outlook-Plugin und zentralem SKS eine schöne Sache soweit)
- Stringente Ver- und Entschlüsselung von Endpunkt zu Endpunkt. (Bei einem clientbasiertem Verschlüsselungssystem, bin ich der Meinung, dass das möglich ist.)
- Garantierte Ver- und Entschlüsselung möglich.
- Sehr sicherer Schlüsselaustausch
Den Flow, den ich mir ausgedacht habe:
Ich setze rein auf asymmetrische Verschlüsselung und zwar auf OpenPGP. Unsere Firma wird die Verschlüsselung unseren Kunden vorgeben, um Inkompatibilitäten vorzubeugen.
Die offiziellen Schlüssel unserer Mitarbeiter würde ich in die Outlooksignaturen einbetten und/oder den offiziellen Schlüssel als Ascii-Datei anhängen.
Offizielle Schlüssel unserer Kundschaft können die Mitarbeiter per Copy/Paste aus eingehenden Emails entnehmen und mit nur 3 Mausklicks im SKS einstellen.
Die Mitarbeiter können über Kleopatra die benötigten offiziellen Schlüssel der Kontaktpartner einfach importieren, wenn sie die noch nicht haben.
Die Emailverschlüsselung und Signierung in Outlook ist dann mit einem Mausklick auf die entsprechende Schaltfläche gemacht.
Ich sehe in dem System den Vorteil, dass Emails auf dem Emailserver nach wie vor verschlüsselt bleiben. Wird er kompromittiert z.B. durch OWA, sieht der Angreifer nur verschlüsselten Krempel.
Da die Ver- und Entschlüsselung clientbasiert ist, ist ein direktes Feedback möglich. Wenn die zentrale Ver- und Entschlüsselungsinstanz ausfällt, gelten zugestellte Emails, die sich nicht (mehr) entschlüsseln lassen dennoch als zugestellt und fristwahrend. Ich sehe im Endpunktsystem die Möglichkeit, Fehler schneller auszumerzen. Die für die Nutzer erstellten Schlüsselpaare würden natürlich gesondert, gesichert und zentral gelagert, um im Falle eines Ausfalls eines Clientsystems, die Ver- und Entschlüsselung schneller wieder in Gang zu bringen.
Der größte Nachteil liegt aus meiner Sicht in der Nachverarbeitung verschlüsselter Emails.
Wenn wir diese in unser Dokumentenmanagementsystem übernehmen wollen, wird es schwierig. Sie müssten zuerst in PDFs umgewandelt werden, damit sie entschlüsselt bleiben aus meiner Sicht.
Wie ist Eure Meinung zu dem Ansatz?
Sehe ich da vielleicht etwas falsch?
Habt vielen Dank für konstruktive Antworten und Euch allen einen guten Start in die Woche.
Andreas
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 376667
Url: https://administrator.de/forum/e-mail-verschluesselung-und-wie-sie-kein-eigentor-werden-koennte-was-meint-ihr-dazu-376667.html
Ausgedruckt am: 22.12.2024 um 09:12 Uhr
20 Kommentare
Neuester Kommentar
Hallo Andreas,
Das würde ich doch gerne als interessante These annehmen, angenommen, ich schick eine Fristsache für den Empfänger unentschlüsselbar zu diesem, wie soll darüber eine Frist gewahrt werden? Ich an der Stelle des Empfängers würde das auf jeden Fall auf eine gerichtliche Feststellung der nicht-Fristwahrung hinaus laufen lassen. Demnach passt das nicht ins Schema. Ggf. hab ich allerdings auch falsch verstanden, was du meinst.
Grundsätzlich halte ich die Sophos implementierung am Sinnvollsten: Email wird zu PDF mit Schlüssel, Schlüssel übermittel ich an den Empfänger. Gerade auch deswegen, weil i.d.R nicht 100% der Kommunikation in sich verschlüsselt sein muss.
Viele Grüße,
Christian
PS: Wofür steht bei dir SKS?
Wenn die zentrale Ver- und Entschlüsselungsinstanz ausfällt, gelten zugestellte Emails, die sich nicht (mehr) entschlüsseln lassen dennoch als zugestellt und fristwahrend
Das würde ich doch gerne als interessante These annehmen, angenommen, ich schick eine Fristsache für den Empfänger unentschlüsselbar zu diesem, wie soll darüber eine Frist gewahrt werden? Ich an der Stelle des Empfängers würde das auf jeden Fall auf eine gerichtliche Feststellung der nicht-Fristwahrung hinaus laufen lassen. Demnach passt das nicht ins Schema. Ggf. hab ich allerdings auch falsch verstanden, was du meinst.
Grundsätzlich halte ich die Sophos implementierung am Sinnvollsten: Email wird zu PDF mit Schlüssel, Schlüssel übermittel ich an den Empfänger. Gerade auch deswegen, weil i.d.R nicht 100% der Kommunikation in sich verschlüsselt sein muss.
Viele Grüße,
Christian
PS: Wofür steht bei dir SKS?
Hallo Andreas,
da hinkt dein Vergleich, denn wenn aufgrund eines Fehlers in der Verschlüsselung eurer Emails diese für den Empfänger nicht mehr entschlüsselbar sein sollten, dann ist das, wie wenn ich einen Brief einwerfe, der sich beim Anfassen (eben generell in Interaktion mit dem Empfänger oder seinen Gehilfen) selbst zerstört - bevor(!) er gelesen werden kann.
Abgesehen halte ich die Aussage "ist ja zugestellt, im Worst Case ist mir das egal, ob er gelesen werden kann" zu dem praktisch für den falschen Ansatz.
Ich denke aber, dass ein SKS (danke für die Erläuterung, hast du mir einen Link hierzu, ich fand nichts?) das Problem DSGVO wohl nicht entschärft. Die Daten liegen schliesslich parat, mehr noch, Ihr verarbeitet damit intern zu dem externe Daten und publiziert diese auch noch "diskret", aber das ist schliesslich kein DSGVO Kriterium. (nur mein Gedanke, keine Rechtsberatung ovgl).
Viele Grüße,
Christian
da hinkt dein Vergleich, denn wenn aufgrund eines Fehlers in der Verschlüsselung eurer Emails diese für den Empfänger nicht mehr entschlüsselbar sein sollten, dann ist das, wie wenn ich einen Brief einwerfe, der sich beim Anfassen (eben generell in Interaktion mit dem Empfänger oder seinen Gehilfen) selbst zerstört - bevor(!) er gelesen werden kann.
Abgesehen halte ich die Aussage "ist ja zugestellt, im Worst Case ist mir das egal, ob er gelesen werden kann" zu dem praktisch für den falschen Ansatz.
Ich denke aber, dass ein SKS (danke für die Erläuterung, hast du mir einen Link hierzu, ich fand nichts?) das Problem DSGVO wohl nicht entschärft. Die Daten liegen schliesslich parat, mehr noch, Ihr verarbeitet damit intern zu dem externe Daten und publiziert diese auch noch "diskret", aber das ist schliesslich kein DSGVO Kriterium. (nur mein Gedanke, keine Rechtsberatung ovgl).
Viele Grüße,
Christian
Das beA würde ich nun nicht unbedingt als Referenz für eine solide Integration anführen...Aber natürlich, wo ein RA dem anderen eine Einwilligung gibt, da ist das Briefgeheimnis auch entkräftet.
Auf der anderen Seite ist mit deiner Lösung jedem der Zugriff möglich, der Zugriff auf die entsprechende Datenbank hat.
Viele Grüße,
Christian
Auf der anderen Seite ist mit deiner Lösung jedem der Zugriff möglich, der Zugriff auf die entsprechende Datenbank hat.
Viele Grüße,
Christian
Nimm die Gateway Lösung, der zusätzliche Sicherheitsgewinn von echter Ende-zu-Ende Verschlüsselung wird mit Ablehnung durch die Benutzer erkauft. Wenn du deinem eigenen Mailserver nicht trauen kannst läuft sowieso grundsätzlich etwas falsch und OWA wird von den Benutzern als Feature gesehen und nicht als Sicherheitslücke.
Nur mit einer Gateway Lösung kannst du eine für nicht Techniker verständliche Lösung anbieten und zentral organisierte Policies bezüglich Verschlüsselung durchsetzen. Dann ist es auch egal ob der Empfänger/Sender S/MIME oder PGP verwenden will wenn das Gateway beides kann.
Das ist meine Erfahrung nach fast 10 Jahren zu diesem Thema, YMMV
Gruß
Andi
Nur mit einer Gateway Lösung kannst du eine für nicht Techniker verständliche Lösung anbieten und zentral organisierte Policies bezüglich Verschlüsselung durchsetzen. Dann ist es auch egal ob der Empfänger/Sender S/MIME oder PGP verwenden will wenn das Gateway beides kann.
Das ist meine Erfahrung nach fast 10 Jahren zu diesem Thema, YMMV
Gruß
Andi
CipherMail kann sowohl PGP, S/MIME als auch verschlüsseltes PDF und Kennwort übertragen, die kostenpflichtige Version hat sogar ein Abholportal. Mit PGP oder S/MIME funktioniert es genauso wie mit "echter" E2E Verschlüsselung nur das dein Ende auf dem Gateway und nicht auf zig Client Devices liegt. Das ist Man-in-the-Middle sicher solange du ein passendes Zertifiakte/Schlüsselmanagement hast. Die PDF Verschlüsselung ist nur dann sinnvoll wenn das Passwort auf einem anderen Weg wie das PDF übertragen wird, CipherMail könnte meine ich SMS nutzen.
Allerdings sind meiner Meinung nach alle Verfahren die nicht nahtlos wie E-Mail funktionieren ein zusätzliche WTF für den Benutzer und wird deshalb selten oder gar nicht genutzt. Wenn unsere Benutzer ein E-Mail mit einem Passwort erhalten oder aufgefordert werden sich auf irgend einer Webseite anzumelden um eine ganz geheime E-Mail abzuholen fliegt diese E-Mail (hoffentlich!) in den Müll.
Deshalb nimm das Gateway und richte S/MIME und PGP ein und deine Benutzer werden nicht mal merken ob die E-Mails verschlüsselt sind. Zusätzlich für Empfänger oder Domains eine Policy für die nur verschlüsselt verschickt werden darf und gut ist.
Alles andere wird auf die Dauer nicht genutzt. Jedesmal die IT anrufen und womöglich ein Ticket aufmachen wenn der Inhalt der E-Mail möglicherweise geheim ist macht auf die Dauer keiner.
Gruß und viel Erfolg
Andi
Allerdings sind meiner Meinung nach alle Verfahren die nicht nahtlos wie E-Mail funktionieren ein zusätzliche WTF für den Benutzer und wird deshalb selten oder gar nicht genutzt. Wenn unsere Benutzer ein E-Mail mit einem Passwort erhalten oder aufgefordert werden sich auf irgend einer Webseite anzumelden um eine ganz geheime E-Mail abzuholen fliegt diese E-Mail (hoffentlich!) in den Müll.
Deshalb nimm das Gateway und richte S/MIME und PGP ein und deine Benutzer werden nicht mal merken ob die E-Mails verschlüsselt sind. Zusätzlich für Empfänger oder Domains eine Policy für die nur verschlüsselt verschickt werden darf und gut ist.
Alles andere wird auf die Dauer nicht genutzt. Jedesmal die IT anrufen und womöglich ein Ticket aufmachen wenn der Inhalt der E-Mail möglicherweise geheim ist macht auf die Dauer keiner.
Gruß und viel Erfolg
Andi
Hallo,
Gut - dann hängt es natürlich grundsätzlich erst einmal davon ab, wie der Kunde die E-Mails verschlüsselt.
Wenn es Stammkunden sind und es eher um Dokumente (also die Anhänge) und weniger um den E-Mail-Text geht, könnte man darüber nachdenken, ob Ihr einen Cloudserver anbietet.
Gruß,
Jörg
Zitat von @beidermachtvongreyscull:
ich arbeite im Bereich der Rechtsberatung und wir müssen natürlich im Hinblick auf Kundenwünsche auch verschlüsselte Email-Kommunikation anbieten.
ich arbeite im Bereich der Rechtsberatung und wir müssen natürlich im Hinblick auf Kundenwünsche auch verschlüsselte Email-Kommunikation anbieten.
Gut - dann hängt es natürlich grundsätzlich erst einmal davon ab, wie der Kunde die E-Mails verschlüsselt.
Wenn es Stammkunden sind und es eher um Dokumente (also die Anhänge) und weniger um den E-Mail-Text geht, könnte man darüber nachdenken, ob Ihr einen Cloudserver anbietet.
Gruß,
Jörg
Guten Abend Andreas,
Gruß,
Dani
Oder würdest Du eher zu einem anderen Gateway tendieren?
wir nutzen bei uns inzwischen NoSpamProxy mit entsprechenden Modulen. Ursprünglich hatten wir NoSpamProxy als SMTP Proxy für Spam/Malwareschutz eingeführt. Inzwischen nutzen wir alle Module und haben verschiedenster Software ausgemustert. Es ging um Konsolidierung von verschiedenen Produkten bzw. Wartungsverträgen, Lizenzen und Support.Gruß,
Dani
Hallo,
Sagen wir mal so: Ich würde Dienstleistungen und Produkte unterscheiden.
Dienstleistungen sind etwas persönliches, hier passt sich normalerweise derjenige an, in dessen Richtung das Geld fließt.
Produkte ist etwas automatisiertes und standartisiertes. Hier bastelt der Kunde halt selber, um sich an meine Prozesse anzudocken.
Aber das geht jetzt sicherlich deutlich am Thema vorbei. Meine Meinung "hab ich ja gesagt" und letztendlich habe ich durch deine Anfrage auch nur einen kleinen Einblick in euer Gewerbe gewinnen können
Gruß,
Jörg
Zitat von @beidermachtvongreyscull:
Wäre im Prinzip richtig, allerdings müssten wir uns dann jedem anpassen.
Gut - dann hängt es natürlich grundsätzlich erst einmal davon ab, wie der Kunde die E-Mails verschlüsselt.
Wäre im Prinzip richtig, allerdings müssten wir uns dann jedem anpassen.
Sagen wir mal so: Ich würde Dienstleistungen und Produkte unterscheiden.
Dienstleistungen sind etwas persönliches, hier passt sich normalerweise derjenige an, in dessen Richtung das Geld fließt.
Produkte ist etwas automatisiertes und standartisiertes. Hier bastelt der Kunde halt selber, um sich an meine Prozesse anzudocken.
Aber das geht jetzt sicherlich deutlich am Thema vorbei. Meine Meinung "hab ich ja gesagt" und letztendlich habe ich durch deine Anfrage auch nur einen kleinen Einblick in euer Gewerbe gewinnen können
Gruß,
Jörg