关于本指南
本指南介绍为提高帐户安全性而做出的影响最大的更改。 每个部分都概述了可以对流程进行的更改，以提高安全性。 影响最大的更改列在前面。
风险是什么？
帐户安全性是供应链安全的基础。 如果攻击者可以在 GitHub Enterprise Cloud 上接管你的帐户，则可以对代码或生成过程进行恶意更改。 因此，你的第一个目标应该是让某人难以接管你的帐户以及你的组织或企业的其他成员的帐户。
集中进行身份验证
如果你是企业或组织所有者，则可以使用 SAML 配置集中式身份验证。 虽然可以手动添加或删除成员，但在 GitHub Enterprise Cloud 与 SAML 标识提供者 (IdP) 之间设置单一登录 (SSO) 和 SCIM 更简单且更安全。 这也简化了企业所有成员的身份验证过程。
可以为企业或组织帐户配置 SAML 身份验证。 使用 SAML，可以通过 IdP 授予对 GitHub.com 上企业或组织成员的个人帐户的访问权限，也可以通过使用 Enterprise Managed Users 创建和控制属于企业的帐户。 有关详细信息，请参阅“关于身份和访问管理”。
配置 SAML 身份验证后，当成员请求访问你的资源时，他们将被定向到你的 SSO 流，以确保你的 IdP 仍能识别他们。 如果无法识别他们，则拒绝其请求。
某些 IdP 支持名为 SCIM 的协议，在对 IdP 进行更改时，该协议可以在 GitHub Enterprise Cloud 上自动预配或取消预配访问权限。 借助 SCIM，随着团队的增长，你可以简化管理，并且可以快速撤销对帐户的访问权限。 SCIM 适用于 GitHub Enterprise Cloud 上的单个组织，或者适用于使用 Enterprise Managed Users 的企业。 有关详细信息，请参阅“关于组织的 SCIM”。
配置双因素身份验证
**注意：**从 2023 年 3 月开始到 2023 年底，GitHub 将逐渐开始要求在 GitHub.com 上贡献代码的所有用户启用一种或多种形式的双因素身份验证 (2FA)。 如果你在符合条件的组中，当选择该组进行注册时，将收到一封通知电子邮件，该电子邮件标志着 45 天的 2FA 注册期的开始，并且你会看到要求你在 GitHub.com 上注册 2FA 的横幅。 如果未收到通知，则表示你不是需要启用 2FA 的组的成员，但我们强烈建议启用 2FA。
有关 2FA 注册推出的详细信息，请参阅此博客文章。
要提高你帐户的安全性，最佳的方式是配置双因素身份验证 (2FA)。 密码本身可以通过猜测、在另一个遭到入侵的网站上重复使用或社交工程（如网络钓鱼）而泄露。 即使攻击者拥有密码，2FA 也会使帐户更加难以遭到入侵。
为确保安全可靠地访问帐户，最佳做法是始终在帐户上至少注册两个第二因素凭据。 使用额外的凭据，可确保即使无法使用某一种凭据也能登入帐户。
此外，应首选密钥和安全密钥而非身份验证器应用（称为 TOTP 应用），并且避免尽量避免使用短信。 基于短信的 2FA 和 TOTP 应用都容易受到网络钓鱼攻击，也无法提供与密钥和安全密钥相同的保护级别。 根据 NIST 800-63B 数字身份指南，不再建议使用短信。
如果 GitHub 选择了组织中的服务帐户进行 2FA 注册，则其令牌和密钥将在截止时间后继续有效，而不会中断。 系统只会在帐户启用 2FA 之前阻止通过网站 UI 对 GitHub 的访问。 建议将 TOTP 设置为服务帐户的第二个因素，并将设置期间公开的 TOTP 机密存储在公司的共享密码管理器中，通过 SSO 控制对机密的访问。
如果你是企业所有者，则可以为企业拥有的所有组织配置策略以要求使用 2FA。
如果你是组织所有者，则可能能够要求组织的所有成员启用 2FA。
若要详细了解如何在自己的帐户上启用 2FA，请参阅“配置双重身份验证”。 若要详细了解如何在组织中要求 2FA，请参阅“在你的组织中要求进行双因素身份验证”。
配置企业帐户
企业所有者可能能够要求企业的所有成员使用 2FA。 GitHub Enterprise Cloud 上 2FA 策略的可用性取决于成员如何进行身份验证以访问企业的资源。
如果企业使用 Enterprise Managed Users 或为你的企业强制执行 SAML 身份验证，则 无法在 GitHub Enterprise Cloud 上配置 2FA。 对 IdP 具有管理访问权限的人员必须为 IdP 配置 2FA。
有关详细信息，请参阅“关于企业 IAM 的 SAML”和“为企业中的安全设置实施策略”。
配置个人帐户
注意：根据企业所有者为 GitHub.com 上的企业配置的身份验证方法，可能无法为个人帐户启用 2FA。
GitHub Enterprise Cloud 支持 2FA 的多个选项，这些选项的作用不太大，但最安全的选项是 WebAuthn 凭据。 WebAuthn 需要用到身份验证器（例如 FIDO2 硬件安全密钥）、平台身份验证器（如 Windows Hello）、Apple 或 Google 手机 或者密码管理器。 尽管很困难，但有可能对其他形式的 2FA 进行网络钓鱼（例如，有人要求你向他们读取你的 6 位一次性密码）。 不过，WebAuthn 的防网络钓鱼能力强，因为域范围内置于协议中，可阻止来自模拟登录页的网站的凭据在 GitHub Enterprise Cloud 上使用。
设置 2FA 时，应始终下载恢复代码并设置多个 2FA 凭据。 这可确保对帐户的访问不依赖于单个设备。 有关详细信息，请参阅“配置双重身份验证”和“配置双重身份验证恢复方法”。
配置组织帐户
注意：根据企业所有者 为 GitHub.com 上的企业配置的身份验证方法，可能无法为组织要求 2FA。
如果你是组织所有者，则可以看到哪些用户未启用 2FA，帮助他们进行设置，然后为组织要求 2FA。 若要引导你完成此过程，请参阅：
使用 SSH 密钥连接到 GitHub Enterprise Cloud
除了登录到该网站之外，还有其他方法可以与 GitHub Enterprise Cloud 进行交互。 许多人使用 SSH 私钥授权推送到 GitHub 的代码。 有关详细信息，请参阅“关于 SSH”。
与帐户密码一样，如果攻击者能够获取 SSH 私钥，他们可能会模拟你并将恶意代码推送到你拥有写权限的任何存储库。 如果将 SSH 私钥存储在磁盘驱动器上，最好使用通行短语保护它。 有关详细信息，请参阅“使用 SSH 密钥密码”。
另一种方法是在硬件安全密钥上生成 SSH 密钥。 可以使用用于 2FA 的同一密钥。 硬件安全密钥很难远程入侵，因为专用 SSH 密钥保留在硬件上，并且无法直接从软件访问。 有关详细信息，请参阅“生成新的 SSH 密钥并将其添加到 ssh-agent”。
硬件支持的 SSH 密钥非常安全，但硬件要求可能不适用于某些组织。 另一种方法是使用仅在短时间内有效的 SSH 密钥，因此即使私钥遭到入侵，也不可能被利用很长时间。 这是运行自己的 SSH 证书颁发机构背后的概念。 虽然此方法可让你对用户身份验证的方式进行大量控制，但它还负责自行维护 SSH 证书颁发机构。 有关详细信息，请参阅“关于 SSH 认证中心”。