Интеллектуальный анализ процессов аутентификации: новая дисциплина CIAM

1. Введение#

Ключи доступа двигают CIAM вперед. Лучшие в своем классе команды начинают инструментировать путь входа от начала до конца, классифицировать ошибки, которые они никогда раньше не регистрировали, и впервые смотреть на клиентскую телеметрию. Подавляющее большинство команд по управлению идентификацией еще не достигло этого: нет реального уровня наблюдаемости аутентификации, нет графа событий для каждой сессии, нет данных о клиентской церемонии. Попытки, успехи и неудачи на стороне сервера все еще составляют всю картину.

Интеллектуальный анализ процессов аутентификации — следующий логичный шаг, но только после того, как появятся базовые данные о событиях. Без уровня наблюдаемости нечего анализировать. С ним становится доступной новая дисциплина. Она напрямую заимствована из интеллектуального анализа бизнес-процессов, который в 2010-х годах превратил необработанные журналы событий ERP в оптимизированные рабочие процессы. Применительно к идентификации она сравнивает спроектированный путь входа с реальным, выявляет пути отклонения, а затем устраняет разрыв с помощью детализированной step-up аутентификации, правил подавления или изменений UX, которые измеряются от начала до конца.

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

1.1 На какие вопросы отвечает эта статья#

В этой статье мы рассматриваем следующие вопросы:

1. Что сделал интеллектуальный анализ процессов для BPM, и какова прямая параллель для аутентификации?
2. Почему развертывание ключей доступа выявило этот пробел, и почему журналов аутентификации никогда не было достаточно самих по себе?
3. Как на самом деле выглядит модель событий интеллектуального анализа процессов аутентификации от начала до конца?
4. Как интеллектуальный анализ процессов связан с детализированной step-up аутентификацией и авторизацией?
5. Что это означает для ландшафта поставщиков CIAM и для команд по идентификации, у которых уже есть IDP?

2. Что интеллектуальный анализ процессов сделал для BPM#

2.1 От журналов событий к оптимизированным процессам#

Интеллектуальный анализ бизнес-процессов возник из понимания того, что каждая ERP, CRM или система обработки заявок записывает журналы событий, которые после реконструкции показывают фактический рабочий процесс, а не тот, что описан в вики. Заказ на покупку, который должен был пройти через трех утверждающих, в 40% случаев обходил двух из них. Процесс подачи претензий, который был задокументирован как прямая линия, в 18% случаев зацикливался сам на себе пять раз. Инструменты интеллектуального анализа процессов, подобные тем, что популяризировала Celonis, восстанавливали эти графы из событий с временными метками и позволяли операторам задать новый вопрос: где реальный процесс отклоняется от спроектированного, и сколько стоит это отклонение?

2.2 Параллель в аутентификации#

Аутентификация имеет ту же структуру. Каждый вход в систему — это последовательность событий с временными метками: страница загружена, идентификатор введен, запрос выбран, биометрия запрошена, утверждение возвращено. Структурная параллель точна. Практическая разница в том, что в отличие от ERP или CRM, эти данные событий еще не живут в ваших журналах IDP — по крайней мере, в той детализированной форме, которая нужна для интеллектуального анализа процессов. IDP записывают результаты входа и используемый метод. Они не записывают клиентскую церемонию: вызов Conditional UI, биометрические запросы, выбор менеджера учетных данных, скрытый отказ до того, как запрос вообще достигнет сервера. Этот уровень, предшествующий утверждению, должен быть инструментально оснащен на уровне frontend SDK и собран в граф для каждой сессии до того, как к нему можно будет применить интеллектуальный анализ процессов.

Как только данные появятся, применяются те же методы: спроектированный путь ключа доступа против реального, спроектированный путь восстановления против реального, спроектированный step-up против реального. Академическая дисциплина вокруг этой работы созревает. Полезной отправной точкой является Манифест интеллектуального анализа процессов от Целевой группы IEEE по интеллектуальному анализу процессов, который определяет проверку соответствия, анализ вариантов и улучшение как три основных метода. Каждый из них один к одному отображается на аутентификацию.

