Acl группы доступа windows

Управление NTFS разрешениями на папки и файлы из PowerShell

Встроенные командлеты для управления ACL в NTFS: Get-Acl и Set-Acl

В PowerShell v5 (Windows 10 / Windows Server 2016) для управления ACL имеется два отдельных встроенных командлета (входят в модуль Microsoft.PowerShell.Security):

Мы не будем подробно останавливаться на этих встроенных командлетах, т.к. их функционал в большинстве случае недостаточен для управления NTFS разрешениями в реальных задачах. Рассмотрим лишь несколько типовых примеров их использования.

Выведем текущего владельца папки (файла) и список назначенных NTFS разрешений:

get-acl C:\Drivers\ |fl

Path : Microsoft.PowerShell.Core\FileSystem::C:\Drivers\
Owner : WORKSTAT1\root
Group : WORKSTAT1\Отсутствует
Access : NT AUTHORITY\Authenticated Users Allow Modify, Synchronize
NT AUTHORITY\SYSTEM Allow FullControl
BUILTIN\Администраторы Allow FullControl
BUILTIN\Пользователи Allow ReadAndExecute, Synchronize
WORKSTAT1\root Allow Modify, Synchronize
Audit :
Sddl : O:S-1-5-21-3650440056-3766451173-3310994491-1001G:S-1-5-21-3650440056-766451173-3310994491-513D:PAI(A;OICI;0x 1301bf;;;AU)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)(A;OICI;0x1301bf;;;S-1-5-21-3650440056-37664 51173-3310994491-1001)

Можно вывести только списки NTFS разрешений в более понятном формате:

С помощью следящей команды можно скопировать NTFS разрешения с одной папки и применить их на другую:

Get-Acl C:\Drivers | Set-Acl C:\Distr

Главная проблема при использовании Set-ACL – командлет всегда пытается сменить владельца ресурса, даже если вы просто хотите изменить NTFS разрешения. В результате, чтобы добавить права на объект нужно использовать такую конструкцию:

Чтобы отключить наследование для папки из PowerShell:

Используем модуль NTFSSecurity для управления разрешениями из PowerShell

Импортируйте модуль NTFSSecurity в сессию PowerShell:

Выведем список команд, доступных в модуле (доступно 36 командлетов):

Выведем текущие NTFS разрешения на каталог:
Get-Item ‘c:\distr’ | Get-NTFSAccess

Как вы видите, текущие разрешения представлены в более удобной форме.

Чтобы предоставить права только на верхнем уровне и не изменять разрешения на вложенные объекты (только на папку), используйте команду:

Удалить назначенные NTFS разрешения:

Следующей командой можно лишить указанную учетную прав на все вложенные объекты в указанной папке (наследованные разрешения будут пропущены):

Следующей командой можно назначить учетную запись Administrator владельцем всех вложенных объектов в каталоге:

Чтобы очистить все разрешения, назначенные на объекты каталога вручную (не будет удалены унаследованные разрешения):

Включить NTFS наследование для всех объектов в каталоге:

Чтобы вывести все разрешения, которые назначены вручную, исключая унаследованные разрешения:

dir C:\distr | Get-NTFSAccess –ExcludeInherited

Можно вывести разрешения, назначенные для определенного аккаунта (не путайте с эффективными разрешениями, речь о них ниже):

Проверка эффективных NTFS разрешений на объекты из PowerShell

Либо вы можете проверить эффективные разрешения на конкретный файл:

Источник

ACL: в поисках идеального решения

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

Эволюция системы разделения прав

Обычно разделение прав эволюционирует так:

Сначала делают флаг admin в таблице user.

Потом оказывается, что кроме админов бывают и другие типы пользователей. Добавляют группы (предопределенный набор). Права и группы жестко связаны. Соотношение между группами и пользователями один ко многим. Так часто бывает потому, что разделение прав связывают с организационной иерархией.

Дальше конечные пользователи хотят сами создавать группы и раздавать им права.

Следующая ступень — некоторым пользователям нужны права, выходящие за рамки их группы. Тут есть такие варианты:

С технической точки зрения есть неудобный момент — работа с «древовидной» структурой в реляционной базе. Например, для получения списка прав: сначала придётся получить все родительские группы, потом нужно будет сделать join на таблицу прав. После получения всего списка из базы к нему нужно будет применить правила разрешения конфликтов. В MySQl иногда используют для этого «хак» c GROUP BY и ORDER, но это решение не портабельное, так как такое поведение GROUP BY не соответствует спецификации SQL.

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

Так же скорее всего придётся столкнуться с проблемой «синхронизации» между кодом и базой. Чтобы права были редактируемые — их нужно хранить в базе. Но функции, которые отвечают за исполнение разделения прав, хранятся в коде.

Как надо было делать

Уже видя, что из этого может получиться, можно сделать следующие выводы:

Сразу писать систему разделения прав с расчётом на более чем две группы (админы и не админы).

Следующая тонкость — в моем описании есть небольшая подмена понятий. Группа (которая отражает принадлежность к иерархической структуре в реальном мире) и группа (роль) в системе разделения прав не всегда одно и тоже. Специально оставил, так как сам наступал на эти грабли (думаю, не я один). Нужно разделить понятия группа и роль. Тогда можно будет сделать соотношение между ролями и пользователями многие ко многим.

При соотношении многие ко многим уходит проблема с «экстра» правами и наследованием групп. Экстра права выносятся в отдельные роли, которые добавляются пользователю, кроме «основной» роли.

Решение конфликтов тоже упрощается: так как структура прав «плоская», то и сами права будут простые. Например, могут быть такие правила:

Реализация

Опишу реализацию на примере веб приложения, которое следует MVC паттерну. В таком приложении права можно разграничивать на уровне контроллера и/или на уровне модели. Так же ACL должен предоставлять хелперы для представления (view).

Базовый интерфейс (Базовый модуль)

Необходимый минимум для работы ACL.

Cамая базовая функция, которая должна быть в любом ACL, отвечающая на вопрос, есть ли у данного пользователя право на данное действие с данным ресурсом:

Функция для вызова в контроллере _ для проверки, есть ли доступ у текущего пользователя. При этом предполагается, что контроллер предоставляет метод для получения текущего пользователя (CoC).

В случае, если доступа нет, то будет передано управление обработчику ошибок неавторизованного доступа. В зависимости от ЯП это можно сделать через исключения или через колбеки.

Должна быть возможность задавать свой способ обработки ошибок не авторизованного доступа. Например, если используется исключения, то в базовом классе контроллера можно задать обработчик так:

Должна быть возможность задать проверку для всех контроллеров разом. Чтобы не надо было в каждом контроллере ставить вызов authorize. В зависимости от технологии это можно сделать или в базовом классе контроллера или с помощью программной прослойки (middleware).

Для базового интерфейса не принципиально устройство групп. Это сделано специально, чтобы его можно было легко внедрять в существующие проекты с целью переделывать по кускам. Базовый интерфейс даже сможет работать с флагом admin в таблице user. Для этого нужно будет реализовать кусок кода, который отвечает за определение прав по пользователю. Например:

Модуль ролей

Предполагается, что модель пользователя предоставляет метод для получения ролей пользователя (CoC).
Если группы не нужно хранить в базе, то задание прав происходит с помощью DSL.

Модуль атрибутов

Рассмотрим пример: автор может делать все CRUD операции со статьями. Но редактировать, удалять статьи, а также просматривать черновики он может только свои. Т.е. получается, что теперь не все статьи одинаковы. Такое разделение прав решается введением атрибутов для ресурсов.
Первый параметр — черновик или нет (draft=true/false); второй — принадлежит ли автору (own).
Итого:

Для поддержки таких атрибутов нужно будет реализовать вспомогательные функции (helpers). Для работы с инстансом модели (ресурсом):

Для работы с методом получения данных (списка) из базы.

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

При вызове этой функции произойдет обращение к модулю разделения прав. Если задать пользователя на уровне модуля разделения прав, то не нужно будет указывать пользователя в каждом вызове этого метода.

К ресурсу можно применить более одного атрибута, при этом условия атрибутов должны складывать по правилам логического и.

Хранение в базе

Описанная структура легко сохраняется в базу.

Пользователь, Роль — n к n; Роль, Право — n к n; Право, Ресурс — n к 1; Право, Атрибут — n к n; Право, Действие — n к 1;

