云資源安全合規(guī)基線自動(dòng)化檢查與配置方案

1、 云資源安全合規(guī)基線自動(dòng)化檢查與配置方案 目 錄 TOC o 1-3 h z u HYPERLINK l _Toc66556447 云資源安全合規(guī)基線自動(dòng)化檢查與配置 PAGEREF _Toc66556447 h 1 HYPERLINK l _Toc66556448 1 云資源安全合規(guī)基線需求和問題 PAGEREF _Toc66556448 h 3 HYPERLINK l _Toc66556449 2 安全基線自動(dòng)化檢查與配置相關(guān)服務(wù)簡介 PAGEREF _Toc66556449 h 4 HYPERLINK l _Toc66556450 2.1 操作記錄審計(jì)服務(wù) PAGEREF _Toc665

2、56450 h 4 HYPERLINK l _Toc66556451 2.2 事件與性能監(jiān)控服務(wù) PAGEREF _Toc66556451 h 4 HYPERLINK l _Toc66556452 2.3 Serverless計(jì)算 PAGEREF _Toc66556452 h 5 HYPERLINK l _Toc66556453 3 安全基線自動(dòng)化檢查與配置實(shí)現(xiàn)方案 PAGEREF _Toc66556453 h 6 HYPERLINK l _Toc66556454 3.1 手動(dòng)拼積木 PAGEREF _Toc66556454 h 6 HYPERLINK l _Toc66556455 3.2 使

3、用云平臺(tái)托管服務(wù) PAGEREF _Toc66556455 h 6 HYPERLINK l _Toc66556456 3.3 使用Policy As Service服務(wù) PAGEREF _Toc66556456 h 7 HYPERLINK l _Toc66556457 4 cloud custodian項(xiàng)目簡介 PAGEREF _Toc66556457 h 7 HYPERLINK l _Toc66556458 4.1 resource PAGEREF _Toc66556458 h 8 HYPERLINK l _Toc66556459 4.2 filters PAGEREF _Toc665564

4、59 h 8 HYPERLINK l _Toc66556460 4.3 actions PAGEREF _Toc66556460 h 9 HYPERLINK l _Toc66556461 4.4 一個(gè)完整的例子 PAGEREF _Toc66556461 h 9 HYPERLINK l _Toc66556462 4.5 mode PAGEREF _Toc66556462 h 10 HYPERLINK l _Toc66556463 5 總結(jié) PAGEREF _Toc66556463 h 13【導(dǎo)讀】本文首先介紹了云平臺(tái)和資源的安全合規(guī)配置基線的需求和問題，然后結(jié)合AWS為例介紹了如何集成云平臺(tái)已有

5、的托管服務(wù)實(shí)現(xiàn)云平臺(tái)和資源的安全合規(guī)自動(dòng)配置和檢查，最后以custodian為例介紹基于Policy規(guī)則聲明式配置和檢查安全合規(guī)基線。1 云資源安全合規(guī)基線需求和問題云平臺(tái)通過自服務(wù)接口提供了快速的資源供給方式，用戶通過云平臺(tái)console或者云管平臺(tái)可以靈活按需快速構(gòu)建云資源，甚至可以在幾分鐘構(gòu)建自己的虛擬數(shù)據(jù)中心，資源的快速構(gòu)建已不是什么難事，真正的難事在于如何有效治理好云資源，安全合規(guī)治理、標(biāo)簽治理、配置與安全基線檢查等都不是什么容易的事。如果前面有云管則可以擋一道，做一些配置限制、基線檢查以及自動(dòng)調(diào)整，但同時(shí)也失去了部分靈活性，并且也難以做到覆蓋所有規(guī)范點(diǎn)。部分企業(yè)采用保姆式，云基礎(chǔ)資

6、源的申請均由云部門統(tǒng)一管理，包括創(chuàng)建和更新，通過一系列流程完成云資源最終交付，業(yè)務(wù)部門只需要能夠通過堡壘機(jī)訪問即可，這樣其實(shí)工作都壓在了云部門，交付也失去了敏捷性。無論采用哪種方式，管理員都避免不了對云資源進(jìn)行審計(jì)和檢查，云基礎(chǔ)資源管理員往往需要花費(fèi)大量的時(shí)間去檢查資源是否滿足安全合規(guī)性、是否符合監(jiān)管要求、是否遵循安全配置基線，常做的工作如檢查資源的標(biāo)簽是否完備并且符合規(guī)范、安全組是否開放了高危端口、虛擬機(jī)是否使用了滿足要求的黃金AMI、業(yè)務(wù)有沒有考慮跨多AZ、磁盤是否加密、虛擬機(jī)是否直接掛彈性IP等等，虛擬機(jī)資源甚至還需要類似主機(jī)IDS工具做進(jìn)一步OS級別的基線檢查。通常我們有如下幾種方法來