3. Почему внедрение ключей доступа выявило пробел#

3.1 Ключи доступа заставляют команды переосмыслить логирование на фронтенде#

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

Именно из-за этого сдвига многие команды сейчас переосмысливают то, как они логируют поведение на стороне клиента. Без инструментария на фронтенде они не могут увидеть, почему пользователи уходят, какие шаги они предпринимают перед входом в систему или что на самом деле произошло, когда попытка входа не была завершена. Журналы сервера показывают только отсутствие, а не причину. Смотрите наш глубокий разбор наблюдаемости аутентификации для получения полной таксономии событий.

3.2 Разрыв между спроектированным и реальным путем#

Как только команды получили клиентские события, они смогли увидеть нечто новое: спроектированный путь ключа доступа (зайти на страницу входа, увидеть кнопку ключа доступа, нажать, пройти аутентификацию, готово) использовался примерно 30% подходящих пользователей. Остальные 70% уходили в сторону через поля пароля, социальный вход, магические ссылки или вообще отказывались от входа. Это проблема интеллектуального анализа процессов, а не проблема логирования. Никакое количество дополнительных кодов ошибок WebAuthn само по себе не сократило бы этот разрыв.

3.3 Почему журналов аутентификации никогда не было достаточно#

Журналы аутентификации сами по себе говорят вам о результатах. Они не говорят вам о путях. Уровень успешного входа в 92% по всем методам может скрывать 40% отказов на пути ключей доступа и 15% отказов на пути паролей, в итоге выглядя как "нормально". Интеллектуальный анализ процессов отвергает это усреднение. Он настаивает на рассмотрении каждого варианта отдельно, а затем ранжировании вариантов по частоте, стоимости и уровню отказов.

4. Как на самом деле выглядит интеллектуальный анализ процессов аутентификации#

4.1 Модель событий: Процессы, События и Классификация результатов#

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

Метаданные процесса. Каждый процесс имеет идентификатор процесса и временную метку. Он привязан к приложению, ОС, браузеру и бренду устройства. Он помечается категорией посетителя (реальный пользователь, ручной тестировщик, автоматический тестировщик, еще не классифицирован), чтобы автоматизацию и бот-трафик можно было отсеять до вычисления любой метрики. Он также несет оценку процесса и количество событий, которые являются двумя простейшими сигналами для "насколько сложной была эта конкретная сессия".

Инициация входа. Каждый процесс записывает, как был запущен поток. Основные типы инициации: text-field (пользователь ввел свой идентификатор), one-tap (сохраненный идентификатор был использован повторно) и cui (Conditional UI отобразил учетные данные без явного нажатия кнопки). Инициация — это измерение, а не метрика: одно и то же развертывание может выглядеть совершенно по-разному в когорте cui и в когорте text-field, и усреднение по ним скрывает именно то поведение, которое должен выявить интеллектуальный анализ процессов.

Классификация результатов. Вместо "успеха" или "неудачи" результатом является один из нескольких классов, соответствующих определенному поведению. Пример для ключей доступа:

• completed - церемония завершена, и пользователь аутентифицирован.
• filtered-explicit-abort - пользователь увидел запрос и явно отменил его.
• filtered-implicit-abort - пользователь ушел или истекло время ожидания без принятия решения.
• filtered-passkey-intel - уровень клиентского интеллекта намеренно подавил путь ключа доступа, как правило, потому что известно, что комбинация устройства и ОС не работает.
• filtered-no-start - поток так и не продвинулся дальше начального шага.
• not-loaded - поверхность аутентификации так и не загрузилась до конца.

Церемония добавления (создания учетных данных) имеет параллельную классификацию, включая случай completed-exclude-credentials, когда у пользователя уже есть учетные данные.

