Статья

Управление пользователями и безопасностью

2026-05-25 14:30 Новые
Управление безопасностью охватывает множество аспектов: от контроля доступа к данным на разных уровнях до аудита действий и интеграции с корпоративными политиками идентификации.
В современном подходе к управлению безопасностью встречается термин S3 2.0 Security - концепция, которая описывает преодоление разрозненного подхода к безопасности, характерного для устаревших систем, и переход к целостной, многоуровневой модели защиты. В этой статье рассматривается, как StarRocks реализует управление пользователями и безопасность в соответствии с современными требованиями.

Модель безопасности и разграничение доступа

Модель безопасности StarRocks базируется на детальном разграничении доступа к различным объектам системы. Она поддерживает широкий спектр уровней, от глобального до колоночного.
Уровни объектов и привилегии
StarRorks позволяет предоставлять доступ на разных уровнях объектов и гибко управлять привилегиями.
Встроенная иерархия объектов (Object Hierarchy):
  1. SYSTEM: высший уровень, включающий операции с плагинами, файлами, правами на управление и т.д.
  2. RESOURCE GROUP / RESOURCE / STORAGE VOLUME: для управления вычислительными и внешними ресурсами
  3. CATALOG: для работы с внешними каталогами данных
  4. DATABASE
  5. TABLE, VIEW, MATERIALIZED VIEW, FUNCTION, PIPE: детальная настройка доступа к данным и объектам внутри БД
  6. USER: управление возможностью создания "impersonation"
  7. COLUMN: доступ на уровне отдельных колонок таблицы (см. ниже)
Фундаментальным принципом безопасности StarRocks является поддержка гибридной модели: Role-Based Access Control (RBAC) и Identity-Based Access Control (IBAC).
  • IBAC позволяет предоставлять права напрямую конкретному пользователю.
  • RBAC предполагает создание ролей — именованных наборов прав, которые затем назначаются пользователям. Это упрощает администрирование при большом числе пользователей.
  • Ключевая особенность — ролевая иерархия (Role Hierarchy). Одна роль может быть вложена в другую, поэтому дочерняя роль наследует права родительской.
  • Политики и маскирование
  • Создание политик для маскирования колонок (CREATE MASKING POLICY) и политик доступа к строкам (CREATE ROW ACCESS POLICY) доступно только в Enterprise-версии.
  • В Open Source-версии StarRocks v3.x эти политики не поддерживаются; разделение обычно происходит через создание нескольких представлений (VIEW), каждое с разным проекционным списком и условием фильтрации, и предоставление прав SELECT на эти представления.
  • Ресурсы (Resources) и каталоги (Catalogs)
  • Существует отдельный объект RESOURCE, на который можно выдать право USAGE_PRIV для возможности его использования.
  • Для федеративных запросов через внешние каталоги (Hive, Iceberg и т.д.) следует использовать права CATALOG (USAGE, DROP, ALTER, CREATE DATABASE) и соответствующие права уровня TABLE.

Управление пользователями и разграничением доступа

Все операции с пользователями, ролями и правами выполняются с помощью SQL-команд, что ставит управление на уровень работы с данными. Система использует концепцию "user identity": 'username'@'userhost' (например, 'analyst'@'192.168.1.%'), по которому пользователь однозначно идентифицируется.
Действие (Operation)
Необходимое право (Required Permission)
Создание / удаление пользователя, создание / удаление роли
ADMIN на любом уровне
Изменение чужого пароля
ADMIN
Изменение своего пароля
любой аутентифицированный пользователь
Предоставление (GRANT) / отзыв (REVOKE) прав
ADMIN, или GRANT на соответствующем уровне (global/database/table)
Предоставление прав с правом делегировать (WITH GRANT OPTION)
требуется ADMIN
Управление ролями
Помимо пользовательских ролей, StarRocks предоставляет пять системных (Built-in) ролей для типовых сценариев администрирования:
  • cluster_admin: управление инфраструктурой кластера (добавление/удаление узлов)
  • db_admin: полное управление данными (создание/удаление БД и таблиц, полный CRUD)
  • user_admin: управление пользователями, ролями и предоставлением прав
  • security_admin: управление интеграциями с внешними системами безопасности (LDAP, JWT, OAuth 2.0)
  • public: назначается всем пользователям по умолчанию и обычно не содержит специальных привилегий.
При создании пользователя через CREATE USER можно сразу назначить ему роль по умолчанию с помощью параметра DEFAULT ROLE. Включенная настройка activate_all_roles_on_login = TRUE приведет к автоматической активации всех ролей пользователя при входе.

Средства мониторинга безопасности и аудит действий

StarRocks не имеет встроенного графического интерфейса для аудита безопасности, но предоставляет мощные низкоуровневые механизмы для его организации.
Журнал аудита действий пользователя: fe.audit.log
Это основной журнал аудита безопасности, который детально фиксирует все SQL-запросы:
  • Местоположение: файл fe/log/fe.audit.log на нодах Frontend, куда записываются все действия.
  • Содержимое: время запроса, clientIp, user, db, полный текст stmt, state (EOF, ERR, OK), errorCode, queryTime (ms), scanRows и другие параметры.
  • Анализ сбоев: поле errorCode и state фиксирует неуспешные попытки подключения (например, неверный пароль или отсутствие прав) и выборки из неразрешённых таблиц (ошибка будет иметь код, например, 1045 для отказа в доступе).