7、完成如上工作：人肉檢查。最土的辦法，登錄每個(gè)業(yè)務(wù)賬號一個(gè)一個(gè)檢查，這種方式費(fèi)力不討好，效率低下。腳本輪詢檢查。通過調(diào)用云平臺(tái)API檢查資源是否合規(guī)及滿足配置基線。這種方法在資源規(guī)模不大的情況下效率還可以，但很考驗(yàn)工程師的腳本能力，腳本維護(hù)起來也比較難。云平臺(tái)托管服務(wù)。這是比較推薦的方法，很多云平臺(tái)都提供了資源的合規(guī)性檢查服務(wù)，比如OpenStack的Congress服務(wù)、AWS Config服務(wù)等。第一種方法沒什么可說的，一兩個(gè)賬戶可以這么玩，幾十上百個(gè)賬戶基本不可行。第二種方法最大的問題是腳本開發(fā)和維護(hù)比較難，除非自己實(shí)現(xiàn)一套規(guī)則引擎框架，否則一個(gè)規(guī)則一個(gè)腳本，根本無法維護(hù)。因此我們主要討論

8、第三種方案，以AWS為例簡要介紹如何利用AWS托管服務(wù)做基線自動(dòng)檢查與配置。2 安全基線自動(dòng)化檢查與配置相關(guān)服務(wù)簡介2.1 操作記錄審計(jì)服務(wù)安全基線自動(dòng)化配置和檢查從用戶操作的時(shí)間點(diǎn)就已經(jīng)開始了，云平臺(tái)每一次在處理API調(diào)用時(shí)都會(huì)記錄誰在什么時(shí)候執(zhí)行了什么操作，每一次操作都會(huì)產(chǎn)生一個(gè)事件，事件中還會(huì)包含API調(diào)用的請求參數(shù)、創(chuàng)建的資源對象等信息。這個(gè)功能不僅是監(jiān)管以及安全審計(jì)要求，也是真正實(shí)現(xiàn)基于事件驅(qū)動(dòng)的基線檢查持續(xù)性和實(shí)時(shí)性的基礎(chǔ)。CloudTrail是AWS的審計(jì)服務(wù)，記錄了所有通過AWS管理控制臺(tái)、AWS開發(fā)工具包、命令行工具和其他AWS服務(wù)執(zhí)行的任何操作。2.2 事件與性能監(jiān)控服務(wù)光

9、產(chǎn)生了操作記錄事件還不行，要實(shí)現(xiàn)基線自動(dòng)化配置和檢查，還需要把這些事件監(jiān)控起來，因此需要監(jiān)控服務(wù)。監(jiān)控服務(wù)不僅僅包括監(jiān)控其他服務(wù)的性能指標(biāo)，還包括監(jiān)控所有的事件和日志。由于監(jiān)控指標(biāo)和事件往往都會(huì)很多，因此監(jiān)控服務(wù)還需要支持根據(jù)一定的條件進(jìn)行數(shù)據(jù)過濾，傳統(tǒng)的監(jiān)控服務(wù)如Zabbix、Prometheus都支持。Cloudwatch是AWS的監(jiān)控服務(wù)，支持根據(jù)規(guī)則過濾和監(jiān)視各種事件。2.3 Serverless計(jì)算事件產(chǎn)生了并且也監(jiān)控起來了，剩下最后一步就是真正的action。你可以訂閱這些事件或者輪詢發(fā)生的事件，然后自己起一個(gè)虛擬機(jī)部署handler服務(wù)來處理消費(fèi)這些事件。但我認(rèn)為最適合用來做ac

10、tion的是serverless計(jì)算，又稱函數(shù)計(jì)算。這是因?yàn)椋阂来翁幚淼氖录ǔ６际仟?dú)立無狀態(tài)的，因此不需要后臺(tái)服務(wù)和存儲(chǔ)介質(zhì)來專門保存狀態(tài)。我們處理的事件產(chǎn)生通常是無時(shí)間規(guī)律的，這種場景不適合起一個(gè)專門的服務(wù)輪詢監(jiān)視，不僅不能保證處理的即時(shí)性，還可能由于無事件產(chǎn)生出現(xiàn)服務(wù)器資源閑置，浪費(fèi)計(jì)算資源。而基于事件觸發(fā)的函數(shù)計(jì)算能最小粒度的實(shí)現(xiàn)按需按量計(jì)算、收費(fèi)，省時(shí)省錢。AWS Lambda服務(wù)是AWS的函數(shù)計(jì)算服務(wù)，支持各種事件觸發(fā)，其中包括Cloudwatch。3 安全基線自動(dòng)化檢查與配置實(shí)現(xiàn)方案3.1 手動(dòng)拼積木有了前面的基礎(chǔ)，充分利用和集成云平臺(tái)已有的托管服務(wù)，很容易就可以實(shí)現(xiàn)安全基線自動(dòng)

