Dynamic Access Control в Windows Server 2012  — технология сложная, состоящая из нескольких компонентов. В свою очередь, каждый компонент представляет собой отдельную, вполне самостоятельную технологию. Рассмотрим их по порядку.

Утверждения

Dinamic Access Control основывается на утверждениях (claims). Для утверждений существует множество определений, приведу наиболее короткое. Утверждение – это информация об объекте, полученная из достоверного источника. В нашем случае объектом служит учетная запись пользователя или компьютера в Active Directory, а в качестве достоверного источника выступает служба KDC (Key Distribution Service), расположенная на контроллере домена.

К утверждениям можно отнести любое из свойств пользователя или компьютера, например принадлежность к определенному подразделению (OU) или членство в группе безопасности, должность пользователя и отдел, в котором он работает, страну и город проживания, почтовый индекс, номер телефона и многое другое.

В Windows Server 2012 используются утверждения трех типов:

1. Утверждения для пользователей (user claim) — в качестве утверждений используется атрибуты учетной записи пользователя в Active Directory, например департамент или должность;
2. Утверждения для устройств (device claim) — здесь в качестве утверждений используется атрибуты учетной записи компьютера, такие как операционная система или состояние здоровья;
3. Утверждения преобразования (transformation claim) — этот тип используется для трансформации утверждений при прохождении через доверительные отношения между лесами. Утверждения этого типа не базируются на атрибутах AD.

Условные выражения

Условные выражения (conditional expressions) представляют из себя сочетание из нескольких (двух и более) утверждений, разделенных логическим оператором. По сути это логические выражения, в котором мы производим сравнение правой и левой части и в качестве результата получаем одно из двух значений — TRUE или FALSE. Выражения используются как при авторизации, так и для проверки доступа к ресурсу.

Примечание. Кроме TRUE и FALSE существует еще один тип значения — UNKNOWN. Это значение возможно получить например в том случае, если соответствующий атрибут пользователя в AD не заполнен.

Напомню, что из себя представляют операторы. Скорее всего они вам знакомы, поэтому подробно описывать не буду, а просто перечислю их значения: равно (==), не равно (!=), больше чем (>), меньше чем (<), больше или равно (>=),  меньше или равно (<=), не (!), и (&&), или (||), содержит (Contains), любой из (Any_of), член группы (MemberOf) и любой член группы (MemberOf_Any).

Для того чтобы понять, как работают условные выражения, возьмем пример выражения, которое может использоваться для ограничения доступа к ресурсу:

User.Title==″Sales Manager″ && (User.Department==″Management″ || User.Department==″Sales″)

Это выражение условно можно разбить на 3 части, каждая из которых использует утверждения. В соответствии с правилами обработки условных выражений, первыми обрабатываются выражения в скобках. И поскольку из двух операторов первым должен обрабатываться  оператор ==,  выражение в скобках обрабатывается слева направо.

В качестве утверждения пользователя идет User.Department, отвечающее за департамент, в котором работает сотрудник. Предположим, наш пользователь является сотрудником отдела продаж (Sales). В этом случае левая часть выражения в скобках для него принимает значение FALSE, а правая TRUE и наше выражение примет вид:

User.Title==″Sales Manager″ && (FALSE || TRUE)

Так как для оператора || достаточно наличия в скобках хотя бы одного значения TRUE, то наше выражение сокращается до такого:

User.Title==″Sales Manager″ && TRUE

Теперь проверяем левую часть выражения. В ней используется атрибут User.Title, отвечающий за должность предполагаемого сотрудника. Если он является менеджером отдела продаж (Sales Manager), то выражение примет вид:

TRUE && TRUE

Для оператора && требуется, чтобы оба условия были истинными. В нашем примере это так, следовательно все выражение примет значение TRUE и пользователь получит доступ к ресурсу.

Свойства ресурсов

Ресурсами, которые можно защитить с помощью Dinamic Access Control, являются файлы. На файловых серверах Windows Server 2012 появилась возможность классифицировать ресурсы, указав для каждого файлового ресурса определенные свойства, а затем использовать эти свойства для определения разрешений доступа.

Вспомним, какие разрешения действуют на файлы.

Share Permission

Для каждой папки, находящейся на сетевом ресурсе, действуют разрешения на шару (Share Permission). Когда то давно, до появления NTFS, это был единственный способ ограничить доступ к файловым ресурсам. На данный момент этот механизм устарел, поэтому хорошей практикой считается в Share Permissions давать полный доступ (Full Access) для всех (Everyone), а контроль доступа осуществлять с помощью разрешений NTFS.

NTFS Permissions

В файловой системе NTFS к каждому объекту  (файлу или папке) привязан список контроля доступа (Access Control List, ACL). В ACL хранятся идентификаторы безопасности (SID) пользователей и групп, которым явным образом разрешен (или запрещен) доступ к объекту. Соответственно, если пользователь или группа, членом которой он является, не указаны в ACL, то такой пользователь доступ не получит.

