← Назад к «Интерфейсы (UI)»

Конфигурации

Обновлено:

Раздел «Каталог и политики» → «Групповые политики» — управление соответствием хостов политикам ИБ через локально запускаемый Ansible на клиентах. Универсальный «солдат»: EDR/антивирус/DLP, харднинг ОС, OVAL-ремедиации, любые конфиги и службы.

Вкладка доступна с правом config.view; появляется после установки на клиенты пакета lsus-config-agent (со встроенным self-contained Ansible). Закрывает класс задач ИБ между патчами и USB-контролем — проверку и исправление конфигурации: EDR (bi.zone) / антивирус (Kaspersky KES) / DLP (Staffcop) — установлен ли и запущен; sshd_config, sysctl, firewall/auditd/NTP — соответствие стандарту. Раньше нужен был отдельный инструмент (Ansible AWX, Tower, скрипты); теперь — единый UI, общая модель хостов/групп/тегов, аудит, роли.

Как это устроено (pull-модель, локальный Ansible, Ed25519-подпись версий, версионирование) — «Как это работает — общая схема» в руководстве администратора.

Релизы, раскатки, назначения#

Групповые политики используют релизную модель (GPO-стиль): изменения готовятся, проверяются и выкатываются постепенно, а не правкой «живой» политики.

Сущность Что это Аналог
Ревизия (release) Неизменяемый снимок политики; цикл draft → validated → approved → retired; откат к проверенной ревизии. Version-контроль GPO
Раскатка (rollout) Применение релиза волнами хостов, фазы precheck → apply → verify. Controlled rollout
Назначение (assignment) Долгоживущая привязка к аудитории; режимы audit (проверка) / enforce (применение). Linked GPO + enforcement
Compliance-расписание Регулярный автоматический precheck соответствия назначенной политике. Continuous compliance

lightbulbИерархия

Политика → ревизии → раскатка волнами → назначение, поддерживающее соответствие. audit — «обкатка», enforce — после проверки. Ревизии и раскатки — в GPO-представлении политики («Ревизии»).

Доставка приложений#

Установка ПО — мастер «Доставить на хосты» в карточке приложения (узел «Развертывания»): канареечная раскатка через тот же цикл ревизий (пакет → установка/проверка → хосты → канарейка → запуск). На шаге «Установка и проверка» мастер показывает, какие этапы уже настроены; править их нужно на вкладке карточки — окно мастера вкладку за собой не переключает. На шаге «Безопасность раскатки» в форме указано, как выбирается пробная группа. Доставка приложений использует экспериментальный шаблон: хосты вне коллекций с включёнными испытаниями в предпросмотре отсекаются, привязать такую политику к коллекции без флажка нельзя. Окно мастера не меняет высоту при смене шага. Подробности — «Доставка приложений (end-to-end)».

AI#

AI-возможности: диалоговый мастер шаблонов политик, генерация кода политик по текстовому описанию и AI-предложения для релизов.

Разделы дерева#

Где искать сущности (дерево «Каталог и политики»):

Сущность Где Назначение
Запуски сценариев отдельный узел дерева Шесть вкладок: Требуют внимания, Кампании, Расписания, Прогоны, Соответствие, Правила (см. схему ниже).
Сценарии и скрипты «Групповые политики» Плейбуки .yml и PS-скрипты .ps1 (категории, версии, подпись); кнопка «⚙ Создать через конструктор» — конструктор.
Профили внутри групповой политики Комплект сценариев, выполняемых вместе.
Дистрибутивы и файлы «Развертывания», «Файлы» Папки, ассеты, дистрибутивы — подробнее.
Собранные файлы «Файлы» (артефакты) Собранные прогонами файлы (TTL).
Учётные данные «Секреты» Credentials/Vault (at-rest, write-only).

Узел «Запуски сценариев» — одна цепочка: расписание и правило сами ничего не ставят, в срок или по событию они создают кампанию (запуск политики на группу хостов); прогон — исполнение кампании на одном хосте; соответствие — итог по хосту сейчас; «Требуют внимания» — очередь на решение человека. Подробный разбор каждой вкладки — в руководстве администратора.

Вкладка «Соответствие»#

Узел «Запуски сценариев» → вкладка «Соответствие»: итог по каждому хосту — назначенные политики и статус по каждой. Колонки: Хост, Политики, Статус, Проверено, Последний прогон (ссылка в журнал прогонов). Проблемные хосты сверху; раскрытие строки — статус по каждой политике, одна упавшая проверка не схлопывает весь результат.

