做云安全運營也有一年多時間了，對云上安全建設和運營有一點粗淺的經驗，希望可以拋磚引玉，借此文章能有機會和大佬們交流 安全運營，安全建設方向的經驗。

[[327356]]

首先我貼一張思維導圖，云上安全運營工作主要圍繞此圖開展，因為我們的身份是云安全乙方，所以不開展SDL工作。

一、風險管理

風險管理工作是安全運營的重頭戲，風險管理是一個動態的過程，所以工作量不言而喻。

我們的風險管理其實和甲方的有些不一樣，比如我們省去了對重要資產的估值這一步，只要是租戶的資產，我們都ALL IN ONE，我們把重心放在更細粒度的發現風險項上。

1.1 云上風險項

1.2 自動化監控風險

阿里云幾乎所有的產品都支持API調用，通過編寫相關規則，可以實現自動化監控風險的功能。

例如安全組風險，通過如下代碼可以獲取到某個Region的所有安全組信息

返回的字典數據中，Permission字段包含了“授權方向”，“IP協議”，“授權范圍”，“端口范圍”，“授權策略”

通過如下示例代碼可以過濾出存在高風險的安全組

這里僅以安全組風險舉例，其它風險項如法炮制，都是調用阿里云API獲取數據，并通過規則篩選出風險項。

6個風險項，以面向對象的編程思想封裝成6個類。并設置計劃任務，每天運行一次。

1.3 降低風險

降低風險也可以理解成風險處置。作為云安全乙方，我們沒有權限對租戶的風險項進行直接修改操作，只能通過以下兩種方式通知租戶進行修復：

1. 釘釘告警
2. 短信告警

1.4 責任劃分

• 平臺側：負責發現風險，并通知到租戶
• 租戶側：進行風險項整改工作

二、應急響應

資產數量多，難免會發生安全事件，所以應急響應也劃分進了安全運營范疇。處理過多次應急響應事件，包括挖礦事件，對外ddos事件。入侵原因top3：ssh暴力破解，redis未授權訪問，elasticsearch弱口令

2.1 事前準備

1. 編寫應急響應方案
2. 工具準備：windows，linux殺毒軟件，rootkit掃描工具

2.2 事中處置

遵守PDCERF模型進行應急響應工作。一般情況下，我會按照如下步驟進行應急

1. 初步判斷事件真偽
2. 找到項目負責人，拉群成立臨時應急響應小組
3. 經租戶授權許可后進行應急響應工作
4. 備份快照
5. 登錄服務器，分析網絡連接，并根據網絡連接進行訪問控制，例如挖礦通信端口1234，立即網絡阻斷掉該端口
6. 通過網絡訪問控制，對內網機器進行隔離，降低內網橫向感染風險
7. 分析進程，kill惡意進程
8. 檢查啟動項，刪除惡意啟動項
9. 檢查是否存在隱形賬號，并通過工具自動化檢查rootkit
10. 殺毒軟件對服務器進行全盤掃描，刪除病毒
11. 入侵溯源，重點分析：.bash_history, web日志，互聯網服務(例如elasticsearch，redis)日志
12. 找到入侵原因后，進行加固

2.3 事后關注

事后，要保持一段時間對該機器以及該網段其它機器進行重點關注，以防殘留后門導致事件復發。

三、安全巡檢

安全巡檢是安全運營工作中頻率最高的工作項。正常情況下，重要的部門需要一天進行2次巡檢，早上下午各一次。

3.1 編寫安全巡檢方案

將巡檢的操作流程，巡檢項，注意事項進行文檔化，一方面可以為新入職的安全工程師提供指導，另外一方面可以滿足安全評審需要。

3.2 日常巡檢工作

假設網絡環境分為專有云區和公有云區，有5個租戶，每天都要進行2次安全巡檢，那么一天巡檢的次數就是10次。需要關注的巡檢項包括：

1. 態勢感知事件
2. 主機安全事件
3. 基線檢查(風險)
4. 漏洞檢查(風險)

那么，浪費在5個租戶上的巡檢時間會非常多，好在阿里云提供了API，可以幫助我們從多租戶雙區域的手工巡檢中解脫出來。這里我想表達的意思是，其實安全巡檢本身沒什么技術含量，但卻又是一個重復繁瑣的工作，利用好編程能力，可以很大程度上提高 工作效率，這也是為什么很多公司要求安全運營人員要掌握一門編程語言的原因。

3.3 記錄巡檢數據

保存巡檢數據主要是為了審計，為了問責。(個人觀點)

假如4月1號早上發生了安全事件，作為安全運營工程師沒有及時做好巡檢工作，第二天巡檢的時候才發現事件告警，導致了租戶嚴重損失，這個責任是需要的安全工程師承擔的。

巡檢日志表格示例

上面的表格4.1沒有對主機安全事件進行巡檢，第二天才發現有挖礦事件，導致租戶遭受了重大損失。所以作為安全運營工程師應該承擔主要責任。

四、安全產品運營

云安全產品運營是我們云安全運營工程的職責之一。租戶通過開通/接入申請，我們對安全產品進行接入，配置操作。

1. 租戶申請10個域名接入WAF -> 安全運營工程師進行配置 -> 本地修改hosts驗證 -> 租戶修改dns記錄
2. 租戶申請10臺ECS接入堡壘機 -> 安全運營工程師進行配置 -> 通過test用戶驗證可用性 ->完成配置
3. 云盾功能性測試。(云盾版本升級后，或者同城容災部署后)

五、編寫文檔

編寫文檔，并不是安全運營工程師的主要職責，這個工作應該由安全架構師或者首席安全官來做。但有時候安全團隊會選擇相信我，讓我完成其中一部分文檔的編寫。例如《云上安全加固方案》，《安全巡檢方案》，《應急響應方案》。有時候嘗試做自己不擅長做的事情，能幫助自己快速成長。

六、業務上線評審(TODOLIST)

目前，租戶的業務上線是沒有經過我們安全評審的。比如項目方可以有權限自己開安全組，想怎么開就怎么開。業務系統上線前也幾乎不會做漏洞掃描和安全測試。安全工作應該伴隨項目規劃到項目實施再到上線項目的整個生命周期。不經過評審就直接上項目，嚴重違背了安全建設生命周期。這一塊需要規范起來，但一直沒有時間去做。