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

1. Введение: операционная реальность корпоративных ключей доступа для сотрудников#

Ключи доступа (passkeys) пришли в корпоративную среду. Вопрос больше не в том, «работает ли эта технология?». Теперь вопрос звучит так: «как нам управлять этим в больших масштабах?». Точки трения сместились на операционный уровень: проблема «курицы и яйца» при начальной регистрации, разница между привязанными к устройству и синхронизируемыми ключами доступа, межплатформенная совместимость и механизмы восстановления, которые не возвращают нас к небезопасному паролю.

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

1. В чем разница между привязанными к устройству и синхронизируемыми ключами доступа в Entra ID?
2. Как выполнить начальную настройку ключей доступа для новых сотрудников без использования паролей?
3. Как пользователи могут восстановить доступ, если они купили новый телефон и потеряли доступ к своему аутентификатору?
4. Какие ошибки в конфигурации приводят к сбоям при регистрации ключей доступа?
5. Как управлять гостевыми пользователями B2B, если требуется MFA, устойчивая к фишингу?
6. Следует ли использовать аппаратные ключи безопасности (YubiKey) или мобильные ключи доступа?
7. Как работать с устройствами на базе macOS наряду с Windows при развертывании ключей доступа?
8. Какие упреждающие меры предотвратят перегрузку службы поддержки при замене телефонов?

2. Понимание ключей доступа в Microsoft Entra#

В Entra «ключи доступа» = учетные данные FIDO2/WebAuthn. Вместо пароля пользователь доказывает владение закрытым ключом, хранящимся в аутентификаторе. Это устойчиво к фишингу, потому что WebAuthn привязывает учетные данные к реальному источнику входа (так что похожий фишинговый сайт не сможет их перехватить). Ознакомьтесь с обзором Microsoft в документации по концепциям ключей доступа (FIDO2).

Entra фактически поддерживает два «режима» ключей доступа, которые ведут себя по-разному.

2.1 Ключи доступа, привязанные к устройству, в Entra#

Эти ключи доступа привязаны к одному физическому устройству (не синхронизируются). Закрытый ключ существует на определенном аппаратном элементе (TPM на ноутбуке, Secure Element на YubiKey). Он не подлежит экспорту.

В Entra концепция привязки к устройству обычно означает:

• Ключи доступа Microsoft Authenticator
• Ключи доступа Windows Hello или Windows Hello for Business (WHfB) (не синхронизируются по состоянию на январь 2026 г.)
• Ключи безопасности FIDO2 (аппаратные ключи, такие как YubiKey)
• Смарт-карты

Базовое руководство Microsoft по настройке ключей доступа, привязанных к устройству, можно найти здесь: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2

Сценарии использования: Доступ с высокими привилегиями, учетные записи экстренного доступа («break-glass»), среды с общими рабочими станциями. Недостаток: Высокое трение. Потеря устройства означает потерю учетных данных. Высокие операционные затраты (например, доставка YubiKey).

2.2 Синхронизируемые ключи доступа в Entra#

Это ключи доступа, хранящиеся в экосистеме провайдера и синхронизируемые между устройствами пользователя (например, iCloud Keychain, Google Password Manager или сторонние провайдеры). Закрытый ключ шифруется и хранится в инфраструктуре синхронизации облачного провайдера.

По состоянию на январь 2026 года в Entra синхронизируемые ключи доступа обрабатываются через функцию предварительной версии (preview): Синхронизируемые ключи доступа (предварительная версия). Для включения и контроля синхронизируемых ключей доступа Entra использует Профили ключей доступа (предварительная версия).

Соответствие нормативным требованиям: Недавно было подтверждено Приложением 1 к NIST SP 800-63B как соответствующее требованиям AAL2. Это огромная регуляторная победа, подтверждающая, что синхронизируемые ключи доступа достаточно «устойчивы к фишингу» для общего использования сотрудниками.

Сценарии использования: Офисные сотрудники, пользователи BYOD, удобство для руководителей. Недостаток: «Более низкий» уровень гарантии по сравнению с аппаратными ключами. Зависимость от безопасности процесса восстановления учетной записи облачного провайдера.

Ниже представлен обзор поддерживаемых Entra провайдеров синхронизируемых ключей доступа:

На странице «Сведения о безопасности» пользователя (Security Info) четко различаются синхронизируемые ключи доступа и ключи, привязанные к устройству. Ниже вы можете увидеть, как отображаются синхронизируемый ключ доступа (от 1Password) и привязанный к устройству ключ доступа (YubiKey 5C NFC):

2.3 Нормативное согласование: уровни NIST AAL#

• AAL3 исторически требовал аппаратных, привязанных к устройству аутентификаторов (таких как YubiKey или смарт-карты), которые используют неэкспортируемый закрытый ключ.
• Уровень AAL2 теперь может быть достигнут с помощью синхронизируемых ключей доступа согласно руководству NIST.
• Нюанс: Хотя синхронизируемые ключи доступа (например, в iCloud) отлично подходят для обычных пользователей, они могут нестрого соответствовать требованию AAL3 о «невозможности экспорта» для самых высоких уровней привилегий. Поэтому необходима сегментированная стратегия: Аппаратные ключи для администраторов (AAL3), Синхронизируемые ключи доступа для сотрудников (AAL2).

