Со стороны сертификация ФСТЭК России часто воспринимается как преимущественно бюрократический процесс. Но при более близком знакомстве быстро становится понятно: ключевая сложность не в документах как таковых.
Чтобы дойти до сертификата, приходится выстраивать контроль над зависимостями, пересматривать офлайн-поставку, наводить порядок в цепочке сборки и формализовывать практики, которые раньше существовали скорее «по договоренности». В какой-то момент становится очевидно, что привычные процессы требуют доработки и более строгой организации.
Эта статья — про то, как мы проходили этот путь, какие изменения оказались действительно необходимыми и чему мы научились по ходу работы. Если вы работаете с контейнерами, инфраструктурой или безопасностью, многие ситуации будут знакомы, а некоторые выводы, возможно, помогут избежать типичных ошибок.
Зачем вообще понадобилась сертификация
Тема сертификации появилась не в формате «собрались, решили, начинаем». Скорее это был логичный этап развития продукта. После того как ФСТЭК России сформировал отдельные требования по безопасности информации к средствам контейнеризации, стало понятно: для продуктов этого класса вопрос целесообразности сертификации фактически решен на уровне регуляторики. Если платформа относится к выделенному классу средств защиты информации, она должна соответствовать установленным требованиям.
При этом сам сертификат — не цель и не финал, а лишь результат длительной работы. Сертификация невозможна без серьезных изменений внутри продукта и процессов его разработки: требуется формализовать контроль зависимостей, пересмотреть подходы к проектированию и поставке, привести практики безопасности в соответствие методике. Основной объем работы происходит задолго до взаимодействия с регулятором и касается именно инженерной части.
С точки зрения заказчиков наличие сертификата имеет разный вес. Для информационных систем, попадающих под определенные классы значимости и защищенности, использование сертифицированных средств защиты информации является обязательным требованием — альтернативы здесь просто не рассматриваются. В других сегментах сертификат не является формальным барьером, но остается существенным преимуществом при выборе платформы.
Важно и то, что речь не идет о «сертификации всего подряд». Сертификация — сложный и ресурсоемкий процесс, который имеет смысл только для продуктов, относящихся к средствам защиты информации. По мере развития ИТ-ландшафта ФСТЭК России ушел от универсальных требований ко всему программному обеспечению и перешел к сегментации по классам решений: контейнеризация, виртуализация, СУБД и другим. Это позволяет разработчикам проектировать продукты под конкретные требования, а заказчикам — понимать, от каких угроз защищают применяемые средства и в каком контуре их использование оправдано.
В этом смысле сертификация перестает быть формальной процедурой и становится частью нормальной инженерной практики — там, где она действительно необходима.
Как и что меняли в продукте и поставке
Когда мы начали приводить Nova в соответствие требованиям ФСТЭК России, довольно быстро стало ясно, что с архитектурой самой платформы все в порядке: к этому моменту она уже была достаточно зрелой, и пересматривать фундаментальные технические решения не потребовалось. Основные изменения лежали в другой плоскости — в процессах поставки, прежде всего в сценариях офлайн-установки.
Исторически Nova устанавливалась двумя способами: онлайн — с использованием публичных репозиториев, и офлайн — через Univеrsе, appliancе с собственными репозиториями и сервисами. До начала сертификационных работ Univеrsе по сути оставался «черным ящиком»: заказчик получал образ виртуальной машины в формате qcow2, разворачивал платформу через ограниченный интерфейс, но не имел возможности проверить состав поставляемых артефактов.
Для сертификации такой подход не подошел. Методики ФСТЭК предполагают, что заказчик должен иметь возможность самостоятельно убедиться в составе поставки: сверить контрольные суммы, проверить содержимое и подтвердить, что артефакты не были изменены на пути от вендора до собственной инфраструктуры. Это потребовало полностью пересмотреть подход к офлайн-поставке.
В результате Univеrsе был переработан. Вместо единого образа виртуальной машины теперь поставляется набор прозрачных архивов с описанием состава и контрольными суммами. Такой формат позволяет заказчику самостоятельно проверить поставляемые артефакты и подтвердить их соответствие сертификационной сборке, выполненной вендором. По сути, это стало самым заметным изменением в рамках всей сертификационной работы: изменения затронули не функциональность платформы, а механизм ее доставки.
Отдельным и не менее важным направлением стала выстроенная доверенная цепочка исходных текстов и сборки. Для прохождения сертификационных испытаний требуется обеспечить полный контроль над используе��ыми заимствованиями — их исходным кодом, процессами сборки, обновлениями и включением в состав продукта.
Для этого была проведена системная работа. Используемые заимствования были перенесены во внутреннюю инфраструктуру, зафиксированы версии и точки интеграции. Их дальнейшее сопровождение — включая обновления, устранение уязвимостей и адаптацию под продуктовые сценарии — осуществляется внутри компании в рамках собственного процесса версионирования и выпуска.
Кроме того, был развернут внутренний репозиторий зависимостей (Nеxus), настроенный для работы с основными используемыми в продукте экосистемами. Это позволило обеспечить полностью контролируемую офлайн-сборку: процессы сборки не обращаются к внешним источникам, что является обязательным условием формирования доверенной цепочки поставки.
По объему работ это один из самых тяжелых этапов: перенос сотни компонентов, настройка пайплайнов, проверка воспроизводимости — на всё это ушло достаточно много времени.
Характерный момент: заметная доля проблем всплыла не в «экзотике», а в самых популярных компонентах. Уязвимости — область живая, базы CVе постоянно обновляются. Компонент, который вчера считался условно «чистым», через несколько месяцев может иметь десятки актуальных уязвимостей. Когда мы перенесли всё внутрь и прогнали через внутренний аудит, стало видно реальное состояние дел: где-то нужен фикс, где-то — обновление, где-то — замена зависимости. Это не «неожиданные дыры», а нормальная картина, когда приводишь большую платформу к строгим требованиям по безопасности.
Отде��ьным блоком пришлось усиливать контроль целостности и происхождения образов. Здесь работа велась сразу на нескольких уровнях:
Воспроизводимость сборки. Каждый компонент собирается детерминированно через CI, а для каждого образа формируется SBOM, позволяющий проверить его состав и источники используемых зависимостей.
Контроль целостности. После сборки для каждого образа фиксируется хэш-сумма, и любое изменение артефакта на этапе доставки может быть обнаружено.
В результате цепочка поставки стала прозрачной не только для вендора: заказчик может проверить поставляемые артефакты теми же способами и убедиться, что на пути от сборки до установки они не подвергались изменениям.
Отдельного внимания потребовала регистрация событий безопасности. Требования ФСТЭК России достаточно четко определяют перечень регистрируемых событий, обязательные поля и формат журналов. В рамках сертификационной работы компоненты логирования были пересобраны и настроены таким образом, чтобы кластер «из коробки» разворачивался с корректной конфигурацией журналов событий безопасности, соответствующей требованиям по безопасности информации.
Как приводили безопасность в соответствие требованиям
Когда работа дошла до аудита безопасности, неожиданностей не возникло — важно лишь правильно понимать контекст. В рамках сертификации ФСТЭК России от вендора не требуется разрабатывать полноценную модель угроз продукта: такая модель формируется на стороне заказчика при аттестации его информационной системы.
Задача сертификационной ветки лежит в другой плоскости. Необходимо определить, какие угрозы должна покрывать сама платформа как средство защиты информации, и какой функционал безопасности должен быть реализован, чтобы соответствовать требованиям и методикам регулятора. Речь идет не о моделировании конкретных сценариев атак, а о формировании и проверке набора защитных механизмов, заложенных в продукт.
Требуемый функционал безопасности был доработан и приведен в соответствие с требованиями методики, после чего оценен с точки зрения воспроизводимости и проверяемости. Реализация дополнительных и уточненных механизмов защиты привела к повышению уровня защищенности Платформы. Требования по безопасности являются формализованными, поэтому коллизий, при которых регуляторные требования оказывались невыполнимыми, не возникало.
Минимизация образов: от рутинной практики к системной задаче
При использовании большого числа базовых образов для отдельных компонентов система быстро начинает включать множество слоёв с различным составом пакетов, политиками безопасности и источниками обновлений. Это увеличивает поверхность атаки, усложняет формирование SBOM и делает управление уязвимостями менее предсказуемым: одни и те же библиотеки могут присутствовать в разных версиях и обновляться с разной периодичностью.
В контуре сертифицируемого средства защиты информации такая ситуация становится отдельным риском. При значительном количестве базовых образов существенно усложняется подтверждение контролируемости цепочки поставки и полноты обновления используемых компонентов в рамках требований методик.
Поэтому в процессе сертификационной подготовки было принято решение сократить количество используемых базовых образов и перейти к ограниченному набору доверенных базовых слоев. Эти слои централизованно сопровождались, регулярно обновлялись и проходили проверку в рамках установленного процесса.
Для компонентов, где критичны минимизация поверхности атаки и предсказуемость состава, применялись distrolеss-образы. Такой подход позволяет исключить из состава образа избыточные компоненты, сократить SBOM до необходимого минимума и упростить анализ уязвимостей.
Статический анализ
В рамках сертификации предъявляются определенные требования к применяемым средствам статического анализа. Инструмент должен поддерживать контекстно-чувствительный и межпроцедурный анализ, а также быть применимым к используемым в продукте языкам программирования и технологиям. Эти требования зафиксированы в методиках и подлежат обязательному выполнению.
Исходя из этого, был выбран инструмент статического анализа SVACе (ИСП РАН), соответствующий требованиям методики и применимый к значительной части используемого технологического стека.
В процессе внедрения статического анализа были определены целевые участки кода, подлежащие проверке, и сопоставлены с возможностями выбранного инструмента. Для тех языков и сценариев, которые не покрывались основным средством, использовались дополнительные инструменты статического анализа.
Результаты статического анализа рассматривались в рамках установленного процесса: выявленные потенциальные дефекты проходили технический разбор, по итогам которого принималось решение о необходимости доработок либо документировании выявленных особенностей в соответствии с методикой.
Пришлось ли переписывать код под анализаторы
Применение статического анализа не потребовало изменений архитектуры или логики работы компонентов. Это ожидаемо: статический анализ выявляет потенциальные дефекты реализации и нарушения правил безопасного программирования, но не затрагивает проектные решения. Выявленные замечания носили локальный характер и касались корректности и качества кода.
Ключевую роль в работе с результатами анализа сыграл установленный процесс триажа. Все выявленные потенциальные проблемы рассматривались с точки зрения применимости, условий эксплуатации и влияния на безопасность. По итогам такого разбора принимались решения о внесении исправлений либо о документировании выявленных особенностей в соответствии с требованиями методики.
Динамика, фаззинг и поверхность атаки
Требования к динамическому анализу также определены в рамках сертификационных испытаний, однако конкретные сценарии и методы тестирования не унифицированы и формируются для каждого продукта отдельно. Подход к динамическому анализу определяется архитектурой продукта, его интерфейсами и предполагаемой поверхностью атаки, а также требованиями ФСТЭК России.
В рамках сертификационной ветки проводилась проверка устойчивости ключевых компонентов и пользовательских интерфейсов к некорректным и нештатным входным данным. Глубина и сценарии динамического тестирования определялись специалистами на основании архитектуры платформы и требований методики.
Как это повлияло на процессы разработки
Культура разработки не претерпела радикальных изменений, однако сместилась в сторону большей формализации и предсказуемости. Сертификация не потребовала отказа от существующих практик, но сделала необходимым их приведение к состоянию, в котором процессы можно однозначно описать, воспроизвести и подтвердить в рамках установленных требований.
Ключевым изменением стало то, что практики безопасной разработки были закреплены как постоянная часть жизненного цикла продукта. Генерация SBOM, статический и динамический анализ, тестирование устойчивости, контроль целостности артефактов, подпись образов и детерминированные пайплайны сборки были интегрированы в базовую цепочку разработки и поставки. Эти этапы сохраняются и после завершения сертификационных мероприятий и используются как часть штатного процесса.
При этом дополнительной избыточности в процессах не возникло. Набор применяемых инструментов и проверок формировался исходя из требований методики и целесообразности их использования в конкретных этапах разработки. Все внедренные практики были включены в процессы на постоянной основе и не потребовали последующего пересмотра или отказа.
Грабли и неожиданные уроки
Самая болезненная ошибка — выбор «не того» базового слоя для образов на старте. Когда у тебя сотня компонентов, каждый со своим CI, цена такой ошибки растет по экспоненте. На момент, когда мы обнаружили проблему, вся платформа уже проходила сборку и тестирование. Пришлось возвращаться назад: менять основу, пересобирать все, пересматривать зависимости, проверять заново.
Дальше классическая цепочка: смена основы — пересборка всех компонентов — актуализация зависимостей — повторные проверки. Процесс занял много времени и ясно показал: базовый слой — не техническая мелочь, а фактический фундамент всей сборочной структуры.
Второй важный урок — масштабные изменения всегда порождают цепную реакцию. Любое изменение в одном компоненте — это одна история. Изменение базового слоя, от которого зависят десятки пайплайнов, — совсем другая. Несколько раз мы ловили «эффект домино»: обновили слой — посыпались смежные сборки — тянем за собой последующие цепочки.
Этот опыт сильно повысил внимание к стабильности инфраструктуры и тому, как она ведет себя под нагрузкой изменений.
Что стоило сделать иначе
По сути — только один пункт: базовый слой контейнеров должен определяться максимально тщательно и как можно раньше. Во всём остальном подход себя оправдал: умеренное количество инструментов, отказ от избыточных проверок, акцент на качестве, а не на скорости.
Что остается в Nova после сертификации
Сертификат не является завершающим этапом, а означает переход продукта в режим постоянного сопровождения и поддержания соответствия установленным требованиям. После его получения начинается регламентированный цикл работ, без которого эксплуатация сертифицированного продукта невозможна.
В этот цикл входят:
поддержание актуального состояния используемых компонентов и заимствований;
устранение выявляемых критических уязвимостей в установленные сроки;
выпуск обновлений с учетом требований по безопасности;
проведение повторных проверок и анализов;
развитие и поддержание процессов разработки безопасного программного обеспечения.
Поэтому всё, что появилось в ходе подготовки сертификационной ветки, остается в Nova как часть базовой инженерной культуры. Что еще реально улучшилось:
Зрелость процессов. Сборка стала предсказуемой и формализованной: от исходников до итогового образа путь теперь полностью воспроизводим.
Безопасность как стандарт. SBOM, минимизация образов, подпись контейнеров — не временные меры, а стандартные стадии пайплайна.
Качество кода. Статика, динамика, фаззинг и грамотный триаж показали реальный прирост устойчивости и прозрачности.
Практики, которые стоит забрать себе даже без ФСТЭК России
Сертификация ФСТЭК России — процесс длительный и ресурсоемкий, однако многие подходы, применяемые в его рамках, оказываются полезными и вне регуляторных требований. Речь идёт о практиках, направленных на повышение воспроизводимости, управляемости и предсказуемости жизненного цикла продукта.
Формирование доверенной цепочки поставки компонентов. Использование зависимостей напрямую из внешних источников упрощает начальный этап разработки, но усложняет контроль и сопровождение. Хранение исходных текстов и пакетов во внутренней инфраструктуре, фиксация версий и контроль источников позволяют снизить риски компрометации и обеспечить воспроизводимость сборки.
Минимизация контейнерных образов и управление SBOM. Для контейнеризованных приложений состав образов напрямую влияет на поверхность атаки и сложность сопровождения. Сокращение количества компонентов и явное описание состава через SBOM упрощают анализ уязвимостей, обновление зависимостей и контроль актуального состояния продукта.
Встраивание статического и динамического анализа в процесс разработки. Практики безопасной разработки предполагают не разовые проверки, а их регулярное выполнение в рамках жизненного цикла продукта. Анализы выполняются в привязке к изменениям кода и сборки и становятся частью стандартного процесса контроля качества, а не отдельной активностью «по требованию».
Проверка воспроизводимости сборки в изолированной среде. Возможность собрать и упаковать продукт без обращения к внешним источникам служит индикатором зрелости процессов поставки. Полностью контролируемая офлайн-сборка снижает зависимость от внешних факторов и повышает устойчивость продукта при эксплуатации.
Что это значит для инженеров и заказчиков — и что будет дальше
С инженерной точки зрения сертификация — это не формальная процедура и не результат в виде документа. Она требует выстраивания прозрачной цепочки поставки, воспроизводимой сборки, управления зависимостями, анализа уязвимостей и минимизации контейнерных образов. Реализация этих требований приводит к системным изменениям в процессах разработки и поставки, которые сохраняются и после прохождения сертификации.
Со стороны заказчика ключевым фактором является предсказуемость эксплуатации продукта. Важно, чтобы платформа могла быть развернута в заданном контуре, была совместима с сертифицированными операционными системами и соответствовала установленным требованиям по безопасности информации. Для госсектора и объектов критической информационной инфраструктуры это является обязательным условием применения продукта. Наличие сертифицированной версии Nova позволяет заказчику использовать платформу в таких средах без дополнительных регуляторных рисков.
В результате проведенной работы требования безопасности перестали рассматриваться как внешнее ограничение и были встроены в архитектуру и процессы разработки. Контроль исходных текстов, зависимостей, сборки и поставки, а также выполнение регулярных проверок стали частью стандартного жизненного цикла продукта.
Получение сертификата не завершает этот процесс. Поддержание соответствия требованиям предполагает постоянную работу: актуализацию компонентов, устранение выявляемых уязвимостей, выпуск обновлений и поддержание установленного уровня зрелости процессов. Параллельно развивается совместимость и интеграция продуктов внутри продуктовой линейки компании, формируются единые требования и практики разработки безопасного программного обеспечения.
Для Nova это означает переход к устойчивой модели развития, в которой требования безопасности и воспроизводимости рассматриваются как базовые характеристики продукта, а не как разовые задачи, связанные исключительно с прохождением сертификации.
