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

资源中心博客

Teams 扩散:管理 Microsoft Teams 的激增

Teams 扩散:管理 Microsoft Teams 的激增

Mar 2, 2026

Teams 扩张(sprawl)发生在 Microsoft Teams 的创建速度超过治理能力时,导致缺乏管理的工作区、责任归属不清以及数据暴露失去控制。由于每个团队都会生成一个 Microsoft 365 Group 以及相关的连接服务,扩张会扩大访问风险、使合规变得更复杂,并提高运营成本。要预防这一问题,需要在 Teams、SharePoint 以及 identity 之间实施生命周期控制、强制执行所有权以及提升可见性。

Teams 扩散是 Microsoft 365 环境中最容易被忽视的安全风险之一。当所有员工都能在无需审批、没有命名规范或到期策略的情况下按需创建团队时,最终会产生数百个缺乏治理的工作区:没有明确的负责人、命名不一致且数据分散。

这种治理缺口会带来可衡量的风险。Netwrix 2025 Cybersecurity Trends Report指出,业务用户的错误或疏忽已连续三年位列前三大安全挑战。

Teams 扩散正是这种风险如何显现的经典案例:出于良好意图的协作决策,如果缺少护栏,就会在整个组织范围内造成安全与合规方面的暴露。

什么是 Microsoft Teams 扩散?它为什么会发生?

Microsoft Teams sprawl 是指在你的 Microsoft 365 环境中,团队、频道和内容不受控制地无限扩张。这不只是“团队太多”这么简单。当团队创建速度超过组织跟踪所有权、执行访问控制以及盘点每个工作区内数据的能力时,就会出现这种情况。

该问题会迅速叠加,因为 Teams 并不是孤立存在的。每创建一个团队,就会自动生成底层的 Microsoft 365 Group,以及关联的 SharePoint site 、共享邮箱和 OneNote 笔记本。此类扩张带来的是实实在在的安全与合规暴露,而不仅仅是数字上的“杂乱”。

那为什么会发生这种情况呢?Microsoft 365 默认启用 Teams 创建,而平台出厂时没有审批工作流、没有命名要求,也没有到期策略。随后,有四个因素推动 sprawl 在环境中进一步蔓延:

  • 宽松的默认设置奠定了基础:Microsoft 365 Groups 的创建在开箱即用的情况下对所有用户都已启用。系统内没有原生的审批机制,没有命名策略强制执行,也没有自动的生命周期管理——除非你自己进行配置。
  • 疫情加速了一切: 当组织在 2020 年匆忙启用远程办公时,IT 团队更重视让 Teams 正常运行,而不是对其进行治理。来自 2020-2021 年间的这类遗留 sprawl 往往仍未得到处理。
  • 对技术专业知识的要求会形成障碍: Teams 管理中心无法限制团队创建。该治理控制位于 Microsoft Entra ID PowerShell 和 Entra 管理中心。缺乏 PowerShell 专业知识的组织可以使用第三方治理平台,这些平台提供基于模板的自动化,而无需具备脚本编写知识。
  • 可视性不足会加剧问题: 原生使用报告只显示过去 28 天内的有限活动数据。原生并不提供对不活跃或被放弃团队的报告。你无法修复看不见的问题,而微软的原生工具会留下显著的可视性缺口。

这些根本原因不仅会带来运维方面的麻烦。随着团队蔓延问题得不到处理,安全、合规和财务方面的具体风险也会不断加剧。

如何判断组织存在 Teams 蔓延问题

如果以下任何情况听起来都很熟悉,那么蔓延(sprawl)很可能已经开始占据主导:

  • 缺少活跃所有者的团队: 没有所有者的团队,或拥有 5 位及以上所有者的团队,会导致问责关系被稀释到以至于没人真正对团队内部的内容负责。
  • 90 天以上无活动: 对已完成项目缺少归档策略、长期处于闲置状态的团队,表明缺少生命周期策略。即使团队不活跃,它仍然携带权限和数据。
  • 未受控制的访客访问: 2025 年 11 月的 Teams 更新(MC1182004)默认启用了用户与任意电子邮件地址开始聊天的能力。如果您最近没有审计访客访问策略,外部用户可能拥有的访问权限比您想象的更多。
  • 重复且不一致的命名: 名称相似的多个团队、"Project"或"Test"这类通用标签,以及在描述中缺少上下文信息的团队,都表明缺少命名规范。
  • 未配置过期策略: 如果团队无论是否在使用都将无限期保留,那么每个已完成项目团队都会保持活动并可访问,从而扩大您的攻击面,并使合规审计更加复杂。
  • 无限制的团队创建: 如果你尚未通过 Microsoft Entra ID 配置创建限制,那么每位用户都可以在缺乏监管的情况下创建新的团队。这是默认 Microsoft 365 配置,而大多数组织从不对其进行更改。

