Многие системы на базе Exchange Server имеют набор почтовых ящиков, служащих для каких-то определенных целей. Организации используют почтовые ящики с анонимным доступом для таких специализированных задач, как распространение информации или сбор данных от многих пользователей. Например, может быть создан ящик HelpDesk, на который пользователи отправляют свои запросы по поводу обеспечения поддержки или консультаций. При этом три или четыре человека могут просматривать содержимое данного ящика и отвечать на такие сообщения. Или же можно использовать почтовые ящики HR Manager либо VP of Operations для рассылки бюллетеней, сообщающих, например, о том, что текущий рабочий день будет на 2 часа короче, так как объявлено штормовое предупреждение.

Контролируемая почта

Многие системы на базе Exchange Server имеют набор почтовых ящиков, служащих для каких-то определенных целей. Организации используют почтовые ящики с анонимным доступом для таких специализированных задач, как распространение информации или сбор данных от многих пользователей. Например, может быть создан ящик HelpDesk, на который пользователи отправляют свои запросы по поводу обеспечения поддержки или консультаций. При этом три или четыре человека могут просматривать содержимое данного ящика и отвечать на такие сообщения. Или же можно использовать почтовые ящики HR Manager либо VP of Operations для рассылки бюллетеней, сообщающих, например, о том, что текущий рабочий день будет на 2 часа короче, так как объявлено штормовое предупреждение.

Анонимные почтовые ящики часто используются, когда за деловую переписку отвечает несколько человек. Поскольку в каждый момент времени доступ к почтовому ящику может иметь не один человек, необходимо обеспечить гарантированные механизмы учета, аудита доступа и авторства отправленных сообщений. Что произойдет, если кто-то отправит сообщение "все могут идти домой" без подтвержденного авторства? Можно ли будет определить, кто послал сообщение? Пользователи смогут проверить подлинность сообщения? В этой статье я расскажу о том, как настроить систему так, чтобы легко было проверить путь сообщения при использовании анонимного почтового ящика и дать пользователям возможность установить автора писем.

Доступ к анонимным почтовым ящикам

Для создания анонимного почтового ящика нужно для выбранного почтового ящика предоставить определенным пользователям право User Rights. На Экране 1 показана такая конфигурация для Exchange Server 5.5.

Экран 1: Назначение прав для анонимного почтового ящика.

Сотрудники с соответствующими правами User Rights могут использовать анонимный почтовый ящик несколькими способами. Они могут определить его в конфигурации Outlook и получить доступ ко всему почтовому ящику; они могут, используя Outlook, открыть папку почтового ящика другого сотрудника и также использовать функцию Exchange Send As для того, чтобы просто вводить название анонимного почтового ящика в поле сообщения "От". На Экране 2 показано, что Kevin Mason работает со своим почтовым ящиком, но вводит "VP of Operations" в поле "От" для отправки сообщения от имени VP of Operations.

Экран 2: Использование возможностей Send As.

Регистрация информации об анонимном почтовом ящике

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

Экран 3: Результаты трассировки сообщения.

Трассировка сообщения подтверждает, что сообщение прибыло из анонимного почтового ящика (информация в журналах трассировки Exchange предназначена для отслеживания прохождения сообщений через компоненты системы, а не для проверки безопасности).

На Экране 3 мы видим результат работы модуля трассировки сообщений в Exchange 5.5, а в Exchange 2000 Server также отмечается, что это анонимный ящик - вместо того, чтобы указать доменную учетную запись или имя почтового ящика, из которого было отправлено сообщение. Когда к почтовому ящику обращается пользователь (с помощью соответствующей конфигурации Outlook), чья учетная запись не является для него основной, Exchange 2000 и Exchange 5.5 записывают событие с ID 1016 в системный журнал приложений. Это происходит потому, что система распознает, что учетная запись, с которой обратились к почтовому ящику, не определена как Primary Windows account в Exchange 5.5 или не является в Active Directory (AD) учетной записью, связанной с объектом почтового ящика. Но если пользователь осуществляет доступ к анонимному почтовому ящику другим способом (например, используя Send As или другую функцию), в журнале по умолчанию ничего не отображается.

