Методика ФСТЭК об уровне зрелости: что заказчик Directum RX может записать в договор с ИТ-подрядчиком и как это проверить

Коротко. С 7 августа 2026 года заказчик может записать в договор требования к зрелости подрядчика по методике ФСТЭК. Для инфраструктуры Directum RX это десять проверяемых пунктов: именные доступы, одна точка входа, изменения через репозиторий, секреты в хранилище, происхождение образов, сетевые политики, ограничение контейнеров, бэкап с протоколом, код проверен на целевых ОС, ежемесячный отчёт. Каждый пункт проверяется артефактом, а не обещанием.

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

Симптом

Договор на сопровождение есть, работы идут, а на простые вопросы ответа нет:

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

Пока не случилось инцидента, эти вопросы кажутся формальностью. После инцидента они становятся вопросами об ответственности, и ответы «мы же профессионалы» в акт не попадают.

Что утвердила ФСТЭК

Документ называется «Методика оценки уровня зрелости деятельности в области технической защиты информации в информационных системах и обеспечения безопасности значимых объектов критической информационной инфраструктуры». Одобрен 7 августа 2026 года и применяется с этой даты.

Методика оценивает не защищённость конкретной системы, а то, как у организации устроена сама работа по защите информации. Оценка идёт по 21 направлению деятельности (управление уязвимостями, доступом, инцидентами, резервирование и другие), и в каждом направлении проверяется восемь видов требований с весами:

По каждому виду ставится 0, 0,5 или 1, умножается на вес, и по сумме с порогами определяется уровень. Уровней пять: нулевой, начальный, системный, контролируемый, верифицируемый. Логика по нарастающей: сначала научиться выполнять требования, потом делать это системно, потом регулярно проверять себя, потом дать проверить независимой стороне. Верифицируемый уровень без внешней оценки недостижим, а внешнюю оценку проводит только организация с лицензией ФСТЭК.

Кого это касается. Методика адресована операторам государственных информационных систем, информационных систем персональных данных и субъектам КИИ. Целевые уровни привязаны к классу системы: для ГИС третьего класса и ИСПДн третьего и четвёртого уровня защищённости не ниже начального, для второго класса не ниже системного, для первого не ниже контролируемого. Система документооборота почти всегда ИСПДн, потому что в ней лежат кадровые документы, поэтому у оператора RX методика есть в списке, даже если он не государственный.

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

Почему одной строки в договоре мало

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

Восемь видов требований из методики хорошо ложатся на договор об инфраструктуре, если переводить их не в формулировки «исполнитель обязуется соблюдать», а в проверяемые вещи: какой артефакт существует, где он лежит, как заказчик его смотрит. Ниже десять таких пунктов. Это не пересказ 21 направления методики, а то, что реально отличает подрядчика, за которым можно проверить, от подрядчика, которому приходится верить.

Десять пунктов для договора и как проверить каждый

1. Доступ только именной. У каждого инженера подрядчика своя учётная запись на серверах и в базе, вход по ключу, общих паролей нет. Доступ на изменение включается на согласованное окно и выключается после. Проверка: список учётных записей на любом сервере и журнал входов за месяц. Учётные записи вида admin или support, под которыми ходят несколько человек, это ноль по этому пункту.

2. Вход через одну точку. Подрядчик заходит через бастион или VPN заказчика, который пишет сессии. Прямого доступа с интернета на серверы нет. Проверка: правила межсетевого экрана и журнал бастиона.

3. Все изменения через репозиторий. Конфигурация серверов, кластера и сервисов RX описана кодом (Ansible, Helm, Terraform, что угодно) и лежит в репозитории заказчика или с доступом заказчика. Изменение на сервере это коммит с ревью, а не сессия в консоли. Такой подход называют GitOps, когда репозиторий сам становится источником состояния кластера. Проверка: история коммитов за месяц сопоставляется с журналом входов. Если в журнале сессии есть, а коммитов нет, значит, менялось руками. Второй способ: запуск раскатки в режиме проверки, который показывает расхождения между кодом и сервером. Расхождений быть не должно.

4. Секреты в хранилище, не в файлах. Пароли базы, брокера, хранилища, ключи API лежат в хранилище секретов (Vault, зашифрованные файлы с ключами у ограниченного круга) и не встречаются в репозитории и в переписке открытым текстом. Проверка: поиск по репозиторию по словам password, secret, token. Найденное должно быть либо зашифровано, либо ссылкой на хранилище. Плюс список тех, у кого есть ключ расшифровки.

