遵循这些最佳实践将有助于您提供安全的用户体验。
授权、身份验证和访问控制
我们建议创建 GitHub 应用程序，而不是 OAuth 应用程序。 GitHub 应用程序是官方推荐的与 GitHub 集成的方式，因为它们提供更精细的数据访问权限。 有关详细信息，请参阅“GitHub 应用和 OAuth 应用之间的差异”。
- 应用程序应使用最小权限原则，只请求应用程序执行其预期功能所需的 OAuth 作用域和 GitHub 应用程序权限。 有关详细信息，请参阅维基百科最小权限原则。
- 应用程序应为客户提供删除其帐户的方法，而无需发送电子邮件或呼叫支持人员。
- 应用程序不应在应用程序的不同实现之间共享令牌。 例如，桌面应用程序应该使用与基于 Web 的应用程序不同的令牌。 单个令牌允许每个应用程序单独请求 GitHub 资源所需的访问权限。
- 根据每种用户类型所需的功能，针对不同的用户角色设计应用程序。 例如，标准用户不应有权访问管理功能，帐单管理员可能不需要仓库代码推送权限。
- 应用程序不应共享服务帐户（如电子邮件或数据库服务）来管理 SaaS 服务。
- 应用程序中使用的所有服务都应具有唯一的登录名和密码凭据。
- 对生产托管基础架构的管理员权限只能授予担当管理职责的工程师和员工。
- 应用不应使用 personal access token 进行身份验证，应作为 OAuth 应用或 GitHub 应用进行身份验证：
- OAuth 应用应使用 OAuth 令牌进行身份验证。
- GitHub 应用应使用 JSON Web 令牌 (JWT)、OAuth 令牌或安装访问令牌进行身份验证。
数据保护
- 应用程序应使用带有有效 TLS 证书或 SSH for Git 的 HTTPS 对通过公共互联网传输的数据进行加密。
- 应用程序应安全地存储客户端 ID 和客户端密钥。 建议将它们存储为环境变量。
- 应用程序应在收到用户请求后 30 天内或在用户与 GitHub 的法律关系终止后 30 天内删除所有 GitHub 用户数据。
- 应用程序不应要求用户提供其 GitHub 密码。
- 应用程序应该对令牌、客户端 ID 和客户端密钥进行加密。
日志记录和监视
应用程序应具有日志记录和监视功能。 应用程序日志应保留至少 30 天，并存档至少一年。 安全日志应包括：
- 身份验证和授权事件
- 服务配置更改
- 对象读取和写入
- 所有用户和组权限更改
- 角色提升到管理员
- 每个事件的一致时间戳
- 所有记录操作的源用户、IP 地址和/或主机名
事件响应工作流
要为用户提供安全体验，应在上架应用程序之前制定明确的事件响应计划。 我们建议您在自己的公司内成立安全和运营事件响应团队，而不是使用第三方供应商。 您应该能够在确认事件后 24 小时内通知 GitHub。
有关事件响应工作流的示例，请参阅 SANS 研究所网站上的“数据泄露响应策略”。 包含明确的事件响应措施的简短文档比冗长的策略模板更有价值。
漏洞管理和补丁工作流程
您应该定期对生产基础架构进行漏洞扫描。 您应该对漏洞扫描的结果进行分类，并定义您同意修复漏洞的时间段。
如果您还没有准备好设置完整的漏洞管理程序，最好先创建一个修补流程。 有关创建修补程序管理策略的指南，请参阅此 TechRepublic 文章：“建立修补程序管理策略”。