Соответствие ФСТЭК
Модель безопасности
Сертификация относится к платформе vStack HCP целиком, поэтому раздел описывает соответствие требованиям без привязки к версии продукта.
Требования по безопасности информации к средствам виртуализации утверждены приказом ФСТЭК России от 27 октября 2022 г. № 187. Они устанавливают шесть классов защиты, где шестой — самый низкий, а первый — самый высокий. Средство виртуализации 4 класса применяется в значимых объектах критической информационной инфраструктуры 1 категории значимости, в государственных информационных системах 1 класса защищённости, в автоматизированных системах управления производственными и технологическими процессами 1 класса защищённости, в информационных системах персональных данных при необходимости обеспечения 1 уровня защищённости и в информационных системах общего пользования II класса.
Класс защиты тянет за собой два внешних условия, которые сам продукт не закрывает. Средство виртуализации 4 класса должно соответствовать 4 уровню доверия по приказу ФСТЭК России от 2 июня 2020 г. № 76 (с изменениями, внесёнными приказом от 18 апреля 2022 г. № 68). Хостовая операционная система, в среде которой оно работает, должна быть сертифицирована на 4 класс защиты и 4 уровень доверия — по требованиям к операционным системам, утверждённым приказом ФСТЭК России от 19 августа 2016 г. № 119, и по тому же приказу № 76. Регистрацию событий требования привязывают к разделам 3–6 ГОСТ Р 59548-2022, идентификацию и аутентификацию — к разделам 4–7 ГОСТ Р 58833-2020. Меры РБПО по ГОСТ Р 56939 и ГОСТ Р 71207 рассматриваются отдельно: их наличие не подтверждает выполнение всех требований приказа № 76 к разработке, документации и испытаниям.
Требования называют десять функций безопасности (ФБ) и предъявляют к каждой свой пункт. vStack Center — управляющий слой платформы: он держит эталонные конфигурации, роли, политику входа и журнал событий, а исполняет команды гипервизор на узлах. Поэтому часть функций закрывается в vStack Center, часть — на узле, а часть требует средств за пределами платформы.
| Функция безопасности | Пункт | Где закрывается |
|---|---|---|
| ФБ1 Доверенная загрузка ВМ | 9 | гипервизор узла; vStack Center хранит эталон конфигурации и фиксирует расхождения |
| ФБ2 Контроль целостности | 10 | vStack Center — целостность журнала и сверка конфигурации ВМ; объекты узла — гипервизор и хостовая ОС |
| ФБ3 Регистрация событий безопасности | 11 | vStack Center |
| ФБ4 Ролевой метод управления доступом | 12 | vStack Center |
| ФБ5 Резервное копирование | 13 | vStack Center — копии ВМ и архивы журнала; параметры настройки платформы — внешними средствами |
| ФБ6 Управление потоками информации | 15 | vStack Center — сети ВЦОД и Edge-маршрутизаторы; фильтрация трафика — на узлах |
| ФБ7 Защита памяти | 16 | гипервизор и хостовая ОС |
| ФБ8 Ограничение программной среды | 14 | хостовая ОС узла |
| ФБ9 Идентификация и аутентификация | 17 | vStack Center |
| ФБ10 Централизованное управление образами ВМ и ВМ | 18 | vStack Center |
Устройство разграничения доступа описано в разделе Модель безопасности, настройка под требования класса — в разделе Харденинг. Требования приказа № 76 к четвёртому уровню доверия разобраны по пунктам в разделе Уровень доверия 4.
Соответствие
ФБ1. Доверенная загрузка виртуальных машин (п. 9).
Требование класса 4: заблокировать запуск ВМ при нарушении целостности конфигурации её виртуального оборудования, а также при нарушении целостности файлов виртуальной BIOS (первичного загрузчика ВМ) и (или) исполняемых файлов гостевой ОС (п. 9.2).
Пункт 9.2 допускает альтернативу. Отсутствие проверки файлов гостевой ОС само по себе не означает невыполнение всего пункта: нужно подтвердить охват первичного загрузчика и блокировку запуска для выбранного варианта.
| Требование | Как закрыто |
|---|---|
| Эталон конфигурации виртуального оборудования (п. 9.1) | Эталонная конфигурация ВМ (vCPU, память, диски, сетевые адаптеры, профиль ОС) хранится в управляющем слое, а не на узле |
| Выявление расхождения конфигурации (п. 9.1) | Действие «сверить конфигурацию» строит ожидаемое состояние из записей базы и сравнивает с состоянием работающей ВМ. Результат — статус и число расхождений; расхождение пишется в журнал событием о нарушении целостности. Из сравнения исключаются SMBIOS UUID гостя, чувствительные ключи, поля checkpoint.*, значение nvmf=false и определённые остаточные поля живой миграции |
| Целостность файлов виртуальной BIOS (п. 9.2) | Гипервизор открывает файл прошивки с запросом проверки целостности. При загруженном манифесте и включённом режиме блокировки подсистема узла сверяет файл с отпечатком SHA-512. Несовпадение даёт ошибку аутентификации и ненулевой код завершения процесса ВМ — машина не запускается. При отсутствии записи возможен обход по привилегии, поэтому этот сценарий проверяется отдельно. Каталог прошивок включён в сканирование с исключениями из фильтров по пути и типу содержимого. Один запрос проверки без режима блокировки защиты не обеспечивает |
| Целостность исполняемых файлов гостевой ОС (п. 9.2) | Проверка перед запуском в проверенных путях Center и узла не найдена. Наличие возможностей TPM или UEFI не доказывает такую проверку. Это ограничение выбранного механизма, а не самостоятельное основание считать весь п. 9.2 незакрытым |
Отдельно стоит различать две проверки прошивки. Контроллер ВМ проверяет, что файл прошивки существует, и при его отсутствии подставляет прошивку по умолчанию; подмена отсутствующего файла целостностью не управляет. Блокировка запуска при нарушенной целостности приходит от подсистемы контроля целостности узла, а не от этой проверки.
ФБ2. Контроль целостности (п. 10).
Требование класса 4 добавляет к контролю целостности объектов и настроек обеспечение целостности сведений о событиях безопасности.
| Требование | Как закрыто |
|---|---|
| Целостность сведений о событиях безопасности (п. 10.3) | Записи журнала связаны SHA-256 хеш-цепочкой: хеш записи считается от хеша предыдущей записи и полей самой записи — номера, времени, типа, категории, важности, субъекта, результата и подробностей. Первая запись опирается на стартовое значение цепочки, а при архивации сохраняется якорь, поэтому цепочка продолжается через архив. Проверка проходит цепочку и показывает, где она нарушена, с отчётом о последней проверке |
| Контроль целостности в процессе загрузки (п. 10.1) | Загрузчик со встроенным доверенным якорем умеет проверять подпись манифеста и передавать ядру его путь и SHA-256; ядро проверяет и разбирает переданный манифест при монтировании корня. В выпущенной линии подписанный загрузочный манифест в поставку не собирается. В готовящейся линии на новой базовой системе его сборка подтверждена журналом сборки, но конечный носитель и передача манифеста от загрузчика ядру на стенде не проверены. Этот манифест охватывает каталог /boot, а не все компоненты узла |
| Контроль целостности динамически в процессе функционирования (п. 10.1) | Манифест собирается на узле утилитой платформы: обход системных каталогов, отбор по типу содержимого, отпечаток SHA-512 на файл. Администратор загружает его в ядро без проверки подписи. Включение проверки, режим блокировки и запрет загрузки новых манифестов задаются отдельными командами. В режиме блокировки проверяются запуск программы, открытие файла, отображение файла в память, изменение прав отображения и загрузка модулей ядра; действуют условия режима и исключения по привилегиям |
| Контроль целостности конфигурации виртуального оборудования ВМ (п. 10.1) | Сверка работающей ВМ с эталонной записью, результат «совпадает / не совпадает» с числом расхождений |
| Информирование администратора безопасности (п. 10.1) | Узлы шлют события контроля целостности в журнал vStack Center с указанием пути к файлу и алгоритма контрольной суммы. Критические события попадают в счётчик непрочитанных и в почтовые оповещения с настраиваемым порогом важности |
| Целостность исполняемых файлов и параметров настройки (п. 10.2) | Генератор отбирает исполняемые файлы и сценарии узла. Каталоги настроек сканируются, но обычные текстовые файлы настроек отсекаются фильтром по типу содержимого; отдельный файл можно передать генератору явно. Загрузочный манифест тоже исключает ряд изменяемых настроек. Полное покрытие настроек узла и исполняемых файлов управляющей ВМ не подтверждено; штатная проверка конфигурационной базы Center не найдена |
ФБ3. Регистрация событий безопасности (п. 11).
Пункт 11.1 задаёт обязательный перечень регистрируемых событий и свойства журнала, пункт 11.2 добавляет для класса 4 описание события со сведениями о его важности.
| Требование | Как закрыто |
|---|---|
| Перечень обязательных событий | Успешная и неуспешная аутентификация, доступ к ВМ, создание и удаление ВМ, запуск и остановка ВМ и компонентов платформы с указанием причины остановки, изменение ролевой модели, изменение конфигурации платформы и ВМ, факты нарушения целостности |
| Состав записи | Номер записи, UUID события, время, тип события, субъект, объект, результат success или failure, адрес источника запроса; причина остановки и прочие обстоятельства — в подробностях. Субъект, объект и адрес могут отсутствовать: например, при обработке ответа о сверке ВМ имя пользователя и адрес запроса не сохраняются |
| Важность события (класс 4) | Отдельное поле severity со словарём уровней; три верхних уровня считаются критическими |
| Журнал только на чтение | Методов правки и удаления записей нет; роль аудитора журнал читает и выгружает, но не меняет |
| Оповещение администратора безопасности | Серверная часть ведёт счётчик непрочитанных критических событий и отправляет письма настроенным получателям, если на управляющей ВМ задан почтовый сервер. Условия и состав письма — ниже, в блоке «Почтовые оповещения». Всплывающее уведомление в интерфейсе проверкой серверного кода не подтверждено |
| Отбор записей журнала | API поддерживает фильтры по времени, типу, категории, важности, субъекту, результату и прочитанности. Фильтра по объекту нет |
| Реакция на событие | Учётная запись блокируется при исчерпании лимита неудачных попыток входа |
| Архивирование при исчерпании места | Автоархивация вытесняет старые записи в сжатые файлы .csv.gz и освобождает таблицу |
Почтовые оповещения.
Письмо отправляет диспетчер vStack Center после того, как запись события сохранена в журнале. Если запись откатилась, письма не будет. Отправка идёт в фоне: медленный или недоступный почтовый сервер запись в журнал не задерживает и не отменяет.
Письмо уходит, только когда выполнены все четыре условия.
| Условие | Как устроено |
|---|---|
| Рассылка включена | Переключатель в настройках журнала. По умолчанию выключен |
| Важность события не ниже порога | Порог по умолчанию — alert. При нём письма приходят о событиях уровней emergency и alert: нарушение целостности файла, конфигурации и конфигурации ВМ, повреждение манифеста целостности, нарушение хеш-цепочки журнала. Блокировка учётной записи, исчерпание места на диске, паника ядра узла и замена диска в пуле имеют уровень critical и при пороге по умолчанию писем не порождают, хотя индикатор критических событий в интерфейсе их считает |
| Задан хотя бы один получатель | Каждый адрес проверяется на формат при сохранении настроек |
| Задан почтовый сервер | Адрес SMTP-сервера задаётся в окружении диспетчера на управляющей ВМ. Без него почтовый транспорт не создаётся, и письма не уходят при любых настройках в интерфейсе. Штатное развёртывание управляющей ВМ этот параметр не задаёт |
Тема письма — [vStack Security] <наименование события> — <код уровня>. Тело —
простой текст: наименование события, уровень важности, дата и время, субъект
(имя и идентификатор пользователя), объект (тип, идентификатор, имя), результат и
IP-адрес источника запроса. Отсутствующее поле заменяется прочерком. Каждый
получатель получает отдельное письмо.
При разборе письма учитывайте четыре особенности:
- время в письме — момент формирования письма в UTC, а не время записи в журнале;
- номера записи и UUID события в письме нет, запись в журнале находят фильтром по типу события и времени;
- повторной отправки нет: если почтовый сервер недоступен или отклонил письмо, ошибка остаётся только в логе диспетчера, в журнале безопасности и в интерфейсе её не видно;
- логина, пароля и режима шифрования для SMTP-сервера диспетчер не принимает, поэтому сервер должен принимать письма от управляющей ВМ без аутентификации.
Изменение настроек рассылки через интерфейс или API пишется в журнал событием
config.security_settings_changed. Параметры почтового сервера задаются в
файле окружения на управляющей ВМ, мимо API, и их правка отдельным событием в
журнал не попадает. Порядок настройки — в разделах Харденинг и
Как настроить письма о событиях журнала безопасности.
Механика журнала описана в разделе Журнал безопасности.
ФБ4. Ролевой метод управления доступом (п. 12).
Пункт 12 требует четыре роли пользователей и задаёт минимальный состав прав каждой. Каждой соответствует фиксированная роль vStack Center.
| Роль по требованиям | Роль в vStack Center | Что требует пункт |
|---|---|---|
| Разработчик виртуальной машины (п. 12.1) | VM Developer | Создавать ВМ и изменять их конфигурацию |
| Администратор безопасности средства виртуализации (п. 12.2) | Security Admin | Читать журнал событий, формировать отчёты по заданным критериям отбора, выгружать данные журнала |
| Администратор средства виртуализации (п. 12.3) | Cluster Master | Заводить и вести учётные записи, назначать права на ВМ, управлять виртуальным оборудованием и квотами, перемещать, запускать, останавливать и удалять ВМ, создавать снимки состояния |
| Администратор виртуальной машины (п. 12.4) | vDC User | Доступ к виртуальной машине через интерфейс платформы |
| Требование | Как закрыто |
|---|---|
| Полномочия в пределах назначенной роли (п. 12.5) | Привилегии с областью действия на уровне кластера, ВЦОД и собственных объектов; авторизация каждого вызова единой функцией |
| Защита настроек разграничения | Фиксированные роли неизменяемы через API; привилегии управления ролями кастомным ролям не выдаются |
| Криптографическая защита удалённого доступа (п. 12.6) | Требует средств криптографической защиты, прошедших оценку соответствия; в состав платформы они не входят и разворачиваются отдельно |
Состав ролей и полный реестр привилегий — в справочнике Роли и привилегии.
ФБ5. Резервное копирование (п. 13).
Класс 4 требует резервного копирования образов ВМ и конфигурации их виртуального оборудования, параметров настройки платформы и сведений о событиях безопасности.
| Требование | Как закрыто |
|---|---|
| Копии образов ВМ | Резервное копирование кластер-кластер: цепочка копий на кластере-хранителе, точки восстановления, выдача точки обратно |
| Конфигурация виртуального оборудования ВМ | При получении конфигурации со слоя хранения Center создаёт запись области импорта; окончательный импорт ВМ выполняет оператор |
| Сведения о событиях безопасности | Автоархивация журнала в сжатые файлы и выгрузка событий в CSV и JSON; перенос архивов за пределы кластера выполняет администратор |
| Параметры настройки платформы | Штатный экспорт конфигурации и автоматизация дампа базы в проверенном коде не найдены. Дамп базы по расписанию — рекомендуемая административная мера; регламент с составом копии, восстановлением и проверкой результата не предъявлен |
Модель копирования — в разделе Резервное копирование кластер-кластер.
ФБ6. Управление потоками информации (п. 15).
| Требование | Как закрыто |
|---|---|
| Управление потоками между ВМ и информационными системами | Сети ВЦОД разных типов, пулы адресов и Edge-маршрутизаторы с правилами firewall и NAT |
| Контроль взаимодействия ВМ между собой | Сеть ВЦОД ограничивает связность машин. Доступ к сетям кластерных типов проверяется по привилегии, которую по умолчанию имеет только Cluster Master; её можно выдать кастомной роли |
| Фильтрация на канальном и сетевом уровнях | Center передаёт правила firewall и NAT Edge-маршрутизатору. Исполнение фильтрации на узле проверкой кода Center не подтверждено |
ФБ9. Идентификация и аутентификация пользователей (п. 17).
Класс 4 задаёт числовые требования: пароль не короче 8 символов при алфавите не менее 70 символов и не более 4 неуспешных попыток аутентификации до блокировки.
| Требование | Как закрыто |
|---|---|
| Аутентификация по идентификатору и паролю | Вход по имени и паролю, сессионный токен на каждый запрос; запрос без токена отклоняется до разбора операции |
| Длина и состав пароля | По умолчанию минимальная длина — 8 символов и включены требования заглавной и строчной ASCII-буквы, цифры и специального символа. Специальным считается любой символ вне ASCII-букв и цифр. Это политика продукта: приказ задаёт длину и размер допустимого алфавита, а не обязательное наличие четырёх типов символов в каждом пароле |
| Лимит попыток по умолчанию | 4 неуспешные попытки; окно подсчёта и срок блокировки — по 30 минут. Приказ задаёт только предел в 4 попытки (п. 17.3), срок разблокировки устанавливает администратор (п. 17.1). Соответствие алгоритма с временным окном требует отдельного обоснования |
| Смена первичного пароля | Новая учётная запись получает признак обязательной смены пароля; до смены временная сессия допускает смену своего пароля и чтение политики |
| Уникальность идентификаторов пользователей (п. 17.1) | Имена учётных записей уникальны в пределах кластера |
| Запрет повторить действующий пароль | При самостоятельной смене новый пароль сверяется с текущим паролем той же учётной записи. При сбросе пароля другого пользователя администратором эта проверка пропускается |
| Блокировка после неуспешных попыток | Настраиваемый лимит попыток, окно их подсчёта и срок блокировки; снятие вручную администратором или по истечении срока |
| Хранение аутентификационной информации | Пароли хранятся хешем bcrypt, в открытом виде не выдаются и не логируются |
| Сообщение при неверном вводе | Серверная часть возвращает Authentication failure, в отдельных случаях с error.data. Приглашение повторить ввод в интерфейсе проверкой кода Center не подтверждено |
| Взаимная идентификация и аутентификация при удалённом доступе | В Center подтверждены проверки сессии и допустимой точки доступа. Взаимный процесс, включая проверку идентичности сервера и доверие к его сертификату, этим кодом не подтверждён |
Числовые значения длины и лимита попыток по умолчанию соответствуют п. 17.3, но метод правки параметров безопасности принимает любую минимальную длину пароля от единицы и любой лимит попыток от единицы, поэтому администратор с глобальными правами может опустить длину ниже восьми символов или поднять лимит попыток выше четырёх, и платформа этого не отклонит. Требования к составу можно отключить. Проверить значения и не ослабить их — работа администратора, см. Харденинг.
ФБ10. Централизованное управление образами ВМ и виртуальными машинами (п. 18).
| Требование | Как закрыто |
|---|---|
| Создание, хранение, получение и удаление образов ВМ | Библиотека образов ОС: внешний источник, импорт в кластер, раздача по пулам, привязка к ВЦОД, удаление. Есть прямая загрузка файла по персональной ссылке со сроком действия: Center получает контрольную сумму от службы загрузки и ставит принятый файл в раздачу. Сумма сама по себе не подтверждает доверенность происхождения |
| Создание образа из ВМ и модификация образов (п. 18.1) | Метод os-image-from-vm реализует только вход операции: проверяет ВМ и права, записывает намерение, блокирует ВМ и создаёт запись образа в состоянии importing. Отправка команды преобразования и завершение операции не найдены. Полное создание образа из ВМ и модификация образов не подтверждены |
| Сверка SHA-256 при импорте образа | Импорт из библиотеки идёт через службу раздачи образов: Center передаёт ей ожидаемую сумму из манифеста библиотеки, раздача по пулам начинается только после ответа о готовности, а при ответе sha256_mismatch импорт прекращается с записью события нарушения целостности. По спецификации служба считает сумму по скачанным байтам до раздачи; код самой службы этой проверкой не прочитан. Узловое скачивание образа по адресу и приём потока на узле сумму не сверяют, но в путь импорта из библиотеки не входят. При прямой загрузке файла эталонная сумма вычисляется после приёма файла, поэтому сверки с суммой отправителя нет. П. 18.1 не задаёт алгоритм SHA-256 |
| Чтение записей журнала и отчёты по критериям отбора | API поддерживает фильтры по времени, типу, категории, важности, субъекту, результату и прочитанности. Фильтра по объекту нет; параметр objective меняет форму ответа |
| Выгрузка данных журнала | Экспорт событий в CSV и JSON, скачивание архивных файлов |
| Управление размещением и перемещением ВМ и их образов (классы 5 и 4) | Перенос ВМ между узлами и пулами хранения, включая живой перенос хранилища работающей ВМ, клонирование и копирование дисков на другой кластер. Конфигурация ВМ переносится вместе с машиной; охват всех настроек и перемещения образов отдельно не подтверждён |
ФБ8. Ограничение программной среды (п. 14).
Функция реализована хостовой операционной системой узла — vStack OS. В интерфейсе vStack Center она не настраивается, поэтому ниже описаны механизмы узла.
Класс 4 требует к общему контролю запуска добавить блокировку запуска компонентов с нарушенной целостностью и блокировку компонентов, не прошедших аутентификацию с использованием свидетельств подлинности модулей.
| Требование | Как закрыто |
|---|---|
| Перечень компонентов, разрешённых для запуска (п. 14.1) | Манифест целостности: строка на файл вида «абсолютный путь и отпечаток SHA-512». Манифест собирается обходом системных каталогов с отбором по типу содержимого — исполняемые файлы, сценарии оболочки, сценарии Perl и Python. В состоянии применения запуск файла без записи в манифесте блокируется |
| Блокировка запуска при нарушенной целостности (п. 14.2) | Отпечаток считается по файлу и сверяется с манифестом, поэтому изменённый файл запуск не проходит. Дополнительно запись в файл, попавший в манифест, запрещается отдельным тумблером, а если файл всё же открыт на запись, кешированный вердикт сбрасывается — иначе правка осталась бы незамеченной до вытеснения записи о файле |
| Блокировка компонентов без свидетельства подлинности (п. 14.2) | Подпись загрузочного манифеста проверяется загрузчиком по встроенному доверенному якорю; ядру передаётся SHA-256. В выпущенной линии манифест не собирается, в готовящейся линии на новой базовой системе его сборка подтверждена для /boot. Манифест, загружаемый администратором утилитой платформы на работающем узле, принимается без проверки подписи. Пакетная раздача и скрипт обновления подписываются, проверка подписи подтверждена в конвейере публикации |
| Защита от обхода контроля | Кроме запуска, проверяются отображение файла в память и изменение прав отображения. Механизмы действуют с условиями режима и исключениями по привилегиям; наличие этих проверок не заменяет испытания обхода |
ФБ7. Защита памяти (п. 16).
Функция реализована гипервизором и хостовой ОС узла. Требования пункта 16.1 предъявляются ко всем трём классам одинаково, поэтому дельты класса 4 здесь нет.
| Требование | Как закрыто |
|---|---|
| Очистка остаточной информации в памяти при её освобождении либо блокирование доступа к ней | При уничтожении ВМ гипервизор затирает обычные страницы памяти гостя; память устройств и страницы без физической подложки пропускаются, при сбросе ВМ память сохраняется. Затирание по умолчанию выключено. Порядок включения — в разделе Харденинг |
| Удаление объектов файловой системы перезаписью | В выпущенной линии свойство secure_destroy включает физическую перезапись блоков удаляемого набора данных по всем копиям адресов; общие блоки дедупликации с несколькими ссылками пропускаются. Свойство по умолчанию выключено |
| Размещение кода вне области, доступной одновременно для записи и исполнения (W^X) | Обычная сборка: режим разрешительный. Сертифицируемый контур: файл настроек задаёт kern.elf64.allow_wx=0; требуется проверить фактическое значение на узле. В реализации есть исключения для отдельных ELF-флагов |
| Изоляция областей памяти ВМ | Память каждой ВМ живёт в собственных объектах сегментов гипервизора и отображается гостю через вложенные таблицы страниц; общей области памяти у машин нет. Управляющий слой в отображении памяти не участвует |
Меры РБПО в процессе разработки.
Эти меры относятся к процессу разработки продукта, а не к его настройке администратором, и в интерфейсе не отражаются.
| Мера | Как закрыта |
|---|---|
| Статический анализ кода | Находка линтера проваливает конвейер сборки |
| Композиционный анализ | Проверки cargo-deny на известные уязвимости, запрещённые пакеты и лицензии проваливают конвейер. Находки Trivy уровней HIGH и CRITICAL также проваливают конвейер |
| Контроль подавлений | Подавление находки без обоснования останавливает конвейер, причём по всему дереву, а не только на изменённых файлах. Новое подавление требует свежего согласования от выделенного списка специалистов по безопасности; автор изменения согласовать себя не может |
| Классификация зависимостей | Источник разметки поверхности атаки и участия в функциях безопасности — перечень изделия в devops/ports. Для компонентов вне явного перечня применяются значения по умолчанию no/no; это не подтверждает отдельный анализ каждого компонента |
| Ведомость состава | Формирование ведомости включено для основной ветки и выпуска срочных исправлений из неё; для ветки разработки и остальных веток выключено |
| Воспроизводимость сборки | Набор инструментов Rust зафиксирован, анализаторы включены в сборочный образ. Отдельные версии устанавливаемых инструментов cargo и Semgrep командами установки не закреплены |
| Поиск шаблонов небезопасного кода | Находка Semgrep проваливает конвейер |
Проверки действуют в конвейере; ведомость состава строится только в указанных выше случаях. Настройки репозитория сейчас допускают слияние при проваленном конвейере. Поэтому находка проваливает конвейер, но сама по себе не останавливает слияние.
Требования уровня доверия 4.
Требования приказа № 76 разобраны по пунктам в разделе Уровень доверия 4. Модель по п. 8.2 требует документа и оценки содержания; для анализа скрытых каналов по п. 20.2 сначала уточняется применимость по п. 17. Фаззинг рассматривается отдельно как мера ГОСТ, а не как третий пункт приказа № 76. Усиления четвёртого уровня не ограничиваются моделью и скрытыми каналами.
Доступность механизмов и значения узла зависят от линии и контура сборки. Порядок настройки и проверки после каждого обновления — в разделе Харденинг.
Границы подтверждения
Страница описывает реализованные механизмы и их проверяемые свойства. Она не подтверждает статус сертификации платформы или хостовой ОС, а также выполнение требований, которые зависят от внешних компонентов или поведения интерфейса.
Механизмы узла — доверенная загрузка ВМ, контроль целостности, ограничение программной среды и защита памяти — описаны по исходным текстам хостовой ОС и её сборочных профилей. Страница описывает их устройство и наблюдаемое поведение; подтверждением результатов испытаний она не является. Значения параметров, приведённые как «по умолчанию», взяты из кода и миграций базы и относятся к поставке без изменений, внесённых администратором.
Харденинг
Числовые параметры парольной политики, лимит неудачных попыток и автоархивация журнала приходят со значениями, которые требованиям класса 4 удовлетворяют, — администратор их проверяет и не ослабляет. А вот разделение четырёх ролей по разным учётным записям, оповещения о событиях безопасности и сетевая доступность управляющего слоя конфигурацией по умолчанию не закрыты: это работа администратора. Порядок — в разделе Харденинг.