2.4 Требования к готовности устройств#

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

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

Помимо минимальных требований к версии, поддержка возможностей на стороне браузера также различается в зависимости от платформы. Согласно анализу возможностей WebAuthn клиентов Corbado Passkey Benchmark 2026, поддержка браузерами в 1 квартале 2026 года составляет 97–100 % для Conditional Get и гибридного транспорта, но только 83–92 % для Conditional Create в типичном наборе потребительских браузеров — ограничение, которое сильнее всего сказывается на Windows, поскольку Windows Hello не поддерживает путь Conditional Create, а браузер Edge в частности сообщает об очень низкой поддержке Conditional Create в том же наборе данных. Бенчмарк охватывает развертывания B2C, ориентированные на потребителей, а не корпоративные среды, но те же самые ограничения возможностей браузера/ОС по-прежнему применимы к развертываниям Entra ID; организации с большим количеством пользователей Edge могут оказаться значительно ниже смешанного диапазона 83–92 % для Conditional Create.

2.5 Рекомендации по учетным данным для персонажей пользователей#

Microsoft рекомендует применять подход к развертыванию учетных данных, основанный на персонажах пользователей. Различные роли имеют разные требования к безопасности и допустимые уровни трения:

Портативные учетные данные (могут использоваться на разных устройствах):

Локальные учетные данные (специфичные для устройства):

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

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

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

3.1 Операционный сдвиг#

«Проблемы заключаются не в технологическом стеке, а на операционном уровне.» Это подтверждает, что технические препятствия, такие как ошибки «Ключ доступа не зарегистрирован» или невидимость параметров Windows Hello на личных устройствах, являются не уникальными аномалиями, а системными точками трения, присущими текущему уровню зрелости экосистемы. Для корпоративных операций ключом является разделение ожидаемых и непредвиденных сбоев при мониторинге. Явно классифицируйте ошибки WebAuthn и отслеживайте NotAllowedError, AbortError и ошибки ключей доступа Credential Manager как отдельные сигналы. Наш playbook по аналитике аутентификации предоставляет фреймворк для классификации этих сигналов, а аналитика ключей доступа охватывает специфические для ключей доступа KPI, такие как показатели активации и входа.

3.2 Регистрация: момент «пан или пропал»#

Регистрация — самый сложный этап развертывания, требующий значительных усилий по управлению изменениями.

• Сложность предварительной регистрации: Регистрация новых сотрудников, у которых нет никаких предыдущих учетных данных, является основным узким местом. Зависимость от регистрации при посредничестве администратора создает разрозненный пользовательский опыт.
• Фрагментация платформ: «Разочарование пользователей шагами» из-за независимых итераций браузеров, операционных систем и менеджеров паролей. Это приводит к временным несоответствиям, когда процесс работает в Chrome/Windows, но дает сбой в Safari/macOS или дает сбой на неуправляемых личных устройствах, но успешно выполняется на корпоративных.

3.3 Пробел в ментальной модели#

«Пользователям нужна не криптография, им нужна ментальная модель». Путаница в терминологии создает когнитивную нагрузку:

• Passkey (Ключ доступа)
• Security Key (Ключ безопасности)
• Hardware Key (Аппаратный ключ)
• YubiKey
• passwordless (без пароля)
• Windows Security (Безопасность Windows)
• Windows Hello
• Windows Hello for Business (WHfB)
• Microsoft Authenticator
• Phone Sign-in (Вход с телефона)

Для технически не подкованных или даже подкованных пользователей различия между этими терминами не очевидны.

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

3.4 Ограничения коммуникации#

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

4. Глубокое погружение в конфигурацию Microsoft Entra ID#

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

4.1 Политика методов аутентификации (Authentication methods policy)#

Устаревшие порталы MFA и SSPR упразднены. Вся конфигурация FIDO2 должна выполняться в единой вкладке Политика методов аутентификации.

• Метод ключа безопасности FIDO2: Он должен быть включен и нацелен. Рекомендуется выбрать «Все пользователи» для включения, но контролировать применение через Conditional Access.
• Ограничения ключей (AAGUID): Каждое устройство FIDO2 (например, YubiKey 5 NFC, Microsoft Authenticator на iOS, Google Password Manager) имеет уникальный идентификатор аттестации аутентификатора (AAGUID). В качестве передовой практики для сред с высоким уровнем безопасности используйте настройку «Обеспечить ограничения ключей» (Enforce Key Restrictions), чтобы разрешить (Allow) только определенные утвержденные AAGUID. Это не позволит пользователям регистрировать дешевые, непроверенные ключи безопасности «серого рынка».

4.2 Аттестация: критическая точка принятия решений#

Одним из самых важных решений в конфигурации является «Обеспечить аттестацию» (Enforce Attestation).

• Что это делает: Заставляет аутентификатор криптографически подтвердить свою марку и модель для Entra ID во время регистрации.
• Конфликт: Синхронизируемые ключи доступа (хранящиеся у таких программных провайдеров, как iCloud Keychain, Bitwarden или Google Password Manager) обычно не поддерживают аттестацию, потому что они основаны на программном обеспечении и не зависят от платформы. Они не могут подписать вызов с помощью сертификата аппаратной партии.
• Компромисс:
  • Установлено на ДА (YES): Требуется для высокого уровня гарантии (AAL3). Гарантирует, что ключ привязан к аппаратному обеспечению. Блокирует программных провайдеров ключей доступа.
  • Установлено на НЕТ (NO): Разрешает синхронизируемые ключи доступа. Немного снижает уровень гарантии (AAL2). Разрешает программных провайдеров ключей доступа.

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

