Внедрение наименее привилегированных административных моделей

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

"Большинство учебных курсов, связанных с безопасностью и документации, обсуждают реализацию принципа наименьшей привилегии, но организации редко следуют за ним. Принцип прост, и влияние его правильного применения значительно повышает безопасность и снижает риск. Принцип указывает, что все пользователи должны войти с учетной записью пользователя, которая имеет абсолютные минимальные разрешения, необходимые для выполнения текущей задачи, и ничего больше. Это обеспечивает защиту от вредоносного кода, среди других атак. Этот принцип применяется к компьютерам и пользователям этих компьютеров. "Одна из причин, по которой этот принцип работает так хорошо, заключается в том, что он заставляет вас делать некоторые внутренние исследования. Например, необходимо определить привилегии доступа, необходимые компьютеру или пользователю, а затем реализовать их. Для многих организаций эта задача изначально может показаться большой работой; однако это важный шаг для успешной защиты сетевой среды. "Необходимо предоставить всем пользователям домена права администратора домена в соответствии с понятием наименьших привилегий. Например, если администратор входит в систему с привилегированной учетной записью и непреднамеренно запускает программу вирусов, вирус имеет административный доступ к локальному компьютеру и всему домену. Если администратор вместо этого выполнил вход с помощью непривилегированного (неадминистративного) учетной записи, область повреждения вируса будет только локальным компьютером, так как он выполняется как локальный пользователь компьютера. "В другом примере учетные записи, которым вы предоставляете права администратора уровня домена, не должны иметь повышенных прав в другом лесу, даже если между лесами есть отношения доверия. Эта тактика помогает предотвратить широко распространенный ущерб, если злоумышленнику удастся скомпрометировать один управляемый лес. Организации должны регулярно проверять свою сеть для защиты от несанкционированного эскалации привилегий».

Следующий фрагмент представлен в пакете ресурсов Microsoft Безопасность Windows, который впервые опубликован в 2005 году:

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

Проблема с привилегиями

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

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

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

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

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

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

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

В Active Directory

В Active Directory обычно обнаруживается, что группы EA, DA и BA содержат чрезмерное количество учетных записей. Чаще всего группа EA организации содержит наименьшее количество участников, группы DA обычно содержат умножение числа пользователей в группе EA, а группы администраторов обычно содержат больше членов, чем население других групп. Это часто связано с убеждением, что администраторы каким-то образом "менее привилегированны", чем DAs или EAs. Хотя права и разрешения, предоставленные каждой из этих групп, отличаются, они должны быть фактически признаны одинаково мощными группами, поскольку член одного из них может сделать себя членом других двух групп.

На серверах-членах

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

На рабочих станциях

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

В приложениях

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

В репозиториях данных

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

Уменьшение привилегий

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

Защита учетных записей локального администратора на рабочих станциях и серверах-членах

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

Защита учетных записей локального администратора

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

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

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

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

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

В одном или нескольких объектах групповой политики, которые вы создаете и связываете с рабочими станциями и подразделениями сервера в каждом домене, добавьте учетную запись администратора в следующие права пользователя в разделе "Конфигурация компьютера\Политики\Параметры Windows\Параметры безопасности\Локальные политики\Назначения прав пользователей:

• Отказ в доступе к компьютеру из сети
• Отказ во входе в качестве пакетного задания
• Отказать во входе в качестве службы
• Запретить вход в систему через службу удаленных рабочих столов

При добавлении учетных записей администраторов в эти права пользователя укажите, добавляете ли учетную запись локального администратора или учетную запись администратора домена таким образом, что она будет помечена. Например, чтобы добавить учетную запись администратора домена NWDLS в эти права запрета, введите учетную запись в качестве NWDLS\Administrator или перейдите к учетной записи администратора для домена NWDLS. Чтобы ограничить учетную запись локального администратора, введите "Администратор " в этих параметрах прав пользователя в редакторе объектов групповой политики.

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

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

Защита локальных привилегированных учетных записей и групп в Active Directory

Номер закона Шесть: компьютер является безопасным, так как администратор является надежным. - Десять неизменяемых законов безопасности (версия 2.0)

