要求对高影响操作提供在场证明

你现在可以在成员对 GitHub Enterprise Cloud 账户采取高影响操作之前，要求进行交互式重新认证或多因素质询。在场证明是 GitHub 面向企业的 sudo 模式的扩展，在需要时执行更高的安全标准。此公开预览仅适用于 github.com 和 GHEC-DR 上使用 Microsoft Entra ID 作为其 SSO 身份提供程序 (IdP)（通过 SAML 或 OIDC）的托管用户 (EMU) 企业。被盗的会话 cookie 和长期有效的身份验证令牌已出现在最近几起供应链攻击中。在场证明确认在高影响操作发生的那一刻，是真实、获授权的人在操作，而不仅仅是使用了有效的会话或令牌。我们通过将用户送回其 IdP 进行检查来验证这一点，允许你设置自定义 IdP 策略来管理在 GitHub 上执行的操作。这通过阻止使用受损或被劫持的凭据，或阻止代理在你不知情的情况下多走一步，来改善安全态势。它还帮助受监管客户满足合规要求，即在敏感操作前进行新鲜认证，例如来自 FDA Part 11 等框架的要求。当企业成员尝试执行高影响操作（例如，创建令牌、编辑 webhook、更改组织安全设置、查看恢复代码）时，GitHub 会将其重定向到其 IdP，以满足特定的身份验证策略。这可能意味着执行多因素身份验证、检查设备合规性，或只是再次登录以证明新鲜度。只有当用户从 IdP 返回并证明其满足所需策略时，GitHub 才允许该操作继续。在场证明使用与 sudo 模式相同的会话模型。成功质询后，用户可以在该浏览器会话中继续执行高影响操作两小时，而无需再次执行在场证明检查。如果你的企业使用 Entra ID 进行 SSO，你可以配置在场证明，通过以下要求之一添加这层额外验证：重新认证：成员再次使用你的 IdP 进行认证。根据你的 IdP 策略，密码可能满足此要求。MFA：成员再次认证，并根据你的 IdP 配置满足额外的多因素质询（例如，身份验证器应用、生物识别）。在拉取请求合并前支持在场证明即将推出。了解有关如何配置在场证明和 sudo 模式的更多信息，或加入 GitHub Community 中的对话。

GitHub Enterprise Cloud 公开预览“在场证明”，允许企业在成员执行高影响操作前，通过 Entra ID 强制交互式重新认证或 MFA。该能力扩展 sudo 模式，应对会话 cookie 与长期令牌被盗的供应链攻击，并帮助受监管客户满足敏感操作前新鲜认证要求。

• GitHub Enterprise Cloud 公开预览“在场证明”，允许企业在成员执行高影响操作前，通过 Entra ID 强制交互式重新认证或 MFA。该能力扩展 sudo 模式，应对会话 cookie 与长期令牌被盗的供应链攻击，并帮助受监管客户满足敏感操作前新鲜认证要求。
• 原贴提到：You can now require an interactive re-authentication or a multi-factor c
• 来源：github.blog

GitHub 在 Changelog 中宣布，企业现在可以为高影响操作要求“在场证明”。这不是一个单纯的新开关，而是把 sudo 模式从个人操作安全扩展到企业身份治理：在创建令牌、编辑 webhook、修改组织安全设置、查看恢复代码等动作前，GitHub 会把成员送回企业 IdP，确认当前操作由真实、获授权的人发起。

这是什么信号

信号核心是“操作时刻的身份新鲜度”。过去很多安全机制只看会话或令牌是否有效，但被盗的会话 cookie 和长期令牌已经出现在供应链攻击中。GitHub 选择把验证点前移到高影响动作发生的那一刻，并且把策略执行权交给企业自己的 IdP。目前该能力处于公开预览，只面向 github.com 和 GHEC-DR 上使用 Microsoft Entra ID 作为 SSO IdP（SAML 或 OIDC）的托管用户企业。

为什么重要

对平台安全来说，这补上了“有效凭据不等于真实授权”的缺口。攻击者拿到 cookie 或 token 后，往往可以静默执行敏感操作；在场证明要求重新认证或 MFA，能显著提高这类操作的成本。对受监管行业，它还对应“敏感操作前新鲜认证”的合规诉求，原文提到 FDA Part 11 等框架。对企业安全团队，这意味着可以把 GitHub 上的关键动作纳入既有 IdP 策略，而不是只依赖 GitHub 自身权限模型。

对谁有价值

• 使用 GitHub Enterprise Cloud 且以 Entra ID 做 SSO 的 EMU 企业。
• 安全与合规负责人：需要证明敏感操作前有强认证。
• 平台工程/IT 管理员：希望统一管理 GitHub 高影响操作的认证策略。
• 受供应链攻击威胁的研发组织：需要降低令牌和会话被盗后的影响。

可以怎么行动

• 先确认企业是否属于当前预览范围：EMU、Entra ID、SAML 或 OIDC。
• 在 IdP 中设计重新认证或 MFA 策略，明确哪些 GitHub 操作必须触发。
• 从高影响但低频的操作开始试点，例如创建令牌、编辑 webhook、更改安全设置。
• 评估两小时会话缓存对安全与开发者体验的平衡，必要时缩短 IdP 侧会话或增加条件。
• 为 PR 合并前验证做预留，因为原文提到该支持即将推出。

风险与限制

• 范围有限：只支持特定 EMU 企业和 Entra ID SSO，并非所有 GitHub 用户都可用。
• 依赖 IdP：如果 IdP 不可用或策略配置错误，可能阻碍关键操作。
• 体验摩擦：高影响操作会跳转回 IdP，频繁触发可能影响效率。
• 缓存窗口：成功质询后同一浏览器会话两小时内不再检查，存在时间窗口。
• 仍是公开预览：能力边界和覆盖操作可能继续变化。

总体判断：这是 GitHub 把企业身份基础设施更深地嵌入平台安全控制的一步。它不会替代最小权限、令牌生命周期管理和供应链防护，但对已经使用 Entra ID 的 EMU 企业来说，是值得优先评估的高杠杆安全配置。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《要求对高影响操作提供在场证明》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