Доступ к файловому серверу с помощью утверждений

Функция Dynamic Access Control, реализованная в службе Windows Server 2012 Active Directory Domain Services (AD DS), обеспечивает, помимо прочего, возможность работы с утверждениями. Динамический контроль доступа Dynamic Access Control — это мощная и сложная технология, позволяющая применять на файловых серверах Windows Server 2012 средства централизованного управления, классификации и защиты информации. Однако мало кто обратил внимание на то, что пользователи могут немедленно применять на этих файловых серверах утверждения, не дожидаясь реализации функции динамического контроля доступа.

Группы безопасности

Группы безопасности применяются в сфере управления доступом к файлам и папкам с тех пор, как на свет появилась файловая система Windows NT Server. Этот метод «сдерживания толпы», предполагающий добавление групп к списку управления доступом (ACL) с последующим управлением членством в группах, дал администраторам возможность управлять доступом к контролируемым ресурсам, не прибегая постоянно к спискам управления доступом. Если добавить к этому возможность вложения упомянутых групп (к примеру, для обеспечения доступа к той или иной папке из любой точки земного шара мы можем добавить к доменной локальной группе Sales глобальные группы NA_Sales, SA_Sales, EUR_Sales и APAC_Sales), мы получим мощную и гибкую модель управления доступом.

Однако всех проблем это не решает. Во-первых, одним из наименее проработанных аспектов «гигиены» Active Directory (AD) остается управление жизненным циклом групп безопасности. Все хотят создавать группы как можно быстрее, но когда приходит время ликвидировать такие группы, похоже, что до этого никому (кроме администраторов AD) нет дела. В результате в большинстве крупных доменов AD сохраняются десятки тысяч групп безопасности, многие из которых пусты, а планов по их удалению не существует.

Во-вторых, вы можете столкнуться с проблемами в процессе построения архитектуры управления доступом на базе универсальной/глобальной/доменной локальной группы доступа, если не обратите внимание на возможность приобретения или продажи компании, в результате чего может возникнуть необходимость в доступе из нескольких лесов.

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

Многие аспекты этой сложности находят свое отражение в маркере доступа пользователя. Маркер доступа AD, хранимый в поле Privilege Attribute Certificate (PAC) билета получения билета Kerberos ticket-granting ticket (TGT), содержит идентификатор безопасности данного пользователя, а также идентификаторы безопасности групп безопасности, к которым относится пользователь. Если вследствие сложной вложенности групп пользователь является членом множества групп, маркеры этого пользователя будут объемными, что может привести к возникновению проблем с доступом к ресурсу.

Одна из главных причин, объясняющих применение вложенных групп в данной модели, состоит в том, что они представляют собой единственную архитектурную конструкцию, обеспечивающую выполнение операций AND. Рассмотрим для примера реализуемую в США силами некой транснациональной корпорации программу, относящуюся к категории секретных. Одно из требований состоит в том, что доступ к папке, содержащей информацию о зарплатах участвующих в программе служащих, имеют только сотрудники управления по работе с кадрами. Далее, поскольку речь идет о секретах корпорации, такой доступ могут иметь только штатные сотрудники управления кадрами, причем являющиеся гражданами США. Если для управления доступом будут использоваться только группы безопасности, схема управления доступом может иметь вид, как на рисунке 1. В этом случае для обеспечения доступа необходимо создать 12 групп с целью выполнения трех условий AND. Умножьте этот показатель на коэффициент, составляющий для транснациональной корпорации несколько сотен единиц, и вы поймете, каковы масштабы проблемы.

Рисунок 1. Пример модели управления доступом

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

В модели управления доступом, представленной на рисунке 1, применяются только группы безопасности и не используется репозитарий актуальных корпоративных данных: собственно Active Directory.

В большинстве компаний служба AD получает почти все данные об атрибутах пользователей непосредственно из баз данных кадровых служб, что гарантирует актуальность этих данных. Однако если в компании не используется внешний обработчик — скажем, служба метакаталогов, — эти изменения не находят отражения в членстве групп безопасности.

