Михаил Ванин, Identity Blitz: Мы хотим, чтобы внедрение IАМ-систем было таким же простым, как настройка роутера

Редакция Anti-malware.ru пообщалась с Михаилом Ваниным, генеральным директором компании Identity Blitz, о переходе к беспарольной аутентификации и связанных с этим рисках. В интервью обсудили Passkey и FIDO2, социальную инженерию и фишинг, роль IAM-систем в крупных организациях, влияние регуляторов на рынок, а также практические рекомендации для компаний, которые только начинают внедрять современные механизмы аутентификации.

Михаил, первый вопрос — насчёт беспарольного будущего. Оно часто преподносится как абсолютное благо, однако не хочется, чтобы появились новые риски и векторы атак, которые будут порождены этим самым беспарольным будущим. Например, уязвимости в самих аутентификаторах, биометрике, TPM-чипах или риск социальной инженерии, направленный на перепривязку устройств. Как индустрия должна готовиться к этим вызовам уже сейчас?

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

Во-первых, это, конечно, FIDO2 и Passkey, так называемые ключи доступа, которые сейчас активно продвигаются на мировом уровне в качестве альтернативы паролям.

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

В-третьих, мы можем наблюдать сейчас в популярных сервисах (Яндекс, Сбер, «Госуслуги») возможность входа с помощью QR-кода, когда мы уже залогинены на мобильном телефоне, в мобильном приложении. Это облегчает возможность входа на компьютере путём сканирования показанного нам QR-кода без необходимости ввода пароля.

И в-четвёртых, вход через внешних поставщиков идентификации: «Госуслуги», банковские сервисы, Яндекс, ВК, Mail.ru, МТС.

Какие беспарольные способы не хочется рассматривать, так это различные варианты одноразовых паролей, присылаемых на СМС и email, которые, в принципе, в определённых сценариях работают (Wildberries и Ozon, например), но я бы их не формулировал как абсолютное благо.

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

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

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

Например, я в «Госуслуги» предпочитаю входить с помощью QR-кода. И заметил, что в какой-то момент сервис мне стал предлагать не сразу экран с подтверждением входа, а сначала показывает промежуточный красный экран и спрашивает, нет ли какого-то незнакомца, который просит меня сейчас отсканировать QR-код. Причём кнопки «ДА» и «НЕТ» всегда стоят в разных местах: это опять же свидетельство, что данный способ взяли в эксплуатацию злоумышленники.

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

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

Можно предположить, что если этот способ будет массовым, то пользователям будут звонить и обманным путём уговаривать их привязать к своему Apple ID или Google Account устройство злоумышленника. А дальше будет происходить следующее. Если мы выпускаем ключ безопасности с сохранением в наших устройствах платформенно (происходит, когда мы соглашаемся на вход по Face ID, Touch ID, отпечатку пальца, лицу или с технологией Windows Hello), то в момент выпуска ключи сохраняются не только в надёжном TPM-модуле нашего устройства, но также распространяются через экосистему на другие наши устройства в этой же экосистеме.

Например, если у меня несколько устройств подвязано к одному Apple ID, то, когда я выпущу Passkey на телефоне, он магическим образом попадёт и в мой компьютер Apple, и в мой планшет. И если каким-то образом злоумышленник смог убедить меня подвязать свои устройства к моему Apple ID, то шаринг (распространение) этих ключей безопасности произойдёт и в устройство злоумышленника.

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

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

Например, проводится техобслуживание, включён особый режим, и мне «рекомендуется воспользоваться альтернативными способами входа». Если у меня эти способы не отключены, то, вполне возможно, я стану жертвой и воспользуюсь ослабленными методами входа. Чтобы фишинг можно было максимально устранить, в какой-то момент в системе должна появиться возможность отказа от использования пароля, если я уже перешёл на современный способ входа.

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

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

Со временем этот подход изменится: будет проводиться более строгая аттестация ключа доступа, будут учитываться устройства тех или иных производителей. Есть доверие или нет? Прошли они сертификацию FIDO-Альянса (FIDO Alliance) или не прошли? Технологии и стандарты для этого уже существуют.

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

