Харденинг

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

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

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

Харденинг

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

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

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

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

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

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

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

Парольная политика. Сверьте длину пароля, допустимый алфавит и лимит попыток с таблицей ниже. Обязательные классы символов — дополнительная политика продукта, а не способ измерить размер алфавита. Настройки можно ослабить. Запрет совпадения пароля с именем пользователя действует всегда. Запрет повторить текущий пароль проверяется при самостоятельной смене; сброс пароля другого пользователя администратором его не проверяет.

Параметры под 4 класс защиты. Требования к средствам виртуализации 4 класса задают длину пароля не меньше 8, алфавит не меньше 70 символов и предел неудачных попыток не больше 4 (п. 17.3 приказа № 187). По умолчанию длина и лимит попыток соответствуют этим числам. Проверьте их после развёртывания и обновления кластера; отдельно настройте оповещения и хранение копий журнала. Окно подсчёта и срок блокировки по 30 минут — значения продукта, а не числа из приказа. Соответствие алгоритма с временным окном требует отдельного обоснования.

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

Параметр	Требование приказа № 187	Настройка / рекомендация продукта	Где задаётся
password_min_length	Не меньше 8	По умолчанию 8; не уменьшайте	Settings → Security policy
Допустимый алфавит пароля	Не меньше 70 символов	Проверьте набор допустимых символов; обязательные типы символов в каждом пароле и размер алфавита — разные свойства	политика паролей и проверка ввода
Требования к составу символов	Обязательные четыре типа не заданы	Оставьте включёнными заглавные и строчные буквы, цифры и специальные символы, как рекомендует руководство пользователя	Settings → Security policy
max_failed_attempts	Не больше 4	По умолчанию 4; не увеличивайте	там же
failed_attempts_window_minutes	Число минут не задано	По умолчанию 30; руководство пользователя требует ненулевое окно	там же
lockout_duration_minutes	Срок устанавливает администратор	По умолчанию 30; 0 — снятие только вручную	там же
Автоархивация журнала	Архивирование при исчерпании места (п. 11.1)	Проверьте, что включена и каталог задан; отдельно организуйте резервную копию	настройки журнала безопасности
Оповещения о событиях безопасности	Оповещение администратора безопасности (п. 11.1)	Задайте почтовый сервер, включите рассылку, задайте получателей и порог важности; по умолчанию рассылка выключена, порог alert. Порядок — ниже, «Почтовые оповещения»	почтовый сервер — файл окружения диспетчера на управляющей ВМ; рассылка — настройки журнала безопасности

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

Почтовые оповещения. Настройки рассылки в интерфейсе сами письма не отправляют: диспетчеру vStack Center нужен адрес SMTP-сервера, а штатное развёртывание управляющей ВМ его не задаёт. Как устроена рассылка и что приходит в письме — в разделе Соответствие ФСТЭК.

1. Подготовьте SMTP-сервер, который принимает письма от управляющей ВМ без аутентификации: логина, пароля и режима шифрования диспетчер не принимает. Исходящие соединения управляющей ВМ по умолчанию не ограничены; если вы их закрыли, откройте порт SMTP-сервера.

2. На управляющей ВМ добавьте параметры в файл окружения диспетчера /usr/local/etc/vstack_center_dispatcher.env:

   SMTP_HOST=192.0.2.25
   SMTP_PORT=25
   SMTP_SEND_FROM=vstack-security@example.com
   SMTP_TIMEOUT=15000

   Параметр	Значение
   SMTP_HOST	Адрес SMTP-сервера. Пустое значение отключает отправку
   SMTP_PORT	Порт, по умолчанию 25
   SMTP_SEND_FROM	Адрес отправителя. Без параметра письма уходят от no-reply@vstack.com, и почтовый сервер организации может не принять письмо от чужого домена
   SMTP_TIMEOUT	Таймаут соединения в миллисекундах, по умолчанию 15000

3. Перезапустите диспетчер: service vstack_center_dispatcher restart.