Задание начальных значений

В системе должны быть настройки по умолчанию. Чтобы не зависеть от реализации базы для задания начальных значений можно использовать все тот же DSL (функция allow).

Интерфейс редактирования прав

Под редактированием понимается возможность создавать, удалять роли и возможность редактировать права роли. Для создания права можно будет выбрать ресурс, действие и атрибуты из предопределённого набора. Чтобы с этим мог работать конечный пользователь они должны иметь человеко-понятный вид (а не вид костант, которые используются в коде).
Соответственно в базе нужно хранить этот предопределённый набор и человеко-понятное обозначение констант.

Форма создания/редактирования прав

Должны быть такие поля:

Синхронизация

Задания для поддержки синхронности между кодом и базой, а так же для проверки целостности лучше сразу автоматизировать (написать скрипты), так как их придётся выполнять много раз.

Сбор данных из кода

Сначала надо собрать все данные по коду.

Сбор ресурсов

Ресурсами могут выступать модели или контроллеры (они же маршруты или route). Модели легко собрать, по идеологии MVC они должны находиться отдельно (в отдельной папке). При сборе маршрутов тоже не должно возникнуть проблем. В современных MVC фреймворках задание маршрута выглядит примерно так:

Естественно можно собирать оба вида ресурсов или только один в зависимости от потребностей.

Сбор атрибутов

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

Сбор действий

Есть 4 стандартных действия для моделей (CRUD) и одно действие для маршрута (access). Все остальные действия можно искать по коду текстовым поиском (по функции allow, authorize итп).

Из кода в базу

После сбора данных по коду нужно сложить их в промежуточное хранилище (файл). Тогда в этот же файл можно будет добавлять человекопонятные описания. Так же это позволить обойти несовершенство алгоритма сбора (поиска) данных по коду. Допустим, алгоритм не находит некоторые данные в коде (скорее всего действия). Тогда их можно будет дописать в файл «руками». При следующем запуске алгоритм опять не найдёт эти же данные и удалит их из файла. Чтобы этого не происходило, их надо пометить, как добавленные вручную, чтобы скрипт синхронизации не пытался их удалить. Получившийся файл надо хранить в системе контроля версий вместе с кодом.

При доставке обновлений или при разворачивании системы на другом железе (deployment) нужно будет запустить скрипт синхронизации. Скрипт считает данные из файла. Сделает проверку, что нет конфликтов — не удалены данные, которые ещё участвуют в разделении прав. После чего запишет новые данные в базу. Дальше добавит новые права по умолчанию (если есть еще один файл с правами по умолчанию).

Формат файла

При автоматической сборке данных в файл могут попадать «лишние» данные, которые не нужно отображать в интерфейсе редактирования (не нужно добавлять в базу). Для таких данных нужно ввести признак того, что их не нужно сохранять в базу (например, значение false вместо описания).

Последний штрих

Надо не забыть добавить хелперы для тестирования.

То что не попало в статью

Поля (параметры, свойства) моделей как атрибуты

Изначально я хотел собирать не только функции (хелперы) атрибутов, но и все поля моделей, чтобы можно было с ними сравнивать (draft=false, amount>100). Но понял, что это не очень хорошая идея и вот почему:

Разделение прав на уровне полей модели

Решение пока только «на бумаге». Во время реализации могут найтись подводные камни или идеи получше. Публикую статью, чтобы хабрачитатели указали на недочёты в моем подходе и предложили свои идеи.

UPD
Начал отвечать на комментарии, думать над реализацией и сразу нашел ошибки:

Должна быть возможность задать проверку для всех контроллеров разом. Чтобы не надо было в каждом контроллере ставить вызов authorize. В зависимости от технологии это можно сделать или в базовом классе контроллера или с помощью программной прослойки (middleware).

Источник

Создание и изменение в Powershell NTFS разрешений ACL

Основной способ ограничения доступа к файлам и папкам дает файловая система NTFS с ее таблицами ACL. Это может быть право только на чтение файла (открытие и просмотр), на чтение и запись (открытие, просмотр, изменение и сохранение) и многие другие. Такие права мы чаще устанавливаем через GUI назначая права не конечному пользователю, а группе в которой он состоит. Все действия по созданию и изменению мы так же можем сделать через Powershell.

