Неделю назад под моей статьёй про ротацию паролей появился комментарий. Читатель писал, что длина пароля должна быть не менее 15 символов, и это позиция ФСТЭК, изложенная в документе «Рекомендации по защите сетевого периметра информационных (автоматизированных) систем». Документ опубликован 10 марта 2026 года на сайте регулятора.
Я пошёл проверять. Цифра 15 действительно есть, в пункте 1.2. Только относится она к паролям на сетевых пограничных устройствах и включается там, где авторизацию по сертификатам сделать нельзя. Учётных записей пользователей в информационной системе этот пункт не касается.
Заодно прочитал документ целиком. Тридцать пять пунктов про устройство периметра, лежит на сайте ФСТЭК с 10 марта, и ни одного разбора я не нашёл.
Значит, разберу сам. И посчитаю, сколько из этих пунктов упирается в деньги.
Что это за документ и почему он не обязателен
Документ ничего не обязывает, это рекомендации. Слово «требования» в тексте всё-таки встречается, ровно один раз, в пункте 1.2 про сложность пароля.
Лежит он в разделе «Рекомендации по повышению защищённости информационной инфраструктуры». Не среди нормативных актов и не среди методических документов, которые пункт 68 приказа № 117 делает обязательными. Обязанности из него не следует. Никаких сроков и никаких санкций в нём тоже нет.
В той ветке так и получилось: цитата из рекомендаций пришла как норма. А обязательные двенадцать символов стоят в другом документе, в методдоке ФСТЭК от 12 апреля 2026 года, мера ИАФ.3.
Читать их всё равно стоит. В аннотации к документу на сайте ФСТЭК сказано, что рекомендации разработаны «по результатам анализа успешных фактов реализации угроз безопасности информации, связанных с удаленной эксплуатацией уязвимостей, а также осуществлением несанкционированного доступа к внутренней инфраструктуре из внешней сети». То есть это разбор того, через что реально заходили. И когда после инцидента придут разбираться, первым прозвучит вопрос, почему не сделано то, что регулятор публично советовал полгода назад.
Документ короткий, двенадцать с половиной тысяч знаков, и по сути это готовый опросник для самопроверки. В таком виде я его дальше и разложил.
Чек-лист: 35 пунктов по восьми разделам
Структура такая: семь разделов разбиты на 34 подпункта, восьмой сформулирован одним абзацем без деления. Отсюда и 35.
Пометки в скобках мои и отвечают на один вопрос: нужно ли идти в бюджет за новой закупкой. [0 ₽] — закупки не требуется, хватает регламента и рук администратора. [₽₽₽] — нужна покупка или лицензия. [зависит] — закупки нет, если нужное уже стоит в инфраструктуре.
Оговорюсь сразу: «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 Определены место, способ хранения и частота. Принципы: не менее трёх копий, одна основная и две резервные; не менее двух разных типов носителей; одна копия хранится обособленно от остальных. [зависит]: три копии на двух носителях это место и железо, иногда дороже отдельного АРМ.
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.
Комментарии (6)

vesper-bot
20.08.2026 07:09Кейс - инфраструктура в ДЦ. Как исключить удаленное администрирование? (Сейчас выделенный АРМ есть, но он ВМ де-факто, с доступным RDP через танцы с бубном. Аудит есть, публикаций эндпойнтов на периферии таки нет)

zgwerby
20.08.2026 07:09Документ - реально - описывает то, что надо сделать для географически локализованного на уровне здания юнита {компании, подразделения, etc}. Там эти требования реально (а не на бумажке) выполнимы. Есть чёткий периметр, разделяющий "снаружи" и "внутри", есть возможность контролировать сеть до уровня проводов и иметь чёткую карту сети, с разделением сетей без костылей с VLAN, а физически, на разных проводах, есть возможность контролировать физический доступ до критичных устройств.
Особенно абсолютно правильные требования к контролирующему устройству - которых, по хорошему вообще должно быть 2-3 и располагаться они должны вообще в разных комнатах с разным уровнем физического допуска (контроль устройств ядра сети; контроль mission-critical сервисов; обычное АРМ админа, с которого доступно все остальное и интернет, но без любого доступа на устройства из п.1 и 2).
Однако стоит вступить в постковидную эпоху и распределённые формы организации юнита, то документ разъезжается по швам: облака иначе чем удалённо в принципе не администрируются (никто не прописывает штатного админа в ДЦ, который может быть далековато от места работы юнита) - кроме случаев коллока, когда арендуется лишь место и сеть, но и то, только при установке и выезде из него. Гибридный / удалённый формат работы администратора, если следовать документу, тогда тоже исключается. Нет намёка на аварийные сценарии работы, кроме "сидим в здании и по памяти со смартфона чиним".
Плюс не прописано: с заканчивающейся поддержкой - чьей? - вендора или сообщества? Переход на community-каналы обновления при наличии достаточных оснований для доверия - это продление поддержки или компенсаторные меры? Самоподдержка (внутри юнита), когда прошивка и пакеты аудируются, правятся, собираются и деплоятся самостоятельно - это поддержка или компенсаторные меры? Туда же вопрос про внутренние форки.
Короче, да. Правильно, полезно, вот только отражает реальность до массовых удалёнок и применимо (для части мер) только для больших, локализованных на конкретной территории юнитов, потому что...правильно, компромиссы.
max9
оч странный текст, почему вы считаете работу руками бесплатной? такие же деньги, в тч на поддержке, простой пример - обновили железо/ПО и вкл-выкл snmpv3 уже по-другому. или система мониторинга при обновлении отрыгнула работать с v3.
это полностью эквивалентно лицензированию - тоже работы длящиеся по времени.
putnik456
Видимо, "0 рублей" подразумевается как "0 рублей сверх зарплаты".
Меня больше смутил момент про "бесплатные" резервные копии - место стоит денег, и зачастую бОльших, чем отдельное АРМ для администрирования
max9
это если есть кому этим заниматься. и если капасити этих человеков влезает в тайминги.
AcousticBoy Автор
Справедливо. Пометка «0 ₽» отвечала ровно на один вопрос: надо ли идти в бюджет за новой закупкой. Труд администратора в неё не заложен, хотя именно он и есть основная стоимость.
Про snmpv3 согласен: после каждого обновления железа настраивать заново, разовой такую работу не назовёшь.
«Ноль рублей сверх зарплаты» сформулировано точнее, чем у меня. Я исходил из того, что администраторы в организации уже есть, а рост задач конвертируется в деньги косвенно, через нагрузку и зарплаты, минуя счёт от вендора. В тексте этого не было, претензия честная.
Про резервные копии тут прямая ошибка. Пункт 4.2 требует три копии на двух типах носителей, одну из них обособленно, это место и железо. «0 ₽» там стоять не должно.
Поправил: у 4.2 теперь «зависит», в легенде оговорка про «ноль сверх зарплаты», в конце деление на капитальные затраты и операционные. Капитальных четыре, остальное операционные, и нулевыми они не бывают. Про капасити принимаю тоже: когда специалист один на всю инфраструктуру, разница между «не нужна закупка» и «некому делать» исчезает. Спасибо за ваши комменты, теперь стало точнее!