В ACL содержатся записи управления доступом (Access control entry, ACE), которые и определяют разрешения пользователя при доступе к объекту. Каждый ACE представляет из себя:

• SID доверенного лица — идентификатор пользователя\группы, доступ которого мы контролируем;
• Маску доступа — тип доступа (чтение, запись, выполнение и т.д);
• Флаги — определяют тип ACE (разрешение или запрет), а также параметры наследования.

Примечание. Кроме явно назначенных разрешений в ACL могут входить разрешения, наследуемые из дескриптора безопасности родительского объекта. Наследование позволяет применять разрешения доступа родительского объекта к любому дочернему объекту, что избавляет от необходимости назначать разрешения каждому новому объекту. Наследование включено по умолчанию, но при необходимости можно его отключить и изменить наследуемые разрешения.

ACE располагаются в ACL в определенном приоритетном порядке:

• Первыми идут ACE, назначенные на объект явным образом (т.е. вручную), сначала запрещающие ACE, потом разрешающие;
• Затем следуют разрешения, наследуемые напрямую от родительского объекта, также сначала запрещающие, потом разрешающие;
• И затем идут разрешения, наследуемые от других вышестоящих объектов.

С появлением Windows Server 2012 ситуация изменилась. ACE значительно расширились и появилась возможность включать в них утверждения. На рисунке приведен стандартный дескриптор безопасности (он же ACE) папки. В терминах языка SDDL (Security Definition Descriptor Language) он означает следующее:

O:BA — владельцем объекта (Owner) является встроенная группа Builtin\Administrators;
G:DU — основная группа Domain Users;
D:PAI — дескриптор имеет тип DACL (D), в нем заблокировано наследование от вышестоящих объектов (P), но разрешено для нижестоящих объектов (AI);
A — Allow, означает разрешающий ACE;
OICI — флаги наследования для дочерних объектов;
0x1301bf — разрешения Modify и Synchronize в шестнадцатеричном виде;
AU — группа Authenicated Users.

Проще говоря, пользователи, входящие в группу Authenicated Users, имеют разрешение на изменение содержимого этой папки.
А вот тот же ACE, но уже с использованием утверждений. Рассмотрим поподробней, что изменилось. Во первых, появилась буква X, которая означает, что в ACE используются утверждения, а во вторых, в скобках содержится условное выражение. В этом выражении говорится, что доступ к объекту cмогут получить только те пользователи, у которых атрибут Department имеет значение Sales, а атрибут Office — значение Central. То есть доступ разрешен для сотрудников отдела продаж, работающих в центральном офисе.

Использование ACE на основе утверждений значительно расширяет возможности по управлению доступом, ведь в качестве критерия доступа может выступать как свойства пользователя, так и ресурса. Также стоит помнить, что утверждения не отменяют стандартные разрешения NTFS, а дополняют их. При доступе к ресурсу сначала проверяется принадлежность пользователя к нужной группе безопасности, и только при положительном результате проверки очередь доходит до утверждений.

Центральные политики доступа

Итак, мы имеем с одной стороны утверждения пользователей и устройств, а с другой — классификацию ресурсов. Для объединения этих технологий используются централизованные политики доступа (Central Access Policy, CAP). CAP хранятся в службе Active Directory, в разделе конфигурации и являются общими для всего леса.
Типичный пример центральной политики доступа приведен на следующем рисунке.

 

Процесс создания и применения CAP состоит из нескольких этапов:

• Сначала создаются необходимые утверждения для пользователей и устройств;
• Затем создаются свойства ресурсов;
• Свойства ресурсов применяются к файловым серверам, и на их основании производится классификация файлов;
• На основе утверждений создаются централизованные правила доступа (Central Access Rule), которые представляют из себя набор условных выражений наподобие описанных ранее;
• Создается CAP, в которую входят одно или несколько централизованных правил доступа;
• CAP публикуется в Active Directory и распространяется на файловые сервера с помощью групповых политик.

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

Kerberos

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

Напомню в общих чертах, как происходит доступ к ресурсу с использованием Kerberos.

1. Пользователь пытается войти в систему, для чего вводит свои учетные данные — имя пользователя, пароль и домен. Клиент Kerberos на рабочей станции обращается к службе KDC на контроллере домена и отправляет ей запрос на аутентификацию (KRB_AS_REQ). В запросе содержится имя пользователя, имя домена и специальный аутентификатор — текущее время на рабочей станции, зашифрованное хэшем пароля пользователя.

2. Служба KDC находит пользователя в AD, извлекает его секретный ключ и расшифровывает аутентификатор, получая таким образом время отправки запроса. Если расшифровка прошла успешно и полученное время не расходится с временем на контроллере домена более чем на 5 минут (политика Kerberos по умолчанию), KDC выдает ответное сообщение (KRB_AS_REP). В ответе содержится сессионный ключ и отметка времени окончания билета, зашифрованные секретным ключом пользователя, а также билет TGT (Tiсket Granting Ticket), который зашифрован секретным ключом службы KDC.

