10110010011101001011001101101110101018200.devFrom Enterprise.Systems
免费开始

如何在整个 Google Workspace 组织中强制启用 MFA

The 8200.dev Team阅读时间 5 分钟

多因素认证是大多数组织能够部署的投入回报率最高的安全控制措施,在 Google Workspace 中,它被称为两步验证(2SV)。问题在于*强制*这个词。让 MFA 可用很容易,但基本没什么用——最有可能遭受攻击的账户,恰恰是最不愿意主动开启的账户。真正的保护来自强制执行:在整个组织范围内要求使用 MFA,配合恰当的验证方式,并采用不会让任何人被锁定在外的推行方案。本文就是这样一份推行方案。

为什么“可用”不等于“强制”

如果两步验证是可选的,采用情况就会遵循阻力最小的路径:懂技术、有安全意识的员工会主动启用;忙碌的高管以及与服务相关的账户则不会。攻击者深知这一点。凭据钓鱼和密码重用攻击正是瞄准那些没有启用两步验证的账户。一项可选的控制措施,保护的恰恰是最不需要它的人。

强制执行则彻底扭转了这一局面。当两步验证成为必需项时,窃取的密码就不再足以接管账户——这一举措就能中和最常见的账户入侵途径。

谨慎选择你的验证方式

并非所有第二验证因素都是等效的。从最强到最弱依次为:

  • 通行密钥与硬件安全密钥(FIDO2)。 具备抗钓鱼能力:它们与合法网站进行加密绑定,因此钓鱼页面无法转发它们。这是黄金标准,强烈建议管理员及其他高价值账户使用。
  • Google 提示 / 身份验证器应用(TOTP)。 相比密码有实质性提升,但坚定的实时钓鱼工具仍可能转发一次性验证码。适合普通用户群体。
  • 短信验证码。 聊胜于无,但容易受到 SIM 卡劫持和拦截的攻击。可以作为备用方式,但不应作为主要验证方式。

合理的策略是:为管理员和敏感群体要求使用强抗钓鱼验证方式,允许其他所有人使用基于应用的验证码,并尽量减少短信验证的使用。

分阶段推行,避免锁定风险

阻碍 MFA 强制推行的顾虑,正是担心把人锁定在外。通过分阶段推行来消除这一风险:

  1. 先做好沟通。 告知组织将发生什么变化、原因是什么,以及截止时间。提供注册说明。突然强制执行会引发大量帮助台工单和不满情绪。
  2. 开放注册窗口期。 将两步验证设置为可用状态,并设定截止日期。跟踪注册进度,以便了解哪些账户尚未完成注册。
  3. 提醒还未行动的人。 随着截止日期临近,提醒尚未注册的账户。这一阶段通常能让绝大多数拖延者完成注册。
  4. 强制执行时设置新用户宽限期。 开启强制执行,但为新创建的账户配置宽限期,以确保入职流程不会在首次登录时被阻断。
  5. 分发备用选项。 确保用户已注册备用验证码或第二验证方式,这样一旦手机丢失,只是一个小麻烦,而不会导致账户被锁定。
  6. 谨慎处理例外情况。 某些服务账户或共享账户确实可能难以适配交互式两步验证。应将这些账户迁移到更合适的身份验证模型(服务账户密钥、专门处理方式),而不是在用户策略中划出大范围的豁免。

管理控制台支持在组织单位级别进行强制执行,因此你可以先在 IT 部门试点,再扩展到某个部门,最后覆盖整个组织——从而进一步降低推行风险。

常见误区

  • “出于便利”豁免高管。 价值最高的账户恰恰是最不该被豁免的账户。如果有例外,反而应该要求他们使用*最强*的验证方式。
  • 仅允许短信验证。 这只是走个形式上的流程,却仍然留下了 SIM 卡劫持的隐患。应推动使用基于应用或硬件的验证方式。
  • 忽略服务账户和共享账户。 这些账户往往拥有重要权限,却又跳过了交互式认证。应对其进行专门治理——参见识别高风险 AI 代理与服务账户
  • 将其视为一次性工作。 新增账户、新的例外情形以及策略偏差,都意味着强制执行需要定期核查,而不是一次性开关切换就能一劳永逸。

验证强制执行情况——不要想当然

开启策略和确认策略*确实应用到每一个账户*,是两件不同的事情。在策略生效前创建的账户、位于被豁免组织单位中的账户,或恰好处于宽限期内的账户,都可能悄悄游离于强制执行范围之外。健全的Google Workspace 安全态势的一部分——也是 SOC 2 审计员在 CC6.1 条款下专门审查的控制项——就是要检查 MFA 强制执行是否覆盖整个组织,而不仅仅是确认开关已打开。

这正是那种容易出现偏差、且审计员会要求你提供证据的配置项。一款能够检查全组织设置的态势工具,会标记出哪些地方尚未强制启用两步验证(在具备相应管理员可见性的前提下),从而让“我们已强制执行 MFA”成为一个经过验证的事实,而不是一种假设。

处理棘手情况

大多数账户都能顺利完成注册,不会出现问题。但有几类账户需要谨慎处理,而你如何对待它们,往往决定了强制执行能否真正落地:

  • 高管与重要人物(VIP)。 他们是钓鱼攻击的首要目标,也最有可能要求豁免。应要求他们使用最强的验证方式,而不是给予豁免。高管账户被攻破是最糟糕的后果之一;为图方便而承担这种风险并不值得。
  • 共享邮箱与角色账户。 交互式两步验证适用于个人,而不适用于五个人共用的邮箱。应将这些账户重新建模为对个人受保护账户的委托访问,让保护措施真正落实到具体的人。
  • 服务账户与自动化账户。 这些账户根本不应该进行交互式登录。应使用单独管理的服务账户凭据对其进行认证,并将其作为非人类身份进行治理。
  • 现场员工与一线工作人员。 没有智能手机或网络连接有限的人员需要一种可行的验证方式——硬件密钥或备用码——应在强制执行日之前就规划好,而不是在帮助台临时应对。

贯穿所有这些情形的原则是:不要为了照顾少数边缘情况,而在用户策略中划出大范围的豁免。应针对每种情形采用恰当的机制加以解决,从而保持基线策略的完整性。

推行之后:保持强制执行状态

强制执行并非终点。新增账户、新创建的组织单位以及个别例外情形,都可能为覆盖范围的松动创造缝隙。应将定期核查纳入日常工作routine:确认两步验证在每个组织单位中仍处于强制状态,确认没有任何豁免悄然变成永久性豁免,并确认在需要强验证方式的地方仍然要求使用强验证方式。世界上最强大的控制措施,如果没有人确认它仍在生效,也会逐渐失效——“我们已强制执行 MFA”应当是一句你能够证明的话,而不是你希望它依然成立的说法。

8200.dev 会审计你的 Google Workspace 管理配置——包括两步验证的强制执行状态、共享控制以及电子邮件认证——并标记出偏差项,直接链接到对应设置。参见工作原理

想确认 MFA 是否真正在所有地方都得到强制执行? 启动你的免费安全审计,全面了解你的 Google Workspace 身份与配置态势。

分享X / TwitterLinkedIn

相关文章