在近年DevOps風潮下,帶動軟體開發人員與IT維運技術人員,密切溝通合作的文化,但為避免事後才發現安全被忽略,如何將相關安全融入持續整合、持續交付過程,也成關切焦點。

在今年10月中舉行的DevOpsDays臺北場,微軟專家技術部雲端架構技術顧問黃承皓,也提出建言,教大家分享在DevOps過程中,將安全納入考量。

以開發者與維運者而言,都有許多需要注意的安全要項,黃承皓表示,微軟在實作上就是依循微軟安全開發生命週期(SDL),以及營運安全保證Operational Security Assurance(OSA),而重點更是要把這兩項結合在一起,成為能夠順利協作的過程。

同時,人員心態的改變也是一大重點,他並列出幾個要項,包括建立威脅模型,程式碼審核、安全測試與依循SDL,以及紅藍隊攻防演練、集中安全監控與滲透測試,並要思考如何偵測到攻擊,以及事件處理與恢復。

對於實務上開發人員和維運者所遇到的一些問題,以開發者的面向來看,最常見到的狀況,就是設計一開始就沒有考慮到安全,或是程式碼審查(code Review)時只檢查功能,沒有檢查安全,黃承皓並認為第三方Library的使用問題,將會越來越嚴重;而在維運者的面向來看,則是在於系統記錄的細節程度、權限的管理,以及自動政策檢查等方面。

他並舉出四個最常見的情境,例如,在老闆指示很重要的服務要立即交付的壓力下,安全就容易被犧牲,其次,維運者可能為了方便,往往希望透過一個Command指令就能直接登入到伺服器,但時程越趕,通常會導致失誤越容易發生;第三是維運者可能認為設定簡單,不會誤用,但設定錯誤的問題其實很常見;最後,抱持自己的系統都沒問題的錯誤觀念。

要如何確保上述狀況不會發生?怎樣在過程中能逐步變得更安全,對應開發者與維運者的面向,黃承皓表示,微軟在實作上就是依循微軟安全開發生命週期(SDL),當中包含了12項要點,以及營運安全保證Operational Security Assurance(OSA),這部分有也11項要點必須注意。

從威脅模型建立做起,並要重視使用開源的安全管理

要尋找系統潛在威脅,建立威脅模型很重要。黃承皓指出,例如,微軟使用自行開發的威脅模型化工具Threat Modeling,可以顯示系統上所有用到的元件,並容易將各個組件關聯畫出,以瞭解可能的漏洞與安全防範建議。

為了讓安全與DevOps更具效率,黃承皓特別說明,他們現在的作法,是將大型系統整合測試(SIT),拆散成單元測試的形式,並且是放到最前面的階段去做,這樣的好處是,帶來效率上的提升,減少開發完交付測試後所需要的時間。

對於使用開源的安全問題考量,他認為,一般開發團隊可能沒有特別去注意,原因是很花時間,因此,他建議最好能找一些商業軟體來輔助,以掌握使用的程式庫是否過期或有已知漏洞等。

同時,他也列出了不少可用的工具,包括NPM Audit、OWASP Dependency Check、GreenKeeper、Snyk、WhiteSource Bolt與DevSkim等,而他們自己是使用WhiteSource的產品。

 

為了更容易挑選適用的工具,由於相關工具的使用都需要去適應,因此在選工具、選流程時,一定要有自動化執行的機制,他建議,不要挑選太複雜會花很多時間的工具。

還有常見的問題在於,像是程式碼寫死(Hard Code)的問題,他表示可使用一些帳密掃描(Credential Scan)工具,在CI/CD的過程中,檢查程式碼中有無帳號密碼等敏感資訊。

關於身分權限安全方面,黃承皓表示,由於身分盜用對企業的傷害相當直接,因此他強調,應確保各個使用者帳號要是最小權限原則,並可採用多因素驗證,或是IP位址限制等方式,防範外部的入侵,而這些偵測過程,也可透過自動化作法去進行,以隨時監看是否有違反政策的情形。

另外,如果是使用Azure的用戶,他也建議,可以參考Secure DevOps Kit的作法,這裡包含了六大重點環節,能夠幫助使用者瞭解如何設計安全的應用程式,其中,他並強調,建立完善的log機制,可供事後分析或是事前警報。

最後,他也指出在流程設計中,從提交前、提交、驗收、生產到維運這5大階段,都有一些要注意的面向,例如,可以透過掃描工具輔助檢查,而相依性的程式庫一定要掃描,而且要懂得實現Infrastructure as code(IaC)的重要性,以及可利用煙霧測試(Smoke test)來檢測報警監控機制是否完善。他強調,必須要在每個階段都加入回饋的機制,並要作為下次更版的改善目標,才能不斷去優化安全流程。

DevOps的5大階段安全策略與建立回饋機制

關於整體流程上的安全考量,黃承皓提出5大階段的安全建議。例如,在一開始的Pre-Commit階段,可使用威脅模型、整合環境安全外掛,以及pre-commit hooks工具、安全程式碼標準,他並指出透過掃描工具去檢查是不錯的選擇,而同儕審查(peer review)也很重要,畢竟人可以看的程度不同。

在提交(Commit)階段,包括靜態程式碼、安全單元測試與相依性管理。他並強調,相依性的程式庫一定要去掃描,否則永遠不會知道發生什麼事。而在驗收(Acceptance)方面,黃承皓指出Infrastructure as code(IaC)的重要性,在實際布署上,有一些作法可以避免產品被入侵後,需要辛苦重建的過程,便於大型災難復原。例如,透過IaC保留現在的Config環境,甚至在每次布署時都使用IaC的方式去重新布署,可以降低被滲透的機會。這是因為APT攻擊的潛伏時間很長,如果自身的環境是不斷被刪掉重建,相對而言,較不易遭受APT入侵。並要執行安全掃描、雲端組態與安全驗收測試(Security Acceptance Testing)等。無論如何,在CI/CD中加入安全機制,確保線上安全品質,才能不斷確保目前線上的安全,並將修正加入CI/CD流程。

在最後兩階段中,其實也有不少需要進行的資安工作。在組態檢查與滲透測試之外,他也指出在紅藍隊情境可用煙霧測試Security Smoke Test,來檢測報警監控機制是否完善,最後並要有持續的監控、威脅情資、滲透測試與非指責性事後調查。另外,他也特別強調,在這五大流程設計中,其實都要有回饋並能加入下一次迭代,才能不斷優化安全流程。


Advertisement

更多 iThome相關內容