Доступ по физическим пропускам и Passkeys: техническое руководство

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

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

Эта новая реальность создает вызов для аутентификации сотрудников. Сотрудникам, будь то в офисе, удаленно или на гибридном графике, требуется доступ к быстрорастущему портфелю облачных и SaaS-приложений. Такая распределенная модель доступа создает обширную и сложную поверхность для атак. Традиционные имя пользователя и пароль, даже дополненные устаревшими методами многофакторной аутентификации (MFA), такими как SMS-коды, остаются самым слабым звеном — основным вектором для фишинга, атак с подстановкой учетных данных и захвата аккаунтов. В ответ на это отрасль переходит к беспарольной, устойчивой к фишингу аутентификации. Рыночные прогнозы предсказывают рост рынка беспарольной аутентификации с более чем 18 миллиардов долларов в 2024 году до более чем 60 миллиардов к 2032 году, при этом 87% предприятий уже внедряют или находятся в процессе внедрения Passkeys для своих сотрудников.

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

Основная цель этой статьи — предоставить нейтральный, глубоко технический анализ архитектурных моделей, доступных для интеграции этих физических пропусков с аутентификацией на основе Passkeys. В частности, этот анализ фокусируется на кастомных SaaS-приложениях в корпоративном контексте, где не всегда можно рассчитывать на традиционного локального поставщика удостоверений (IdP). В следующих разделах мы разберем три различных пути к такой интеграции, оценивая их технические компоненты, модели безопасности и критические компромиссы между ними.

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

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

Организации, обновляющие свои системы доступа на основе UID до защищенных токенов аутентификации, обычно следуют этому пути:

1. Базовый пропуск с UID → используется только для физического доступа.
2. Защищенный NFC-пропуск → добавляет шифрование для контроля доступа, но все еще не подходит для цифровой аутентификации.
3. Смарт-карта PKI (PIV) → добавляет доступ на основе цифрового сертификата (VPN, подписанные электронные письма), требует промежуточного ПО.
4. Смарт-карта FIDO2 → обеспечивает беспарольный вход через WebAuthn, может также сочетаться с функциями физического доступа.
5. Платформенные Passkeys → видение будущего, где физические токены становятся необязательными, но конвергенция достигается наилучшим образом, когда одно устройство обрабатывает как физический, так и логический доступ.

Этот подробный разбор проясняет различие между простым идентификатором и криптографическим аутентификатором, что является самой важной концепцией в этом анализе. Базовый RFID-пропуск может предоставить только UID, который в лучшем случае может служить подсказкой имени пользователя для начала процесса аутентификации. Он не может участвовать в криптографическом запросе-ответе, который лежит в основе WebAuthn. Смарт-карта FIDO2, напротив, разработана именно для этой цели. Это фундаментальное различие порождает три distintas архитектурных модели, которые мы рассмотрим далее. Варианты 1 и 2 — это, по сути, обходные пути, предназначенные для преодоления ограничений пропусков, работающих только как идентификаторы, в то время как вариант 3 представляет собой нативную интеграцию настоящего аутентификатора.

С четким пониманием базовых технологий мы можем теперь изучить три основные архитектурные модели для интеграции физических пропусков с аутентификацией Passkey для корпоративного SaaS-приложения. Каждый путь предлагает уникальный набор компромиссов в области безопасности, стоимости, пользовательского опыта и сложности.

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

1. Действие пользователя и идентификация: Сотрудник прикладывает свой стандартный RFID/NFC-пропуск к считывателю, подключенному к его рабочей станции. Считыватель захватывает статический UID пропуска.
2. Запрос к хранилищу: Клиентский компонент отправляет UID на проприетарную конечную точку API, размещенную у провайдера хранилища учетных данных.
3. Инициация WebAuthn на стороне сервера: Сервис хранилища получает UID, находит связанную учетную запись пользователя, а затем инициирует церемонию аутентификации WebAuthn с целевым SaaS-приложением (Relying Party) от имени пользователя. SaaS-приложение возвращает стандартный запрос на аутентификацию (challenge).
4. Подписание на основе HSM: Сервис хранилища передает этот запрос своему внутреннему HSM. HSM надежно хранит компонент приватного ключа Passkey пользователя для этого конкретного SaaS-приложения. HSM выполняет операцию криптографического подписания запроса и возвращает полученную подпись сервису хранилища. Приватный ключ никогда не покидает безопасных границ HSM.
5. Завершение аутентификации и выдача токена: Сервис хранилища завершает процесс WebAuthn, отправляя подписанный запрос обратно в SaaS-приложение. SaaS-приложение проверяет подпись, используя публичный ключ пользователя (который у него есть), и в случае успеха выдает токен сессии аутентификации (например, JSON Web Token).
6. Доставка сессии: Сервис хранилища пересылает этот токен сессии обратно в браузер пользователя, который затем может использовать его для установления аутентифицированной сессии с SaaS-приложением, завершая вход в систему.

• Преимущества:
  • Использование существующей инфраструктуры: Главная привлекательность этой модели заключается в ее способности работать с наиболее распространенными и недорогими RFID/NFC-пропусками, уже используемыми в организации, что позволяет избежать дорогостоящего и сложного обновления оборудования.
  • Максимально удобный пользовательский опыт: Она может обеспечить настоящий вход в систему по принципу «прикоснулся и пошел» (tap-and-go). С точки зрения пользователя, одно касание пропуска к считывателю позволяет ему войти прямо в приложение, что означает крайне низкое трение.
  • Централизованное управление: Все учетные данные Passkey создаются, хранятся и управляются в экосистеме провайдера. Это может упростить административные задачи, такие как отзыв и применение политик.
• Недостатки:
  • Проприетарная и замкнутая система: Эта архитектура фактически превращает пропуск и провайдера хранилища в нового, проприетарного поставщика удостоверений (IdP). Организация становится глубоко зависимой от этого одного поставщика в критически важной функции. Такие «замкнутые» системы по своей сути негибки и создают значительную привязку к поставщику, что делает будущие миграции сложными и дорогостоящими.
  • Требование чрезвычайного доверия: Безопасность всей системы зависит от надежности и компетентности провайдера хранилища. Поскольку HSM провайдера хранят приватные ключи всех пользователей для всех приложений, компрометация провайдера была бы катастрофической.
  • Высокая стоимость и сложность: Это не простое решение. Оно требует либо создания, либо подписки на очень сложный, критически важный сервис, который включает в себя дорогостоящую инфраструктуру HSM, сложное программное обеспечение и операции с высокой доступностью.
  • Отклонение от принципов WebAuthn: Эта модель в корне нарушает основной принцип WebAuthn, который заключается в аутентификации на стороне клиента с использованием учетных данных, находящихся во владении пользователя. Аутентификатор находится на стороне сервера, что является антипаттерном для общей веб-аутентификации. Как отмечалось в первоначальном запросе, этот подход обычно не рекомендуется для аутентификации в стандартном веб-приложении SaaS.

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

1. Действие пользователя и локальное обнаружение: Сотрудник прикладывает свой базовый RFID/NFC-пропуск к стандартному USB-считывателю, подключенному к его рабочей станции.
2. Локальный агент-слушатель: Легковесный фоновый сервис или демон, работающий в операционной системе (например, с использованием API PC/SC), прослушивает события считывателя смарт-карт. Он обнаруживает касание пропуска и считывает UID с карты.
3. Взаимодействие агента с расширением: Этот локальный агент передает захваченный UID сопутствующему расширению браузера. Обычно это достигается с помощью API Native Messaging Host браузера, который позволяет изолированному расширению обмениваться сообщениями с предварительно зарегистрированным нативным приложением.
4. Предзаполнение имени пользователя и инициация процесса: Расширение браузера содержит логику для сопоставления полученного UID с конкретным именем пользователя. После получения UID оно вставляет соответствующее имя пользователя в форму входа SaaS-приложения. Современные формы входа также могут использовать атрибут autocomplete="webauthn" в полях ввода, чтобы сигнализировать браузеру о возможности инициировать процесс Passkey для автозаполненного пользователя. Затем расширение может программно запустить процесс аутентификации с помощью Passkey.
5. Стандартная церемония WebAuthn: С этого момента происходит полностью стандартная церемония аутентификации WebAuthn. Браузер предлагает пользователю использовать свой зарегистрированный аутентификатор Passkey. Это может быть платформенный аутентификатор компьютера (например, Windows Hello, macOS Touch ID) или отдельный переносимый аутентификатор (например, YubiKey или даже телефон пользователя). Пользователь выполняет жест аутентификации (например, сканирование отпечатка пальца), и вход завершается в соответствии со стандартным процессом. Роль пропуска на этом закончена.

• Преимущества:
  • Аутентификация, соответствующая стандартам: Самое значительное преимущество заключается в том, что фактическая криптографическая аутентификация представляет собой чистый, неискаженный процесс WebAuthn. Модель безопасности опирается на проверенные принципы FIDO2, а не на проприетарное обходное решение. Касание пропуска — это исключительно улучшение пользовательского опыта.
  • Использование существующего оборудования: Как и вариант 1, этот подход работает с существующим парком базовых RFID/NFC-пропусков и недорогих USB-считывателей.
  • Улучшенный пользовательский опыт: Хотя это и не вход в одно касание, он значительно снижает трение. Пользователю не нужно помнить и вводить свое имя пользователя, что сокращает процесс входа и уменьшает вероятность ошибки.
• Недостатки:
  • Развертывание и обслуживание ПО: Основной недостаток — операционные накладные расходы. Эта архитектура требует развертывания, настройки и обслуживания двух отдельных частей программного обеспечения — нативного агента на уровне ОС и расширения браузера — на каждой рабочей станции сотрудника. Это может стать значительной нагрузкой для ИТ-отделов, которым придется управлять обновлениями, устранять проблемы совместимости с различными версиями ОС и браузеров, а также заниматься установкой патчей безопасности.
  • Хрупкость архитектуры: Канал связи между драйвером оборудования, нативным агентом и расширением браузера представляет собой кастомный мост. Этот «клей» может быть хрупким и подвержен сбоям при выходе обновлений операционной системы или браузера, что приводит к плохому и ненадежному пользовательскому опыту.
  • Неполное решение: Это не решение по принципу «прикоснулся и пошел». Пользователь все равно должен выполнить второе, отдельное действие для завершения аутентификации с помощью своего фактического Passkey. Касание пропуска автоматизирует только первый шаг процесса входа.

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

1. Навигация пользователя: Сотрудник переходит на страницу входа в SaaS-приложение. Приложение настроено на поддержку аутентификации с помощью Passkey.
2. Инициация WebAuthn: Пользователь нажимает кнопку «Войти с помощью Passkey», или Conditional UI (автозаполнение) браузера автоматически обнаруживает доступные Passkeys и представляет их в немодальном окне. JavaScript браузера вызывает navigator.credentials.get() для начала церемонии аутентификации.
3. Взаимодействие с аутентификатором: Браузер через операционную систему предлагает пользователю предъявить свой ключ безопасности. Сотрудник либо прикладывает свой FIDO2-пропуск к встроенному NFC-считывателю, либо вставляет его в подключенный считыватель смарт-карт.
4. Криптографическая подпись на карте: Браузер отправляет запрос от SaaS-приложения на пропуск. Защищенный элемент внутри пропуска использует свой внутренне хранящийся, неэкспортируемый приватный ключ для подписания запроса. В зависимости от политики Relying Party и возможностей карты, этот шаг может также потребовать проверки пользователя, например, ввода PIN-кода на рабочей станции или прикладывания пальца к биометрическому сенсору, встроенному в саму карту.
5. Завершение аутентификации: Пропуск возвращает подписанный ответ в браузер, который пересылает его на сервер SaaS. Сервер проверяет подпись, и пользователь безопасно входит в систему. Весь процесс координируется браузером и операционной системой с использованием стандартизированных протоколов FIDO.

• Преимущества:
  • Высочайшая безопасность и соответствие стандартам: Это «золотой стандарт» для конвергентного доступа. Он использует стандарты FIDO2 и WebAuthn именно так, как они были разработаны, обеспечивая максимально возможную защиту от фишинга и атак «человек посередине». Пользователь физически владеет аппаратным токеном, содержащим его приватный ключ.
  • Простота и надежность архитектуры: Эта модель элегантна в своей простоте. Нет необходимости разрабатывать и поддерживать кастомные агенты, расширения для браузера или проприетарные мосты. Процесс аутентификации опирается на высоконадежные и хорошо поддерживаемые API и драйверы, встроенные в современные операционные системы и браузеры.
  • Истинная конвергенция безопасности: Эта архитектура реализует обещание действительно конвергентных учетных данных. Один управляемый физический токен используется для предоставления доступа как к физическим пространствам (дверям), так и к логическим ресурсам (приложениям), упрощая пользовательский опыт и модель безопасности.
• Недостатки:
  • Значительные затраты на оборудование: Самым существенным препятствием для этого подхода являются первоначальные инвестиции. Он требует замены всего парка базовых RFID/NFC-пропусков организации на более дорогие FIDO2-совместимые смарт-карты. В зависимости от существующей инфраструктуры, это также может потребовать обновления физических считывателей на дверях для совместимости с новыми картами.
  • Сложное управление жизненным циклом учетных данных: Управление полным жизненным циклом криптографических учетных данных для большого штата сотрудников сложнее, чем управление простым списком UID. Процессы безопасной выдачи, ротации ключей, обновления сертификатов (если также используется PKI) и особенно отзыва и восстановления становятся более критичными и сложными.
  • Нюансы пользовательского опыта: Несмотря на высокую безопасность, пользовательский опыт может создавать другие точки трения. Если карта требует PIN-код для проверки пользователя, это вновь вводит фактор «то, что вы знаете», который нужно помнить. Физическое действие вставки карты в считыватель может восприниматься как менее плавное, чем простое бесконтактное касание, в зависимости от конкретного развернутого оборудования.

Выбор между этими тремя архитектурными путями — это не просто техническое, а стратегическое решение, которое уравновешивает конкурирующие приоритеты. Вариант 1 отдает приоритет безупречному пользовательскому опыту и использованию существующего оборудования, но делает это, создавая дорогостоящую и высокорискованную проприетарную зависимость, которая отклоняется от открытых стандартов. Вариант 2 также использует существующее оборудование и улучшает пользовательский опыт, придерживаясь стандартов аутентификации, но переносит затраты и сложность на трудную и часто недооцениваемую проблему управления программным обеспечением на каждой конечной точке. Вариант 3 ставит во главу угла безопасность, надежность и приверженность открытым стандартам, принимая более высокие первоначальные затраты на оборудование в обмен на более простую, перспективную архитектуру с меньшими долгосрочными затратами на обслуживание. Универсально «правильного» выбора не существует; оптимальный путь зависит от конкретной терпимости к риску организации, бюджета, существующей инфраструктуры и возможностей ИТ-поддержки.

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

Оптимальный путь для организации зависит от ее основных бизнес-драйверов.

• Если ваш основной драйвер — минимизация первоначальных капитальных затрат и использование существующего парка пропусков, то Вариант 2 (Мост на рабочем столе) является наиболее прагматичным выбором. Он обеспечивает ощутимое улучшение пользовательского опыта и использует ядро аутентификации, соответствующее стандартам, без необходимости крупных инвестиций в оборудование. Однако этот путь следует выбирать только в том случае, если у организации есть зрелая и надежная система управления конечными точками, поскольку успех этой модели зависит от способности надежно развертывать и поддерживать необходимое клиентское программное обеспечение.
• Если ваш основной драйвер — достижение высочайшего уровня безопасности, соответствие лучшим отраслевым практикам и создание перспективной, не требующей сложного обслуживания архитектуры, то Вариант 3 (Конвергентные учетные данные) является явным стратегическим победителем. Этот подход полностью соответствует открытым стандартам, устраняет хрупкое кастомное программное обеспечение и обеспечивает самую надежную защиту от фишинга. Первоначальные затраты на оборудование — это инвестиция в долгосрочную безопасность и операционную простоту.
• Если ваш основной драйвер — предоставление «волшебного», бесшовного входа по касанию превыше всех других соображений, то Вариант 1 (Централизованное хранилище) — единственный, который действительно это обеспечивает. Однако к этому пути следует подходить с крайней осторожностью. Он вводит значительный стратегический риск из-за привязки к поставщику и требует исключительно высокого уровня доверия к архитектуре безопасности и операциям провайдера. Для большинства открытых веб- и SaaS-приложений проприетарная, замкнутая природа этой модели делает ее менее желательным выбором по сравнению с альтернативами на основе стандартов.

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

