Управление ACL в PowerShell (часть 3, заключительная)

Contents of this directory is archived and no longer updated.

Управление ACL в PowerShell (часть 3, заключительная)

Примечание: данный пост перепечатан в связи с закрытием бложиков на spaces.live.com, как имеющий какую-то ценность для автора и/или читателей.

В предыдущих частях я рассказал как управлять ACL списками в PowerShell для файлов и папок NTFS. В этой, заключительной части я покажу:

управление ACL списками реестра;
смена владельца (Owner) объекта;
управление аудитом файловой системы и реестра.

Управление ACL списками реестра

ACL списки реестра в PowerShell управляются по такому же принципу, что и для объектов файловой системы NTFS. Отличия заключаются только в доступных разрешениях, уровнях наследования и именах используемых классов. Для установки разрешений на ключи реестра используется класс RegistryAccessRule. Список самих разрешений перечислен в RegistryRights Enumeration. Чтобы посмотреть этот список в PowerShell достаточно выполнить команду:

[C:\] [system.enum]::getnames([System.Security.AccessControl.RegistryRights])
QueryValues
SetValue
CreateSubKey
EnumerateSubKeys
Notify
CreateLink
Delete
ReadPermissions
WriteKey
ExecuteKey
ReadKey
ChangePermissions
TakeOwnership
FullControl

Получение списков ACL для ключей реестра производится так же как и для объектов файловой системы:

Get-Acl HKLM:\Software\Microsoft

Создание, удаление и базовые операции с ключами реестра достаточно наглядно и доступно рассказано в TechNet, поэтому здесь я не буду рассказывать про эти операции. Предположим, у нас есть ключ реестра HKLM\Software\AutoCAD на который группа Users имеет право чтения и мы хотим группе Users дать право WriteKey. Для этого по аналогии с назначением прав на объекты файловой системы сделаем следующее:

$ACL = Get-ACL HKLM:\Software\AutoCAD 
$AccessRule = new-object System.Security.AccessControl.RegistryAccessRule ("Users", "WriteKey", "Allow") 
$ACL.SetAccessRule($AccessRule) 
$ACL | Set-Acl HKLM:\Software\AutoCAD

Единственное отличие от варианта с файловой системой заключается в используемом классе, а именно: RegistryAccessRule вместо FileSystemAccessRule. Таким же образом и удаляются явно назначенные ключи реестра:

$ACL = Get-ACL HKLM:\Software\AutoCAD 
$AccessRule = new-object System.Security.AccessControl.RegistryAccessRule ("Users", "WriteKey", "Allow") 
$ACL.RemoveAccessRule($AccessRule) 
$ACL | Set-Acl HKLM:\Software\AutoCAD

Здесь я выделил только изменившийся метод, который теперь стал RemoveAccessRule и удаляет необходимые разрешения. Наследование тоже отменяется схожим методом:

$ACL = Get-ACL HKLM:\Software\AutoCAD 
$ACL.SetAccessRuleProtection($True, $True) 
$ACL | Set-Acl HKLM:\Software\AutoCAD

Т.е. на этих примерах видно, что управление ACL реестра из PowerShell абсолютно такое же, отличи тут только одно - используемые классы управления. И в завершении разговора об управлении ACL реестра из PowerShell добавлю лишь информацию о глубине действия устанавливаемых разрешений:

This key - без флагов. По умолчанию при назначении разрешений, они применяются только на конкретный ключ
This key and subkeys - CI, None
Subkeys only - CI, IO

Смена владельца для объекта

К сожалению по некоторым причинам управление владельцами объектов затруднено, но, тем не менее, некоторые возможности присутствуют - это назначение владельцем себя самого или своей группы. Предположим, есть некоторый ресурс, владельцем которого является рядовой пользователь и во время выполнения скрипта администратору необходимо перехватить владение объектом на себя, т.е. стать новым владельцем ресурса. Делается это по схожей аналогии как мы добавляли в предыдущем примере пользователя в список доступа к ресурса и назначали ему право Modify. Итак:

# сперва считаем список ACL (включая список Owner) из папки Test в переменную 
$ACL=Get-Acl C:\Test 
# Теперь создадим новый объект пользователя или группы, которая должна будет стать владельцем и этот объект
# присвоим в переменную. Объект пользователя для установки его во владение создаётся
# через класс System.Security.Principal.NTAccount. В этой строке имя пользователя будет преобразовано в
# объект с SID'ом, т.к. в записях ACL фигурируют только SID'ы участников безопасности, которые имеют какой-
# либо доступ к ресурсу. 
$Account = new-object system.security.principal.ntaccount("Administrator") 
# теперь нужно передать созданный объект из переменной $Account в переменную списка ACL, которую мы
# получили в первой строке. Так же укажем конкретный ACE в который нужно записать нашего пользователя. В
# данном случае это Owner и задаётся он действием SetOwner. 
$ACL.SetOwner($Account) 
# теперь переменная $ACL содержит уже изменённый список ACL для ресурса с новым владельцем. В этом можно
# убедиться набрав $ACL | Format-List. Однако, это ещё содержится только в переменной, поэтому последней
# строкой мы применим этот список ACL для папки Test 
$ACL | Set-Acl C:\Test

Вот таким образом можно спокойно перехватывать владение объектом. Но, при этом пользователь из под которого выполняется данный скрипт должен иметь следующие права:

право Take Ownership для данного объекта, либо иметь право Take Ownership в локальной политике безопасности;
право Read Permissions для конкретного объекта;
право Change Permissions для конкретного объекта;
право Restore files and directories (SeRestore Privilegy) в локальной политике безопасности.

Примечание: к сожалению в PowerShell пока что нету механизма установки в качестве владельца другого пользователя или группы. Можно только назначить владельцем либо себя, либо свою группу. С чем это связано мне пока точно неизвестно, но данный вопрос уже отправлен спецам по PowerShell, которые, возможно, смогут помочь как-то разъяснить ситуацию.

Управление аудитом объектов файловой системы и реестра из PowerShell

Назанчение правил аудита доступа к объектам файловой системы и реестра назначаются точно по таким же принципам, что и установка разрешений безопасности. Разница здесь лишь в используемых классах. Здесь коротко опишу класс и его методы.

Для файловой системы основным классом является FileSystemAuditRule, который содержит в себе такие методы как (перечислю наиболее часто используемые):

AddAuditRule - добавляет правила аудита на объект файловой системы;
SetAuditRule - устанавливает правила аудита на объект файловой системы (заменяет имеющийся);
SetAuditRuleProtection - устанавливает наследование правил аудита от родительского объекта;
RemoveAuditRule - удаляет правила аудита доступа;
PurgeAuditRules - очищает весь список аудита доступа к объектам.

Вообще, весь список методов описан в классе FileSystemSecurity и который можно просмотреть здесь:

http://msdn.microsoft.com/en-us/library/system.security.accesscontrol.filesystemsecurity_methods(VS.80).aspx

Для аудита реестра используется класс RegistryAuditRule, который содержит похожие методы, что и для файловой системы и полный список методов описан в классе RegistrySecurity:

http://msdn.microsoft.com/en-us/library/system.security.accesscontrol.registrysecurity_methods(VS.80).aspx

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

Comments:

Comments are closed.