Пункт 4.1 приложения 3 к ПТКЗИ: реквизиты доступа, установленные по умолчанию

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

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

Практический смысл требования состоит в том, что владелец ИС должен исключить возможность доступа к активам ИС и СЗИ с использованием известных, типовых, заводских, демонстрационных или временных реквизитов. Это не только пароли вида admin/admin. Речь также идёт о предустановленных учётных записях, стандартных API-ключах, дефолтных SSH-ключах, типовых паролях к web-интерфейсам, встроенных технических пользователях и иных средствах доступа, которые не были индивидуализированы для конкретной ИС.

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

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

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

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

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

Что относится к реквизитам доступа по умолчанию

Ошибка при реализации пункта 4.1 часто состоит в слишком узком понимании реквизитов доступа. Владелец ИС меняет пароль администратора на сервере, но не проверяет сетевое оборудование, СЗИ, встроенные учётные записи приложений, тестовые аккаунты, API-доступы и сервисные интерфейсы. Такое исполнение неполно, поскольку формулировка требования охватывает активы ИС и средства защиты информации в целом.

• Заводские учётные записи. Например, admin, root, supervisor, operator, support, user и аналогичные встроенные пользователи, созданные производителем или поставщиком.
• Пароли по умолчанию. Типовые пароли из документации, руководств администратора, публичных баз дефолтных паролей или шаблонов установки.
• Демонстрационные и тестовые учётные записи. Пользователи, созданные при внедрении, тестировании, пилотной эксплуатации или обучении.
• Временные реквизиты интегратора. Доступы, созданные подрядчиком для настройки, отладки или сопровождения, но не удалённые после завершения работ.
• Стандартные ключи и токены. Предустановленные SSH-ключи, API-ключи, секреты приложений, токены интеграций, если они не заменены при вводе в эксплуатацию.
• Предустановленные административные интерфейсы. Web-консоли, CLI, SNMP community, IPMI/iDRAC/iLO, консоли виртуализации, панели управления СЗИ и иные точки входа.
• Стандартные локальные пользователи приложений и СУБД. Встроенные аккаунты, которые остаются активными после установки продукта и могут использоваться для администрирования или обслуживания.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для пункта 4.1 внутренние документы должны быть привязаны к реальному жизненному циклу активов. Основной момент – изменение или блокировка реквизитов по умолчанию должны выполняться до ввода актива или СЗИ в промышленную эксплуатацию, а не после обнаружения проблемы при проверке.

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

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

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

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

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

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

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

• изменены пароли на серверах, но не проверены сетевое оборудование, СЗИ, СУБД и web-консоли;
• оставлены активными заводские учётные записи, которые “никто не использует”;
• временные учётные записи интегратора не удалены после завершения работ;
• стандартные SNMP community strings остаются включёнными;
• предустановленные API-ключи, токены или SSH-ключи не заменены при вводе системы в эксплуатацию;
• административные интерфейсы доступны из широкого сетевого сегмента и защищены только изменённым паролем;
• реквизиты по умолчанию изменены, но новые пароли хранятся в открытом виде в файлах, таблицах или переписке;
• проверка выполняется только перед аттестацией, но не включена в регулярный процесс ввода новых активов;
• нет доказательств: чек-листов, скриншотов, выгрузок пользователей, актов настройки или результатов сканирования;
• исключения не оформлены, хотя часть встроенных учётных записей невозможно удалить технически.

Вывод

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

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

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

• Управление жизненным циклом учётных записей
• Контроль правил генерации и смены паролей
• Замена и модернизация активов после окончания эксплуатации

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

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