EMR Serverless StarRocks企业级安全能力

功能优势

StarRocks的SSL加密连接功能相较于传统的明文连接，具有以下显著优势：

• 数据加密传输

  • SSL连接采用加密技术保护客户端与StarRocks实例之间的数据，防止在传输过程中发生窃听或篡改。

  • SSL/TLS协议支持双向认证（双向SSL），即客户端和服务器端均需验证对方的证书。

• 证书验证机制

  • 当启用SSL连接时，StarRocks将验证客户端提供的证书的合法性。

  • 如果使用平台自签名证书，StarRocks平台将自动生成并颁发证书，客户端可直接使用。

• 增强安全性

  通过SSL加密，StarRocks实例能够满足企业级数据安全需求，符合数据保护和隐私合规的要求。

• 兼容性

  • 支持客户自定义证书和平台自签名证书，适用于不同的部署场景。

  • 平台自签名证书使用2048位RSA非对称加密算法进行加密，确保通信的高效性和安全性。

证书类型

StarRocks提供了两类SSL证书管理方式，以满足不同用户的需求：

• 客户自定义证书

  • 您可以上传自己的SSL证书，适用于已有PKI（公钥基础设施）的企业环境。

  • 自定义证书需满足P12格式，StarRocks平台将对私钥和证书链的有效性进行验证。

• 平台自签名证书

  • StarRocks支持自动生成自签名证书，方便用户快速部署SSL加密功能。

  • 自动生成的证书会以P12格式提供，包含私钥和证书链，便于客户端直接使用。

基本使用

StarRocks SSL连接的基本使用步骤和配置说明，请参见设置SSL加密。

信封加密机制的核心流程

1. 在KMS中创建主密钥

   • 用户或系统在KMS（密钥管理服务）中创建一个主密钥（Master Key），用于加密数据密钥（Data Key）。

   • 主密钥的安全性由KMS保障，通常存储在高度安全的环境中，不会直接暴露。

2. 调用KMS的GenerateDataKey接口

   • 当需要对业务数据进行加密时，云产品（StarRocks底层的ECS云盘）会调用KMS提供的GenerateDataKey接口，请求生成一个数据密钥（Data Key）。

   • 数据密钥用于实际加密业务数据，通常为对称密钥（Symmetric Key）。

3. KMS返回数据密钥

   KMS返回数据密钥包含以下两部分：

   • 数据密钥明文（Data Key Plaintext）：用于加密业务数据的明文密钥。

   • 数据密钥密文（Data Key Ciphertext）：主密钥加密后的数据密钥，以密文形式存储。

• 云产品使用数据密钥加密数据

  • StarRocks使用数据密钥明文对业务数据进行加密，生成数据密文（Data Ciphertext）。

  • 将数据密钥密文和数据密文一同写入持久化存储介质（如ECS云盘）。

  • 数据密钥明文仅在云产品的内存中使用，不会以明文形式存储在持久化存储介质上。

  • KMS提供的默认密钥、软件密钥、硬件密钥，均支持被阿里云产品集成用于服务端加密，更多信息请参见密钥服务概述。

信封加密机制的特点

• 分层密钥管理

  • 主密钥（Master Key）：由KMS管理，仅用于加密数据密钥，不直接接触业务数据。

  • 数据密钥（Data Key）：用于实际加密业务数据，生命周期短暂，仅在内存中使用。

  • 通过分层管理，主密钥的安全性得到保障，数据密钥的使用也更加灵活。

• 数据密钥的安全性

  • 数据密钥明文仅存在于云产品的内存中，不会持久化存储，避免了密钥被泄露的风险。

  • 数据密钥密文由KMS使用主密钥加密生成，存储在持久化介质中，确保密钥的安全性。

• 数据加密与解密

  • 加密过程：业务数据使用数据密钥明文进行加密，生成数据密文。

  • 解密过程：当StarRocks从ECS云盘读取数据时，会通过KMS解密数据密钥密文，获取数据密钥明文，再使用数据密钥明文解密数据密文，恢复原始数据。

• 安全性与合规性

  • 信封加密机制符合企业级数据安全标准，能够满足数据保护和隐私合规的要求。

  • 数据密钥的生命周期管理由KMS负责，支持密钥轮换、撤销等操作，进一步提升安全性。

底层实现方式

• 账号归属

  • StarRocks实例底层ECS：归属于StarRocks云产品资源账号。

  • KMS密钥实例：归属于客户租户账号。

  • 管控服务：使用StarRocks云产品服务账号跨账号授权。

• 角色授权链

  用户在创建KMS加密的StarRocks时，需要将StarRocks产品角色aliyunserviceroleforemrstarrocks授权给StarRocks管控服务，以便其访问用户的KMS。用户对StarRocks服务访问KMS的授权为Service类型授权，而StarRocks服务对StarRocks生产账号的授权则为User类型授权。此外，StarRocks生产账号对ECS服务的授权也属于Service类型授权。因此，StarRocks在创建加密盘时需要建立完整的授权链。

开启KMS磁盘加密

• 启用限制

  • 仅支持ESSD云盘、SSD云盘和高效云盘，不支持加密本地盘。

  • 仅可在创建实例时开启，开启后不可关闭。

• 在创建StarRocks实例时，需选择已创建的密钥，ASI在调度ECS实例时将自动绑定所选择的KMS。

  

StarRocks支持的Ranger功能

• 创建Policy策略

  • Access Policy（访问策略）：控制用户或角色数据库、表、列等对象的访问权限。

  • Masking Policy（数据脱敏策略）：对敏感数据进行脱敏处理，确保用户只能看到经过脱敏的数据。

  • Row-level Filter Policy（行级过滤策略）：根据配置的过滤条件，限制用户对特定行数据的访问。

• Ranger审计日志

  StarRocks支持Ranger审计日志功能，记录用户的访问行为和权限使用情况，便于后续审计和分析。

• External Catalog的支持

  • 对于External Catalog（如Hive、HDFS等外部数据源），StarRocks可以复用Ranger中已有的外部Service（如Hive Service）进行权限控制，无需额外配置。

  • 不同Catalog可以匹配不同的Ranger Service，实现灵活的权限管理。

• Kerberos认证的Ranger Server

  目前StarRocks支持Kerberos认证的Ranger Server。

StarRocks与Ranger的访问控制模式

StarRocks提供了以下三种访问控制模式，用户可以根据需求灵活选择：

• 全部使用Ranger进行权限管理

  在StarRocks Service中统一管理内表、外表及所有对象的访问权限。

• 内表使用Ranger，外表复用外部Service

  • 内表及内部对象的权限在StarRocks Service中管理。

  • External Catalog的权限直接复用外部数据源对应的Ranger Service（如Hive Service），无需额外配置。

• 混合模式：Ranger与原生RBAC结合

  • External Catalog使用Ranger进行权限管理，复用外部数据源对应的Ranger Service。

  • 内部对象及内部表使用StarRocks原生RBAC鉴权模式，不集成Ranger。

StarRocks集成Ranger的优势

• 统一权限管理

  通过Ranger，可以统一管理StarRocks内部和外部数据源的权限，简化权限管理流程。

• 增强的数据安全能力

  Ranger提供了数据脱敏（Masking） 和行级过滤（Row-level Filtering）等高级功能，进一步增强了StarRocks的数据安全能力。

• 审计与合规性

  Ranger的审计日志功能可以帮助企业满足数据安全审计和合规性要求。

• 灵活的权限配置

  支持针对不同Catalog配置不同的Ranger Service，满足复杂场景下的权限管理需求。

StarRocks与Ranger的适用场景

• 场景1：统一权限管理

  如果企业希望统一管理StarRocks内部和外部数据源的权限，可以选择全部使用Ranger进行权限管理。

• 场景2：混合权限管理

  如果企业希望保留StarRocks原生RBAC系统用于内部对象的管理，同时利用Ranger对外部Catalog进行权限控制，可以选择混合模式。

• 场景3：外部Catalog的快速集成

  如果企业已经配置了Ranger的外部Service（如 Hive Service），StarRocks可以直接复用这些配置，快速实现对External Catalog的权限控制。

安全能力点

StarRocks的RBAC（基于角色的访问控制）能力主要体现在以下几个方面：

• 角色定义：StarRocks 允许管理员创建自定义角色，并为角色分配特定的权限。

• 权限授予：权限可以授予用户或角色，管理员可以通过角色管理权限，而不是直接为每个用户分配权限。

• 动态调整：权限和角色的定义可以在集群运行时动态调整，无需重启服务。

• 权限审计：支持权限变更的审计功能，管理员可以追踪权限的授予和回收操作。

• 权限回收：管理员可以灵活地回收用户的权限，确保权限不会被滥用。

RBAC基础原理

StarRocks的RBAC机制基于以下原理：

• 角色与权限的映射：角色是权限的集合，每个角色可以包含多个权限。权限可以是针对数据库、表、列或操作（如SELECT、INSERT、DELETE等）。

• 用户与角色的映射：用户可以通过被授予多个角色来获得不同的权限集合。StarRocks在权限验证时会合并用户直接拥有的权限。

• 权限检查：StarRocks在每次用户操作时会检查其权限，确保用户只能访问其被允许的资源。

StarRocks RBAC权限体系优势

• 管理简便：通过角色管理权限，减少了直接为每个用户分配权限的工作量，提高了管理效率。

• 权限隔离：角色可以将不同类型的权限进行隔离，避免用户获得不必要的权限。

• 安全性高：权限的集中管理和动态调整确保了系统的安全性，降低了误操作或权限滥用的风险。

• 灵活性强：权限的动态调整使得权限管理更加灵活，能够适应复杂的业务需求。

RBAC基本使用及管控平台能力

StarRocks的RBAC使用流程如下，管理员可以通过SQL命令行或者管控平台进行授权操作：

1. 创建角色：管理员可以通过SQL命令创建新的角色。 

2. 赋予角色权限：管理员可以为角色分配特定的权限，例如对某个数据库、表或列的读写权限。 

3. 将角色授予用户：管理员可以将角色授予用户，用户通过角色间接获得权限。 

4. 权限验证：用户在访问资源时，StarRocks会根据其被授予的角色来验证权限。

5. 回收权限：管理员可以回收用户的角色或直接回收角色的权限。 

更多详细信息，请参见管理用户及数据授权。

Kerberos认证的支持

• 配置Kerberos认证

  • StarRocks允许用户在连接配置中启用Kerberos认证，确保用户身份的可信性和通信的安全性。

  • 配置通常涉及设置KDC服务器地址、票据缓存路径等参数，以集成现有的Kerberos基础设施。

• 与DataLake集群的集成

  • StarRocks能够连接到已经启用了Kerberos认证的DataLake存储集群，如HDFS、OSS等。

  • 用户在访问外部数据源时，需要通过Kerberos进行身份验证，确保只有授权用户能访问特定数据。

• 增强的安全性

  Kerberos认证通过提供强身份验证，有效防止未授权访问和数据泄露，提升整体数据传输安全性。

适用场景

• 企业级安全需求

  适用于已部署Kerberos环境的企业，StarRocks用户可以利用现有的安全基础设施，增强数据集群的安全性。

• 统一安全策略

  通过Kerberos认证和StarRocks的RBAC/Ranger集成，实现统一的安全策略管理，提升整体安全性和管理效率。