Приведенные здесь сведения предназначены для предоставления общих рекомендаций по защите встроенных учетных записей и групп с высоким уровнем привилегий в Active Directory. Подробные пошаговые инструкции также приведены в приложении D. Защита встроенных учетных записей администраторов в Active Directory, приложение E. Защита групп корпоративных администраторов в Active Directory, приложение F. Защита групп администраторов домена в Active Directory и в приложении G: защита групп администраторов в Active Directory.

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

Защита встроенных учетных записей администратора в Active Directory

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

Элементы управления для встроенных учетных записей администратора

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

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

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

Включение флага "Смарт-карта требуется для интерактивного входа" в учетной записи

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

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

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

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

В одном или нескольких объектах групповой политики, которые вы создаете и связываете с рабочими станциями и подразделениями сервера-участников в каждом домене, добавьте учетную запись администратора каждого домена в следующие права пользователя в разделе "Конфигурация компьютера\Политики\Параметры windows\Параметры безопасности\Локальные политики\Назначения прав пользователя":

• Отказ в доступе к компьютеру из сети
• Отказ во входе в качестве пакетного задания
• Отказать во входе в качестве службы
• Запретить вход в систему через службу удаленных рабочих столов

Настройка объектов групповой политики для ограничения учетных записей администратора на контроллерах домена

В каждом домене в лесу политика контроллеров домена по умолчанию или политика, связанная с подразделением контроллеров домена, должна быть изменена, чтобы добавить учетную запись администратора каждого домена в следующие права пользователя в разделе "Конфигурация компьютера\Политики\Политики\Параметры безопасности\Локальные политики\Назначения прав пользователя":

• Отказ в доступе к компьютеру из сети
• Отказ во входе в качестве пакетного задания
• Отказать во входе в качестве службы
• Запретить вход в систему через службу удаленных рабочих столов

Настройка аудита встроенных учетных записей администратора

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

Защита администраторов, администраторов домена и групп администраторов предприятия

Защита групп корпоративных администраторов

Группа администраторов предприятия, размещенная в корневом домене леса, не должна содержать пользователей на ежедневной основе, за исключением возможной учетной записи локального администратора домена, если она защищена, как описано ранее и в приложении D. Защита встроенных учетных записей администраторов в Active Directory.

Если требуется доступ EA, пользователи, чьи учетные записи требуют прав и разрешений EA, временно помещаются в группу администраторов предприятия. Хотя пользователи используют учетные записи с высоким уровнем привилегий, их действия должны быть проверены и желательно выполняться с одним пользователем, выполняющим изменения, и другим пользователем, наблюдающим за изменениями, чтобы свести к минимуму вероятность непреднамеренного неправильного использования или неправильной настройки. После завершения действий учетные записи должны быть удалены из группы EA. Это можно сделать с помощью ручных процедур и документированных процессов, стороннего программного обеспечения управления привилегированными удостоверениями и доступом (PIM/PAM) или сочетания обоих. Рекомендации по созданию учетных записей, которые можно использовать для управления членством в привилегированных группах в Active Directory, приведены в статье "Привлекательные учетные записи для кражи учетных данных" и подробные инструкции приведены в приложении I. Создание учетных записей управления для защищенных учетных записей и групп в Active Directory.

Администраторы предприятия по умолчанию являются членами встроенной группы администраторов в каждом домене в лесу. Удаление группы администраторов предприятия из групп администраторов в каждом домене является неуместным изменением, так как в случае сценария аварийного восстановления леса права EA, скорее всего, потребуются. Если группа администраторов предприятия была удалена из групп администраторов в лесу, ее следует добавить в группу "Администраторы" в каждом домене, а следующие дополнительные элементы управления должны быть реализованы:

• Как описано ранее, группа администраторов предприятия не должна содержать пользователей на ежедневной основе, за исключением учетной записи администратора корневого домена леса, которая должна быть защищена, как описано в приложении D. Защита встроенных учетных записей администраторов в Active Directory.
• В группах групповой политики, связанных с подразделениями, содержащими серверы-члены и рабочие станции в каждом домене, группа EA должна быть добавлена в следующие права пользователя:
  • Отказ в доступе к компьютеру из сети
  • Отказ во входе в качестве пакетного задания
  • Отказать во входе в качестве службы
  • Запретить локальный вход
  • Запрет входа через службы удаленных рабочих столов.