lightbulbЧто считать «соответствием»

«Соответствует» = последний проверочный прогон прошёл без расхождений. Это «проходит конкретный профиль», а не «безопасен вообще» — комбинируйте профили (EDR + AV + sshd + sysctl).

Вкладка «Прогоны»#

Журнал исполнения на хостах — точка входа для разбора инцидента на конкретной машине. Колонки: ID, Хост, Сценарий, Статус, Режим, Длительность, Начато, Кем, Кампания, Расписание (последние две — ссылки на те же объекты). По умолчанию журнал сгруппирован по хостам, переключатель «Списком» возвращает плоский вид.

Детали прогона#

Сводка и две вкладки: Задачи (модуль, статус, было ли изменение) и Лог (полный вывод; активный прогон обновляется сам). Для неудачных видна первая упавшая задача; кнопки «Скопировать вывод» и «Повторить». Устройство прогона (статусы, аренда, повтор при потере связи) — в руководстве.

Расписания и назначения#

Назначение — желаемое состояние: «политика X должна применяться к аудитории Y». Живёт оно на вкладке «Расписания» узла «Запуски сценариев» (политика, аудитория, режим, интервал, статус, следующий запуск) и в GPO-представлении политики («Область»). Расписание само ничего не ставит: в срок оно создаёт кампанию.

Назначить политику#

В дереве «Каталог и политики» кликните правой кнопкой по коллекции → «Назначить политику» (или кнопка «+» на вкладке «Расписания»). Поля: политика, аудитория, режим — проверка или применение, интервал. Для критичных политик включайте непрерывное поддержание: новый хост аудитории или отключённая служба будут замечены автоматически.

Вкладка «Кампании»#

Кампания — один запуск политики на группу хостов: вручную, по расписанию или по правилу. Колонки: Имя, Политика, Статус, Прогресс, След. шаг, Действия. Ход кампании, согласование и остановка — в руководстве.

Создать кампанию#

Кнопка «+» на вкладке «Кампании»: политика, цели (через пикер, см. ниже), режим — проверка или применение, предел одновременных прогонов, окно запуска.

Пикер целей (хосты/группы/теги)#

Универсальный селектор целей (кампания / расписание / разовый запуск); открывается поверх текущей модалки.

  • Тип целей — группы / теги / хосты; текстовый поиск находит и компьютеры — по имени или IP; «Все найденные» / «Снять» — массовое выделение найденного.
  • Чекбоксы с мета-информацией (группа/тег — число хостов, хост — ОС и IP).
  • Выбранное — отдельным списком справа: лишнюю строку можно убрать прямо оттуда, не разыскивая её в дереве; счётчик «Выбрано: N»; «Готово» — цели попадают в родительскую форму.

Тот же селектор с этими возможностями используется и при назначении ролей.

Жизненный цикл задания#

Кампания создаётся, согласовывается, запускается волнами и завершается (полностью, с частью неудач или отменой); непрерывные кампании продолжают поддерживать соответствие. Подробно — в руководстве.

Запуск сценариев и параметры#

Отдельной сущности «шаблон запуска» больше нет: параметры (режим, цели, переменные) задаются в форме «Запустить» из каталога сценариев или хранятся в расписании — повторяемый запуск настраивается расписанием.

Параметры запуска#

В форме запуска: режим — проверка или применение; цель (по умолчанию — аудитория политики); пользователь для прогона (по умолчанию root; эскалация требует настроенного sudo без пароля); таймаут (при превышении прогон снимается); переменные сценария.

Расписания#

cron-расписание — атрибут назначения (расписания); по наступлению срока создаётся кампания. Формат — 5-полевые cron-выражения (*/5 * * * *, 0 2 * * *) + часовой пояс.

Форма «Запустить»#

Переопределение цели (пусто — аудитория по умолчанию) и ответы на вопросы сценария (если они заданы). Ответы строго типизированы на сервере; строки не интерпретируются как YAML — защита от инъекций в переменные сценария.

Профили политик#

Профиль — комплект сценариев, выполняемых вместе (например, «Базовая ИБ Linux»: EDR + sshd + sysctl + auditd). Настраивается внутри групповой политики; выбирается при назначении и запуске.

Новый профиль#

Состав — чекбоксы по категориям сценариев (видны имя и slug, встроенные — с бейджем); при редактировании выбранные отмечаются сами.

