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

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

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

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

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

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

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

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

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

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

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

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

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

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

В Active Directory

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

Даже если переименованы учетные записи локального Администратор istrator, политики по-прежнему применяются.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

Контроль доступа на основе ролей (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 неизменяемых законов о безопасности Администратор istration

Атаки на кражу хэша и других учетных данных не относятся к операционным системам 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). Помимо мониторинга учетных записей, следует ограничить, кто может изменить учетные записи как можно меньшего набора административных пользователей. Аналогичным образом, учетные записи администраторов должны быть защищены и отслеживаться для несанкционированных изменений.