Краткие выводы
Архитектура идентификации в Salesforce — это не разовый технический проект, а постоянно действующий контрольный слой: кто входит, с какой идентификацией, с какими разрешениями, и что происходит, когда доступ к системе больше не требуется. Выбор между SAML и OIDC, JIT и SCIM, а также между политикой MFA на уровне поставщика идентификации (IdP) и внутренней принудительной проверкой в Salesforce — все это кажется деталями конфигурации, но фактически определяет, сколько времени потребуется для блокировки доступа уволенного сотрудника и какая часть таких инцидентов будет обнаружена только при аудите.
Правильный подход начинается не с протокола, а с двух вопросов: кто является источником истины для идентификации пользователя и каково максимально допустимое время между событием прекращения работы (Offboarding) и фактической блокировкой доступа. Отсюда вытекают все остальные решения — тип федерации, метод управления учетными записями (Provisioning), политика сессий и процесс аварийного доступа (Break Glass).
Организации, которые также рассматривают вопрос о самих разрешениях, а не только об аутентификации, найдут дополнительную информацию в модели разрешений Salesforce.
Карта решений: четыре слоя идентификации в Salesforce
| Слой | Вопрос, который необходимо решить | Основные опции | Что может выйти из строя при неправильном решении |
|---|---|---|---|
| Федерация и аутентификация | Кто является поставщиком идентификации (IdP) и как Salesforce доверяет ему | SAML 2.0, OIDC, делегированная аутентификация | Двойной вход, несоответствие атрибутов, нарушение доверия |
| Управление учетными записями (Provisioning) и жизненный цикл | Как пользователь создается, обновляется и удаляется | JIT Provisioning, SCIM, ручное создание | Устаревшие учетные записи, доступ, сохраняющийся после увольнения |
| Сессия и MFA | Где применяется уровень аутентификации и продолжительность сессии | MFA в IdP, внутренний MFA в Salesforce, политики сессий | Обход MFA через альтернативный путь, сессия, которая никогда не истекает |
| Аварийный доступ (Break Glass) и аудит | Что происходит, если SSO выходит из строя, и кто проверяет аномалии | Контролируемый аварийный пользователь, история входов, мониторинг событий | Полная зависимость от IdP, невозможность ретроспективного расследования |
SAML против OIDC: не вопрос "что новее"
Выбор между двумя протоколами не должен основываться на тенденциях, а на существующей инфраструктуре. SAML работает с XML и подписанными утверждениями (Assertions), и распространен в организациях с Active Directory Federation Services или давним IdP, который уже используется десятками других систем. OIDC построен поверх OAuth 2.0, проще в обслуживании и особенно удобен, когда тот же IdP должен обслуживать как современных потребителей API, так и вход пользователей.
Распространенная ошибка — выбирать по принципу "что выглядит более продвинуто", не проверяя, какие атрибуты уже отправляет существующий IdP и как они соотносятся с Salesforce (имя пользователя, ID федерации, профиль, группа наборов разрешений). Неправильное сопоставление атрибутов на этапе настройки часто приводит к ручной коррекции десятков пользователей в производственной среде, а не просто к изменению конфигурации.
Важный момент: даже при выборе OIDC или SAML, стоит отдельно планировать IdP-инициированный и SP-инициированный вход. Некоторые распространенные инциденты безопасности возникают из-за того, что SP-инициированный вход остается открытым, хотя весь процесс входа был запланирован только через портал IdP.
JIT Provisioning против SCIM: когда "в момент входа" недостаточно
JIT (Just-In-Time) Provisioning создает или обновляет пользователя в Salesforce во время первого входа, согласно данным, поступающим от IdP в SAML Assertion или OIDC Token. Это удобно, недорого в реализации и достаточно для большинства организаций, где пользователи регулярно входят в систему.
Проблема: JIT не решает проблему деактивации (Deprovisioning). Если сотрудник удален из IdP, но больше не входит в систему, его пользовательская учетная запись остается активной в Salesforce неограниченное время, потому что нет события, которое вызывает обновление. Именно здесь вступает в силу SCIM (System for Cross-domain Identity Management) — он обеспечивает централизованную, инициируемую синхронизацию от IdP к Salesforce, включая немедленную деактивацию при удалении пользователя в источнике.
Практическое правило: если у организации есть требование к удалению учетной записи (Offboarding) в течение часов, а не дней — для подрядчиков, временных сотрудников, доступа к конфиденциальным данным — SCIM является не "приятным дополнением", а требованием соответствия. Если текучесть кадров низкая и управление уже включает ежеквартальный обзор доступов, одного JIT может быть достаточно при условии, что он сопровождается документированным ручным процессом для немедленной блокировки.
Планирование управления учетными записями (Provisioning) всегда должно рассматриваться также в контексте сложности автоматизации вокруг него — например, когда задействованы потоки (Flow), выполняющие логику распределения разрешений во время создания пользователя, где актуально сравнение Flow против Apex в отношении того, где целесообразен настраиваемый код.
MFA и политика сессий: два слоя, а не один
Распространенная ошибка — ограничиться MFA, принудительно применяемым поставщиком идентификации, и полагать, что он охватывает все пути входа в Salesforce. На практике, пока существует пользователь, который может войти напрямую через login.salesforce.com — например, интеграция, пользователь API или администратор, имеющий резервный доступ — требуется отдельная политика MFA, настроенная внутри самой Salesforce (Identity Verification, Session Security Levels).
Кроме того, политика сессий определяет важные, но легко упускаемые моменты: Session Timeout, «Force logout on session timeout», Login IP Ranges, и "High Assurance Session" обязательны для чувствительных операций (например, изменение разрешений или массовый экспорт данных). Организация, которая настраивает сильный MFA, но оставляет Session Timeout по умолчанию в два часа, открывает окно, в котором украденный компьютер сохраняет активный доступ гораздо дольше разумного времени.
Аварийный доступ (Break Glass) и аудит: когда SSO выходит из строя, кто входит
Полная зависимость от внешнего поставщика идентификации (IdP) создает единую точку отказа: если IdP выходит из строя или существует ошибка в конфигурации федерации, никто не может войти, включая тех, кто должен устранить проблему. Принятое решение — пользователь аварийного доступа (Break Glass) — учетная запись суперпользователя с независимой аутентификацией (не зависящей от SSO), паролем, хранящимся в сейфе (Vault), а не в памяти человека, и отдельным MFA.
Важно различать: аварийный доступ (Break Glass) — это не "удобная лазейка", а контролируемый механизм экстренного реагирования. Его использование должно вызывать автоматическое оповещение и проверяться в течение одного рабочего дня тем, кто не является его пользователем. Многие организации правильно настраивают пользователя, но забывают о текущем контроле — пароль не меняется, а его разрешения слишком широки по умолчанию.
Организационный сценарий: сбой Offboarding в средней страховой компании
Предположим, страховая компания с примерно 600 сотрудниками, использующая Okta в качестве поставщика идентификации (Identity Provider) и конфигурацию SAML с Salesforce, созданную около трех лет назад. Управление учетными записями (Provisioning) полностью основано на JIT: когда новый сотрудник входит в систему в первый раз, для него создается пользовательская учетная запись с профилем (Profile) и группой наборов разрешений (Permission Set Group) в соответствии с группой Okta, к которой он принадлежит.
В одном случае сотрудник службы поддержки был уволен в пятницу днем. Команда ИТ немедленно деактивировала его в Okta. Однако, поскольку не было механизма SCIM или веб-хука, который синхронизировал бы деактивацию с Salesforce, его пользовательская учетная запись оставалась активной там — и поскольку его сессия уже была активна с утра и не была настроена опция "Force logout on session timeout", он продолжал получать доступ к системе даже после увольнения, пока кто-то не заметил это при еженедельном обзоре доступа в понедельник.
Решение, которое было реализовано, не было полным переходом на SCIM (что потребовало бы отдельного проекта и бюджета на интеграцию), а немедленное объединение трех действий: активация "Force logout on session timeout" для всех конфиденциальных профилей, сокращение времени ожидания сессии (Session Timeout) со 120 минут до 30 минут для клиентских ролей, и добавление автоматического шага в процесс корпоративного Offboarding, который выполняет прямую деактивацию в Salesforce как самостоятельное действие, а не только как косвенный результат деактивации в Okta. SCIM оставался целью на следующий квартал, уже с бюджетом и одобрением, но наиболее опасный пробел был устранен в течение недели.
Распространенные риски и профилактические меры
| Риск | Как это выглядит на практике | Профилактическая мера |
|---|---|---|
| Полная зависимость от JIT без деактивации | Уволенные пользователи остаются активными неограниченное время | Добавление независимого шага Offboarding в Salesforce, не зависящего от синхронизации |
| MFA только в IdP | Пользователи интеграции и администраторы обходят MFA через прямой вход | Внутренняя политика MFA в Salesforce для всех типов пользователей |
| Слишком долгий Session Timeout | Украденный компьютер или забытая открытая сессия сохраняет доступ часами | Сокращение времени ожидания (Timeout) и принудительный выход (Force Logout) для чувствительных профилей |
| Break Glass без контроля | Использование экстренной учетной записи не обнаруживается вовремя | Автоматическое оповещение и проверка в течение одного рабочего дня для каждого использования |
| Неправильное сопоставление атрибутов из IdP | Пользователь получает неверный профиль (Profile) или роль (Role) при первом входе | Полная проверка сопоставления в среде Sandbox перед изменением в производственной среде |
Контрольный список для создания или аудита архитектуры идентификации
- ☐ Определен единственный поставщик идентификации (Identity Provider) как источник достоверных данных, и известно, что происходит при его сбое.
- ☐ Протокол (SAML или OIDC) выбран на основе существующей инфраструктуры, а не тенденций.
- ☐ Отображение атрибутов между IdP и Profile/Permission Set Group проверено в Sandbox.
- ☐ Определена четкая политика: только JIT, или JIT в сочетании с SCIM в соответствии с требованием к процедуре увольнения (Offboarding).
- ☐ MFA принудительно применяется внутри Salesforce, а не только в IdP.
- ☐ Session Timeout и Force Logout настроены в соответствии с чувствительностью профиля.
- ☐ Существует контролируемый пользователь Break Glass с отдельным MFA и паролем в хранилище.
- ☐ Процесс Offboarding включает самостоятельный шаг для деактивации в Salesforce.
- ☐ Login History и Event Monitoring проверяются по установленному расписанию.
- ☐ Существует план периодической проверки (Access Review), который не зависит только от памяти ИТ-отдела.
Как оценить эффективность архитектуры
Основной показатель — это не "работает ли SSO", а время реакции между событием в источнике достоверных данных и соответствующим изменением в Salesforce: сколько времени проходит между удалением пользователя в IdP и его фактической деактивацией. Дополнительный показатель — это доля входов, осуществляемых по непредвиденному пути (прямой вход вместо входа через IdP), которая должна стремиться к нулю, за исключением документированных Break Glass. Третий показатель — это частота пересмотра разрешений по сравнению с текущим состоянием — не каждое организационное изменение проходит через IdP, поэтому ежеквартальный пересмотр остается необходимым даже при полной автоматизации управления учетными записями (Provisioning).
Для внедрения или аудита архитектуры идентификации в существующей среде Salesforce можно воспользоваться услугой по архитектуре CRM. Организации, которые также рассматривают связь с ERP и кадровыми системами как часть общей картины идентификации, найдут дополнительную информацию в интеграции Salesforce с ERP и более широкое представление об архитектуре в руководстве по архитектуре CRM.
Заключение
Архитектура идентификации в Salesforce создается единожды, но ежедневно проверяется на наличие отдельных инцидентов: уходящий сотрудник, сессия, которую забыли закрыть, интеграция, обходящая MFA. Ключевые решения (SAML против OIDC, JIT против SCIM, двойной MFA, контролируемый Break Glass) не должны зависеть от конфигурации IdP по умолчанию, а должны определяться временем, необходимым для блокировки доступа, и уровнем чувствительности раскрываемой информации. Организация, которая планирует этот слой заранее, вместо того чтобы обнаруживать пробелы при аудите или после инцидента безопасности, экономит как на затратах на исправление, так и снижает репутационный и регуляторный риски.