Защита учетных записей служб Windows (часть 2)

Опубликовано: 7 Апреля, 2023

Введение

В первой части этой статьи мы рассмотрели тот факт, что учетные записи служб — это учетные записи с высоким уровнем привилегий (обычно), которые должны быть защищены по сравнению с другими учетными записями. По сути, эти учетные записи пользователей аналогичны учетным записям ИТ/администраторов, за исключением того, что они почти не управляются. Мы также рассмотрели тот факт, что эти учетные записи не должны быть учетной записью администратора. Причины здесь были очевидны, но это все равно нужно было указать. В этом выпуске мы продолжим проверку конфигурации и причины, по которым эти учетные записи служб должны быть защищены.

Убедитесь, что учетные записи служб не являются учетными записями пользователей-людей

Я часто обнаруживаю, что учетные записи служб используют учетные записи пользователей ИТ-персонала. Я понимаю причины, но результат ужасен. Причина в том, что ИТ-сотруднику требовалось установить приложение, и казалось, что у него не было времени на создание нового пользователя для этой задачи, поэтому вместо этого использовалась его собственная учетная запись пользователя. Имя пользователя и пароль были легко доступны, поэтому они были использованы. Ужасно то, что этот пароль обычно не менялся с того момента.

Проблемы продолжаются, поскольку учетная запись службы теперь связана с учетной записью пользователя-человека. Во-первых, если пользователь меняет должностные обязанности, скажем, переходит из ИТ в отдел кадров, теперь у этой учетной записи пользователя больше не должно быть прав администратора для домена. Что произойдет сейчас? Во-вторых, если пользователь покинет компанию, что произойдет с учетной записью пользователя. Учетную запись необходимо отключить и вскоре удалить, но это невозможно из-за того, что учетная запись также используется в качестве учетной записи службы. Это оставляет черный ход в компанию для сотрудника, покинувшего компанию, поскольку учетная запись не может быть отключена и удалена. В-третьих, даже если пользователь останется в ИТ, сотрудник будет продолжать утверждать, что смена пароля невозможна, так как это нарушит работу службы, для которой используется учетная запись службы.

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

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

Я часто слышу, что пароли учетных записей служб нельзя изменить из-за того, что ИТ-отдел не знает всех местоположений, в которых используется учетная запись службы. Я понимаю, что это дилемма, но это не оправдание. ИТ «ДОЛЖНЫ» знать такие детали даже в очень большой среде. На самом деле, в очень большой среде это еще более важно, так как проблемы, связанные с передачей хэша, уязвимостями, слабыми паролями и многим другим, могут иметь больший эффект и их гораздо сложнее устранить.

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

Несколько ключевых замечаний по настройке этого аудита:

Обязательно настройте «Аудит событий входа в учетную запись» в объекте групповой политики, который связан с OU контроллеров домена, как показано на рисунке 1.
Обязательно либо просмотрите каждый журнал безопасности на каждом контроллере домена, чтобы отследить все входы в систему (поскольку эта информация не реплицируется между контроллерами домена), либо настройте пересылку журнала событий, чтобы централизовать журнал со всех контроллеров домена (пересылка журнала событий бесплатна и т. д.). информацию можно найти здесь).

Рисунок 1. Аудит событий входа в учетную запись, для которых установлено значение «Успех»

Когда у вас есть список всех серверов, на которых используется учетная запись службы, вы можете принимать решения о правильной настройке учетной записи службы. Во-первых, если учетная запись службы пересекается со слишком многими службами, теперь вы можете создавать уникальные учетные записи служб для каждой службы, чтобы снизить общий риск. Во-вторых, вы можете настроить список серверов, на которые разрешен вход служебной учетной записи. Это настраивается в учетной записи пользователя в Active Directory. Вкладка «Войти в систему», а затем настройка списка серверов для этой конфигурации показана на рисунках 2 и 3.

Рисунок 2: Настройте параметр «Вход в систему» для учетной записи службы в Active Directory.

Рисунок 3: Создание списка серверов, на которые может войти учетная запись службы.

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

Убедитесь, что учетные записи служб имеют безопасные пароли

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

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

30+ персонажей
Использование прописных букв альфа, строчных букв альфа, цифр, специальных символов и пробелов
В такой ситуации всегда легче ввести парольную фразу, что-то вроде «Люди, которые думают, что они все знают, сильно раздражают тех из нас, кто все знает».

Резюме

Служебные учетные записи, безусловно, являются одним из самых раздражающих, но важных аспектов защиты вашей инфраструктуры Windows. Нам нужны служебные аккаунты, в этом нет сомнений. Мы должны использовать их, и без хороших мер безопасности мы оставляем эти учетные записи уязвимыми со значительными эксплойтами. Нам нужно получить контроль над этими учетными записями служб, обеспечив их максимальную безопасность, поскольку мы обычно настраиваем их, а затем забываем о них. Здесь мы применили несколько простых подходов к защите наших сервисных учетных записей. Во-первых, убедитесь, что учетная запись не использует встроенную учетную запись администратора. Это вызывает конфликт ролей и этого просто не следует делать. Во-вторых, следите за тем, чтобы учетная запись службы не дублировалась совместно с пользователем-человеком, особенно с пользователем ИТ. В-третьих, ограничения рабочих станций для учетных записей службы должны включать только те серверы, на которых используется учетная запись службы. Это идеальный способ уменьшить поверхность атаки. Наконец, обязательно настройте учетные записи служб на использование длинного, надежного и сложного пароля. В идеале пароль должен быть длиннее 30 символов, использовать все возможные типы символов и не передаваться другим лицам.