Для того чтобы работа с анонимным почтовым ящиком велась без особого ущерба для системы безопасности, можно увеличить уровень диагностики по двум параметрам в Private Information Store. При работе с Exchange 5.5 необходимо, используя программу Microsoft Exchange Administrator, раскрыть дерево контейнеров и выбрать объект Private Information Store (ORG\Site\Configuration\Server\<server>\Private Information Store). В меню File выберите Properties и закладку Diagnostics Logging (см. Экран 4). В окне Services выберите Private. В окне Category следует выделить Logons и установить уровень диагностики на Minimum. Для параметра Send As также установите уровень диагностики в Minimum и нажмите OK.

Экран 4: Настройки Diagnostics Logging

Для Exchange 2000 эта процедура выглядит идентично. Используя оснастку Microsoft Management Console (MMC) Exchange System Manager (ESM), раскройте контейнер Administrative Groups. Если контейнер Administrative Groups не отображается, то сначала надо вызвать Properties на уровне организации и установить флажок Display Administrative Groups. Далее следует раскрыть Administrative Group, затем контейнер Servers. Правой кнопкой щелкните на нужном сервере и выберите Properties. Перейдите на закладку Diagnostics Logging. В секции Services раскройте объект MSExchangeIS и выделите объект Mailbox. В категории выделите Logons и установите уровень диагностики в Minimum. Выделите Send As и также установите уровень диагностики в Minimum, затем щелкните OK. Эту процедуру нужно выполнить для всех серверов Exchange, поскольку события регистрируются только для тех серверов, которые хранят почтовые ящики, в том числе анонимные. Ни Exchange 2000, ни Exchange 5.5 не требуют перезагрузки - изменения уровня диагностики воспринимаются сразу же.

После внесения изменений в системном журнале приложений появятся два дополнительных события. Когда кто-то будет обращаться к почтовому ящику (включая владельца) или задействовать функции File, Open и другие, в журнале Application появится событие с ID 1009, а событие с ID 1032 (показано на Экране 5) проинформирует о применении функции Send As.

Экран 5: Событие Send As

При использовании функции Send As можно определить, кто нажал на кнопку "Отправить". Однако если несколько пользователей отправят сообщения одновременно, придется выяснять, кто же отправил то или иное сообщение. Такая диагностика увеличит количество элементов в журнале Application, поэтому потребуется увеличивать максимальный размер этого журнала. Преимущества дополнительной диагностики и трассировки превосходят расходы на выполнение регистрации всех данных. Если ваша система будет сильно занята такой регистрацией и возникнет угроза потери некоторых данных, следует рассмотреть такие продукты как Hewlett-Packard (HP) OpenView или NetIQ AppManager. Эти приложения помогут управлять журналами системных событий.

{mospagebreak}

Проверка подлинности сообщений

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

Экран 6: Подставной отправитель.

Например, на Экране 6 показано сообщение, отправленное списку рассылки All Staff, которому соответствует адрес SMTP: This email address is being protected from spambots. You need JavaScript enabled to view it.. Для создания такого сообщения достаточно с помощью утилиты Telnet подключиться к серверу SMTP и ввести следующие команды и данные:

HELO mysystem.demo.com
MAIL FROM: This email address is being protected from spambots. You need JavaScript enabled to view it.
RCPT TO: This email address is being protected from spambots. You need JavaScript enabled to view it.
DATA
From: <This email address is being protected from spambots. You need JavaScript enabled to view it.> VP of Operations
To: All Staff
Subject: Early Dismissal
You are authorized to leave early (2 hours) because of the ice storm.
Kevin