Это позволит членам группы EA войти на серверы-члены и рабочие станции. Если серверы переходов используются для администрирования контроллеров домена и Active Directory, убедитесь, что серверы переходов находятся в подразделении, к которому не связаны ограничивающие объекты групповой политики.

• Аудит должен быть настроен для отправки оповещений, если какие-либо изменения вносятся в свойства или членство в группе EA. Эти оповещения должны отправляться как минимум пользователям или командам, ответственным за администрирование Active Directory и реагирование на инциденты. Кроме того, следует определить процессы и процедуры для временного заполнения группы EA, включая процедуры уведомлений при выполнении законной совокупности группы.

Защита групп администраторов домена

Как и в группе "Администраторы предприятия", членство в группах администраторов домена должно потребоваться только в сценариях сборки или аварийного восстановления. В группе DA не должно быть учетных записей пользователей, за исключением учетной записи локального администратора для домена, если она была защищена, как описано в приложении D. Защита встроенных учетных записей администраторов в Active Directory.

Если требуется доступ к DA, учетные записи, необходимые этому уровню доступа, должны временно размещаться в группе DA для домена. Хотя пользователи используют учетные записи с высоким уровнем привилегий, действия должны быть проверены и желательно выполняться с одним пользователем, выполняющим изменения, и другим пользователем, наблюдающим за изменениями, чтобы свести к минимуму вероятность непреднамеренного неправильного использования или неправильной настройки. После завершения действий учетные записи должны быть удалены из группы администраторов домена. Это можно сделать с помощью ручных процедур и документированных процессов с помощью стороннего программного обеспечения управления привилегированными удостоверениями и доступом (PIM/PAM) или сочетания обоих. Рекомендации по созданию учетных записей, которые можно использовать для управления членством в привилегированных группах в Active Directory, приведены в приложении I. Создание учетных записей управления для защищенных учетных записей и групп в Active Directory.

Администраторы домена по умолчанию являются членами локальных групп администраторов на всех серверах-членах и рабочих станциях в соответствующих доменах. Это вложение по умолчанию не должно быть изменено, так как оно влияет на возможность поддержки и варианты аварийного восстановления. Если группы администраторов домена были удалены из локальных групп администраторов на серверах-членах, они должны быть добавлены в группу администраторов на каждом сервере-члене и рабочей станции в домене с помощью параметров ограниченной группы в связанных группах групповой политики. Кроме того, следует реализовать следующие общие элементы управления, описанные в приложении F. Защита групп администраторов домена в Active Directory .

Для группы администраторов домена в каждом домене в лесу:

1. Удалите всех участников из группы DA, за исключением встроенной учетной записи администратора для домена, если она была защищена, как описано в приложении D. Защита встроенных учетных записей администраторов в Active Directory.

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

   • Отказ в доступе к компьютеру из сети
   • Отказ во входе в качестве пакетного задания
   • Отказать во входе в качестве службы
   • Запретить локальный вход
   • Запретить вход в систему через службу удаленных рабочих столов

   Это позволит предотвратить вход членов группы DA на серверы-члены и рабочие станции. Если серверы переходов используются для администрирования контроллеров домена и Active Directory, убедитесь, что серверы переходов находятся в подразделении, к которому не связаны ограничивающие объекты групповой политики.

3. Аудит должен быть настроен для отправки оповещений, если какие-либо изменения вносятся в свойства или членство в группе DA. Эти оповещения должны отправляться как минимум пользователям или командам, ответственным за администрирование AD DS и реагирование на инциденты. Кроме того, следует определить процессы и процедуры для временного заполнения группы DA, включая процедуры уведомлений при выполнении законной совокупности группы.

Защита групп администраторов в Active Directory

