Служба банка данных Microsoft Exchange поддерживает события аудита Windows NT на основе системной политики. Эти события регистрируются в журнале безопасности, и в них указывается каждый экземпляр открытого объекта. Этот тип ведения журнала относится к самому высокому уровню аудита и сопровождается подробными записями о доступе к объектам. Аудит доступа не заменяет аудит Windows. В аудите Windows основное внимание уделяется событиям, связанным с открытием и закрытием объектов. При аудите доступа некоторые события объектов полностью игнорируются в пользу событий, соответствующих реальному доступу пользователей к данным. Рассмотрим следующий пример:

В аудите Windows основное внимание уделяется событиям, связанным со входом в почтовый ящик. В Exchange событие входа — это действие по привязке к данным, которое впоследствии позволит клиенту попытаться открывать папки. Сам объект входа не предоставляет доступа к определенным данным. Поэтому он является ложной фокальной точкой аудита.

В аудите доступа основное внимание уделяется событиям, связанным с доступом клиента к фактическим данным системы обмена сообщениями или использованием прав, которые влияют на эти данные. Например:

• Открывая папку, клиент получает доступ к реальным данным.
  
  
• Открывая сообщение, клиент получает доступ к реальным данным.
  
  

Вход в почтовый ящик — это неявная операция получения доступа к папке. Аудит доступа позволяет не обращать внимание на операции, которые выполняются на уровнях ниже поддерева межабонентских сообщений (IPM), такие как просмотр данных о занятости кэша. Кроме того, в аудите доступа игнорируется доступ со стороны системных процессов Exchange. При этом могут регистрироваться только определенные классы доступа. Добиться компромисса между аудитом Windows и аудитом доступа можно за счет правильных настроек. Аудит Windows можно задать с помощью политики. Аудитом доступа позволяют управлять диагностические категории банка данных Microsoft Exchange.

Важно!
При аудите доступа не регистрируется удаление сообщений, регистрируется только доступ к ним.

Количество событий, которые заносятся в журнал при аудите, напрямую связано с нагрузкой на сервер и операциями, которые пользователи выполняют в любой момент времени и которые принадлежат к типу для аудита. При аудите доступа события не добавляются в журнал приложений, поскольку он тоже является источником диагностических данных, которые помогают устранять неполадки. В Exchange 2007 с пакетом обновления 2 (SP2) в результате установки на сервер роли сервера почтовых ящиков создается новый журнал событий. Это журнал событий аудита Exchange. По умолчанию этот журнал расположен в каталоге \Exchange Server\Logs\AuditLogs. На компьютере с ОС Windows Server 2008 он находится в каталоге Applications and Services Logs\Exchange Auditing. Местоположение этого файла журнала по умолчанию — %PROGRAMFILES%\Exchange Server\Logging\Auditlogs. В списке управления доступом (ACL) для журнала аудита Exchange по умолчанию задаются следующие разрешения:

• для администраторов Exchange Administrators — доступ для чтения и очистки;
  
  
• для администраторов организации Exchange — доступ для чтения и очистки;
  
  
• для серверов Exchange — доступ для чтения и записи;
  
  
• для локальной службы — полный доступ.
  
  

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

• На нулевом уровне (0) ведения журнала ничего не регистрируется.
  
  
• На первом уровне ведения журнала (1) в журнал добавляются только действия пользователей с правами администратора.
  
  
• На втором (2) и четвертом (4) уровнях в журнал записываются только события, связанные с доступом одного пользователя к почтовому ящику другого пользователя.
  
  
• На третьем (3) и пятом (5) уровнях в журнал записываются события, связанные с доступом любого пользователя к любому почтовому ящику.
  
  

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

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

• На нулевом уровне (0) ничего не регистрируется. При доступе к папкам на этом уровне ведения журнала события в журнал не заносятся.
  
  
• На первом уровне (1) в журнале регистрируется только доступ с правами администратора.
  
  
• На втором (2) и четвертом (4) уровнях в журнал записываются только события, связанные с доступом одного пользователя с включенной поддержкой почтового ящика к папке другого пользователя с включенной поддержкой почтового ящика.
  
  
• На третьем (3) и пятом (5) уровнях в журнал записываются события, связанные с доступом любого пользователя к любой папке.
  
  

