Аудит удаления и доступа к файлам и запись событий в лог-файл средствами Powershell
Начнем.
Для начала включим к групповых политиках возможность аудита доступа к файлам и папкам.
Локальные политики безопасности->Конфигурация расширенной политики безопасности->Доступ к объектам
Включим «Аудит файловой системы» на успех и отказ.
После этого на необходимые нам папки необходимо настроить аудит.
Проходим в свойства папки общего доступа на файловом сервере, переходим в закладку «Безопасность», жмем «Дополнительно», переходим в закладку «Аудит», жмем «Изменить» и «Добавить». Выбираем пользователей для которых вести аудит. Рекомендую выбрать «Все», иначе бессмысленно. Уровень применения «Для этой папки и ее подпапок и файлов».
Выбираем действия над которыми мы хотим вести аудит. Я выбрал «Создание файлов/дозапись данных» Успех/Отказ, «Создание папок/дозапись данных» Успех/отказ, Удаление подпапок и файлов и просто удаление, так же на Успех/Отказ.
Жмем ОК. Ждем применения политик аудита на все файлы. После этого в журнале событий безопасности, будет появляться очень много событий доступа к файлам и папкам. Количество событий прямопропорционально зависит от количества работающих пользователей с общим ресурсом, и, конечно же, от активности использования.
Итак, данные мы уже имеем в логах, остается только их оттуда вытащить, и только те, которые нас интересуют, без лишней «воды». После этого акурратно построчно занесем наши данные в текстовый файл разделяя данные симовлами табуляции, чтобы в дальнейшем, к примеру, открыть их табличным редактором.
А теперь очень интересный скрипт.
Скрипт пишет лог об удаленных файлах.
Как оказалось при удалении файлов и удалении дескрипторов создается одно и тоже событие в логе, под При этом в теле сообщения могут быть разные значения «Операции доступа»: Запись данных (или добавление файла), DELETE и т.д.
Конечно же нас интересует операция DELETE. Но и это еще не все. Самое интересное, то что, при обычном переименовании файла создается 2 события с ID 4663, первое с Операцией доступа: DELETE, а второе с операцией: Запись данных (или добавление файла). Значит если просто отбирать 4663 то мы будем иметь очень много недостоверной информации: куда попадут файлы и удаленные и просто переименованные.
Однако мной было замечено, что при явном удалении файла создается еще одно событие с ID 4660, в котором, если внимательно изучить тело сообщения, содержится имя пользователя и еще много всякой служебной информации, но нет имени файла. Зато есть код дескриптора. 
Однако предшествующим данному событию было событие с ID 4663. Где как раз таки и указывается и имя файла, и имя пользователя и время, и операция как не странно там DELETE. И самое главное там имеется номер дескриптора, который соответствует номеру дескриптора из события выше (4660, помните? которое создается при явном удалении файла). Значит теперь, чтобы точно знать какие файлы удалены, необходимо просто найти все события с ID 4660, а так же предшествующие каждому этому событию, событие с кодом 4663, в котором будет содержаться номер нужного дескриптора. 
Эти 2 события генерируются одновременно при удалении файла, но записываются последовательно, сначала 4663, потом 4660. При этом их порядковые номера различаются на один. У 4660 порядковый номер на единицу больше чем у 4663.
Именно по этому свойству и ищется нужное событие. 
Т.е. не записываем информацию об удаленных временных файлах (.*tmp), файлах блокировок документов MS Office (.*lock), и временных файлах MS Office (.*
Для лога удаленных файлов я использую схему: один файл на один месяц с именем содержащим номер месяца и год). Т.к. удаленных файлов в разы меньше чем файлов к которым был доступ.
В итоге вместо бесконечного «рытья» логов в поисках правды, можно открыть лог-файл любым табличным редактором и просмотреть нужные нам данные по пользователю или файлу.
Рекомендации
Вам придется самим определить время в течении которого вы будете искать нужные события. Чем больше период, тем дольше ищет. Все зависит от производительности сервера. Если слабенький — то начните с 10 минут. Посмотрите, как быстро отработает. Если дольше 10 минут, то либо увеличьте еще, вдруг поможет, либо наоборот уменьшите период до 5 минут.
Отслеживаем удаление файлов на PowerShell
Когда наше файловое хранилище разменяло третий терабайт, все чаще наш отдел стал получать просьбы выяснить, кто удалил важный документ или целую папку с документами. Нередко это происходит по чьему-то злому умыслу. Бэкапы — это хорошо, но страна должна знать своих героев. А молоко вдвойне вкусней, когда мы можем написать его на PowerShell.
Пока разбирался, решил записать для коллег по цеху, а потом подумал, что может пригодиться кому-то еще. Материал получился смешанный. Кто-то найдет для себя готовое решение, кому-то пригодятся несколько неочевидные методы работы с PowerShell или планировщиком задач, а кто-то проверит на быстродействие свои скрипты.
Но ход мыслей Deks мне понравился.
Краткий дискурс: При включенном аудите файловой системы в момент удаления файла в журнале безопасности создаются два события, с кодами 4663 и, следом, 4660. Первое записывает попытку запроса доступа на удаление, данные о пользователе и пути к удаляемому файлу, а второе — фиксирует свершившийся факт удаления. У событий есть уникальный идентификатор EventRecordID, который отличается на единицу у этих двух событий.
Ниже приведен исходный скрипт, собирающий информацию об удаленных файлах и пользователях, их удаливших.
С помощью команды Measure-Command получили следующее:
Многовато, на вторичных ФС будет дольше. Сходу очень не понравился десятиэтажный пайп, поэтому для начала я его структурировал:
Получилось уменьшить этажность пайпа и убрать перечисления Foreach, а заодно сделать код более читаемым, но большого эффекта это не дало, разница в пределах погрешности:
Пришлось немного подумать головой. Какие операции занимают больше всего времени? Можно было бы натыкать еще десяток Measure-Command, но в общем-то в данном случае и так очевидно, что больше всего времени тратится на запросы в журнал (это не самая быстрая процедура даже в MMC) и на повторяющиеся конвертации в XML (к тому же, в случае с EventRecordID это и вовсе необязательно). Попробуем сделать и то и другое по одному разу, а заодно исключить промежуточные переменные:
А вот это уже результат. Ускорение практически в два раза!
Автоматизируем
Порадовались, и хватит. Три минуты — это лучше, чем пять, но как лучше всего запускать скрипт? Раз в час? Так могут ускользнуть записи, которые появляются одновременно с запуском скрипта. Делать запрос не за час, а за 65 минут? Тогда записи могут повторяться. Да и искать потом запись о нужном файле среди тысячи логов — мутор. Писать раз в сутки? Ротация логов забудет половину. Нужно что-то более надежное. В комментариях к статье Deks кто-то говорил о приложении на дотнете, работающем в режиме службы, но это, знаете, из разряда «There are 14 competing standards»…
В планировщике заданий Windows можно создать триггер на событие в системном журнале. Вот так:
Отлично! Скрипт будет запускаться ровно в момент удаления файла, и наш журнал будет создаватья в реальном времени! Но наша радость будет неполной, если мы не сможем определить, какое событие нам нужно записать в момент запуска. Нам нужна хитрость. Их есть у нас! Недолгий гуглинг показал, что по триггеру «Событие» планировщик может передавать исполняемому файлу информацию о событии. Но делается это, мягко говоря, неочевидно. Последовательность действий такая:
Нужно обязательно разрешить одновременный запуск нескольких экземпляров, а также, как мне кажется, стоит запретить ручной запуск и задать лимит времени выполнения:
Создадим триггер типа 0 (Event). Далее задаем XML-запрос для получения нужных нам событий. Код XML-запроса можно получить в консоли MMC «Журнал событий», выбрав необходимые параметры и переключившись на вкладку «XML»:
Главная хитрость: указываем переменную, которую нужно передать скрипту.
Собственно, описание выполняемой команды:
«Концепция поменялась»
Вернемся к скрипту для записи логов. Теперь нам не надо получать все события, а нужно доставать одно-единственное, да еще переданное в качестве аргумента. Для этого мы допишем заголовки, превращающие скрипт в командлет с параметрами. До кучи — сделаем возможным изменять путь к логу «на лету», авось, пригодится:
Теперь нам больше не нужно перечисление Foreach-Object, поскольку обрабатывается всего одно событие. Не два, потому что событие с кодом 4660 используется только для того, чтобы инициировать скрипт, полезной информации оно в себе не несет.
Помните, в начале я хотел, чтобы пользователи могли без моего участия узнатьзлодея? Так вот, в случае, если файл удален в папке документов какого-либо отдела — пишем лог также в корень папки отдела.
Итоговый командлет
Ну вот, кусочки нарезаны, осталось собрать все воедино и еще чуть-чуть оптимизировать. Получится как-то так:
Теперь сотрудники любого отдела могут в реальном времени видеть, кто, что и когда удалил из их каталогов. Отмечу, что я не стал рассматривать здесь права доступа к файлам логов (чтобы злодей не мог их удалить) и ротацию. Структура и права доступа к каталогам на нашем файлере тянут на отдельную статью, а ротация в какой-то степени усложнит поиск нужной строки.
Простая система аудита удаления файлов и папок для Windows Server
Любой администратор Windows сталкивался с ситуацией, когда разъяренные пользователи хотят узнать, кто именно удалил мега важный файл с годовым отчетом в общей папке на файловом сервере. Эту информацию можно получить только при условии ведения аудита удаления файлов и папок на файловом сервере, иначе останется только восстановить удаленный файл из резервной копии (а вы их уже делаете?) и развести руками.
Но, даже при включенном аудите удаления файлов, найти что-то в логах бывает проблематично. Во-первых, найти нужную запись среди тысячи событий довольно сложно (в Windows отсутствуют вменяемые средства поиска интересующего события с возможностью гибкой фильтрации), а во-вторых, если файл был удален давно, это событие может просто отсутствовать в журнале, т.к. было перезатерто более новыми.
В этой статье мы покажем пример организации на встроенных средствах Windows системы аудита удаления файлов и папок в общем сетевом каталоге (файловом сервере) с записью событий в отдельную базу данных на MySQL.
Благодаря наличию БД с информацией обо всех удаленных файлах администратор сможет дать ответы на вопросы:
В первую очередь на файловом сервере Windows нужно включить аудит событий, обеспечивающий запись информации об удалении файлов в журнал системы. Эту процедуру мы уже рассматривали в статье Аудит доступа к файлам и папкам в Windows.
Совет. Аудит удаления файлов в конкретной папке можно включить и через PowerShell:
При успешном удалении файла в журнале безопасности системы появляется событие Event ID 4663 от источника Microsoft Windows security auditing. В описании события есть информация об имени удаленного файла, учетной записи из-под которой было выполнено удаление и имени процесса.
Итак, интересующие нас события пишутся в журнал, настала пора создать на сервере 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));
Скрипт сбора информации из журнала событий. Мы фильтруем журнал по событию с ID 4663 за текущий день
Следующий скрипт запишет полученные данные в БД MySQL на удаленном сервере:
Теперь, чтобы узнать, кто удалил файл «document1 — Copy.DOC», достаточно в консоли PowerShell выполнить следующий скрипт.
В консоли получаем имя пользователя и время удаления файла.
При желании по аналогии можно реагировать простую веб страницу на php для получения информации о виновниках удаления файлов в более удобном виде. Задача решается силами любого php программиста за 1-2 часа.
Итак, мы предложили идею и некий общий каркас системы аудита и хранения информации об удаленных файлах в сетевых шарах, при желании ее с лёгкостью можно будет модифицировать под ваши нужды.
Аудит доступа к файлам и папкам Windows на примере Windows server 2012R2
Иногда бывает необходимо понять кто удалил/изменил/переименовал конкретный файл или папку. В ОС Windows для этого используется аудит доступа к объектам.
Необходимо понимать, что аудит забирает на себя.
Для того, чтобы можно было настраивать аудит файлов и папок необходимо предварительно включить эту возможность через локальные (или в случае если у Вас используется Microsoft AD групповые) политики безопасности.
В случае локальных политик необходимо запустить оснастку “Локальная политика безопасности”, для этого необходимо нажать комбинацию клавиш Win+R, в открывшееся поле ввести secpol.msc и нажать клавишу Enter.
Для этого необходимо открыть свойства файла или папки, перейти на вкладку “Безопасность”, нажать “Дополнительно” и “Аудит”.
Нажимаем “Добавить” и начинаем настраивать аудит.
Можно вписать туда имя пользователя или группы, если имя заранее неизвестно, то можно воспользоваться кнопкой “Дополнительно” которая открывает форму поиска где можно выбрать интересующих нас пользователей и группы. Чтобы контролировались действия всех пользователей необходимо выбрать группу “Все”.
Для папок поля такие:
А такие для файлов:
После этого начнется сбор данных аудита. Все события аудита пишутся в журнал “Безопасность”. Открыть его проще всего через оснастку “Управление компьютером” compmgmt.msc.
Каждое событие ОС Windows имеет свой код события. Список событий достаточно обширен и доступен на сайте Microsoft либо в интернете. Например события аудита можно посмотреть здесь.
Вручную можно, например, задать например такой фильтр:
Далее в отфильтрованных событиях необходимо найти интересующее нас по имени объекта.
Открыть его двойным щелчком мыши и увидеть кто удалил данный файл в поле субъект.
Заметки системного администратора
Грань между «Сейчас чуть-чуть подправлю» и «Ой, б#я!» — очень тонка!
Аудит создания и удаления файлов в Windows 2008, 2012 и 2016
1. Включение механизма аудита
Оптимальный инструмент — групповые политики (применять к OU отслеживаемых серверов). Возможно использование аналогичных локальных политик для каждого сервера
«Computer Settings \ Windows Settings \ Security Settings \ Advanced audit policy configuration \ system audit policies \ object access \ audit file system» => «audit events: success» enabled.
Весьма маловероятен сценарий, когда вам будет необходимо мониторить неудачные попытки доступа к файлам. Не отрицаю, что возможен. Но чаще нужно узнать кто удалил (или выложил) файл.
2. Настройка аудита на конкретных папках
Далее непосредственно на серверах, которые хранят данные, используя проводник, зайдя в свойства папки, которую нужно мониторить, включить настройки аудита для группы, которую хотим мониторить. Например, Everyone, если мы хотим отслеживать любые изменения любыми возможными пользователями и сервисами:
«Delete subfolders and file — Successful»
“Create files / write data — Successful”
“Create folders / append data — Successful”
3. Мониторинг событий
После этого в логах сервера (на котором хранятся файлы) в Security Event Log будут появляться события при создании и удалении файлов и поддиректорий из указанных выше папок.
Отследить конкретных участников операции можно с помощью двух событий:
Event ID: 4660
Description: An object was deleted.
Event ID: 4663
Description:An attempt was made to access an object.
Виды масок доступа:
| Тип доступа | Hex | Описание |
| ReadData (or ListDirectory) | 0×1 | ReadData – чтение данных из файла или объекта директории.ListDirectory – просмотр содержимого директории. |
| WriteData (or AddFile) | 0×2 | WriteData – запись данных в файл.AddFile – создание файла в директории. |
| AppendData (or AddSubdirectory or CreatePipeInstance) | 0×4 | AppendData – дописывание данных в файл. Не перезаписывает существующие данные, если дополнительно не содержит флага WriteData.AddSubdirectory – создание поддиректорий. |
| DELETE | 0×10000 | Удаление объекта. |
Ключевой источник информации – события 4663:
Раздел Subject содержит информацию об аккаунте, из-под которого производились операции над объектом.
Object – информация о файле (путь, имя, handle)
Process Information содержит информацию о том, какой процесс производил операции с файлом.
В разделе Access Request Information размещена информация о типе доступа и маске доступа.
При создании файла в указанной папке, в Security Event Log появляется пара событий с ID 4663, первое с маской 0х2, второе с маской 0х4.
При удалении файла появляется событие с ID 4663 и маской доступа 0х10000, а также событие 4660. Определить какой именно файл был удалён по событию 4660 можно найдя предваряющее его событие 4663, имеющее идентичный handle.