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

Администраторы домена: кто лишний?

В небольших компаниях часто практикуется предоставление привилегий администратора домена учетным записям всех специалистов по ИТ. Это не только самый простой способ предоставить полный административный доступ ко всем рабочим станциям и серверам (поскольку группа администраторов домена входит в группу локальных администраторов, когда компьютеры являются членами домена), но и способ обеспечить доступ на чтение/изменение объектов в Active Directory (AD). Но как часто младшим системным администраторам и специалистам технической поддержки действительно нужны привилегии администратора домена? Вовсе не обязательно подвергать риску всю сетевую структуру, предоставляя новому сотруднику в его первый рабочий день полный административный доступ к ней, поскольку административный доступ к рабочим станциям можно обеспечить не только посредством участия в группе администраторов домена. Лучше всего предоставлять полный административный доступ к серверам только в случае реальной необходимости.

Определение уровней доступа

В отличие от системы безопасности UNIX, где для управления доступом к файлам используются индивидуальные списки контроля доступа access control lists (ACL), в Windows доступ ко всем объектам осуществляется про помощи набора встроенных групп, которые значительно облегчают процесс назначения разрешений. Однако, несмотря на соблазн облегчить себе жизнь и добавить учетные записи системных администраторов во все группы, делать это нужно крайне осторожно, поскольку в данном случае будет весьма сложно контролировать изменения в системе. С другой стороны, вполне допустимо сделать системных администраторов участниками групп с правами только на чтение, таких, например, как читатели журнала событий Event Log Readers, поскольку такие группы не имеют административного доступа к серверам.

Учетным записям служб часто требуется административный доступ или привилегии, которых нет у обычных пользователей. Такие учетные записи могут использоваться и для запуска задач по расписанию или пакетных файлов, для чего также могут потребоваться расширенные привилегии. Учетные записи, используемые для предоставления временного доступа к серверам (например, учетные записи аварийного доступа, firecall accounts) в целях обслуживания, также требуют привилегированного доступа. Все остальные запросы на предоставление постоянного привилегированного доступа к серверам вне контекста учетных записей служб или аварийных учетных записей следует тщательно взвесить, поскольку в большинстве случаев такой доступ не является необходимым.

Предварительная подготовка

Прежде чем рассмотреть работу непосредственно с серверами и привилегированными учетными записями, необходимо создать такую структуру AD, которая облегчит управление сервером. Рассматриваемая в этой статье иерархическая структура подразделений (OU) построена на рекомендациях статьи «Windows Server 2008 Security Compliance Management Toolkit» (technet.microsoft.com/en-us/library/cc514539.aspx) и представляет собой типичную структуру, обычно развертываемую в организациях. На экране 1 показаны объекты групповой политики GPO с префиксом WS08 EC, которые были автоматически сгенерированы при помощи инструмента GPOAccelerator, входящего в описанный в статье набор инструментов, и настроены согласно рекомендациям для каждой роли сервера в стандартной для предприятия конфигурации.

Обратите внимание, что наряду с контейнером по умолчанию для контроллеров домена (DC) созданы организационные подразделения (OU) для учетных записей аварийного доступа, учетных записей служб и рядовых серверов WS08 EC. Таким образом, служебные и аварийные учетные записи будут отделены от ученых записей обычных пользователей домена, что позволит делегировать управление определенными свойствами этих учетных записей ограниченному числу пользователей.

Подразделение «Рядовые серверы WS08 EC», в свою очередь, состоит из нескольких OU для отдельных ролей сервера: «Серверы приложений WS08» и «Файловые серверы WS08 EC». Базовый GPO для сервера приложений WS08 был создан при помощи мастера настройки безопасности Windows Server 2008, поскольку эти серверы являются специфичными для организации. Подразделение «Серверы приложений WS08» содержит также OU DMZ, а, следовательно, для противодействия внешним угрозам к этим серверам могут быть применены другие настройки безопасности.

Учетные записи аварийного доступа

Прежде чем отключить встроенные администраторские учетные записи и изменить пароли к ним, необходимо создать учетную запись пользователя домена для каждого сервера в отдельном подразделении «Учетные записи аварийного доступа». Для того чтобы добавить каждому серверу соответствующую учетную запись аварийного доступа, воспользуемся политикой групп с ограниченным доступом Restricted Groups. Учетными записями аварийного доступа должна управлять выделенная группа безопасности. В ее функции входит включение отключенных в остальное время учетных записей и генерация для них случайных паролей, которые затем предоставляются системным администраторам и действуют при этом ограниченное время, после чего учетные записи снова отключаются, а пароли к ним изменяются.

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

Делегирование доступа к управлению учетными записями аварийного доступа

В нашем примере для серверов приложений в подразделении «Учетные записи аварийного доступа» созданы четыре учетные записи аварийного доступа (например, AppServ01_Firecall, AppServ02_Firecall). Также у нас есть особая группа администраторов по безопасности, которая имеет полномочия на включение, отключение, разблокировку и сброс паролей на учетных записях в OU «Учетные записи аварийного доступа».

Воспользуемся оснасткой «Пользо­ва­тели и компьютеры Active Directory» консоли управления MMC, чтобы делегировать доступ к OU «Учетные записи аварийного доступа».

  1. В меню «Администрирование» откроем оснастку «Пользователи и компьютеры Active Directory» с правами администратора домена. В левой панели развернем строку домена, щелкнем правой кнопкой по OU «Учетные записи аварийного доступа» и выберем пункт меню «Делегирование управления».
  2. Щелкнем «Далее» на экране приветствия мастера делегирования управления.
  3. На экране «Пользователи и Группы» нажмем «Добавить». В этом примере заранее создана группа «Администраторы безопасности при исполнении», которой мы делегируем управление учетными записями в подразделении «Учетные записи аварийного доступа». На самом деле для этих целей можно использовать любую доменную группу. В диалоговом окне «Выберите пользователей, компьютеры или группы» вводим имя группы, которой нужно делегировать управление, и нажимаем ОК. Нажимаем «Далее» на экране «Пользователи и группы».
  4. На экране «Делегируемые задачи» выбираем «Создать особую задачу для делегирования» и нажимаем «Далее».
  5. На экране «Тип объекта Active Directory» выберем «Только следующие объекты в этой папке» и «Объекты пользователя» в нижней части списка. Нажимаем «Далее».
  6. На экране «Разрешения» выберем «Общие» и «Разрешения для свойств». В списке выбираем следующие разрешения: смена пароля, сброс пароля, чтение lockoutTime, запись lockoutTime, чтение userAccountControl, запись userAccountControl. Нажимаем «Далее», а затем «Готово».

Теперь любой пользователь из группы «Администраторы безопасности при исполнении», который во всем остальном является обычным пользователем домена, сможет при помощи оснастки «Пользователи и компьютеры Active Directory» выполнять ограниченный набор действий над учетными записями в OU «Учетные записи аварийного доступа».

Управление привилегированным доступом к серверам при помощи политики групп с ограниченным доступом

На экране 1, помимо базового GPO «Серверы приложений WS08», показано четыре дополнительных GPO, связанных с подразделением «Серверы приложений WS08» и снабженных префиксом «Группы с ограниченным доступом», каждый из которых сопоставлен одному из четырех серверов, чьи учетные записи расположены в этом OU. Кроме того, эти дополнительные GPO содержат фильтр WMI, чтобы обеспечить применение их параметров только к нужному серверу. Чтобы создать GPO для групп с ограниченным доступом, откроем управление групповой политикой из подменю «Администрирование» в меню «Пуск» с правами администратора домена.

 

