为高影响操作强制要求「在场证明」

你现在可以要求成员在 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 为企业版云账户推出「在场证明」公开预览：成员执行创建令牌、修改 webhook、变更组织安全设置等高影响操作前，必须回到身份提供商完成重新认证或多因素验证，只有带着满足策略的证明才能继续操作。该能力仅面向使用 Microsoft Entra ID 作为 SSO 身份提供商的托管用户企业，挑战通过后同一浏览器会话在两小时内免重复校验。

• GitHub 为企业版云账户推出「在场证明」公开预览：成员执行创建令牌、修改 webhook、变更组织安全设置等高影响操作前，必须回到身份提供商完成重新认证或多因素验证，只有带着满足策略的证明才能继续操作。该能力仅面向使用 Microsoft Entra ID 作为 SSO 身份提供商的托管用户企业，挑战通过后同一浏览器会话在两小时内免重复校验。
• 原贴提到：You can now require an interactive re-authentication or a multi-factor c
• 来源：github.blog

这是什么信号

GitHub 把「操作前先证明你是谁、你现在就在」这件事，从可选的安全最佳实践，做成了平台级可配置的强制项。过去企业的安全边界建立在「会话有效即代表身份可信」之上，这次 GitHub 明确否定了这个假设：有效的会话 cookie 和长期令牌近期反复出现在供应链攻击中，因此它要求在高影响操作的那一瞬间，用户必须回到 IdP 完成一次全新的验证。这是从「认证一次、长期放行」向「关键动作按次验证」的转向。

为什么重要

真正的危险不是密码被猜到，而是攻击者拿到一个已经通过认证的会话或令牌，然后安静地做那些只有管理员才能做的事——创建长期令牌、改 webhook、动组织安全设置、查看恢复代码。这些操作一旦得手，往往意味着整条供应链的下游都被波及。在场证明把验证点精确卡在这些动作上，等于给「被劫持的凭据」和「未经授权的自动化代理」设了一道临时闸门。对受监管行业来说，它还有另一层意义：FDA Part 11 这类框架要求敏感操作前有新鲜认证，以前这需要企业自己做适配，现在可以直接落在 IdP 策略里。

对谁有价值

直接受益的是使用 GitHub Enterprise Cloud、托管用户（EMU）模式、且以 Microsoft Entra ID 作为 SSO 身份提供商（SAML 或 OIDC）的企业安全负责人与平台工程团队。他们可以用企业已有的 IdP 策略统一治理 GitHub 上的高危操作，而不是在 GitHub 侧再维护一套规则。间接相关的是开发者体验负责人：任何额外的验证步骤都会落到日常流程上，如何划定「高影响」的范围，是安全与效率之间的实际取舍。对其他企业来说，即便暂时不在适用范围，这也是一份可参考的模型——关键操作按次验证、验证策略下沉到 IdP、业务系统只做执行方。

可以怎么行动

第一，先盘点自己企业里哪些 GitHub 操作属于「一旦被冒用就代价巨大」，对照 GitHub 给出的例子（创建令牌、编辑 webhook、更改组织安全设置、查看恢复代码）核对清单。第二，如果条件满足，在预览阶段用最小范围试验，观察对自动化流程和 CI 的影响——注意自动化代理同样会被这道检查拦住，需要提前规划服务账号与人工审批的边界。第三，把验证强度做成策略而不是硬编码：能用重新认证解决的就不要一律上 MFA，能只覆盖少数动作的就不要全量开启。第四，把「新鲜认证」作为合规证据链的一环，和现有审计流程对齐。第五，留意拉取请求合并前的在场证明即将推出，这会直接影响代码评审到合入的路径，需要提前和研发流程负责人打招呼。

风险与限制

适用范围很窄：目前仅限 github.com 和 GHEC-DR 上、以 Entra ID 做 SSO 的 EMU 企业，其他身份提供商和普通组织暂时用不上。它是公开预览，能力与行为仍可能变化。机制上，挑战成功后两小时内同一浏览器会话不再重复校验，这个窗口意味着防护不是持续的，而是按会话节流的，攻击者若恰好在窗口期内活动仍有余地。体验上，额外的跳转与验证会打断操作流，如果高影响动作定义得过宽，开发者摩擦会明显上升。最后，把验证委托给 IdP 之后，安全强度实际上取决于企业自己的 IdP 策略配得对不对——策略过松，这道闸门就形同虚设。

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

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

• Allison 原帖