Уровни воронки и инвентаря. Поверх процессов имеют значение два агрегированных уровня. Уровень воронки распределяет процессы с течением времени по результатам, инициации, статусу завершения, ОС и приложению как для входа, так и для добавления. Уровень инвентаря учетных данных группирует существующие ключи доступа по статусу синхронизации (синхронизировано или нет), транспорту (internal, hybrid, usb, nfc, ble, smart-card), аутентификатору (Apple, Google Password Manager, iCloud Keychain, Windows Hello, 1Password, Bitwarden, Dashlane, YubiKey), ОС и браузеру. Без уровня инвентаря невозможно спросить, сосредоточен ли данный вариант отклонения на конкретном менеджере учетных данных или состоянии синхронизации.

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

4.2 Счастливый путь против Анализа отклонений#

После того, как события сохраняются в виде направленного графа для каждой сессии, вы можете задать вопрос интеллектуального анализа процессов: какой процент сессий следует счастливому пути, и для тех, которые этого не делают, каковы пять основных вариантов отклонений, ранжированных по частоте? В наших аналитических данных пять лучших вариантов обычно составляют 85% всех отклонений. Исправление двух из них обычно улучшает показатели больше, чем любое A/B-тестирование на счастливом пути.

4.3 Обнаружение дрейфа когорт#

Варианты дрейфуют. Обновление браузера, выход новой версии ОС, изменение менеджера учетных данных могут сделать ранее незначительный вариант внезапно доминирующим. Обнаружение дрейфа когорт — это дисциплина наблюдения за распределением вариантов в когорте устройство/ОС/браузер с течением времени, вместо того чтобы смотреть только на совокупный уровень успеха. Именно так команды отлавливают тихие регрессии за часы, а не за кварталы.

5. От интеллектуального анализа процессов к детализированному Step-up#

5.1 Почему Step-up недостаточно используется#

Step-up аутентификация существует уже более десяти лет. Она использовалась недостаточно, потому что большинство команд повышают уровень одинаково независимо от риска: принудительно запрашивают OTP для каждой транзакции выше определенного порога. Это грубое правило, а не решение с оценкой риска. Оно создает трения для 95% легитимных ценных транзакций, чтобы остановить 5% подозрительных.

5.2 Пути с оценкой рисков#

Благодаря данным интеллектуального анализа процессов вы можете непрерывно оценивать сессию. Репутация устройства, базовый уровень успеха когорты, аномалии времени суток, отклонение от собственного исторического пути пользователя, идентификация менеджера учетных данных, репутация IP. Оценка риска затем управляет детализированным решением о step-up аутентификации: требовать второй фактор только тогда, когда оценка риска сессии превышает порог ценности транзакции. Сессии с низким риском для ценных транзакций проходят. Сессии с высоким риском для транзакций с низкой ценностью проходят через step-up аутентификацию.

6. Что это значит для ландшафта поставщиков CIAM#

6.1 Проектирование путей как специализированная дисциплина#

Исторически индустрия идентификации объединяла проектирование путей внутри IDP. Механизмы оркестрации внутри Okta, Ping, ForgeRock, Auth0 и других позволяют настраивать потоки. Чего они не делают хорошо, так это не наблюдают за ними. Это несоответствие открывает пространство для специализированного аналитического уровня.

6.2 Почему ни один IDP не поставит это нативно#

Поставщики IDP оптимизируют уровень управления: кто может войти в систему, с какими учетными данными, в соответствии с какой политикой. Интеллектуальный анализ процессов — это дисциплина уровня данных: каждое событие в масштабе нормализуется по комбинациям ОС/браузера/менеджера учетных данных. Объем событий, кардинальность и базовые показатели по всем клиентам — все это работает против нативной сборки IDP. Посмотрите полевые заметки в нашем руководстве «купить или создать ключи доступа» для того же паттерна, примененного к уровню SDK.

6.3 Уровень аналитики как новая категория#

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

