2026年特权访问管理魔力象限™:Netwrix连续第五年获认可。 下载报告。

资源中心博客

如何查找和保护未知的数据资产

如何查找和保护未知的数据资产

Oct 6, 2026

未知的数据资产造成库存缺口,削弱了安全性、合规性和网络弹性,因为未跟踪的存储不在分类、访问治理和持续可见性范围内。团队无法评估敏感内容,验证有效访问,或随着资产和权限的变化保持Data Security Posture Management的最新状态。持续的发现、分类和访问审查弥补了这一差距。

大多数数据安全程序只能保护它们已知存在的资产。库存之外的shares、buckets和导出也不在分类、访问治理和持续监控范围内,造成盲点,使敏感数据可能长时间暴露。

这些盲点出现在泄露数据中。影子数据出现在分析的35%的泄露事件中,IBM's Cost of a Data Breach Report 2024,这是最新一期区分影子数据的报告。涉及影子数据的泄露事件识别和遏制时间更长,平均生命周期为291天,平均成本为527万美元。不完整的清单削弱了检测和响应能力。

这就是为什么国家标准与技术研究院(National Institute of Standards and Technology)的网络安全框架(NIST CSF)2.0强调维护数据清单及相应元数据的原因。

这些清单为DLP、分类、访问审查和持续监控等控制措施提供了基础。当数据存储缺失于清单时,这些控制措施覆盖它的可能性就会大大降低。

什么是未知的数据资产?

未知数据资产是指组织当前清单中缺失的任何数据存储,例如超出项目期限的共享、次级云账户中的存储桶,或离职分析师留下的导出文件。该术语涵盖dark data和shadow data,但无论标签如何,只要无人管理,该资产就值得调查。

Term

What creates it

Where it typically lives

Urgency signal

Dark data

Data collected but never analyzed or acted on

Cloud buckets, legacy shares, SaaS exports, AI caches, log repositories

Lower until classification shows sensitive content

Shadow data

Unknown data assets

This guide's operational term for any asset absent from the current inventory, for any reason

Anywhere: on-premises shares, cloud storage, backups, forgotten SaaS repositories

Depends on content; the inventory gap defines the category

为什么未知的数据资产不断堆积

新资产到达的速度快于任何手动清单记录,因此在时点审查后差距仍然存在,未能关闭。

  • 员工自助存储: 当批准的选项较慢或更受限制时,员工会开设自己的云存储账户。Netskope Threat Labs' Cloud and Threat Report: 2026 发现平均组织中31%的用户每月上传数据到个人云应用,且60%的 insider threat 事件涉及个人云应用实例。
  • SaaS扩展: SaaS的采用加剧了更广泛的技术扩展。Forrester 2024年第二季度Tech Pulse调查 发现77%的美国技术决策者报告中度到广泛的技术扩展。
  • 孤立系统: 应用程序退役可能会留下备份和导出文件,这些文件比源系统存在时间更长,且无人负责。云平台将此设为默认行为,因为手动创建的Amazon Relational Database Service (RDS)快照在源实例被删除后仍然存在。
  • Shadow AI 采用情况: 生成式 AI(GenAI)工具在有人将敏感数据粘贴到提示中或将工具连接到数据源时会复制敏感数据。一次 Gartner 对175名员工的调查,于2026年2月5日发布,发现超过57%的人在工作中使用了个人GenAI账户,33%的人承认在未经批准的工具中输入了敏感信息。

为什么库存差距比大多数安全团队想象的更重要

清单范围决定了每个Data Security Control可以覆盖的资产。超出该范围的暴露则未被测量。

没有人知道存在的资产无法被控制

DLP、SIEM、access governance 和加密仅覆盖有人指向的存储。无人编目或分类的存储库不受控制覆盖,降低可见性,扩大未管理的暴露,延缓事件响应准备。

大多数组织知道这一差距,但尚未弥合

The Netwrix 2026 Data and Identity Security Report 调查了2,317名IT和安全领导者,得出了严峻的结论。55%的组织未持续维护敏感数据清单,74%无法获得其敏感数据所在位置及可访问身份的统一视图。持续的清单维护和统一的访问可见性仍然不常见。

