Passkeys и FIDO2 в корпоративной среде: план перехода

Зачем уходить от паролей и что дают passkeys

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

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

Passkeys простыми словами - это вход без пароля. Вместо «секретного слова» используется криптографический ключ, привязанный к устройству и подтверждаемый биометрией или PIN. Важное отличие от пароля и одноразовых кодов (OTP): passkey нельзя просто выманить на поддельном сайте. Он работает только с настоящим сервисом и не раскрывает «секрет» при вводе.

Для сотрудников это обычно выглядит как привычная разблокировка телефона или рабочего ПК: приложил палец, ввел PIN - и вошел. Для ИТ и поддержки эффект тоже заметен: меньше обращений по сбросу паролей, но больше внимания к правилам выдачи ключей, управлению устройствами и сценариям восстановления доступа.

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

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

Passkeys и FIDO2: термины, которые важно не путать

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

FIDO2 - это набор стандартов, который описывает, как устроен беспарольный вход и как «общаются» приложение и аутентификатор. Упрощенно картина такая:

• WebAuthn - часть на стороне приложения (чаще веб), которая описывает запрос на вход.
• CTAP2 - часть, которая описывает связь с аутентификатором (аппаратный ключ, телефон и т.д.).
• FIDO2 - «зонтик», объединяющий WebAuthn и CTAP2.

Passkey - удобная для пользователя форма учетных данных на базе FIDO. Технически это пара ключей: приватный хранится в аутентификаторе, публичный - у сервиса. Пользователь подтверждает вход биометрией или PIN, но сам секрет не вводит и не передает.

Аутентификатором может быть разное - и это важно для политики безопасности:

• аппаратный ключ безопасности (USB, NFC);
• телефон как ключ (подтверждение на устройстве);
• встроенная биометрия и защищенный модуль в ноутбуке;
• смарт-карта или корпоративный токен (если это поддерживает ваша среда).

На практике это применяют для входа в веб-сервисы и порталы, доступа к VPN и удаленному рабочему месту, разблокировки рабочих станций, админ-доступа к критичным системам. Для администраторов обычно выбирают более строгий вариант: отдельный аппаратный ключ и запрет синхронизации на личные устройства.

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

Быстрая оценка готовности: что проверить до пилота

Перед пилотом важно понять, где именно сегодня вводится пароль и кто управляет доступом. Обычно достаточно 1-2 встреч с ИТ и ИБ, чтобы заранее увидеть узкие места и сэкономить недели.

Начните с инвентаризации точек входа. Помимо почты и корпоративных порталов почти всегда всплывают VPN, VDI, CRM/ERP, панели администрирования, сервисные учетные записи и доступ подрядчиков. Важно не просто перечислить системы, а для каждой зафиксировать: как проходит вход, есть ли MFA, и можно ли подключить FIDO2 без переделки приложения.

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

Отдельная тема - устройства. Passkeys и FIDO2 упираются в реальную технику: какие ОС у сотрудников, есть ли мобильные устройства, используются ли киоски и shared-PC, как люди работают в командировках. В госучреждении с общими компьютерами в приемных «привязка» ключа к личному профилю может быть сложнее, чем в офисе с персональными ноутбуками.

Чтобы не расползаться, соберите минимальный набор данных по готовности:

• список точек входа и приоритетность (что ломать нельзя);
• точка управления доступом и текущие политики MFA;
• парк устройств и сценарии (офис, удаленка, shared-PC);
• требования ИБ и регуляторов: журналы, сроки хранения, аудит событий;
• возможности поддержки: кто помогает пользователям и в какие часы.

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

Пошаговый план внедрения: от пилота до масштабирования

Переход на passkeys лучше вести как проект с волнами, а не как разовую «замену паролей». В Passkeys и FIDO2 в корпоративной среде главный риск обычно не в технологии, а в организационных деталях: кто попал в пилот, что делать при потере устройства, и когда пароль перестанет быть запасным входом.

1) Пилот: короткий, измеримый, с реальными пользователями

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

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

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