• Профиль A (Администраторы): Обеспечить аттестацию = Да (Yes)
• Профиль B (Обычный персонал): Обеспечить аттестацию = Нет (No)

4.3 Объяснение профилей ключей доступа (Passkey Profiles)#

Думайте о Профилях ключей доступа как о механизме определения:

• «Эти пользователи могут использовать синхронизируемые ключи доступа»
• «Эти пользователи должны использовать только привязанные к устройству»
• «Аттестация требуется против не требуется» (и, следовательно: синхронизируемые ключи доступа разрешены против исключены)
• «Ограничить определенными типами аутентификаторов (ограничения AAGUID)»

Ниже вы можете увидеть страницу настроек ключей доступа (FIDO2) в центре администрирования Microsoft Entra, где вы настраиваете профили ключей доступа:

При редактировании профиля ключа доступа вы можете настроить применение аттестации, целевые типы (привязанные к устройству, синхронизируемые или оба) и определенные ограничения AAGUID:

4.4 Условный доступ (Conditional Access) и надежность аутентификации#

Применение может осуществляться с помощью политик Conditional Access (CA) с использованием Надежности аутентификации (Authentication Strengths).

• Надежность MFA, устойчивой к фишингу: Эта встроенная надежность требует FIDO2, Windows Hello for Business (WHfB) или аутентификацию на основе сертификатов (CBA).
• Ловушка блокировки: Если вы создадите политику CA, которая требует «MFA, устойчивую к фишингу» для «Всех облачных приложений» и примените ее ко «Всем пользователям», вы немедленно заблокируете всех пользователей, которые еще не зарегистрировали ключ доступа. Они даже не смогут войти в систему, чтобы зарегистрировать его.
• Парадокс «Регистрации сведений о безопасности»: Это специфическое действие пользователя в CA. Если вы требуете MFA, устойчивую к фишингу, для выполнения действия Регистрация сведений о безопасности (Register Security Information), вы создаете круговую зависимость (проблема курицы и яйца). Пользователь не может зарегистрировать свой первый ключ доступа, потому что ему нужен ключ доступа для доступа к странице регистрации.

Вот обзор того, какие методы аутентификации соответствуют каким требованиям к надежности:

4.5 Предпочтительная для системы аутентификация#

Функция «Предпочтительная для системы многофакторная аутентификация» в Entra ID заставляет механизм входа запрашивать у пользователя наиболее безопасный из зарегистрированных методов.

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

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

4.6 Особенности macOS: Platform SSO#

Для организаций со смешанными средами Windows/macOS macOS Platform SSO предоставляет эквивалент Windows Hello for Business от Apple. В сочетании с решениями MDM вы можете достичь:

• Учетных данных, привязанных к устройству и Secure Enclave на Mac
• Опыта SSO в нативных и веб-приложениях
• Устойчивой к фишингу аутентификации, которая соответствует требованиям AAL2/AAL3

Примечание: Для macOS Platform SSO требуется macOS 13+ и правильная настройка MDM. Установка существенно отличается от Windows WHfB, поэтому планируйте отдельные направления развертывания.

5. Распространенные ошибки конфигурации: почему «это работает только с Microsoft Authenticator»#

Если ваша цель — синхронизируемые ключи доступа на неуправляемых устройствах, вот наиболее частые блокираторы:

5.1 Синхронизируемые ключи доступа не включены/не нацелены#

Недостаточно просто включить «FIDO2» в Entra. Для синхронизируемых ключей доступа обычно требуется:

• Путь к функции предварительной версии, описанный в разделе Синхронизируемые ключи доступа (предварительная версия)
• Конфигурация профиля с использованием Профилей ключей доступа

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

5.2 Применяется аттестация (блокирует синхронизируемые ключи доступа)#

Это вызывает больше всего вопросов в организациях, заботящихся о безопасности:

• Entra может требовать аттестацию для некоторых сценариев ключей доступа (помогает проверить тип/происхождение аутентификатора)
• Синхронизируемые ключи доступа не поддерживают аттестацию в Entra, поэтому, если аттестация обязательна, регистрация синхронизируемых ключей доступа не удастся, и у вас останутся только варианты с привязкой к устройству

5.3 Белый список AAGUID блокирует провайдеров#

Entra позволяет вам ограничивать список разрешенных аутентификаторов (часто через белые/черные списки AAGUID). Если вы добавляете в белый список только Microsoft Authenticator (или узкий набор аутентификаторов), сторонние синхронизируемые провайдеры могут быть неявно заблокированы. Путаница заключается в том, что локальная аутентификация (например, Touch ID, Face ID, биометрическое сканирование Windows) работает, но страница входа Entra затем отображает ошибку.

5.4 Conditional Access принудительно устанавливает определенные типы ключей доступа#

Даже если ключи доступа включены, Conditional Access может фактически заставить пользователей использовать подмножество методов (например, «только Authenticator» или конфигурация надежности, которая не допускает предполагаемый профиль ключей доступа). На практике это создает «зависимость от Authenticator» даже в том случае, когда планируются синхронизируемые ключи доступа.

