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

## Метаданные

- Документ 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. Ссылки

- [Стиль API и контракт ответов](api-style)
- [API и протоколы интеграции](api-and-protocols)
- [Информационная безопасность и защита данных](security-and-data-protection)
- [Руководство администратора](../operations/admin-manual)