Аудит изменений прав доступа для учетных записей пользователей и групп
Аудит основных действий по управлению учетными записями пользователей и групп играет важную роль в общей стратегии защиты корпоративных данных. Необходимость отслеживания изменений в свойствах объектов — пользователей и групп — очевидна. Например, если атакующему удастся преодолеть все рубежи защиты, мониторинг изменений объектов остается последней мерой, которая позволяет оценить нанесенный ущерб и определить, какая именно часть системы или сети подверглась нападению. Если на компанию распространяются новые требования государственного регулирования и законодательные акты типа Health Insurance Portability and Accountability Act (HIPAA), Gramm Leach Bliley Act (GLBA) и Sarbanes-Oxley Act (SOX), мониторинг является одним из ключевых предписаний. Кроме того, мониторинг — единственное средство противодействия злонамеренным действиям самих администраторов компании. Наконец, если вы решили воспользоваться заложенными в AD средствами делегирования полномочий, аудит администрирования учетных записей — единственное, что поможет сохранить сведения об изменениях полномочий администраторов различных уровней.
Журнал безопасности Windows Server 2003 содержит две категории событий, позволяющих выполнять мониторинг изменений, касающихся учетных записей пользователей и групп, — это Directory Service Access и Account Management. Directory Service Access предоставляет детализированную низкоуровневую информацию, а Account Management предоставляет менее детализированные сведения о событиях более высокого уровня. Обе категории событий дают ценную информацию, но для отслеживания изменений пользователей и групп роль категории Account Management невозможно переоценить. Account Management предоставляет необходимые для аудита данные в форме идентификаторов событий, возникающих при изменениях учетных записей пользователей, групп и компьютеров. События Directory Service Access более подробно будут рассмотрены в следующей статье. Здесь же мы разберем, как использовать Account Management для построения системы аудита действий с учетными записями пользователей и групп.
Начнем...
Управление учетными записями (Account Management) использует ID различных событий для создания, удаления, а также любых изменений объектов пользователей и групп (эти ID перечислены в табл. 1). Для настройки ведения журнала событий управления учетными записями необходимо включить политику аудита управления учетными записями (Audit Account Management). Это можно сделать на локальном компьютере с помощью оснастки MMC Local Security Policy или же с помощью объекта групповых политик в AD для группы компьютеров.
Следует иметь в виду, что аудит управления учетными записями Audit Account Management можно включить для контроллеров доменов, серверов и рабочих станций. Для контроллеров доменов Account Management отслеживает события, связанные с изменениями учетных записей компьютеров, пользователей домена и групп в AD. При этом, если в домене имеется несколько контроллеров, события регистрируются только на том контроллере, на котором они были выполнены; когда изменения реплицируются на другие контроллеры домена, данные события не будут регистрироваться в журналах на этих серверах. Изменения, касающиеся локальных пользователей и локальных групп на серверах домена и рабочих станциях, регистрируются только в базах SAM этих компьютеров. Хотя основная часть действий, связанных с мониторингом, относится именно к мониторингу изменений учетных записей пользователей домена, полноценная система аудита должна охватывать и локальные изменения на серверах и рабочих станциях домена. Самый распространенный метод атаки заключается в том, что в SAM компьютера создается локальная учетная запись, которая включается в локальную группу администраторов, после чего злоумышленник может получить доступ ко всем ресурсам компьютера.
Мониторинг изменений пользовательских учетных записей
При создании учетной записи пользователя Windows сохраняет в журнале событие с ID 624 (см. экран 1). Из приведенного на экране 1 описания события видно, что пользователь The Architect создал новую учетную запись для пользователя AgentSmith. Поле Caller logon ID содержит число, соответствующее идентификатору регистрации в сети пользователя The Architect при регистрации на контроллере домена, которое фиксируется событиями с ID 528 или ID 540. В разделе Attributes перечислены некоторые атрибуты учетной записи, указанные при ее создании. Причем изначально в момент создания учетная запись заблокирована, как видно в разделе User Account Control. Однако, если продолжить просмотр журнала Security, вскоре после этого события с ID 624 увидим несколько событий с ID 642, одно из которых представлено на экране 2. При рассмотрении раздела User Account Control этого события видно, что учетная запись AgentSmith разблокирована.
Зачем потребовалось событие с ID 642? Когда администратор создает учетную запись пользователя в Windows 2003, а затем выполняет настройку различных атрибутов с помощью мастера New Object User, в журнал сохраняется серия событий с ID 624. Список атрибутов для событий с ID 624 и ID 642 соответствует атрибутам учетной записи SAM (большинство этих атрибутов можно видеть на вкладке Account диалогового окна свойств учетной записи пользователя), но не включает дополнительных атрибутов объекта «пользователь» в AD. В AD все атрибуты и операции, поддерживаемые записью SAM, преобразовываются в эквивалентные им записи LDAP. Для большинства задач обеспечения безопасности мониторинга учетных записей пользователей на уровне SAM вполне достаточно.
Для некоторых типов изменения свойств учетных записей пользователей Windows 2003 сохраняет в журнале события, указывающие на вид изменения. Например, при снятии блокировки (enable) пользовательской учетной записи Windows 2003 сохраняет событие с идентификатором ID 626 (список событий представлен в табл. 2). Список событий изменения свойств учетных записей пользователей в Windows 2003 был значительно изменен по сравнению с Windows 2000. Обратите внимание на разделение событий с ID 627 (смена пароля) и с ID 628 (сброс пароля). Когда пользователь самостоятельно изменяет свой пароль, Windows запрашивает ввод старого пароля, что гарантирует аутентичность пользователя. В этом случае речь идет об изменении пароля. Когда изменение пароля для пользователя выполняет администратор, система регистрирует сброс пароля — в этом отношении Windows 2003 предоставляет более точные сведения для аудита, чем Windows 2000.
В заключение следует разобраться, какая связь существует между событием с ID 642 и событиями, приведенными в табл. 2. Событие с ID 642 происходит при каждом изменении учетной записи пользователя. Для некоторых типов изменений учетной записи в непосредственной близости от события с ID 642 в журнале будут фигурировать дополнительные события, перечисленные в табл. 2. Для мониторинга изменений, которые фиксируются в журнале безопасности Windows 2003, гораздо проще отслеживать появление в журнале определенных идентификаторов событий, чем настраивать систему отчетов либо генерации предупреждений или анализировать текстовые строки внутри записи события с ID 642.
Мониторинг изменения учетных записей групп
Доменные группы в AD определяются двумя характеристиками: типом и областью действия (scope). Тип определяет, является ли группа группой рассылки или же группой безопасности. Область действия определяет, каким образом группа может использоваться. Группы рассылки предназначены для использования почтовым сервером Exchange Server 2000 и более поздними версиями и не имеют настроек безопасности. Группы рассылки не могут использоваться в списках контроля доступа ACL и других настройках, связанных с управлением безопасностью и правами доступа. Группы безопасности применяются для определения разрешений доступа к файлам и другим ресурсам, при этом, если разрешено использование группы безопасности в почтовой системе, они могут также выступать в роли списков рассылки Exchange. Область действия определяет, насколько широко в сети группа может использоваться, и ограничивает количество других групп, в которые данная группа может быть добавлена в качестве члена. Универсальным группам может быть предоставлен доступ к объектам на любом компьютере в лесу AD, при этом в них могут быть включены в качестве членов любые пользователи, глобальные и универсальные группы. Глобальным группам может быть предоставлен доступ к любым ресурсам леса AD, но при этом их членами могут быть только пользователи и группы из того же домена, что и сама группа. Доменные локальные группы могут включать пользователей и группы из всего леса, но доступ они предоставляют только к ресурсам своего домена. Windows сохраняет в журнале отдельные события для каждой комбинации типа, области действия и операции. При всех операциях над группами — создании, изменении и удалении — указывается только имя группы и имя выполнившего операцию. При выполнении операций добавления и исключения членов группы в журнале фиксируются имя группы, имена добавленных или удаленных учетных записей и имя выполнившего операцию.
Практические советы и рекомендации
Какие из изменений учетных записей пользователей и групп нужно отслеживать? Из всего списка событий, перечисленных в табл. 1, наибольший интерес представляют изменения пользовательской учетной записи (событие с ID 642), добавление членов в группы безопасности (события с ID 636, 632 и 660) и создание новых учетных записей пользователей (ID 624). Если произошла случайная или умышленная компрометация системы безопасности, на это обязательно укажет одно из перечисленных пяти событий. Как правило, атакующий создает для себя новую учетную запись или разблокирует и предоставляет дополнительные права какой-либо из существующих учетных записей. Поскольку доступ к информационным ресурсам обычно осуществляется через групповые разрешения, мониторинг включения новых пользователей в группу является основным способом отслеживания изменений прав доступа и необходим для обеспечения требований информационной безопасности.
Я советую включить аудит управления учетными записями для всех компьютеров в домене. Мониторинг каких изменений необходим и на что следует обращать внимание в первую очередь? Если для мониторинга системных журналов используются сценарии собственной разработки или инструментальные средства от независимых разработчиков, можно настроить периодическое формирование отчетов, а также генерацию предупреждений системы безопасности практически в режиме реального времени для особо важных событий, которые происходят редко и могут с высокой вероятностью свидетельствовать о потенциальной бреши. Для менее подозрительных событий можно использовать ежедневные, еженедельные и ежемесячные отчеты. Ежедневные отчеты и экстренные предупреждения можно настроить на активацию учетной записи и изменение членства в привилегированных группах, таких как Administrators, Domain Admins, Account Operators, Backup Operators, Server Operators, Power Users, а также в других важных группах, специфичных для конкретной сети. Если компания достаточно мала, а изменения редки, она может позволить себе ежедневный мониторинг создания новых пользовательских учетных записей вместо более редкого анализа отчетов.
По возможности надо отслеживать создание новых учетных записей и изменение членства в группах на серверах, входящих в домен. Следуя лучшим методам, необходимо всячески минимизировать применение локальных пользовательских учетных записей, групп и операций с локальными базами SAM. Если система обнаруживает появление новой локальной пользовательской учетной записи или изменение членства в локальной группе, администратор должен иметь возможность сразу узнать об этом.
Если в компании имеется служба поддержки, которая выполняет такие рутинные операции, как сброс забытых паролей, необходимо убедиться, что аудит подобного рода событий включен. Нужно взять себе за правило регулярно выполнять выборочные проверки соответствия событий в журнале Security документации, которую ведут сотрудники службы поддержки. Кстати, они должны знать, что такие проверки ведутся регулярно, — это заставит их воздержаться от соблазна использовать служебное положение в предосудительных целях.
События категории Account Management позволяют поставить изменения, произошедшие в пользовательских учетных записях и группах, в соответствие официально зарегистрированным журнальным записям и проверить правомочность действий персонала и наличие согласования у соответствующих руководителей. В роли журнальных записей могут выступать протоколы программ службы поддержки или же архивы сообщений электронной почты с запросами менеджеров на создание учетных записей для новых сотрудников. В одной из небольших компаний, с которой мне довелось работать, в качестве такого журнала использовалась дискуссия в Windows SharePoint под названием Account and Access Requests. При этом все запросы на изменение прав должны были подтверждаться менеджерами компании. Менеджерам поступали уведомления о запросах на изменение прав, и все, что от них требовалось, — перейти по ссылке в электронной почте и ответить «Подтверждаю».
Я нашел, где можно купить ювелирные изделия недорого!
Легендарный компьютер Apple для вашего дома
Весна на дворе! Посмотрите, сколько положительных эмоций вызывает фотография, размещенная в интересном дружелюбном блоге - скоро и у нас будет такая травка.