5.5 Гости B2B против учетных записей участников#

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

6. Операционные проблемы и решения#

6.1 Парадокс начальной настройки#

Самая распространенная проблема («Регистрация — самая сложная часть») — это проблема загрузки: Как безопасно выдать учетные данные с высоким уровнем гарантии пользователю, у которого в настоящее время нет учетных данных (или есть только учетные данные с низким уровнем гарантии)?

6.1.1 Temporary Access Pass (TAP)#

Temporary Access Pass (TAP) — это архитектурный подход к подключению без пароля.

• Что это такое: Ограниченный по времени (например, 1 час) код доступа с высокой энтропией, который Entra ID рассматривает как метод «строгой аутентификации». Он устраняет необходимость в пароле или существующей MFA.
• Рабочий процесс:
  1. Проверка личности: Личность нового сотрудника проверяется (например, через процесс HR или проверку менеджером).
  2. Выпуск: Администратор (или автоматизированное Logic App) генерирует TAP для пользователя.
  3. «Магический» вход: Пользователь переходит на aka.ms/mysecurityinfo. Он вводит свое имя пользователя и TAP.
  4. Регистрация: Поскольку TAP удовлетворяет требованию «Строгая аутентификация», пользователю предоставляется доступ к вкладке Security Info. Он нажимает «Добавить метод» и регистрирует свой ключ доступа.
  5. Установившееся состояние: Срок действия TAP истекает. Теперь у пользователя есть учетные данные, устойчивые к фишингу. Он ни разу не вводил пароль.

6.1.2 Автоматизация с помощью Graph API#

Для крупных организаций ручная выдача TAP немасштабируема. Передовая практика — автоматизировать это с помощью Microsoft Graph API.

• Сценарий: Новый сотрудник обрабатывается в системе HR (Workday/SuccessFactors).
• Триггер: Событие подготовки инициирует Azure Logic App.
• Действие: Logic App вызывает POST-запрос к Graph API /users/{id}/authentication/temporaryAccessPassMethods.
• Доставка: TAP безопасно доставляется руководителю пользователя или на личную электронную почту (в зашифрованном виде) для доступа в первый день.

6.1.3 Microsoft Entra Verified ID для подключения с высоким уровнем гарантии#

Для удаленного подключения или сценариев, требующих высокого уровня гарантии личности, Entra Verified ID от Microsoft с функцией Face Check предоставляет путь регистрации, ориентированный в первую очередь на отказ от паролей:

1. Подтверждение личности: Новый пользователь подтверждает свою личность через партнера IDV (сканирование удостоверения личности государственного образца).
2. Биометрическое сопоставление: Face Check сравнивает живое селфи с фотографией в документе, удостоверяющем личность, с помощью Azure AI Vision. Передается только оценка достоверности совпадения (без необработанных биометрических данных).
3. Выдача подтвержденных учетных данных: Пользователь получает учетные данные Verified ID.
4. Выдача TAP: После успешной проверки система выдает Temporary Access Pass.
5. Начальная загрузка ключа доступа: Пользователь регистрирует свой первый ключ доступа с помощью TAP.

Процесс Face Check проводит пользователей через три шага: Проверка (обмен учетными данными), Подтверждение (выполнение сканирования лица) и Просмотр (результат совпадения):

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

6.2 Проблема замены телефона (скрытая проблема масштабирования)#

Это часто является самым большим источником звонков в службу поддержки при развертывании ключей доступа. Организации с большим количеством пользователей BYOD (например, более 10 000 устройств) могут получить огромное количество звонков в службу поддержки только от пользователей, получающих новые телефоны и не знающих процесс перерегистрации методов аутентификации.

Когда вы добавляете сюда ключи доступа, это становится еще более критичным, потому что:

• Пользователи устанавливают приложения (например, Outlook) на свой новый телефон
• Эти приложения запрашивают аутентификацию
• Запрос MFA появляется на старом телефоне (который они, возможно, уже сдали или стерли)
• Пользователь заблокирован и звонит в службу поддержки

6.2.1 Матрица сценариев при замене телефона#

Цель состоит в том, чтобы переместить как можно больше случаев в первые две строки, минимизируя участие службы поддержки.

6.2.2 Трюк с регистрацией в Intune#

Умное наблюдение: требование ключа доступа для регистрации в Intune вынуждает пользователей немедленно завершить настройку Microsoft Authenticator на своем новом телефоне — до того, как они смогут получить доступ к корпоративным приложениям.

• Сегодня: Регистрация в Intune требует усиления MFA (step-up). Это означает, что если вы хотите войти в систему на новом телефоне, вы устанавливаете там Outlook. Однако запрос MFA отправляется на старый телефон.
• С требованием ключа доступа: Чтобы завершить регистрацию, пользователи должны сначала настроить ключи доступа Microsoft Authenticator на новом телефоне. Это происходит быстро (в день смены телефона), а не месяцы спустя, когда старого телефона уже нет.

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

6.3 Аппаратные ключи безопасности сопряжены с проблемами логистики#

Аппаратные ключи (YubiKey и т. д.) иногда позиционируются как универсальное решение. Теоретически так оно и есть, однако реальный мир демонстрирует больше проблем:

• Логистический кошмар: Организации, которые ранее развертывали физические токены (например, RSA SecurID), часто тратили годы, пытаясь от них избавиться. Замена одной программы физических токенов другой не выглядит привлекательной.
• Прямая поставка (Drop-shipping): Yubico может отправлять ключи напрямую пользователям, и им не требуется замена батареи каждые несколько лет (в отличие от SecurID). Но если кто-то забудет свой ключ, он не сможет войти в систему (для общих рабочих столов).
• Нагрузка на локальный ИТ-отдел: Местные руководители не должны становиться де-факто службой ИТ-поддержки забытых ключей.
• Стоимость: Аппаратные ключи добавляют затраты на каждого пользователя, которые масштабируются в зависимости от численности персонала.

Когда аппаратные ключи имеют смысл:

• Администраторы уровня 0: Администраторы домена, учетные записи «break-glass»
• Общие рабочие станции: Среды киосков, производственные цеха, полевые планшеты
• Подрядчики без BYOD: Внешние пользователи, которые не будут использовать личные устройства

6.4 Проблемы с неуправляемыми устройствами#

Многие пользователи жалуются, что не видят вариантов использования ключей доступа на личном устройстве. Это классическая точка трения для «неуправляемого устройства».

6.4.1 Анализ ошибки «Ключ доступа не зарегистрирован»#

Пользователи могут не иметь возможности добавить ключи доступа на личном устройстве, в то время как это работает на корпоративном. Вероятно, это связано с взаимодействием политик соответствия Intune (Intune Compliance Policies) с процессом регистрации.

• Механизм: Windows Hello for Business (WHfB) — это учетные данные платформы. Они привязаны к TPM конкретного устройства (привязанный к устройству ключ доступа).
• Ограничение: Чтобы зарегистрировать WHfB, устройство обычно должно быть присоединено (Entra Joined или Hybrid Joined) к тенанту. На личное устройство, которое просто «Зарегистрировано» (Workplace Joined), могут распространяться политические ограничения, применяемые через Intune, которые блокируют предоставление контейнеров WHfB, если устройство не полностью управляется или не соответствует требованиям. См. Требования к входу с помощью ключа безопасности FIDO2.
• Опция «Ключ доступа»: На личном устройстве пользователь должен пытаться зарегистрировать ключ безопасности FIDO2 (роуминг) или кросс-девайс ключ доступа (на своем телефоне), а не Windows Hello for Business (если регистрация BYOD не поддерживается полностью).
• Проблема видимости Entra ID: Если «Windows Hello» не отображается в качестве опции, устройство не выполнило предварительную регистрацию MDM.

6.4.2 Сбои кросс-девайс аутентификации (CDA)#

На неуправляемых устройствах пользователи часто используют процесс кросс-девайс аутентификации (CDA) (сканирование QR-кода на ПК с помощью телефона).

• Зависимость от Bluetooth: CDA требует, чтобы Bluetooth был включен как на ПК, так и на телефоне. Им не нужно сопрягаться, но они должны выполнить квитирование Bluetooth Low Energy (BLE), чтобы доказать близость. Подробнее см. в разделе Ключи доступа, привязанные к устройству, в Microsoft Authenticator.
• Блокировщик корпоративной политики: Если Bluetooth отключен на корпоративных ноутбуках через BIOS или GPO в целях «безопасности», вы уже сломали основной механизм для роуминга ключей доступа.
• Блокировка Websocket: Процесс CDA использует websocket-соединение к cable.ua5v.com или cable.auth.com. Агрессивные корпоративные брандмауэры или конфигурации Zscaler часто блокируют эти домены, в результате чего сканирование QR-кода зависает или завершается сбоем без сообщений. См. документацию по ключам доступа Microsoft Authenticator.

6.5 B2B и внешние идентификаторы#

Еще одной болевой точкой для предприятий является работа с внешними консультантами (гостями B2B).

• Проблема: Консультант пытается получить доступ к сайту SharePoint. Тенант применяет политику Conditional Access, требующую «MFA, устойчивую к фишингу».
• Сбой: Консультант пытается зарегистрировать ключ FIDO2 в тенанте ресурсов. Это не удается. Entra ID не поддерживает регистрацию ключей FIDO2 гостевыми пользователями в тенанте ресурсов.
• Исправление: Cross-Tenant Access Settings (Параметры доступа между тенантами)
  • Логика: Вместо того чтобы заставлять гостя регистрировать учетные данные в вашем тенанте, вы должны доверять учетным данным, которые он использует в своем тенанте.
  • Конфигурация: Перейдите в External Identities > Cross-tenant access settings. Выберите партнерскую организацию. В разделе Inbound Trust (Входящее доверие) установите флажок «Доверять многофакторной аутентификации из тенантов Microsoft Entra».
  • Результат: Когда консультант входит в систему с помощью YubiKey в своем домашнем тенанте, ваш тенант получает заявку (claim), в которой говорится «MFA Satisfied + Phishing Resistant». Доступ предоставляется без необходимости регистрации пользователем чего-либо. Это передает управление жизненным циклом учетных данных партнеру, снижая вашу ответственность и нагрузку на службу поддержки.

7. Стратегии восстановления#

