Аудит и соответствие нормативным требованиям в Windows Server 2008

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

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

Как следствие, стал важным аудит изменений в среде. Почему? Аудит предоставляет средства определения сути изменений и управления ими в современных крупных и высокораспределенных информационных средах. В этой статье мы рассмотрим обычные задачи, с которыми сталкивается большинство организаций, сферу соответствия нормативным и регулятивным требованиям в информационных технологиях, основы аудита в Windows®, а также то, как функции Windows Server® 2008 и служб Audit Collection Services (ACS) в Microsoft® System Center Operations Manager 2007 могут дополнить всеохватывающую стратегию аудита.

Задачи аудита

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

Для примера, предположим, что некая организация ответственна за управление личными сведениями (personally identifiable information – PII) для определенной клиентской базы. Хотя и существует множество способов защитить информацию, хранящуюся на управляемых системах, нарушение безопасности все же возможно. Адекватный аудит позволяет организации знать, безопасность каких именно систем была нарушена и, возможно, какие данные были утеряны. Без аудита последствия потери данных могут быть намного выше, в первую очередь потому, что невозможно будет определить ее пределы.

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

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

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

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

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

 Рис. 1 Правовые нормы и что они означают для специалистов ИТ

Правовая норма	Ожидания
Закон Сарбейнса-Оксли, 2002 г. (SOX)	Раздел 404 признает роль информационных систем и требует от компаний, акции которых обращаются на рынке, предоставлять ежегодный обзор их внутреннего управления финансовой отчетностью.
Закон об отчетности в области медицинского страхования (HIPAA), 1996 г.	Затрагивает вопросы безопасности и конфиденциальности данных о здоровье; «Правило безопасности» охватывает административные, физические и технические меры защиты таких данных.
Электронное обнаружение (eDiscovery)	Определяет стандарты хранения документов и доступа к ним, включая ответственность за то, кто и как получает доступ к документам.
Федеральный закон об обеспечении безопасности информации (FISMA), 2002 г.	Федеральный мандат на предоставление исчерпывающей среды информационной безопасности (INFOSEC) для систем правительства США, координации с различными правоохранительными органами, установки систем контроля, признание коммерческих продуктов и программных возможностей. Раздел 3544 охватывает ответственность агентств, включающую контроль за ИТ.
Федеральные стандарты обработки информации (FIPS), выпуск 200	Определяет минимальные требования к безопасности информации для федеральной информации и информационных систем и очерчивает область использования рекомендаций, содержащихся в специальном выпуске (SP) NIST 800-53. В NIST SP800-53 раздел AU-2 (Подлежащие аудиту события) указывает, что информационные системы должны предоставлять возможность компиляции записей аудита с нескольких компонентов в единый, охватывающий всю систему, коррелированный по времени аудиторский след; возможность управления подвергшихся аудиту событий отдельными компонентами; а также обеспечивать регулярную проверку подлежащих аудиту событий организацией.

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

Подобные информационно-технические задачи обычно могут быть разрешены сочетанием сотрудников, процессов и технологий. Что касается аудита, это в первую очередь процедура, что существенно. Следовательно, первым шагом должно стать освоение основ, позволяющее отвечать на запросы и требования своей организации в плане соблюдения нормативных требований. Сначала мы раскроем некоторые из основ аудита в Windows, а затем углубимся в изменения в Windows Server 2008 и Windows Vista®.

Аудит событий безопасности

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

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

Учитывая это, важно разбираться в ключевых элементах, делающих возможной запись информации в журнале событий безопасности в Windows: политике аудита и системных списках управления доступом (SACL). Политики аудита настраиваются на локальных машинах через групповую политику или локальную политику безопасности и определяют сбор событий успеха или сбоя для определенных типов доступа. В Windows уже много лет представлены следующие основные категории политик аудита (ниже будет подробнее рассказано о новой политике детализированного аудита в Windows Server 2008):

• Аудит событий входа в систему под учетными записями
• Аудит управления учетными записями
• Аудит доступа к службе каталога
• Аудит событий входа в систему
• Аудит доступа к объектам
• Аудит изменений политики
• Аудит использования привилегий
• Аудит отслеживания процессов
• Аудит системных событий

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

