暗数据(dark data)解析：为什么看不见的数据是安全问题

大多数安全计划都是围绕已知数据（known data）构建的：这些数据已被盘点(inventoried)、已被分类(classified)，并处于现行控制(active controls)的边界(perimeter)之内。在大多数组织中，已知数据只是少数。

另一半则是未被管理、未被分类，且往往被彻底遗忘的部分。入侵取证（breach forensics）与审计发现（audit findings）越来越多地指向的正是这些区域。

根据 Splunk 的《State of Dark Data》报告 调查，平均而言，55% 的企业数据属于“暗数据”：组织会存储这些数据，但却无法定位、分类或对其访问进行治理。

这一比例是跨行业的平均水平；在存在传统（遗留）基础设施、高 SaaS 采用率或治理投入有限的环境中，这一占比会显著更高。

实际含义很直接：组织投入的每一种安全控制（DLP、SIEM、 access governance、加密）都只能保护它所知道的数据。

什么是暗数据？

暗数据是指组织已收集并存储但已被遗忘的任何数据。因此，它不会被主动管理、分类或监控，导致其位置、敏感性和访问权限在事实上处于未知状态。

这当然包括 敏感材料，例如 PII、PHI、支付卡数据，以及已经偏离受治理系统范围的凭据；还包括在运营过程中生成的数据（日志、遥测、导出、备份），这些数据恰好包含了无人意识到被采集过的标识符。

尽管这两类都并非被设计为持久的受监管数据存储，但它们都会带来真实的安全与合规风险暴露。

暗数据（Dark data）与数据蔓延（data sprawl）等相邻概念不同，后者往往也会在同一讨论中被提及。数据蔓延是指数据在各系统中被无控制地生成并扩散：组织知道这些副本存在，但尚未对其进行治理。

两者的整改路径不同；如果把它们混为一谈，就会导致治理项目去解决错误的问题。

暗数据（Dark data）的类型

暗数据以不同形式出现，反映组织在正常运作过程中如何生成并积累数据；而且每种形式都有不同的风险特征。

• 运营数据与遥测数据： 在没有保留边界的情况下保留的 Web 服务器日志、应用程序追踪、SIEM 归档以及遥测数据管道，往往包含会话令牌、IP 地址，以及通过查询参数或 API 调用采集到的个人数据。
• 冗余副本与被搁置的导出： 为一次性项目创建的来自 CRM、ERP、HR 或临床系统的 CSV、Excel 和 JSON 导出文件，随后被留在共享驱动器中，既没有在职负责人，也没有删除计划。
• 测试与开发数据： 未进行脱敏或保留控制就将生产数据复制到开发（dev）、测试（test）或沙盒环境中，包含即使相关应用已不存在，仍可能保留客户或患者表的完整副本。
• 孤立的备份与旧版应用数据： 已停用系统的备份和归档数据集会在多年后仍保留大量敏感记录，但没有被指派的负责人对删除决策负责。

混合环境中暗数据所在的位置

上述类型会在可预测的基础设施位置中不断累积，这些位置往往不在标准安全与治理工具的覆盖范围之内。

云存储与对象桶

为迁移、概念验证或一次性分析任务创建的 S3、Azure Blob 和 GCS 桶，并且从未被停用，最终会作为未受治理的数据存储继续存在。

由于从未纳入正式的资产清单，这些数据通常不在 DLP 的覆盖范围内；其访问配置往往继承了创建时上下文中的过度宽松权限，并且完全被排除在访问审查之外。

传统文件共享、NAS 和协作空间

部门级文件共享和 NAS 设备会在多年的正常运营过程中不断积累未经审查的内容。 SharePoint 站点、Teams 频道 以及已完成项目中的 OneDrive 文件夹会在没有在职所有者的情况下继续存储合同、报告和数据提取件。

这些环境中保留着组织里最古老、最敏感的一部分数据，但又恰恰是最不可能被纳入监控规则或分类工具适用范围的地点之一。

备份、归档和日志存储库

长期备份、云端归档分层以及日志存储中包含凭据、会话令牌、PII 和 PHI，而这些数据从未被设计为需要长期保留。用于主动调试的日志详细程度设置在日志在缺少分类或审查的情况下跨多年的保留窗口持续保留个人数据时，会演变为合规责任。

SaaS 导出与 AI 工具集成

