Такая технология как динамический контроль доступа рассматривается в моих статьях уже достаточно давно, но, если честно, я еще не добрался даже до половины всех тем, которые мне хотелось бы рассмотреть. Но, тем не менее, эта статья позволит вам значительно лучше освоить данную технологию и узнать об очередном кирпичике, который крепится ко всему фундаменту динамического контроля доступа. Образно говоря, к такому кирпичику динамического контроля доступа можно отнести не что иное, как сам централизованный доступ. Центральный доступ, по своему существу, позволяет вам реализовать централизованный механизм соответствующих политик авторизации, благодаря которым вы сможете автоматизировать в своей компании "умное" распределение прав. Ведь если вы должным образом сгенерируете свои утверждения, распланируете и создадите все заточенные под ваш бизнес объекты свойств ресурсов, настроите требуемые списки свойств ресурсов и реализуете красивую и корректную классификацию, но допустите непреднамеренные банальные ошибки при работе с централизованными правилами или политиками доступа, весь ваш труд может полететь в тартарары.
Именно по этой причине крайне важно уделить должное внимание созданию своих уникальных централизованных правил и политик доступа и потратить на это столько времени, сколько будет необходимо для того, чтобы полностью предвидеть все возможные ситуации, которые могут произойти уже после того, как вы внедрите технологию динамического контроля доступа в свою производственную среду. Здесь очень важно, чтобы вы все тесты изначально провели в лабораторных условиях и, по возможности, с пилотной группой, так как в противном случае исход может быть самым непредсказуемым. В принципе, к планированию динамического контроля доступа мы с вами еще вернемся в одной из последних статей данного цикла, поэтому останавливаться подробнее на данном этапе в рамках этой темы попросту бессмысленно.
Сегодня будут рассмотрены такие моменты, как назначение самих централизованных правил доступа и централизованных политик доступа. Вы узнаете о том, каким образом можно создать, отредактировать и удалить такие правила и политики. Более того, в этой статье вы узнаете о самом распространении и применении централизованных политик доступа. Получается, как и в случае с четвертой статьей данного цикла, материала в этой статье будет достаточно много, по этой причине будем переходить к первому разделу.

Централизованные правила доступа

Прежде чем мы начнем создавать централизованные правила доступа, следует определиться с тем, что же вообще это такое и для чего нужны такие объекты. По своему определению, Централизованное правило доступа - это выражение правил авторизации, которые могут включать одно или несколько условий, затрагивающих группы пользователей, требования пользователей и устройств, а также свойства ресурсов. Получается, сгенерированное централизованное правило доступа определяет, кому будет предоставлен доступ к определённой области ресурсов. Как и все объекты технологии динамического контроля доступа, такие правила обязательно должны включать в себя уникальные имена и, что, конечно, опционально, понятные описания. Более того, как я уже успел указать ранее, эти правила также включают в себя определенные выражения, которые представляют собой условные выражения языка SDDL (Security Descriptor Definition Language).
Также можно отметить и то, что несколько централизованных правил доступа можно объединить в централизованную политику доступа. В общих чертах, если для домена определены одно или несколько централизованных правил доступа, администраторы файловых ресурсов для своего удобства могут сопоставить определенные правила с определенными ресурсами и бизнес-требованиями.
В принципе, по теоретической части касательно централизованных правил доступа сказать уже, по сути, нечего, поэтому перейдем к более интересной части: практической. Далее я расскажу о создании, редактировании, а также об удалении централизованных правил доступа. Начинать мы, естественно, будем с

Создания централизованного правила доступа

Прежде всего стоит знать о том, что по умолчанию на серверах не создается ни одного централизованного правила. Поэтому вам для дальнейшего использования централизованных правил доступа, а уж тем более централизованных политик доступа, обязательно нужно будет создавать таковые собственноручно. Само по себе создание уникальных централизованных правил доступа - задача не сложная. Этот процесс вам может напомнить создание всех объектов, о которых мы с вами говорили на протяжении всех предыдущих статей настоящего цикла, так как выполнить данную задачу вы можете как при помощи центра администрирования Active Directory, так и средствами такого инструмента как Windows PowerShell. Начинать будем, естественно, с консоли центра администрирования Active Directory. Весь этот процесс выглядит следующим образом:

1. На контроллере домена вам следует открыть консоль "Центр администрирования Active Directory", где в области узлов перехода нужно выделить узел "Динамический контроль доступа", а затем выбрать "Central Access Rules"(Dynamic Access Control > Central Access Rules). Также вы можете перейти к этому узлу, выбрав опцию под номером 3 - "Создать централизованное правило доступа" на плитке динамического контроля доступа на начальном экране данной консоли;
2. На втором шаге данной процедуры вам нужно либо из контекстного меню области сведений, либо из области"Задачи" (Tasks) последовательно выбрать опции "Создать", а также "Централизованное правило доступа"(New > Central Access Rule), как видно на следующей иллюстрации:

   
   Рис. 1. Создание нового централизованного правила доступа