Сценарии и скрипты (Playbook'и)#

Каталог Ansible-плейбуков в разделе «Групповые политики» — ядро функциональности: неизменяемые версии (редактирование не ломает идущие прогоны) + Ed25519-подпись.

Категории#

Каталог группируется по категориям (заголовок группы + счётчик плейбуков); список динамический. Builtin-категории:

Ключ Название Что проверяет/делает
compliance_security Защита (EDR/AV/DLP) СЗИ: пакет установлен + служба enabled+running.
compliance_os Конфигурация ОС Харднинг/конфиг ОС, OVAL-сценарии.
remediation_config Настройка конфигов Приведение конфигов (lineinfile/ini_file/template).
remediation_service Управление службами Установка/перезапуск/включение служб СЗИ.
inventory_facts Сбор фактов Факты/инвентарь (дополняет inventory LSUS).
maintenance Обслуживание Очистка кэша, ротация.

Используются в фильтре каталога, редакторе сценария и выборе в профиль. Управление категориями и редактор — в руководстве.

Builtin-набор#

Builtin-сценарии по умолчанию не сидируются — вместо них шаблоны конструктора политик: сценарий собирается в UI, плейбук сохраняется как custom с round-trip (пересборка не теряет ручные правки). Функциональность прежних 25 builtin-сценариев (EDR/AV/DLP, sshd/sysctl, службы, факты, обслуживание, ввод в домен) перенесена в шаблоны конструктора (таблица соответствия — в руководстве).

Колонки: Имя / slug; Категория; ОС (или «любая»); Режимы check/apply/both; Версия; Источник builtin/custom; Подпись (✓ = Ed25519); Действия — «Открыть», «Запустить» (config.run.operate), «Удалить» (только custom), «Форкнуть» (builtin). Фильтры: поиск по имени, категория, источник (builtin/custom).

Импорт/экспорт#

  • Экспорт — .yml плейбука (slug/категория/version/checksum) или bundle-ZIP (манифест + плейбуки + профили + шаблоны), без секретов (только метаданные Credentials) — для air-gapped-переноса.
  • Импорт — YAML или ZIP с валидацией; конфликты slug: новая версия / переименование / перезапись (только custom); builtin защищён; импортируемое становится custom. Право — config.playbooks.operate.

Узел «Секреты» (учётные данные)#

Хранилище секретов для сценариев: пароли Ansible Vault, секретные переменные.

warningШифрование at-rest

Секреты шифруются перед записью в базу. Открытый текст никогда не возвращается интерфейсом (только имя/тип/дата); агенту секрет передаётся только по TLS и после прогона удаляется; из логов вымарывается.

Колонки: Имя; Тип — пароль Vault или секретные переменные; Создано; Действия — «Удалить». Галочку «Разрешить использование в сценариях (системный пользователь)» у секрета ставит только администратор: она разрешает серверу применять секрет в фоновых сценариях — например, в политике установки клиента (см. Клиент LSUS → Установка) и при подключении по SSH/WinRM.

Новая учётная запись#

Поля: имя; тип; секрет (write-only — не отображается после сохранения).

Сопутствующий компонент: lsus-config-agent#

Выполнение плейбуков на хостах обеспечивает пакет lsus-config-agent — systemd-сервис (по образцу lsus-usb-control), наследующий server_url и токен из конфигов lsus-client. Агент сам опрашивает сервер (pull), проверяет Ed25519-подпись и SHA-256 каждого playbook, запускает ansible-playbook -c local через встроенный self-contained venv и отправляет результат. Windows-движок проверок (без Ansible) — в планах; детали — на странице lsus-config-agent (Linux).

Роли и права (RBAC)#

Вкладка и её действия защищены permission-ключами:

Ключ Что даёт Кому выдавать
config.view Доступ к вкладке (просмотр). Всем администраторам ИБ.
config.playbooks.operate Плейбуки и профили: создание/редактирование/импорт/экспорт. Разработчикам плейбуков.
config.templates.operate Формы запуска сценариев и расписания. Старшим администраторам.
config.run.operate Запуск плейбуков/профилей/шаблонов; назначения и задания. Операторам.
config.credentials.operate Управление Credentials/Vault. Самый узкий круг — автоматически не грантится.
config.assets.operate «Раздаваемые файлы»: папки, ассеты, дистрибутивы, привязка к плейбукам, доставка артефактов (история — по config.view). Администраторам контента.

Роли admin/edge_admin получают config.view/playbooks.operate/templates.operate/run.operate/assets.operate автоматически; config.credentials.operate — вручную через редактор ролей. Мутации логируются в аудит; failed/unreachable-прогоны — security-события (видны в SIEM при настроенном экспорте).

Связанные страницы#