某头部零售集团的数据云平台“多租户安全”实践

这家以食品零售起家的集团，旗下拥有多个全国知名的子品牌。在品牌 A 的业务部门用上数据云平台一年后，品牌 B 表示，“A 用得不错，我们也在考虑上数据云平台，部分数据和 A 做个互动，能碰撞出更多价值，也少做重复建设。”

现在，有 3 个选择摆在这家集团的 IT 团队面前：

方案一：品牌 B 独享新一份集群资源，与品牌 A 共用同一套数据云平台管理。

方案二：品牌 B 数据接入原有平台，与品牌 A 共用一套资源及平台。

方案三：和品牌 A 共用一套资源及平台，但采用多租户安全技术方案。

需求拆解：要资源节约，也要数据安全

上文所述方案一，理论上是最直接的选择：

品牌 A 继续用原有资源及数据云平台，品牌 B 另外采购一份新的集群资源，双方数据物理隔离，互不抢占资源，权限也完全掌握在自己手中，安全指数极高。

奇点云数据云平台 DataSimba 支持通过同一平台管理多个工作空间（Workspace），因此企业无需另外购买数据云平台，品牌 A、品牌 B 以及该公司更多其他部门都能在各自权限内使用该平台。

方案一：工作空间级隔离

然而，双份集群资源意味着双边资源都无法得到最大程度利用，存在一定浪费。

平台、资源都直接复用的方案二怎么样？

无需重新部署，只要导入品牌 B 的数据，并在数据云平台上为 B 开设新账户，A 和 B 通过平台各自管理权限内的项目；双品牌可以共享集群数据、存储和计算资源，依赖平台调度能力，品牌 A 和品牌 B 所用的资源能动态调度，总量上更节约。

方案二：共用资源及平台的弱逻辑隔离

方案二的优点是显而易见的，此类做法在业内也较为常见。然而，在数据安全上稍有弱点：该方案的权限体系未触及大数据集群管理引擎，就像租在同一栋楼里，有门做了隔断，但没有金融级的防盗门和监控系统。奇点云资深架构专家简愉谈到：“这种方案对管理员要求极高，管理员必须要细致地配置权限、角色、策略，并定期检查收回过期的权限，才能规避违规行为。（违规行为例如，内部运维人员绕过上层体系，直连大数据底层集群以试图获取项目数据。）”

此外，方案二对平台调度能力要求较高。如果平台调度不够“聪明”，就容易出现品牌 B 任务耗时过久、品牌 A 任务不得不长时间等待甚至影响业务的情况。

在资源高效利用但互不抢占、同时保障数据安全的前提下，最终，这家企业选择了方案三：多品牌共用一套集群资源和数据云平台，并采用多租户安全技术方案。（注：对于集团企业/上市公司的财务部门而言，出于合规要求，仍更推荐采用工作空间级隔离方案，即方案一。）

方案解析：三个“双层”，加持多租户安全

那么，到底什么是多租户？

“多租户”，顾名思义，资源方把资源“租赁”给多个客户。“租”指客户自己没有资源（例如计算、存储、数据、服务等资源），需要租用。“多”则指资源提供方提供的资源同时被多个租户租赁使用。

多租户技术自提出以来已有 60 余年，从大型机到云计算时代，都曾得到广泛应用。它让资源提供方的资源利用最大化，作为平台身份服务更多租户，也免去了租户自行运管基础设施的烦恼。以企业举例，IT 团队负责为企业采购并管理一整套资源，其中各 BU 就是不同的租户，租户在各自的资源空间下完成自己的开发工作，而互不抢占资源、影响作业进度。同时，管理方也可以根据各租户长期使用情况，更合理地规划资源。

事实上，对于“企业级”的数据资产管理而言，多租户仅仅完成资源隔离还不足够。“多租户场景下的数据安全值得企业关注。”简愉表示，在资源共享的情况下，如何实现对资源进行租户粒度的安全隔离，是资源提供商需要解决的核心技术问题。

为此，DataSimba 在经典的多租户方案基础上，增加了“双层身份认证”、“双层权限校验”、“双层存储加密”，来保证租户资源的强逻辑隔离与数据安全。

最终，该集团采用了 DataSimba 多租户安全方案，技术架构如下图所示：

方案三：DataSimba 多租户安全隔离

• 双层身份认证

即证明“我是谁”。

数据云平台（例如 DataSimba）和大数据集群管理引擎（例如 DataKun）是两套独立的系统，有各自的账户体系，需要在每个系统入口均进行严格的身份认证。其中，DataKun 开启了 Kerberos 认证，每个用户（Unix User）都会被分配自有的 Principal 及 Keytab 文件（相当于登录名和密码）。

在两套系统各自完成身份认证的情况下，完成两套账户的一对一映射。此后，DataSimba 的用户（User）向 DataKun 提交分布式离线/实时作业，都是通过其关联的 Kerberos 凭证进行身份认证。

• 双层权限校验

即校验我是否有权限对相应资源进行相应操作。

DataSimba 对接口和菜单权限、数据权限均有所管控。以数据权限为例，租户（Account）下设若干子账号（User），子账号的数据权限申请只能在租户已租用的资源范围内，权限粒度可精确到表、字段、行级。只有权限校验通过，子账号方可通过 DataSimba 向大数据集群提交作业，否则在这一层即校验失败，作业/任务中止提交。

同样，大数据集群管理引擎例如 DataKun，也需要进行权限校验，鉴权粒度为数据库级数据权限，来保障大数据集群侧用户（Unix User）数据、存储、计算的隔离与安全。大数据集群管理引擎理论上不限于 DataKun，其它部署了安全组件的大数据集群管理引擎也可实现。

需要注意的是，两层权限均是通过权限策略进行强逻辑隔离。这也意味着租户之间的计算、数据、存储和服务隔离是软隔离，可以通过动态调整权限策略，实现多租户之间的计算、数据、存储和服务的共享。比如品牌 A 的数据云平台租户可以给品牌 B 租户赋予数据访问权限，即可实现品牌 A 和品牌 B 的数据共享，而无需进行数据迁移。

• 双层存储加密

即就算试图绕过 DataSimba 和大数据集群管理引擎、直接读取源文件，也无法读取成功。架构中设置了两层文件存储加密“双保险”，包括：DataSimba 侧基于分布式存储方案，开启透明加密；大数据集群引擎侧开启底层文件加密和密钥的管理权限独立托管。

为什么权限管控一定要“双层”？

实际上，从技术实现来看，数据权限管控压缩成一层似乎也无妨：

统一在大数据集群侧大数据安全组件中实现对数据云平台 DataSimba 用户的表、字段、行级数据权限管控。子账号（User）在通过 DataSimba 向集群管理引擎提交 Hive/Spark/Flink 等大数据作业任务时，使用其集群侧的 Kerberos 凭证即可。这也是业内很多大数据平台服务商所采用的方案。

然而，从自主可控的数据安全要求来看，设置双层数据权限管控是极为必要的。

在许多客户的实际场景中，数据云平台和大数据集群管理引擎可能是独立运营的，其厂牌不同，底层大数据集群管理还可能交由特定部门维护。因此，企业内负责数据云平台的部门及其服务商能否在集群管理引擎安装安全插件，就成了不确定性。也就是说，数据云平台如果本身没有严格的数据权限管控体系，而完全依赖于集群管理的安全政策，就难以 100%确保数据安全。

因此，DataSimba 设置了数据权限代理层，解耦数据云平台与客户大数据集群管理的安全性依赖，从而实现在不侵入大数据集群管理引擎的前提下，依旧有与大数据安全组件等同能力的数据权限管控。

近期，该零售集团已完成 DataSimba 多租户技术架构的部署。在多个数据团队互不抢占资源的同时，相较传统方案，更节约了 50%的大数据集群计算节点。同时，通过动态的权限管控，支持租户间（例如跨部门）数据安全共享，而无需数据迁移成本。

目前，奇点云数据云平台 DataSimba 多租户架构已在十余家企业完成落地实践，包括旗下有汽车、工业技术等多业态的知名工业集团，创新机器人领域的科技公司，及知名酒类贸易集团等等。

作者简介：

简愉，奇点云数据平台部资深架构师，曾供职于中国科学技术大学博士后/副研究员，主攻大数据领域算法与安全方向研究，已发表数篇 SCI 学术期刊/会议论文，并发明大数据安全技术专利。