Конфигурации
Раздел «Каталог и политики» → «Групповые политики» — управление соответствием хостов политикам информационной безопасности через локально запускаемый Ansible на клиентах. Универсальный «солдат» для проверки и приведения в соответствие: EDR/антивирус/DLP, харднинг ОС, OVAL-ремедиации, любые конфиги и службы.
Раздел доступен только если у администратора есть право config.view. Появляется в дашборде Master после установки на клиенты отдельного пакета lsus-config-agent (поставляется со встроенным self-contained Ansible, без необходимости тянуть ansible из репозиториев ОС).
Зачем нужна эта вкладка¶
LSUS уже умеет управлять обновлениями (кампании Linux/Windows) и USB-контролем. Но между патчами и USB остаётся обширный класс задач ИБ, которые требуют проверки состояния конфигурации и его исправления:
- Установлен ли EDR (bi.zone), антивирус (Kaspersky KES), DLP (Staffcop), запущены ли их службы?
- Соответствует ли
sshd_configстандарту (PermitRootLogin no, PasswordAuthentication no и т.п.)? - Применены ли безопасные параметры ядра (
sysctl)? - Настроены ли firewall/auditd/NTP?
Раньше для этого нужен был отдельный инструмент (Ansible AWX, Tower, самописные скрипты). «Конфигурации» закрывают эту потребность внутри LSUS — единый UI, общая модель хостов/групп/тегов, аудит, роли, та же инфраструктура репозиториев.
Как это работает — общая схема¶
Ключевые свойства¶
- Pull-модель — агент сам опрашивает сервер (
GET /api/v1/clients/ansible/runs/pending), никаких входящих SSH/портов на клиенте открывать не нужно. Тот же Bearer-токен, что уlsus-client. - Локальный Ansible —
ansible-playbook -c localзапускается на самом клиенте, без SSH-push с сервера. Пакетlsus-config-agentпоставляется со встроенным venv (15 wheels, ~12 МБ), не требует интернета и установкиansibleиз ОС. - Ed25519-подпись версий — каждый playbook подписывается приватным ключом сервера; агент обязательно проверяет подпись перед выполнением. Защищает от подмены контента (RCE от root — главный риск).
- Версионирование — контент playbook'а хранится в immutable
config_playbook_versions; редактирование создаёт новую версию. Идущие прогоны ссылаются на конкретную версию — редактирование их не ломает. - Антишторм — раскатка батчами с
throttle/jitter, lease на выполнение, экспоненциальный backoff на агенте.
Релизы, раскатки, назначения¶
Групповые политики используют релизную модель (GPO-стиль) — как в MS Group Policy Management. Это безопаснее, чем править «живую» политику: изменения готовятся, проверяются и выкатываются постепенно.
| Сущность | Что это | Аналог |
|---|---|---|
| Ревизия (release) | Самоверсионируемый неизменяемый снимок политики. Жизненный цикл: draft → validated → approved → retired. Можно безопасно готовить изменения и откатываться к проверенной ревизии. |
Version-контроль GPO |
| Раскатка (rollout) | Плановое применение релиза волнами хостов с фазами precheck → apply → verify. Удобно для осторожного выкатывания крупных изменений. |
Controlled rollout |
| Назначение (assignment) | Долгоживущая привязка политики к аудитории в режимах audit (только проверка) или enforce (применение). Поддерживает непрерывное поддержание соответствия. |
Linked GPO + enforcement |
| Compliance-расписание | Непрерывный precheck соответствия: система сама регулярно проверяет, что хосты отвечают требованиям назначенной политики. | Continuous compliance |
Режимы назначения: audit vs enforce
audit— политика только проверяется (precheck), ничего не меняет на хостах. Безопасно для «обкатки».enforce— найденные расхождения применяются. Включайте после того, как убедились в режимеaudit.
Иерархия
Политика → её ревизии (release) → раскатка (rollout) конкретной ревизии волнами → назначение (assignment), постоянно поддерживающее соответствие на аудитории. Ревизии и раскатки видны в GPO-представлении политики на вкладке «Ревизии» в дереве «Каталог и политики».
Доставка приложений¶
Для установки ПО используется мастер «Доставить на хосты» в карточке приложения (узел «Развертывания») — канареечная раскатка дистрибутивов через тот же release-жизненный цикл, что и у политик: пакет → установка/проверка → хосты → канарейка → запуск. Это рекомендуемый путь для доставки ПО (подробности — в разделе «Доставка приложений (end-to-end)» ниже).
AI¶
Доступны AI-возможности: диалоговый мастер шаблонов политик, генерация кода политик по текстовому описанию и AI-предложения для релизов и раскаток (подробнее — AI-стек).
Разделы дерева¶
Сущности конфигураций разнесены по узлам дерева вкладки «Каталог и политики» (см. Каталог и политики). В таблице ниже — где их искать:
| Сущность | Узел дерева «Каталог и политики» | Назначение |
|---|---|---|
| Соответствие | карточка групповой политики / коллекции | Сводная таблица: какие хосты «в норме», какие нет, по каким профилям. |
| Запуски | карточка групповой политики | История всех прогонов playbook'ов со статусами, логами, per-task детализацией. |
| Назначения | GPO-представление → «Область (Scope)» | Долгоживущая привязка политики к аудитории (см. «Назначения (assignments)» ниже). |
| Задания | карточка релиза/раскатки | Оркестрованные массовые прогоны с throttle/окном/continuous — через rollout-волны. |
| Шаблоны | «Групповые политики» → templates/scripts | AWX-style Job Templates (переиспользуемая конфигурация запуска). |
| Профили | внутри групповой политики | Группировка playbook'ов в комплект проверок. |
| Сценарии и скрипты | «Групповые политики» → scripts | Каталог Ansible-плейбуков (.yml) и PowerShell-скриптов (.ps1) с категориями, тегами, версионированием. Здесь же кнопка «⚙ Создать через конструктор» (модалка ADMX-подобного конструктора). |
| Дистрибутивы и файлы | «Развертывания» и «Файлы» | Файловый менеджер: папки, отдельные файлы-ассеты (доставляются на хост) и дистрибутивы-учётные единицы (карточка + 1..N файлов для установки ПО). |
| Собранные файлы | «Файлы» (артефакты) | Артефакты, собранные с хостов прогонами (логи, отчёты), с TTL и опциональной доставкой во внешние системы. |
| Учётные данные | «Секреты» | Credentials/Vault (шифрование at-rest, write-only). |
Подвкладка «Соответстви延
Главная «карта состояния» парка по политикам ИБ. Показывает, для каждого управляемого хоста: какие профили на него назначены и какой статус по каждому.
Колонки таблицы¶
- Хост — hostname; рядом индикатор
(offline), если хост давно не посылал heartbeat. - ОС —
os_nameхоста (Debian, RedOS, Astra, ALT, Ubuntu и т.д.). - Статус — «худший» статус по всем назначенным профилям:
- Соответствует (successful) — все проверки пройдены.
- Изменено (changed) — при apply-режиме что-то поменялось.
- Не соответствует (failed) — проверки упали.
- Ошибка (error) — ошибка выполнения/агента.
- Профили/назначения — список статусов по каждому профилю с тултипом
failed:N, changed:N. - Последняя проверка — время последнего прогона.
- Действия — кнопка «Проверить» (запускает check-прогоны для этого хоста по всем назначениям).
Фильтры и действия¶
- Поиск по hostname — текстовый.
- Фильтр по статусу — Все / Соответствует / Не соответствует / Изменено / Ошибка.
- «Запустить проверки» — массовое действие: запустить check-прогоны по всем активным назначениям (с правом
config.run.operate).
Что считать «соответствием»
«Соответствует» = последний check-прогон вернул successful (т.е. ни одна assert-задача не упала, служба running+enabled и т.п.). Это не означает, что хост «безопасен вообще» — только что он проходит конкретный профиль. Комбинируйте несколько профилей (EDR + AV + sshd-harden + sysctl) для полной картины.
Подвкладка «Запуск軶
Журнал всех прогонов playbook'ов — аналог Job списка в AWX. Используется для диагностики и разбора инцидентов.
Колонки таблицы¶
- ID — идентификатор
config_run. - Хост —
host_id(имя видно в деталях). - Playbook/профиль — что запускалось (
pbv#Nдля плейбука-версии,profile#Nдля профиля). - Режим —
checkилиapply. - Статус — AWX-выровненные:
pending(ожидает),claimed(взят агентом),running(выполняется),successful/failed/changed/error/timed_out/canceled. - Recap — сводка
ok:N ch:N fail:N unr:N(changed/unreachable/rescued). - Длительность — в секундах.
- Инициатор — кто/что создал прогон (пользователь,
schedule#N,assignment#N,continuous). - Действия — «Детали».
Фильтры¶
- Статус — быстрый фильтр (например, только failed).
- host_id — отдельный хост.
- Постраничная навигация — 50 записей на страницу.
Модалка «Детали прогона» (configRunDetailModal)¶
Открывается по клику на «Детали». Самый важный экран для диагностики.
Шапка:
- Хост, playbook (slug vN), режим, attempt (N/M).
- Сводка большими цифрами: статус, ok / changed / failed / unreachable / rescued, rc (код возврата ansible-playbook), версия ansible, длительность.
- При failed/error/timed_out — крупное сообщение error_summary (первая упавшая задача + её msg).
Подвкладки внутри модалки:
- Задачи — таблица per-task (config_run_tasks): play, task, модуль, статус (бейдж), changed, msg (обрезан, полный в tooltip). Удобный фильтр «только failed/changed» (визуально по бейджам).
- stdout — человекочитаемый лог прогона (поле stdout_log): классический ansible-default-формат (PLAY [..] / TASK [..] / MSG / PLAY RECAP), read-only, можно скопировать. Это не сырой JSON — агент собирает его из распарсенного callback'а без повторного запуска ansible (см. config-agent).
- сырой вывод ansible (JSON-callback) — отдельная вкладка с сырым JSON-callback из поля report. Отображается только если в результате прогона есть report; предназначена для глубокой отладки и интеграции, повседневная диагностика идёт по человекочитаемому stdout.
- stderr — отдельно, с подсветкой.
Live-прогресс: если прогон ещё активный (pending/claimed/running) — модалка автоматически опрашивает GET /config/runs/<id> каждые 3 секунды и обновляет сводку/задачи. Удобно наблюдать за выполнением в реальном времени.
Кнопки внизу:
- «Скопировать stdout» — копирует человекочитаемый лог (stdout_log) в буфер обмена.
- «Повторить» — создаёт новый прогон с теми же параметрами (только если статус failed/error/timed_out).
Подвкладка «Назначения»¶
Декларативный слой: «профиль X должен применяться к группе Y». В отличие от разовых запусков, назначение — это желаемое состояние, которое автоматически поддерживается.
Назначения (assignments) с режимами audit/enforce
Назначения используют модель assignments с режимами audit (только проверка) и enforce (применение). Это долгоживущая привязка политики к аудитории (коллекции из дерева «Каталог и политики»), видна в GPO-представлении политики на вкладке «Область (Scope)».
Чем это отличается от задания¶
- Назначение — постоянная связь «профиль ↔ цель». Worker периодически перепроверяет состояние, особенно при
continuous=true: новые хосты, попавшие в группу/тег, автоматически наследуют проверку. - Задание — конкретный управляемый массовый прогон «здесь и сейчас» (или по расписанию).
Колонки таблицы¶
- Имя — название назначения.
- Сценарий —
profile#Nилиtmpl#N. - Цель —
group:N,tag:Nилиhost:N. - Режим —
checkилиapply. - Охват (хостов) — сколько хостов попадает в цель на текущий момент.
- Continuous — флаг автонаследования новыми хостами.
- Вкл — включено/выключено.
- Последний запуск — когда worker последний раз ставил прогоны.
- Действия — «Вкл/Выкл», «Удалить».
Модалка «Назначить сценарий» (configAssignmentModal)¶
- Имя назначения — человекочитаемое.
- Профиль — выбор из списка существующих.
- Цель — тип — Группа / Тег / Хост.
- ID цели — числовой ID группы/тега/хоста (видно в соответствующих разделах LSUS).
- Режим — check (только проверка) или apply (применять изменения).
- Continuous — если включено, worker будет регулярно перепроверять и создавать прогоны для failed/changed и для новых хостов в цели.
Когда использовать continuous
Включайте continuous для критичных политик ИБ (например, «EDR bi.zone должен быть установлен и запущен на всех серверах»). Тогда при появлении нового хоста в группе или при случайном отключении службы LSUS автоматически заметит и сообщит об отклонении.
Подвкладка «Задания»¶
Оркестрованные массовые прогоны — аналог install-кампаний LSUS для обновлений, но для Ansible-плейбуков. В кодовой базе и API эта сущность называется campaign (для совместимости с терминологией обновлений LSUS), в интерфейсе — «задание».
Колонки таблицы¶
- Имя задания.
- Сценарий (профиль/шаблон).
- Режим (check/apply).
- Статус —
pending,dispatching,running,partial,completed,failed,canceled. - Прогресс —
N (successful:X, failed:Y, ...)поconfig_runs. - Throttle — сколько прогонов одновременно in-flight.
- Действия — «Запустить» (повторный dispatch), «Отменить» (отменяет pending-прогоны).
Модалка «Новое задание» (configCampaignModal)¶
Модалка с поясняющей плашкой «Что такое задание?» (раскрывающийся блок <details>).
- Имя задания.
- Профиль — выбор из списка.
- Цели — выбор через пикер (кнопка «Выбрать…»), а не ручной ввод ID. См. Пикер целей ниже.
- Режим — Проверка (check) или Применение (apply).
- Throttle — максимум одновременно выполняющихся прогонов (анти-шторм).
- «Создать и запустить» — сразу создаёт задание и запускает диспетчеризацию.
Пикер целей (хосты/группы/теги)¶
Универсальный селектор целей для модалок: задание / разовый запуск / назначение. Открывается отдельной модалкой поверх текущей (configTargetPickerModal), по образцу мастера кампаний Linux/Windows в LSUS.
- Тип целей — Группы / Теги / Хосты (переключатель).
- Поиск — текстовый фильтр по имени.
- «Все найденные» / «Снять» — массовое выделение/снятие.
- Список чекбоксов — каждый пункт с именем и краткой мета-информацией (для группы — число хостов, для хоста — ОС и IP, для тега — число хостов).
- «Выбрано: N» — счётчик.
- «Готово» — подтверждение; выбранные ID попадают в родительскую модалку, в строке «Цели» появляется summary: «N выбрано: <имя1>, <имя2>, …».
Данные подгружаются из /api/v1/groups/, /api/v1/host-tags, /api/v1/admin/hosts (с лимитом 2000). Кешируются на стороне браузера, повторных запросов при переключении типа нет.
Для назначения выбирается ровно одна цель (singular); для задания/разового запуска — множество.
Жизненный цикл задания¶
rejected-KB в непрерывных кампаниях
Задания конфигураций используют тот же движок campaign, что и кампании обновлений. Непрерывные кампании (auto-continue) корректно исключают rejected KB на Windows — отклонённые администратором обновления один раз исключаются и в дальнейшие батчи не возвращаются, пустые батчи со статусом completed_in_compliance не плодятся. Поведение распространяется и на задания конфигураций с continuous=true, поскольку они разделяют единый планировщик батчей.
Подвкладка «Шаблоны» (Job Templates)¶
AWX-style шаблон запуска — переиспользуемая конфигурация: «playbook X + такие-то extra_vars + такой-то режим + такая-то цель». Запускается одной кнопкой, без повторного ввода параметров.
Колонки таблицы¶
- Имя шаблона.
- Playbook/профиль.
- Режим — check/apply/ask (спрашивать при запуске).
- Цель по умолчанию — JSON с host/group/tag.
- Расписание —
cron-выражение, если задано. - Run as / Become — пользователь запуска и флаг эскалации.
- Действия — «Запустить» (Launch), «Удалить».
Модалка «Новый шаблон» (configTemplateModal)¶
- Имя.
- Playbook или Профиль (один из двух).
- Режим — check / apply / ask.
- Run as user — от чьего имени запускать плейбук (по умолчанию
root). - Таймаут — секунды; при превышении процесс
ansible-playbookбудет убит, прогон перейдёт вtimed_out. - become — эскалация привилегий внутри плейбука (требует NOPASSWD sudo на клиенте).
- extra_vars — JSON переменных по умолчанию.
Расписания¶
cron-расписание — это атрибут назначения (config_assignments.cron), а не отдельная сущность у шаблона. Worker task_config_assignments каждую минуту проверяет наступившие расписания и создаёт прогоны. Поддерживаются стандартные 5-полевые cron-выражения (*/5 * * * *, 0 2 * * * и т.п.) + IANA timezone.
Запуск шаблона (launch_template)¶
При нажатии «Запустить» открывается форма (в будущих версиях — Survey):
- Переопределение цели (если пусто — используется default_target).
- Survey-ответы (если в шаблоне задан survey_spec).
Survey строго типизирован на сервере: ответы приводятся к объявленным типам (integer/float/choice/multiselect/password/text). Строки не интерпретируются как YAML — защита от инъекций в extra_vars.
Подвкладка «Профил軶
Профиль — комплект playbook'ов, выполняемых вместе как одна проверка. Например, профиль «Базовая ИБ Linux» может включать: проверку EDR + проверку sshd + проверку sysctl + проверку auditd.
Колонки таблицы¶
- Имя профиля.
- Состав — количество playbook'ов.
- Действия — «Изменить», «Удалить».
Модалка «Новый профиль» (configProfileModal)¶
- Имя.
- Состав: playbook'и — выбор через чекбоксы, сгруппированный по категориям. Список плейбуков подгружается автоматически; можно отметить нужные галочками. Имя/Slug каждого видны, builtin-плейбуки помечены бейджем «builtin».
В режиме редактирования ранее выбранные playbook'и автоматически отмечаются.
Профиль vs шаблон
- Профиль — это только набор playbook'ов, без параметров запуска. Используется как «комплект».
- Шаблон — это профиль + параметры (режим, цель, extra_vars, расписание). То, что запускается кнопкой.
- Можно запускать профиль напрямую (разовый запуск / назначение / задание) без шаблона.
Подвкладка «Playbook'軶
Каталог Ansible-плейбуков — ядро функциональности. Хранится в БД с версионированием и Ed25519-подписью.
Категории¶
Каталог плейбуков древовидно группируется по категориям — каждая категория выводится как «заголовок группы» (серая строка с названием и счётчиком плейбуков), под ней строки плейбуков этой категории. Это упрощает навигацию по большому парку плейбуков.
Список категорий динамический — хранится в таблице config_categories (миграция 127). Встроенные (builtin) 6 категорий:
| Ключ | Название | Что проверяет/делает |
|---|---|---|
compliance_security |
Защита (EDR/AV/DLP) | СЗИ: EDR, антивирус, DLP — пакет установлен + служба enabled+running. |
compliance_os |
Конфигурация ОС | Харднинг/конфиг ОС, OVAL-сценарии. |
remediation_config |
Настройка конфигов | Приведение конфигов в соответствие (lineinfile/ini_file/template). |
remediation_service |
Управление службами | Установка/перезапуск/включение служб СЗИ. |
inventory_facts |
Сбор фактов | Сбор фактов/инвентаря (дополняет существующий inventory LSUS). |
maintenance |
Обслуживание | Обслуживание (очистка кэша, ротация). |
Управление категориями¶
Кнопка «Категории…» в шапке подвкладки открывает модалку управления (configCategoriesModal):
- Добавить — ключ (строчные латинские, напр.
compliance_db) + название. - Переименовать — у любой категории можно изменить
label(даже у builtin). - Удалить — только пользовательские (builtin защищены); нельзя удалить, если она используется плейбуками (сначала смените им категорию).
- is_builtin — встроенные помечены бейджем «встр.», их нельзя удалить.
Категории используются в:
- фильтре подвкладки «Playbook'и»;
- селекте категории в модалке редактирования плейбука;
- группировке при выборе плейбуков в модалке профиля (чекбоксами).
Builtin-набор (поставляется «из коробки»)¶
Готовые builtin-сценарии (ConfigPlaybook) по умолчанию не сидируются — вместо этого поставляются ADMX-подобные шаблоны политик конструктора (см. подвкладку «Конструктор политик»). Администратор сам собирает нужный сценарий через UI конструктора, выбирая политики и задавая параметры — готовый плейбук сохраняется как custom с привязкой builder_spec (round-trip: пересборка не теряет ручные правки, см. «Diff при пересборке» ниже).
Раньше (до переноса) существовал фиксированный набор из 25 builtin-сценариев (проверки EDR/AV/DLP, харднинг sshd/sysctl, службы, сбор фактов, обслуживание). Их функциональность перенесена в шаблоны:
| Область | Шаблон конструктора |
|---|---|
| EDR bi.zone / Kaspersky KES / DLP Staffcop / generic «пакет+служба» (Linux) | lsus.linux.security-checks |
| Kaspersky KES / Microsoft Defender / Windows Update (Windows) | lsus.win.security-checks |
| Харднинг sshd | lsus.linux.sshd |
| sysctl-параметры ядра | lsus.linux.sysctl |
| Службы: задать состояние / замаскировать опасные (Linux) | lsus.linux.service |
| Служба Windows: задать состояние | lsus.win.service |
| auditd + NTP, аппаратные/security-факты (Linux) | lsus.linux.security-checks, lsus.linux.facts |
| Сбор фактов ОС / инвентаризация ПО / аудит локальных админов (Windows) | lsus.win.facts |
| Очистка пакетного кэша / ротация journald (Linux) | lsus.linux.maintenance |
| Ввод Linux в домен (AD/Samba/RedADM/FreeIPA/ALD Pro) | lsus.linux.domain-join |
| Очистка диска (Windows) | lsus.win.maintenance |
| UAC / hardening реестра (Windows) | lsus.win.uac, lsus.win.registry |
| Часовой пояс и NTP (Windows) | lsus.win.timezone |
Колонки таблицы¶
- Имя / slug.
- Категория.
- ОС (os_family, или «любая»).
- Режимы — check / apply / both.
- Версия — текущая версия контента.
- Источник —
builtin(жирным) илиcustom. - Подпись — ✓ если версия подписана Ed25519.
- Действия — «Открыть», «Запустить» (с правом
config.run.operate), «Удалить» (только custom), «Форкнуть» (для builtin).
Фильтры¶
- Поиск по имени.
- Категория.
- Источник — builtin / custom.
- Кнопки «Импорт», «Экспорт bundle» (с правом
config.playbooks.operate).
Модалка «Создать/редактировать плейбук» (configPlaybookEditModal)¶
Двухпанельный редактор:
Левая панель — метаданные:
- Имя — человекочитаемое.
- Slug — уникальный идентификатор (строчные латинские, цифры, дефис). По соглашению <category-short>-<target>-<action>, напр. sec-myapp-check.
- Категория (select).
- Теги (через запятую).
- ОС (os_family, или пусто = любая).
- Режимы — check + apply / только check / только apply.
- Описание.
Правая панель — редактор YAML:
- Текстовое поле с моноширинным шрифтом для контента playbook'а.
- Кнопка «Проверить» → серверная валидация (/config/playbooks/validate): YAML-парсинг + структурная схема + при наличии серверного ansible-core venv — ansible-playbook --syntax-check. Ошибки подсвечиваются с номерами строк.
- Кнопка AI — зарезервирована, в этой версии выключена (задел на будущее).
При сохранении:
1. Сервер валидирует YAML.
2. Создаётся новая immutable версия (config_playbook_versions) с SHA-256 checksum.
3. Версия подписывается Ed25519 приватным ключом сервера.
4. current_version_id плейбука переключается на новую версию.
builtin нельзя редактировать
builtin-плейбуки защищены от прямого редактирования (кнопка «Сохранить» вернёт ошибку). Используйте «Форкнуть» — создаст custom-копию с новым slug, которую можно свободно менять.
Модалка «Запустить плейбук» (configPlaybookRunModal)¶
- Режим — check / apply.
- Цель — host_id через запятую.
- Run as user (опц.).
- become (чекбокс).
- extra_vars (JSON).
Импорт/экспорт¶
- Экспорт одного —
GET /config/playbooks/<id>/export→.ymlс заголовком-комментарием (slug, категория, version, checksum). - Экспорт bundle —
GET /config/export→ ZIP:manifest.json+playbooks/*.yml+profiles.json+templates.json. Без секретов (Credentials не выгружаются — только их метаданные). Для переноса между инсталляциями LSUS (air-gapped). - Импорт — модалка
configImportModal, принимает YAML-файл или ZIP-bundle. Перед сохранением — валидация. Конфликты по slug разрешаются: новая версия / переименование / перезапись (только custom). builtin защищён. Импортируемое всегда становитсяsource=custom.
Подвкладка «Учётные данные» (Credentials/Vault)¶
Хранилище секретов для плейбуков: пароли Ansible Vault, секретные переменные.
Шифрование at-rest
Секреты шифруются Fernet по SECRET_KEY сервера перед записью в БД. Plaintext никогда не возвращается в админ-API — список показывает только имя/тип/дату. Расшифрованный секрет передаётся агенту только по TLS и транзиентно (в spec запуска), агент пишет его во временный файл 600 и удаляет в finally. Из stdout/stderr логов секрет redact'ится перед хранением.
Колонки таблицы¶
- Имя.
- Тип —
vault_password(Ansible Vault) илиsecret_vars(JSON). - Создано.
- Действия — «Удалить».
Модалка «Новая учётная запись» (configCredentialModal)¶
- Имя.
- Тип (select).
- Секрет (textarea, write-only — поле ввода, не отображается после сохранения).
Сопутствующий компонент: lsus-config-agent¶
Чтобы вкладка «Конфигурации» действительно выполняла плейбуки на хостах, на Linux-клиентах должен быть установлен отдельный пакет lsus-config-agent. Это самостоятельный systemd-сервис (по образцу lsus-usb-control), который:
- читает
server_urlиapi_tokenиз конфиговlsus-client; - опрашивает
GET /api/v1/clients/ansible/runs/pendingс jitter; - получает spec запуска (playbook + подпись + extra_vars + vault);
- проверяет Ed25519-подпись и SHA-256 checksum перед выполнением;
- запускает
ansible-playbook -c local --check|--becomeчерез встроенный venv; - отправляет прогресс и финальный результат (recap + per-task + человекочитаемый
stdout_log+ сырой JSON-callback вreport+ stderr).
Поставляется со встроенным self-contained Ansible (vendored venv в /var/lib/lsus-config-agent/venv): ansible-core 2.19.11 + ansible.posix + community.general + нативные deps (cryptography, cffi) как manylinux2014 x86_64 wheels (15 wheels, ~12 МБ). Не требует интернета, установки ansible из репозиториев ОС или системных devel-пакетов.
Поддерживаемые ОС (проверено end-to-end)¶
| ОС | Версия | Python | Особенность |
|---|---|---|---|
| RED OS | 8.0.2 | 3.11.11 | — |
| Astra Linux | 1.7.9 | 3.7 → 3.11 | ставится python3.11 из LSUS-репо |
| Astra Linux | 1.8.5 | 3.11.2 | — |
| Ubuntu | 22.04 | 3.10 → 3.11 | ставится python3.11 |
| Ubuntu | 24.04 | 3.12.3 | venv --without-pip + bootstrap |
| ALT Linux | 11.1 | 3.12.7 (glibc 2.38) | — |
| CentOS Stream | 10 | 3.12 | — |
Везде: x86_64, stable ABI cp311-abi3 покрывает Python 3.11 и 3.12 одним набором wheels. Windows-движок проверок — в планах (без Ansible).
Запуск не от root¶
В шаблоне/запуске можно указать run_as_user. Тогда демон (работающий под root) сбрасывает привилегии через runuser -u <user> -- и запускает плейбук от имени этого пользователя. Временные файлы (playbook, vars, vault) создаются с владельцем и правами 600. become=true пробрасывается в Ansible для эскалации внутри плейбука (требует настроенного NOPASSWD sudo на хосте).
become + sudo = root
Запуск не от root не означает «безопасно»: при become=true и наличии NOPASSWD sudo плейбук всё равно эскалирует до root. Используйте run_as_user для принципа наименьших привилегий только там, где эскалация не нужна.
Роли и права (RBAC)¶
Вкладка и её действия защищены пятью permission-ключами:
| Ключ | Что даёт | Кому выдавать |
|---|---|---|
config.view |
Доступ к вкладке (просмотр). | Всем администраторам ИБ. |
config.playbooks.operate |
Создание/редактирование/импорт/экспорт плейбуков и профилей. | Разработчикам плейбуков. |
config.templates.operate |
Управление Job Templates, Surveys, Schedules. | Старшим администраторам. |
config.run.operate |
Запуск плейбуков/профилей/шаблонов; назначения и задания. | Операторам. |
config.credentials.operate |
Управление Credentials/Vault. | Самый узкий круг — автоматически не грантится. |
config.assets.operate |
Файловый менеджер «Раздаваемые файлы»: папки, ассеты (upload версий, подпись), дистрибутивы (карточка + файлы, finalize), привязка к плейбукам, ручная доставка артефактов. История — на чтение по config.view. |
Администраторам контента. |
По умолчанию роли admin/edge_admin получают config.view/playbooks.operate/templates.operate/run.operate/assets.operate автоматически. config.credentials.operate настраивается вручную через редактор ролей.
Все мутации логируются в журнал аудита (config_playbook_create, config_run_create, config_template_launch, config_import, …). События failed/unreachable прогонов эмитятся как security-события (видны в SIEM, если настроен экспорт).
Жизненный цикл прогона (config_run)¶
Статусы config_run (AWX-выровненные)¶
| Статус | Значение |
|---|---|
pending |
Создан, ждёт агента. |
claimed |
Агент забрал (lease активен). |
running |
Выполняется. |
successful |
Завершён без failed/changed. |
changed |
Завершён, что-то изменено (apply-режим). |
failed |
Проверка/применение упали. |
error |
Ошибка агента (нет venv, нет подписи и т.п.). |
timed_out |
Превышён timeout_seconds, процесс убит. |
canceled |
Отменён оператором (только из pending). |
Lease и reclaim¶
Каждый claimed прогон имеет lease_expires_at = claimed_at + timeout + 30 мин. Если агент не отчитался в срок (упал, потерял связь, хост выключили) — worker task_config_lease_reaper возвращает прогон в pending (инкремент attempt). При attempt >= max_attempts (по умолчанию 3) — переводится в timed_out. Это исключает «зависшие» прогоны и дубли выполнения.
Антишторм и устойчивость¶
| Механизм | Где | Что делает |
|---|---|---|
| Throttle + jitter | Campaigns/Assignments в worker | Раскатка батчами, не все разом. |
Retry-After / next_poll_seconds |
GET /runs/pending |
Сервер регулирует частоту опроса. |
| Стаггеринг расписаний | Worker schedules | Расписания на много хостов распределяются по времени. |
Rate-limit /clients/ansible/* |
Сервер | Защита от шторма запросов агента. |
| Один прогон за раз | Агент | Сериализация, нет локальных ресурсных штормов. |
| Экспоненциальный backoff | Агент | При ошибках сети/5xx, уважение Retry-After. |
| Lease + reaper | Worker + DB | Нет «зависших» и дублей. |
Ретенция config_runs |
task_config_runs_cleanup |
Удаление terminal-прогонов старше 90 дней. |
Типичные сценарии¶
1. Проверить, что на всех серверах работает EDR bi.zone¶
- Конструктор политик → «Создать через конструктор»: выбрать Linux → категория «Безопасность и СЗИ» → политика «EDR bi.zone» (шаблон
lsus.linux.security-checks) → задатьedr_package_name/edr_required_services(по умолчаниюbzsenagent/bzsenagent, bzsenedcore) → «Включено» → сохранить как сценарийEDR-check. - Назначения → «Назначить»: профиль с этим сценарием, цель — группа «Серверы Linux», режим
check, Continuous: ✓. - Worker автоматически создаст check-прогоны для всех хостов группы.
- Соответствие — смотрим сводку: какие хосты
successful, какиеfailed. - Клик на failed → «Детали» → виден упавший
assert(«служба bzsenedcore не running»). - Передать в ИБ-отдел список хостов для разбора.
2. Привести sshd в соответствие стандарту (apply)¶
- Конструктор политик → «Создать через конструктор»: Linux → категория «Linux: SSH» → политика «Харднинг sshd» (шаблон
lsus.linux.sshd) → вoptionsзадатьPermitRootLogin=no, PasswordAuthentication=no, Protocol=2(при необходимости добавитьMaxAuthTries=3) → «Включено» → сохранить как сценарий. - Назначения → «Назначить»: режим
ask(спрашивать при запуске), цель — группа «Серверы». - Сначала «Запустить» в режиме
check— посмотреть, сколько хостов отличаются от стандарта. - Затем «Запустить» в режиме
apply—lineinfileприведёт конфиг в соответствие, сvalidate sshd -t(проверка синтаксиса перед сохранением). - В «Запуски» — детали, что именно поменялось (
changed:N). - При необходимости донастроить сценарий вручную — «Открыть в конструкторе» пересоберёт поверх (round-trip), либо редактировать код напрямую (тогда пересборка предупредит diff'ом).
3. Перенос набора плейбуков между инсталляциями LSUS (air-gapped)¶
- На «исходном» Master: «Экспорт bundle» → скачивается
lsus-config-bundle.zip. - На «целевом» Master: «Импорт» → выбрать ZIP → валидация → импорт.
- Проверить, что все плейбуки появились в каталоге (как
custom). - При необходимости — привязать к шаблонам/профилям/назначениям.
Файлы: Windows-контент, ассеты, артефакты (миграция 128)¶
В «Конфигурациях» всё — файлы, просто разного назначения. Различаются
content_type/os_family и род (kind):
| Kind | Где живёт | Что это |
|---|---|---|
| playbook / script | config_playbooks (с content_type=yaml/powershell) |
Исполняемый файл; редактируется в UI («Сценарии и скрипты») |
| asset | config_assets + config_asset_versions |
Файл-нагрузка на хост (сертификат/конфиг); immutable + Ed25519 |
| distribution | config_distributions + config_distribution_versions + config_distribution_files |
Дистрибутив ПО — семейство с версиями: карточка + N версий (immutable-набор файлов, 1..N каждый) |
| artifact | config_run_artifacts |
Собранный агентом с хоста файл (для отдачи наружу) |
Windows-контент (PowerShell)¶
PS-скрипт — это не отдельная сущность, а config_playbooks с
content_type='powershell'. В модалке плейбука выберите тип контента
(YAML / PowerShell) и целевую ОС (os_family=windows). Исполняет
служба конфигураций LsusConfigAgent.exe на Windows-хосте; на Linux такой плейбук
физически не попадёт в очередь благодаря os_family-guard.
Конвенция скрипта:
- Принимает
-Mode {check|apply}(check= dry-run,apply= применить). - В финале выводит в stdout один JSON-блок:
json {"status":"successful|failed|changed", "summary":{"ok":N,"changed":N,"failed":N}, "tasks":[{"name":"...","status":"ok|failed","changed":false,"msg":"..."}]} - Совместимость с PowerShell 4.0 (Windows Server 2012 R2): WMI/
netshвместо
новых cmdlet'ов. extra_varsчитает из$env:LSUS_EXTRA_VARS; собираемые файлы — в
$env:LSUS_ARTIFACTS_DIR.
Builtin-набор Windows-скриптов (6 шт.): проверка Kaspersky/firewall/UAC, сбор
фактов, реестр-хардненинг, состояние службы.
Раздаваемые файлы (файловый менеджер)¶
Подвкладка «Раздаваемые файлы» — трёхзонный файловый менеджер:
- Дерево папок (слева) — иерархия с materialized path (
config_assets.folder - явные узлы в
config_asset_folders). Папки создаются, переименовываются,
перемещаются и удаляются (с подтверждением для непустых). Перетаскивание
файла на папку в дереве перемещает его. - Список файлов (центр) — файлы текущей папки: отдельные ассеты и
дистрибутивы. Мультивыбор + батч-операции (переместить/удалить). Dropzone:
перетащите внешние файлы — каждый станет отдельным ассетом в текущей папке. - Drawer деталей (справа) — вкладки «Метаданные / Версии-файлы / Привязки /
История». История (audit_logs) показывает кто/когда/что загрузил или изменил.
Ассет — immutable-версия файла с Ed25519-подписью (как плейбук, но бинарь).
Привязка к плейбуку (config_playbook_assets) декларирует: какой ассет и куда
положить перед прогоном (dest_path, mode, owner). Агент перед запуском
скачивает ассет, проверяет sha256+подпись и кладёт по пути. Upload версий —
chunked с потоковой склейкой на сервере (прямо на диск, инкрементальный sha256;
без буферизации многогигабайтных файлов в RAM).
Дистрибутив — учётная единица-семейство ПО (Firefox, VLC, …) с карточкой
(издатель/продукт/архитектура/язык/команда установки). Конкретная версия ПО
(152.0.3, 153.0, …) — отдельный immutable-снапшот (config_distribution_versions)
со своим набором файлов (1..N, immutable + Ed25519). Это зеркальный паттерн к
ассетам (config_assets/config_asset_versions): одна карточка, много версий.
Создаётся через мастер «Дистрибутив…»:
- Шаг 1 — карточка-семейство: имя/slug, издатель, продукт, версия ПО, архитектура,
язык, ОС, папка, описание. Модалка сразу показывает 5 карточек этапов
lifecycle (Определение/Предпроверка/Установка/Контроль/Удаление), включая
«Сгенерировать с AI» (ad-hoc черезstaging_tokenиз шага 2). Сразу
создаётся первая draft-версия (version=1), куда пойдут файлы. Правка
метаданных готовой карточки — на вкладке «Обзор» drawer'а; новые версии —
на вкладке «Версии». - Шаг 2 — загрузка файлов версии: несколько файлов или целая папка (через
webkitdirectory, с сохранением относительных путейrel_path) либо DnD.
Крупные файлы — потоковая chunked-загрузка (многоГБ, потоковая склейка на диск
без буферизации в RAM). Дубликатыrel_pathв пределах версии отклоняются.
При добавлении распознаваемого установщика (MSI/EXE/DEB/RPM) автопрофиль
lifecycle подмешивается в карточки этапов пофазно (не перезатирая уже
заполненные вручную этапы). Инспекция файла (POST /distributions/inspect)
также сохраняет копию прочитанного префикса файла и возвращает
staging_token— по нему кнопка «Сгенерировать с AI» на карточке этапа
получает контекст файла ещё до создания дистрибутива. - Finalize версии (по кнопке «Создать» или автоматически по загрузке
файлов) — версия закрывается (статусactive): сервер определяет
dist_type(single_file / archive / folder) и primary-файл (эвристика
setup.exe/*.msi/install*), авто-детектит версию ПО из метаданных
файла (см. ниже). Если lifecycle-контракт не готов (нераспознанный EXE,
архив/папка без известного профиля) — сервер вернёт409, версия останется
draft, а UI вместо ошибки сразу откроет карточку дистрибутива на вкладке
«Установка и проверка»: там нужно донастроить этапы (вручную или AI-генерацией)
и нажать «Завершить и активировать версию». При успешном finalize карточка
переходит вactive, и та же вкладка открывается автоматически — карточки
этапов заполнены автопрофилем, если файл распознан.
Версии дистрибутива (latest / pinned)¶
Карточка хранит указатель current_version_id — latest-версию (ту, что
раздаётся, если в привязке не указано иное). В drawer деталей дистрибутива на
вкладке «Версии» доступны:
- список всех версий (label, статус, число файлов, объём, источник авто-детекта,
бейдж «текущая»); - кнопка «Добавить версию» — создаёт новую draft-версию и сразу переводит в
шаг загрузки файлов (карточку-семейство править не нужно); - кнопка «сделать latest» (promote) — назначает выбранную finalized-версию
current; кнопка finalize для draft-версий прямо из drawer; - файлы выбранной версии (с скачиванием).
Привязка к сценарию («Файлы на хост») для дистрибутива поддерживает два режима:
- latest (по умолчанию) — раздаётся
current-версия; её смена (promote
новой) автоматически подхватывается новыми прогонами без правки привязки; - pinned — фиксируется конкретная версия (
distribution_version_id); для
регламентированных окружений, где нужен точный build.
Авто-детект версии ПО (универсальный)¶
При finalize версии сервер определяет version_label с многоуровневым fallback
(без новых зависимостей):
- Метаданные бинарника — для
.exe/.dll: разбор PE-ресурсаVS_VERSIONINFO
(FileVersion/ProductVersion). Для Firefox/VLC/Chrome даёт точную версию.
Для.msi— ProductVersion из summary info. - Regex имени файла —
\d+(\.\d+){1,3}(напр.vlc-3.0.20-win64.exe) либо
чисто-цифровой build (7z2407→2407). - Ручной ввод в визарде/finalize — всегда побеждает авто-детект.
Источник записывается в detected_from (metadata/filename/manual) и виден
в drawer для диагностики.
Доставка приложений (end-to-end)¶
Рекомендуемый путь для администратора — мастер «Доставить на хосты» в карточке
приложения (вкладка «Обзор»), а не ручная цепочка назначений:
- Загрузка пакета (MSI/EXE/DEB/RPM) и finalize с автопрофилем lifecycle.
- Мастер: пакет → установка/проверка → хосты → канарейка → запуск.
- Prepare идемпотентно создаёт managed playbook, профиль и draft release.
- Согласование ревизии (separation of duties).
- Application rollout с
target_action(install/upgrade/repair/uninstall). - Мониторинг: release → approval → rollout → waves →
config_host_distribution_state.
Настройка этапов lifecycle (карточки + AI)¶
Раньше lifecycle-контракт (detect/check/install/verify/uninstall × Windows/Linux)
редактировался только как сырой JSON на отдельной вкладке — это было тяжело для
администратора и оператора. Теперь основной способ настройки — отдельная вкладка
«Установка и проверка» в карточке приложения (не путать с вкладкой «Обзор» —
там только карточка семейства, версия/пакет и чеклист готовности). Те же самые
карточки этапов (с кнопкой «Сгенерировать с AI») показываются и в модалке
«Новый дистрибутив» ещё до создания записи — см. шаг 1 мастера выше; разница
только в том, что там нет раздельных «Сохранить для версии/базовым» (всё уходит
в lifecycle_defaults вместе при «Создать»), а AI работает в ad-hoc режиме через
временный застейдженный файл. Вкладка «Установка и проверка» сверху вниз показывает:
- «Как это работает» — поток Определение → Предпроверка → Установка →
Контроль, разница между «для версии» и «базовым для всех версий». Установка
и удаление настраиваются только здесь (lifecycle JSON); отдельных полей
install_commandв карточке больше нет. - «Этапы установки и проверки» — секция с разворачиваемыми карточками
этапов:
- каждый этап — отдельная карточка с понятной формой: тумблер
«Этап включён», способ выполнения (powershell/ansible/shell/
package_manager/none), поле со скриптом/командой, коды успеха, таймаут.
Для Windows скрипт — PowerShell. Для Linuxansibleозначает, что скрипт —
настоящий YAML-список задач Ansible (модулиansible.builtin.apt/dnf/
command/…), которые вставляются как есть в собираемый playbook и
исполняются встроенным локальным Ansible агентаlsus-config-agent; коды
успеха для этой ветки не нужны — успех/неуспех этапа определяется тем,
упали задачи или нет.shell/package_manager— по-прежнему bash-команды.
Подсказка под селектором и плейсхолдер поля меняются в зависимости от
выбранного способа выполнения;
- кнопка «Сгенерировать с AI» на карточке — просит AI-ассистента заполнить
только этот этап (модель получает целевую ОС и данные пакета); результат
показывается прямо в карточке с явным указанием способа выполнения
(executor) — для Windows и Linuxshell/package_managerтакже с кодами
успеха (для Linuxansibleкоды успеха не показываются — не применимы),
плюс кнопками «Принять» (подставить в форму) и «Отклонить» —
ничего не сохраняется без ручного подтверждения. Модель проинструктирована
возвращать для Linuxexecutor=ansibleименно YAML-список задач Ansible,
а не bash; если она вернула пустой/нераспознанный executor, UI подставляет
согласованный с ОС вариант (powershellдля Windows,ansibleдля Linux);
- «Сохранить для версии» — изменения применяются только к выбранной версии
(override); «Сделать базовым для всех версий» — меняет сценарий
приложения (defaults), которым пользуются все версии без своего override;
- если AI недоступен или вернул невалидный ответ, для MSI/EXE/DEB/RPM
подставляется детерминированный автопрофиль —
генерация с AI никогда не оставляет этап пустым при распознанном пакете.
Для MSI все Windows-фазы (включаяinstall) намеренно используют executor
powershell: detect/verify/uninstall читают реестр (Get-ItemProperty),
а сама командаmsiexec /i "{{installer_path}}" /qn /norestartпроверяет
код завершения через$LASTEXITCODE— PowerShell исполняет и обычные
команды, поэтому это не ошибка распознавания. Для DEB/RPM автопрофиль —
настоящие задачи Ansible (ansible.builtin.apt/dnf, с fallback через
apt -f install/yum), executoransible— запускает lifecycle-скрипты
как настоящие Ansible-задачи;
- если версия ещёdraft(не прошла finalize, например пакет не распознан
автоматически), в конце секции показывается заметный блок с кнопкой
«Завершить и активировать версию» — после настройки этапов вручную
или через AI её можно активировать прямо здесь, без возврата в мастер. - Кнопка «Экспертный режим (JSON)» — раскрывает свёрнутый по умолчанию блок
с сырым JSON-контрактом (defaults/overrides/итоговый эффективный контракт).
Он показывает то же самое, что и карточки этапов, но предназначен для
точечных правок и просмотра, а не для повседневной настройки.
Дистрибутив привязывается к сценарию так же, как ассет
(config_playbook_assets.distribution_id, опционально distribution_version_id);
Windows .NET-агент получает в claim-спеке файлы резолвнутой версии
(rel_path + подпись + checksum + version_label для диагностики), стримит их
на диск в dest_path, проверяет sha256 и Ed25519; установка/удаление выполняются
сгенерированным playbook по lifecycle-контракту (политика lsus.software.install,
auto_install=false на привязке). Привязка доступна через UI «Файлы на хост»
(переключатель Ассет/Дистрибутив + селектор версии).
Поддержка агентами: Windows .NET-агент (сборка с config-distributions) — полная
(доставка + verify + install, latest/pinned). Linux config-агент пока не поддерживает
дистрибутивы (только обычные ассеты).
Пример E2E (демо-стенд): карточка-семейство «Mozilla Firefox» (os=windows,
lifecycle с этапом install через msiexec) → загрузка установщика 152.0.3
(88 МБ, sha256+Ed25519) → finalize (active, авто-детект версии из PE-метаданных,
версия становится current/latest) → привязка к сценарию из политики
lsus.software.install (dest_path=C:\Deploy\firefox, pinned/latest) →
apply-прогон: агент скачал файл, проверил подпись, playbook выполнил lifecycle
install (rc=0), verify подтвердил версию → Firefox 152.0.3 установлен. Позже:
загрузка версии 153.0 → promote в latest → новые прогоны автоматически ставят
153.0 без правки привязки.
Артефакты (файл с хоста наружу)¶
Скрипт складывает собираемые файлы (отчёты, факты для сторонней системы) в
LSUS_ARTIFACTS_DIR; после прогона агент грузит их на сервер (single-shot /
chunked) в config_run_artifacts. Артефакты:
- read-only, TTL (по умолчанию 7 дней, чистятся воркером по
expires_at); - доступны в модалке прогона (скачать/превью);
- форвардятся во внешнюю систему через integration-gateway (эпик внешних
интеграций) —target_provider_id. Пока gateway не подключён — хранятся
инертно, доступ через API/UI.
Конструктор политик (ADMX-подобные шаблоны)¶
Графический конструктор конфигураций по образцу ADMX/ADML (Windows GPO),
адаптированный под LSUS: вместо записи в реестр он генерирует YAML (Ansible)
или PowerShell скрипт. Единица сохранения — обычный ConfigPlaybook (попадает в
«Сценарии и скрипты» с бейджем ⚙ конструктор), поэтому к нему применимы все
существующие механизмы (версионирование, Ed25519-подпись, назначения, запуски).
Конструктор — это хелпер создания сценария/скрипта, поэтому открывается
модальным окном (не отдельной подвкладкой):
- кнопка «⚙ Создать через конструктор» на подвкладке «Сценарии и скрипты»;
- пункт «Открыть в конструкторе» в контекстном меню сценария, созданного
конструктором (round-trip пересборка).
Принцип работы¶
- Выберите целевую ОС (Windows → PowerShell, Linux → YAML) и найдите политику в
дереве «категория → политика» слева. - Задайте состояние триады: Not Configured (политика выключена), Enabled
(привести к целевому состоянию) или Disabled (обратное действие, если автор
шаблона его задал). - Заполните параметры (элементы): строки, списки, ключ=значение, пути, выбор
дистрибутива и т.п. - Живое превью внизу показывает сгенерированный код и строку доставки
(какие дистрибутивы будут доставлены на хост). - «Сохранить как сценарий» создаёт
ConfigPlaybookсо спецификацией сборки
(builder_spec).
Виды политик¶
- action — эмитит фрагмент кода напрямую (служба, реестр, sysctl, UAC);
- contribution — вкладывает значения в общий артефакт (напр.
policies.json
Firefox), который доставляется один раз; кросс-ОС: один и тот же артефакт под
Windows/Linux разными путями; - resource — объявляет привязку-ресурс: дистрибутив доставляется на хост
(deliver-only), а скрипт ставит/удаляет ПО. Используется для установки ПО.
Встроенные типовые политики¶
Поставляются builtin-шаблоны (видны сразу в дереве конструктора):
Windows:
- Служба (lsus.win.service) — состояние и тип запуска службы.
- Значение реестра (lsus.win.registry) — задать/удалить значение (hive, ключ, тип).
- Брандмауэр (lsus.win.firewall) — вкл/выкл профили Domain/Private/Public.
- Microsoft Defender (lsus.win.defender) — защита в реальном времени (RTP) вкл/выкл.
- Часовой пояс и NTP (lsus.win.timezone) — TZ + служба w32time + ресинхронизация.
- UAC (lsus.win.uac) — EnableLUA.
Linux:
- Службы (lsus.linux.service) — служба running+enabled / stopped+disabled; маскирование опасных служб (telnet/rsh/rlogin/tftp/rpcbind и др.).
- sysctl (lsus.linux.sysctl) — параметры ядра (ключ=значение).
- Хардненинг sshd (lsus.linux.sshd) — параметры sshd_config с валидацией sshd -t.
- Пакеты (lsus.linux.package) — установка (present) / удаление (absent).
- Ввод в домен (lsus.linux.domain-join) — после агента: AD/Samba/RedADM (realm/net ads) и FreeIPA/ALD Pro; пароль — ConfigCredential, не kickstart. См. PXE.
Кросс-ОС:
- Firefox (lsus.app.firefox) — policies.json (contribution), доставка win/linux.
- Установка/удаление ПО (lsus.software.install) — из «Дистрибутивов и файлов».
Установка/удаление ПО из «Дистрибутивов и файло⻶
Политика «Установить / удалить приложение» (шаблон lsus.software.install):
берёт дистрибутив из «Дистрибутивов и файлов», доставляет его на хост
(только файлы, auto_install=false) и устанавливает (Enabled) или удаляет
(Disabled). На Windows использует install_command/uninstall_command
карточки или msiexec/exe; на Linux — apt/dnf/package. Установка делается
скриптом единообразно для обеих ОС — это делает процесс очевидным и доступным
через графический интерфейс.
Расширяемость и кастомные шаблоны¶
- Builtin-шаблоны поставляются вместе с сервером и доступны сразу после установки.
- Кастомные загружаются через UI — кнопка «Управление шаблонами…» в
тулбаре конструктора (правоconfig.builder.operate): импорт.zip-bundle,
список builtin/custom, экспорт (в т.ч. builtin — для клонирования),
включение/выключение, довериеui.js, удаление custom. Эквивалент API:
POST /config/policy-templates/import(ziptemplate.yml+strings/*.yml+
опц.ui.js). Формат bundle и JS-SDK описаны в документации шаблонов. - Опциональный
ui.js— кастомные виджеты/валидация полей в UI
(window.LsusBuilder.registerPlugin). Для builtin — доверенный; для custom по
умолчанию выключен (риск XSS), включается флагомtrustedотдельно.
Гибридный round-trip¶
Сохранённый сценарий хранит builder_spec (выбранные политики + параметры) и
builder_generated_hash (sha256 сгенерированного контента). В списке сценариев:
- ⚙ — создано конструктором, пересборка безопасна;
- ⚙✎ — контент изменён вручную: при «Открыть в конструкторе» и пересборке
показывается подтверждение перезаписи.
Связанные страницы¶
- Каталог и политики — единое AD-подобное дерево: узлы «Групповые политики», «Развертывания», «Файлы», «Сертификаты», «Секреты».
- Обновление системы — релизная модель политик, доставка приложений, AI-мастер шаблонов.
- Быстрый старт — установка Master/клиентов.
- Установка и развёртывание (Docker) — сборка и релиз.
- Хосты — инвентаризация, коллекции, теги (используются в назначениях).
- Linux — linux-кампании обновлений (аналог заданий конфигураций для пакетов).
- OVAL/MSRC — server-side compliance по пакетам (дополняет Ansible-проверки).
- Администрирование — роли и права (
config.*). - Список доступов (RBAC) — детальный каталог прав.