Почему растет наценка за безопасность в тарифах SaaS

При этом речь идет не о редкой корпоративной функции, а о поддержке стандартных протоколов централизованной аутентификации — прежде всего SAML 2.0 и OIDC.

Так появляется парадокс: технически SSO может быть одной из базовых возможностей современного SaaS, но коммерчески его нередко оставляют только в самом дорогом плане. Для небольшой команды это выглядит как необязательная премиум-функция. Для компании с десятками сервисов, требованиями к управлению доступом и регулярными проверками безопасности — уже как обязательный платеж.

Важно разделять две вещи. SSO не делает сервис безопасным автоматически и не заменяет все остальные меры защиты. Но оно позволяет централизовать вход, MFA, жизненный цикл учетных записей и часть аудита. Поэтому вопрос о цене SSO — это не только вопрос удобства авторизации. Это вопрос того, сколько стоит управляемость собственной облачной инфраструктуры.

Что такое SSO Tax: экономика дискриминационного ценообразования

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

Типовая схема выглядит так:

• вендор предлагает недорогой тариф для небольших команд;
• локальная аутентификация и базовые настройки доступа доступны сразу;
• подключение SAML или OIDC ограничено старшим планом;
• вместе с SSO клиент получает и другие корпоративные функции: расширенный аудит, более широкую поддержку, управление ролями, договорные гарантии или увеличенные лимиты;
• итоговая цена растет значительно сильнее, чем расходы на саму обработку входа.

На практике это означает, что клиент платит не только за протокол. Он платит за право использовать корпоративную модель управления доступом внутри конкретного продукта и за весь набор функций, к которому вендор привязал SSO.

SAML и OIDC — открытые стандарты. Их поддерживают распространенные провайдеры идентификации, включая Okta, Auth0, Azure AD и Keycloak. Но из этого не следует, что добавление SSO в коммерческий продукт ничего не стоит. Вендору нужно реализовать и поддерживать не только редирект пользователя на IdP, но и обработку ошибок, маппинг атрибутов, управление доменами, привязку учетных записей, журналы событий, документацию и совместимость с разными конфигурациями клиентов.

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

Поэтому наценку за SSO в тарифах SaaS корректнее рассматривать не как прямую стоимость нескольких строк кода, а как часть ценовой стратегии. Вендор отделяет команды, которым достаточно локальных учетных записей, от компаний, для которых централизованное управление идентичностями становится условием закупки.

У такой стратегии есть несколько коммерческих мотивов:

• разделить рынок по платежеспособности и масштабу;
• подтолкнуть растущие команды к Enterprise-тарифу;
• включить SSO в пакет корпоративных функций, за которые клиент платит в совокупности;
• повысить средний чек без изменения основного продукта;
• усилить зависимость клиента от платформы, если перенос учетных записей и политик доступа требует значительной работы.

SSO Tax — это не отдельный счет за протокол, а способ превратить управление доступом в признак корпоративного тарифа.

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

Разрыв между себестоимостью и ценником: реальные затраты на SAML-федерацию

Оценка Clerk для базовой SAML-федерации называла инфраструктурные расходы на уровне около $0.015 за активного пользователя в месяц. В такой оценке учитываются типичные операции, связанные с обработкой федерации:

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

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

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

Именно здесь в исходных сравнениях часто появляется методологическая ошибка. Если базовый тариф GitHub стоит $4 за пользователя в месяц, а корпоративный план — $21, разница составляет $17. Для HubSpot в приведенном примере разница между планами составляет $130. Но из этих сумм нельзя вычесть $0.015 и получить маржу конкретного вендора на SSO. Мы не знаем, какая часть разницы приходится на федерацию, какая — на поддержку, лимиты, управление, аналитику или другие возможности Enterprise.

Корректнее представить картину так:

Из таблицы следует не то, что вендор получает $16.985 или $129.985 «за SSO». Такой вывод был бы чрезмерным. Следует другое: стоимость базовой обработки федерации может быть небольшой по сравнению с розничной разницей между планами, но цена продукта определяется более широким набором факторов.

К дополнительным затратам вендора относятся:

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

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

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

Безопасность как привилегия: как наценка влияет на защищенность бизнеса

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