Exchange примет и доставит сообщение по списку рассылки All Staff. Если получатели проверят детали заголовка сообщения, они увидят, что оно отправлено из внешней системы и примут его за поддельное (обычно пользователи не знают, как просмотреть заголовок сообщения). Более того, дважды щелкнув по "Отправителю" и посмотрев окно "Свойств", многие пользователи решили бы, что сообщение подлинное. Версии Exchange и Outlook, выпущенные до появления Windows XP, использовали адреса SMTP в полях To: и From: для поиска соответствующего объекта в AD или в Exchange Directory. Найдя объект, Outlook читал свойства в каталоге и отображал дополнительные детали, такие как адрес и телефон, дополняя иллюзию подлинности.

Технология цифровой подписи

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

Экран 7: Цифровая подпись и проверка.

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

Размещение цифровых подписей в сообщении

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

Проверка цифровых сертификатов в Outlook

Когда центр Certificate Authority (CA) выпускает сертификат, то в него попадает набор ассоциированных атрибутов, которые показывают, для кого предназначен сертификат, время его действия и расположение списка отозванных сертификатов - CRL. На Экране А показаны некоторые атрибуты. Экран A: Атрибуты сертификата. Outlook 2000 может проверить сертификат на соответствие датам Valid from и Valid to, но при этом Outlook не проверяет CRL, хотя CA мог отозвать этот сертификат. Для настройки Outlook 2000 на проверку CRL потребуется внести изменения в системный реестр. Откройте редактор реестра и перейдите в раздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography. Создайте подраздел с названием {7801ebd0-cf4b-11d0-851f-0060979387ea}. В этом подразделе создайте новый параметр REG_DWORD с названием PolicyFlags и присвойте ему значение 10000 (шестнадцатеричное). После перезапуска Outlook он уже будет проверять сертификаты в CRL. Кроме того, следует установить пакет обновлений Microsoft Office Service Release 1a (SR1a) или выше. До этого обновления, в случае если Outlook не мог подтвердить цифровую подпись из-за того, что у него не было соответствующего сертификата в его хранилище или из-за того, что сертификат был найден в CRL, просто выдавалось предупреждающее сообщение о том, что возникли проблемы с подтверждением подписи, а информация о причинах сбоя не предоставлялась. Младшие версии Outlook также ошибочно сообщали, что сертификат не отозван (Certificate not revoked), в то время как этот сертификат был в CRL. Необходимо рассмотреть еще два момента, связанных с CRL, но крайне важных для приложений, использующих сертификаты. Во-первых, когда CA публикует CRL, назначается срок действия. Для ускорения процесса проверки Outlook запрашивает CRL и кэширует его. Outlook не запросит другой CRL у того же CA, пока не истечет срок действия. При этом Outlook не знает о том, что в действующий CRL добавлялись сертификаты. Во-вторых, CRL доступны через точки распространения CDP (CRL Distribution Points). Outlook получает доступ к CDP через общий ресурс, FTP, LDAP или HTTP (CA определяет механизм). Если CDP недоступны или Outlook запрашивает новый CRL, при открытии нового сообщения возникнет существенная задержка.

Если у вас еще не установлен Outlook XP, рекомендуется использовать версию не ниже, чем Outlook 2000 Service Release 1a (SR1a). В версии SR1a устранены проблемы, связанные с обработкой списков отмененных сертификатов (Certificate Revocation Lists - CRL - списки сертификатов, которые были отменены из-за таких ситуаций, как потеря или компрометация личных закрытых ключей). Во-вторых, требуется связать цифровой сертификат с почтовым адресом отправителя. Цифровые сертификаты имеют две части - открытый ключ и закрытый ключ, выдаваемые специальными центрами сертификации Certificate Authority (CA). CA могут работать внутри организации и обслуживать свою почтовую систему или могут быть установлены в другой компании, которой организация доверяет. Такие независимые компании подтверждают подлинность отправителя и выдают ему сертификат, а затем подтверждают подлинность отправителя получателю. CA выполняет эти функции, создавая доступные открытые ключи сертификатов, которые идентифицируют организацию в CA. Такие сертификаты называются корневыми или промежуточными сертификатами CA, в зависимости от типа CA. Когда CA выпускает сертификат для индивидуальных почтовых адресов, CA подписывает сертификат, используя свой закрытый ключ. Получатель проверяет открытый ключ в сертификате отправителя, используя данные подписи CA и открытый ключ сертификата. Если подпись CA правильная, сертификат отправителя считается достоверным.

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