На этом заканчивается первый этап, пользователь успешно аутентифицируется в домене и входит в систему на своей рабочей станции.

3. Теперь пользователю требуется получить доступ к ресурсам, находящимся на файловом сервере. В Kerberos любой объект, к которому требуется получить доступ, называется службой. Клиент опять обращается к службе KDC с запросом (KRB_TGS_REQ), в котором содержится имя службы, к которой нужен доступ, имя пользователя и отметка времени, зашифрованные сессионным ключом, а также билет TGT.

4. KDC расшифровывает TGT, используя свой собственный ключ, а метка времени расшифровывается копией сессионного ключа. Если со временем все в порядке и билет TGT не просрочен, клиенту отправляется ответ (KRB_TGS_REP), содержащий две копии билета TGS (Ticket Granting Service), один для клиента и один для службы. При этом билет службы шифруется секретным ключом этой службы и вкладывается в клиентский билет, который шифруется сессионным ключом пользователя.

В билет TGS входят имя пользователя, имя службы, маркер времени и срок жизни билета, а также новый сессионный ключ. Кроме того, в TGS есть раздел данных, известный как сертификат атрибута привилегий PAC (Privilege Attribute Certificate). В PAC содержатся SID пользователя и SIDы всех групп безопасности, членом которых он является.

5. Клиент получает ответ службы KDC, расшифровывает его сессионным ключом и извлекает новый сессионный ключ. Этим ключом он шифрует метку времени и отправляет ее вместе с именем пользователя и билетом службы TGS на сервер запросом (KRB_AP_REQ). Сервер принимает запрос, расшифровывает билет TGS своим секретным ключом и извлекает свою копию сессионного ключа. Этим ключом он расшифровывает метку времени и таким образом устанавливает подлинность клиента.

Подсистема безопасности на сервере извлекает из PAC данные пользователя. Затем она обращается в локальную базу данных и проверяет, не является ли пользователь членом локальной группы на данном компьютере, и если да, то добавляет полученные SID к списку данных, извлеченных из билета. На основе полученного списка формируется маркер доступа (Access token), который привязывается к сессии пользователя.

Теперь, когда пользователь запрашивает доступ к объекту, информация из маркера доступа сравнивается с дескриптором безопасности объекта, и на основе полученной информации пользователь получает (или не получает) требуемый доступ.

6. В некоторых случаях требуется передача дополнительного сообщения от сервера к клиенту (KRB_AP_REP). Этот процесс называется взаимной аутентификацией и используется в том случае, если клиент требует у службы подтверждение подлинности.

В Windows Server 2012 в протокол Kerberos были внесены некоторые изменения, призванные обеспечить поддержку Dynamic Access Control.

Kerberos Security Support Provider (SSP) — основа клиентской службы Kerberos. В Windows Server 2012 и Windows 8 библиотека Kerberos.dll была переработана для поддержки утверждений пользователя и данных авторизации устройства в атрибуте PAC.

PAC также был переработан и может включать в себя следующие данные:

• SID пользователя и SIDы всех групп безопасности, членом которых пользователь является;
• Утверждения пользователя;
• SID устройства и SIDы всех групп безопасности, членом которых устройство является;
• Утверждения устройств.

Составные удостоверения (Compound Identity) — еще одна новая технология, позволяющая включать в билет TGS не только авторизационные данные пользователя, но и данные его компьютера. Это позволяет предоставлять доступ как на основании того, кем является пользователь, так и на основании устройства, на котором он работает.

Защита Kerberos (Kerberos armoring) — технология создания защищенного канала между клиентом и службой KDC, ее еще называют FAST (Flexible Authentication Secure Tunnel). Суть этой технологии в следующем: перед аутентификацией пользователя его компьютер тоже должен пройти аутентификацию в домене и получить от службы KDC билет TGT. FAST использует этот билет для того, чтобы зашифровать дальнейший обмен данными между пользователем и KDC, создавая безопасный канал связи между ними и делая невозможным перехват сообщений.

И наконец в службу KDC (Kdcsvc.dll) Windows Server 2012 также включена поддержка утверждений и составных удостоверений.

С учетом всех этих новых возможностей процесс авторизации несколько изменился. Когда клиент отправляет запрос на контроллер домена, служба KDC получает запрос и проверяет значение флага claims в структуре PA-PAC-OPTION. Если он имеет значение TRUE, то значит клиенту требуются утверждения. KDC извлекает из базы Active Directory необходимые атрибуты и добавляет их в PAC. Клиент получает билет TGS, содержащий утверждения, и с этим билетом обращается к службе. Соответственно служба, получив билет TGS, извлекает из него утверждения и добавляет их в маркер доступа, на основании которого предоставляется доступ к ресурсу.

Часть 2. Настройка и использование Dynamic Access Control