问题发现（Findings）最佳实践：安全风险巡检闭环 - 全域智能运维平台 STAROps

本文以"安全组公网暴露风险巡检"为例，介绍如何通过问题发现（Findings）能力，完成从定时巡检、问题生成、人工确认、处置执行到验证关闭的完整闭环，让安全风险"发现一个、跟踪一个、闭环一个"。

业务场景

企业安全团队需要定期检查云资源的公网暴露面，例如安全组是否对 0.0.0.0/0 放通了 SSH（22）、RDP（3389）等高危端口。传统巡检方式存在以下痛点：

问题跟踪靠人工台账：巡检产出的报告是一份"快照"，问题有没有处理、处理到哪一步，需要人工记录和跟进。
重复问题反复上报：同一安全组规则问题每次巡检都出现在报告里，无法识别"这是同一个老问题"。
修复效果无法验证：安全组规则改了没有、改得对不对，缺少自动化手段验证，"没看到告警"常被误认为"问题已解决"。
问题复发无感知：已修复的问题被再次改坏时，没有机制能关联历史处理记录。

通过 STAROps 的问题发现（Findings）能力，数字员工会在巡检中自动将风险归纳为问题（Finding），自动去重、跟踪处置进度、验证修复效果，并在复发时重新打开原问题，实现安全风险的闭环管理。

方案架构

本实践的完整闭环涉及以下核心环节：

定时巡检：创建定时触发的长期任务（Mission），数字员工按计划自动执行安全组规则检查。
问题生成：数字员工将巡检发现的风险归纳为 Finding：同一安全组规则导致多台 ECS 暴露的问题聚合为一个 Finding 并锚定安全组；创建前自动与历史 Finding 做相似度检查，避免重复上报。
查看与确认：运维人员在控制台查看 Finding 详情、证据和影响面；对结论存疑时可发起"再次确认"，由数字员工重新核查。
处置执行：Finding 自带处理项（Task）和验证条件。收敛安全组规则属于高风险操作，默认进入人工确认（HIL）流程，可通过钉钉等 IM 一键确认后由数字员工执行。
验证关闭：下一轮巡检覆盖原检查范围且未再发现该风险时，Finding 自动关闭。
复发重开：已关闭的问题再次出现时，原 Finding 被重新打开并延续历史，而不是新建问题。

环境确认

在开始之前，确认以下环境已就绪：

检查项	确认方式
数字员工已创建	在 STAROps 控制台确认目标数字员工状态正常。
工作空间已接入云资源数据	在工作空间详情页确认已接入安全组、ECS 实例等云资源配置数据。
数字员工具备所需权限	数字员工关联的 RAM 角色需要具备安全组规则的读取权限；如需自动执行收敛操作，还需具备对应写权限。
通知渠道已配置	如需通过 IM 进行高风险操作确认，请提前配置钉钉等通知渠道。

实施步骤

步骤一：创建安全巡检长期任务

登录 STAROps 控制台。
在左侧导航栏，单击长期任务，进入长期任务管理页面。
在页面右上角，单击 + 新建长期任务。
在对话框中选择数字员工、模型。

使用自然语言描述巡检目标，例如：

帮我去巡检下，每天早上 9 点帮我去执行。

巡检范围：当前账号下的杭州地域的 ECS 主机的安全组的入方向规则。

关注重点：

1. 是否对 0.0.0.0/0 放通了 22、3389 等高危管理端口；

2. 受影响的安全组和 ECS 实例有哪些。

通知：不需要通知任何人。

输出要求：发现的风险归纳为问题发现（Finding），然后使用特定的 SubAgent 来创建 Findings，并以服务端的 Findings 为准。

输入目标后，数字员工会进行意图对齐，确认巡检频率、范围和输出形式，并自动生成执行蓝图（Blueprint）。确认蓝图后，长期任务启动。

说明

目标描述越具体，生成的执行蓝图越准确。建议明确巡检频率、检查范围、关注端口和聚合粒度要求。

步骤二：查看巡检发现的问题

巡检执行完成后，通过以下任一入口查看生成的 Finding：

在控制台问题列表页面查看当前账号下的全部 Finding。
在长期任务详情页查看本次巡检任务产生的 Finding。
按数字员工维度筛选，聚焦某个执行主体的发现。

单击目标 Finding 进入详情页，可查看问题的完整信息。以上述场景为例，一个典型 Finding 包含：

标题        安全组公网暴露 SSH
类别        安全风险        严重度    高
置信度      0.95
摘要        同一安全组规则导致多台 ECS 实例暴露 22 端口。

影响对象    安全组 sg-xxx（锚定对象）
            ECS 实例 i-xxx1、i-xxx2 等 10 台（受影响对象）

证据        安全组入方向规则快照：tcp 22/22，源 0.0.0.0/0

处理项      收敛安全组公网 SSH 入方向规则
            风险等级：高（需人工确认后执行）
            验证条件：安全组不再放通 0.0.0.0/0:22

状态        打开    首次发现：06-10 09:00    发生次数：1

步骤三：确认问题结论（可选）

如果对 Finding 的判断存疑，可以：

单击再次确认，系统将自动发起对话，由数字员工重新核查该问题是否合理。例如安全组虽然放通了 22 端口，但关联实例均处于停止状态，数字员工会重新评估实际风险。
对 Finding 进行正向或负向反馈，负反馈可填写原因（如"影响对象识别有误"），帮助数字员工持续提升判断质量。
对需要重点跟进的问题，使用置顶、收藏等关注型操作。

步骤四：确认并执行处置

在 Finding 详情页查看处理项的处置方案和风险提示。
由于收敛安全组规则属于高风险操作，执行前会弹出确认提示，请核对影响面（关联的 10 台 ECS 实例、依赖 SSH 运维的通道等）。
确认无误后，通过以下任一方式完成人工确认（HIL）：
- 在控制台直接确认执行；
- 在钉钉等 IM 通知中单击确认（支持通知到个人或群组）；
- 通过 OpenAPI 对接企业自有审批系统完成确认。
数字员工执行处置动作（将 22 端口的放通源收敛为办公网段或跳板机安全组），执行过程全程可观测。
重要
高风险操作默认必须人工确认后才会执行。请确认处置方案中已预留合法的运维通道，避免直接关闭 22 端口导致运维失联。

步骤五：验证修复并自动关闭

下一轮定时巡检执行时，数字员工会重新检查原范围的安全组规则：

若验证条件"安全组不再放通 0.0.0.0/0:22"满足，Finding 自动关闭，关闭类型为"已解决"，完整保留处置与验证记录。
若本轮巡检未覆盖原检查范围（例如数据源临时不可用），Finding 不会关闭，避免"没检查到"被误判为"已解决"。

您也可以随时在详情页查看证据后手动关闭 Finding。

步骤六：问题复发场景

假设一个月后有人将安全组规则重新改回 0.0.0.0/0 放通，下一轮巡检发现该风险时：

系统识别出这与已关闭的 Finding 是同一问题，自动重新打开（Reopen）原 Finding，发生次数递增。
您可以完整回溯该问题的历史：首次发现时间、当时的处置方案、验证记录和本次复发的证据，快速定位是配置回退还是新增变更所致。

实践效果

通过本实践，安全风险巡检从"出报告"升级为"管闭环"：

去重降噪：同一问题 30 次巡检只对应一个 Finding，发生次数自动累计。
责任到人：处理项明确负责人与验证条件，处置进度可跟踪。
安全可控：高风险操作人工确认兜底，执行过程全程留痕可审计。
复发可感知：问题重复出现时自动重开并关联完整历史。

扩展场景

同样的闭环模式适用于更多巡检场景：

场景	Finding 聚合方式
多块磁盘即将写满	按磁盘或挂载点拆分，独立处理、独立验证。
多个 Pod 同一崩溃特征	聚合为一个 Finding，锚定到所属服务。
SSL 证书到期检查	按证书或域名聚合，处理项为更新证书并验证生效。
数据未接入、权限不足等诊断缺口	生成缺口类 Finding，处理项明确需补齐的数据或权限。