{"meta":{"title":"响应安全事件","intro":"从战略上应对影响企业中的 GitHub 组织或存储库的安全事件。","product":"安全性和代码质量","breadcrumbs":[{"href":"/zh/code-security","title":"安全性和代码质量"},{"href":"/zh/code-security/tutorials","title":"Tutorials"},{"href":"/zh/code-security/tutorials/secure-your-organization","title":"保护你的组织"},{"href":"/zh/code-security/tutorials/secure-your-organization/respond-to-a-security-incident","title":"响应安全事件"}],"documentType":"article"},"body":"# 响应安全事件\n\n从战略上应对影响企业中的 GitHub 组织或存储库的安全事件。\n\n本文中的指南面向企业所有者、组织所有者、安全经理和安全团队。 但是，需要具有企业所有者角色才能执行本文中所述的多项操作。 某些步骤可能需要与组织所有者或存储库管理员进行协调。\n\n## 介绍\n\n本指南逐步讲解如何应对安全事件，概述用于验证和调查威胁的各个方面，并介绍可用于控制和修复威胁的工具。\n\n> \\[!IMPORTANT] 此处的步骤是一般准则。 每个事件都是独一无二的，可能需要根据具体情况使用不同的方法。\n>\n> 虽然 GitHub 支持 可以帮助解决特定于平台的问题，但在调查和应对影响您系统和资源的安全事件方面，您最有能力和优势。\n\n### 先决条件\n\n理想情况下，你已为企业启用了 **审核日志流式处理** 和 **源 IP 地址可见性** （将数据流式传输到安全信息和事件管理 （SIEM） 系统），并且你有权访问该数据。 请参阅“[流式处理企业审核日志](/zh/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise)”。\n\n### 在整个响应中\n\n在进行响应过程中，请确保：\n\n* **保留证据**：获取可疑活动的屏幕截图、导出日志或查询结果，并在清理之前保存受影响文件或代码的副本。\n* **记录**：记录你的发现（例如，时间、日期、泄露指标（IoC）、受影响的存储库），并记录你做出的每个决定。\n* **沟通**：通知相关利益干系人（如安全主管和工程经理，以及法律和隐私团队（如果敏感数据处于危险状态），并使其保持更新。\n\n## 步骤 1：评估信号并快速验证\n\n目标是快速确定你看到的信号是否可能是真正的主动威胁。\n\n### 1. 识别\n\n尝试识别所看到信号的性质。 例如，信号是否显示以下指示：\n\n* **凭据泄露**（泄露机密的警报，在外部站点发现的凭据报告）\n* **未经授权的访问或帐户泄露** （可疑登录报告、不熟悉的提交或更改）\n* **数据外泄** （可疑文件更改或添加报告、意外工作流运行、异常 API 活动、未知存储库创建或意外存储库可见性更改）\n* **恶意代码注入** （报告可疑代码更改、意外的工作流运行、添加新文件）\n* **供应链攻击** （可疑包版本报告、易受攻击依赖项的警报）\n\n若要帮助识别整个组织或企业中的这些威胁信号，请参阅 [常见安全事件调查领域](/zh/code-security/reference/security-incident-response/investigation-areas)。\n\n> \\[!NOTE]\n> \\[!NOTE] Runner 的 IP 地址是从共享基础设施中动态分配的，可能会因其他无关活动而被标记。 有关详细信息，请参阅“[故障排除工作流](/zh/actions/how-tos/troubleshoot-workflows#runner-ip-addresses-flagged-by-security-scanners)”。\n\n建议不要在调查的早期阶段花费太多时间进行深入检查，因为初始目标是 **确定** 威胁信号，以 **验证** 威胁信号并制定响应策略。\n\n### 2. 验证\n\n检查是否有证据来验证潜在威胁是否真实，以及它当前是否处于活动状态。\n\n以下 GitHub 工具和表面可能会有所帮助。\n\n| 工具/表面 | Purpose |\n| ----------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- |\n| [安全概述和安全警报](/zh/code-security/reference/security-incident-response/investigation-tools#security-overview-and-security-alerts) | 查看整个组织或企业的安全警报 |\n| [审核日志](/zh/code-security/reference/security-incident-response/investigation-tools#audit-logs) | 搜索与要调查的信号相关的事件，例如令牌创建、权限更改或存储库可见性更改 |\n| [活动视图](/zh/code-security/reference/security-incident-response/investigation-tools#activity-view) | 查看特定存储库的推送、提交和分支活动的时间线 |\n| \\[ | |\n| GitHub 代码搜索]\\(/code-security/reference/security-incident-response/investigation-tools#github-code-search) | 跨存储库搜索已知泄露指标，例如特定文件名或代码模式 |\n| [依赖项关系图](/zh/code-security/reference/security-incident-response/investigation-tools#dependency-graph) | 检查存储库是否依赖于特定包或包版本 |\n| [工作流运行和日志](/zh/code-security/reference/security-incident-response/investigation-tools#workflow-runs-and-logs) | 查看工作流执行历史记录并检查可疑活动的日志输出 |\n\n有关每个工具的详细信息，请参阅 [安全事件调查工具](/zh/code-security/reference/security-incident-response/investigation-tools)。\n\n验证阶段可能 **很快**：\n\n* 旨在收集足够的证据，以确定信号是否可能是 **真实** 和 **积极的** 威胁。\n* 如果无法快速排除信号为误报，则假定它是真实的。\n* 稍后可以执行深入调查。\n\n### 3. 决定\n\n根据收集的证据，确定三件事：\n\n1. **这是真正的威胁吗？** 如果不能快速自信地将信号排除为误报，请将其视为真实信号并继续遏制。\n2. **威胁是否仍处于活动状态？** 如果攻击者似乎仍然具有访问权限或仍在活动，请优先立即采取控制措施。 如果妥协看起来是历史的，你仍然需要调查和修正，但你可能有更多的时间来计划你的响应。\n3. **潜在的范围是什么？** 考虑泄露可能达到的距离—单个凭据、存储库、组织或整个企业。 这将帮助你适当地调整响应。\n\n如果有疑虑，请将威胁视为真实威胁，然后根据证据适当调整响应。\n\n## 步骤 2：包含威胁\n\n下一步假设正在处理真正的活动威胁。 现在的目标是根据你目前所知立即降低持续风险。\n\n可以选择执行多个包含操作来限制攻击者的访问和功能。\n\n> \\[!IMPORTANT]\n> 应根据威胁的性质、潜在范围和此时提供的证据来选择操作。 我们不建议对每个事件采取所有这些操作。 某些操作比其他操作更具破坏性或破坏性，因此，必须根据对上述威胁性质的评估来权衡每个操作的风险和好处。\n\n### 撤销已泄露的凭据\n\n对于公开或利用的凭据，可以采取的最直接操作是撤销受影响的凭据，以防止进一步滥用。\n\n* **通过 API 撤销**\n\n 如果令牌是以下类型之一，并且令牌的文本值是已知的，则可以通过 **REST API 提交请求**来撤销令牌（或任何人）。 请参阅“[撤销](/zh/rest/credentials/revoke?apiVersion=2022-11-28#revoke-a-list-of-credentials)”。\n\n * Personal access token (classic)\n * Fine-grained personal access token\n * OAuth app 访问令牌\n * GitHub App 用户访问令牌\n * GitHub App 刷新令牌\n\n* **吊销和限制选项**\n\n 还有一些用于阻止凭据访问的其他选项。 有关按凭据类型列出的完整列表，请参阅 [GitHub 凭据类型参考](/zh/organizations/managing-programmatic-access-to-your-organization/github-credential-types)。\n\n* **撤销或删除特定用户的凭据**\n\n 如果已确定特定的泄露帐户，则企业或组织所有者 GitHub Enterprise Cloud 可以撤销该单个用户的 SSO 授权。 对于具有 Enterprise Managed Users 的企业，您还可以彻底删除凭据。 这种方式比批量操作的干扰更小，同时仍能遏制威胁。 请参阅“[撤销企业中的 SSO 授权或删除凭据](/zh/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents/revoke-authorizations-or-tokens#taking-action-against-individual-members)”。\n\n* **撤销或删除特定类型的凭据**\n\n 如果该事件仅限于一种凭据类型，例如 personal access tokens (classic)，则企业或组织所有者可以使用 或 REST APIGitHub，针对所有成员仅撤销该类型的 SSO 授权，或仅删除该类型的凭据。 这会针对受影响的凭据类型，而不会中断其他凭据。 请参阅“[撤销企业中的 SSO 授权或删除凭据](/zh/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents/revoke-authorizations-or-tokens#taking-action-against-a-specific-credential-type)”。\n\n* **紧急行动（重大事件）**\n\n 在 GitHub Enterprise Cloud 上的企业 和组织 所有者可以批量执行紧急操作，对其整个企业 或组织的访问进行锁定。 对于具有 Enterprise Managed Users此功能的企业，这包括 **删除所有用户令牌和密钥**。 这些是具有高影响力的操作，会破坏自动化，应该仅用于重大事件。 请参阅“[响应企业中的安全事件](/zh/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents)”。\n\n所有这些取消授权和吊销操作（无论是由管理员发起还是由受影响的用户启动）都记录在审核日志中，受影响的用户会收到电子邮件通知。\n\n### 限制访问\n\n若要限制对企业、组织或存储库的访问，可以立即执行多项操作。\n\n* **配置 IP 允许列表**\n\n 阻止未知或可疑的 IP 地址访问组织或企业。 请参阅 [使用 IP 允许列表限制企业网络的流入流量](/zh/enterprise-cloud@latest/admin/configuring-settings/hardening-security-for-your-enterprise/restricting-network-traffic-to-your-enterprise-with-an-ip-allow-list) （企业管理员）和 [管理组织允许的 IP 地址](/zh/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-allowed-ip-addresses-for-your-organization) （组织所有者）。\n\n* **删除遭到入侵或可疑的用户**\n\n 删除用户或暂停帐户。 请参阅 [从组织中删除成员](/zh/organizations/managing-membership-in-your-organization/removing-a-member-from-your-organization) （组织所有者）。\n\n* **将存储库可见性更改为专用**\n\n 将受影响的存储库可见性更改为专用存储库，并限制其他人进行进一步更改的能力。 例如，如果敏感代码在属于组织的公共存储库中公开，或者恶意参与者将存储库的可见性设置从专用更改为公共，则可以更改存储库的可见性。 请参阅 [设置存储库可见性](/zh/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility) （存储库管理员和组织所有者）和 [限制在组织中更改仓库可见性](/zh/organizations/managing-organization-settings/restricting-repository-visibility-changes-in-your-organization) （组织所有者）。\n\n* **紧急行动（重大事件）**\n\n 企业所有者可以在GitHub Enterprise Cloud上采取批量紧急措施来封锁整个企业的访问权限。 其中包括 **锁定 SSO** 以阻止所有非所有者访问，并 **撤消跨组织的所有用户 SSO 授权**。 这些是具有高影响力的操作，会破坏自动化，应该仅用于重大事件。 请参阅“[响应企业中的安全事件](/zh/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents)”。\n\n### 禁用恶意组件和活动\n\n* **停止恶意工作流运行**\n\n 如果怀疑 GitHub Actions 工作流或运行程序正在用作活动攻击的一部分，则可以执行以下操作：\n\n * 取消受影响存储库的正在进行的工作流运行。 请参阅“[取消工作流程运行](/zh/actions/how-tos/manage-workflow-runs/cancel-a-workflow-run)”。\n * 对组织中受影响的存储库或特定组织禁用 GitHub Actions 。 请参阅 [禁用或限制组织的 GitHub Actions](/zh/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization) （组织所有者）和 [在企业中强制实施GitHub Actions策略](/zh/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise) （企业管理员）。\n * 删除自托管运行程序。 请参阅“[删除自托管的运行器](/zh/actions/how-tos/manage-runners/self-hosted-runners/remove-runners)”。\n\n* **禁用 Webhook**\n\n 如果怀疑泄露的存储库或组织 Webhook 正在用作实时数据外泄通道，则可以禁用它。 请参阅“[禁用网络钩子 (Webhook)](/zh/webhooks/using-webhooks/disabling-webhooks)”。\n\n* **删除恶意分支**\n\n 如果已识别包含恶意代码或工作流的分支，请立即将其删除以防止执行。 请参阅“[管理存储库中的分支](/zh/pull-requests/how-tos/commit-changes/managing-branches-within-your-repository#deleting-a-branch)”。\n\n## 步骤 3：完全调查\n\n立即遏制后，目标是了解事件的完整范围和影响，识别所有 IOC 和持久性机制，并收集用于围堵和完全消除威胁所需的证据。\n\n> \\[!IMPORTANT] 事件响应不是线性过程。 在发现新的 IoC 或对攻击更加了解时，可能需要反复进行调查、遏制和修正。\n\n1. 根据你所看到的信号和到目前为止收集的证据，制定一个 **工作假设** ，了解所发生的事情，并决定你需要证明或反驳该假设所需的其他证据。\n2. 请考虑 **AUTOTITLE** 中概述的不同[调查区域](/zh/code-security/reference/security-incident-response/investigation-areas)，以帮助指导调查。\n\n 不要将调查限制在单一方向。 许多攻击使用多种技术的组合，例如恶意包安装与凭据利用、工作流文件注入和数据外泄相结合。 确保正在调查所有潜在的攻击途径。\n3. **记录**迄今已知的所有 IoC，在 GitHub 的所有表面搜索跟踪。\n4. **清点** 所有受影响的工作流、存储库和组织，以系统地捕获事件的范围。\n * 包括存储库名称、受影响的内容（代码、机密、工作流）和泄露时间线。\n * 创建所有受影响的帐户和凭据的列表。 请注意，哪些令牌、SSH 密钥或其他凭据可能已公开或滥用。\n5. **根据证据验证** 你的工作理论。\n * 查看已收集的证据。 它是否支持你的初始假设？\n * 请考虑替代说明。 你观察到的活动是否有其他原因？\n * 如果假设被反驳，请根据证据形成新的假设，并根据需要重复调查步骤。\n6. ```\n 如果发现新的 IoC 或持续活动的证据，需要立即采取行动，**请返回遏制**。\n ```\n\n对所发生的事情和根本原因的理解高度有信心后，请记录调查结果并继续修正。\n\n## 步骤 4：修正\n\n现在的目标是删除所有泄露跟踪，修复根本原因，并将系统还原到安全状态。 修正操作将取决于面临的泄露，但一些良好做法如下所示。\n\n### 轮换令牌和机密\n\n即使不确定凭据是否已被泄露，只要有泄露的可能，也应该轮换凭据。\n\n* 生成新的令牌和密钥以替换已吊销或可能已泄露的任何令牌和密钥。 \n* 在存储库、环境和组织级别轮换存储在 GitHub 中的机密。\n* 在可能已被使用已泄露令牌访问过的外部系统中更新任何凭据。\n* 请考虑启用令牌过期策略，以鼓励今后定期轮换。 请参阅“[在企业中强制实施个人访问令牌策略](/zh/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-personal-access-tokens-in-your-enterprise)”。\n\n### 对持久性机制的审核\n\n你需要检查攻击者可能已建立的持久性机制，以确保在您进行初步封锁措施之后，访问权限仍然可以保持。\n\n这包括（但不限于）检查以下内容：\n\n* 可能已添加或修改的可疑或不熟悉的工作流文件。\n* 指向不熟悉域的新 Webhook。\n* 新自托管运行程序。\n* 对自托管运行程序的修改。\n* 新安装的 GitHub Apps 或 OAuth app 授权。\n* 新的部署密钥已添加到代码库中。\n* 新的二进制文件或可执行文件。\n\n### 审核并重新安装依赖项\n\n受损的依赖项可以作为攻击途径。 请确保对依赖项进行全面审核，并从受信任的源重新安装依赖项。\n\n* 查看有关易受攻击依赖项的Dependabot警报，并在有可用时查看有关恶意软件包的Dependabot malware alerts警报。 （Dependabot malware alerts 目前可用于 npm 生态系统。）若要调查其他恶意软件公告，请在 `type:malware` 中搜索 GitHub Advisory Database 并审核依赖项关系图中是否存在匹配项。\n* 将依赖项固定到已知良好的版本或提交 SHA，然后从包注册表重新安装。\n\n### 验证修正\n\n确认修正工作已成功。\n\n* 查看 code scanning 警报以确认代码漏洞已解决，并且未引入任何新漏洞。\n* 查看 secret scanning 警报，确认未在任何存储库中公开任何机密，并且所有警报都已解决。\n* 在事件发生后的几天和几周内，继续查看和监视审核日志及其他相关方面。\n\n## 步骤 5. Document\n\n完整的文档对于剩余阶段和将来的参考至关重要。\n\n* 记录调查期间发现的所有 IoC。\n* 记录执行的所有修正步骤，包括时间戳和执行每个操作的人员。\n* 维护受影响存储库、工作流和帐户的清单。\n* 记录决策及其背后的推理。\n* 请注意任何合规性、法律或隐私方面的影响。 请考虑此事件是否构成需要通知的数据泄露。\n\n## 步骤 6：反射和强化\n\n现在的目标是从事件中吸取教训，加强安全态势，以防止类似的事件。\n\n1. 编写 **事件摘要**。 这应包括从第一个指示到解决的事件的时间线，以及根本原因分析、决策和行动以及吸取的教训。\n2. 跟踪安全事件中的任何**未完成操作项**，例如剩余补救任务，以及需要根据所吸取的教训实施的任何安全改进。\n\nCopilot 可以帮助创建这些问题，你可以将定义明确的问题分配给 Copilot 独立处理。 请参阅 [启动GitHub Copilot会话](/zh/copilot/how-tos/use-copilot-agents/cloud-agent/start-copilot-sessions)。\n\n1. 如果还没有，请确保您的公司或团队具有最新的一份**安全事件响应计划**。 这应包括已定义的角色和责任、升级路径、通信协议、严重性分类条件和常见威胁类型的分步响应过程。\n Copilot 可以帮助根据特定需求和资源生成和优化此计划。 有关其他指南，请参阅 [什么是事件响应](https://github.com/resources/articles/what-is-incident-response#what-is-incident-response)。\n\n## 后续步骤\n\n* 如果尚未这样做，请考虑强化安全状况，以减少未来事件的风险。 请参阅“[防范安全威胁](/zh/code-security/tutorials/secure-your-organization/protect-against-threats)”。"}