Teams 过度扩展带来的业务与安全风险

缺乏治理的 Teams 环境会在安全暴露、合规失败以及运营成本方面带来风险。每一项都会加剧其他问题,而当它们叠加在一起时,就说明应将“过度扩展”视为安全问题,而非简单的 IT 后勤维护任务。

1. 安全暴露

最直接的风险是未经授权的访问。当团队在缺乏监督的情况下不断扩张时,成员管理就会崩溃。前员工会保留访问权限,访客用户会无限期地停留在系统中,并且权限分配会在没有相应移除的情况下不断累积。其结果是 access control 特权范围逐步扩大(privilege creep),且随着每一个未受管理的团队而愈演愈烈。

这种访问问题会引发数据可视性问题。PHI、PII、受控非机密信息(Controlled Unclassified Information,CUI)以及财务记录散落在缺乏管控的各个团队中,使得无法建立集中式盘点(inventory)。

原生的 Microsoft 工具可以向你展示某个特定团队内部有什么,但它们并不提供用于在数百个不断扩张的团队及其关联 SharePoint 站点中定位敏感数据所需的 audit trails

与此同时,缺乏管控的团队创建实际上会在本应被管理的平台内“催生”影子 IT。员工并没有恶意行为,但当任何人都可以在没有 IT 监督的情况下创建工作区并存储数据时,就等于绕过了为应对正是这类风险而设置的控制措施。

2. 合规失败

团队的无序扩张会在多个监管框架中造成风险暴露:

  • HIPAA: 当受保护的健康信息(PHI)落入未被监控的团队时,组织将失去对受保护健康信息实施最小权限访问的能力。若发生数据泄露,60 天的通知要求假设你能够确定 PHI 存在于何处;但面对数百个缺乏治理的团队,你做不到。
  • SOC 2: 审计员期望看到证据,证明你的环境中访问控制能够被一致地应用。团队的无序扩张会制造出他们正在寻找的那种不一致:成员资格缺乏管理的工作区、没有责任人对所有权进行问责,以及没有审计追踪来表明谁访问了什么。
  • CMMC 2.0: 对国防承包商而言,无序扩张会削弱评估人员所评估的访问控制实践。若你的 Teams 环境无法证明对 Controlled Unclassified Information(CUI,受控的非机密信息)实施了受控访问,这一差距可能会让你失去合同资格。
  • GDPR: 大量涌现的团队会在不再需要的情况下继续保留个人数据;当你无法定位某个人数据的所有实例时,“被遗忘权(right to be forgotten)”几乎无法实际履行。

eDiscovery 会加剧这些合规风险。Microsoft Teams 通过 Microsoft Purview 支持 eDiscovery,但这种“失控扩张”会使其在实际运营中变得不切实际。

在数百个未受管理的团队之间进行内容搜索会变得呈指数级困难;为法律保全(legal hold)识别需要的工作区几乎不可能;沟通合规监测也无法扩展。

3. 运营与财务成本

安全与合规风险最受关注,但失控扩张也会持续拖累 IT 资源。每一个未受治理的团队,最终都会变成需要有人进行处置分诊(triage)的工作区:

  • 确定归属
  • 评估其是否包含敏感数据
  • 决定是归档还是删除

在大多数组织中,这种分流并不会主动提前进行,因此会一直堆积,直到合规审计或安全事件迫使组织处理问题;此时的清理就变成了应急措施,而不再是常规流程。

后台会不断累积存储成本。每个团队都会生成对应的 SharePoint 站点;如果没有设置到期或保留策略,不活跃的团队会无限期保留文件、聊天记录和共享文档。

