防止组织中数据泄露的最佳做法

关于本指南

作为组织所有者，防止泄露专用或敏感数据应该是首要任务。 无论是有意还是意外，数据泄露都可能给相关方带来重大风险。 虽然 GitHub 采取措施帮助你防止数据泄露，但你也有责任管理组织以加强安全性。

在防范数据泄露方面，有几个关键组件：

• 采取主动的预防方法
• 及早检测可能的泄露
• 在事件发生时维护缓解计划

最佳方法取决于所管理的组织类型。 例如，专注于开放源代码开发的组织可能需要比完全商业化的组织更宽松的控制，以允许外部协作。 本文提供有关要考虑的 GitHub 功能和设置的高级指导，你应根据需要实施这些功能和设置。

保护帐户

通过实施安全最佳做法来保护组织的存储库和设置，包括启用 2FA 并要求所有成员使用 2FA，以及建立强密码准则。

• 要求组织成员、外部协作者和计费管理员为其个人帐户启用双因素认证 (2FA)，从而增加恶意攻击者访问组织存储库和设置的难度。 有关详细信息，请参阅 在你的组织中要求进行双因素身份验证。

• 遵循 GitHub 建议的密码准则，鼓励用户创建强密码并妥善保护这些密码。 有关详细信息，请参阅 创建强密码。

• 鼓励用户在其个人帐户设置中保持启用用户的推送保护，这样无论他们推送到哪个公共存储库，都将受到保护。 有关详细信息，请参阅“用户的推送保护”。

• 在 GitHub 中建立内部安全策略，使用户知道在怀疑发生事件时要采取的适当步骤和要联系的人员。 有关详细信息，请参阅“将安全策略添加到存储库”。

有关保护帐户的详细信息，请参阅 确保帐户安全的最佳做法。

防止数据泄露

作为组织所有者，应根据组织类型适当地限制和查看访问权限。 请考虑以下设置进行更严格的控制：

建议	详细信息
禁用创建存储库分支的功能。

          [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-the-forking-policy-for-your-repository)

禁止更改存储库可见性。 | 限制在组织中更改仓库可见性 将存储库创建限制为专用或内部。 |
限制在组织中创建仓库 禁用存储库删除和传输。 | 设置删除或转让仓库的权限 | | 将 personal access token 范围限定为必要的最低权限。 | None 通过在适当的时候将公共存储库转换为专用存储库来保护代码。 可以使用 GitHub App 自动提醒存储库所有者这一更改。 | GitHub Marketplace 中的 Prevent-Public-Repos 通过验证域并将电子邮件通知仅限于已验证的电子邮件域来确认组织的标识。 | 验证或批准您组织的域 确保组织已升级到 GitHub 客户协议，而不是使用标准服务条款。 | 升级到 GitHub 客户协议 防止参与者进行意外提交。 | 从存储库中删除敏感数据

检测数据泄露

无论你在多大程度上加强了组织以防止数据泄露，仍可能会发生一些泄露，你可以使用 secret scanning、审核日志和分支保护规则进行响应。

使用 secret scanning

Secret scanning 通过针对 GitHub 存储库中每个分支的完整 Git 历史记录扫描和检测意外提交的机密，帮助跨组织和存储库保护代码和机密的安全。 任何与机密扫描合作伙伴、其他服务提供商提供的或你或你的组织定义的模式匹配的字符串，都会在存储库的“安全”**** 选项卡中作为警报报告。

secret scanning 有两种可用形式：合作伙伴的机密扫描警报 和 用户的机密扫描警报。

• 合作伙伴的机密扫描警报：默认情况下启用，会自动在所有公共存储库和公共 npm 包上运行。

• 用户的机密扫描警报：要为组织获得额外的扫描功能，需要启用 用户的机密扫描警报。

  启用后，可以在以下类型的存储库上检测到 用户的机密扫描警报：

  • GitHub.com 上个人帐户拥有的公共存储库
  • 组织拥有的公共存储库
  • 由使用 GitHub Team 或 GitHub Enterprise Cloud 的组织拥有的专用和内部仓库，且具有 GitHub Code Security 的许可证

有关 secret scanning 的详细信息，请参阅“关于机密扫描”。

还可以启用 secret scanning 作为存储库或组织的推送保护。 启用此功能时，secret scanning 会阻止参与者用检测到的机密来推送代码。有关详细信息，请参阅 关于推送保护。 最后，还可以扩展检测以包含自定义机密字符串结构。 有关详细信息，请参阅“为机密扫描定义自定义模式”。

审查组织的审核日志

你还可以利用组织的审核日志及 GraphQL 审核日志 API，主动保护 IP 并维护组织的合规性。 有关详细信息，请参阅 审查组织的审核日志 和 接口。

设置分支保护规则

要确保所有代码在合并到默认分支之前都经过适当的评审，可以启用分支保护。 通过设置分支保护规则，可以在参与者推送更改之前强制实施某些工作流或要求。 有关详细信息，请参阅“关于受保护分支”。

可以创建规则集作为分支保护规则的替代方法。 相比分支保护规则，规则集有更多的优势，例如它有状态，可发现性更好，而且无需管理员访问权限。 还可以同时应用多个规则集。 有关详细信息，请参阅“关于规则集”。

缓解数据泄露

如果用户推送了敏感数据，请要求他们使用 git filter-repo 工具将其删除。 有关详细信息，请参阅“从存储库中删除敏感数据”。 此外，如果敏感数据尚未推送，你可以仅在本地撤销这些更改；有关详细信息，请参阅 the GitHub Blog（但请注意，git revert 并不是撤销添加敏感数据的有效方法，因为它会在 Git 历史记录中保留原始的敏感提交）。

如果无法直接与存储库所有者协调以删除你确信拥有的数据，可以填写 DMCA 删除通知表单并告知 GitHub 支持。 确保包含有问题的提交哈希值。 有关详细信息，请参阅 DMCA 删除通知。

后续步骤

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-code)
  

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds)