FAQ для IT-администраторов

Ответы на типовые вопросы заказчиков и их айтишников. Для установки и диагностики см. отдельные документы — installation-onprem.md и troubleshooting.md.

Содержание

1. Платформы и возможности
2. Marketplace и приложения
3. Лицензирование и тарифы
4. Соответствие требованиям
5. Администрирование tenant
6. Интеграции
7. Безопасность и доступ
8. Эксплуатация

1. Платформы и возможности

1.1. Можно ли enroll iPhone?

Пока нет. iOS/macOS MDM (Apple School Manager / Business Manager + APNs + Vendor ID $299/год) запланирован на milestone M41, Q3 2026. К тому моменту потребуется: - юрлицо с подтверждённой регистрацией - Apple Developer Enterprise account - DeviceCheck-интеграция для anti-cloning

На пилоте Триола (Q2 2026) iPhone не управляются через Комендант. Если в парке есть iPhone — сейчас они работают в режиме «нет контроля» (BYOD), после релиза M41 автоматически мигрируют.

1.2. Какие Android-версии поддерживаются?

AOSP без GMS (Urovo, Atol, Chainway) — полная поддержка, MQTT вместо FCM для push.

1.3. Что с Windows и macOS?

• Windows — Linux DPC через WS-Trust запланирован на M11.1. Управление через Intune-style profile (registry, BitLocker, Defender). ETA: Q3 2026.
• macOS — через тот же Apple MDM stack что и iOS, M41.
• Linux — desktop DPC (Ubuntu, Astra Linux, Alt Linux, RedOS) через M11.5, есть бета. TPM-attestation + MQTT.
• Аврора ОС — M11.4, есть прототип.

Для пилота Триола основной фокус — Android (ТСД, смартфоны ТП, планшеты мерчендайзеров).

1.4. Есть ли мобильное приложение для администратора?

Да, Комендант Admin (Android + iOS) — разрабатывается локально, релиз M17. Функционал: - push-уведомления о критических алёртах - быстрый lost-mode / wipe - просмотр онлайна парка - утверждение app-install requests

Не предназначен как полная замена admin UI — это «IT-support в поле» для быстрых действий с телефона.

1.5. Сколько устройств может вести один tenant?

Лимит из лицензии. Технически tested до 10 000 устройств на один инстанс. Для > 2000 устройств рекомендуется: - multi-node HA кластер (M13.1) - отдельный EMQX в cluster-mode (минимум 3 ноды) - read-replica PostgreSQL

Для пилота Триола (250–500 устройств) хватит одного инстанса средней конфигурации.

2. Marketplace и приложения

2.1. Как добавить приложение из РуСтор?

Admin UI → /apps → New App → RuStore tab
  Вставить URL: https://apps.rustore.ru/app/<package>
  → Fetch metadata
  → автоматически заполнится: название, иконка, версия, description
  → Publish

Далее привязать к policy: /policies/<id> → Required Apps → Add → выбрать.

Устройство получит установочную команду при следующем MQTT-reconnect (обычно < 1 мин).

2.2. Как добавить APK из своего источника (in-house app)?

/apps → New App → APK upload
  Загрузить .apk (до 200 MB)
  → проверяется подпись (apksigner)
  → extractaется package, version, permissions
  → опционально подпись vendor-signing через /settings/code-signing

Для production APK крайне рекомендую Подписать через vendor-keystore — тогда обновление через OTA без re-install.

2.3. Google Play Store — работает?

Только в сценарии Managed Google Play (требует Android Enterprise + корп-аккаунт Google Workspace). На пилоте Триола Google Play не используется (нет GMS на ТСД).

Для корп-смартфонов ТП — Managed Play настраивается через /settings/google → Bind Enterprise, ETA для полной поддержки — M16.

Альтернатива сейчас: F-Droid как репозиторий в marketplace (см. /apps → F-Droid repositories).

2.4. Можно ли запретить пользователю устанавливать приложения?

Да. В policy:

app_control:
  install_unknown_sources: denied
  package_whitelist_mode: true   # только приложения из whitelist
  package_blacklist: [com.whatsapp, org.telegram.messenger]
  factory_reset_protection: true

