НТБот 26.8: ролевая модель из 17 прав доступа и секреты платформы в HashiCorp Vault

Вышел релиз НТБот 26.8 — обновление безопасности платформы нагрузочного тестирования. Изменения затрагивают инфраструктурный слой платформы: хранение секретов, модель доступа и защиту служебных компонентов.

Разграничение прав доступа: расширение до 17 прав

Для повышения гибкости доступа к той или иной функциональности платформы пересмотрена ролевая модель. Прежняя модель не позволяла выдать доступ «только на чтение» или отделить того, кто читает журнал аудита, от того, кто управляет платформой.

Теперь доступ собирается из атомарных прав по схеме «ресурс × действие». Действий три: просмотр (видеть ресурс и его список), изменение (создавать, править, удалять) и управление (запуск, контроль исполнения, администрирование). Всего 17 прав:

Ресурс	Просмотр	Изменение	Управление
Проекты	✓	—	✓
Сценарии	✓	✓	✓ (запуск)
Хранилище скриптов	✓	✓	—
Тесты	✓	—	✓ (пауза, остановка, потоки)
SLA	✓	✓	—
Генераторы и эмуляторы	✓	—	✓
Лицензии	✓	—	✓
Журнал аудита	✓	—	—
Пользователи	—	—	✓

Права включаются переключателями в панели администратора, раздел «Роли и права».

Разграничение прав доступа: настройка прав роли по ресурсам в панели администратора НТБот

Из прав собираются роли. В поставке их три: Пользователь (работа со сценариями, скриптами, тестами, SLA и генераторами), Администратор (то же плюс управление проектами, лицензиями и пользователями) и Администратор ИБ — узкая роль с одним правом на чтение журнала аудита, появившегося в релизе 26.7. Право на журнал аудита Администратору намеренно не выдаётся: тот, кто управляет системой, не может незаметно вычистить собственный аудит-след.

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

Секреты платформы в HashiCorp Vault

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

Vault входит в поставку — отдельная инсталляция на стороне заказчика не требуется. Версия 1.21.4, образ собирается офлайн с проверкой контрольной суммы бинарного файла.
Хранилище данных — PostgreSQL, поэтому секреты не теряются при пересоздании контейнера. Режим — одиночный узел: кластер высокой доступности на этом хранилище не поддерживается.
Вход по AppRole с проверкой сертификата Vault по отдельному хранилищу доверенных сертификатов.
Распечатывание — вручную. При инициализации выпускается 5 долей ключа, для распечатывания нужны любые 3. Автоматического распечатывания нет: после рестарта контейнера оператор вводит доли заново, доли между запусками не меняются.
Отказ вместо тихого старта. Если Vault недоступен, запечатан или отвечает отказом по политике, конфигурационный сервис ждёт его 5 минут, а затем останавливается и сообщает причину — вместо запуска с пустыми секретами.

Шифрование и аудит инфраструктурных сервисов

Служебные компоненты платформы — Kafka, MinIO, ZooKeeper и nginx — получили обязательную аутентификацию и шифрование канала TLS 1.2/1.3.

Kafka переведена на SASL_SSL: у каждого сервиса своя служебная учётная запись вместо общей, доступ к топикам разграничен правилами ACL с запретом по умолчанию, обращения журналируются в формате CEF для средств сбора событий безопасности.
MinIO работает по HTTPS, клиенты подключаются через хранилище доверенных сертификатов, вместо администраторского доступа используются сервисные учётные записи с минимальными привилегиями, аудит пишется в Kafka.
ZooKeeper закрыт TLS-шифрованием.
nginx передаёт реальные адреса клиентов в Keycloak, поэтому записи аудита содержат достоверный источник обращения.

Шифрование — серверное: клиентские сертификаты для сервисов не требуются, подлинность клиента подтверждается служебной учётной записью. Серверный сертификат, закрытый ключ и хранилище PKCS12 лежат в одном защищённом каталоге на хосте и монтируются в контейнеры только на чтение. Для продуктивной среды самоподписанный сертификат заменяется выпущенным доверенным удостоверяющим центром — порядок описан в разделе документации «Настройки безопасности».

Обновление с версии 26.7: совместимость и порядок перехода

Обновление выполняется с версии 26.7.
Прежние роли заменяются новыми бесшовно: роли и права создаются автоматически при старте платформы, отдельная миграция учётных записей не нужна.
Обновление требует технологического окна. Установка идёт тремя фазами: инициализация базы данных, пауза с вводом трёх долей ключа Vault, запуск остальных сервисов. До распечатывания Vault сервисы, зависящие от конфигурационного, не поднимаются.
Перед обновлением снимается резервная копия базы данных и проверяется наличие сохранённых долей ключа Vault.
Внешние генераторы нагрузки на отдельных машинах и сторонние получатели данных из Kafka переводятся на SASL_SSL, адрес MinIO меняется с HTTP на HTTPS.

Частые вопросы

Нужно ли разворачивать HashiCorp Vault отдельно? Нет. Vault поставляется в составе платформы и настраивается установочным сценарием.

Что происходит с ролями администратора и пользователя после обновления? Они заменяются новыми ролями бесшовно, доступ пользователей не прерывается.

Требуется ли останавливать платформу при обновлении? Да. Установка проходит в три фазы с паузой на ввод долей ключа Vault, поэтому обновление планируется в технологическое окно.

Можно ли выдать доступ только на просмотр результатов тестов? Да. Роль собирается из прав на просмотр — например, только «Тесты: просмотр» и «Сценарии: просмотр».

Как обновиться

Обновление до версии 26.8 выполняется в рамках сопровождения или внедрения платформы НТБот. Настройка ролей описана в разделе документации «Управление доступом», порядок получения обновлений — в разделе «Обновления и поддержка продукта». Если вы ещё не работаете с НТБот — запросите демонстрацию.

Ещё по теме:

Источник: НТБот