修正仓库中泄露的机密

了解如何有效地应对 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 计划的组织可以执行免费机密风险评估（按需、时间点扫描），以评估其机密泄露风险****。 请参阅“关于机密风险评估”。

步骤 3. 制定修正策略

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

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

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

如果机密具有高风险（即机密仍处于活动状态、在公共仓库中暴露或属于生产凭据），建议：

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

    注意

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

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

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

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

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

即使是中低风险的机密也需要修正，因为如果暴露在外，它们仍然会对安全性和合规性构成风险。

步骤 4. 撤销机密

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

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

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

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

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

注意

GitHub 自动撤销公共仓库中泄露的 GitHub personal access tokens (PAT)。

对于专用仓库中泄露的 GitHub PAT，可以通过单击“Report leak”，直接从 secret scanning 警报中向 GitHub 报告泄露****。

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

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

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

识别

  1. 使用 GitHub 的代码搜索来检查机密的所有代码、议题和拉取请求。
    • 使用 org:YOUR-ORG "SECRET-STRING" 在整个组织内进行搜索。
    • 使用 repo:YOUR-REPO "SECRET-STRING" 搜索仓库。
  2. 检查仓库存储的部署密钥、机密和变量。
    • 单击“Settings”，然后在“Security”下单击“Secrets and variables”或“Deploy keys”********。
  3. 检查任何已安装的 GitHub Apps 和可能使用机密的集成。

坐标

  1. 指示 Copilot 为更新受影响服务所涉及的每个任务创建议题（和子议题）。 请参阅 使用 GitHub Copilot 创建问题。
  2. 如果涉及多个利益干系人，请为议题创建项目板，以跟踪进度并促进沟通。

更新和验证

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

    提示

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

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

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

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

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

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

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

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

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

步骤 7. 清理仓库

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

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

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

步骤 8。 解决警报

  1. 通过选择“Close as”并将警报标记为“Revoked”，关闭仓库中的 secret scanning 警报****。
  2. 在团队的知识库或事件管理系统中记录事件，包括为修正泄漏采取的步骤和任何经验教训。

步骤 9. 防止进一步泄漏

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

  1. 如果还没有为仓库启用推送保护 (part of GitHub Secret Protection)，请确保进行启用。 了解如何实施严格的绕过控制，以便只有受信任的用户才能绕过推送保护。 请参阅“关于推送保护”。
  2. 确保个人帐户已启用“Push protection for users”，这可防止意外将受支持的机密推送到任何公共仓库__。
  3. 在团队或组织内倡导或实施机密管理的最佳做法：
    • 使用环境变量来存储机密，而不是在代码库中对其进行硬编码。
    • 使用机密管理工具（例如仓库设置页下 GitHub 的“Secrets and variables”存储）来安全地存储和管理机密。
    • 定期轮换机密以尽量减少任何潜在泄漏的影响。
  4. 记录事件和修正步骤，以帮助团队从过去的错误中吸取教训并改进未来的做法。
  5. 提倡并开展定期学习和安全培训。 例如，请参阅 Microsoft Learn 的 GitHub 高级安全课程。

其他阅读材料