Общий ИИ-чат для компании: вход по корпоративной учётной записи и увольнение сотрудника

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

Эта статья построена вокруг одного вопроса: что нужно настроить помимо SSO, чтобы доступ к общему ИИ-чату действительно прекращался после ухода человека. В примерах используется Open WebUI, потому что его документация прямо разделяет способ входа и всё остальное. Но сама логика проверки пригодится для любого общего чата, который стоит за корпоративным входом.

Две разные задачи: «кто ты» и «что тебе можно»

Вход через SSO отвечает на первый вопрос. Провайдер подтверждает, что за экраном находится конкретный человек из вашей организации. Open WebUI поддерживает для этого OAuth/OIDC, а также схему с доверенными заголовками за прокси аутентификации (документация по SSO). Это два принципиально разных механизма: в первом случае чат сам участвует в обмене с провайдером, во втором он доверяет тому, что ему передал стоящий перед ним прокси.

Второй вопрос — «что этому человеку можно внутри» — решается уже самим чатом. Создание аккаунтов, роли и группы настраиваются отдельно от выбора способа входа (там же). Из этого следует практический вывод, который проще всего проиллюстрировать бытовой аналогией: SSO — это охранник на проходной, который смотрит на пропуск. А вот какие двери открываются внутри здания, зависит от настроек замков на этажах. Охранник может быть безупречным, но если на этаже все двери открыты любому, кто вошёл, строгость проходной ничего не решает.

Отсюда первая карта различий, которую стоит держать перед глазами:

• Учётная запись у провайдера — подтверждает личность и отвечает за пароль, второй фактор и блокировку человека на уровне всей организации.
• Локальный аккаунт в чате — запись, созданная в Open WebUI при первом входе или заранее; к ней привязаны история, настройки и права.
• Роль — крупный уровень допуска внутри чата.
• Группа и разрешения — более тонкая настройка: кто видит какие модели, знания и инструменты.
• Сессия — состояние уже открытого браузера, которое переживает многое из перечисленного выше, если не проверить обратное.

Если обращаться с этими пятью слоями как с одним, увольнение превращается в лотерею: заблокировали человека в каталоге и считают дело закрытым, хотя в чате остались его аккаунт, членство в группе и, возможно, живая вкладка.

Как новый человек появляется в чате: путь от первой кнопки до рабочего места

Чтобы понять, что именно потом отзывать, полезно сначала один раз провести тестового сотрудника через регистрацию и записать, какие состояния он проходит. Роли в Open WebUI системные: администратор, обычный пользователь и ожидающий подтверждения. Роли отличаются от групп и разрешений (документация по ролям). Для жизненного цикла важна именно роль «ожидающий подтверждения»: она описывает человека, который прошёл вход, но ещё не допущен к работе.

Представим условную компанию из трёх отделов: юристы, аналитики и поддержка. Заведём тестовую учётную запись «Тест Тестов» у провайдера и пройдём по шагам.

1. Первый вход. Тестовый пользователь нажимает кнопку SSO. Провайдер подтверждает личность, чат создаёт локальный аккаунт, если его ещё нет и если создание аккаунтов настроено как разрешённое. Наблюдаемый результат: в списке пользователей администратора появилась новая запись с определённой ролью.
2. Ожидание. Если новые аккаунты попадают в статус ожидающих подтверждения, человек видит экран ожидания, а не рабочее пространство. Наблюдаемый результат: чат открывается, но ни модели, ни история недоступны. Это и есть то безопасное промежуточное состояние, которое стоит увидеть своими глазами.
3. Подтверждение. Администратор переводит аккаунт в роль обычного пользователя. Наблюдаемый результат: при следующем обновлении страницы человек видит рабочий интерфейс.
4. Назначение группы. Аккаунт добавляется в группу своего отдела. Наблюдаемый результат: пользователь видит те модели и материалы, которые группа ему открывает, и не видит остальных.

