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