Мы заинтересованы в повышении уровня безопасности корпоративной электронной почты по нескольким причинам: 1) Защита внутренней информации от утечек. 2) Письма клиентам будут подписаны. 3) Способ отметить, что письмо пришло извне (чтобы предотвратить атаки социальной инженерии, вылавливающие вещи, или попытки отдавать приказы вместо менеджера и т. Д.).
В качестве решения мы думаем об этой схеме (я хорошо знаю GPG, поэтому буду использовать эти термины для описания решения):
1) Все внутренние электронные письма (из / в корпоративный домен (-ы) будут отправляться в зашифрованном виде с использованием секретного ключа GPG сотрудника, который будет подписан главным ключом (ключ CA для всей корпорации).
2) Электронные письма, отправленные внешним клиентам, будут подписаны только с использованием закрытого ключа сотрудника, поэтому при желании они могут проверить, что его ключ действителен на нашем общедоступном сервере.
3) К ЛЮБЫМ письмам, приходящим из-за пределов корпорации, будет добавлена дополнительная строка с надписью «Внешняя почта» или что-то в этом роде.
Преимущество работы в такой структуре будет заключаться в том, что в случае ухода сотрудника, увольнения, предательства или кражи ключа достаточно легко отозвать его действительность, используя основной корпоративный ключ CA. Я еще не знаю, как это сделать, но в GPG это работает.
Недостатком, конечно же, является то, что ВСЕ сотрудники, особенно тупые, будут большой головной болью при настройке шифрования и обеспечении шифрования каждой внутренней электронной почты.
Я читал подобные вопросы:
Лучший клиент шифрования для Outook 2007 / Exchange?
Ищете решение для шифрования электронной почты
Второе кажется слишком сложным для наших нужд, но Ironport звучал многообещающе ... однако я не могу найти ничего подходящего на их веб-сайте - я неправильно смотрю?
Я также упомяну, что у нас есть центр обработки данных, поэтому решение должно быть таким, которое мы можем интегрировать в наших помещениях.
Итак, как вы думаете, люди? и есть предложения? :)
Несколько лет назад была мечта, что все начнут делать зашифрованную почту. Почтовые клиенты начали поддерживать такие вещи, как S / MIME и PGP. Это оказался кошмар. Любое решение безопасности, которое полагается на то, что пользователи делают что-то дополнительное, чтобы заставить его работать, большую часть времени дает сбой. Ожидать, что конечные пользователи поймут секретные ключи, открытые ключи и шифрование, на самом деле слишком многого.
Однако появилось несколько общих решений, позволяющих обойти эти проблемы.
Во-первых, вы можете использовать TLS. Если есть организация, с которой вы ведете много дел, и вам нужна безопасная электронная почта между вашей компанией и их компанией, вы можете договориться о TLS с их почтовыми служащими. Как вы это реализуете, зависит от вашей почтовой системы, но в конечном итоге вы можете принудительно использовать TLS между двумя своими сайтами. В то же время вы можете настроить исходящий MTA для попытки TLS на любой внешний сайт. Если они его поддерживают, его используют. В противном случае используется обычный незашифрованный SMTP. Это часто называют «оппортунистическим TLS», и это стало очень распространенным явлением.
Во-вторых, многие пакеты защиты электронной почты теперь поддерживают какой-то зашифрованный исходящий веб-шлюз. Вы упомянули Ironport. Это один вариант, но есть и другие, например, Tumbleweed. Большинство размещенных SMTP-шлюзов тоже делают это (Postini / Google, MessageLabs и т. Д.). В этом сценарии исходящая почта проходит через систему или службу, а определенные сообщения помечаются как «требуется безопасность», где они перенаправляются в веб-систему, которая отправляет уведомление о безопасном сообщении, и они нажимают ссылку и переходят к чтению безопасное сообщение на веб-сервере и может ответить на него там. Есть много вариантов того, как эти сообщения помечаются как требующие безопасности. Обычно у вас есть возможность создавать фильтры, которые сканируют тело сообщения на предмет таких вещей, как номера социального страхования, номера кредитных карт или что-то еще. Обычно пользователи также могут принудительно защитить сообщение, вставив определенную фразу в тело сообщения.
Я уверен, что есть другие варианты, которые мне не приходят в голову в данный момент, но эти два довольно распространены и заслуживают изучения.