Перейти к основному содержимому

Настройки безопасности

Аутентификацию и авторизацию в Apache Superset обеспечивает Flask AppBuilder (FAB) — фреймворк разработки приложений поверх Flask. FAB предоставляет аутентификацию, управление пользователями, разрешения и роли. Прочитайте его документацию по безопасности — большинство концепций на этой странице ссылаются на примитивы FAB.

Реализация в Liteset

Liteset портирует security-поверхность FAB в AsyncSecurityManager, работающий на Litestar/ASGI. Конфигурационная поверхность идентична Apache Superset:

  • Те же ключи AUTH_TYPE, AUTH_USER_REGISTRATION, AUTH_ROLES_*, OAUTH_PROVIDERS, LDAP_* в superset_config.py.
  • Те же таблицы ab_user, ab_role, ab_permission_view, ab_user_role в БД метаданных (без изменений схемы).
  • Тот же формат Flask-подписанной session-cookie (декодируется в Liteset нативно) и тот же заголовок X-CSRFToken — сессии переживают миграцию.
  • Подклассы SupersetSecurityManager, написанные для Apache Superset, продолжают работать — но методы, которые в Liteset асинхронные (oauth_user_info, add_user, update_user_auth_stat, find_user, …), должны быть async def-оверрайдами при наследовании от AsyncSecurityManager Liteset. Если нужен синхронный код из сторонней библиотеки — оборачивайте через await asyncio.to_thread(...).

Когда страница ссылается на flask_appbuilder.security.manager.AUTH_OAUTH и подобное — те же константы реэкспортированы из superset.security для удобства, а ссылки на документацию Apache Superset остаются авторитетными для деталей поведения.

Стандартные роли​

Liteset поставляется с набором ролей, которыми управляет сам Liteset. Можно полагать, что эти роли остаются актуальными по мере развития Superset/Liteset (и при обновлении версий).

Хотя у пользователей Admin есть техническая возможность, не рекомендуется менять разрешения, связанные с этими ролями (например, удалять или добавлять разрешения). При выполнении команды superset init (часто используется при обновлении версий) разрешения каждой роли будут пересинхронизированы со стандартными значениями.

Таблицу разрешений по этим ролям см. в /RESOURCES/STANDARD_ROLES.md.

Admin​

У админов все возможные права, включая выдачу/отзыв прав другим пользователям и редактирование чужих чартов и дашбордов.

Alpha​

Alpha имеют доступ ко всем источникам данных, но не могут давать/отзывать доступ другим. Также они ограничены редактированием только своих объектов. Могут добавлять и менять источники данных.

Gamma​

Gamma имеют ограниченный доступ. Они видят данные только из источников, к которым им явно дали доступ через дополнительную роль. Видят только чарты и дашборды, построенные на доступных им источниках. Не могут менять или добавлять источники данных. Считается, что они скорее потребители контента, хотя могут создавать чарты и дашборды.

В списках чартов и дашбордов Gamma видят только то, к чему у них есть доступ.

sql_lab​

Роль sql_lab даёт доступ к SQL Lab. Admin имеют доступ ко всем БД по умолчанию, Alpha и Gamma — нужно давать доступ к каждой БД отдельно.

Public​

Чтобы дать незалогиненным пользователям доступ к части функций — используйте PUBLIC_ROLE_LIKE и присвойте ему роль, чьи разрешения вы хотите распространить на public.

Например, PUBLIC_ROLE_LIKE = "Gamma" в superset_config.py даст public-роли тот же набор разрешений, что и у Gamma. Это полезно, чтобы анонимные пользователи могли смотреть дашборды. Явное предоставление прав на конкретные датасеты всё равно нужно — отредактируйте роль Public и добавьте к ней публичные источники данных вручную.

Управление доступом к источникам данных для роли Gamma​

Как дать пользователям доступ только к определённым датасетам:

  1. Назначьте пользователям с ограниченным доступом только роль Gamma.
  2. Создайте новую роль (Menu → Security → List Roles → нажмите «+»).

В новом окне задайте имя роли, привяжите пользователей и выберите таблицы в выпадающем списке Permissions. Используйте автодополнение, чтобы быстро найти нужные таблицы.