2) Коммуникации и поддержка: чтобы люди не паниковали

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

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

3) Масштабирование волнами и даты отключения паролей

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

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

Совместимость приложений: как пройти через легаси без хаоса

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

Соберите список точек входа: веб-порталы, VPN, VDI, почта, ERP/CRM, админские консоли, сервисные аккаунты, доступ подрядчиков. Для каждой точки зафиксируйте: поддерживает ли она WebAuthn/FIDO2 напрямую, есть ли SSO, какие протоколы используются (SAML, OIDC, RADIUS), и можно ли обновить версию без остановки бизнеса.

Матрицу проще держать в порядке, если:

• разделить приложения на 3 группы: уже готовы, готовы через SSO, не готовы;
• отдельно отметить вход через браузер (обычно проще) и через клиент (часто сложнее);
• пометить админские доступы и привилегированные роли;
• назначить владельца приложения и окно для обновлений;
• заранее определить, что будет временным решением на 3-6 месяцев, а что нужно исправить «навсегда».

Типовые проблемные зоны почти всегда повторяются. Старые веб-приложения могут не поддерживать современные методы входа и ломаться из-за устаревших шифров или встроенных форм логина. «Толстые» клиенты часто понимают только логин и пароль, а обновления требуют длинных согласований. Отдельная история - RDP/SSH: там важны не passkeys «как в браузере», а связка с корпоративной учеткой, сертификатами или шлюзом доступа.

Обычно помогает комбинация подходов:

• вход через SSO (приложение остается как есть, политика входа меняется у провайдера идентификации);
• шлюз или прокси для легаси (сильная проверка на входе, дальше доступ к старому приложению);
• обновление версии, если продукт живой;
• замена, если поддержка закончилась и риск растет;
• отдельный управляемый путь для RDP/SSH (бастион-хост, VDI или другое контролируемое место входа).

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

Практичный пример: в большой организации часть сотрудников работает в современных веб-системах, а часть - в старом клиенте для учета. Пилот запускают на первой группе через SSO и FIDO2, а для легаси фиксируют временный шлюз и план обновления. Прогресс идет быстро, но без отключений и паники.

Требования к ключам и политика для разных ролей

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

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

Базовые требования к ключам

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

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

Вопрос «сколько ключей на человека» лучше решать по ролям. Для большинства достаточно одного основного метода (например, passkey на корпоративном ноутбуке) и одного резервного (аппаратный ключ или второй зарегистрированный девайс). Резервный вариант должен храниться отдельно - не в одном чехле с ноутбуком и не «в ящике на всех». На практике помогает учет и хранение в опечатанном конверте или в сейфе подразделения.

Политика для админов и привилегированных ролей

Для администраторов правило простое: отдельные ключи и повышенная строгость. То, что обычно снижает риск:

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

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

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

Восстановление доступа: правила, которые спасают проект

Беспарольная аутентификация чаще ломается не на входе, а на восстановлении. Если человек потерял ключ, разбил телефон, сменил устройство или уехал без резерва, он либо остановит работу, либо начнет обходить правила. Поэтому сценарии восстановления нужно согласовать до пилота и закрепить в политике.

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

Базовые сценарии и что сделать заранее

Заранее проверьте, как команда действует в типовых случаях:

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

Чтобы подтверждать личность без лишней бюрократии, используйте 2-3 сигнала, которые реально проверить: корпоративный пропуск и лицо, звонок на номер из HR, подтверждение через руководителя по заранее утвержденному каналу. Один канал не должен быть единственной точкой отказа.

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

Увольнение, передача ролей и break-glass

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

Break-glass аккаунты допустимы только для аварийных работ. Держите их в минимальном количестве и контролируйте использование: включение только по инциденту, фиксация причины, уведомление безопасности и обязательная смена секретов сразу после применения.

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

Типичные ошибки при переходе на passkeys

Переход на passkeys часто проваливается не из-за технологий, а из-за правил и поддержки. Даже если Passkeys и FIDO2 в корпоративной среде уже поддерживаются вашими устройствами и IdP, пользователи найдут обходной путь, если им неудобно или непонятно.