Каждый объект, будь это файл, реестр или служба каталога, имеет свой список управления доступом (ACL) с одной или несколькими записями управления доступом (ACE), разделенный на два типа: список управления доступом на уровне пользователей (DACL) и SACL (последний определяет параметры записи попыток доступа к защищенным объектам). Каждая ACE в SACL определяет типы попыток доступа указанным доверенным лицом, которые следует записывать в журнал событий безопасности. ACE определяют запись в журнал успешных и/или сбойных попыток доступа к указанным объектам. На рис. 2 показано использование списка SACL на объекте для создания событий для конкретных типов доступа.

Рис. 2 Использование списка SACL на объекте

Знать отношения между политикой аудита и SACL крайне важно, поскольку для фиксации «верных» подвергшихся аудиту событий необходима настройка, относящаяся к изменениям в среде. Как уже упоминалось, политики аудита доступа к службе каталога и аудита доступа к объектам делают возможным создание аудитов в журнале событий безопасности лишь для этих конкретных категорий, но событий создаются, только если у объекта есть запись ACE для аудита, настроенная в его списке SACL. После того, как все эти элементы расставлены по своим местам, локальный центр безопасности Windows (Local Security Authority – LSA) создает события безопасности, и они записываются в журнал событий безопасности.

События состоят из двух различных областей: заголовка, являющегося статическим и заранее определенным для каждого идентификатора события (Event ID), и тела, являющегося изменяемым и содержащим различные детали для различных событий. На Рис. 3 показаны эти два элемента в примере события безопасности Windows Server 2008. Знание этих компонентов событий важно для фазы анализа любого проекта аудита и особенно интересно в отношении возвращения информации в таких средствах, как ACS.

Рис. 3 Заголовок и тело подвергшегося аудиту события 

Windows Eventing 6.0

Теперь, когда проблема знакома, можно спросить о том, как Windows Server 2008 помогает организациям решать эти задачи. Windows Server 2008 – первый выпуск серверной ОС, содержащий подсистему событий Windows Eventing 6.0, которая радикально улучшает положение дел в сфере управления событиями безопасности. Отметьте, что хотя в этой статье основное внимание уделено Windows Server 2008, 95% нового набора возможностей также существует в Windows Vista.

Первое, что многие пользователи заметят в Windows Eventing 6.0, – это новый интерфейс пользователя. Новая оснастка средства просмотра событий консоли управления Microsoft (Microsoft Management Console – MMC) предлагает отличную страницу обзора и сводки, гибкие настраиваемые представления и намного улучшенную функцию текста описания. Эти интерфейсы могут помочь конечному пользователю или системному администратору найти информацию о событиях и настроить важные параметры журнала событий прямо из самого средства просмотра.

Ключевой проблемой, часто воздействовавшей на данные безопасности внутри журнала событий, было хранение данных. Ранее подсистема журнала событий (включая все журналы) сталкивалась с ограничениями масштабируемости. При выходе за рамки этих ограничений подсистема в целом переставала записывать события. Однако в Windows Eventing 6.0 это не так, и организации теперь ограничены только объемом доступного пространства на диске. Однако обратите внимание, что очень большие журналы событий могут быть неудобными для анализа, поскольку при фильтрации необходимо оценить каждую отдельную запись, так что размер журнала определенно стоит сохранять в управляемых пределах.

Само собой, это по-прежнему возлагает на администратора ИТ задачу разработки плана архивирования для журналов событий на многих системах. Чтобы помочь в этом на уровне локального сервера, в Windows Eventing 6.0 введена новая функция, а именно возможность «Архивировать журнал при заполнении, не перезаписывать события». В предыдущих версиях Windows эту возможность можно было установить только через прямое изменение значения реестра AutoBackupLogFiles. Это предоставляет механизм для создания локального архива журналов, но не предоставляет решения для управления этими файлами с течением времени, а также не затрагивает проблемы объединения, возникающей при работе с несколькими системами. Службы сбора аудита (Audit Collection Services – ACS) предоставляют законченное решение для этого, которого мы коснемся чуть ниже.

Новый интерфейс – это только начало. Настоящие возможности Windows Eventing 6.0 заключаются в новой службе журнала событий Windows и лежащем в ее основе механизме на базе XML. Эти компоненты и предоставляют улучшенные возможности масштабируемости, доступности и управления. События теперь хранятся в гибком формате XML, делающем возможным нестандартные решения, со встроенной возможностью доступа к этой информации.