5. Известно происхождение всего, что установлено. Образы контейнеров и пакеты берутся из реестра заказчика или подрядчика, а не с первого попавшегося зеркала. Для каждого образа известна версия, дата сканирования на уязвимости и решение по найденному. Это защита цепочки поставок: после того как публичные реестры несколько раз удаляли и подменяли образы, «поставили последнее из интернета» перестало быть допустимым ответом. Проверка: отчёт сканера (Trivy, Grype) по образам продуктивного контура с датой не старше месяца и список исключений с обоснованием.

6. Сервисы видят только то, что им нужно. В кластере или на серверах действуют сетевые политики: сервис RX ходит в базу, брокер и хранилище, но не в соседний контур и не в интернет. Между стендами (тест, приёмка, продуктив) трафика нет. Проверка: список сетевых политик и тест изнутри контейнера: попытка соединиться туда, куда не положено, не должна проходить.

7. Контейнеры и процессы ограничены. Сервисы не работают от root, файловая система контейнера только на чтение, лишние возможности ядра отключены, включены профили изоляции (AppArmor, SELinux, seccomp), где их поддерживает ОС. Для контейнеров в кластере это задаётся политикой на уровне пространства имён, а не доброй волей каждого манифеста. Проверка: настройки безопасности в манифестах и политика допуска в кластере. На Astra Linux дополнительно смотрят, что мандатные механизмы не выключены ради удобства.

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

9. Код раскатки проверен на целевых ОС. Если заказчик работает на Astra Linux или РЕД ОС, роли и чарты подрядчика должны быть проверены именно на них, а не только на Ubuntu, и повторный запуск не должен ничего менять (идемпотентность). Иначе первая раскатка в продуктив станет первым тестом. Проверка: отчёт прогона на стенде с перечнем ОС и результатом повторного запуска без изменений. У подрядчика, который относится к этому серьёзно, такой стенд есть и отчёты выдаются по запросу.

10. Ежемесячный отчёт и пересмотр. Раз в месяц подрядчик отдаёт список изменений, инцидентов, найденных уязвимостей и что с ними сделано. Раз в год или при смене версии RX и ОС пункты договора пересматриваются. Проверка: сам отчёт. Если его нет три месяца подряд, пункт не выполняется.

Если сопоставить с видами требований методики: пункты 3, 8, 10 закрывают документирование и актуализацию, 1, 2, 4, 6, 7 выполнение и инструменты, 5 и 9 контроль. Квалификацию и обучение договором не проверить, только вопросами на встрече. Внешний аудит остаётся за заказчиком: он решает, нужна ли ему проверка лицензиатом ФСТЭК, и от подрядчика для неё нужны те же артефакты, что в списке выше.

Что спросить у подрядчика до подписания

Пять вопросов, на которые должен быть ответ за минуту, без «уточним и вернёмся»:

1. Покажите, как выглядит ваш журнал изменений на одном из контуров. Не регламент, а журнал.
2. Где лежат пароли от базы этого контура и кто из ваших людей их видел.
3. Когда в последний раз восстанавливались из бэкапа и сколько заняло.
4. Откуда берёте образы и когда их последний раз сканировали.
5. На каких ОС проверен ваш код раскатки и как проверяете, что повторный запуск ничего не ломает.

Подрядчик, у которого это устроено, ответит с экрана. Подрядчик, у которого не устроено, начнёт рассказывать про опыт и сертификаты.

Чего не делать

• Не требовать верифицируемый уровень от подрядчика на пять человек. Он недостижим без внешней проверки лицензиатом ФСТЭК, и в договоре такое требование либо проигнорируют, либо заложат в цену. Начальный или системный уровень по описанным пунктам даёт больше, чем недостижимый на бумаге.
• Не путать методику с аттестацией системы. Методика про то, как организована работа, аттестация про конкретную систему. Одно не заменяет другое.
• Не переписывать в договор все 21 направление методики. Договор об инфраструктуре RX касается пяти-шести из них, остальное относится к заказчику как оператору.
• Не принимать «у нас есть политика ИБ» вместо журнала. Документ без следа выполнения это половина балла по методике и ноль пользы при инциденте.
• Не забывать про свою сторону. Если заказчик выдаёт подрядчику один общий пароль от всех серверов, пункт 1 не выполнит никто.