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

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

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

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

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

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

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

Естественно, нужно политиками обеспечить достаточную длину и сложность пароля как для пользователей, так и для администраторов и условия блокировки. Я говорю о политиках раздела Computer Configuration -> Windows Settings -> Security Settings -> Account Policies

  • Password Policy
  • Account Lockout Policy

Политика паролей в домене WindowsМожно сделать более жёсткие требования к длине и хранимой истории паролей для администраторов с помощью 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 серверах принудительно завершать приостановленные сессии с помощью политик в разделе 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.

Еще записи по теме: Active Directory, Security
Понравилась статья? Скажи спасибо и расскажи друзьям!
Назад:
Вперед:

Комментариев: 4

Оставить комментарий
  1. Андрей | 25.09.2017

    Интересная статья! Благодарю!
    Вопрос на счет Protected Users. Если пользователь будет находиться в других группах — например админская группа SQL, то будет ли в этом случае работать группа защищенных групп?

    Ответить
    • Сергей | 26.09.2017

      Промахнулся с ответом. См. мой комментарий.

      Ответить
  2. Сергей | 26.09.2017

    Ну а почему нет-то? Членство в этой группе не зависит/не влияет от/на членства(о) в других группах.
    В реальном домене в любом случае любая учётка хоть в какой-то группе да находится. Хотя бы в «Domain Users». Чем остальные группы хуже?
    Другое дело, что ограничивая аутентификацию учётки исключительно по Kerberos мы получаем побочные эффекты. Скажем я админ и решил положить свою админскую учётку в «Protected Users». Логичный вроде бы ход. Теперь я пришел домой и мне что-то понадобилось сделать на сервере на работе. Я подключаюсь к рабочей сети по VPN, пробую зайти на сервер через RDP. И.. хрен. Комп не в домене -> аутентификация не проходит.
    Известная аксиома, что удобство работы обратно пропорционально безопасности. Внедрив все технологии безопасности мы, к огромному сожалению, превратим нашу систему в малоюзабельное нечто.

    Ответить
    • itpro | 26.09.2017

      Все верно, группа Protected Users — довольно мощное средство, но накладывает кучу ограничений. И перед массовым внедрением нужно тщательно проверить, как будет работать ожидаемый функционал системы.
      Плюс, чтобы SQL сервер корректно авторизовал с помощью Kerberos его необходимо дополнительно «готовить»

      Ответить
Полные правила комментирования на сайте winitpro.ru. Вопросы, не связанные с содержимым статьи или ее обсуждением удаляются.

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Я не робот( Обязательно отметьте)



MAXCACHE: 0.4MB/0.00048 sec