/ 方案资料
By 数可安
24 Apr 2025
09
35
当下，数据安全已然跃居企业重点关注的核心领域之首。本文着重阐述一种依托分类分级开展的权限收敛方案，力求通过精准管理，在保障数据安全的基石上，提升数据可用性与业务效率，实现多维度的平衡发展。
数据分类的本质是依据数据的属性、功能及价值高低，将其划归为不同组别。在落地实操阶段，企业需贴合自身发展脉络与业务需求，对数据分类维度进行适配性调整。尽管规章制度可细分出多种类别，但于实际推行环节，宜先聚焦关键数据，将非核心数据统统归入 “其他” 类别。以个人信息为例，可率先锁定姓名、手机号、身份证号和银行卡号这四大关键要素为一类，其余信息统归 “其他”，为后续数据分级找准锚点。
数据分级聚焦于衡量数据的敏感程度以及关乎业务发展的影响力，进而为其贴上不同的安全级别标签。同样要紧密贴合企业业务特性进行分层定级。若企业重点关注个人信息中的四项关键要素，可考量将姓名归为 2 级，鉴于其敏感性相对略低；而手机号、身份证号和银行卡号因敏感性突出，定为 3 级，其余数据暂定为 1 级，构建起清晰的数据安全等级序列。
传统以数据库为单位的授权模式，存在较大安全隐患。一旦用户权限外泄或遭滥用，整个数据库将陷入安全漩涡。而革新后的按表授权模式，将权限精准聚焦到单一表格，严格限定用户仅能接触完成任务所必需的表内数据，隔绝与其他表格的关联。如此一来，即便权限失控，影响圈也仅限特定表格，能有效遏制数据泄露风险扩散，同时契合部分业务部门限制外部访问的诉求，达成安全性与业务适配性的双赢。
为保障项目稳步推进，应搭建一个跨部门的虚拟协作小组，其成员涵盖数据管理板块（包含 DBA 以及大数据团队力量）、信息安全专员以及研发团队代表，凝聚各方智慧与资源，形成工作合力。
项目落地需要一整套系统架构支撑，具体涵盖分类分级系统、工单流转系统、审批流程系统以及数据存储管理系统（如常见的 mysql、hadoop 系列相关组件），各系统协同发力，为权限收敛工作筑牢技术根基。
实现权限申请从宽泛的库级别向精细的表级别转变。
对敏感字段默认执行脱敏操作，保障数据隐私。
针对不同敏感层级的表格，匹配差异化的审批流程，强化权限管控的针对性。
明确待治理数据库的范畴，为后续精准打标提供边界指引。
界定权限调整所波及的人员群体，依据部门职责特性，数据管理部门因职能所需保留高阶权限，其他部门则依照统一规范匹配适配的数据使用权。
开启数据治理序幕前，先对组织全域数据进行地毯式识别与标记，精准锚定各数据的属性特质及应用场景。联合数据管理部门深度研讨，锚定治理范围，再借助分类分级系统，依据既定策略为范围内的数据贴上精准标签。着重关注存量与增量数据的扫描策略差异，存量数据可手动依托系统处理，增量数据则借助接口自动化操作。
扫描作业时，需与数据管理部门提前沟通，敲定合理的扫描时间窗口与并发量，规避对业务运行的干扰。并充分考量不同部门的业务节奏差异，如大数据部门习惯日间处理批任务，偏好白天扫描；MySQL 等业务库则倾向晚间扫描。同时，为提升效率、降低风险，合理控制并行任务数量，采用定时启动策略，巧妙错峰执行任务。
遵循数据的分类分级成果，精心定义层级分明的访问权限，并依循用户角色与职责精准分配权限。先将数据表区分为敏感与非敏感两大类，针对敏感表增加审批环节，非敏感表仅需直属上级审批，敏感表则要历经直属上级及更高层的双重审批。
在授权模式上，个人授权与角色授权双管齐下。个人授权力求权限聚焦，契合最小化原则；角色授权则便利新人快速融入角色，获取基本权限开展工作。特别注意，敏感表不可嵌入角色授权体系，必须由用户单独发起申请，以此提升效率，最大程度压缩敏感数据的暴露面，降低数据失窃风险。
系统建设聚焦两大核心方向：一是在现有工单系统中嵌入适配模块，实现工单处理的自动化升级，兼顾成本管控与效率提升；二是完善数据管理系统，使其在接收到工单系统指令后，能自动落实授权操作。以大数据平台为例，工单系统完成审批后，定时脚本自动读取数据库中的工单信息，借助 Ranger 完成授权，全程无需人工介入。系统搭建过程中，重点关注三个核心接口调用，即组件 ID 查询接口、表敏感等级查询接口以及扫描打标任务发起接口。鉴于扫描打标接口涉及大量 JSON 数据，代码编写时易出错，需预留充足时间调试。此外，为兼顾敏感字段脱敏需求，新增表中敏感字段查询接口，并梳理常用非敏感表，匹配对应角色，助力新用户上线后便捷获取权限。
权限收敛分两步走：增量收敛与存量收敛。系统上线后，新老用户申请过往未授权的表时，必须依循系统流程，严控权限范围，摒弃整库授权的粗放模式。对于老用户，基于其过往访问记录，筛选一年内的表访问清单，经用户确认后，批量授权相关表并回收整库权限。
此过程沟通协调任务艰巨，可能遭遇阻力。应对策略是分部门逐一沟通谈判，避免反对声音形成连锁反应。若在集体会议中遭遇质疑，会上应秉持坚定立场，会后再斟酌让步策略。权限收缩流程如下：
1.为各团队梳理常用非敏感表并纳入组内。
2.明确截止时间节点 1，新用户按新方案执行授权。
3.整理老用户近一年表访问记录，标注表及敏感字段敏感等级。
4.确定截止时间节点 2，正式回收老用户库权限。
鉴于数据表实时动态变化，设立定时任务对新增或变更的表及时打标至关重要，可委派数据管理部门负责，利用脚本对接分类分级系统，每日定时发起打标任务。同时，鉴于角色中不能混入敏感表且表字段存在变更可能，设置定时任务每日复核角色内表的敏感等级，发现变动及时通知管理员处理。.
此外，及时纠正打标错误也是关键环节。可能出现的错误类型包括敏感表与非敏感表标识颠倒，以及分类分级系统对视图标识的缺失，这些问题均需人工介入修正。系统间调用也可能出现异常，如工单系统调用分类分级系统后无法获取表敏感等级，生成异常工单，需人工判定敏感等级。异常工单类型多样，或是因网络波动、系统故障致调用失败，或是因权限不足无法扫描对应集群、数据库。
当分类分级系统功能受限或遭遇数据异常时，手工导入数据处理流程便显得不可或缺。以下是主要场景及手工上传流程：
必要流程 ：先获取表（视图）字段信息，确定敏感字段，在字段样例中填入关键样例数据，上传至系统打标，并记录单独处理的工单信息，便于后续复用。
场景一：视图处理流程 ：从数据库管理员处获取视图及 sql 语句，借助 Python 脚本提取 sql 中的表，查询表的敏感等级及敏感字段，按规则标记视图字段敏感性，再进入手工上传流程。
场景二：无法正常扫描的表 ：由数据库管理员提供表及字段信息，识别敏感字段后，进入手工上传流程。
场景三：人工反馈打标等级异常且采样规则调整无效时 ：收集反馈的敏感字段信息，进入手工上传流程。
随着时间推移，库中表发生变化，重新扫描时，表的敏感等级可能发生转变，进而影响组内表及依赖视图：
场景 1 ：若表由非敏感转为敏感，需人工将其从组内剔除。
场景 2 ：当表从非敏感变为敏感，依赖该表的视图申请授权时会失败，需人工修改视图敏感等级，若视图已在组内，则触发场景 1 流程。
大多数企业都配备了数据查询平台，记录用户的查询、下载日志。在此基础上深化审计工作，一方面可审查用户是否超权限访问未申请的表，另一方面聚焦用户对敏感数据的查询、下载行为。典型审计场景包括：
定期核查角色内表的敏感性变化，尤其是非敏感表转敏感的情况，及时剔除敏感表并通知成员调整权限。
检查授权给个人的表敏感性是否变异，尤其是非敏感转敏感时，询问用户是否需查看明文数据，如需则重新走审批流程。
1.在开展数据清理、同步等对磁盘 I/O 要求苛刻的任务时，易冲击查询接口稳定性。 2.多个扫描任务并行执行，进程易崩溃，需人工重启恢复。 3.若使用机械硬盘，会大幅拉低性能，即便直连 ClickHouse，单次请求耗时也可能达数秒。 4.面对数据库中的超大表，不加过滤处理会严重拖慢扫描进度，甚至致使打标任务功亏一篑。 5.系统可能将 11 位数字误判为手机号，继而误抬高表的敏感等级，而身份证号、银行卡号识别精准度相对较高。 6.打标成败与敏感表识别精准度、数据质量紧密相连，采样获取有效数据时，识别成功率较高，反之则较低。 7.表字段变更后，重新扫描可能出现覆盖失败、数据重复等问题，这与系统设计有关，解决方案是定期清理冗余数据。
输入您的邮箱，接收最新的产品及方案信息。
我们不会发送垃圾邮件，请放心订阅。
400-1100-561