未知资产在违规取证中出现比例过高

Unit 42 2025年全球事件响应报告指出,未管理和未监控的资产,包括端点、应用程序和影子IT,是攻击者容易进入的入口。

McLeod Health于2026年3月5日在一台正在退役的服务器上发现了可疑文件,根据其事件通知,这是在2025年10月17-18日未经授权访问137天后。持续的资产可见性有助于在事件响应时更快调查并增强网络弹性。

Netwrix DSPM在本地、云端和SaaS环境中发现敏感数据,并优先处理访问风险,帮助安全团队专注于最重要的事项。预约演示。

一种用于查找未知数据资产的可重复方法

每个环境都有自己的枚举工具和盲点,因此应针对每个环境运行发现,以考虑这些差异。

首先获得对每个环境的只读访问权限

Discovery 只能发现其账户可见的内容,因此在运行任何枚举之前,请请求对每个环境的只读访问。使用命名的专用身份,而非共享管理员凭据,以确保每个 discovery 查询都可追溯。

  • 本地部署:对Active Directory的读取访问权限、每台服务器的远程管理路径,以及对每个查询的SQL Server实例的登录。下面的工作流程通过CIM会话访问远程服务器。
  • AWS:登录管理账户或委派管理员,创建组织范围的AWS Config聚合器,并将托管策略AWSConfigRoleForOrganizations附加到其角色。
  • Azure:在管理组级别授予读取权限。Azure Resource Graph不会返回账户无法读取的资源的结果,因此缺少权限可能会使部分资产看起来为空。
  • Google Cloud:在您搜索的组织、文件夹或项目上授予 Cloud Asset Viewer(roles/cloudasset.viewer)权限。
  • Entra ID 和 SaaS:列出 通过 Microsoft Graph 的委托 OAuth 授权 需要 Directory.Read.All 权限,且登录的管理员需要拥有 Global Reader 等角色。
  • 备份和快照:它们位于备份控制台或云快照API之后,而非源系统,因此应包含在访问请求中。
  • 未注册的应用:无人注册的应用没有可读取的管理员记录。请改为从Defender for Endpoint、日志收集器或上传的防火墙和代理日志中提供Cloud Discovery数据。

任何只读账户无法访问的内容本身即为一项发现。将其记录为访问缺口并升级以作出决策。

本地服务器、共享和数据库

从 Active Directory 开始,向外扩展,因为这是获取完整本地系统检查列表的最快路径。

  1. 使用 Get-ADComputer 从 Active Directory 中提取文件服务器主机名,遵循 Get-ADComputer 参考。
  2. 通过 Common Information Model (CIM) 会话枚举 Server Message Block (SMB) 共享,使用 Get-SmbShare -Special $false 来排除管理共享。
  3. 在 SQL Server 中提取 sys.servers,以返回所有链接或远程服务器,这些服务器通常指向无人记录的实例。

使用此PowerShell工作流一次运行步骤1和2:

      $servers = Get-ADComputer -Filter * -Properties OperatingSystem |
    Where-Object OperatingSystem -Like '*Server*'
foreach ($server in $servers) {
    $session = New-CimSession -ComputerName $server.DNSHostName
    Get-SmbShare -CimSession $session -Special $false
    Remove-CimSession $session
}
      

输出是完整的共享和服务器清单,可与已有文档进行比较;文档中缺失的部分即为未知资产。

云存储、备份和数据库

