Что происходит с продуктом, когда разработчик решает пройти сертификацию ФСТЭК

На примере сервиса мультифакторной аутентификации MULTIFACTOR: от лицензирования компании и подготовки продукта до испытаний, аттестации облачной части и нескольких десятков неудобных вопросов к архитектуре

Всем привет! Я Антон Трофимов, в компании МУЛЬТИФАКТОР отвечаю за ИБ и на протяжении всего года занимался получением сертификата ФСТЭК. Можно думать, что сертификация ФСТЭК — это финальная проверка готового продукта. На практике всё наоборот: проверять начинают задолго до того, как продукт попадает в лабораторию.

В какой-то момент требования регулятора начинают добираться буквально до всего: архитектуры, зависимостей, кода, контейнеров, тестов, инфраструктуры и процессов разработки. Мы в компании МУЛЬТИФАКТОР прошли этот путь на собственном продукте.

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

Сначала нужно получить лицензию на разработку

До сертификации продукта есть ещё один уровень — получение лицензии на деятельность по разработке и производству средств защиты конфиденциальной информации.

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

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

В итоге лицензию мы получили. И только после этого началась сертификация самого продукта.

Сертификация — это не один большой тест

На старте кажется, что всё просто: сделали продукт, отдали его в лабораторию, прошли испытания и получили сертификат. Но между первым и последним пунктом есть большой подготовительный этап — сам продукт нужно привести к состоянию, в котором его можно полноценно проверить.

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

Отдельная задача — готовые библиотеки и сторонние компоненты. Современный продукт не пишется полностью с нуля: используются библиотеки и фреймворки от Amazon, Google и других разработчиков. Для сертификации важно понимать, какие именно компоненты используются, откуда они происходят, какие функции выполняют и допустимо ли их применение с точки зрения требований ФСТЭК. 

Похожую работу провели с контейнерами. В MULTIFACTOR их около 10, и для каждого нужно было определить состав, назначение, зависимости и функции. Файлы внутри продукта пришлось размечать, чтобы было понятно, к каким компонентам они относятся. Отдельно обозначали поверхность атаки — например, для компонентов, связанных с авторизацией.

Здесь мы начали тесно взаимодействовать с испытательной лабораторией. Испытания проводили в АО Центр «Атомзащитаинформ» (ЦАЗИ). Заявку мы подали 17 января 2025 года, и в процессе столкнулись ещё с одной сложностью: поменялся сам порядок подачи документов. Раньше достаточно было подать заявление, приложить формуляр и необходимые материалы. Теперь на этапе подачи нужно было сразу предоставлять зависимости изделия.

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

Отдельно регулятор установил требования к перечням заимствованных программных компонентов с открытым исходным кодом: для организаций, осуществляющих сертифицированное производство или сертификацию серийного производства СЗИ, такие перечни должны были быть представлены в ФСТЭК России до 1 января 2025 года.

SBOM: список зависимостей превращается в отдельный артефакт

Один из самых заметных пластов работы — Software Bill of Materials, или SBOM.

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

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

Поскольку наши продукты в основном написаны на C#, для формирования SBOM мы использовали dotnet CycloneDX. Полученные SBOM затем объединяли с помощью утилит CycloneDX. После этого запускали собственные скрипты для приведения файлов к требуемому формату и использовали утилиту SBOM Checker. Процесс выглядел примерно так: собрать SBOM → объединить результаты → привести к нужному формату → прогнать проверки → исправить ошибки → повторить проверку.

Отдельно проверяли получившиеся SBOM на уязвимости. Для этого использовали утилиту Bomber.

Отдельный вопрос — заимствованные компоненты. Нужно было подготовить информацию о них, проверить наличие уязвимостей и определить, какие компоненты связаны с поверхностью атаки и функциями безопасности.

Если компонент содержит известную уязвимость, нужно разобраться:

• затрагивает ли она используемую конфигурацию;

• может ли быть реализована в нашем продукте;

• относится ли к компоненту, который находится на поверхности атаки;

• можно ли устранить проблему обновлением;

• если нельзя — почему уязвимость неприменима или каким способом она компенсируется.

Чем меньше лишнего кода, тем меньше вопросов

Каждая дополнительная библиотека, сервис или компонент увеличивает количество вещей, которые нужно понимать, документировать и проверять. Анализ SBOM действительно может приводить к пересмотру архитектуры: чем меньше компонентная база, тем проще контролировать её состав и безопасность.