Иерархия папок почтового ящика состоит из поддерева сообщений, не являющихся межабонентскими, в котором содержатся такие используемые приложением папки, как папки поиска, а также из поддерева межабонентских сообщений (IPM), в котором содержатся папки, которые используют и просматривают пользователи, такие как «Входящие» и «Отправленные». Основные события соответствуют обычному доступу к папкам, которые видят пользователи. Эти папки обычно называют папками электронной почты. Доступ к папке заносится в журнал на основном уровне, если папка является дочерней папкой поддерева межабонентских сообщений (IPM). Ведение журнала всех событий охватывает папки, невидимые для пользователя, такие как корневая папка почтового ящика, а также папки, которые не принадлежат поддереву межабонентских сообщений (IPM). Администраторам, которым нужно вести аудит доступа к папкам электронной почты, таким как «Входящие», «Отправленные» или «Черновики», нет необходимости включать более высокие уровни ведения журнала событий. В таблице ниже перечислены события из категории доступа к папкам, которые регистрируются на каждом уровне ведения журнала.

Категория: доступ к папкам

Если аудит доступа к папкам включен, в журнале регистрируются события, подобные следующим:

Ниже приведены значения параметров в этом сообщении.

• %1 — это URL-имя папки. Другими словами, это полный путь к папке.
  
  
• %2 — это отображаемое имя папки. Сочетание отображаемого имени и пути к папке позволяет отличить папку от других папок с таким же именем.
  
  

Общие сведения о событиях аудита

• %3 — это значение legacyDN открытого почтового ящика.
  
  
• %4 — это имя пользователя, который прошел проверку подлинности для доступа к банку данных.
  
  
• %5 — это значение legacyDN пользователя, который открыл объект.
  
  
• %6 — это значение legacyDN почтового ящика.
  
  
• %7 — это флаг, который указывает, использовались ли права администратора для открытия папки.
  
  
• %8 — это относительный уникальный идентификатор. С помощью этого параметра можно соотнести последовательность действий в течение короткого периода.
  
  

Сведения о клиенте

• %9 — это имя компьютера.
  
  
• %10 — это адрес, который составил клиент. Это значение зависит от протокола, который был использован для подключения к серверу. Для локальных подключений (подключений с того же компьютера) используется имя компьютера. Двоичные файлы Exchange по возможности отправляют IP-адрес версии 6. В противном случае они отправляют IP-адрес версии 4. Отправленный IP-адрес является IP-адресом, идентифицированным клиентом. Для клиентов, расположенных за шлюзом преобразования сетевых адресов (NAT), такой IP-адрес может не являться различающимся.
  
  
• %11 — это имя процесса. Это имя двоичного файла приложения, которое обратилось для доступа к объекту.
  
  
• %12 — это идентификатор процесса. Он представляет собой числовой идентификатор определенного процесса.
  
  
• %13 — это идентификатор приложения. Это присвоенное клиентом значение, которое позволяет различать экземпляры файла Powershell.exe. Он также может быть событием, которое позволяет помечать дополнительные модули во время операций доступа к серверу.
  
  

Пример записи о событии доступа к папке в журнале событий

События доступа к сообщениям указывают на успешное открытие сообщения в банке данных Exchange. В сообщениях не поддерживаются основные события. Аудит доступа ко всем сообщениям основан на уровне ведения журнала, который задает администратор. В таблице ниже перечислены события из категории доступа к сообщениям, которые регистрируются на каждом уровне ведения журнала.

Категория: доступ к сообщениям

Если аудит доступа к сообщениям включен, в журнале регистрируются события, подобные следующим:

Ниже приведены значения параметров в этом сообщении.