从核心业务系统导出到营销、HR 或产品 SaaS 平台的数据，存在于受管数据环境之外。AI 和自动化平台会将运营数据摄入到自身的存储或长期存在的缓存层中，这些内容很少出现在资产清单里，从而形成不断增长的暗数据类别，其生命周期中缺乏天然边界。

是什么导致暗数据不断积累

对于设计预防性控制的安全架构师而言，理解根本原因至关重要：被动式清理的速度更慢、成本也更高，而在源头减少积累则更有效。

缺失的数据生命周期治理

大多数组织都有数据创建流程，但没有相应的删除或重新分类流程。数据通过摄取管道、SaaS 集成以及用户生成的工作流进入系统，并且会无限期地保留，因为不存在用于将数据移出系统的自动化生命周期规则、所有权分配或审查触发器。只要保留期限无限制且分类是可选项，暗数据就会作为默认结果不断累积。

组织与工具孤岛

由某个团队创建的数据很少会进入另一个团队的治理范围。市场导出、开发者数据库副本、财务归档以及项目文件的转储，各自都会生成治理职能无法追踪的数据产物。

安全与数据治理团队通常缺乏用于盘点这些环境的工具，因此数据会在组织边界之间悄无声息地持续累积。

AI、自动化与云扩散

当在采用时缺乏治理要求时，每一次新的 AI 集成、自动化工作流和云服务都会默认成为暗数据的生成源。

这些工具会生成派生数据集、推理日志以及集成缓存；在未定义责任归属或生命周期边界的情况下，它们会持续存在。

AI 工具连接是增长最快的因素：与基于 LLM 的工具共享的数据可能会在 AI 供应商的基础设施中长期保存，且完全不在组织治理的范围之内。

为什么暗数据是一个安全问题

暗数据会增加数据泄露成本、扩大攻击面、带来监管暴露风险，并削弱组织为保护已知数据所依赖的控制措施。

你无法保护你看不见的东西

DLP、SIEM、访问治理以及加密保护的是它们所知道的数据信息库。任何从未被编目或分类的存储库，都不在这些控制措施的覆盖范围之内。根据 IBM 2025 Cost of a Data Breach Report，35% 的数据泄露涉及影子数据；与不包含影子数据成分的泄露相比，这类泄露的平均成本高 16%，且识别所需时间长 26.2%。

现有的安全工具并不擅长发现它

DLP 策略面向已知的渠道；SIEM 从已接入的系统摄取日志；而 IAM 和 IGA 则管理清单中资产的访问权限。这些工具都无法发现自己尚未知晓的内容。暗数据会在“发现”这一层逐项击败每个控制：如果某个存储库从未被纳入资产清单，DLP 就永远不会扫描它，SIEM 就永远不会监控它，而访问审查也永远不会覆盖它。

源自未受管理数据的监管风险

GDPR, HIPAA, CCPA以及大多数面向行业的框架会将包含受监管信息的未受管理数据存储视为合规失败。

数据最小化以及隐私设计（privacy by design）要求能够证明已清楚了解个人数据存放在哪里，并提供用于保留数据的文档化理由。

Data Subject Access Requests（DSARs）以及“删除权”请求在没有完整的数据清单的情况下，从结构上就很难履行；缺少此类清单也是“暗数据（dark data）”项目的特征。

审计与保证（assurance）的阻力

审计人员现在会直接询问非结构化且未受治理的数据。每一个未知的数据存储都要么成为在审计压力下需要手动调查的棘手例外，要么成为削弱更广泛控制性断言的审计发现。

具备结构化的发现（discovery）计划的组织（已定义的范围、文档化的方法论、当前盘点及整改日志）往往比那些在现场工作期间才出现未知存储的组织表现更好。

如何发现并治理暗数据（dark data）

目标是建立可视性与流程控制，以防止未知存储不断积累，同时对已存在的问题进行处理。

顺序很关键：发现（discovery）必须先于策略（policy）。因为基于不完整盘点构建的治理框架会产生虚假的保证。

步骤 1：界定范围，并按风险进行优先级排序

创建分层的范围清单。

1. 第 1 层：最可能存放受监管数据、且控制措施最薄弱的存储位置（与生产环境绑定的云对象存储、传统文件共享、Microsoft 365、SaaS 导出器）。
2. 第 2 层：备份、归档层和日志存储。
3. 第 3 层：测试与开发环境，以及已退役系统的归档。

