GPO и Ansible: как держать одинаковые настройки на парке
Применяйте одни и те же настройки на весь парк: групповые политики (GPO) на Windows, Ansible на Linux — и раз в неделю смотрите, кто отстал. Какие именно меры в эталоне — не здесь: hardening Windows, hardening Linux. Одинаковая точка старта машин — золотой образ. Обновления Windows как покрытие WSUS — соседняя тема очереди, не этот рецепт.
Статья опирается на логику направления «Безопасность конечных устройств» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. CIS Control 4 требует поддерживать безопасную конфигурацию, а не настроить один раз вручную: cisecurity.org/controls. Это не российский закон. Плейбук и GPO применяйте к своим узлам.
Два контура, одна идея
| Windows | Linux | |
|---|---|---|
| Носитель эталона | GPO на подразделение (OU) | Один playbook на группу инвентаря |
| Проверка «как есть» | gpresult |
ansible-playbook --check |
| Исключение | Отдельное OU или фильтр с датой | Группа exceptions с датой в комментарии |
Не держите второй эталон «в голове админа». Локальный администратор Windows — отдельный контур: LAPS. Прокси и DNS на станциях тоже задайте отсюда, не вручную: прокси выхода.
Windows: что должно примениться
На выборке станций и серверов (документация Microsoft, вывод краткий):
gpresult /r /scope computerОжидаемо: в блоке Applied Group Policy Objects есть имя вашего эталонного GPO, не только «Local Group Policy». Команда: gpresult. Если объекта нет — машина не в том OU, нет связи с доменом или политика отключена. Не пишите пароль в строку /p.
Linux: синтаксис, потом сухой прогон
С управляющей машины, инвентарь и playbook — свои имена:
ansible-playbook -i inventory.ini site.yml --syntax-check
ansible-playbook -i inventory.ini site.yml --check --diffОжидаемо: сначала «playbook: …» без ошибки синтаксиса; затем список отличий без записи на диск (--check / -C, плюс --diff / -D). Документация: ansible-playbook. Риск: без --check плейбук сразу меняет боевые узлы. Сначала сухой прогон на копии, потом применение в окно изменений: перечень для ИБ.
В playbook не кладите пароли и ключи: переменные и хранилище секретов, не файл в git. Уже лежащие секреты — другой разбор: секреты в git.
Диагностика
| Симптом | Причина и что делать |
|---|---|
| Эталон есть, треть парка другая | Нет проверки. Раз в неделю gpresult и --check на выборке |
| Один сервер «нельзя трогать» | Исключение без даты. Поставьте срок или верните в контур |
| Ansible меняет не те хосты | Широкий инвентарь. Сузьте -l группу |
| GPO применилась, образ старый | Так и должно: образ — старт, политики — дрейф. Обновите образ отдельно |
Где это в модели зрелости
Материал относится к направлению «Безопасность конечных устройств» (хаб: конечные устройства, карта: карта зрелости). Hardening говорит «что выключить». Без GPO и Ansible это сделано на трёх машинах и забыто. Золотой образ не заменяет политики: через месяц парк снова разъедется.
Как проверить
- На трёх Windows в
gpresult /rвидно эталонное GPO. - На трёх Linux
ansible-playbook --checkлибо без отличий, либо отличия в задаче на исправление. - Исключения имеют дату окончания.
- В репозитории плейбука нет паролей.
- Статья не повторяет чек-лист hardening и не учит снимать образ.
Источники
- CIS Control 4: cisecurity.org/controls.
- gpresult: learn.microsoft.com.
- ansible-playbook: docs.ansible.com.
