Уровень доверия 4
Модель безопасности
Средство виртуализации 4 класса защиты обязано соответствовать 4 уровню доверия — это пункт 6 требований к средствам виртуализации, утверждённых приказом ФСТЭК России от 27 октября 2022 г. № 187. Сами уровни доверия задаёт приказ ФСТЭК России от 2 июня 2020 г. № 76 (с изменениями, внесёнными приказом от 18 апреля 2022 г. № 68). Разбор функций безопасности — в разделе Соответствие ФСТЭК; здесь разобраны требования приказа № 76.
Требования приказа № 76 адресованы не настройке платформы, а её разработке, испытаниям и сопровождению. Поэтому закрываются они тремя разными способами, и различать их важно:
- артефактами репозиториев — конвейер сборки, подпись раздачи, манифест целостности, набор тестов. Это проверяется чтением кода и конфигураций;
- документами изделия — технические условия, формуляр, функциональная спецификация, проектная документация, программа и методики испытаний. Они ведутся отдельно от этой документации, и страница на них только ссылается;
- процедурами заявителя — сроки реакции на недостатки, рассылка обновлений, информирование об окончании поддержки.
В таблице 1 приказа только две строки отсутствуют для пятого и шестого уровней: модель безопасности средства (строка 1.1, п. 8.2) и анализ скрытых каналов (строка 2.3, п. 20.2). Помимо них, четвёртый уровень усиливает существующие требования в пп. 10.3, 12.3, 14.3, 15.3, 18.3, 19.3, 22.3 и 23.3: к интерфейсам, проектной документации, управлению конфигурацией, безопасной разработке, испытаниям и поддержке. Часть усилений относится к аппаратной платформе и применяется с учётом состава изделия. Применимость тестирования и анализа скрытых каналов зависит также от вида средства по п. 17.
Соответствие
Требования к разработке и производству
Хостовая операционная система (п. 7 приказа № 187).
Требование внешнее по отношению к платформе: хостовая ОС должна быть сертифицирована на 4 класс защиты и 4 уровень доверия по требованиям к операционным системам, утверждённым приказом ФСТЭК России от 19 августа 2016 г. № 119, и по приказу № 76. Функции безопасности узла — доверенная загрузка, контроль целостности, ограничение программной среды, защита памяти — реализованы в vStack OS.
Модель безопасности средства (п. 8.2).
Требование предъявляется только к четвёртому уровню доверия. Модель должна описывать реализуемые политики управления доступом и реализуемые политики фильтрации информационных потоков, включать описание условий безопасности, выполнение которых указывает на реализацию политик, и доказательство выполнения этих условий формальным (математическим) способом. Неформально должна быть показана связь условий безопасности с режимами функционирования. Язык описания должен быть математическим или машиночитаемым и допускать полную проверку корректности описания и доказательств независимо от разработчика модели.
Границы доверия и права пользователей описаны в разделе Модель безопасности.
Архитектура безопасности средства (п. 9).
Архитектура должна обеспечивать невозможность обхода функций безопасности и защиту их от несанкционированного доступа, а описание — обосновывать безопасность инициализации, собственную защиту от несанкционированного доступа и невозможность обхода.
| Что требуется | Чем закрывается в платформе |
|---|---|
| Безопасность процесса инициализации | Загрузчик умеет проверять подпись манифеста по встроенному доверенному якорю и передавать ядру его путь и SHA-256. В выпущенной линии манифест в поставку не собирается; в готовящейся линии на новой базовой системе его сборка для /boot подтверждена |
| Невозможность обхода функций безопасности | Проверки целостности предусмотрены при запуске, открытии файла, отображении в память и изменении прав отображения. Их действие зависит от режима подсистемы и исключений по привилегиям; наличие проверок не заменяет обоснование невозможности обхода |
| Собственная защита от несанкционированного доступа | Запрет записи и переименования верифицированных файлов задаётся параметрами загрузчика. Фактические значения проверяет администратор. Подсистему вручную переводят в состояние «включена, применяется, загрузка новых манифестов запрещена»; последний запрет сам по себе не включает режим блокировки исполнения |
| Защита функций безопасности управляющего слоя | Авторизация каждого вызова API единой функцией; фиксированные роли неизменяемы через API; привилегии управления ролями кастомным ролям не выдаются |
Функциональная спецификация средства (п. 10.3).
Спецификация должна перечислять все функции средства, описывать назначение, способы использования и параметры каждого интерфейса функций безопасности, действия с каждым интерфейсом, сообщения об ошибках при выполнении функций безопасности и при вызове каждого интерфейса, а также перечислять интерфейсы, не влияющие на функции безопасности.
Интерфейс управляющего слоя описан в справочнике API: методы, параметры, коды ошибок и требуемые привилегии перечислены по методам, и раздел Справочник ведётся из канона API. Реестр интерфейсов форка базовой системы перечисляет параметры и вызовы, отданные наружу, с пометкой об обязательствах по стабильности каждого; он описывает стык ядра с контроллером узла.
Проектирование средства и проектная документация (пп. 11, 12.3).
Требуется перечень подсистем с разделением на реализующие функции безопасности, поддерживающие их выполнение и не влияющие на него, проект на уровне подсистем и на уровне модулей, сопоставление функций и интерфейсов с подсистемами и модулями. Для пятого уровня и выше в документацию входят исходные тексты с контрольными суммами файлов, кроме заимствованного программного обеспечения, не реализующего функции безопасности и не влияющего на их реализацию. Для компонентов без необходимых сведений требуются описанные меры против эксплуатации уязвимостей или документированные способы получения недостающих сведений.
| Что требуется | Чем закрывается |
|---|---|
| Перечень подсистем и модулей, описание взаимодействия | Подсистемы и их взаимодействие описаны в репозиториях продукта |
| Классификация заимствованных компонентов | Разметку задаёт перечень изделия в devops/ports; компоненты вне явного перечня получают значения по умолчанию no/no |
| Сведения об аппаратной платформе | Технический проект заявляет программный состав изделия. Применимость аппаратных обязанностей по п. 12.3 требуется подтвердить составом сертифицируемого средства |
Средства разработки (п. 13).
Требуется документация с описанием применяемых средств разработки и использованных опций. Версия набора инструментов сборки зафиксирована, инструменты анализа включены в сборочный образ, профили сборки продукта заданы файлами конфигурации в репозитории — включая отдельный профиль сертифицируемого контура. Опции сборки тем самым лежат в репозитории в машиночитаемом виде.
Управление конфигурацией средства (п. 14.3).
Четвёртый уровень доверия добавляет к общим требованиям управление изменениями исходных текстов, применение автоматизированных мер контроля, обеспечивающих внесение только санкционированных изменений, и организацию процедур приёмки изменённых или вновь созданных элементов конфигурации.
| Что требуется | Чем закрывается |
|---|---|
| Управление изменениями исходных текстов | Изменения рассматриваются через запросы на слияние; конвейер проверяет код и подавления находок |
| Автоматизированные меры контроля санкционированности | Линтер, Semgrep, проверки зависимостей и лицензий, Trivy и контроль подавлений проваливают конвейер при находке. Новое подавление требует отдельного согласования специалистом по безопасности; самоодобрение запрещено. Настройки репозитория сейчас допускают слияние при проваленном конвейере |
| Уникальная маркировка и список элементов конфигурации | Ведомость CycloneDX формируется для основной ветки, включая выпуск срочных исправлений из неё; в ветке разработки и остальных ветках генерация выключена. Идентификаторы пакетов и хеши архивов не заменяют полный список элементов, включая документацию и разработчика каждого элемента |
Документация по безопасной разработке (пп. 15.1–15.3).
Требуется описание физических, процедурных и организационных мер защиты конфиденциальности и целостности проектной документации и реализации средства, а также мер, снижающих вероятность появления уязвимостей, с обоснованием. Меры безопасной разработки, работающие в конвейере, перечислены в разделе Соответствие ФСТЭК; документ об обеспечении безопасной разработки требуется предъявить для оценки выполнения п. 15.1, наследуемого пп. 15.2 и 15.3. Собственное усиление п. 15.3 относится к безопасной разработке аппаратной платформы и применяется с учётом состава изделия.
Эксплуатационная документация (п. 16).
Требуется формуляр средства с контрольными суммами дистрибутива и исполняемых файлов, руководство пользователя и руководство администратора. Руководство пользователя должно описывать режимы работы, принципы безопасной работы, функции и интерфейсы, доступные каждой роли, параметры безопасности с их безопасными значениями, типы событий безопасности, связанных с доступными пользователю функциями, и действия после сбоев.
Руководство администратора должно описывать приёмку поставленного средства, безопасную установку и настройку, реализацию функций безопасности среды функционирования. Эти обязанности не заменяются перечнем настроек продукта.
Оба руководства есть в комплекте от 28.09.2026. Публичная документация раскрывает часть содержания руководств: типы событий безопасности — Журнал безопасности, функции и интерфейсы по ролям — справочник Роли и привилегии, параметры безопасности и их безопасные значения — раздел Харденинг. Контрольные суммы дистрибутива в публичную документацию не выносятся: они уточняются при каждом обновлении и живут в формуляре.
Параметры узла и порядок настройки уже приведены в руководстве администратора от 28.09.2026 (§3.6) и руководстве пользователя той же даты (§4.2): затирание памяти и блоков, W^X, манифест, защита верифицированных файлов и проверка после обновления. Механизмы описаны в разделе Соответствие ФСТЭК.
Требования к проведению испытаний
Тестирование средства (п. 18.3).
По п. 17 тестирование и анализ скрытых каналов проводятся только для средств защиты информации. Применимость к изделию требуется подтвердить его категорией; ниже приведён состав требований при их применимости.
Тестовая документация четвёртого уровня доверия должна включать план тестирования со сценариями, зависимостями и необходимыми ресурсами, сопоставление тестов с интерфейсами функций безопасности из функциональной спецификации, с подсистемами из эскизного проекта и с модулями из технического проекта — с демонстрацией полного покрытия функций безопасности тестами, ожидаемые и фактические результаты с выводами об успешности. При тестировании оценивается влияние на модули, реализующие функции безопасности, со стороны остальных модулей.
| Что требуется | Чем закрывается |
|---|---|
| Тесты функций безопасности | Подсистема контроля целостности закрыта отдельным набором сценариев: отображение в память и изменение прав отображения, подпись манифеста, конфигурация ядра, журналирование, классификация блокирующих событий, обход по привилегии, жёсткие ссылки. Набор лежит в репозитории базовой системы вместе с вспомогательными программами и аналитической запиской |
| Тесты механизма затирания при удалении | Для выпущенной линии описан набор сценариев на разных геометриях пула и свойствах набора данных |
| Тесты по дефектам | Каждый разобранный дефект базовой системы несёт в репозитории описание, воспроизведение и регрессионный тест |
| Тесты управляющего слоя | Непрошедший модульный тест проваливает конвейер; настройки репозитория сейчас не запрещают слияние при таком результате |
Выявление уязвимостей и недекларированных возможностей (п. 19.3).
Испытания программного обеспечения четвёртого уровня доверия проводятся по 4 уровню контроля. Это работа испытательной лаборатории, и её результат — не свойство продукта. Со стороны разработки под неё готовятся исходные тексты с контрольными суммами, ведомость состава и разметка зависимостей по участию в функциях безопасности. Приёмочные испытания по выявлению уязвимостей проводит изготовитель; постоянно действующая часть — блокирующая проверка зависимостей на известные уязвимости в конвейере. Trivy при находках HIGH и CRITICAL и Semgrep при находке также проваливают конвейер.
Анализ скрытых каналов (п. 20.2).
Требование предъявляется к четвёртому уровню доверия при условии применимости по п. 17: анализ проводится только для средств защиты информации. Требуются идентификация и анализ скрытых каналов по памяти, оценка их потенциальной пропускной способности формальными, техническими или модельными методами, требования к среде функционирования для ограничения, мониторинга или устранения найденных каналов и отдельная документация анализа — с описанием использованных процедур, данных анализа, сделанных предположений и оценки наиболее опасного сценария по каждому выявленному каналу. При необходимости механизмы отражаются в функциональной спецификации и эскизном проекте, а требования к среде — в руководствах администратора и пользователя.
Затирание памяти гостя реализовано, а отладочная обвязка с поиском тестового образца есть только в выпущенной линии; в готовящейся она удалена. Проверка затирания не заменяет анализ каналов и их пропускной способности.
Требования к поддержке безопасности
Устранение недостатков (п. 22.3).
Четвёртый уровень доверия требует разработать компенсирующие меры или ограничения и довести сведения о них до потребителей не более чем за 48 часов с момента выявления недостатка. Также требуется доводить сведения о недостатках и мерах до каждого потребителя сертифицированного средства — письмом на электронный адрес или компонентом средства, который делает это автоматически. Доработка средства или мер защиты — в срок не более 60 дней с момента выявления недостатка. Наследуемый п. 22.1 также требует информирования ФСТЭК России и банка данных угроз, исправления и регрессионных испытаний.
Сроки и адресная рассылка — процедуры заявителя, из репозиториев они не выводятся. Со стороны продукта под них есть контур публикации срочных исправлений: отдельный конвейер выпускает исправление на релизной ветке с подписью, минуя цикл ветки разработки.
Обновление средства (п. 23.3).
Требуется информирование потребителей о выпуске обновлений, получение обновления способом, обеспечивающим целостность, получение обновлений по сети с информационного ресурса заявителя, подлинность и целостность обновлений за счёт электронной подписи и — для четвёртого уровня — доведение информации о выпуске до каждого потребителя.
| Что требуется | Чем закрывается |
|---|---|
| Подлинность и целостность обновления | Раздача пакетов подписана: тип подписи — открытый ключ, ключ раздачи выкладывается вместе с ней. Скрипт обновления публикуется с отсоединённой подписью, и конвейер проверяет её проверкой цифровой подписи по SHA-256 против того же открытого ключа; несовпадение останавливает публикацию |
| Целостность полученного набора | Ожидаемый отпечаток открытого ключа зашит в проверку конвейера, а его совпадение с ключом в раздаче сверяется отдельно |
| Обновление с ресурса заявителя | Обновление тянется с репозитория раздачи; сертифицируемый контур раздаётся из отдельного каталога |
| Информирование каждого потребителя | Процедура заявителя |
Документирование процедур устранения недостатков и обновления (п. 24).
Требуется включение процедур устранения недостатков в программную и конструкторскую документацию и регламент обновления средства потребителем с порядком получения, установки и контроля установки обновления. Из трёх частей публичная документация закрывает контроль установки: сверка версий пакетов по узлам описана в разделе Управление узлами. Порядок получения и установки как регламент ведётся документом изделия.
Информирование об окончании производства и поддержки (п. 25).
Потребители и ФСТЭК России должны быть проинформированы не позднее чем за год до окончания производства или поддержки безопасности средства. Процедура заявителя, средствами платформы не закрывается.
Границы подтверждения
Страница сопоставляет требования приказа № 76 с механизмами и артефактами, которые проверяются чтением репозиториев продукта. Документы изделия, статус сертификации и результаты испытаний рассматриваются отдельно.
Динамический анализ, включая фаззинг, рассматривается отдельно как мера РБПО по ГОСТ Р 56939. В предоставленной выписке приказа № 76 отдельного пункта о фаззинге нет. Основание и применимость этой меры по стандарту или программе сертификации требуют уточнения.
Харденинг
После установки и каждого обновления узла администратор проверяет настройки безопасности. Контроль целостности приводится в рабочее состояние вручную: сборка и загрузка манифеста, включение проверки, режим блокировки и запрет загрузки новых манифестов.
В обычной сборке W^X требует настройки; в сертифицируемом контуре файл настроек задаёт запрет, и администратор проверяет фактическое значение. Затирание памяти выключено по умолчанию. Затирание блоков доступно в выпущенной линии и тоже выключено. Порядок и ограничения — в разделе Харденинг.