Навигация по посту

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

Основы разрешений

Оба этих типа разрешений хранятся в специальной таблице MFT (Master File Table).

Основное средство для редактирования этих разрешений в GUI можно увидеть зайдя в свойства файла или папки:

В области 4 выделены следующие разрешения:

Чаще всего мы работаем с разрешениями выше, но есть еще один список с возможностью настройки прав более тонко:

Групповые разрешения могут принимать флаги Allow и Deny, которые разрешат или запретят указанные действия. Указывать разрешения для пользователей через Deny считается плохой практикой и практически не используется.

Кроме этого существует наследование:

Наследование помогает установить разрешения для одной папки так, что оно будет применяться ко вложенным файлам и папкам. Если наследование отключить (2), то у нас будет возможность убрать все наследуемые разрешения или оставить их.

Функции по работе со строками в Powershell

Получение текущих разрешений в Powershell

На примере ниже я верну разрешения для папки «C:\TestFolder\»

В области 1 выделен владелец папки, а под областью 2 отображаются все группы и пользователи с правами.

Мы можем проверять права не только локальной, но и сетевой папки. На примере ниже возвращена та же папка:

Поиск всех папок с правами у определенной группы

Представим, что мы хотим проверить права данные определенной группе. Мы можем заходить в свойства каждой папки и смотреть вкладку «Безопасности», а можем сделать это через Powershell.

Обычно у нас есть какой-то каталог с общим доступом с папками внутри, на которые мы выдаем разрешения. В моем случае такой каталог «Moscow», а на папки внутри я уже даю права:

В следующем примере я узнаю на какие папки установлены разрешения для TestGroup:

Изменение, копирование и добавление разрешений

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

Для создания нового объекта с правами используется класс «FileSystemAccessRule», который в команде будет выглядеть так:

Расшифровать значения можно следующим образом:

Изменение и добавление прав у пользователя и групп

Допустим у нас есть пользователь «Test User (001)» с возможностью чтения папки «Folder1» и мы хотим добавить еще права на запись. Это будет выглядеть так:

Наследование типа ‘ContainerInherit, ObjectInherit’ говорит о том, что оно касается этой папки и всех вложенных папок и файлов.

Таким же образом работает добавление новой группы или пользователя в список ACL:

Права, которые мы можем дать имеют сокращенное название и они отображены далее:

При этом вы можете применить набор разрешений, например в виде Write, но результат будет отображаться в виде «Special Premission»:

Если бы я указал наследование в виде ‘ContainerInherit, ObjectInherit’, то права бы применились как нужно:

Поэтому я рекомендую смотреть существующие разрешения на примере того, как я сделал это выше.

Удаление прав у пользователя или группы

Для удаления всех разрешений есть метод «RemoveAccessRuleAll». Работает он так же:

Смена владельца

Смена владельца файла или папки делается через метод SetOwner. Этот метод, в качестве идентификатора, принимает SID пользователя и что бы его узнать нужно использовать класс «System.Security.Principal.Ntaccount». На практике это выглядит так:

Как отсортировать в Powershell объекты через Sort-Object

Включение или отключение наследования папок и файлов

Для управления наследованием используется метод «SetAccessRuleProtection», который устанавливает следующее:

Сбор всех прав и их экспорт в CSV

Учитывая примеры выше мы можем временно собирать отчеты по выданным правам. Пример того, как может выглядеть отчет:

Источник

Управление ACL из PowerShell

Как вы знаете, в файловой системе NTFS каждый объект (файл или папка) имеет свой список контроля доступа (Access Control List, ACL). ACL определяет, кто (или что) имеет доступ к объекту, и какие операции разрешено (или запрещено) этому субъекту проводить над объектом.

В PowerShell для управления ACL есть целых два командлета:

• Get-ACL — извлекает список ACL для объекта. Полученные данные можно передать для дальнейшей обработки (напр. по конвейеру) или просто сохранить в файл;
• Set-ACL — устанавливает новые или изменяет существующие списки ACL для объекта.

В качестве самого простого примера скопируем разрешения одной папки на другую:

Get-Acl C:\test | Set-Acl C:\test2

Сравним ACL до и после. Как видите, изменения налицо.

