用Claude自動化阿里雲安全群組治理

簡而言之： 把安全群組規則匯出來，連同你想要的政策一起交給Claude，拿回一份按嚴重程度排序的清單：過度放行、無人需要、重複遮蔽、以及環境之間漂移的規則，並以可複核的差異形式呈現。這涵蓋了這件事的前百分之八十。而「套用變更」這一步仍然要走人工審批和變更紀錄——一個對正式環境安全群組有寫權限的AI代理，不是該建的形狀。

沒人會計劃讓一個安全群組最後攢到四十條規則。它是一個又一個緊急的週五攢出來的：一個供應商需要存取、一個外包在排查什麼、一個監控工具搆不到某個通訊埠。每一條規則在被加上的那天都合情合理。兩年之後，沒人說得清哪些還需要，而那條叫「test-rule-3」的規則，已經比三位可能知道它是幹什麼的人待得更久。

這件事持續存在的原因不是疏忽。手工複核規則是一項真正枯燥、又沒有可見回報的工作，它要求你一次性把整個資產裝進腦子裡，而在每一個具體的決策點上，感覺最安全的動作都是「別動這條」。於是規則越攢越多，攻擊面在悄悄變大。

這恰恰是語言模型真正擅長的那類問題：讀一份龐大的結構化匯出、把它對照一份你用大白話寫下來的政策、然後產出一份具體而有序的「看起來不對」的清單。它不擅長的是判斷「關掉這個通訊埠會不會弄壞正式環境」，而這正是「套用」那一半仍然屬於人的原因。

安全群組為什麼會腐化

到處都是同樣的模式，而把它們叫出名字就完成了一半的工作。

臨時規則變成永久規則。 為一次遷移、一次業者展示或一次除錯開的存取權，從來沒被關掉，因為關掉它沒有期限、也沒有人負責。

全世界都能到達一個管理通訊埠。 SSH或RDP上出現0.0.0.0/0這樣的來源範圍，是最常見的嚴重發現，而它通常是某人為了快點把自己放行、並打算「回頭再收緊」的結果。

規則沒有主人、也沒有到期。 那個本可以解釋這條規則的欄位是選填的，所以它是空的。而且沒有任何機制會在某一天問一句「這條還需要嗎？」

環境之間會漂移。 預備環境是十八個月前從正式環境複製出來的，此後兩邊各自演化，而沒人比對過——常見的情況是預備環境帶著更鬆的規則和同樣的資料。

重複和被遮蔽的規則會堆積。 兩條涵蓋範圍重疊的規則，其中一條永遠不會生效，而兩條都沒人敢刪，因為刪掉的後果並不清楚。

把當前狀態從阿里雲裡取出來

該匯出什麼，怎麼匯？

阿里雲透過ECS的API、以及基於它的命令列工具公開安全群組清單——「列出安全群組」和「查詢單個安全群組的規則」這兩個動作就是你需要的，而具體的動作名稱和參數值得去查當前的API文件，而不是相信某段程式碼片段，因為這些是會演進的。

匯出的東西要比規則本身更多。一條規則只有放在脈絡裡才可判斷，所以請把安全群組清單連同它們各自所屬的VPC和地區、每個群組的完整規則集，以及每個群組上實際掛載了哪些執行個體，一起拉出來。最後這一項比聽上去更重要：一個什麼都沒掛的寬鬆安全群組，和一個正在保護資料庫的同樣寬鬆的安全群組，是兩個不同的問題。

在你營運的每一個地區上都做一遍。自然生長出來的資產裡，幾乎總有一個被遺忘的地區，裡面還跑著東西；而一份只涵蓋了「你會想到的那個地區」的複核，恰恰會漏掉那個有意思的發現。

分析這一趟需要哪些RAM權限？

唯讀，而這不是走形式。分析這一趟只需要查詢安全群組和執行個體，別無其他，所以它應該在一個改不了任何東西的RAM身分下執行。阿里雲為ECS提供了符合這個需求的唯讀政策；請在RAM主控台裡核對當前的政策名稱和它們的確切範圍，而不是憑記憶用一個名字。

除了良好衛生之外，這件事要緊還有兩個理由。第一，一個唯讀憑證消除了整整一類事故——那種「本來只想產生報告的自動化最後改了東西」的事故；你最害怕的那件事變成了結構上不可能，而不只是「本意不是那樣」。第二，它改變了你和審批這項工作的人之間的對話：「一份唯讀匯出、由人複核、由人套用」是一個容易批的方案，而「一個對防火牆有寫權限的代理」不是，也不該是。

把這個憑證像對待任何其他正式環境金鑰那樣存放，並給它一個有效期。一個長期有效的AccessKey躺在某個指令碼目錄裡，比這次複核會翻出來的大多數問題都更嚴重。

