第3章：数据资产发现的四大挑战
做数据资产发现这件事，说起来简单——把数据找出来、分好类、打上标签。可真到了实战环节，你会发现事情远没那么理想。我个人在帮十几家企业落地DSPM项目时，几乎每次都会撞上同样的几堵墙。今天咱们就把这四堵墙掰开揉碎了聊聊。
3.1 影子数据：你看不见的才是最大的风险
什么叫影子数据？说白了，就是那些不在IT部门管控范围内的数据。我记得有一次帮一家金融客户做数据盘点，按照他们的资产管理台账，应该只有20个数据库实例。结果我拿扫描工具一跑，好家伙——47个，多出来的27个全是业务部门自己搭建的。
影子数据通常来自这几个场景：
- Shadow IT 应用——业务部门自己采购的SaaS工具，数据直接往里灌，根本没过IT的眼
- 个人云盘同步——员工把公司数据同步到个人网盘、OneDrive、甚至微信文件传输助手
- 临时开发环境——开发人员为了调试方便，在本地或临时服务器上复制了生产数据
- 测试数据副本——测试环境里的数据快照，用完没人删，一存就是好几年
- 邮件附件散落——含敏感信息的Excel报表，通过邮件在组织内无限转发
关键指标：根据Gartner的报告，组织内平均有40%-60%的数据资产是IT部门不知道的。这意味着你做的所有安全策略，实际覆盖率可能不到一半。
我有个朋友之前在一家电商公司做数据治理，他们花了三个月建了一个超漂亮的数据目录。结果第二年做审计时发现，目录里的数据只占实际数据量的35%。剩下的65%呢？散落在各个业务部门的共享文件夹里、员工的本地硬盘上、甚至一些已经停用的云存储桶里。
实战建议：别只盯着资产管理台账。先跑一遍络扫描，把“意外发现”的数据资产单独标记出来。我曾经在一个客户的AWS账号里发现了一个三年前创建的S3桶，里面存着完整的客户信用卡数据——全明文。
3.2 数据蔓延：增长速度远快于治理速度
数据蔓延，就是数据像野草一样疯长。你想想看，十年前一个企业每天产生几百MB数据就算多了，现在呢？每小时几个TB都算正常。问题不在于数据量大，而在于数据失去了管控。
我在项目中遇到过这样的情况：一个制造企业，产线传感器数据每秒钟都在写入数据湖。但数据湖里80%的数据从写入那天起就再也没被读过。存储费用在涨，数据分类的工作量在涨，但数据价值却在下降。
数据蔓延带来的具体问题：
| 维度 | 典型表现 | 后果 |
|---|---|---|
| 存储膨胀 | 同一份数据被不同部门重复存储，格式各不相同 | 存储成本飙升，备份窗口拉长 |
| 版本混乱 | 同一张报表有"最终版"、"最终版v2"、"打死不改版" | 数据一致性无法保证，审计时说不清哪个版本是权威 |
| 冗余副本 | 数据从生产库->ETL中间库->分析库->报表库->归档库，层层复制 | 敏感数据暴露面成倍扩大 |
| 冷数据积压 | 超过90天未访问的文件占总体积的70%以上 | 大量资源被无效数据占用 |
避坑指南：我曾经帮客户做数据蔓延治理时，发现他们一个Hadoop集群里存着5年前的点击流日志——这5年产生的数据够再建三个数据中心了。血泪教训：在数据资产发现阶段，就要把数据生命周期策略一起定下来，别等数据堆成山了再想办法。
怎么应对数据蔓延？我个人习惯在项目启动时先做一次数据热度分析。把数据按访问频率分成热数据、温数据、冷数据。热数据保留在高性能存储上，温数据降级，冷数据归档或删除。这一步做完，往往能释放30%-50%的存储空间。
3.3 多云环境：统一视图难如登天
现在的企业，很少只用一家云厂商。AWS跑核心业务、Azure做AD和Office 365、GCP搞AI训练、阿里云管中国区业务……这种情况太常见了。但问题来了——每个云厂商的数据资产管理方式都不一样。
AWS用S3 Inventory做数据清单，Azure用Purview，GCP用Data Catalog，阿里云用DataWorks。它们的数据格式、分类方式、API调用频率限制、收费模式全都不一样。你想把所有数据资产拉到一个平台上看？光是适配这些接口就能写几百行代码。
多云环境下的数据资产发现，难在三个层面：
- API差异——每家云厂商的数据清单API参数、返回格式、分页逻辑都不同
- 网络隔离——数据在VPC内部、跨区域云服务之间、本地数据中心之间流转，路径不可见
- 数据驻留合规——同一份数据可能在不同区域有副本，哪些是主本、哪些是副本？
我记得有一次给一个跨国企业做项目，他们的数据分布在AWS美西、Azure西欧、阿里云华东三个区域。光是搞清楚每个区域有哪些存储桶、哪些数据库实例，就花了两周。最头疼的是，同一个客户的数据在三个区域都有副本，但每个副本的标签、权限、生命周期策略完全不同。
一个小技巧：不要试图一次性把所有云厂商的数据都拉通。先选一家数据最多的云作为试点，把发现流程跑通，再横向扩展到其他云。这样即使进度慢一点，但至少不会一开始就被各种API限制卡死。
3.4 权限复杂度：谁能碰什么数据，根本说不清
权限复杂度，是大家最容易低估的一个挑战。你可能会想：权限管理嘛，有IAM不就行了？但实际情况远比这个复杂。
一个典型的中型企业，数据资产的访问权限通常是这样的：
- 直接权限——通过IAM用户或角色直接授予的访问权限
- 组权限——通过AD或LDAP组继承的权限，人进组就有，人走组就丢
- 资源策略——Bucket Policy、KMS Key Policy等直接绑定在资源上的策略
- 信任关系——跨账号、跨云服务的信任策略，允许某个服务代表用户访问数据
- 临时授权——STS临时令牌、Pre-signed URL等有时效的授权方式
- 应用代理——通过中间应用层访问数据库，数据使用者本身没有直接的数据库权限
你想想看，一个数据文件可能同时受IAM策略、Bucket Policy、ACL、服务控制策略（SCP）四层控制。要搞清楚“谁到底能不能访问这个文件”，就得一层层地解析策略逻辑。最麻烦的是，很多权限是隐式的——比如一个S3 Bucket的公共访问权限默认是关闭的，但某个子账号通过Resource-based Policy又对这个Bucket开放了特定路径的访问。
避坑指南：我曾经做过一个权限审计项目，发现某公司的财务数据库居然被一个已经离职两年的员工的IAM账号访问着。原因是他当年所属的AD组一直没有被清理，而数据库的权限是通过AD组继承的。从那以后，我建议所有客户在做数据资产发现时，一定要同时跑权限分析——否则你发现的资产可能根本不可控。
权限复杂度带来的最大风险是权限爆炸——权限越积越多，人走了权限还在，服务换了角色还在，最后没人知道数据到底被谁访问过。DSPM项目里，我建议把“权限可见性”作为数据资产发现的第三个维度（前两个是资产清单和数据分类）。
| 权限类型 | 发现难度 | 常见隐患 |
|---|---|---|
| IAM策略 | 中等 | 策略过于宽松，Action设为 * |
| Resource-based Policy | 高 | 公共读写权限误开启 |
| 组继承 | 低 | 组内僵尸账号未被移除 |
| 跨账号信任 | 极高 | 信任范围过大，信任整个外部账号 |
| 临时授权 | 极高 | Pre-signed URL有效期过长 |
| 应用代理访问 | 高 | 中间层数据库账号共享，审计日志无法定位到人 |
核心观点：数据资产发现不只是“找到数据在哪里”的技术问题，更是“谁能碰到这些数据”的治理问题。缺少权限维度的资产发现，就像拿到了一个装有宝藏的保险柜列表，却没有一把能打开的钥匙。