問題發現（Findings）最佳實務：安全風險巡檢閉環 - STAROps

本文以"安全性群組公網暴露風險巡檢"為例，介紹如何通過問題發現（Findings）能力，完成從定時巡檢、問題產生、人工確認、處置執行到驗證關閉的完整閉環，讓安全風險"發現一個、跟蹤一個、閉環一個"。

業務情境

企業安全團隊需要定期檢查雲資源的公網暴露面，例如安全性群組是否對 0.0.0.0/0 放通了 SSH（22）、RDP（3389）等高危連接埠。傳統巡檢方式存在以下痛點：

問題跟蹤靠人工台賬：巡檢產出的報告是一份"快照"，問題有沒有處理、處理到哪一步，需要人工記錄和跟進。
重複問題反覆上報：同一安全性群組規則問題每次巡檢都出現在報告裡，無法識別"這是同一個老問題"。
修複效果無法驗證：安全性群組規則改了沒有、改得對不對，缺少自動化手段驗證，"沒看到警示"常被誤認為"問題已解決"。
問題複發無感知：已修複的問題被再次改壞時，沒有機制能關聯歷史處理記錄。

通過 STAROps 的問題發現（Findings）能力，數字員工會在巡檢中自動將風險歸納為問題（Finding），自動去重、跟蹤處置進度、驗證修複效果，並在複發時重新開啟原問題，實現安全風險的閉環管理。

方案架構

本實踐的完整閉環涉及以下核心環節：

定時巡檢：建立定時觸發的長期任務（Mission），數字員工按計劃自動執行安全性群組規則檢查。
問題產生：數字員工將巡檢發現的風險歸納為 Finding：同一安全性群組規則導致多台 ECS 暴露的問題彙總為一個 Finding 並錨定安全性群組；建立前自動與歷史 Finding 做相似性檢查，避免重複上報。
查看與確認：營運人員在控制台查看 Finding 詳情、證據和影響面；對結論存疑時可發起"再次確認"，由數字員工重新核查。
處置執行：Finding 內建處理項（Task）和驗證條件。收斂安全性群組規則屬於高風險操作，預設進入人工確認（HIL）流程，可通過DingTalk等 IM 一鍵確認後由數字員工執行。
驗證關閉：下一輪巡檢覆蓋原檢查範圍且未再發現該風險時，Finding 自動關閉。
複發重開：已關閉的問題再次出現時，原 Finding 被重新開啟並延續歷史，而不是建立問題。

環境確認

在開始之前，確認以下環境已就緒：

檢查項	確認方式
數字員工已建立	在 STAROps 控制台確認目標數字員工狀態正常。
工作空間已接入雲資源資料	在工作空間詳情頁確認已接入安全性群組、ECS 執行個體等雲資源配置資料。
數字員工具備要求的權限	數字員工關聯的 RAM 角色需要具備安全性群組規則的讀取許可權；如需自動執行收斂操作，還需具備對應寫入權限。
通知渠道已配置	如需通過 IM 進行高風險操作確認，請提前配置DingTalk等通知渠道。

實施步驟

步驟一：建立安全巡檢長期任務

登入 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）：
- 在控制台直接確認執行；
- 在DingTalk等 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，處理項明確需補齊的資料或許可權。