Затем подтвердите у пользователей с ролью Gamma, что они видят объекты (дашборды и чарты), связанные с теми таблицами, к которым вы расширили им доступ.

Соображения безопасности при выполнении SQL​

Apache Superset включает фичи, повышающие безопасность взаимодействия с подключёнными БД, например DISALLOWED_SQL_FUNCTIONS. Цель — предотвратить выполнение потенциально опасных функций БД или системных переменных через интерфейсы вроде SQL Lab.

Однако важно понимать:

Liteset/Superset — не файрвол БД. Встроенные проверки (типа DISALLOWED_SQL_FUNCTIONS) — слой защиты, но не гарантируют 100%-ю защиту от всех угроз уровня БД и продвинутых байпас-техник (например, специфические injection через комментарии). Это дополнение, а не замена надёжной безопасности на уровне БД.

Конфигурация — ключ. Эффективность защиты Liteset сильно зависит от грамотной конфигурации администратором: поддержание DISALLOWED_SQL_FUNCTIONS, аккуратное управление feature flags (ENABLE_TEMPLATE_PROCESSING), настройка прочих параметров безопасности.

Безопасность БД — главное. Окончательная ответственность за защиту доступа к БД, контроль разрешений и предотвращение несанкционированного выполнения функций лежит на DBA и команде безопасности, управляющих самой БД.

Рекомендуемые практики на уровне БД:

  • Принцип минимальных привилегий: Liteset подключается к БД через выделенные учётные записи с минимально необходимыми правами (обычно — read-only к нужным схемам/таблицам).
  • Database Roles & Permissions: используйте нативные роли БД для ограничения доступа к чувствительным функциям, системным переменным (@@hostname), схемам, таблицам.
  • Сетевая безопасность: file/network firewall, прокси для ограничения подключений.
  • Аудит: включайте аудит на уровне БД для мониторинга запросов и доступа.

Сочетание встроенной защиты Liteset с надёжной безопасностью БД даёт более устойчивый и многослойный security posture.

REST API для управления пользователями и ролями​

Flask-AppBuilder поддерживает REST API для CRUD пользователей. Эта фича находится в beta и не включена в Liteset по умолчанию. Включить:

FAB_ADD_SECURITY_API = True

После включения в Swagger станут видны дополнительные endpoint'ы Security.

Кастомизация разрешений​

Разрешения, выставляемые FAB, очень гранулярны и позволяют тонкую кастомизацию. FAB автоматически создаёт множество разрешений для каждой модели (can_add, can_delete, can_show, can_edit, ...) и для каждой view. Кроме того, Liteset выставляет более гранулярные разрешения вроде all_datasource_access.

Не рекомендуется менять три базовые роли — Liteset построен на ряде допущений о них. Создавайте свои роли и объединяйте их со стандартными.

Permissions​

Роли — это набор разрешений, и Liteset делит их на категории:

  • Model & Action: модели — это сущности типа Dashboard, Slice, User. У каждой модели фиксированный набор разрешений — can_edit, can_show, can_delete, can_list, can_add и т. д. Например, чтобы разрешить пользователю удалять дашборды — добавьте can_delete для Dashboard в его роль.
  • Views: views — это конкретные веб-страницы, например Explore или SQL Lab. При выдаче — пользователь увидит соответствующий пункт меню и сможет открыть страницу.
  • Data source: для каждого источника данных создаётся разрешение. Без all_datasource_access пользователь видит только разрешённые ему источники.
  • Database: доступ к БД даёт доступ ко всем источникам данных в этой БД и возможность писать запросы в SQL Lab (если у пользователя есть соответствующее разрешение).

Ограничение доступа к подмножеству источников данных​

Рекомендуется давать пользователю роль Gamma плюс другие роли, открывающие конкретные источники. Создавайте отдельные роли под каждый профиль доступа. Например, у команды Finance свой набор БД и источников — соберите эти разрешения в одну роль. Пользователю назначается Gamma как фундамент моделей и views, плюс Finance — как набор разрешений на конкретные данные.

