суббота, 11 июля 2026 г.

SCIM: технология, которая автоматически создает и удаляет учетные записи сотрудников

Каждый специалист по информационной безопасности хотя бы раз сталкивался с этой ситуацией. В компанию выходит новый сотрудник. Ему нужны:

  • корпоративная почта;
  • VPN;
  • Jira;
  • GitLab;
  • CRM;
  • корпоративный портал;
  • система Service Desk;
  • десяток внутренних приложений.

В идеальном мире все это должно работать уже в первый рабочий день. На практике же начинается знакомый квест.

— «Почту уже сделали?»
— «В VPN пока нет.»
— «GitLab создаст DevOps.»
— «CRM оформят завтра.»
— «В Jira забыли добавить в нужную группу.»

Через несколько дней доступы наконец появляются. А потом сотрудник увольняется… И начинается второй квест — только теперь нужно вспомнить все системы, где существовала его учетная запись.

Именно здесь на сцену выходит технология, о которой обычные пользователи почти никогда не слышат: SCIM.


Что такое SCIM?

SCIM (System for Cross-domain Identity Management) — это стандарт автоматизированного Provisioning (провижининга) пользователей. Он позволяет IAM-платформам синхронизировать учетные записи, группы и атрибуты между кадровыми системами и корпоративными приложениями по унифицированному REST API. SCIM важен в тех организациях, где требуется централизованное управление всем жизненным циклом учетных записей.

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

«Появился новый сотрудник? Создать его везде.»
«Изменился отдел? Обновить права.»
«Сотрудник уволился? Заблокировать учетную запись во всех системах.»

И сделать это автоматически. 

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

Как выглядит архитектура?

Допустим, в компании есть:

  • Кадровая система (HRIS) в виде 1С:ЗУП, БОСС-Кадровик, VK HR Tek, SAP SuccessFactors, Workday, Oracle HCM
  • IAM / Identity Platform в виде Microsoft Entra ID, Okta, Keycloak, Authentik, Zitadel, Solar inRights, Avanpost IDM, Indeed Identity Manager
  • Jira
  • GitLab
  • Microsoft 365

Выглядит это примерно так:

Место Keycloak может занимать любой IDM: Entra ID, Okta,  Indeed IDM, Avanpost IDM

SCIM становится своеобразным распределительным узлом. Ему совершенно неважно, сколько приложений используется в компании. Пять, двадцать или сто. Все они получают одинаковую информацию о пользователях.

Какие российские продукты работают со SCIM?

Поддержка SCIM постепенно появляется и в отечественных решениях класса IAM/IDM. Наиболее известные продукты:

  • Solar inRights;
  • Avanpost IDM;
  • Indeed Identity Manager.

Представьте обычную компанию

Допустим, HR оформил нового разработчика. В кадровой системе появляется запись:

Иван Петров
Backend Developer
Отдел разработки

И через несколько секунд SCIM начинает свою работу.

Он сообщает корпоративным сервисам:

  • создать пользователя;
  • указать имя;
  • назначить корпоративную почту;
  • добавить в группу Developers;
  • выдать необходимые роли.

В результате еще до первого входа сотрудника уже готовы:

✅ Почта
✅ Jira
✅ GitLab
✅ VPN
✅ Wiki
✅ Service Desk

Все произошло без участия администратора.

Кстати, мы привыкли что на публичных порталах работает Just-In-Time Provisioning, когда пользователь создается в момент первого успешного входа.  JIT подходит для B2C-сервисов и небольших организаций, где сервис доступа всего один. SCIM нужен корпоративным системам, где учетные записи, группы и роли должны быть подготовлены заранее, а изменения в правах и увольнения автоматически синхронизироваться между десятками приложений.

А что происходит при увольнении?

Вот здесь начинается самое интересное. Представьте, что сотрудник увольняется в пятницу вечером и HR оформляет приказ. Через несколько секунд SCIM отправляет команды: "Заблокировать пользователя". И это происходит одновременно во всех системах.

  • Не нужно писать администраторам.
  • Не нужно открывать десятки консолей.
  • Не нужно искать забытые сервисы.
  • Все отключается автоматически.

Именно поэтому специалисты по информационной безопасности любят SCIM.

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

⚠️ Важный нюанс

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

Например, после увольнения могут оставаться действительными:

  • JWT Access Token;
  • Refresh Token;
  • OAuth Device Token;
  • Personal Access Token (PAT);
  • API Key;
  • SSH-ключи;
  • сертификаты клиента;
  • сервисные аккаунты и агенты, созданные пользователем;
  • долгоживущие сессии в браузере.

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

