微軟DevOps資安實務大公開，側重威脅模型建立與自動化

在近年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，來檢測報警監控機制是否完善，最後並要有持續的監控、威脅情資、滲透測試與非指責性事後調查。另外，他也特別強調，在這五大流程設計中，其實都要有回饋並能加入下一次迭代，才能不斷優化安全流程。