Как включить размещаемые сертификаты s/mime для дополнительной защиты сообщений - cправка

Введение в SMTP

Связь по умолчанию осуществляется в виде открытого текста. Но в настоящее время вы, скорее всего, увидите, как почтовые серверы переключаются с обычного текста на защищенный канал с помощью SSL / TLS .
Порты по умолчанию — 25, 465 (устарело) и 587, где 25 предназначен для использования для отправки от вашего почтового клиента на почтовый сервер, а более высокие порты для ретрансляции между SMTP-сервером.

SMTP-сервер может действовать как клиент и как сервер, так как он должен отправлять и получать электронные письма одновременно. Рассмотрим брандмауэр, который обрабатывает все ваши электронные письма, как исходящие, так и входящие — в обоих случаях задействован SMTP.

Некоторые термины, используемые вместе с SMTP :

Почтовый пользовательский агент (MUA) : это программа (часть), подключающаяся к SMTP-серверу для отправки электронной почты. Скорее всего, это ваш Outlook, Thunderbird или что угодно.

Агент пересылки почты (MTA) : транспортная часть программы. Они получают и передают электронные письма. Это может быть сервер Exchange, шлюз с выходом в Интернет и так далее.

Соответствующий RFC5321 упоминает только эти два термина.
Однако, если вы начнете спрашивать Интернет о SMTP, вы наверняка наткнетесь на агента отправки почты (MSA) и агента доставки почты (MDA) и некоторые другие.
Это также особые функции программы, участвующей в рабочем процессе электронной почты, которые позволяют описать процесс более точно и детально. MSA является частью получающую электронную почту от MUA и MDA, и передающей письмо к конечному принимающему MUA. Скорее всего, все эти функции будут найдены в одном или двух продуктах в вашей среде, которые могут позаботиться обо всех этих шагах.
Таким образом, рабочий процесс передачи электронного письма от одного пользователя к другому может выглядеть так:

MUA → MSA → MTA → Интернет → MTA → MDA → MUA

Термины relay и gateway четко определены в RFC5321.

Шаг 3. Синхронизация пользовательских сертификатов для S/MIME с Майкрософт 365

Прежде чем любой пользователь сможет отправлять сообщения, защищенные S/MIME, в Exchange Online необходимо настроить и настроить соответствующие сертификаты для каждого пользователя и опубликовать общедоступные сертификаты X.509 в Майкрософт 365. Почтовый клиент отправителя использует общедоступный сертификат получателя для шифрования сообщения.

Выдача сертификатов и их публикация в локальной службе Active Directory. Дополнительные сведения см. в статье Обзор служб сертификатов Active Directory.
После публикации сертификатов используйте Azure AD Connect, чтобы синхронизировать данные пользователей из локальной среды Exchange с Майкрософт 365. Дополнительные сведения об этом процессе см. в разделе Синхронизация Azure AD Connect: Общие сведения о синхронизации и настройке синхронизации.

Наряду с синхронизацией других данных каталога Azure AD Connect синхронизирует атрибуты userCertificate и userSMIMECertificate для каждого объекта пользователя для подписывания и шифрования сообщений электронной почты S/MIME. Дополнительные сведения о Azure AD Connect см. в статье Что такое Azure AD Connect?.

Шифрование S/MIME

Шифрование сообщений предоставляет решение для раскрытия информации. Электронная почта на основе SMTP не защищает сообщения. Сообщение электронной почты SMTP в Интернете может прочитать любой пользователь, который видит его во время перемещения или просматривает его, где оно хранится. Эти проблемы решаются S/MIME с помощью шифрования. Шифрование — это способ изменения информации, чтобы ее нельзя было прочитать или понять, пока она не будет изменена обратно в удобочитаемую и понятную форму. Шифрование сообщений предоставляет две службы безопасности:

Конфиденциальность. Шифрование сообщений служит для защиты содержимого сообщения электронной почты. Только предполагаемый получатель может просматривать содержимое, а содержимое остается конфиденциальным и не может быть известно кому-либо, кто может получить или просмотреть сообщение. Шифрование обеспечивает конфиденциальность во время передачи сообщения и хранения.
Целостность данных. Как и в случае с цифровыми подписями, шифрование сообщений предоставляет службы целостности данных в результате конкретных операций, которые делают возможным шифрование.

Важно!