Для kiosk-режима whitelist обязателен — разрешены только приложения из allowed_tasks.

2.5. Marketplace-bundles (комплекты для якорного клиента)

Для ГК Триол доступен preset anchor_triol — один клик создаёт 6 policy + groups: - merchandiser — SFA, Яндекс.Карты, камера, навигация - tsd — WMS-клиент, сканер штрих-кодов, kiosk - driver_truck — навигатор, контакты, emergency-call - warehouse_supervisor — WMS + отчёты + почта - cashier — 1С:Розница в kiosk - office — BYOD-профиль, корп-почта, Диадок

Активация: /marketplace → ГК Триол bundle → Install.

Custom bundles под других клиентов — делаются на запрос в течение 3 рабочих дней.

3. Лицензирование и тарифы

3.1. Сколько стоит Enterprise on-prem?

Актуальный прайс — /pricing на landing (komendant-mdm.ru/pricing) или в коммерческом предложении.

Базовые ориентиры:

Для enterprise on-prem включено: - бессрочная лицензия (или подписка, выбор клиента) - обновления 1 год - внедрение + обучение 8 часов - поддержка 8×5 включена, 24×7 за доплату

3.2. Что если лицензия истекла?

• SaaS — сервис переходит в read-only через 7 дней льготного периода: политики применяются, но новые enroll и команды блокированы. Через 30 дней — полное отключение (данные сохраняются 90 дней для восстановления).
• On-prem — аналогично. Expiry проверяется по Ed25519-подписи license.json. Можно продолжить работу с просроченной лицензией в degraded-режиме: новые enroll блокируются, текущие устройства продолжают получать heartbeat, но команд нельзя слать.

3.3. Можно ли перейти с SaaS на on-prem?

Да. Migration tool в Milestone M15: 1. Создаёте on-prem инстанс по installation-onprem.md 2. В SaaS cabinet: /admin/migration → Export tenant dump → получаете зашифрованный дамп 3. На on-prem: komendant-cli tenant import <dump> → устройства получают новые QR-коды и переключаются на новый сервер 4. Переход на парк 100 устройств — ~4 часа с окном обслуживания

3.4. Пробный период

14 дней trial на SaaS с полной функциональностью до 50 устройств. Регистрация на komendant-mdm.ru/signup, активация через email + SMS-код.

Для on-prem trial — через партнёра, выдаётся time-limited license на 60 дней.

3.5. Оплата

• SaaS — ЮKassa (карты, СБП, юрлицо через счёт-оферту)
• On-prem — безнал по счёту, оплата 100% до поставки или 50/50 (первый платёж до старта внедрения)
• Для бюджетных заказчиков — аккредитив, рассрочка по 44-ФЗ (обсуждается индивидуально)

4. Соответствие требованиям

4.1. Поддержка ГОСТ-шифрования?

Запланировано на M50, конец 2026 — интеграция с КриптоПро CSP для TLS-ГОСТ (2012) и VipNet для канала management → device. Текущее состояние — только стандартный TLS 1.3 с RSA/ECDSA.

Для заказчиков, где ГОСТ обязателен по регуляторике — ждите M50 либо используйте шлюз VipNet перед Комендант MDM (работает прозрачно).

4.2. ФСТЭК / ФСБ сертификация

• Реестр Минцифры — подано, ожидаем решения (M16 этап 1 завершён).
• ФСТЭК УЗ-1/УЗ-2 — запланировано после регистрации юрлица и прохождения сертификации лаборатории. ETA неопределён, зависит от внешних процессов.
• ГосСОПКА-интеграция — не требуется для SMB, запланировано для enterprise-segment.

Для пилота Триола (частный бизнес, не госсектор) сертификация ФСТЭК не требуется.

4.3. 152-ФЗ compliance

