Пункт 5.6 приложения 3 к ПТКЗИ: многофакторная и многоэтапная аутентификация

Смысл требования

Пункт 5.6 приложения 3 к ПТКЗИ – практический разбор требования «многофакторная аутентификация». Пункт 5.6 относится к усилению аутентификации пользователей информационной системы. Его смысл состоит в том, что одного пароля в отдельных сценариях может быть недостаточно для подтверждения личности пользователя, особенно если речь идёт об удалённом доступе, административных действиях, подписании электронных документов, доступе к чувствительной информации или операциям, имеющим юридические либо существенные организационные последствия.

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

Формулировка требования

Приложение 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ), раздел «Обеспечение криптографической защиты информации», пункт 5.6: «обеспечение многофакторной и (или) многоэтапной аутентификации пользователей в информационной системе (криптографический токен и (или) средства выработки электронной цифровой подписи)».

Обязательность применения

По таблице приложения 3 требование пункта 5.6 имеет отметку «+/–» для всех классов типовых ИС. Следовательно, оно является рекомендуемым для 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл и 3-дсп.

Рекомендательный статус означает, что владелец ИС должен рассмотреть меру и принять обоснованное решение с учётом удалённого доступа, привилегированных ролей, электронных документов, критичных операций и последствий компрометации пароля. Если требование включено в ТЗ, оно становится частью принятой модели СЗИ и должно быть реализовано и проверено в установленном объёме.

Практическая трактовка требования

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

В скобках пункт 5.6 прямо называет криптографический токен и (или) средства выработки ЭЦП. Поэтому нельзя автоматически считать эквивалентом любую комбинацию пароля, SMS-кода, электронной почты или push-уведомления. Такие механизмы могут быть полезными дополнительными мерами, но соответствие именно пункту 5.6 должно подтверждаться выбранной архитектурой, ТЗ и характеристиками применяемого средства.

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

Где многофакторная или многоэтапная аутентификация особенно уместна

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

• Удалённый доступ пользователей. VPN, VDI, терминальные шлюзы, web-доступ и иные удалённые точки входа являются типовыми кандидатами для усиленной аутентификации.
• Административный доступ. Вход в серверы, сетевое оборудование, СЗИ, консоли управления, системы резервного копирования, SIEM и инфраструктурные сервисы должен рассматриваться как повышенный риск.
• Доступ к электронным документам и операциям подписания. Если пользователь подписывает документы ЭЦП, дополнительная проверка личности и контроль ключевого носителя имеют прямое значение для доверия к операции.
• Доступ к чувствительным данным. Медицинские сведения, специальные персональные данные, финансовая информация, юридически значимые записи, государственные или служебные данные могут требовать усиленного режима входа.
• Операции изменения критичных данных. Изменение справочников, прав доступа, реквизитов, статусов, финансовых показателей, медицинских записей или иных значимых объектов может быть защищено дополнительным этапом подтверждения.
• Доступ внешних пользователей и подрядчиков. Для сторонних специалистов, удалённой поддержки и временного доступа парольная модель особенно рискованна.
• Повышение привилегий. Отдельный этап подтверждения может требоваться не при обычном входе, а при переходе к административным функциям или выполнении чувствительной операции.

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

Что следует подтвердить при проверке

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

• проведён ли анализ применимости пункта 5.6 и отражено ли решение в ТЗ или иной проектной документации;
• определены ли категории пользователей и сценарии, где применяется многофакторная или многоэтапная аутентификация;
• указаны ли используемые средства: криптографические токены, средства выработки ЭЦП, сертификаты, ключевые носители, серверы аутентификации или прикладные механизмы;
• закреплён ли порядок выдачи, учёта, хранения, возврата, блокировки и уничтожения токенов или иных средств аутентификации;
• определён ли порядок действий при утрате токена, компрометации ключа, раскрытии PIN-кода или подозрении на несанкционированное использование;
• реализована ли техническая настройка в VPN, приложении, СЗИ, IAM, СУБД, терминальном доступе или иной точке входа;
• ведутся ли журналы успешной и неуспешной усиленной аутентификации, отказов, ошибок, блокировок и административных действий;
• можно ли показать фактические настройки, перечень пользователей, скриншоты политик, записи журналов и документы по выдаче средств аутентификации;
• есть ли исключения из усиленной аутентификации и оформлены ли они с обоснованием и компенсирующими мерами.

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

Варианты реализации

Организационный вариант.