Каждый шаг здесь даёт проверяемый признак, и это не случайно. Позже, при увольнении, нужно будет пройти по этой цепочке в обратную сторону и убедиться, что каждый признак исчез. Если вы никогда не видели статус «ожидающий» вживую, вы не отличите его от поломки.

Заметьте также, чего в этой цепочке нет: автоматического «умного» поведения при смене должности. Чат не знает, что вчера человек был юристом, а сегодня стал аналитиком. Пока вы сами не договорились, откуда берутся группы, они остаются тем, что кто-то когда-то назначил.

Роль или группа: две рабочие задачи, которые нельзя смешивать

Самая частая ошибка проектирования доступа — пытаться выразить всё ролью. Но роль в Open WebUI грубая: администратор, обычный пользователь, ожидающий. Для всего остального существуют группы и разрешения, и документация подчёркивает, что это разные вещи (роли). Покажем на двух условных задачах, как они работают вместе.

Задача первая: юристам нужна модель с доступом к библиотеке договоров

Допустим, в компании есть тридцать человек в юридическом отделе и ещё сто сорок в остальных подразделениях (числа условные, для наглядности). Юристам нужна отдельная настройка чата: определённая модель и набор загруженных документов. Остальным эти материалы видеть нельзя.

Здесь роль не помогает: все сто семьдесят человек — обычные пользователи. Разделение делается группой «Юристы» и правами на ресурсы, которые к ней привязаны. Проверяемый результат: тестовый пользователь из группы видит модель и документы, тестовый пользователь без группы не видит. Проверять нужно обоими пробными учётными записями, иначе можно ошибиться в обе стороны: случайно закрыть доступ своим или случайно открыть чужим.

Задача вторая: временный подрядчик на три недели

Подрядчику нужен чат, но только с одной универсальной моделью и без любых внутренних материалов. Тут возникает соблазн создать «роль подрядчика», которой в системном списке нет. Правильный ход другой: подрядчик остаётся обычным пользователем, но не состоит ни в одной группе с внутренними ресурсами, а при необходимости получает отдельную группу «Подрядчики» с минимальным набором разрешений.

Эти два примера показывают, почему смешивать роли и группы опасно. Если закрывать юристов от остальных через роль, придётся изобретать то, чего система не предусматривает. Если же давать права на уровне отдельных людей, то при уходе каждого придётся вспоминать, что ему выдавали. Группа хороша тем, что у неё есть состав, а состав можно проверить списком.

Что происходит при переводе в другой отдел

Перевод — тихий родственник увольнения. Сотрудник остаётся в компании, его учётная запись у провайдера жива, вход работает, но права должны смениться. Если группы в чате назначались вручную, то после перевода человек одновременно состоит в старой и в новой группе. Он не заметит ничего необычного, ведь у него просто стало больше возможностей. Именно поэтому перевод стоит включить в тот же тест, что и увольнение: после изменения должности проверьте, что старая группа больше не показывает человеку её ресурсы.

Практическое правило из этого: источник истины о составе групп должен быть один и понятный. Либо вы ведёте группы вручную и у вас есть процедура обновления при каждом кадровом событии, либо группы синхронизируются с провайдером, и тогда вы отдельно проверяете, как и когда эта синхронизация применяется в вашей версии. Что именно доступно в конкретной установке, определяется её версией и настройками, поэтому заранее не стоит рассчитывать ни на одно, ни на другое — проверьте на тестовой записи.

Увольнение как маршрут по пяти точкам

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

Точка первая: учётная запись у провайдера

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

Чего она сама по себе не гарантирует, зависит от конкретной установки. Локальный аккаунт в чате остаётся записью в базе, и сам по себе факт блокировки у провайдера его не удаляет. Уже выданная сессия живёт по своим правилам. Не стоит поэтому обещать себе мгновенный отзыв одной блокировкой у провайдера: точные возможности завершения сессий, включая обратные уведомления от провайдера, нужно проверять отдельно для вашей версии и настройки.

Точка вторая: членство в группах

