За последние три года я руководил проектами по переходу на беспарольную аутентификацию в трех компаниях из списка Fortune 500, и могу с уверенностью сказать: отказ от паролей в гибридной среде Active Directory и Microsoft Entra ID — одна из самых полезных и недооцененных технических задач в современном управлении идентификационными данными. Теоретическая привлекательность очевидна: отсутствие паролей означает отсутствие компрометации учетных данных, фишинг становится экспоненциально сложнее, а ваша позиция в области безопасности фундаментально смещается с «предотвращения утечек» на «предположение о наличии утечки». Но реальность внедрения в средах, охватывающих локальную и облачную инфраструктуру? Вот где кроется истинная сложность.
Большинство организаций, с которыми я работал, начинают этот путь с романтических представлений о том, как можно просто щелкнуть выключателем и отправиться в беспарольное будущее. Вместо этого они обнаруживают, что достижение истинной беспарольной аутентификации требует переосмысления архитектуры идентификационных данных с нуля. Дело не в замене одного метода аутентификации другим — это фундаментальная перестройка процесса проверки личности на каждом уровне вашей инфраструктуры. Переход требует тщательного планирования, технической строгости и непоколебимой приверженности принципам безопасности в ущерб удобству.
Предварительные условия: создание фундамента перед миграцией
Прежде чем говорить о беспарольной аутентификации, нам нужно рассмотреть то, что я называю «треугольником предварительных условий»: облачное доверие Kerberos, регистрация устройств и политики условного доступа. Пропустите хотя бы один из них, и ваша миграция застопорится, не успев набрать обороты.
Облачное доверие Kerberos — это недооцененный герой гибридных беспарольных развертываний. Когда я начинал работать над своей первой полной миграцией, я недооценил, насколько критичен этот элемент. Традиционный Kerberos предполагает управляемую сеть с контроллерами домена, которые вы контролируете. Облачный Kerberos позволяет вашим облачным службам выдавать билеты Kerberos устройствам, гибридно присоединенным к домену, без необходимости наличия контроллера домена в Интернете. Это ваш мост между локальными и облачными идентификационными данными, и он является обязательным условием для бесшовной гибридной аутентификации. Механизмы самого Kerberos не претерпели значительных изменений с момента его появления в 1980-х годах, но расширение его на облачные среды потребовало фундаментального переосмысления того, как выдаются и проверяются билеты аутентификации в границах доверия.
Для работы облачного Kerberos требуется Azure AD Connect версии 2.0 или выше с агентом синхронизации облака, настроенным для синхронизации хешей паролей (даже если вы не используете ее для аутентификации — это остается предварительным условием). Ваши гибридно присоединенные устройства должны работать под управлением Windows 10 20H2 или новее и иметь надежное сетевое подключение как к вашим локальным контроллерам домена, так и к Azure. В одном из развертываний моя команда провела две недели, устраняя сбои аутентификации, прежде чем обнаружила, что правило брандмауэра блокировало необходимое соединение по порту 88. Это единственное открытие подчеркнуло, почему сетевая проверка должна проводиться до пилотного развертывания, а не во время него.
Далее следует регистрация и управление устройствами. Каждое устройство, пытающееся пройти беспарольную аутентификацию, должно быть либо присоединено к Azure AD, либо гибридно присоединено к AD, либо зарегистрировано в Entra ID. Я обнаружил, что гибридно присоединенные устройства лучше всего работают в истинно гибридных средах, поскольку они поддерживают связь с локальной инфраструктурой, одновременно получая преимущества облачной идентификации. Ваше развертывание Intune Mobile Device Management становится здесь критически важным — устройства должны соответствовать вашим политикам, прежде чем им будет доверена беспарольная регистрация. Это означает обеспечение шифрования диска, запуск антивируса и соответствие устройств базовым требованиям безопасности вашей организации. Базовый уровень соответствия не является карательным; это минимально приемлемый порог безопасности.
Политики условного доступа формируют последнюю сторону треугольника предварительных условий. Они не являются необязательными — именно они обеспечивают соблюдение принципа «нулевое доверие, всегда проверяй» (Zero Trust). Национальный институт стандартов и технологий определяет архитектуру нулевого доверия как требующую непрерывной проверки и явного предоставления доступа на основе всех доступных точек данных. Я настраиваю политики, которые требуют соответствия устройства, принудительного многофакторного подтверждения подлинности для конфиденциальных операций и полного блокирования устаревшей аутентификации. Политика, которую я обычно рекомендую в качестве отправной точки, требует гибридно присоединенных устройств, соответствия статусу Intune и MFA для всего доступа к локальным ресурсам, при этом разрешая бесшовный вход для полностью соответствующих устройств. Это создает порочный круг, где безопасность и пользовательский опыт усиливают друг друга.
Решения по архитектуре: гибридные потоки аутентификации и Windows Hello for Business
Как только ваши предварительные условия выполнены, вы сталкиваетесь с критическими архитектурными решениями, которые будут определять ваше развертывание на долгие годы. Основной точкой принятия решения является выбор между использованием Windows Hello for Business, ключей безопасности FIDO2 или входа через телефон в качестве основного механизма аутентификации.
По моему опыту, Windows Hello for Business является основой для гибридных сред. Он использует биометрическую аутентификацию или аутентификацию по PIN-коду на самом устройстве, предотвращая передачу учетных данных по сети. Когда пользователь входит в систему с помощью Windows Hello, он не отправляет пароль и даже учетные данные — он использует закрытый ключ, хранящийся в модуле доверенной платформы (TPM) устройства, для подтверждения своей личности. Для гибридно присоединенных устройств это работает бесшовно, поскольку устройство может аутентифицироваться как для вашего локального контроллера домена (с использованием облачного Kerberos), так и для Entra ID одним действием. Это устраняет поверхность атаки, которую создает традиционная аутентификация по паролю. Организации, ищущие дополнительную информацию о подходах к беспарольной аутентификации, могут ознакомиться с рекомендациями Агентства по кибербезопасности и защите инфраструктуры, которое опубликовало подробные рекомендации по переходу от паролей.
Однако — и это крайне важно — не все устройства имеют TPM 2.0, который требуется для наиболее безопасных реализаций. В одной организации, где мы развернули систему на 15 000 устройств, мы обнаружили, что 12% не соответствовали аппаратным требованиям. В итоге мы внедрили поэтапный подход: Windows Hello for Business на соответствующих устройствах, а ключи безопасности FIDO2 — в качестве резервного варианта для устройств, которые не могли его поддерживать. Ключи FIDO2, соответствующие открытому стандарту FIDO2, также являются вашим решением для сценариев, где требуются физические токены аутентификации — особенно полезно для привилегированных учетных записей или сценариев с высоким риском. Они устойчивы к фишингу и захвату учетных записей, поскольку требуется физическое владение токеном. Исследования Identity Defined Security Alliance показали, что организации, использующие аутентификаторы, соответствующие стандарту FIDO2, сокращают инциденты с компрометацией учетных записей более чем на 90% по сравнению с системами, зависящими от паролей.
Архитектурное решение также включает определение того, как вы обрабатываете устаревшие приложения, которые по-прежнему требуют паролей. Ваши варианты ограничены: внедрить шлюз приложений, совместимый с беспарольной аутентификацией, полностью отказаться от приложения или использовать функции интеллектуальной блокировки и защиты паролей Entra ID для снижения рисков во время перехода. Я обычно рекомендую рассматривать поддержку устаревших приложений как временный мост, а не как постоянную архитектуру. Организации, которые рассматривают это как постоянное решение, неизбежно обнаруживают, что им приходится поддерживать парольную инфраструктуру бесконечно, подрывая всю позицию безопасности, которую они строят.
Рабочие процессы миграции: пошаговая реальность
Сама миграция должна следовать структурированному подходу, который я отработал в нескольких организациях. Начните с пилотной группы — я рекомендую от 50 до 200 пользователей, готовых принять некоторые неудобства в обмен на улучшения безопасности. Эта группа должна включать ИТ-персонал и пользователей, заботящихся о безопасности, которые могут предоставить ценную обратную связь, не будучи разочарованными проблемами ранней стадии.
На этапе пилотирования настройте Windows Hello for Business с помощью групповых политик в вашей локальной инфраструктуре для устройств, присоединенных к домену, а политики Intune — для устройств, управляемых облаком. Настройте Entra ID, чтобы требовать Windows Hello в качестве предпочтительного метода аутентификации. На этом этапе сохраняйте традиционную аутентификацию по паролю в качестве резервного варианта — не потому, что вам не хватает уверенности, а потому, что доверие пользователей к системе имеет значение. Я обычно наблюдаю период от трех до четырех недель, в течение которого вы поддерживаете оба метода, пока пользователи адаптируются. Этот период предоставляет бесценные данные о реальных моделях использования и крайних случаях.
Второй этап включает расширение на группы на уровне отделов. К этому моменту вы должны были выявить и задокументировать все шаблоны устранения неполадок, возникшие в вашем пилотном проекте. Распространенные проблемы, с которыми я сталкивался, включают политики сложности PIN-кода, конфликтующие с конфигурацией Windows Hello, проблемы с кэшированием учетных данных на гибридно присоединенных устройствах и путаницу в отношении восстановления доступа при утере или компрометации устройства. Хорошо разработанная база знаний службы поддержки на этом этапе предотвращает превращение третьего этапа в кризис поддержки.
Заключительный этап — полномасштабное развертывание по всей организации с отключенной аутентификацией по паролю. Здесь вы должны иметь полную уверенность в своих резервных механизмах и способности вашей службы поддержки справляться с крайними случаями. Я рекомендую сохранять аутентификацию по паролю для сценариев «break-glass» (хотя и с жесткими ограничениями и логированием) по крайней мере в течение 90 дней после полного развертывания. Эта система безопасности обеспечивает психологический комфорт руководству и создает реальный аварийный выход, если что-то неожиданное произойдет в больших масштабах.
Шаблоны устранения неполадок и извлеченные уроки
После руководства тремя крупномасштабными развертываниями я составил список проблем, которые заслуживают внимания, прежде чем они станут производственными проблемами, а не задокументированными решениями.
Проверка соответствия устройств часто становится узким местом. Если ваши политики Intune слишком строги, пользователи будут заблокированы от беспарольной аутентификации, поскольку их устройства не соответствуют требованиям. Решение заключается не в ослаблении политик, а в автоматизации исправления несоответствий. Используйте скрипты исправления Intune для автоматического включения необходимых функций и обновления настроек вместо блокировки доступа. Когда устройство становится несоответствующим из-за отсутствия обновления безопасности, скрипты исправления могут незаметно развернуть это обновление, восстановив доступ без взаимодействия со службой поддержки.
Сбои обновления билетов облачного Kerberos происходят, когда устройства теряют сетевое подключение. Я обнаружил, что пользователи ценят понимание того, что кратковременные сбои в сети могут потребовать от них временного использования альтернативного метода аутентификации. Документирование этого ожидания и предоставление четких сообщений об ошибках значительно снижает нагрузку на службу поддержки. Одна организация, с которой я работал, создала простую панель состояния, отображающую работоспособность облачного подключения, что значительно повысило доверие пользователей к системе.
Поток сброса PIN-кода Windows Hello требует тщательного планирования. Пользователи будут забывать PIN-коды — не потому, что они невнимательны, а потому, что у них теперь на один пароль меньше, и они перенаправляют свои когнитивные усилия в другое русло. Внедрите возможность сброса PIN-кода самообслуживания Entra ID, но тщательно протестируйте ее в различных сетевых условиях. Я обнаружил в одном из развертываний, что пользователи не могли сбросить PIN-код в автономном режиме, что приводило к созданию заявок в службу поддержки, даже несмотря на то, что функция технически была доступна онлайн. Простой автономный вариант сброса устранил бы эти заявки.
Механизмы восстановления заслуживают особого внимания. Что произойдет, если устройство пользователя будет украдено? Что, если TPM выйдет из строя? Что, если они забудут свой PIN-код и не смогут получить доступ к вашему порталу самообслуживания? Документируйте эти сценарии и протестируйте их со своей службой поддержки до полного развертывания. Я обнаружил, что уверенность службы поддержки в процедурах восстановления напрямую коррелирует с уверенностью пользователей в беспарольной аутентификации.
Конечная точка: по-настоящему беспарольная корпоративная среда
Достижение истинной беспарольной аутентификации в гибридной среде означает признание того, что вы строите новую модель безопасности, а не просто меняете способ аутентификации пользователей. Требуемые усилия значительны, но улучшение безопасности глубоко. Я видел, как организации переходили от сценариев аутентификации с большим количеством утечек к архитектурам нулевого доверия, где каждый запрос на доступ оценивается в контексте, и где компрометация одного устройства не приводит к полной компрометации учетной записи.
Путешествие к беспарольной аутентификации — это не пункт назначения, которого достигают за месяцы, а направление, в котором постоянно движутся. Организации, которые добиваются успеха, рассматривают беспарольную миграцию не как проект с конечной датой, а как фундаментальный сдвиг в их подходе к идентификации и доверию. Они поддерживают этот импульс, постоянно обновляя политики, расширяя охват на новые приложения и сценарии использования, а также совершенствуя свою архитектуру по мере развития технологий.
Вид с другой стороны стоит этого путешествия. Как только вы поживете в беспарольной среде, возвращение к аутентификации по паролю будет ощущаться как снятие ремня безопасности во время движения. Риск кажется очевидным в ретроспективе, а достигнутая безопасность становится обязательной.
Эта статья опубликована в рамках Foundry Expert Contributor Network.
Хотите присоединиться?
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Sameer Bhanushali