М. В.: Я бы тут разделил постановку проблемы. Сложности в предприятиях возникают в тех случаях, когда в компании каждое приложение самостоятельно реализует процесс входа. И, конечно, если в приложении предусмотрен вход только по паролю, то возможность добавить туда какие-то альтернативные способы означает необходимость доработки этого приложения. И те разработчики, кто это будут делать, могут вовсе не являться специалистами в данном вопросе.

Более прогрессивный подход: компании внедряют себе специализированный инфраструктурный сервис, который отвечает за управление аутентификацией. Это так называемый класс систем Identity Access Management (IAM, управления идентификацией и доступом). И эти системы уже разрабатываются компаниями, которые на задачах управления аутентификацией специализируются.

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

Этот подход существует уже десятилетия. Есть развитые протоколы для взаимодействия приложений с IAM-системами: SAML, OpenID Connect, OAuth 2 и ряд других. Как мне кажется, самое верное — уйти от встроенной идентификации и аутентификации приложения к использованию централизованного решения по управлению аутентификацией. И тогда внедрение новинок, изменение процессов будет выполняться значительно проще.

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

Когда пытаешься ввести какие-то альтернативы паролям, пусть даже прогрессивные, то сталкиваешься с тем, что пользователей сначала нужно этим способам научить. И самое главное — нельзя пока добиться универсальности. Один пользователь имеет смартфон современный, у него есть возможность включить Passkey, он умеет сканировать QR-коды. А у другого — кнопочный телефон, нет подходящих функций в устройстве.

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

С чего же начать? С подключения наиболее востребованных сервисов.

Есть FIDO2-ключи, которые надёжные, но требуют покупки железа. Соответственно, это затраты. Можно использовать биометрию на смартфоне, но в этом случае мы попадаем в зависимость от производительности устройства. Как найти баланс между безопасностью, общей доступностью и удобством? И должен ли бизнес предлагать свой пользовательский выбор из нескольких беспарольных методов, не ведёт ли это к усложнению поддержки?

М. В.: С FIDO2-ключами хочу отметить, что не только требуется покупка железа, но и по-хорошему нужно, чтобы у пользователя было минимум 2 FIDO2-ключа. Потому что один из ключей может оказаться потерянным, и пользователь не сможет входить в систему. Если в Apple-устройствах настраиваешь вход в компьютер по FIDO2-ключу, то нельзя включить его как единственный способ входа, не имея двух ключей.

Биометрия на смартфоне — это тоже в большинстве случаев использование технологии FIDO2, просто в качестве ключей доступа используются не аппаратные, так называемые переносные roaming-ключи, а платформенные, встроенные в смартфон, в его TPM-модуль, и которые реализуются самим устройством.

По поводу зависимости от производителя устройств — я не соглашусь, потому что в FIDO Alliance участвуют разные производители: Apple, Google, Microsoft и другие компании. И то, что у них в конечном счёте получилось, мне нравится. Я могу в устройствах Apple использовать мобильный телефон на Android в качестве смартфона с биометрией, и наоборот, я могу прекрасно заходить в браузер Google или в системы с Microsoft, используя свой iPhone с выпущенным на нём ключом доступа Passkey.

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

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

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

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

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

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

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

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

Также технология может требовать наличия на компьютере Bluetooth и подключения к внешнему интернету.

Если брать регулятора, он интересуется тем, какая используется криптография. Нужна сертифицированная ГОСТ-криптография, а по технологии FIDO2 используется зарубежная. Это тоже может стать проблемой для разрешения к использованию в системах критической инфраструктуры.

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

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

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

Второй пример участия регулятора: у нас есть Единая система идентификации и аутентификации (ЕСИА), к которой не так просто подключиться. Последние изменения, которые ввёл регулятор 1 июля 2025 года: для подключения к ЕСИА необходимо использовать типовые решения, прошедшие оценку корректности встраивания в СКЗИ, либо проводить аналогичные испытания для собственных решений.

То есть регулятор сделал очень большой акцент на проверку того, насколько безопасно используется взаимодействие с СКЗИ. Но публично не было известно ни о каком случае, что именно из-за проблем с криптографией были какие-то инциденты с безопасностью.

В итоге подключиться к ЕСИА весьма сложно, дорого, и явно многие компании не могут это сделать. Они вынуждены пользоваться менее безопасными альтернативами, использовать вход через те же коды СМС, что не добавляет безопасности.

