Эксперты в подборе IT-оборудования
Файл исчез. Просто взял и пропал с сервера. Кто удалил? Когда это произошло? Случайность или злой умысел? Без системы аудита на эти вопросы ответить невозможно - остаются только догадки, взаимные обвинения и нервы. А ведь речь может идти о документах, которые терять нельзя: договорах, финансовых отчётах, проектной документации.
Аудит файловой системы - это не слежка за сотрудниками, а штатный механизм Windows, который фиксирует действия с данными: кто создал файл, кто переименовал, кто изменил права доступа, кто удалил. Ниже - как его включить, какие события искать и что делать, если журнал оказался пустым.
Плохая новость сразу: задним числом узнать, кто удалил файл, нельзя. Аудит пишет события начиная с момента включения. Всё, что происходило раньше, нигде не осталось. Если политика не была настроена, в журнале Security ничего про этот файл не появится.
Что можно сделать прямо сейчас:
И сразу включить аудит, чтобы следующий такой случай был разобран за пять минут.
Механизм состоит из двух независимых частей, и в этом главная ловушка: включить нужно обе. Политика говорит системе «пиши события такого типа», SACL на папке говорит «вот за этим объектом следи». Без второй части журнал останется пустым.
В доменной среде - через групповую политику:
Конфигурация компьютера → Политики → Конфигурация Windows → Параметры безопасности →
Конфигурация расширенной политики аудита (Advanced Audit Policy Configuration) →
Доступ к объектам (Object Access) → Аудит файловой системы (Audit File System)
Ставим «Успех» и «Отказ». Успех покажет, кто что сделал; отказ - кто пытался и не смог.
На отдельно стоящем сервере то же включается через secpol.msc или командой. Здесь есть тонкость: названия подкатегорий локализованы, и на русской Windows строка "File System" не найдётся. Чтобы не гадать, используйте GUID подкатегории - он одинаков в любой локали:
auditpol /set /subcategory:{0CCE921D-69AE-11D9-BED3-505054503030} /success:enable /failure:enable
Это тот шаг, который пропускают чаще всего.
Свойства папки → Безопасность → Дополнительно → вкладка Аудит → Добавить. Выбираем субъект (обычно «Все» или конкретную группу), тип «Все» (успех и отказ) и отмечаем нужные разрешения.
Минимальный полезный набор для отслеживания удалений и правок:
Ставить галочку «Полный доступ» не надо: событий станет на порядок больше, полезных среди них не прибавится.
После gpupdate /force на сервере смотрим фактическое состояние:
auditpol /get /subcategory:{0CCE921D-69AE-11D9-BED3-505054503030}
Должно быть «Успех и отказ». Если пусто - политика не доехала или её перебивает другая GPO.
Открываем «Просмотр событий» → журнал Безопасность и фильтруем по коду события. Или сразу из PowerShell:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4663} -MaxEvents 200 |
Where-Object { $_.Message -match 'Договоры' } |
Select-Object TimeCreated, Id, Message | Format-List
Вместо Договоры подставьте фрагмент пути к нужной папке или имя файла.
| Код | Что означает | Когда пригодится |
|---|---|---|
| 4663 | Выполнена попытка доступа к объекту | Главное событие. Содержит имя файла, учётную запись и тип доступа. Для удалений ищите его с доступом DELETE |
| 4660 | Объект удалён | Срабатывает только при реальном удалении. Имени файла не содержит - только Handle ID |
| 4656 | Запрошен дескриптор объекта | Начало операции, полезно для связки событий |
| 4658 | Дескриптор закрыт | Требует включённой подкатегории «Работа с дескрипторами» |
| 4670 | Изменены разрешения объекта | Кто и как правил права доступа |
| 4664 | Создана жёсткая ссылка | Редко, но встречается при попытках обойти учёт |
| 5145 | Проверка доступа к объекту сетевой шары | Отдельная подкатегория, содержит IP-адрес клиента |
Событие 4660 подтверждает факт удаления, но не говорит, какой именно файл удалён - в нём есть только Handle ID. Microsoft прямо рекомендует отслеживать удаления по событию 4663 с типом доступа DELETE: там имя файла есть. Связать пару можно по совпадающему Handle ID - 4663 скажет «что», 4660 подтвердит, что это было именно удаление.
Обратная сторона: 4663 с DELETE появляется и при переименовании файла. Само по себе это событие удаление не доказывает, поэтому связка двух надёжнее любого из них по отдельности.
Их две, и задачи у них не совпадают.
| Аудит файловой системы | Подробный аудит общего доступа | |
|---|---|---|
| Событие | 4663, 4660, 4670 | 5145 |
| Нужен ли SACL | Да, иначе событий не будет | Нет, аудируются все шары сразу |
| IP-адрес клиента | Нет | Есть |
| Объём событий | Зависит от того, как расставлены SACL | Высокий на файловом сервере |
Если вопрос звучит как «кто удалил файл в конкретной папке» - хватит первой, с аккуратно поставленным SACL. Если нужно понять, с какой машины пришёл человек, придётся включать вторую: IP-адреса клиента в событиях файловой системы попросту нет.
GUID подкатегории подробного аудита общего доступа - {0CCE9244-69AE-11D9-BED3-505054503030}.
Включать её на файловом сервере «на всякий случай» не стоит: она пишет событие на каждое обращение к каждому файлу на всех шарах. Журнал переполнится за часы. Рабочий компромисс - включить только «Отказ»: объём небольшой, а видно, кто ломился туда, куда ему не положено.
Отдельный вопрос, с аудитом не связанный вовсе. Спрашивают его постоянно: файл заблокирован, Excel пишет «только для чтения», кто виноват.
Смотреть надо не в журнал, а в список открытых сессий SMB:
Get-SmbOpenFile | Select-Object ClientUserName, ClientComputerName, Path
Командлет входит в модуль SmbShare и есть в Windows Server 2016 и новее. В выводе видно учётную запись, имя или IP клиентской машины и полный путь к файлу.
В оснастке этот же список лежит здесь: Управление компьютером → Общие папки → Открытые файлы.
Если файл держит зависшая сессия, её закрывают парным командлетом:
Get-SmbOpenFile | Where-Object { $_.Path -like '*otchet.xlsx' } | Close-SmbOpenFile -Force
Предупредите пользователя перед этим: несохранённые изменения потеряются.
Три причины покрывают почти все случаи.
SACL не поставлен. Встречается чаще всего. Политика включена, галочка стоит, а событий нет, потому что система пишет их только для объектов с настроенным списком аудита. Проверяется за минуту: свойства папки → Безопасность → Дополнительно → Аудит. Пусто - вот и ответ.
Политика не применилась. Проверьте auditpol /get по GUID подкатегории, как в шаге 3. Частая причина - устаревшая политика «Аудит доступа к объектам» из классического раздела перебивает расширенную.
Журнал успел перезаписаться. Размер журнала Security по умолчанию скромный, а аудит файловой системы генерирует события быстро. Если в свойствах журнала стоит «затирать старые по мере необходимости», события недельной давности могли просто не дожить. Под аудит файлового сервера журнал увеличивают до сотен мегабайт и настраивают выгрузку в отдельное хранилище.
Причин три, и все практические.
Разбор инцидентов. Кто удалил, кто переименовал, кто выгрузил папку с договорами накануне увольнения. Без журнала это разговор на уровне «а я не я».
Наведение порядка в правах. Аудит показывает, кто реально работает с какими данными. Обычно выясняется, что половина доступов выдана «на всякий случай» и никем не используется - их можно смело снимать. Как устроены сами разрешения, разбирали в статье про права доступа к файлам в Linux; в Windows логика похожая, только вместо chmod - списки ACL.
Требования регуляторов. Если организация обрабатывает персональные данные, регистрация событий безопасности входит в состав обязательных мер защиты по 152-ФЗ и приказу ФСТЭК России № 21. Для объектов критической информационной инфраструктуры аналогичные требования идут от 187-ФЗ. Журналы доступа к файлам - часть доказательной базы при проверке. Что ещё спрашивают на такой проверке, собрано в материале про подготовку инфраструктуры к аудиту ИБ.
Встроенный аудит Windows бесплатен и уже установлен. Его потолок - анализ. Журнал Security хранит события в сыром виде, и собрать из тысяч записей внятный отчёт «что происходило с этой папкой за месяц» руками тяжело. Плюс события лежат на каждом сервере отдельно.
| Действие | Фиксируется встроенными средствами | Что для этого нужно |
|---|---|---|
| Чтение файла | Да | SACL с правом чтения, аудит успеха |
| Изменение файла | Да | SACL с правом записи |
| Удаление файла | Да | SACL с правом удаления; события 4663 (DELETE) и 4660 |
| Изменение прав доступа | Да | SACL со сменой разрешений; событие 4670 |
| Доступ по сети с IP клиента | Только через подробный аудит общего доступа | Событие 5145, высокий объём |
| Кто держит файл открытым | Да, но не аудитом | Get-SmbOpenFile или оснастка «Общие папки» |
| Отчёты и оповещения | Нет | Нужна внешняя система |
Коммерческие системы класса DCAP закрывают именно разбор: собирают события с нескольких серверов, строят отчёты, шлют оповещения. На российском рынке это «Гарда DCAP», SearchInform FileAuditor, 10-Strike; первые две есть в реестре отечественного ПО, что важно при требованиях по импортозамещению. Возможности у них заметно отличаются, и выбирать стоит после пилота на своих объёмах - универсального ответа тут нет.
Практическое правило: пока файловый сервер один и папок под наблюдением немного, встроенного аудита плюс выгрузки журнала хватает. Отдельную систему берут, когда серверов несколько или когда отчёты нужно показывать регулярно и не вручную.
Не включайте аудит на всё подряд. Microsoft в документации предупреждает об этом прямым текстом: без плана, что именно вы собираетесь анализировать, журнал заполнится бесполезными записями. Начните с каталогов, где лежат договоры, финансовая отчётность и персональные данные.
Разведите уровни важности. Попытка удалить папку с отчётностью - повод для оповещения. Чтение файла из общей папки - строка в журнале, и только.
Продумайте хранение. Сроки хранения журналов задаются вашими регламентами, но технически об этом надо позаботиться заранее: увеличить журнал Security, настроить выгрузку и следить за местом. Если данных много, под них выделяют отдельный файловый сервер или том.
Защитите сами журналы. Если у злоумышленника есть возможность подчистить логи, вся конструкция теряет смысл. Права на журналы - не ниже, чем на данные, а лучше - копия на отдельной машине, куда с файлового сервера доступа нет. Общие приёмы - как читать логи сервера в Windows и Linux - собраны в отдельной статье.
Файловый сервер не изолирован: он связан с Active Directory, резервным копированием, антивирусом, иногда с DLP. Аудит даёт им контекст. DLP поймала отправку конфиденциального файла - журнал файлового сервера покажет, откуда файл взяли и кто имел к нему доступ раньше.
Политики стоит пересматривать: за год меняются структура папок, состав отделов и набор угроз, а настройки аудита остаются от прошлой инфраструктуры.
И главное. Аудит бесполезен, если на результаты никто не смотрит. Назначьте ответственного, настройте оповещения на критичные события, заведите привычку раз в месяц пролистывать отчёт. Инструмент работает только тогда, когда его используют - иначе это просто журнал, который заполняется и затирается.
Если файловый сервер вырос из старой машины под столом и журналы уже некуда складывать, ищите отказоустойчивое решение: как собрать отказоустойчивый файловый сервер и как правильно настроить общую папку по SMB, разбирали отдельно.
Аудит имеет смысл, когда под ним есть железо с запасом: журналы, теневые копии и история версий едят место и дисковые операции. Подберём и соберём файловый сервер для офиса под ваш объём данных и число пользователей - с расчётом дисковой подсистемы под аудит и резервные копии.
11+ лет на рынке серверов, поставки по всей России. Позвоните +7 (800) 551-80-12 или напишите на info@ittelo.ru - подберём конфигурацию под ваши объёмы.
