Netwrix 1Secure 提供跨数据和身份的统一可见性——免费试用14天,享有完全访问权限。开始免费试用

资源中心博客

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

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

Oct 6, 2026

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

大多数数据安全程序只能保护它们已知存在的资产。库存之外的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) 快照在源实例删除后依然存在。
  • 影子AI采用: 生成式AI(GenAI)工具在有人将敏感数据粘贴到提示中或将工具连接到数据源时会复制敏感数据。一次Gartner对175名员工的调查,于2026年2月5日发布,发现超过57%的人曾使用个人GenAI账户进行工作,33%的人承认在未经批准的工具中输入敏感信息。

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

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

无人知晓存在的资产无法被控制

DLP、SIEM、访问治理和加密只覆盖指定的存储。无人编目或分类的存储库不受控制范围覆盖,降低可见性,扩大未管理的暴露,延缓事件响应准备。

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

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

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

Unit 42 2025年全球事件响应报告指出,未管理和未监控的资产,包括endpoints、应用程序和shadow 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 搜索 storage.googleapis.com/Bucket 资产类型,适用于 Google Cloud。
  2. 在 AWS 中运行 Elastic Block Store (EBS) AWSSupport-AnalyzeEBSResourceUsage 运行手册,以列出处于可用状态的卷和其源卷已不存在的快照。
  3. 检查 Azure 中的 Business Continuity Center,查找用户取消配置其源资源后遗留的已取消配置恢复点。
  4. 将合并的输出与当前库存进行比较,将任何没有命名且活跃项目的存储账户、卷或恢复点视为审查候选,因为本地工具只能看到有人注册的资源。

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

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

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

  1. 针对防火墙、代理或端点流量日志运行Defender for Cloud Apps Cloud Discovery,以显示所有正在使用的SaaS应用,包括那些没有Open Authorization (OAuth) 授权或管理员记录的应用。
  2. 将这些Cloud Discovery结果筛选到Microsoft的生成式AI应用类别,以专门隔离未经授权的AI工具。
  3. 将Purview浏览器扩展(适用于Edge和Chrome)导入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列出了六个机密性影响因素,并警告它们相互作用,因为单个因素可能表明影响程度较低,而另一个因素则可能覆盖它,导致影响程度较高。请查看完整的NIST影响指导以了解完整框架。

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

使用基于模式和上下文的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”),并在持续监控开始前根据least privilege和NIST AC-6应用。

为每个资产回答“谁可以访问,是否应该访问?”

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

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

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

资产在每个能够访问它的人类或非人类身份都有名称和确认的访问理由之前,均不安全。

将资产置于持续监控之下

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

影子数据逃避现有的访问控制和监控及记录数据访问的工具,这使得“known but unmonitored”成为一个独立于“unknown”的风险类别。持续的可见性将这两类转变为可衡量的Data Security Posture Management工作。

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

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

弥合发现到修复的差距

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

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

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

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

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

证明修复有效

在 Cheshire County Government,一台存储受监管数据的服务器出现了意外的27,000次文件变更激增。其五人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 如何将未知的数据资产转变为受管控且持续监控的库存部分。

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

分享到

了解更多

关于作者

Asset Not Found

Netwrix Team