Хотя шифрование сообщений обеспечивает конфиденциальность, оно никак не проверяет подлинность отправителя сообщения. Неподписаное зашифрованное сообщение так же восприимчиво к олицетворению отправителя, как и сообщение, которое не зашифровано. Поскольку непринудие является прямым результатом проверки подлинности, шифрование сообщений также не обеспечивает отмену отзыва. Хотя шифрование обеспечивает целостность данных, зашифрованное сообщение может показать только, что сообщение не было изменено с момента его отправки. Сведения о том, кто отправил сообщение, не предоставляются. Чтобы подтвердить удостоверение отправителя, сообщение должно использовать цифровую подпись.

Цифровые подписи S/MIME

Цифровые подписи являются наиболее часто используемой службой S/MIME. Как следует из названия, цифровые подписи являются цифровыми аналогами традиционной юридической подписи на бумажном документе. Как и в случае с юридической подписью, цифровые подписи предоставляют следующие возможности безопасности:

Проверка подлинности. Подпись служит для проверки удостоверения. Он проверяет ответ на вопрос «кто вы», предоставляя средства отличия этой сущности от всех остальных и доказывая ее уникальность. Так как в электронной почте SMTP нет проверки подлинности, нельзя узнать, кто отправил сообщение. Проверка подлинности в цифровой подписи решает эту проблему, позволяя получателю знать, что сообщение было отправлено лицом или организацией, которые утверждают, что отправили сообщение.
Непринудие. Уникальность подписи не позволяет владельцу подписи отказаться от подписи. Эта возможность называется неотрекоменцией. Таким образом, проверка подлинности, которую предоставляет сигнатура, дает средства для принудительного применения отказа. Концепция невозврата наиболее знакома в контексте бумажных контрактов: подписанный контракт является юридически обязательным документом, и открещиться от подписанной подписи невозможно. Цифровые подписи обеспечивают ту же функцию и, все чаще в некоторых областях, признаются в качестве юридически обязательной, аналогичной подписи на бумаге. Так как smtp-адрес электронной почты не предоставляет средства проверки подлинности, он не может обеспечить отказ. Отправитель легко дезавуировать владение SMTP-сообщением электронной почты.
Целостность данных. Дополнительная служба безопасности, предоставляемая цифровыми подписями, — это целостность данных. Целостность данных является результатом конкретных операций, которые делают возможными цифровые подписи. В службах целостности данных, когда получатель сообщения электронной почты с цифровой подписью проверяет цифровую подпись, получатель уверен, что полученное сообщение электронной почты фактически является тем же сообщением, которое было подписано и отправлено, и не было изменено во время передачи. Любое изменение сообщения во время передачи после его подписания делает подпись недействительной. Таким образом, цифровые подписи обеспечивают гарантию того, что подписи на бумаге не могут быть изменены после его подписания.

Важно!

Хотя цифровые подписи обеспечивают целостность данных, они не обеспечивают конфиденциальность. Сообщения только с цифровой подписью отправляются в виде ясного текста, например smtp-сообщения, и могут быть прочитаны другими пользователями. В случае, когда сообщение непрозрачно подписано, достигается уровень маскировки, так как сообщение закодировано в кодировке base64, но оно по-прежнему является четким текстом. Чтобы защитить содержимое сообщений электронной почты, необходимо использовать шифрование.

Отправка Зашифрованных Сообщений

Для того, что бы Отправить зашифрованное сообщение, убедитесь, что ваш Закрытый Ключ разблокирован, все получатели сообщения включены в вашу Записную Книгу и что в Записной Книге имеются их сертификаты.

Если ваш Закрытый Ключ разблокирован, то на странице Создания сообщения вы увидите флажок Зашифровать. Отметьте этот флажок для того, что бы зашифровать сообщение. Если вы отправляете сообщение с приложениями, то всё содержимое вашего сообщения, включая приложения, будет зашифровано Открытыми Ключами получателей (полученными из Сертификатов) и вашим собственным Открытым Ключом. В результате, если копия зашифрованного сообщения сохраняется в вашей папке Sent, то вы сами сможете прочитать (расшифровать) его.

Если вы выберите обе опции Подписать и Зашифровать, то сообщение будет создано как Подписанное, а затем всё его содержимое (включая заголовки сообщения и вашу подпись) будет зашифровано.

Используйте настройку Методы Шифрования Веб Интерфейса Пользователя для указания «типа» шифрования.

Сертификаты

