Иногда бывает необходимо понять кто удалил/изменил/переименовал конкретный файл или папку. В ОС Windows для этого используется аудит доступа к объектам.
Аудит это запись в специальные журналы информации об определенных событиях (источник, код события, успешность, объект и т.д. ). Объектом аудита может являться как любой файл или папка, так и определенное событие, например вход в систему или выход из нее, то есть можно записывать все события происходящие с конкретным файлом или папкой — чтение, запись, удаление и т.д., можно события входа в систему и т.д.
Необходимо понимать, что аудит забирает на себя.
Для того, чтобы можно было настраивать аудит файлов и папок необходимо предварительно включить эту возможность через локальные (или в случае если у Вас используется Microsoft AD групповые) политики безопасности.
В случае локальных политик необходимо запустить оснастку “Локальная политика безопасности”, для этого необходимо нажать комбинацию клавиш Win+R, в открывшееся поле ввести secpol.msc и нажать клавишу Enter.
В открывшейся оснастке в дереве слева необходимо перейти в раздел “Локальные политики” — “Политика аудита”.
Далее необходимо выбрать необходимую нам политику — в данном случае это “Аудит доступа к объектам”. Именно этой политикой регулируется доступ к объектам файловой системы (файлам и папкам) и раскрыть ее двойным щелчком мыши. В открывшемся окне необходимо выбрать какие именно типы событий будут регистрироваться — “Успех” (разрешение на операцию получено) и/или “Отказ” — запрет операции и проставить соответствующие галочки, после чего нажать “Ок”.
Теперь когда включена возможность ведения аудита интересующих нас событий и их тип можно переходить к настройке самих объектов — в нашем случае файлов и папок.
Для этого необходимо открыть свойства файла или папки, перейти на вкладку “Безопасность”, нажать “Дополнительно” и “Аудит”.
Нажимаем “Добавить” и начинаем настраивать аудит.
Сначала выбираем субъект — это чьи действия будут аудироваться (записываться в журнал аудита).
Можно вписать туда имя пользователя или группы, если имя заранее неизвестно, то можно воспользоваться кнопкой “Дополнительно” которая открывает форму поиска где можно выбрать интересующих нас пользователей и группы. Чтобы контролировались действия всех пользователей необходимо выбрать группу “Все”.
Далее необходимо настроить тип аудируемых событий (Успех, Отказ, Все), также область область применения для аудита папок — только эта папка, папка с подпапками, только подпапки. только файлы и т.д., а также сами события аудита.
Для папок поля такие:
А такие для файлов:
После этого начнется сбор данных аудита. Все события аудита пишутся в журнал “Безопасность”. Открыть его проще всего через оснастку “Управление компьютером” compmgmt.msc.
В дереве слева выбрать “Просмотр событий” — “Журналы Windows” — “Безопасность”.
Каждое событие ОС Windows имеет свой код события. Список событий достаточно обширен и доступен на сайте Microsoft либо в интернете.
Попробуем например найти событие удаления файла, для этого удалим файл на котором предварительно настроен аудит (если это не тестовые файл, то не забываем сделать его копию, так как аудит это всего лишь информация о действиях, а не разрешение/запрет этих действий). Нам нужно событие с кодом 4663 — получение доступа к объекту, у которого в поле Операции доступа Написано “DELETE” . Поиск событий в журналах Windows достаточно сложен, поэтому обычно используются специализированные средства анализа — системы мониторинга, скрипты и т.д.
Вручную можно, например, задать например такой фильтр:
Далее в отфильтрованных событиях необходимо найти интересующее нас по имени объекта.
Открыть его двойным щелчком мыши и увидеть кто удалил данный файл в поле субъект.
На этом демонстрация аудита доступа к файлам и папкам Windows на примере Windows server 2012R2 окончена. В нашей базе знаний вы найдёте ещё множество статей посвящённых различным аспектам работы в Windows, а если вы ищете надежный виртуальный сервер под управлением Windows, обратите внимания на нашу услугу — Аренда виртуального сервера Windows.
Опубликовано: 18.09.2016
Запускаем редактор групповых политик
Для этого в Windows 10 или Server 2012 R2 кликаем правой кнопкой мыши по Пуск и нажимаем Панель управления:
В более ранних версиях Windows кликаем по Пуск и выбираем Панель управления:
Теперь открываем Система и безопасность:
Администрирование:
И выбираем Локальная политика безопасности:
* Совет: редактор групповых политик можно открыть через командную строку командой gpedit.msc.
* Нюанс: в доменной среде с сервером Active Directory необходимо открывать групповые политики на стороне контроллера домена и применять их к серверам или компьютерам компании.
Настраиваем политику
Раскрываем Конфигурация компьютера — Конфигурация Windows — Параметры безопасности — Локальные политики — Политика аудита:
В окне справа кликаем дважды по Аудит доступа к объектам:
В открывшемся окне ставим галочки на Успех и Отказ:
Нажимаем OK и закрываем редактор управления групповыми политиками.
Настраиваем аудит для файлов и папок
Кликаем правой кнопкой мыши по папке, для которой нужно настроить аудит и выбираем Свойства:
Переходим на вкладку Безопасность:
Нажимаем по Дополнительно:
В открывшемся окне переходим на вкладку Аудит и нажимаем Продолжить:
Кликаем Добавить:
Кликаем по Выберите субьект:
и выбираем учетную запись или группу пользователей, для которых необходимо установить аудит, например, все:
Нажимаем OK и выставляем галочки напротив действий, для которых система будет протоколировать события:
Нажимаем OK три раза.
Была ли полезна вам эта инструкция?
Да Нет
Мы продолжаем перевод и публикацию материалов, связанных с Windows Server 2012 и обновлениями штатных систем аудита Microsoft. Приглашаем заинтересованных читателей ознакомиться с рассказом сотрудника команды Windows Server о новых возможностях Dynamic Access Control.
Здравствуйте, меня зовут Nir Ben-Zvi, я работаю в команде Windows Server. Я рад представить вам сегодня новый набор функций для Динамического контроля доступом (Dynamic Access Control), который имеется в Windows Server 2012.
Сначала я вкратце расскажу о процессе планирования, затем мы рассмотрим новую модель политики центрального доступа (Central Access Policy) и опишем что нового в Файловом Сервере, решении, которое мы встроили в Windows Server 2012. Я также вопросов постепенного внедрения, так чтобы Вам не нужно было перемещать всю среду на Windows Server 2012, если Вам нужно использовать данную функцию. В конце мы рассмотрим вопросы, связанные с тем какие решения наших партнеров помогут расширить предлагаемых функционал наших решений.
Введение
В современных (читай: сложных) IT-инфраструктурах создание данных происходит с ошеломляющей скоростью в рассредоточенных системах; одновременно доступ к этим данным осуществляется с многочисленных устройств. Выполнение требований нормативов по информационной безопасности и потребность в защите конфиденциальной информации от утечек – одни из важнейших проблем для бизнеса и IT. Чтобы эти проблемы были успешно решены – необходимо контролировать, кто получил доступ к определенной информации, причем желательно, чтобы желательно, чтобы при осуществлении такого контроля информация о доступе была представлена максимально наглядно.
Мы были в курсе этим проблем, стоящих перед бизнесом и IT уже пару лет назад, когда планировали, каким будет Windows Server 2012. Вот только несколько часто встречающихся запросов со стороны наших клиентов:
• Централизованное управление доступом к информации как на основе запросов бизнеса, так и с целью выполнения требований нормативов
• Должен осуществляться аудит доступа к информации для целей анализа и выполнения требований нормативов по ИБ
• Конфиденциальная информация должна быть защищена
• Владельцы контента должны быть ответственны за свою информацию – администраторы не должны заниматься не своей работой
• Ключевым аспектом является поддержание продуктивности деятельности специалистов, работающих с информацией
Мы взглянули на отдельные должностные позиции в организации и их взаимодействие в процессе выполнения запросов со стороны бизнеса, и регулирующих органов, чтобы представить адекватный запросам набор технологий и решений.
Таким образом, список должностей, вовлеченных в решение обозначенных проблем, начинается с CSO/CIO, который определяет потребности с позиций бизнеса и выполнения требований нормативов. За ними следуют IT-администраторы, которые осуществляют управление системами, и владельцы контента, которые контролируют фактическую информацию. Что касается тех, кто непосредственно работает с информацией, то влияние применяемых решений на них должно быть минимальным (в идеале его не должно быть совсем).
Чтобы помочь организациям выполнить требования нормативов и решить стоящие перед ними бизнес-задачи, мы в конечном итоге, сфокусировались на следующих сферах:
• Определение информации, управление которой должно осуществляться для достижения поставленных целей
• Применение политик доступа к информации
• Аудит доступа к информации
• Шифрование информации
Эти задачи были переведены в набор функций Windows, которые делают возможным защиту данных с помощью решений Windows и решений партнеров.
• Добавлена возможность конфигурировать в Active Directory централизованный доступ (Central Access) и политики аудита. Эти политики основаны на условных требованиях (см. ниже); при этом могут быть значительно снижено число групп безопасности для контроля доступа:
o Кем является пользователь
o Какое устройство он использует
o К каким данным получен доступ
• Заявки (claims) интегрированы в аутентификацию Windows (Kerberos), так что пользователи и устройства могут быть описаны не только посредством групп безопасности, в которых они состоят, но также и по заявкам, например: “Пользователь из Отдела финансов”, и “Категория доступа (security clearance) пользователя высокая”.
• Улучшена инфраструктура классификации файлов (File Classification Infrastructure), что позволит владельцам контента и пользователям идентифицировать (присваивать теги) их данные, так что IT-администраторы могут создавать целевые политики, основываясь на этих тегах. Эта возможность работает наряду с возможностью инфраструктуры классификации файлов автоматически классифицировать файлы на основании их содержимого или других характеристик.
• Интегрированы службы управления правами (Rights Management Services), чтобы автоматически защищать (шифровать) конфиденциальную информацию на серверах, так что даже тогда, когда она покидает сервер, она защищена.
Политики центрального доступа
Политики центрального доступа можно сравнить со страховкой, которую организация применяют на своих серверах. Эти политики улучшают (но не заменяют) политику локального доступа (например, дискреционный ACL), которая применяются к информации. Например, если локальный DACL файла разрешает доступ определенному пользователю, но Центральная политика запрещает доступ этому же пользователю, то он не сможет получить доступ к файлу (и наоборот).
Инициатива по внедрению и усилению политики центрального доступа произрастает из различных причин и из различных уровней организации:
• Политика, связанная с выполнением требований нормативов: Эта политика соотносится с требованиями нормативов и бизнеса и нацелена на защиту правильного (адекватно установленного) доступа к информации, управление которой осуществляется. Например, дать доступ к информации, которая подпадает под регулирующие документы “US-EU Safe Harbor”, только определенной группе пользователей.
• Политика разрешений на уровне отделов: Каждый отдел в организации имеет определенные требования к работе с данными, которые бы они хотели бы защитить (укрепить). Такая ситуация часто встречается в организациях с разветвленной организационной структурой. Например, отдел финансов хочет ограничить доступ к финансовой информации только для финансовых работников.
• Политика “необходимо знать” (Need to know policy): Эта политика гарантирует, что доступ допускается только тем, кому “необходимо знать”. Например:
o Вендоры должны получать доступ к информации и редактировать только файлы, которые относятся к проектам, над которым они работают.
o В финансовых учреждениях “стены” между информацией важны, например, аналитики не должны получать доступ к брокерской информации, а брокеры – к аналитической.
Политики центрального аудита
Политика центрального аудита (Central Audit Policy) – мощный инструмент, который позволяют поддерживать безопасность организации. Одной из ключевых целей аудита безопасности является выполнение требований нормативов по информационной безопасности. Отраслевые стандарты, такие как SOX, HIPPA, PCI и другие требуют от организаций следовать жестко установленному набору правил, связанных с информационной безопасностью и конфиденциальностью данных (privacy). Работа аудиторов заключается в том, чтобы установить наличие (или отсутствие) таких политик, тем самым доказывается выполнение (или не выполнение) требований этих стандартов. Вдобавок, аудит безопасности позволяют фиксировать аномальное поведение, определять и избегать образования дыр в системе безопасности и ограничивать несанкционированное поведение – любая важная деятельность пользователей записывается, а такие записи могут быть использованы при проведении расследования.
Windows Server 2012 позволяет администраторам разрабатывать политики аудита, используя выражения, которые принимают во внимание то, к какой информации пользователи получают доступ и кем эти пользователи являются, так что организация может осуществлять аудит доступа только к определенной информации, вне зависимости от того, где бы они не находилась. Это открывает дорогу к более целевым и в то же время простым в использовании политикам аудита. Теперь можно реализовывать сценарии, которые до настоящего момента было сложно осуществить. Например, Вы можете легко разработать политики аудита, которые перечислены ниже:
• Аудит всех, у которого нет высокой категории допуска и кто, тем не менее, пытается получить доступ к “важной” информации
• Аудит всех вендоров, которые пытаются получить доступ к документам по проектам, над которыми они не работают.
Это помогает регулировать объем событий аудита и ограничивает их только до более важных, так что Вы можете отслеживать доступ к информации на различных серверах без создания огромного количества записей.
В дополнение, тегирование информации записывается в события аудита, так что с помощью механизма сбора событий можно формировать контекстуальные отчеты, например: Кто получил доступ к Важной информации за последние три месяца.
Решение для файлового сервера
Основываясь на подобной инфраструктуре, мы разработали комплексное решение для Windows Server 2012 Active Directory, Windows Server 2012 File Server и Windows 8 client. Это решение позволяет вам:
• Идентифицировать данные, используя автоматическую и ручную классификацию файлов.
• Контролировать доступ к файлам по всем серверам, применяя гарантию (safety net) политик центрального доступа. Например, Вы можете контролировать, кто получает информацию о здоровье сети по всей организации.
• Аудит доступа к файлам на файловых серверах, используют политики центрального аудита для целей выполнения нормативов по информационной безопасности и проведения расследований. Например, Вы можете определить, кто получил доступ к высоко конфиденциальной информации за последние три месяца.
• Шифрование данных посредством автоматического применения шифрования служб управления правами (Rights Management Services (RMS)) для конфиденциальных документов. Например, Вы можете настроить RMS на шифрование всех документов, которые содержат информацию, защищаемую нормативом HIPAA.
Для того чтобы поддержать внедрение на множестве файловых серверов в организации, мы также предоставляем Data Classification Toolkit, который позволяет осуществлять настройку и формирования отчетов среди многочисленных серверов.
Бета-версию Data Classification Toolkit можно скачать здесь.
Концепция постепенного внедрения
Одним из ключевых принципов разработки DAC является постепенные внедрения. Вы можете начать использовать эту функцию, как только у Вас возникнет потребность решать задачи, стоящие перед Вашей компанией в части аудита файловых серверов и доступа к информации.
Вы можете использовать большинство из возможностей Dynamic Access Control в файловом сервере Windows Server 2012 и обновленной схеме домена Active Directory. Добавление минимального числа контроллеров доменов Windows Server 2012 позволить включить пользовательские заявки и т.д. Каждая часть системы, которую Вы обновите, даст Вам больше возможностей, однако задавать скорость внедрения – это уже на ваше усмотрение.
Решения партнеров
Решения партнеров и ряд бизнес приложений может повысить эффективность использования инвестиций в инфраструктуру Windows для Dynamic Access Control, обеспечивая ценность для организаций, использующих Active Directory. Вот лишь некоторые примеры партнерских решений, которые представляли на конференции в прошлом году:
• Интеграция систем предотвращения утечки данных (Data Leakage Prevention) с системой автоматической классификации содержимого
• Централизованный анализ данных аудита
• Авторизация служб управления правами (Rights Management Services) с использованием Central Access Policies
• Многие другие…
via Technet
As per Spiceworks Virtualization Trends for 2016, Windows Server 2012 has been one of the most widely deployed servers around the globe for supporting collaborative work environments. Because of the intrinsic nature of these kinds of environments, where multiple users have access to the same resources, fixing responsibility for user actions becomes very important.
Thus, it is important to audit all user actions concerning files and folders access. In this article, the process of enabling files and folders auditing on Windows Server 2012 has been explained.
On Windows Server 2012, auditing file and folder accesses consists of two parts:
- Enable File and Folder auditing which can be done in two ways:
- Through Group Policy (for Domains, Sites and Organizational Units)
- Local Security policy (for specific folder)
- Configure audit settings for File and Folders
This article will cover the process of enabling auditing for object access on a Windows Server 2012 through Group Policy.
1. Enable Auditing through Group Policy (for Domains, Sites and OUs)
To enable auditing through GPO, follow these steps:
- Go to “Start” ➔ “Control Panel”. In this window, double-click “Administrative Tools”, and then double-click “Group Policy Management” console to open it.
- Go to the concerned domain and expand it as shown in the following figure.
Figure 1: Go to concerned domain and expand the node - Right-click “Group Policy Objects, and click “New”.
Figure 2: Select New from the context menu - In “New GPO” dialog box, enter the name of new GPO and click “OK”.
Figure 3: Enter new GPO’s name - Right-click the newly created GPO and click “Edit” to open “Group Policy Management Editor” window.
Figure 4: GPO management editor - In “Group Policy Management Editor”, go to “Computer Configuration” ➔ “Policies” ➔ “Windows Settings” ➔ “Local Policies”.
- Select “Audit Policies” to view all of its policies in the right panel.
Figure 5: Audit policies - Double-click “Audit Object Access” to access its properties
- Click “Define these Policy Settings” to check its box.
- Check both “Success” and “Failure” boxes.
Figure 6: Configure Audit object access - Click “Apply” and “OK”.
- Execute the following command at “Run” or “Command Prompt” to apply this policy on the domain controller.
gpupdate /force</strong
After the policy has been applied, you can configure audit settings for File and Folders.
2. Enable Auditing of Specific Folder
To select specific folders and define users, follow these steps.
- Select the folder that you want to audit.
- Right-click and click “Properties” to access its properties.
- Go to “Security” tab, and click “Advanced”.
Figure 7: Property sheet of the folder - In “Advanced Security Settings…” dialog box, select “Auditing” tab.
Figure 8: Click the Auditing tab - Click “Add”. “Auditing Entry for…” window appears on the screen.
Figure 9: Auditing Entry for Documents dialog box - Click “Select a principal” link. It shows “Select User…” dialog box.
- Type the name of that user, of which access you want to monitor. Click “Check Names” button to validate its entry. You can repeat this step to provide the names of all users, whose access to the selected folder have to monitored. Alternatively, you can type “Everyone” to monitor every users’ accesses to this folder.
Figure 10: Select User for auditing - Click “OK” once you have made your selection of users. It takes you back to “Auditing Entry” window.
Figure 11: Auditing Entry for Documents settings - Select “Both” in “Type” drop-down menu to monitor both “Success” and “Fail” accesses made to the folder.
- In “Applies to” drop-down menu, select “This folder, subfolders, and files”.
- Select “Full Control” or the appropriate permissions for auditing. It is advised to click “Show Advanced Permissions” and select all permissions.
- You can use “Add a condition” link at the bottom to limit the scope of this auditing entry. You can add multiple conditions, if required. This way the auditing will generate limited logs.
- Click “OK” to save the settings and close “Auditing Entry for …” window.
- Click “Apply” and “OK” to close “Advanced Security Settings for” window.
- Click “OK” to close the folder properties.
View the Record in Event Viewer
After auditing has been enabled, the logged events can be viewed in Event Viewer. The following image shows the logged event for a file access.
How Lepide File Server Auditor helps with File and Folder Access Auditing
The Lepide File Server Auditor enables you to easily track any modifications being made to File Server, including files and folders themselves. You can track file copy events, file read attempts, file modifications, moves, creations, deletions and more with just the click of a button. You can also track whenever users attempt to read files (both successfully and failed attempts).
These reports take seconds to generate and provide all the critical file server auditing information that you need to detect potential threats or unwanted changes being made.
Conclusion:
In this article, we have gone through the native process for configuring file and folder auditing. We have also shown you how much better our Lepide File Server Auditor (part of Lepide Data Security Platform) is at doing the same job. Given the importance of security and compliance, it obvious that a specialized solution like Lepide’s File Server auditing software should be given preference over native auditing.
Download Lepide File Server Auditor
Как включить аудит доступа к файлам Windows в картинках
Запускаем редактор групповых политик
Для этого в Windows 10 или Server 2012 R2 кликаем правой кнопкой мыши по Пуск и нажимаем Панель управления:
В более ранних версиях Windows кликаем по Пуск и выбираем Панель управления:
Теперь открываем Система и безопасность:
И выбираем Локальная политика безопасности:
* Совет: редактор групповых политик можно открыть через командную строку командой gpedit.msc.
* Нюанс: в доменной среде с сервером Active Directory необходимо открывать групповые политики на стороне контроллера домена и применять их к серверам или компьютерам компании.
Настраиваем политику
Раскрываем Конфигурация компьютера — Конфигурация Windows — Параметры безопасности — Локальные политики — Политика аудита:
В окне справа кликаем дважды по Аудит доступа к объектам:
В открывшемся окне ставим галочки на Успех и Отказ:
Нажимаем OK и закрываем редактор управления групповыми политиками.
Настраиваем аудит для файлов и папок
Кликаем правой кнопкой мыши по папке, для которой нужно настроить аудит и выбираем Свойства:
Переходим на вкладку Безопасность:
Нажимаем по Дополнительно:
В открывшемся окне переходим на вкладку Аудит и нажимаем Продолжить:
Кликаем по Выберите субьект:
и выбираем учетную запись или группу пользователей, для которых необходимо установить аудит, например, все:
Нажимаем OK и выставляем галочки напротив действий, для которых система будет протоколировать события:
Источник
План аудита доступа к файлам Plan for File Access Auditing
Область применения. Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
В этом разделе описываются усовершенствования аудита безопасности, появившиеся в Windows Server 2012, и новые параметры аудита, которые следует учитывать при развертывании динамического контроля доступа на предприятии. The information in this topic explains the security auditing enhancements that are introduced in Windows Server 2012 and new audit settings that you should consider as you deploy Dynamic Access Control in your enterprise. Фактические параметры политики аудита будут зависеть от поставленных целей, которые могут включать проверку соответствия нормативным требованиям, наблюдение, криминалистический анализ и устранение неисправностей. The actual audit policy settings that you deploy will depend on your goals, which can include regulatory compliance, monitoring, forensic analysis, and troubleshooting.
Для получения подробной информации о планировании и развертывании общей стратегии аудита безопасности предприятия см. статью Планирование и развертывание расширенных политик аудита безопасности. Detailed information about how to plan and deploy an overall security auditing strategy for your enterprise is explained in Planning and Deploying Advanced Security Audit Policies. Для получения дополнительной информации о настройке и развертывании политики аудита безопасности см. Пошаговое руководство по расширенной политике аудита безопасности. For more information about configuring and deploying a security audit policy, see the Advanced Security Audit Policy Step-by-Step Guide.
Следующие возможности аудита безопасности в Windows Server 2012 можно использовать с динамическим контролем доступа для расширения общей стратегии аудита безопасности. The following security auditing capabilities in Windows Server 2012 can be used with Dynamic Access Control to extend your overall security auditing strategy.
Политики аудита на основе выражений. Expression-based audit policies. Динамический контроль доступа позволяет создавать адресные политики аудита, используя выражения на основе требований пользователя, компьютера и ресурсов. Dynamic Access Control enables you to create targeted audit policies by using expressions based on user, computer, and resource claims. Например, можно создать политику аудита для отслеживания всех операций чтения и записи в файлах, которые классифицируются как «оказывающие сильное влияние на бизнес», для сотрудников, не обладающих высокой категорией доступа. For example, you could create an audit policy to track all Read and Write operations on files classified as high-business impact by employees who do not have a high-security clearance. Политики аудита на основе выражений могут быть созданы непосредственно для файла или папки либо централизованно через групповую политику. Expression-based audit policies can be authored directly for a file or folder or centrally through Group Policy. Дополнительные сведения см. в разделе Групповая политика использование аудита доступа к глобальным объектам. For more information, see Group Policy using Global Object Access Auditing.
Дополнительная информация от аудита доступа к объектам. Additional information from object access auditing. Аудит доступа к файлам не является новым для Windows Server 2012. File access auditing is not new to Windows Server 2012 . Если применяется правильная политика аудита, операционные системы Windows и Windows Server будут создавать событие аудита при каждой попытке пользователя получить доступ к файлу. With the right audit policy in place, the Windows and Windows Server operating systems generate an audit event each time a user accesses a file. События доступа к существующим файлам (4656, 4663) содержат сведения об атрибутах файла, к которому был получен доступ. Existing File Access events (4656, 4663) contain information about the attributes of the file that was accessed. Эту информацию могут использовать средства фильтрации журнала событий, чтобы помочь в определении наиболее значимых событий аудита. This information can be used by event log filtering tools to help you identify the most relevant audit events. Дополнительные сведения см. в разделах Аудит работы с дескрипторами и Диспетчер учетных записей безопасности аудита. For more information, see Audit Handle Manipulation and Audit Security Accounts Manager.
Дополнительные сведения о событиях входа пользователя. More information from user logon events. Если применяется правильная политика аудита, операционные системы Windows создают событие аудита при каждом локальном или удаленном входе пользователя в систему. With the right audit policy in place, Windows operating systems generate an audit event every time a user signs in to a computer locally or remotely. В Windows Server 2012 или Windows 8 можно также отслеживать утверждения пользователей и устройств, связанные с маркером безопасности пользователя. In Windows Server 2012 or Windows 8, you can also monitor user and device claims associated with a user’s security token. Например, это могут быть такие категории доступа, как «Отдел», «Организация», «Проект» и «Безопасность». Событие 4626 содержит информацию об этих заявках пользователей и устройств на доступ, что может использоваться в средствах управления журналом аудита, чтобы связать события входа пользователя с событиями доступа к объектам и разрешить фильтрацию событий на основе атрибутов файлов и атрибутов пользователей. Examples can include Department, Company, Project, and Security clearances.Event 4626 contains information about these user claims and device claims, which can be leveraged by audit log management tools to correlate user logon events with object access events to enable event filtering based on file attributes and user attributes. Дополнительные сведения о аудите входа пользователей см. в разделе Аудит входа в систему. For more information about user logon auditing, see Audit Logon.
Отслеживание изменений в новых типах защищаемых объектов. Change tracking for new types of securable objects. В следующих сценариях важно отслеживать изменения в защищаемых объектах. Tracking changes to securable objects can be important in the following scenarios:
Отслеживание изменений в централизованных политиках и правилах доступа. Change tracking for central access policies and central access rules. Централизованные политики и правила доступа определяют централизованную политику, которая может быть использована при управлении доступом к критическим ресурсам. Central access policies and central access rules define the central policy that can be used to control access to critical resources. Любые их изменения могут непосредственно влиять на права доступа к файлам, которые предоставлены пользователям на нескольких компьютерах. Any change to these can directly impact the file access permissions that are granted to users on multiple computers. Поэтому отслеживание изменений в централизованных политиках и правилах доступа может быть важно для организации. Therefore, tracking changes to central access policies and central access rules can be important for your organization. Так как централизованные политики и правила доступа хранятся в доменных службах Active Directory (AD DS), можно проводить аудит попыток их изменения, так же как и проводить аудит изменений любых других защищаемых объектов в доменных службах Active Directory. Because central access policies and central access rules are stored in Active Directory Domain Services (AD DS), you can audit attempts to modify them, like auditing changes to any other securable object in AD DS. Дополнительные сведения см. в разделе Аудит доступа к службе каталогов. For more information, see Audit Directory Service Access.
Отслеживание изменений в определениях словаря утверждений. Change tracking for definitions in the claim dictionary. Определения утверждений включают имя утверждения, описание и возможные значения. Claim definitions include the claim name, description, and possible values. Любые изменения в определении утверждения могут влиять на права доступа к критическим ресурсам. Any change to the claim definition can impact the access permissions on critical resources. Поэтому отслеживание изменений в определениях утверждений может быть важно для организации. Therefore, tracking changes to claim definitions can be important to your organization. Подобно централизованным политикам и правилам доступа, определения утверждений хранятся в доменных службах Active Directory, поэтому для них аудит может быть выполнен так же, как и для других защищаемых объектов в AD DS. Like central access policies and central access rules, claim definitions are stored in AD DS; therefore, they can be audited like any another securable object in AD DS. Дополнительные сведения см. в разделе Аудит доступа к службе каталогов. For more information, see Audit Directory Service Access.
Отслеживание изменений в атрибутах файла. Change tracking for file attributes. Атрибуты файла определяют, какое централизованное правило доступа применяется к этому файлу. File attributes determine which central access rule applies to the file. Изменение атрибутов файла потенциально может влиять на ограничения доступа к файлу. A change to the file attributes can potentially impact the access restrictions on the file. Поэтому важно отслеживать изменения атрибутов файла. Therefore, it can be important to track changes to file attributes. Можно отслеживать изменения атрибутов файла на любом компьютере, настроив политику аудита для изменения политики авторизации. You can track changes to file attributes on any computer by configuring the authorization policy change auditing policy. Дополнительные сведения см. в разделе Аудит изменения политики авторизации и Аудит доступа к объектам для файловых систем. For more information, see Authorization Policy Change auditing and Object Access auditing for File Systems. В Windows Server 2012 событие 4911 отличает изменения политики атрибутов файлов от других событий изменения политики авторизации. In Windows Server 2012 , Event 4911 differentiates file attribute policy changes from other authorization policy change events.
Отслеживание изменений в централизованной политике доступа, связанной с файлом. Chang tracking for the central access policy associated with a file. Событие 4913 отображает идентификаторы безопасности (SID) для старой и новой централизованных политик доступа. Event 4913 displays the security identifiers (SIDs) of the old and new central access policies. Каждая централизованная политика доступа также имеет имя, понятное для пользователя, которое может быть найдено с помощью этого идентификатора безопасности. Each central access policy also has a user friendly name that can be looked up using this security identifier. Дополнительные сведения см. в разделе Аудит изменений политики авторизации. For more information, see Authorization Policy Change auditing.
Отслеживание изменений атрибутов пользователя и компьютера. Change tracking for user and computer attributes. Как и файлы, объекты пользователей и компьютеров могут иметь атрибуты, а изменения этих атрибутов могут повлиять на возможность доступа пользователя к файлам. Like files, user and computer objects can have attributes, and changes to these attributes can impact the user’s ability to access files. Таким образом, важно отслеживать изменения атрибутов пользователя или компьютера. Therefore, it can be valuable to track changes to user or computer attributes. Объект-пользователь и объект-компьютер хранятся в доменных службах Active Directory, следовательно, можно проводить аудит изменения их атрибутов. User and computer objects are stored in AD DS; therefore, changes to their attributes can be audited. Дополнительные сведения см. в разделе доступ к службам каталогов. For more information, see DS Access.
Промежуточное сохранение изменений политики. Policy change staging. Изменения в централизованных политиках доступа могут влиять на решения о предоставлении доступа на всех компьютерах, на которых применяются политики. Changes to central access policies can impact the access control decisions on all computers where the policies are enforced. Нестрогая политика может предоставить больше доступа, чем предполагается, в то время как чрезмерно строгая политика может вызвать огромное количество обращений в службу поддержки. A loose policy could grant more access than desired, and an overly restrictive policy could generate an excessive number of Help Desk calls. Поэтому очень важно проверить изменения централизованной политики доступа до того, как они будут применены. As a result, it can be extremely valuable to verify changes to a central access policy before enforcing the change. Для этой цели в Windows Server 2012 введена концепция «промежуточного хранения». For that purpose, Windows Server 2012 introduces the concept of «staging.» Промежуточное сохранение позволяет пользователям проверить предложенные изменения политики до того, как применить их. Staging enables users to verify their proposed policy changes before enforcing them. Для использования промежуточного сохранения предложенные политики разворачиваются вместе с принятыми политиками, но промежуточные политики фактически не предоставляют доступ и не запрещают его. To use policy staging, proposed policies are deployed with the enforced policies, but staged policies do not actually grant or deny permissions. Вместо этого в Windows Server 2012 регистрируется событие аудита (4818) в любой момент, когда проверка доступа, использующая промежуточную политику, отличается от результата проверки доступа, использующей принудительную политику. Instead, Windows Server 2012 logs an audit event (4818) any time the result of the access check that uses the staged policy is different from the result of an access check that uses the enforced policy.
Источник
С помощью аудита событий доступа к объектам файловой системы вы можете определить конкретного пользователя, который создал, удалил или изменил определенный файл. В этой статье мы покажем, как настроить аудит событий удаления объектов в общей сетевой папке на Windows Server 2016. После настройки аудита, вы можете с помощью информации в журнале событий найти пользователя, который удалил на файловом сервере.
При удалении файла из сетевой папки, он удаляется сразу, а не отправляется в корзину пользователя. Список открытых по сети файлов в сетевой папке можно получить так.
Содержание:
- Включаем политику аудита доступа к файлам и папкам в Windows
- Настройка аудита событий удаления файлов из конкретной папки
- Запись событий удаления файлов в SQL базу (MySQL/MSSQL)
- Запись информации о событиях удаления файлов в текстовый файл
Включаем политику аудита доступа к файлам и папкам в Windows
По умолчанию в Windows Server не включен аудит событий доступа к объектам на файловой системе. Вы можете включить и настроить аудит событий с помощью групповой политики. Если нужно включить политики аудита на нескольких серверах или компьютера, можно использовать доменные GPO (настраиваются с помощью консоли управления gpmc.msc). Если нужно настроить аудит только на одном сервере, можно воспользоваться локальной групповой политикой.
- Запустите консоль редактора локальной политики –
gpedit.msc
; - Перейдитевраздел GPO срасширенными политиками аудита Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Object Access;
- Откройте политику Audit File System и укажите, что вы хотите сохранять в журнал только успешные события доступа к объектам файловой системы (Configure the following audit events -> Success);
Также можно включить аудит доступа к локальным объектам с помощью политики Audit Object Access в разделе Windows Settings -> Security Settings -> Local Policy -> Audit Policy. Однако использование политики Audit File System предпочтительнее, поскольку она отслеживает только события NTFS.
- Сохраните изменения и обновите настройки локальной групповой политики с помощью команды
gpupdate /force
.
Настройка аудита событий удаления файлов из конкретной папки
Теперь нужно настроить аудит в свойствах общей сетевой папки, доступ к которой вы хотите отслеживать. Запустите проводник и откройте свойства общей папки. Перейдите на вкладку Security. Нажмите кнопку Advanced -> вкладка Auditing.
Если появится сообщение You must be an administrator or have been given the appropriate privileges to view the audit properties of this object, нажмите кнопку Continue.
Затем нажмите кнопку Add чтобы указать пользователя или группу, для которых нужно записывать все события аудита. Если вы хотите отслеживать события для всех пользователей, укажите группу Everyone.
Затем нужно указать использование каких разрешений доступа к объекту нужно записывать в лог. Чтобы сохранять в Event Log только события удаления файлов, нажмите кнопку Show advanced permissions. В списке событий оставьте аудит только для событий удаления папок и файлов — Delete и Delete subfolders and files.
Совет. Включение аудита доступа к объектам Windows накладывает дополнительные расходы на ресурсы системы. Всегда старайтесь минимизировать количество объектов и событий аудита, которые нужно отслеживать.
Совет. Вы можете настроить аудит удаления файлов в папке с помощью через PowerShell:
$Path = "D:Public"
$AuditChangesRules = New-Object System.Security.AccessControl.FileSystemAuditRule('Everyone', 'Delete,DeleteSubdirectoriesAndFiles', 'none', 'none', 'Success')
$Acl = Get-Acl -Path $Path
$Acl.AddAuditRule($AuditChangesRules)
Set-Acl -Path $Path -AclObject $Acl
Теперь, если пользователь удалит любой файл или папку в сетевой папке, в журнале безопасности системы появляется событие File System -> Audit Succes c Event ID 4663 от источника Microsoft Windows security auditing.
Откройте mmc консоль Event Viewer (
eventvwr.msc
), разверните секцию Windows Logs -> Security. Включите фильтр событий по EventID 4663.
Откройте любой их оставшихся событий в Event Viewer. Как вы видите, в нем есть информация об имени удаленного файла и учетной записи пользователя, который удалил файл.
An attempt was made to access an object. Subject: Security ID: CORPaaivanov Account Name: aaivanov Account Domain: CORP Logon ID: 0x61B71716 Object: Object Server: Security Object Type: File Object Name: E:DistrBackup.rar Handle ID: 0x7bc4 Resource Attributes: S:AI Process Information: Process ID: 0x4 Process Name: Access Request Information: Accesses: DELETE Access Mask: 0x10000
После настройки аудита, найдите в журнале Security вы сможете найти с:
- Кто и когда удалил файл в сетевой папке;
- Из какого приложения удален файл;
- На какой момент времени нужно восстанавливать бэкап данного каталога.
Запись событий удаления файлов в SQL базу (MySQL/MSSQL)
Если после включения аудита удаления файлов в сетевой папке, вы видите в журнале много событий, найти что-то в логах бывает проблематично. Во-первых, найти нужную запись среди тысячи событий довольно сложно (в Windows отсутствуют вменяемые средства поиска интересующего события с возможностью гибкой фильтрации), а во-вторых, если файл был удален давно, это событие может просто отсутствовать в журнале, т.к. было перезатерто более новыми.
Вы можете записывать все нужные событий в отдельную SQL базу данных. Для хранения событий можно использовать Microsoft SQL Server, Elasticsearch или MySQL/MariaDB.
В этом примере мы покажем, как записывать события аудита в отдельную таблицу БД на сервере MySQL. Формат таблицы:
- Имя сервера;
- Имя удаленного файла
- Время удаления;
- Имя пользователя, удалившего файл.
MySQL запрос на создание такой таблицы будет выглядеть так:
CREATE TABLE track_del (id INT NOT NULL AUTO_INCREMENT, server VARCHAR(100), file_name VARCHAR(255), dt_time DATETIME, user_name VARCHAR(100), PRIMARY KEY (ID));
Для получения событий с EventID 4663 из журнала Security за текущий день можно использовать такой PowerShell скрипт:
$today = get-date -DisplayHint date -UFormat %Y-%m-%d
Get-WinEvent -FilterHashTable @{LogName="Security";starttime="$today";id=4663} | Foreach {
$event = [xml]$_.ToXml()
if($event)
{
$Time = Get-Date $_.TimeCreated -UFormat "%Y-%m-%d %H:%M:%S"
$File = $event.Event.EventData.Data[6]."#text"
$User = $event.Event.EventData.Data[1]."#text"
$Computer = $event.Event.System.computer
}
}
Следующий PowerShell скрипт запишет полученные данные в БД MySQL на удаленном сервере:
Set-ExecutionPolicy RemoteSigned
Add-Type –Path ‘C:Program Files (x86)MySQLMySQL Connector Net 6.9.8Assembliesv4.5MySql.Data.dll'
$Connection = [MySql.Data.MySqlClient.MySqlConnection]@{ConnectionString='server=10.7.7.13;uid=posh;[email protected];database=aduser'}
$Connection.Open()
$sql = New-Object MySql.Data.MySqlClient.MySqlCommand
$sql.Connection = $Connection
$today = get-date -DisplayHint date -UFormat %Y-%m-%d
Get-WinEvent -FilterHashTable @{LogName="Security";starttime="$today";id=4663} | Foreach {
$event = [xml]$_.ToXml()
if($event)
{
$Time = Get-Date $_.TimeCreated -UFormat "%Y-%m-%d %H:%M:%S"
$File = $event.Event.EventData.Data[6]."#text"
$File = $File.Replace(‘’,’|’)
$User = $event.Event.EventData.Data[1]."#text"
$Computer = $event.Event.System.computer
$sql.CommandText = "INSERT INTO track_del (server,file_name,dt_time,user_name ) VALUES ('$Computer','$File','$Time','$User')"
$sql.ExecuteNonQuery()
}
}
$Reader.Close()
$Connection.Close()
После сохранения событий во внешнюю базу данных, этот журнал можно очистить.
Теперь, чтобы узнать, кто удалил файл «document1 — Copy.DOC». Достаточно в консоли PowerShell выполнить следующий скрипт.
$DeletedFile = "%document1 - Copy.DOC%"
Set-ExecutionPolicy RemoteSigned
Add-Type –Path ‘C:Program Files (x86)MySQLMySQL Connector Net 6.9.8Assembliesv4.5MySql.Data.dll'
$Connection = [MySql.Data.MySqlClient.MySqlConnection]@{ConnectionString='server=10.7.7.13;uid=posh;[email protected];database=aduser'}
$Connection.Open()
$MYSQLCommand = New-Object MySql.Data.MySqlClient.MySqlCommand
$MYSQLDataAdapter = New-Object MySql.Data.MySqlClient.MySqlDataAdapter
$MYSQLDataSet = New-Object System.Data.DataSet
$MYSQLCommand.Connection=$Connection
$MYSQLCommand.CommandText="SELECT user_name,dt_time from track_del where file_name LIKE '$DeletedFile'"
$MYSQLDataAdapter.SelectCommand=$MYSQLCommand
$NumberOfDataSets=$MYSQLDataAdapter.Fill($MYSQLDataSet, "data")
foreach($DataSet in $MYSQLDataSet.tables[0])
{
write-host "User:" $DataSet.user_name "at:" $DataSet.dt_time
}
$Connection.Close()
В результате в консоли PS появится имя пользователя и время удаления файла.
Примечание. Была обнаружена проблема — символ «» не записывается в БД, поэтому мы заменили его на «|». Соответственно если нужно вывести полный путь к файлу, при выборке из базы можно выполнить обратную замену:
$DataSet.file_name.Replace(‘|’,’’)
. Спасибо Alex Kornev за замечание!
Скрипт сброса данных из журнала в БД можно выполнять один раз в конце дня по планировщику или повесить триггер на событие удаления (On Event), что более ресурсоемко. Все зависит от требования к системе.
Совет. Нужно убедиться, что вы указали достаточно большой максимальный размер для журнала безопасности, чтобы в него помещались все события за день. Иначе придется запускать задания сброса данных из журнала в базу чаще, чем 1 раз в день, или вообще по триггеру. Для рабочих станция Maximum Log Size как правило стоит задать не менее 64 Мб, на северах – 262 Мб. Опцию перезаписи старых событий нужно оставить включенной (Overwrite events as needed).
Можно создать реагировать простую веб страницу на php для получения информации о событиях удаления файлов в более удобном виде. Задача решается силами любого php программиста за 1-2 часа.
Важный совет. При наличии в журнале информации об удалении файла пользователем не спешите однозначно интерпретировать его как преднамеренное или даже злонамеренное. Многие программы (особенно этим грешат программы пакета MS Office), при сохранении изменений, сначала создается временный файл, данные записываются в него, а старая версия файла удаляется. В этом случае имеет смысл дополнительной записи в БД имени процесса, которым было выполнено удаление файла (поле ProcessName события), и вести анализ событий удаления файлов с учетом этого факта. Либо можно фильтровать события от некоторых процессов, например, winword.exe, excel.exe и пр.
Запись информации о событиях удаления файлов в текстовый файл
Если вы не хотите вести отдельную БД, можно сохранять события аудита удалений файлов в текстовый лог файл. Воспользуйтесь таким PowerShell скриптом:
$Outfile = "C:psdelete-file-log.txt"
$today = get-date -DisplayHint date -UFormat %Y-%m-%d
Get-WinEvent -FilterHashTable @{LogName="Security";starttime="$today";id=4663} | Foreach {
$event = [xml]$_.ToXml()
if($event)
{
$Time = Get-Date $_.TimeCreated -UFormat "%Y-%m-%d %H:%M:%S"
$File = $event.Event.EventData.Data[6]."#text"
$User = $event.Event.EventData.Data[1]."#text"
$strLog = $Computer + " " + $File + " " + $Time + " " + $User
$strLog | out-file $Outfile –append
}
}
[/alert]
Итак, мы предложили идею и некий общий каркас системы аудита и хранения информации об удаленных файлах в сетевых шарах, при желании ее с лёгкостью можно будет модифицировать под ваши нужды.
Как настроить политики аудита Windows таким образом, чтобы охват мониторинга SOC был полноценным? Рассмотрим оптимальный список политик, а также выделим самое необходимое, отсеяв лишнее.
- Введение
- Знакомство с расширенным аудитом Windows
- Настройка политик аудита
- Усиление цифровой обороны
- Выводы
Введение
Все мы любим заворожённо читать про очередное расследование инцидента, где шаг за шагом распутывается клубок: как проник злоумышленник, какие инструменты он использовал и когда, что за процессы создавались на скомпрометированном хосте, что происходило в сети и, конечно же, кто виноват и что делать.
На практике ответы на эти вопросы находятся не всегда. Зачастую при расследовании специалисты отделов ИБ сталкиваются с тем, что аудит не настроен, логи перезаписались, отсутствует единая система хранения и анализа журналов, «перезалит» заражённый хост (популярное решение всех проблем).
Ниже мы разберём один из самых важных этапов, который нужен для того, чтобы расследование не завершилось ещё в самом начале: сбор и хранение журналов аудита. Будут рассмотрены возможности расширенного аудита ОС Windows и его настройка.
Знакомство с расширенным аудитом Windows
Речь пойдёт о настройках для систем Microsoft Windows Vista / Server 2008 и выше. Начиная с указанных операционных систем компания Microsoft сделала шаг вперёд в понимании аудита и управления им. Так появился расширенный аудит. Теперь администраторы и специалисты по информационной безопасности могут управлять аудитом на уровне не только категорий, но и подкатегорий.
Давайте подробнее остановимся на них. Откроем оснастку локальной групповой политики, используя команду «gpedit.msc» (или через «secpol.msc»). Для групповых политик всё будет аналогично, только все действия будут выполняться через «gpmc.msc».
Полный путь к настройкам аудита выглядит следующим образом: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Политика аудита (Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy).
Рисунок 1. Политика аудита
Расширенный аудит, в свою очередь, находится здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).
Рисунок 2. Конфигурация расширенной политики аудита
Ниже на рисунке видно, как они коррелируют между собой.
Рисунок 3. Корреляция аудита и расширенного аудита
В общей сложности нам доступны 10 политик и 60 подкатегорий.
Таблица 1. Категории и подкатегории аудита
| Категория (Category) | Подкатегория (Subcategory) | |
| Вход учётной записи (Account Logon) | Аудит проверки учётных данных (Audit Credential Validation) | |
| Аудит службы проверки подлинности Kerberos (Audit Kerberos Authentication Service) | ||
| Аудит операций с билетами службы Kerberos (Audit Kerberos Service Ticket Operations) | ||
| Аудит других событий входа учётных записей (Audit Other Account Logon Events) | ||
| Управление учётными записями (Account Management) | Аудит управления группами приложений (Audit Application Group Management) | |
| Аудит управления учётными записями компьютеров (Audit Computer Account Management) | ||
| Аудит управления группами распространения (Audit Distribution Group Management) | ||
| Аудит других событий управления учётными записями (Audit Other Account Management Events) | ||
| Аудит управления группами безопасности (Audit Security Group Management) | ||
| Аудит управления учётными записями пользователей (Audit User Account Management) | ||
| Подробное отслеживание (Detailed Tracking) | Аудит активности DPAPI (Audit DPAPI Activity) | |
| PNP-действие аудита (Audit PNP Activity) | ||
| Аудит создания процессов (Audit Process Creation) | ||
| Аудит завершения процессов (Audit Process Termination) | ||
| Аудит событий RPC (Audit RPC Events) | ||
| Проверка изменений прав маркера (Audit Token Right Adjusted) [Windows 10 / Server 2016 и выше] | ||
| Доступ к службе каталогов DS (DS Access) | Аудит подробной репликации службы каталогов (Audit Detailed Directory Service Replication) | |
| Аудит доступа к службе каталогов (Audit Directory Service Access) | ||
| Аудит изменения службы каталогов (Audit Directory Services Changes) | ||
| Аудит репликации службы каталогов (Audit Directory Service Replication) | ||
| Вход / выход (Logon / Logoff) | Аудит блокировки учётных записей (Audit Account Lockout) | |
| Аудит заявок пользователей или устройств на доступ (Audit User / Device Claims) | ||
| Аудит расширенного режима IPsec (Audit IPsec Extended Mode) | ||
| Аудит основного режима IPsec (Audit IPsec Main Mode) | ||
| Аудит быстрого режима IPsec (Audit IPsec Quick Mode) | ||
| Аудит выхода из системы (Audit Logoff) | ||
| Аудит входа в систему (Audit Logon) | ||
| Аудит сервера политики сети (Audit Network Policy Server) | ||
| Аудит других событий входа и выхода (Audit Other Logon / Logoff Events) | ||
| Аудит специального входа (Audit Special Logon) | ||
| Доступ к объектам (Object Access) | Аудит событий, создаваемых приложениями (Audit Application Generated) | |
| Аудит служб сертификации (Audit Certification Services) | ||
| Аудит сведений об общем файловом ресурсе (Audit Detailed File Share) | ||
| Аудит общего файлового ресурса (Audit File Share) | ||
| Аудит файловой системы (Audit File System) | ||
| Аудит подключения платформы фильтрации (Audit Filtering Platform Connection) | ||
| Аудит отбрасывания пакетов платформой фильтрации (Audit Filtering Platform Packet Drop) | ||
| Аудит работы с дескрипторами (Audit Handle Manipulation) | ||
| Аудит объектов ядра (Audit Kernel Object) | ||
| Аудит других событий доступа к объектам (Audit Other Object Access Events) | ||
| Аудит реестра (Audit Registry) | ||
| Аудит съёмного носителя (Audit Removable Storage) | ||
| Аудит диспетчера учётных записей безопасности (Audit SAM) | ||
| Аудит сверки с централизованной политикой доступа (Audit Central Access Policy Staging) | ||
| Изменение политики (Policy Change) | Аудит изменения политики аудита (Audit Policy Change) | |
| Аудит изменения политики проверки подлинности (Audit Authentication Policy Change) | ||
| Аудит изменения политики авторизации (Audit Authorization Policy Change) | ||
| Аудит изменения политики платформы фильтрации (Audit Filtering Platform Policy Change) | ||
| Аудит изменения политики на уровне правил MPSSVC (Audit MPSSVC Rule-Level Policy Change) | ||
| Аудит других событий изменения политики (Audit Other Policy Change Events) | ||
| Использование привилегий (Privilege Use) | Аудит использования привилегий, не затрагивающих конфиденциальные данные (Audit Non Sensitive Privilege Use) | |
| Аудит других событий использования привилегий (Audit Other Privilege Use Events) | ||
| Аудит использования привилегий, затрагивающих конфиденциальные данные (Audit Sensitive Privilege Use) | ||
| Система (System) | Аудит драйвера IPsec (Audit IPsec Driver) | |
| Аудит других системных событий (Audit Other System Events) | ||
| Аудит изменения состояния безопасности (Audit Security State Change) | ||
| Аудит расширения системы безопасности (Audit Security System Extension) | ||
| Аудит целостности системы (Audit System Integrity) | ||
| Аудит доступа к глобальным объектам (Global Object Access Auditing) | Файловая система (File system) | |
| Реестр (Registry) |
Теперь вместо включения аудита «Доступ к объектам» мы можем очень тонко настроить его по подкатегориям. Например, мы не будем включать аудит событий «платформы фильтрации Windows», потому что он генерирует крайне большое количество событий (всё сетевое взаимодействие хоста), которые к тому же лучше отслеживать на специализированном оборудовании, таком как межсетевые экраны, маршрутизаторы, прокси- и DNS-серверы.
Включим аудит файловой системы, реестра, съёмного носителя и других событий доступа к объектам, а всё остальное оставим в выключенном состоянии (параметр «Не настроено»).
Рисунок 4. Пример настройки аудита доступа к объектам через подкатегории
События аудита могут иметь значение «Успех и отказ», изображённое на рис. 4, или поддерживать только одно из двух состояний. Например, аудит создания процессов (Event ID 4688: A new process has been created) может быть только «успешным» (рис. 5).
Рисунок 5. Аудит создания процессов регистрирует успешные события
Если вы не знаете, нужна ли вам та или иная политика аудита, то ознакомиться с их описанием тоже очень легко. Оно есть на вкладке «Пояснение» соответствующей политики.
Рисунок 6. Вкладка с описанием политики
Для некоторых политик аудита дополнительно нужно настраивать системные списки управления доступом (SACL). Это в первую очередь касается файлового аудита и аудита реестра (альтернатива — использовать весьма специфичную политику «Аудит доступа к глобальным объектам»).
Например, чтобы отслеживать изменения в файле «hosts», откроем его свойства и перейдём в настройки аудита: «Безопасность» -> «Дополнительно» -> «Аудит». Добавим субъект аудита: выбираем группу «Все». Тип аудита — «Успех». Ставим галочки напротив записи данных, удаления, смены разрешений и смены владельца.
Рисунок 7. Настройка SACL
Если в вашей компании уже существуют различные групповые политики с настройками аудита, но вы хотите начать использовать расширенный аудит и подкатегории, то для этого случая Microsoft учла и ввела новую политику, которая называется «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings). По умолчанию она включена. Проверить состояние политики можно здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Параметры безопасности (Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options).
Рисунок 8. Принудительное переопределение параметров политики аудита
Дополнительно вы можете управлять политиками аудита через инструмент командной строки «auditpol.exe».
Рисунок 9. Использование инструмента auditpol
Настройка политик аудита
Очень часто можно услышать совет: «давайте включим все политики». Это, конечно, — «путь джедая», но, как показывает практика, не все джедаи добрались до финала.
Для большинства сценариев мониторинга нет острой необходимости включать всё. Это излишне. Включая все политики, вы можете получить гигантский поток событий, в котором очень легко «утонуть». В большой инфраструктуре с несколькими тысячами Windows-хостов поток событий может исчисляться десятками тысяч EPS (событий в секунду). Это порождает другую, не менее сложную задачу: как этим управлять, где это хранить, как обрабатывать.
Предлагаем рассмотреть оптимальный список политик, который может вам понадобиться. Также стоит обратить внимание на то, что фактически настроек две (и, соответственно, существуют две различные GPO). Первая — исключительно для контроллеров домена, так как часть событий (например, ID 4768: A Kerberos authentication ticket (TGT) was requested) фиксируется исключительно на них. Вторая — для рядовых серверов и АРМ пользователей.
Таблица 2. Рекомендуемые настройки аудита Windows
| Категория | Подкатегория | Включить | Хост (DC, сервер, АРМ) | Категория (успех / отказ) |
| Account Logon | Audit Credential Validation | + | DC, сервер, АРМ | Успех и отказ |
| Audit Kerberos Authentication Service | + | DC | Успех и отказ | |
| Audit Kerberos Service Ticket Operations | + | DC | Успех и отказ | |
| Audit Other Account Logon Events | — | |||
| Account Management | Audit Application Group Management | + | DC | Успех и отказ |
| Audit Computer Account Management | + | DC | Успех | |
| Audit Distribution Group Management | + | DC | Успех | |
| Audit Other Account Management Events | + | DC, сервер, АРМ | Успех | |
| Audit Security Group Management | + | DC, сервер, АРМ | Успех | |
| Audit User Account Management | + | DC, сервер, АРМ | Успех и отказ | |
| Detailed Tracking | Audit DPAPI Activity | + | DC, сервер, АРМ | Успех и отказ |
| Audit PNP Activity | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Process Creation | + | DC, сервер, АРМ | Успех | |
| Audit Process Termination | — | |||
| Audit RPC Events | — | |||
| Audit Token Right Adjusted | — | |||
| DS Access | Audit Detailed Directory Service Replication | + | DC | Успех и отказ |
| Audit Directory Service Access | + | DC | Успех и отказ | |
| Audit Directory Services Changes | + | DC | Успех и отказ | |
| Audit Directory Service Replication | + | DC | Успех и отказ | |
| Logon/Logoff | Audit Account Lockout | + | DC, сервер, АРМ | Отказ |
| Audit User / Device Claims | — | |||
| Audit IPsec Extended Mode | — | |||
| Audit IPsec Main Mode | — | |||
| Audit IPsec Quick Mode | — | |||
| Audit Logoff | + | DC, сервер, АРМ | Успех | |
| Audit Logon | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Network Policy Server | — | |||
| Audit Other Logon / Logoff Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Special Logon | + | DC, сервер, АРМ | Успех | |
| Object Access | Audit Application Generated | — | ||
| Audit Certification Services | — | |||
| Audit Detailed File Share | — | |||
| Audit File Share | — | |||
| Audit File System | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Filtering Platform Connection | — | |||
| Audit Filtering Platform Packet Drop | — | |||
| Audit Handle Manipulation | — | |||
| Audit Kernel Object | — | |||
| Audit Other Object Access Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Registry | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Removable Storage | + | DC, сервер, АРМ | Успех и отказ | |
| Audit SAM | — | |||
| Audit Central Access Policy Staging | — | |||
| Policy Change | Audit Policy Change | + | DC, сервер, АРМ | Успех |
| Audit Authentication Policy Change | + | DC, сервер, АРМ | Успех | |
| Audit Authorization Policy Change | + | DC, сервер, АРМ | Успех | |
| Audit Filtering Platform Policy Change | — | |||
| Audit MPSSVC Rule-Level Policy Change | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Other Policy Change Events | — | |||
| Privilege Use | Audit Non Sensitive Privilege Use | + | DC, сервер, АРМ | Успех и отказ |
| Audit Other Privilege Use Events | — | |||
| Audit Sensitive Privilege Use | + | DC, сервер, АРМ | Успех и отказ | |
| System | Audit IPsec Driver | — | ||
| Audit Other System Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Security State Change | + | DC, сервер, АРМ | Успех | |
| Audit Security System Extension | + | DC, сервер, АРМ | Успех | |
| Audit System Integrity | — | |||
| Global Object Access Auditing | File system | — | ||
| Registry | — |
После включения описанных политик у вас будут все необходимые события для мониторинга и расследования инцидентов.
Усиление цифровой обороны
Для максимальной отдачи необходимо выполнить ещё одну настройку — включить логирование «командной строки процесса». Тогда на рабочих станциях и серверах, к которым применяется этот параметр политики, сведения из командной строки будут заноситься в журнал событий «Безопасность» (Security) с ID 4688.
Рисунок 10. Журналирование командной строки процесса
Требования к версии ОС: не ниже Windows Server 2012 R2, Windows 8.1. Данная функциональность также доступна и на ОС Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012 после установки обновления KB 3004375.
Путь к политике: Конфигурация компьютера / Административные шаблоны / Система / Аудит создания процессов (Computer Configuration / Administrative Templates / System / Audit Process Creation). Имя: «Включать командную строку в события создания процессов» (Include command line in process creation events).
Рисунок 11. Путь к аудиту создания процессов
Включаем политику, выставив соответствующее значение, и нажимаем «Применить» (Apply).
Рисунок 12. Настройка «Включать командную строку в события создания процессов»
После включения этой политики в журнале событий «Безопасность» (Security) в событиях с кодом 4688 появится дополнительное значение «Командная строка процесса» (Process Command Line), где будет отображаться тело исполняемой команды.
В примере ниже демонстрируется, как это поможет заглянуть чуть глубже. На первый взгляд в событии происходит запуск легитимного процесса «opera_autoupdate.exe», но вот строка «Process Command Line» больше похожа на запуск утилиты «mimikatz». Без активированной политики «Включать командную строку в события создания процессов» мы этого не зафиксируем.
Рисунок 13. Детектирование mimikatz
Укрепим нашу оборону и полным журналированием работы самого мощного инструмента ОС Windows — PowerShell. Для этого необходима версия PowerShell 5.0 или выше.
PowerShell 5.0 / 5.1 предустановлен в Windows 10, Windows Server 2016 и Windows Server 2019. Для остальных операционных систем необходимо обновить модуль Windows Management Framework.
Список поддерживаемых ОС:
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2 SP1
- Windows 8.1
- Windows 8
- Windows 7 SP1
Скачайте с сайта Microsoft соответствующую версию, выполните установку и перезагрузку хоста. Также обязательным требованием является наличие Microsoft .NET Framework 4.5 или выше.
Включим регистрацию блоков сценариев PowerShell через соответствующую политику. Она находится по следующему пути: Административные шаблоны / Компоненты Windows / Windows PowerShell (Administrative Templates / Windows Components / Windows PowerShell). Имя: «Включить регистрацию блоков сценариев PowerShell» (Turn on PowerShell Script Block Logging)
Рисунок 14. Путь к аудиту Windows PowerShell
Включаем политику и нажимаем «Применить» (Apply). При этом устанавливать галочку напротив поля «Регистрация начала или остановки вызова блоков сценариев» (Log script block invocation start / stop events) не нужно. Данная функция увеличивает количество регистрируемых событий, которые не несут полезной информации.
Рисунок 15. Включить регистрацию блоков сценариев PowerShell
После включения этой политики PowerShell будет регистрировать в журнале событий трассировки Microsoft-Windows-PowerShell/Operational с кодом события 4104 все блоки сценариев, в том числе — путь, тело скрипта и все используемые командлеты.
Рисунок 16. Пример регистрируемого события 4104
Хорошей практикой является увеличение размера самих журналов, даже если вы используете SIEM или сервер сборщика событий (Windows Event Collector). Например, журнал «Безопасность» (Security) по умолчанию имеет размер 20 МБ. При настроенном аудите на типичном АРМ этого объёма хватит на журналирование нескольких дней, на сервере — нескольких часов, а на контроллере домена 20 МБ не хватит ни на что.
Рекомендуем для всех основных журналов следующие объёмы:
- журнал «Установка» (Setup) — не менее 10 МБ,
- журнал «Система» (System) — не менее 50 МБ,
- журнал «Приложение» (Application) — не менее 50 МБ,
- журнал «Безопасность» (Security) — не менее 200 МБ (для контроллера домена — не менее 500 МБ).
При этом оставляем функцию перезаписи старых событий (по умолчанию она активирована).
Рисунок 17. Настройка хранения журналов аудита
Выводы
Настройка необходимых для мониторинга политик аудита, локальное долговременное хранение журналов, протоколирование запуска процессов и команд PowerShell позволит не упустить важные события безопасности и тщательно расследовать инциденты. Это — один из ключевых этапов в построении процессов непрерывного мониторинга, снижения рисков ИБ и повышения уровня защищённости.
В дальнейшем важно будет обеспечить централизованный сбор и хранение журналов в SIEM-системе, настройку корреляционных правил, киберразведку (Threat Intelligence), проведение активных испытаний безопасности в формате Red / Blue Team.