Доменные службы AD системы Server 2012 обеспечивают передачу атрибутов пользователей и устройств в файловую службу в форме утверждений (или заявок). Когда эта функция активирована, вы можете добавлять значения атрибутов (такие, как название отдела или номер) в список управления доступом к файлу или к папке с тем, чтобы управлять доступом к соответствующему ресурсу. И хотя я не вижу, каким образом утверждения могут вытеснить группы безопасности в механизме управления доступом — классы атрибутов AD жестко определены, и их нельзя просто так создавать либо модифицировать — применение атрибутов AD в форме утверждений с целью дополнения и, вероятно, упрощения управления доступом на базе групп может быть хорошим подспорьем для администраторов. Далее я объясню, как можно использовать эту гибридную модель в приведенном выше примере.

Вместо двух из трех условий в этом примере, Full Time Employees_US и HR Department_US, можно задействовать утверждения. Рассмотрим условие Full Time Employees_US. Я могу расщепить его на два атрибута AD. Во-первых, страна, гражданином которой является тот или иной служащий, может быть представлена двузначным атрибутом countryCode (типичным выбором для Соединенных Штатов будет комбинация 00). А во-вторых, статус служащего будет наилучшим образом представлять атрибут employeeType. Последний из перечисленных атрибутов является строковым, так что можете определять его по своему усмотрению. Это и хорошо, и плохо; его следует облечь в форму максимально простую и удобную для чтения. Иными словами, значения 0, 1, 2 и 3 вполне хороши, но никто из просматривающих эти атрибуты не сможет сказать, что же стоит за данными значениями. Используйте другие обозначения. Они могут быть простыми, но в то же время должны содержать некий ключ, указывающий на смысл того или иного значения: «F" или»FTE«может означать»full-time employee«, то есть»штатный сотрудник«, "T» — «временный сотрудник» (temp), «C" -»контракт«(contract), а»V«- поставщик (vendor). Разумеется, указанные обозначения построены на базе английского языка, но ведь речь идет о компании, базирующейся в Соединенных Штатах.

Заданное условие можно описать следующим образом:

user.countryCode=00 AND user.employeeType=FTE

Для отдела HR Department_US я могу дополнительно упростить ситуацию. Если я буду исходить из того, что приведенное выше выражение истинно (то есть сотрудники являются гражданами США и штатными служащими), то если они состоят в штате отдела по работе с кадрами, они будут являться членами отдела US HR department. Чтобы выразить эту мысль в утверждении AD, я могу воспользоваться атрибутом департамента:

user.department=HR

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

Рисунок 2. Гибридная модель управления доступом на?основе групп и утверждений

Можно утверждать даже, что локальная группа Secret US Program Employee Bonusesdomain является излишней (хотя возможно, что в соответствии со стандартной практикой организации доступа ее следует оставить). С помощью условных выражений я сократил число групп, необходимых для представления этого условия доступа, на две трети.

Пример формирования гибридных разрешений

Ниже следует пошаговое описание того, как нужно реализовывать данный гибридный набор разрешений в вымышленном домене Fly By Night Software (flybynightsoftware.com). Сначала создайте доменную локальную группу Secret US Program Employee Bonuses, а затем глобальную группу Secret Project Members_US. Добавьте Secret Project Members_US в Secret US Program Employee Bonuses и включите эту группу в список управления доступом Program Bonusesfolder. Далее создайте параметры управления на базе утверждений.

Перед тем как приступать к созданию типов утверждений, вам надлежит активировать утверждения для своего домена с помощью процесса, который я описал в статье»Enable Claims Support в Windows Server 2012 Active Directory«, опубликованной в предыдущем номере журнала. Затем вы должны создать типы утверждений для следующих атрибутов пользователей:

employeeType
countryCode
department

Чтобы выполнить эту задачу, запустите административный центр Active Directory (см. экран 1).

Экран 1. Административный центр Active Directory

Это можно сделать тремя способами, но если у вас открыто окно командной строки, просто введите символы DSAC.

На левой панели содержания щелкните на стрелке рядом с Dynamic Access Control и выберите пункт Claim Types (см. экран 2).

Экран 2. Выбор типа утверждения

В правой части экрана появляется панель Tasks, на которой вы можете создавать новые типы утверждений. Типы утверждений появляются и на левой панели содержания в разделе Dynamic Access Control.

На панели Tasks выберите пункты New и Claim Type. Откроется диалоговое окно Create Claim Type (см. экран 3).

Экран 3. Создание типа утверждений

В поле фильтра Source Attribute введите имя служащего. При этом число доступных атрибутов автоматически сокращается до трех; выберите из списка атрибут employeeType. Отметим, что отображаемое имя по умолчанию совпадает с отображаемым именем атрибута. Если вы хотите сделать имя более понятным, замените его именем Employee Type. Можете также актуализировать описание так, чтобы оно включало в себя различные возможные значения данного атрибута.