Экран 1. Оптимальная иерархическая структура подразделений (OU)

 

  1. В левой панели окна «Управление групповой политикой» развернем лес и домен, как показано на экране 1.
  2. Правой кнопкой щелкнем по контейнеру «Объекты групповой политики» и выберем в контекстном меню пункт «Новый».
  3. В окне «Новый объект групповой политики» введем имя объекта «Группы с ограниченным доступом» и добавим к нему имя определенного сервера (например, «Группы с ограниченным доступом MyServer1»), а затем нажмем ОК.
  4. Развернем контейнер «Объекты групповой политики», правой кнопкой щелкнем в списке по вновь созданному GPO и выберем в меню пункт «Редактировать».
  5. В редакторе управления групповыми политиками последовательно развернем «Конфигурацию компьютера», «Политики», «Конфи­гурацию Windows» и «Параметры безопасности».
  6. Щелкнем правой кнопкой по «Группам с ограниченным доступом» и выберем пункт меню «Добавление группы».
  7. В диалоговом окне «Добав­ле­ние группы» введем «Администраторы» в поле «Группа» и нажмем ОК.
  8. В диалоговом окне «Свойства: Администраторы» щелкнем «Добавить» справа от списка «Участники этой группы».
  9. В диалоговом окне «Добавление участника» введем «Администратор» в поле «Участники этой группы».
  10. Нажмем «Обзор» и в диалоговом окне «Выбрать пользователей, учетные записи служб, группы» добавим в список участников группу администраторов домена, а также, при необходимости, какие-либо учетные записи служб и аварийного доступа, относящиеся к данному серверу. Важно помнить, что политика групп ограниченного доступа не вносит поправки в состав локальных участников группы, а заменяет всех участников всякий раз, когда групповая политика обновляется на сервере. Следовательно, в список необходимо включить и те группы и учетные записи, которые уже существуют на сервере. Политика групп с ограниченным доступом не должна использоваться на контроллерах домена для управления доменными группами.
  11. После того как все необходимые доменные учетные записи и/или группы будут помещены в список участников группы, нажмем ОК. Все выбранные учетные записи появятся в списке диалогового окна «Добавить участника», разделенные точкой с запятой. Нажмем ОК для продолжения.
  12. Нажмем ОК в окне «Свойства: Администраторы» и закроем редактор управления групповой политикой.

Перед тем как связать вновь созданный GPO с подразделением, необходимо добавить фильтр WMI, чтобы обеспечить применение политики к нужному серверу. В качестве альтернативы можно создать отдельное подразделение OU для каждого сервера. Но и в том и в другом случае потребуется дополнительный объект AD.

  1. Вернемся в управление групповой политикой, щелкнем правой кнопкой раздел «Фильтры WMI» в левой панели и выберем пункт меню «Создать».
  2. В диалоговом окне «Новый фильтр WMI» зададим имя фильтра MyServer1, добавим его описание и нажмем кнопку «Добавить» справа от поля «Запросы».
  3. В диалоговом окне «Запрос WMI» введем Select Win32_ComputerSystem where Name = "MyServer1" в поле «Запрос» и нажмем ОК.
  4. Теперь в диалоговом окне «Новый фильтр WMI» (экран 2) нажмем «Сохранить».
  5. Далее в разделе «Объекты групповой политики» выберем ранее созданный GPO.
  6. В правой панели переключимся на вкладку «Область». В разделе фильтра WMI в выпадающем меню выберем только что созданный фильтр MyServer1. Нажмем «Да» в окне предупреждения, чтобы применить фильтр.

 

Экран 2. Диалоговое окно «Новый фильтр WMI»

Теперь можно связать GPO с соответствующим подразделением, чтобы применить к серверу политику групп с ограниченным доступом. Если добавить учетную запись в группу локальных администраторов на каком-либо сервере, а затем с помощью команды Gpupdate/force обновить вышеуказанную политику, появится уведомление о том, что добавленная учетная запись была удалена из группы.

Встроенные учетные записи администратора

После первоначального развертывания серверов учетные записи администратора на них обязательно должны быть отключены, а пароли изменены. И хотя в Server 2008 и Windows Vista или более новых версиях встроенная учетная запись администратора по умолчанию отключена, пароль к ней должен быть обязательно изменен на каждом сервере, поскольку эту учетную запись все еще можно использовать для авторизации в системе при загрузке в безопасном режиме. Для уже развернутых серверов отключение встроенной учетной записи администратора, а также изменение пароля можно произвести при помощи сценария. Вход в BIOS на всех серверах обязательно должен быть защищен при помощи пароля, а порядок загрузки следует установить в положение «загрузка только с локального диска».

Учетные записи служб

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

Server 2008 R2 положил начало концепции управляемых учетных записей служб MSA и виртуальных учетных записей. MSA — это доменные учетные записи, которые создаются и управляются при помощи команд оболочки PowerShell. Пароли к ним, состоящие из 240 символов, генерируются автоматически и сбрасываются службой Netlogon каждые 30 дней, подобно прочим учетным записям компьютера. MSA могут быть привязаны только к одному компьютеру (под управлением Server 2008 R2 или Windows 7), но на каждом компьютере их может быть несколько. Если лес AD работает в режиме Server 2008 R2, то в оснастке «Пользователи и компьютеры Active Directory» можно увидеть контейнер «Управляемые учетные записи служб», выбрав в меню «Вид» отображение дополнительных параметров.