11、化檢查與配置工作了。以AWS安全組規(guī)則為例，只需要開啟Cloudtrail功能，并在Cloudwatch中配置規(guī)則Rule監(jiān)聽 AuthorizeSecurityGroupIngress事件，然后Target配置觸發(fā)Lambda函數(shù)，Lambda函數(shù)拿到事件，找到安全組規(guī)則對應(yīng)的資源對象，檢查是否滿足要求，不滿足要求則進(jìn)行通知告警，通過lambda能做權(quán)限范圍以內(nèi)的任何事。另外以一個(gè)AWS上常見的問題為例，我們知道AWS的EC2、EBS等資源是不記錄創(chuàng)建用戶的，如果一個(gè)賬戶有多個(gè)用戶，在EC2列表中根本查不到這個(gè)虛擬機(jī)到底是誰創(chuàng)建的，只能通過cloudtrail在海量日志中慢慢去找了。解決的辦

12、法其實(shí)也很簡單，通過cloudwatch監(jiān)聽cloudtrail的RunInstances事件并觸發(fā)lambda函數(shù)調(diào)用，這個(gè)lambda函數(shù)負(fù)責(zé)把event取出來，根據(jù)event的記錄的用戶名把標(biāo)簽CreatorName打到EC2實(shí)例上即可。我們發(fā)現(xiàn)這種方案的工作量主要集中在Lambda函數(shù)的代碼開發(fā)。3.2 使用云平臺(tái)托管服務(wù)很多云平臺(tái)都提供了專門的配置基線檢查托管服務(wù)，比如OpenStack Congress服務(wù)、AWS的Config服務(wù)，使用這些托管的服務(wù)，利用其內(nèi)置的規(guī)則能夠省去寫lambda代碼。以AWS Config為例，目前國內(nèi)AWS已經(jīng)支持83條托管規(guī)則，包括：檢查是否使用合

13、規(guī)的AMI；檢查Tag是否完備和規(guī)范；檢查安全組是否開放了指定端口的/0訪問；.但是AWS Config服務(wù)只能做合規(guī)性配置基線檢查，不能做任何操作。另外如果托管的規(guī)則不能滿足需求，Config還支持觸發(fā)自定義Lambda函數(shù)。3.3 使用Policy As Service服務(wù)前面介紹的方法配置都不是什么難事，難就難在需要自己寫lambda函數(shù)，規(guī)則多了工作量還是挺大的，并且規(guī)則多了代碼維護(hù)起來也特別麻煩。如果能把規(guī)則邏輯從代碼中抽象出來，用戶只需要聲明或者定義規(guī)則，不需要每個(gè)規(guī)則都要自己寫lambda函數(shù)告訴平臺(tái)怎么一步步處理，而只需要復(fù)用一套通用規(guī)則引擎，則顯然無論工作量還是

14、管理難度都會(huì)大大減少。這就是我們將要介紹的Policy as Service服務(wù)，我們只需要根據(jù)規(guī)則聲明Policy，無需關(guān)心具體怎么實(shí)現(xiàn)的，只要關(guān)心最終狀態(tài)是否滿足我們聲明的規(guī)則即可。聲明式編程在其他地方也被廣泛使用，比如Kubernetes通過YAML文件聲明資源，Docker Compose也是，Terraform也是如此。Congress是針對OpenStack基于Policy聲明的安全合規(guī)配置基線檢查工具。CapitalOne開源的cloud custodian（簡稱c7n）也是基于policy聲明的云資源配置基線檢查工具，目前支持AWS、Azure以及GCP，未來可能還會(huì)支持Kub

15、ernetes。本文接下來簡單介紹下cloud custodian項(xiàng)目。4 cloud custodian項(xiàng)目簡介相比前面的介紹的方法需要自己寫lambda函數(shù)或者腳本，c7n是聲明式的，這很符合現(xiàn)代的使用模式。c7n policy包含3個(gè)主要部分：resource: 聲明資源類型，比如aws.ec2。filters: 資源的匹配條件，即聲明滿足這條policy的條件是什么。actions: 行為，即聲明滿足policy條件后做什么，比如對虛擬機(jī)關(guān)機(jī)、刪除虛擬機(jī)、打標(biāo)簽等都是action。4.1 resourcec7n支持AWS 162種資源類型，通過custodian schema可以列出所