3. Как можно заметить на иллюстрации под номером 2, в отобразившемся диалоговом окне вам следует определить значения требуемых управляющих элементов в трех различных группах, причем для создания нового правила вам даже, по большому счету, будет достаточно заполнить только первый контрол верхней группы. Но обо всем по порядку:
   
   • Группа "Общие" (General). Эта группа имеет чуть ли не стандартный набор параметров для большинства создаваемых объектов технологии динамического контроля доступа. В этой группе вам разрешается определить следующие три основные параметра, а именно:
     
     • Имя (Name). Тут все понятно: для идентификации каждого такого правила вам обязательно нужно указывать его имя. Имена должны быть уникальны, указаны в буквенно-цифровом формате, и заполнение этого параметра считается обязательным условием для создания правила доступа. Между прочим, еще во время планирования своих централизованных правил доступа обязательно учтите, что максимально допустимое число знаков для имени вашего правила - 64 знака. То есть вам нужно не превысить данный лимит. Например, в данном примере пусть правило будет называться "Разрешение чтения ресурсов филиалов маркетологам централ. офиса";
     • Описание (Description). Необязательное для заполнения текстовое поле, но наличие описания вам может помочь в том случае, если у вас будут сгенерированы десятки, а то и больше централизованных правил доступа. Как и в случае с именем, количество символов в этом поле также лимитировано. Вы должны уместить описание своего правила максимум в 1024 символа, так как в противном случае вы просто не сможете создать такое правило. В описании напишем "Разрешает получать доступ на чтение маркетологам главного офиса к целевому ресурсу филиалов компании";
     • Защита от случайного удаления (Protect from accidental deletion). Стандартный флажок для объектов центра администрирования Active Directory, который запрещает всем, кроме создателя правила, удалять текущее правило, причем даже учитывая то, что создавать, изменять или же удалять такие правила могут только администраторы, входящие в группы безопасности администраторов домена и администраторов предприятия.
   • Группа "Целевые ресурсы" (Target Resources). Вторая группа данного диалогового окна используется для определения так называемой области действия централизованного правила доступа. Такая область действий создается путем определения созданных ранее объектов свойств ресурсов в качестве так называемых условных выражений. Таким образом, для создаваемого вами правила вы сможете определить практически любую возможную область применения. Несмотря на то, что зачастую принято применять централизованные правила доступа исключительно к небольшим группам того же дискового пространства, можно оставить значение по умолчанию, благодаря чему правило будет применяться ко всем возможным целевым ресурсам. Группировать такие условные выражения вы можете при помощи стандартных операторов И либо ИЛИ. Более того, для создания более сложных сценариев вы можете одновременно группировать по нескольку условных выражений, объединяя области действия таких результатов. Иначе говоря, если вы хотите изменить установленную по умолчанию область действия своего правила, нажмите на кнопку "Изменить" (Edit).
   • Группа "Разрешения" (Permissions). Благодаря этой заключительной группе параметров вы можете предопределить разрешения для создаваемого вами правила при помощи двух различных функциональных возможностей, а именно:
     
     • "Использовать следующие разрешения как предложенные" (Use following permissions as proposed permissions). Согласно официальному определению, этот параметр позволяет вам выполнять аудит результатов запросов на доступ к целевым объектам, не затрагивая работу системы. Иначе говоря, выбрав этот параметр, вы тем самым сможете добавить записи разрешений из соответствующего списка в список предлагаемых записей разрешений для создаваемого вами централизованного правила доступа. Список предлагаемых разрешений можно сочетать с файловой системой аудита для моделирования эффективного доступа, который пользователи будут получать к ресурсу, без изменения как таковых записей разрешения в списке текущих разрешений. Предложенные разрешения генерируют специальное событие аудита, которое можно будет обнаружить в журнале событий, где вы уже сможете подробнее рассмотреть все попытки доступа, выполняемые вашими пользователями;
     • "Использовать следующие разрешения как текущие" (Use following permissions as current permissions). Выбрав этот параметр, вы сможете обеспечить доступ к целевым ресурсам после публикации централизованной политики доступа, где будет фигурировать такое правило. Иначе говоря, текущий список разрешений представляет собой дополнительные разрешения, которые будет считывать операционная система Windows при развертывании централизованного правила доступа на файловом сервере. Как я уже говорил, централизованные правила доступа не заменяют существующие параметры безопасности, и при принятии решения об авторизации система Windows обязательно будет оценивать записи разрешений централизованного правила доступа, текущий список разрешений NTFS, а также списки разрешений общего ресурса.
     
     В данном случае следует остановиться на втором варианте и после нажатия на кнопку "Изменить" (Edit) в уже привычном многим диалоговом окне дополнительных параметров безопасности добавить требуемую группу, например, "Маркетологи Лос-Анджелеса", которой будут назначены права "Чтение и выполнение", а также обычное "Чтение".

     
     Рис. 2. Диалоговое окно создания нового централизованного правила доступа

4. После того как все настройки будут определены, можете смело сохранять свое правило доступа.

