SCIM и SSO для маркетинговых инструментов

Требование к SSO/SCIM поступает одним из двух способов. Иногда оно встроено в анкету по безопасности: «Поддерживает ли ваше приложение SAML 2.0 или OIDC single sign-on? Поддерживает ли оно SCIM 2.0 для автоматизированного провизионинга?». Иногда оно приходит как прямое указание от ИТ-отдела: любой вендор, работающий с персональными данными, должен проходить аутентификацию через корпоративного IdP. Никаких отдельных логинов с паролями, никаких общих учетных данных, никаких исключений.

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

Маркетинговые инструменты - сокращатели ссылок, трекеры кампаний, менеджеры UTM - проходят этот аудит сейчас, потому что маркетинговые команды обрабатывают PII на уровне событий клика. Короткая ссылка, которая регистрирует IP пользователя, user-agent и реферер, обрабатывает персональные данные. Эта обработка должна соответствовать модели доступа, управляемой IdP.

Этот пост представляет собой версию для чек-листа закупок: что требуют SSO и SCIM, где маркетинговые SaaS не справляются и пять вопросов, которые стоит задать на этапе знакомства с вендором.

TL;DR

• SAML 2.0 и OIDC обслуживают разные поколения IdP - устаревшие корпоративные системы используют SAML; современные IdP нативно поддерживают OIDC. Вендор, поддерживающий только один протокол, упускает половину рынка.
• SCIM 2.0 - это уровень провизионинга: он создает учетные записи, обновляет их и - что критически важно - депровизионирует их. JIT-провизионинг создает учетные записи при первом входе, но не депровизионирует. Для аудита требуется SCIM.
• Большинство маркетинговых инструментов ограничивают SSO корпоративным тарифом, стоимость которого на 500–2000 долларов в месяц выше базового плана. Вендоры, включающие SSO в тариф Business без доплаты, являются исключением.
• Вопросы для закупок, которые имеют значение: SAML metadata URL, SCIM endpoint URL, периодичность ротации токена носителя, задержка депровизионирования и маппинг групп IdP в роли.

SAML 2.0 и OIDC: почему они до сих пор сосуществуют

SAML 2.0, опубликованный OASIS в 2005 году, является стандартом федерации на основе XML. IdP отправляет подписанный SAML Response на URL Assertion Consumer Service (ACS) сервис-провайдера (SP); SP проверяет подпись по сертификату IdP, извлекает субъекта и утверждения атрибутов и создает сессию.

OIDC, построенный на OAuth 2.0, выполняет ту же работу с помощью JSON. IdP выдает JWT (ID token), который SP проверяет через эндпоинт JWKS провайдера идентификации.

Оба протокола сосуществуют, так как устаревшие корпоративные IdP - локальные AD FS, старые конфигурации Okta, Ping Federate - ориентированы в первую очередь на SAML. Облачные IdP, такие как Google Workspace и современный стек JumpCloud, нативно поддерживают OIDC и используют SAML как вторичный протокол. Крупные предприятия используют оба.

SP-initiated против IdP-initiated потока. SP-initiated вход является стандартом: пользователь посещает приложение, приложение перенаправляет к IdP, IdP аутентифицирует и отправляет ответ обратно. IdP-initiated пропускает редирект от SP - пользователь нажимает на плитку в дашборде Okta или Entra, и IdP отправляет утверждение напрямую в SP. Оба потока должны работать. IdP-initiated сложнее реализовать безопасно (риск инъекций типа CSRF, если SP не проверяет атрибуты привязки и назначения), и вендоры, поддерживающие только SP-initiated, потерпят неудачу, когда ИТ-отдел попытается добавить плитку приложения в корпоративный дашборд.

SCIM 2.0: уровень провизионинга

SCIM 2.0 - RFC 7644 - автоматизирует управление жизненным циклом учетных записей пользователей в SaaS-приложениях. Три основные операции:

Провизионинг: POST /Users с атрибутами пользователя. SP создает учетную запись и возвращает новый ID.

Обновления: PATCH /Users/:id с полезной нагрузкой JSON Patch - отображаемое имя, отдел, роль, за которые отвечает IdP.

Депровизионинг: DELETE /Users/:id (жесткое удаление) или PATCH /Users/:id с { "active": false } (мягкая деактивация, наиболее распространенный корпоративный паттерн).

Депровизионинг - критически важная часть для аудита. Забытые учетные записи - аккаунты бывших сотрудников, которые не были удалены, потому что ИТ-отдел забыл или вендор не поддерживает автоматизацию - являются постоянной поверхностью для взлома. Контроль A.9.2 стандарта ISO 27001 и CC6.2 стандарта SOC 2 требуют наличия документированного процесса удаления доступа. Ручной депровизионинг предсказуемо дает сбои: тикет на увольнение пропускается, учетная запись остается активной. SCIM делает депровизионинг автоматическим и проверяемым - IdP отправляет запрос на деактивацию, SP фиксирует его в логах, и этот лог является артефактом аудита.