Получив сертификат с копией открытого ключа отправителя, получатель должен проверить достоверность данного сертификата и после этого отправитель становится доверенным. Если сертификат уже установлен на компьютере в хранилище сертификатов, то такие сертификаты система считает достоверными. Предпочтительно для более надежной защиты использовать цепочки сертификатов и списки CRL для определения статуса сертификата. Как говорилось выше, сертификат содержит информацию об используемом центре CA. Для доверенной цепочки, чтобы механизм поверки подлинности работал, нужно хранить на каждом компьютере сертификаты всех известных CA, выпускающих сертификаты, или корневого CA. Таким сертификатам доверяют больше, чем присылаемым отправителем, так как это более типичная ситуация. Поскольку пользователь явно доверяет выпускающему сертификаты CA или корневому CA, неявно он доверяет и отправителю, чья подпись и данные верны, если его нет в списке CRL. Если отправитель использует такие всем известные центры CA, как VeriSign, Thawte или Baltimore Technologies, то он уже имеет на своем ПК установленные сертификаты таких центров. Если отправитель использует сертификаты менее известных CA, то получатель должен установить у себя сертификаты этих CA.

Процедура запроса и получения сертификата отличается у разных центров авторизации CA, но в основном все проходит просто. Вы предоставляете некоторую идентификационную информацию в CA, тот проверяет ее и высылает инструкцию для получения и установки цифрового сертификата. Увидеть сертификат можно с помощью Microsoft Internet Explorer (IE). Для просмотра сертификатов, хранящихся на компьютере, откройте IE, выберите Tools, Internet Options, а затем перейдите на закладку Content. Щелкните кнопку Certificates для отображения хранилища сертификатов. Список сертификатов находится на закладке Personal.

После установки сертификатов необходимо настроить Outlook на использование сертификатов для подписи электронных писем. Откройте Outlook, щелкните Tools, Options и перейдите на закладку Security. Щелкните Settings для отображения диалогового окна Change Security Settings, показанного на Экране 8.

Экран 8: Настройка Outlook для использования цифровых сертификатов.

Поля в секции Certificates and Algorithms должны быть заполнены информацией из установленного сертификата. Если у вас имеется более одного персонального сертификата, вы должны щелкать на выборе сертификата рядом с кнопками Signing Certificate и Encryption Certificate и выбирать из списка имеющихся сертификатов. Если разница в алгоритмах не ясна, следует выбрать параметры по умолчанию. SHA - алгоритм хеширования, используемый по умолчанию, Outlook применяет его для создания дайджеста из сообщения; 3DES - алгоритм шифрования, используемый по умолчанию. Если вы не хотите, чтобы Outlook присоединял ваш открытый сертификат, необходимо убрать флажок Send these certificates with signed messages. Если вы это сделаете, нужно будет обеспечить всех потенциальных получателей копией открытого ключа. Если планируется использовать личный сертификат только для подписи, то можно игнорировать эту настройку, что упростит общую процедуру. Щелкните OK, чтобы закрыть диалоговое окно Change Security Settings. На закладке Security диалогового окна Options следует отметить флажок Add digital signature to outgoing messages, если нужно, чтобы подписывались все исходящие сообщения. Если не выделить этот параметр, придется вручную выбирать пункт цифровой подписи в каждом отправляемом сообщении.

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

Экран 9: Подтверждение цифровой подписи.

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

Дополнительный контроль над почтовой системой

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

Джозеф Ньюбауэр - старший технический консультант Hewlett-Packard, специалист по системам электронной почты. С ним можно связаться по адресу: This email address is being protected from spambots. You need JavaScript enabled to view it..

Windows & .NET Magazine/RE Издательство "Открытые системы" (www.osp.ru)
Постоянный адрес статьи: http://www.osp.ru/win2000/exchange/200306eo318.htm