4. Проверьте лог в каталоге /var/log/vstack-center-dispatcher/. Строка SMTP initialized: host=… значит, что транспорт создан. Строка SMTP_HOST not set — email notifications disabled значит, что диспетчер параметр не прочитал.

5. В интерфейсе откройте Security Event Log → Actions → Notification settings, включите рассылку, добавьте получателей и выберите порог. Сохранить настройки может только Cluster master. Пошагово — в разделе Как настроить письма о событиях журнала безопасности.

Порог по умолчанию alert пропускает только нарушения целостности. Индикатор критических событий в интерфейсе считает три верхних уровня, поэтому при пороге critical письма приходят о тех же событиях, что зажигают индикатор, в том числе о блокировке учётной записи и исчерпании места на диске.

Кнопки пробного письма нет. Доставку проверяйте на событии нужного уровня: при пороге critical заведите тестовую учётную запись и исчерпайте на ней лимит неудачных попыток входа. Блокировка запишется в журнал, и диспетчер отправит письмо. В логе диспетчера на каждого получателя появится email notify: sent to <адрес> или email notify: failed to send to <адрес> с причиной. Строка sent to значит, что письмо принял SMTP-сервер, а не что оно дошло до ящика. После проверки разблокируйте или удалите тестовую учётную запись.

Файл окружения диспетчера генерируется заново при каждом развёртывании конфигурации управляющей ВМ, в том числе при обновлении vStack Center, и строки SMTP_* из него пропадают. После каждого обновления проверяйте строку SMTP initialized в логе диспетчера и при необходимости добавляйте параметры снова.

Архивы журнала хранятся на управляющем узле и могут быть потеряны вместе с ним. Руководство пользователя предписывает перенос на внешнее хранение; настройте его как меру сохранности выбранной реализации. Пункт 13.3 требует резервного копирования событий, но не задаёт единственное место или способ хранения. Одна автоархивация резервную копию не подтверждает.

Для параметров платформы штатный экспорт и автоматизация дампа базы в проверенном коде не найдены. Предусмотрите регламент копирования: состав параметров, расписание, хранение, восстановление и проверку согласованности с ВМ и журналом. Дамп базы управляющего слоя может быть частью такой процедуры; регламент и успешное восстановление проверенными материалами не подтверждены. Само предложение снимать дамп не означает выполнения п. 13.2.

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

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

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

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

В готовящейся линии два отладочных обхода удалены; само затирание памяти по-прежнему выключено по умолчанию. Затирание блоков при удалении набора данных доступно только в выпущенной линии и выполняется синхронно, удлиняя удаление. Возобновление после потери питания проверенными материалами не подтверждено; учтите это в регламенте обслуживания.

Прежде чем включать secure_destroy. Диски виртуальных машин создаются клонированием из образа и могут иметь снимки, то есть делят блоки с другими наборами данных. Сохранность таких общих блоков при удалении набора с включённым свойством проверенными материалами не подтверждена. Перед включением свойства на наборах с дисками ВМ согласуйте его с технической поддержкой vStack и проверьте удаление клона на тестовом пуле: после удаления исходный образ и соседние ВМ должны читаться без ошибок, а zpool scrub — завершаться без ошибок.

Проверьте, что security.mac.veriexec.block_write и security.mac.veriexec.block_rename равны 1. Они задаются из настроек загрузчика; на работающей системе значения не меняются. Нельзя считать оба включёнными во всех сборках: в исходниках новой базовой системы block_write равен 0, хотя руководства называют оба значения включёнными по умолчанию. Фактическое состояние требуется проверить, а при необходимости — задать до перезагрузки.

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

При подключении рабочих мест и серверов к внешним информационным системам руководство администратора (§«Условия эксплуатации») требует также сертифицированных систем обнаружения вторжений и средств межсетевого экранирования. Это условие эксплуатационного комплекта для сертифицируемого применения; внутренние правила Edge его выполнение не подтверждают.