У нас в основном используется .NET, причём разных версий, поэтому в SBOM регулярно появлялось несколько версий одних и тех же пакетов. Например, одновременно могли встречаться Serilog@3.1.1 и Serilog@4.0.0. Кроме того, разные компоненты продукта исторически разрабатывались разными людьми и командами, поэтому у каждого сформировался собственный набор используемых библиотек.

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

Следующий этап — подготовка плана испытаний, и здесь снова появляется разница между обычной разработкой и сертификацией. В разработке мы можем сказать: «У нас есть unit-тесты, CI/CD и проверки безопасности».

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

• анализ архитектуры;

• анализ компонентов и зависимостей;

• анализ уязвимостей;

• статический анализ;

• динамический анализ;

• unit-тестирование;

• fuzzing.

В нашем случае unit-тесты уже были частью разработки, а фаззинг выполняла испытательная лаборатория.

В качестве одного из инструментов анализа мы использовали SonarQube. Инструмент в основном находил так называемые Code Smell — конструкции в коде, которые потенциально могут указывать на проблемы с качеством или небезопасные паттерны. 

Но лаборатории этого оказалось недостаточно. При проведении испытаний она запрашивает все тесты, которые выполняет разработчик, и оценивает, достаточно ли полно проведены проверки. В нашем случае потребовался дополнительный анализ с помощью Svace.

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

Все эти проверки выполняются ещё на этапе подготовки методик, чтобы не пришлось по несколько раз пересобирать продукт уже на этапе оформления протоколов.

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

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

Архитектуру пришлось рассматривать глазами модели угроз

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

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

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

Мы показали лаборатории инфраструктуру, которую ранее уже развернули как боевую для проведения сертификационных испытаний. Специалисты провели обследование системы и предложили варианты её совершенствования.

В продакшене у нас используются решения с открытым исходным кодом и провайдер для защиты от DDoS. Для прохождения аттестации дополнительно пришлось внедрять российские сертифицированные средства защиты от НСД и антивирус, а также менять маршрутизацию.

Сертифицировать облако сложнее

С классическим коробочным решением всё относительно просто: производитель сертифицирует продукт, а заказчик устанавливает его в своей инфраструктуре.

С облачным решением сложнее. MULTIFACTOR состоит из облачной и клиентской частей. Облачная часть развернута в инфраструктуре ЦОД, а клиентские компоненты взаимодействуют с инфраструктурой заказчика.

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

В нашем случае облачная часть размещена в двух сертифицированных ЦОД.

Аттестация: теперь проверяют уже не только код

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

В нашем случае специалисты лаборатории развернули и исследовали систему в облачной инфраструктуре, проверили конфигурации серверов и средств защиты, сопоставили фактическую реализацию с моделью угроз.

По итогам проверки нам пришлось исправить около 100 замечаний.

Они относились к разным уровням системы:

• документация;

• конфигурация;

• инфраструктура;

• настройки средств защиты;

• архитектура;

• процессы.

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

Один из примеров: мы не стали отказываться от Ubuntu 22.04

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

Что меняется в команде разработки

Наверное, главный эффект сертификации — не в появлении нового набора документов, а в том, как меняется сам подход к разработке.

Если раньше основной вопрос мог звучать просто: «Работает ли этот компонент?», то в процессе сертификации появляются дополнительные вопросы: как подтверждается его состав, как отслеживаются изменения, есть ли у него уязвимости, входит ли он в поверхность атаки и выполняет ли функции, связанные с безопасностью. Важно также понимать, можно ли воспроизвести результаты проведённых проверок.

Поэтому сертификация — это уже не задача только специалистов по информационной безопасности. В процесс вовлекается вся команда: разработчики, DevOps, QA, архитекторы, технические писатели и специалисты ИБ.

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

В этом смысле сертификация хорошо показывает зрелость процессов компании. Если необходимые сведения и артефакты приходится собирать вручную непосредственно перед проверкой, значит, эти процессы ещё не стали частью разработки.

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

Что происходит после получения аттестата

23 июля 2026 года мы получили аттестат соответствия ФСТЭК на облачную часть MULTIFACTOR. Но на этом работа не заканчивается. Аттестованный продукт нельзя воспринимать как статичный.

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

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

Поскольку мы будем обновлять сертифицированную версию продукта, потребуется обновлять и аттестованный контур. Скорее всего, это будет означать и проведение повторной аттестации. В соответствии с пунктом 33 приказа ФСТЭК № 77 внесение изменений в архитектуру допускается через проведение дополнительной аттестации.

Вместо заключения

Когда мы начинали этот путь, цель была простой: получить сертификат ФСТЭК на сервис многофакторной аутентификации MULTIFACTOR.

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

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