用户身份验证
谈到用户身份验证，安全性应是首要考虑的问题。 强大的安全性必不可少。 似乎每个月都会有公司报告数据泄露问题。 由于安全流程效率低下，或者仅仅是因为公司内部缺乏最新的安全功能，从而导致凭据被盗。 如果用户采用需要漫长且繁琐的步骤来进行身份验证，则建立安全的用户身份验证可能是一项艰巨的任务。
GitHub Enterprise 支持两种安全用户身份验证的建议方法：
- SAML 单一登录（SSO）
- Two-Factor 身份验证（2FA）
SAML SSO 身份验证
SAML（安全断言标记语言）SSO 将 GitHub 与组织的标识提供者（IdP）集成，允许集中访问控制和改进合规性。 启用后，GitHub 会将用户重定向到 IdP 进行身份验证，然后授予对组织资源的访问权限。
启用和强制实施 SAML SSO
可以在 组织 或 企业级 配置 SAML SSO，具体取决于所需的强制范围。
Organization-Level SAML SSO
- 设置：在 “安全性”下的组织设置中，输入 IdP 的 SAML SSO URL 和公共证书。 测试和保存配置。
- 强制实施：选择 “要求 SAML SSO 身份验证 ”以自动删除不符合要求的成员。
- 用例：适用于具有有限影响的分阶段推出或测试。
注释
GitHub 仅删除无法进行身份验证的组织成员。 企业成员将一直保留，直到他们下次访问资源。
Enterprise-Level SAML SSO
- 设置：在企业帐户设置中，启用类似于组织级别的 SAML SSO。
- 强制实施：在企业中的所有组织中应用 SSO。
- 优点：确保统一策略并降低碎片配置的风险。
- 注意：GitHub 不会 立即删除不符合的企业成员。 系统会提示他们在访问时进行身份验证。
选择正确的 SSO 范围
| 条件 | Org-Level | Enterprise-Level |
|---|---|---|
| 范围 | 单个组织 | 整个企业 |
| 用户删除 | 立即强制实施 | 延迟到下一次访问 |
| 策略一致性 | 因组织而异 | 跨企业统一 |
| 设置复杂性 | 较少 | 较高 |
| 用例 | 试点/测试 | 广泛合规性 |
分步说明：启用和强制实施 SAML SSO
| Scope | 步骤 |
|---|---|
| 组织 | 1. 导航到 组织 → 设置 → 安全性。 2.使用 IdP 的详细信息启用 SAML。 3.测试配置并保存。 4.选择 “需要 SAML SSO”，然后删除不符合要求的用户。 |
| 企业 | 1. 导航到 企业 → 设置 → 安全性。 2.使用 IdP 的详细信息启用 SAML。 3.测试配置并保存。 4.在所有组织之间强制实施 SSO，并查看不符合要求的用户。 |
双因素身份验证 (2FA)
2FA 在用户名和密码之外添加了第二个验证步骤。 对于组织成员、外部协作者和计费经理，你可以要求 2FA。
警告
当你要求对组织使用双因素身份验证时，所有不使用 2FA 的帐户都会从组织中删除，并失去对其存储库的访问权限。 受影响的帐户包括机器人帐户。
有关 2FA 的更多详细信息，请参阅通过双因素身份验证 (2FA) 保护你的帐户。
强制实施 2FA
- 导航到组织 的安全 设置。
- 启用标记为 “需要双重身份验证”的复选框。
- 提前传达要求，以防止失去访问权限。
GitHub 中的 2FA 方法
| 方法 | DESCRIPTION |
|---|---|
| 安全密钥 | 最安全的方法。 阻止网络钓鱼的物理 USB 或 NFC 设备。 要求使用 TOTP（基于时间的一次性密码）或短信（短信服务）进行事先设置。 |
| TOTP 应用 | 推荐。 生成基于时间的一次性密码，支持备份，并脱机工作。 |
| 短信 | 最不安全。 应仅在 TOTP 不可行的地方使用。 GitHub SMS 支持因区域而异。 |
基于时间的一次性密码
GitHub 短信支持
注释
安全密钥在本地存储凭据，并且永远不会公开机密。 GitHub 建议使用 FIDO2/U2F 密钥。
审核 2FA 符合性
查看已启用 2FA 的人员：
- 转到 组织 →选择组织→“ 人员 ”选项卡。
- 选择 2FA 筛选器。
在这里，可以识别不符合要求的用户，并在 GitHub 外部跟进，通常通过电子邮件进行跟踪。
