Skip to main content

确保帐户安全的最佳做法

关于如何保护可以访问你的软件供应链的帐户的指导。

关于本指南

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

风险是什么?

帐户安全性是供应链安全的基础。 如果攻击者能够接管你在 GitHub 上的账户,他们随后就能对你的代码或构建过程进行恶意更改。 因此,你的首要目标应该是让他人难以接管你的账户,以及你所在组织你所在实例的账户。

集中进行身份验证

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

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

有关可用的 GitHub身份验证方法的详细信息,请参阅 标识和访问管理基础知识

配置双因素身份验证

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

为确保安全可靠地访问帐户,最佳做法是始终在帐户上至少注册两个第二因素凭据。 额外的登录凭据可确保即使您无法使用其中一个凭据,也不会无法访问您的账户。

如果你是实例的站点管理员,则可以为实例的所有用户配置 2FA。 2FA 的可用性取决于你使用的身份验证方法。 有关更多信息,请参阅集中进行身份验证

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

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

配置企业帐户

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

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

  • 如果您通过外部 LDAP 目录登录 GitHub Enterprise Server,则可以在 GitHub 上为您的企业强制要求使用双重身份验证。 如果允许目录外部的用户进行内置身份验证,则单个用户可以启用 2FA,但企业不需要 2FA。

有关详细信息,请参阅 在企业中强制执行安全设置策略

配置个人帐户

注意

根据 站点管理员 配置的身份验证方法,您可能无法为个人账户启用 2FA。

GitHub 支持多个 2FA 选项,尽管其中任何选项都比什么都好,但最安全的选项是 WebAuthn 凭据。 WebAuthn 需要用到身份验证器(例如 FIDO2 硬件安全密钥)、平台身份验证器(如 Windows Hello)、Apple 或 Google 手机 或者密码管理器。 尽管很困难,但有可能对其他形式的 2FA 进行网络钓鱼(例如,有人要求你向他们读取你的 6 位一次性密码)。 但是,WebAuthn 对网络钓鱼的抵抗能力要强得多,因为该协议内置了域作用域限制,这会阻止在冒充登录页面的网站上获取的凭据被用于 GitHub。

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

配置组织帐户

注意

根据站点管理员配置的身份验证方法,你可能无法为你的组织强制启用 2FA。

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

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

使用 SSH 密钥连接到GitHub

除了登录该网站外,还有其他方式与 GitHub 交互。 许多人使用 SSH 私钥对他们推送到 GitHub 的代码进行身份验证。 有关详细信息,请参阅“关于 SSH”。

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

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

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

后续步骤