Да, полностью: - РФ-хостинг — все данные в РФ (SaaS на комм. ЦОД РФ, on-prem — на стороне клиента) - pdn_operator — Комендант зарегистрирован как оператор ПДн (Роскомнадзор, уведомление подано) - consent-flow — каждый пользователь при активации даёт согласие на обработку ПДн - incident reporting — 24-часовое уведомление субъектам ПДн, 72-часовое Роскомнадзору, автоматизировано в /admin/incidents - трансграничная передача — отсутствует (декларация в настройках по умолчанию)

4.4. 44-ФЗ / 223-ФЗ (госзакупки)

Товар находится в процессе внесения в реестр Минцифры (отечественное ПО). После включения в реестр — можно участвовать в тендерах как российское ПО. До этого — частные закупки без ограничений.

4.5. PCI DSS

Комендант MDM не обрабатывает платёжные данные клиентов — мы не храним и не передаём PAN, CVV, track data. Платежи за нашу подписку идут через ЮKassa (PCI DSS L1). Если ваша отрасль (например, POS-терминалы) требует PCI DSS для MDM — мы проходим аудит на уровне «MDM как часть scope», требуется отдельное обсуждение.

5. Администрирование tenant

5.1. Как сменить tenant-admin PIN?

PIN используется для подтверждения разрушительных операций (wipe, factory reset, tenant delete). Смена:

Admin UI → /settings/security → PIN
  Введите старый PIN + новый PIN (6-12 цифр, не последовательность)
  → подтверждение через SMS-код на номер tenant-admin
  → consent flow: «Я подтверждаю смену PIN» → submit

Если старый PIN забыт — через super-admin reset: пишете в support с указанием tenant_id + подтверждением полномочий (скан доверенности от ген.директора компании), super-admin сбрасывает PIN через backend-консоль. SLA на сброс — 4 рабочих часа.

5.2. Что делать, если админ забыл MFA (TOTP)?

Есть три варианта по убыванию безопасности:

1. Backup recovery codes. При первой настройке MFA были сгенерированы 10 одноразовых кодов в /settings/security → Backup Codes. Введите любой неиспользованный код на экране логина → попадёте в UI → сразу сгенерируйте новый TOTP и перегенерируйте backup codes.
2. Второй админ в tenant. Если у tenant есть ещё один active admin — он может сбросить MFA другого через /admin/users/<id> → Reset MFA. Подтверждение через его MFA + email-confirm на сброшенный аккаунт.
3. Support ticket. Если ни backup codes, ни второго админа — пишете в support с ID tenant + подтверждением полномочий. Сброс в течение 1 рабочего дня, обязательно повторная верификация email.

Никогда не храните backup codes в том же менеджере паролей, что и пароль от аккаунта.

5.3. Как добавить нового администратора?

/admin/users → New Admin
  email: ivan@example.ru
  role: Admin / Viewer / Operator / Technician
  groups: [warehouse, office] (опционально)
  → Send invite

На почту придёт ссылка-приглашение (valid 7 дней). Новый админ устанавливает пароль и MFA.

Ролевая модель (RBAC):

5.4. Multi-tenant: разделение прав между филиалами

В рамках одного tenant можно создавать groups и ограничивать admins scope'ом групп:

Admin UI → /groups
  ГК Триол → Склад Щёлково (группа A)
            Склад Соколово (группа B)
            Офис Москва (группа C)

/admin/users/<id>/scope → [A, B]  # админ видит только устройства из A и B

Для жёсткого разделения (дочки-холдинги с разными юрлицами) — отдельные tenants, объединены в одном super-org для billing.

5.5. Audit log — что логируется?

Все действия, меняющие state: - login / logout / failed-login / MFA events - policy create/update/delete, assign - device enroll/wipe/lost-mode/reboot - user create/update/delete, role change - tenant settings change, billing actions - SSH / SQL access (для super-admin) - license activate/deactivate

Поле actor_ip, user_agent, request_id. Immutable хранение в таблице audit_events, export в SIEM (syslog/CEF/LEEF) — см. /settings/integrations/siem.

Retention: 7 лет (требование 152-ФЗ для ряда категорий ПДн).

6. Интеграции

6.1. Как ротировать OneC webhook secret?

