Модуль 9. Безопасность и управление доступом в StarRocks
Методологическое понимание безопасности в StarRocks
StarRocks — это MPP-движок, который может обслуживать сотни BI-пользователей и обрабатывать чувствительные данные (финансовые, персональные, коммерческие).
Поэтому безопасность в StarRocks — это не просто «пароль на пользователя», а комплексная система:
- Аутентификация — кто подключается.
- Авторизация — что он может делать.
- Защита каналов — шифрование и контроль доступа.
- Аудит — кто и какие запросы выполнял.
- Минимизация привилегий — только нужные права, без «god mode» для всех.
Методология:
- Разделяйте роли: администраторы кластера, разработчики витрин, BI-пользователи.
- Ограничивайте доступ к сырому уровню — BI должен работать через Presentation Layer.
- Контролируйте входные точки — подключение к FE, админ-порты, API.
Аутентификация (Authentication)
StarRocks поддерживает несколько методов аутентификации:
-
Парольная аутентификация (по умолчанию)
- Создаём пользователя с логином/паролем.
- Пример:
CREATE USER 'bi_user'@'%' IDENTIFIED BY 'StrongP@ssw0rd';
- % означает, что доступ возможен с любого хоста. Для безопасности указываем конкретные IP или маски.
- LDAP / Active Directory
- Для интеграции с корпоративной аутентификацией.
- Настраивается в конфиге FE:
auth_mode=ldap
ldap_url=ldap://ldap.company.com
ldap_user_dn_pattern=uid={0},ou=users,dc=company,dc=com- Плюс: централизованное управление пользователями.
- Минус: требует стабильной связи с LDAP.
- Kerberos
- Для защищённых кластеров в Hadoop/Lakehouse-средах.
- Работает совместно с TLS.
- Используется в high-security установках (банки, гос).
Авторизация (Authorization) и ролевая модель
StarRocks использует ролевую модель доступа.
1. Роли (Roles)
- Создаём роль:
CREATE ROLE bi_analyst;
- Назначаем права:
GRANT SELECT ON db.sales TO ROLE bi_analyst;
- Привязываем роль пользователю:
GRANT bi_analyst TO 'bi_user'@'%';
2. Права (Privileges)
- Global — на весь кластер (CREATE DATABASE, SHOW, GRANT).
- Database-level — на конкретную БД.
- Table-level — SELECT, INSERT, UPDATE, DELETE.
- Column-level — ограничение по конкретным колонкам.
Шифрование и защита каналов
1. TLS/SSL
- FE/BE поддерживают SSL для JDBC/ODBC.
- Конфиг FE:
enable_ssl=true ssl_certificate=/path/cert.pem ssl_private_key=/path/key.pem
- BI-клиенты подключаются по jdbc:mysql://fe_host:9030/db?useSSL=true.
2. Шифрование данных в покое
- На уровне ОС/дисков (LUKS, BitLocker, EBS encryption).
- StarRocks не шифрует сегменты нативно — используем слой ниже.
3. Kerberos для Hadoop/S3-доступа
- Для защищённых внешних таблиц Iceberg/Hive.
Аудит (Audit Logging)
StarRocks ведёт логи:
- FE logs — кто и когда подключался, какие запросы выполнял.
- Audit logs — можно включить в FE:
enable_audit_log=true audit_log_dir=/var/log/starrocks/audit
- Можно интегрировать с SIEM (Splunk, ELK, Graylog) для анализа активности.
Практические кейсы
Кейс 1. BI в банке
- Проблема: аналитики имели доступ к сырым транзакциям с персональными данными.
-
Решение:
- Создали Presentation Layer без персональных полей.
- BI-пользователи получили SELECT только на Presentation.
- Сырые таблицы доступны только ETL-разработчикам.
- Результат: соответствие требованиям PCI DSS.
Кейс 2. Многотенантный кластер
- Проблема: отдел маркетинга случайно получил доступ к витринам финансов.
-
Решение:
- Ввели роли fin_analyst и mkt_analyst.
- Роли получили доступ только к своим БД.
- Результат: полная изоляция данных.
Кейс 3. Интеграция с AD
- Проблема: 300+ пользователей BI, тяжело управлять паролями.
-
Решение:
- Интеграция с Active Directory.
- Роли в StarRocks маппятся на AD-группы.
- Результат: единая точка управления.
Риски и защита
|
Риск |
Симптом |
Как избежать |
|---|---|---|
|
Доступ «@%» без фильтра IP |
Возможен вход откуда угодно |
Ограничивать IP, VPN |
|
Отсутствие ролевой модели |
BI видит всё |
Роли и разделение зон |
|
Пароли в BI-коннекторах в открытом виде |
Утечка конфигурации |
Vault/Secret Manager |
|
Нет аудита |
Неизвестно, кто что делал |
Включить audit log |
|
Нет TLS |
Данные передаются в открытом виде |
Обязательное шифрование |
Методологические рекомендации
- Zero Trust — никто не имеет лишних прав, даже админы.
- Роли вместо прямых прав — проще управлять и отозвать.
- Изоляция окружений — dev/test/prod на разных кластерах или схемах.
- Мониторинг и аудит — подключение к SIEM.
- Регулярный пересмотр прав — минимум раз в квартал.