У пользователя может быть несколько ролей. Например, executive из Finance может иметь Gamma, Finance и Executive. Executive даёт доступ к источникам и дашбордам только для руководства. В Dashboards пользователь увидит только то, к чему у него есть доступ.

Row Level Security​

Через фильтры Row Level Security (меню Security) можно создавать фильтры, привязанные к конкретной таблице и набору ролей. Например, чтобы Finance видел только строки с department = "finance":

  • Создайте RLS-фильтр с условием department = "finance".
  • Привяжите его к роли Finance и нужной таблице.

Поле clause содержит произвольный текст, который добавляется в WHERE сгенерированного SQL. Можно сделать фильтр «последние 30 дней» — date_field > DATE_SUB(NOW(), INTERVAL 30 DAY). Поддерживаются составные условия — client_id = 6 AND advertiser="foo".

Все применимые RLS-фильтры комбинируются (под капотом — через AND). Это значит, что можно случайно создать ситуацию, когда роли друг другу противоречат и вырезают данные в пустоту.

Например, фильтры client_id=4 и client_id=5 на одной роли дадут запросы с client_id=4 AND client_id=5 — это всегда false.

Пользовательские сессии​

Apache Superset использует Flask и Flask-Login для управления сессиями. Liteset декодирует Flask-подписанную session-cookie нативно — из-за этого формат, ключи и поведение совместимы 1:1.

Session-cookie хранят информацию о сессии и состояние пользователя между запросами. Они не содержат личных данных, но идентифицируют сессию на сервере. Cookie зашифрована SECRET_KEY приложения и не читается клиентом. Поэтому очень важно держать SECRET_KEY в секрете и сделать его сложным, уникальным и случайным.

Конфигурация поведения сессий (читается из superset_config.py):

  • SESSION_COOKIE_HTTPONLY (по умолчанию False): ставить ли флаг HttpOnly на cookie.
  • SESSION_COOKIE_SECURE (по умолчанию False): браузер отправляет cookie только по HTTPS, если флаг secure установлен. Приложение должно работать по HTTPS.
  • SESSION_COOKIE_SAMESITE (по умолчанию Lax): запрещает отправку cookie с cross-site запросами.
  • PERMANENT_SESSION_LIFETIME (по умолчанию 31 day): время жизни постоянной сессии (datetime.timedelta).

Переключение на server-side сессии​

Server-side сессии безопаснее и эффективнее client-side. При server-side данные сессии хранятся на сервере, а клиенту отправляется только session ID. На стороне клиента — cookie с session ID; на каждом запросе сервер достаёт по нему данные сессии. При логауте сессия уничтожается на сервере и cookie удаляется на клиенте. Это снижает риск replay-атак и hijacking сессий.

Apache Superset использует Flask-Session. Liteset реализует ту же семантику через свою async-обёртку. Включить:

SESSION_SERVER_SIDE = True

Flask-Session предлагает несколько backend'ов; пример с Redis:

from redis import Redis

SESSION_TYPE = "redis"
SESSION_REDIS = Redis(host="redis", port=6379, db=0)
# подписывать sid в session-cookie
SESSION_USE_SIGNER = True

Content Security Policy (CSP)​

Apache Superset использует Talisman для реализации Content Security Policy (CSP) — дополнительного слоя безопасности против XSS и data injection. Liteset реализует то же поведение через Litestar-middleware, читающий TALISMAN_ENABLED и TALISMAN_CONFIG из superset_config.py.

CSP позволяет администратору сократить или устранить векторы XSS, указав домены, которые браузер должен считать валидными источниками исполняемых скриптов. Браузер с поддержкой CSP выполнит только скрипты из source-файлов с разрешённых доменов, игнорируя все остальные (включая inline-скрипты и обработчики событий в HTML).

CSP описывается набором директив, каждая описывает политику для определённого типа ресурса. Список директив — здесь.

Очень важно правильно сконфигурировать CSP при деплое Liteset — это предотвращает многие виды атак. В config.py есть две переменные:

  • TALISMAN_ENABLED (по умолчанию True): отключите (False), чтобы выключить CSP.
  • TALISMAN_CONFIG содержит само определение политики (см. пример ниже) и любые другие аргументы middleware.

