Результирующий набор планирования политики и ведения журнала

Одна из вещей, которые мне всегда нравились в Windows Server 2003, — это ее гибкость с точки зрения безопасности. Windows Server 2003 обладает достаточной гибкостью, чтобы приспособиться даже к самой причудливой корпоративной политике безопасности. Однако, к сожалению, побочным продуктом такой гибкости является сложность. Windows Server 2003 имеет так много различных уровней безопасности, что может быть трудно предсказать результат изменений политики или отследить нежелательные параметры политики безопасности.

Поскольку политиками безопасности традиционно было очень трудно управлять в средах Windows Server, Microsoft включила в Windows Server 2003 инструмент, предназначенный для значительного упрощения управления политиками безопасности. Этот инструмент называется консолью результирующего набора политик (RSOP). В этой статье я познакомлю вас с этим инструментом и объясню, как вы можете использовать его, чтобы упростить управление политиками безопасности.

Почему так сложно управлять политиками безопасности?

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

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

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

Так как же определить, какие параметры групповой политики являются доминирующими? Вы должны понимать иерархию групповой политики. Групповые политики могут существовать на уровне локального компьютера, сайта, домена и подразделения. Windows обрабатывает групповые политики в таком порядке, чтобы получить действующую политику. Элементы каждой политики объединяются вместе. Например, если локальная политика содержит параметр, указывающий, что пароли должны иметь длину восемь символов, а политика на уровне сайта указывает, что пароли должны меняться каждые 30 дней, то действующая политика будет указывать, что пароли должны иметь длину восемь символов и должны быть меняется каждые 30 дней.

Однако все работает немного по-другому, когда возникают противоречия. Когда возникают противоречия, политика более высокого уровня переопределяет политику более низкого уровня для противоречащих параметров политики. Любые параметры политики, которые не противоречат друг другу, объединяются обычным способом. Например, если локальная политика безопасности указывает, что пароли должны состоять из восьми символов и должны меняться каждые 30 дней, а политика на уровне сайта указывает, что пароли должны иметь длину 10 символов, то действующая политика будет заключаться в том, что пароли должны состоять из 10 символов. длинные и должны меняться каждые 30 дней. Действующая политика сохраняет правило 30 дней, поскольку эти две политики объединены. Однако правило десяти символов имеет приоритет над правилом восьми символов, поскольку политика, требующая десятизначных паролей, существует на более высоком уровне иерархии групповой политики (уровень сайта), чем политика, требующая восьми символов.

Хотя это базовое описание того, как рассчитывается эффективная политика, на самом деле все немного сложнее. Windows позволяет применять групповые политики к пользователям и компьютерам. Поэтому вполне возможно, что у вас может быть как политика пользователя, так и политика компьютера на каждом уровне иерархии групповой политики. Политики пользователей и компьютеров объединяются вместе на каждом уровне иерархии перед обработкой политик более высокого уровня.

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

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

Просмотр результирующего набора политик

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

Консоль RSOP поставляется только с Windows Server 2003. Это не означает, что вы ограничены ее использованием в доменах, работающих исключительно под управлением Windows Server 2003. Вы можете использовать инструмент RSOP в доменах, работающих под управлением Windows 2000 и Windows 2003 Server.

Самый простой способ использовать средство RSOP — открыть консоль «Пользователи и компьютеры Active Directory» и перейти к контейнеру «Пользователи». Затем щелкните правой кнопкой мыши пользователя, учетную запись которого вы хотите проанализировать, и выберите «Все задачи | Результирующий набор команд политик (регистрация) из результирующих контекстных меню.

Как я упоминал ранее, действующая политика лишь частично основана на политиках, назначенных пользователю. Политики уровня компьютера также учитываются при определении эффективной политики. Поэтому на первом экране, который вы увидите, вас спросят, какой компьютер вы хотите использовать для определения действующей политики. Вы можете использовать компьютер, который вы используете в данный момент, другой компьютер, или вы можете полностью игнорировать компьютерную часть политики. Рисунок A показывает, как выглядит этот экран.

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

Нажмите «Далее», и вы увидите краткую информацию о выбранном пользователе и настройках. Щелкните Next еще раз, и инструмент RSOP соберет необходимую информацию и отобразит консоль Resultant Set of Policy, как показано на рисунке B.

Рисунок B: Консоль Resultant Set of Policy показывает действующую политику пользователя

Как вы можете видеть на рисунке, консоль Resultant Set of Policy выглядит точно так же, как редактор групповой политики. Однако разница заключается в том, что параметры безопасности, которые вы просматриваете через эту консоль, отражают действующую политику выбранного пользователя.

Теперь, когда я показал вам, как просмотреть действующую политику пользователя, вам может быть интересно, что вы можете сделать, если действующая политика не отражает ожидаемые параметры. Например, на рисунке B вы заметите, что пользователь Bob настроен на блокировку своей учетной записи после 5 неудачных попыток входа в систему. Что, если бы я ожидал, что он скажет три неудачных попытки входа в систему?

В такой ситуации мне, очевидно, нужно было бы знать, откуда взялась неожиданная настройка. Чтобы узнать, просто щелкните правой кнопкой мыши параметр и выберите команду «Свойства» в появившемся контекстном меню. Когда вы это сделаете, вы увидите лист свойств, в котором параметры безопасности отображаются более подробно. Этот лист свойств не позволит вам изменить настройку, но если вы выберете вкладку «Приоритет», вы сможете узнать, какой объект групповой политики содержит оскорбительную настройку. Например, на рисунке C видно, что параметр политики исходит из политики домена по умолчанию.

Рисунок C. На вкладке «Приоритет» показано, откуда берется параметр политики.

Планирование политики

Раньше, когда вы щелкали правой кнопкой мыши учетную запись пользователя и выбирали команду «Все задачи» в контекстном меню, вы могли заметить параметр «Результирующий набор политик (планирование)». Я не хочу утомлять вас подробностями использования этой опции, потому что она работает аналогично опции Resultant Set of Policy (Logging), которую я вам уже показывал. Я, по крайней мере, хотел, чтобы вы знали, что этот вариант существует. Параметр «Планирование политики» позволяет увидеть эффект изменений безопасности до их внесения. Например, если вы планировали переместить пользователя в другое место в сети, это перемещение потенциально может привести к радикальным изменениям в действующей политике пользователя. Этот инструмент позволяет просматривать последствия такой операции, фактически не выполняя операцию.

Вывод

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