iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 11
0
Cloud Native

資安效能,兩全其美系列 第 11

安全工具 + 安全意識 = 更安全的 DevOps【鐵人挑戰11天】

CI/CD 和 DevOps 都是很棒的工具,可以幫我們快速對新漏洞作出補強,並縮短將修補措施上線到實際應用環境所需的時間。
—— Akamai 資深安全技術總監 Patrick Sullivan

雖然業界公認,有必要將「安全」融入持續性整合與發佈(CI/CD)工作流程,但很多企業的 DevOps 和安全團隊依然還在各自為政,並未有效聯手。

研究機構 451 Research 對350名 IT 決策者進行的調查發現,超過半數 DevOps 團隊並未在 CI/CD 流程中進行足夠的安全措施,儘管他們大部分人都認為非常需要這樣做!

很多企業已經開始為規模越來越大的專案建立 DevOps 團隊,這些團隊的軟體發佈速度比以往提高了不少,但很多 DevOps 團隊並不清楚到底該如何在自己的整個工作流程中做到更高程度的安全防護。

在 DevSecOps 社群對超過2,050名專業人士進行的另一個調查中,72%的受訪者認為安全保護機制十分「煩人」;此外有48%的開發者承認,雖然安全性很重要,但他們沒時間加強這方面的工作。

應用程式的安全性測試絕不是可有可無的東西!下列六大最佳實踐,能夠幫助你讓相關工作進行更順利。

在工具鏈中使用自動化工具

我們有必要在 CI/CD 工具鏈中直接加入可自動化執行的安全測試工具。

為確保安全問題不會干擾開發速度和工作流程,一定要建立直接反饋迴路,藉此為開發者提供最可行、並且最重要的漏洞資料。這樣可以確保在撰寫程式碼的同時,隨時發現安全問題並儘快補救。

https://ithelp.ithome.com.tw/upload/images/20181023/20112135wegTbdhppF.jpg

從451 Research 的報告中可以發現,成功進行 DevOps 的最大障礙之一在於缺乏自動化、整合式的安全工具。但對自動化安全工具的需求正在與日俱增,因為現代化企業越來越需要快速將漏洞掃描和測試結果融入到自己的 DevOps 框架中,持續不斷改善產品的品質和安全性。關鍵業務應用的測試應該更頻繁,因為它可能會為企業帶來更大風險。

安全意識應由始至終貫穿全域

應用程式安全測試的傳統方法,是在部署之前設定檢查點;但現在新的開發和部署頻率與速度與過去相比大幅提高,所以這種方法已經不適合了。此外很多開發團隊由於需要不斷招募新人擴大團隊規模,而安全人員的數量往往跟不上這樣的擴展速度:一些開發團隊中,平均每80個開發者才對應一名應用程式安全專家!

應用程式安全專家必須為開發者提供安全工具和相應的流程,並且必須更緊密地與治理和流程管理工作結合,而不能像傳統方法那樣僅僅測試就完事了。

https://ithelp.ithome.com.tw/upload/images/20181023/20112135ummgH2st9X.jpg

僅僅在開發工作的早期階段進行安全測試、快速發現修復安全瑕疵——是不夠的!還需要從過去的錯誤中學習經驗,來確定相同的失誤不會再次出現。

很多人認知裡的「由始至終」往往停在 IDE 中撰寫程式碼的階段,因為從成本方面考量,人們往往會覺得,開發流程中早期階段所使用的開發環境往往是尋找和修復軟體漏洞最「便宜」的地方。但如果想進一步降低相關成本,並提高開發速度,可以考慮利用 SAST(Static Application Security Testing,靜態應用程式安全測試)工具來幫助開發者瞭解如何能寫出更安全的代碼。

特別注意協力廠商的程式碼

開源元件和協力廠商元件可以幫助我們快速裝配出自己的代碼,對 DevOps 方式來說這是一種非常實用的做法。但任何一個存有缺陷的元件,都可能導致整個應用程式的安全性受到威脅。

有調查發現,平均每個應用程式中有71個安全性漏洞源自協力廠商元件,然而使用協力廠商元件的企業中,只有23%會測試這些代碼的安全性漏洞,只有52%的企業會修復這些元件中發現的安全性漏洞。

https://ithelp.ithome.com.tw/upload/images/20181023/20112135cgwNNn5qyN.jpg

元件中哪怕微不足道的一個安全性漏洞,也會對整個應用程式的安全性產生極大影響。因此要妥善管理應用程式用到的所有代碼和元件,同時經常進行測試,這樣才能確保整個應用程式有足夠的安全性。因此最佳做法是將開源元件也納入自己的漏洞掃描流程中。

站在「駭客」的角度做測試

在進行安全測試時,還應該從駭客或惡意使用者的角度來考慮問題。開發者需要考慮駭客或惡意使用者有可能濫用應用程式來瀏覽不同資料或系統時所採取的方式和思路。只有全方位思考惡意使用者有可能利用每個功能做些什麼,開發者才能採取相應的控制措施加以封堵。

https://ithelp.ithome.com.tw/upload/images/20181023/20112135ESTfcHckSp.jpg

好在我們可以編寫腳本並整合到現有 QA 測試中,來檢測這類問題的濫用案例和測試案例,因此並不會增加太大的負擔。同時這種腳本化測試的做法,可以保證在正常的回歸測試之外,定期進行濫用案例的測試。所以開發者可以更容易地建立有足夠安全性的新功能,而無需時時刻刻擔心安全問題。

不要忽略靜態測試

很多企業對滲透測試和動態應用安全測試(DAST)的重視程度遠遠超過靜態應用安全測試(SAST),此外還有很多團隊會在集中構建和單元測試階段進行安全測試,而不會在提交或撰寫程式碼的過程中直接進行安全測試。

https://ithelp.ithome.com.tw/upload/images/20181023/20112135d9l44Rea1t.jpg

儘管 DAST 和滲透測試很重要,但這些工作要等到軟體發展生命週期的後期,有了完整可執行的應用程式之後才能進行。如果能在開發週期的早期階段,經由 SAST 測試,在開發者編寫或簽入代碼的同時,馬上找出可能存在的錯誤,結果將會大不相同。

SAST 雖然無法找出每種類型的漏洞,但如果能主動採用這種做法,往往可以幫助開發者節省大量時間和工作量。

修正檔安裝操作與 CI/CD 相整合

一般來說,攻擊者常常大量利用新發現的漏洞。每當公布新的漏洞,駭客通常會進行大範圍的掃描,找到尚未更新修正檔但包含這種漏洞的應用程式和系統進行攻擊。

而將修正檔測試和部署流程與 CI/CD 和 DevOps 工具鏈相整合,可以讓軟體中發現和修補安全問題所需的時間減少。這時候修正檔管理工作已經不再由營運維護團隊負責,而是變成了開發過程的一環。

https://ithelp.ithome.com.tw/upload/images/20181023/20112135ZaQvSywQ9A.jpg

使用諸如網路應用程式防火牆等機制進行的「虛擬修正檔」,也能縮短針對新漏洞提供保護所需的時間,而在安裝虛擬修正檔後,開發者也有了更充分的時間來製作真正的修正檔。

https://ithelp.ithome.com.tw/upload/images/20181022/20112135LwOIpVXgFR.png


上一篇
每天都在用的 API,到底多紅你瞭嗎?【鐵人挑戰10天】
下一篇
頻獲國際大獎,Akamai 可不光只是 CDN 平台那麼簡單!【鐵人挑戰12天】
系列文
資安效能,兩全其美30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言