В Windows Server 2012 появился новая концепция централизованного управления доступом к файлам и папкам на уровне всей компании под названием Dynamic Access Control (динамический контроль доступа). Основное отличие новой системы динамического контроля доступа от старой системы доступа к файлам и папкам Access Control List (ACL — списки контроля доступа), позволяющей предоставлять доступ только на учетных записей пользователей и групп, заключается в том, что с помощью Dynamic Access Control (DAC) можно управлять доступом на основе практически любого заданного атрибута и даже критерия. С помощью Dynamic Access Control в Windows Server 2012 можно создавать целые правила управления доступа к данным, которые позволят проворить, например, входит ли пользователь в определенные группы, числится ли он в финансовом отделе и поддерживает ли его планшет шифрование RMS. Эти правила в виде политик в дальнейшем можно применить к любому (или всем) файловым серверам организации, создав тем самым единую систему безопасности.
Недостатки организации доступа на основе ACL
Каким образом реализовывался доступ к общим каталогам на файловых серверах до появления Dynamic Access Control. На общую папку на уровне NTFS и/или шары назначались определенные списки доступа, включающиеся в себя определенные группы в AD (или локальные группы сервера) или конкретные учетные записи. Чтобы пользователь получил доступ к нужному каталогу, администратор должен был включить его в соответствующую группу. Какие недостатки такой модели организации доступа?
· Доступ регулируется только на основании только членства в группе
· При большом количестве общих папок необходимо создавать большое количество групп (выливается в увеличение билета Kerberos)
· Отсутствует возможность контроля доступа на основании характеристик устройства пользователя, с которого подключается пользователь
· Невозможность реализации сложных сценариев доступа
При контроле доступа только на основе ACL нередки случаи, когда пользователь случайно выкладывает конфиденциальную информацию (зарплаты топ-менеджеров, например) на общедоступный (public) ресурс, где все желающие могут с ней познакомится.
Указанные выше недостатки призвана устранить технология динамического контроля доступа.
Архитектура и принципы Windows Server 2012 Dynamic Access Control
В Windows Server 2012 Dynamic Access Control создает еще один уровень управления доступом к файловым объектам на уровне всего домена, причем на эти объекты продолжают действовать NTFS разрешениями
(ACL). Отметим, что правила DAC могут действовать повсеместно, независимо от того, какие NTFS права выставлены на объекте.
Одной из основных концептов модели DAC является понятие claim (заявка или утверждение). В модели управления доступом Windows Server 2012 claim представляет собой атрибут Active Directory, которой определен для использования с централизованными политиками доступа (Central Access Policies). В качестве критериев можно использовать практически любые сохранные в AD параметры, принадлежащие определенному объекту, например, ID устройства, способ входа в систему, местонахождение, личные данные и т.д. Настройка claim-ов осуществляется с помощью консоли управления Active Directory Administrative Center (ADAC) в новом контейнере Claim Based Access. В этом контейнере (изначально пустом) можно создавать собственные утверждения и связывать их с атрибутами пользователей или компьютеров. Основываясь на значениях claim-ов можно определить давать ли доступ данному пользователю/устройству к тому или иному объекту файловой системы.
Следующий компонент DAC – свойства ресурсов (Resource Properties), с помощью которых определяются свойства ресурсов, которые в дальнейшем будут использовать в правила авторизации. Resource Properties – это также отдельный контейнер в Dynamic Access Control.
Следующими элементами DAC являются правила Central Access Rules и политики Central Access Policy. CentralAccess Rules описывают какой уровень доступа предоставить к файлам, каким пользователям, с какими заданными утвержденями, с каких устройств и т.д. Central Access Policy – это политика, содержащая в себе правила Central Access Rules, которая в дальнейшем посредством GPO будет распространена по всей организации (или конкретной OU).
Каким образом можно перейти на модель управления доступом Dynamic Access Control в организации:
1. Создать один/несколько видов клаймов.
2. Активировать одни/несколько свойств ресурсов (метки или теги у файловых объектов)
3. Создать правило Central Access Rule, в котором определяется условия предоставления доступа
4. Добавить созданные правила в политику Central Access Policy
5. С помощью групповых политик распространить CAP на файловые сервера
Естественно, перед внедрением Dynamic Access Control необходимо настроить систему классификации файлов, как это сделать описывается в статье : Классификация файлов с помощью File Classification Infrastructure в Windows Server 2012. Этап определения и классификация данных, хранящихся на файл-серверах наиболее тяжелый и трудоемкий, результатом которого будет назначение управляемым файловым объектам NTFS тэгов.
Каким образом осуществляется проверка разрешений пи доступе к файлу/каталогу конечного пользователя, ведь теперь помимо прав доступа на NTFS осуществляется еще и проверка на соответствие клаймов? Последовательность проверки разрешений следующая:
· Share ACL
· Central Access Policy
· NTFS ACL
Пример использования Dynamic Access Control в Windows Server 2012
Попробуем разобрать на практике возможные пример настройки DAC в Windows 2012. Предположим, что мы хотим создать политику доступа, регулирующую доступ на основе департамента пользователи и страны, в которой он находится.
С помощью консоли AD Administrative Center создадим два новых claim-a: Department и Country. Для этого перейдите в контейнер Dynamic Access Control -> Claim Types и в меню выберите пункт New:
Создадим новое утверждение с именем Department :
и Country :
В атрибуте Country укажем два предопределенных (suggested) значения (EG – Египет, и QR – Катар):
Далее создадим новое свойство ресурса (Resource Properties) для утверждения Country: New-> Resource Properties.
Затем в контейнере Resource Properties активируйте утверждение Department
Теперь создадим новое правило Central Access Rule. В этом правиле будут указаны разрешения, которые применяются к объекту, если claim совпадает с правилом, описанном в CAR.
Предположим, мы правило, определяющее, что пользовали Finance Admins (Department=Finance и County=EG), имеют полный доступ, а пользователи Finance Execs (Department=Finance) – доступ только на чтение. Это правило будет применено ко всем правилам, классифицированным, как относящиеся к финансовому департаменту:
В итоге, правило будет выглядеть так:
Затем создадим политику Central Access Policy (CAP), которая с помощью GPO будет применена ко всем файловым серверам.
В новую политику CAP, включим правило для финансового департамента, созданное ранее:
Далее правило Central Access Policy с помощью групповых политик нужно применить ко всем файловым серверам. Для этого нужно создать новую политику GPO и прилинковать ее к OU с файловыми серверами.
В окне редактора групповых политик (Group Policy Management Editor) перейдите в раздел Computer Configuration->Policies->Windows Settings->Security Settings->File System-Central Access Policy->Manage Central access policies.
В окне настроек Central Access Policies Configuration добавим политику Finance Data и нажмем OK.
Далее нужно разрешить всем доменным контроллерам назначать клаймы. Это также выполняется с помощью GPO, однако в этом случае нам нужно отредактировать политику контроллеров домена — Default Domain Controllers Policy . Перейдите в раздел Computer Configuration->Policies->Administrative Templates->System-> KDC. Откройте параметр KDC Support for claims, compound authentication and Kerberos armoring, задайте ему значение Enabled , а в выпадающем списке выберите Supported
Закройте редактор групповых политик и обновите политики на контроллере домена и файловых серверах командой
gpupdate /force
Посмотрим, что же у нас получилось.
Откройте на файлом сервере, к которому применяется созданная нами политика, свойства любой общей папки или документа, и перейдите на вкладку Classification. Как вы видите, в нем появились два утверждения. Если автоклассификация не настроена, их значения будут не заданы.
Примечание: Чтобы при доступе к файлу проверялись еще и разрешения DAC, у пользователей должен быть доступ к каталогу/файлу на уровне NTFS. В этом примере мы предоставим всем полный доступ на уровне NTFS.
Проверим текущие разрешения на папку.
Перейдем на вкладку Central Policy и применим политику Finance Data.
Если у пользователя не назначены утверждения (он входит в нужную группу, но у него не определены атрибуты department и country), доступа к каталогу у него не будет.
Заключение
С помощью комбинации технологий DAC, AD RMS (позволяет организовать динамическое шифрование файлов с помощью AD RMS и FCI)и FCI можно создавать мощные схемы управления доступом к документам и зашиты конфиденциальной информации, реализуя полноценную DLP систему на базе инфраструктуры Windows Server 2012.
Мы продолжаем перевод и публикацию материалов, связанных с Windows Server 2012 и обновлениями штатных систем аудита Microsoft. Приглашаем заинтересованных читателей ознакомиться с рассказом сотрудника команды Windows Server о новых возможностях Dynamic Access Control.
Здравствуйте, меня зовут Nir Ben-Zvi, я работаю в команде Windows Server. Я рад представить вам сегодня новый набор функций для Динамического контроля доступом (Dynamic Access Control), который имеется в Windows Server 2012.
Сначала я вкратце расскажу о процессе планирования, затем мы рассмотрим новую модель политики центрального доступа (Central Access Policy) и опишем что нового в Файловом Сервере, решении, которое мы встроили в Windows Server 2012. Я также вопросов постепенного внедрения, так чтобы Вам не нужно было перемещать всю среду на Windows Server 2012, если Вам нужно использовать данную функцию. В конце мы рассмотрим вопросы, связанные с тем какие решения наших партнеров помогут расширить предлагаемых функционал наших решений.
Введение
В современных (читай: сложных) IT-инфраструктурах создание данных происходит с ошеломляющей скоростью в рассредоточенных системах; одновременно доступ к этим данным осуществляется с многочисленных устройств. Выполнение требований нормативов по информационной безопасности и потребность в защите конфиденциальной информации от утечек – одни из важнейших проблем для бизнеса и IT. Чтобы эти проблемы были успешно решены – необходимо контролировать, кто получил доступ к определенной информации, причем желательно, чтобы желательно, чтобы при осуществлении такого контроля информация о доступе была представлена максимально наглядно.
Мы были в курсе этим проблем, стоящих перед бизнесом и IT уже пару лет назад, когда планировали, каким будет Windows Server 2012. Вот только несколько часто встречающихся запросов со стороны наших клиентов:
• Централизованное управление доступом к информации как на основе запросов бизнеса, так и с целью выполнения требований нормативов
• Должен осуществляться аудит доступа к информации для целей анализа и выполнения требований нормативов по ИБ
• Конфиденциальная информация должна быть защищена
• Владельцы контента должны быть ответственны за свою информацию – администраторы не должны заниматься не своей работой
• Ключевым аспектом является поддержание продуктивности деятельности специалистов, работающих с информацией
Мы взглянули на отдельные должностные позиции в организации и их взаимодействие в процессе выполнения запросов со стороны бизнеса, и регулирующих органов, чтобы представить адекватный запросам набор технологий и решений.
Таким образом, список должностей, вовлеченных в решение обозначенных проблем, начинается с CSO/CIO, который определяет потребности с позиций бизнеса и выполнения требований нормативов. За ними следуют IT-администраторы, которые осуществляют управление системами, и владельцы контента, которые контролируют фактическую информацию. Что касается тех, кто непосредственно работает с информацией, то влияние применяемых решений на них должно быть минимальным (в идеале его не должно быть совсем).
Чтобы помочь организациям выполнить требования нормативов и решить стоящие перед ними бизнес-задачи, мы в конечном итоге, сфокусировались на следующих сферах:
• Определение информации, управление которой должно осуществляться для достижения поставленных целей
• Применение политик доступа к информации
• Аудит доступа к информации
• Шифрование информации
Эти задачи были переведены в набор функций Windows, которые делают возможным защиту данных с помощью решений Windows и решений партнеров.
• Добавлена возможность конфигурировать в Active Directory централизованный доступ (Central Access) и политики аудита. Эти политики основаны на условных требованиях (см. ниже); при этом могут быть значительно снижено число групп безопасности для контроля доступа:
o Кем является пользователь
o Какое устройство он использует
o К каким данным получен доступ
• Заявки (claims) интегрированы в аутентификацию Windows (Kerberos), так что пользователи и устройства могут быть описаны не только посредством групп безопасности, в которых они состоят, но также и по заявкам, например: “Пользователь из Отдела финансов”, и “Категория доступа (security clearance) пользователя высокая”.
• Улучшена инфраструктура классификации файлов (File Classification Infrastructure), что позволит владельцам контента и пользователям идентифицировать (присваивать теги) их данные, так что IT-администраторы могут создавать целевые политики, основываясь на этих тегах. Эта возможность работает наряду с возможностью инфраструктуры классификации файлов автоматически классифицировать файлы на основании их содержимого или других характеристик.
• Интегрированы службы управления правами (Rights Management Services), чтобы автоматически защищать (шифровать) конфиденциальную информацию на серверах, так что даже тогда, когда она покидает сервер, она защищена.
Политики центрального доступа
Политики центрального доступа можно сравнить со страховкой, которую организация применяют на своих серверах. Эти политики улучшают (но не заменяют) политику локального доступа (например, дискреционный ACL), которая применяются к информации. Например, если локальный DACL файла разрешает доступ определенному пользователю, но Центральная политика запрещает доступ этому же пользователю, то он не сможет получить доступ к файлу (и наоборот).
Инициатива по внедрению и усилению политики центрального доступа произрастает из различных причин и из различных уровней организации:
• Политика, связанная с выполнением требований нормативов: Эта политика соотносится с требованиями нормативов и бизнеса и нацелена на защиту правильного (адекватно установленного) доступа к информации, управление которой осуществляется. Например, дать доступ к информации, которая подпадает под регулирующие документы “US-EU Safe Harbor”, только определенной группе пользователей.
• Политика разрешений на уровне отделов: Каждый отдел в организации имеет определенные требования к работе с данными, которые бы они хотели бы защитить (укрепить). Такая ситуация часто встречается в организациях с разветвленной организационной структурой. Например, отдел финансов хочет ограничить доступ к финансовой информации только для финансовых работников.
• Политика “необходимо знать” (Need to know policy): Эта политика гарантирует, что доступ допускается только тем, кому “необходимо знать”. Например:
o Вендоры должны получать доступ к информации и редактировать только файлы, которые относятся к проектам, над которым они работают.
o В финансовых учреждениях “стены” между информацией важны, например, аналитики не должны получать доступ к брокерской информации, а брокеры – к аналитической.
Политики центрального аудита
Политика центрального аудита (Central Audit Policy) – мощный инструмент, который позволяют поддерживать безопасность организации. Одной из ключевых целей аудита безопасности является выполнение требований нормативов по информационной безопасности. Отраслевые стандарты, такие как SOX, HIPPA, PCI и другие требуют от организаций следовать жестко установленному набору правил, связанных с информационной безопасностью и конфиденциальностью данных (privacy). Работа аудиторов заключается в том, чтобы установить наличие (или отсутствие) таких политик, тем самым доказывается выполнение (или не выполнение) требований этих стандартов. Вдобавок, аудит безопасности позволяют фиксировать аномальное поведение, определять и избегать образования дыр в системе безопасности и ограничивать несанкционированное поведение – любая важная деятельность пользователей записывается, а такие записи могут быть использованы при проведении расследования.
Windows Server 2012 позволяет администраторам разрабатывать политики аудита, используя выражения, которые принимают во внимание то, к какой информации пользователи получают доступ и кем эти пользователи являются, так что организация может осуществлять аудит доступа только к определенной информации, вне зависимости от того, где бы они не находилась. Это открывает дорогу к более целевым и в то же время простым в использовании политикам аудита. Теперь можно реализовывать сценарии, которые до настоящего момента было сложно осуществить. Например, Вы можете легко разработать политики аудита, которые перечислены ниже:
• Аудит всех, у которого нет высокой категории допуска и кто, тем не менее, пытается получить доступ к “важной” информации
• Аудит всех вендоров, которые пытаются получить доступ к документам по проектам, над которыми они не работают.
Это помогает регулировать объем событий аудита и ограничивает их только до более важных, так что Вы можете отслеживать доступ к информации на различных серверах без создания огромного количества записей.
В дополнение, тегирование информации записывается в события аудита, так что с помощью механизма сбора событий можно формировать контекстуальные отчеты, например: Кто получил доступ к Важной информации за последние три месяца.
Решение для файлового сервера
Основываясь на подобной инфраструктуре, мы разработали комплексное решение для Windows Server 2012 Active Directory, Windows Server 2012 File Server и Windows 8 client. Это решение позволяет вам:
• Идентифицировать данные, используя автоматическую и ручную классификацию файлов.
• Контролировать доступ к файлам по всем серверам, применяя гарантию (safety net) политик центрального доступа. Например, Вы можете контролировать, кто получает информацию о здоровье сети по всей организации.
• Аудит доступа к файлам на файловых серверах, используют политики центрального аудита для целей выполнения нормативов по информационной безопасности и проведения расследований. Например, Вы можете определить, кто получил доступ к высоко конфиденциальной информации за последние три месяца.
• Шифрование данных посредством автоматического применения шифрования служб управления правами (Rights Management Services (RMS)) для конфиденциальных документов. Например, Вы можете настроить RMS на шифрование всех документов, которые содержат информацию, защищаемую нормативом HIPAA.
Для того чтобы поддержать внедрение на множестве файловых серверов в организации, мы также предоставляем Data Classification Toolkit, который позволяет осуществлять настройку и формирования отчетов среди многочисленных серверов.
Бета-версию Data Classification Toolkit можно скачать здесь.
Концепция постепенного внедрения
Одним из ключевых принципов разработки DAC является постепенные внедрения. Вы можете начать использовать эту функцию, как только у Вас возникнет потребность решать задачи, стоящие перед Вашей компанией в части аудита файловых серверов и доступа к информации.
Вы можете использовать большинство из возможностей Dynamic Access Control в файловом сервере Windows Server 2012 и обновленной схеме домена Active Directory. Добавление минимального числа контроллеров доменов Windows Server 2012 позволить включить пользовательские заявки и т.д. Каждая часть системы, которую Вы обновите, даст Вам больше возможностей, однако задавать скорость внедрения – это уже на ваше усмотрение.
Решения партнеров
Решения партнеров и ряд бизнес приложений может повысить эффективность использования инвестиций в инфраструктуру Windows для Dynamic Access Control, обеспечивая ценность для организаций, использующих Active Directory. Вот лишь некоторые примеры партнерских решений, которые представляли на конференции в прошлом году:
• Интеграция систем предотвращения утечки данных (Data Leakage Prevention) с системой автоматической классификации содержимого
• Централизованный анализ данных аудита
• Авторизация служб управления правами (Rights Management Services) с использованием Central Access Policies
• Многие другие…
via Technet
What is Dynamic Access Control (DAC)?
Dynamic Access Control (DAC) is a Windows Server feature that debuted in Windows Server 2012. It leverages data-governance technology to give administrators granular, context-aware control over access to file system resources. Administrators can set conditional access controls based on whatever criteria they choose to improve security and regulatory compliance.
Prior to DAC, Windows authorized access to file system resources via shared and NTFS (New Technology File System) permissions. This approach had drawbacks in the areas of scale and granularity for auditing and reporting.
Dynamic Access Control involves data-governance technology that works along with NTFS (New Technology File System) and shared-folder permissions. DAC improves on the use of sharing or NTFS permissions by providing granular control over access to resources as well as easier auditing with more detailed reporting.
The Three Main Features of Dynamic Access Control
1. Classification
Network administrators can classify data with taxonomic tags that assign semantic meaning to file system resources.
2. Claims
A claim is basically an attributes from Active Directory—a piece of information stored as a token, used to grant access to a user or computer.
3. Policy
DAC’s Central Access Policy allows for the use of conditional logic to connect taxonomic tags and claims. The possible combinations provide for highly contextual, granular access control and auditing.
Benefits of Dynamic Access Control (DAC)
Some key benefits of DAC include:
Enhanced security: For example, DAC can allow the same user access to resources when they are in the office, but deny access from less secure locations, such as a cafe.
Detailed auditing and reporting: This can aid in regulatory compliance as well as forensic investigations into attacks or attempted attacks.
Simplified access management: Centralized policies, custom criteria, and automation enable simplified access control, with less work for administrators.
Dynamic Access Control Key Takeaways:
- DAC is data-governance technology that gives administrators granular, context-aware control over access to file system resources.
- Administrators can set conditional access controls based on any criteria they choose.
- Through its three main features—classification, claims, and policy—DAC can make connections and relations, which a computer, by itself, might not be able to make.
- DAC can grant or deny access to resources based on many variables, such as location, for e.g., office vs. cafe.
- The key benefits of DAC include: simplified access management, enhanced security, and improved compliance and forensics.
Dynamic Access Control, also called DaC, is a Windows Server feature that made its first appearance in Windows Server 2012. It remains a central component of most security deployments because it allows a higher degree of conditional access controls based on whatever criteria you’d like applied. In this post, we’ll cover what Dynamic Access Control is, when you’d want to use it, and briefly cover some of the more basic parts of implementing it. To learn about DaC and more, check out our Advanced Windows Server training.
What Exactly Is Dynamic Access Control (DaC)?
Quick Definition: Dynamic Access Control is a Windows Server feature that allows conditional access control. As the name suggests, administrators have the control to grant or restrict access to network resources based on dynamic variables. Maybe your company works with sensitive information that needs to be protected; you decide who can access it, but is that enough?
Maybe that sensitive information is safe with that user while they’re in the office, but what about when they’re working from the café down the street? With DaC, a network administrator has fine-tuned control over who has access to resources, when, and what parameters make that decision.
An Overview of Dynamic Access Control [VIDEO]
In this video, Tim Warner covers a brief demonstration of configuring claims with dynamic access control in Windows Server 2012. This version of Windows Server provides numerous new features, but this video focuses specifically on exploring DAC, what it is, and what it can do for you.
What is Dynamic Access Control Good For?
DaC is a data-governance technology that works along with NTFS permissions and shared folder permissions. Historically with Windows, we provided authorization to file system resources by using a combination of shared and NTFS permissions. Shared permissions were used to make a folder available on your network, NTFS permissions, which apply to both folders and files and grant or block users based on their identity in Active Directory.
That comes with two big problems, problems that Microsoft sought to solve with Dynamic Access Control. First is what to do about sizing upward. As companies get larger and larger, they scale up & out. That makes it more and more cumbersome to juggle Active Directory groups in their Discretionary Access Control Lists (DACLs).
The second problem is that just using NTFS and shared permissions along with traditional Windows Server auditing (which is object-access auditing) doesn’t always provide sufficient detail. Some shops are subject to regulations that impose significant auditing and reporting demands – without fine-tuned controls, satisfying those regulations can be time-intensive and challenging.
Many of those regulations are industry standards. But many could be regulations put in place by a government — and sometimes not even from the country the organization is headquartered in. When you’re talking about those kinds of regulations, data governance is a common term. Data governance more or less means that a network administrator is able to track the access that users have to server resources at a highly granular level. Many regulations require proof that your network can provide an audit trail, tracking who in the organization accessed what, when, where, etc..
Not only that, Dynamic Access Control provides network administrators with yet another tool that gives them further control over their networks: Least Privilege. If you’re unfamiliar with it, the principle of Least Privilege is more or less what it sounds like: users on your domain should always have enough privilege to get to the files that they need to while having the level of access necessary to make the operations on those files that they need to, but no more. Least Privilege sounds like common sense, but the actual time and effort that it takes to restrict access without hampering productivity is significant.
How Does Dynamic Access Control Actually Work?
We’ve got a sense of what DaC does, but we’re left with the question of what is DaC? Dynamic Access Control can be thought of as a triangle with three sides: classification, claims and policy. Let’s get more into each of those.
First, classification. Dynamic Access Control allows network administrators to classify data. With DaC, it’s possible to write taxonomic tags that assign semantic meaning to your file system resources. If you know what taxonomic tags are, you probably appreciate how powerful that is. If you’re not familiar with them, they’re basically a way to add relationships to your data. With good taxonomies and tags, you can connect things to one another that a computer wouldn’t realize are related.
Related to that is data classifications and scrubs. If you follow this blog, watch for a future post in which we’ll be showing the File Server Resource Manager, and how we can actually have it schedule automatic scrubs and automatic classification for your shared folders – really powerful stuff.
The second part of the DaC triangle is on the other side of the coin of classification. On that side, we have users and computers for which we can configure claims. A claim is basically an attribute from Active Directory. Claims are sourced in Active Directory schema, and Dynamic Access Control lets a network administrator present the claim with the user’s access token alongside their AD group memberships, name and password.
Doing that does require enabling Kerberos armoring. Without Kerberos armoring, you couldn’t enable the user’s access token on your domain. Kerberos armoring makes it possible to extend the token and bring in those additional claim properties.
The third side of the DaC triangle is the Central Access Policy. This is where we can use conditional logic to tie together our taxonomic tags that we’ve placed on our shared folders and the claims that we’ve associated with our users and computers. When those come together, you should be able to imagine that that we can provide very granular access in auditing.
Not only that, but because we can audit using conditional statements means that there’s, overall, a lower auditing volume. It also provides more bang for our buck with our auditing infrastructure.
How to Configure Claims in Dynamic Access Control (DaC)
We won’t get into the weeds too far, but next let’s take a moment and demonstrate how to configure claims in Dynamic Access Control. For starters, in order to configure DaC, we’ll need to use either PowerShell or Active Directory Administrative Center (dsac.exe).
If you’re still tied to Active Directory users and computers, you’d best get used to the DSAC. For the rest of this post, we’re assuming that you have access to DSAC and have a network environment you can explore in it. We’ll start with DSAC, and we can open it up by going to a command prompt and typing:
This window should already be fairly familiar to you, so we’ll use the navigation tree to select Dynamic Access Control. This’ll give us a good view of the three sides of our triangle: Claims, Resource Properties (which refer to the metadata tags for our files and folders), and the Central Access Rules and Policies.
For now, we’ll double-click Claims. In our case, we happen to have already created one. If you have any already, you’ll see them displayed in the middle of the screen. We named ours «Department», and it maps to the Department schema attribute. But where are these attributes coming from?
Earlier, we mentioned that attributes are derived from Active Directory. We have to sidetrack briefly, but we can explore exactly what it means that those attributes derive from AD. Since you’re in the DSAC, you should have many users available to you. If you go ahead and open a user account, we can see how easy it is to identify attributes.
Navigate to one of your users and open their user properties sheet. This opens an interface that would let us drill into any of their displayed properties. We could even go beyond what’s shown here in the user’s properties sheet – as long as you know what a particular attribute is named in AD, in the schema, you can get to it.
So, if we wanted to create conditional access — in our case, claims based on department — we’d check to see if the user has that field populated. Presumably, the user we clicked into does have a value in the «Department» field. But maybe rather than assign dynamic control based on what department they’re a part of, we instead wanted to classify based on their location, their city, their state. All these are right there waiting for you.
So, now if we go back to Claim Types, we can right-click, select «New» and then «Claim Type». This window provides us with all the schema attributes. You can filter the list if you know – basically – what you’re looking for. There’s a search menu available that provides contextual feedback, so you could search for – for example – «country» and the results update as you type.
Note: the Display Name for your attribute may not be intuitive, comprehensible, or what you want it to be. If that’s the case, you can select it in this menu and then on the right side, you can update it.
On the same screen, you’ll have the option to associate this update with a user, with a computer, or both. Not only that, but you can optionally suggest values in advance. All this makes it a lot easier later – when you’re making your central access policies – to avoid data entry errors.
Something to note is that anything you create within this Claim Type menu is protected from accidental deletion. What that means is that if while working in the menu, you tried to delete an entry, a window interrupts the action. It’ll stop the deletion, and depending on permissions, it’ll inform the user they don’t have permissions to delete.
Wrapping Up
That’s not an in-depth exploration of Claim Types inside the Active Directory Administrative Center, but if you’ve got a network and DSAC at your disposal, hopefully it gives you a sense of what you’re looking at as you click around. At this point, we’re trying to get you thinking of AD properties for your users and even your devices that you may want to use in Dynamic Access Control Access Control Lists.
There are more steps, like configuring our Resource Properties and Resource Property Lists, but for now, we’ll leave you with this understanding of what DaC is and how some of its options can be configured. If configuring and optimizing Dynamic Access Control is something you need more in-depth study on, consider CBT Nuggets’ Microsoft Windows Server 2012 MCSA training.
Наверное одна из наиболее понравившихся мне новинок в 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