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

Доступ к кластеру проходит через HTTPS-endpoint кластера с сессиями на основе cookie и криптографической подписью запросов. Управляющий слой — единственная точка входа: агенты узлов и контроллер хранилища не принимают запросы клиентов напрямую.

Разграничение прав строится на привилегиях с областью действия (scope), а не на «номерах ролей». Роль — это именованный набор привилегий, и проверка идёт не по роли, а по конкретной привилегии, требуемой методом.

Из чего состоит модель. Объектный слой описывает привилегии, соответствие методов привилегиям, состав ролей, назначение ролей пользователям и область действия назначения. Авторизация каждого вызова выполняется единой функцией, которая проверяет и наличие привилегии, и её область действия.

Области действия. Привилегия может действовать на весь кластер, на конкретный ВЦОД (виртуальный центр обработки данных) либо на объекты, созданные самим пользователем. Последнее — самостоятельное измерение: администратор ВЦОД видит и меняет собственные сети и Edge-маршрутизаторы даже за пределами области действия своего ВЦОД. Для собственных объектов заведён отдельный набор привилегий вида Own, чтобы «своё» и «любое в ВЦОД» не смешивались.

Фиксированные и кастомные роли. Фиксированных ролей семь. Четыре из них отвечают четырём ролям, которых требует ролевой метод управления доступом в средстве виртуализации: Cluster Master — администратор средства виртуализации, Security Admin — администратор безопасности, VM Developer — разработчик ВМ, vDC User — администратор ВМ. Остальные три — vDC Admin, vDC Viewer и Resource Viewer — к требованиям не привязаны и закрывают повседневные задачи. Полный список с областями действия — в справочнике Роли и привилегии, сопоставление с требованиями — в разделе Соответствие ФСТЭК. Роли, поставляемые с продуктом, защищены от изменения и удаления через API. Кастомные роли создаются отдельными методами, доступными только роли Cluster master, и нумеруются из отдельного диапазона — по нему платформа отличает их от фиксированных. Привилегии управления ролями кастомной роли не выдаются: иначе роль смогла бы расширить сама себя.

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

Регистрация действий. Действия над объектами кластера пишутся в журнал событий безопасности с хеш-цепочкой записей, что позволяет обнаружить постороннее вмешательство в журнал. Модель записи, состав полей и проверка целостности описаны в разделе Журнал безопасности.

Соответствие

Требование	Как закрыто
Аутентификация доступа	Сессии на основе cookie с криптографической подписью запросов; настраиваемая парольная политика с запретом повторить текущий пароль
Разграничение доступа	Привилегии с областью действия на уровне кластера, ВЦОД и собственных объектов; авторизация каждого вызова единой функцией
Разделение полномочий	Отдельные роли для аудита событий безопасности и для разработки конфигураций ВМ без права их запуска
Защита настроек разграничения	Фиксированные роли неизменяемы через API; управление ролями недоступно кастомным ролям
Регистрация событий безопасности	Журнал с хеш-цепочкой записей и проверкой целостности

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

Харденинг

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