В понедельник выходит новый разработчик. Ему нужны почта, VPN, Jira, GitLab, CRM, корпоративный портал, Service Desk и десяток внутренних сервисов. В идеальном мире всё это работает к девяти утра первого дня. На практике начинается переписка в чате: почту завели, в VPN пока нет, GitLab сделает DevOps, в CRM оформят завтра, в Jira забыли добавить в нужную группу.
Через неделю доступы собираются. Потом человек увольняется, и та же переписка идёт в обратную сторону, только теперь нужно вспомнить все системы, где его учётная запись вообще заводилась. Вспоминают не все.
Эту задачу решает протокол, о котором обычные пользователи не слышали никогда.
Что такое SCIM
SCIM (System for Cross-domain Identity Management) — стандарт автоматического провижининга. Он описывает, как одна система по единому REST API создаёт, меняет и блокирует учётные записи, группы и атрибуты в другой.
SCIM не программа и не сервер, который можно купить и поставить. Это протокол внутри тех продуктов, что у вас уже работают. Одна сторона отправляет команды (SCIM-клиент), другая выполняет их над пользователями и группами (SCIM-сервер). Обычно клиентом становится IAM-платформа, сервером — приложение.
Проще всего думать о нём как об обходном листе, который заполняется сам. Появился сотрудник — завести везде. Сменил отдел — переписать права. Уволился — заблокировать во всех системах. Без письма администратору и без напоминания.
Работает это через обычный HTTP и JSON:
POST /scim/v2/Users # создать пользователя
PATCH /scim/v2/Users/{id} # изменить данные или снять active
GET /scim/v2/Users # получить информацию
Никакой магии. Стандартные методы REST и схема атрибутов, о которой обе стороны договорились заранее.
Как это выглядит в компании
Источником истины остаётся кадровая система: 1С:ЗУП, БОСС-Кадровик, VK HR Tek, SAP SuccessFactors, Workday, Oracle HCM. Из неё запись уходит в IAM-платформу — Microsoft Entra ID, Okta, Keycloak, Authentik, Zitadel, Solar inRights, Avanpost IDM, Indeed Identity Manager. Дальше платформа рассылает команды по приложениям.
Получается распределительный узел. Ему безразлично, пять у вас приложений или сто двадцать: все получают одинаковые данные о человеке из одного места.
Отечественные IDM подтянулись сюда позже западных, но SCIM сегодня заявлен и в Solar inRights, и в Avanpost IDM, и в Indeed Identity Manager, и в ряде продуктов помельче. Проверять всё равно нужно руками: заявленная поддержка протокола и работающая двусторонняя синхронизация групп — разные вещи, и выясняется это на пилоте.
Отдельно стоит развести SCIM и Just-In-Time Provisioning. JIT создаёт пользователя в момент первого успешного входа, и для публичных порталов этого достаточно. Корпоративной системе нужно, чтобы учётная запись, группы и роли существовали до первого входа, а увольнение доезжало до всех приложений без участия человека. Это уже SCIM.
Пятница, приказ об увольнении
HR оформляет приказ, кадровая система отдаёт изменение в IAM, IAM рассылает команды. Через несколько секунд учётная запись выключена в почте, в Jira, в GitLab, на портале, в Service Desk. Одновременно.
Именно за это безопасники SCIM и любят. Большинство внутренних инцидентов начинается с одной фразы: «мы забыли отключить учётку». Забывчивость лечится автоматизацией лучше, чем регламентом.
А потом начинается интересное.
SCIM блокирует учетную запись, но не отзывает автоматически активные JWT, refresh-токены, API-ключи и браузерные сессии
Нужны отдельные механизмы отзыва токенов и завершения сессий
Протокол меняет состояние записи в базе. Всё, что было выпущено от имени этой записи раньше, живёт по своим правилам и своим срокам.
GitLab как учебный пример
Разработчик за два года работы создал Personal Access Token для локальных скриптов, Deploy Token для выкатки, Project Access Token в паре репозиториев, Group Access Token для общей группы, четыре SSH-ключа и Runner Registration Token, о котором забыл на следующий день.
SCIM заблокировал пользователя. Что произойдёт с этими артефактами?
Ответ зависит от приложения, а не от протокола. SCIM не описывает судьбу токенов и не обязан этого делать. Если продукт связывает выпущенные секреты с жизненным циклом учётной записи, они умрут вместе с ней. Если не связывает, часть из них доживёт до конца срока действия или до явного отзыва руками.
Хуже всего с внешними облачными сервисами, куда сотрудник заходил по корпоративной почте, но которые в вашем IDM никогда не числились. Подрядчики, сервисы подарков и льгот, трекеры, песочницы. Их не отзывает никто, потому что о них не помнит никто.
Браузер, который не заметил увольнения
Пользователь вошёл в приложение через OpenID Connect и получил access token, refresh token и сессионную куку. Учётная запись выключена. Вылетит ли он из системы?
Зависит от того, как приложение написано. Проверяет ли оно статус пользователя на каждом запросе или доверяет подписи токена. Делает ли интроспекцию. Умеет ли Back-Channel Logout. Есть ли вообще механизм глобального завершения сессий и кто имеет право его дёрнуть.
Считать здесь просто. Access token на 15 минут плюс refresh token на неделю дают уволенному человеку неделю работы в системе, если никто не отозвал refresh token отдельно. Приложение при этом ведёт себя абсолютно корректно: оно проверяет подпись, срок действия и издателя, и все проверки проходят.
SCIM, OAuth 2.0 и OpenID Connect — разные задачи
| Стандарт | Что делает |
|---|---|
| SCIM | Создаёт, меняет, блокирует и удаляет учётные записи и группы |
| OpenID Connect | Сообщает приложению, кто именно выполнил вход |
| OAuth 2.0 | Выдаёт приложению права на доступ к ресурсам |
Три стандарта закрывают три разных куска жизненного цикла цифровой личности и работают вместе. Подменять один другим не получится, хотя в презентациях вендоров они регулярно сливаются в общее слово «управление доступом».
Дорогая иллюзия контроля
Многие CISO искренне считают, что покупка тяжёлого IDM и настройка SCIM закрывают проблему мёртвых душ навсегда. Галочка в отчёте стоит, автоматизация работает, аудитор доволен.
На деле SCIM навёл порядок в базе учётных записей. Если архитектура приложений безразлична к жизненному циклу сессий, если access token живёт часами, а API-ключи разработчики выпускают себе сами и нигде не регистрируют, вы автоматизировали беспорядок и купили к нему красивую панель.
Настоящий контур закрывается там, где команда на блокировку тянет за собой отзыв выпущенных токенов и сброс сессий на уровне шлюза и самих приложений. Всё остальное — удобная функция для кадровой службы. Ваш бывший senior сохраняет доступ к репозиториям и к облаку через PAT и SSH-ключ, пока вы смотрите на зелёный статус синхронизации.
Что проверить на этой неделе
Возьмите одного человека, уволенного месяц назад, и пройдите по списку.
- Действует ли хоть один его refresh token в основных приложениях.
- Живы ли его Personal Access Token и SSH-ключи в GitLab и в системе сборки.
- Работают ли API-ключи, которые он выпускал для интеграций и скриптов.
- Остались ли сервисные аккаунты и раннеры, созданные от его имени.
- Есть ли у вас кнопка, которая завершает все его сессии разом, и кто имеет право её нажать.
- Числятся ли в вашем IDM внешние сервисы, куда он ходил по корпоративной почте.
Если хотя бы один пункт из шести отвечает «работает», SCIM у вас настроен, а отзыв доступов не настроен. Это две разные задачи, и вторую за вас не сделает ни один IDM.