Пробел в маркетинговых инструментах

Большинство категорий корпоративного SaaS - HR, CRM, ITSM, хостинг кода - поставляют SSO в планах, которые реально может купить команда среднего бизнеса. Маркетинговые инструменты развивались медленнее. Паттерн, который я вижу постоянно: SSO указан как функция «Enterprise», доступная на отдельном тарифе, который стоит на 500–2000 долларов в месяц дороже плана Business. Это подразумевает, что SSO - это предмет роскоши для крупных организаций, а не базовый контроль безопасности.

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

Вендоры, включающие SSO в тариф Business без отдельной доплаты, являются исключением. Среди сокращателей ссылок: Elido включает SAML/OIDC SSO и SCIM-провизионинг в план Business через WorkOS. Bl.ink включает SSO в план Team. Loops (автоматизация электронной почты) и Customer.io поставляют SSO в тарифе Business без отдельного барьера Enterprise.

Когда вендор указывает SSO только в разделе «Свяжитесь с отделом продаж для уточнения цены Enterprise», вы обрекаете себя на ручной процесс депровизионирования при каждом увольнении сотрудника до тех пор, пока этот инструмент находится в вашем стеке.

Ландшафт IdP и совместимость

На корпоративном ИТ-рынке доминируют шесть IdP:

Okta - наиболее распространенный облачный IdP в американских компаниях. Okta поддерживает SAML 2.0, OIDC и отполированный интерфейс SCIM. Наличие вендора в Okta Integration Network с подтвержденным SCIM означает, что конфигурация для ИТ-команды задокументирована и протестирована; в противном случае им придется писать кастомную интеграцию.

Microsoft Entra ID (ранее Azure AD) - выбор по умолчанию для компаний, использующих Microsoft 365. Его агент провизионинга SCIM опрашивает эндпоинт приложения - интервал по умолчанию составляет 40 минут, поэтому депровизионирование не мгновенное. Это стоит учитывать при анализе закупок.

JumpCloud поддерживает SAML 2.0 и OIDC, а также SCIM 2.0. Популярен среди компаний среднего бизнеса, которым нужен облачный каталог без локального AD.

Google Workspace использует OIDC нативно; SAML 2.0 доступен для совместимости с устаревшими приложениями. Сторонние интеграции SCIM следуют стандартному пути RFC 7644.

OneLogin поддерживает SAML 2.0 и OIDC, а SCIM добавляется сверху. Часто встречается в организациях среднего размера, которые стандартизировались до консолидации рынка Okta.

WorkOS - это платформа на стороне вендора (а не IdP для конечного пользователя), которую SaaS-приложения используют для реализации SSO и SCIM. Вендор, заявляющий «мы используем WorkOS», выражает совместимость с Okta, Entra, JumpCloud, Google и OneLogin одновременно. Интеграция SSO в Elido построена на WorkOS. Практическое значение для ИТ: если вы можете направить Okta или Entra на эндпоинт SCIM, интеграция будет работать без специфической настройки под вендора.

JIT-провизионинг против SCIM-провизионинга

Just-in-Time провизионинг создает учетную запись пользователя при первой аутентификации через SSO. Предварительный этап провизионинга не требуется; атрибуты поступают из утверждения SAML или токена OIDC.

JIT чисто решает половину задачи по провизионингу. Проблема в депровизионировании. Когда пользователь удаляется из IdP, его сессия SSO перестает работать, но учетная запись в SaaS-приложении сохраняется. Долгоживущие API-токены могут продолжать функционировать. Аккаунт будет отображаться при любом аудите активных пользователей.

Для сред ISO 27001 или SOC 2 одного JIT недостаточно. Вопрос аудита заключается не в том, «может ли этот сотрудник войти?», а в том, «есть ли проверяемая запись о прекращении доступа?». JIT не создает такую запись. SCIM создает: событие DELETE или { "active": false } логируется как у IdP, так и у SP с меткой времени и возможностью запроса.

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

Маппинг ролей: группы IdP и роли в SaaS

Стандартный паттерн прост. В IdP есть две группы, marketing-team (весь персонал) и marketing-leads (руководители команд), а в SaaS-приложении две роли (Маркетолог и Админ), поэтому ИТ-команда настраивает маппинг один раз: marketing-team соответствует Маркетологу, marketing-leads соответствует Админу. После этого к нему никто не прикасается. Когда кто-то перемещается между группами, следующая синхронизация SCIM автоматически обновляет их роль.