Как и в случае с группами EA и DA, членство в группе администраторов (BA) должно потребоваться только в сценариях сборки или аварийного восстановления. В группе администраторов не должно быть учетных записей пользователей, за исключением учетной записи локального администратора для домена, если она была защищена, как описано в приложении D. Защита встроенных учетных записей администраторов в Active Directory.

Если требуется доступ администраторов, учетные записи, необходимые этому уровню доступа, должны временно размещаться в группе "Администраторы" для указанного домена. Хотя пользователи используют учетные записи с высоким уровнем привилегий, действия должны выполняться с пользователем, выполняющим изменения, и другим пользователем, наблюдающим за изменениями, чтобы свести к минимуму вероятность непреднамеренного неправильного использования или неправильной настройки. После завершения действий учетные записи должны быть немедленно удалены из группы администраторов. Это можно сделать с помощью ручных процедур и документированных процессов с помощью стороннего программного обеспечения управления привилегированными удостоверениями и доступом (PIM/PAM) или сочетания обоих.

Администраторы по умолчанию являются владельцами большинства объектов AD DS в соответствующих доменах. Членство в этой группе может потребоваться в сценариях сборки и аварийного восстановления, в которых требуется владение или возможность владения объектами. Кроме того, DAs и EAs наследуют ряд своих прав и разрешений в соответствии с их членством по умолчанию в группе администраторов. Не следует изменять вложенную группу по умолчанию для привилегированных групп в Active Directory, а группу администраторов каждого домена следует защитить, как описано в приложении G. Защита групп администраторов в Active Directory и в общих инструкциях ниже.

1. Удалите всех участников из группы "Администраторы", за исключением возможной учетной записи локального администратора для домена, если она была защищена, как описано в приложении D. Защита встроенных учетных записей администраторов в Active Directory.

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

   • Отказ в доступе к компьютеру из сети
   • Запрет входа в качестве пакетного задания;
   • Отказать во входе в качестве службы
   • Это позволит предотвратить использование членов группы "Администраторы" для входа или подключения к серверам-членам или рабочим станциям (если только несколько элементов управления не были впервые нарушены), где их учетные данные могут быть кэшированы и таким образом скомпрометированы. Привилегированная учетная запись никогда не должна использоваться для входа в менее привилегированную систему, и применение этих элементов управления обеспечивает защиту от ряда атак.

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

   • Доступ к этому компьютеру из сети
   • Локальный вход в систему
   • Разрешить вход в систему через службу удаленных рабочих столов

4. Аудит должен быть настроен для отправки оповещений, если какие-либо изменения вносятся в свойства или членство в группе администраторов. Эти оповещения должны отправляться как минимум членам группы, ответственной за администрирование AD DS. Оповещения также следует отправлять членам группы безопасности, а процедуры должны быть определены для изменения членства в группе администраторов. В частности, эти процессы должны включать процедуру, с помощью которой группа безопасности уведомляется, когда группа администраторов будет изменена таким образом, чтобы при отправке оповещений они ожидались, и тревога не вызывается. Кроме того, процессы для уведомления группы безопасности о завершении использования группы администраторов и удаления учетных записей из группы должны быть реализованы.

Контроль доступа на основе ролей (RBAC) для Active Directory

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

Собственные подходы к RBAC для Active Directory

В самой простой реализации RBAC можно реализовать роли в виде групп AD DS и делегирования прав и разрешений группам, которые позволяют им выполнять ежедневное администрирование в указанной области роли.

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

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

1. Какие задачи выполняются на ежедневной основе и какие задачи выполняются реже.
2. В каких системах и в каких приложениях должны предоставляться права и разрешения для членов роли.
3. Какие пользователи должны быть предоставлены в роли.
4. Как будет выполняться управление членством в роли.

