Пользователи, приглашения, роли, 2FA, API-токены и OIDC SSO
Этот раздел описывает управление доступом людей и интеграций в Qarvix: кого приглашать, какие роли выдавать, когда включать 2FA, зачем нужны API-токены и как OIDC SSO помогает централизовать вход.
Главный принцип: пользователь должен получать только тот доступ, который нужен для его задачи. Не выдавайте административные права “на всякий случай” и не используйте учетные записи людей для автоматических интеграций.
Коротко
- Пользователь - человек, который входит в панель Qarvix.
- Роль определяет, что пользователь может делать.
- 2FA защищает вход дополнительным одноразовым кодом.
- API-токен нужен для интеграций и автоматизации, а не для входа человека.
- OIDC SSO позволяет входить через корпоративную систему идентификации.
- Доступ подрядчиков и временных инженеров должен иметь понятную границу и срок.
Типы доступа
В Qarvix полезно разделять доступ по назначению.
| Тип доступа | Для кого | Что важно |
|---|---|---|
| Административный | владельцы контура, старшие инженеры | полный контроль, обязательная 2FA |
| Эксплуатационный | сервисная команда, NOC, инженеры | доступ только к нужным объектам и журналам |
| Временный | подрядчики, монтажники, интеграторы | ограничить область и срок работ |
| Наблюдение | руководители, клиентская сторона | просмотр статусов, отчетов и журналов без изменения настроек |
| Интеграционный | мониторинг, биллинг, внешняя система | API-токен с минимальными правами |
Если человек не должен менять маршруты, ACL или пользователей, ему не нужна административная роль.
Пользователи
Пользователь представляет конкретного человека. Не рекомендуется создавать общие учетные записи вроде support, engineer или admin2, если под ними работают разные люди.
Персональные учетные записи дают понятные ответы:
- кто создал устройство;
- кто выдал токен подключения;
- кто изменил маршрут;
- кто включил или отключил ACL;
- кто получил доступ к объекту;
- кого нужно отключить при увольнении или завершении работ.
Если нужна командная работа, используйте роли, а не общий логин.
Приглашение пользователя
Перед приглашением определите:
- к какой организации относится пользователь;
- к каким сетям он должен иметь доступ;
- должен ли он менять настройки или только смотреть;
- нужен ли доступ к журналам и отчетам;
- является ли доступ постоянным или временным;
- нужна ли 2FA до допуска к production-контуру.
После приглашения проверьте, что пользователь видит только нужные организации, сети и устройства.
Роли
Роли должны отражать реальные обязанности.
Типовая модель:
| Роль | Назначение |
|---|---|
| Владелец организации | управляет организацией, пользователями, лицензией и общими настройками |
| Администратор | создает сети, устройства, правила доступа, маршруты и токены |
| Инженер | подключает устройства, проверяет статусы, работает с журналами |
| Наблюдатель | смотрит статусы, отчеты и журналы без изменения конфигурации |
| Интеграция | обращается к API в рамках ограниченного сценария |
Названия ролей могут отличаться в интерфейсе, но смысл должен оставаться таким: чем ближе роль к управлению доступом и сетями, тем строже требования к безопасности.
Принцип минимальных прав
Минимальные права означают, что пользователю дают доступ только к тем действиям и объектам, которые нужны для работы.
Примеры:
- инженеру камер не нужен доступ ко всем филиалам, если он обслуживает один объект;
- подрядчику не нужна возможность приглашать других пользователей;
- учетной записи мониторинга не нужен доступ к изменению ACL;
- руководителю чаще нужен просмотр отчетов и статусов, а не изменение сетей;
- монтажнику на время работ нужен ограниченный доступ к конкретному объекту.
Такой подход снижает риск случайных изменений и упрощает расследование инцидентов.
2FA
2FA - это двухфакторная защита входа. Помимо пароля пользователь подтверждает вход одноразовым кодом из приложения или другого второго фактора.
2FA особенно важна для:
- владельцев организаций;
- администраторов;
- пользователей, которые создают токены подключения;
- сотрудников с доступом к нескольким клиентам;
- учетных записей, которым доступны маршруты, ACL и журналы.
Если пароль пользователя будет украден, 2FA снижает риск входа в панель без второго фактора.
Рекомендация: включать 2FA для всех административных ролей и для сервисных команд, которые работают с production-объектами.
API-токены
API-токен используется для программного доступа к Qarvix. Это не замена паролю пользователя и не способ дать “общий вход” команде.
API-токены подходят для:
- мониторинга статусов устройств;
- выгрузки данных для отчетов;
- интеграции с внутренней системой учета;
- автоматического создания или проверки объектов;
- доступа к API устройств через туннель в рамках отдельного сценария.
Для API-токена важно задавать:
- понятное имя;
- владельца или ответственную систему;
- минимальные права;
- срок действия, если токен временный;
- процедуру отзыва;
- описание, где токен используется.
Не храните API-токены в общих чатах, документах без контроля доступа или в коде, который попадает в публичные репозитории.
OIDC SSO
OIDC SSO - это вход через корпоративную систему идентификации. Пользователь входит в Qarvix не отдельным локальным паролем, а через уже принятую в компании учетную запись.
OIDC SSO полезен, если:
- в компании уже есть единый вход;
- нужно централизованно отключать сотрудников;
- требуется единая политика MFA/2FA;
- много пользователей и ручные приглашения становятся неудобными;
- нужно снизить количество отдельных паролей;
- доступ должен соответствовать корпоративным группам.
Примеры систем, через которые обычно подключают SSO: Keycloak, Microsoft Entra ID, Okta, Authentik и другие OIDC-провайдеры.
Перед включением SSO согласуйте:
- кто администратор OIDC-провайдера;
- какие группы получают доступ к Qarvix;
- как группы сопоставляются с ролями;
- что происходит при увольнении сотрудника;
- сохраняется ли локальный административный доступ на случай аварии SSO.
Доступ подрядчиков
Подрядчики и временные инженеры должны получать доступ только на время работ и только к нужной области.
Перед выдачей доступа зафиксируйте:
- кто запросил доступ;
- к какому объекту или сети нужен доступ;
- какие действия разрешены;
- нужен ли доступ к LAN-подсети или только к роутеру;
- когда доступ должен быть отозван;
- кто проверяет результат работ.
После завершения работ проверьте журнал аудита и отзовите лишние права.
Отзыв доступа
Отзыв доступа нужен не только при увольнении. Его стоит делать после завершения подрядных работ, смены роли сотрудника, окончания пилота или переноса объекта в другую команду.
Порядок проверки:
- отключите или удалите пользователя из организации;
- отзовите временные роли;
- проверьте API-токены, созданные этим пользователем;
- убедитесь, что у пользователя нет статических клиентов, которые продолжают использоваться;
- проверьте журнал аудита за период работ;
- обновите список ответственных за объект.
Если используется OIDC SSO, отключение пользователя в корпоративной системе должно блокировать вход в Qarvix. Но локальные токены и статические клиенты все равно нужно проверять отдельно.
Доступ к API устройств через туннель
Доступ к API устройств за роутером может быть удобен для мониторинга и интеграций, но его нельзя открывать всем пользователям без ограничений.
Перед выдачей такого доступа определите:
- кто обращается к API;
- к какому устройству или подсети;
- какой протокол и порт используются;
- нужен ли постоянный доступ или временный;
- должны ли действия попадать в отчет или журнал;
- можно ли ограничить доступ отдельным маршрутом или ACL.
Например, сервис мониторинга может получать данные с датчиков через туннель, но не должен иметь административный доступ к панели Qarvix.
Журналы и контроль
Для управления доступом важны два типа следов:
- журнал аудита показывает действия пользователей в панели;
- журналы устройств показывают события подключения, конфигурации и состояния устройств.
Проверяйте журналы после:
- приглашения нового пользователя;
- выдачи административной роли;
- создания API-токена;
- изменения ACL;
- выдачи доступа подрядчику;
- завершения работ на объекте.
Так проще доказать, кто и когда менял доступ, и быстрее разбирать инциденты.
Практические рекомендации
- Не используйте общие учетные записи для людей.
- Включайте 2FA для администраторов.
- Разделяйте доступ сотрудников, подрядчиков и интеграций.
- Выдавайте API-токены только под конкретную задачу.
- Регулярно проверяйте пользователей, роли и токены.
- Для нескольких клиентов используйте отдельные организации.
- Для production-контуров заранее согласуйте модель ролей.
- После завершения работ отзывайте временный доступ.
Контрольный список
- У каждого пользователя персональная учетная запись.
- Администраторы используют 2FA.
- Подрядчики не имеют лишних прав.
- API-токены названы понятно и имеют владельца.
- Временные доступы имеют срок проверки.
- Роли соответствуют реальным обязанностям.
- Пользователь видит только нужные организации и сети.
- Доступ к LAN/API ограничен правилами.
- В журнале аудита видны ключевые изменения.
- Есть процедура отзыва доступа.
Связанные разделы
- Организации и сети - где задаются границы владения и отчетности.
- Устройства и VPN-адреса - как пользователи и клиенты появляются в сети.
- Сети, маршруты и ACL - как ограничивать доступ техническими правилами.
- API устройств через туннель - как безопасно открывать локальные API.
- Журналы и отчеты - где проверять действия пользователей и событийность.