重慶交通建設(shè)集團(tuán)有限公司網(wǎng)站seo排名點(diǎn)擊器
一、前言
一般安全都屬于運(yùn)維部下面，和上家公司的運(yùn)維總監(jiān)聊過(guò)幾次一些日常安全工作能不能融入到DevOps中，沒(méi)多久因?yàn)楦鞣N原因離職。18年入職5月一家第三方支付公司，前半年在各種檢查中度過(guò)，監(jiān)管形勢(shì)嚴(yán)峻加上大領(lǐng)導(dǎo)對(duì)安全的重視(主要還是監(jiān)管)，所有部門19年的目標(biāo)都和安全掛鉤。由于支付公司需要面對(duì)各種監(jiān)管機(jī)構(gòu)的檢查，部分安全做的比較完善，經(jīng)過(guò)近一年對(duì)公司的熟悉發(fā)現(xiàn)應(yīng)用安全方面比較薄弱。這部分業(yè)內(nèi)比較好的解決方案就是SDL，和各廠商交流過(guò)之后決定自己照葫蘆畫(huà)瓢在公司一點(diǎn)一點(diǎn)推廣。
上圖為標(biāo)準(zhǔn)版的SDL,由于運(yùn)維采用DevOps體系，測(cè)試也使用自動(dòng)化進(jìn)行功能測(cè)試，版本迭代周期比較快,安全人手不足加上對(duì)SDL的威脅建模等方法也一頭霧水、如果把安全在加入整個(gè)流程會(huì)嚴(yán)重影響交付時(shí)間。在這種情況調(diào)研了一些業(yè)內(nèi)的一些做法，決定把SDL精簡(jiǎn)化 。精簡(jiǎn)版SDL如下：
二、精簡(jiǎn)版SDL落地實(shí)踐
安全培訓(xùn)
SDL核心之一就是安全培訓(xùn)，所以在安全培訓(xùn)上我們做了安全編碼、安全意識(shí)、安全知識(shí)庫(kù)、安全SDK
安全編碼：
我們?cè)诰W(wǎng)上找了一些java安全編碼規(guī)范、產(chǎn)品安全設(shè)計(jì)及開(kāi)發(fā)安全規(guī)范結(jié)合公司實(shí)際業(yè)務(wù)出了一版。
因?yàn)楦鞣N監(jiān)管機(jī)構(gòu)對(duì)培訓(xùn)都有要求，借此推了一下安全培訓(xùn)，定期對(duì)開(kāi)發(fā)和新員工入職的培訓(xùn)。
安全意識(shí)：
公司有企業(yè)微信公眾號(hào)，大部分員工都關(guān)注了，在公眾號(hào)推廣了一波。
宣傳完之后答題，答題滿分送小禮品
因?yàn)槿耸植蛔?#xff0c;而功能測(cè)試和安全測(cè)試本質(zhì)上有很多相通的地方，測(cè)試部門也比較配合，針對(duì)測(cè)試人員做了一些安全測(cè)試相關(guān)的培訓(xùn)，但是效果并不是太理想。
安全知識(shí)庫(kù)：
在漏洞修復(fù)過(guò)程中，開(kāi)發(fā)很多不太了解漏洞原理、修復(fù)方案，所以我們建立了安全知識(shí)庫(kù)，開(kāi)發(fā)先到安全知識(shí)庫(kù)查相關(guān)解決方法。找不到的再和安全人員溝通，安全人員對(duì)知識(shí)庫(kù)不斷更新，形成一個(gè)閉環(huán)。
安全SDK
由于公司有架構(gòu)部門，開(kāi)發(fā)框架基本是架構(gòu)部門提供。我們將一些常見(jiàn)的漏洞和架構(gòu)部門溝通之后，讓架構(gòu)將一些漏洞修復(fù)方式用SDK實(shí)現(xiàn)，開(kāi)發(fā)只需要導(dǎo)入JAR包，在配置文件中配置即可。其中也挺多坑的，需要慢慢優(yōu)化。
三、 安全需求設(shè)計(jì)
公司有項(xiàng)目立項(xiàng)系統(tǒng)，所有的項(xiàng)目立項(xiàng)都需要通過(guò)系統(tǒng)來(lái)進(jìn)行立項(xiàng)，安全為必選項(xiàng)，評(píng)審會(huì)安全也必須要參與
這個(gè)時(shí)候基本上項(xiàng)目經(jīng)理會(huì)找安全人員進(jìn)行溝通，copy了一份VIP的產(chǎn)品安全設(shè)計(jì)規(guī)范，根據(jù)需求文檔和項(xiàng)目經(jīng)理確定安全需求。
確認(rèn)好安全需求之后將按需求加入到需求文檔，并確認(rèn)安全測(cè)試時(shí)間，此流程只針對(duì)新項(xiàng)目，已經(jīng)上線的項(xiàng)目的需求并未按照此流程，后續(xù)在安全測(cè)試時(shí)候會(huì)講到這部分的項(xiàng)目是怎么做的。
四、開(kāi)發(fā)、安全測(cè)試
安全測(cè)試主要分為代碼審計(jì)，漏洞掃描，手工安全測(cè)試。由此衍生出來(lái)的安全產(chǎn)品分為3類。DAST：動(dòng)態(tài)應(yīng)用程序安全測(cè)試 (wvs,appscan)、SAST：靜態(tài)應(yīng)用程序安全測(cè)試 (fortify,rips)、IAST：交互式應(yīng)用程序安全測(cè)試 (seeker，靂鑒),這三種產(chǎn)品的詳細(xì)介紹可以參考https://www.aqniu.com/learn/46910.html,下圖為三種產(chǎn)品的測(cè)試結(jié)果對(duì)比。
這幾類產(chǎn)品實(shí)現(xiàn)了自動(dòng)化可以繼承到DevOps中。接下來(lái)我們將這些工具融入到開(kāi)發(fā)測(cè)試階段。
IAST的實(shí)現(xiàn)模式較多，常見(jiàn)的有代理模式、VPN、流量鏡像、插樁模式，本文介紹最具代表性的2種模式，代理模式和插樁模式。一些調(diào)研過(guò)的產(chǎn)品如下圖，具體測(cè)試結(jié)果就不公布了。
開(kāi)發(fā)階段
在對(duì)幾類產(chǎn)品調(diào)研的時(shí)候發(fā)現(xiàn)IAST的插樁模式可以直接放到開(kāi)發(fā)環(huán)境，開(kāi)發(fā)環(huán)境和測(cè)試環(huán)境的代碼區(qū)別主要還是在于application.yml配置文件，所以可以提前將該模式放到開(kāi)發(fā)階段。
開(kāi)發(fā)寫完代碼提交到gitlab部署到開(kāi)發(fā)環(huán)境啟動(dòng)應(yīng)用的時(shí)候，開(kāi)發(fā)需要驗(yàn)證一下功能是否可用，這個(gè)時(shí)候就可以檢測(cè)出是否存在漏洞。
公司在測(cè)試環(huán)境使用rancher，把IAST的jar包放入到項(xiàng)目的gitlab,在部署的時(shí)候把代碼拉到本地，通過(guò)修改Dockerfile文件把jar包添加到容器。
ADD shell/xxx.jar /home/app/xx/lib
由于公司項(xiàng)目基本統(tǒng)一使用spring-boot，所有的項(xiàng)目都通過(guò)一個(gè)start.sh腳本來(lái)啟動(dòng)應(yīng)用，start.sh和Dockerfile一樣需要添加到項(xiàng)目的gitlab，同時(shí)修改start.sh腳本文件即可。
-javaagent:$APP_HOME/lib/xx.jar -jar $APP_HOME/app/*.jar --spring.profiles.active=dev >$APP_HOME/logs/startup.log 2>&1 &
測(cè)試項(xiàng)目如下，忽略錯(cuò)別字：
開(kāi)發(fā)提交代碼部署完之后，訪問(wèn)一下正常的功能即可在平臺(tái)上看見(jiàn)是否存在漏洞。
部分產(chǎn)品同時(shí)還會(huì)檢測(cè)第三方組件包。
公司使用harbor來(lái)對(duì)鏡像進(jìn)行當(dāng)倉(cāng)庫(kù)鏡像，項(xiàng)目部署完成之后會(huì)打包成一個(gè)鏡像上傳到harbor，harbor自帶鏡像掃描功能。
測(cè)試階段
開(kāi)發(fā)完成之后進(jìn)入到測(cè)試階段。這個(gè)階段我們進(jìn)行靜態(tài)代碼掃描，功能測(cè)試，安全測(cè)試。
靜態(tài)代碼掃描
利用靜態(tài)代碼掃描工具對(duì)代碼在編譯之前進(jìn)行掃描，并在靜態(tài)代碼層面上發(fā)現(xiàn)各種問(wèn)題，其中包括安全問(wèn)題。部分工具列表：
靜態(tài)代碼掃描我們采用sonarQube集成，我們使用的是FindbugSecurity,精簡(jiǎn)規(guī)則，然后在持續(xù)構(gòu)建過(guò)程中，進(jìn)行靜態(tài)代碼bug,安全掃描。
靜態(tài)代碼掃描的同時(shí)也可以掃描第三方依賴包，OWSAP的Dependency-Check就可以集成到持續(xù)構(gòu)建過(guò)程中，由于IAST類產(chǎn)品支持該功能，不多做介紹。
功能測(cè)試
功能測(cè)試方面，公司測(cè)試部門實(shí)現(xiàn)了自動(dòng)化測(cè)試平臺(tái)，前期我們并未使用agent的方式檢測(cè)，一開(kāi)始使用開(kāi)源的gourdscan加上openrasp，利用openrasp的默認(rèn)開(kāi)啟不攔截模式和漏洞記錄功能來(lái)檢測(cè)服務(wù)端無(wú)返回的漏洞。
只需要在自動(dòng)化平臺(tái)上配置代理IP：
openrasp漏洞記錄
后來(lái)測(cè)試反饋掃描的臟數(shù)據(jù)太多，效果也并不是很好，就放棄了此方案。改用開(kāi)發(fā)階段的IAST的插樁方式，同樣在測(cè)試環(huán)境也和開(kāi)發(fā)環(huán)境一樣利用agent來(lái)檢測(cè)問(wèn)題。功能測(cè)試完成之后。由于測(cè)試人員對(duì)漏洞并不是太理解，所以定的流程為測(cè)試人員到平臺(tái)查看報(bào)告和安全人員溝通哪些問(wèn)題需要修復(fù)，然后將問(wèn)題寫入到測(cè)試報(bào)告
安全測(cè)試
在測(cè)試階段已經(jīng)將安全加入到整個(gè)流程里面，所有需求更改完成都需要通過(guò)功能測(cè)試，也就是所有的流程過(guò)一遍安全測(cè)試，這樣安全人手也不是很足，決定采用內(nèi)外服務(wù)區(qū)分的辦法來(lái)確定是否需要安全人員介入
漏洞管理
漏洞管理這一塊制定了漏洞管理制度，根據(jù)影響程度對(duì)漏洞進(jìn)行評(píng)級(jí)，嚴(yán)重漏洞必須改完之后才能上線，高中低危漏洞且影響較小需要排期，安全人員定期跟蹤漏洞修復(fù)情況。
五、 監(jiān)控
支付公司一般安全設(shè)備基本都有，這一塊基本上將設(shè)備的syslog打到日志中心可視化，并定制對(duì)應(yīng)的規(guī)則實(shí)現(xiàn)告警即可
六、結(jié)束語(yǔ)
個(gè)人知識(shí)和經(jīng)驗(yàn)不足對(duì)sdl的體系并不是很熟悉，沒(méi)什么經(jīng)驗(yàn)，所以只能做到目前的程度。后續(xù)還有許多地方可以優(yōu)化，增加流程等。如果有什么好的建議歡迎交流