WhereHows项目中数据集列业务属性编辑权限缺失问题分析

背景介绍

在数据治理平台WhereHows的最新版本中，业务属性(Business Attribute)作为一个重要功能被引入。该功能最初在13.3版本中以特性标志(feature flag)的形式出现，并在后续版本中正式启用。业务属性为数据集列提供了额外的业务上下文信息，是数据目录和数据治理的重要组成部分。

问题描述

在权限管理模块中发现了一个重要的功能缺陷：系统缺少对"编辑数据集列业务属性"操作的权限控制策略。这意味着任何用户都可以不受限制地修改数据集列的业务属性，这显然不符合企业级数据治理平台的安全要求。

技术细节分析

1. 权限策略机制：WhereHows采用基于角色的访问控制(RBAC)模型，通过"管理权限"界面可以创建和管理各种权限策略。对于数据集列的元数据操作，系统已经实现了对描述(Description)、标签(Tags)和术语表词条(Glossary Terms)的编辑权限控制。

2. 缺失的权限项：在创建新策略时，权限类型选择"元数据"后，权限下拉列表中可以看到：

   • 编辑数据集列描述
   • 编辑数据集列标签
   • 编辑数据集列术语表词条 但唯独缺少"编辑数据集列业务属性"这一关键权限项。

3. 安全影响：由于缺乏相应的权限控制，系统存在以下风险：

   • 低权限用户可能修改关键业务属性
   • 无法实现细粒度的访问控制
   • 审计追踪不完整

解决方案建议

1. 后端实现：

   • 需要在权限服务中添加新的权限枚举值
   • 更新权限验证逻辑，在业务属性修改操作前检查权限
   • 确保API网关层也进行相应的权限校验

2. 前端实现：

   • 在权限管理界面添加新的权限选项
   • 更新用户界面以反映权限状态
   • 确保无权限用户无法看到或访问业务属性编辑功能

3. 数据库变更：

   • 可能需要更新权限策略存储结构
   • 考虑添加默认权限策略的迁移脚本

最佳实践

对于类似的数据治理平台权限系统设计，建议：

1. 权限与功能同步：每当添加新功能时，应同步考虑其权限控制需求，避免功能先于权限机制上线。

2. 权限分类明确：将权限按类型(如元数据、数据访问、管理等)清晰划分，便于管理员理解和管理。

3. 默认安全原则：新功能的权限默认应设置为最严格，避免出现无权限控制的开放状态。

4. 权限继承机制：考虑实现权限继承关系，减少权限管理复杂度。

总结

数据治理平台的权限控制系统是其安全架构的核心组成部分。WhereHows项目中发现的业务属性编辑权限缺失问题提醒我们，在快速迭代开发新功能的同时，必须同步完善相关的安全控制机制。这不仅涉及前端界面的权限选项，还包括后端服务的权限验证、API网关的访问控制等多个层面的协同工作。完善的权限系统是确保企业数据资产安全、实现合规性要求的基础保障。