Аудит доступа к почтовым ящикам в Exchange 2007(Часть 2)

OSzone.net » Microsoft » Exchange Server » Exchange Server 2007 » Аудит доступа к почтовым ящикам в Exchange 2007(Часть 2)
Автор: Нейл Хобсон
Иcточник: www.msexchange.ru
Опубликована: 25.05.2010

Это вторая и последняя статья из цикла о новой функции аудита доступа к почтовым ящикам, введенной в Exchange 2007 Service Pack 2. В первой части мы рассмотрели работу с этой функцией при помощи Exchange Management Shell, разобрались с событиями, вносимыми в журнал, когда пользователь получает доступ к собственному почтовому ящику, либо к почтовому ящику другого пользователя. Теперь, во второй части, мы завершим обзор этой функции описанием, как через Exchange Management Shell включить аудит, и кроме того, посмотрим на события, заносимые в категории журнала Message Access и Send As. Однако начнем мы вторую часть с того, как можно отключить аудит для конкретных аккаунтов.

Bypass Auditing

В первой части нашего цикла мы видели, как создавалась запись в журнале событий аудита Exchange, когда один пользователь получал доступ к почтовому ящику другого пользователя. Прочитав об этом, вы, возможно, задались вопросом, что происходит в тех случаях, когда аккаунт службы приложения, например, приложения резервного копирования, получает доступ ко всем почтовым ящикам, причем это является его обычной операцией. Действительно ли в таких случаях будет создано множество записей в журнале событий аудита Exchange во время работы такого приложения? К счастью, такая проблема снимается при помощью разрешения Bypass Auditing, являющегося расширением схемы, применяющейся при установке Exchange 2007 Service Pack 2. В уже указанной ситуации выдается разрешение Bypass Auditing аккаунту, используемому приложением резервного копирования. Если у приложения есть разрешение Bypass Auditing, никаких записей о нем в журнал делаться не будет.

Разрешение Bypass Auditing нужно выдавать аккаунту для каждой релевантной базы данных почтовых ящиков. Если вы распределили почтовые ящики пользователей равномерно по всем базам данных, вам придется убедиться в том, что вы выдали соответствующее разрешение для всех баз данных. Чтобы выдать разрешение Bypass Auditing, вы можете воспользоваться командой Add-ADPermission. В приведенном ниже примере аккаунт службы neilhobson\svc-backup получил разрешение Bypass Auditing для всех баз данных почтовых ящиков, поскольку результат команды Get-MailboxDatabase, возвращающей все базы данных, был передан в команду, добавляющую необходимые разрешения. Вот пример такой команды:

Get-MailboxDatabase | Add-ADPermission -User neilhobson\svc-backup 'ExtendedRights ms-exch-store-bypass-access-auditing 'InheritanceType all

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

*
Увеличить

Рисунок 8: Добавление разрешения Bypass Auditing

Настройка с помощью Management Shell

Также в первой части мы видели, как использовать Exchange Management Console для настройки уровня диагностики. Очевидно, то же самое можно делать и через Exchange Management Shell, так что давайте сейчас разберемся с этим.

На Рисунке 4 в первой части цикла мы устанавливали Folder Access в категории уровня диагностики, находящейся под категорией MSExchangeIS\9000 Private. Чтобы сделать то же в Exchange Management Shell, вы должны сначала воспользоваться командой Set-Location, чтобы указать на местоположение в реестре, используемое для изменения уровня диагностики. В PowerShell команда Set-Location используется для перехода не только по файловой системе, но и по реестру. Полный путь в реестре для установки уровня диагностики такой:

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\Diagnostics\9000 Private

Ниже на Рисунке 9 вы видите различные значения в этом ключе реестра; мы вернемся к ним немного позднее в этой статье.

*

Рисунок 9: Ключ реестра 9000 Private

Первая команда, которую нужно запустить, показана ниже. Она заставляет Exchange Management Shell работать в определенной локации реестра.

Set-Location 'HKLM:\System\CurrentControlSet\Services\MSExchangeIS\Diagnostics\9000 Private'

После выполнения этой команды ваш курсор должен измениться: вместо приглашения к вводу в обычной папке вы увидите его в локации реестра. На Рисунке 9 выше вы видели, что полное имя категории Folder Access - 9074 Folder Access, а значение в Data равно 0. Имя величины важно знать, так как именно это имя нам нужно указывать при изменении значения данных. Чтобы изменить значение этого параметра реестра, нам нужно воспользоваться командой Set-ItemProperty с параметрами Path, Name и Value. Что касается Path, нам нужно всего лишь использовать локальный путь, указываемый точкой (.). Для Name нужно использовать значение 9074 Folder Access, как уже упоминалось. Наконец, что касается значения Value: тут нужно указывать требуемый уровень диагностики, который в первой статье цикла был установлен как Medium.

