Включить аудит доступа к файлам windows server 2012

Иногда бывает необходимо понять кто удалил/изменил/переименовал конкретный файл или папку. В ОС 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 2016. После настройки аудита, вы можете с помощью информации в журнале событий найти пользователя, который удалил на файловом сервере.

При удалении файла из сетевой папки, он удаляется сразу, а не отправляется в корзину пользователя. Список открытых по сети файлов в сетевой папке можно получить так.

Включаем политику аудита доступа к файлам и папкам в Windows

По умолчанию в Windows Server не включен аудит событий доступа к объектам на файловой системе. Вы можете включить и настроить аудит событий с помощью групповой политики. Если нужно включить политики аудита на нескольких серверах или компьютера, можно использовать доменные GPO (настраиваются с помощью консоли управления gpmc.msc). Если нужно настроить аудит только на одном сервере, можно воспользоваться локальной групповой политикой.

1. Запустите консоль редактора локальной политики –
   gpedit.msc
   ;
2. Перейдитевраздел GPO срасширенными политиками аудита Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Object Access;
3. Откройте политику Audit File System и укажите, что вы хотите сохранять в журнал только успешные события доступа к объектам файловой системы (Configure the following audit events -> Success);

   Также можно включить аудит доступа к локальным объектам с помощью политики Audit Object Access в разделе Windows Settings -> Security Settings -> Local Policy -> Audit Policy. Однако использование политики Audit File System предпочтительнее, поскольку она отслеживает только события NTFS.

   

4. Сохраните изменения и обновите настройки локальной групповой политики с помощью команды
   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 накладывает дополнительные расходы на ресурсы системы. Всегда старайтесь минимизировать количество объектов и событий аудита, которые нужно отслеживать.

Теперь, если пользователь удалит любой файл или папку в сетевой папке, в журнале безопасности системы появляется событие 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 для этого используется аудит доступа к объектам.

Аудит это запись в специальные журналы информации об определенных событиях (источник, код события, успешность, объект и т.д. ). Объектом аудита может являться как любой файл или папка, так и определенное событие, например вход в систему или выход из нее, то есть можно записывать все события происходящие с конкретным файлом или папкой — чтение, запись, удаление и т.д., можно события входа в систему и т.д.

Необходимо понимать, что аудит забирает на себя.

Для того, чтобы можно было настраивать аудит файлов и папок необходимо предварительно включить эту возможность через локальные (или в случае если у Вас используется Microsoft AD групповые) политики безопасности.

В случае локальных политик необходимо запустить оснастку “Локальная политика безопасности”, для этого необходимо нажать комбинацию клавиш Win+R, в открывшееся поле ввести secpol.msc и нажать клавишу Enter.

В открывшейся оснастке в дереве слева необходимо перейти в раздел “Локальные политики” — “Политика аудита”.

Далее необходимо выбрать необходимую нам политику — в данном случае это “Аудит доступа к объектам”. Именно этой политикой регулируется доступ к объектам файловой системы (файлам и папкам) и раскрыть ее двойным щелчком мыши. В открывшемся окне необходимо выбрать какие именно типы событий будут регистрироваться — “Успех” (разрешение на операцию получено) и/или “Отказ” — запрет операции и проставить соответствующие галочки, после чего нажать “Ок”.

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

Для этого необходимо открыть свойства файла или папки, перейти на вкладку “Безопасность”, нажать “Дополнительно” и “Аудит”.

Нажимаем “Добавить” и начинаем настраивать аудит.

Сначала выбираем субъект — это чьи действия будут аудироваться (записываться в журнал аудита).

Можно вписать туда имя пользователя или группы, если имя заранее неизвестно, то можно воспользоваться кнопкой “Дополнительно” которая открывает форму поиска где можно выбрать интересующих нас пользователей и группы. Чтобы контролировались действия всех пользователей необходимо выбрать группу “Все”.

Далее необходимо настроить тип аудируемых событий (Успех, Отказ, Все), также область область применения для аудита папок — только эта папка, папка с подпапками, только подпапки. только файлы и т.д., а также сами события аудита.

Для папок поля такие:

А такие для файлов:

После этого начнется сбор данных аудита. Все события аудита пишутся в журнал “Безопасность”. Открыть его проще всего через оснастку “Управление компьютером” compmgmt.msc.

В дереве слева выбрать “Просмотр событий” — “Журналы Windows” — “Безопасность”.

Каждое событие ОС Windows имеет свой код события. Список событий достаточно обширен и доступен на сайте Microsoft либо в интернете.

Попробуем например найти событие удаления файла, для этого удалим файл на котором предварительно настроен аудит (если это не тестовые файл, то не забываем сделать его копию, так как аудит это всего лишь информация о действиях, а не разрешение/запрет этих действий). Нам нужно событие с кодом 4663 — получение доступа к объекту, у которого в поле Операции доступа Написано “DELETE” . Поиск событий в журналах Windows достаточно сложен, поэтому обычно используются специализированные средства анализа — системы мониторинга, скрипты и т.д.

Вручную можно, например, задать например такой фильтр:

Далее в отфильтрованных событиях необходимо найти интересующее нас по имени объекта.

Открыть его двойным щелчком мыши и увидеть кто удалил данный файл в поле субъект.

Мы продолжаем перевод и публикацию материалов, связанных с 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

Как включить аудит доступа к файлам 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.

Источник