Как методы шифрования, так и методы подписывания предполагают, что стороны могут свободно обмениваться информацией об Открытых Ключах. PKI снимает риск «кражи ключа»: предполагается, что Открытый Ключ может быть известен всем (может быть «известен публично»).
Но всегда существует другой риск — когда сторона получает Открытый Ключ, она должна быть уверенной, что этот ключ в действительности принадлежит тому, кому надо. В противном случае третья сторона может сгенерировать свою собственную пару Закрытый/Открытый Ключ и отправить в центр Открытый Ключ, притворившись, что этот Открытый Ключ принадлежит шпиону. Если центр не заметит эту подделку, то он будет использовать этот ключ для шифрования информации, передаваемой шпиону. Шпион будет не в состоянии прочитать её (она зашифрована неверным Открытым Ключом), но третья сторона, выпустившая эту пару ключей, сможет расшифровать информацию, так как она обладает соответствующим Закрытым Ключом.

В целях решения этой проблемы Открытые Ключи не распространяются в «сыром виде». Вместо этого, они распространяются встроенными в Сертификаты. Сертификат содержит следующие данные:

«Тема» — имя стороны, которой принадлежит Сертификат.
Открытый Ключ — Открытый Ключ стороны, указанной в поле «Тема».
«Эмитент» — имя стороны, которая выпустила этот сертификат.
Подпись — дайджест вышеуказанных данных, зашифрованный Закрытым Ключом Эмитента.

Сертификаты выпускаются Центром Сертификации — стороной, которой должны доверять все стороны. Все стороны должны знать Открытый Ключ Центра Сертификации. В современных приложениях для работы с Интернет (браузерах, почтовых программах и т.д.) имеется встроенный список Доверенных Центров Сертификации (включая VeriSign и другие подобные ей компании), а также в них встроены Открытые Ключи этих Доверенных Центров Сертификации.

По получении сертификата, получающая сторона может проверить, выпущен ли сертификат «доверенным центром сертификации»: проверяется, является ли имя «эмитента» Сертификата одним из «Доверенных Центров Сертификации» и используется заранее известный Открытый Ключ этого Центра для проверки подписи Сертификата. Если подпись проверена, то сторона может доверять тому, что Открытый Ключ в Сертификате действительно принадлежит стороне, указанной в Теме Сертификата.

Очень часто используется Центр Сертификации — посредник. Например, корпорация может получить Сертификат, выданный Центром Сертификации, и затем она сама может выступать в роли Центра Сертификации, выпуская сертификаты для своих сотрудников. Для того, что бы сделать возможным проверку таких сертификатов третьей стороной, Сертификаты, выпущенные Центром Сертификации — Посредником должны отправляться вместе с собственным Сертификатом Центра Сертификации — Посредника. Получающая сторона сначала проверяет, что этот Сертификат действительно выпущен этим Центром-Посредником (используя Открытый Ключ из Сертификата для проверки подписи в Сертификате отправителя), а затем она проверяет, что Центр-Посредник является тем, кем он представляется (проверяется его Сертификат с использованием известного Открытого Ключа Доверенного Центра Сертификации).

Что вы можете сделать для защиты электронной почты?

В прошлой статье «Как при помощи токена сделать Windows домен безопаснее? Часть 1» мы рассказали, как настроить безопасный вход в домен. Напомнили, что такое двухфакторная аутентификация и каковы ее преимущества.

В этой статье мы поговорим о защите электронной почты.

Стандартные почтовые протоколы не включают очевидных механизмов защиты, которые гарантировали бы авторство писем и обеспечивали простую и легкую проверку. Такая ситуация с защитой почтовых систем дает возможность злоумышленникам создавать письма с фальшивыми адресами. Поэтому нельзя быть на 100% уверенным в том, что человек, данные которого указаны в поле «От кого», действительно является автором письма. Также тело электронного письма легко изменить, т. к. нет средств проверки целостности и при передаче через множество серверов письмо может быть прочитано и изменено.

Один из способов обеспечить конфиденциальность переписки — шифрование сообщений, а один из способов проверить целостность письма и установить авторство — подписание его электронной подписью.

Зашифрованное сообщение будет доступно для прочтения только тем получателям, у которых имеется закрытый ключ, соответствующий открытому, при помощи которого было зашифровано сообщение. Любой другой получатель не сможет даже открыть письмо.

1. Как SSL / TLS защищают электронную почту

Secure Sockets Layer (SSL) и его преемник, Transport Layer Security (TLS), являются наиболее распространенными протоколами безопасности электронной почты, которые защищают вашу электронную почту во время ее перемещения через Интернет.

