Неделю назад под моей статьёй про ротацию паролей появился комментарий. Читатель писал, что длина пароля должна быть не менее 15 символов, и это позиция ФСТЭК, изложенная в документе «Рекомендации по защите сетевого периметра информационных (автоматизированных) систем». Документ опубликован 10 марта 2026 года на сайте регулятора.

Я пошёл проверять. Цифра 15 действительно есть, в пункте 1.2. Только относится она к паролям на сетевых пограничных устройствах и включается там, где авторизацию по сертификатам сделать нельзя. Учётных записей пользователей в информационной системе этот пункт не касается.

Заодно прочитал документ целиком. Тридцать пять пунктов про устройство периметра, лежит на сайте ФСТЭК с 10 марта, и ни одного разбора я не нашёл.

Значит, разберу сам. И посчитаю, сколько из этих пунктов упирается в деньги.

Что это за документ и почему он не обязателен

Документ ничего не обязывает, это рекомендации. Слово «требования» в тексте всё-таки встречается, ровно один раз, в пункте 1.2 про сложность пароля.

Лежит он в разделе «Рекомендации по повышению защищённости информационной инфраструктуры». Не среди нормативных актов и не среди методических документов, которые пункт 68 приказа № 117 делает обязательными. Обязанности из него не следует. Никаких сроков и никаких санкций в нём тоже нет.

В той ветке так и получилось: цитата из рекомендаций пришла как норма. А обязательные двенадцать символов стоят в другом документе, в методдоке ФСТЭК от 12 апреля 2026 года, мера ИАФ.3.

Читать их всё равно стоит. В аннотации к документу на сайте ФСТЭК сказано, что рекомендации разработаны «по результатам анализа успешных фактов реализации угроз безопасности информации, связанных с удаленной эксплуатацией уязвимостей, а также осуществлением несанкционированного доступа к внутренней инфраструктуре из внешней сети». То есть это разбор того, через что реально заходили. И когда после инцидента придут разбираться, первым прозвучит вопрос, почему не сделано то, что регулятор публично советовал полгода назад.

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

Чек-лист: 35 пунктов по восьми разделам

Структура такая: семь разделов разбиты на 34 подпункта, восьмой сформулирован одним абзацем без деления. Отсюда и 35.

Пометки в скобках мои. [0 ₽] — закрывается регламентом, руками и головой. [$] — нужна покупка или лицензия. [зависит] — бесплатно, если нужное уже стоит в инфраструктуре.

1. Администрирование пограничных устройств (10 пунктов)

• 1.1 Настройка устройств только с отдельных АРМ, изолированных от интернета и предназначенных только для администрирования оборудования. [зависит]: отдельная машина под задачу либо уже выделена, либо её придётся купить.

• 1.2 Авторизация по сертификатам. Если невозможно, пароль от 15 символов, верхний и нижний регистр, спецсимволы, без персонифицированной информации. [0 ₽]

• 1.3 На каждом устройстве свой пароль, отличный от остальных. [0 ₽]

• 1.4 Контроль конфигураций организационными и техническими мерами: PAM, LDAP-каталоги, регламент изменений, контроль целостности, регистрация событий и возможность установить причину и ответственного. [зависит]: регламент пишется бесплатно, PAM покупается.

• 1.5 Выявить все сервисы, доступные из интернета по публичным адресам, определить их легитимность, нелегитимные заблокировать. [0 ₽]

• 1.6 Учёт пограничных устройств с назначением, конфигурацией, версиями ПО, сроками эксплуатации и сроками поддержки производителя. [0 ₽]

• 1.7 Управление жизненным циклом устройств, у которых заканчивается поддержка и которые нельзя вывести из эксплуатации: компенсирующие меры с учётом того, что уязвимости в них устранить уже нельзя. [0 ₽]

• 1.8 Исключить удалённое администрирование, включая публикацию интерфейсов SSH, RDP, VNC на периметре и в DMZ. [0 ₽]

• 1.9 Обязательное согласование с ответственными за ИБ любых изменений конфигурации, которые влияют на разграничение доступа, сегментацию, работу средств защиты, регистрацию событий, параметры аутентификации. [0 ₽]

• 1.10 Только безопасные протоколы мониторинга: HTTPS и SNMP v3, а HTTP и SNMP v1/v2 отключить. [0 ₽]

2. Устойчивость к DDoS (5 пунктов)

• 2.1 Правила межсетевого экранирования блокируют неразрешённый трафик, причём и входящий, и исходящий. [0 ₽] при наличии межсетевого экрана.

• 2.2 Фильтрация трафика прикладного уровня через WAF, включённый в режим противодействия атакам. [$]

• 2.3 Активированы функции защиты от DDoS на межсетевых экранах и других средствах защиты. [зависит]: смотря что умеет установленное оборудование.

• 2.4 Ограничение числа подключений с одного адреса, например через rate-limit. [0 ₽]

• 2.5 Взаимодействие с оператором связи по противодействию атакам, в соответствии с условиями договора и планом реагирования. [зависит]: у операторов такая услуга бывает и в тарифе, и за отдельные деньги.

3. Сегментация (5 пунктов)

• 3.1 Сегментация через VLAN на сетевом оборудовании и на уровне управления виртуальной инфраструктурой, плюс отдельная локальная сеть для ключевых сегментов. [0 ₽]

• 3.2 Управление трафиком между сегментами через ACL, с учётом категории обрабатываемой информации: служебная, персональные данные. [0 ₽]

• 3.3 Доступ к сети по модели нулевого доверия, ZTNA. [$]

• 3.4 Администрирование устройств уровня ядра невозможно из пользовательских, серверных и внешних сегментов. [0 ₽]

• 3.5 DMZ для внешних взаимодействий, из неё нет прямого доступа во внутренние сегменты кроме регламентированных взаимодействий. [0 ₽]

4. Резервное копирование конфигураций (6 пунктов)

• 4.1 Процесс регламентирован, назначено ответственное лицо или подразделение. [0 ₽]

• 4.2 Определены место, способ хранения и частота. Принципы: не менее трёх копий, одна основная и две резервные; не менее двух разных типов носителей; одна копия хранится обособленно от остальных. [0 ₽]

• 4.3 Копирование не реже одного раза в месяц. [0 ₽]

• 4.4 Определён перечень учётных записей с правом делать резервные копии. [0 ₽]

• 4.5 Копируются правила межсетевого экранирования, конфигурации VLAN, настройки NAT, списки пользователей, ролей и прав доступа. [0 ₽]

• 4.6 Проверка возможности восстановления из резервных копий не реже одного раза в три месяца. [0 ₽]

5. Управление уязвимостями (2 пункта)

• 5.1 Процессы управления уязвимостями по Методике анализа защищённости от 25 ноября 2025 года и Руководству по организации процесса управления уязвимостями от 17 мая 2023 года. [0 ₽] в части процесса.

• 5.2 Установка обновлений безопасности по Методике тестирования обновлений от 28 октября 2022 года и Методике оценки уровня критичности уязвимостей от 30 июня 2025 года. [0 ₽]

6. Аутентификация и доступ (3 пункта)

• 6.1 Централизованный контроль доступа через межсетевые экраны и систему NAC. [$]

• 6.2 Многофакторная аутентификация при административном доступе к инфраструктуре, из которой идёт доступ к пограничным устройствам. [зависит]: там, где MFA уже работает в домене, платить не за что.

• 6.3 Разграничение ролей администрирования по минимальным привилегиям: администратор безопасности, администратор сети, оператор. [0 ₽]

7. Регистрация событий (3 пункта)

• 7.1 Сбор событий через SIEM с автоматической обработкой, выявлением аномалий, оповещениями и поддержкой расследований. [$]

• 7.2 Централизованный сбор и хранение журналов с максимально детализированным уровнем и синхронизацией времени через NTP. Собираются успешные и неуспешные попытки авторизации с именем пользователя, методом аутентификации, адресом, временем, именем хоста и идентификатором сеанса. [0 ₽]: централизованный сбор журналов поднимается и без SIEM.

• 7.3 Оповещение администраторов ИБ о фактах успешной аутентификации с административными привилегиями, множественных неудачных попытках, смене способа аутентификации как попытке обойти MFA, изменениях конфигурации, изменении параметров журналирования, попытках очистки журналов, обновлении ПО из непредусмотренных источников, экспорте и восстановлении конфигурации. [0 ₽]

8. Учения (1 пункт)

• 8 Регулярные учения по реагированию на инциденты «для подтверждения их эффективности и способности органа (организации) обеспечивать выявление, локализацию, устранение инцидентов и восстановление работоспособности информационной инфраструктуры». [0 ₽]

Что запрещено прямым текстом

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

Публикация интерфейсов управления наружу. Пункт 1.8 требует исключить удалённое администрирование пограничных устройств, «в том числе публикацию интерфейсов удаленного управления (SSH, RDP, VNC) на сетевом периметре или в демилитаризованной зоне». Глагол там именно «исключить», без смягчений. DMZ упомянута отдельно, чтобы не было соблазна считать её безопасным местом.

Администрирование с обычной рабочей станции. Пункт 1.1: настройка только с отдельных АРМ, изолированных от интернета и предназначенных только для этой задачи. Ноутбук админа с открытой почтой под описание не подходит.

Небезопасные протоколы мониторинга. Пункт 1.10 прямо называет то, что нужно отключить: HTTP и SNMP версий 1 и 2.

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

Три пункта, которые не выполнены почти нигде

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

7.3, оповещение о попытке обойти MFA. Формулировка «смены способа аутентификации (попытки обойти MFA)» описывает конкретный сценарий атаки, при котором злоумышленник переключается на резервный метод входа. Событие есть в журналах, оповещение по нему настроено редко.

1.7, компенсирующие меры для устройств с заканчивающейся поддержкой. Устройство, которое нельзя обновить и нельзя вывести из эксплуатации, обычно просто остаётся в строю и молчит. Регулятор предлагает признать это письменно и обложить компенсирующими мерами.

Что документ тянет за собой

Раздел про уязвимости целиком построен на отсылках. Пункты 5.1 и 5.2 адресуют читателя к четырём документам ФСТЭК:

• Методика анализа защищённости информационных систем, утверждена 25 ноября 2025 года;

• Руководство по организации процесса управления уязвимостями в органе (организации), 17 мая 2023 года;

• Методика тестирования обновлений безопасности, 28 октября 2022 года;

• Методика оценки уровня критичности уязвимостей, 30 июня 2025 года.

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

Сколько это стоит

Из 35 пунктов покупки требуют четыре: WAF в режиме противодействия, ZTNA, NAC и SIEM. Ещё пять зависят от того, что уже стоит: изолированное АРМ администрирования (1.1), PAM (1.4), функции защиты от DDoS на имеющемся оборудовании (2.3), договор с оператором связи (2.5) и многофакторная аутентификация (6.2), которая в организации с доменом часто уже настроена.

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

Вывод получается неудобный. Когда периметр ломают через опубликованный наружу RDP или через устройство, о существовании которого забыли, дело обычно не в отсутствии бюджета.

Что с этим делать

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

А теперь вопрос к тем, у кого периметр в проде: сколько из 35 пунктов закрыто у вас и какой из них вызывает наибольшее сопротивление? У меня ставка на 1.8 и на 4.6.