Нормативный источник: пункт 3.3 Приложения 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ).
Смысл требования
Пункт 3.3 приложения 3 к ПТКЗИ – практический разбор требования «защита ввода паролей». Пункт 3.3 касается защиты аутентификационной информации в момент её ввода пользователем. Его смысл состоит в том, что пароль, PIN-код, одноразовый код, секретная фраза или иной аутентификационный признак не должны отображаться на экране в открытом виде, попадать в видимые подсказки, журналы, историю ввода, диагностические сообщения или иные каналы обратной связи, доступные пользователю, администратору либо постороннему наблюдателю.
Требование выглядит простым, но на практике часто нарушается в самописных веб-приложениях, административных интерфейсах, консольных утилитах, скриптах обслуживания и временных технических формах входа. Формальная аутентификация может быть реализована, но если при вводе пароль виден на экране, отражается в URL, попадает в параметры командной строки или сохраняется в отладочных логах, защитный смысл аутентификации существенно снижается.
Формулировка требования
Приложение 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ), раздел «Требования по обеспечению идентификации и аутентификации», пункт 3.3: «обеспечение защиты обратной связи при вводе аутентификационной информации».
Обязательность применения
По таблице приложения 3 требование пункта 3.3 является обязательным для всех классов типовых ИС: 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл, 3-дсп. Рекомендательный режим применения для этого требования не предусмотрен.
Практически это означает, что владелец ИС должен обеспечить защиту обратной связи во всех точках, где пользователь, администратор или сервисный субъект вводит аутентификационные данные. Не имеет значения, используется ли сложная доменная модель, локальная форма входа, VPN-клиент, административная консоль, веб-интерфейс или терминальный доступ. Если вводится аутентификационная информация, её отображение и обработка должны быть защищены.
Что именно следует защищать
Под защитой обратной связи не следует понимать только замену символов пароля на точки или звёздочки в форме входа. Это основной, но не единственный элемент требования. Обратная связь – это всё, что система возвращает пользователю или отображает в процессе ввода и обработки аутентификационной информации. Поэтому необходимо исключить не только открытое отображение пароля, но и косвенное раскрытие аутентификационных данных через интерфейс, ошибки, журналы и технические следы.
- Пароли и PIN-коды. При вводе должны маскироваться либо не отображаться вовсе, в зависимости от типа интерфейса.
- Одноразовые коды и секретные фразы. Не должны сохраняться в открытом виде в истории браузера, автозаполнении, журналах приложения или диагностических сообщениях.
- Токены, ключи API и иные секреты. Не должны вводиться и отображаться через обычные текстовые поля, параметры URL или открытые командные строки без защиты.
- Сообщения об ошибках аутентификации. Не должны раскрывать избыточные сведения, позволяющие уточнить существование учётной записи, структуру механизма входа или причину отказа сверх необходимого.
- Журналы и отладочные данные. Не должны содержать введённые пароли, одноразовые коды, секретные значения, содержимое полей аутентификации и аналогичные данные.
- Скрипты и служебные утилиты. Не должны требовать ввода пароля способом, при котором он виден на экране, сохраняется в истории команд или передаётся в явных параметрах запуска.
Критерий исполнения можно сформулировать так: пользователь получает подтверждение факта ввода или результата аутентификации, но сама аутентификационная информация не раскрывается ни визуально, ни технически, ни через побочные каналы интерфейса.
Что следует подтвердить при проверке
При проверке пункта 3.3 обычно оценивается не наличие отдельного документа, а фактическое поведение точек аутентификации. Проверяющий смотрит, как работает форма входа, консоль, VPN-клиент, административный интерфейс, прикладное ПО и иные средства, через которые вводятся реквизиты доступа. Дополнительно анализируется, не попадают ли аутентификационные данные в журналы, URL, историю команд, отладочные файлы и сообщения об ошибках.
- маскируется ли пароль или иной секрет при вводе в пользовательских и административных интерфейсах;
- исключено ли отображение аутентификационной информации в открытом виде при ошибке входа, повторном вводе или автозаполнении формы;
- не передаются ли пароли и секреты в параметрах URL, открытых командных строках или видимых полях форм;
- не сохраняются ли аутентификационные данные в прикладных, системных, отладочных или веб-журналах;
- не раскрывают ли сообщения об ошибках избыточные сведения о наличии учётной записи или механизме проверки;
- охвачены ли требованием не только пользовательские формы, но и административные, сервисные и технические точки входа;
- существует ли порядок разработки, тестирования или приёмки прикладных интерфейсов, исключающий открытое отображение аутентификационной информации.
Наиболее уязвимый участок – самописные и редко используемые административные формы. В типовых операционных системах и зрелых приложениях маскирование обычно реализовано штатно, а в собственных модулях входа, скриптах сопровождения и временных сервисных интерфейсах требование часто забывают.
Варианты реализации
Организационный вариант.
Владелец ИС закрепляет в ЛПА, требованиях к разработке, требованиях к эксплуатации или инструкции администратора правило о запрете открытого отображения аутентификационной информации и её записи в журналы. Такой вариант важен как управленческая основа, особенно если в ИС есть собственная разработка или доработка прикладных интерфейсов. Однако сам по себе документ не закрывает требование без фактической реализации в интерфейсах.
Технический вариант.
Защита реализуется средствами самих платформ и приложений: маскированием полей пароля, отключением вывода введённых секретов в консоли, запретом передачи паролей через URL, исключением секретов из логов, корректной обработкой ошибок входа и безопасной работой с полями аутентификации. Такой вариант является основным для фактического исполнения требования.
Комбинированный вариант.
Наиболее устойчивый подход. Владелец ИС документально устанавливает требования к защите обратной связи, разработчик или администратор реализует их в интерфейсах, а при тестировании и приёмке проверяется фактическое отсутствие раскрытия аутентификационной информации. Для систем с собственной разработкой именно такой вариант наиболее обоснован.
Что закрепить в ТЗ, ЛПА и ОРД
Приложение 3 к Положению содержит перечень требований, подлежащих включению в техническое задание на создание системы защиты информации. Поэтому в ТЗ необходимо зафиксировать требуемый результат и границы его применения, а в ЛПА и ОРД – порядок эксплуатации, роли, ответственность и подтверждающие процедуры.
- запрет отображения аутентификационной информации в открытом виде при вводе;
- запрет записи паролей, одноразовых кодов, секретов и токенов в журналы и отладочные файлы;
- запрет передачи аутентификационной информации через URL и открытые параметры командной строки;
- требование маскирования полей ввода пароля, PIN-кода и аналогичных секретов;
- требование проверки форм входа и административных интерфейсов при приёмке и изменении приложения;
- порядок обработки ошибок аутентификации без избыточного раскрытия сведений;
- требования к служебным скриптам и консольным средствам, исключающие видимый ввод паролей;
- действия при выявлении раскрытия аутентификационной информации в интерфейсе или журнале.
В техническом задании или требованиях к разработке это положение лучше формулировать как обязательное требование к интерфейсам аутентификации и обработке секретов. Тогда оно проверяется не только при аттестации, но и при изменении приложения.
Техническая реализация и инструменты
Техническая реализация пункта 3.3 обычно не требует отдельного тяжёлого продукта. Чаще всего она обеспечивается правильной настройкой интерфейсов, безопасной разработкой и контролем журналирования. Инструменты здесь выступают не как отдельная система защиты, а как средства реализации и проверки.
- Штатные механизмы ОС и приложений. Вход в Windows, Linux, СУБД, VPN-клиенты и большинство зрелых систем уже предусматривает скрытый ввод пароля. Задача владельца ИС – убедиться, что не используются обходные или небезопасные технические формы входа.
- HTML-поля типа password и безопасные компоненты UI. Для веб-приложений важно использовать корректные поля ввода секретов, исключать передачу паролей через URL и не сохранять значения в открытом виде на клиенте.
- Фреймворки аутентификации и IAM/SSO-платформы. Keycloak, Microsoft Entra ID, ADFS, FreeIPA и аналогичные решения обычно уже реализуют корректную обработку форм входа, но требуют правильной интеграции с приложениями.
- OpenSSH, PAM и консольные средства безопасного ввода. В Unix/Linux-среде важно использовать механизмы, при которых пароль не отображается и не сохраняется в истории команд.
- Сканеры веб-уязвимостей и средства тестирования приложений. OWASP ZAP, Burp Suite и аналогичные инструменты могут использоваться для проверки того, не передаются ли секреты в URL, не отражаются ли в ответах приложения и не попадают ли в небезопасные параметры.
- Средства анализа журналов и DLP/секрет-сканеры. Могут применяться для выявления попадания паролей, токенов и ключей в журналы, репозитории, отладочные файлы и служебные выгрузки.
- Secure coding checklist. Практичный инструмент для собственной разработки: чек-лист приёмки форм входа, обработки ошибок, логирования и хранения секретов.
При выборе подхода важно не усложнять требование искусственно. Для типовой инфраструктуры достаточно штатных механизмов маскирования и запрета записи секретов в журналы. Для собственной разработки нужен дополнительный контроль: требования к интерфейсам, проверка форм входа, анализ логов и тестирование обработки ошибок.
Типичные ошибки при реализации
- пароль или иной секрет отображается в форме входа в открытом виде;
- поле пароля реализовано как обычное текстовое поле;
- аутентификационные данные передаются через URL, query-параметры или видимые параметры командной строки;
- пароли, токены или одноразовые коды попадают в прикладные, системные или отладочные журналы;
- ошибки входа раскрывают избыточные сведения о существовании учётной записи или внутренней логике проверки;
- служебные скрипты требуют ввода пароля в открытом виде или сохраняют его в истории команд;
- административные интерфейсы и временные сервисные формы не проверяются на защиту обратной связи;
- требование учитывается в пользовательском интерфейсе, но не применяется к API, CLI, интеграциям и техническим средствам сопровождения.
Вывод
Пункт 3.3 не требует сложной архитектуры, но требует аккуратности. Его нельзя сводить только к звёздочкам в поле пароля, поскольку риск раскрытия аутентификационной информации возникает также в ошибках, логах, URL, командных строках, отладочных файлах, служебных скриптах и административных интерфейсах.
Для типовой ИС достаточно обеспечить скрытый ввод секретов, корректную обработку ошибок и отсутствие аутентификационных данных в журналах. Для систем с собственной разработкой или техническими интерфейсами требуется более строгий комбинированный подход: требования в ТЗ, проверка при приёмке, безопасная реализация форм входа и периодический контроль журналов на отсутствие секретов. Требование считается исполненным тогда, когда аутентификационная информация не раскрывается пользователю, администратору или постороннему лицу через механизмы обратной связи при вводе и обработке.