Строгая аутентификация по требованиям ФСТЭК: когда она нужна и как реализовать

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

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

Разберёмся, что такое строгая аутентификация, чем она отличается от MFA и 2FA, какие пользователи и ресурсы требуют особого внимания и как организовать защищённый доступ, в том числе в закрытом контуре.

Что такое строгая аутентификация

Само понятие MFA широкое по охвату методов: любая комбинация двух разнородных факторов (пароль + SMS, пароль + TOTP, биометрия + пуш) образует MFA.

Строгая аутентификация — это определенное подмножество механизмов аутентификации. Строгая аутентификация выдвигает жесткое техническое требование к стойкости самого протокола: защита от перехвата и атак повторного воспроизведения (replay-атак) с помощью асимметричной криптографии/челленджа.

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

Важно: строгая аутентификация определяется не количеством факторов. Два фактора сами по себе не делают аутентификацию строгой.

Например, схема «пароль + одноразовый код» является многофакторной аутентификацией, но не обязательно строгой. То же относится к другим распространённым способам дополнительного подтверждения — пуш, SMS, звонкам и подобным механизмам.

При этом строгая аутентификация может быть многофакторной, но MFA и строгая аутентификация — не синонимы.

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

В текущем наборе методов MULTIFACTOR именно FIDO2-токены относятся к механизмам строгой аутентификации. Остальные доступные способы дополнительного подтверждения — например, пуш, OTP, SMS или звонок — позволяют реализовать MFA, но сами по себе не являются строгой аутентификацией.

Подробнее термин разобран в глоссарии MULTIFACTOR.

Что здесь регулирует ФСТЭК

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

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

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

Отдельно стоит учитывать изменения нормативной базы. Например, в материале о приказе ФСТЭК № 117 мы подробно разбирали изменения требований и их влияние на защиту информационных систем.

Кого в первую очередь защищать строгой аутентификацией

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

Привилегированные пользователи

Учётная запись администратора имеет значительно больше возможностей, чем обычная пользовательская. Через неё можно менять настройки, управлять пользователями, устанавливать программное обеспечение и получать доступ к критичным ресурсам.

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

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

Пользователи удалённого доступа

VPN, RDP, VDI и SSH являются дополнительными точками входа в корпоративную инфраструктуру. Если доступ к ним защищён только паролем, компрометация учётной записи может привести к попытке подключения извне.

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

Внешние и гостевые пользователи

Отдельного внимания требуют подрядчики, партнёры и другие пользователи, которым предоставляется ограниченный доступ к корпоративным ресурсам.

Здесь важно определить не только способ аутентификации, но и жизненный цикл учётной записи: кто выдаёт доступ, на какой срок, к каким ресурсам он предоставляется и как быстро отзывается.

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

Строгая аутентификация и КИИ

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

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

• требования, применимые к конкретному объекту;
• класс защищённости;
• модель угроз;
• категории пользователей;
• состав защищаемых ресурсов;
• используемые средства защиты;
• особенности сетевой архитектуры.

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

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

Подробнее о сертифицированном решении для объектов КИИ можно узнать на странице MULTIFACTOR ФСТЭК.

Как реализовать строгую аутентификацию

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

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

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

Такой подход позволяет не менять существующую систему управления пользователями, а добавить дополнительный механизм проверки при обращении к защищаемым ресурсам.

А если инфраструктура находится в закрытом контуре?

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

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

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

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

Какие механизмы аутентификации можно использовать

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

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

Что нужно проверить перед внедрением

Перед тем как выбирать конкретное решение, стоит пройтись по нескольким вопросам.

1. Какие ресурсы нужно защищать?
VPN, RDP, VDI, SSH, веб-приложения, административные панели, облачные сервисы.

2. Кто получает доступ?
Штатные сотрудники, администраторы, подрядчики, партнёры, гости.

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

4. Какие учётные записи наиболее критичны?
В первую очередь стоит определить привилегированные аккаунты и доступ к наиболее важным ресурсам.

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

6. С чем должна интегрироваться система аутентификации?
Например, с Active Directory, LDAP, VPN, VDI, RDP или корпоративными приложениями.

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

8. Как контролируются события?
Важно понимать, какие события аутентификации фиксируются и где затем анализируются.