拥有数百个“孤立团队”的组织,正在为毫无业务用途的存储付费,同时还会产生他们尚未纳入考量的责任风险。

还有一个是取证(discovery)成本。当法律或合规团队在诉讼或监管询查期间需要在缺乏治理的环境中进行搜索时,eDiscovery 处理成本会随着涉及的工作区数量而按比例增加。

本应是有针对性的搜索,却变成了覆盖数百个团队的“大范围扫描”:命名不一致、责任归属不清、且缺乏数据分类。由此带来的低效会直接转化为可计费工时增加、时间表延误,以及在取证(discovery)过程本身中的暴露风险加大。

如何防止新的 Teams 蔓延(sprawl)

与 Teams 创建、命名和到期相关的治理控制都位于 Microsoft Entra ID 级别,而不是在 Teams 管理中心(Teams Admin Center)中。要把预防做对,意味着需要在目录(directory)级别配置四项内容。

限制创建团队(team creation)

使用 Microsoft Entra ID PowerShell 或 Entra 管理中心创建一个专用安全组,其中包含所有被授权创建 Teams 的用户。然后配置目录级设置,将创建权限限制为仅该组。AzureADPreview 模块于 2025 年 3 月 30 日达到支持终止,因此 Microsoft 现建议为长期支持使用 Microsoft Graph PowerShell SDK。

避免实施会造成 IT 瓶颈的“一刀切”限制。目标是将创建流程引导到理解您的命名规范和数据分类要求的用户,而不是彻底取消自助式协作。

实施命名策略

在 Microsoft Entra ID 中配置命名策略(Entra 管理中心 → Groups → Naming Policy)。使用固定字符串或诸如 [Department]、[Company] 或 [Office] 之类的动态属性,以在所有 Microsoft 365 Groups 工作负载中(包括 Teams、Outlook、SharePoint、Planner 和 Viva Engage)强制执行一致的命名。

一致的命名不仅能改善组织结构。它还能在规模化的情况下,让审计范围界定、合规搜索以及生命周期决策变得切实可行。当团队遵循可预测的命名模式时,就能轻松识别负责人、用途和敏感级别。

配置过期策略

通过 Microsoft Entra ID 设置过期策略(Groups → Expiration),以便在设定的时间后(通常为 365 天)自动使团队过期。正在积极使用的团队会在过期前约 35 天自动续期,因此高效团队不会受到影响。所有团队所有者将在 30 天时收到续期通知。

这是抵御 范围蔓延累积 的最有效控制。没有过期机制时,所有已完成的项目团队都会无限期持续存在,累积无人实际管理的权限和数据。

强制执行所有者要求

所有权是其他所有治理控制的基础。没有负责任的所有者,就无法执行命名策略;无法评估过期续期;也无法做出敏感数据相关的决策。

要求所有团队至少有两名所有者。使用 Microsoft Entra ID Access Reviews 实施季度所有者审查,并在当前所有者离开组织时,定义为指定新所有者的升级流程。

如何清理现有的 Teams 泛滥

治理策略可以防止新的泛滥,但无法解决那些已经存在且缺乏监督的团队。通过一个结构化的清理流程,分五个阶段进行。

第 1 阶段:盘点评估

首先导出当前 Teams 环境的完整盘点信息,包括团队名称、所有者状态、活动水平以及可见性设置。根据以下条件识别需要清理的候选项:

  • 无活动: 90–180 天内没有任何活动的团队
  • 所有权缺失: 没有活跃所有者,或根本没有所有者的团队
  • 重复项: 名称相似或完全相同的多个团队
  • 单成员团队: 创建了但从未用于协作的工作区

第 2 阶段:与相关方沟通

通知处于不活跃状态的团队的负责人,制定清理时间表(通常提前 30–60 天通知),并为负责人提供清晰的流程,让他们能够续期或说明保留团队的理由。沟通至关重要,因为如果在未通知的情况下删除团队,会造成组织层面的摩擦,并削弱对 IT 治理的信任。

第 3 阶段:归档不活跃的团队

