Наверное одна из наиболее понравившихся мне новинок в 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 - маркер доступа кэширует все группы, в которые входит пользователь. Пользовательские учётные записи включались в глобальные группы, затем в универсальные, а они уже в локальные доменные, на которые уже и назначались разрешения (естественно в плоской модели леса универсальные группы не использовались).
Особенно, это было явно выраженно при назначение разрешений на сетевые ресурсы: разрешения мы предоставляли на сетевой ресурс с помощью одних групп и на 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 содержит следующие свойства классификации:
К примеру, правило, которое я создал для департамента 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
Помимо улучшений технологии сжатия 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
ИЗ ЖИЗНИ: В своей практике при построении модели безопасности, я всегда стараюсь минимизировать членство пользователя в группах в рамках роли и не допускать более 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
Комментариев нет:
Отправить комментарий
Уважаемый коллега, Ваш комментарий пройдёт модерацию, чтобы избежать спам-атак в ленте. Спасибо за понимание.