普元DevOps平臺的安全可靠設計

轉載本文需註明出處：微信公衆號EAWorld，違者必究。

引言：

普元DevOps平臺覆蓋從需求到運維，力求幫助團隊提高工做效率、保障系統質量。在安全可靠層面，平臺須要考慮自身如何跨環境且流程合規，還需保障所生產的軟件的安全可靠。
本文從流程、代碼、介質、環境等角度出發，重點聚焦在安全可靠建設過程當中的一些思路與技術支撐，最終造成平臺級的建設方法與體系。

目錄：

1. DevOps平臺的安全可靠涉及哪些方面？
2. DevOps平臺安全可靠的設計與實現思路
3. 普元DevOps平臺的當前能力與後續計劃

1. DevOps平臺的安全可靠涉及哪些方面？

衆所周知，如今國家對安全可靠、自主可控這些方面的要求很高，也讓咱們團隊從新審視DevOps產品在這方面須要如何改善和演進。



咱們從兩方面來看平臺的安全的可靠：
 

1. 平臺自身，考慮到DevOps平臺的必定特殊性（跨環境、跨部門），在自身的合規、數據隔離等方面顯得尤其重要
2. 軟件生產，平臺支撐了軟件交付的整個過程，在生產過程的各階段，須要對最終軟件的安全可靠造成協力，儘早發現相關風險

1、平臺自身的安全可靠

平臺自身來看，包含如上圖四個方面：
 

1. 無單點：這裏包含兩個意思，平臺集成的三方中間件較多，須要保障其爲集羣模式；再一個即便某些中間件徹底故障了，也不能影響整個DevOps平臺的運行
2. 數據與環境隔離：不一樣項目、不一樣團隊的數據要保證隔離，一個項目的多套環境，多套介質一樣要保證隔離
3. UI與API的權限控制：對界面的菜單、按鈕進行權限控制，對後臺api的訪問權限進行權限控制
4. 可審計：對於什麼人在何時在平臺上作了什麼，在動做先後資源產生了這樣的變動

2、軟件生產的安全可靠



軟件生產過程咱們則是從需求、設計開發、構建測試、發佈、運維這幾個階段來梳理安全可靠的一些關鍵點的。

2. DevOps平臺安全可靠的設計與實現思路

咱們就從平臺自身和軟件生產兩大方面，分別舉例來講說安全可靠方面的一些實現思路。

平臺自身 — 平臺無單點



正如以前對無單點的描述，平臺須要解決兩類無單點：

好比咱們使用了jenkins，jenkins的集羣是一主多從的模式，這個存在必定的單點問題（master），之間的通訊模式有兩種（ssh和jnlp），在屢次測試後，最終選擇的是jnlp（ssh可靠性存在問題），master單點問題則經過多套jenkins集羣來部分解決；

再好比使用jira來進行項目管理，但jira這種商業產品通常不會部署集羣，因此平臺另外一方面要考慮的則是即便jira宕機，仍舊能夠保證平臺的可靠運行（因此平臺還會提供工做項本地存儲的模式）。



平臺最終的默認部署架構則如上圖，每一個節點首先要解決自身的可靠方案，考慮到數據和網絡的安全，像堡壘機、介質庫代理模式也都在整個平臺的默認部署架構中。

平臺自身 — 數據與環境的隔離



再來看數據與環境的隔離：



好比介質庫，首先各項目的介質庫要隔離，一個項目的開發庫、測試庫、投產庫一樣要隔離，測試經過的介質，則經過可控的同步手段發到投產庫。



再好比部署引擎，什麼引擎可針對什麼環境進行部署操做，也是嚴格控制的，防止環境操做越權。



再有就是部署的操做，什麼人審批仍是可自動執行，部署完成後由誰確認（亦或是經過自動化測試確認），這些關鍵事項，須要結合不一樣團隊的實際狀況進行不一樣的個性化配置。

軟件生產 — 需求任務管理的安全可靠



需求任務的管理核心是風險識別，對進度要嚴格把控，一般包括四個視角：
 