Затем убираем человека из групп. Это важнее, чем кажется: если по какой-то причине аккаунт останется активным, пустое членство лишает его доступа к внутренним моделям и материалам. Проверяемый результат: тестовым входом администратора «от имени» проверить нельзя, поэтому ориентируемся на список состава группы. Человека в нём быть не должно, а количество участников группы изменилось ровно на единицу.

Если группы синхронизируются автоматически, этот шаг превращается в проверку, а не в действие. Откройте группу и убедитесь, что запись действительно исчезла, а не ждёт следующего входа пользователя, который уже не состоится. Здесь легко ошибиться: синхронизация, привязанная ко входу, не сработает для человека, который больше не входит.

Точка третья: права внутри Open WebUI

Здесь два действия, и между ними есть выбор. Можно понизить роль аккаунта до ожидающего подтверждения: чат продолжит хранить запись, но не пустит человека к рабочему пространству. Либо удалить аккаунт целиком, вместе с тем, что к нему привязано. Выбор зависит от политики хранения: нужна ли компании история переписки уволенного сотрудника, например для передачи дел или разбора инцидентов.

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

Отдельно проверьте административные права. Если уходящий сотрудник был администратором чата, понижать нужно не только его самого, но и пересмотреть, не осталось ли в системе единственного администратора, который уволился. Иначе вы лишите доступа не только его, но и себя.

Точка четвёртая: уже открытая сессия

Это самое неудобное место, потому что его труднее всего увидеть. Человек вошёл в чат утром, закрыл ноутбук и уехал, а вечером ему отключили учётную запись. Открытая вкладка осталась на столе, а в браузере хранится то, что позволяет чату считать его уже вошедшим. Что с этим произойдёт при следующем запросе, зависит от того, как именно ваша установка проверяет сессию: только по собственному токену или с оглядкой на провайдера, и каков срок жизни этого токена.

Поэтому честный ответ на вопрос «как быстро пропадёт доступ» звучит так: это нужно измерить. Заведите тестовую учётную запись, войдите в чат в одном браузере, затем заблокируйте человека у провайдера, понизьте роль в чате и в уже открытой вкладке попробуйте отправить сообщение и обновить страницу. Запишите, что произошло сразу, через пять минут и через час. Эти наблюдения и есть ответ для вашей установки. Если окажется, что сессия живёт дольше, чем допустимо, то на этом этапе вы обнаружили реальную настройку, которую нужно ужесточить: срок жизни токена, принудительный выход или другие возможности вашей версии.

Точка пятая: то, что человек унёс с собой

Остаются личные ключи. Если пользователям разрешено создавать собственные API-ключи или подключать личные подключения к моделям, то у уходящего сотрудника есть пути обращения к системе, которые не зависят от интерфейса. Они не исчезают от того, что человек перестал заходить через SSO. Проверьте, какие ключи и подключения привязаны к его аккаунту, и отзовите их. Если аккаунт удаляется целиком, посмотрите, что стало с его ключами: пробное обращение с этим ключом должно завершаться отказом. Если ключи были общими командными, их придётся заменить, а все сервисы, которые их использовали, перенастроить. Именно общие ключи чаще всего забываются, ведь формально они никому лично не принадлежат.

Карта состояний, которую удобно держать в тетради администратора

Соберём всё в одну таблицу. Она нужна не для заучивания, а чтобы в момент кадрового события не вспоминать порядок.

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

Доверенные заголовки: удобно, пока никто не может обойти прокси

Второй способ входа, о котором говорит документация, — доверенные заголовки за прокси аутентификации (документация по SSO). Идея проста: перед чатом стоит прокси, который сам разбирается с провайдером и передаёт чату имя пользователя в заголовке запроса. Чат этому имени верит. Для администратора это удобно, потому что в самом чате не нужно настраивать обмен с провайдером.

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

Отсюда конкретные проверки:

• Чат слушает только внутренний адрес. Сетевой порт приложения не должен быть доступен снаружи, кроме как через прокси. Проверка: попытка подключиться к нему с постороннего узла завершается отказом.
• Прокси сам перезаписывает заголовки. Если клиент присылает собственный заголовок с именем пользователя, прокси обязан его отбросить и подставить значение, полученное от провайдера. Проверка: запрос с поддельным заголовком не меняет личность в чате.
• Увольнение проверяется на уровне прокси. Пока он решает, кого пускать, блокировка у провайдера должна приводить к отказу именно на нём. Проверьте это тем же чистым браузером.

Эта схема хорошо подходит там, где вы полностью контролируете сетевой путь: прокси и чат работают на одном сервере или в одной закрытой сети, а наружу смотрит только прокси. Если чат и прокси разнесены по разным местам, а сетевые правила пересматриваются редко, риск прямого обхода растёт. В таком случае OAuth/OIDC, при котором чат сам участвует в обмене с провайдером, оставляет меньше места для ошибок конфигурации.

Где всё это разместить и зачем здесь VPS

Общий чат для компании — служба, которая работает постоянно и к которой предъявляют две сетевые просьбы: быть доступной сотрудникам и не быть доступной остальным. Собственный сервер хорош тем, что вы сами решаете, какие порты открыты, где стоит прокси и какие правила применяются. Для схемы с доверенными заголовками это особенно существенно: нужно, чтобы приложение и прокси находились под вашим управлением.

VPS MAATRIX предоставляет root-доступ, диски NVMe и процессоры AMD EPYC, а виртуальный сервер создаётся автоматически через пару минут после оплаты (страница аренды VPS). Root-доступ здесь нужен практически: настройка прокси, правил сетевого доступа и отдельного внутреннего адреса для приложения требует прав на уровне системы. Среди тарифов есть Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe), Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ), Maat (8 vCPU, 16 ГБ, 240 ГБ) и Djed (16 vCPU, 32 ГБ, 320 ГБ). Для пилота с тестовыми учётными записями вполне хватит младших вариантов, но число одновременных пользователей зависит от того, что именно подключено за чатом, поэтому реальную нагрузку нужно мерить, а не угадывать по строке тарифа.

Отдельное замечание о почте: если вы строите вокруг чата собственные уведомления об изменении доступа, то те же вопросы жизненного цикла возникают и там. О связанной теме можно прочитать в материале про выделенный сервер для корпоративной почты.

Репетиция увольнения на тестовой учётной записи

Всё описанное имеет смысл только после того, как вы один раз пройдёте маршрут целиком. Вот последовательность, которую можно выполнить за час на тестовом человеке.

1. Создайте у провайдера пользователя «Тест Увольняемый» и включите его в одну рабочую группу.
2. Войдите им в чат из отдельного профиля браузера. Убедитесь, что вы видите нужные модели и материалы.
3. Оставьте эту вкладку открытой и создайте личный ключ, если ваша установка это позволяет.
4. В другом окне заблокируйте человека у провайдера. Затем уберите его из группы и измените роль или удалите аккаунт.
5. В чистом профиле браузера попробуйте новый вход: он должен быть отклонён.
6. Вернитесь к старой вкладке: отправьте сообщение, обновите страницу, откройте список моделей. Запишите результат.
7. Выполните запрос со старым ключом и посмотрите, что он вернёт.

Лучше всего повторить этот прогон при каждом изменении настроек входа, обновлении версии или смене провайдера. Тогда ваша карта состояний остаётся актуальной, а не превращается в красивую схему, которая когда-то была верна.

Старая вкладка как последняя инстанция

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

Если после блокировки, снятия групп и изменения роли эта вкладка по-прежнему отправляет сообщения и получает ответы, значит, отзыв не завершён, как бы аккуратно ни выглядели списки пользователей. Если же она теряет доступ в пределах срока, который вы считаете допустимым, и этот срок вы измерили на своей версии, а не предположили, то интеграция работает как нужно. Именно открытый браузер бывшего сотрудника отделяет красивую схему входа от настоящего завершения доступа.