每个提供商都保留自己的库存工具,因此必须在每个提供商中分别运行枚举,才能比较结果。

  1. 列举每个使用中的供应商在组织级别的存储资源。AWS Config 配置聚合器涵盖 Amazon Web Services;Azure Resource Graph 查询 Microsoft.Storage/storageAccounts 在管理组范围内覆盖多达 10,000 个 Microsoft Azure 订阅,Cloud Asset Inventory 搜索 Google Cloud 的 storage.googleapis.com/Bucket 资产类型。
  2. 在AWS中运行Elastic Block Store (EBS)的AWSSupport-AnalyzeEBSResourceUsage运行手册,列出处于可用状态的卷和其源卷已不存在的快照。AWSSupport-AnalyzeEBSResourceUsage runbook in AWS to list volumes in available state and snapshots whose source volume no longer exists.
  3. 检查 Azure 中的 Business Continuity Center,查找用户取消配置其源资源后遗留的已取消配置恢复点。
  4. 将合并的输出与当前库存进行比较,将任何没有命名且活跃项目的存储账户、卷或恢复点视为审查候选,因为本地工具只能看到有人注册的资源。

当前清单中缺失的任何结果,按定义都是未知资产,无论源系统是否仍在运行。2025年,安全研究员Jeremiah Fowler发现了378GB的Navy Federal Credit Union备份文件正是以这种方式暴露,存放在无人监控的公共Amazon S3存储桶中。

SaaS 应用程序、OAuth 授权和 shadow AI

Entra ID 和治理仪表板仅显示已被某人注册或同意的应用,因此查找无人注册的应用需要一个基于流量的单独步骤。

  1. 针对防火墙、代理或端点流量日志运行Defender for Cloud Apps Cloud Discovery,以发现所有正在使用的SaaS应用,包括那些没有Open Authorization (OAuth) 授权或管理员记录的应用。
  2. 将这些Cloud Discovery结果筛选到Microsoft的生成式AI应用类别,以专门隔离未经授权的AI工具。
  3. 将适用于 Edge 和 Chrome 的 Purview 浏览器扩展集成到 Insider Risk Management 的 Risky AI 使用模板中,该模板可检测已接入设备上包含敏感信息的提示和响应,并捕获 Cloud Discovery 流量日志无法看到的内容。
  4. 请单独审查外部共享链接,因为标准的SharePoint共享报告排除了Anyone链接;SharePoint管理中心的Data Access Governance报告包含它们,但需要相应的SharePoint管理插件,并覆盖28天的时间窗口。
  5. 在任何批准的AI部署之前,运行必需的SharePoint管理插件“Everyone Except External Users (EEEU)”报告,该报告列出过去28天内与整个组织共享的前100个站点。Copilot上线的那一刻,这些站点都将可通过AI搜索,因为Copilot的响应基于用户已获权限访问的数据。

如何判断哪些未知资产重要

并非所有未跟踪的资产都需要同等的紧迫性;内容和访问应决定优先顺序,无论资产位置多么隐蔽。

优先考虑内容而非位置

包含personally identifiable information (PII)、protected health information (PHI) 或支付卡数据的资产是紧急的,无论其路径多么隐蔽;非敏感数据的副本可以等待。

NIST SP 800-122 列出了六个机密性影响因素,并警告它们相互作用,因为单一因素可能表明影响程度较低,而另一个因素则可能将其覆盖为高影响。请查阅complete NIST impact guidance以了解完整框架。

在排除任何内容为噪声之前先进行分类

使用基于模式和上下文的classification来区分真实暴露与噪声。敏感信息类型的Purview置信度级别为65、75或85;低设置捕获最多匹配和最多误报。

已知的测试主账户号码,如Visa的4111111111111111,会通过Luhn校验,因此应通过允许列表或精确匹配参考表将其排除,以免浪费修复时间。

首先标记广泛访问和敏感内容

NIST SP 800-122 解释说,更多的人和系统访问 PII 会增加泄露其机密性的风险。将 Everyone、Authenticated Users 或开放共享链接可访问的敏感数据视为首要修复层级,优先于访问权限严格的数据。

如何保护您发现的未知数据资产

Netwrix 2026报告发现,75%的基于事件的数据泄露始于身份被攻破或权限配置错误,因此身份贯穿后续的每一步。

首先修复访问权限

对于每个新发现且确认含有敏感数据或广泛暴露的资产,首先限制过度访问;如果内容的敏感性尚不明确,请及时分类以确定最终修复优先级。

无人审查的权限使资产暴露,Verizon 2026 Data Breach Investigations Report发现,半数权限配置错误的发现几乎花费了八个月才解决。