Виртуальные учетные записи не создаются, но используются для запуска служб. Доступ к ним можно получить, набрав NT SERVICE\ [имя службы] в поле «С учетной записью» на вкладке «Вход в систему» в консоли управления службы, оставив при этом поле «Пароль» пустым. Виртуальные учетные записи наделены такими же полномочиями, как сетевая служба: они имеют права стандартного пользователя на локальной системе, но с сетью взаимодействуют как локальная учетная запись компьютера. Виртуальные учетные записи должны использоваться в том случае, когда не требуются особые права доступа к домену. Более подробную информацию о MSA и виртуальных учетных записях можно найти в статье «Управление учетными записями служб с помощью MSA», опубликованной в Windows IT Pro/RE № 8 за 2010 год.

Аудит событий регистрации в системе и выхода из системы

После того как системный администратор уведомит группу безо­пасности о том, что его работа на сервере закончена и что учетная запись аварийного доступа может быть отключена, нелишним будет проверить журнал событий безопасности этого сервера и убедиться в том, что учетная запись аварийного доступа действительно завершила работу в системе. Даже если учетная запись отключена, это не всегда означает, что она не может и далее выполнять административные функции, особенно если она уже получила маркер доступа. Группе безопасности можно предоставить доступ на чтение журналов событий безопасности на серверах для контроля событий регистрации/завершения 4624 и 4634.

Также можно использовать пересылку событий и собирать все журналы на центральном сервере. Если исходные серверы работают под управлением Server 2008, то учетная запись сетевой службы должна быть добавлена в локальную группу «Читатели журнала событий», для того чтобы события безопасности могли быть переданы. Более подробную информацию о требованиях, необходимых для передачи событий безопасности, можно найти в статье «Forwarding Security Events from Windows XP, Server 2003, and Vista/Server 2008» (http://blogs.technet.com/b/otto/archive/2009/06/22/forwarding-security-events-from-windows-xp-server-2003?and-vista-server-2008.aspx).

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

 

Экран 3. Пересылка только указанных событий для заданного пользователя

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

$group = [ADSI]"WinNT://
   MyServer1/Administrators"
$members = @ ($group.psbase
   .Invoke ("Members"))
$members | foreach {$_.GetType ()
   .InvokeMember ("AdsPath","GetProperty",
   $null,$_,$null)}

Контроллеры домена

Привилегированный доступ к контроллерам домена представляет собой определенную проблему, поскольку здесь нет локальных групп, и административного доступа, предоставленного пользователю посредством встроенной группы AD (например «Операторы сервера»), достаточно для того, чтобы пользователь мог сам себе поднять полномочия, что не позволяет полностью разделить доступ к серверу и к AD.

Но тем не менее учетные записи аварийного доступа могут быть созданы и для контроллеров домена. Из-за того что встроенные группы AD являются, по сути, распределенными, эти учетные записи могут быть ограничены тем контроллером домена, на котором они могут производить регистрацию, посредством применения функции «Этот пользователь может входить» на вкладке «Учетная запись» свойств пользователя в оснастке «Пользователи и компьютеры Active Directory», как показано на экране 4. В любом случае, как только у пользователя появляются полномочия администратора домена, любые введенные ограничения можно обойти. Ежедневные административные задачи, требующие подключения к контроллеру домена, должны выполняться с использованием средств удаленного администрирования сервера RSAT и делегированных пользователям соответствующих полномочий.

 

Экран 4. Функция «Этот пользователь может входить»

Минимизация риска

Утверждение простых процедур и делегирование управления может в значительной мере снизить риск, связанный с возможным нанесением вреда целостности системы ИТ-персоналом или с получением несанкционированного доступа к данным компании. Возможно, методик, описанных в этой статье, будет недостаточно, чтобы удовлетворить самых строгих аудиторов, но, по крайней мере, они направят вас на верный путь. Для более крупных организаций можно рекомендовать продукты сторонних производителей, такие как PowerKeeper компании BeyondTrust и Password Manager Pro компании ManageEngine, которые помогут полностью автоматизировать управление привилегированными учетными записями на сотнях серверов и обеспечить соответствие правительственным и промышленным стандартам.

Рассел Смит (rms@russell-smith.net) — независимый ИТ-консультант, специализируется на управлении системами

 

 

 

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF