Физические смарт-карты и USB-токены обеспечивают строгую аутентификацию, но создают проблемы при удалённой работе и BYOD. Можно ли отказаться от них и при этом не снижать уровень защиты?
- 1. Введение
- 2. Что ГОСТ Р 58833-2020 понимает под строгой аутентификацией
- 3. Почему физический токен не является обязательным
- 4. Какие механизмы позволяют отказаться от физического токена
- 5. Как организовать строгую аутентификацию в BYOD
- 6. Что доступно на российском рынке
- 7. Как выбирать решение
- 8. Выводы
Введение
Физическая смарт-карта или USB-токен защищает закрытый ключ и позволяют использовать его для аутентификации и других криптографических операций. Но при удалённой и гибридной работе физический носитель создаёт дополнительные организационные задачи: его нужно выпустить, передать сотруднику, учитывать, заменять при утере или поломке и отзывать при увольнении.
Проблема становится заметнее, когда сотрудник использует для работы сразу несколько устройств. В сценарии BYOD (Bring Your Own Device — использование личного устройства для работы) компания должна обеспечить защищённый доступ, не получая полного контроля над личным компьютером или смартфоном.
Отсюда возникает вопрос: можно ли отказаться от физического токена и при этом сохранить строгую аутентификацию? Если да, то какие условия должны выполняться, чтобы другой способ аутентификации обеспечивал требуемый уровень доверия к результату?
Что ГОСТ Р 58833-2020 понимает под строгой аутентификацией
ГОСТ Р 58833-2020 разделяет аутентификацию на простую, усиленную и строгую.
Строгая аутентификация определяется как многофакторная взаимная аутентификация с использованием криптографических протоколов. В отличие от обычной многофакторной проверки, при которой система может подтвердить только личность пользователя, при строгой аутентификации участники процесса должны удостовериться в подлинности друг друга через криптографический обмен.
Стандарт выделяет три основных фактора аутентификации:
- фактор знания, например, пароль или PIN-код;
- фактор владения — устройство или другой объект, содержащий аутентификационную информацию;
- биометрический фактор — характеристика человека, используемая для подтверждения личности.
Для многофакторной аутентификации необходимо совместно использовать как минимум два различных фактора. При строгой аутентификации этого недостаточно. Обмен аутентификационной информацией должен быть взаимным и выполняться с использованием соответствующих криптографических протоколов.
В качестве примера строгой аутентификации ГОСТ Р 58833-2020 приводит использование закрытого ключа и соответствующего ему электронного удостоверения с открытым ключом. При этом устройство аутентификации может быть не только аппаратным, но и виртуальным.
Стандарт не требует использовать именно USB-носитель или смарт-карту. Физический токен — лишь один из вариантов реализации устройства аутентификации.
С 1 октября 2025 года действует ГОСТ Р 70262.2-2025, который устанавливает уровни доверия аутентификации и определяет требования к видам и средствам аутентификации для каждого из них. При разработке стандарта учитывались положения ГОСТ Р 58833-2020.
При этом строгая аутентификация и высокий уровень доверия аутентификации — не синонимы: строгая аутентификация описывает способ проведения аутентификационного обмена, а уровень доверия характеризует степень уверенности в его результате. Поэтому наличие TPM, passkey или другого криптографического средства само по себе не означает соответствия высокому уровню доверия. Необходимо оценивать всю схему аутентификации и её реализацию.
При проектировании новых систем российским компаниям имеет смысл учитывать оба документа: ГОСТ Р 58833-2020 задаёт общую модель аутентификации, а ГОСТ Р 70262.2-2025 — требования к уровням доверия и средствам аутентификации.
Почему физический токен не является обязательным
Физическая смарт-карта хранит закрытый ключ, защищает его от штатного экспорта и выполняет криптографические операции. Для использования ключа пользователь может подтверждать действие PIN-кодом или другим фактором.
При использовании встроенного или программного аутентификатора отдельного носителя нет. Закрытый ключ создаётся на устройстве и хранится в защищённом хранилище — например, в TPM (Trusted Platform Module, доверенный платформенный модуль) компьютера или защищённом хранилище мобильной платформы. Криптографическая операция выполняется непосредственно на устройстве, а пользователь подтверждает использование ключа PIN-кодом, паролем устройства или биометрией.
При этом важно, чтобы закрытый ключ не передавался за пределы защищённого хранилища и не мог быть штатно экспортирован. При аутентификации система проверяет криптографическое подтверждение владения соответствующим ключом.
Таким образом, отсутствие физического токена само по себе не означает отказ от его защитной модели: ключ можно хранить и использовать средствами самого устройства. Но строгая аутентификация определяется не наличием TPM, сертификата или конкретного типа носителя, а всей схемой аутентификации и используемыми в ней факторами.
Какие механизмы позволяют отказаться от физического токена
Есть несколько технологий, которые позволяют перенести аутентификационные функции с отдельного носителя на компьютер, смартфон или программный аутентификатор. Они решают разные задачи и подходят для разных инфраструктур.
Виртуальная смарт-карта
Виртуальная смарт-карта — это программная эмуляция физической смарт-карты. Ключи хранятся в аппаратном модуле TPM, который защищает их от извлечения. Операционная система получает интерфейс, соответствующий модели смарт-карты, что позволяет использовать сертификатную аутентификацию без USB-токена и считывателя.
Microsoft описывает виртуальную смарт-карту как технологию, которая эмулирует физическую смарт-карту с использованием TPM. При этом компания рекомендует для новых установок Windows рассматривать Windows Hello for Business или FIDO2 вместо виртуальных смарт-карт.
Для существующей Windows-инфраструктуры виртуальная смарт-карта подходит, если приложения и сервисы уже используют сертификатную аутентификацию по модели smart card.
Основное ограничение — привязка ключа к конкретному компьютеру. Это одновременно повышает защиту от переноса ключа и усложняет замену устройства. При потере компьютера или переходе сотрудника на другой ПК обычно требуется сформировать новое удостоверение.
Для российских компаний такой сценарий также технически реализуем. Например, Рутокен KeyBox поддерживает управление TPM Virtual Smart Card и Windows Hello for Business наряду с физическими ключевыми носителями.
Виртуальная смарт-карта сама по себе не делает процесс строгой аутентификацией по ГОСТ. Она предоставляет способ работы с ключом, а соответствие ГОСТ зависит от всей архитектуры: использования не менее двух факторов, взаимности аутентификации и криптографических протоколов.
Рисунок 1. Принцип работы виртуальной смарт-карты (Microsoft)
Сертификат на устройстве
Другой вариант — не имитировать смарт-карту, а использовать сертификат непосредственно на компьютере или мобильном устройстве.
В этом случае ключевая пара создаётся на устройстве, а закрытый ключ хранится в защищённом хранилище ОС или аппаратном механизме, если это поддерживается платформой.
Такой подход применяется, например, для:
- корпоративного Wi-Fi с 802.1X;
- TLS-аутентификации;
- корпоративной почты;
- отдельных приложений и сервисов;
- идентификации устройства.
На мобильных устройствах выдачу сертификатов можно автоматизировать средствами MDM (Mobile Device Management, управление мобильными устройствами) или UEM (Unified Endpoint Management, унифицированное управление конечными точками).
В таких сценариях используются SCEP (Simple Certificate Enrollment Protocol, простой протокол регистрации сертификатов) и другие механизмы автоматической регистрации сертификатов.
Сертификат сам по себе не является строгой аутентификацией. Он подтверждает связь открытого ключа с пользователем, устройством или субъектом. Соответствие ГОСТ зависит от всей архитектуры: использования не менее двух факторов, взаимности аутентификации и криптографических протоколов.
Windows Hello for Business
Windows Hello for Business — современный механизм беспарольной аутентификации в Windows. Ключевая пара создаётся на устройстве, а закрытый ключ защищается средствами устройства. Для подтверждения операции пользователь использует PIN-код или биометрию.
В корпоративной среде Windows Hello for Business поддерживает несколько моделей доверия, включая Cloud Kerberos Trust, Key Trust и Certificate Trust.
Важный момент для архитектуры: Windows Hello for Business не является просто виртуальной смарт-картой нового поколения. В зависимости от выбранной модели меняется способ построения доверия и взаимодействия с Active Directory или Microsoft Entra ID.
При соответствующей архитектуре Windows Hello for Business может использоваться для реализации строгой аутентификации: применяются два фактора — закрытый ключ, привязанный к устройству (фактор владения), и PIN-код (фактор знания) или биометрия (фактор присущности). TPM не является отдельным фактором. Он используется для генерации и защиты закрытого ключа на устройстве.
FIDO2 и passkeys
FIDO2 использует асимметричную криптографию. При регистрации создаётся пара ключей: закрытый ключ остаётся у аутентификатора, а сервис сохраняет открытый ключ.
При входе сервис формирует криптографический запрос, а аутентификатор подписывает его закрытым ключом после подтверждения пользователем операции с помощью PIN-кода, биометрии или другого механизма разблокировки.
Главное преимущество FIDO2 — устойчивость к фишингу: учётные данные связаны с конкретным сервисом, поэтому фальшивый сайт не может получить от пользователя тот же набор данных, который требуется для входа на настоящий ресурс.
Рисунок 2. Процесс аутентификации по WebAuthn/FIDO2 (Источник: MojoAuth)
Passkey — это учётные данные FIDO, основанные на паре открытого и закрытого ключей. Для пользователя они выступают как единый способ входа без пароля. При этом важно различать device-bound passkeys (привязанные к конкретному устройству) и synced passkeys (синхронизируемые между устройствами).
В первом случае закрытый ключ остаётся на конкретном устройстве. Во втором случае учётные данные могут синхронизироваться между устройствами пользователя через механизм синхронизации соответствующего провайдера (например, iCloud Keychain, Google Password Manager) или через совместимые менеджеры паролей.
Для BYOD это важное различие. Device-bound passkey проще связать с конкретным устройством и его состоянием. При смене или потере устройства потребуется использовать другой зарегистрированный аутентификатор или пройти процедуру восстановления доступа. Synced passkey удобнее при работе с нескольких устройств, но управление им зависит от механизма синхронизации и политики провайдера.
Соответствие ГОСТ Р 58833-2020 зависит не от типа passkey, а от того, где хранится ключ и как подтверждается пользователь.
Device-bound passkey с аппаратной защитой ключа и подтверждением через PIN или биометрию использует два фактора — владения и знания/присущности.
Synced passkey синхронизирует закрытый ключ между устройствами, поэтому ключ может покидать устройство. Для такого сценария нужно отдельно оценивать, как подтверждается пользователь, можно ли отозвать удостоверение и кто управляет синхронизацией.
Таблица 1. Как эти механизмы соотносятся со строгой аутентификацией
|
Механизм |
Что заменяет |
Может ли быть частью строгой аутентификации |
|
Виртуальная смарт-карта |
Физическую смарт-карту и считыватель |
Да, при условии двух факторов и контроля устройства |
|
Сертификат на устройстве |
Физический носитель сертификата |
Да, при правильной архитектуре и двух факторах |
|
Windows Hello for Business |
Пароль и в некоторых сценариях физический носитель |
Да, при использовании двух факторов (закрытый ключ, привязанный к устройству + PIN/биометрия) |
|
FIDO2 |
Пароль или часть схемы MFA |
Да, при аппаратной защите ключа и использовании двух факторов |
|
Passkey |
Парольный способ входа |
Зависит от реализации (device-bound vs synced) |
Как организовать строгую аутентификацию в BYOD
В сценариях BYOD компания, помимо аутентификации пользователя, должна учитывать состояние устройства. Наличие действующего сертификата или зарегистрированного FIDO-аутентификатора не означает, что устройство безопасно. Личный компьютер или смартфон может быть потерян, скомпрометирован или не соответствовать корпоративным требованиям.
Поэтому архитектура должна разделять две задачи:
- аутентификацию пользователя — кто получает доступ;
- контроль устройства — с какого устройства этот доступ разрешён.
Для сертификатного сценария могут использоваться защищённое хранилище ключа, сертификат, система аутентификации и средства управления устройством. MDM/UEM при этом не становится частью самой криптографической аутентификации, но позволяет управлять устройством и применять к нему политики безопасности.
Что необходимо контролировать
В зависимости от уровня риска компания может проверять:
- поддерживаемую версию ОС;
- состояние механизмов защиты устройства;
- наличие блокировки экрана;
- шифрование;
- отсутствие root или jailbreak, если это предусмотрено политикой;
- наличие рабочего профиля;
- состояние корпоративного удостоверения;
- соответствие устройства установленным требованиям.
Не все проверки должны быть одинаковыми для всех ресурсов. Для обычного корпоративного приложения требования могут быть мягче, чем для доступа администратора к критической системе.
Как отделить рабочие данные от личных
Для BYOD важен принцип минимального управления. Компания не обязательно должна получать полный контроль над личным смартфоном.
Android Enterprise Work Profile позволяет выделить рабочий контур с корпоративными приложениями и данными.
У Apple для личных устройств используется Account-driven User Enrollment, предназначенный для разделения корпоративных и личных данных.
Можно управлять корпоративным контуром, не превращая личный смартфон сотрудника в полностью управляемое корпоративное устройство.
Что происходит при потере устройства
Потеря устройства должна рассматриваться как потенциальная компрометация корпоративного удостоверения.
В зависимости от архитектуры организация может:
- прекратить активные сессии;
- запретить новые подключения с устройства;
- заблокировать или отозвать корпоративное удостоверение;
- удалить корпоративные данные средствами MDM/UEM;
- зарегистрировать новое устройство;
- выпустить новое удостоверение.
Для BYOD важен выборочный отзыв корпоративного доступа. Компания должна иметь возможность удалить свои данные и прекратить доступ к корпоративным ресурсам, не получая контроля над личной информацией сотрудника.
Яндекс ID, VK ID, СберБанк Онлайн и личный кабинет МТС поддерживают FIDO2 и passkeys. Это позволяет организовать строгую аутентификацию в BYOD‑среде без отдельного физического токена: ключи хранятся в защищённой среде смартфона или ПК, а их использование подтверждается биометрией или PIN-кодом. В корпоративной среде такой подход дополняют MDM/UEM‑системами, чтобы централизованно управлять доступом и отзывать его при утере устройства.
По данным VK ID, за год аудитория беспарольных сценариев выросла на 16% и достигла 58 млн пользователей. По прогнозам аналитиков, к концу 2026 года число пользователей беспарольных методов входа в России может вырасти до 70–75 млн человек.
Что доступно на российском рынке
Для построения такой архитектуры российские компании могут использовать несколько классов решений: системы управления виртуальными и программными средствами аутентификации, механизмы сертификатной и мобильной аутентификации, а также инструменты контроля устройств в BYOD.
Управление виртуальными смарт-картами и ключами
Рутокен KeyBox
Рутокен KeyBox — система администрирования и управления жизненным циклом ключевых носителей и сертификатов от компании «Актив». Она объединяет учётные записи пользователей, средства аутентификации и политики безопасности. Серверная и клиентская части работают в Windows и Linux.
KeyBox позволяет регистрировать носители, назначать их пользователям, выпускать и обновлять сертификаты, блокировать и отзывать средства аутентификации. Пользователь может самостоятельно менять PIN-код, обновлять сертификаты и отзывать удостоверение при утрате носителя.
Администраторы могут настраивать политики подключения к удостоверяющим центрам, шаблоны сертификатов, параметры жизненного цикла носителей и требования к PIN-кодам, а также выполнять резервное копирование ключевой информации.
Журнал операций позволяет отслеживать действия с носителями и формировать отчёты по пользователям, устройствам, событиям и исполнителям.
Рисунок 3. Компоненты системы (Источник: Рутокен)
Особенности продукта:
- Подходит для: организаций, которым требуется централизованное управление средствами аутентификации.
- Сильные стороны: управление жизненным циклом носителей и сертификатов, работа с устройствами разных производителей (Рутокен, JaCarta, ESMART, eToken, YubiKey и др.), самообслуживание пользователей, аудит операций.
- Ограничения: KeyBox не заменяет механизм строгой аутентификации, инфраструктуру открытых ключей (PKI) или систему контроля состояния устройства, а управляет средствами аутентификации и их жизненным циклом.
- Когда выбирать: если нужна альтернатива физическим носителям, сертификатная модель аутентификации и централизованное управление удостоверениями.
Рутокен KeyBox включён в Единый реестр российского ПО (реестровая запись № 18160 от 29.06.2023) и сертифицирован ФСТЭК (сертификат № 4972 от 04.09.2025).
Больше информации — на сайте компании.
JaCarta Management System (JMS)
JaCarta Management System (JMS) — система для управления аппаратными и программными средствами аутентификации и электронной подписи для Microsoft Windows от компании «Аладдин». Система управляет токенами, смарт-картами, сертификатами и другими средствами аутентификации.
Для отказа от физических носителей JMS умеет выпускать сертификаты непосредственно в хранилище компьютера и TPM. Можно использовать сертификатную аутентификацию без USB-токена.
JMS автоматически выдаёт и отзывает сертификаты по заданным политикам. Например, профиль можно связать с группой в Active Directory: при добавлении пользователя в группу JMS выпускает сертификат, при удалении — отзывает.
Для пользователей есть веб-портал самообслуживания. Сотрудник может самостоятельно выпускать, блокировать и заменять токены, менять PIN-код.
Рисунок 4. Управление жизненным циклом токенов (Источник: компания «Аладдин Р. Д.»)
Особенности продукта:
- Подходит для: организаций, которым нужно централизованно управлять токенами, сертификатами и программными средствами аутентификации.
- Сильные стороны: управление жизненным циклом токенов и сертификатов; выпуск сертификатов в хранилище ПК и TPM; интеграция с УЦ и Active Directory; поддержка средств аутентификации разных производителей.
- Ограничения: серверная часть работает на Windows Server; для некоторых компонентов требуется Microsoft SQL Server.
- Когда выбирать: если нужно централизованно управлять физическими и программными средствами аутентификации и постепенно отказаться от USB-токенов в отдельных сценариях.
JMS включена в Единый реестр российского ПО (реестровая запись № 311 от 08.04.2016).
Больше информации — на сайте компании.
Сертификатная и мобильная аутентификация
КриптоПро Ключ
Программный комплекс «КриптоПро Ключ» предназначен для выполнения криптографических операций, в том числе для создания электронной подписи с использованием пользовательских ключей. Ключи могут храниться в мобильном приложении, в распределённом виде — между приложением и сервером, а также на рабочем месте пользователя в режиме «КриптоПро Ключ Lite».
Для выполнения криптографических операций на серверных компонентах используется программно-аппаратный комплекс (ПАКМ) «КриптоПро HSM». На мобильных устройствах доступны приложения «КриптоПро Ключ» и «КриптоКлюч».
Для начала работы пользователь регистрирует учётную запись, устанавливает мобильное приложение и привязывает устройство к учётной записи. Затем он создаёт запрос на выпуск сертификата и после его выпуска устанавливает сертификат.
Рисунок 5. Настройка аутентификации через мобильное приложение (Источник: КриптоПро)
Особенности продукта:
- Подходит для: бизнеса и госсектора, сотрудники которых планируют отказаться от привязки к аппаратным USB-токенам и рабочим местам и подписывать документы с личного мобильного устройства.
- Сильные стороны: поддержка распределённого хранения и использования пользовательских ключей; создание усиленной квалифицированной электронной подписи (УКЭП) в разных форматах.
- Ограничения: необходимость развёртывания серверной архитектуры с ПАКМ «КриптоПро HSM».
- Когда выбирать: если требуется формировать УКЭП и использовать разные способы хранения пользовательских ключей.
ПК «КриптоПро Ключ» версии 1.0 (исполнения 1–5) сертифицирован ФСБ России (сертификат № СФ/124-5210 от 10.07.2025). Продукт включён в Единый реестр российского ПО (реестровая запись № 17932 от 13.06.2023).
Больше информации — на сайте компании.
ViPNet PKI Client
ViPNet PKI Client — программный комплекс компании «ИнфоТеКС» для работы в инфраструктуре открытых ключей (PKI).
ViPNet PKI Client позволяет создавать и проверять электронную подпись, шифровать и расшифровывать файлы, работать с сертификатами и формировать запросы на их получение. Клиент также используется для аутентификации пользователей и организации защищённых TLS-соединений с применением криптографических алгоритмов ГОСТ.
Продукт включает функциональные модули для основных пользовательских сценариев работы в PKI.
Рисунок 6. Пример схемы использования ViPNet PKI Client (Источник: ИнфоТеКС)
Особенности продукта:
- Подходит для: организаций, которым нужна работа с PKI, сертификатами и криптографической аутентификацией на компьютерах и мобильных устройствах.
- Сильные стороны: поддержка Windows, Linux, Android, iOS и ОС «Аврора»; кроссбраузерная работа с электронной подписью и доступ к веб-ресурсам по протоколу TLS ГОСТ; поддержка разных устройств для хранения ключей и сертификатов; поддержка TLS 1.2 и 1.3; совместимость со СКЗИ, средствами ЭП и удостоверяющими центрами других производителей.
- Ограничения: набор функций зависит от исполнения.
- Когда выбирать: если нужен продукт, сертифицированный как СКЗИ и средство ЭП классов КС1–КС3.
ViPNet PKI Client внесён в «Единый реестр нотификаций о характеристиках шифровальных (криптографических) средств и товаров, их содержащих». Продукт сертифицирован ФСБ России (сертификат № СФ/124-5364 от 26.12.2025) и включён в Единый реестр российского ПО (реестровая запись № 3601 от 28.06.2017).
Больше информации — на сайте компании.
Аутентификация с привязкой к устройству
Avanpost Unified SSO
Avanpost Unified SSO — решение для единого входа в корпоративные приложения и сервисы. Оно передаёт аутентифицированную сессию между ОС, веб-приложениями, десктопными клиентами, VPN, VDI и другими ресурсами без повторного ввода учётных данных. Поддерживаются протоколы OpenID Connect, SAML, RADIUS, LDAP и Enterprise SSO для устаревших приложений.
Для отказа от физических токенов в нём используется технология E-Passport — цифровое удостоверение, связанное с конкретным устройством.
Ключевая пара для E-Passport генерируется непосредственно на устройстве, а закрытый ключ хранится в защищённом хранилище в неизвлекаемом виде. В зависимости от платформы используются TPM (Windows), Secure Enclave (iOS/macOS) или Keystore (Android). Сертификат для E-Passport выпускается доверенным удостоверяющим центром Avanpost CA или Microsoft CA.
После первичной проверки пользователя (с использованием MFA) E-Passport устанавливается на устройство и связывается с ним. С этого момента устройство считается доверенным. Система проверяет наличие E-Passport при каждом обращении к ресурсу и предоставляет доступ без повторного ввода учётных данных. Криптографическая привязка сессии к устройству (Device Binding) защищает от перехвата сессионных cookie-файлов и клонирования сессии на другое устройство.
E-Passport позволяет перенести функцию физического носителя с отдельного токена на само устройство. Это устраняет необходимость выдавать сотруднику USB-токен или смарт-карту, но одновременно создаёт зависимость от конкретного компьютера или смартфона. При потере или замене устройства корпоративное удостоверение необходимо заблокировать или отозвать, после чего зарегистрировать новое устройство и выпустить новое удостоверение.
Рисунок 7. Окно настройки двухфакторной аутентификации (Источник: Avanpost)
Особенности продукта:
- Подходит для: компаний, использующих несколько информационных систем (веб-, десктопные и legacy-приложения), которым требуется единый доступ без повторного ввода учётных данных, особенно в гибридных и удалённых сценариях работы.
- Сильные стороны: криптографическая привязка E-Passport к устройству; неизвлекаемое хранение закрытого ключа в защищённом хранилище; поддержка Windows, Linux, iOS и Android; единая аутентификация для разных типов корпоративных ресурсов; защита сессии от перехвата и клонирования.
- Ограничения: E-Passport не заменяет удостоверяющий центр. Уровень аутентификации определяется всей схемой его использования. Для контроля состояния BYOD могут потребоваться дополнительные средства MDM/UEM.
- Когда выбирать: если нужно заменить физический токен цифровым удостоверением, привязанным к компьютеру или мобильному устройству, и при этом сохранить сертификатную модель аутентификации и единый доступ к корпоративным ресурсам, включая legacy-приложения.
Avanpost Unified SSO входит в экосистему Avanpost (FAM, MFA+, Device Control) и строится на принципах Zero Trust.
Больше информации — на сайте компании.
Управление устройствами в BYOD
Эти решения не заменяют механизм строгой аутентификации, но дополняют его. Они позволяют контролировать состояние устройств, применять политики безопасности, управлять корпоративными приложениями и сертификатами, а при необходимости блокировать устройство или удалять с него корпоративные данные.
«Аврора Центр»
«Аврора Центр» — UEM-платформа компании «Открытая мобильная платформа» для централизованного управления устройствами и корпоративными приложениями. Она позволяет администрировать парк до двух миллионов устройств — смартфонов, планшетов, настольных компьютеров, ноутбуков, ТСД, SoftPOS-терминалов и киосков — под управлением ОС «Аврора», Android, включая AOSP-сборки, и российских дистрибутивов Linux.
Платформа позволяет применять политики безопасности, проводить инвентаризацию и мониторинг устройств, управлять приложениями и настраивать сетевые подключения. Для Android поддерживается режим «киоска», в котором устройство можно ограничить набором разрешённых функций и приложений.
«Аврора Центр» поддерживает доставку корневых и пользовательских сертификатов и интеграцию с Microsoft Active Directory, Samba DC, ALD Pro, FreeIPA и центрами сертификации. Сертификаты можно доставлять на управляемые устройства и удалять с них.
Платформа также поддерживает настройку Wi-Fi, удалённую блокировку и очистку устройства при потере, а для Linux — принудительное удаление информации с утерянного устройства. Приложения можно централизованно публиковать, устанавливать, обновлять и удалять без участия пользователя.
Рисунок 8. Привязка устройства к пользователю, синхронизированному в ПУ (Источник: «Аврора Центр»)
Особенности продукта:
- Подходит для: крупных предприятий, государственных структур, банков и компаний из ритейла, логистики, транспорта, промышленности и энергетики, которым нужно централизованно управлять смартфонами, планшетами, ТСД (терминалы сбора данных) и компьютерами на ОС «Аврора», Android и Linux.
- Сильные стороны: работа в закрытом корпоративном контуре; управление тремя ОС из одной платформы; доставка сертификатов; интеграция с Microsoft Active Directory и центрами сертификации; режим «киоска» для Android.
- Ограничения: «Аврора Центр» управляет устройствами и сертификатами, но не является самостоятельным средством строгой аутентификации. Для сертификатной аутентификации требуется внешняя инфраструктура сертификации, с которой платформа интегрируется.
- Когда выбирать: если нужно управлять устройствами на ОС «Аврора», Android и Linux в закрытом корпоративном контуре, централизованно применять политики безопасности и доставлять сертификаты для подключения к корпоративным сервисам.
«Аврора Центр» сертифицирована ФСТЭК России (сертификат № 4203, действует до 30.12.2029). Продукт включён в Единый реестр российского ПО (реестровая запись № 6875 от 01.09.2020).
Больше информации — на сайте компании.
Avanpost Device Control
Avanpost Device Control — решение для контроля устройств и оценки их защищённости. Оно анализирует устройства пользователей, определяет уровень риска и позволяет учитывать эти данные при предоставлении доступа к корпоративным ресурсам.
Device Control входит в линейку Avanpost Access и может использоваться вместе с Avanpost FAM и MFA+. В такой архитектуре сведения об устройстве становятся дополнительным контекстом для принятия решения о доступе.
Решение позволяет регистрировать устройства пользователей и управлять ими из единой системы. Администратор может отслеживать устройства, просматривать информацию о них и использовать политики, учитывающие состояние устройства.
Для аутентификации Avanpost FAM/MFA+ поддерживает разные механизмы, в том числе сертификаты, смарт-карты, WebAuthn и программные OTP. Device Control при этом отвечает не за сам фактор аутентификации, а за оценку устройства, с которого пользователь получает доступ.
При входе с доверенного устройства система запоминает его цифровой отпечаток (fingerprint) и упрощает последующую аутентификацию. Например, запрашивает один фактор вместо двух. Для десктопных устройств это делается через компонент Avanpost FAM Agent, для мобильных — через приложение Avanpost Authenticator.
При потере или компрометации устройства пользователь через личный кабинет может пометить его как скомпрометированное, после чего система завершает все активные сессии и блокирует вход с этого устройства.
Рисунок 9. Пример интерфейса в Avanpost DS (Источник: Avanpost)
Особенности продукта:
- Подходит для: организаций, которым нужен контроль доступа к корпоративным ресурсам с личных устройств сотрудников без внедрения полноценной MDM/UEM-платформы.
- Сильные стороны: оценка защищённости устройств, контекстные политики доступа и интеграция с механизмами аутентификации Avanpost.
- Ограничения: Device Control не заменяет фактор аутентификации. Для построения полноценного процесса доступа он используется вместе с другими компонентами Avanpost, например FAM или MFA+.
- Когда выбирать: если при аутентификации важно учитывать не только личность пользователя, но и устройство, с которого он подключается.
Больше информации — на сайте компании.
Cloud Mobile Device Management
Cloud MDM — решение российского поставщика ИТ-услуг и облачных сервисов Beeline Cloud для централизованного управления корпоративными и личными мобильными устройствами сотрудников.
Сервис интегрируется с инфраструктурой заказчика и предоставляется по модели Self‑Service. Администратор управляет устройствами через веб-консоль: регистрирует их, применяет политики безопасности и настраивает параметры.
Cloud MDM поддерживает разграничение личной и корпоративной информации на устройстве. Организация получает контроль над корпоративной частью устройства, тогда как личные приложения и данные сотрудника остаются вне управления.
Рисунок 10. Веб-консоль Cloud MDM (Источник: beeline cloud)
Особенности продукта:
- Подходит для: организаций, которым нужно управлять корпоративной частью личных устройств сотрудников в BYOD-сценариях и централизованно применять к ней политики безопасности.
- Сильные стороны: облачная модель предоставления без необходимости собственной инфраструктуры; поддержка BYOD с разграничением рабочих и личных данных; автоматическая доставка корпоративных настроек и сертификатов; поддержка широкого спектра ОС и управление устройствами из единой консоли.
- Ограничения: Cloud MDM предназначен для управления устройствами и не является механизмом строгой аутентификации. Для использования сертификатов потребуется соответствующая PKI и инфраструктура удостоверяющего центра. Набор доступных функций зависит от операционной системы и режима управления устройством.
- Когда выбирать: если в BYOD-архитектуре нужно отделить корпоративную рабочую среду от личной, централизованно применять политики безопасности и доставлять сертификаты на устройства без выдачи сотрудникам физических носителей.
Больше информации — на сайте компании.
Kaspersky Secure Mobility Management
Kaspersky Secure Mobility Management (KSMM) — решение для управления мобильными устройствами и их защитой. Платформа поддерживает Android, iOS и ОС «Аврора» и управляется через Kaspersky Security Center.
Для личных устройств предусмотрены отдельные режимы управления. На Android можно использовать режим личного устройства и корпоративный контейнер, который изолирует рабочую среду от личной. Для iOS доступны базовое управление личным устройством и расширенное управление корпоративным устройством.
KSMM позволяет централизованно настраивать параметры устройств, управлять приложениями, ограничениями и корпоративными данными, а также настраивать Wi-Fi . Администратор также может удалённо заблокировать устройство или удалить с него корпоративные данные.
KSMM позволяет создавать, устанавливать, продлевать и удалять мобильные сертификаты, а также интегрироваться с инфраструктурой открытых ключей. Для Android поддерживается получение сертификатов через SCEP (Simple Certificate Enrollment Protocol, протокол автоматической выдачи сертификатов).
Сертификаты могут использоваться для идентификации мобильного устройства и настройки корпоративной почты. При интеграции с PKI система может автоматически выдавать сертификаты при подключении устройства.
Рисунок 11. Архитектура Kaspersky Secure Mobility Management (Источник: Kaspersky)
Особенности продукта:
- Подходит для: компаний, сотрудники которых используют мобильные устройства для работы, в том числе личные устройства в BYOD-сценариях.
- Сильные стороны: разделение корпоративных и личных данных, управление сертификатами и интеграция с PKI.
- Ограничения: KSMM управляет устройствами и сертификатами, но не является самостоятельным механизмом строгой аутентификации. Для неё нужны отдельный сервис аутентификации и соответствующая инфраструктура.
- Когда выбирать: если нужно управлять мобильными устройствами в BYOD-сценариях и автоматически доставлять на них корпоративные сертификаты для Wi-Fi, почты и других сервисов.
Больше информации — на сайте компании и в нашем обзоре.
SafeMobile UEM
SafeMobile UEM — платформа класса UEM/MDM для централизованного управления конечными устройствами на Android, iOS/iPadOS, «Аврора», Windows и Linux из единой консоли. Набор функций зависит от операционной системы.
UEM SafeMobile поддерживает автоматическую выдачу клиентских сертификатов через SCEP (Simple Certificate Enrollment Protocol, протокол автоматической выдачи сертификатов). Платформа получает сертификат из корпоративного удостоверяющего центра и распространяет его на устройства. Сертификаты можно использовать, например, для подключения к корпоративной почте, Wi-Fi, VPN и Microsoft Exchange.
В версии 14.1 появилась поддержка доставки сертификатов и настройки Wi-Fi с аутентификацией по SCEP для устройств на «Авроре». В версии 16.0 появилась возможность автоматически предоставлять указанным Android-приложениям доступ к сертификату без подтверждения его выбора пользователем.
В июне 2026 года SafeMobile и SafeTech Lab объявили об интеграции UEM SafeMobile с SafeTech CA для автоматического выпуска и обновления сертификатов.
Для BYOD SafeMobile создаёт отдельный корпоративный контур: на Android это рабочий профиль (Google или Samsung Knox), на iOS — управляемые приложения с запретом передачи данных в неуправляемые. В нём можно размещать рабочие приложения и данные, не предоставляя организации доступ к личным файлам пользователя. Администратор задаёт политики безопасности и требования к паролю, управляет корпоративными приложениями, может удалённо заблокировать устройство или удалить корпоративные данные из рабочей области.
Рисунок 12. Техническая архитектура UEM SafeMobile (Источник: SafeMobile)
Особенности продукта:
- Подходит для: организаций с повышенными требованиями к ИБ — банков, государственных учреждений, промышленных и транспортных компаний, которым нужна российская UEM-платформа для управления корпоративными и личными мобильными устройствами, с которых сотрудники получают доступ к корпоративным сервисам.
- Сильные стороны: поддержка Android/AOSP, iOS, «Аврора», Windows и Linux; настройка политик безопасности и реагирование на компрометацию устройств; автоматическая выдача и отзыв сертификатов через SCEP; более 400 тыс. устройств под управлением платформы.
- Ограничения: SafeMobile UEM не заменяет удостоверяющий центр. Для автоматической выдачи сертификатов требуется подключение к корпоративному УЦ или использование настроенного SCEP-сервера.
- Когда выбирать: если нужно объединить управление устройствами, защиту корпоративных данных в BYOD и сертификатную аутентификацию для доступа к Wi-Fi, почте и другим корпоративным сервисам.
- если нужно объединить управление устройствами, защиту корпоративных данных в BYOD и сертификатную аутентификацию для доступа к Wi-Fi, почте и другим корпоративным сервисам.
SafeMobile UEM включена в Единый реестр российского ПО (реестровая запись № 11745 от 15.10.2021) и сертифицирована ФСТЭК России по 4-му уровню доверия (сертификат № 4845 от 30.08.2024).
Больше информации — на сайте компании.
WorksPad MDM
WorksPad MDM — модуль управления мобильными устройствами в составе платформы WorksPad EMM от компании «РуПост». Это полноценное EMM-решение, объединяющее суперапп, платформу для микроприложений и MDM в одном продукте. Предназначено для централизованного управления корпоративными и личными мобильными устройствами на iOS и Android.
Для отказа от физических токенов WorksPad MDM поддерживает SCEP для автоматической доставки пользовательских сертификатов на управляемые устройства. Сертификаты могут использоваться для аутентификации во встроенном браузере WorksPad.
Для BYOD корпоративные данные защищаются в суперапп-контейнере WorksPad. Такой подход позволяет отделить рабочую информацию от личных данных пользователя, не распространяя контроль MDM на всё устройство. В случае потери устройства администратор может удалить корпоративные данные. Доступна версия с ГОСТ-шифрованием данных в контейнере.
Рисунок 13. Кластерная архитектура развёртывания WorksPad (Источник: WorksPad)
Особенности продукта:
- Подходит для: организаций, которым нужно организовать защищённую мобильную работу сотрудников на iOS и Android, в том числе с личных устройств, и использовать сертификатную аутентификацию без обязательного применения физических токенов.
- Сильные стороны: поддержка BYOD с изоляцией корпоративных данных в суперапп-контейнере; автоматическая доставка сертификатов через SCEP; встроенная интеграция с Active Directory, DLP и VPN; версия с шифрованием данных в контейнере по ГОСТ.
- Ограничения: WorksPad MDM предназначен для управления мобильными устройствами и защиты корпоративных данных, а не является самостоятельным механизмом строгой аутентификации. Сертификатная аутентификация требует соответствующей PKI-инфраструктуры.
- Когда выбирать: если в BYOD-архитектуре нужно защитить корпоративные данные на личных смартфонах и планшетах, отделить их от личной информации пользователя и использовать сертификаты для доступа к корпоративным ресурсам без обязательной выдачи физических токенов.
WorksPad включён в Единый реестр российского ПО (реестровая запись № 4106 от 11.12.2017).
Больше информации — на сайте компании и в нашем обзоре.
Как выбирать решение
При выборе решения для строгой аутентификации без физического токена важно сначала определить, что именно должно заменить токен и какие требования предъявляются к устройству:
- Если нужна сертификатная аутентификация с виртуальной смарт-картой на компьютере или централизованное управление сертификатами — Рутокен KeyBox или JaCarta Management System.
- Если нужна аутентификация с использованием сертификатов на мобильных устройствах — КриптоПро Ключ или ViPNet PKI Client.
- Если нужна беспарольная аутентификация по FIDO2/passkey с аппаратным хранением ключей — Рутокен Pass.
- Если нужен единый вход с криптографической привязкой удостоверения к устройству — Avanpost Unified SSO.
- Если важно контролировать состояние личных устройств сотрудников (BYOD) — Avanpost Device Control, Kaspersky Secure Mobility Management, SafeMobile UEM, WorksPad MDM, «Аврора Центр», Cloud MDM.
- Если нужна защищённая работа с личного устройства без полного контроля над ним — решения с поддержкой BYOD и контейнеризации, например WorksPad MDM или Kaspersky Secure Mobility Management.
Эти решения могут быть компонентами архитектуры строгой аутентификации по ГОСТ Р 58833-2020. Рутокен KeyBox, Avanpost Unified SSO / E-Passport и системы с аппаратным хранением ключей в TPM/Secure Enclave/Keystore — примеры таких компонентов, но их наличие само по себе не гарантирует соответствия ГОСТ.
При замене физического токена на удостоверение, привязанное к устройству, предусмотрите сценарии потери, замены или компрометации устройства: блокировку удостоверения, отзыв сертификата и регистрацию нового устройства.
Выводы
Отказ от физического токена возможен, но не любая технология сама по себе обеспечивает строгую аутентификацию по ГОСТ Р 58833-2020. Ключевые требования — использование двух факторов, взаимная аутентификация и применение криптографических протоколов.
Виртуальная смарт-карта может быть частью строгой аутентификации при условии аппаратной защиты ключа (TPM) и использования второго фактора (PIN, биометрия).
Windows Hello for Business в соответствующей архитектуре может обеспечить строгую аутентификацию: ключ, привязанный к устройству, выступает фактором владения и защищается TPM, а PIN-код является фактором знания, биометрия — фактором присущности. При этом взаимная аутентификация и криптографические протоколы обеспечиваются выбранной моделью доверия и инфраструктурой аутентификации.
FIDO2 и passkeys также могут быть компонентами строгой аутентификации, но это зависит от конкретной реализации, способа защиты ключа, используемых факторов и криптографических протоколов.
Для BYOD одного механизма аутентификации недостаточно. Нужен контроль состояния устройства. MDM/UEM не заменяет строгую аутентификацию, но дополняет её, позволяя проверять соответствие устройства политикам безопасности и управлять сертификатами.
Выбор решения зависит от того, какие ресурсы защищаются, какие устройства используют сотрудники и какие регуляторные требования необходимо соблюдать.
Для российского рынка дополнительный фактор — требования к отечественным криптоалгоритмам (ГОСТ), сертифицированным СКЗИ и совместимости с российскими ОС и корпоративными системами.
