Соответствие ФСТЭК
Модель безопасности
Сертификация относится к платформе 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.
Требования называют десять функций безопасности (ФБ) и предъявляют к каждой свой пункт. 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.1) | Эталонная конфигурация ВМ (vCPU, память, диски, сетевые адаптеры, профиль ОС) хранится в управляющем слое, а не на узле |
| Выявление расхождения конфигурации (п. 9.1) | Отдельное действие «сверить конфигурацию» строит ожидаемое состояние в пространстве имён конфигурации гипервизора из тех же записей базы, которыми ВМ создавалась и запускалась, и сравнивает с состоянием работающей машины. Результат — статус и число расхождений; расхождение пишется в журнал событием о нарушении целостности. Сравнение идёт без списка исключений: из ответа узла отбрасывается единственное поле — SMBIOS UUID гостя, у которого в управляющем слое нет аналога |
| Целостность файлов виртуальной BIOS (п. 9.2) | Гипервизор открывает файл прошивки с запросом проверки целостности. Подсистема контроля целостности узла сверяет файл с отпечатком SHA-512 из манифеста, и при несовпадении или отсутствии записи открытие завершается ошибкой аутентификации, а процесс ВМ завершается с ненулевым кодом — машина не запускается. Файлы прошивки попадают в манифест намеренно: каталог прошивок входит в список сканирования, а фильтры по пути и по типу содержат для него явное исключение, поэтому образ прошивки получает запись в манифесте, хотя не является ни исполняемым файлом, ни сценарием. Условие работы — загруженный манифест и включённый режим блокировки на узле |
| Блокировка запуска по конфигурации (п. 9.1) | Выполняется гипервизором узла, вне управляющего слоя |
| Целостность исполняемых файлов гостевой ОС (п. 9.2) | Механизма нет. Файловая система гостя перед запуском не читается ни узлом, ни управляющим слоем. Средств, которыми гостевая ОС могла бы проверить себя сама, платформа тоже не предоставляет: виртуальный TPM машине не выдаётся, поддержка постоянного хранилища переменных UEFI в контроллере ВМ отключена, а прошивки поставляются в сборках без хранилища доверенных ключей. Требование остаётся открытым, см. незакрытые вопросы в конце раздела |
Отдельно стоит различать две проверки прошивки. Контроллер ВМ проверяет, что файл прошивки существует, и при его отсутствии подставляет прошивку по умолчанию; подмена отсутствующего файла целостностью не управляет. Блокировка запуска при нарушенной целостности приходит от подсистемы контроля целостности узла, а не от этой проверки.
ФБ2. Контроль целостности (п. 10).
Требование класса 4 добавляет к контролю целостности объектов и настроек обеспечение целостности сведений о событиях безопасности.
| Требование | Как закрыто |
|---|---|
| Целостность сведений о событиях безопасности (п. 10.3) | Записи журнала связаны SHA-256 хеш-цепочкой: хеш записи считается от хеша предыдущей записи и полей самой записи — номера, времени, типа, категории, важности, субъекта, результата и подробностей. Первая запись опирается на стартовое значение цепочки, а при архивации сохраняется якорь, поэтому цепочка продолжается через архив. Проверка проходит цепочку и показывает, где она нарушена, с отчётом о последней проверке |
| Контроль целостности в процессе загрузки (п. 10.1) | Механизм в базовой системе есть и сборочным профилем запрошен: загрузчик со встроенным доверенным якорем проверяет подпись манифеста и передаёт ядру путь к манифесту и его SHA-256, а ядро разбирает манифест на монтировании корня и при ошибке разбора останавливает загрузку. Подписанный манифест загрузки при этом в поставку не собирается, поэтому проверять на загрузке пока нечего — см. незакрытые вопросы в конце раздела |
| Контроль целостности динамически в процессе функционирования (п. 10.1) | Манифест собирается на узле утилитой платформы: обход системных каталогов, отбор по типу содержимого, отпечаток SHA-512 на файл. Загрузка манифеста в ядро, включение проверки, режим блокировки и запрет загрузки новых манифестов задаются отдельными командами. В режиме блокировки проверка навешена на запуск программы, открытие файла, отображение файла в память, изменение прав отображения и загрузку модулей ядра |
| Контроль целостности конфигурации виртуального оборудования ВМ (п. 10.1) | Сверка работающей ВМ с эталонной записью, результат «совпадает / не совпадает» с числом расхождений |
| Информирование администратора безопасности (п. 10.1) | Узлы шлют события контроля целостности в журнал vStack Center с указанием пути к файлу и алгоритма контрольной суммы. Критические события попадают в счётчик непрочитанных и в почтовые оповещения с настраиваемым порогом важности |
| Целостность исполняемых файлов и параметров настройки (п. 10.2) | Исполняемые файлы узла и его каталоги настроек входят в манифест: список сканирования по умолчанию включает системные каталоги исполняемых файлов, каталоги настроек и каталог загрузки. Параметры настройки управляющего слоя живут в базе, и штатной проверки их целостности нет — см. незакрытые вопросы в конце раздела |
ФБ3. Регистрация событий безопасности (п. 11).
Пункт 11.1 задаёт обязательный перечень регистрируемых событий и свойства журнала, пункт 11.2 добавляет для класса 4 описание события со сведениями о его важности.
| Требование | Как закрыто |
|---|---|
| Перечень обязательных событий | Успешная и неуспешная аутентификация, доступ к ВМ, создание и удаление ВМ, запуск и остановка ВМ и компонентов платформы с указанием причины остановки, изменение ролевой модели, изменение конфигурации платформы и ВМ, факты нарушения целостности |
| Состав записи | Номер записи, UUID события, время, тип события, субъект, объект, результат success или failure, адрес источника запроса; причина остановки и прочие обстоятельства события — в подробностях записи |
| Важность события (класс 4) | Отдельное поле severity со словарём уровней; три верхних уровня считаются критическими |
| Журнал только на чтение | Методов правки и удаления записей нет; роль аудитора журнал читает и выгружает, но не меняет |
| Оповещение администратора безопасности | Всплывающее уведомление о новом критическом событии, счётчик непрочитанных, письма получателям |
| Реакция на событие | Учётная запись блокируется при исчерпании лимита неудачных попыток входа |
| Архивирование при исчерпании места | Автоархивация вытесняет старые записи в сжатые файлы .csv.gz и освобождает таблицу |
Механика журнала описана в разделе Журнал безопасности.
ФБ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 требует резервного копирования образов ВМ и конфигурации их виртуального оборудования, параметров настройки платформы и сведений о событиях безопасности.
| Требование | Как закрыто |
|---|---|
| Копии образов ВМ | Резервное копирование кластер-кластер: цепочка копий на кластере-хранителе, точки восстановления, выдача точки обратно |
| Конфигурация виртуального оборудования ВМ | Эталонная конфигурация хранится в базе управляющего слоя и восстанавливается вместе с ВМ |
| Сведения о событиях безопасности | Автоархивация журнала в сжатые файлы и выгрузка событий в CSV и JSON; перенос архивов за пределы кластера выполняет администратор |
| Параметры настройки платформы | Отдельной операции в интерфейсе нет. Требование закрывается регламентной процедурой администратора — снятием дампа базы управляющего слоя по расписанию вместе с копиями ВМ |
Модель копирования — в разделе Резервное копирование кластер-кластер.
ФБ6. Управление потоками информации (п. 15).
| Требование | Как закрыто |
|---|---|
| Управление потоками между ВМ и информационными системами | Сети ВЦОД разных типов, пулы адресов и Edge-маршрутизаторы с правилами firewall и NAT |
| Контроль взаимодействия ВМ между собой | Сеть ВЦОД ограничивает связность машин; сети кластерных типов доступны только роли Cluster Master |
| Фильтрация на канальном и сетевом уровнях | Правила применяются на Edge-маршрутизаторе; сам трафик проходит через сетевой слой узлов |
ФБ9. Идентификация и аутентификация пользователей (п. 17).
Класс 4 задаёт числовые требования: пароль не короче 8 символов при алфавите не менее 70 символов и не более 4 неуспешных попыток аутентификации до блокировки.
| Требование | Как закрыто |
|---|---|
| Аутентификация по идентификатору и паролю | Вход по имени и паролю, сессионный токен на каждый запрос; запрос без токена отклоняется до разбора операции |
| Длина и состав пароля | Настраиваемая минимальная длина и четыре требования к составу символов: заглавная буква, строчная, цифра, спецсимвол. По умолчанию минимальная длина — 8 символов, и все четыре требования включены, что даёт алфавит из 26 заглавных, 26 строчных, 10 цифр и 32 знаков пунктуации — 94 символа против требуемых 70 |
| Лимит попыток по умолчанию | 4 неуспешные попытки, окно подсчёта 30 минут, срок блокировки 30 минут — ровно предел, заданный классом 4 |
| Смена первичного пароля | Учётной записи включается требование сменить пароль при первом входе; до смены доступна только форма смены |
| Запрет одинаковых идентификаторов и паролей у разных пользователей (п. 17.1) | Имена учётных записей уникальны в пределах кластера. Пароли разных учётных записей между собой не сравниваются — требование закрыто частично, см. незакрытые вопросы в конце раздела |
| Запрет повторить действующий пароль | При смене пароля новый сверяется с текущим паролем той же учётной записи |
| Блокировка после неуспешных попыток | Настраиваемый лимит попыток, окно их подсчёта и срок блокировки; снятие вручную администратором или по истечении срока |
| Хранение аутентификационной информации | Пароли хранятся хешем bcrypt, в открытом виде не выдаются и не логируются |
| Сообщение при неверном вводе | Неуспешный вход возвращает приглашение ввести идентификатор и пароль заново, без указания, какая из двух частей не совпала |
| Взаимная аутентификация при удалённом доступе | HTTPS-endpoint кластера с криптографической подписью запросов |
Значения по умолчанию требованиям класса 4 удовлетворяют, но нижней границы у них нет: метод правки параметров безопасности принимает любую минимальную длину пароля от единицы и любой лимит попыток от единицы, поэтому администратор с глобальными правами может опустить длину ниже восьми символов или поднять лимит попыток выше четырёх, и платформа этого не отклонит. Проверить значения и не ослабить их — работа администратора, см. Харденинг.
ФБ10. Централизованное управление образами ВМ и виртуальными машинами (п. 18).
| Требование | Как закрыто |
|---|---|
| Создание, хранение, получение и удаление образов ВМ | Библиотека образов ОС: внешний источник, импорт в кластер, раздача по пулам, привязка к ВЦОД, удаление образа |
| Модификация образов ВМ | Управляющий слой образы не изменяет: библиотека принимает готовый образ из внешнего источника. Требование закрывается подготовкой образа вне платформы — см. незакрытые вопросы в конце раздела |
| Чтение записей журнала и отчёты по критериям отбора | Экран журнала с фильтрами по времени, типу, категории, важности, субъекту и объекту |
| Выгрузка данных журнала | Экспорт событий в CSV и JSON, скачивание архивных файлов |
| Управление размещением и перемещением ВМ и их образов (классы 5 и 4) | Перенос ВМ между узлами и пулами хранения, клонирование, копирование дисков на другой кластер; конфигурация ВМ переносится вместе с машиной |
ФБ8. Ограничение программной среды (п. 14).
Функция реализована хостовой операционной системой узла — vStack OS. В интерфейсе vStack Center она не настраивается, поэтому ниже описаны механизмы узла.
Класс 4 требует к общему контролю запуска добавить блокировку запуска компонентов с нарушенной целостностью и блокировку компонентов, не прошедших аутентификацию с использованием свидетельств подлинности модулей.
| Требование | Как закрыто |
|---|---|
| Перечень компонентов, разрешённых для запуска (п. 14.1) | Манифест целостности: строка на файл вида «абсолютный путь и отпечаток SHA-512». Манифест собирается обходом системных каталогов с отбором по типу содержимого — исполняемые файлы, сценарии оболочки, сценарии Perl и Python. В состоянии применения запуск файла без записи в манифесте блокируется |
| Блокировка запуска при нарушенной целостности (п. 14.2) | Отпечаток считается по файлу и сверяется с манифестом, поэтому изменённый файл запуск не проходит. Дополнительно запись в файл, попавший в манифест, запрещается отдельным тумблером, а если файл всё же открыт на запись, кешированный вердикт сбрасывается — иначе правка осталась бы незамеченной до вытеснения записи о файле |
| Блокировка компонентов без свидетельства подлинности (п. 14.2) | Манифест подписан, подпись проверяется загрузчиком по доверенному якорю, встроенному в загрузчик; ядро дополнительно получает SHA-256 манифеста и останавливает загрузку при расхождении. Раздача пакетов, из которой узел получает компоненты, подписана ключом раздачи, а скрипт обновления публикуется с отсоединённой подписью и проверяется по тому же ключу |
| Невозможность обхода контроля | Кроме запуска, проверка навешена на отображение файла в память и на изменение прав отображения. Без второго хука первый обходится тривиально: отобразить файл без права исполнения и добавить право отдельным вызовом |
ФБ7. Защита памяти (п. 16).
Функция реализована гипервизором и хостовой ОС узла. Требования пункта 16.1 предъявляются ко всем трём классам одинаково, поэтому дельты класса 4 здесь нет.
| Требование | Как закрыто |
|---|---|
| Очистка остаточной информации в памяти при её освобождении | При уничтожении ВМ гипервизор обходит сегменты памяти гостя и затирает страницы; память устройств и страницы без физической подложки пропускаются, при сбросе ВМ память сохраняется намеренно. Механизм включается отдельным параметром ядра и по умолчанию выключен. На текущей линии сборки вместе с ним работает отладочная обвязка, которая до и после затирания дважды просматривает память на тестовый образец и пишет в журнал ядра границы областей памяти, поэтому включать его следует по порядку из раздела Харденинг, а не одним параметром |
| Удаление объектов файловой системы перезаписью | Свойство набора данных включает затирание: при удалении набора, до стандартного пути освобождения, обходятся все блоки и физически перезаписываются по всем копиям адресов. Блоки дедупликации с числом ссылок больше единицы пропускаются, чтобы не повредить данные других наборов. Свойство по умолчанию выключено. Перезапись выполняется нулями, тогда как требование называет случайную битовую последовательность — расхождение вынесено в незакрытые вопросы |
| Размещение кода вне области, доступной одновременно для записи и исполнения | Запрет одновременной записи и исполнения включается файлом настроек ядра, который приходит с сертифицируемым контуром сборки; в обычной сборке базовой системы этот режим разрешительный |
| Изоляция областей памяти ВМ | Память каждой ВМ живёт в собственных объектах сегментов гипервизора и отображается гостю через вложенные таблицы страниц; общей области памяти у машин нет. Управляющий слой в отображении памяти не участвует |
Меры РБПО в процессе разработки.
Эти меры относятся к процессу разработки продукта, а не к его настройке администратором, и в интерфейсе не отражаются.
| Мера | Как закрыта |
|---|---|
| Статический анализ кода | Блокирующий линтер в конвейере сборки: находка останавливает слияние |
| Композиционный анализ | Проверка зависимостей на известные уязвимости и на запрещённые пакеты блокирует слияние; проверка лицензий и сканирование по расширенной базе уязвимостей работают в предупреждающем режиме |
| Контроль подавлений | Подавление находки без обоснования останавливает конвейер, причём по всему дереву, а не только на изменённых файлах. Новое подавление требует свежего согласования от выделенного списка специалистов по безопасности; автор изменения согласовать себя не может |
| Классификация зависимостей | Каждая внешняя зависимость размечена по признакам поверхности атаки и участия в функциях безопасности |
| Ведомость состава | Формирование ведомости состава программного обеспечения включено в конвейере сборки |
| Воспроизводимость сборки | Версия набора инструментов сборки зафиксирована, инструменты анализа запечены в сборочный образ |
| Поиск шаблонов небезопасного кода | Дополнительный анализатор шаблонов включён в предупреждающем режиме |
Перечисленные меры действуют в конвейере и отрабатывают на каждом изменении.
Что по уровню доверия 4 пока не закрыто.
Требования приказа № 76 разобраны по пунктам в разделе Уровень доверия 4. Открытыми там остаются три пункта: модель безопасности средства с формальным доказательством условий безопасности (п. 8.2), идентификация и анализ скрытых каналов по памяти (п. 20.2) и динамический анализ как мера безопасной разработки по ГОСТ Р 56939. Первые два к пятому и шестому уровням доверия не предъявляются вовсе, то есть именно ими четвёртый уровень от них и отличается. Пока они открыты, вывод о полном соответствии уровню доверия 4 преждевремен.
Что не закрыто по функциям безопасности.
| Что требуется | Пункт | Состояние |
|---|---|---|
| Блокировка запуска ВМ при нарушении целостности исполняемых файлов гостевой ОС | 9.2 | Механизм не обнаружен: файловая система гостя перед запуском не читается ни узлом, ни управляющим слоем |
| Перезапись удаляемых объектов файловой системы случайной битовой последовательностью | 16.1 | Перезапись выполняется нулями. Механизм и его тестовое покрытие есть, но константная последовательность буквальной формулировке требования не отвечает — решение о приемлемости за лабораторией |
| Контроль целостности параметров настройки средства | 10.2 | Манифест покрывает исполняемые файлы и каталоги настроек узла. Управляющий слой работает на отдельной виртуальной машине, и на неё контроль целостности не распространяется: в её развёртывании подсистема не поднимается, манифест не собирается. Параметры настройки управляющего слоя живут в базе, штатной проверки их целостности нет |
| Сверка полученного образа ВМ с контрольной суммой | 18.1, 10.1 | Манифест библиотеки образов несёт обязательную SHA-256 на каждый образ, управляющий слой её сохраняет и отдаёт в списке. Сверки скачанного образа с этой суммой нет: узел тянет образ в том по сети и содержимое не хеширует |
| Контроль целостности в процессе загрузки | 10.1 | Загрузчик проверять умеет и сборочным профилем это запрошено, но подписанный манифест загрузки в поставку не собирается: сборка манифеста включается ключом подписи, которого в профилях нет. До этого контроль целостности на узле начинается после загрузки — с момента, когда администратор собрал и загрузил манифест |
| Модификация образов ВМ | 18.1 | Через управляющий слой образ можно получить, раздать по пулам, клонировать и удалить, но не изменить и не создать из существующей ВМ. Преобразование образов из сторонних форматов на слое хранения реализовано, однако в API управляющего слоя не выставлено |
| Запрет одинаковых паролей у разных пользователей | 17.1 | Пароли разных учётных записей между собой не сравниваются |
| Резервное копирование параметров настройки платформы | 13.2 | Отдельной операции в интерфейсе нет; закрывается регламентной процедурой администратора |
Три механизма класса 4 реализованы, но по умолчанию выключены, поэтому без настройки узла требования не выполняются: затирание памяти гостя при уничтожении ВМ, затирание блоков при удалении набора данных и запрет одновременной записи и исполнения, который приходит только с сертифицируемым контуром сборки. Порядок включения — в разделе Харденинг.
Границы подтверждения
Страница описывает реализованные механизмы и их проверяемые свойства. Она не подтверждает статус сертификации платформы или хостовой ОС, а также выполнение требований, которые зависят от внешних компонентов или поведения интерфейса.
Имена учётных записей уникальны. Пароли разных учётных записей управляющий слой между собой не сравнивает; это ограничение нельзя трактовать как запрет на совпадение паролей.
Механизмы узла — доверенная загрузка ВМ, контроль целостности, ограничение программной среды и защита памяти — описаны по исходным текстам хостовой ОС и её сборочных профилей. Страница описывает их устройство и наблюдаемое поведение; подтверждением результатов испытаний она не является. Значения параметров, приведённые как «по умолчанию», взяты из кода и миграций базы и относятся к поставке без изменений, внесённых администратором.
Харденинг
Числовые параметры парольной политики, лимит неудачных попыток и автоархивация журнала приходят со значениями, которые требованиям класса 4 удовлетворяют, — администратор их проверяет и не ослабляет. А вот разделение четырёх ролей по разным учётным записям, оповещения о событиях безопасности и сетевая доступность управляющего слоя конфигурацией по умолчанию не закрыты: это работа администратора. Порядок — в разделе Харденинг.