Членство в группах передаётся через ресурс SCIM Groups (GET /Groups, POST /Groups, PATCH /Groups/:id). Поддерживает его не каждый вендор. Некоторые реализуют только провизионинг пользователей, а значит, маппинг ролей по-прежнему требует ручной настройки для каждого пользователя, по одному аккаунту, всякий раз когда кто-то меняет команду. Уточните у вендора, поддерживается ли SCIM group push и возможна ли настройка маппинга ролей администратором без обращения в службу поддержки.

Организациям из ЕС нужно проверить ещё одну вещь. Данные о членстве в группах IdP, передаваемые через SCIM, сами по себе могут составлять персональные данные в соответствии со Статьёй 4(1) GDPR, а ваш SaaS-вендор является процессором этих данных. Ваш DPA должен это указывать. В посте о Data residency ЕС для маркетинга подробно описано, что должно быть указано об этом относительно уровня идентификационных данных.

Что спрашивать при закупке

Пять вопросов, которые определяют, будет ли интеграция SSO/SCIM маркетингового инструмента проектом на полдня или на несколько недель:

SAML metadata URL. Может ли вендор предоставить статический URL, указывающий на их метаданные SP (entity ID, ACS URL, сертификат подписи)? Это то, что вы вставляете в Okta или Entra. Ручной ввод метаданных для каждого клиента - плохой признак.

SCIM endpoint и метод аутентификации. Каков базовый URL SCIM? Токен носителя (Bearer token) является стандартом; OAuth 2.0 client credentials сложнее. Какова периодичность ротации токена? Статический токен, который никогда не меняется, является уязвимостью.

Задержка депровизионирования. Когда IdP отправляет PATCH /Users/:id { "active": false } или DELETE, как быстро прекращается доступ? Интервал провизионинга Entra по умолчанию составляет 40 минут на стороне IdP. Вендор должен гарантировать окно обработки после поступления запроса. Комбинация обеих задержек - это то, о чем спросит ваш аудитор SOC 2.

Поддержка Group push. Group push - это отдельная функция, не входящая в провизионинг пользователей через SCIM. Если вендор реализует только синхронизацию пользователей, маппинг ролей - это ручная настройка для каждого человека. Спросите об этом специально.

Поддержка IdP tile. Можно ли добавить приложение в виде плитки в дашборд Okta или Entra и поддерживает ли оно IdP-initiated вход?

Соответствие нормативным требованиям

Контроль A.9.2 Приложения A стандарта ISO 27001 требует, чтобы права доступа пользователей предоставлялись, пересматривались и прекращались в соответствии с документированным процессом. Контроль A.9.3 требует, чтобы пользователи аутентифицировались только с помощью назначенных им учетных данных. На практике SCIM - это операционный механизм, который связывает «HR-увольнение» с «аннулированием доступа в SaaS» без ручных шагов.

SOC 2 CC6.2 требует, чтобы организации регистрировали и авторизовывали пользователей перед предоставлением доступа. CC6.3 требует периодического пересмотра и удаления доступа. Лог депровизионирования SCIM - запись с меткой времени о том, когда IdP дал команду SaaS-приложению деактивировать или удалить пользователя, - является артефактом аудита, подтверждающим соответствие CC6.3 для каждого приложения в области проверки.

Elido не имеет сертификата ISO 27001, а SOC 2 находится на этапе подготовки, отчёт ещё не выдан. Подход к идентификации - SAML/OIDC через WorkOS, депровизионирование SCIM 2.0 и одна роль по умолчанию на каталог (маппинг групп на роли пока недоступен) - задокументирован на странице доверия и в резюме solutions/enterprise. Для рабочих процессов, связанных с HIPAA, BAA - отдельное соглашение на тарифах Business и Enterprise, его запрашивают на [email protected].

В основах GDPR для сокращателей ссылок подробно рассмотрены Статьи 28 и 32. SSO и SCIM - это технические контроли Статьи 32 (аутентификация через SSO, депровизионирование через SCIM), а не просто дополнительные функции. Это компоненты системы безопасности, которые ваш DPO оценивает во время проверки по Статье 32.

На странице /pricing приведена разбивка планов и указано, где доступны SSO/SCIM. Страница /solutions/compliance - это резюме для команд по закупкам. Разговор о доказательствах депровизионирования должен происходить в том же звонке по закупкам, что и обсуждение DPA, списка субпроцессоров и обязательств по локализации данных - именно эти вопросы определяют, пройдет ли маркетинговый инструмент проверку безопасности.

NIST SP 800-63-3 Digital Identity Guidelines, доступный от 2026-05-12, является авторитетной базой для уровней доверия и типов аутентификаторов, которая лежит в основе многих корпоративных требований к политикам IdP. Раздел федерации - 800-63C - напрямую относится к настройке интеграции SAML и OIDC.