План аудита доступа к файлам 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

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

Настройка аудита событий удаления файлов из конкретной папки

Теперь нужно настроить аудит в свойствах общей сетевой папки, доступ к которой вы хотите отслеживать. Запустите проводник и откройте свойства общей папки. Перейдите на вкладку 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.

$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. Как вы видите, в нем есть информация об имени удаленного файла и учетной записи пользователя, который удалил файл.

После настройки аудита, найдите в журнале 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));

Если вы хотите использовать Microsoft SQL, обратите внимание на статью “Как выполнить запрос к MSSQL Server из скрипта PowerShell?”.

Для получения событий с EventID 4663 из журнала Security за текущий день можно использовать такой PowerShell скрипт:

$today = get-date -DisplayHint date -UFormat %Y-%m-%d
Get-WinEvent -FilterHashTable @ | 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)\MySQL\MySQL Connector Net 6.9.8\Assemblies\v4.5\MySql.Data.dll’
$Connection = [MySql.Data.MySqlClient.MySqlConnection]@
$Connection.Open()
$sql = New-Object MySql.Data.MySqlClient.MySqlCommand
$sql.Connection = $Connection
$today = get-date -DisplayHint date -UFormat %Y-%m-%d
Get-WinEvent -FilterHashTable @ | 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)\MySQL\MySQL Connector Net 6.9.8\Assemblies\v4.5\MySql.Data.dll’
$Connection = [MySql.Data.MySqlClient.MySqlConnection]@
$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 появится имя пользователя и время удаления файла.

Скрипт сброса данных из журнала в БД можно выполнять один раз в конце дня по планировщику или повесить триггер на событие удаления (On Event), что более ресурсоемко. Все зависит от требования к системе.

Можно создать реагировать простую веб страницу на php для получения информации о событиях удаления файлов в более удобном виде. Задача решается силами любого php программиста за 1-2 часа.

Запись информации о событиях удаления файлов в текстовый файл

Если вы не хотите вести отдельную БД, можно сохранять события аудита удалений файлов в текстовый лог файл. Воспользуйтесь таким PowerShell скриптом:

$Outfile = «C:\ps\delete-file-log.txt»
$today = get-date -DisplayHint date -UFormat %Y-%m-%d
Get-WinEvent -FilterHashTable @ | 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
>
>

Итак, мы предложили идею и некий общий каркас системы аудита и хранения информации об удаленных файлах в сетевых шарах, при желании ее с лёгкостью можно будет модифицировать под ваши нужды.