Продвинутые средства анализа логов
Встроенного графического интерфейса для аудита безопасности нет, но централизованный анализ логов можно организовать несколькими способами:
  1. Использовать плагин AuditLoader: он загружает записи из fe.audit.log в обычную таблицу StarRocks, позволяя анализировать их с помощью SQL для быстрого поиска подозрительных действий.
  2. Интегрировать логи с системами класса SIEM (например, Splunk, ELK) для построения дашбордов активностей пользователя и выявления аномалий.
  3. Создать таблицу для Big Query Logs: если анализировать fe.audit.log напрямую неудобно, можно настроить AuditLoader и загружать события в патиционированную таблицу и строить отчетность SQL-запросами.
Дополнительные инструменты контроля
  • SHOW PROCESSLIST и information_schema.processlist: отображают выполняемые запросы и их владельцев.
  • information_schema.column_privileges: системное представление, по которому можно отслеживать, кому и какие колоночные права были предоставлены.
  • information_schema.tables и role_privileges: для мониторинга доступа к объектам схемы данных.

Аутентификация и авторизация доступа

Аутентификация: проверка подлинности
StarRocks поддерживает несколько механизмов аутентификации. Конкретный набор возможностей зависит от версии и выбранного способа интеграции:
  1. Аутентификация по паролю: самый простой встроенный способ, где пароль хранится в хэшированном виде.
  2. LDAP-аутентификация: позволяет аутентифицировать пользователей во внешнем LDAP-сервере (например, Active Directory).
  3. JWT (JSON Web Token) и OAuth 2.0: для интеграции с внешними identity provider и современных сценариев доступа.
  4. Kerberos-аутентификация: централизованная служба, используемая в высокозащищенных средах с корпоративной политикой безопасности.
Команда SHOW AUTHENTICATION FOR user отображает метод и детали аутентификации выбранного пользователя.
Авторизация: контроль доступа
После аутентификации пользователь авторизуется. StarRocks управляет правами (Privileges), такими как:
  • Полный спектр: ALL, ALTER, DROP, INSERT, DELETE, SELECT, UPDATE, EXPORT и другие.
  • WITH GRANT OPTION: делегирование права пользователь может давать другим.
  • USAGE_PRIV: разрешение использовать объект типа RESOURCE.
Механизмы превентивной защиты: SQL Blacklist
Для предотвращения выполнения нежелательных или небезопасных запросов StarRocks предлагает механизм "SQL-блоклистов":
  • Принцип работы: администратор может добавить один или несколько SQL-блоклистов в виде регулярных выражений (ADD SQLBLACKLIST). Когда механизм enable_sql_blacklist включен, каждый входящий SQL-запрос проверяется на соответствие блоклисту. При совпадении — запрос не выполняется и возвращается ошибка.
  • Пример использования: например, можно запретить любые запросы типа DROP TABLE, добавив соответствующий паттерн.

Администрирование безопасности: управление и настройка

Настройка безопасности — это комплексный процесс, который включает несколько этапов.
Концепция S3 2.0 Security: централизованное и каталог-ориентированное управление
StarRocks предлагает современную схему безопасности:
  1. Многоуровневый и целостный подход: централизованное создание единых политик безопасности и их применение ко всем вычислительным движкам, работающим с данными в различных форматах (Iceberg, Hudi, Delta Lake).
  2. Интеграция с Apache Ranger (Security Integration): поддерживается Security Integration для авторизации (authorization) через Apache Ranger при работе с Enterprise версией StarRocks 3.3 для централизованного управления доступом к данным на различных платформах.
  3. Защита данных с многофакторной аутентификацией (MFA): можно настраивать Group Provider для интеграции с внешними группами пользователей из LDAP / Active Directory и последующей авторизации через Apache Ranger.
  4. Как применять на практике: определить схему безопасности, создать security_admin и провести конфигурацию:
sql
-- (1) Создание безопасности-админа (примените принцип наименьших привилегий!)
CREATE USER 'security_admin'@'%' IDENTIFIED BY 'strong_password';
GRANT security_admin TO USER 'security_admin'@'%';
-- (2) Создайте Security Integration для аутентификации
CREATE SECURITY INTEGRATION my_ldap_auth
PROPERTIES (
"type" = "authentication_ldap_simple",
"authentication_ldap_simple_server_host" = "ldap.company.com",
"authentication_ldap_simple_server_port" = "389"
);
  • Парольная политика: используйте настройки паролей, например, время жизни пароля (PASSWORD EXPIRE).
  • Безопасное управление пользователями: наделяйте системными ролями только по необходимости: db_admin для дата-инженеров, user_admin для администраторов пользователей, никогда cluster_admin.
  • Защита сети (Network Security): используйте белые списки (Whitelisting) в userhost, ограничивая доступ только с доверенных IP-адресов.
  • Шифрование данных в хранилище (Encryption at Rest): для external storage и lakehouse-сценариев используйте возможности шифрования выбранного объектного хранилища, например server-side encryption с KMS в S3-совместимой инфраструктуре.
  • Шифрование передачи данных (Encryption in Transit): активируйте SSL-шифрование трафика между клиентами и сервером StarRocks для защиты от перехвата。

Заключение

Система безопасности StarRocks — это многогранный механизм, который требует ответственного подхода от администратора. Ключом к безопасной работе является сочетание нескольких мер:
  1. Правильное проектирование политик разграничения доступа, вплоть до уровня колонок.
  2. Регулярный аудит всех действий пользователей с помощью журнала fe.audit.log и системы централизованного логирования.
  3. Применение современных методов аутентификации (LDAP, Kerberos, JWT) и их интеграция с корпоративной инфраструктурой.
  4. Использование системных ролей и механизма делегирования прав (WITH GRANT OPTION) для безопасного и масштабируемого администрирования.