Я просматривал несколько пакетов для предотвращения утечки / потери данных, но в их документации я не могу найти, как они относятся к HTTPS.
Один из «векторов утечки» - отправка информации в веб-приложения через HTTPS. В этом случае единственный способ обнаружить утечку - это расшифровать ее.
Но для этого ему нужно будет выдать себя за удаленный сервер, используя поддельные сертификаты, как человек в середине атаки. Во избежание подозрений и жалоб пользователей, я полагаю, что корпорация должна вставить свой сертификат в качестве действительного ЦС в браузеры устройств, принадлежащих компании.
Мои вопросы:
Это не "как" человек в средней атаке, это человек в средней атаке.
Вы реализуете его с помощью прокси-сервера, который заменит удаленный сертификат вашим собственным сертификатом. В процессе их браузер будет выдавать ошибки о том, что сертификат недействителен. В этом суть HTTPS и сертификации. Так что, если у вас есть опытный пользователь, они будут знать, что вы перехватываете информацию.
Вы можете использовать прокси, которые просто записывают действия человека, чтобы вы могли записывать, что происходит и где они просматривают, но на самом деле, если вы применяете драконовские меры для предотвращения возможность что кто-то ворует вашу информацию, вы, вероятно, создаете рабочее место, которое поощряет такое отношение, которое оправдывает для сотрудника то, что он делает это в первую очередь. И вам также понадобится политика увольнения кадров для мобильных телефонов (запись с помощью камер), USB-накопителей и, возможно, убедитесь, что они также не запоминают что-то.
В любом случае, не существует «простого» способа нарушить мониторинг HTTPS без какого-либо способа его обнаружения, если только вы просто не заблокируете исходящий доступ к этому порту с помощью правила брандмауэра или прокси-фильтра. В противном случае весь смысл HTTPS бессмыслен.
Но для этого ему нужно будет выдать себя за удаленный сервер, используя поддельные сертификаты.
Да - вам понадобится не только сертификат, подписанный приемлемым для клиента органом, но также потребуется отравить DNS для клиента или перенаправить поток IP-пакетов.
Я подозреваю, что технически возможно реализовать прокси HTTPS, который будет генерировать сертификат на лету, подписанный локальным центром сертификации, и передавать запросы с его помощью, но это очень сложно.
Если вас беспокоит утечка данных через HTTPS, просто не разрешайте своим пользователям доступ к HTTPS.
Это не решает их проблемы с записью на клочках бумаги.
Единственное практическое решение - вести хороший контрольный журнал - желательно с горшками с медом.
Проблема https действительно решается с помощью решения типа MiM. Обычно это означает, что прокси-сервер перехватывает исходящие сеансы https и обслуживает их пользователю, подписанному его собственным сертификатом ssl, при этом самостоятельно отправляя https-сообщения во внешний мир.
Бесплатное решение myDLP может сделать это, используя собственную конфигурацию squid, а более сложные решения, такие как Websense и symantec, iirc делают то же самое, хотя и немного более мощно (балансировка нагрузки между такими прокси, мелкозернистое управление сертификатами и т. Д. )