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

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

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

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

Базовый список правил:

• Учетные записи администраторов домена/организации должны использоваться только для управления доменом и контроллерами домена. Нельзя использовать эти учетные записи для доступа и управления рабочими станциями. Аналогичное требование должно предъявляться для учетных записей администраторов серверов
• Для учетных записей администраторов домена желательно использовать двухфакторную аутентификацию
• На своих рабочих станциях администраторы должны работать под учетными записями с правами обычного пользователя
• Для защиты привилегированных учетных записей (администраторы домена, Exchange, серверов) нужно рассмотреть возможность использования группы защищенных пользователей (Protected Users)
• Запрет использования обезличенных общих административных аккаунтов. Все аккаунты администраторов должны быть персонифицированы
• Нельзя запускать сервисы под учетными записями администраторов (а тем более администратора домена), желательно использовать выделенные учетные записи или Managed Service Accounts .
• Запрет работы пользователей под правами локального администратора

Естественно, нужно политиками обеспечить достаточную длину и сложность пароля как для пользователей, так и для администраторов и условия блокировки. Я говорю о политиках раздела Computer Configuration -> Windows Settings -> Security Settings -> Account Policies (см статью https://winitpro.ru/index.php/2018/10/26/politika-parolej-uchetnyx-zapisej-v-active-directory/):

• Password Policy
• Account Lockout Policy

Можно сделать более жёсткие требования к длине и хранимой истории паролей для администраторов с помощью Fine-Grained Password Policies.
Касательно встроенной учетной записи на компьютерах пользователей. Нельзя использовать одинаковые пароли локального администратора на всех ПК. Желательно вообще отключить (или хотя бы переименовать) локальную учетку administrator. Для регулярной смены пароля этой учетной записи на уникальный на каждом компьютере в сети можно использовать LAPS.

Доступ по сети с помощью локальных учетных записей и удаленных вход по RDP нужно запретить групповыми политиками . Данные политики находятся в разделе Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.

• Deny access to this computer from the network – Отказать в доступе к этому компьютеру из сети
• Deny log on through Remote Desktop Services – Запретить вход в систему через службы удаленных рабочих столов
• Deny log on as a batch job – Отказать во входе в качестве пакетного задания

• Deny log on as a service — Отказать во входе в качестве службы

После окончания административного сеанса (установка ПО, настройка системы и т.д. ) компьютер пользователя лучше перезагрузить. А на RDS серверах принудительно завершать приостановленные RDP сессии с помощью политик в разделе Computer Configuration->Policies->Administrative Templates->Windows Components->Remote Desktop Services->Remote Desktop Session Host->Session Time Limits.

В домене с Windows Server 2016 для временного предоставления административных прав можно использовать новую фичу Temporary Group Membership

В этой я описал первоочередные правила, которые помогут вам повысить уровень защиты административных аккаунтов в вашем домене Windows. Конечно, это статья не претендует на полноценных гайд по защите и ограничению прав учетных записей администратора, но вполне может стать вашей отправной точкой по построению безопасной инфраструктуры. Для дальнейшего изучения темы рекомендую начать с изучения документации Microsoft: Best Practices for Securing Active Directory.