Часто решения по восстановлению все еще отстают от фактического развертывания. Существует несколько вариантов восстановления в зависимости от потребностей вашей организации.

7.1 Self-Service Account Recovery (SSAR) с помощью Verified ID#

Новый процесс самостоятельного восстановления учетной записи (SSAR) от Microsoft Entra ID (в предварительной версии) позволяет осуществлять восстановление с высоким уровнем гарантии без участия службы поддержки.

1. Триггер: Пользователь не может войти в систему. Выбирает «Восстановить мою учетную запись».
2. Проверка личности: Пользователь перенаправляется к стороннему провайдеру проверки личности (IDV) (например, Onfido, IDemia).
3. Проверка документов: Пользователь сканирует свои физические водительские права, национальное удостоверение личности или паспорт с помощью камеры мобильного телефона.
4. Проверка живости (Liveness Check): Пользователь выполняет селфи для Face Check. Оно сопоставляется с документом, удостоверяющим личность (и, возможно, с фотографией, сохраненной в Entra ID). Для сопоставления используются API Azure AI Vision Face, и передается только оценка достоверности. Никакие необработанные биометрические данные не попадают в приложение.
5. Восстановление: В случае успеха система автоматически выдает пользователю Temporary Access Pass (TAP).
6. Повторная регистрация: Пользователь использует TAP для немедленной регистрации нового ключа доступа.

Рекомендация: Этот автоматизированный путь восстановления с использованием биометрии превосходит метод «Позвонить в службу поддержки», который уязвим для социальной инженерии (атаки с использованием голосовых дипфейков).

7.2 Восстановление при содействии менеджера с помощью My Staff#

Если вы хотите снизить нагрузку на службу поддержки (Service Desk), но не можете включить полное самообслуживание, Microsoft Entra включает встроенную функцию делегированного администрирования под названием My Staff.

• Как это работает: Делегируйте ограниченные разрешения «Менеджерам команд» (через административные единицы в Entra).
• Процесс: Если пользователь теряет доступ, он может обратиться к делегированному локальному администратору, который может использовать портал My Staff для поддерживаемых задач восстановления, таких как сброс пароля или обновление номера телефона.
• Чем это помогает: Это переносит общую работу по восстановлению учетных записей из центральной службы поддержки и ускоряет процесс оказания помощи.

7.3 Киоск самостоятельного восстановления (интранет)#

Поскольку у пользователей часто по-прежнему есть доверенный ноутбук, защищенный WHfB, вы можете создать простую страницу интранета на случай экстренных ситуаций («break glass»).

• Сборка: Простое внутреннее веб-приложение, требующее входа в систему WHfB (строгая аутентификация).
• Действие: После аутентификации пользователь нажимает «У меня новый телефон». Приложение использует Microsoft Graph API (фоновую службу) для генерации краткосрочного Temporary Access Pass (TAP) и отображает его на экране.
• Результат: Пользователь вводит этот TAP на своем новом телефоне, чтобы настроить приложение Microsoft Authenticator. Нулевое участие службы поддержки.

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

8. Рекомендации по развертыванию корпоративных ключей доступа#

Структурируйте развертывание вокруг стадий зрелости. Признайте трения («Технология готова, операционная часть сложна») и примените эти меры по смягчению.

8.1 Немедленные действия (Фаза «Исправления»)#

1. Аудит Bluetooth и брандмауэров: Убедитесь, что корпоративные ноутбуки разрешают Bluetooth (для проверки близости), и добавьте в белый список ретрансляционные домены FIDO/WebAuthn (\*.cable.auth.com), чтобы исправить сбои при работе с несколькими устройствами.
2. Включите межтенантное доверие (Cross-Tenant Trust): Прекратите пытаться регистрировать гостевые ключи доступа. Настройте Inbound Trust for MFA для ключевых партнеров, чтобы немедленно решить проблемы доступа B2B.
3. Внедрите TAP для онбординга: Сделайте обязательным использование Temporary Access Pass для всех новых пользователей при онбординге, чтобы решить проблему блокировки регистрации по типу «курицы и яйца».

8.2 Стратегические решения (Фаза «Архитектуры»)#

1. Примите модель «Гибридных гарантий» (Hybrid Assurance):
   • Уровень 0 (Администраторы): Обеспечьте применение Аттестации и Ограничений ключей. Разрешены только YubiKey/аппаратные ключи (AAL3).
   • Уровень 1 (Сотрудники): Отключите применение аттестации с помощью Профилей ключей доступа. Разрешите синхронизируемые ключи доступа, чтобы снизить трение и затраты (AAL2).
2. План для macOS: Разверните Platform SSO с вашим MDM как параллельный путь для Windows WHfB.

8.3 Подготовка к будущему (Фаза «Оптимизации»)#

1. План для SSAR: Начните пилотный проект по самостоятельному восстановлению учетной записи (Self-Service Account Recovery) с Verified ID, чтобы устранить службу поддержки как вектор социальной инженерии.
2. Предпочтительная для системы аутентификация: Включите эту политику для автоматического «обновления» пользователей до ключей доступа, как только они их зарегистрируют, стимулируя внедрение без жесткого мандата.
3. Развертывание вариантов восстановления: Внедрите TAP при содействии менеджера через My Staff и/или Киоск самостоятельного восстановления.
4. Требование ключа доступа в Intune: Рассмотрите возможность требовать ключ доступа для регистрации в Intune, чтобы заставить пользователей регистрироваться на новых устройствах на раннем этапе.