В production-режиме Liteset на старте проверяет наличие CSP. Если CSP не найден — выдаст предупреждение о рисках. В окружениях, где CSP управляется внешним софтом, отключите предупреждение через CONTENT_SECURITY_POLICY_WARNING в config.py.

Требования к CSP​

  • Liteset требует директиву style-src 'unsafe-inline':

    style-src 'self' 'unsafe-inline'

  • Загружаются и выполняются только скрипты, помеченные nonce. Nonce — случайная строка, генерируемая Talisman/middleware на каждый рендер страницы. Получить текущий nonce из jinja-шаблона: csp_nonce().

    <script nonce="{{ csp_nonce() }}">
    /* my script */
    </script>

  • Некоторые дашборды загружают изображения через data-URI — нужно data: в img-src:

    img-src 'self' data:

  • MapBox-чарты используют workers и подключаются к серверам MapBox — добавьте к Liteset-origin:

    worker-src 'self' blob:
    connect-src 'self' https://api.mapbox.com https://events.mapbox.com

  • Cartodiagram-чарты запрашивают карту (картинку и json) из внешних источников, редактируемых пользователями — нужен список разрешённых доменов или wildcard '*' в img-src и connect-src.

  • Остальные директивы CSP по умолчанию 'self' — ограничивают контент тем же origin, что и Liteset.

Для адаптации CSP — следуйте инструкциям и примерам из Content Security Policy Reference.

Прочие соображения по Talisman​

TALISMAN_ENABLED = True запускает защиту с дефолтными аргументами, среди которых content_security_policy — лишь один. Остальные — в документации Talisman, секция Options. Они в целом улучшают безопасность, но администраторам стоит знать об их наличии.

В частности, force_https = True (по умолчанию False) может сломать Alerts & Reports в Liteset, если воркеры обращаются к чартам по WEBDRIVER_BASEURL, начинающемуся с http://. Если HTTPS у вас обеспечивается upstream'ом (балансировщиком/application gateway) — оставьте force_https = False. Иначе включите:

TALISMAN_CONFIG = {
    "force_https": True,
    "content_security_policy": { ...

Конфигурация Talisman​

Параметры можно менять в superset_config.py. Если нужно скорректировать политики — переопределите дефолт.

Пример: разрешить загрузку изображений из S3 или других внешних источников:

TALISMAN_CONFIG = {
    "content_security_policy": {
        "base-uri": ["'self'"],
        "default-src": ["'self'"],
        "img-src": [
            "'self'",
            "blob:",
            "data:",
            "https://apachesuperset.gateway.scarf.sh",
            "https://static.scarf.sh/",
            # "https://cdn.brandfolder.io", # раскомментируйте, если SLACK_ENABLE_AVATARS=True
            "ows.terrestris.de",
            "aws.s3.com", # добавьте свой S3-bucket или внешний источник
        ],
        "worker-src": ["'self'", "blob:"],
        "connect-src": [
            "'self'",
            "https://api.mapbox.com",
            "https://events.mapbox.com",
        ],
        "object-src": "'none'",
        "style-src": [
            "'self'",
            "'unsafe-inline'",
        ],
        "script-src": ["'self'", "'strict-dynamic'"],
    },
    "content_security_policy_nonce_in": ["script-src"],
    "force_https": False,
    "session_cookie_secure": False,
}

Подробнее о настройке — /docs/configuration/networking-settings#changing-flask-talisman-csp.

Сообщение об уязвимостях безопасности​

См. процесс репортинга для Liteset:

  • Уязвимости в Liteset-специфичном коде (async runtime, AsyncSecurityManager, кастомные middleware) — через GitHub Security Advisories Liteset.
  • Уязвимости в коде upstream Apache Superset, который Liteset переиспользует (фронтенд, движок чартов, SQL-парсер, FAB-производная auth-логика) — через private@superset.apache.org. Liteset подтянет фикс на следующем синке.

В обоих случаях соблюдайте принципы responsible disclosure: не публикуйте проблему до выпуска фикса.