Пункт 3.2 приложения 3 к ПТКЗИ: идентификация и аутентификация пользователей ИС и СЗИ

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

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

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

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

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

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

По таблице приложения 3 требование пункта 3.2 является обязательным для всех классов типовых ИС: 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл, 3-дсп. Рекомендательный режим применения для данного требования не предусмотрен.

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

Что именно должно быть охвачено

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

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

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

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

При проверке пункта 3.2 анализируется не только наличие паролей. Проверяющий оценивает, существует ли у владельца ИС целостная модель идентификации и аутентификации, охватывающая основные активы, административные интерфейсы и средства защиты информации. Особое внимание обычно уделяется индивидуальности учётных записей, отсутствию общих реквизитов доступа, управляемости сервисных учётных записей и соответствию фактических настроек внутренним документам.

• закреплён ли порядок идентификации и аутентификации в ЛПА, регламенте управления учётными записями, инструкции администратора или ином ОРД;
• используются ли индивидуальные учётные записи пользователей и администраторов;
• исключено ли использование общих, обезличенных или неучтённых учётных записей для регулярной работы;
• охвачены ли идентификацией и аутентификацией не только приложения, но и ОС, СУБД, сетевое оборудование, СЗИ и административные интерфейсы;
• определён ли порядок применения сервисных учётных записей и запрещено ли их использование для интерактивного входа без необходимости;
• можно ли связать действия в журналах с конкретным пользователем, администратором, ролью или сервисной функцией;
• установлены ли требования к первичной выдаче реквизитов доступа, смене паролей, блокировке и восстановлению доступа;
• есть ли механизм усиленной аутентификации для удалённого, административного или привилегированного доступа, если это требуется архитектурой и уровнем риска.

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

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

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

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

Технический вариант.

Идентификация и аутентификация реализуются средствами операционных систем, каталогов, приложений, СУБД, сетевого оборудования и СЗИ. Это могут быть локальные учётные записи, доменная аутентификация, LDAP, RADIUS, TACACS+, SSO, сертификаты, аппаратные токены или многофакторная аутентификация. Технический вариант эффективен только при условии, что он соответствует утверждённой модели доступа и не создаёт неучтённых исключений.

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

Наиболее устойчивый подход. Владелец ИС документально определяет модель идентификации и аутентификации, затем реализует её технически через выбранные средства и периодически сверяет фактические настройки с утверждённым порядком. Для обычной ИС это может быть доменная или каталоговая модель. Для систем с удалённым и привилегированным доступом обычно требуется усиление за счёт MFA, PAM, RADIUS/TACACS+ или сертификатной аутентификации.

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

Приложение 3 к Положению содержит перечень требований, подлежащих включению в техническое задание на создание системы защиты информации. Поэтому в ТЗ необходимо зафиксировать требуемый результат и границы его применения, а в ЛПА и ОРД – порядок эксплуатации, роли, ответственность и подтверждающие процедуры.

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

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

Техническая реализация и инструменты

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

• Active Directory / LDAP / FreeIPA. Базовые средства централизованной идентификации и аутентификации для серверов, рабочих станций и приложений. Позволяют управлять пользователями, группами, политиками входа и жизненным циклом учётных записей.
• RADIUS / TACACS+. Применяются для сетевого оборудования, VPN, Wi-Fi, административного доступа к маршрутизаторам, коммутаторам, межсетевым экранам и иным инфраструктурным компонентам. TACACS+ особенно полезен там, где требуется разграничение административных команд.
• SSO и федеративная аутентификация. Используются для прикладных систем и веб-сервисов, когда требуется единая точка входа и управляемая модель идентификации. Важно контролировать не только удобство входа, но и правильность привязки ролей.
• MFA / двухфакторная аутентификация. Уместна для удалённого доступа, административных функций, доступа к СЗИ, облачным консолям и критичным приложениям. Не является прямой заменой базовой идентификации, а усиливает её.
• PAM-системы. Применяются для контроля привилегированного доступа к серверам, сетевому оборудованию, СЗИ и административным интерфейсам. Позволяют управлять сессиями, выдачей привилегий и фиксацией действий администраторов.
• Локальные механизмы ОС и приложений. Допустимы для небольших или изолированных ИС, если обеспечивается индивидуальность учётных записей, управляемость паролей и фиксация действий. При росте системы такой подход быстро становится трудносопровождаемым.
• Сертификатная аутентификация и аппаратные токены. Применимы в случаях, когда требуется усиленное подтверждение личности, особенно для удалённого, административного или юридически значимого доступа.

При выборе инструмента необходимо исходить не из названия продукта, а из того, какие субъекты и какие точки доступа требуется охватить. Если каталог используется только для рабочих станций, а доступ к сетевому оборудованию, СЗИ и СУБД остаётся на локальных общих учётных записях, требование не реализовано полноценно.

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

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

Вывод

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

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

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

• Разграничение доступа пользователей
• Полномочное управление учётными записями
• Контроль правил генерации и смены паролей