среда, 7 августа 2013 г.

Поговорим о Dynamic Access Control

Наверное одна из наиболее понравившихся мне новинок в Windows Server 2012 - это Dynamic Access Control.

Помимо улучшений технологии сжатия PAC (Privilege Account Certificate) и увеличения размера буфера до 48 Kb в Windows Server 2012, это один из способов преодолеть проблему с переполнением маркера доступа TGT Kerberos и просто оптимизировать управление системой безопасности доступа к ресурсам в больших средах (о изменениях в Windwos Server 2012 R2 тут http://technet.microsoft.com/en-us/library/hh831747.aspx).

Размер маркера в билете Kerberos в системах предыдущего поколения составляет 12 Kb, это примерно около 1015 SID на одного пользователя.

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

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

Account - Global Security Group - Universal Security Group - Domain Local Security Group - Permissions

Account - Global Security Group - Domain Local Security Group - Permissions
  
Особенно, это было явно выраженно при назначение разрешений на сетевые ресурсы: разрешения мы предоставляли на сетевой ресурс с помощью одних групп и на NTFS с помощью других.

ИЗ ЖИЗНИ: В своей практике при построении модели безопасности, я всегда стараюсь минимизировать членство пользователя  в группах в рамках роли и не допускать более 3-х уровней вложенности групп. Так же, закладываю механизмы контроля за актуальностью выданых прав, хотя бы на уровне рекомендаций.

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

ПРИМЕЧАНИЕ! При миграции с помощью ADMT с использованием SIDHistory, если пользователь входил в исходном домене в 500 групп, то кол-во SID  в токене удвоится, что фактически спровоцирует проблему с переполнением токена; Поэтому перед миграцией необходимо избавиться от ненужного более членства в группах и фантомов.

С помощью технолгии DAC мы можем упростить сиутацию.

ПРИМЕЧАНИЕ! DAC использует CBAC Security Model - Claim Based Access Control Security Model.

Рассмотрим сценарий предоставления доступа к общему сетевому ресурсу с использованием DAC и claim based authentication.

В данном сценарии у нас есть два департамента: Finance и Information Technology и несколько пользователей, являющихся сотрудниками данных департаментов.






Каждый пользователь должнен получать доступ к своему ресурсу.

У нас есть два общих ресурса на файловом сервере на базе Windows Server 2012: одна общая папка для департамента Finance и вторая для Information Technology.

Разрешения на сетевой доступ по-умолчанию, добавлена только группа Authenticated Users с правами Read & Modify, а права NTFS аналогичны.

Пользователь Jane Dow относится к финансовому департаменту




Папка Finance содержит следующие свойства классификации:

 

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





К примеру, правило, которое я создал для департамента Finance выглядит следующим образом



ПРИМЕЧАНИЕ! Для работы данного функционала необходим Windows Server 2012 с ролью файлового сервера, Windows 8 клиент и контроллер домена на базе Windows Server 2012, DFL 2012. По данной ссылке есть информация, что DAC поддерживает 2008 R2 и Windows 7 в качестве клиентов, но я не проверял (подробнее тут http://blogs.dirteam.com/blogs/sanderberkouwer/archive/2012/09/24/new-features-in-active-directory-domain-services-in-windows-server-2012-part-20-dynamic-access-control-dac.aspx)

Результатом работы правила, является получение доступа к ресурсу финансового департамента пользователем Dow Jane (Рис. 1) и Smith John, но отказ в доступе для пользователя Kiss Tom (Рис. 2).

Рис.1.

Рис. 2.

Особенно заманчивым данный сценарий выглядит в комбинации с AD RMS. Так же любопытны сценарии с закреплением возможности доступа с конкретного сетевого устройства и т. д.  Claims можно легко комбинировать, используя логику мастеров построения Target Resource правил и разрешений.


 

Несмотря на новшевства DAC, смешанные сценарии на основе RBAC и ACL плюс CBAC никто не отменял, на сколько мне известно ReFS до сих пор не умеет работать с политиками авторизации, да и в обычной жизни, не всегда всё просто.

Что касается хранения настроек DAC:

Сами claims и другие настройки DAC сохраняются в разделе Configuration леса со всеми вытекающими последствиями




Что касается первичного диагностирования и устранения проблем то следует обратить внимание вот на что:

1. Что является claims целевого ресурса? Какие выражения и Permissions содержаться в правиле?
2. DAC тесно связан с GPO: если не работает GPO - не работает DAC, так же необходимо проверить правильнось назначения CAR, CAP через GPO.
3. Можно посмотреть, что мешает получить доступ к ресурсу с помощью вкладки Effective Access в свойствах безопасности целевого ресурса (поле Access limited by). Тут мы можем поэксперементировать с пользователем, добавить или убрать дополнительную группу, членом, которой он является или claim пользователя


4. Мы можем посмотреть claim пользователя с помощью команды whoami /claims

Комментариев нет:

Отправить комментарий

Уважаемый коллега, Ваш комментарий пройдёт модерацию, чтобы избежать спам-атак в ленте. Спасибо за понимание.