跳到主要内容
版本 下一

保护您的 Superset 生产环境安装

本指南适用于 Apache Superset 4.0 及更高版本，是管理员应根据其特定部署架构进行调整的一系列最佳实践。

默认的 Apache Superset 配置是为易用性和开发而优化的，并非为安全性。对于任何生产部署，至关重要的是，您需审阅并应用以下安全配置，以强化您的实例，保护用户数据，并防止未经授权的访问。

本指南提供了一份全面的基本安全配置和最佳实践清单。

关键先决条件：HTTPS/TLS 配置​

在没有 HTTPS (TLS) 的情况下运行 Superset 是不安全的。没有它，所有网络流量（包括用户凭据、会话令牌和敏感数据）都会以明文形式发送，并且可以轻易被截获。

  • 使用反向代理：您的 Superset 实例应始终部署在配置为处理 HTTPS 终止的反向代理（例如 Nginx、Traefik）或负载均衡器（例如 AWS ALB、Google Cloud Load Balancer）之后。
  • 强制执行现代 TLS：配置您的代理以强制执行 TLS 1.2 或更高版本，并使用强大的、行业标准的密码套件。
  • 实施 HSTS：使用 HTTP Strict Transport Security (HSTS) 标头，确保浏览器仅通过 HTTPS 连接到您的 Superset 实例。这可以在您的反向代理中或在 Superset 的 Talisman 设置中进行配置。

SUPERSET_SECRET_KEY 管理（关键）​

这是您 Superset 实例最关键的安全设置。它用于签署所有会话 Cookie 并加密元数据数据库中的敏感信息，例如数据库连接凭据。

  • 生成一个唯一、强大的密钥：必须为每个 Superset 实例生成一个唯一的密钥。使用加密安全的方法创建它。 
    # Example using openssl to generate a strong key
    openssl rand -base64 42
  • 安全存储密钥：密钥必须保密。建议的方法是将其存储为环境变量或秘密管理系统（例如 AWS Secrets Manager、HashiCorp Vault）中。请勿将密钥硬编码在 superset_config.py 中或将其提交到版本控制。
    # In superset_config.py
    import os
    SECRET_KEY = os.environ.get('SUPERSET_SECRET_KEY')

⚠️ 警告：您的 SUPERSET_SECRET_KEY 必须是唯一的​

切勿在不同的环境（例如，开发、阶段、生产）或不同的 Superset 实例中重复使用相同的 SUPERSET_SECRET_KEY。重复使用密钥允许在这些实例之间使用加密签名的会话 Cookie，如果 Cookie 被泄露，这可能导致完全的身份验证绕过。请将此密钥视为您的主密码。

会话管理安全（关键）​

正确配置用户会话对于防止会话劫持和确保会话正确终止至关重要。

默认的无状态基于 Cookie 的会话处理在注销后立即失效会话方面存在挑战。对于所有生产部署，我们强烈建议配置可选的服务器端会话后端，例如 Redis、Memcached 或数据库。这确保了会话数据安全地存储在服务器上，并且可以在注销时立即销毁，使任何复制的会话 Cookie 立即失效。

Redis 的 superset_config.py 示例

# superset_config.py
from redis import Redis
import os

# 1. Enable server-side sessions
SESSION_SERVER_SIDE = True

# 2. Choose your backend (e.g., 'redis', 'memcached', 'filesystem', 'sqlalchemy')
SESSION_TYPE = 'redis'

# 3. Configure your Redis connection
# Use environment variables for sensitive details
SESSION_REDIS = Redis(
    host=os.environ.get('REDIS_HOST', 'localhost'),
    port=int(os.environ.get('REDIS_PORT', 6379)),
    password=os.environ.get('REDIS_PASSWORD'),
    db=int(os.environ.get('REDIS_DB', 0)),
    ssl=os.environ.get('REDIS_SSL_ENABLED', 'True').lower() == 'true',
    ssl_cert_reqs='required' # Or another appropriate SSL setting
)

# 4. Ensure the session cookie is signed for integrity
SESSION_USE_SIGNER = True

这对于所有部署都是强制性的，无论是无状态还是服务器端。

# superset_config.py
from datetime import timedelta

# Set a short absolute session timeout
# The default is 31 days, which is NOT recommended for production.
PERMANENT_SESSION_LIFETIME = timedelta(hours=8)

# Enforce secure cookie flags to prevent browser-based attacks
SESSION_COOKIE_SECURE = True      # Transmit cookie only over HTTPS
SESSION_COOKIE_HTTPONLY = True    # Prevent client-side JS from accessing the cookie
SESSION_COOKIE_SAMESITE = 'Lax'   # Provide protection against CSRF attacks

推荐的默认设置 'Lax' 为大多数用例提供了良好的 CSRF 保护。但是，如果您需要使用 iFrame 将 Superset 仪表板嵌入到其他应用程序中，则需要将此设置更改为 'None'。

SESSION_COOKIE_SAMESITE = 'None'

将 SameSite 设置为 'None' 要求 SESSION_COOKIE_SECURE 也设置为 True。请注意，此配置会禁用浏览器的一些内置 CSRF 保护以允许跨域功能，因此仅在需要 iFrame 嵌入时才应使用。

认证和授权​