該讓Claude找什麼

四個能產出發現的問題

先說明你想要的政策——哪些通訊埠可以對公網開放、管理存取可以接受哪些來源、你的各個環境本來應該長什麼樣——然後對照它去問。沒有一份說明白的政策，模型就會套用泛泛的最佳實務，產出一堆你會跟它爭的發現。

過度放行的來源。 任何放行了寬泛公網範圍的規則，按「它後面是什麼」排序。先是管理通訊埠，然後是其餘的，並且把每個群組上掛載的執行個體名列出來，好讓讀的人判斷嚴重程度。

看起來沒有東西需要的規則。 對應不上任何你在跑的服務的通訊埠、沒有掛載任何執行個體的安全群組、指向一個你早已停止合作的供應商的來源。模型提出，你來確認——它看不到你的流量。

重複和被遮蔽的規則。 範圍重疊、其中一條讓另一條變得無關緊要的情況。在四十條規則裡靠手工找出來很枯燥，而對一個一次性讀完全部的模型來說不值一提。

環境之間的漂移。 給它兩份匯出，問它有什麼不同。這是那種沒人會手工去做的檢查，而令人意外的發現常常就在那裡。

要一份差異，而不是一篇散文

輸出格式決定了這件事會不會變成常規。一段描述你資安態勢的散文是不可操作的，也沒人會讀第二遍。

請改為要求：每一條提議的變更佔一行——哪個群組、哪條規則、改成什麼、為什麼、以及一個嚴重程度。要求給出實現它的確切API呼叫或主控台操作，讓複核的人是在檢查一個具體動作，而不是在解讀一條建議。並且明確要求每一項都附一句「影響半徑」——如果這條改錯了，什麼會停止運作——因為那正是複核者真正需要的欄位，也是模型不被要求就會跳過的那個。

把提議和分析分開放。一個正在審批變更的人，應該讀到的是一份變更清單，而不是在一段解釋裡翻找它們。

一個週期性的治理閉環

五步，按這個順序，每次都一樣。

匯出當前狀態，按排程執行，而不是等誰想起來。分析，對照你說明白的政策。複核那份提議的差異，由人來做，凡是影響半徑不清楚的一律打回。套用，走你正常的變更流程——和任何其他防火牆變更走同一條、同樣的審批。記錄改了什麼、為什麼、誰批的。

對一個經常變動的資產來說，每月做一次匯出和分析是合理的節奏；對一個穩定的資產，每季也說得過去。而比間隔更要緊的是這個閉環真的閉上：一份沒人複核的分析比沒有分析更糟，因為它製造出一條「工作已經做過」的書面痕跡。

AI輔助規則複核 vs 雲端原生設定工具 vs 託管資安服務

起步成本 — AI輔助複核勝出。一份匯出、一段提示、一個下午。
理解你的意圖 — AI輔助複核明顯勝出。原生工具對照的是泛泛的最佳實務；一個模型可以對照你自己寫下的政策，包括你刻意留下的那些例外。
持續、自動的評估 — 雲端原生設定工具勝出。它們不需要誰記得就會執行，而「需要誰記得」正是每一個手工流程的失敗模式。
安全群組之外的涵蓋面 — 原生工具和託管服務都勝過一次性複核，後者只看得見你匯出的那部分。
有人為結果負責 — 託管資安服務完勝。無論你的工程師忙不忙，複核都會發生，而且結果由別人負責。
能拿去稽核的證據 — 託管服務勝出。一份帶日期和審批鏈的報告是稽核方接受的東西；一段聊天紀錄不是。

它們是疊加關係而不是競爭關係。對一個從沒被複核過的資產來說，AI輔助的一趟是最快的清理方式；一個原生設定工具讓它不再重新腐化；而當這套紀律需要在「大家都很忙」的情況下依然活著時，你買的就是託管服務。

哪些規則絕不能自動化掉

三條，而它們正是「治理」和「事故」之間的差別。

每一次變更都由人審批。 模型提出，一個有脈絡的人來定。即使提議明顯是對的，這條也成立，因為「明顯是對的」恰恰是自動化做不了、而人做得了的那種判斷。

每一次變更都留下紀錄。 改了什麼、什麼時候、誰批的、理由是什麼。這是讓下一次複核成為可能的東西，也是稽核方會要的東西。

每一次變更都有回滾路徑。 在套用之前，先知道原先的狀態和怎麼恢復它。把變更之前那份匯出留著——它就是回滾方案。

