Ich habe mir mehrere Suiten zur Verhinderung von Datenlecks und -verlusten angesehen, kann in deren Dokumentation jedoch nicht finden, wie sie mit HTTPS umgehen.
Einer der „Leckvektoren“ ist das Senden von Informationen an Webanwendungen über HTTPS. In diesem Fall besteht die einzige Möglichkeit, das Leck zu erkennen, darin, es zu entschlüsseln.
Dazu müsste es sich jedoch als Remote-Server ausgeben und gefälschte Zertifikate verwenden, wie bei einem Man-in-the-Middle-Angriff. Um zu vermeiden, dass Benutzer misstrauisch werden oder sich beschweren, muss das Unternehmen vermutlich sein Zertifikat als gültige Zertifizierungsstelle in die Browser der unternehmenseigenen Geräte einfügen.
Meine Fragen sind:
- Hat jemand Erfahrung aus erster Hand mit einem solchen Szenario? Können Sie uns sagen, wie Sie es umgesetzt haben?
- Habe ich Recht oder gibt es eine andere Möglichkeit, HTTPS zu verwalten (beispielsweise durch Erkennen der verwendeten Daten auf Desktopebene mit einem Agenten)?
Antwort1
Das ist nicht „wie“ ein Man-in-the-Middle-Angriff, es IST ein Man-in-the-Middle-Angriff.
Sie implementieren es mithilfe eines Proxyservers, der Ihr eigenes Zertifikat durch das Remote-Zertifikat ersetzt. Dabei wird der Browser des Benutzers Fehlermeldungen ausgeben, dass das Zertifikat nicht gültig ist. Das ist der Sinn von HTTPS und Zertifizierung. Wenn Sie also einen versierten Benutzer haben, wird dieser wissen, dass Sie die Informationen abfangen.
Sie können Proxys verwenden, die nur die Aktivitäten einer Person aufzeichnen, sodass Sie aufzeichnen können, was passiert und wo sie surft. Wenn Sie jedoch wirklich drakonische Maßnahmen ergreifen, um dieWahrscheinlichkeitdass jemand Ihre Informationen stiehlt, schaffen Sie wahrscheinlich einen Arbeitsplatz, der eine Einstellung fördert, die es für den Mitarbeiter rechtfertigt, dies überhaupt zu tun. Und Sie müssen auch Personalrichtlinien für Mobiltelefone (Aufnahme mit Kameras), USB-Sticks und vielleicht auch dafür sorgen, dass sie sich nichts merken.
Es gibt jedenfalls keine „einfache“ Möglichkeit, die HTTPS-Überwachung zu unterbrechen, ohne dass dies entdeckt wird, es sei denn, Sie blockieren einfach den ausgehenden Zugriff auf diesen Port mit einer Firewall-Regel oder einem Proxy-Filter. Andernfalls ist der ganze Sinn von HTTPS sinnlos.
Antwort2
Dazu müsste er sich jedoch als Remote-Server ausgeben und gefälschte Zertifikate verwenden.
Ja – Sie bräuchten nicht nur ein Zertifikat, das von einer für den Client akzeptablen Zertifizierungsstelle unterzeichnet wurde, sondern Sie müssten auch den DNS für den Client „vergiften“ oder den IP-Paketstrom umleiten.
Ich vermute, dass es technisch möglich sein könnte, einen HTTPS-Proxy zu implementieren, der spontan ein von einer lokalen Zertifizierungsstelle signiertes Zertifikat generiert und die Anforderungen damit proxyt. Das wäre allerdings sehr schwierig.
Wenn Sie Bedenken wegen eines Datenverlusts über HTTPS haben, erlauben Sie Ihren Benutzern einfach keinen Zugriff auf HTTPS.
Es löst nicht das Problem, dass sie Dinge auf Zetteln aufschreiben.
Die einzige praktische Lösung besteht darin, ein gutes Prüfprotokoll aufzubewahren – vorzugsweise mit Honeypots.
Antwort3
Das https-Problem wird tatsächlich durch die MiM-Lösung gelöst. Normalerweise bedeutet dies, dass ein Proxy ausgehende https-Sitzungen abfängt und diese dem Benutzer mit seinem eigenen SSL-Zertifikat signiert zur Verfügung stellt, während er die https-Kommunikation mit der Außenwelt selbst durchführt.
Die kostenlose myDLP-Lösung kann das mithilfe ihrer eigenen Squid-Konfiguration, und die komplexeren Lösungen wie Websense und Symantec tun, wenn ich mich recht entsinne, dasselbe, wenn auch etwas leistungsfähiger (Lastausgleich zwischen solchen Proxys, feinkörniges Zertifikatsmanagement usw.).