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

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

一、風險管理

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

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

1.1 雲上風險項

風險名稱	詳情
安全組風險	[-1/-1,21/21,22/22,3389/3389,6379/6379,1433/1433,3306/3306]，0.0.0.0/0，入方向，允許
RDS白名單風險	白名單策略：0.0.0.0/0
安騎士離線風險	安騎士狀態: offline
漏洞	調用雲盾API獲取相關數據
弱口令風險	數據庫，tomcat，weblogic，RDP，SSH
基線檢查	調用雲盾基線檢查API獲取

1.2 自動化監控風險

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

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

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

Permission	安全組權限規則**。
CreateTime	String	2018-12-12T07:28:38Z	創建時間，UTC時間。
Description	String	FinanceDept	安全組描述信息。
DestCidrIp	String	0.0.0.0/0	目標IP地址段，用於出方向授權。
DestGroupId	String	sg-securitygroupid1	目標安全組，用於出方向授權。
DestGroupName	String	SecurityGuard	目的端安全組名稱。
DestGroupOwnerAccount	String	SecurityGuard	目標安全組所屬阿里雲賬戶ID。
Direction	String	ingress	授權方向。
IpProtocol	String	TCP	IP協議。
Ipv6DestCidrIp	String	2001:db8:1233:1a00::***	目的IPv6地址段。
Ipv6SourceCidrIp	String	2001:db8:1234:1a00::***	源IPv6地址段。
NicType	String	intranet	網絡類型。
Policy	String	Accept	授權策略。
PortRange	String	80/80	端口範圍。
Priority	String	1	規則優先級。
SourceCidrIp	String	0.0.0.0/0	源IP地址段，用於入方向授權。
SourceGroupId	String	sg-securitygroupid2	源安全組，用於入方向授權。
SourceGroupName	String	FinanceDeptJoshua	源端安全組名稱。
SourceGroupOwnerAccount	String	FinanceJoshua	源安全組所屬阿里雲賬戶ID。
SourcePortRange	String	80/80	源端端口範圍。

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

這裏僅以安全組風險舉例，其它風險項如法炮製，都是調用阿里雲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號早上發生了安全事件，作爲安全運營工程師沒有及時做好巡檢工作，第二天巡檢的時候才發現事件告警，導致了租戶嚴重損失，這個責任是需要的安全工程師承擔的。

巡檢日誌表格示例

巡檢時間	巡檢項	租戶	備註
2020.4.1 10:20	基線檢查	省政府	安全
2020.4.1 10:20	態勢感知事件	省政府	安全
2020.4.2 16:20	基線檢查	省政府	安全
2020.4.2 16:20	漏洞檢查	省政府	安全
2020.4.2 16:20	態勢感知事件	省政府	暴力破解成功
2020.4.2 16:20	主機安全事件	省政府	挖礦事件

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

四、安全產品運營

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

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

五、編寫文檔

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

六、業務上線評審（TODOLIST）

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

雲安全業務上線評審項
1. 業務系統是否做過安全測試
2. web業務是否接入WAF
3. 服務器配置是否滿足安全基線要求
4. 安全組是否滿足安全要求
5. 安騎士是否在線
6. web程序是否以最低權限要求運行

*本文作者：Haczhou，轉載請註明來自FreeBuf.COM