7. Как Corbado помогает с интеллектуальным анализом процессов аутентификации#

Corbado предоставляет уровень измерений и принятия, который находится поверх существующих IDP. Он интегрируется с Okta, Auth0, Ory, ForgeRock и пользовательскими стеками, не заменяя их. То, что он добавляет, — это именно возможность интеллектуального анализа процессов:

• Сквозная таксономия событий. Клиентский SDK фиксирует всю церемонию от загрузки страницы до утверждения, включая события, предшествующие идентификатору, вызов Conditional UI и выбор менеджера учетных данных.
• Анализ вариантов из коробки. Платформа реконструирует графы путей для каждой когорты и ранжирует варианты отклонений по частоте, возможности восстановления и стоимости.
• Оповещение о дрейфе когорт. Когда распределение вариантов смещается для конкретной ОС, браузера или менеджера учетных данных, платформа сигнализирует об этом до того, как это станет проблемой второго дня.
• Базовые показатели по различным развертываниям. Поскольку Corbado агрегирует анонимизированные данные по клиентским средам, новые ошибки или регрессии, выявленные в одном развертывании, классифицируются и документируются до того, как они достигнут вашего. Посмотрите почему Corbado для понимания полного подхода.
• Обратная связь в оркестрацию. Решения о step-up аутентификации на основе оценки риска и правила подавления могут быть переданы обратно в IDP или обработаны на уровне принятия, включая динамические аварийные выключатели и подталкивания (nudging), специфичные для когорты.

8. Заключение#

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

О Corbado

Corbado — это Passkey Intelligence Platform для CIAM-команд, обеспечивающих аутентификацию пользователей в крупных масштабах. Мы показываем то, что не видят логи IDP и общие инструменты аналитики: какие устройства, версии ОС, браузеры и менеджеры учётных данных поддерживают passkey, почему регистрации не превращаются в логины, где сбоит WebAuthn-поток и когда обновление ОС или браузера тихо ломает вход — всё это без замены Okta, Auth0, Ping, Cognito или вашего собственного IDP. Два продукта: Corbado Observe добавляет наблюдаемость для passkey и любых других способов входа. Corbado Connect даёт managed passkey со встроенной аналитикой (рядом с вашим IDP). VicRoads использует passkey для более чем 5 млн пользователей с Corbado (+80 % активации passkey). Поговорить с экспертом по passkey →

FAQ#

Что такое интеллектуальный анализ процессов аутентификации?#

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

Чем это отличается от аналитики аутентификации?#

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

Почему внедрение ключей доступа делает эту дисциплину необходимой?#

Внедрение ключей доступа — первая причина, по которой команды CIAM вообще инструментируют клиентские события. Как только эти события начинают существовать, агрегированные метрики скрывают слишком много: уровень успеха в 92% может маскировать уровень отказов в 40% на пути ключей доступа. Интеллектуальный анализ процессов отвергает это усреднение и заставляет команды рассматривать варианты отдельно.

Как интеллектуальный анализ процессов связан со step-up аутентификацией?#

Step-up аутентификация работает лучше всего, когда она оценивается по риску, а не основывается на правилах. Интеллектуальный анализ процессов предоставляет доказательства на уровне сессии (базовый уровень когорты, отклонение от исторического пути пользователя, репутация устройства), что позволяет механизму step-up принимать детализированное решение, а не грубое решение на основе порога.

Будет ли мой IDP поставлять это нативно?#

Вряд ли в ближайшей перспективе. IDP оптимизируют уровень управления. Интеллектуальный анализ процессов — это дисциплина уровня данных с высоким объемом событий и высокой кардинальностью по комбинациям ОС, браузера и менеджеров учетных данных. Этот паттерн совпадает с тем, что мы видим сегодня на уровне SDK, о чем говорится в нашем руководстве по выбору между покупкой и разработкой.

Что в первую очередь должна измерить команда CIAM?#

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