Когда я слышу, что кто-то говорит, что они «модернизировали» приложение, это обычно означает, что они включили SAML или OIDC. Возможно, оба.
SSOделаетУпростить доступ и уменьшить трение.Но вот что меня беспокоит: слишком много команд останавливается там.Они внедряют SSO и предполагают, что трудная часть закончена.Но на практике, это когда реальная сложность начинает выходить на поверхность.
Почему «мы модернизированы» не всегда означает то, что вы думаете
Когда люди говорят мне, что их приложение модернизировано, я спрашиваю, что это действительно означает. во многих случаях это просто означает, что приложение теперь поддерживает SSO. Он все еще использует ту же внутреннюю логику сеанса.
То, что происходит здесь, более распространено, чем признают большинство: мы модернизируем переднюю дверь и оставляем остальную часть дома неизменной.
И это проблема, потому что идентичность не только о входе, это о том, что происходит после этого.
Что дает современная аутентификация
Современные протоколы аутх, такие как SAML и OIDC, были разработаны для решения реальных проблем — в основном логина и федерации.
И да, SSO через эти протоколы улучшает позицию безопасности, но давайте не будем путать удобство с полнотой.
Протоколы — это прогресс, но это не конечная линия
Не заблуждайтесь, добавление поддержки для OIDC или SAML является прогрессом. Вы получаете меньше паролей, меньше трения и более последовательный пользовательский опыт.То, что они не обеспечивают, это другие критические элементы управления, на которые мы полагались с системами управления веб-доступом (WAM): централизованный контроль сеанса, осуществление авторизации, интеграция каталогов и последовательное управление политикой.
Системы WAM не были идеальными, но они дали нам последовательный слой управления по всем приложениям.Когда мы удалили их, не заменяя этот слой, мы потеряли что-то важное — и я видел последствия из первых рук.
Приложение не является современным, если личность все еще твердо зашифрована
Я видел приложения, которые выглядят стройно на поверхности, но по-прежнему полагаются на хрупкую, специфическую для разработчика идентичность.В этих случаях добавление SSO не устраняет реальный риск — несовместимое поведение в приложениях и средах.
Некоторые команды по-прежнему используют устаревшие библиотеки сеансов. Другие жестко кодируют правила доступа таким образом, что аудит становится кошмаром.
Где все распадается: управление сессиями
Одним из крупнейших слепых точек идентичности в модернизированных средах является управление сессиями.Люди полагают, что SSO заботится об этом, но это не так.
С помощью WAM поведение сеансов — временные отсрочки, обновления, отзывы — обрабатывалось в одном месте. Вы могли бы применить изменение политики и знать, что оно будет действовать на всей компании.
Я работал с командами, использующими Spring, Node.js, Rails — и даже в рамках одной рамки нет гарантии последовательности.Каждое приложение заканчивается собственной конфигурацией, своими особенностями и собственными пробелами в безопасности.
Неспособность применять последовательные временные рамки сеанса представляет собой огромный риск, если они не могут отозвать сеансы, когда происходит что-то подозрительное.
Стоимость децентрализованной сеансовой логики
Когда исправление библиотек сеансов занимает недели или месяцы, или никто не знает, где определены временные промежутки времени, безопасность становится реактивной в лучшем случае.
Я видел, что компании борются только с тем, чтобы проследить, как работает их обработка сеансов.Это стало племенным знанием, скрытым глубоко в коде приложения.
Это не является устойчивым, особенно для предприятий, которые имеют дело с соблюдением или целями нулевого доверия.
Развитие идентичности и авторизация дрейфа
То же самое, что происходит с логикой сеанса, происходит с авторизацией.После того, как она будет перемещена в код приложений, централизованное управление становится практически невозможным.
Правила затаиваются в бизнес-логике.Политики дрейфуют.И в конце концов, никто точно не знает, кто имеет доступ к чему — или почему.Даже приложения, которые поддерживают современную аутентификацию, могут потерпеть неудачу здесь, потому что AuthZ не является частью протокола.
Оркестрация должна быть следующей
На данный момент я думаю, что это ясно: современная аутентификация - это всего лишь часть головоломки.
Преимущества использования оркестрации включают:
- Возврат возможности немедленно отменить сеансы
- Применение политики сеанса и authZ последовательно
- Управление ключами и сертификатами федерации с одного места
- Интеграция с сигналами риска (например, CAEP) для поддержки нулевого доверия
- И делать все это без перезаписи приложений или переключения провайдеров идентификации
Оркестрация преодолевает разрыв между «современной поддержкой протокола» и реальной модернизацией идентичности.
Централизация не означает отступление
Иногда люди полагают, что возвращение контроля над личностью в одно место — это шаг назад, но это не то, о чем идет речь.
Речь идет о том, чтобы обеспечить гибкость. О том, чтобы дать командам безопасности необходимую видимость, не замедляя разработчиков. О том, чтобы управлять идентификацией как услугой — а не как серией хаков, специфических для приложений.
Когда у вас нет оркестрации, каждая проблема с идентичностью становится разовым решением.
Если я разговариваю с командой по безопасности, я обычно задаю такой вопрос: «Как быстро можно отменить сеансы пользователя?через каждое приложение в вашем предприятии«Сейчас?»
Если ответ что-то меньше, чем «немедленно», есть проблема, которую стоит решить.
The takeaway: не останавливайтесь на SSO
Я скажу это ясно: современная аутентификация необходима, но она неполна.Если вы остановитесь на SSO, вам не хватает уровня управления, который заставляет все остальное работать — безопасно, последовательно и в масштабе.
Так что да, примите SAML. Запустите OIDC. Но не позволяйте логин-коробке быть финишной линией.
Если вы хотите реальной безопасности, оркестрация должна быть частью путешествия.
О авторе
Даррен Платт возглавлял инженерные команды в Securant Technologies, Ping Identity, Simplified, RSA и Oracle. теперь он является вице-президентом по управлению продуктами и инженерии в Strata Identity, где он строит первую распределенную платформу Identity Orchestration для распределенных сред и вносит свой вклад в новый стандарт оркестрации политики, IDQL и его справочное программное обеспечение Hexa.
