Enterprise Server 3.21 目前作为发布候选版本提供。

修正存储库中泄露的机密

了解如何有效地响应存储库中 GitHub 泄露的机密。

Phase 3: Pilot GitHub Secret Protection

4 篇中的第 4 篇
更多文章→

在本文中

介绍

如果 API 密钥、令牌和凭据等机密在代码库中无意中暴露或存储不当，则可能会给团队和组织带来重大的安全风险。

任何泄露的机密都应该被认为会立即受到侵害，并且必须采取适当的修正措施，例如撤销机密。 只是从代码库中移除机密、推送新的提交或删除并重新创建存储库并不能阻止机密被利用。

本教程将指导你在将机密意外提交到存储库或收到存储库中机密泄漏警报时，该如何操作。

先决条件

  • 你至少具有存储库写权限。
  • 可选：Secret scanning 已为存储库启用。

    注意

    Secret scanning 对于公共存储库 ，是免费的 。 它可作为 GitHub Secret Protection 的一部分，在 GitHub Team 和 GitHub Enterprise Cloud 计划中的私有仓库中提供。

步骤 1. 标识机密并收集上下文

收集尽可能多的关于泄露机密的信息。 这将有助于评估风险并确定最佳修正操作过程。

  1. 确定机密类型及其提供程序。
    • 例如，机密是 GitHubpersonal access token （PAT）、OpenAI API 密钥、SSH 私钥？
  2. 查找包含泄露机密的存储库、文件和行。
  3. 标识机密所有者。 这是创建机密或对机密负责的个人或团队。
    • 检查存储库的 CODEOWNERS 文件以确定负责的团队。
    • 使用 git log -S 来帮助搜索存储库的提交历史记录，以标识提交机密的人员。

提示

如果你的存储库已启用 secret scanning，则 secret scanning 警报可提供其中大多数详细信息。

步骤 2. 评估风险

如何进行修正将取决于与机密泄漏关联的风险因素。

Secret scanning 可以帮助你评估与警报相关的风险，但如果尚未 secret scanning 启用，仍可以根据可用的信息执行风险评估。

选项 1.

Secret scanning 已启用

secret scanning查看与泄漏关联的警报，检查警报标签和任何可用的元数据：

  1. 检查机密的有效性状态以确定机密是否仍然处于活动状态。 警报将包含一个状态，此状态描述机密是处于活动状态还是非活动状态，或者其有效性是否未知。

    注意

    • 有效性检查仅适用于某些机密类型。 要检查是否支持你的机密类型，请参阅 支持的机密扫描模式。
    • 机密提供者始终是用于确定机密有效性的最可靠事实源。
  2. 检查 public exposure 标签以确定机密是否已在公共存储库中泄露。
  3. 检查 multiple leaks 标签以确定机密是否已在多个位置公开。
  4. 如果该密钥是 GitHub PAT，请检查 警报元数据，查看有关该密钥上次使用时间及其访问范围的信息。
  5. 评估哪些服务或应用程序依赖于此机密，并考虑如果立即撤销该机密，是否可能导致停机或中断。

选项 2.

Secret scanning 未启用

如果尚未为该存储库启用 secret scanning，请根据以下内容进行风险评估：

  1. 检查存储库的可见性。 该存储库是否为公共存储库？
  2. 查找最近使用过机密的迹象。 是否有任何近期提交或拉取请求引用了机密？ 是否有任何日志或审核线索显示正在使用的机密？
  3. 评估包含机密的文件和周围上下文。 此机密是用于生产部署脚本（风险较高）还是测试文件（风险较低）？ 此机密是与数据库凭据还是管理密钥关联（风险较高）？
  4. 评估哪些服务或应用程序依赖于此机密，并考虑如果立即撤销该机密，是否可能导致停机或中断。

提示

使用 GitHub Team 和 GitHub Enterprise 计划的组织可以执行免费的机密泄露风险评估（按需进行的时间点扫描），以评估其面临机密泄露的暴露情况。 请参阅“借助 GitHub 实现机密保护”。

步骤 3. 制定修正策略

下一步取决于你在上一步中执行的风险评估。

针对高风险机密快速采取行动

自动扫描程序可在数分钟内找到公开的机密。 它们可能会在数小时内被恶意行动者利用。 活动机密的公开时间越长，发生严重泄露的可能性就越大。

如果机密为高风险（即机密仍处于活动状态、已在公共存储库中公开或者是生产凭据），那么我们建议：

  1. 立即优先撤销机密。 请参阅步骤 4。

    注意

    如果你担心服务停机，则可能需要先生成具有相同权限的新机密，让应用程序开始使用新令牌，_然后_再撤销旧机密。

  2. 在撤销期间或撤销之后，与机密所有者（在步骤 1 中标识）、存储库管理员和安全负责人沟通。

针对中低风险机密制定计划

如果机密为中低风险（即机密不再处于活动状态、已在专用存储库中公开，或者是测试或开发凭据），则可以相应地规划修正策略：

  1. 使用步骤 1 中收集的信息，找到对机密负责的团队并提醒他们注意机密泄露。
  2. 说明泄露的内容和泄露时间。 说明你需要撤销机密、生成新机密，并且受影响的服务将需要更新。
  3. 通知存储库管理员和安全负责人有关泄漏的情况，并解释需要或已经采取的任何修正操作。
  4. 与相应团队一起规划撤销和轮换的时间以协调平稳过渡。