Ошибки при внедрении строгой аутентификации

Считать любую MFA строгой аутентификацией

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

Защищать только одну точку входа

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

Использовать одинаковую политику для всех

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

Забывать про гостевые учётные записи

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

Не учитывать закрытый контур

Если инфраструктура не имеет выхода в интернет, это нужно учитывать до внедрения решения, а не после.

Считать сертификат гарантией соответствия всей инфраструктуры

Сертификат ФСТЭК относится к конкретному средству и установленной области его применения. Он не означает автоматически, что вся информационная система организации соответствует требованиям регулятора.

MULTIFACTOR для многофакторной и строгой аутентификации

Система многофакторной аутентификации и контроля доступа MULTIFACTOR позволяет организовать многофакторную аутентификацию пользователей при доступе к корпоративным ресурсам, включая VPN, RDP, VDI, SSH, Windows, Linux и облачные приложения.

Решение интегрируется с корпоративными каталогами и поддерживает технологию единого входа SSO. Для разных сценариев можно использовать пуш, OTP, SMS, звонок, Telegram и другие способы подтверждения.

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

Для защищённых информационных систем доступна сертифицированная версия решения. MULTIFACTOR имеет сертификат ФСТЭК России № 5039 и 4-й уровень доверия.

Подробнее о требованиях и возможностях сертифицированной версии — на странице MULTIFACTOR ФСТЭК.

FAQ

Что такое строгая аутентификация?

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

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

Чем строгая аутентификация отличается от MFA?

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

Например, пароль + OTP — это MFA, но не обязательно строгая аутентификация. FIDO2-токен использует криптографический механизм и в соответствующем сценарии относится к строгой аутентификации.

Обязательна ли двухфакторная аутентификация по требованиям ФСТЭК?

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

Нужна ли строгая аутентификация привилегированным пользователям?

Привилегированные учётные записи требуют отдельного внимания при построении политики доступа из-за объёма предоставляемых им полномочий. Конкретные требования зависят от защищаемой системы и действующих для неё мер безопасности.

Можно ли использовать строгую аутентификацию в закрытом контуре?

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

Можно ли считать OTP или пуш строгой аутентификацией?

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

Использует ли MULTIFACTOR строгую аутентификацию?

Да. В текущем наборе методов MULTIFACTOR строгая аутентификация реализуется с использованием FIDO2-токенов. 

Есть ли у MULTIFACTOR сертификат ФСТЭК?

Да. Сертифицированная версия MULTIFACTOR имеет сертификат ФСТЭК России № 5039 и 4-й уровень доверия.

Используемые термины

Многофакторная аутентификация (MFA) — способ подтверждения личности с использованием двух или более независимых факторов аутентификации.

Двухфакторная аутентификация (2FA) — способ аутентификации, при котором для подтверждения личности используются два независимых фактора.

Строгая аутентификация — способ аутентификации с высоким уровнем защиты, основанный на криптографической стойкости механизма и его устойчивости к компрометации.

FIDO2 — набор стандартов для криптографически защищённой аутентификации без передачи серверу общего секретного ключа пользователя.

FIDO2-токен — аппаратное устройство, используемое для криптографического подтверждения личности пользователя.

VPN (Virtual Private Network) — технология организации защищённого сетевого соединения поверх другой сети, в том числе для удалённого доступа к корпоративным ресурсам.

RDP (Remote Desktop Protocol) — протокол Microsoft для удалённого подключения к рабочему столу и приложениям Windows.

VDI (Virtual Desktop Infrastructure) — инфраструктура виртуальных рабочих столов, в которой пользователь получает удалённый доступ к виртуальной рабочей среде.

SSH (Secure Shell) — протокол защищённого удалённого доступа к системам и выполнения команд, широко используемый для администрирования серверов.

Active Directory — служба каталогов Microsoft для централизованного управления пользователями, компьютерами и другими объектами доменной инфраструктуры.

LDAP (Lightweight Directory Access Protocol) — протокол доступа и взаимодействия со службами каталогов.

SSO (Single Sign-On) — технология единого входа, позволяющая пользователю получить доступ к нескольким связанным системам после одной успешной аутентификации.

OTP (One-Time Password) — одноразовый пароль, который используется для дополнительного подтверждения личности пользователя.

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