Но при корректной настройке SSO меняет точку управления доступом. Вместо десятков независимых форм входа компания использует корпоративный IdP как общий слой идентификации. Это дает несколько типичных эффектов:

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

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

То же относится к MFA. Политика многофакторной аутентификации в IdP распространяется на вход через IdP, но не обязательно покрывает:

• локальные учетные записи, созданные до внедрения SSO;
• сервисные аккаунты;
• персональные токены и API-ключи;
• аварийные административные учетные записи;
• интеграции, которые используют отдельный механизм авторизации.

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

Compliance-аудит также не делает SSO обязательным сам по себе. SOC 2, ISO 27001 и PCI DSS ориентированы на наличие и работу соответствующих контролей: управление доступом, MFA в применимых сценариях, разделение полномочий, журналирование, отзыв прав и регулярные проверки. Эти задачи можно частично решать без SSO, используя локальные механизмы конкретного SaaS. Однако без централизованной аутентификации обычно сложнее доказать единообразие политик и собрать подтверждения по всем приложениям.

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

Цена отказа от Enterprise в таком случае может выражаться не только в счете от вендора. Компания получает более сложную операционную модель:

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

Последний пункт связан с shadow IT. Если корпоративный сервис неудобен или его подключение занимает слишком много времени, сотрудники могут завести личные аккаунты на альтернативной платформе. Это не прямое следствие отсутствия SSO, но высокая цена безопасной конфигурации повышает вероятность обходных решений. Данные оказываются в сервисах, которые не входят в реестр, а учетные записи не контролируются корпоративным IdP.

Цена человеческого фактора: ручное управление доступом без SSO

Главный аргумент в пользу SSO для большинства компаний — не экономия на серверных ресурсах. Это сокращение количества ручных операций и точек, в которых администратор может ошибиться.

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

Типовые операции выглядят так:

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

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

Это принципиальное различие между SSO и полноценным identity lifecycle management:

Особенно важно не путать SSO с автоматической ротацией credentials. SSO может избавить пользователя от необходимости знать локальный пароль SaaS, но оно не ротирует автоматически API-ключи, секреты интеграций, сервисные пароли и учетные данные, которые приложение использует вне интерактивного входа. Даже локальные аварийные аккаунты могут требовать отдельного процесса смены паролей.

Оценивать экономию нужно на собственных операциях, а не обещать универсальный процент. Допустим, в компании 100 сотрудников, 30 SaaS-сервисов и текучесть 15% в год. Если для одного увольнения требуется около двух часов ручной работы, то 15 увольнений дают примерно 30 часов в год только на этот сценарий. Это заметная нагрузка, но она сама по себе не подтверждает, что ручной процесс обходится компании в сумму, сопоставимую с годовой наценкой крупного Enterprise-тарифа.

К этим 30 часам могут добавляться переводы сотрудников между командами, временные доступы, проверки лицензий, разбор исключений и работа с токенами. Но считать их нужно отдельно. На итог влияют ставка специалиста, число реальных операций, качество автоматизации через API и то, сколько сервисов действительно участвует в процессе увольнения.

Практическая модель расчета может быть простой:

1. Составить перечень приложений, где учетные записи отключаются вручную.

2. Замерить время на увольнение, перевод и подключение одного пользователя.

3. Посчитать частоту таких операций за год.

4. Отдельно учесть расследования ошибок и повторные проверки.

5. Сравнить получившуюся сумму не только с Enterprise-тарифом, но и со стоимостью внедрения, сопровождения и контроля SSO.

Такой расчет даст более честный ответ, чем абстрактное обещание «сэкономить 80% трудозатрат». Иногда SSO действительно сокращает рутину в разы. Иногда основная проблема находится не во входе, а в отсутствии SCIM, API или нормальной модели ролей у самого SaaS.

Масштабы проблемы: что показывают сравнения тарифов

Сравнения, собранные в каталогах цен на SSO, показывают, что единая логика у рынка отсутствует. В одних сервисах федерация включена в относительно доступный план, в других ее связывают с Enterprise-пакетом. Где-то разница между планами объясняется целым набором корпоративных функций, а где-то SSO оказывается одним из немногих заметных отличий.

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

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

