Концепт «Ключ»

Вход продолжается после потери устройства. Подключение, проверка и восстановление имеют самостоятельные состояния и основания.

Концепт-проект: «Ключ» — вымышленная компания. Результатов работы здесь нет: только решения и гипотезы.

О заказчике

• Сценарий: Вход сотрудников организаций и восстановление после потери второго фактора
• Участники: Сотрудник, администратор организации и поддержка
• Граница: Один способ подключения и один согласованный путь восстановления
• Данные: Аккаунты, устройства и коды вымышлены; реальный доступ не создаётся

Задача

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

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

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

Риски исходного процесса

Настройка выглядит завершённой раньше времени

Статус меняется только после пробной проверки в проектируемом рабочем процессе.

Потерян телефон

Резервный путь и обращение в поддержку разделены и объяснены.

Поддержка получает лишние полномочия

Оператор видит состояние и основание решения, а не секреты пользователя.

Старое устройство продолжает работать

Отзыв сессий входит в отдельную проверку серверной реализации.

Решение

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

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

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

Как устроен продукт

1. Подключение. Способ подтверждения, условия и незавершённая регистрация. Зачем: Человек понимает момент включения.
2. Пробная проверка. Поле кода и отдельный результат подтверждения. Зачем: Просмотр инструкции не считается регистрацией.
3. Восстановление. Резервное средство или запрос с дальнейшим рассмотрением. Зачем: Обращение не выдаёт доступ автоматически.
4. Сессии. Контекст устройств и управляемый отзыв. Зачем: Старые входы не остаются невидимыми.

Что помогает пройти сценарий

Результат рядом с действием

На каждом шаге показано, что подтверждено и что ещё требуется.

Безопасная диагностика

Причина остановки доступна оператору без копирования секретов.

Плановая смена устройства

Замена с действующим средством отделена от полной потери доступа.

Ключевые сценарии

Подключить средство

Завершить регистрацию с пробной проверкой.

На входе: Пользователь уже прошёл согласованное подтверждение текущего доступа.

1. Открыть настройки.
2. Начать регистрацию.
3. Подтвердить владение средством.
4. Проверить итоговое состояние.

На выходе: Средство зарегистрировано по серверному подтверждению.

Если что-то пошло не так: Закрытие вкладки до проверки оставляет незавершённую настройку.

Критерий приёмки: После повторного открытия интерфейс показывает реальное состояние регистрации.

Потерять устройство

Продолжить по разрешённому резервному пути.

На входе: Основное средство недоступно; рабочей сессии нет.

1. Выбрать другой способ.
2. Предъявить разрешённое резервное средство.
3. Дождаться серверной проверки.
4. Перейти к замене потерянного фактора.

На выходе: Восстановление идёт по утверждённой процедуре.

Если что-то пошло не так: Отсутствие резервного средства ведёт к запросу в поддержку, без автоматического входа.

Критерий приёмки: Запрос восстановления сам по себе не создаёт рабочую сессию.

Отозвать прежний вход

Проверить старое устройство после смены доступа.

На входе: Доступ восстановлен и принято решение об отзыве прежних сессий.

1. Открыть список сессий.
2. Выбрать прежнее устройство.
3. Подтвердить отзыв.
4. Проверить защищённый запрос со старого клиента.

На выходе: Отозванная сессия больше не даёт доступ.

Если что-то пошло не так: Сетевая ошибка отображается как неподтверждённый результат, а не успех.

Критерий приёмки: Сервер отклоняет защищённую операцию после подтверждённого отзыва.

Роли пользователей

Сотрудник

Подключить средство и войти, не потеряв доступ к работе.

Я закончил настройку или ещё нет?

Администратор клиента

Применить политику для своей организации.

Кто готов к обязательному второму фактору?

Поддержка

Разобрать потерю средства по разрешённой процедуре.

Какое основание позволяет продолжить восстановление?

Как устроено технически

Серверная модель

Регистрация, ожидание второго фактора, сессия и отзыв реализуются самостоятельными состояниями.

Хранение и журналы

Секреты не отправляются в аналитику; права и срок хранения определяются отдельно.

Совместимость клиентов

Браузер, мобильный клиент и SSO проверяются на отсутствие обходного входа.

Проверка безопасности

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

Что входит в разработку

• Один тип пользователя и политика организации
• Подключение и пробная проверка
• Резервный путь и обращение в поддержку
• Управление сессиями и безопасный журнал

План реализации

1. Карта входов: проверяем браузер, мобильный клиент, SSO и служебные исключения.
2. Политика: определяем роли, критические действия и основания восстановления.
3. Реализация: подключение, проверка, сессии и отзыв получают серверную модель.
4. Испытания: проверяем незавершённую регистрацию, потерю средства и старые сессии.

Что замеряем после запуска

• Незавершённое подключение — Закрываем вкладку и проверяем, что фактор не включился сам.
• Граница сессии — После первого фактора защищённая операция остаётся недоступной.
• Одноразовость — Повтор использованного резервного средства не даёт новый доступ.
• Отзыв — После восстановления старое устройство следует согласованной политике сессий.

Стек

React, TypeScript, Серверная модель сессий, Адаптер аутентификации.

Все кейсы · Услуга · Калькулятор стоимости

Интерфейс и рабочие состояния

Три настольных состояния и мобильный экран авторского интерактивного прототипа. Содержание вымышленное; реальный сервер, внедрение и бизнес-результаты не заявляются.