SSL и TLS являются протоколами прикладного уровня. В сетях интернет-связи прикладной уровень стандартизирует связь для услуг конечного пользователя. В этом случае прикладной уровень обеспечивает инфраструктуру безопасности (набор правил), которая работает с SMTP (также протоколом прикладного уровня) для защиты вашей электронной почты.

Далее в этом разделе статьи обсуждается TLS, так как его предшественник SSL полностью устарел в 2015 году.

TLS обеспечивает дополнительную конфиденциальность и безопасность для общения компьютерных программ. В этом случае TLS обеспечивает безопасность для SMTP.

Когда ваш почтовый клиент отправляет и получает сообщение, он использует протокол управления передачей (TCP — часть транспортного уровня, а ваш почтовый клиент использует его для соединения с почтовым сервером), чтобы инициировать «рукопожатие» с почтовым сервером.

Рукопожатие — это последовательность шагов, в ходе которых почтовый клиент и почтовый сервер проверяют параметры безопасности и шифрования и начинают передачу самой электронной почты. На базовом уровне рукопожатие работает так:

Клиент отправляет «привет», типы шифрования и совместимые версии TLS на сервер электронной почты.
Сервер отвечает сервером TLS Digital Certificate и открытым ключом шифрования сервера.
Клиент проверяет информацию сертификата.
Клиент генерирует Общий секретный ключ (также известный как Pre-Master Key), используя открытый ключ сервера, и отправляет его на сервер.
Сервер расшифровывает секретный общий ключ.
Клиент и сервер теперь могут использовать секретный общий ключ для шифрования передачи данных, в данном случае, вашей электронной почты.

TLS очень важен, так как подавляющее большинство почтовых серверов и почтовых клиентов используют его для обеспечения базового уровня шифрования вашей электронной почты.

Оппортунистический TLS и Принудительный TLS

Оппортунистический TLS — это команда протокола, которая сообщает серверу электронной почты, что почтовый клиент хочет превратить существующее соединение в безопасное соединение TLS.

Время от времени ваш почтовый клиент будет использовать простое текстовое соединение вместо того, чтобы следовать вышеупомянутому процессу рукопожатия, чтобы создать безопасное соединение. Оппортунистический TLS попытается запустить рукопожатие TLS для создания туннеля. Однако в случае сбоя процесса рукопожатия Opportunistic TLS будет использовать простое текстовое соединение и отправлять электронную почту без шифрования.

Принудительный TLS — это конфигурация протокола, которая заставляет все транзакции электронной почты использовать стандарт безопасного TLS. Если электронная почта не может пройти от почтового клиента до почтового сервера, то для получателя электронной почты сообщение не будет отправлено .

Цифровые подписи S/MIME

Проверка подлинности. Подпись служит для проверки удостоверения. Он проверяет ответ на вопрос «кто вы», предоставляя средства отличия этой сущности от всех остальных и доказывая ее уникальность. Так как в электронной почте SMTP нет проверки подлинности, нельзя узнать, кто отправил сообщение. Проверка подлинности в цифровой подписи решает эту проблему, позволяя получателю знать, что сообщение было отправлено лицом или организацией, которые утверждают, что отправили сообщение.
Непринудие. Уникальность подписи не позволяет владельцу подписи отказаться от подписи. Эта возможность называется неотрекоменцией. Таким образом, проверка подлинности, которую предоставляет сигнатура, дает средства для принудительного применения отказа. Концепция невозврата наиболее знакома в контексте бумажных контрактов: подписанный контракт является юридически обязательным документом, и открещиться от подписанной подписи невозможно. Цифровые подписи обеспечивают ту же функцию и, все чаще в некоторых областях, признаются в качестве юридически обязательной, аналогичной подписи на бумаге. Так как smtp-адрес электронной почты не предоставляет средства проверки подлинности, он не может обеспечить отказ. Отправитель легко дезавуировать владение SMTP-сообщением электронной почты.
Целостность данных. Дополнительная служба безопасности, предоставляемая цифровыми подписями, — это целостность данных. Целостность данных является результатом конкретных операций, которые делают возможными цифровые подписи. В службах целостности данных, когда получатель сообщения электронной почты с цифровой подписью проверяет цифровую подпись, получатель уверен, что полученное сообщение электронной почты фактически является тем же сообщением, которое было подписано и отправлено, и не было изменено во время передачи. Любое изменение сообщения во время передачи после его подписания делает подпись недействительной. Таким образом, цифровые подписи обеспечивают гарантию того, что подписи на бумаге не могут быть изменены после его подписания.