При копировании ACL нужно иметь в виду, что пользователь, под которым выполняется эта операция, должен являться владельцем (Owner) исходного ресурса (в примере это папка Test) и обладать правом Take Ownership. Дело в том, что при переносе разрешений нельзя перенести другого владельца. Если владельцем папки Test является текущий пользователь и он обладает правом Take Ownership, то все разрешения включая владельца будут скопированы на папку Test2. Если же одно из условий не выполняется, то будет выдана ошибка.

В списке будут показаны как основные, так и детальные разрешения (обычно они показываются на вкладке Advanced).

Для примера попробуем дать пользователю Testuser1 полные права на папку Test2:

#считываем текущий список ACL папки Test2
$acl = Get-Acl C:\Test2;
#Cоздаем переменную с указанием пользователя, прав доступа и типа разрешения
$AccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule (″Testuser1″,″FullControl″,″Allow″);
#Передаем переменную в класс FileSystemAccessRule для создания объекта
$acl.SetAccessRule($AccessRule);
#Применяем разрешения к папке
$acl | Set-Acl c:\Test2;

По умолчанию созданное правило дает пользователю права только на саму папку. Если требуется распространить данное правило на дочерние объекты, то в создаваемом правиле потребуется дополнительно указать параметры наследования:

Например такое правило будет распространяться на саму папку и все ее содержимое:

$AccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule (″Testuser1″,″FullControl″,″ContainerInherit,ObjectInherit″,″None″,″Allow″)

Удаление разрешений производится по такой же схеме, что и добавление, только вместо метода SetAccessRule будет использоваться метод RemoveAccessRule:

$acl = Get-Acl C:\Test2;
$AccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule (″Testuser1″,″FullControl″,″Allow″);
$acl.RemoveAccessRule($AccessRule);
$acl | Set-Acl c:\Test2;

И еще один момент. Метод SetAccessRule полностью заменяет разрешения для пользователя. Поэтому, если нужно добавить новые права к уже имеющимся, то используем метод AddAccessRule.

Для удаления всех разрешений пользователя (полное удаление из ACL) используется метод PurgeAccessRules, для работы которого в качестве параметра нужно передать имя пользователя или группы. В работе этого метода есть одна особенность — он не умеет работать со строковыми значениями имён пользователей и групп, поэтому нужен механизм преобразования строковых значений в SID. Для примера удалим группу Users из списка доступа папки Test2:

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

По умолчанию вновь созданный объект наследует разрешения от родителя. Для примера создадим новый объект (папку Test3) и отключим у нее наследование:

#Создаем новую папку и выводим ее ACL
md C:\Test3 | Get-Acl | fl;
#Считываем ACL папки Test3
$acl = Get-Acl C:\Test3;
#Отключаем наследование и удаляем все унаследованные разрешения
$acl.SetAccessRuleProtection($true,$false);
#Применяем ACL к папке Test3
$acl | Set-Acl C:\Test3;

Если теперь посмотреть на разрешения папки Test3, то в поле Access мы увидим пустоту. И не удивительно, ведь все наследуемые разрешения мы удалили, а явно заданных у нее не было. Теперь доступ к папке сможет получить только ее владелец (Owner).

И раз речь зашла о владельце. Владельцем объекта автоматически становится пользователь, этот объект создавший (Creator Owner). Есть политика Take Ownership, позволяющая захватывать права владения объектом. По умолчанию это право есть только у членов группы локальных администраторов.

Для управления владельцами объектов в PowerShell используется метод SetOwner. В качестве примера поменяем владельца папки Test2:

#Считываем ACL
$acl = Get-Acl C:\Test2;
#Преобразуем строковый параметр группы Administrators в SID
$group = New-Object System.Security.Principal.Ntaccount(″Administrators″);
#Применяем метод SetOwner
$acl.SetOwner($group);
#Применяем ACL к объекту
$acl | Set-Acl C:\Test2;

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

• Право Take Ownership для данного объекта;
• Права Read и Change Permissions для данного объекта;
• Право Restore files and directories в локальной политике безопасности.

Ну вроде все. Список методов, использующихся для управления ACL, подробно описан в классе FileSystemSecurity на MSDN. Подробнее о разрешениях NTFS можно почитать здесь.

Источник