Как видите, здесь нет ничего сложного. Теперь, пожалуй, рассмотрим такой момент, как создание централизованных правил доступа несколько иным методом, а если говорить точнее, то при помощи такого мощнейшего административного средства как Windows PowerShell. Если полностью обобщить командлеты PowerShell, отвечающие за управление такими политиками, то, как и в случае с  управлением списками свойств ресурсов, о которых шла речь в предыдущей статье данного цикла, здесь можно выделить три различных командлета, а именно: New-ADCentralAccessRule, благодаря которому вы можете создавать новые централизованные политики доступа, Set-ADCentralAccessRule, позволяющий редактировать существующие правила, а также Remove-ADCentralAccessRule, который, соответственно, отвечает за удаление последних. Ввиду того, что операции по редактированию и удалению существующих правил доступа средствами PowerShell выполняются достаточно просто, эти операции в текущей статье будут попросту опущены. А сейчас же займемся созданием новой централизованной политики доступа.
Например, сейчас нужно создать политику, которая будет называться "Доступ маркетологов Лос-Анджелеса к ресурсам маркетинга" с описанием "Политика, разрешающая маркетологам получать доступ ко всем ресурсам, классифицированным для подразделения Marketing", которая разрешает соответствующей группе получать доступ ко всем ресурсам с правильной классификацией. В данном случае команда PowerShell будет выглядеть следующим образом:

где: 