在每个层级内，根据三个标准进行优先级排序：监管范围（GDPR、HIPAA、PCI DSS）、数据量以及自上次访问审查以来的时间。

对三个标准都达到高严重级别的存储位置，优先放到发现队列的前面。请记录范围界定（scoping）决策，以便下一次评估周期能够在此基础上不断完善，而不是从头再做一遍。

第 2 步：在范围内的存储位置上运行自动发现与分类

先部署用于发现和分类的工具，并优先针对最高优先级的存储位置进行扫描。将其配置为在无需事先了解数据存放位置的情况下，扫描文件系统、对象存储、数据库以及协作环境。

接着设置分类规则，以检测 PII、PHI、支付卡数据、凭据（credentials）以及任何特定行业所监管的内容。

先用只读模式运行第一次扫描，以建立基线。将结果导出为三个成果物：已发现的存储位置列表、每个存储位置的敏感度分级，以及一张有效权限映射图，显示哪些用户和组能够访问每个存储位置。

这些合并后的输出就是后续程序运作所依据的资产清单。

步骤 3：映射所有权并做出保留（留存）决策

为每个已发现的存储位置指定业务负责人。若无法确定负责人，则在规定的时间窗口内（大多数方案使用 30 天）向数据治理负责人升级处理以完成指派。没有负责人（未归属）的存储位置不能进入下一步。

一旦完成所有权指派，负责人需要回答两个问题：这份数据是否仍然需要，以及当前访问权限是否体现 least privilege？

未能通过第一次移动到删除队列的存储（在法律保留与保留期限检查之后），以及未能通过第二次移动到访问补救队列的存储。

同时通过这两个条件的存储将进入治理范围，并配备有文档化的负责人和定期审查节奏。

第 4 步：在范围内的存储上强制执行生命周期策略

为每个受治理的存储应用自动化生命周期规则：对对象桶使用云存储生命周期策略，对运营数据存储使用数据库保留策略，对归档层使用备份保留设置。

为每类数据设置默认过期间隔，并在需要无限期保留时要求明确且有时间限制的例外。

将每条生命周期规则与第 2 步生成的分类关联起来，这样被标记为“regulated”的数据就能自动触发正确的保留路径。

手动删除流程会变成积压任务（backlogs），而积压任务又会转化为永久的暗数据累积。因此目标是在默认情况下实现自动化，仅将手动审查保留给例外情况。

第 5 步：将持续发现落到运营层面

以明确的频率安排重复的发现扫描（大多数项目运行：Tier 1 每周、Tier 2 每月、Tier 3 每季度），并在现有盘点（inventory）之外出现任何新的存储位置（store）时发出告警。

配置发现平台，将分类结果和访问结果输入到 SIEM、SOAR 和 GRC 平台中，这样高风险位置就会与其他安全信号出现在同一套仪表盘（dashboard）上。

明确升级触发条件：新的高容量敏感数据存储库；突然发生的权限变更，能够广泛暴露受监管内容；或现有存储库中的分类结果骤增。

每个触发条件都会路由到指定的响应方，并配套补救SLA。最终产出的是：dark data 治理作为持续的运营能力来运转，而不是每季度一次的项目。

在下一次审计替你发现 dark data 之前，选择正确的方法

大多数 dark data 项目会先从策略入手，再在实现可见性之后推进。保留期限计划以及 data classification 相关框架会基于“凭记忆绘制”的数据地图来制定，但这永远无法与生产系统、归档和 SaaS 集成中实际存在的情况相匹配。

Netwrix Access Analyzer 可发现并识别 sensitive data，覆盖 Windows 文件服务器、NAS、SharePoint、Microsoft 365 以及主要数据库。它将每个存储库连接到有效权限分析，展示谁可以访问其中的内容。

对于存在于 AWS、Azure 和 GCP 等平台的云原生存储中的暗数据，Netwrix DSPM 可将发现与安全态势管理扩展到云数据仓库；同时，还提供对本地与混合 Microsoft 环境的 Access Analyzer 覆盖。

Netwrix Auditor 通过持续监控敏感数据的访问与修改方式来扩展这种可见性。三者合并，将静态清单转化为可执行的 data security 治理：未知的存储进入范围，以证据为依据跟踪整改进度，并且每个周期都会缩小已产生数据与已纳入治理的数据之间的差距。

请求演示，了解 Netwrix 如何帮助您在下一次审计替您发现漏洞之前，发现暗数据、治理访问权限并满足合规要求。