16、有的resource類型:resources:- aws.account- aws.ami- aws.ec2- .不同的資源類型支持不同的filters以及actions。4.2 filters不同的resource支持不同的filter type，其中value type可以說是最樸素也是最通用的filter type了，直接讀取resource的屬性值進(jìn)行匹配。比如我們通常會(huì)制作自己的黃金AMI，我們要求業(yè)務(wù)必須使用黃金AMI啟動(dòng)虛擬機(jī)，通過如下filters可以找出所有不合規(guī)的虛擬機(jī)列表:filters:- type: value key: ImageId op: not-in valu

17、e:- ami-1# Invalid- ami-2# Invalid- .如果是單值匹配，可以簡化寫法， type可以省略。比如過濾所有運(yùn)行狀態(tài)為running的AWS ec2虛擬機(jī)，filters可以簡化為:filters:- State.Name: running基于標(biāo)簽過濾資源可能是最常用的方式了，因此使用標(biāo)簽也有簡便的寫法:- tag:Custodian: value如上過濾所有打了Custodian標(biāo)簽值為 value的資源列表。如果匹配所有沒有打Custodian標(biāo)簽的資源列表可以寫成tag:Custodian:present，其中 present是一個(gè)特殊的操作符，表示該屬性值不

18、存在，更多的操作符可以參考官方文檔Generic Filters。除了value的filter type，針對特定的resource類型，還有許多非常有用的filter type，通過custodian schema aws.ec2.filters可以查看AWS ec2支持的所有filters type，比如instance-age type可以基于實(shí)例創(chuàng)建時(shí)長進(jìn)行過濾:- type: instance-age days: 60如上會(huì)匹配所有超過2個(gè)月的虛擬機(jī)。4.3 actions和filters一樣，不同的resource type支持不同的action，以ec2為例支持的actions包

19、括但不限于如下:開關(guān)機(jī)、重啟;修改安全組;打標(biāo)簽、修改標(biāo)簽；打快照；執(zhí)行l(wèi)ambda函數(shù)、webhook；告警、郵件通知；.4.4 一個(gè)完整的例子有了resource、filters、actions我們就可以確定針對哪種資源滿足什么條件執(zhí)行什么動(dòng)作了。還是以前面的黃金AMI為例，假設(shè)我們針對沒有按照要求使用管理員規(guī)定的黃金AMI的不合規(guī)虛擬機(jī)執(zhí)行關(guān)機(jī)操作， resource: ec2 comment: |Find all running EC2 instances that are using invalid AMIsand stop them filters:- State.Name: ru

20、nning- type: value key: ImageId op: in value:- ami-1# Invalid- ami-2- . actions:- stop在本地執(zhí)行：4.5 modecustodian是一次運(yùn)行的Job任務(wù)，和Terraform一樣運(yùn)行完任務(wù)就結(jié)束了，沒有運(yùn)行任何后臺(tái)服務(wù)。因此需要每次在虛擬機(jī)上敲命令行手動(dòng)執(zhí)行，當(dāng)然聰明點(diǎn)的做法是寫一個(gè)cron job，每隔一段時(shí)間自動(dòng)跑一遍。如果c7n只支持這種模式那就沒啥用了，顯然c7n不會(huì)做得這么低端。其實(shí)c7n最強(qiáng)大的功能角色是充當(dāng)粘合劑，把云平臺(tái)的各種配置功能粘合在一起，集成云平臺(tái)已有的托管工具。以AWS為例，由于c

21、7n是一次運(yùn)行的無狀態(tài)Job任務(wù)，那其實(shí)根本就不需要在虛擬機(jī)上本地運(yùn)行浪費(fèi)虛擬機(jī)浪費(fèi)錢，現(xiàn)在都流行serverless了，lambda再合適不過了。誰來觸發(fā)lambda，當(dāng)然event最合適，因此使用cloudwatch觸發(fā)最合適。event誰來產(chǎn)生，cloudtrail會(huì)記錄AWS的所有API調(diào)用event，因此cloudtrail最合適做event的記錄和發(fā)布了。AWS支持cloudwatch、cloudtail、config-rule等各種mode。還是以AWS自動(dòng)給資源打上User標(biāo)簽的問題為例，前面已經(jīng)介紹了實(shí)現(xiàn)方案?，F(xiàn)在的問題是如果有很多賬戶，每個(gè)賬戶都手動(dòng)配置一遍顯然非常繁瑣且耗

22、時(shí)間。當(dāng)然可以把lambda函數(shù)提前放到S3上，然后通過Terraform配置lambda、cloudwatch、cloudtrail，不過這種方式單說lambda函數(shù)不說，光Terraform代碼沒有幾百行肯定是搞不定的。而使用c7n則只需要寫一條policy，不到20行代碼：- name: ec2-auto-tag-user resource: ec2 mode: type: cloudtrail role: arn:aws-cn:iam:*:role/* events: - RunInstances filters: - tag:CreatorName: absent actions: - type: auto-tag-user tag: CreatorName p