虽然 Superset 内置的数据库认证很方便，但对于生产环境，强烈建议与企业级身份提供商 (IdP) 集成。

  • 使用企业 IdP：通过 OAuth 或 LDAP 配置身份验证，以利用您组织现有的身份管理系统。这提供了单点登录 (SSO)、多因素身份验证 (MFA) 和集中式用户配置/取消配置等优势。
  • 最小权限原则：将用户分配到其工作所需的最严格的角色。避免过度分配 Admin 或 Alpha 角色给用户，并确保在适当的情况下应用行级安全性。
  • 管理员帐户：配置新的管理帐户后，删除或禁用默认的管理员用户。

内容安全策略 (CSP) 和其他标头​

Superset 可以使用 Flask-Talisman 设置安全标头。但是，它必须明确启用。

⚠️ 重要提示：Talisman 默认禁用​

在 Superset 4.0 及更高版本中，Talisman 默认禁用（TALISMAN_ENABLED = False）。您必须在 superset_config.py 中明确启用它，才能使 TALISMAN_CONFIG 中定义的安全标头生效。

以下是有关如何设置 Talisman 的文档部分：https://superset.org.cn/docs/security/#content-security-policy-csp

数据库安全​

❗ Superset 不是数据库防火墙​

理解Apache Superset 是一个数据可视化和探索平台，而不是数据库防火墙或您数据仓库的全面安全解决方案至关重要。虽然 Superset 提供了帮助管理数据访问的功能，但保护底层数据库的最终责任在于您的数据库管理员 (DBA) 和安全团队。这包括直接在数据库内部管理网络访问、用户权限和细粒度权限。以下配置是重要的二级安全层，但不应是您唯一的防线。

  • 使用专用数据库用户：Superset 中配置的数据库连接应使用具有有限权限的专用数据库用户。此用户应仅具有查询其所需数据源所需的最低权限（例如，特定架构上的 SELECT）。它不应具有 INSERT、UPDATE、DELETE 或管理权限。
  • 限制危险的 SQL 函数：为了缓解潜在的 SQL 注入风险，请在 superset_config.py 中配置 DISALLOWED_SQL_FUNCTIONS 列表。请注意，这是一种纵深防御措施，不能替代正确的数据库权限。

附加安全层​

  • Web 应用程序防火墙 (WAF)：强烈建议将 Superset 部署在 WAF（例如 Cloudflare、AWS WAF）之后。具有标准规则集（如 OWASP Core Rule Set）的 WAF 提供了一层关键的防御，可抵御常见的攻击，如 SQL 注入、XSS 和远程代码执行。

监控和日志记录​

  • 配置结构化日志记录：设置强大的日志记录配置以捕获重要的安全事件。
  • 集中化日志：将所有 Superset 组件（前端、worker 等）的日志发送到中央 SIEM（安全信息和事件管理）系统，进行分析和警报。
  • 监控关键事件：为可疑活动创建警报，包括：
    • 单个用户或单个 IP 地址的多次登录失败尝试。
    • 用户角色或权限的更改。
    • 高权限用户的创建或删除。
    • 尝试使用不允许的 SQL 函数。

附录 A：生产部署清单​

初始设置：​

  • HTTPS/TLS 已配置并通过反向代理强制执行。
  • 已生成唯一的、强大的 SUPERSET_SECRET_KEY 并将其安全地存储在环境变量或密钥库中。
  • 已配置服务器端会话管理（例如 Redis）。
  • PERMANENT_SESSION_LIFETIME 已设置为较短的持续时间（例如 8 小时）。
  • 所有会话 Cookie 安全标志（Secure、HttpOnly、SameSite）均已启用。
  • DEBUG 模式已设置为 False。
  • Talisman 已明确启用并配置了严格的内容安全策略。
  • 数据库连接使用专用、有限权限的帐户。
  • 身份验证已与企业身份提供商 (OAuth/LDAP) 集成。
  • 已在 Superset 前面部署 Web 应用程序防火墙 (WAF)。
  • 日志记录已配置，并且日志已发送到中央监控系统。

持续维护：​

  • 定期更新到 Superset 的最新主要或次要版本。这些版本会收到最新的安全补丁。
  • 定期（例如每季度）并在任何潜在安全事件发生后轮换 SUPERSET_SECRET_KEY。
  • 对所有用户进行季度访问审查。
  • 假设日志记录和监控已到位，每周审查安全监控警报。

附录 B：SECRET_KEY 轮换和泄露响应​

为什么要以及何时轮换 SECRET_KEY 轮换 SUPERSET_SECRET_KEY 是一项关键的安全程序。在已知或怀疑泄露后是强制性的，并且在有权访问密钥的员工离职时是最佳实践。虽然定期轮换可以限制未知泄露的暴露窗口，但它是一项高影响操作，将使所有用户会话失效，需要仔细执行以避免破坏您的实例。管理此密钥的原则与加密存储的一般最佳实践一致，OWASP 加密存储备忘单中对此有更详细的说明：https://cheatsheetseries.owasp.ac.cn/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html

轮换密钥的程序 必须严格遵循安全轮换 SECRET_KEY 的程序，以避免将自己锁定在实例之外。Apache Superset 官方文档维护着正确且最新的程序。请遵循此处的官方指南：https://superset.org.cn/docs/configuration/configuring-superset/#rotating-to-a-newer-secret_key

编辑此页面
上次更新于，作者：Evan Rusackas