确保帐户安全的最佳做法

关于本指南

本指南介绍为提高帐户安全性而做出的影响最大的更改。 每个部分都概述了可以对流程进行的更改，以提高安全性。 影响最大的更改列在前面。

风险是什么？

帐户安全性是供应链安全的基础。 如果攻击者可以在 GitHub Enterprise Server 上接管你的帐户，则可以对代码或生成过程进行恶意更改。 因此，你的第一个目标应该是让某人难以接管你的帐户以及你的 GitHub Enterprise Server 实例的其他用户的帐户。

集中进行身份验证

如果你是 你的 GitHub Enterprise Server 实例 的站点管理员，则可以通过选择与现有标识提供者 (IdP) 连接的身份验证方法（例如 CAS、SAML 或 LDAP）来简化用户的登录体验。 这意味着，他们不再需要记住 GitHub 的额外密码。

某些身份验证方法还支持将其他信息传达给 GitHub Enterprise Server，例如，用户所属的组或同步用户的加密密钥。 这是在组织增长时简化管理的好方法。

有关 GitHub Enterprise Server 可用的身份验证方法的更多信息，请参阅“关于身份和访问管理”。

配置双因素身份验证

要提高你个人帐户或你的 GitHub Enterprise Server 实例的安全性，最佳的方式是配置双因素身份验证 (2FA)。 密码本身可以通过猜测、在另一个遭到入侵的网站上重复使用或社交工程（如网络钓鱼）而泄露。 即使攻击者拥有密码，2FA 也会使帐户更加难以遭到入侵。

为确保安全可靠地访问帐户，最佳做法是始终在帐户上至少注册两个第二因素凭据。 使用额外的凭据，可确保即使无法使用某一种凭据也能登入帐户。

如果你是 你的 GitHub Enterprise Server 实例 的站点管理员，则可能可以为实例的所有用户配置 2FA。 GitHub Enterprise Server 上 2FA 的可用性取决于所使用的身份验证方法。 有关详细信息，请参阅“集中进行身份验证”。

如果你是组织所有者，则可能能够要求组织的所有成员启用 2FA。

若要详细了解如何在自己的帐户上启用 2FA，请参阅“配置双重身份验证”。 若要详细了解如何在组织中要求 2FA，请参阅“在你的组织中要求进行双因素身份验证”。

配置企业帐户

企业所有者可能能够要求实例上的所有用户使用 2FA。 GitHub Enterprise Server 上 2FA 策略的可用性取决于用户如何进行身份验证以访问实例。

• 如果使用 CAS 或 SAML SSO 通过外部 IdP 登录到 你的 GitHub Enterprise Server 实例，则 无法在 GitHub Enterprise Server 上配置 2FA。 对 IdP 具有管理访问权限的人员必须为 IdP 配置 2FA。

• 如果通过外部 LDAP 目录登录到 你的 GitHub Enterprise Server 实例，则可以在 GitHub Enterprise Server 上为企业要求 2FA。 如果允许目录外部的用户进行内置身份验证，则单个用户可以启用 2FA，但企业不需要 2FA。

有关详细信息，请参阅“为企业中的安全设置实施策略”。

配置个人帐户

GitHub Enterprise Server 支持 2FA 的多个选项，这些选项的作用不太大，但最安全的选项是 WebAuthn 凭据。 WebAuthn 需要用到身份验证器（例如 FIDO2 硬件安全密钥）、平台身份验证器（如 Windows Hello）、Apple 或 Google 手机 或者密码管理器。 尽管很困难，但有可能对其他形式的 2FA 进行网络钓鱼（例如，有人要求你向他们读取你的 6 位一次性密码）。 不过，WebAuthn 的防网络钓鱼能力强，因为域范围内置于协议中，可阻止来自模拟登录页的网站的凭据在 GitHub Enterprise Server 上使用。

设置 2FA 时，应始终下载恢复代码并设置多个 2FA 凭据。 这可确保对帐户的访问不依赖于单个设备。 有关详细信息，请参阅“配置双重身份验证”和“配置双重身份验证恢复方法”。

配置组织帐户

如果你是组织所有者，则可以看到哪些用户未启用 2FA，帮助他们进行设置，然后为组织要求 2FA。 若要引导你完成此过程，请参阅：

1. "查看组织中的用户是否已启用 2FA"
2. “准备在组织中要求双重身份验证”
3. “在你的组织中要求进行双因素身份验证”

使用 SSH 密钥连接到 GitHub Enterprise Server

除了登录到该网站之外，还有其他方法可以与 GitHub Enterprise Server 进行交互。 许多人使用 SSH 私钥授权推送到 GitHub 的代码。 有关详细信息，请参阅“关于 SSH”。

与帐户密码一样，如果攻击者能够获取 SSH 私钥，他们可能会模拟你并将恶意代码推送到你拥有写权限的任何存储库。 如果将 SSH 私钥存储在磁盘驱动器上，最好使用通行短语保护它。 有关详细信息，请参阅“使用 SSH 密钥密码”。

另一种方法是在硬件安全密钥上生成 SSH 密钥。 可以使用用于 2FA 的同一密钥。 硬件安全密钥很难远程入侵，因为专用 SSH 密钥保留在硬件上，并且无法直接从软件访问。 有关详细信息，请参阅“生成新的 SSH 密钥并将其添加到 ssh-agent”。

硬件支持的 SSH 密钥非常安全，但硬件要求可能不适用于某些组织。 另一种方法是使用仅在短时间内有效的 SSH 密钥，因此即使私钥遭到入侵，也不可能被利用很长时间。 这是运行自己的 SSH 证书颁发机构背后的概念。 虽然此方法可让你对用户身份验证的方式进行大量控制，但它还负责自行维护 SSH 证书颁发机构。 有关详细信息，请参阅“关于 SSH 认证中心”。

后续步骤

• "保护端到端供应链"
• "保护供应链中的代码的最佳做法"
• “保护生成系统的最佳做法”
• “防止组织中数据泄露的最佳做法”