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