8.4 Матрица устранения неполадок#

9. Мониторинг развертывания с помощью Phishing-Resistant Passwordless Workbook#

Microsoft выпустила Phishing-Resistant Passwordless Workbook, которую организации с журналами в Azure Monitor могут использовать для отслеживания хода развертывания. Доступ к ней можно получить в центре администрирования Entra в разделе Monitoring > Workbooks:

В этой рабочей книге (workbook) есть два основных раздела:

9.1 Фаза готовности к регистрации (Enrollment Readiness)#

Используйте эту вкладку для анализа журналов входа и определения, какие пользователи готовы к регистрации, а какие могут быть заблокированы. Вы можете фильтровать по платформе ОС (Windows, macOS, iOS, Android) и типу учетных данных (Authenticator App Passkey, FIDO2 Security Key, Certificate-Based Authentication):

Рабочая книга показывает:

• Пары Пользователь/Устройство, готовые к регистрации (Ready for Enrollment): пользователи, которые могут зарегистрировать выбранный тип учетных данных
• Пары Пользователь/Устройство, не готовые (Not Ready): пользователи, у которых могут возникнуть проблемы с регистрацией (например, устаревшие версии ОС)

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

9.2 Фаза готовности к применению (Enforcement Readiness)#

Как только пользователи будут готовы к аутентификации только с защитой от фишинга, используйте вкладку готовности к применению. Сначала создайте политику Conditional Access в режиме только для отчета (Report-Only), которая требует MFA, устойчивую к фишингу. Это заполнит журналы входа данными о том, был бы доступ заблокирован, если бы применение было активным.

Панель мониторинга показывает:

• Всего пользователей в области действия
• Успех только в отчете (Report Only Success) - пользователи, которые прошли бы проверку
• Политика не удовлетворена (Policy Not Satisfied) - пользователи, которые были бы заблокированы (исследуйте их!)
• Разбивку по состоянию устройства, платформе устройства и клиентскому приложению

Используйте вкладку Дальнейший анализ данных (Further Data Analysis), чтобы выяснить, почему определенные пользователи были бы заблокированы. Эти данные помогут вам определить целевых пользователей для исправления до включения принудительного применения.

9.3 Волновое развертывание с мониторингом службы поддержки#

Microsoft рекомендует выполнять развертывания волнами с гибкими диапазонами дат. Отслеживайте объем заявок в службу поддержки как сигнал:

• Объем заявок увеличивается: Замедлите развертывание, коммуникации и принудительные действия
• Объем заявок уменьшается: Возобновите активность

Создайте группы безопасности Microsoft Entra ID для каждой волны и постепенно добавляйте группы в свои политики. Это предотвратит перегрузку команд поддержки.

10. Контрольный список для пилотного проекта синхронизируемых ключей доступа#

Если целью являются синхронизируемые ключи доступа без зависимости от Microsoft Authenticator, следуйте этим правилам пилотного проекта:

1. Включите синхронизируемые ключи доступа (предварительная версия). Следуйте инструкциям Синхронизируемые ключи доступа (предварительная версия).

2. Используйте Профили ключей доступа (предварительная версия) и нацельтесь на пилотную группу. Создайте/назначьте профиль, который разрешает синхронизируемые ключи доступа, как описано в разделе Профили ключей доступа.

3. Не требуйте обязательной аттестации (по крайней мере, для пилотной группы). Применение аттестации исключает синхронизируемые ключи доступа в соответствии с документацией по концепциям ключей доступа (FIDO2).

4. Изначально избегайте строгих белых списков AAGUID. Начните с разрешающего режима, чтобы подтвердить работу процесса, а затем ужесточите ограничения, когда узнаете, каких провайдеров вы хотите разрешить. См. Включение ключей доступа (FIDO2).

5. Убедитесь, что Conditional Access не навязывает Microsoft Authenticator. Убедитесь, что параметры CA/надежности аутентификации по-прежнему допускают профиль ключей доступа, который вы собираетесь использовать (в противном случае это выглядит как зависимость от Microsoft Authenticator).

6. Проверьте модель идентификации (участник (member) против гостя). Если пользователи являются гостями, подтвердите ожидаемую поддержку в вашей модели тенанта, прежде чем тратить время на настройку профилей.

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

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

1. Привязанные к устройству или синхронизируемые ключи доступа: Учетные данные, привязанные к устройству (например, Microsoft Authenticator, Windows Hello, YubiKey, смарт-карты), строго привязаны к одному устройству и соответствуют AAL3. Синхронизируемые ключи доступа (например, iCloud Keychain, Google Password Manager) работают на разных устройствах и соответствуют AAL2. Большинству организаций нужны оба варианта: аппаратные аутентификаторы для администраторов (AAL3) и синхронизируемые ключи доступа для остальных сотрудников (AAL2).

2. Начальная настройка для новых сотрудников: Используйте Temporary Access Pass (TAP) для решения проблемы курицы и яйца при онбординге. Для крупномасштабных развертываний автоматизируйте это с помощью Graph API. Для сценариев использования с высоким уровнем гарантии дополните онбординг с помощью Entra Verified ID и Face Check.

