Я ищу решение для шифрования электронной почты для клиента. В настоящее время они используют Exchange 2007, но при необходимости готовы перейти на размещенное решение. Они ищут решение, которое позволит им шифровать сообщения на основе определенных правил (например, сообщение содержит определенную конфиденциальную информацию). Они предпочли бы автоматическое решение, чтобы уменьшить вероятность того, что конфиденциальные данные будут отправлены в незашифрованном виде. У них нет контроля над клиентом на стороне получателя, поэтому это может быть Outlook, Yahoo, Gmail и т. Д. Я видел некоторые решения, которые отправляют получателю уведомление, а затем позволяют получателю перейти на сайт для просмотра / загрузки сообщение / вложение. У кого-нибудь есть опыт работы с этим типом решения? Приборы или размещенные решения?
Позвольте мне предварить это: схемы шифрования электронной почты - отстой, все они.
S / MIME - единственный широко поддерживаемый метод шифрования / дешифрования электронной почты. Для этого необходимо, чтобы и у получателя, и у отправителя были сертификаты (пары ключей, частный и открытый). У отправителя должен быть открытый ключ получателя. Часто бывает просто сначала отправить ключ по электронной почте или разместить его на веб-сайте; Однако стандартного способа сделать это не существует. Отправитель шифрует электронное письмо открытым ключом получателя и аутентифицирует его своим личным ключом. Получатель должен иметь свой собственный закрытый ключ и открытый ключ отправителя (который обычно прикрепляется к электронному письму для простоты) для расшифровки и аутентификации электронного письма.
Если вы понимаете, что, не прочитав его хотя бы 3 раза, поздравляю, вы заслуживаете небольшого вознаграждения (и, скорее всего, вы ИТ-специалист, а не бедный пользователь, который должен пытаться делать это каждый день).
Настроить правила, требующие шифрования в Outlook, не так уж сложно. На самом деле выполнить указанное выше требование, чтобы Outlook мог зашифровать электронную почту, это сложно.
Альтернативное решение (которое мы используем) - создание веб-сайта портала; защищен SSL или подобным. Разместите документ или информацию на веб-сайте, а затем отправьте адрес получателю по электронной почте. Попросите их позвонить вам, чтобы получить свой пароль, если вы не установили его заранее, или для дополнительной оплаты используйте стороннюю аутентификацию, такую как OpenID.
Я работал на стороне клиента в поддерживаемом государством совместном предприятии по обеспечению безопасности электронной почты, которое имело те же требования, что и вы описали, хотя и реализовано иначе. Как объясняет Крис С., возложение бремени шифрования на конечного пользователя редко срабатывает.
Опять же, как предположил Крис С., они изначально хотели настроить безопасную систему обмена сообщениями на основе Интернета, но конечные пользователи и заинтересованные стороны не хотели или не могли изменять процессы, поскольку у них были сторонние приложения, требующие SMTP / электронной почты. как транспорт.
В итоге они установили безопасный центральный агент передачи почты (MTA), который все участвующие стороны использовали в качестве зашифрованного TLS интеллектуального хоста для маршрутизации почты. Этот центральный MTA затем анализировал заголовки каждого почтового сообщения, и если было совпадение адреса назначения с белым списком «подлежащих шифрованию», это, в свою очередь, передавалось через TLS на MTA назначения; если совпадений не было, почта маршрутизировалась через записи MX как обычно в незашифрованном виде. При правильных правилах брандмауэра нет простого способа отправлять текстовые сообщения по «ошибке», поэтому, хотя и не используется сквозное шифрование, почта шифруется при передаче между доверенными MTA и не требует от конечного пользователя каких-либо действий. чтобы это произошло.
Система (по-прежнему) работает хорошо, но, очевидно, требует большой координации между администраторами почты каждой участвующей организации.
Если такая координация невозможна в вашей ситуации, я с Крисом С. в этом: я бы установил безопасную систему обмена сообщениями с использованием сертификатов SSL (для этого можно легко использовать SharePoint Services 3.0) и, возможно, двухфакторной аутентификации, в зависимости от ваших требований.
В настоящее время я нахожусь в процессе внедрения решения для клиента. Мы используем технику Ironport. Электронные письма проверяются модулем DLP Ironport и, если они соответствуют критериям, зашифровываются. Ironport предлагает множество решений. Вы можете установить собственное устройство и управлять им, использовать размещенное устройство в их центре обработки данных или поручить Ironport управлять устройствами в вашем местоположении.
Получатель электронной почты получает сообщение в виде html-вложения, содержащего зашифрованное электронное письмо и некоторый JavaScript-код, который взаимодействует с Ironport для получения ключей и дешифрования сообщения. Никаких специальных клиентских или предварительных общих сертификатов или ключей не требуется.
Есть множество подобных товаров. Мы рассмотрели решения от ZixCorp, Axway (Secure Messenger), Google / Postini, Microsoft и McAfee. Многие из размещенных решений требуют, чтобы вы также использовали их службы фильтрации спама / антивируса.
Вы можете попробовать шлюз шифрования электронной почты с открытым исходным кодом Djigzo (www.djigzo.com). Это шлюз SMTP с поддержкой шифрования S / MIME и PDF, который содержит модуль DLP, который может помещать в карантин или принудительно шифровать вашу электронную почту в зависимости от содержимого электронной почты. Все готово к запуску Virtual Appliance доступна для VMware и Hyper-V, а установочные пакеты доступны для Debian / Ubuntu и RedHat / CentOS.