Владелец ИС определяет, для каких пользователей, ролей, систем и операций требуется усиленная аутентификация. В ЛПА и ОРД закрепляются правила выдачи токенов, применения средств ЭЦП, действий при утрате, блокировки доступа и контроля использования. Такой вариант необходим как основа, но без технической реализации он не закрывает требование.

Многофакторная аутентификация при входе.

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

Многоэтапная аутентификация при критичных действиях.

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

Комбинированный вариант.

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

Что целесообразно закрепить в ТЗ, ЛПА и ОРД

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

• решение о применении или неприменении пункта 5.6 с учётом класса ИС, архитектуры и рисков;
• категории пользователей, для которых применяется многофакторная или многоэтапная аутентификация;
• перечень точек доступа и операций, где требуется усиленная аутентификация;
• перечень используемых средств: криптографические токены, сертификаты, средства выработки ЭЦП, IAM, VPN, прикладные модули;
• порядок выдачи, учёта, хранения, возврата, блокировки и уничтожения токенов или иных средств аутентификации;
• порядок защиты PIN-кодов, паролей, ключей и иных секретов доступа к токенам;
• порядок действий при утрате токена, компрометации ключа, подозрении на несанкционированное использование или отказе средства аутентификации;
• порядок оформления исключений и временного доступа без усиленной аутентификации, если такие случаи допускаются;
• порядок журналирования успешных и неуспешных попыток усиленной аутентификации;
• ответственных лиц за сопровождение средств аутентификации и контроль соблюдения установленного порядка.

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

Возможность технической реализации и инструменты

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

• Криптографический токен. Подтверждает владение индивидуальным средством и применяется вместе с PIN-кодом или иным установленным способом.
• Средство выработки ЭЦП. Может использоваться для дополнительного подтверждения пользователя или значимой операции, если такая модель предусмотрена системой.
• Многоэтапная проверка. Дополнительная аутентификация запрашивается перед повышением привилегий, подписанием, изменением критичных данных или доступом к защищённой функции.
• Централизованное управление. Система должна позволять учитывать выданные средства, блокировать их при утрате и журналировать успешные и неуспешные проверки.
• Аварийный доступ. Исключения и резервные способы входа должны быть ограничены, учтены и не превращаться в постоянный обход усиленной аутентификации.

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

Типичные ошибки при реализации

• требование включено в ТЗ, но фактически используется только парольная аутентификация;
• MFA включена только для части пользователей без описания критериев выбора;
• администраторы могут обходить усиленную аутентификацию через локальные учётные записи;
• токены передаются между сотрудниками или используются не владельцами;
• PIN-коды к токенам хранятся вместе с носителями или известны нескольким лицам;
• утрата токена или компрометация ключа не приводит к немедленной блокировке доступа;
• многоэтапное подтверждение критичной операции реализовано в интерфейсе, но не защищает сам объект операции;
• нет журналирования успешных и неуспешных попыток усиленной аутентификации;
• исключения из MFA не оформлены и не пересматриваются;
• обычный SMS-код или push-уведомление автоматически считается исполнением пункта 5.6 без анализа соответствия формулировке требования;
• усиленная аутентификация есть при входе, но отсутствует при критичных операциях, где риск выше, чем при самом факте доступа.

Вывод

Пункт 5.6 следует рассматривать как рекомендованное усиление доверия к аутентификации пользователей. Его нельзя механически сводить к любой второй проверке или к формальной галочке “MFA включена”. Нужно определить, какие сценарии доступа и операции требуют усиления, какие средства применяются и как они связаны с криптографическим токеном, средствами выработки ЭЦП или иной выбранной моделью.

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

Связанные материалы

• Идентификация и аутентификация пользователей
• Блокировка доступа при неактивности
• Защита личных ключей ЭЦП

Нормативная основа

• Приказ ОАЦ № 66 в редакции приказа № 259 от 10.12.2024 с учётом изменений, внесённых приказом № 98 от 27.05.2026 с учётом изменений, внесённых приказом № 98 от 27.05.2026 с учётом изменений, внесённых приказом № 98 от 27.05.2026 – приложение 3, пункт 5.6; пункт 12 о формировании требований ТЗ с учётом технологий; пункт 13 о порядке применения СЗИ и технологии ЭЦП. Официальный текст
• Реестр средств защиты информации ОАЦ – проверка статуса конкретного криптографического токена или средства ЭЦП, когда это требуется законодательством и ТЗ. Официальный реестр