3. Восстановление при замене телефона: Предлагайте несколько методов восстановления: Киоск самостоятельного восстановления (используйте ноутбук в качестве устройства начальной загрузки), TAP при содействии менеджера через My Staff и SSAR (самостоятельное восстановление учетной записи) с Verified ID для пограничных случаев.

4. Ошибки конфигурации: Наиболее частые ошибки включают глобальное применение аттестации, не включение функций предварительной версии для синхронизируемых ключей доступа, чрезмерно строгие белые списки AAGUID и политики Conditional Access (CA), которые создают круговые зависимости.

5. Гости B2B: Избегайте прямой регистрации ключей доступа для гостей B2B в вашем тенанте. Вместо этого включите Cross-Tenant Access Trust (Доверие к доступу между тенантами), чтобы проверять учетные данные из домашнего тенанта гостя.

6. Аппаратные ключи против мобильных ключей доступа: Аппаратные ключи безопасности требуются для определенных ролей с высоким уровнем безопасности (администраторы, общие рабочие станции), но создают логистические препятствия в масштабе. Мобильные ключи доступа, как правило, более практичны для сотрудников.

7. macOS вместе с Windows: Используйте Platform SSO с JAMF/MDM для включения поддержки ключей доступа в macOS параллельно с развертываниями Windows. Планируйте рабочие процессы, специфичные для конкретной платформы.

8. Превентивные меры: Используйте Intune, чтобы выявлять неактивные устройства и побуждать пользователей к исправлению ситуации до того, как произойдет блокировка. Рассмотрите возможность сделать регистрацию ключей доступа обязательным условием для регистрации в Intune, чтобы способствовать раннему внедрению. Создайте рабочий процесс самостоятельного восстановления, используя ноутбуки в качестве устройств начальной загрузки.

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

О 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 →

Часто задаваемые вопросы#

Почему включение MFA, устойчивой к фишингу, в Conditional Access блокирует всех моих пользователей?#

Создание политики Conditional Access, требующей MFA, устойчивую к фишингу, для всех облачных приложений, немедленно блокирует любого пользователя, который еще не зарегистрировал ключ доступа, включая блокировку доступа к самой странице регистрации Security Info. Эта круговая зависимость, называемая парадоксом «Регистрации сведений о безопасности», означает, что вы должны выдать Temporary Access Pass затронутым пользователям перед включением применения политики, чтобы они могли завершить первоначальную регистрацию.

Как работать с гостевыми пользователями B2B, если мой тенант требует MFA, устойчивую к фишингу?#

Entra ID не поддерживает регистрацию ключей FIDO2 гостевыми пользователями в тенанте ресурсов, поэтому попытка принудительно зарегистрировать ключи доступа для гостей завершится неудачей. Правильным решением будет настройка Cross-Tenant Access Settings в External Identities для доверия заявкам MFA от домашнего тенанта гостя. Это означает, что YubiKey, используемый в их собственной организации, удовлетворяет вашему требованию MFA, устойчивому к фишингу, без какой-либо регистрации в вашем тенанте.

Почему аутентификация по QR-коду между устройствами дает сбой без уведомлений при входе с помощью ключа доступа?#

Аутентификация между устройствами (Cross-Device Authentication) требует включения Bluetooth как на ПК, так и на телефоне для завершения рукопожатия BLE, поэтому любая корпоративная политика, отключающая Bluetooth, полностью нарушит этот процесс. Процесс также использует соединение WebSocket к cable.auth.com, которое часто блокируют брандмауэры или конфигурации Zscaler, в результате чего сканирование QR-кода зависает или завершается сбоем без четкого сообщения об ошибке.

Как проверить, какие сотрудники готовы к обязательному использованию устойчивой к фишингу MFA, прежде чем я ее включу?#

Рабочая книга (workbook) Microsoft Phishing-Resistant Passwordless Workbook, доступная через центр администрирования Entra в разделе Monitoring > Workbooks, предоставляет представление Enrollment Readiness (Готовность к регистрации), показывающее, какие пары пользователь/устройство могут регистрироваться в зависимости от платформы и типа учетных данных. Для проверки готовности к принудительному применению создайте политику Conditional Access в режиме только для отчетов (report-only), требующую MFA, устойчивую к фишингу, чтобы журналы входа показывали, какие пользователи были бы заблокированы до того, как вы активируете реальное принудительное применение.

Какова лучшая стратегия восстановления для сотрудников, которые приобрели новый телефон и потеряли доступ к своему ключу доступа?#

Рекомендуемый подход является многоуровневым: Киоск самостоятельного восстановления (Self-Service Recovery Kiosk) с использованием ноутбука с защитой WHfB генерирует Temporary Access Pass через Graph API и покрывает большинство случаев без участия службы поддержки. Для пользователей без ноутбука функция Manager-Assisted TAP через портал My Staff делегирует восстановление непосредственным руководителям, а Self-Service Account Recovery с биометрической проверкой Entra Verified ID Face Check обрабатывает пограничные случаи, требующие полной повторной проверки личности.

Дополнительная литература#

Для более глубокого погружения в развертывание корпоративных ключей доступа/FIDO2 следите за такими экспертами, как Merill Fernando и Jan Bakker, которые регулярно публикуют практические руководства по аутентификации в Microsoft Entra.