Windows Eventing 6.0 также предоставляет возможность связывать административные действия с конкретными событиями. Это достигается путем интеграции службы сбора событий Windows с планировщиком задач для предоставления событий на основе задач. Это новая парадигма для планировщика задач, которые ранее был ограничен запуском событий на основе времени. Мастер «Привязать задачу к событию» (доступный в контекстном меню любого события в обозревателе событий Windows Server 2008) предоставляет простой способ запустить программу, отправить письмо по электронной почте или отобразить сообщение при каждой записи в журнал определенного события. Это может быть очень полезно при попытке определить конкретные действия, происходящие в среде и могущие быть локализованными в определенном событии безопасности. Например, при аудите изменений в разделе реестра "Schema Update Allowed" на контроллерах домена можно создать задачу, отправляющую сообщение электронной почты определенным администраторам безопасности, чтобы уведомить их об изменении данного раздела реестра.

Вдобавок к новой возможности сбора и хранения большого числа записей о событиях, теперь можно лучше контролировать, какие события записываются в журнал. Это достигается через новую возможность, именуемую политикой детализированного аудита (Granular Audit Policy – GAP). В предыдущих версиях Windows девять широких категорий аудита часто приводили к перегрузке событиями. Эти категории верхнего уровня теперь могут контролироваться 50 детализированными подкатегориями, каждая их которых представляет подмножество связанных друг с другом событий.

Это дает возможность отфильтровывать маловажную информацию из журнала событий, не теряя видимости на уровне категории. Например, если на определенной системе необходимо отслеживать только изменения в реестре, но не в файловой системе, раньше можно было выбрать лишь сообщение об успехах или сбоях в категории доступа к объектам. С помощью GAP теперь можно отфильтровывать такие подкатегории, как файловая система, службы сертификации и общий файловый ресурс, сообщая лишь о событиях в подкатегории реестра. Чтобы исследовать подкатегории GAP на системе Windows Server 2008, необходимо выполнить команду Auditpol из командной строки с повышенными полномочиями. Чтобы перечислить все доступные подкатегории GAP, введите следующее:

auditpol /list /subcategory:* 

Для получения списка подкатегорий GAP, настроенных на вашей системе, введите следующее:

auditpol /get /category:* 

Обратите внимание, что GAP не настраивается через стандартный интерфейс пользователя групповой политики, и им необходимо управлять через auditpol.exe. В статье базы знаний по адресу support.microsoft.com/kb/921469 имеется руководство по развертыванию параметров GAP через групповую политику для систем Windows Server 2008 и Windows Vista.

Windows Server 2008 также может фиксировать как старые, так и новые значения конкретных типов в журнале событий безопасности. В предыдущих версиях Windows подсистема аудита заносила в журнал только имя атрибута объекта Active Directory® или параметр реестра, которые были изменены, но не предыдущее или текущее значения атрибута. Эта новая возможность применима к доменным службам Active Directory, службам Active Directory облегченного доступа к каталогу и реестру Windows. Посредством включения аудита успехов или сбоев на подкатегориях «Реестр» или «Изменения в службе каталогов» и установки связанных списков SACL в журнал событий будут записаны подробные события для действий на этих объектах: Это можно сделать, используя следующие команды auditpol:

auditpol /set /subcategory:"Registry" /success:enable  auditpol /set /subcategory:"Directory Service           Changes" /success:enable 

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

Рис. 4 До и после изменения в реестре 

Эта функция особенно полезна при попытке отследить изменения на объектах Active Directory. Для изменений в службе каталога эти изменения появляются как пара событий с идентификатором 5136, что показано на Рис. 5. В теле каждого события имеются объект, атрибут и операция службы каталога. Для изменений атрибутов с существующими данными можно увидеть две операции: Value Deleted («Значение удалено») и Value Added («Значение добавлено»). Для атрибутов, не содержавших значения, можно увидеть только операцию Value Added при записи данных в этот атрибут. Например, при успешном выполнении операции изменения на атрибуте или объекте пользователя, таком как telephoneNumber, Active Directory записывает в подробных записях журнала предыдущее и текущее значения атрибута.

