Можно ли защитить пересылаемые по электронным каналам документы без дополнительных затрат? Что выбрать: PGP или S/MIME? Нужен ли "необязательный" СА? Что ж, попытаемся найти ответы…Мы уже рассматривали некоторые моменты установки и начала работы электронной почты, основанной на почтовом сервере Microsoft Exchange Server 2000 в среде Active Directory домена Windows 2000. Данная же статья посвящена одной из наиболее раздражающих и огорчающих проблем при организации обработки информации - проблеме безопасности при работе с электронной почтой. А точнее: защите почтовых сообщений от несанкционированного использования.

В соответствии с принятым набором инструментальных средств, в качестве клиентской операционной среды будем рассматривать Windows 2000/ХР Professional. Почтовые клиенты - Outlook Express и Microsoft Outlook. Почтовый сервер - Microsoft Exchange Server 2000.

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

Нетерпеливый читатель наверняка задается вопросом: "Да-да-да, все это хорошо. Но где же неизбежная ложка дегтя?". Что ж, недостатки любой вещи чаще всего коренятся в ее же достоинствах.

Электронная почта недорога, удобна, комфортна? Значит, ею пользуются многие. И, следовательно, при помощи e-mail нередко пересылается что-то личное, конфиденциальное и даже интимное - словом, не предназначенное для чужих глаз.
И вот тут-то самое время окатить читателя холодным душем. Электронная почта таит массу возможностей для нарушения безопасной работы с информацией. Она предоставляет широкое поле для передачи через присоединенные файлы программ-вирусов, программ-шпионов, троянов и т.п. Сообщения электронной почты легко перехватить, прочесть, "подредактировать" (понятно, без ведома и позволения отправителя) и, наконец, отправить послание с произвольным текстом любому из ваших абонентов - причем от вашего имени.

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

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

Пути защиты

Прежде чем приступить к изучению механизма защиты, очертим перечень угроз, от которых этот самый механизм должен предохранять. Это:

• несанкционированное чтение почты;
• несанкционированная корректировка почтового сообщения;
• формирование и отправка писем от чужого имени.

Все эти опасности давно известны, потому как в равной мере актуальны и при использовании обычной (бумажной) корреспонденции. Пути защиты также идентичны:

• аутентификация отправителя при помощи определенного идентификатора, подделка которого максимально затруднительна (для бумажного письма таким идентификатором является подпись автора);
• шифрование содержимого письма.

Методы и механизмы защиты

Защита почты от неразрешенного чтения или изменений основана на использовании электронной подписи и на криптографировании.

Сразу отметим, что такой популярный механизм защиты, как шифровка сообщений, основанная на протоколе PGP (Pretty Good privacy), мы рассматривать не будем. Причины таковы:

• с мая 2002 года ни одна версия PGP (бесплатная или коммерческая) не была сертифицирована на совместимость с операционной системой Microsoft Windows XP;
• бесплатная версия PGP, сертифицированная на совместимость с Windows 2000, предназначена для использования только в некоммерческих целях;
• базируясь на операционной системе Microsoft и используя при этом почтовую систему Microsoft (сервер и клиент), целесообразно использовать средства защиты, также встроенные в систему Windows;
• и, в конце концов, лишними знания никогда не бывают :).

Защита почты в среде Windows основана на практической реализации протокола стандартизованного безопасного формата сообщения S/MIME. Secure Multipurpose Internet Mail Extensions - многоцелевое расширение для обеспечения безопасности интернет-почты. S/MIME защищает сообщения и файлы от несанкционированного раскрытия данных, поддерживает цифровые подписи и шифрование в соответствии со стандартом PKCS # 7.

Шифрование базируется на инфраструктуре открытого ключа Windows 2000/2003 (PKI - public-key infrastructure), то есть используются сертификаты с личным ключом и технология криптографирования открытыми ключами.

Службы сертификатов (Certificate Services) Windows 2000 выполняют целый ряд функций - но в данном случае нас интересует обеспечение защиты электронной почты с помощью цифровой подписи и шифрования.

Не углубляясь в вопросы теории, уточним только, что службы сертификации Windows 2000 не устанавливаются по умолчанию при инсталляции операционной системы, а поставляются лишь в дистрибуции типа Server и состоят, в основном, из следующих компонент:

• центры сертификации;
• иерархия центров сертификации;
• ключи;
• сертификаты;
• список отозванных сертификатов;
• хранилища сертификатов.

Указанный список не полон, так как мы рассматриваем вопросы использования сертификатов только в соответствии с темой статьи (защита почты). Основной целью использования этих служб является управление созданием и обращением сертификатов для пользователя, компьютера, приложения.