/settings/integrations/onec → OneC
  → Rotate Secret
  → подтверждение через MFA
  → выводится новый secret (копировать сразу, больше не покажется)
  → добавить в конфиг 1С (обмен → HTTPS → заголовок X-Komendant-Signature)
  → старый secret живёт ещё 24 часа (grace period), потом отключается

Рекомендуется ротировать секрет раз в 90 дней. Алёрт KomendantWebhookSecretOld придёт, если секрет не меняли > 120 дней.

6.2. LDAP / Active Directory / Аструм

Поддерживается через SSO: - LDAP / AD — /settings/sso/ldap, mapping группы AD → role в Комендант - SAML 2.0 — для любых IdP (Kerberos, Okta, Keycloak, Аструм) - OIDC — Яндекс ID, ВК Workspace, корп Keycloak

Enrollment auto-provisioning: при первом SSO-login user создаётся автоматически с ролью из default_role_on_provision.

6.3. SIEM (MaxPatrol SIEM, Kaspersky KUMA, Positive Technologies)

/settings/integrations/siem
  type: syslog | https-webhook | kafka
  host: siem.example.ru
  port: 514
  format: CEF (ArcSight-style) | LEEF (QRadar-style) | JSON
  events: [auth.*, device.*, policy.*] (фильтр)

Тестовое событие — /settings/integrations/siem → Send Test. Запись в SIEM появится в течение 30 сек.

6.4. 1С / СБИС / Диадок

• 1С — REST API + webhooks (двусторонний обмен). Инструкция для 1С-разработчика: docs/runbooks/integration-1c.md.
• СБИС — одностронний push событий (новые сотрудники, увольнения) через webhook endpoint СБИС.
• Диадок — пока не интегрировано, roadmap Q3 2026.

6.5. Webhook на уведомления

/settings/integrations/webhooks
  URL: https://hooks.slack.com/... | https://tg-bridge.example.ru/...
  events: [alert.critical, device.offline_30min, license.expiring_30d]
  secret: <signed with HMAC-SHA256>

Поддерживается: Slack-compatible, Telegram через бридж, Mattermost, общий HTTPS webhook. Для RocketChat и корп-мессенджеров — HTTPS webhook + адаптер на стороне клиента.

6.6. API для собственных интеграций

Полный REST API: https://api.mdm.example.ru/docs (OpenAPI 3.0, Swagger UI). Аутентификация — API-токены через /settings/api-tokens, scope-based permissions. Rate-limit: 100 req/min на tenant, 1000 для enterprise.

7. Безопасность и доступ

7.1. Шифрование данных

• At rest — PostgreSQL encryption через LUKS на уровне диска + AES-GCM для секретных полей (JWT keys, API tokens) на уровне приложения
• In transit — TLS 1.3 везде (API, MQTT, admin UI, DPC→server)
• Backups — AES-256-GCM с отдельным passphrase (не хранится на сервере)
• Master license key — Ed25519, хранится в /root/komendant-secret/ с chmod 600
• ГОСТ — M50, см. вопрос 4.1

7.2. Доступ root на сервер

• Только команда DevOps клиента. Мы (Комендант) для on-prem доступа не имеем.
• SSH — только по ключу, без password. Fail2ban jail включён (после 5 неудачных попыток — ban на 24 часа).
• sudo логируется в /var/log/auth.log, форвард в SIEM.

7.3. Защита от инсайдерских атак

• RLS (Row-Level Security) FORCE в PostgreSQL — даже komendant_app с пропуском middleware не увидит чужой tenant.
• super-admin actions — все под audit + require MFA + require SMS confirmation на deлеtrucrive.
• 2-human rule на wipe tenant: одна роль инициирует, вторая подтверждает в течение 15 минут.
• Separation of duties: Billing Admin ≠ System Admin ≠ Security Admin.

7.4. DDoS-защита

SaaS-версия: - Cloudflare / Qrator / Servicepipe перед landing + admin UI - rate-limit на nginx (10 req/sec на IP) + CrowdSec - ModSecurity CRS + custom rules - EMQX listener limit 1000 connections/IP

