- Обзор управления доступом Access Control Overview
- Описание функции Feature description
- Access Control Editor
- Dynamic Access Control в Windows Server 2012
- Недостатки организации доступа на основе ACL
- Архитектура и принципы Windows Server 2012 Dynamic Access Control
- Пример использования Dynamic Access Control в Windows Server 2012
- Заключение
Обзор управления доступом Access Control Overview
Относится к: Applies to
- Windows 10 Windows 10
- Windows Server 2016 Windows Server 2016
В этом разделе для ИТ-специалистов описывается управление доступом в Windows, которое является процессом авторизации пользователей, групп и компьютеров для доступа к объектам в сети или на компьютере. This topic for the IT professional describes access control in Windows, which is the process of authorizing users, groups, and computers to access objects on the network or computer. Ключевыми понятиями, которые составляют управление доступом, являются разрешения, владение объектами, наследование разрешений, права пользователей и аудит объектов. Key concepts that make up access control are permissions, ownership of objects, inheritance of permissions, user rights, and object auditing.
Описание функции Feature description
Компьютеры с поддерживаемой версией Windows могут управлять использованием системных и сетевых ресурсов с помощью взаимосвязанных механизмов проверки подлинности и авторизации. Computers that are running a supported version of Windows can control the use of system and network resources through the interrelated mechanisms of authentication and authorization. После проверки подлинности пользователя операционная система Windows использует встроенные технологии авторизации и управления доступом для реализации второго этапа защиты ресурсов: определения, имеет ли пользователь с проверкой подлинности правильные разрешения на доступ к ресурсу. After a user is authenticated, the Windows operating system uses built-in authorization and access control technologies to implement the second phase of protecting resources: determining if an authenticated user has the correct permissions to access a resource.
Общие ресурсы доступны пользователям и группам, кроме владельца ресурса, и они должны быть защищены от несанкционированного использования. Shared resources are available to users and groups other than the resource’s owner, and they need to be protected from unauthorized use. В модели управления доступом пользователи и группы (также именуемые директорами безопасности) представлены уникальными идентификаторами безопасности (SID). In the access control model, users and groups (also referred to as security principals) are represented by unique security identifiers (SIDs). Им назначены права и разрешения, которые информируют операционную систему о том, что может сделать каждый пользователь и группа. They are assigned rights and permissions that inform the operating system what each user and group can do. У каждого ресурса есть владелец, который предоставляет разрешения директорам безопасности. Each resource has an owner who grants permissions to security principals. Во время проверки контроля доступа эти разрешения проверяются, чтобы определить, какие принципы безопасности могут получить доступ к ресурсу и каким образом они могут получить к нему доступ. During the access control check, these permissions are examined to determine which security principals can access the resource and how they can access it.
Принципы безопасности выполняют действия (в том числе чтение, записи, изменение или полный контроль) на объектах. Security principals perform actions (which include Read, Write, Modify, or Full control) on objects. Объекты включают файлы, папки, принтеры, ключи реестра и объекты служб домена Active Directory (AD DS). Objects include files, folders, printers, registry keys, and Active Directory Domain Services (AD DS) objects. Общие ресурсы используют списки управления доступом (ACLs) для назначения разрешений. Shared resources use access control lists (ACLs) to assign permissions. Это позволяет руководителям ресурсов применять управление доступом следующими способами: This enables resource managers to enforce access control in the following ways:
Отказ в доступе к несанкционированным пользователям и группам Deny access to unauthorized users and groups
Установите четко определенные ограничения доступа, предоставляемого уполномоченным пользователям и группам Set well-defined limits on the access that is provided to authorized users and groups
Владельцы объектов обычно выдают разрешения группам безопасности, а не отдельным пользователям. Object owners generally grant permissions to security groups rather than to individual users. Пользователи и компьютеры, добавленные в существующие группы, принимают разрешения этой группы. Users and computers that are added to existing groups assume the permissions of that group. Если объект (например, папка) может удерживать другие объекты (например, подмостки и файлы), он называется контейнером. If an object (such as a folder) can hold other objects (such as subfolders and files), it is called a container. В иерархии объектов связь между контейнером и его контентом выражается, ссылаясь на контейнер в качестве родительского. In a hierarchy of objects, the relationship between a container and its content is expressed by referring to the container as the parent. Объект в контейнере называется ребенком, и ребенок наследует параметры управления доступом родителя. An object in the container is referred to as the child, and the child inherits the access control settings of the parent. Владельцы объектов часто определяют разрешения для контейнерных объектов, а не отдельных детских объектов, чтобы облегчить управление управлением доступом. Object owners often define permissions for container objects, rather than individual child objects, to ease access control management.
Этот набор контента содержит: This content set contains:
Access Control Editor
The access control editor is a set of property sheets and property pages that enable the user to view and modify the components of an object’s security descriptor. The editor consists of two main parts:
- A basic security property page that provides a simple interface for editing the access control entries (ACEs) in an object’s discretionary access control list (DACL). This page can include an optional Advanced button that displays the advanced security property sheet.
- An advanced security property sheet with property pages that enable the user to edit the object’s system access control list (SACL), change the object’s owner, or perform advanced editing of the object’s DACL.
The CreateSecurityPage function creates the basic security property page. You can then use the PropertySheet function or the PSM_ADDPAGE message to add this page to a property sheet.
Alternatively, you can use the EditSecurity function to display a property sheet that contains the basic security property page.
For both CreateSecurityPage and EditSecurity, the caller must pass a pointer to an implementation of the ISecurityInformation interface. The access control editor calls the methods of this interface to retrieve access control information about the object being edited and to pass the user’s input back to your application. The ISecurityInformation methods have the following purposes:
To initialize the property pages.
Your implementation of the GetObjectInformation method passes an SI_OBJECT_INFO structure to the editor. This structure specifies the property pages that you want the editor to display and other information that determines the editing options available to the user.
To provide security information about the object being edited.
Your GetSecurity implementation passes the object’s initial security descriptor to the editor. The GetAccessRights and MapGeneric methods provide information about the object’s access rights. The GetInheritTypes method provides information about how the object’s ACEs can be inherited by child objects.
To pass the user’s input back to your application.
When the user clicks Okay or Apply, the editor calls your SetSecurity method to pass back a security descriptor containing the user’s changes.
Dynamic Access Control в Windows Server 2012
В 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 осуществляется еще и проверка на соответствие клаймов? Последовательность проверки разрешений следующая:
· Central Access Policy
Пример использования 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
Закройте редактор групповых политик и обновите политики на контроллере домена и файловых серверах командой
Посмотрим, что же у нас получилось.
Откройте на файлом сервере, к которому применяется созданная нами политика, свойства любой общей папки или документа, и перейдите на вкладку Classification. Как вы видите, в нем появились два утверждения. Если автоклассификация не настроена, их значения будут не заданы.
Примечание: Чтобы при доступе к файлу проверялись еще и разрешения DAC, у пользователей должен быть доступ к каталогу/файлу на уровне NTFS. В этом примере мы предоставим всем полный доступ на уровне NTFS.
Проверим текущие разрешения на папку.
Перейдем на вкладку Central Policy и применим политику Finance Data.
Если у пользователя не назначены утверждения (он входит в нужную группу, но у него не определены атрибуты department и country), доступа к каталогу у него не будет.
Заключение
С помощью комбинации технологий DAC, AD RMS (как организовать динамическое шифрование файлов с помощью AD RMS и FCI )и FCI можно создавать мощные схемы управления доступом к документам и зашиты конфиденциальной информации, реализуя полноценную DLP систему на базе инфраструктуры Windows Server 2012.