В доступных рыночных сравнениях медианная наценка оценивается примерно в +150%. Это не универсальная ставка для всех SaaS и не норматив рынка. На нее влияют состав выборки, способ расчета и то, какие функции включены в сравниваемые планы. Поэтому медиану разумно использовать как ориентир для поиска аномально дорогих предложений, а не как точную формулу бюджета.

На размер разницы обычно влияют несколько факторов:

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

Последний фактор особенно важен. Чем глубже SaaS встроен в процессы, тем меньше значение имеет формальная цена альтернативы. Миграция может потребовать переноса данных, перестройки интеграций, обучения пользователей и повторной настройки ролей. Вендор понимает эту зависимость и может удерживать корпоративные функции в дорогом плане: клиент сравнивает не $17 или $130 на пользователя, а риск масштабного перехода на другую платформу.

В такой ситуации SSO становится частью vendor lock-in. Не потому, что сам протокол невозможно перенести, а потому, что вокруг него формируется связка из доменов, групп, ролей, журналов, автоматизации и процессов администрирования. Чем больше этих элементов завязано на конкретного поставщика, тем дороже отказаться от его Enterprise-условий.

Как проверять цену безопасности до покупки

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

Для каждого SaaS полезно зафиксировать:

• поддерживает ли он SAML, OIDC или оба протокола;
• можно ли отключить локальный вход;
• передаются ли группы и атрибуты;
• есть ли SCIM или API для жизненного цикла пользователей;
• как отзываются сессии и токены;
• какие события попадают в журнал;
• можно ли отправлять их в SIEM;
• защищены ли сервисные аккаунты и аварийные учетные записи;
• какие роли доступны администраторам;
• входят ли аудит и экспорт логов в тот же тариф;
• есть ли ограничения по числу доменов, IdP или пользователей.

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

При закупке полезно разделять цену трех компонентов:

1. Федерация входа. Пользователь проходит аутентификацию через корпоративный IdP.

2. Управление жизненным циклом. Учетные записи и группы создаются, изменяются и удаляются автоматически.

3. Контроль и расследование. Компания получает журналы, отчеты, интеграции с SIEM и инструменты проверки действий.

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

Требования стоит формулировать до переговоров, а не после получения счета. Если сервис используется для финансовых операций, HR-процессов, разработки или работы с клиентскими данными, отсутствие федерации может быть архитектурным риском. Но это не означает, что любой сервис без SSO нужно немедленно исключить. Для некритичного приложения приемлемым вариантом может стать отдельная политика паролей, обязательная MFA, ограничение числа администраторов и регулярный ручной аудит.

Enterprise-переговоры тоже не сводятся к просьбе «убрать SSO Tax». Вендору можно предъявить более предметную позицию:

• сравнить его условия с сервисами, где SSO уже включен в базовый тариф;
• запросить перечень функций, которые формируют разницу между планами;
• разделить стоимость федерации, аудита и поддержки;
• попросить включить SSO в текущий план при долгосрочном контракте;
• зафиксировать возможность пересмотра тарифа при росте числа пользователей;
• уточнить, какие скидки действуют для годовой оплаты и консолидации лицензий;
• проверить, не продается ли нужная функция отдельно в составе add-on.

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

Безопасность не должна быть скрытой премией

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

У бизнеса в этом случае есть три параллельные задачи.

Первая — не приписывать SSO свойства, которых у него нет. Оно не обеспечивает автоматическую ротацию всех учетных данных, не отзывает само по себе API-ключи и не делает compliance выполненным. Для этого нужны отдельные процессы и инструменты.

Вторая — считать совокупную стоимость владения. В цену отсутствия SSO входят не только ручные часы, но и вероятность забытых аккаунтов, задержки при увольнении, сложность аудита и риск появления shadow IT. В цену Enterprise входят не только SSO, но и остальные функции пакета. Сравнивать нужно именно эти совокупности.

Третья — не принимать тарифную модель вендора как архитектурный закон. При выборе новых сервисов можно отдавать приоритет поставщикам, которые включают федерацию в базовый или средний план, а для существующих продуктов — заранее оценивать стоимость миграции и переговоров. Иногда дешевле заменить сервис. Иногда разумнее заплатить за старший тариф, если миграция затронет критичные процессы. Решение должно следовать из рисков и операционной модели, а не из лозунга о том, что любая наценка за SSO незаконна или технически бессмысленна.

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

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