On-prem — клиент сам отвечает за периметр. Рекомендуем DDoS-Guard или Qrator как upstream.

7.5. Pen-test / баг-баунти

Ежегодный external pen-test (прошёл в M11, повторный в M23). Bug bounty — программа на hackerone, запуск после регистрации в реестре Минцифры.

Если вы нашли уязвимость — security@komendant-mdm.ru, PGP-ключ на landing (/security). Reward от 10 000 ₽ (info) до 500 000 ₽ (RCE).

8. Эксплуатация

8.1. SLA

Критичность: - P1 — прод down, блокирует бизнес - P2 — отдельная функция сломана, workaround есть - P3 — минорные баги, косметика - P4 — вопрос / enhancement

8.2. Как открыть заявку в поддержку?

1. Admin UI → виджет в правом нижнем углу (SupportWidget)
2. Email: support@komendant-mdm.ru
3. Telegram: @komendant_support (публичный канал для общих вопросов, для P1 — email)
4. По телефону: enterprise-клиентам выдаётся hotline number после подписания договора

В заявке указать: - tenant_id (видно в /settings → About) - tier критичности (P1-P4) - шаги воспроизведения - logs (для сервера — journalctl --since "1 hour ago" -u komendant-api, для устройства — bugreport.zip через adb)

8.3. Часовые пояса

Все timestamps в UI — в локальном TZ пользователя (из browser). В audit log — UTC + TZ-offset. Серверные cron-задачи — в TZ сервера (обычно Europe/Moscow для РФ клиентов).

8.4. Что происходит при переезде устройства в другой филиал?

Если admin переносит device в другую группу — новая policy применяется при следующем heartbeat (< 1 мин). Device не переенроллится, JWT остаётся прежним. В audit появится событие device.group.changed.

Если device фактически перемещается в другой регион РФ — никаких действий не требуется, только поменяется последний GPS-heartbeat.

8.5. Wipe устройства при увольнении сотрудника

/devices/<id> → Actions → Wipe
  Тип: factory_reset (полный сброс) | corp_only (только корп-данные, для BYOD)
  MFA confirmation
  PIN confirmation
  → команда уходит в MQTT, выполняется в течение 1 минуты если устройство online
  → если offline — помечается в очереди, выполнится при первом online-событии
  → audit event: device.wipe.scheduled + device.wipe.completed

Для BYOD (личный телефон сотрудника) рекомендую corp_only — удаляются только managed-profile данные и корп-приложения, личные фотки не трогаются.

8.6. Отчёты и аналитика

/reports — преднастроенные отчёты: - Парк по OS/модели/производителю - Compliance (% устройств с pass policy) - Utilization (активность, heartbeat gaps) - Incidents (alerts за период) - Licensing (активные/free)

Экспорт — PDF / Excel / CSV / JSON. Расписание (еженедельный отчёт на почту) — /reports/<id> → Schedule.

Кастом-отчёты — через API + ваш BI (PowerBI, Yandex DataLens, Apache Superset). Пример дашборда — docs/runbooks/bi-datalens-example.md.

8.7. Как обновить DPC на устройствах?

• Managed Play — автоматически через Google Play (если доступен).
• Komendant Update Stream — для AOSP и устройств без GMS. В /settings/dpc/updates: channel: stable | beta auto_update: on rollout_waves: 5%, 25%, 100% window: 02:00-05:00 Moscow
• Ручное — в /devices отметить устройства → Actions → Update DPC → upload.apk или pick version.

Rollback если что-то пошло не так — /settings/dpc/updates → History → Rollback last wave.

8.8. Что делать при плановых работах у нас?

Уведомление за 7 дней на email tenant-admin + в admin UI banner. Окно обычно 01:00–04:00 Moscow, downtime < 10 мин (rolling deploy). Для on-prem — вы сами планируете окно.

Экстренные security-fixes — без предварительного уведомления, уведомление пост-фактум с описанием уязвимости (CVE, если публично).

Версия документа: 1.0 (2026-04-18). Если ответа на ваш вопрос здесь нет: support@komendant-mdm.ru.