Во многих средах создание элементов управления доступом на основе ролей для администрирования среды Active Directory может быть сложной задачей для реализации и обслуживания. Если вы четко определили роли и обязанности по администрированию ИТ-инфраструктуры, вам может потребоваться использовать дополнительные средства для создания управляемого собственного развертывания RBAC. Например, если Forefront Identity Manager (FIM) используется в вашей среде, можно использовать FIM для автоматизации создания и заполнения административных ролей, что может упростить текущее администрирование. Если вы используете Microsoft Endpoint Configuration Manager и System Center Operations Manager (SCOM), можно использовать роли, относящиеся к приложению, для делегирования функций управления и мониторинга, а также обеспечения согласованной настройки и аудита в разных системах в домене. Если вы реализовали инфраструктуру открытых ключей (PKI), вы можете выдавать и требовать смарт-карты для ИТ-персонала, ответственного за администрирование среды. С помощью управления учетными данными FIM (FIM CM) можно даже объединить управление ролями и учетными данными для административного персонала.

В других случаях для организации может быть предпочтительнее развернуть стороннее программное обеспечение RBAC, которое предоставляет функциональные возможности "вне коробки". Коммерческие, внеоплатные решения (COTS) для RBAC для Active Directory, Windows и каталогов, отличных от Windows, и операционных систем, предлагаются рядом поставщиков. При выборе между собственными решениями и сторонними продуктами следует учитывать следующие факторы:

1. Бюджет. Инвестируя в разработку RBAC с помощью программного обеспечения и средств, которые вы уже можете использовать, вы можете сократить затраты на программное обеспечение, участвующие в развертывании решения. Однако если у вас нет сотрудников, опытных в создании и развертывании собственных решений RBAC, вам может потребоваться привлечь консультационные ресурсы для разработки решения. Необходимо тщательно взвесить ожидаемые затраты на пользовательское решение с затратами на развертывание решения "вне коробки", особенно если бюджет ограничен.
2. Состав ИТ-среды: если ваша среда состоит в основном из систем Windows, или если вы уже используете Active Directory для управления системами и учетными записями, отличными от Windows, пользовательские собственные решения могут обеспечить оптимальное решение для ваших потребностей. Если инфраструктура содержит множество систем, которые не работают под управлением Windows и не управляются Active Directory, может потребоваться рассмотреть варианты управления системами, отличными от Windows, отдельно от среды Active Directory.
3. Модель привилегий в решении. Если продукт полагается на размещение учетных записей службы в группы с высоким уровнем привилегий в Active Directory и не предлагает варианты, которые не требуют чрезмерной привилегии, предоставляются программному обеспечению RBAC, вы не на самом деле сократили область атаки Active Directory, которую вы только изменили состав наиболее привилегированных групп в каталоге. Если поставщик приложений не может предоставлять элементы управления учетными записями служб, которые свести к минимуму вероятность компрометации и вредоносного использования учетных записей, вы можете рассмотреть другие варианты.

Управление привилегированными пользователями

Управление привилегированными удостоверениями (PIM) иногда называется привилегированным управлением учетными записями (PAM) или привилегированным управлением учетными данными (PCM) — это проектирование, строительство и реализация подходов к управлению привилегированными учетными записями в инфраструктуре. Как правило, PIM предоставляет механизмы, с помощью которых учетные записи предоставляются временные права и разрешения, необходимые для выполнения функций исправления сборки или перерыва, а не оставляя привилегии постоянно присоединенными к учетным записям. Можно ли создавать функции PIM вручную или реализовываться с помощью развертывания стороннего программного обеспечения одной или нескольких следующих функций:

• Учетные данные "хранилища", где пароли для привилегированных учетных записей "извлечены" и назначены первоначальный пароль, а затем "возвращены" при завершении действий, когда пароли снова сбрасываются в учетных записях.
• Ограничения на использование привилегированных учетных данных
• Одноразовые учетные данные
• Созданное рабочим процессом предоставление привилегий с мониторингом и отчетом о выполняемых действиях и автоматическом удалении привилегий при завершении или истечении срока действия истекло.
• Замена жестко закодированных учетных данных, таких как имена пользователей и пароли в скриптах с помощью интерфейсов api программирования приложений, которые позволяют получать учетные данные из хранилищ по мере необходимости.
• Автоматическое управление учетными данными учетной записи службы

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

Одной из проблем управления привилегированными учетными записями является то, что по умолчанию учетные записи, которые могут управлять привилегированными и защищенными учетными записями и группами, являются привилегированными и защищенными учетными записями. Если вы реализуете соответствующие решения RBAC и PIM для установки Active Directory, решения могут включать подходы, которые позволяют эффективно удалять членство в наиболее привилегированных группах в каталоге, заполняя группы только временно и при необходимости.

