11
Verständnisfrage Exchange Server, Outlook und S MIME Verschlüsselung
Hallo,
ich habe eine Verständnisfrage zur Funktionsweise von S/MIME Verschlüsselung mit Exchange Server/Outlook.
Ausgangsinfrastruktur:
Ein DC, ein Exchange Server (großteils On-Premises, aber auch Exchange Server Online) und x Clients mit Outlook und x Benutzern.
Ich habe keine praktische Erfahrung mit Exchange Server. Daher geht es mir nicht um die genaue Einrichtung, sondern um die mögliche Umsetzung. Bevor ich mich etwas genauer mit dem Thema beschäftigt habe, ging ich von folgender Einrichtung aus:
S/MIME Zertifikate für alle Postfächer erstellen. Diese dann im Exchange Server zu den jeweiligen Postfächern importieren. So dass der Exchange Server die Ver- und Entschlüsselung der E-Mails automatisch übernimmt.
Nun hat sich erstmal für mich herausgestellt das es doch nicht so einfach ist.
Was ich bis jetzt so gelesen habe:
1) Outlook:
Das S/MIME Zertifikat muss an jedem Client für den entsprechenden User importiert werden.
Das ist doch recht umständlich, vor allem wenn eine Domäne vorhanden ist. Und wenn die User doch mal den Client wechseln und sich mir ihrem Account anmelden, so wären die S/MIME Zertifikat nicht für diesen User auf diesem Client eingerichtet.
Wie würde das mit den öffentlichen Postfächern (info@ usw.) aussehen? Muss ich die S/MIME Zertifikat dann auch in den Clients importieren, die auf diese Postfächer Zugriff haben müssen. Sehr wahrscheinlich. Ich gehe davon aus das dann weiterhin die Synchronisation klappt, so dass alle die auf diese öffentlichen Postfächer Zugriff haben sollen, die empfangenen und gesendeten E-Mails lesen können.
Bei dieser Umsetzung werden die E-Mails bei den Clients verschlüsselt in der PST-Datei abgelegt, oder? Nach meinem Verständnis wird bei einer Ransomware Attacke die PST-Datei abgesaugt. So gelangen die an die komplette E-Mail-Korrespondenz des Opfers. Wenn die E-Mails aber in der PST-Datei verschlüsselt abgelegt sind, können die Angreifer nichts damit anfangen, oder?
2) Exchange Server:
Beim schnellen Überfliegen habe ich es so verstanden, dass ich einen CA-Server brauche in dem die S/MIME Zertifikat hinterlegt werden. Je nach Situation noch ein PKI-Server.
Es erfolgt eine Einstellung in der AD sowie auf dem Exchange Server.
Den noch muss ich die S/MIME Zertifikat auf jedem Client wie bei 1) importieren.
Den noch würde das S/MIME Zertifikat nicht automatisch bei den Clients installiert, wenn der User mal den Client wechselt, oder?
Einen wirklichen Vorteil kann ich da jetzt nicht zu 1) sehen.
3) E-Mail-Gateway:
Ich schalte vor dem Exchange-Server einen E-Mail-Gateway davor, der die Ver- und Entschlüsselung der E-Mails übernimmt.
Hier muss ich nur die S/MIME Zertifikat der User im Gateway hinterlegen und „fertig“.
Was mich hier aber stört, ist dass die E-Mails dann unverschlüsselt im Exchange-Server bzw. im Client (PST-Datei) liegt. So dass bei einer Ransomware Attacke die Angreifer die E-Mails unverschlüsselt absaugen können, richtig?
Es ist ja möglich das keine Daten auf den Clients in der PST-Datei gespeichert/synchronisiert werden und die E-Mails nur auf dem Exchange Server liegen. Damit wäre aber das Offline-Arbeiten im Outlook nicht mehr möglich, da ja keine E-Mails in der PST-Datei sind. Dann kann man nur hoffen das es keine gravierende Sicherheitslücke im Exchange-Server gibt, die es Angreifer ermöglicht die E-Mails abzusaugen.
4) Eine Möglichkeit die ich noch nicht gefunden oder übersehen habe:
Kennt ihr eine Alternative zu den drei zuvor genannten Varianten? Leider muss ich dabei vorerst im Outlook oder Exchanger-Server Universum bleiben.
Wie ihr bestimmt schon festgestellt habt, habe ich ein große Augenmerkmal auf Datensicherheit gelegt. Vor allem das keine unbefugten Dritten an unverschlüsselte E-Mails gelangen (sofern die E-Mails auch verschlüsselt wurden). Und das Zusammenarbeiten (öffentliche Postfächer) nicht beeinträchtigt. Idealer weiße sollte der administrative Aufwand in Grenzen halten – auch für einen Turnschuh-Admin.
Danke für eure Hilfe.
ich habe eine Verständnisfrage zur Funktionsweise von S/MIME Verschlüsselung mit Exchange Server/Outlook.
Ausgangsinfrastruktur:
Ein DC, ein Exchange Server (großteils On-Premises, aber auch Exchange Server Online) und x Clients mit Outlook und x Benutzern.
Ich habe keine praktische Erfahrung mit Exchange Server. Daher geht es mir nicht um die genaue Einrichtung, sondern um die mögliche Umsetzung. Bevor ich mich etwas genauer mit dem Thema beschäftigt habe, ging ich von folgender Einrichtung aus:
S/MIME Zertifikate für alle Postfächer erstellen. Diese dann im Exchange Server zu den jeweiligen Postfächern importieren. So dass der Exchange Server die Ver- und Entschlüsselung der E-Mails automatisch übernimmt.
Nun hat sich erstmal für mich herausgestellt das es doch nicht so einfach ist.
Was ich bis jetzt so gelesen habe:
1) Outlook:
Das S/MIME Zertifikat muss an jedem Client für den entsprechenden User importiert werden.
Das ist doch recht umständlich, vor allem wenn eine Domäne vorhanden ist. Und wenn die User doch mal den Client wechseln und sich mir ihrem Account anmelden, so wären die S/MIME Zertifikat nicht für diesen User auf diesem Client eingerichtet.
Wie würde das mit den öffentlichen Postfächern (info@ usw.) aussehen? Muss ich die S/MIME Zertifikat dann auch in den Clients importieren, die auf diese Postfächer Zugriff haben müssen. Sehr wahrscheinlich. Ich gehe davon aus das dann weiterhin die Synchronisation klappt, so dass alle die auf diese öffentlichen Postfächer Zugriff haben sollen, die empfangenen und gesendeten E-Mails lesen können.
Bei dieser Umsetzung werden die E-Mails bei den Clients verschlüsselt in der PST-Datei abgelegt, oder? Nach meinem Verständnis wird bei einer Ransomware Attacke die PST-Datei abgesaugt. So gelangen die an die komplette E-Mail-Korrespondenz des Opfers. Wenn die E-Mails aber in der PST-Datei verschlüsselt abgelegt sind, können die Angreifer nichts damit anfangen, oder?
2) Exchange Server:
Beim schnellen Überfliegen habe ich es so verstanden, dass ich einen CA-Server brauche in dem die S/MIME Zertifikat hinterlegt werden. Je nach Situation noch ein PKI-Server.
Es erfolgt eine Einstellung in der AD sowie auf dem Exchange Server.
Den noch muss ich die S/MIME Zertifikat auf jedem Client wie bei 1) importieren.
Den noch würde das S/MIME Zertifikat nicht automatisch bei den Clients installiert, wenn der User mal den Client wechselt, oder?
Einen wirklichen Vorteil kann ich da jetzt nicht zu 1) sehen.
3) E-Mail-Gateway:
Ich schalte vor dem Exchange-Server einen E-Mail-Gateway davor, der die Ver- und Entschlüsselung der E-Mails übernimmt.
Hier muss ich nur die S/MIME Zertifikat der User im Gateway hinterlegen und „fertig“.
Was mich hier aber stört, ist dass die E-Mails dann unverschlüsselt im Exchange-Server bzw. im Client (PST-Datei) liegt. So dass bei einer Ransomware Attacke die Angreifer die E-Mails unverschlüsselt absaugen können, richtig?
Es ist ja möglich das keine Daten auf den Clients in der PST-Datei gespeichert/synchronisiert werden und die E-Mails nur auf dem Exchange Server liegen. Damit wäre aber das Offline-Arbeiten im Outlook nicht mehr möglich, da ja keine E-Mails in der PST-Datei sind. Dann kann man nur hoffen das es keine gravierende Sicherheitslücke im Exchange-Server gibt, die es Angreifer ermöglicht die E-Mails abzusaugen.
4) Eine Möglichkeit die ich noch nicht gefunden oder übersehen habe:
Kennt ihr eine Alternative zu den drei zuvor genannten Varianten? Leider muss ich dabei vorerst im Outlook oder Exchanger-Server Universum bleiben.
Wie ihr bestimmt schon festgestellt habt, habe ich ein große Augenmerkmal auf Datensicherheit gelegt. Vor allem das keine unbefugten Dritten an unverschlüsselte E-Mails gelangen (sofern die E-Mails auch verschlüsselt wurden). Und das Zusammenarbeiten (öffentliche Postfächer) nicht beeinträchtigt. Idealer weiße sollte der administrative Aufwand in Grenzen halten – auch für einen Turnschuh-Admin.
Danke für eure Hilfe.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671374
Url: https://administrator.de/forum/verstaendnisfrage-exchange-server-outlook-und-s-mime-verschluesselung-671374.html
Ausgedruckt am: 19.02.2025 um 04:02 Uhr
11 Kommentare
Neuester Kommentar
ALSO 
fangen wir mal klein an. Erstmal das S/Mime Zertifikat und wie das funktiuoniert.
Es gibt immer einen PRIVAT key und einen Public key (key = Zertifikat).
So wenn dir jemand eine verschlüsseltes Email schicken soll, dann muss er erst dein Public key haben, ansonsten kann er es für dich ja nicht verschlüsseln. Zum entschlüsseln ist dein Private Key im outlook oder per third party software (Plugin Outlook) eingebunden.
Bedeutet wenn du jemand eine verschlüsselte email schicken willst, dann musst du auch erst seinen Public key haben.
Dann kannst deine Email mit deinem Public key quasi signieren, also wenn man die dann anders speichert passt es nicht mehr, und gleichzeitig ist die signatur eben dein public key >> somit kann der empfänger dir dann antworten verschlüsselt.
soweit so gut.
Nun kommen wir zum Punkt PKI, eine PrivateKey Infrastruktur. das ist dann das ding was die deinen private und public key verwaltet und erstellt usw...
jetz gibts 3 möglichkeiten
1. du holst die die keys bei entsprechenden anbietern und dann bindest du sie entsprechend ein und kosten halt
2. du hast so ne eigene PKI, meist kennt aber niemand deine PKI was dann nachteile hat das leute nirgends ihre keys public haben und somit fremde nur per vorheriger signierter email in den genuss des public keys kommen
3. du nutzt so ein email secure gateway, da werden auch keys erstellt meist gekoppelt an dienstleister siehe 1. punkt aber halt automatisch und die hersteller der appliance haben dann so zentrale public PKI stores wo vernünftige software auch nachschaut, kann man sich ggf. das vorherige signierte email schicken sparen....
4. gibts auch noch die möglichkeit mit outlook online 365 postfach kann man das direkt enablen und keys werden erstellt und im Azure AD User hinterlegt, ABER nicht downloadbar der Private key
was das ganze problem daran mit den keys? machst du ende zu ende encryption, bedeutet die email landet verschlüsselt in deinem posteingang und wird nur live beim aufmachen entschlüsselt, dann brauchst du den private key davor. vorteil auch im backup ist es verschlüsselt, nachteil >> man muss auf die emails 10 jahre lang zugriff haben. so und wenn nun das zertifikat nicht downloadbar ist als admin und irgendwo verwart wird, kommt man dann plötzlich nicht an die emails, weil user nach 5 jahren gegangen, lizenz weg, user wird in der cloud automatisch gelöscht nach x monaten und futsch...
daher fällt version 4 nach deutschem recht und meisten anderen ländern eigentlich flach... mein gott hatte ich da ne diskussion mit microsoft leuten... abartig...
egal also appliance mail gateway ist wohl die praktikabelste weil die mails liegen nicht verschlüsselt beim endanwender im postfach, dort sind sie immer entschlüsselt. sondern lediglich im email flow also outlook >> an server oder exchange online hat vorher noch appliance zwischen drin, die hat rules wenns nach extern geht versuchen zu verschlüsseln sofern public key abgreifbar oder bekannt >> dann verschlüsselt übern exchange oder über exchange online raus. für den empfang ist der empfänger zuständig >> sein bier.
beim empfang kommt email rein und appliance merkt sich auch signaturen also public keys die so reinkommen... und entschlüsselt mail und das geht dann zum email server ins postfach und liegt da unentschlüsselt.
Wenn mans genau nimmt ist das eigentlich nicht verschlüsseltr versand weil wenns dann wieder exchange online geht ist der weg vom mail gateway zum exchange online unverschlüsselt un das geht auch übers internet.
ABER ist halt quadratisch praktisch gut und easy zu handhaben, kostet halt pro user... anmerkung die verdienen sich da schon ne goldene nase...
so hoffe konnte dir ein wenig erklären bei fragen oder mehr details nochmal fragen.
meine meinung wenn du nicht viel ärger haben willst hol die ein email secure gateway...
aber auch hier abklären was mit den Private Keys passiert ob die gebackupt werden und wo und wie wegen 10 jahre aufbewahrungszeit von geschäftlicher korespondenz wozu nun mal auch emails gehören.
WIN als Admin Restore von Emails Problemlos
WIN Rechtlich im Grünen Bereich deswegen (Aufbewahrungspflicht) ohne mords aufwand
LOSE gewisse wege sind dann nicht gesichert, gilt aber trotzdem als verschlüsselt...
wählst du die vollverschlüsselung
LOSE Jeder User muss der Key gesichert werden und ggf. individuell eingerichtet werden usw...
LOSE Restore nur von verschlüsselten Emails möglich
LOSE hast du keine keys Rechtlich am Ars..
WIN voller Weg verschlüsselt auf deiner seite, wenn empfänger Email Secure Gateway benutzt hättest du es dir auch sparen können
fangen wir mal klein an. Erstmal das S/Mime Zertifikat und wie das funktiuoniert.
Es gibt immer einen PRIVAT key und einen Public key (key = Zertifikat).
So wenn dir jemand eine verschlüsseltes Email schicken soll, dann muss er erst dein Public key haben, ansonsten kann er es für dich ja nicht verschlüsseln. Zum entschlüsseln ist dein Private Key im outlook oder per third party software (Plugin Outlook) eingebunden.
Bedeutet wenn du jemand eine verschlüsselte email schicken willst, dann musst du auch erst seinen Public key haben.
Dann kannst deine Email mit deinem Public key quasi signieren, also wenn man die dann anders speichert passt es nicht mehr, und gleichzeitig ist die signatur eben dein public key >> somit kann der empfänger dir dann antworten verschlüsselt.
soweit so gut.
Nun kommen wir zum Punkt PKI, eine PrivateKey Infrastruktur. das ist dann das ding was die deinen private und public key verwaltet und erstellt usw...
jetz gibts 3 möglichkeiten
1. du holst die die keys bei entsprechenden anbietern und dann bindest du sie entsprechend ein und kosten halt
2. du hast so ne eigene PKI, meist kennt aber niemand deine PKI was dann nachteile hat das leute nirgends ihre keys public haben und somit fremde nur per vorheriger signierter email in den genuss des public keys kommen
3. du nutzt so ein email secure gateway, da werden auch keys erstellt meist gekoppelt an dienstleister siehe 1. punkt aber halt automatisch und die hersteller der appliance haben dann so zentrale public PKI stores wo vernünftige software auch nachschaut, kann man sich ggf. das vorherige signierte email schicken sparen....
4. gibts auch noch die möglichkeit mit outlook online 365 postfach kann man das direkt enablen und keys werden erstellt und im Azure AD User hinterlegt, ABER nicht downloadbar der Private key
was das ganze problem daran mit den keys? machst du ende zu ende encryption, bedeutet die email landet verschlüsselt in deinem posteingang und wird nur live beim aufmachen entschlüsselt, dann brauchst du den private key davor. vorteil auch im backup ist es verschlüsselt, nachteil >> man muss auf die emails 10 jahre lang zugriff haben. so und wenn nun das zertifikat nicht downloadbar ist als admin und irgendwo verwart wird, kommt man dann plötzlich nicht an die emails, weil user nach 5 jahren gegangen, lizenz weg, user wird in der cloud automatisch gelöscht nach x monaten und futsch...
daher fällt version 4 nach deutschem recht und meisten anderen ländern eigentlich flach... mein gott hatte ich da ne diskussion mit microsoft leuten... abartig...
egal also appliance mail gateway ist wohl die praktikabelste weil die mails liegen nicht verschlüsselt beim endanwender im postfach, dort sind sie immer entschlüsselt. sondern lediglich im email flow also outlook >> an server oder exchange online hat vorher noch appliance zwischen drin, die hat rules wenns nach extern geht versuchen zu verschlüsseln sofern public key abgreifbar oder bekannt >> dann verschlüsselt übern exchange oder über exchange online raus. für den empfang ist der empfänger zuständig >> sein bier.
beim empfang kommt email rein und appliance merkt sich auch signaturen also public keys die so reinkommen... und entschlüsselt mail und das geht dann zum email server ins postfach und liegt da unentschlüsselt.
Wenn mans genau nimmt ist das eigentlich nicht verschlüsseltr versand weil wenns dann wieder exchange online geht ist der weg vom mail gateway zum exchange online unverschlüsselt un das geht auch übers internet.
ABER ist halt quadratisch praktisch gut und easy zu handhaben, kostet halt pro user... anmerkung die verdienen sich da schon ne goldene nase...
so hoffe konnte dir ein wenig erklären bei fragen oder mehr details nochmal fragen.
meine meinung wenn du nicht viel ärger haben willst hol die ein email secure gateway...
aber auch hier abklären was mit den Private Keys passiert ob die gebackupt werden und wo und wie wegen 10 jahre aufbewahrungszeit von geschäftlicher korespondenz wozu nun mal auch emails gehören.
WIN als Admin Restore von Emails Problemlos
WIN Rechtlich im Grünen Bereich deswegen (Aufbewahrungspflicht) ohne mords aufwand
LOSE gewisse wege sind dann nicht gesichert, gilt aber trotzdem als verschlüsselt...
wählst du die vollverschlüsselung
LOSE Jeder User muss der Key gesichert werden und ggf. individuell eingerichtet werden usw...
LOSE Restore nur von verschlüsselten Emails möglich
LOSE hast du keine keys Rechtlich am Ars..
WIN voller Weg verschlüsselt auf deiner seite, wenn empfänger Email Secure Gateway benutzt hättest du es dir auch sparen können
Danke dir.
Beim Thema S/MIME und PGP bin ich gut im Bilde. Haben selber S/MIME in Nutzung, aber halt ohne Exchange und Outlook.
Auch die Thematik revisionsicher und Schlüssel aufheben, da ja die S/MIME alle 3 und ab Juni/Juli aller 2 Jahre ausgetauscht werden müssen.
Die Probleme des Empfängers sind mir egal Für mich ist die "Sicherheit" der eigenen Kunden entscheiden, sofern es gewünscht ist.
Beim Thema S/MIME und PGP bin ich gut im Bilde. Haben selber S/MIME in Nutzung, aber halt ohne Exchange und Outlook.
Auch die Thematik revisionsicher und Schlüssel aufheben, da ja die S/MIME alle 3 und ab Juni/Juli aller 2 Jahre ausgetauscht werden müssen.
Die Probleme des Empfängers sind mir egal
Für mich ist die "Sicherheit" der eigenen Kunden entscheiden, sofern es gewünscht ist.
Zitat von @oi-polloi:
1) Outlook:
Das S/MIME Zertifikat muss an jedem Client für den entsprechenden User importiert werden.
Das S/MIME Zertifikat muss an jedem Client für den entsprechenden User importiert werden.
Ja, man benötigt ein passendes Deployment, notfalls manuell.
Wie würde das mit den öffentlichen Postfächern (info@ usw.) aussehen? Muss ich die S/MIME Zertifikat dann auch in den Clients importieren, die auf diese Postfächer Zugriff haben müssen.
Ja.
Bei dieser Umsetzung werden die E-Mails bei den Clients verschlüsselt in der PST-Datei abgelegt, oder? Nach meinem Verständnis wird bei einer Ransomware Attacke die PST-Datei abgesaugt. So gelangen die an die komplette E-Mail-Korrespondenz des Opfers. Wenn die E-Mails aber in der PST-Datei verschlüsselt abgelegt sind, können die Angreifer nichts damit anfangen, oder?
Da die PST Dateien ja lokal auf dem Endgerät liegen und der Angreifer Zugriff auf diesen hat, ist ja auch der Zugriff auf die Zertifikate gegeben. Somit sollte die Ablageart keine Rolle spielen.
2) Exchange Server:
Der Exchange Server ist in die E2E Verschlüsselung nicht involviert und benötigt hierfür somit auch nicht die S/MIME Zertifikate, somit ist hierfür auch keine PKI Infrastruktur notwendig.
3) E-Mail-Gateway:
Ich schalte vor dem Exchange-Server einen E-Mail-Gateway davor, der die Ver- und Entschlüsselung der E-Mails übernimmt.
Hier muss ich nur die S/MIME Zertifikat der User im Gateway hinterlegen und „fertig“.
Was mich hier aber stört, ist dass die E-Mails dann unverschlüsselt im Exchange-Server bzw. im Client (PST-Datei) liegt. So dass bei einer Ransomware Attacke die Angreifer die E-Mails unverschlüsselt absaugen können, richtig?
Ich schalte vor dem Exchange-Server einen E-Mail-Gateway davor, der die Ver- und Entschlüsselung der E-Mails übernimmt.
Hier muss ich nur die S/MIME Zertifikat der User im Gateway hinterlegen und „fertig“.
Was mich hier aber stört, ist dass die E-Mails dann unverschlüsselt im Exchange-Server bzw. im Client (PST-Datei) liegt. So dass bei einer Ransomware Attacke die Angreifer die E-Mails unverschlüsselt absaugen können, richtig?
Richtig, es ist keine E2E Verschlüsselung.
4) Eine Möglichkeit die ich noch nicht gefunden oder übersehen habe:
Kennt ihr eine Alternative zu den drei zuvor genannten Varianten?
Kennt ihr eine Alternative zu den drei zuvor genannten Varianten?
Die wäre mir nicht bekannt.
S/MIME ist kein Schutz vor Ransomware und Datenabluss.
Ich würde auch erstmal das Ziel näher betrachten, das man mit der S/MIME Verschlüsselung erreichen will.
Auch der Exchange-Server sollte sicher sein oder hinter einem Proxy oder ähnliches. Hilft es dir da wirklich wenn ein vermutlich kleiner Teil an E-Mails auf dem Exchange verschlüsselt liegt? Meta-Daten sind ja auch in diesem Fall betroffen - ich weiß nicht ob man das irgendwie als "mehr Sicherheit" betrachten sollte.
Ich persönlich nutze Ciphermail als Gateway und bin damit sehr zufrieden. Ich habe allerdings keine PKI Anbindung und kann Zertifikate auch nicht automatisch prüfen, das Ding nimmt nur E-Mails an und schickt sie weg. Ich konfiguriere also alles quasi zu Fuß - dafür aber gezielt so wie ich es will. Wir kaufen Zertifikate, ich kann aber auch eigene, nicht öffentlich vertrauenswürdige Zertifikate erstellen und kann darüber mit anderen Gateways auch z.B. auf Domain-Level mit dem selben Zertifikat SMIME machen. Mein Exchange lebt sogar sicherer weil nur das Gateway von extern ohne VPN erreichbar ist, nicht der Exchange...
S/MIME durch den Client finde ich hauptsächlich dann sinnvoll, wenn der User nicht der Infrastruktur vertraut. Also die HR oder GF die zum Beispiel nicht wollen das ihre Admins Mails lesen können. Ansonsten ist das echt nur nervig. Vor allem auch auf Mobilgeräten....
S/MIME ist kein Schutz vor Ransomware und Datenabluss.
Richtig. Du sprichst immer davon das eine Ransomware dein System angreifen könnte und verschlüsselte E-Mails in einer PST dann "sicher" wären. Allerdings liegt auch der private key auf dem Client - Ich halte es für sehr zweifelhaft das wenn der Client komprommitiert wird, das Zertifikat halt nicht abfließen soll, die PST aber schon. Könnte theoretisch sein aber annehmen würde ich das nicht.Auch der Exchange-Server sollte sicher sein oder hinter einem Proxy oder ähnliches. Hilft es dir da wirklich wenn ein vermutlich kleiner Teil an E-Mails auf dem Exchange verschlüsselt liegt? Meta-Daten sind ja auch in diesem Fall betroffen - ich weiß nicht ob man das irgendwie als "mehr Sicherheit" betrachten sollte.
Ich persönlich nutze Ciphermail als Gateway und bin damit sehr zufrieden. Ich habe allerdings keine PKI Anbindung und kann Zertifikate auch nicht automatisch prüfen, das Ding nimmt nur E-Mails an und schickt sie weg. Ich konfiguriere also alles quasi zu Fuß - dafür aber gezielt so wie ich es will. Wir kaufen Zertifikate, ich kann aber auch eigene, nicht öffentlich vertrauenswürdige Zertifikate erstellen und kann darüber mit anderen Gateways auch z.B. auf Domain-Level mit dem selben Zertifikat SMIME machen. Mein Exchange lebt sogar sicherer weil nur das Gateway von extern ohne VPN erreichbar ist, nicht der Exchange...
S/MIME durch den Client finde ich hauptsächlich dann sinnvoll, wenn der User nicht der Infrastruktur vertraut. Also die HR oder GF die zum Beispiel nicht wollen das ihre Admins Mails lesen können. Ansonsten ist das echt nur nervig. Vor allem auch auf Mobilgeräten....
Zitat von @mbehrens:
Bei dieser Umsetzung werden die E-Mails bei den Clients verschlüsselt in der PST-Datei abgelegt, oder? Nach meinem Verständnis wird bei einer Ransomware Attacke die PST-Datei abgesaugt. So gelangen die an die komplette E-Mail-Korrespondenz des Opfers. Wenn die E-Mails aber in der PST-Datei verschlüsselt abgelegt sind, können die Angreifer nichts damit anfangen, oder?
Da die PST Dateien ja lokal auf dem Endgerät liegen und der Angreifer Zugriff auf diesen hat, ist ja auch der Zugriff auf die Zertifikate gegeben. Somit sollte die Ablageart keine Rolle spielen.
Zitat von @ukulele-7:
Ich würde auch erstmal das Ziel näher betrachten, das man mit der S/MIME Verschlüsselung erreichen will.
S/MIME ist kein Schutz vor Ransomware und Datenabluss.
Richtig. Du sprichst immer davon das eine Ransomware dein System angreifen könnte und verschlüsselte E-Mails in einer PST dann "sicher" wären. Allerdings liegt auch der private key auf dem Client - Ich halte es für sehr zweifelhaft das wenn der Client komprommitiert wird, das Zertifikat halt nicht abfließen soll, die PST aber schon. Könnte theoretisch sein aber annehmen würde ich das nicht.Ok, wenn das so ist, dann bin ich gerade echt baff.
Wir verwenden S/MIME. Die Zertifikate binde ich je postfach in unsere CRM (welche auch E-Mail-Kommunikation abbildet) ein. Beim einspielen des Zertifikats werde ich immer nach dem Passwort zu dem Zertifikat gefragt.
Nun ging ich davon aus, wenn die das Zertifikat in Outlook importiere ich ebenfalls nach dem PW des Zeritifkats gefragt werde.
Ist dem nicht so?
Und wenn nach dem PW gefragt wird, wird das doch hoffentlich nicht irgendwo (Regestry oder sonstwo) im Klartext von Outlook gespeichert?
S/MIME ist kein Schutz vor Ransomware und Datenabluss.
Ja es ist kein Schutz vor Datenabfluss, aber was nützen die Daten wenn diese Verschlüsselt sind und die Angreifer nicht das Zertifikat samt Passwort haben. Es ist im Endeffekt "nur" wichtig, dass keine Dritten die Daten lesen (verarbeiten) können.
Ok, in wie weit Outlook gegen Brutforceattaken bei der Zertifikatpasswortabfrage geschützt ist, weiß ich nicht.
Ich ging davon aus, dass die E-Mails verschlüsselt auf dem Client (PST-Datei) liegen und erst beim öffnen von Outlook diese Daten mit dem Zertifikat "live" entschlüsselt werden.
Da stellst sich mir gerade die Frage:
Ist eine E2E-Verschlüsselung mit MS-Produkten bei der E-Mail-Kommunikation nicht möglich? Irgendwie kann ich mir das nicht vorstellen, da MS ja immer gern das super Busines-Produkt sein möchte.
Auch der Exchange-Server sollte sicher sein oder hinter einem Proxy oder ähnliches. Hilft es dir da wirklich wenn ein vermutlich kleiner Teil an E-Mails auf dem Exchange verschlüsselt liegt? Meta-Daten sind ja auch in diesem Fall betroffen - ich weiß nicht ob man das irgendwie als "mehr Sicherheit" betrachten sollte.
Meta-daten lasse ich erst einmal bei Seite.
Erst einmal ist der E-Mail-Inhalt für mich entscheiden. Und dieser kann E2E-Verschlüsselt werden. Das Verhindern das Dritte Zugriff auf den Inhalt erlangen könnten, ist für mich aktuell an erster Stelle.
Vor 6 Jahren konnte ich unter Thunderbird ( mit PGP) auch bestimmen das der Betreff mit verschlüsselt wird. Gibt es so eine Option bei Outlook (Exchange Server)?
Die Gerichte und Landesdatenschutzbehörden gehen da langsam einen nervigen Weg und zwar das neben TLS auch E2E-Verschlüsselung verpflichten wird (jeweils für manche Berufsgruben oder vlt auch nicht).
Mein Exchange lebt sogar sicherer weil nur das Gateway von extern ohne VPN erreichbar ist, nicht der Exchange...
Versuch ich mir zu merken.
S/MIME durch den Client finde ich hauptsächlich dann sinnvoll, wenn der User nicht der Infrastruktur vertraut. Also die HR oder GF die zum Beispiel nicht wollen das ihre Admins Mails lesen können. Ansonsten ist das echt nur nervig. Vor allem auch auf Mobilgeräten....
An die Mobilgeräte habe ich noch nicht gedacht. Ist den auf dem Handy das Einbinden (Outlook-App) der S/MIME-Zertifikate wenigstens genaus "leicht" wie beim Outlook aufm Desktop?
Beim einspielen des Zertifikats werde ich immer nach dem Passwort zu dem Zertifikat gefragt.
Er fragt nach dem Passwort für den Zertifikats-Container, die i.d.R. passwortgeschützt sind / werden müssen wenn sie den private key enthalten. Ohne Eingabe des PW kann er das Zertifikat nicht entpacken und importieren.
https://www.sslmentor.de/help/ssl-certificate-formats
Da nach liegt das Zertifikat im Zertifikatsspeicher des OS, nicht im E-Mail Client. Der bietet dann i.d.R. etwas mehr Sicherheit, das stimmt schon. Aber ich gehe davon aus das zumindest Windows auch einen Angriffsvektor bietet, auch wenn ich mich da wirklich nicht auskenne (mit dem Zertifikatsspeicher). Und interessant dürfte der für einen Angreifer schon sein.
Bei Apple wäre das auch der Passwortmanager wenn ich mich nicht irre.
Der Mailclient muss dann mit dem Zertifikatsspeicher des Gerätes interagieren. Zumindest Outlook fragt nicht bei jedem öffnen einer Mail nach einem Passwort. Vielleicht kann man das Einstellen, mich würde das ziemlich nerven und es würde die Arbeit deutlich behindern.
Die Gerichte und Landesdatenschutzbehörden gehen da langsam einen nervigen Weg und zwar das neben TLS auch E2E-Verschlüsselung verpflichten wird (jeweils für manche Berufsgruben oder vlt auch nicht).
Also ich bin nicht ganz sicher auf was du dich beziehst. Generell ist eine TLS verschlüsselte E-Mail eben nur bei der Übermittlung verschlüsselt, nicht aber auf den Servern. Das heißt es gibt zwar einen sinnvollen technischen Schutz, aber am Ende läuft die E-Mail häufig unverschlüsselt über die Server Dritter (z.B. ISP). In dem Fall ist das wie eine unverschlüsselte E-Mail und ich wäre auch nicht auf die Idee gekommen personenbezogene Daten ohne Einwilligung des Betroffenen darüber zu verschicken.Das war aus meiner Sicht von Anfang an so, das ist keine spezielle oder neue Interpretation von Behörden oder Gerichten.
Also ich bin nicht ganz sicher auf was du dich beziehst. Generell ist eine TLS verschlüsselte E-Mail eben nur bei der Übermittlung verschlüsselt, nicht aber auf den Servern. Das heißt es gibt zwar einen sinnvollen technischen Schutz, aber am Ende läuft die E-Mail häufig unverschlüsselt über die Server Dritter (z.B. ISP). In dem Fall ist das wie eine unverschlüsselte E-Mail und ich wäre auch nicht auf die Idee gekommen personenbezogene Daten ohne Einwilligung des Betroffenen darüber zu verschicken.
Ich wollte das jetzt nicht soweit aufblähen das Thema.
Es gibt ein Urteil vom LG Mainz aus dem Jahr 2021. In dem die TLS-Verschlüsselung für die E-Mail-Kommunikation ausreichend ist. Bei besonderen pbz. Daten nach Art. 9 der DSGVO bedarf es einen weiteren Schutz über der TLS-Verschlüsselung hinaus.
Im Dez. 2024 gab es ein Urteil, dass der Meinung ist, das selbst eine Rechnung mittels E2E zu verschlüsseln ist.
Auch die E-Mail-Adresse an sich ist ein pbz. Datum.
Die E-Mail-Kommunikation ist aktuell das am meist genutzte Medium. Und der Customer nutzt dies gern für eine schnelle und unkomplizierte Kommunikation.
Bei der Einwilligung ist allerdings darauf zu achten, dass die Betroffenen nicht in eine unverschlüsselte E-Mail-Kommunikation einwilligen. Dazu gab es - ich glaube - in 2018 auch ein Urteil. Es ist nicht zulässig gegen TOMs einzuwilligen, um so den Datenschutz zu umgehen.
Das war aus meiner Sicht von Anfang an so, das ist keine spezielle oder neue Interpretation von Behörden oder Gerichten.
Bisher gabs es da unterschiedliche Ansichten seitens der Behörden und Gerichte. So das eine TLS-Verschlüsselung ausreichend war.Wenn die jetzt aber dazu übergehen sollten, dass jeder Betrieb (auch der 1-2 Mann Betrieb) eine E2E-Verschlüssungsinfrastruktur haben müssen, würde es schon daran scheitern, dass ein Großteil der Bevölkerung keine E2E nutzt. Aber da kommen wir von meinem eigentlichem Thema zu weit weg.
Aber meine Anfangsfrage behinhaltet gerade diese Datenschutzthematik und wie man es mit Exchange und Outlook so gut und sicher wie möglich abbilden kann.
Ich hoffte auf eine Umsetzung so dass entweder die E-Mails verschlüsselt auf dem Client liegen - .
Oder die E-Mails auf dem E-Mail-Server (Exchange) verschlüsselt liegen und es über eine TLS an den Client nur als "Ansicht" übermittelt wird und somit keine E-Mails auf dem Client liegen.
Damit könnte man den Befinden von Behörden, Gerichten und Kunden entgegen kommen - E-Mails sind E2E. Und im Falle eine Komprimitierung wäre die E-Mails - sofern verschlüsselt - vor unbefugten Dritten geschützt.
So stelle ich mir das in einer naiven E-Mail-Welt vor und hätte nicht gedacht, dass es doch so kompliziert vorallem mit dem Exchange Server ist.
Der Mailclient muss dann mit dem Zertifikatsspeicher des Gerätes interagieren. Zumindest Outlook fragt nicht bei jedem öffnen einer Mail nach einem Passwort. Vielleicht kann man das Einstellen, mich würde das ziemlich nerven und es würde die Arbeit deutlich behindern.
Inwieweit würde dies die Arbeit behindern, wenn es in Outlook eingestellt ist und Outlook die Arbeit übernimmt?
Ich bin der Auffassung es würde ja schon genügen, wenn diese Abfrage an den Zertifikatspeicher beim Starten von Outlook erfolgt. Und wenn eine neue E-Mail eintrifft, dann kennt Outlook das PW und kann die E-Mail verschlüsseln.
Falls ein Angreifer sich nun die PST-Datei absaugt und mit seinem Outlook öffnen will, benötigt er das SMIME Zertifikat und auch das PW.
Zitat von @oi-polloi:
Ich hoffte auf eine Umsetzung so dass entweder die E-Mails verschlüsselt auf dem Client liegen - .
Oder die E-Mails auf dem E-Mail-Server (Exchange) verschlüsselt liegen und es über eine TLS an den Client nur als "Ansicht" übermittelt wird und somit keine E-Mails auf dem Client liegen.
Outlook nutzt SSL für die Verbindung zum Exchange. Wenn du also keine PST-Datei am Client hast, bleiben die E-Mails im wesentlichen auf dem Exchange.Ich hoffte auf eine Umsetzung so dass entweder die E-Mails verschlüsselt auf dem Client liegen - .
Oder die E-Mails auf dem E-Mail-Server (Exchange) verschlüsselt liegen und es über eine TLS an den Client nur als "Ansicht" übermittelt wird und somit keine E-Mails auf dem Client liegen.
Damit könnte man den Befinden von Behörden, Gerichten und Kunden entgegen kommen - E-Mails sind E2E.
Nein E2E wäre es nicht weil dein Server auch Zugriff hat. Im Sinne des Datenschutzes liegt aber dennoch kein Verstoß vor, dein Server darf deine Daten verarbeiten.Und im Falle eine Komprimitierung wäre die E-Mails - sofern verschlüsselt - vor unbefugten Dritten geschützt.
Der Datenschutz hält dich dazu an, deine Systeme zu schützen und, falls kompromittiert, geeignete Maßnahmen zu ergreifen (unter anderem auch deinen Informationspflichten nachzukommen). Du redest im Prinzip von "Schadensbegrenzung". Die ist sicherlich nett gemeint aber ändert vermutlich nichts an deinen eigentlichen Pflichten.So stelle ich mir das in einer naiven E-Mail-Welt vor und hätte nicht gedacht, dass es doch so kompliziert vorallem mit dem Exchange Server ist.
Ein Server muss sinnvoll abgesichert sein. Totale Sicherheit gibt es nicht. Kompliziert wird es, wenn du ein höheres Level an Sicherheit haben musst weil du in irgendeiner Weise Teil der KRITIS bist oder dergleichen.Der Mailclient muss dann mit dem Zertifikatsspeicher des Gerätes interagieren. Zumindest Outlook fragt nicht bei jedem öffnen einer Mail nach einem Passwort. Vielleicht kann man das Einstellen, mich würde das ziemlich nerven und es würde die Arbeit deutlich behindern.
Inwieweit würde dies die Arbeit behindern, wenn es in Outlook eingestellt ist und Outlook die Arbeit übernimmt?
Ich bin der Auffassung es würde ja schon genügen, wenn diese Abfrage an den Zertifikatspeicher beim Starten von Outlook erfolgt. Und wenn eine neue E-Mail eintrifft, dann kennt Outlook das PW und kann die E-Mail verschlüsseln.
Falls ein Angreifer sich nun die PST-Datei absaugt und mit seinem Outlook öffnen will, benötigt er das SMIME Zertifikat und auch das PW.
Nein er benötigt Zugang zum Zertifikatsspeicher. Outlook hat den, der Angreifer idealerweise nicht. Das hier habe ich spontan gefunden, vielleicht hilft das:Falls ein Angreifer sich nun die PST-Datei absaugt und mit seinem Outlook öffnen will, benötigt er das SMIME Zertifikat und auch das PW.
http://lkl-it.de/blog/?p=670
Wenn du dein Zertifikat sinnvoll schützen willst, nutze eine Smartcard. (Die geht allerdings wieder nicht am Handy oder im OWA, also E-Mails nur noch am Mail Client.)
Danke für den Link.
Wenn ich das richtig verstanden habe.
Alle Passwörter werden im Benutzerordner verschlüsselt abgelegt und bei Verwendung mit dem Windows-Passwort entschlüsselt.
Jede Anwendung die der Benutzer startet und Zugriff auf diese "Datenbank" haben will, bekommt den Zugriff und kann das entsprechende Passwort daraus auslesen - da ja schon der User mit der Anmeldung an Windows diese Datenbank entsperrt hat.
Somit kämen die Angreifer über ein separates Programm/Befehl an das Passwort, wenn möglich saugen die neben der PST-Datei auch noch das S/MIME-Zertifikat (sofern kein Zertifikatsspeicher eingerichte ist) mit ab und haben dann vollumfänglichen Zugriff auf die eigentlich verschlüsselten E-Mails.
Dies kann man nur umgehen in dem man die Sicherheit erhöht, so dass bei jeder neuen E-Mail Ver- oder Entschlüsselung der User entweder das Windowspasswort eingeben oder irgendwas bestätigen muss. Die Bestätigungsfenster werden dann irgendwann zur Gewohnheit und ungelesen bestätigt.
Habe ich das so einfach richtig wieder gegeben?
Dann bliebe ja nur noch die Option die Verschlüsselung der E-Mails dem E-Mail-Server oder Gateway zu überlassen. Und dafür zu sorgen, das keine E-Mails im Outlook in der PST-Datei gespeichert werden - und somit die Offline-Funktion von Outlook unnutzbar zu machen.
In meinem Datenschutzverletzungsszenario (Ransomeware) gehe mal von den einfachen "Skript-Kidies" aus, die mit wenig Aufwand Schaden anrichten wollen. Die werden sehr wahrscheinlich es nur auf die PST-Datei abgesehen haben.
Staatliche Akteuer berücksichtige ich nicht.
Wenn ich das richtig verstanden habe.
Alle Passwörter werden im Benutzerordner verschlüsselt abgelegt und bei Verwendung mit dem Windows-Passwort entschlüsselt.
Jede Anwendung die der Benutzer startet und Zugriff auf diese "Datenbank" haben will, bekommt den Zugriff und kann das entsprechende Passwort daraus auslesen - da ja schon der User mit der Anmeldung an Windows diese Datenbank entsperrt hat.
Somit kämen die Angreifer über ein separates Programm/Befehl an das Passwort, wenn möglich saugen die neben der PST-Datei auch noch das S/MIME-Zertifikat (sofern kein Zertifikatsspeicher eingerichte ist) mit ab und haben dann vollumfänglichen Zugriff auf die eigentlich verschlüsselten E-Mails.
Dies kann man nur umgehen in dem man die Sicherheit erhöht, so dass bei jeder neuen E-Mail Ver- oder Entschlüsselung der User entweder das Windowspasswort eingeben oder irgendwas bestätigen muss. Die Bestätigungsfenster werden dann irgendwann zur Gewohnheit und ungelesen bestätigt.
Habe ich das so einfach richtig wieder gegeben?
Dann bliebe ja nur noch die Option die Verschlüsselung der E-Mails dem E-Mail-Server oder Gateway zu überlassen. Und dafür zu sorgen, das keine E-Mails im Outlook in der PST-Datei gespeichert werden - und somit die Offline-Funktion von Outlook unnutzbar zu machen.
In meinem Datenschutzverletzungsszenario (Ransomeware) gehe mal von den einfachen "Skript-Kidies" aus, die mit wenig Aufwand Schaden anrichten wollen. Die werden sehr wahrscheinlich es nur auf die PST-Datei abgesehen haben.
Staatliche Akteuer berücksichtige ich nicht.
Grundsätzlich ja. Es geht nicht in dem Sinne um "Passwörter" sondern um private keys. Die können auch auf einer Smartcard liegen, da bekommst du die nicht runter kopiert. Dann muss immer physisch die Karte zur Entschlüsselung vor liegen + PIN Eingabe. Das ist sehr sicher, macht es allerdings auch für Mobilgeräte ungeeignet.
Dann bliebe ja nur noch die Option die Verschlüsselung der E-Mails dem E-Mail-Server oder Gateway zu überlassen. Und dafür zu sorgen, das keine E-Mails im Outlook in der PST-Datei gespeichert werden - und somit die Offline-Funktion von Outlook unnutzbar zu machen.
Das ist auf jeden Fall administrativ die deutlich angenehmere Variante. Auch i.S. Archivierung ist das einfacher und die Server muss man eh schützen.
Wenn dein Exchange von Außen erreichbar ist bietet ein Web Application Proxy einen guten Schutz:
https://www.msxfaq.de/internet/wap.htm
Ich muss aber sagen das ich das ziemlich aufwendig finde und auch nicht machen wollen würde. Besser scheint es mir, den Exchange nur per Gateway für E-Mail Verkehr erreichbar zu machen. Ich habe wie gesagt Mobilgeräte nur per VPN am Exchange. Ist ein wenig old school gedacht und nicht so hip von wegen zero trust.
Dazu kommt das Exchange 2019 on premise im Oktober EOL geht. Da nach wirds teuer, keiner weiß wie teuer... Da will Microsoft nun endlich alle in die Cloud drücken.
Dann bliebe ja nur noch die Option die Verschlüsselung der E-Mails dem E-Mail-Server oder Gateway zu überlassen. Und dafür zu sorgen, das keine E-Mails im Outlook in der PST-Datei gespeichert werden - und somit die Offline-Funktion von Outlook unnutzbar zu machen.
Wenn dein Exchange von Außen erreichbar ist bietet ein Web Application Proxy einen guten Schutz:
https://www.msxfaq.de/internet/wap.htm
Ich muss aber sagen das ich das ziemlich aufwendig finde und auch nicht machen wollen würde. Besser scheint es mir, den Exchange nur per Gateway für E-Mail Verkehr erreichbar zu machen. Ich habe wie gesagt Mobilgeräte nur per VPN am Exchange. Ist ein wenig old school gedacht und nicht so hip von wegen zero trust.
Dazu kommt das Exchange 2019 on premise im Oktober EOL geht. Da nach wirds teuer, keiner weiß wie teuer... Da will Microsoft nun endlich alle in die Cloud drücken.
Der Exchange Server muss nicht von außen erreichbar sein. Falls doch dann aber nur per VPN - ebenfalls oldschool.
Auf das endgültige Preismodel für den Exchange Server On Premises warte ich auch noch, bis jetzt sieht es ja so aus, dass die Cloud das "günstiger" Modell wird - je nach Lizenzmodell.
Auf das endgültige Preismodel für den Exchange Server On Premises warte ich auch noch, bis jetzt sieht es ja so aus, dass die Cloud das "günstiger" Modell wird - je nach Lizenzmodell.