• %1 — это идентификатор открываемого сообщения Интернета.
  
  
• %3 — это почтовый ящик, в котором сохранено сообщение.
  
  
• %4 — это пользователь, который прошел проверку подлинности для доступа к банку данных.
  
  
• %5 — это значение legacyDN пользователя, который открыл сообщение.
  
  
• %6 — это значение legacyDN почтового ящика.
  
  
• %7 — это флаг, который указывает, использовались ли права администратора для открытия сообщения.
  
  
• %8 — это относительный уникальный идентификатор, с помощью которого можно соотнести последовательность действий в течение короткого периода.
  
  

Сведения о клиенте

• %9 — это имя компьютера.
  
  
• %10 — это адрес, который составил клиент. Это значение зависит от протокола, который был использован для подключения к серверу. Для локальных подключений (подключений с того же компьютера) используется имя компьютера. Двоичные файлы Exchange по возможности отправляют IP-адрес версии 6. В противном случае они отправляют IP-адрес версии 4. Отправленный IP-адрес является IP-адресом, идентифицированным клиентом. Для клиентов, расположенных за шлюзом преобразования сетевых адресов (NAT), такой IP-адрес может не являться различающимся.
  
  
• %11 — это имя процесса. Это имя двоичного файла приложения, которое обратилось для доступа к объекту.
  
  
• %12 — это идентификатор процесса. Он представляет собой числовой идентификатор определенного процесса.
  
  
• %13 — это идентификатор приложения. Это присвоенное клиентом значение, которое позволяет различать экземпляры файла Powershell.exe. Он также может быть событием, которое позволяет помечать дополнительные модули во время операций доступа к серверу.
  
  

Пример записи о событии доступа к сообщению в журнале событий

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

Категория: расширенное событие «Отправить как»

Если аудит расширенных событий «Отправить как» включен, в журнале регистрируются события, подобные следующим:

Ниже приведены значения параметров в этом сообщении.

• %1 — это значение legacyDN пользователя, пытающегося отправить сообщение.
  
  
• %2 — это значение legacyDN пользователя, от которого отправляется сообщение.
  
  
• %3 — это идентификатор сообщения Интернета.
  
  
• %4 — это пользователь, который прошел проверку подлинности для доступа к банку данных.
  
  
• %5 — это значение legacyDN пользователя, пытающегося получить доступ.
  
  
• %6 — это значение legacyDN почтового ящика.
  
  
• %7 — это флаг, который указывает, использовались ли права администратора для отправки сообщения.
  
  
• %8 — это относительный уникальный идентификатор, с помощью которого можно соотнести действия в течение короткого периода.
  
  

Сведения о клиенте

• %9 — это имя компьютера.
  
  
• %10 — это адрес, который составил клиент. Это значение зависит от протокола, который был использован для подключения к серверу. Для локальных подключений (подключений с того же компьютера) используется имя компьютера. Двоичные файлы Exchange по возможности отправляют IP-адрес версии 6. В противном случае они отправляют IP-адрес версии 4. Отправленный IP-адрес является IP-адресом, идентифицированным клиентом. Для клиентов, расположенных за шлюзом преобразования сетевых адресов (NAT), такой IP-адрес может не являться различающимся.
  
  
• %11 — это имя процесса. Это имя двоичного файла приложения, которое обратилось для доступа к объекту.
  
  
• %12 — это идентификатор процесса. Он представляет собой числовой идентификатор определенного процесса.
  
  
• %13 — это идентификатор приложения. Это присвоенное клиентом значение, которое позволяет различать экземпляры файла Powershell.exe. Он также может быть событием, которое позволяет помечать дополнительные модули во время операций доступа к серверу.
  
  

Дополнительные сведения о предоставлении разрешения «Отправить как» см. в разделе Инструкции по предоставлению разрешений «Отправить как» для почтового ящика.

Пример записи в журнале о событии «Отправить как»

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

Категория: расширенная отправка от имени другого пользователя

Если аудит расширенных событий «Отправить от имени» включен, в журнале регистрируются события, подобные следующим:

Ниже приведены значения параметров в этом сообщении.

• %1 — это значение legacyDN пользователя, пытающегося отправить сообщение.
  
  
• %2 — это значение legacyDN пользователя, от имени которого отправляется сообщение.
  
  
• %3 — это идентификатор сообщения Интернета.
  
  
• %4 — это пользователь, который прошел проверку подлинности для доступа к банку данных.
  
  
• %5 — это значение legacyDN пользователя, пытающегося получить доступ.
  
  
• %6 — это значение legacyDN почтового ящика.
  
  
• %7 — это флаг, который указывает, использовались ли права администратора для отправки сообщения.
  
  
• %8 — это относительный уникальный идентификатор, с помощью которого можно соотнести действия в течение короткого периода.
  
  

Сведения о клиенте

• %9 — это имя компьютера.
  
  
• %10 — это адрес, который составил клиент. Это значение зависит от протокола, который был использован для подключения к серверу. Для локальных подключений (подключений с того же компьютера) используется имя компьютера. Двоичные файлы Exchange по возможности отправляют IP-адрес версии 6. В противном случае они отправляют IP-адрес версии 4. Отправленный IP-адрес является IP-адресом, идентифицированным клиентом. Для клиентов, расположенных за шлюзом преобразования сетевых адресов (NAT), такой IP-адрес может не являться различающимся.
  
  
• %11 — это имя процесса. Это имя двоичного файла приложения, которое обратилось для доступа к объекту.
  
  
• %12 — это идентификатор процесса. Он представляет собой числовой идентификатор определенного процесса.
  
  
• %13 — это идентификатор приложения. Это присвоенное клиентом значение, которое позволяет различать экземпляры файла Powershell.exe. Он также может быть событием, которое позволяет помечать дополнительные модули во время операций доступа к серверу.
  
  

Пример записи в журнале о событии отправки от имени другого пользователя

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

В сервере Exchange 2007 с пакетом обновления 2 (SP2) в схему добавлено новое расширенное право. Это право на обход аудита. Право на обход аудита позволяет не добавлять в журнал записи о действиях с учетной записи пользователя, который имеет это право. Поэтому не следует давать право на обход аудита пользователям, для которых следует выполнять аудит.

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

Чтобы обойти аудит для учетных записей определенных служб, предоставьте соответствующее право для каждой базы данных почтовых ящиков с помощью командлета Add-ADPermission. Например, чтобы предоставить учетной записи Example\ServiceAccount право на Обход аудита доступа, выполните в командной консоли Exchange следующую команду:

	Копировать код
get-mailboxdatabase -Identity "Server01\StorageGroup01\MailboxDatabase01" | Add-ADPermission -User example\ServiceAccount -ExtendedRights ms-Exch-Store-Bypass-Access-Auditing -InheritanceType All

Аудит доступа к почтовым ящикам Exchange — это сложный процесс, зависящий от того, с какой целью будут использоваться сведения, какие требования к аудиту предъявляются в конкретной организации, какие приложения используются и насколько высок уровень доверия к администраторам.

Аудит безопасности Windows NT является лучшим решением для организаций, в которых предъявляются очень высокие требования к уровню аудита. При этом создаются журналы аудита доступа всех пользователей ко всем объектам, а все добавленные в журналы сведения хранятся в журнале безопасности.

Аудит доступа Exchange подходит для тех организаций, которым не нужен аудит безопасности Windows. Такой аудит подходит для тех организаций, которым нужно регистрировать события с такими характеристиками.

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

Аудит доступа администратора с использованием прав администратора

Аудит только доступа из одного почтового ящика к другому

Сравнение аудита основных событий и всех событий

Расширенные сведения о клиенте

Таблицы содержимого папок

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

Обход аудита

Администраторы доменов

Изменения в порядке ведения журнала диагностики

Локальные администраторы

Вопросы производительности

Дополнительные сведения о том, как изменять уровни ведения журналов диагностики Exchange, см. в разделе Изменение уровня ведения журнала для процессов сервера Exchange Server.