SSO и ролевой доступ: когда они нужны AI-платформе

Короткий ответ

SSO (единый вход) позволяет сотруднику входить в несколько систем с одной учётной записью компании — например, через корпоративную почту. RBAC (ролевой доступ) определяет, что каждый сотрудник может видеть и менять в соответствии с ролью. AI-платформе RBAC нужен почти всегда: там хранятся переписки клиентов, записи звонков и настройки, меняющие поведение AI. SSO обычно становится необходим, когда растёт число пользователей, часто меняются сотрудники, в компании уже есть централизованная система учётных записей или отрасль регулируется. Главное правило: каждый видит только то, что нужно для работы, а доступ уволившегося закрывается сразу.

Два понятия — два вопроса

SSO отвечает на вопрос «кто входит?»: сотрудник заходит под центральной учётной записью компании, не держит отдельный пароль в каждой системе, а при увольнении теряет доступ ко всем системам, как только центральную запись закрывают. RBAC отвечает на вопрос «что ему можно?»: оператор видит только свои диалоги, руководитель — диалоги команды, администратор меняет настройки.

Одно не заменяет другое. RBAC работает и без SSO, но учётными записями управляют вручную. SSO без RBAC просто даёт всем одинаково широкий доступ — только удобнее.

Когда это нужно: признаки

• Больше 15–20 пользователей и несколько команд (продажи, поддержка, маркетинг).
• Высокая текучесть — каждый месяц кто-то приходит и уходит.
• В систему заходят подрядчики и аутсорсинговые команды.
• В компании уже есть централизованная система учётных записей, и IT требует подключать к ней все системы.
• Отрасль регулируется (банки, страхование, медицина), и контроль доступа проверяют на аудитах.
• На платформе чувствительные данные: записи звонков, персональные данные, вопросы об оплате.

Матрица ролей для AI-платформы

На AI-платформе есть чувствительные права, которых нет в обычной CRM: менять инструкции AI и базу знаний, прослушивать записи звонков, выгружать данные. Иллюстративная матрица:

1. 1ОператорСвои диалоги и лиды; остановка бота в своём диалоге. Без выгрузки.
2. 2Руководитель командыДиалоги команды, отчёты, назначение. Без доступа к настройкам.
3. 3Редактор знанийБаза знаний и правила ответов AI; без данных клиентов.
4. 4АдминистраторНастройки, интеграции, пользователи. Каждое изменение записывается в журнал.
5. 5АудиторТолько чтение: журналы и отчёты, без права изменений.

Минимальные привилегии

Каждая роль получает только доступ, нужный для работы. На практике чаще всего нарушается «временный» широкий доступ: кто-то становится администратором, чтобы решить проблему, и это право никто не отзывает. Правило: временный доступ выдаётся с датой окончания. У чувствительных данных вроде записей звонков свои правила доступа — они разобраны в статье о персональных данных в записях звонков.

Увольнение: закрытие доступа

Самый частый риск доступа — бывший сотрудник, который всё ещё может войти. С SSO это решается автоматически при закрытии центральной учётной записи. Без SSO нужна письменная процедура: как только HR сообщает об увольнении, администратор в тот же день закрывает учётную запись во всех системах, а открытые диалоги и лиды пользователя передаются другому. Раз в месяц сверяйте список активных пользователей со списком HR.

Проверка доступа и MFA

• Раз в квартал пересматривайте, у кого какая роль, — лишний доступ отзывается.
• Для администраторов двухфакторная аутентификация (MFA) обязательна.
• Никаких общих «офисных» учётных записей — каждое действие должно принадлежать конкретному человеку.
• Для интеграций — отдельные сервисные учётные записи и ключи, а не личные.
• Изменения доступа записываются в журнал.

Вопросы поставщику

• Какие способы входа поддерживаются: email и пароль, корпоративная учётная запись, SSO?
• Роли заданы заранее или их можно настроить самим?
• Изменение инструкций AI и базы знаний — отдельное право?
• Доступ к записям звонков и к выгрузке управляется отдельно?
• Когда закрывается доступ удалённого пользователя?
• Записываются ли входы и изменения в журнал и кто может его смотреть?

Иллюстративный пример

Это иллюстративный пример. Страховая компания открывает AI-платформу командам поддержки и продаж — 40 пользователей. В первый месяц всем дан одинаково широкий доступ. При подготовке к аудиту выясняется, что менеджеры продаж видят и переписки поддержки с жалобами, а учётные записи двух бывших сотрудников всё ещё активны.

Компания вводит матрицу из пяти ролей, сокращает права администратора до двух человек и связывает процедуру увольнения с HR. SSO с центральной системой учётных записей отдельно обсуждается с поставщиком на следующем этапе.

Типичные ошибки

• Права администратора всем — «для удобства».
• Общие учётные записи — действия не привязаны к человеку.
• Незакрытые учётные записи уволившихся.
• Считать право менять инструкции AI обычным правом.
• Никогда не проводить проверку доступа.

Ограничения

RBAC защищает, только если настроен правильно: если роли не совпадают с реальной работой, сотрудники «находят выход» через общие учётные записи или пароли. SSO зависит от безопасности самой центральной учётной записи — слабость там ставит под угрозу все системы. В регулируемых отраслях требования к доступу задают закон и внутренняя политика, и их нужно проверять отдельно.

Доступ в Vexvon

В Vexvon можно войти по email и паролю или через аккаунт Google. Согласно странице безопасности Vexvon, права доступа управляются на уровне пользователей и ролей — например, сотрудник продаж видит только закреплённых за ним клиентов, — доступ пользователя, удалённого из аккаунта, закрывается сразу, а действия в аккаунте записываются. Корпоративный SSO мы не заявляем как готовую возможность: если он вам нужен, обсудим это в начале проекта. Подробнее — безопасность.

Следующий шаг

Выпишите всех пользователей платформы в таблицу и рядом с каждым укажите две вещи: роль и доступ, который ему действительно нужен. Несовпадающие строки — ваш первый список исправлений. Общие слои интеграции разобраны в статье о корпоративной интеграции AI. Другие статьи — в разделе о корпоративной интеграции; модель доступа можно разобрать во время демо.