Однако при реализации собственных RBAC и PIM следует рассмотреть возможность создания учетных записей без привилегий и с единственной функцией заполнения и удаления привилегированных групп в Active Directory при необходимости. Приложение I. Создание учетных записей управления для защищенных учетных записей и групп в Active Directory содержит пошаговые инструкции, которые можно использовать для создания учетных записей для этой цели.

Реализация надежных элементов управления проверкой подлинности

Номер закона Шесть: Есть кто-то там пытается угадать ваши пароли. - 10 неизменяемых законов администрации безопасности

Атаки на кражу хэша и других учетных данных не относятся к операционным системам Windows и не являются новыми. В 1997 году была создана первая атака на хэш. Однако исторически эти атаки требовали настраиваемых средств, были поражены или пропущены в их успехе, и требуют, чтобы злоумышленники имели относительно высокую степень навыка. Внедрение свободно доступных средств, которые легко использовать средства, которые изначально извлекают учетные данные, привели к экспоненциальному увеличению числа и успешности атак кражи учетных данных в последние годы. Однако атаки кражи учетных данных не являются единственными механизмами, с помощью которых учетные данные предназначены и скомпрометированы.

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

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

Общие элементы управления проверкой подлинности

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

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

Дополнительные элементы управления для виртуальных IP-учетных записей

Еще одним преимуществом реализации смарт-карт или других механизмов проверки подлинности на основе сертификатов является возможность использовать механизм проверки подлинности для защиты конфиденциальных данных, доступных для пользователей ВИРТУАЛЬНЫХ IP-адресов. Контроль механизма проверки подлинности доступен в доменах, в которых для функционального уровня задано значение Windows Server 2012 или Windows Server 2008 R2. Если она включена, средство проверки подлинности Authentication Assurance добавляет членство в глобальной группе, назначенное администратором, в маркер Kerberos пользователя, когда учетные данные пользователя проходят проверку подлинности во время входа с помощью метода входа на основе сертификатов.

Это позволяет администраторам ресурсов управлять доступом к ресурсам, таким как файлы, папки и принтеры, в зависимости от того, входит ли пользователь в систему с помощью метода входа на основе сертификатов, а также тип используемого сертификата. Например, если пользователь входит в систему с помощью смарт-карты, доступ пользователя к ресурсам в сети можно указать по-разному, если пользователь не использует смарт-карту (то есть, когда пользователь входит в систему, введя имя пользователя и пароль). Дополнительные сведения о механизме проверки подлинности см . в пошаговом руководстве по механизму проверки подлинности для AD DS в Windows Server 2008 R2.

Настройка проверки подлинности привилегированной учетной записи

В Active Directory для всех административных учетных записей включите смарт-карту для интерактивного атрибута входа и выполните аудит изменений на вкладке "Учетная запись" на вкладке "Учетная запись" (например, cn, name, sAMAccountName, userPrincipalName и userAccountControl).

Хотя настройка смарт-карты "Требовать" для интерактивного входа в учетные записи сбрасывает пароль учетной записи на случайное значение 120 символов и требует смарт-карт для интерактивного входа, атрибут по-прежнему может быть перезаписан пользователями с разрешениями, которые позволяют им изменять пароли в учетных записях, а учетные записи можно использовать для установки неинтерактивных входов только с именем пользователя и паролем.

В других случаях в зависимости от конфигурации учетных записей в Active Directory и параметрах сертификатов в службах сертификатов Active Directory (AD CS) или сторонних атрибутов PKI, имя участника-пользователя (UPN) для административных или виртуальных IP-адресов можно использовать для определенного типа атаки, как описано здесь.

Перехват имени участника-участника для spoofing сертификатов

Хотя тщательное обсуждение атак на инфраструктуры открытых ключей (PKIs) находится вне области этого документа, атаки на общедоступные и частные PKIs увеличились экспоненциально с 2008 года. Нарушения общедоступных PKIs широко публикуются, но нападения на внутренние PKI организации, возможно, еще более плодовиты. Одна из таких атак использует Active Directory и сертификаты, чтобы позволить злоумышленнику спуфинировать учетные данные других учетных записей таким образом, что может быть трудно обнаружить.

