Защита учетных записей пользователей в корпоративной сети на базе домена MS Windows типовая и простая задача. Все уже реализовано и регламентировано (например в MS TechNet Password Best practices или в 17/21 приказах ФСТЭК ):
- Использование сложного и длинного пароля.
- Временная блокировка пользователя в случае неправильного ввода пароля.
- Периодическая обязательная смена пароля пользователем.
Но что делать с "служебными" технологическими учетными записями?
Такие записи есть в любой корпоративной сети и используются, например, для:
- функционирования программ и служб на серверах;
- связи программ с СУБД (при доменной авторизации в СУБД);
- создания служебных почтовых ящиков в Exchange.
Так же отнесем к этому списку учетные записи администраторов, в случае если они используются для вышеперечисленных задач.
О особенностях защиты служебных учетных записей мы дальше и поговорим.
name='more'>
Почему нужно "по особенному" защищать служебные учетные записи?
Потому что к ним невозможно применить те же политики безопасности, что и к рядовым пользовательским записям, а именно:- Временная блокировка пользователя в случае неправильного ввода пароля.Нельзя блокировать служебную запись, иначе сервис, в котором задействована эта запись, перестанет функционировать для всех пользователей сети. Такая блокировка может произойти из за ошибки сотрудника, целенаправленного саботажа или вирусной активности связанной с перебором паролей (например, Net-Worm.Win32.Kido).
- Периодическая обязательная смена пароля пользователем.Нельзя устанавливать периодическую обязательную смену пароля для служебной учетной записи, иначе система запросит смену пароля и заблокирует запись, а использующий ее сервис, опять же, перестанет функционировать.
Получается, что в сети есть множество служебных учетных записей, не защищенных от перебора и с годами несменяемым паролем. А если учесть, что за время функционирования сервиса к его обслуживанию мог приложиться не один инженер, считаем пароль известным широкому кругу лиц.
Защита у служебных учетных записей ниже, чем у записей пользователей, а используя их можно в сети совершить что угодно, тем более что зачастую они наделены расширенными привилегиями.
Ниже приведены приемы, позволяющие минимизировать риск несанкционированного использования служебных учетных записей. Все они прошли проверку и внедрены в корпоративной сети.
Автоматическая разблокировка и оповещение
Отключение политик блокировки учетной записи в случае ввода неверного пароля чревато полным отсутствием защиты от подбора пароля.
Можно применить следующее решение:
- политику блокировки учетных записей распространить на всех, в том числе и на служебные учетные записи;
- в случае блокировки служебной учетной записи осуществлять ее немедленную разблокировку и оповещение администратора безопасности о факте блокировки с указанием компьютера, на котором был неверно введен пароль.
В результате, мы хоть и не пресекаем попытки подбора пароля, но оповещаем администратора, давая ему возможность оперативно среагировать на инцидент.
Реализация:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[(EventID=4740)]] and *[EventData[Data[@Name='TargetUserName'] and (Data='[USERNAME]')]] and *[EventData[Data[@Name='SubjectDomainName'] and (Data='[DOMAIN NAME]')]]</Select>
</Query>
</QueryList>
Где:
На контроллере домена в планировщике событий настраиваем задание, срабатывающее по событию блокировки конкретной служебной учетной записи:
Свойства события -> Вкладка: Триггеры –> Создать –> Назначить дату: При событии ->Параметры: Настраиваемое -> Создать фильтр события… -> Вкладка: XML -><QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[(EventID=4740)]] and *[EventData[Data[@Name='TargetUserName'] and (Data='[USERNAME]')]] and *[EventData[Data[@Name='SubjectDomainName'] and (Data='[DOMAIN NAME]')]]</Select>
</Query>
</QueryList>
Где:
[USERNAME]-имя контролируемой учетной записи;
[DOMAIN NAME]-имя домена.
-ExecutionPolicy RemoteSigned -Command "& {C:ScriptsUnlock.ps1 -user [USERNAME] }"
Основу скрипта составляют команды:
Import-Module ActiveDirectory // работаем с АД
Unlock-ADAccount $user // снимаем блокировку с учетной записи
Get-EventLog -LogName 'Security' -newest 10000 | Where-Object {$_.EventID -eq 4740 -and $_.ReplacementStrings[0] -eq "$user"} | Select-Object -first 1 // сохраняем текст события, чтобы узнать с какого компьютера произошла блокировка
Net.Mail //отправляем уведомление администратору.
[DOMAIN NAME]-имя домена.
Далее настраиваем действие по этому событию - запуск скрипта, который принимает в качестве аргуметов имя учетной записи, снимает с нее блокировку и отправляет уведомление по электронной почте.
В нашем случае это скрипт на powershell, запуск с аргументами:-ExecutionPolicy RemoteSigned -Command "& {C:ScriptsUnlock.ps1 -user [USERNAME] }"
Основу скрипта составляют команды:
Import-Module ActiveDirectory // работаем с АД
Unlock-ADAccount $user // снимаем блокировку с учетной записи
Get-EventLog -LogName 'Security' -newest 10000 | Where-Object {$_.EventID -eq 4740 -and $_.ReplacementStrings[0] -eq "$user"} | Select-Object -first 1 // сохраняем текст события, чтобы узнать с какого компьютера произошла блокировка
Net.Mail //отправляем уведомление администратору.
Данное событие в планировщике задач нужно продублировать для каждой служебной учетной записи, находящейся на контроле. Если таких записей слишком много, то есть смысл модернизировать решение, чтобы:
- задание в планировщике срабатывало при блокировке любой учетной записи (событие 4740 в журнале безопасности);
- осуществлялся поиск каждой заблокированной учетной записи в группе домена "служебные учетные записи" (например);
- в случае, если учетная запись находится в группе, осуществлялась ее разблокировка и уведомление администратора.
Блокировка полноценной работы
В своем большинстве служебные учетные записи используются для работы конкретных служб или для работы на серверах. Значит, для них можно отключить все лишние возможности. Например, запретить возможность локального входа на компьютеры сети.
Microsoft предлагает делать это соответствующей политикой, расположенной тут: Параметры безопасностиЛокальные политикиНазначение прав пользователяЛокальный вход в систему. Но иногда использование этой политики затруднительно, тогда можно использовать следующий метод:
- создаем доменную группу "служебные учетные записи" и добавляем в нее все учетные записи, которым ни к чему осуществлять локальный вход на компьютеры сети;
- создаем групповую политику домена, применяемую к созданной группе и включающую единственное правило - запуск при входе в систему %SystemRoot%System32logoff.exe.
В результате, даже если пароль от учетной записи будет скомпрометирован, зайти с ним на компьютеры сети будет проблематично.
Мониторинг подозрительной активности
Если учетная запись создана для работы с БД или авторизации приложения, то ей нечего делать на файловых серверах или контроллере домена. Конечно, при правильно настроенных правах доступа она туда и не попадет, но кто даст гарантию? Поэтому необходимо вести различного рода мониторинг подозрительной активности со стороны служебных учетных записей. Для этих целей можно использовать:
- планировщики заданий и скрипты;
- различные SIEM решения;
- DLP системы.
Описывать варианты мониторинга на примере конкретных систем защиты в данной статье будет лишним, учитывая что в каждой сети они свои, приведу лишь события, которые имеет смысл "отлавливать":
- авторизация на компьютерах и серверах (в том числе неудачные попытки авторизации);
- заход на файловые сервера, создание и изменение файлов на них;
- обращения к контроллеру домена;
- запуск приложений, ненужных данной учетной записи.
В качестве резюме: компрометация и последующее несанкционированное использование служебных учетных записей являются серьезной угрозой для любой корпоративной сети и при построении системы защиты следует уделять большее внимание их защите и контролю. Необходимо понимать, что можно заблокировать, а что необходимо поставить на контроль.
