Применение passkeys в организациях: нюансы и проблемы

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

Поддержка passkeys в системах управления identity

Перед тем как решать организационные проблемы и писать политики, стоит разобраться, готовы ли к переходу на КД основные ИТ-системы в организации.

Microsoft Entra ID (Azure AD) полностью поддерживает КД и позволяет администраторам выбрать КД в качестве основного метода входа в систему.

Для гибридных внедрений, где есть on-prem-ресурсы, Entra ID может генерировать токены Kerberos (TGT), которые затем будет обрабатывать доменный сервер Active Directory.

А вот для входа через RDP и VDI и входа в AD, работающую только on-premises, нативной поддержки у Microsoft пока нет. Впрочем, с некоторыми ухищрениями организация может записывать passkey на аппаратный токен, например YubiKey, который будет одновременно поддерживать традиционную технологию PIVKey (смарт-карты) и FIDO2. Также для поддержки этих сценариев есть сторонние решения, но организации потребуется оценить, как их применение влияет на общую защищенность и регуляторное соответствие.

В Google Workspace и Google Cloud есть полная поддержка passkeys.

Популярные системы управления identity, такие как Okta, Ping, Cisco Duo, RSA ID Plus, поддерживают FIDO2 и все основные формы КД.

Поддержка passkeys в клиентских устройствах

Этот вопрос мы подробно рассмотрели в отдельном посте — все современные ОС от Google, Apple и Microsoft поддерживают КД, а вот для Linux потребуются дополнительные инструменты и поддержка в целом ограничена.

За «фасадом» полной поддержки скрывается большое разнообразие сценариев хранения КД, которые могут быть плохо совместимы между собой. Наиболее проблемны сочетания вроде «Windows-компьютеры + Android-смартфоны». Создав ключ доступа на одном устройстве, пользователь запросто может не иметь к нему никакого доступа на другом. В рамках корпорации со строгими политиками в парке техники проблему можно решить, например, генерируя несколько КД — по одному на каждое корпоративное устройство пользователя. Это немного трудоемко при первоначальной настройке (сотруднику надо пройти один и тот же путь создания КД на каждом устройстве), зато потом пользователю удобно, он входит в системы с минимальными тратами времени, а при утере одного из устройств не оказывается полностью изолированным от рабочих данных.

Второй возможный вариант — применять одобренный компанией менеджер паролей в качестве хранилища КД, синхронизируемых между всеми устройствами сотрудника. Также менеджер секретов потребуется компаниям, применяющим Linux-системы на компьютерах сотрудников, поскольку на уровне этой ОС хранить КД невозможно. Этот сценарий может быть более сложным для прохождения аудитов регуляторного соответствия.

Почти нет проблем синхронизации и многоплатформенности при использовании КД на аппаратных носителях (YubiKey и подобных), но такое решение значительно дороже в облуживании.

Поддержка passkeys в бизнес-приложениях

Идеальным сценарием реализации КД будет вход во все бизнес-приложения через SSO, тогда имплементировать поддержку passkeys нужно только на стороне корпоративного решения SSO (Entra ID, Okta и тому подобных). Если важные бизнес-приложения не поддерживают SSO или эта поддержка не входит в контракт (печально, но встречается), для пользователей придется выпускать отдельные ключи доступа для входа в каждую из систем. Аппаратные токены могут хранить от 25 до 100 КД, поэтому дополнительные расходы здесь будут только на администрирование.

Среди популярных у бизнеса систем, полностью поддерживающих passkeys, отметим Adobe Creative Cloud, AWS, GitHub, Google Workspace, HubSpot, Office 365, Salesforce и Zoho. Некоторые системы SAP также поддерживают ключи доступа.

Готовность сотрудников

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

• чем КД лучше паролей (безопаснее, быстрее входить в систему, не надо регулярно менять пароли);
• как используется биометрия в КД (никогда не покидает устройство, не хранится и не обрабатывается работодателем);
• как получить первый passkey (у Microsoft есть технология Temporary Access Pass, сторонние системы IAM часто присылают ссылку на первичное подключение — процесс нужно детально документировать);
• что делать, если устройство не признает ключ доступа;
• что делать, если потерял устройство (зайти с другого устройства, на которое выпущен свой КД, либо применить одноразовый код, выдаваемый сотруднику в запечатанном конверте как раз на такой случай);
• как входить в рабочие системы с других компьютеров (если это разрешено);
• как выглядит фишинг, выманивающий доступ через КД.

Passkeys — не панацея

Переход на КД не означает, что команда ИБ может вычеркнуть угрозы identity из своего списка рисков. Да, возможности злоумышленников сокращаются, но они могут:

• атаковать системы, где переход на КД не совершен;
• атаковать системы, где оставлены «запасные» способы входа, например пароли и СМС-коды;
• красть токены аутентификации с зараженных инфостилерами компьютеров;
• использовать специальную технологию для обхода защиты passkeys.

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

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

В общем, переход на passkeys требует детальной настройки политик как в части аутентификации (запрет паролей при наличии КД, запрет физических токенов неизвестных производителей и так далее), так и в части мониторинга (регистрация КД или сценарии cross-device из подозрительных местоположений).