以及貫穿這三條的那個立場：不要針對正式環境的安全群組去搭一個自動套用的閉環。 一個能在沒有人在路徑上的情況下打開通訊埠的代理，是你一開始那個問題的一個更新、也更糟的版本。「讀取並提議」是形狀；「套用」是一個決定。

把這件事做對：RAM憑證、變更控制，以及何時該讓IT介入

有三件事值得刻意定下來。

第一，憑證。一個唯讀的RAM身分，範圍收斂到分析所需，有明確的有效期，並且像任何其他正式環境金鑰那樣存放。如果同一套自動化以後需要套用變更，那是另一個身分、另一次審批、另一場對話——而不是把第一個的權限擴一擴。

第二，什麼離開了你的環境。一份安全群組匯出就是一張你攻擊面的地圖：哪些通訊埠開著、從哪裡能進、保護著什麼。這確實敏感，而它去了哪裡值得一個決定，而不是一個習慣。請讀一讀你所用那個具體產品層級的資料處理與訓練條款，而不是靠假設，因為商業版和企業版通常與消費級不同，條款也會變。出於同樣的原因，我們在內部AI助理的中國資料落地問題裡討論過的那些考量，在這裡同樣適用。

第三，當所有人都忙起來時，誰來負責這個閉環。這才是會衰減的那部分。防火牆規則的變更與調校、每月的差距分析、每季的設定備份，恰恰是託管IT資安服務作為一項持續運轉的紀律（而不是一個意願）所涵蓋的內容。我們的AI+支援服務幫你把這類自動化建在受治理的憑證和公司帳號上；我們的託管IT支援則涵蓋圍繞它的權限生命週期。Brocent自2007年在北京創立以來，一直在亞洲提供託管IT與資安服務，總部位於新加坡，並自2016年起設有香港辦公室。

常見問題

AI代理應該自動套用安全群組變更嗎？

不應該，至少不能對正式環境。失敗模式不是「模型偶爾會錯」——而是當它錯的時候沒人會注意到，因為紀錄上寫著「變更已由一套流程而不是一個人核准並執行」。請把模型留在分析和提議上，並在任何會修改規則的動作前面，放一個人和一條變更紀錄。

分析這一趟到底需要哪些RAM權限？

讀取權限，用於查詢安全群組、它們的規則，以及掛載在上面的執行個體，別無其他。阿里雲發布了涵蓋這一點的ECS唯讀政策；請在RAM主控台裡核對當前的名稱和範圍，而不是從一篇文章裡抄一個政策名。如果一份被提議的權限集裡包含任何能修改的東西，那它就是這件事的錯誤權限集。

把規則集匯出給AI工具會不會造成暴露？

這是一個真實的考量，因為那份匯出描述的就是你的攻擊面。請刻意地決定它：核對你所用層級的資料處理條款、優先選擇商業版或企業版，並考慮在不破壞分析的前提下去識別化執行個體標識。對那些無法接受這一點的資產，同樣的方法用一個自架模型、或者一套指令碼化的規則檢查，也一樣成立。

這應該多久跑一次？

對經常變動的資產每月一次，對穩定的資產每季一次，以及在任何重大遷移或新環境上線之後立刻做一次。間隔本身沒有「閉環是否閉上」重要——一份沒人複核的匯出提供不了任何保護，還製造出一條誤導性的紀錄。

這和等保等稽核要求怎麼銜接？

「對網路存取控制做週期性複核並留存證據」，是包括中國等級保護制度在內的多種安全框架裡常見的期待。這個閉環產出的那些東西——一份帶日期的匯出、一份成文的政策、一份被複核過的提議、一次審批和一條變更紀錄——正是稽核方會要的證據形狀。至於適用於你所定級別的具體要求，請與有資格的評測機構確認，而不要假設這樣就滿足了。

模型能告訴我們哪些規則實際在用嗎？

僅憑規則集不能——它只能根據你描述的服務，告訴你哪些規則看起來不必要。真實的使用情況需要流量資料，那是另一個你得自己提供的來源。請把每一條「看起來沒在用」的發現當作一個要去問懂這個系統的人的問題，而不是一個結論。

從哪裡開始

挑一個地區和一個正式環境VPC。把安全群組、它們的規則和掛載的執行個體匯出來，用五句大白話寫下你想要的政策，然後要求按「後面是什麼」排序的過度放行規則清單。你會拿到一份不長的清單，其中大部分你認得，還有一些你不認得。先修那些對全世界開放的管理通訊埠，走你正常的變更流程，並把那份匯出留作回滾。然後決定下個月由誰再跑一次——因為一次性的清理，價值遠低於一個不需要誰記得的閉環。如果你更希望這個閉環被妥善地負責起來，並帶著稽核會要的那條證據鏈，歡迎與我們聯絡。