Учетные записи и доступ#

Метаданные#

  • Документ ID: REG-TECH-006

  • Версия: 0.1.1

  • Ответственный: ООО "Аросса"

  • Статус: Готово

1. Назначение#

  • Документ фиксирует единый подход к учетным записям, ролям и аутентификации для local, tenant и master контуров.

  • Модель применяется к UI, API, MQTT-доступу и сервисным интеграциям.

2. Базовые сущности#

  • Account: учетная запись пользователя или сервиса (human | service).

  • Role: набор прав для бизнес-функций (operator, engineer, tenant_admin, master_operator, auditor).

  • Permission: атомарное действие (status.read, device.command.send, policy.edit, account.manage).

  • AccountRoleBinding: привязка учетной записи к роли в области видимости (tenant_id, site_id).

  • Credential: тип учетных данных (password, rfid_mifare, passkey_qr, passkey_rfid, api_token, refresh_token).

  • AuditEvent: событие аутентификации/авторизации/административного изменения.

3. Ролевая модель (RBAC)#

  • Доступ назначается через роли; прямое назначение отдельных прав допускается только для сервисных аккаунтов.

  • Роли и права хранятся централизованно в tenant/master API с синхронизацией в local-контур.

  • Минимально необходимые роли:

    • tenant_admin — управление учетками, ролями, интеграциями tenant-контура.

    • operator — эксплуатационные операции и обработка событий.

    • engineer — диагностика, сервисные команды, работа с конфигурациями.

    • auditor — только чтение и аудит-журналы.

    • master_operator — межtenant-мониторинг в master-контуре.

4. Состояния учетной записи#

  • pending_activation — создана, но не активирована.

  • active — активная учетная запись.

  • blocked — временная блокировка (ручная или по политике).

  • archived — выведена из эксплуатации, вход запрещен.

5. Сценарии аутентификации#

  • Оператор в local-контуре: RFID MIFARE + PIN (по политике объекта).

  • Phone-assisted local-контур для iP-1510: QR challenge/response, при совместимости допустим BLE как ускоритель, для iPhone/Safari обязателен fallback QR -> 4-digit code.

  • Web-доступ tenant/master: passkey_qr/passkey_rfid (reference runtime), login/password и 2FA как целевой расширенный профиль.

  • Сервисные интеграции: api_token с ограниченным сроком действия и scope-правами.

  • MQTT-доступ: отдельные учетные данные интеграционного уровня с привязкой к tenant и контроллеру.

6. API-контур учеток#

  • GET /api/v1/accounts/list

  • GET /api/v1/accounts/scheme

  • GET /api/v1/accounts/{id}

  • POST /api/v1/accounts

  • PATCH /api/v1/accounts/{id}

  • POST /api/v1/accounts/{id}/block

  • POST /api/v1/accounts/{id}/unblock

  • GET /api/v1/roles/list

  • POST /api/v1/accounts/{id}/roles

  • DELETE /api/v1/accounts/{id}/roles/{role_id}

  • GET /api/v1/audit-events/list?scope=auth

  • POST /api/v1/auth/passkey/commands/start

  • POST /api/v1/auth/passkey/commands/complete

  • GET /api/v1/auth/passkey/status

  • GET /api/v1/auth/me

  • POST /api/v1/auth/commands/logout

7. Политики безопасности учеток#

  • Минимальная сложность пароля и срок действия задаются политикой tenant.

  • Лимит неуспешных попыток входа переводит учетку в blocked до разблокировки.

  • Сервисные токены имеют TTL, ротацию и обязательный аудит использования.

  • Любое изменение роли, пароля, токена и блокировки фиксируется в аудит-журнале.

8. Разграничение контуров#

  • Local: автономная работа с кэшом учеток и прав для отказоустойчивости.

  • Tenant: основной источник прав и политик для объекта эксплуатации.

  • Master: агрегированный доступ к межtenant-функциям без прямого управления локальными учетками.

9. Ссылки#