Центр сертификации создает, назначает, отзывает сертификаты и управляет ими. Всего существует четыре типа таких центров. Рассмотрим простейший вариант, когда применяется один тип - корневой центр сертификации предприятия (СА). СА генерирует вместе с сертификатом открытый и закрытый ключи.

Сертификаты Windows 2000 соответствуют требованиям стандарта Х.509 v3, то есть они предназначены лишь для идентификации владельца и содержат копию открытого ключа СА.

Срок действия сертификата ограничен, по истечению отведенного времени сертификат либо продлевается, либо отзывается.

Сертификаты используются рядом приложений, в частности Microsoft Exchange 2000/2003.

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

Абонент А, отправляя почту абоненту В, должен шифровать почту открытым ключом абонента В, а получатель (абонент В) расшифровывает почту, используя свой закрытый ключ. Следовательно, для получения от абонента А зашифрованной почты абонент В предварительно обязан передать абоненту А свой открытый ключ. Эта передача может происходить различными путями: электронной почтой, на носителе информации (HDD, дискета, флэш-память и т.п.).

Дальнейшее рассмотрение технологии обеспечения защиты почты невозможно без ознакомления с последовательностью развертывания в Windows-домене инфраструктуры публичных ключей (PKI). Эта последовательность включает такие шаги:

1. Установка служб сертификации.
2. Установка модуля "Сертификационный центр" (Certification Authority - CA).

Развертывание PKI

1. Установка служб сертификации производится с помощью мастера Windows Component Wizard, при этом проходим следующие шаги:

• Control Panel (Панель управления) - Add\Remove Windows Component (Добавить/Удалить Компонент Windows);
• в списке выбираем компонент Certificate Services. (Внимание! Компьютер-сервер, выбранный для установки служб сертификации, должен быть контроллером домена. Кроме того, после завершения установки этот сервер нельзя будет переименовать или вывести из состава домена.);
• в появившемся диалоговом окне необходимо выбрать тип сертификационного центра. Предполагая, что это первый сертификационный центр, выбираем тип enterprise root CA;
• в диалоговом окне СА Identifying Information требуется ввести информацию, идентифицирующую конкретный СА: его имя, наименование организации, населенного пункта и страны, адрес электронной почты и комментарий;
• в окне Data Storage Location (Местоположение данных) нужно указать место хранения базы данных и файлов журналов СА. После ввода этой информации Wizard сообщает, что программа установки на период своей работы приостанавливает службу IIS;
• установка СА завершается - и на экран поступает соответствующее сообщение.

2. Установка модуля "Сертификационный центр" (Certification Authority - CA).

Рис. 1. Формирование mmc-консоли модуля Certification

После установки служб сертификации требуется добавить в mmc-консоль модуль расширения Certification Authority, так как именно он управляет работой СА. Для этого производим следующие действия:

• в командной строке запускам команду mmc;
• в меню Console (Консоль) выбираем опцию Add/Remove Snap-in (Добавить/Удалить оснастку). Откроется диалоговое окно Add/Remove Snap-in (Добавить/Удалить изолированную оснастку), нажимаем кнопку Add (Добавить);
• в окне Add Stand-Alone Snap-in (Добавить/Удалить изолированную оснастку) в списке оснасток (рис. 1) выбираем элемент Certification Authority и нажимаем кнопку Add (Добавить);
• закрываем последовательно все раскрытые окна.

Запрашиваем сертификаты для пользователей.

Сертификаты должны получить все пользователи - абоненты защищаемой электронной почты. Обязательное условие: те, кто получает сертификат, должны быть пользователями Wiondows-домена, в котором мы установили СА.

Пользователь, получающий сертификат, начинает сеанс, запускает веб-браузер и обращается к Центру сертификации через URL http://name-server/certsrv/, где name-server - имя контроллера домена, на котором установлен СА.

Появляется диалоговое окно Microsoft Certificate Services (рис. 2).

Рис. 2. Начало процесса запроса сертификата

Устанавливаем тип задания дальнейшей обработки Request a sertificate, жмем кнопку Next. На следующий запрос из типов формирования запроса выбираем Advanced request.

В ответ на ввод типа появляется на экране окно Advanced Certificate Requests (Расширенного запроса сертификата) с предложением выбрать тип сертификации. Отмечаем в перечне строку Submit a certificate request to this CA using a form. То есть мы запрашиваем формирование сертификата средствами СА с применением формы запроса и нажимаем кнопку Next.

Появляется диалоговое окно формы для ввода данных, используемых для формирования сертификата. После ввода информации в поля формы (рис. 3) нажимаем кнопку Next.

Рис. 3. Форма запроса данных пользовательского сертификата

На фоне формы запроса появляется запрос, требующий подтверждения формирования сертификата. После подтверждения поступает извещение, которое информирует о возможности начала инсталляции сертификата. В процессе установки на экран поступает сообщение, предупреждающее о возможных угрозах безопасности системе в случае обновления сертификатов НЕ доверенным веб-узлом. И, наконец, появляется последнее сообщение - о завершении формирования запрошенного сертификата.