Находясь в поле Description, не вводите в текст символ переноса строки; если вы нажмете клавишу Enter, система просто создаст тип утверждения в момент, когда вы не будете к этому готовы. Когда же вы будете готовы, нажмите кнопку OK, создавая тем самым требуемый тип утверждения. Повторите процесс для атрибутов countryCode и department (см. экран 4).

Экран 4. Созданы все типы утверждений

Теперь вы готовы к настройке папки Program Bonuses с помощью данной комбинации групп безопасности и утверждений. Просмотрите свойства папки, вкладку Security, затем дополнительные разрешения и нажмите кнопку Add. Углубившись на четыре уровня в диалоговые окна File Explorer, вы доберетесь до окна Permission Entry (см. экран 5), где создается элемент управления доступом (ACE), который вы сможете добавить в дискретный список управления доступом (discretionary ACL, DACL) соответствующей папки.

Экран 5. Добавление условных выражений в элемент управления доступом

В этом диалоговом окне три основных раздела. В первом разделе выбирается субъект безопасности (в данном случае это Secret US Program Employee Bonuses), который будет добавлен в элемент управления доступом. Далее следует тип доступа, который будет предоставлен. Третий раздел новый. В нем вы можете указывать условия, ограничивающие доступ к ресурсам. Если вам приходилось работать с медиаплеером iTunes корпорации Apple, этот раздел покажется вам знакомым; подобным же образом создается интеллектуальный список воспроизведения на базе атрибутов отобранных музыкальных файлов). На экране 5 я добавил три условия на базе утверждений, необходимые для удовлетворения требований по доступу из нашего примера. Вы увидите, с какой легкостью выполняется процедура настройки условного доступа после того, как вы подготовили соответствующие утверждения, доступные в данном диалоговом окне.

После нажатия кнопки OK эти условия отображаются в столбце Conditions диалогового окна Advanced Security Settings (см. экран 6).

Экран 6. Список управления доступом с элементом управления доступом на основе условного выражения

Предостережения по поводу элементов управления доступом на базе утверждений

Применение элементов контроля доступа на базе утверждений влечет за собой некоторые сложности в управлении, и вам следует принять их во внимание. При работе с групповой моделью нужно внимательно относиться к тому, кто из пользователей имеет право на выполнение так называемых CRUD-операций (create, (read), update, delete), которые приводят к изменению состава группы. Аналогичные сложности существуют и при работе с утверждениями: вы должны обращать внимание на то, кто наделяется правами вводить, обновлять и удалять значения атрибутов AD. Но поскольку нужды в этом до сих пор практически не ощущалось, управление атрибутами AD в большинстве компаний не получило такого же развития, как управление группами. Так что если вы хотите задействовать средства управления доступом на базе утверждений, вам следует быть внимательными. Вводится ли данный атрибут из соображений»удобства" с другой системы или иным способом, обеспечивающим безопасность? Кто из сотрудников HR-отдела имеет право вводить атрибуты employeeType, countryCode и departmentattributes? А что произойдет, если пользователь с такими правами доступа изменит формат одного из упомянутых атрибутов? Приведет ли это к нарушению выполненных вами настроек системы управления доступом на базе утверждений в производственной сфере? И будет ли вам заблаговременно отправлено предупреждение о таком нарушении?

Кроме того, вам нужно быть уверенным в том, что данные AD не скомпрометированы и согласованы как внутри домена, так и в рамках ряда доменов, если в вашей сети имеется многодоменный лес. Вы не можете рассчитывать на согласованную работу утверждения, если данные, на которых оно основано, не являются согласованными. К тому же вам не следует забывать о воздействии, которое утверждения оказывают на билет получения билета Kerberos TGT. Если вы будете использовать тот или иной тип утверждения для определения относящегося ко множеству субъектов атрибута, такого, как employeeType, значение этого утверждения попадет в маркеры безопасности всех пользователей компании. Само по себе это обстоятельство не имеет особого значения, но если вы будете использовать в утверждениях широко распространенные AD-атрибуты и не продумаете заранее, к чему это может привести, — пеняйте на себя. Впрочем, если тот или иной атрибут заполняется только для отдельных пользователей, он будет добавлен к маркерам безопасности только этих пользователей.

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

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

Опыт работы с утверждениями

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