修正存储库中泄露的机密

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

本文内容

介绍

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

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

如果你不小心将机密提交到存储库，或者收到了存储库中机密泄露的警报，则本操作指南将指导你如何处理。

先决条件

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

    注意

    Secret scanning 对公共存储库免费。 它作为 GitHub Secret Protection 的一部分提供，适用于 GitHub Team 和 GitHub Enterprise Cloud 计划中的专用存储库。

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

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

  1. 确定机密类型及其提供程序。
    • 例如，机密是 GitHub personal 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 会自动撤销公共存储库中泄露的 GitHub personal access tokens (PAT)。

对于专用存储库中泄露的 GitHub PAT，你可以通过单击报告泄露，直接从 secret scanning 警报中向 GitHub 报告泄露。

对于其他机密类型，如果与 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 的“Secrets and variables”存储）安全地存储和管理机密。
    • 定期轮换机密以尽量减少任何潜在泄漏的影响。
  4. 记录事件和修正步骤，以帮助团队从过去的错误中吸取教训并改进未来的做法。
  5. 提倡并开展定期学习和安全培训。 例如，请参阅 Microsoft Learn 中的 GitHub 高级安全性课程。

延伸阅读

  •         [AUTOTITLE](/code-security/secret-scanning/introduction/about-secret-scanning)

  •         [AUTOTITLE](/code-security/secret-scanning/introduction/about-push-protection)

  •         [AUTOTITLE](/code-security/secret-scanning/introduction/supported-secret-scanning-patterns)

  •         [AUTOTITLE](/get-started/learning-about-github/about-github-advanced-security)