即使是中低风险的机密，也必须修正，因为如果公开了机密，那么它们仍然会对安全性和合规性构成风险。

步骤 4. 撤销机密

仅仅从代码库中移除机密是不够的。 最重要的修正步骤是使用机密提供程序撤销机密。 通过撤销机密，可以大大降低机密被利用的可能性。

  1. 使用步骤 1 中收集的信息，找到机密提供者的网站或文档。

  2. 按照提供程序的说明撤销机密。 这通常涉及登录提供程序的门户并导航到管理机密的部分。

    如果无法访问提供程序门户，请联系机密所有者或相关存储库管理员以获取有关撤销机密的帮助。

  3. 如有必要，生成一个新机密来替换撤销的机密。 这通常需要还原依赖于原始机密的服务功能。

注意

GitHub 自动撤销 GitHubpersonal access tokens 在公共代码仓库中泄露的个人访问令牌（PAT）。

对于私有仓库中泄露的 GitHub PAT，您可以通过点击 报告泄露，直接在 GitHub 警报中向 secret scanning 报告该泄露。

对于其他机密类型，如果在公共存储库中泄露了与某个受支持合作伙伴模式匹配 GitHub的机密， GitHub 则会自动向机密提供程序报告泄漏，该提供程序可能会立即撤销机密。

步骤 5：标识并更新受影响的服务

接下来，你需要协调更新所有使用泄露的机密的受影响服务，并使用新的机密对其进行更新。

Identify

  1. 使用 GitHub 的代码搜索，在所有代码、议题和拉取请求中检查该密钥。
    • 使用 org:YOUR-ORG "SECRET-STRING" 在整个组织内进行搜索。
    • 使用 repo:YOUR-REPO "SECRET-STRING" 搜索存储库。
  2. 检查存储库存储的部署密钥、机密和变量。
    • 单击“设置”，然后在“安全性”下面，单击机密和变量或部署密钥。
  3. 检查是否存在任何已安装的 GitHub Apps 和可能使用该密钥的集成。

Coordinate

  1. 指示 Copilot 为更新受影响的服务所涉及的每个任务创建问题（和子问题）。

  2. 如果涉及多个利益干系人，请为议题创建项目板以跟踪进度并促进沟通。

更新和验证

  1. 使用新机密更新应用程序，确保应用程序正确使用新凭据。

    提示

    向应用程序提供敏感凭据的一种安全方法是通过保管库。 例如，你可以通过仓库设置页面中的“机密和变量”存储，向 GitHub 操作和工作流提供敏感凭据。

  2. 测试受影响的服务以确保其能够使用新机密正常运行。

步骤 6. 检查未经授权的访问

服务恢复正常运行后，请务必检查机密公开时可能发生的任何未经授权的访问。

  1. 查看 GitHub与机密及其使用情况相关的事件的审核日志。

    对于组织和企业级审核日志，你可以专门搜索与访问令牌相关的事件。 请参阅 标识由访问令牌执行的审核日志事件（组织）和 标识由访问令牌执行的审核日志事件（企业）。

    访问 GitHub的审核日志取决于你的角色，因此，如果你没有必要的权限，则可能需要联系组织所有者或企业管理员。

  2. 查看机密提供者的审核日志。

    • 例如，对于 Amazon Web Services (AWS) 机密，你可以检查 CloudTrail 日志，查找使用泄露的机密进行的任何未经授权的访问尝试。 请参阅 AWS CloudTrail 文档中的什么是 AWS CloudTrail？。

步骤 7. 清理存储库

尽管你现在已经撤销并更新了代码库中的机密，但此机密可能仍然存在于存储库的提交历史记录中。 理想情况下，你应该在存储库中搜索并移除机密的所有实例。

但是，清理 Git 历史记录的过程可能会造成破坏和中断，因为它可能涉及强制将更改推送到存储库。

与存储库的安全负责人一起，仔细考虑清理存储库历史记录对合规性或安全义务的影响。 请参阅“从存储库中删除敏感数据”。

步骤 8。 解决警报

  1. 在仓库中关闭 secret scanning 警报，方法是选择 关闭为 并将该警报标记为“已撤销”。
  2. 在团队的知识库或事件管理系统中记录事件，包括为修正泄漏所采取的步骤和任何经验教训。

步骤 9. 防止进一步泄漏

处理机密泄露通常会造成中断，过程复杂且耗时。 机密处理的重点应始终放在不惜一切代价防止泄露上：

  1. 确保已为存储库启用推送保护（部分 GitHub Secret Protection），如果尚未启用。 了解如何实施严格的绕过控制，以便只有受信任的用户才能绕过推送保护。 请参阅“推送保护”。
  2. 确保已对个人帐户启用“用户的推送保护”，这可防止意外将受支持的机密推送到_任何_公存储库。
  3. 在团队或组织内倡导或实施机密管理最佳做法：
    • 使用环境变量存储机密，而不是在代码库中对其进行硬编码。
    • 使用像 GitHub 的“机密和变量”存储功能这样的机密管理工具，在你的仓库设置页面中安全地存储和管理机密信息。
    • 定期轮换机密以尽量减少任何潜在泄漏的影响。
  4. 记录事件和修正步骤，以帮助团队从过去的错误中吸取教训并改进未来的做法。
  5. 提倡并开展定期学习和安全培训。 例如，请参阅 GitHub Advanced Security course from Microsoft Learn。
为存储库启用推送保护Phase 4: Monitor and assess value