{"meta":{"title":"组织对泄露的敏感信息的修复工作","intro":"通过安全活动和警报分配，系统化地组织和管理泄露机密的修复工作。","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/organize-leak-remediation","title":"组织泄漏修正"}],"documentType":"article"},"body":"# 组织对泄露的敏感信息的修复工作\n\n通过安全活动和警报分配，系统化地组织和管理泄露机密的修复工作。\n\n## 介绍\n\n在本教程中，你将为泄露的机密组织修正工作。 你将了解如何：\n\n* 创建安全活动以跟踪补救工作\n* 基于所有权分配警报\n* 监视修正进度\n* 与利益干系人沟通\n\n## 先决条件\n\n* 必须为你的组织同时启用 GitHub Secret Protection 和 secret scanning。 请参阅“[定价与激活 GitHub Secret Protection](/zh/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/protect-your-secrets)”。\n* 必须有可用的现有 secret scanning 警报。\n\n## 步骤 1：查看 机密扫描警报\n\n在采取行动之前，需要了解组织安全警报的当前状态。\n\n1. 在 GitHub 上，导航到组织的主页面。\n\n2. 在组织名称下，单击 ** Security and quality** 该选项卡。\n\n3. 在左侧边栏中的“查找”下，单击 右侧的 **Secret scanning** 符号。\n\n4. 在下拉列表中，选择 `Default`。\n `Default` 与支持的模式和指定的自定义模式相关。\n\n5. 或者，可以选择 `Generic` 查看非结构化机密（如密码）。 但是，泛型模式通常比默认模式生成更多的误报，因此，请考虑在解决高优先级泄漏后查看这些警报。\n\n6. 查看未关闭警报的总数以及受影响的存储库数量。\n\n7. 使用筛选器识别最紧急的警报，并确定修正工作的优先级。\n * 若要显示 **公共** 存储库中的泄漏，请使用 `publicly-leaked`。\n * 若要显示在同一组织或企业内的 **多个存储库** 中找到的机密泄漏，请使用 `is:multi-repository`。\n * 若要显示仍然 **有效的**机密，请使用 `validity:active`。\n * 若要按特定的 **service** 凭据（AWS、Azure、GitHub）进行筛选，请使用 `provider:`。\n * 若要按特定 **令牌类型**进行筛选，请使用 `secret-type:`。\n\n8. （可选）在“见解”下的边栏中，单击 **Secret scanning** 以查看：\n * 最常被阻止或绕过的机密类型\n * 阻止推送次数或绕过操作最多的存储库\n\n## 步骤 2：创建安全活动\n\n可以设置安全活动，以便在多个存储库中组织和跟踪修正工作。\n\n1. 导航到你的组织并单击 ** Security and quality**。\n2. 在左侧面板中，选择“ ** 市场活动**”。\n3. 单击“ **创建活动 **”，然后选择以下任一项：\n * 选择预定义的 Secrets 活动模板。\n * 使用自定义筛选器定位特定警报（例如， `is:open provider:azure` 或 `is:open validity:active`）。\n4. 查看警报（最多 1000 个），并根据需要调整筛选器。\n5. 单击“ **另存为** ”并选择“ **发布宣传活动**”。\n6. 填写市场活动信息，然后单击“ **发布市场活动**”。\n\n## 步骤 3：将警报分配给团队成员\n\n创建活动后，你希望将每个警报分配给负责修复它们的开发人员。\n\n1. 在活动页面上，单击 ，以展开存储库并查看其警报。\n2. 单击警报以打开其详细信息页。\n3. 在右侧栏中，单击 **“分配者**”。\n4. 选择要修复警报的开发人员。 通常，这是提交机密的人员或检测到泄露的存储库管理员。 它们必须具有写入访问权限。\n\n## 步骤 4：监视修正进度\n\n分配警报后，需要定期跟踪市场活动进度，以确保及时完成。\n\n1. 在您的推广活动页面, 查看推广活动摘要。 你会知道的：\n * **活动进展**：已关闭的警示数量（已修复或已取消），或者仍需审阅的警示数量。\n * **状态**：活动截止日期之前的天数\n2. 您可以浏览活动详细信息：\n * 展开任何存储库以查看其警报修正进度。\n * 将 **“分组依据** ”设置为 **“无** ”以显示所有警报的列表。\n * 使用筛选器专注于特定存储库或警报。\n3. 根据未关闭警报最多或近期进展不足的存储库识别需要重点关注的领域，并联系相应的存储库维护人员或负责人以获取支持。\n\n## 步骤 5：与利益干系人沟通\n\n在整个修正过程中，应让利益相关者了解定期更新的进度。 可以使用市场活动仪表板中的信息来帮助生成这些更新。\n\n1. 进入广告活动仪表板。\n2. 确定要在报表中包含的信息。 请考虑以下关键指标：\n * 本周解决的警报\n * 剩余未处理的警报\n * 正常进度与有风险项\n * 值得注意的成就或阻碍\n3. 将指标合并到更新中，然后通过电子邮件、Slack、Teams 或安全会议分发。\n\n## 步骤 6：记录修正过程\n\n最后，应创建标准化过程，使将来的修正工作更高效。\n\n1. 开发针对特定机密类型的指南。 例如：\n * **AWS 凭据**：如何轮换访问密钥和更新服务\n * **GitHub 令牌**：如何撤销和重新生成 Personal Access Tokens\n * **API 密钥**：特定于服务的轮换过程\n * **数据库凭据**：安全轮换，不会中断服务\n2. 创建修正清单。\n 1. 验证机密是否已实际泄露。\n 2. 确定机密是否仍然有效。\n 3. 吊销或轮换已泄露的机密。\n 4. 使用旧机密更新所有系统。\n 5. 测试系统是否能使用新凭据正常运行。\n 6. 记录事件和修正步骤。\n 7. 将警报标记为已解决。\n3. 建立升级路径。\n * 定义何时升级到安全领导。\n * 确定不同机密类型的领域专家。\n * 为严重泄漏创建事件响应过程。"}