Один повторяющийся пароль может связать рабочее место администратора, контроллер домена и сервер 1С. Если атакующий получит привилегированную учётную запись, под угрозой окажутся все системы и пользователи домена.
CISA добавила в каталог бесплатных средств Weak Password Test. Проверка ищет десять типов проблем с паролями Active Directory, включая короткие, пустые и повторяющиеся пароли. Задача администратора — получить отчёт и заменить найденные пароли без остановки служб 1С, СУБД и резервного копирования.
Начните с учётных записей, которые дают доступ к серверам 1С
Не проверяйте список пользователей по алфавиту. Сначала выделите учётные записи, захват которых даст административный доступ или остановит рабочие базы после неосторожной смены пароля.
Microsoft относит встроенные группы Enterprise Admins, Domain Admins и Administrators к группам с наивысшими правами в Active Directory. Доступ к контроллеру домена даёт атакующему возможность изменить, повредить или уничтожить базу AD.
Следующая группа — локальные администраторы серверов 1С и СУБД. Их права уже доменных, но одного такого аккаунта хватит для остановки служб, изменения файлов или отключения резервного копирования.
Служебные учётные записи требуют другого подхода. Опасность скрывается не только в слабом пароле. После его смены служба продолжит запускаться со старыми реквизитами и остановится при следующем старте сервера.
| Тип учётной записи | Что получит атакующий | Что рискует остановиться после смены пароля | Кто подтверждает замену |
|---|---|---|---|
Член Enterprise Admins, Domain Admins или Administrators | Управление доменом, контроллерами и подчинёнными системами | Административные задания и службы, если аккаунт использовали для постоянного запуска | Администратор AD и ответственный за серверы 1С |
| Локальный администратор сервера | Управление конкретным сервером 1С, СУБД или резервного копирования | Локальные службы, планировщик, сценарии обслуживания | Владелец сервера и администратор 1С |
| Служебная учётная запись | Права службы, которая работает под этим аккаунтом | Сервер 1С, агент СУБД, задания копирования, мониторинг | Владелец каждой зависимой службы |
| Обычный пользователь домена | Доступ к данным и приложениям этого пользователя | Пользовательские подключения и сохранённые задания | Пользователь и служба поддержки |
Первым исправляйте пароль, который одновременно слаб и открывает административный доступ. Служебный пароль меняйте после инвентаризации зависимостей, иначе аудит сам создаст простой.
Отделите административные аккаунты от служебных
Одна учётная запись не должна одновременно обслуживать сервер и использоваться для повседневной работы. Microsoft предупреждает: вход с привилегированным аккаунтом на незащищённом компьютере повышает риск кражи реквизитов.
Риск растёт, если администратор открывает под этим аккаунтом почту и браузер. Вредоносная страница, вложение или расширение получает шанс добраться до реквизитов активного сеанса.
Для каждой учётной записи из привилегированных групп зафиксируйте назначение:
- кто владелец;
- на каких компьютерах разрешён вход;
- где сохранены реквизиты;
- какие службы используют аккаунт;
- кто подтвердит работу после смены пароля.
Если назначение неизвестно, не удаляйте аккаунт и не меняйте пароль вслепую. Сначала изучите журналы входа и конфигурацию служб. Неизвестная учётная запись может оказаться забытой, но работающей связью между компонентами.
Выберите способ аудита по допустимому доступу к AD
В исследовании подтверждены два маршрута: CISA Weak Password Test и команда Test-PasswordQuality из модуля DSInternals. Они решают похожую задачу, но требуют разной модели доверия.
CISA сообщает о десяти типах проверяемых слабостей. Среди них есть короткие, пустые и повторяющиеся пароли. При этом CISA не подтверждает пригодность или результат средства для конкретной организации: включение в бесплатный каталог не равно рекомендации.
DSInternals описывает механику подробнее. Test-PasswordQuality находит слабые, повторяющиеся, стандартные, пустые и неистекающие пароли. Результат доступен как читаемый отчёт и как объект PowerShell.
Модуль принимает данные двух типов. Get-ADDBAccount передаёт сведения из копии ntds.dit, а Get-ADReplAccount получает их через механизм DCSync. Оба маршрута затрагивают доменные данные, поэтому запускайте их только в согласованном административном контуре.
| Способ | Какой доступ нужен | Что подтверждено документацией | Риск для рабочего домена | Когда выбирать |
|---|---|---|---|---|
| CISA Weak Password Test | Определяется процедурой выбранной проверки CISA | Десять типов слабостей, включая короткие, пустые и повторяющиеся пароли | Зависит от порядка передачи и обработки данных | Когда правила организации допускают сервис CISA и согласован способ работы с доменными данными |
DSInternals с копией ntds.dit | Доступ к подготовленной копии базы AD | Слабые, повторяющиеся, стандартные, пустые и неистекающие пароли | Рабочий контроллер не участвует в анализе, но копия содержит доменные данные | Когда можно подготовить, изолировать и затем удалить рабочую копию |
| DSInternals через DCSync | Права, достаточные для репликационного получения данных | Те же категории отчёта Test-PasswordQuality | Ошибка в правах или обращении с результатом затрагивает рабочий домен | Когда онлайн-анализ согласован и проводится выделенной административной учётной записью |
Для первого прохода выбирайте маршрут с наименьшим доступом, который всё же даёт нужный отчёт. DCSync и копию ntds.dit используйте там, где вы контролируете хранение исходных данных и результата.
Не переносите в рабочий домен команды из случайной инструкции. Заявления о Specops, Have I Been Pwned и настройках GPO в предоставленных материалах опираются на сторонний обзор, а не на документацию производителей. Этого мало для редакционной рекомендации.
Подготовьте аудит так, чтобы отчёт не стал новой утечкой
Microsoft указывает, что похитители реквизитов целятся в постоянно привилегированные аккаунты, контроллеры домена и инфраструктурные службы. Отчёт Test-PasswordQuality помогает выделить такие учётные записи среди найденных проблем. Поэтому доступ к результату должен быть не шире доступа к другим материалам аудита безопасности.
Создайте для проверки отдельный каталог с ограниченными правами. Не отправляйте результат по общей почте, не кладите его в сетевую папку отдела и не прикладывайте к заявке в службе поддержки.
Если анализ требует копии ntds.dit, заранее назначьте место хранения и срок удаления. После аудита удалите рабочие копии штатным для вашей организации способом и проверьте, что они не попали в обычное резервное копирование.
Сам запуск лучше провести в окно обслуживания, хотя рабочие базы останавливать не требуется. Окно нужно не инструменту, а администраторам: критическая находка может потребовать смены пароля и проверки зависимых служб.
Читайте отчёт по последствиям, а не по числу строк
Число строк не определяет порядок исправления. Microsoft указывает, что похитители реквизитов нацеливаются на постоянно привилегированные аккаунты и учётные записи, связанные с инфраструктурными службами. Поэтому сначала проверяйте находки с административным доступом, а затем остальные.
Разделите находки по типу:
| Находка | Как трактовать | Первое действие | Что проверить после исправления |
|---|---|---|---|
| Пустой пароль | Учётная запись требует проверки назначения и доступных способов входа | Назначить новый пароль по принятой политике | Старый вход закрыт, блокировки не растут |
| Стандартный пароль | Пароль могли оставить после установки или массового создания аккаунтов | Проверить владельца и сменить реквизиты | Службы и задания используют новые данные |
| Повторяющийся пароль | Компрометация одного аккаунта помогает атаковать остальные | Начать с совпадений у привилегированных аккаунтов | Повторный аудит больше не видит совпадение |
| Короткий или слабый пароль | Устойчивость не соответствует принятой политике | Заменить после проверки зависимостей | Пользователь входит, приложения работают |
| Неистекающий пароль | Это признак для проверки, а не доказательство компрометации | Уточнить назначение и причину исключения | Исключение обосновано либо снято |
Отдельно ищите совпадения между обычным и административным аккаунтом одного сотрудника. Такой пароль уничтожает смысл разделения ролей: реквизиты можно украсть в повседневном сеансе, а применить в административном.
Неистекающий пароль переносите в конец очереди, если других признаков риска нет. Сначала выясните, почему для аккаунта отключили срок действия. Для службы это могло быть осознанным решением, хотя зависимость всё равно стоит убрать.
Перед сменой служебного пароля найдите все сохранённые реквизиты
Слабый служебный пароль нельзя считать исправленным сразу после смены в Active Directory. Старые реквизиты могут остаться в службах Windows, планировщике, средствах резервного копирования и мониторинга.
Проверьте хотя бы четыре места:
- службы сервера 1С и связанные агенты;
- службы или задания СУБД;
- задания планировщика Windows;
- программы резервного копирования и мониторинга.
Список нужно расширить под вашу схему. Если аккаунт обслуживает файловый ресурс, интеграцию или запуск сценариев, добавьте их до смены пароля.
Назначьте человека, который проверит каждый компонент. Фраза «учётка вроде нигде больше не используется» не подходит: после перезагрузки такая догадка превращается в остановленную службу.
Меняйте пароли по одному контуру
Массовая смена всех найденных паролей затрудняет диагностику. Если после неё перестанет открываться база, придётся одновременно проверять сервер 1С, СУБД, DNS, резервное копирование и доменные политики.
Разделите работу на короткие серии. Внутри одной серии меняйте реквизиты только у связанных компонентов, затем проверяйте результат.
Для служебной учётной записи порядок такой:
- Зафиксируйте службы, задания и подключения со старыми реквизитами.
- Подготовьте ответственных за проверку 1С, СУБД и резервного копирования.
- Смените пароль в Active Directory.
- Обновите реквизиты во всех найденных зависимостях.
- Проверьте запуск служб и выполнение заданий.
- Откройте базу 1С под обычным пользователем.
- Повторите аудит этой учётной записи.
Если пароль влияет на GPO или работу контроллеров домена, сначала проведите изменения на отдельном пилотном контуре. Рабочие серверы 1С не должны первыми встретить новую политику.
Не лечите одинаковые локальные пароли переименованием аккаунта
Одинаковый пароль локального администратора на нескольких серверах переносит компрометацию с одного узла на остальные. Microsoft прямо относит такую конфигурацию к рискам для учётных данных.
Переименование встроенного администратора не меняет его SID. Поэтому новое имя не решает проблему одинаковых реквизитов.
Microsoft LAPS назначает отдельный пароль локальному администратору каждого доменного компьютера и хранит его в Active Directory. Для внедрения опирайтесь на документацию Microsoft, а не на параметры из стороннего чек-листа: предоставленное исследование не подтверждает точные версии, права и команды настройки.
После внедрения проверьте не наличие объекта политики, а результат на нескольких серверах. Пароли должны различаться, доступ к ним — соответствовать ролям администраторов.
Закройте путь к повторной краже реквизитов
Новая парольная политика не защищает привилегированный аккаунт, если администратор продолжает читать под ним почту. Microsoft связывает такие сеансы с повышенным риском кражи реквизитов.
Для административной работы используйте выделенный защищённый компьютер. На нём не должно быть почтового клиента, офисных программ и обычного веб-браузинга. Microsoft также требует MFA для привилегированных аккаунтов и административных действий на защищённых рабочих местах.
Постоянное членство в группах с наивысшими правами тоже стоит убрать. Microsoft относит эту меру к профилактике атак на Active Directory. Администратор должен получать привилегии на время работы, а не носить их в каждом сеансе.
После смены паролей проверьте вход в 1С и работу доменной авторизации. Отдельный тест авторизации 1С через несколько контроллеров поможет проверить этот участок независимо от парольного аудита.
Порядок работ на ближайшее окно обслуживания
Перед началом зафиксируйте область аудита: привилегированные, служебные и обычные доменные учётные записи. Назначьте владельца каждому административному и служебному аккаунту.
Дальше действуйте в таком порядке:
- Выберите CISA Weak Password Test или DSInternals по допустимому доступу к AD.
- Сохраните отчёт в каталоге с ограниченными правами.
- Сначала исправьте пустые и стандартные пароли.
- Затем устраните совпадения у привилегированных аккаунтов.
- Разведите пароли административного и обычного аккаунтов одного сотрудника.
- Исправьте остальные слабые пароли.
- Проверьте назначение неистекающих учётных записей.
- Удалите рабочие копии доменных данных после завершения аудита.
Этот порядок следует из последствий привилегированного доступа, описанных Microsoft. Он ставит выше находку, которая открывает больше систем, а не ту, которая первой попалась в отчёте.
Слабый пароль устранён только после трёх проверок: старые реквизиты больше не работают, зависимые службы запустились, повторный аудит не показывает ту же находку. Если хотя бы одна проверка провалена, работа ещё не закончена.