1. 當前項目版本中的積壓（backlog）狀況，一個項目週期中，正常來說時間過了50%，積壓項和完成項也應差很少是1:1的狀態
2. 我的代辦的風險，時刻關注團隊中每一個人的當前積壓任務
3. 當日工做的風險，這在天天的例會上最關注的視角
4. 特別需求的風險，在敏捷模式下比較常態，將特殊需求調整優先級或直接置頂，並在必定時間窗口由某我的特別關注與跟蹤

因此下面的一些看板模式，都是爲上述的一些風險識別場景而提供的。

關注項目積壓：



關注我的積壓：



今日關注與特別關注：



軟件生產 — 開發測試的安全可靠



這個階段的兩個核心工件是代碼和介質，是須要重點保障安全可靠的。

代碼質量包括開發禁止項，代碼靜態掃描、提交信息合規等，之因此把開發禁止項與靜態掃描分開說，主要是目前技術實現上手段區別（目前咱們的開發禁止項還不太能經過自動的靜態掃描來發現）。

好比開發禁止項的一些具體細項，咱們目前仍是經過規範、設計和review來作的：
 

• 禁止將大量業務數據存在會話區
• 禁止明文傳輸敏感數據
• 禁止使用XA數據源
• 對錶數據10K+的查詢必須分頁
• 禁止使用非maven模式依賴三方jar
• ……

靜態掃描，在平臺上則是經過集成三方工具來實現，不過相關的代碼掃描工具備不少，在具體抉擇時，是從下面幾個維度來考慮的。


目前在咱們平臺上集成的是sonar、fortify、checkmarx等，經過在CI流水線中定義，並將執行報告直接展現在安全質量的界面上。

在代碼提交時，爲保證相關提交有跡可循（解決什麼問題），也爲後續可以反向統計需求的一些具體開發過程，對代碼提交也進行了嚴格控制，對不符合規範的代碼提交，是沒法代碼入庫的（hook控制）。



在介質方面，要作到安全合規，對介質中的一些介質（尤爲三方介質），要快速發現其商業風險，好比license：



這裏尤爲對於一些老系統，裏面的jar沒法直觀的看出來源、版本等，平臺是須要幫助項目快速找到源信息，並創建起相關信息庫。

在介質管理方面，像黑鴨、傑蛙這些公司已經在這個領域積累了很好的安全庫，因此咱們也在考慮與這些產品進行合做對接。

軟件生產 — 發佈的安全可靠

在軟件發佈時，經過技術保障來屏蔽發佈失敗的風險。考慮到不一樣的應用服務器或底層環境的差別，每一箇中間件上的實現手段則會存在必定的區別，這裏以websphere上的應用發佈爲例：



須要考慮如何備份，卸載後安裝仍是直接更新，是否須要重啓，如何探測部署的成功或失敗，失敗後是否須要回退，以及如何回退，這些都須要在平臺提供的websphere部署任務上可配，才能保證發佈的安全可靠。

除了上述部署流程執行外，在部署以前還要有不少的探測或預執行能力，擺闊檢查網絡可達、腳本執行權限、進程的存活、端口的可用、配置的正確與否，這些都是平臺須要內置能力。

3.普元DevOps平臺的當前能力與後續計劃

最後總結下咱們目前在平臺安全可靠上所集成的工具以及基於這些作了些什麼特性。



在每一個階段經過集成三方的開源或商業工具，來提供上層能力，但也避免被三方綁定，因此會對集成模型與接口進行抽象，並隨着不斷迭代，本身也能提供下層部分產品能力。

普元DevOps平臺的後續計劃



後續咱們還會積極與廠商合做，同時積累本身在安全、合規這些方面的基線庫，並將更多的開放生態中的東西集成進來，不斷提高此領域能力。

 

關於做者：顧偉，現任普元信息主任架構師，長期致力於IT技術研究、產品設計與開發、架構諮詢等工做，擅長Web、OSGI、CI/CD、服務治理、雲計算等領域技術；對DevOps、自動化運維、微服務架構有着濃厚的興趣。


關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享。長按二維碼關注！