Списки управления доступом
Список управления доступом на уровне пользователей (DACL) определяет доверенные лица, которым разрешен или запрещен доступ к защищаемому объекту. Когда процесс пытается получить доступ к защищаемому объекту, система проверяет ACE в списке DACL объекта, чтобы определить, следует ли предоставить доступ к нему. Если у объекта нет DACL, система предоставляет полный доступ для всех. Если DACL объекта не имеет записей ACE, система отклоняет все попытки доступа к объекту, так как список DACL не разрешает права доступа. Система проверяет ACE по порядку, пока не обнаружит один или несколько записей ACE, которые разрешают все запрошенные права доступа, или пока не будут отклонены все запрошенные права доступа. Дополнительные сведения см. в статье Управление доступом к объекту в DACL. Сведения о том, как правильно создать список DACL, см. в разделе Создание списка DACL.
Системный список управления доступом (SACL) позволяет администраторам регистрировать попытки доступа к защищенному объекту. Каждый элемент ACE указывает типы попыток доступа с помощью указанного доверенного лица, которое приводит к тому, что система создает запись в журнале событий безопасности. Элемент управления доступом в списке SACL может создавать записи аудита при неудачной попытке доступа, при успешном или в обоих случаях. Дополнительные сведения о SACL см. в разделе Создание аудита и право доступа к SACL.
Не пытайтесь работать непосредственно с содержимым ACL. Чтобы обеспечить семантическую правильность списков ACL, используйте соответствующие функции для создания ACL и управления ими. Дополнительные сведения см. в разделе Получение сведений из ACL и Создание или изменение списка управления доступом.
Списки ACL также обеспечивают управление доступом к объектам службы Microsoft Active Directory Directory. Active Directory интерфейсов служб (ADSI) включают подпрограммы для создания и изменения содержимого этих списков ACL. Дополнительные сведения см. в разделе Управление доступом к Active Directory объектам.
Список управления доступом (ACL).
в Windows 7/8/10 17.07.2020 0 185 Просмотров
Список управления доступом (ACL) – это любой механизм для реализации управления доступом в ОС, файловой системе, службе каталогов или другом программном обеспечении. Списки управления доступом (ACL) внедрены в базовую архитектуру операционных систем платформ Microsoft Windows и используются для управления доступом к объектам в Active Directory и файлам на томах NTFS.
Список управления доступом – это в основном список, прикрепленный к объекту, определяющий, какие субъекты безопасности (пользователи, группы, компьютеры и т. д.) имеют доступ к объекту и какой уровень доступа им разрешен. В Windows 7 списки управления доступом правильнее называть дискреционными списками управления доступом (DACL), поскольку они могут настраиваться и управляться администраторами по своему усмотрению.
Существует также другой тип ACL в Windows, называемый System access control list (SACL), который используется для управления генерацией сообщений аудита, когда аудит объектов был настроен в файловой системе.
Список контроля доступа к системе (SACL)
Системный список управления доступом (SACL) позволяет администраторам регистрировать попытки доступа к защищенному объекту. Каждый ACE определяет типы попыток доступа указанного доверенного лица, которые заставляют систему генерировать запись в журнале событий безопасности. ACE в SACL может генерировать записи аудита, когда попытка доступа терпит неудачу, когда она успешна, или и то, и другое. Дополнительные сведения о SACLs см. В разделе генерация аудита и право доступа к SACL.
Списки управления доступом изначально реализованы на некоторых платформах операционных систем UNIX, таких как Solaris (который впервые реализовал ACL в версии 2.5.1), а также доступны в качестве стороннего программного обеспечения для других платформ UNIX.
Традиционно управление доступом в файловых системах UNIX осуществлялось с помощью команды chmod (change mode), но это обеспечивало лишь ограниченный или грубый контроль разрешений на доступ к файлам и не обеспечивало гибкости для настройки уникальных наборов разрешений на доступ для конкретных пользователей или групп.
Зачем использовать ACL?
Основная идея использования ACL заключается в обеспечении безопасности вашей сети. Без него любой трафик может либо входить, либо выходить, что делает его более уязвимым для нежелательного и опасного трафика.
Для повышения безопасности с помощью ACL можно, например, запретить определенные обновления маршрутизации или обеспечить управление потоком трафика.
Как показано на рисунке ниже, устройство маршрутизации имеет ACL, который запрещает доступ хосту C в финансовую сеть, и в то же время он разрешает доступ к хосту D.
С помощью ACL вы можете фильтровать пакеты для одного или группы IP-адресов или различных протоколов, таких как TCP или UDP.
Так, например, вместо блокировки только одного хоста в команде разработчиков, вы можете запретить доступ ко всей сети и разрешить только один. Или вы также можете ограничить доступ к хосту C.
Если инженеру с хоста С необходимо получить доступ к веб-серверу, расположенному в финансовой сети, можно разрешить только порт 80, а все остальное заблокировать.
Создание политик безопасности с использованием расширенных списков управления доступом для портов
Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016
В этом разделе содержатся сведения о расширенных списках управления доступом к портам (ACL) в Windows Server 2016. Можно настроить расширенные списки ACL на виртуальном коммутаторе Hyper-V для разрешения и блокировки сетевого трафика, передающегося между виртуальными машинами, подключенными к коммутатору через виртуальные сетевые адаптеры.
В этом разделе содержатся следующие подразделы.
Подробные правила списков ACL
Расширенные списки управления доступом виртуального коммутатора Hyper-V позволяют создавать подробные правила, которые можно применять к отдельным сетевым адаптерам виртуальных машин, подключенным к виртуальному коммутатору Hyper-V. Возможность создания подробных правил позволяет предприятиям и поставщикам облачных служб (CSP) устранять угрозы сетевой безопасности в многоклиентской среде общего сервера.
Используя расширенные списки ACL, вместо того чтобы создавать общие правила, блокирующие или разрешающие весь трафик, передающийся между виртуальными машинами по всем протоколам, вы можете блокировать или разрешать сетевой трафик отдельных протоколов, работающих на виртуальных машинах. можно создать расширенные правила ACL в Windows Server 2016, которые включают в себя следующий набор параметров из пяти кортежей: исходный ip-адрес, ip-адрес назначения, протокол, исходный порт и порт назначения. Кроме того, каждое правило может определять направление сетевого трафика (входящий или исходящий) и поддерживаемое действие (блокировать или разрешать трафик).
Например, можно настроить для виртуальной машины списки ACL для портов так, чтобы разрешать весь входящий и исходящий трафик HTTP и HTTPS на порте 80 и блокировать сетевой трафик всех прочих протоколов на всех портах.
Эта возможность задать трафик протокола, который разрешено или запрещено получать клиентским виртуальным машинам, обеспечивает гибкость при настройке политик безопасности.
Настройка правил списков ACL с помощью Windows PowerShell
Для настройки расширенного списка ACL необходимо использовать команду Windows PowerShell Add-VMNetworkAdapterExtendedAcl. У этой команды четыре разных типа синтаксиса со своими отдельными функциями:
Добавьте расширенный список ACL для всех сетевых адаптеров именованной виртуальной машины, который указывается первым параметром-VMName. Синтаксис:
Если требуется добавить расширенный список ACL к одному сетевому адаптеру, а не ко всем, можно указать сетевой адаптер с параметром-Вмнетворкадаптернаме.
Добавление расширенного списка ACL для конкретного виртуального сетевого адаптера на определенной виртуальной машине. Синтаксис:
Добавление расширенного списка ACL для всех виртуальных сетевых адаптеров, зарезервированных для использования операционной системой управления узлами Hyper-V.
Если требуется добавить расширенный список ACL к одному сетевому адаптеру, а не ко всем, можно указать сетевой адаптер с параметром-Вмнетворкадаптернаме.
добавьте расширенный список ACL к объекту виртуальной машины, созданному в Windows PowerShell, например $vm = get-VM «my_vm». В следующей строке кода можно выполнить эту команду для создания расширенного списка ACL со следующим синтаксисом:
Примеры подробных правил списков ACL
Далее приведены несколько примеров возможного использования команды Add-VMNetworkAdapterExtendedAcl для настройки расширенных списков ACL для портов и для создания политик безопасности виртуальных машин.
Значения параметра правила Направление в таблице ниже определяются направлением потока трафика (входящий или исходящий) виртуальной машины, для которой создается правило. Если виртуальная машина принимает трафик, он является входящим, если отправляет — исходящим. Например, если к виртуальной машине применяется правило, блокирующее входящий трафик, направление входящего трафика будет от внешних ресурсов к виртуальной машине. Если применяется правило, блокирующее исходящий трафик, направление исходящего трафика будет от локальной виртуальной машины к внешним ресурсам.
Применение политик безопасности на уровне приложения
Поскольку многие серверы приложений используют стандартизированные порты TCP/UDP для взаимодействия с клиентскими компьютерами, можно легко создать правила, блокирующие или разрешающие доступ к серверу приложений, путем фильтрации трафика, поступающего на порт, назначенный приложению, и отправляемого с этого порта.
Например, можно разрешить пользователю вход на сервер приложений в центре обработки данных при помощи подключения к удаленному рабочему столу (RDP). Так как RDP использует порт TCP 3389, можно настроить следующее правило:
| Исходный IP-адрес | Конечный IP-адрес | Протокол | Исходный порт | Конечный порт | Направление | Действие |
|---|---|---|---|---|---|---|
| * | * | TCP | * | 3389 | В | Allow |
Далее приведены два примера создания правил с помощью команд Windows PowerShell. В первом примере правило блокирует весь трафик к виртуальной машине с именем «ApplicationServer». Во втором примере правила, которое применяется к сетевому адаптеру виртуальной машины с именем «ApplicationServer», разрешается только входящий трафик RDP для виртуальной машины.
При создании правил можно использовать параметр -Weight для определения порядка, в котором виртуальный коммутатор Hyper-V обрабатывает правила. Значения для параметров -Weight выражаются как целые числа. правила с более высоким целым числом обрабатываются раньше правил с более низкими целыми числами. Например, если к сетевому адаптеру виртуальной машины применяется два правила, одно с весовым коэффициентом 1, другое с весовым коэффициентом 10, то второе правило будет обработано раньше.
Применение политик безопасности на уровне пользователя и на уровне приложения
Поскольку правило может сопоставляться с пятикортежным IP-пакетом (исходный IP-адрес, конечный IP-адрес, протокол, порт источника и порт назначения), правило может применять более подробную политику безопасности по сравнению со списком ACL для порта.
например, если вы хотите предоставить службе DHCP ограниченное число клиентских компьютеров, использующих конкретный набор DHCP-серверов, можно настроить следующие правила на Windows Server 2016 компьютере, на котором выполняется Hyper-V, где размещены пользовательские виртуальные машины:
| Исходный IP-адрес | Конечный IP-адрес | Протокол | Исходный порт | Конечный порт | Направление | Действие |
|---|---|---|---|---|---|---|
| * | 255.255.255.255 | UDP | * | 67 | Исходящий | Allow |
| * | 10.175.124.0/25 | UDP | * | 67 | Исходящий | Allow |
| 10.175.124.0/25 | * | UDP | * | 68 | В | Allow |
Далее приведены примеры создания этих правил с помощью команд Windows PowerShell.
Обеспечение поддержки безопасности для приложения не TCP/UDP
Хотя большая часть трафика в центре обработки данных — это трафик TCP и UDP, часть трафика использует другие протоколы. Например, чтобы разрешить группе серверов запускать приложение многоадресной IP-рассылки, использующее протокол IGMP, можно создать следующее правило.
Назначенный номер IP-протокола для IGMP — 0x02.
| Исходный IP-адрес | Конечный IP-адрес | Протокол | Исходный порт | Конечный порт | Направление | Действие |
|---|---|---|---|---|---|---|
| * | * | 0x02 | * | * | В | Allow |
| * | * | 0x02 | * | * | Исходящий | Allow |
Далее приведен пример создания этих правил с помощью команд Windows PowerShell.
Правила списков ACL с отслеживанием состояния
Еще одна новая возможность расширенных списков ACL — настройка правил с отслеживанием состояния. Правило с отслеживанием состояния фильтрует пакеты на основе пяти атрибутов в IP-адресе источника пакета, IP-адресе назначения, протоколе, исходном порте и целевом порте.
Правила с отслеживанием состояния имеют следующие возможности:
Они всегда разрешают трафик и не используются для его блокировки.
Если значение параметра Направление — «Входящий» и трафик соответствует правилу, то виртуальный коммутатор Hyper-V динамически создает соответствующее правило, разрешающее виртуальной машине отправлять исходящий трафик внешнему ресурсу.
Если значение параметра Направление — «Исходящий» и трафик соответствует правилу, то виртуальный коммутатор Hyper-V динамически создает соответствующее правило, разрешающее виртуальной машине принимать входящий трафик от внешнего ресурса.
Они включают атрибут времени ожидания, выражаемый в секундах. Когда на коммутатор поступает сетевой пакет, соответствующий правилу с отслеживанием состояния, виртуальный коммутатор Hyper-V создает состояние таким образом, чтобы разрешить все последующие пакеты, передаваемые в обоих направлениях того же потока. Срок действия состояния истекает, когда отсутствует трафик в каком-либо направлении в течение периода, заданного значением времени ожидания.
Далее приведен пример возможного использования правил с отслеживанием состояния.
Разрешать входящий трафик удаленного сервера только после обращения к нему локального сервера
В некоторых случаях правило с отслеживанием состояния необходимо использовать потому, что только оно позволяет отслеживать известное установленное соединение и отличать его от прочих подключений.
Например, чтобы разрешить серверу приложений виртуальной машины инициировать подключения на порте 80 к веб-службам в Интернете и дать удаленным веб-серверам возможность отвечать на трафик виртуальной машины, можно настроить правило с отслеживанием состояния, разрешающее первоначальный исходящий трафик, передающийся с виртуальной машины веб-службам. Поскольку это правило с отслеживанием состояния, обратный трафик, поступающий с веб-серверов на виртуальную машину, также разрешен. Из соображений безопасности можно блокировать весь прочий входящий сетевой трафик, поступающий на виртуальную машину.
Чтобы настроить такое правило, можно использовать параметры, указанные в таблице ниже.
В связи с ограничениями форматирования и объемом данных в этой таблице информация в ней отображается не так, как в предыдущих таблицах этого документа.
| Параметр | Правило 1 | Правило 2 | Правило 3 |
|---|---|---|---|
| Исходный IP-адрес | * | * | * |
| Конечный IP-адрес | * | * | * |
| Протокол | * | * | TCP |
| Исходный порт | * | * | * |
| Конечный порт | * | * | 80 |
| Направление | В | Исходящий | Исходящий |
| Действие | Запрет | Запрет | Allow |
| С отслеживанием состояния | Нет | Нет | Да |
| Время ожидания (сек) | Недоступно | Недоступно | 3600 |
Правило с отслеживанием состояния разрешает серверу приложений виртуальной машины подключаться к удаленному веб-серверу. При отправке первого пакета виртуальный коммутатор Hyper-V динамически создает два состояния потока, чтобы разрешить все пакеты, отправляемые на удаленный веб-сервер, и все пакеты, возвращающиеся с него. Когда поток пакетов между серверами прекращается, срок действия состояний потока истекает через назначенное время ожидания — 3600 секунд (один час).
Далее приведен пример создания этих правил с помощью команд Windows 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).