Если сертификат представлен для проверки подлинности в системе, присоединенной к домену, содержимое атрибута Subject или альтернативного имени субъекта (SAN) в сертификате используется для сопоставления сертификата с объектом пользователя в Active Directory. В зависимости от типа сертификата и способа его создания атрибут Subject в сертификате обычно содержит общее имя пользователя (CN), как показано на следующем снимке экрана.

По умолчанию Active Directory создает cn пользователя, объединяя имя учетной записи + "+ фамилию. Однако компоненты CN объектов пользователей в Active Directory не являются обязательными или гарантированно уникальными, и перемещение учетной записи пользователя в другое расположение в каталоге изменяет различающееся имя учетной записи (DN), которое является полным путем к объекту в каталоге, как показано на нижней панели предыдущего снимка экрана.

Так как имена субъектов сертификата не являются статическими или уникальными, содержимое альтернативного имени субъекта часто используется для поиска объекта пользователя в Active Directory. Атрибут SAN для сертификатов, выданных пользователями корпоративных центров сертификации (интегрированные ЦС Active Directory), обычно содержит имя участника-пользователя или адрес электронной почты пользователя. Так как имена участника-пользователя гарантированно являются уникальными в лесу AD DS, поиск пользовательского объекта по имени участника-пользователя обычно выполняется как часть проверки подлинности, с сертификатами или без них, участвующими в процессе проверки подлинности.

Использование имен участника-пользователя в атрибутах SAN в сертификатах проверки подлинности может использоваться злоумышленниками для получения мошеннических сертификатов. Если злоумышленник скомпрометировал учетную запись, которая имеет возможность считывать и записывать имена участника-пользователя на пользовательские объекты, атака реализуется следующим образом:

Атрибут ИМЕНИ участника-пользователя для объекта пользователя (например, vip-пользователя) временно изменяется на другое значение. Атрибут имени учетной записи SAM и CN можно также изменить в настоящее время, хотя это обычно не требуется по причинам, описанным ранее.

Когда атрибут имени участника-пользователя в целевой учетной записи был изменен, устаревший, включенная учетная запись пользователя или недавно созданный атрибут имени участника-пользователя изменяется на значение, которое изначально было назначено целевой учетной записи. Устаревшие учетные записи пользователей — это учетные записи, которые не вошли в систему в течение длительного периода времени, но не были отключены. Они нацелены на злоумышленников, которые намерены "скрыться в простом виде" по следующим причинам:

1. Так как учетная запись включена, но недавно не использовалась, использование учетной записи вряд ли активирует оповещения, позволяющие включить отключенную учетную запись пользователя.
2. Использование существующей учетной записи не требует создания новой учетной записи пользователя, которую может заметить администратор.
3. Устаревшие учетные записи пользователей, которые по-прежнему включены, обычно являются членами различных групп безопасности и предоставляют доступ к ресурсам в сети, упрощая доступ и "смешиваясь" с существующим населением пользователей.

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

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

Теперь злоумышленник имеет один или несколько сертификатов, которые могут быть представлены для проверки подлинности в ресурсах и приложениях, как если бы пользователь — это виртуальный IP-адрес, учетная запись которого была временно изменена. Хотя полное обсуждение всех способов, в которых сертификаты и PKI могут быть нацелены злоумышленниками, выходит за рамки этого документа, этот механизм атаки предоставляется для иллюстрации того, почему вы должны отслеживать привилегированные и ВИРТУАЛЬНЫе учетные записи в AD DS для изменений, особенно для изменений на вкладке "Учетная запись" для учетной записи (например, cn, name, sAMAccountName, userPrincipalName и userAccountControl). Помимо мониторинга учетных записей, следует ограничить, кто может изменить учетные записи как можно меньшего набора административных пользователей. Аналогичным образом, учетные записи администраторов должны быть защищены и отслеживаться для несанкционированных изменений.