Интересно будет посмотреть, к чему мы придём дальше с этим. С какими проблемами вы сталкивались при решении задачи предоставления доступа к системам разных производителей с разными механизмами аутентификации? И есть ли возможности экосистемности в области идентификации и аутентификации?

М. В.: Экосистемность определённая присутствует. Хороший пример — как раз технологии FIDO2, в которых участвуют конкурирующие вендоры, чтобы заместить пароли и наконец-то предложить такую популярную им альтернативу в виде Passkey, ключей доступа. И благодаря их сотрудничеству можно использовать любые современные браузеры, операционные системы.

Второй пример экосистемности — это развитие стандартов взаимодействия приложений с IAM-системами (по протоколам OpenID Connect, OAuth). Есть производители приложений, которые могут ничего не знать про производителя IAM-систем, делать в своих приложениях возможность входа, ориентируясь, например, на какой-то популярный open-source продукт. Но их приложения легко интегрируются с другими решениями, поддерживающими те же самые стандарты.

Где ощущается недостаток универсальности и стандартизации, так это в решениях по многофакторной аутентификации, завязанных на использовании мобильных приложений. Тут у каждого производителя своё собственное мобильное приложение, API. Иногда API даже закрыты.

Например, у Apple и Google есть свои механизмы для подтверждения операции с использованием любого из устройств, привязанных к Apple ID или Google-аккаунту, но они это используют только внутри своих систем. Какого-то API, чтобы этот механизм можно было задействовать в сторонних приложениях, не предусмотрено.

И если говорить про нас, мы, конечно, приветствуем максимальную совместимость со сторонними решениями. У нас есть поддержка OpenID Connect, SAML, RADIUS, WS-Federation, и благодаря этому почти любое приложение можно с нашим решением состыковать.

С другой стороны, каждый заказчик по-своему хранит учётные записи, у кого-то это Active Directory, ALD Pro, база данных. Мы тоже предоставляем гибкость, чтобы можно было подключаться к любым хранилищам учётных записей заказчика, чтобы не было завязки на необходимость импортирования в наше решение.

И в части поддержки МФА мы тоже считаем, что правильнее на это смотреть как на экосистему, потому что сейчас, если заказчик выбрал решение одного МФА-производителя, он не может его просто так взять и заменить на МФА-решение другого производителя: ему для этого нужно сделать полную переинтеграцию своих приложений. В нашем решении мы пошли по пути, что мы добавляем возможности входа через наш Blitz Identity Provider либо через любое стороннее МФА-решение на выбор заказчика. Он их может даже комбинировать друг с другом.

Некоторые наши заказчики в качестве МФА используют решение Aladdin JAS (JaCarta Authentication Server, JAS). Они им довольны, и мы считаем, что они правильно выбрали это решение и заинтересованы продолжать его использовать. Поэтому, внедряя Blitz, мы добавляем им возможность продолжать использовать Aladdin JAS как специализированное средство для подтверждения входа. С другой стороны, у них появляется возможность его использовать не только в тех приложениях, которые они подружили c Aladdin JAS, но и во всех подключённых к Blitz приложениях.

Этот подход дал нам уже плоды. Например, 2 недели назад мы добавили поддержку мессенджера MAX как средства для подтверждения входа.

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

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

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

Сейчас появился тренд: пользователь проходит один раз многофакторную аутентификацию с устройством, это устройство у него запоминается, для последующих входов пользователя просят установить пин-код, который хранится на устройстве, или включить биометрию FaceID, TouchID. Последующий вход — с помощью пин-кода, отпечатка пальца, лица, биометрии. И некоторого токена, который при этом с устройства передаётся на сервер для проверки.

Этот подход был очень популярен, когда использовались мобильные приложения банкинга, но со временем в банкингах стала развиваться и возможность входа с помощью ключей Passkey. Например, в корпоративный банкинг ВТБ добавилась возможность такого входа, я ей регулярно пользуюсь. В корпоративный банкинг Точка Банка появилась возможность установить пин-код для будущих входов.

Не нужно теперь ждать каждый раз при входе СМС. И к тому же кажется, что банк тоже беспокоится и лишний раз мне СМС не высылает, деньги не тратит.

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

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

Вопрос непосредственно по продуктам вашей компании. Как развивается Blitz Identity Provider сейчас и какие планы по развитию продукта на ближайшие 3−5 лет?

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