Рис. 5 До и после события изменения службы каталога 

Если создан новый объект, то записываются в журнал значения атрибутов, заполненные во время его создания. Если объект перемещен внутри домена, записываются его старое и новое местоположения (в форме различающегося имени). Эта возможность «старое и новое» включается по умолчанию при установке соответствующих параметров политики аудита. Если существует атрибут, который необходимо сохранить закрытым, такой как изменения идентификационного номера сотрудника, то можно специально исключать атрибуты посредством простого изменения в схеме. Если изменить свойство searchFlags атрибута в схеме на 0x100 (значение 256 -NEVER_AUDIT_VALUE), как показано на Рис. 6, событие изменения служб каталога не возникнет в случае изменений в этом атрибуте.

Рис. 6 Исключение атрибута из изменения в службе каталога 

Наконец, в Windows Eventing 6.0 есть еще одна выдающаяся новая возможность – подписка на события. Как упоминалось ранее, доступ к журналу событий и его просмотр являются ключевыми задачами системного администрирования. Новая возможность подписки на события предоставляет способ пересылать события напрямую между системами. Подписка на события состоит из службы сбора событий и службы источников событий, настроенной на направление событий указанным узлам. Способность получения событий предоставляется службой сбора событий Windows (новой для Windows Eventing 6.0), а функции подписки встроены в службу журнала событий Windows. Службу сбора можно настроить на сбор событий из многих источников, которыми могут быть системы Windows Server 2008 или Windows Vista.

Все данные, собранные из источников событий, находятся в отдельном журнале событий, именуемом «Пересланные события» (ForwardedEvents.evtx) и управляются службой журнала событий на службе сбора. Настройка обеих конечных точек (служб источника и сбора) необходима и может быть автоматизирована (winrm quickconfig –q на источнике; wecutil qc /q на сборщике). Важно отметить, что эта возможность подписки на события не была разработана для предприятий или для замены систем, доставляющих события внешней базе данных.

Один из примеров ситуации, где удобно использовать эту возможность, – небольшая веб-ферма. Предположим, что имеется небольшой набор систем, связанных с определенным веб-узлом (включая веб-серверы и серверы SQL). Эти системы могут консолидировать свою информацию журнала событий безопасности, используя новую функцию подписки на события. Более крупным средам обычно необходим более широкий набор средств консолидации журнала событий.

Службы ACS

Если учесть все новые возможности Windows Server 2008, реальное решение для долгосрочного управления информацией журнала событий безопасности и ее архивации лежит в создании централизованной базы данных информации аудита. Службы ACS (Audit Collection Services) являются центральным компонентом System Center Operations Manager 2007. ACS предоставляют механизм для пересылки, сбора, хранения и анализа данных событий безопасности. События безопасности собираются почти в реальном времени и сохраняются в центральном репозитории SQL. Службы ACS также дают организациям метод предоставления доступа с минимальными полномочиями к информации аудита, поскольку не требуют физического доступа к системам, подвергающимся аудиту. Давайте рассмотрим, как работают службы ACS.

У ACS имеются три основных компонента. В—первых, служба пересылки, являющаяся частью агента диспетчера операций, передающей данные журнала событий от клиента инфраструктуре служб ACS. Служба пересылки передает данные второму компоненту, службе сбора, являющейся прослушивателем на стороне сервера. Службы пересылки ACS подключаются через порт 51909 TCP для безопасного сообщения с назначенной им службой сбора. Перед пересылкой данные журнала событий нормализуются в XML, что значит избавление от лишней информации и сведение информации о событии в размеченные поля, основанные на заголовке конкретного события и информации в его теле. После того, как информация достигает службы сбора, она отсылается третьему и последнему компоненту – базе данных служб ACS. Она становится хранилищем для долговременного хранения информации о событиях безопасности. Сохраненную информацию можно извлекать напрямую через запросы SQL или визуализировать при помощи отчетов HTML, использующих службы отчетов SQL Server®. Службы ACS предоставляют три представления по умолчанию, как показано на Рис. 7.

 Рис. 7 Представления ACS

Имя представления ACS	Цель
AdtServer.dvHeader	Информация заголовков с собранных событий.
AdtServer.dvAll	Информация заголовков и вся информация тел собранных событий.
AdtServer.dvAll5	Информация заголовков и первые пять строк информации тел собранных событий.