Самая частая ошибка - сделать passkeys обязательными для всех в один день. В ответ появляется «теневая ИТ»: сотрудники просят коллег войти за них, сохраняют одноразовые коды в заметках или требуют вернуть «как было». Надежнее начинать с небольшой группы и расширять только после того, как стало понятно, где ломаются процессы.

Пять провалов, которые встречаются чаще всего:

• принудительный перевод без пилота и понятных исключений на первые недели;
• игнорирование shared-PC и сменных рабочих мест (ресепшн, колл-центр, медкабинет, учебный класс), где вход «с телефона» не всегда возможен;
• ситуация, когда пароль остается основным способом, а passkeys добавляют «для удобства» - фишинг и повторное использование паролей никуда не уходят;
• helpdesk не готов: нет скриптов, статусов заявок, инструмента для безопасного восстановления - пользователи начинают обходить правила;
• одинаковые правила для сотрудников, подрядчиков и администраторов, хотя риски и требования у них разные.

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

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

И еще одно: заранее оцените нагрузку на поддержку. При смене привычного способа входа первые 2-3 недели почти всегда дают пик обращений. Если helpdesk готов, пользователи быстрее привыкают, и проект не теряет доверие.

Короткий чеклист перед запуском

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

Пять вопросов, на которые нужны четкие ответы:

• Кто идет в пилот и зачем. Выбраны 1-2 пилотные группы (например, ИТ и служба поддержки, затем бухгалтерия или операторы контакт-центра). Заранее определены метрики: доля успешных входов, количество обращений в helpdesk, время восстановления доступа, процент приложений без паролей.
• Какие приложения готовы, а какие нет. Составлен список систем, где люди реально входят каждый день: почта, ERP/CRM, порталы, VDI, VPN, админки. Для сложных приложений выбран путь: обновление, замена, вход через единый провайдер, или временное исключение с датой окончания.
• Какие ключи допускаются и сколько нужно резервов. Утверждены типы аутентификаторов (аппаратный, встроенный в устройство, мобильный) и правила по количеству. Для критичных ролей - минимум один основной и один запасной. Отдельно прописано, что делать с подрядчиками, сменными сотрудниками и теми, кто работает в полях.
• Как восстанавливаем доступ без хаоса. Описаны процедуры «потерял устройство/ключ», «сменил телефон», «подозрение на компрометацию». Helpdesk обучен: какие проверки личности допустимы, кто утверждает восстановление, сколько это занимает, какие события обязательно фиксировать.
• Что пишем в журналы и как реагируем. Настроены логи входов, отказов, регистраций ключей и действий восстановления. Назначены ответственные: кто отслеживает аномалии (много отказов, регистрация нового ключа ночью, попытки на разные аккаунты), и какие шаги выполняются при инциденте.

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

Реалистичный сценарий и следующие шаги

Компания на 400 сотрудников: головной офис и 120 удаленных. Есть 2-3 ключевые системы, без которых работа встанет: корпоративная почта и календарь, VPN для доступа к внутренним ресурсам и один бизнес-сервис (например, ERP или портал заявок). Цель на первый квартал - проверить, как Passkeys и FIDO2 в корпоративной среде работают в реальных условиях и что нужно изменить в процессах.

Для пилота выбирают 30-50 человек: ИТ, финансы, несколько руководителей и часть удаленных сотрудников. Их опыт обычно самый показательный: много входов, разные устройства, высокий риск фишинга.

Как обычно проходит первая неделя пилота

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

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

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

Как измерить результат и что делать дальше

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

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

Если внутри компании не хватает времени на обследование приложений, настройку SSO и отработку восстановления, помогает интегратор. В Казахстане такие проекты часто удобнее вести вместе с обновлением рабочих мест и серверной части: GSE.kz, как производитель и системный интегратор, может закрыть поставку корпоративных компьютеров и серверов, интеграцию инфраструктуры и поддержку, чтобы пилот не держался на одном-двух энтузиастах.