У нас находится в разработке механизм более безопасного запоминания устройства с возможностью установить на нем пин-код, чтобы при последующих входах можно было ввести пин-код и создать сессию на устройстве без необходимости вводов логинов, паролей, кодов, СМС и прочего.

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

У нас появилось своё собственное мобильное приложение Blitz Key в операционной системе Android, а также компонент для Windows Logon — чтобы можно было добавить второй фактор аутентификации при входе в операционную систему Windows. В Linux у нас эта возможность была и раньше.

Если смотреть наши более долгосрочные планы на 3−5 лет, то это очень большой горизонт планирования. Нам хочется переработать IAM-платформу, чтобы внедрение нашего продукта было доступно не только компаниям из крупного бизнеса. Ведь сейчас для внедрения IAM-систем нужна техническая экспертиза, нужно разбираться в протоколах, найти нужных специалистов, которые могут администрировать под Linux наше приложение. Для большинства компаний из малого-среднего бизнеса это недоступно.

Мы хотим, чтобы внедрение IАМ-систем было таким же простым, как настройка роутера или возможность поставить контроллер домена MS AD (Microsoft Active Directory).

Рассчитываем, что за 3−5 лет нам удастся достичь такого уровня, что нашу IАМ-систему можно будет просто поставить, как коробочку: включить, выбрать некоторые рекомендуемые режимы и начинать ими пользоваться.

Мне кажется, это было бы шикарно. Один из основных принципов предоставления доступа в текущее время — это Zero Trust Network Access (ZTNA, концепция нулевого доверия). Какую роль играет ваш продукт в его реализации? Можно ли, используя ваш продукт, обеспечить идентификацию устройств, сервисных аккаунтов и API-ключей, которые зачастую становятся слабым звеном?

М. В.: В центре IAM-системы лежит авторизационный фреймворк OAuth 2. Он как раз предназначен для того, чтобы приложения, пройдя авторизацию, получали некоторые билеты авторизационные, access-токены, могли их использовать для вызова защищаемых ресурсов.

Соответственно, мы предоставляем поддержку необходимых стандартов, чтобы выпускать, обменивать и проверять токены. У нас есть вспомогательный компонент Blitz Keeper, который можно ставить как прокси между приложениями и защищаемыми сервисами: он может упростить процесс контроля, обмена, проверки токенов. И мы его тоже в этом году достаточно серьёзно развили. Дополнительно к механизмам OAuth 2.0 Token Exchange мы добавили возможность авторизации GraphQL-запросов, поддержку защиты сервисов с Basic-авторизацией и API Key, а также более простых режимов авторизации.

Что касается использования идентификации устройств в сценариях, когда пользователь входит в веб-приложение, тут есть у нас определённые сложности. Наша система — преимущественно серверная. Возможность идентификации устройства из веб-браузера серьёзно ограничена. Мы, конечно, используем для идентификации IP-адрес, браузерные заголовки, User Agent и Sec-CH-* заголовки. Мы используем браузерный отпечаток, который с каждым обновлением браузеров становится сложнее вычислять, и помечаем устройства, с которых ранее происходили успешные входы с помощью своих cookies: для понимания, что пользователь идёт с известных ранее проверенных устройств.

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

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

И финальный вопрос. Какие 3 шага вы рекомендуете компаниям, которые только начинают переход к современным механизмам аутентификации?

М. В.: Я рекомендую, на самом деле, не 3 шага, а больше, чтобы процесс оказался максимально эффективным.

Начать я рекомендую с выделения в компании определённой проектной группы, которая будет заниматься этим вопросом, чтобы не получалось, что кто-то один участвует в выборе, и потом он становится крайним, если этот выбор произошёл неудачно. К тому же лучше с самого начала привлекать не только людей, которые разбираются в ИТ и ИБ, но и тех, кто будет потом заниматься эксплуатацией, технической поддержкой конечных пользователей, а также людей со стороны бизнеса, чтобы, участвуя вместе в этой проектной группе с самого начала, они могли оказать проекту необходимую поддержку в дальнейшем.

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

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

Далее на этапе выбора решений лучше составить некоторый шорт-лист: что доступно на рынке, отобрать варианты.

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

После объективной оценки, подходят пилотируемые решения или нет, выбрать лучшее, провести его внедрение.

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

Михаил, благодарю, что нашли время пообщаться. Удачи и развития вашему бизнесу в наступающем году!