Для просмотра выданных и отозванных сертификатов, их градаций и состояния используется оснастка Сертификаты. Для добавления этой оснастки в состав консоли выполняем следующее:

• в командной строке запускаем команду mmc;
• в меню Console (Консоль) выбираем опцию Add/Remove Snap-in (Добавить/Удалить оснастку). В открывшемся диалоговом окне Add/Remove Snap-in нажимаем кнопку Add (Добавить);
• в диалоге Add Stand-Alone Snap-in (Добавить/Удалить изолированную оснастку) выбираем в списке оснастку Сертификаты и нажимаем кнопку Add (Добавить);
• закрываем последовательно все раскрытые окна.

Теперь запускаем консоль Сертификаты и видим дерево сертификатов (рис. 4).

Рис. 4. Дерево сертификатов

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

Рис. 5. Сертификат пользователя

Перейдем теперь непосредственно к организации шифрования и формированию цифровых подписей. То есть необходимо решить следующие задачи:

• настройка программного клиентского обеспечения Microsoft Outlook на использование средств защиты;
• закрытая почтовая связь с абонентом, работающим в той же ЛВС;
• закрытая почтовая связь с абонентом, работающим в удаленном режиме.

Что касается первого пункта - настройки клиентского ПО Microsoft Outlook - то перечень действий пользователя для получения сертификата уже описан (см. рис. 2). После получения пользователями своих сертификатов выполним настройку клиентского программного обеспечения Microsoft Outlook для отправки защищаемых почтовых сообщений.

Запускаем Microsoft Outlook, выбираем в пункте меню Сервис опцию Параметры и в соответствующем окне переходим на закладку Безопасность (рис. 6). Активируем параметры Шифровать содержимое и вложения исходящих сообщений и Добавлять цифровую подпись к исходящим сообщениям.

Рис. 6. Активация средств безопасности Microsoft Outlook

В этом же окне нажимаем кнопку Параметры, в диалоговом окне Изменение настроек безопасности устанавливаем значения:

• имя конфигурации - "установки S/MIME (имя почтового ящика)";
• формат сообщения - "S/MIME".

Кроме того, задаем (устанавливая соответствующие флажки) использование параметров Настройка безопасности по умолчанию для этого формата, Настройка по умолчанию для всех сообщений.

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

Иная ситуация складывается, когда получатель письма физически не связан с контроллером домена. В этом случае удаленный абонент А должен:

1. Стать членом домена для получения собственного сертификата, чтобы иметь возможность работать со своей корреспонденцией.
2. Получить от абонента В его открытый ключ для криптографирования почты, направляемой абоненту В.
3. Отправить абоненту В свой открытый ключ для того, чтобы абонент В мог криптографировать почту, направляемую им абоненту А.

Надеюсь, читатель не запутался :).
Сказанное проиллюстрировано в таблице.

Рассмотрим действия детальнее. Получение абонентом А собственного сертификата проходит в четыре этапа:

• первое - регистрация и получение сертификата;
• далее абонент А входит в консоль Сертификаты, раскрывает последовательно ветки Сертификаты - текущий пользователь, Личные, Сертификаты, выделяет в правой половине окна свой сертификат, вызывает контекстное меню, вызывает пункт Все задачи, а в нем Экспорт. Начинает работать Мастер экспорта сертификатов. Абонент А заказывает опцию Да, экспортировать закрытый ключ, указывает место для экспорта файла и имя этого файла, нажимает последовательно кнопки Далее, Готово - в результате формируется соответствующий файл с расширением .cer;
• затем этот файл записывается на компьютер абонента А;
• и, наконец, абонент А, получив сформированный файл сертификата, кликает по нему мышкой, после чего выполняется импорт сертификата.

Получение абонентом А от абонента В открытого ключа состоит из следующих действий:

• абонент В на своем ПК входит в консоль Сертификаты, раскрывает последовательно ветки Сертификаты - текущий пользователь, Личные, Сертификаты, выделяет в правой половине окна свой сертификат, вызывает контекстное меню, выбирает пункт Все задачи, а в нем - Экспорт. Начинает работать Мастер экспорта сертификатов. Заказываем опцию Нет, не экспортировать закрытый ключ, указываем место для экспорта файла и имя файла, нажимаем последовательно кнопки Далее, Готово - в результате формируется соответствующий файл с расширением .cer;
• полученный файл передается абоненту А;
• абонент А, получив сформированный файл, кликает по нему мышкой, после чего выполняется импорт сертификата с открытым ключом.

Абоненты выполняют настройку почтового клиентского обеспечения (рис. 6), после чего могут приступать к обмену зашифрованной почтой.