做雲安全運營也有一年多時間了,對雲上安全建設和運營有一點粗淺的經驗,希望可以抛磚引玉,借此文章能有機會和大佬們交流 安全運營,安全建設方向的經驗。
首先我貼一張思維導圖,雲上安全運營工作主要圍繞此圖開展,因為我們的身份是雲安全乙方,所以不開展SDL工作。
風險管理工作是安全運營的重頭戲,風險管理是一個動态的過程,所以工作量不言而喻。
我們的風險管理其實和甲方的有些不一樣,比如我們省去了對重要資産的估值這一步,隻要是租戶的資産,我們都ALL IN ONE,我們把重心放在更細粒度的發現風險項上。
風險名稱詳情安全組風險[-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獲取
阿裡雲幾乎所有的産品都支持API調用,通過編寫相關規則,可以實現自動化監控風險的功能。
例如安全組風險,通過如下代碼可以獲取到某個Region的所有安全組信息
返回的字典數據中,Permission字段包含了“授權方向”,“IP協議”,“授權範圍”,“端口範圍”,“授權策略”
Permission安全組權限規則**。CreateTimeStringDescriptionStringDestCidrIpStringDestGroupIdStringDestGroupNameStringDestGroupOwnerAccountStringDirectionStringIpProtocolStringIpv6DestCidrIpStringIpv6SourceCidrIpStringNicTypeStringPolicyStringPortRangeStringPriorityStringSourceCidrIpStringSourceGroupIdStringSourceGroupNameStringSourceGroupOwnerAccountStringSourcePortRangeString
通過如下示例代碼可以過濾出存在高風險的安全組
這裡僅以安全組風險舉例,其它風險項如法炮制,都是調用阿裡雲API獲取數據,并通過規則篩選出風險項。
6個風險項,以面向對象的編程思想封裝成6個類。并設置計劃任務,每天運行一次。
降低風險也可以理解成風險處置。作為雲安全乙方,我們沒有權限對租戶的風險項進行直接修改操作,隻能通過以下兩種方式通知租戶進行修複:
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業務是否接入WAF3. 服務器配置是否滿足安全基線要求4. 安全組是否滿足安全要求5. 安騎士是否在線6. web程序是否以最低權限要求運行
*本文作者:Haczhou,轉載請注明來自FreeBuf.COM
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!