Чтобы изменить уровень диагностики на Lowest, используйте значение 0.

Для Low используйте 1.

Для Medium используйте 3.

Наконец, для уровня High используйте 5.

То есть, команда должна быть следующая:

Set-ItemProperty 'Path . 'Name '9074 Folder Access' 'Value 3

Если все в порядке, курсор должен просто перейти на следующую линию. Чтобы убедиться в том, что настройка была проведена успешна, просто выполните команду Get-ItemProperty с параметром Path, указанным точкой (.):

Get-ItemProperty 'Path .

В результате вы получите нечто похожее на то, что показано на Рисунке 10 ниже. Использованные выше команды, возможно, не очень удобны, особенно если вы не слишком много используете PowerShell, но если вы планируете писать сценарии сборки для ваших серверов Exchange 2007, эти команды легко можно добавлять в любой сценарий для PowerShell.

*

Рисунок 10: Настройка реестра с помощью Exchange Management Shell

Дополнительная клиентская информация

Как я уже говорил в первой статье цикла, начать просмотр дополнительной клиентской информации в журнале событий вы можете с описания записи журнала событий, сделанной при доступе к папке другого пользователя. Полная клиентская информация, отображаемая в записях журнала событий, показана на Рисунке 6 первой части цикла:

Machine Name: CCR-SRV1

Address: 192.168.50.50

Process Name: w3wp.exe

Process Id: 0

Application Id: Client=OWA

Как видите, отсюда вполне понятно, что Mark получил доступ к папке Rob'а из Outlook Web Access, запущенного на сервере CCR-SRV1, имеющем IP-адрес 192.168.50.50. Если Outlook используется как клиентское приложение, имя процесса должно быть OUTLOOK.EXE, а не w3wp.exe, как тут показано.

Уровни журнала событий

В первой части цикла мы видели, как уровень журнала был установлен в Medium, чтобы отслеживать доступ к папкам. Мы видели установку в мастере Manage Diagnostics Logging Properties; напоминаю: выглядит она так (см. Рисунок 11).

*

Рисунок 11: Manage Diagnostics Logging Properties

Также на Рисунке 11 можно заметить, что всего есть пять различных уровней журнала событий, начиная с Lowest и заканчивая Expert. Различия между разными уровнями журнала заключаются в различных объемах записываемой информации. Среднего уровня вполне достаточно для отслеживания доступа к папкам в почтовом ящике обычного пользователя; и нет никакой необходимости увеличивать этот уровень, разве что вам понадобится отследить доступ к информации в не-IPM’овском поддереве или к таким папкам, как корневая папка почтовых ящиков, известная также как Top of Information Store (см. Рисунок 12).

*

Рисунок 12: Event ID 10100 ' Mailbox Root Folder

Аудит других областей

Аналогичные записи в журнале событий делаются и для других категорий - Message Access, Extended Send As и Extended Send On Behalf Of. Например, если уровень для категории Message Access - Medium, и Mark получает доступ к сообщению в почтовом ящике Rob'а, записывается event ID 10102, что отражено на Рисунке 13. На этом же Рисунке можно заметить, что тут показывается message ID сообщения, к которому был получен доступ, а также другая важная информация, например, папка, содержащая сообщение, определенное имя пользователя, получившего доступ, а также имя владельца почтового ящика. В запись в журнале событий также включается та клиентская информация, которую вы уже видели ранее в этой статье.

*

Рисунок 13: Event ID 10102 ' Message Access

При аудите категории Extended Send As event ID в журнале событий меняется на 10106, а категория меняется на Send As (см. Рисунок 14). Там же видно, что описание в журнале событий раскрывает отдельные имена пользователей, участвующих в транзакции, и что Mark отправил сообщение так, как будто оно исходит от Rob’а.

*

Рисунок 14: Event ID 10106 ' Send As

Заключение

На этом мы завершаем наш двухчастный обзор новой функции аудита доступа к почтовым ящикам в Exchange 2007 Service Pack 2. Это очень мощная функция, которая может быстро заполнить ваши журналы событий множеством информации, поэтому очень важно хорошо выбрать момент, когда эта функция вам нужна. Также очень важно определиться, сколько времени вы собираетесь хранить записанные данные.


Ссылка: http://www.oszone.net/12591/Exchange-2007-2