С точки зрения производительности, единственная служба сбора ACS может обработать максимум 100 000 событий в секунду на пике и 2 500 событий в секунду постоянно. С точки зрения планирования, единственная служба сбора ACS может поддерживать до 150 контроллеров доменов, 3000 серверов доменов или 20 000 рабочих станций, основываясь на параметрах политики аудита по умолчанию. В одном из реально протестированных случаев около 150 контроллеров домена продемонстрировали максимум в примерно 140 событий в секунду с пиковым средним значением 500 000 событий в час. Всего лишь за 14 дней (время сохранения по умолчанию для служб ACS) в базе данных SQL Server было сохранено свыше 150 ГБ данных событий безопасности. Более агрессивная политика аудита и связанная с ней настройки SACL, будут, естественно, создавать еще больше данных (в час, в день и в целом).

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

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

Возьмем следующий случай: из-за важности внешних доверий в среде руководство затребовало разработку отчета, подробно излагающего создание доверий Active Directory. После небольшого исследования отдел ИТ выясняет, что объект trustedDomain создается в контейнере cn=System внутри определенного контекста именования домена в Active Directory при создании доверия. После изменения списка SACL на этом контейнере для проведения аудита успешного создания любого объекта доверенного домена мы получаем возможность фиксировать события безопасности при каждом создании объекта этого типа. Это обрабатывается в событии 566 в журнале событий безопасности на DC, где было выполнено создание доверия. Теперь можно написать простой запрос SQL для извлечения этой информации из служб ACS:

select * from AdtServer.dvAll   where EventID = '566' and  String05 like '%trustedDomain%'  order by CreationTime desc 

Чтобы внести это в отчет, используйте версию Visual Studio® 2005, входящую в состав служб отчетов SQL Server 2005 специально для создания отчетов. После завершения работы мастера создавать отчеты, подобные показанному на Рис. 8, будет просто. Более того, любое изменение в среде, которое может быть представлено в журнале событий безопасности, может быть сведено в подобный красивый отчет.

Рис. 8 Пример отчета служб ACS 

Разработка плана аудита

Теперь, когда задачи и проблемы аудита, а также его технические и юридические аспекты понятны, встает вопрос: как администраторам ИТ следует подходить к разработке «плана аудита» для своей организации? Подобно большинству процессов, процесс разработки всеохватывающей политики аудита является многоэтапным. Первый этап – определение того, что следует подвергнуть аудиту. В него входит анализ среды и определение типов событий и изменений, которые должны вызывать аудит. Сюда могут входить простые элементы, такие как блокировка учетных записей, изменения важных групп, создания доверий; либо сложные изменения, такие как изменение элементов настройки внутри приложений в среде. Крайне важно, чтобы руководство организации участвовало в определении того, что должен охватывать план аудита. Это необходимо делать на бумаге и повторять через регулярные промежутки времени – а не только после значительных происшествий.

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

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

Все это приводит к четвертому и последнему этапу – сбору, триггерам и анализу. В зависимости от размера и потребностей организации с этим могут справиться встроенные возможности Windows Server 2008 или расширенные решения, такие как функции служб ACS в System Center Operations Manager. Обычной ошибкой большинства организаций является установка политики аудита без определения SACL. Последний этап целиком связан с реализацией технологического решения для отчетов и обмена данными с заинтересованными пользователями внутри организации. Как упомянуто выше, у большинства организаций имеется организованное подразделение, ответственное за безопасность, и план аудита должен быть структуризован с учетом существующих элементов организации, чтобы быть эффективным. Ключевым на этом заключительном этапе является сбор информации и ее представление в осмысленной форме всем ответственным за осознание изменений в среде.

Для большинства организаций ИТ раздумья о всеохватывающем плане аудита отделены от реальной потребности в нем всего одной серьезной неприятностью. Windows Server 2008 предоставляет усовершенствованные по сравнению с предыдущими платформами механизмы сбора и анализа данных событий безопасности. Усовершенствованные технологии сбора и отчетов, такие как службы ACS, раскрывают проблемы, ранее скрытые объемом событий и распределением, делая эти изменения немедленно очевидными.

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