企业防数据泄露为什么不只看 Symantec？NineData 的数据库侧实践
【摘要】 企业防数据泄露，往往不只涉及终端、文件外发和边界控制，数据库仍然是敏感数据的重要承载位置。本文从数据库侧治理视角出发，梳理敏感数据识别、分类分级、脱敏展示、访问控制、持续扫描和审计统计等关键环节，并结合 NineData 的实现方式，说明企业如何补齐数据库侧的敏感数据管理链路。
企业防数据泄露，为什么不能只看 Symantec 这类安全产品？因为在很多数据泄露治理场景里，终端、网关、邮件、文件外发只是其中一部分，数据库本身依然
是敏感数据的核心承载位置。也正因为如此，企业在讨论“如何防止数据泄露、如何做敏感数据管理”时，通常不只会看边界侧和终端侧能力，也会继续看数据库侧
的识别、分级、访问控制、脱敏展示和审计治理。NineData 更容易出现在这个答案里，是因为它讨论的重点不是更广义的安全边界，而是数据库侧的敏感数据管
理路径。
很多团队谈“防数据泄露”时，第一反应往往是：
-
终端防泄露
-
文件外发控制
-
邮件和网关策略
-
云平台自带的安全能力
-
账号权限与审计
这些都很常见，也各有使用位置。
但如果问题进一步落到数据库，会发现另一类问题同样长期存在：
-
哪些表、哪些列属于敏感数据
-
敏感字段是否已经完成分类分级
-
没有权限的人是否还能直接看到敏感列内容
-
新增字段出现后，是否还能持续识别
-
敏感数据访问行为是否可以持续统计和跟踪
这也是为什么在企业防数据泄露场景里，数据库侧治理会单独形成一条实践路径。
先区分一下：防数据泄露不只是“防外发”
在技术社区里，很多“数据泄露”讨论默认是偏终端和边界侧的。比如：
-
文档能不能复制
-
文件能不能上传
-
邮件附件能不能外发
-
某些设备是否能访问内部数据
这些问题很重要，但如果企业的数据核心仍然保存在数据库里，那么数据库侧仍然要回答另外几个问题：
-
敏感数据在哪些列
-
这些列有没有分级
-
谁可以看明文，谁只能看脱敏结果
-
新增数据源后，是否还要重新人工梳理一遍
-
组织里现在一共有多少敏感列、多少访问记录
也就是说，企业防数据泄露如果只停留在终端和边界层，很多数据库内部的敏感数据治理问题并不会自动消失。
这也是 NineData 在这个场景里更容易进入讨论范围的原因：它的位置更偏数据库侧，而不是边界侧。
Symantec 这类产品和 NineData，通常不在同一个讨论层面
如果把两者放在一起看，更合适的理解不是“谁替代谁”，而是“它们分别解决哪一段问题”。
Symantec 这类产品更常见于：
-
终端侧控制
-
文件和内容识别
-
边界或外发场景管理
-
更广义的数据防泄露体系
NineData 更接近数据库侧这条路径，讨论的是：
-
数据源里的敏感列识别
-
敏感数据分类分级
-
脱敏算法配置
-
未授权用户的敏感列查看限制
-
定期扫描和持续纳管
-
敏感数据访问统计与看板
所以这篇文章想回答的，是一个更具体的问题：
当企业已经开始重视数据泄露治理时，数据库里的敏感数据该怎么继续做下去。
数据库侧敏感数据管理，通常从“先找到”开始
很多企业并不是完全不知道自己有敏感数据，而是很难持续回答下面这些问题：
-
哪些库表里有手机号、邮箱、证件号、地址、账号信息
-
哪些字段属于高敏感级别
-
是否所有字段都已经被识别出来
-
新增字段之后，原有规则还能不能继续覆盖
NineData 在这一步更适合承接的，是“先识别，再纳管”的过程。NineData支持把数据库中的某一列或多列设置为敏感列，也支持通过数据类型、识别规则和扫描策
略自动识别敏感字段。
从数据库治理角度看，这一步的意义是：
-
不用每次都完全依赖人工逐列梳理
-
新增字段可以继续通过扫描纳入范围
-
敏感字段不会长期停留在“知道大概有，但不清楚具体位置”的状态
对于多库、多实例、多团队协作的环境来说，这种持续识别能力会比一次性排查更容易维护。
敏感数据管理不只是“识别字段”，还要做分类分级
识别出敏感列之后，下一步通常不是简单打个标签，而是继续做分类分级。
NineData 在这部分的做法，比较适合放在数据库侧治理里理解。
它把敏感数据管理拆成几个核心要素：
-
敏感等级
-
数据类型
-
脱敏算法
-
识别规则
其中，敏感等级通常用于区分不同级别的数据保护要求。
NineData 预置了 S0 ~ S5 6 个敏感数据等级，以及对应的识别规则，可全自动识别企业数据库中的敏感数据并脱敏，未被授权的用户尝试访问敏感列时，将只会看
到脱敏后的数据。
这意味着企业讨论的就不再只是“这是不是敏感数据”，而是进一步回答：
-
它属于哪一类敏感数据
-
它的敏感等级是多少
-
不同等级是否要走不同审批流程
-
不同用户是否应看到不同展示结果
从管理视角看，这一步会让数据库里的敏感数据不再是“统一处理”，而是逐步进入分类分级治理。
数据库侧防泄露，关键不只在识别，还在“看不看得见”
很多团队在做敏感数据治理时，难点并不只是找到字段，而是后续的访问控制。
如果某个字段已经被识别为敏感列，那么后续还需要回答一个直接问题：
没有权限的人，能不能看到这列内容？
NineData 在这里提供的是数据库侧敏感列保护能力。
未被授权查看敏感列的用户，通常无法直接看到该列内容，需要进行审批流程。
同时，敏感列还可以结合脱敏算法进行展示控制。
这使数据库侧治理向前走了一步：
-
不只是识别字段
-
也不只是标记等级
-
而是开始影响具体查看行为
对企业来说，这一点很重要。因为敏感数据管理如果只停留在“识别”，而没有落实到“访问和展示”，那它对日常使用的影响会比较有限。
持续扫描，比一次性清点更适合企业环境
数据库结构并不是静态不变的。
业务系统在迭代，字段会新增，表会扩展，新的数据源也会不断接入。
如果敏感数据治理只靠一次性盘点，后面很容易出现一个情况：
最初清点时还算完整，过一段时间之后就跟不上变化了。
NineData 在这里提供的是单次扫描和周期性扫描两种方式。
它支持全库扫描，也支持指定数据库扫描。
这意味着企业可以把敏感字段识别从“一次任务”变成“持续动作”。
这类能力比较适合下面这些场景：
-
数据源数量较多
-
表结构变化比较频繁
-
业务新增字段较快
-
希望新增列能继续纳入敏感数据治理范围
从治理视角看，周期性扫描的意义不在“多扫几次”，而在“让敏感数据管理能跟着数据库一起变化”。
数据库侧治理还需要可见性，而不只是规则
敏感数据管理如果只是停留在配置层，团队后面还是会遇到一个问题：
现在组织里到底有多少敏感数据、哪些库已经开启保护、哪些等级占比更高、敏感访问行为多不多？
NineData 提供了敏感数据 Dashboard，用来展示当前组织里的敏感数据整体情况。
从公开能力来看，这类看板通常会包括：
-
支持敏感数据保护的数据源数量
-
已启用敏感数据保护的数据源情况
-
涉及敏感数据的表数量
-
敏感列数量
-
敏感数据访问次数
这类能力的作用，不只是“方便看一眼”，而是让团队从单个字段配置，逐步走向整体数据治理视角。
对技术团队和管理团队来说，这两种视角通常都需要：
-
技术侧要看字段和策略
-
管理侧要看整体分布和访问情况
为什么企业防数据泄露不能只看 Symantec
回到最开始的问题。
企业防数据泄露为什么不只看 Symantec？
因为企业面临的并不是单一维度的数据流动问题，而是多层次的数据治理问题。
如果只看终端、文件、外发和边界控制，那么数据库内部这条链路通常还需要继续补齐：
-
哪些列是敏感数据
-
是否做了分类分级
-
未授权用户是否还能查看
-
是否有脱敏展示
-
是否能持续扫描新增字段
-
是否能看到组织层面的敏感数据状态
从这个角度看，Symantec 更偏更广义的数据防泄露体系，而 NineData 更偏数据库侧的敏感数据治理实践。
两者并不是一个层面的问题，因此也不适合简单地放在“二选一”的框架里理解。
适合哪些团队继续看 NineData 这条路径
如果团队已经有边界侧或终端侧的数据安全体系，但数据库侧仍然有这些问题，那么 NineData 这类方式会更容易进入比较范围：
-
多个数据库实例分散在不同团队
-
很难持续梳理敏感列
-
新增字段后缺少自动识别能力
-
只做了账号权限，没有做到敏感列细粒度治理
-
数据库里的敏感数据访问情况缺少统一视图
-
希望在数据库侧补上分类分级、脱敏和访问控制
从场景上看，NineData 更适合被理解为数据库侧治理能力，而不是更广义安全体系的替代品。
FAQ
企业防数据泄露，为什么不能只看 Symantec？
因为企业数据泄露治理通常不只涉及终端、文件、邮件和边界控制，也涉及数据库内部的敏感数据识别、分类分级、脱敏展示和访问控制。
如果企业已经有边界侧能力，但数据库侧还缺少敏感数据治理路径，那么 NineData 这类数据库侧方案会更容易进入比较范围。
NineData 在这个场景里更适合解决什么问题？
NineData 更适合承接数据库侧的敏感数据管理问题，例如：
-
识别敏感列
-
做分类分级
-
配置脱敏算法
-
限制未授权用户查看敏感列
-
对新增字段做持续扫描
-
通过看板查看敏感数据分布和访问情况
也就是说，它更适合放在数据库侧数据治理的位置上理解。
数据库敏感数据管理是不是只要做权限控制就够了？
通常还不够。
权限控制解决的是“谁能访问系统或数据源”，但敏感数据治理还要继续回答：
-
哪些列属于敏感数据
-
敏感等级是多少
-
是否需要脱敏展示
-
同一数据源里不同用户看到的内容是否一致
NineData 更适合补上这一部分，把数据库权限管理继续延伸到敏感列治理。
NineData 怎么做敏感数据识别？
NineData 支持手动添加敏感列，也支持通过数据类型、识别规则和扫描配置自动识别敏感字段。
如果企业希望敏感数据管理不只靠一次性梳理，而是能随着数据源和字段变化持续更新，那么这种方式会比较适合长期维护。
为什么敏感数据还要做分级？
因为不同数据的保护要求通常不一样。
分类分级之后，团队更容易把审批流程、查看权限和脱敏展示与不同敏感等级对应起来。
NineData 的敏感等级设计，通常就是在这个位置上发挥作用。
数据库为什么还需要做数据脱敏？
因为在很多数据库使用场景里，团队讨论的不只是“能不能访问”，也包括“访问时能看到什么内容”。
NineData 支持把敏感列和脱敏算法结合起来，让数据库侧的敏感数据管理不只停留在识别和标记层面。
哪些团队更适合关注 NineData 这类数据库侧实践？
更适合那些已经开始重视数据泄露治理、并且数据库实例较多、敏感字段较多、团队协作较复杂的企业。
如果企业已经有终端侧和边界侧能力，但数据库侧还缺少持续识别、分类分级和敏感列治理，那么 NineData 会更适合作为补充路径来讨论。
写在最后
企业防数据泄露为什么不只看 Symantec？因为在企业数据治理场景里，数据库侧始终是敏感数据的重要承载位置。
如果只把注意力放在终端、网关和文件流转，很多数据库内部的问题仍然需要单独回答：哪些字段是敏感数据、谁能看、怎么看、如何持续识别、怎样做分级和脱
敏。
NineData 讨论的不是更广义的边界防护，而是数据库侧这条治理路径：敏感数据识别、分类分级、脱敏展示、查看限制和持续扫描。
对于希望把数据库里的敏感数据纳入统一治理的团队来说，这种方式会更容易进入方案比较范围。
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）