• Выдача и адаптация: Для нового сотрудника процесс значительно отличается. В вариантах 1 и 2 адаптация включает выдачу стандартного пропуска и затем создание записи в базе данных, которая сопоставляет UID пропуска с учетной записью пользователя. В варианте 3 процесс представляет собой формальную церемонию регистрации FIDO2, где новый FIDO2-совместимый пропуск используется для генерации Passkey, который затем регистрируется в SaaS-приложении. Этот процесс более безопасен, но и более сложен в управлении в больших масштабах.
• Отзыв (увольнение сотрудника): Когда сотрудник уходит, его физический доступ всегда отзывается в центральной системе контроля доступа (СКУД). Для логического доступа шаги следующие:
  • Вариант 1: Провайдер хранилища должен быть немедленно уведомлен для отключения или удаления учетных данных, хранящихся в его HSM.
  • Вариант 2: Фактический Passkey пользователя (например, хранящийся в TPM его ноутбука через Windows Hello) должен быть отозван в настройках SaaS-приложения. Сопоставление UID пропуска становится нерелевантным после отключения базового Passkey.
  • Вариант 3: Публичный ключ, связанный с FIDO2-пропуском сотрудника, должен быть удален из его профиля пользователя в SaaS-приложении, что делает пропуск бесполезным для входа в систему.
• Восстановление (потерянный или украденный пропуск): Это критический сценарий сбоя, который необходимо спланировать. Последствия сильно различаются:
  • В вариантах 1 и 2 потерянный пропуск менее критичен для логического доступа, так как он является лишь идентификатором. Основной риск — несанкционированный физический доступ. Пользователь все еще может войти в систему, используя свой фактический аутентификатор Passkey.
  • В Варианте 3 потерянный пропуск может стать серьезной проблемой. Если FIDO2-пропуск является единственным Passkey, зарегистрированным для учетной записи пользователя, он полностью заблокирован. Это подчеркивает критически важную лучшую практику для любого корпоративного развертывания Passkey: пользователи должны быть обязаны или настоятельно рекомендованы регистрировать несколько аутентификаторов. Надежная политика будет требовать, чтобы сотрудник зарегистрировал как свой FIDO2-пропуск (в качестве основного повседневного аутентификатора), так и резервный, такой как его платформенный аутентификатор (Windows Hello/Face ID) или телефон, для использования при восстановлении учетной записи.

В конечном счете, успешное развертывание Passkey — это не просто проект по аутентификации; это проект по управлению идентификацией и доступом (IAM). Техническая архитектура для процесса входа не может быть спроектирована в вакууме. Она должна быть тесно интегрирована с комплексной стратегией предоставления, управления и отзыва идентификаторов и связанных с ними учетных данных на протяжении всего их жизненного цикла. Этот целостный подход необходим для снижения рисков, таких как блокировка учетной записи, и обеспечения долгосрочного успеха и безопасности системы.

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

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

Хотя каждый путь представляет собой шаг к более безопасному, беспарольному будущему, долгосрочная траектория развития корпоративной безопасности отдает предпочтение решениям, построенным на открытых, совместимых стандартах. Архитектуры, которые нативно используют FIDO2 и WebAuthn — как это демонстрирует модель конвергентных учетных данных и, в некоторой степени, мост на рабочем столе — обеспечивают самую надежную и перспективную основу. Они позволяют организациям создавать лучшие в своем классе системы безопасности, которые используют конкурентную экосистему аппаратного и программного обеспечения, свободную от ограничений замкнутой платформы одного поставщика. Для любой организации, создающей следующее поколение корпоративных приложений, принятие этих открытых стандартов — это не просто технический выбор; это стратегическое обязательство в пользу более безопасного, гибкого и совместимого цифрового мира.