Важно!

Шаг 1. Настройка и публикация сертификатов S/MIME

Каждому пользователю в вашей организации требуется собственный сертификат, выданный для подписывания и шифрования. Эти сертификаты публикуются в локальная служба Active Directory для распространения. Служба Active Directory должна находиться на компьютерах в физическом расположении, которое вы контролируете, а не в удаленном объекте или облачной службе в Интернете.

Дополнительные сведения об Active Directory см. в доменные службы Active Directory Обзор.

Установите центр сертификации на основе Windows и настройте инфраструктуру открытых ключей для выдачи сертификатов S/MIME. Также поддерживаются сертификаты, выданные сторонними поставщиками сертификатов. Дополнительные сведения см. в статье Обзор служб сертификатов Active Directory.

Примечания.
- Сертификаты, выданные сторонним ЦС, имеют преимущество автоматического доверия для всех клиентов и устройств. Сертификаты, выданные внутренним частным ЦС, не являются автоматически доверенными клиентами и устройствами, и не все устройства (например, телефоны) могут быть настроены на доверие частным сертификатам.
- Рассмотрите возможность использования промежуточного сертификата вместо корневого сертификата для выдачи сертификатов пользователям. Таким образом, если вам когда-либо потребуется отозвать и перевыпускать сертификаты, корневой сертификат по-прежнему остается нетронутым.
- Сертификат должен иметь закрытый ключ, а расширение X509 «Идентификатор ключа субъекта» должно быть заполнено.
Опубликуйте сертификат пользователя в учетной записи локальная служба Active Directory в атрибутах UserSMIMECertificate и (или) UserCertificate.

Шаг 2. Настройка коллекции виртуальных сертификатов в Exchange Online

Коллекция виртуальных сертификатов отвечает за проверку сертификатов S/MIME. Настройте коллекцию виртуальных сертификатов, выполнив следующие действия.

Экспортируйте корневые и промежуточные сертификаты, необходимые для проверки пользовательских сертификатов S/MIME, с доверенного компьютера в файл сериализованного хранилища сертификатов (SST) в Windows PowerShell. Например:

Подробные сведения о синтаксисе и параметрах см. в разделе Export-Certificate.
Импортируйте сертификаты из SST-файла в Exchange Online, выполнив следующую команду в Exchange Online PowerShell:

Подробные сведения о синтаксисе и параметрах см. в разделе Set-SmimeConfig.

Наш маленький CA

Создаём приватный ключ и публичный сертификат нашего «удостоверяющего центра»:

# openssl genrsa -aes256 -out mail-ca.key 8192
# chmod 0400 mail-ca.key

Приватный ключ (mal-ca.key) — самый важный файл из всего, что мы в этот раз создаем. Пароль secret1 естественно должен быть значительно сложнее, ведь если произойдет утечка приватного ключа то только пароль ключа будет защищать вас от поддельных сертификатов. Заранее подумайте, какие данные вы введете в сведения о сертификате, ведь этот сертификат будет потом установлен на всех клиентских устройствах в роли удостоверяющего центра. Если изменить сертификат одного клиента будет просто, то изменить этот сертификат будет совсем не просто.

Создаём публичный сертификат (mail-ca.crt), который будет установлен на всех клиентских устройствах (он будет подтверждать корректность сертификатов на устройствах пользователей):

# openssl req -new -x509 -sha512 -days 3650 -key mail-ca.key -out mail-ca.crt

Преобразуем сертификат в формат DER для дальнейшего импорта в разные почтовые программы:

# openssl x509 -outform der -in mail-ca.crt -out mail-ca.der

Получение Подписанных Сообщений

Сообщение, хранящееся в папке (или часть сообщения) может иметь цифровую подпись. Когда вы открываете такое сообщение, компонент Веб Интерфейс Пользователя автоматически проверяет целостность подписанной части. Он получает данные о Подписавших сообщение из Подписей и пытается проверить подписи всех тех, кто подписал это сообщение. Затем он показывает список подписавших, чьи подписи проверены и соответствуют содержанию сообщения:

Подписано Цифровой Подписью (Text SHA1)

Уважаемые Господа,

Мы очень благодарны вам за ваше предложение. Мы принимаем его.

Искренне ваши,
Образцовые Посылатели

Содержимое Корректно, проверено:

Sample Sender <sender@domain.dom>

Если подпись не может быть проверена, высвечивается сообщение об ошибке.