• Параметр Name отвечает за имя создаваемого объекта. Назначение и ограничения этого параметра полностью совпадают с возможностями консоли центра администрирования;
• Параметр Description предназначен для указания описания создаваемого вами правила;
• Параметр CurrentACL позволяет определить текущий список разрешений для создаваемого вами правила доступа. Самое сложное в значении этого параметра то, что здесь нужно указать все ваши разрешения в краткой форме, записанной на языке SDDL. С этим параметром самое главное - тщательное изучение документов  ACE Strings и  SID Strings. В целом, всегда перепроверяйте правильность указания этого параметра, так как ошибки, связанные с этим параметром, могут оказаться решающими;
• Параметр ProposedAcl определяет предложенные разрешения, которые указываются в том же формате, что и предыдущий параметр, и на которых мы с вами подробнее остановимся в следующем подразделе данной статьи;
• Параметр ProtectedFromAccidentalDeletion представляет собой стандартный параметр общей группы диалогового окна создания централизованных правил доступа, отвечающий за защиту от случайного удаления;
• Параметр ResourceCondition - это параметр, значением которого должно выступать условие данного правила. В этом примере (@RESOURCE.Department_MS == `"Marketing`") все указывается точно так же, как и произносится вслух, то есть ресурс (@RESOURCE) подразделения (Department_MS) равняется (==) значению Marketing (`"Marketing`"). Чтобы научиться правильно составлять такие условия, требуется много практики, а также, при желании, вы можете периодически после создания правил вручную изучать журнал Windows PowerShell;
• Параметр Server - это просто имя сервера, на котором должно быть создано такое правило. Так как в данном частном случае именем сервера выступает DC домена diopharmaceutic.local, мы получаем соответствующее значение этого параметра.

Вывод данной команды очень простой: если вы не увидели ошибки - все хорошо и централизованное правило доступа у вас было создано. Пример вывода этой команды можно увидеть ниже:

Рис. 3. Создание централизованного правила доступа средствами Windows PowerShell

Изменение существующего централизованного правила доступа

Всегда бывают такие ситуации, когда после создания нового объекта возникает необходимость в его изменении. Быть может, при создании была допущена ошибка, может быть вы просто забыли добавить требуемое разрешение, может, заданное условие было недостаточно исчерпывающим… Вариантов может быть много. Но самое главное то, что в случае нехватки требуемой информации созданный объект необходимо модифицировать. Само собой, централизованные правила доступа нормально относятся к такой ситуации, и для изменения существующего объекта от вас не требуется никаких сверхъестественных действий. Грубо говоря, вы переходите к тому же узлу, в котором было создано само правило (Dynamic Access Control > Central Access Rules), находите такое правило в списке области сведений, а затем либо из контекстного меню такого объекта, либо из панели задач выбираете опцию "Свойства" (Properties).
В отобразившемся диалоговом окне изменения созданного вами правил, вам предоставляются практически те же возможности, что и при создании такого правила, за исключением трех моментов:

• Во-первых, вы не можете изменять наименование своего правила. Нет у вас такой возможности и все;
• Во-вторых, помимо редактирования текущих разрешений, вам еще предоставляют возможность настроитьпредложенные разрешения, о которых я вскользь упоминал во время создания централизованного правила доступа средствами Windows PowerShell. Что такое эти предложенные разрешения? Прежде всего, необходимо понимать разницу между текущими и предложенными разрешениями. Текущий список разрешений представляет собой записи, которые определяют доступ к ресурсам для вашего централизованного правила доступа. Эти разрешения вступят в силу после того, как вы развернете свое централизованное правило доступа с помощью централизованной политики доступа, о чем вы дальше узнаете из этой статьи. В свою очередь, предложенные разрешения можно обнаружить только лишь в том случае, если вы захотите просмотреть свойства или же изменить ваше существующее правило доступа. В списке предложенных разрешений вы можете просмотреть все возможные изменения в разрешениях между текущими участниками безопасности со списком предлагаемых разрешений. Но, несмотря на это, стоит обратить внимание на то, что такой список предложенных разрешения никак не повлияет на текущие разрешения пользователей. Также обязательно обратите внимание еще и на то, что если вы хотите иметь возможность просматривать и анализировать подобные промежуточные разрешения, вам необходимо активировать флажок"Включить поэтапную настройку разрешений" (Enable permission staging configuration). Более того, при работе с предложенными разрешениями обязательно обратите внимание на следующие возможности:
  
  • Параметр "Изменить" (Edit). Как очевидно, данная кнопка вызывает диалоговое окно дополнительных параметров безопасности, позволяя изменить или добавить разрешения в группу предложенных разрешений;
  • Параметр "Применить предложенные" (Apply Proposed). Данный параметр позволяет вам заменить текущие разрешения теми разрешениями, которые вы определили в группе предложенных разрешений;
  • Параметр "Копировать из текущих" (Copy from Current). В свою очередь, данный параметр позволяет вам выполнить обратное действие, то есть это действие попросту заменяет разрешения в списке предложенных разрешения разрешениями из текущего списка разрешений.
• В-третьих, после того, как вы один раз измените установленные изначально разрешения, при каждом последующем открытии диалогового окна свойств измененного вами централизованного правила доступа для вас станут доступны возможности еще одной группы - группы "Предыдущие разрешения" (Previous permissions). Что происходит после того, как вы изменили свое правило? После изменения разрешений централизованного правила доступа операционная система копирует первоначальные текущие разрешения в список группы "Предыдущие разрешения", а затем сохраняет обновленный из предложенных разрешений список текущих разрешений, а также список предыдущих разрешений. Главное помнить то, что этот список включает в себя только одну копию записей предыдущих разрешений. Иначе говоря, функциональные возможности центра администрирования Active Directory не поддерживают полную историю всех ваших изменений в разрешениях текущего списка разрешений.

На диалоговое окно свойств измененного централизованного правила доступа вы можете посмотреть на следующей иллюстрации:

Рис. 4. Диалоговое окно свойств измененного централизованного правила доступа

Удаление существующего централизованного правила доступа

Операции по удалению существующих централизованных правил доступа, скорее всего, наипростейшие операции, которые только можно выполнить. Для этого вам следует в узле Dynamic Access Control > Central Access Rules центра администрирования Active Directory выделить ненужное более правило доступа, а затем либо из контекстного меню, либо из панели задач выбрать команду "Удалить" (Remove). В отобразившемся диалоговом окне подтверждения удаления вам нужно будет нажать на кнопку "Да", означающую, что вы однозначно определились со своим выбором. И все, правило будет моментально удалено. 
В том случае, если перед вами отобразится диалоговое окно, свидетельствующее о нехватке прав, откройте диалоговое окно свойств удаляемого вами правила, а затем снимите флажок с опции Защита от случайного удаления (Protect from accidental deletion). После этого повторите действия по удалению правила.

Управление централизованными политиками доступа

С централизованными правилами доступа мы с вами уже разобрались, поэтому стоит переходить к следующей теме данной статьи, которая посвящается централизованным политикам доступа. Централизованные политики доступа - это политики авторизации, впервые появившиеся в серверной операционной системе Windows Server 2012 и включающие условные выражения. В принципе, такие политики представляют собой коллекции объектов централизованных правил доступа. Создавать такие политики можно при помощи центра администрирования Active Directory, а уже после этого вы сможете их распространять средствами функциональных возможностей групповой политики. Например, если бизнес-требования организации включают ограничение доступа к личным сведениям файлов владельцем файла и членами какого-то подразделения, скажем, отдела кадров, которым разрешено просматривать личные сведения, тогда это общая политика организации, применимая к файлам личных сведений, на каком бы из файловых серверов организации они ни располагались. Как я уже сказал, централизованные политики доступа могут включать в себя одно или несколько централизованных правил доступа, а централизованные правила доступа, в свою очередь, могут быть членами нескольких различных централизованных политик доступа.
Тут, как я уже упоминал ранее, вам обязательно следует обратить внимание на то, что централизованные политики доступаповышают безопасность доступа к файлам и папкам, которые располагаются на выделенных файловых серверах, но никак не заменяют какие-либо локальные политики доступа или же избирательные таблицы управления доступом (DACL), которые уже применяются к тем же файлам или папкам. Иначе говоря, они работают слаженно и сообща. Возьмём такой простейший пример: в централизованной политике доступа четко прописано, что пользователь может использовать конкретный документ, размещенный на файловом сервере, но в списке DACL определено, что в доступе к файлу отказано. Таким образом, пользователь не сможет получить доступ к такому документу. С таким ограничением можно столкнуться по той причине, что правила запрета всегда будут превалировать над разрешающими правилами, причем независимо от того, при помощи какой технологии вы запрещали либо разрешали доступ к самому файлу или папке.
С назначением централизованных политик доступа мы с вами немного разобрались, но также желательно знать еще о некоторых предварительных требованиях, которые обязательно должны быть соблюдены перед тем, как вы начнете у себя в организации внедрять централизованные политики доступа. К этим требованиям можно отнести то, что:

1. Вы должны создать утверждения, которые будут при помощи соответствующих атрибутов подключены к объектам учетных записей пользователей или компьютеров;
2. Также вам понадобится создать определения свойств файла;
3. Необходимо создать одно или несколько централизованных правил доступа, естественно, в зависимости от ваших бизнес-требований;
4. Следует создать как минимум один объект централизованной политики доступа и, как следствие, определить ее параметры;
5. При помощи функциональных возможностей групповой политики следует распространить такие политики на файловые сервера. Таким образом, ваши файловые сервера под управлением операционных систем Windows Server 2012/2012 R2 уже будут знать о существовании динамического контроля доступа и о том, что в вашей организации были созданы централизованные политики доступа;
6. В конце концов, на конечных серверах необходимо применить такие политики на выбранные вами общедоступные папки.

Теперь перейдем к практической части этого раздела и посмотрим, каким образом можно создавать, редактировать, добавлять или удалять к такому объекту централизованные правила доступа, а также как можно удалить объекты централизованных политик доступа, причем как при помощи консоли центра администрирования Active Directory, так и средствами Windows PowerShell.

Создание централизованной политики доступа

Задачи, связанные с управлением централизованными политиками доступа, очень похожи на задачи, связанные с реализацией централизованных правил доступа. В приведенном ниже примере будет показано создание централизованной политики доступа, основанное на первом созданном в этой статье правиле доступа. Итак, чтобы создать такую политику, нужно выполнить следующие действия:

1. В консоли центра администрирования Active Directory на этот раз нужно перейти к узлу "Динамический контроль доступа > Central Access Policies" (Dynamic Access Control > Central Access Policies), либо можно выбрать опцию под номером 4, которая называется "Создать централизованную политику доступа" на плитке динамического контроля доступа на начальном экране текущей консоли. Находясь в этом узле, вызовите из области сведений контекстное меню или на панели задач выберите опции "Создать" и "Централизованная политика доступа"(New > Central Access Policy), как показано на следующей иллюстрации:

   
   Рис. 5. Создание централизованной политики доступа

2. После этого, находясь в диалоговом окне "Создать Централизованная политика доступа" (Create Central Access Policy), вы можете определить все требуемые параметры для будущей политики доступа. В отличие от диалогового окна создания или изменения централизованных правил доступа, при создании таких политик вам предоставляется возможность редактирования параметров лишь двух групп, а именно:
   
   • Группа "Общие" (General). Как и в предыдущем случае, это общие параметры, позволяющие должным образом охарактеризовать вашу политику. Здесь вы можете определить три уже давно известных и понятных параметра:
     
     • Имя (Name). Позволяет указать читабельное имя для создаваемой вами политики. В нашем примере данное правило будет называться "Маркетологи Лос-Анджелеса";
     • Описание (Description). Привычное описание для создаваемого объекта динамического контроля доступа. В этом поле будет указано "Накопительная политика с правилами доступа маркетологов Лос-Анджелеса";
     • Защита от случайного удаления (Protect from accidental deletion). Параметр, запрещающий удалять созданную вами централизованную политику доступа без вашего ведома. Как и во всех предыдущих случаях, не будем снимать этот флажок и рассмотрим следующую группу параметров.
   • Группа "Участник" (Member). В этой группе создаваемой централизованной политики доступа вы можете указать централизованные правила доступа, которые станут членами этой политики. По нажатию на кнопку"Добавить" (Add) перед вами отобразится диалоговое окно добавления централизованных правил доступа, где вы из соответствующего списка с левой стороны (см. иллюстрацию ниже) должны выбрать одно или несколько правил. После того, как у вас будут выбраны требуемые правила, нажмите на верхнюю кнопку с двойной угловой скобкой, чтобы переместить такие правила к списку добавленных правил доступа. Между прочим, непосредственно из этого диалогового окна вы можете вызвать мастер (точнее, диалоговое окно) добавления нового централизованного правила доступа.
   
   Кстати, в группе централизованных правил доступа участников, в столбце "Состояние разрешений" (Permission State) вы можете обнаружить используемые централизованным правилом доступа списки разрешений, которые будут распространяться на это правило. Как видно на следующей иллюстрации, в качестве допустимых значений таких разрешений выступают значения "Предложенные", а также "Текущие" (Proposed, Current).

   
   Рис. 6. Диалоговое окно создания централизованной политики доступа

3. Нажимаем на кнопку "ОК", тем самым сохранив создаваемую централизованную политику доступа.

С GUI-методом все понятно, поэтому перейдем к более сложному методу, а именно к созданию централизованной политики доступа средствами Windows PowerShell. По существу, командлеты, работающие с возможностями централизованных политик доступа в какой-то степени напоминают методы управления списками свойств ресурсов средствами Windows PowerShell. То есть вы не сможете просто так, при помощи одного командлета, полноценно создать централизованную политику доступа со всеми ее членами. Вам для начала нужно будет создать сам объект, а затем уже при помощи второго командлета добавить к созданной политике требуемые правила доступа.
Получается, для работы с этими объектами вы можете воспользоваться следующими пятью командлетами Windows PowerShell: New-ADCentralAccessPolicy, при помощи которого вы создаете сам объект централизованной политики доступа; Set-ADCentralAccessPolicy, отвечающий за изменение существующей политики; Remove-ADCentralAccessPolicy, благодаря которому, собственно, вы удаляете ненужные политики доступа, а также командлетыAdd-ADCentralAccessPolicyMember и Remove-ADCentralAccessPolicyMember, предназначенные для добавления централизованных правил доступа в выбранные вами политики или их удаления. В следующем примере будут рассмотрены только два командлета, позволяющие добавить новую централизованную политику доступа, а также добавить для нее одно правило доступа. Итак, для начала нужно будет воспользоваться следующим командлетом:

New-ADCentralAccessPolicy -description:"Just another CAP" -Name:"Test CAP" -Server:"DC.biopharmaceutic.local" -ProtectedFromAccidentalDeletion:$true 
Как видите, с этим командлетом вообще не должно возникнуть никаких проблем. Здесь параметр Name отвечает за имя правила, Description - за его описание, при помощи параметра Server вы можете указать целевой сервер для создаваемого правила, а при помощи параметра ProtectedFromAccidentalDeletion ­- запретить в дальнейшем удалять созданный вами объект.
Самое интересное начинается на этапе добавления централизованных правил доступа к созданному вами правилу. При помощи второй команды вы должны указать централизованные правила доступа, которые будут добавляться к вашей политике. Такая команда будет выглядеть следующим образом: 

Add-ADCentralAccessPolicyMember -Identity:"CN=Test CAP,CN=Central Access Policies,CN=Claims Configuration,CN=Services,CN=Configuration,DC=biopharmaceutic,DC=local" -Members:"CN=Доступ маркетологов Лос-Анджелеса к ресурсам маркетинга,CN=Central Access Rules,CN=Claims Configuration,CN=Services,CN=Configuration,DC=biopharmaceutic,DC=local" -Server:"DC.biopharmaceutic.local" 
Здесь фигурируют только два параметра, а именно: параметр Identity, позволяющий указать созданное ранее правило, а также параметр Members, где вам нужно будет через запятую указать все требуемые централизованные правила доступа. Как обычно, если после выполнения команд вы не увидите никаких предупреждений, значит, все было создано правильно. Пример вывода этих команд проиллюстрирован ниже:

Рис. 7. Создание централизованного правила доступа средствами Windows PowerShell

Изменение и удаление существующих централизованных политик доступа

Изменение и удаление существующих централизованных политик доступа, скорее всего, представляют собой наипростейшие операции среди всех рассмотренных в этой статье задач. Такой вывод можно сделать по той причине, что как при помощи команды изменения свойств, так и во время удаления политик вы не столкнетесь с какими-либо новыми параметрами или свойствами. Чтобы изменить существующую политику доступа, вам нужно в центре администрирования Active Directory перейти к узлу Dynamic Access Control > Central Access Policies, выбрать требуемую политику доступа, а затем либо из контекстного меню, либо из панели "Задачи" (Tasks) выбрать команду "Свойства" (Properties).

Более того, если вам понадобится добавить к существующей централизованной политике доступа новое правило доступа, из того же контекстного меню или панели задач выберите команду "Добавить централизованные правила доступа" (Add Central Access Rule). После выбора этой опции отобразится диалоговое окно добавления централизованных правил доступа, о котором шла речь во втором этапе процедуры создания централизованной политики доступа.

С удалением более ненужных централизованных политик доступа у вас также не должно возникнуть каких-либо трудностей. Для этого в том же узле Central Access Policies выберите требуемый объект, а затем выполните команду "Удалить"(Delete) из контекстного меню.

Распространение централизованных политик доступа

Разумеется, сами по себе централизованные политики вам ничего не дадут. Чтобы начать их применять на ваших производственных файловых серверах, сперва их нужно централизованно распространить. Наилучшим методом автоматизации распространения практически любых настроек для операционных систем Windows является использование функциональных возможностей групповых политик. На данный момент при помощи групповой политики вы можете сделать практически все, что только можно себе представить, в плане кастомизации систем. Если это какие-то определенные параметры системы, которые можно найти в графическом интерфейсе, - пожалуйста, для вас были разработаны тысячи административных шаблонов. Вам нужно установить приложение - для этого есть расширение CSE  GPSI, определить политики паролей, настроить системные службы, ограничить доступ к системному реестру или, скажем, настроить политики ограничения доступа к программам, правила брандмауэра Windows или IPSEC - в этом помогут  существующие параметры из узла "Конфигурация Windows". Если вам нужно выполнить централизованную настройку какого-то определённого программного продукта, возможно, вендор уже выполнил за вас огромную часть работы, выпустив к своему продукту административные шаблоны. Даже если вы не смогли найти для себя искомый параметр политики, вы всегда можете воспользоваться  предпочтениями групповой политики, которые могут вас избавить от написания громоздких скриптов, в которых так просто допустить ошибку.
И такая технология как "Динамический контроль доступа", конечно, не обошлась без своего расширения клиентской стороны для групповой политики. Так как все создаваемые вами правила и политики хранятся в доменных службах Active Directory, по большому счету, остается лишь изъять такие объекты из требуемых контейнеров, а затем распространить указанные в них параметры на конкретные машины. На словах это звучит весьма просто, но посмотрим, что же собой представляет такая процедура на практике. 
Итак, чтобы распространить свои созданные ранее централизованные политики доступа на файловые серверы, нужно будет выполнить следующие действия:

1. Для начала нужно открыть оснастку "Управление групповой политикой" (Group Policy Management), где следует в подразделении с целевыми файловыми серверами создать новый объект групповой политики, скажем "Dynamic Access Control 01", а затем открыть для такого объекта редактор управления групповыми политиками;
2. В отобразившейся оснастке требуемое расширение CSE можно локализовать в параметрах безопасности. То есть следует перейти к узлу Конфигурация компьютера\Политики\Конфигурация Windows\Параметры безопасности\Файловая система (Computer Configuration\Policies\Windows Settings\Security Settings\File System). Как вы помните по предыдущим серверным операционным системам от Microsoft, в этом узле вы можете настроить разрешения доступа для пользователей или групп к объектам, расположенным на определенном компьютере, о чем уже шла речь в моей статье "Локальная политика безопасности. Часть 6: группы с ограниченным доступом, системные службы, реестр и файловая система". Сейчас же, начиная с Windows Server 2012, в данном узле можно обнаружить еще один вложенный узел, который называется "Централизованная политика доступа" (Central Access Policy) и который как раз предназначен для распространения созданных ранее централизованных политик доступа. Чтобы настроить параметр политики, вам нужно перейти к данному узлу, а затем, как показано на следующей иллюстрации, из контекстного меню выбрать команду "Управление централизованными политиками доступа" (Manage Central Access Policies…):

   
   Рис. 8. Создание параметра политики в редакторе GPME

3. Должно отобразиться диалоговое окно "Конфигурация централизованных политик доступа" (Central Access Policies Configuration), благодаря которому вы и можете распространить сгенерированные заранее политики доступа на свои целевые файловые сервера. Для этого, как можно увидеть ниже, нужно из списка "Доступные центрованные политики доступа" (Available Central Access Policies) выбрать все распространяемые политики доступа (в случае необходимости, вы можете зажать клавишу CTRL и выбрать требуемые политики), а затем, по нажатию на кнопку "Добавить" (Add), переместить таковые в список "Примененные централизованные политики доступа" (Applicable Central Access Policies):

   
   Рис. 9. Конфигурация централизованных политик доступа

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

В принципе, так как в ряды функциональных возможностей групповой политики прибавилось расширение клиентской стороны, позволяющее управлять централизованными политиками доступа, настроенные вами политики обязательно должны в каком-то виде храниться в папке SYSVOL на всех контроллерах домена, которые участвуют в репликации. Например, чтобы локализовать сгенерированные параметры политики, на контроллере домена вам следует перейти к папке C:\Windows\SYSVOL\domain\Policies\{6DF180BA-22E3-4D52-A34F-158633E56956}\Machine\Microsoft\Windows NT\Cap , где C:\Windows\SYSVOL\domain\Policies представляет собой путь к каталогу со всеми созданными в домене объектами групповой политики, {6DF180BA-22E3-4D52-A34F-158633E56956} - это GUID самого объекта групповой политики, который только что был создан и настроен (узнать это можно, вызвав диалоговое окно свойств для самого верхнего узла непосредственно из редактора управления групповыми политиками), а Machine\Microsoft\Windows NT\Cap- это уже путь к папке, где располагается файл, в котором и будут определены указанные вами параметры политики.
В этом каталоге можно найти единственный INF-файл, который называется cap.inf (сокращение от Central Access Policy). Этот файл не зашифрован, и при желании вы можете просмотреть его содержимое. Например, в моем случае такой файл будет включать в себя следующие строки:

[Version]
Signature="$Windows NT$"
[CAPS]
"CN=Test CAP,CN=Central Access Policies,CN=Claims Configuration,CN=Services,CN=Configuration,DC=biopharmaceutic,DC=local"
"CN=Маркетологи Лос-Анджелеса,CN=Central Access Policies,CN=Claims Configuration,CN=Services,CN=Configuration,DC=biopharmaceutic,DC=local"

Полагаю, что из содержимого такого файла все понятно и не следует его рассматривать более подробно. Грубо говоря, как вы видите, здесь можно обнаружить различающиеся имена, которые определяют наименование и местоположение централизованной политики доступа, сохраненной в доменных службах Active Directory.
Выходит, что в этом INF-файле можно обнаружить только само наименование политики и ее расположение. То есть, если после получения такого файла вообще не выполнять никаких действий, то в этом случае клиент попросту не будет знать, что же собой представляют такие политики, не говоря уже о правилах. Именно по этой причине операционной системе необходимо предпринимать какие-то действия и реализовать механизмы, позволяющие правильно "понять, для чего нужны эти политики и что с ними можно сделать". Благо, в Windows Server 2012/2012 R2 уже все реализовано "из коробки". Уже после обновления параметров групповой политики системная библиотека auditcse.dll считывает требуемую информацию о централизованных политиках доступа из INF-файла, а затем посредством LDAP-запросов все необходимые системе данные будут получены из доменных служб благодаря расширению клиентской стороны и записаны в системный реестр целевого компьютера.
Если у вас есть желание локализовать и поизучать такие параметры, вам нужно будет воспользоваться редактором реестра и, находясь в окне regerdit, перейти к разделу HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CentralizedAccessPolicies. Причем обратите внимание на то, что в разделе CAPEs можно найти централизованные правила доступа, а в разделе CAPs будут находиться параметры, отвечающие за централизованные политики доступа. Например, как для правил, так и для политик доступа можно обнаружить параметрыName и Description, которые отвечают, соответственно, за имя и описание определенного объекта. Как видно на следующей иллюстрации, в данном разделе реестра можно найти подразделы, которые включают в себя все распространенные вами централизованные политики доступа со своими параметрами:

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

Применение централизованных политик доступа

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

1. Откройте проводник Windows и перейдите к папке, для которой вы хотите настроить динамический контроль доступа. После этого откройте контекстное меню и выберите опцию "Свойства" (Properties);
2. В отобразившемся диалоговом окне свойств вашей папки перейдите на вкладку "Безопасность" (Security), а после этого, для отображения расширенных возможностей, нажмите на кнопку "Дополнительно" (Advanced);
3. Если у вас до этого все было выполнено правильно, тогда помимо вкладок "Разрешения", "Аудит" и"Действующие права доступа" (Permissions, Auditing, Effective Access) вы должны обнаружить вкладку"Централизованная политика" (Central Policy), которая в данном случае нас и интересует. Именно на этой вкладке редактора дополнительных параметров безопасности будут фигурировать все развернутые централизованные политики доступа.
   Изначально там не выбрана ни одна политика, так как не было произведено должных настроек. Вам следует развернуть раскрывающийся список и выбрать политику, которая подходит для выбранной вами папки. Например, если в данном примере выбрать политику "Маркетологи Лос-Анджелеса", то вы увидите все правила доступа, которые будут отрабатывать согласно условиям вашей политики. Эти правила вы не можете изменить из данного диалогового окна, но в любой момент, естественно, вы можете вернуться к центру администрирования Active Directory и внести должные правки. Чтобы изменения вступили в силу, от вас потребуется лишь обновить параметры групповой политики на целевой машине. Диалоговое окно дополнительных параметров безопасности с вкладкой централизованных политик вы можете увидеть ниже:

   
   Рис. 11. Вкладка централизованной политики дополнительных параметров безопасности

4. Выбрав требуемую централизованную политику доступа, вы можете окончательно сохранять параметры безопасности для выбранной папки. Теперь при сохранении изменений операционная система создаст определенную связь между выбранной вами политикой и локальной папкой, причем сделает это таким образом, что идентификатор централизованной политики доступа определяется как последняя запись в списке SACL конечного объекта. Стоит обратить внимание на то, что все идентификаторы объектов централизованных политик доступа начинаются с S-1-17, что позволяет их визуально отличать от идентификаторов безопасности, а самой операционной системе определять то, какие конкретно файлы и папки находятся под управлением централизованных политик доступа.
   

Заключение

Итак, в этой статье мы с вами продолжили обсуждать динамический контроль доступа. Вы узнали о том, что собой представляют централизованные правила доступа и как можно управлять такими правилами, причем как при помощи консоли центра администрирования Active Directory, так и используя возможности Windows PowerShell. Более того, в этой статье было подробно рассказано о дальнейшей судьбе правил доступа, то есть об их членстве в централизованных политиках доступа. Также вы узнали о том, как можно управлять такими политиками. Еще вы могли узнать о распространении таких политик доступа средствами групповой политики, а в последнем, небольшом, разделе этой статьи речь шла о том, как можно применить сгенерированные и распространенные ранее централизованные политики доступа к целевым папкам и файлам размещенным на файловых серверах.
В следующей статье этого цикла мы с вами продолжим более детально рассматривать технологию динамического контроля доступа и подробнее остановимся на условных выражениях и предложенных разрешениях, будут рассмотрены несколько "живых" примеров использования централизованных политик доступа, а также много других интересных моментов, о которых я не успел упомянуть в первых пяти статьях настоящего цикла.

• Купить Microsoft Windows Server Standard 2012 R2
• Купить Microsoft Windows Server Essentials 2012 R2
• Купить Microsoft Windows Server Datacenter 2012 R2
• Задать вопрос менеджеру интернет-магазина ITShop.ru online