Особенно интересный пример — GitLab

Допустим разработчик создал:

  • Personal Access Token;
  • Deploy Token;
  • Project Access Token;
  • Group Access Token;
  • SSH Keys;
  • Runner Registration Token.

SCIM заблокировал пользователя.

Но вопрос: Что произойдет с этими токенами?

Ответ зависит от самого приложения. 

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

Еще интереснее — браузер

Представим, что пользователь вошел через OpenID Connect.

У него уже есть:

  • Access Token
  • Refresh Token
  • Session Cookie

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

  • проверяет ли оно статус пользователя при каждом запросе;
  • использует ли интроспекцию токенов;
  • есть ли механизм глобального завершения сессий;
  • поддерживается ли Back-Channel Logout или Front-Channel Logout в OIDC;
  • каков срок жизни access token и refresh token.

Если access token действует 15 минут, а refresh token можно использовать неделю, то без дополнительных механизмов пользователь может продолжать работать до истечения срока действия токена или до момента, когда приложение попытается обновить сессию.

Что именно умеет SCIM?

На самом деле возможностей больше, чем кажется. SCIM умеет:

  • создавать пользователей;
  • изменять их данные;
  • блокировать учетные записи;
  • удалять пользователей;
  • создавать группы;
  • управлять членством в группах;
  • изменять атрибуты сотрудников;
  • синхронизировать изменения между системами.

Причем делает это через обычный REST API. Например:

POST /Users (Создать пользователя)
PATCH /Users (Изменить данные)
GET /Users (Получить информацию)

Никакой магии. Обычный HTTP, JSON и стандартные методы REST.

SCIM — это не OAuth и не OpenID Connect

ТехнологияЧто делает
SCIMСоздает, изменяет и удаляет учетные записи
OpenID ConnectСообщает приложению, кто выполнил вход
OAuth 2.0Выдает права доступа 

Они работают вместе.

Какие системы поддерживают SCIM?

Сегодня практически все крупные корпоративные продукты умеют работать с этим стандартом.

Почему это важно для информационной безопасности?

Если посмотреть на большинство инцидентов, связанных с внутренними пользователями, то многие начинаются одинаково: «Мы забыли отключить учетную запись.» Именно человеческий фактор остается главным источником подобных ошибок. SCIM практически устраняет эту проблему.

Когда кадровая система становится единственным источником истины (Source of Truth), все остальные приложения автоматически получают актуальную информацию.

Ушел сотрудник — доступ исчезает. Перевели в другой отдел — меняются группы и роли. Сменил фамилию — обновляются атрибуты. Все происходит централизованно.

Где SCIM особенно полезен?

Чем больше организация, тем сильнее ощущается эффект. Если в компании используется:

  • Microsoft 365;
  • Jira;
  • GitLab;
  • VPN;
  • CRM;
  • корпоративный портал;
  • десятки внутренних сервисов,

то ручное управление доступами превращается в постоянную головную боль. SCIM позволяет превратить этот хаос в управляемый автоматический процесс. Именно поэтому его поддержка сегодня считается практически обязательной функцией любой современной системы управления идентификацией (IAM).

Заключение

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

В связке с OAuth 2.0 и OpenID Connect стандарт SCIM закрывает последнюю важную задачу жизненного цикла цифровой личности — автоматическое управление учетными записями. А для специалистов по информационной безопасности это означает меньше ручной работы, меньше ошибок и значительно более высокий уровень контроля над корпоративными доступами.

И важно помнить про проблему с отзывом доступов

Многие CISO искренне верят, что покупка тяжелого IDM и настройка SCIM закрывает проблему «мертвых душ» раз и навсегда. Галочка в отчете стоит, автоматизация работает.

На практике SCIM просто наводит порядок в базе данных. Если ваша архитектура приложений плевать хотела на жизненный цикл сессий, если Access Token живет часами, а API-ключи создаются разработчиками бесконтрольно — никакой SCIM вас не спасет. Вы просто автоматизировали бардак.

Настоящая безопасность начинается там, где SCIM-команда на блокировку мгновенно триггерит отзыв всех выпущенных токенов и сброс сессий на уровне Gateway и самих приложений. Всё остальное — удобная фича для HR, а не защита контура. Вы покупаете дорогую иллюзию контроля, пока ваши уволенные синьоры сохраняют доступ к Git и AWS через PAT и SSH-ключи.

on
Ярлыки: