这两年做数据安全项目的同行不管是甲方还是乙方普遍有一个共性感受分类分级做了但业务部门还是爱给多大权限给多大权限权限管控工具上了但底下的数据到底是什么级别、能不能给这个角色看说不清楚。分类分级和权限管控这两件事但凡有一头是悬空的整个数据安全体系就落到“墙上画画”的尴尬局面。我这次负责建设的正是一套把“数据分类分级”和“权限管控”从方案设计阶段就绑定在一起的一体化安全方案。核心思路不复杂先把数据资产盘清楚、贴上安全级别标签然后让权限系统按数据标签和身份标签去决定谁能看、能看多少、能不能带走。整个项目从需求梳理到落地运营前后花了三个多月涉及十几套业务系统、近千个数据库实例和几万个账号的权限梳理。这篇文章就把整个方案的设计逻辑、技术选型、落地过程和踩过的坑完整拆开希望能给正在做类似工作的同行一些能直接用的参考。1. 一体化方案的整体设计思路为什么必须把分类分级和权限管控绑在一起1.1 先从行业普遍存在的“三张皮”现象说起我们经常会在客户现场看到一种典型场景公司依据监管要求做了数据分类分级输出了一份厚厚的数据资产分级清单挂在文档系统里合规检查的时候拿出来应付一下平时没人看。另一边运维团队在数据库、大数据平台、文件服务器上做的权限配置和这份分级清单完全没有关系。再加上身份治理系统里已有的岗位角色权限三方各管各的谁也不挨谁。这就是典型的“三张皮”。这种割裂带来的实质性问题非常明确。研发同学提了个需求说要查生产库某张表的全部字段运维看到工单就批了完全不去确认这些字段里有没有客户手机号、身份证号、银行卡号。等数据泄露了翻日志才发现问题。不是某个人故意违规而是从流程上就没有人把“这张表包含L3级敏感数据”的信息传递给决策节点。所以这次项目启动的第一原则就是把分类分级的结果变成权限管控的输入条件而不是变成一本束之高阁的台账。1.2 一体化方案的目标形态数据资产目录、安全标签、权限策略引擎三件套我最终敲定的目标架构概括起来是三个核心部件第一个是数据资产目录。把企业所有的数据源接入进来不管是MySQL、Oracle、Hive、HDFS还是文件服务器统一做元数据采集和资产打标。第二个是敏感数据识别引擎。通过规则、正则、机器学习模型去自动发现数据内容中的敏感信息给出每个字段、每张表、每个文件的风险等级建议。第三个是权限策略引擎。这一层负责把“谁身份、对什么数据资产、能做什么访问动作、在什么条件下环境/时间/地点”翻译成一套可执行、可审计的策略。这三个部件之间的关系是单向强依赖的资产目录提供数据的“身份信息”识别引擎给数据“定价”权限策略引擎再基于这个“价格”决定谁能消费。这样的好处是整个方案的逻辑非常清晰后续做权限审批、审计、风险展示都有据可依。2. 数据分类分级落地实施定级模型、识别规则与打标流程2.1 分级模型怎么定——先抄再改别从零造轮子很多团队刚开始做分类分级的时候容易陷入一个误区非得自创一套分类体系把数据分成十个八个大类、四五个级别每个级别还要写长篇定义。我个人的建议是先参考现有的监管口径和行业标准再按自身业务特点去做裁剪。我这边采用的是经典的四级模型直接从数据敏感度和影响范围两个维度去切级别名称典型数据影响描述L1公开数据官网发布信息、产品宣传册泄露后无影响或影响可忽略L2内部数据内部规章制度、非敏感统计报表泄露后对企业造成轻微不利影响L3敏感数据员工工资、业务交易明细、客户联系方式泄露后对企业或个人造成严重不利影响L4核心数据用户口令、支付密钥、大规模批量个人信息泄露后对企业业务、个人隐私造成灾难性影响这个模型看起来简单但落地的时候卡在细节上到底哪些字段算“大规模批量个人信息”我当时的处理方式是给分级规则加量化条件。比如“包含身份证号字段的表记录数大于1万条级别自动定为L4小于1万条定L3”。这样的规则虽然粗糙但好处是业务部门听得懂、评审会上吵不起来自动化引擎也好实现。2.2 敏感数据识别规则与自动化打标过程分类分级不能全靠人工在Excel里梳理那对于上千张表的规模根本不现实。我们的方案里核心是搭了一套自动识别、辅助人工确认的流水线。识别规则这块优先级最高的是:特证识别也就是正则表达式。比如身份证号用18位数字加末位X的模式去匹配手机号用^1[3-9]\d{9}$银行卡号除了正则还要再过一遍Luhn校验算法不然把一串普通数字误判成银行卡后面打标就会乱套。除了特征值还增加了关键字上下文识别比如表的字段名里出现“姓名”“手机”“地址”“身份证”这些词就自动加权判定。整个打标流程分四步走源端接入通过数据源连接器批量登记库表元数据。扫描任务下发选择目标库表配置采样率生产环境不建议全量扫描一般按1%-5%采样大数据量库按分区采样。规则命中与判定识别引擎按规则集逐字段扫描采样数据计算敏感数据命中比例。生成分级建议并推送确认系统自动生成“字段级别表级别”的分级建议数据owner确认后生效。这里有个非常关键的细节分级建议尽量不要直接生效一定要保留一个人工确认节点。因为自动识别引擎经常会有误判比如某张表字段名叫“备注”里面存了一堆文本偶然出现一个身份证号样式的字符串这时候自动判定为L3就不合适。保留确认节点既尊重业务部门的意见也为后续权限管控策略提供了站得住的依据。2.3 分类分级的组织保障和确认机制技术流程搭完了最难的其实是组织层面的推动。数据owner是谁他认不认这个分级结果出问题了谁负责——这些事不前置约定清楚后面全是扯皮。我这次的做法是出了分级确认单制度。识别引擎给出建议级别后系统自动给数据owner发通知要求五个工作日内确认。超过时限未确认的默认按建议级别高一档执行。同时每季度做一次分级结果复核业务数据变化了、新增库表了都要动态调整。这套做法推下去前期确实有不少业务部门来吵说系统怎么把我的表定成L3了我们这就是内部记录。应对方式很简单你有异议可以申诉但申诉材料里必须写清楚这张表存储的数据如果泄露对客户隐私和企业声誉会产生什么影响。业务部门自己写完之后十有八九会同意原来的定级甚至主动要求上调。因为把责任摆到台面上每个人都会更审慎地对待数据。3. 权限管控的技术实现认证、授权与动态权限3.1 认证层Kerberos在大数据安全认证中的应用原理权限管控的第一步是先说清楚“你是谁”。在这个项目里认证层面集中用了Kerberos协议。提到Kerberos很多做传统业务系统的人会有点陌生但它在Hadoop、Hive、Impala这些大数据组件里是被广泛使用的底层认证机制是整个大数据安全体系的基石。我尽量用通俗的话解释Kerberos的原理。它相当于公司前台的一个门禁发证中心整个认证过程涉及到三个角色客户端请求访问数据服务的用户或应用。认证服务器ASAuthentication Server负责验证客户端身份验证通过了发给一张“TGT票据授权票据”相当于临时通行证。票据授权服务器TGSTicket Granting Server拿着TGT去找它换具体服务的入场券也就是Service Ticket。整个流程大致是这样用户输入账号密码客户端把身份信息发给ASAS校验通过后返回用用户密码加密的TGT。客户端解密拿到TGT后再用它向TGS申请访问HDFS或Hive的会话票据。TGS检查TGT没问题就发一张带有时间戳和服务信息的Service Ticket给客户端。客户端拿着这张票去访问数据服务节点服务节点验票通过一次性会话开始。这个机制最大的优点是密码不会在网络里裸奔每次会话都有时效性票据过了有效期必须重新申请。我们在落地时把票据生命周期默认配置为8小时管理员会话最长12小时。有几次我们排查大数据平台“间歇性访问失败”的问题最后发现就是客户端服务器和KDC服务器的时间偏差太大Kerberos的票据里带着时间戳客户端时间比KDC快了十几分钟超过了默认的时间容差一般默认在300秒左右认证直接失败。把NTP时间同步统一配好之后问题立刻消失。这个坑在后面问题排查部分我会再细说。3.2 授权层RBAC加ABAC的组合权限模型认证解决了“你是谁”授权要解决的是“你能干什么”。这期项目的权限模型没有走单一路线而是用了RBAC基于角色的访问控制和ABAC基于属性的访问控制的混合模式。RBAC就不多展开了大家都清楚核心就是用户挂角色、角色挂权限。这套模式在传统业务系统里足够用但放在数据平台场景下有个明显短板它判断不了上下文。比如同样一个“数据分析师”角色在工作时间访问某张L3级表是完全合理的但凌晨三点从陌生IP登录去批量拉取这张表就很可疑。RBAC表达不了这种条件约束这时候就需要ABAC上场。ABAC的思路是把访问控制的决策因素拆成主体属性用户部门、职级、数据密级、资源属性库表级别、字段敏感类型、环境属性访问时间、IP归属、设备状态然后把这些属性塞进策略表达式里。一个典型的策略表达式长这样允许操作查询 适用条件 用户部门 “运营部” 数据资产等级 L2 访问时间 ∈ [09:00, 18:00] 客户端IP ∈ 办公网段我的做法是在核心数据查询入口统一 SQL 查询平台上同时启用两类模型粗粒度的权限用 RBAC 控制“用户能不能进这个库、看这张表”细粒度的风险控制交给 ABAC 策略引擎来判断“当前这次查询允不允许执行、需不需要额外审批”。3.3 动态权限策略与审批流的联动设计光有权限模型不够权限策略要能响应动态风险变化。我这边设计了几条比较关键的策略联动级别越级联动审批普通用户查询L1、L2级数据直接放行查询L3级数据必须提交申请并指定查询期限查询L4级数据除了提交申请还要部门负责人和数据owner双人审批审批通过后才能获得临时权限。批量提取熔断策略单次SQL查询返回超过1万行L3级数据或者累计查询涉及超过5万条敏感记录系统自动终止任务并触发安全告警。非工作时段访问策略非工作时间访问L3级以上数据即便用户有权限也要追加一次短信二次认证认证通过才放行。审批这块我强烈建议做成和ITSM工单系统对接而不是在安全平台上另起炉灶。让用户在同一套流程里提交权限申请、审批、归档。避免业务部门说“我权限申请在安全平台上提了但运维那边不认”两个系统流程打架。我们接完之后权限申请的合规率明显提升因为所有审批痕迹都能完整拉出审计链路。4. 一体化联动机制从安全标签到动态策略4.1 安全标签如何传递到各个数据出口分类分级的结果如果只停留在数据资产管理平台里那权限管控还是空话。所以这套一体化方案最花功夫的地方是把“安全标签”这个元数据真正传递到数据消费链路的各个节点上。我们在每个数据源接入时都会建立一个“数据资产指纹”里面存了库、表、字段的元数据和分级标签。这个指纹会同步给下游几个主要的消费通道数据开发平台开发人员在写SQL时系统自动提示所查表的数据级别命中敏感字段自动掩码。数据服务API网关API接口注册时强制关联数据标签L3级接口自动开启调用频控和参数白名单。数据分析BI工具数据集建模时强制要求选择数据级别高级别数据集的报表导出自动带审批水印和下载审计。这里有一个常见的执行难点下游平台的标签是初始化同步的但上游分级调整了之后下游怎么及时感知我们的做法是建立消息通知机制数据资产平台上任何一张表的标签发生变更都会通过消息队列推送给下游平台下游平台收到消息立即更新自身的字段元数据。这个机制立住之后“标签同步滞后导致越权”的问题就基本被根治了。4.2 动态掩码、行级权限与列级权限的落地权限管控到字段级这是这次项目里最被业务部门关注的一个部分。列级权限比较好理解比如人事专员可以看到员工的姓名、手机号但看不到薪资列薪资数据只对薪酬组的同事开放。这个用统一的SQL查询网关做改写就能实现当用户发起查询时网关根据用户的属性判断他是否有权访问请求列无权限的列直接在SQL解析阶段拦截返回“无权限访问”提示。行级权限相对复杂一些。比如不同区域的销售只能查看自己区域内的客户数据这就需要在查询语句中自动追加一个行过滤条件WHERE region 华东。我们是在查询网关里配置行级权限策略用户查询时网关自动改写SQL、追加过滤条件这样用户自己根本感知不到也绕不过去。脱敏处理是最后一道底线。对于L3级以上数据的敏感字段我建议默认启用自动掩码策略手机号显示前3后4身份证显示前6后4银行卡号显示前4后4。这里要特别提一下不要在应用层做脱敏一定要在数据出口网关层面做。否则应用开发者一拿到全量数据在页面上再怎么脱敏都拦不住有人把数据拖走。这套机制落地后数据库账号再也不用给每个开发同学单独开放真实查询权限了所有人都走统一出口敏感数据一出网关就被规则处理好了。4.3 权限审计与风险分析让策略持续有效一体化方案的前半程是把规则建起来但安全工作的常态是持续运营。所以我专门在平台里搭了权限审计模块每隔一段时间自动做一遍权限复核。审计模块重点盯三类东西权限僵尸账号超过90天未登录但权限还挂着的账号自动生成回收工单。越权账号离职人员权限未及时回收的、转岗人员仍保留原部门数据权限的。高权限账号异常访问拥有DBA或管理员权限的账号在非工作时间批量查询敏感表。有一条经验值得分享权限复核如果靠人工在Excel里对账基本做一次就没人愿意做第二次。最好是把规则预置成自动化任务每周跑一次自动输出风险清单并推送给业务部门确认。要让系统去盯人而不是让人去盯系统。5. 落地过程中的常见问题与排查技巧5.1 分类分级推进中的典型阻力与应对所有做数据安全治理的同行最头疼的一件事业务部门不配合。我们项目推进期也是各种软磨硬泡。常见的阻力大概有两种一种是不承认自己的数据是敏感数据。明明存了上万条客户手机号偏偏说这表只是临时表没什么机密。应对办法是把合规风险明确摆出来告诉他们“数据一旦泄露监管处罚的级别和这表的数据量直接挂钩”业务负责人立刻就会认真对待。另一种是担心分类分级工作影响业务效率。最典型的是“我天天要导数据你搞了权限管控我是不是连数据都拿不到了”。这种情况下不能只做限制还要做出“便利性”。我们的做法是在安全前提下提供一个好用的申请通道数据查询和导出申请全部线上化正常情况下10分钟就能审批完成打破“安全流程繁琐”的固有印象。通道顺滑了业务部门的配合度自然就上来。5.2 权限梳理中容易踩的坑第一个坑权限账实不符。很多业务系统用了很多年角色建了几百个权限乱得像蜘蛛网。只靠访谈业务负责人去梳理现状根本不可靠。我的建议是在梳理阶段直接用脚本把系统中的权限配置全量拉出来按账号、角色、资源做三维矩阵图再拿去给业务部门确认。拿着事实去沟通效率比开会高得多。第二个坑权限最小化矫枉过正。有的团队做最小权限原则把所有人权限收得很紧结果业务天天提工单要权限安全团队被淹没在审批流里。后来我们调整了策略权限默认最小化不变但对L2级以下数据放开自助申请通道让用户不需要审批就能获取基础权限。敏感数据才走审批流程。这个分层处理之后审批压力下降了七成安全合规也完全没放松。5.3 Kerberos认证、标签识别、策略配置的实用排查表最后整理一份我们在项目中反复用到的排查速查表希望对正在落地的同行有用。问题现象排查方向解决方案大数据平台周期性认证失败Kerberos客户端与KDC服务器时间偏差统一配置NTP时间同步时间偏差控制在300秒内部分用户无法访问Hive表客户端票据过期或本地缓存有旧票据执行kinit -R刷新票据必要时重新执行kinit标签同步后下游平台未更新消息队列消息积压或消费失败检查MQ消费日志补推变更通知敏感字段在查询结果中未脱敏查询走了旁路通道未经过安全网关收敛数据库账号权限强制所有查询走统一入口策略匹配不生效ABAC属性获取不全比如用户部门属性为空检查身份源同步任务补齐用户属性字典Kerberos这个问题要再强调一下很多刚开始接触大数据安全体系的同事会在时间同步上栽跟头。KDC服务器和所有客户端节点的系统时间必须保持严格一致千万别因为图省事只在部分节点配了NTP。最好的做法是全线统一走同一个时间源配一次之后基本不用再管。另外标签识别的误报率一定要持续观测。规则上线后不要以为万事大吉建议每周抽检一次误报记录对于反复误报的规则要及时调整权重保证分类分级结果能持续取信于业务部门。我在实际项目中的体会是数据安全方案最容易失败的地方不在技术而在“数据的语言”和“安全策略的语言”没有对齐。分类分级和权限管控一体化本质上就是给这两个领域搭一座翻译桥。只要这座桥搭稳了后面无论是应对监管检查还是处理内部数据泄露风险腰杆都能挺得直一些。最后再分享一个实用小技巧如果你们公司还没有专门的数据安全管理委员会可以先从“数据分级评审小组”这种轻量组织入手拉上安全、运维、核心业务部门三方代表每月开一次碰头会。不用一开始就搞太大的组织架构先把机制跑起来比什么都强。