归档会让团队变为只读,同时保留所有内容。对受监管行业而言,归档应当是默认操作,而不是立即删除。归档后的团队会为合规目的保留其数据,并将其从正在的协作中移除,同时防止权限进一步累积。

第 4 阶段:删除不必要的团队

只有在确认以下情况后才应进行删除:

  • 没有适用的保留策略
  • 数据不具备合规价值
  • 不存在法律保全(Legal Hold)
  • 已导出所需数据
  • 已获得相关方批准

被删除的团队会先进入为期 30 天的“软删除”状态,然后才会被永久移除;如果有内容被过早删除,就能提供一个恢复窗口。

第 5 阶段:配置保留策略

在开始大规模删除之前,通过 Microsoft Purview 为 Teams 频道消息和聊天配置保留策略。保留时长应符合你的监管要求。若未落实这些策略,清理工作可能会误删具有合规价值的数据。

清理完成后,持续存在的挑战是在不依赖持续的手动工作前提下维持治理。上方“预防”部分中涵盖的到期策略、所有权审查和创建限制能够防止“蔓延”重新发展。

Netwrix 如何支持 Teams 治理

治理策略和清理脚本能够解决 Teams 膨胀带来的结构性问题。但更深层的挑战在于可视性:

  • 了解数百个团队及其关联的 SharePoint 站点中,谁对哪些数据拥有访问权限
  • 检测权限发生漂移的时间点
  • 生成监管机构真正认可的审计证据

这正是微软原生工具留下的空白,也是 Netwrix 发挥作用的地方。Netwrix 1Secure 可在不进行复杂部署的情况下,从第一天起让您获得对 Microsoft 365 环境的可视性。对于 SharePoint Online,1Secure 会跟踪数据访问活动,呈现敏感数据位置,并监控协作环境中的权限变更。

Netwrix risk summary dashboard

风险评估仪表盘会突出 Teams 扩张(sprawl)带来的问题:过度的权限、对敏感数据的开放访问、仍保留访问权限的休眠账户,以及违反组织政策的权限配置。基于 AI 的修复建议可帮助团队优先处理需要先修复的事项。

Netwrix Auditor提供监管行业所需的深入、以合规为导向的审计。借助快速部署以及数小时内即可获取的报告,Auditor 能覆盖 Teams、SharePoint、Active Directory 以及文件服务器,提供审计追踪。类似 Google 的交互式搜索可让调查人员回答“谁在何时访问了什么”,从而面向整个环境进行检索,而不仅仅是一次只针对一个团队。

HIPAA、SOC 2、GDPR、PCI DSS 和 CMMC 的预定义合规映射意味着:审计准备不再需要手动收集证据,而是通过提取报告即可完成。

在您的 Microsoft 365 环境中进行特权访问时,Netwrix Privilege Secure提供按需(just-in-time)的预置/开通(provisioning),从而消除常驻的管理员特权,并通过会话录制(session recording)为审计追踪提供支持。

大多数组织并不是缺少治理意愿。他们缺的是:能够清晰地看见其 Teams 环境中正在发生什么,并据此采取行动的能力。Netwrix 在不增加本已繁忙且人手紧张的安全团队复杂度的情况下,弥补了这一差距。

预约演示 以便亲眼看到 Netwrix 的实际效果,并了解你能多快从失控的无序扩张转向可审计的管控。

Netwrix Directory Manager 通过委派式自助服务,自动化覆盖 Active Directory 和 Entra ID 的组与用户管理。请求演示

关于 Teams sprawl 的常见问题

分享到

了解更多

关于作者

Dirk schrader

Dirk Schrader

安全研究高级副总裁(VP)

Dirk Schrader 是 Netwrix 的常驻 CISO(EMEA)以及安全研究高级副总裁(VP)。他拥有 CISSP(ISC²)和 CISM(ISACA)等资质,是一位在 IT 安全领域拥有 25 年经验的老兵。Dirk 致力于以现代化的方式应对网络威胁,从而推动网络韧性的发展。Dirk 曾参与全球范围内的网络安全项目:职业初期从技术与支持岗位做起,随后在大型跨国公司和小型初创企业中分别担任销售、市场与产品管理等职务。他已发表大量文章,强调为实现网络韧性,需要重视变更管理与漏洞管理。