从ACL中剥离Everyone和Authenticated Users,过期Anyone链接(CISA的ScubaGear基线将默认共享范围设置为“Specific people”),并在开始持续监控之前根据NIST AC-6应用least privilege。

回答“谁可以访问此项,他们应该访问吗?”针对每个资产

回答该问题需要进行有效访问分析,因为原始ACL无法显示完整结果。某些identity路径需要单独关注。

在 Microsoft Entra ID 中,transitiveMemberOf 会将用户和服务主体的嵌套组展平,但应用程序分配不会传递到嵌套组,因此仅目录枚举会高估谁可以打开应用。

所有链接完全存在于目录查询之外,因此请单独审查共享链接审核,并在审查中包括非人类身份。

资产在所有能够访问它的人工或非人工身份都有名称且访问理由得到确认之前,均不算安全。

将资产置于持续监控之下

在清点资产并纠正访问权限后,应用与其他所有地方相同的持续可见性,包括文件共享审计事件或等效的云审计轨迹,以及NIST CA-7持续监控和CM-3变更控制,确保权限不会回退。

影子数据逃避现有的访问控制和监控及记录数据访问的工具,使“已知但未监控”成为独立于“未知”的风险类别。 Data Security Posture Management的持续可见性将这两类转化为可衡量的工作。

Netwrix 如何帮助发现和保护未知的数据资产

大多数发现工作停滞在同样的三点:知道什么是真正敏感的,知道谁能访问,以及在有人询问时证明这两点。

弥合发现到修复的差距

Netwrix DSPM 提供了查找和保护敏感数据、优先处理合规风险以及解决混合环境中风险访问的综合能力。

Netwrix Access Analyzer 作为其企业级Data Security Posture Management引擎,具备数据发现、分类、Data Access Governance,以及涵盖文件系统、SharePoint、数据库和云存储的40多个数据收集模块。

将原始权限转化为有效访问

Access Analyzer 解析嵌套的组成员身份,显示用户或账户实际拥有的访问权限,而非对象上列出的原始权限,方便团队直接审查有效访问,而无需手动重建。

基于风险的优先排序随后将修复工作指向结合了开放或过度访问与已确认敏感内容的敏感数据,遵循本指南推荐的相同分诊流程。团队可以分配数据所有者并跟踪针对暴露风险的修复决策,将一次性清理转变为可重复的治理流程。

证明修复有效

在 Cheshire County Government,一台存储受监管数据的服务器出现了27000次文件变更的意外激增。其五人IT团队将变更追踪到权限配置错误,并使用 Netwrix Auditor 对Active Directory和Windows文件服务器进行了调查,15分钟内完成,而手动日志审查则需要数天。

First National Bank Minnesota 重建了其 Active Directory 环境,将收入验证记录、社会保障号码和就业历史严格限制在知情必要范围内。Netwrix Auditor 精确显示了这些敏感数据的位置及可访问人员,银行在预算的六个月内完成了重建,实际只用了三周。

在整个资产中扩展相同的模型

Access Analyzer 支持跨本地和云数据源的发现与分类,包括 Microsoft 环境和 Amazon S3,同时支持 Azure Files,因此相同的分类和访问审查模型可从文件服务器延伸到云和 SaaS 存储库。

云存储和SaaS OAuth连接通常是最易防御的起点,因为大量应用资产以影子IT形式出现;从那里开始,同样的审查扩展到本地共享、备份和导出。

在成为安全漏洞之前关闭库存差距

库存差距不会长时间停留在文档问题上。一旦未知资产持有敏感数据或开放访问,它就成为安全控制差距,届时成本将体现在违规时间线上,而非电子表格行中。

在每个环境中持续运行发现,优先考虑内容和访问权限而非便利性,并通过监控闭环,确保一次出现的资产不会再次消失。

请求演示,了解 Netwrix DSPM 如何将未知的数据资产转变为受控且持续监控的库存部分。

关于如何查找和保护未知数据资产的常见问题

分享到

了解更多

关于作者

Asset Not Found

Netwrix Team