Харденинг

Модель безопасности

Харденинг vStack Center — это сужение поверхности доступа управляющего слоя и выдача минимально необходимых прав пользователям. Продукт даёт средства разграничения, но безопасной конфигурации по умолчанию не предполагает: набор ролей, область их действия и сетевую доступность определяет администратор.

Устройство самой модели — привилегии, области действия, защита фиксированных ролей — описано в разделе Модель безопасности.

Харденинг

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

Наименьшие права. Выдавайте привилегии по принципу наименьших прав и всегда задавайте точную область действия. Назначение роли без ограничения областью делает права кластерными, даже если задача пользователя ограничена одним ВЦОД. Для доступа к собственным объектам пользователя используйте привилегии вида Own, а не полные привилегии на ВЦОД.

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

Отдельная роль для аудита. Для разбора событий безопасности назначайте роль администратора безопасности, а не роль Cluster master. Она даёт просмотр, фильтрацию, экспорт журнала и проверку целостности, но не даёт управлять ВМ, сетями, пользователями и инфраструктурой — то есть аудитор не может изменить то, что проверяет.

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

Ограничение выгрузки журнала. Просмотр и экспорт журнала безопасности управляются отдельными привилегиями. Держите их только у роли Cluster master и у администратора безопасности: выгрузка журнала — это полный след действий всех пользователей кластера.

Проверка целостности. Периодически запускайте проверку хеш-цепочки журнала и читайте её статус. Порядок и методы описаны в разделе Журнал безопасности.

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

Параметры под 4 класс защиты. Требования к средствам виртуализации 4 класса задают часть параметров числом. Политика входа и архивация журнала приходят со значениями, которые этим числам удовлетворяют, поэтому работа администратора здесь — не выставить их, а не ослабить: проверить после развёртывания и ещё раз после обновления кластера. Оповещения — единственное, что придётся включить самому.

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

Параметр	Значение под класс 4	Где задаётся
password_min_length	не меньше 8	Settings → Security policy
Требования к составу символов	все четыре включены	там же, четыре тумблера
max_failed_attempts	не больше 4	там же
lockout_duration_minutes	срок снятия блокировки или 0 для снятия только вручную	там же
Автоархивация журнала	включена, каталог хранения задан	настройки журнала безопасности
Оповещения о событиях безопасности	включены, получатели заданы, порог важности выбран	там же; по умолчанию рассылка выключена

Четыре требуемых роли разведите по разным учётным записям. Совмещение роли администратора безопасности с ролью мастера кластера в одном пользователе обнуляет смысл разделения: аудитор получает права менять то, что проверяет. Подробности сопоставления ролей — в разделе Соответствие ФСТЭК.

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

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

Настройки узла под класс 4. Часть требований класса закрывается механизмами хостовой ОС, и три из них в поставке выключены. В интерфейсе vStack Center они не отражаются, поэтому проверять и включать их приходится на узле.

Механизм	Требование	Состояние в поставке
hw.vmm.safe_exit	Очистка остаточной информации в памяти при её освобождении: затирание памяти гостя при уничтожении ВМ	Выключено, значение 0. Включается установкой в 1, но на текущей линии сборки вместе с затиранием включается отладочная обвязка — см. предупреждение ниже
Свойство набора данных secure_destroy	Удаление объектов файловой системы перезаписью	Выключено. Включается на наборах данных, где лежат диски ВМ, и наследуется дочерними
kern.elf64.allow_wx	Размещение кода вне области, доступной одновременно для записи и исполнения	Значение 0 приходит файлом настроек только с сертифицируемым контуром сборки. В обычной сборке режим разрешительный

Подсистему контроля целостности узла нужно привести в рабочее состояние вручную: собрать манифест, загрузить его в ядро, включить проверку, перевести в режим блокировки и запретить загрузку новых манифестов. Автоматически это не происходит: путь через загрузчик в базовой системе есть, но подписанный манифест загрузки в поставку не собирается, и ни установочный overlay, ни стартовые скрипты сборку манифеста не запускают. Ожидаемое состояние после настройки — «загружена, включена, применяется, загрузка новых манифестов запрещена»; проверяйте его после каждого обновления узла, потому что обновление меняет файлы, попавшие в манифест.

Прежде чем включать затирание памяти, прочтите это. На текущей линии сборки затирание памяти гостя идёт в паре с отладочной обвязкой, которая скомпилирована безусловно. При hw.vmm.safe_exit=1 уничтожение каждой ВМ выполняет два полных прохода по памяти гостя в поисках фиксированного тестового образца — до затирания и после — и печатает в журнал ядра границы областей памяти, включая адреса в адресном пространстве ядра. К стоимости самого затирания это добавляет два обхода всей памяти машины и заметный объём записей в журнал. Обвязка предусмотрена для проверки механизма на стенде; на узлах с ВМ в сотни гигабайт включать затирание без предварительного замера задержки уничтожения не стоит. Замеров на больших ВМ в проекте не делалось.

Затирание при удалении набора данных выполняется синхронно и на больших наборах удлиняет удаление; продолжения с места остановки после потери питания нет. Это стоит учесть в регламенте обслуживания, а не выяснять на первом удалении крупного диска.

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

Удалённый доступ пользователей через сети связи общего пользования требует средств криптографической защиты, прошедших оценку соответствия. В состав платформы они не входят: канал до HTTPS-endpoint кластера защищается отдельно развёрнутым средством.