148 lines
8.1 KiB
Markdown
148 lines
8.1 KiB
Markdown
# Коммерческие модули DetMir
|
|
|
|
DetMir / AWatch-rus коммерчески правильнее подавать как платформу
|
|
операционного контроля с тремя прикладными модулями. Первый модуль - Workforce:
|
|
он дает ежедневную бизнес-ценность владельцу и руководителю. Security и
|
|
Forensics усиливают продукт, но не должны перетягивать позиционирование в
|
|
сторону сертифицированной DLP/SIEM/СЗИ.
|
|
|
|
## DetMir Workforce
|
|
|
|
Для владельца, директора, руководителя подразделения и операционного менеджера.
|
|
|
|
Показывает:
|
|
|
|
- кто реально работал в рабочем окне;
|
|
- кто перегружен, простаивает или выпадает из нормального профиля активности;
|
|
- сколько времени команда проводит в RDP, 1С и рабочих приложениях;
|
|
- какие приложения и процессы забирают рабочее время;
|
|
- как меняется загрузка сотрудников и подразделений;
|
|
- где тормозят бизнес-процессы.
|
|
|
|
Основные KPI:
|
|
|
|
- индекс активности: proxy `активное время / плановое рабочее время`;
|
|
- взвешенная активность: только при настроенной role/application policy;
|
|
- сравнение подразделений за текущий день;
|
|
- сравнение ответственных/владельцев процессов за текущий день;
|
|
- статус тренда: `daily_only`, `weekly_ready` или `monthly_ready`;
|
|
- активное время;
|
|
- простой;
|
|
- число рабочих сессий;
|
|
- активные приложения;
|
|
- документы/операции 1С при наличии связанного бизнес-слоя.
|
|
|
|
Важно: термин "полезная активность" нельзя использовать для простого proxy по
|
|
времени. Он допустим только для будущего/настроенного слоя, где приложения
|
|
взвешены по ролям: например, для бухгалтера `1C` имеет высокий вес, а для
|
|
маркетолога браузер и соцсети могут быть частью рабочей активности.
|
|
|
|
### Настройка весов приложений
|
|
|
|
Публичный пример:
|
|
|
|
- `configs/detmir-workforce-policy.example.json`
|
|
|
|
Runtime-файл на сервере портала:
|
|
|
|
- `/etc/detmir-portal-workforce-policy.json`
|
|
|
|
Правило:
|
|
|
|
- `default_role` задает роль для агрегированного отчета;
|
|
- `planned_hours_per_day` задает плановый рабочий день для роли;
|
|
- `default_weight` применяется к приложениям без явного правила;
|
|
- `application_weights` задает веса приложений по подстроке имени.
|
|
|
|
Пример логики:
|
|
|
|
- бухгалтер: `1C = 1.0`, `Excel = 0.9`, `YouTube = 0.0`;
|
|
- продажи: `CRM = 1.0`, `browser = 0.8`, `mail = 0.8`;
|
|
- разработчик: `IDE/code = 1.0`, `terminal = 0.9`, `browser = 0.7`.
|
|
|
|
После изменения runtime-файла нужно перезапустить портал:
|
|
|
|
```bash
|
|
sudo systemctl restart detmir-portal.service
|
|
```
|
|
|
|
Если policy-файл отсутствует, портал показывает только нейтральный
|
|
`Индекс активности`. `Взвешенная активность` появляется только после настройки
|
|
role/application policy.
|
|
|
|
### Сравнение подразделений и тренды
|
|
|
|
Портал использует validated management snapshot из Worktime API и показывает:
|
|
|
|
- подразделения: coverage, активные пользователи, суммарное активное время;
|
|
- ответственных/владельцев процессов: coverage, активные пользователи,
|
|
суммарное активное время;
|
|
- статус тренда по числу накопленных daily points.
|
|
|
|
Worktime API сохраняет daily history как агрегированные trend-points, без
|
|
полных строк сотрудников и без evidence. Runtime-настройки:
|
|
|
|
- `AW_WORKTIME_MANAGEMENT_HISTORY_DIR`;
|
|
- `AW_WORKTIME_MANAGEMENT_HISTORY_DAYS`;
|
|
- `AW_WORKTIME_MANAGEMENT_HISTORY_RETENTION_DAYS`.
|
|
|
|
Правило честной интерпретации:
|
|
|
|
- `daily_only` - есть только оперативный дневной срез, месячные выводы делать
|
|
нельзя;
|
|
- `weekly_ready` - накоплено достаточно точек для недельного сравнения;
|
|
- `monthly_ready` - накоплено достаточно точек для месячного отчета владельцу.
|
|
|
|
Месячный отчет должен строиться только после накопления daily history. Если
|
|
история содержит один день, интерфейс обязан показывать дневной срез, а не
|
|
выдавать его за тренд месяца.
|
|
|
|
Корректная формулировка для продажи:
|
|
|
|
> DetMir помогает руководителю видеть загрузку сотрудников и бизнес-процессов
|
|
> без ручного просмотра логов и без подмены управленческой оценки простым
|
|
> учетом "сидел за компьютером".
|
|
|
|
## DetMir Security
|
|
|
|
Для ИБ, администратора и оператора расследований.
|
|
|
|
Показывает:
|
|
|
|
- DLP-сигналы: буфер обмена, печать, USB, файловые операции;
|
|
- severity/status технических сигналов;
|
|
- очередь DLP/case review;
|
|
- evidence metadata и доступные скриншоты;
|
|
- audit просмотра evidence и действий оператора.
|
|
|
|
В публичных и коммерческих материалах важно говорить аккуратно:
|
|
|
|
- `detections/cases` - это derived detections/cases;
|
|
- подтвержденным инцидентом событие становится после регламентной валидации;
|
|
- продукт не заявляется как сертифицированная DLP/SIEM/EDR/XDR/СЗИ.
|
|
|
|
## DetMir Forensics
|
|
|
|
Для разбора сложных событий и пост-инцидентной аналитики.
|
|
|
|
Показывает:
|
|
|
|
- цепочку событий ActivityWatch;
|
|
- Hayabusa/offline evidence workflow;
|
|
- связь технических сигналов, кейсов и артефактов;
|
|
- audit trail просмотра и обработки материалов;
|
|
- экспортируемые материалы для внутреннего расследования.
|
|
|
|
## Приоритет в демонстрации
|
|
|
|
Порядок показа владельцу бизнеса:
|
|
|
|
1. Workforce: индекс активности, загрузка, RDP/1С, рабочие приложения.
|
|
2. Commercial reports: ежедневный срез, KPI, Markdown/HTML отчет.
|
|
3. Security: DLP-сигналы и evidence.
|
|
4. Forensics: цепочка расследования, Hayabusa, кейсы.
|
|
5. Reliability: автономность, health-check, SLO, Grafana freshness.
|
|
|
|
Такой порядок снижает сопротивление вокруг темы "слежки" и переводит разговор
|
|
в плоскость эффективности, управляемости и доказуемой операционной картины.
|